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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
