Messages in this thread | | | Date | Wed, 1 Mar 2006 18:19:30 -0700 | From | "Eric D. Mudama" <> | Subject | Re: LibPATA code issues / 2.6.15.4 |
| |
On 3/1/06, Nicolas Mailhot <nicolas.mailhot@gmail.com> wrote: > Le mercredi 01 mars 2006 à 14:22 -0500, Mark Lord a écrit : > > Nicolas Mailhot wrote: > > >> > > > How about the drives that got blacklisted following : > > > http://bugzilla.kernel.org/show_bug.cgi?id=5914 ? > > > and > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951 ? > > > > > > Device Model: Maxtor 6L300S0 > > > Firmware Version: BANC1G10 > > > > > > on Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) > > > > Mmm.. somebody with one of those controllers should check > > to see if *any* drives work with FUA, and blacklist the controller > > instead of the drives if everything is failing. > > I'm a someone with such a controller (that's my boog here) > But I only have these drives. > So I can only confirm the combo it deadly. > (I could possibly try to plug one on the nforce4 controller, not sure if > extracting the box from the tangle of cables and hardware he's part of > is worth it. sata_nv is rev-eng, while the siI docs are public, right?) > > I do suspect Eric D. Mudama knows if the problem is on the hard-drive > side though > > Regards, > > -- > Nicolas Mailhot > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.1 (GNU/Linux) > > iEYEABECAAYFAkQGKmoACgkQI2bVKDsp8g0veQCggJkweq1nQn7YNSEIobOHitk0 > QXsAn0TnHI/6LBG9nezBnS0MTskLml0W > =s1TM > -----END PGP SIGNATURE----- >
I didn't know offhand so we plugged in a bus analzyer and took a look here in the lab... We didn't have a 3114 lying around, but issuing the Write DMA FUA (0x3D) opcode on a 3112 resulted in a D0h soft hang. I think they're related (4-port vs 2-port).
Looking at the bus trace, the command is issued on the SATA bus, the drive generates a DMA Activate FIS which is accepted by the 3112, and then the 3112 generates a Data Payload FIS (46h) with no contents.
The first DWORD of the payload is a HOLD primitive, to which the device promptly responds with HOLDA, and the two are in a soft bus lock and will sit forever. No data is ever generated by the host (stopped capture after 4 seconds).
I believe this core should not be part of the FUA whitelist. If I remember correctly, there are other implementations out there with similar limitations to opcodes this "new" to ATA.
--eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |