Date: Sat, 27 Feb 1999 03:08:21 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Sheldon Hearn <sheldonh@iafrica.com> Cc: Pierre Beyssac <beyssac@enst.fr>, Greg Lehey <grog@lemis.com>, freebsd-current@FreeBSD.ORG Subject: Re: IDE CDROM not found with PIIX4 chipset, -current kernel Message-ID: <36D6E315.91969389@newsguy.com> References: <71924.920022976@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > > > It was somehow distressing, though, that the new code had the exact > > same bug as the old, even though it was quite different code. > > When you say "the new code", are you referring to the newer acd driver > as opposed to the older wcd driver? If so, do you think it'll be worth > my while trying to mangle into the acd code your diffs against the wcd > code? No. As I said, that was ages ago... :-) Once we had a wd.c whose code path was quite different from what we have (had) in wd.c now. i368/1730. Funny that did doesn't seem to be the original PR that was fixed, but one applying to the "new" (then :) code. Didn't have much success searching for my own PRs. It ought to do substring searching on the web pages, but it doesn't. :-( OTOH, it seems some of my PRs were filed as confidential, even though they were not, so that my also explain why I couldn't find the other PR. Relevant parts: > This happens because a DELAY is missing in one loop, and ARS_BSY > flag is being ignored in another (atapi_request_immediate and > atapi_wait_cmd functions). On the code: > ireason = inb (ata->port + AR_IREASON); > ac->result.status = inb (ata->port + AR_STATUS); > phase = (ireason & (ARI_CMD | ARI_IN)) | > - (ac->result.status & ARS_DRQ); > + (ac->result.status & (ARS_DRQ|ARS_BSY)); > if (phase == PHASE_CMDOUT) > break; > DELAY (10); The missing delay is not relevant. (Or, at least, I hope acd is not missing delays in wait loops!) The problem is the ARS_BSY signal. If my memory doesn't fail me, if ARS_BSY is active, then the other signals may contain trash. In this particular loop, ARS_BSY could be active, but it wasn't being checked for, on the assumption that ARS_DRQ would only be up (down?) when the operation completed. Mmmmm.... Found my PRs now. It definitely looks like a PR went confidential... :-( I think I explained the bug a lot better on the other one... :-( Oh, well. Well, feel free to search for ARS_DRQ and ARS_BSY on acd (if it uses the same defines...). The ATAPI document I used was SFF8020. It might have been obsoleted by now. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36D6E315.91969389>