From owner-freebsd-bugs Mon Mar 24 12:20:06 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
by freefall.freebsd.org (8.8.5/8.8.5) id MAA02710
for bugs-outgoing; Mon, 24 Mar 1997 12:20:06 -0800 (PST)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.8.5/8.8.5) id MAA02701;
Mon, 24 Mar 1997 12:20:02 -0800 (PST)
Resent-Date: Mon, 24 Mar 1997 12:20:02 -0800 (PST)
Resent-Message-Id: <199703242020.MAA02701@freefall.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org,
Received:(from nobody@localhost) by.freefall.freebsd.org.id.MAA02297;Mon; (8.8.5/8.8.5);,
24 Mar 1997 12:10:04.-0800 (PST)
Message-Id: <199703242010.MAA02297@freefall.freebsd.org>
Date: Mon, 24 Mar 1997 12:10:04 -0800 (PST)
From: troyd@euler.com
To: freebsd-gnats-submit@freebsd.org
X-Send-Pr-Version: www-1.0
Subject: i386/3083: Toshiba XM-5702B ATAPI CDROM not detected (fix included in this PR)
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>Number: 3083
>Category: i386
>Synopsis: Toshiba XM-5702B ATAPI CDROM not detected (fix included in this PR)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Mar 24 12:20:01 PST 1997
>Last-Modified:
>Originator: Troy De Jongh
>Organization:
Euler Solutions (consultant)
>Release: 2.1.7 Security CDROM release
>Environment:
FreeBSD 2.1.7-RELEASE #0: Wed Feb 19 23:08:10 1997 jkh@thingy.cdrom.com:/usr/src/sys/compile/
GENERIC
>Description:
The Toshiba XM-5702B ATAPI CDROM drive in my Micron box is not detected
by the stock kernel. In the atapi_probe() routine, the code expects
to eventually find 0 in the status (AR_STATUS) register. For some
reason, at bootup the value in this register is always 0xff. Because of
this,if debugging is turned on in atapi.c, you will see the ATAPI code
fail to detect the Toshiba 12X drive in this manner (I've included
a few lines of additional context from the dmesg output):
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: NEC 72065B
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <QUANTUM FIREBALL_TM2550A>
wd0: 2445MB (5008752 sectors), 4969 cyls, 16 heads, 63 S/T, 512 B/S
atapi0.1 at 0x1f0: attach called
atapiX.1 at 0x1f0: identify not ready, status=0
wdc1 at 0x170-0x177 irq 15 on isa
atapi1.0 at 0x170: attach called
atapiX.0 at 0x170: controller busy, status=ff<busy,ready,fault,opdone,drq,corr,check>
atapi1.1 at 0x170: attach called
atapiX.1 at 0x170: controller busy, status=ff<busy,ready,fault,opdone,drq,corr,check>
bt0 not found at 0x330
uha0 not found at 0x330
aha0 not found at 0x330
The "controller busy" line is seen because the status (AR_STATUS)
register doesn't change and the timeout is reached.
>How-To-Repeat:
Boot up a kernel on a Micron P133 with a Toshiba ATAPI XM-5702B drive
located at 0x170.
(If more info is needed, feel free to send me email at troyd@euler.com).
>Fix:
This is a quick workaround that worked for me. Since I'm not an
ATAPI deity, I'll leave it to someone else to actually verify
that my code won't break something else. Here's an explanation
of what I did. I simply ignore the status (AR_STATUS) register
if its value is 0xFF upon entering the atapi_probe routine and
I don't attempt to wait for a change in status. Instead I jump
straight ahead to where the IDENTIFY command is issued to the
device. Here's the unified diff:
--- atapi.c0 Mon Mar 17 17:22:23 1997
+++ atapi.c Mon Mar 24 13:15:27 1997
@@ -318,11 +318,13 @@
struct atapi_params *ap;
char tb [DEV_BSIZE];
+ if(inb(port + AR_STATUS) != 0xff) { /* TDJ HACK */
/* Wait for controller not busy. */
if (atapi_wait (port, 0) < 0) {
print (("atapiX.%d at 0x%x: controller busy, status=%b\n",
unit, port, inb (port + AR_STATUS), ARS_BITS));
return (0);
+ }
}
/* Issue ATAPI IDENTIFY command. */
>Audit-Trail:
>Unformatted: