On Fri, 1 Jun 2007, Jeff Garzik wrote: > > With these old PATA devices, device reset is "six of one, half-dozen of the > other." Using SRST is the only way to kick some ATAPI devices into working: > http://suif.stanford.edu/~csapuntz/blackmagic.html#reset Well, wouldn't it be a good thing to 1) if BUSY/DRQ is set even before you try the problem, obviously skip the two polite cases, and go to #4 2) try to just do an IDENTIFY 3) if that doesn't work, do a HOST RESET and then try again 4) if that doesn't work, do the full SRST (or some variation of the above). That at least has the potential to get you six working devices, and half a dozen other working devices, for a total of 12. With no unnecessary resets or long timeouts! (Btw, the 150ms wait after reset is really nasty. A few of those, and we're wasting seconds during bootup. Why the hell does it do that, when the old driver - and the spec - said 2ms?) > I'm mainly interested in hearing feedback from Fedora 7 damage, before making > a major decision about the probing code. If this is a single dain bramaged > device, we should avoid punishing the majority. But if this is a trend, it > warrants careful reconsideration. I thought the default in Fedora was to use the PATA driver first? If so, you're going to miss a lot of cases that "just work", because they use the old driver. At least that was what my situation was on the P4 that I recently complained about the "set transfer mode" problem: it used to use the old PATA drivers that didn't have the issue, so I never even _knew_ the new libata-based code had problems. Linus - 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
