Fajun Chen wrote: > Hi Andrew, > > The part of the puzzle is that I have not found a baseline where it > works. I do need to do more controlled and comparative testing. One on > my list is to test the same code on i386 hardware. It's also a good > idea to test without using SG as you suggested. But what are my > alternatives to get both PATA and SATA support without sg? sd > interface, sg read/write instead of sg ioctl (probably little code Fajun, I assume you meant "_sd_ read/write instead of sg ioctl". If so, then FYI, the SG_IO ioctl is available on all block devices that accept SCSI commands in the lk 2.6 series. There are some small differences (see www.torque.net/sg/sg_io.html ) but I would think that your test programs using the sg driver should work ok with the sd driver. Direct and mmap()-ed IO are done differently. > difference here). For PATA, IDE path may be worthy of testing, but it > would require quite extensive change to my test application. >From Russell King's earlier response it sounds like it could be an architecture issue. Quite a few folks use the sg driver for SCSI and SATA device bashing. Doug Gilbert > On 8/20/06, Andrew Morton <akpm@xxxxxxxx> wrote: >> On Sun, 20 Aug 2006 03:30:56 -0600 >> "Fajun Chen" <fajunchen@xxxxxxxxx> wrote: >> >> > Hi Folks, >> > >> > I use ATA pass through via sg ioctl interface for data read/write. Two >> > kernels were tested: >> > Linux 2.6.15.4 with Jeff Garzik's libata patch (pata support) >> > Linux 2.6.18-rc2 with Jeff Garzik's git libata patch (new EH, hotplug, >> > pata support) >> > Hardware: ARM IOP80321 with PCI-X >> > Host adapters: sata Sil3124 and pata Sil680 >> > Test algorithm: random write-read-compare (same range) >> > >> > I've tried sg mmap, direct and indirect IO on both 2.6.18-rc2 and >> > 2.6.15.4 release, none of the combinations survived data compare >> > overnight test. I also tried to change cache policy to write through >> > on 2.6.15.4, no luck either. Several different symptoms were >> > observed among the failures: >> > 1. A few bytes in a data pattern were not written correctly to the >> > disc (low data miscompare rate) >> > 2. Pretty much none of the data were written correctly to the disc >> > (high data miscompare rate) >> > 3. Data were written to the disc correctly but miscompares when read >> > it back. What's weird is that when the read buffer was printed out >> > right after data miscompare , it contains the correct data! >> > Sg write failures (symptom #1 and #2) are more typical than read >> > failure (symptom #3). This problem has been observed on many >> > different test machines with both pata and sata drives. >> > >> > I don't know of a good way to trace and isolate the problem yet. Since >> > data miscompare issue can be caused by issues from different >> > subsystems, I cc'ed some subsystem maintainers here. Any information >> > or suggestions are greatly appreciated. >> > >> >> Have you tested the same hardware to the same extent without using the SG >> interface? Say, using read() and write()? That'll help us determine >> whether the problem is related to the sg stuff, or to something else, >> like >> a hardware failure. >> > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
