[cc'ing Mark, Bart and Sergei. Hi] Alan wrote: >>> This makes unreliable cable detection even more unreliable. Please >>> consider for -stable. Thanks. > > At minimum you also need to stop doing drive side detect for PATA_CBL_80 > as many controllers don't do both so if you've got host side detect that > is what you must trust. > > Fixed that in my internal tree and it seems happier It seems libata is wrong about device side cable detection. Device side cable detection tries to detect host side capacitor connected to PDIAG-, depends on the slave device releasing PDIAG- signal. According to Annex B of ATA/ATAPI-5, IDENTIFY should be issued to the slave device first to ensure that it releases PDIAG- and then use the cable detection result from the master device. As we IDENTIFY master first right after reset, slave if present is driving PDIAG-, so the master on IDENTIFY always thinks the capacitor is present and 40c limit is always applied. IDE is better off because it doesn't reset before IDENTIFYing and it's likely that BIOS has issued some commands to the slave device prior to passing control to OS thus making it release PDIAG-. 1. Device side cable detection can only be used to limit speed because if motherboard doesn't have capacitor attached to PDIAG-, the test result always indicates 80c. 2. Host side detection involves issuing commands to attached devices because it depends on the slave device releasing PDIAG-, so most controllers do cable detection in BIOS and just put the result in PCI config region or wherever. We dunno how BIOS does it exactly but many of them probably consider device side detection result as well. So, considering #1 and #2, it might be best to just believe what the controller (BIOS) says and not bother about device side detection. In fact, we've been effectively ignoring device side detection result before my "fix" for device side cable detection. What do you think? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
