Date: Sun, 19 Jan 2003 10:31:05 -0800 (PST) From: "James J. Ramsey" <jjramsey_6x9eq42@yahoo.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: freebsd-bugs@freebsd.org Subject: Re: Possible bugs in setting UDMA speed (Re: Semirandom bug in FreeBSD's ATA querying) Message-ID: <20030119183105.67054.qmail@web10703.mail.yahoo.com> In-Reply-To: <20030119064755.GA362@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- David Schultz <dschultz@uclink.Berkeley.EDU> wrote: > Probing ATA devices is really simple: you issue a > command to the > device to identify itself, and it obliges. From what I've heard, it's simpler in theory than in practice because ATA is a rather crufty, clumsy standard. Now what if FreeBSD is 1) failing to detect that the IDE cable is not fit for UDMA66, or 2) issues the identify command before it detects that the cable isn't fit for UDMA66? Those are concrete possibilities that can be checked out, either by having the maintainers check the code, or by having someone with slightly different hardware try to duplicate that might produce the error. > So even > though > something only goes wrong as a result of a bad cable > or drive, the > reason that the problem affects only FreeBSD is that > FreeBSD does > its delay differently after issuing a command than > Linux and > Windows do. If the cable were flaky, Linux and Windows would likely show ugly things like data corruption. The only possibility I can think of where the cable could be at fault would be 1) if the cable were nominally designed for ATA66 but couldn't really handle it, and 2) if Linux and Windows were both conservative about disk I/O speed, thus masking the cable's unfitness. > Moreover, FreeBSD's approach seems to > work for > everyone's hardware but yours. Don't be so sure that the problem is quite so specific to my hardware. Bear in mind that most of those who can't get FreeBSD to install cleanly on their hardware will not bother, or even have the time to bother, with conducting experiments to try to narrow down the problem. Never assume that because only one person reports a problem that only one person has the problem, especially if the problem leaves behind few and cryptic clues. > Since you're the only one who can reproduce the > problem, I'm the only one who has so far reproduced and documented the problem. It seems to me that a smart move would be to try to duplicate the problem on slightly different hardware. Now that I've got a working before-and-after scenario, the most difficult parts of reproducing the problem would be 1) finding the spare machine, 2) finding the spare time, and 3) finding a spare IDE cable that is not meant handle ATA66. > it would > be helpful if you could try Bruce's suggestions of > adding delays. > A kludgy but reliable way to do this is with the > statement > tsleep(NULL, PRIBIO, "atawt", hz / 20); > Another thing you might try before you do that is to > modify the > ata_command() call in ata_getparam() so that the > last argument > is ATA_WAIT_READY instead of ATA_IMMEDIATE or > ATA_WAIT_INTR. I'd rather wait until someone else has done some bug checking or testing before doing something as drastic as installing FreeBSD just to try to debug it. Even if the checks or tests turned out to be a bust, that would at least a sign that somebody else is really trying to figure out where the problem lies instead of just assuming it's a hardware issue. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030119183105.67054.qmail>