Date: Sun, 19 Jan 2003 13:20:11 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: jjramsey@pobox.com Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: Possible bugs in setting UDMA speed (Re: Semirandom bug in FreeBSD's ATA querying) Message-ID: <20030119212011.GA794@HAL9000.homeunix.com> In-Reply-To: <20030119183105.67054.qmail@web10703.mail.yahoo.com> References: <20030119064755.GA362@HAL9000.homeunix.com> <20030119183105.67054.qmail@web10703.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake James J. Ramsey <jjramsey_6x9eq42@yahoo.com>: > --- 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. No, you don't understand. The IDENTIFY DEVICE command does not use UDMA; it's a simple packet command. The device itself is responsible for detecting the cable type by determining how long it takes for a particular capacitor to charge, and it reports the result as part of the response to the IDENTIFY DEVICE command. The only caveat mentioned in the standard is that for obscure reasons, the driver needs to probe the slave before probing the master, and the FreeBSD driver does that. So to address the possibilities you mention: 1) FreeBSD looks at the correct bit to see what kind of cable is in use. This isn't rocket science, and it actually works on all of the devices I have used. (The ATA standard warns that the device's detection mechanism isn't 100% reliable; however, you have a different problem. See (2).) 2) The IDENTIFY (PACKET) DEVICE command works with both types of cable and on any device that supports packet mode. Also, I *have* tried to duplicate your problem. When I use 40-pin cables, my Quantum FB+ 20.5 still works and the driver reports ``DMA limited to UDMA33, non-ATA66 cable or device''. When I attach a CD-ROM to the same channel, it still works. > > 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. As I said, the distinction between a 40-pin and 80-pin cable is not relevant from the point of view of identifying the device correctly. That's why I think the problem may have been the CD-ROM. > > 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. [...] > > Since you're the only one who can reproduce the > > problem, What I meant is, you seem to be the only person who can reproduce this problem right now. Therefore, I think it would be most helpful to Soeren (the ATA driver maintainer) if you could do a little bit of testing. Saying ``the code is broken'' doesn't help when there is no indication as to what might be wrong, or why even similar hardware (such as mine) doesn't have any problems. > 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. Okay, okay...I'll try the old Promise controller and a CD-ROM that only supports PIO mode to see if either of those make a difference. Fingers crossed... 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?20030119212011.GA794>