From owner-freebsd-current Fri Feb 26 10:10:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BBA7314F9E for ; Fri, 26 Feb 1999 10:10:06 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA06389; Sat, 27 Feb 1999 03:09:23 +0900 (JST) Message-ID: <36D6E315.91969389@newsguy.com> Date: Sat, 27 Feb 1999 03:08:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Sheldon Hearn Cc: Pierre Beyssac , Greg Lehey , freebsd-current@FreeBSD.ORG Subject: Re: IDE CDROM not found with PIIX4 chipset, -current kernel References: <71924.920022976@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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