Date: Mon, 19 Mar 2001 12:00:04 -0800 (PST) From: "Matthew Emmerton" <matt@gsicomp.on.ca> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/25370: ATA subsystem in 4.x fails to recognize some ATA CD-ROMs Message-ID: <200103192000.f2JK04D85255@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/25370; it has been noted by GNATS.
From: "Matthew Emmerton" <matt@gsicomp.on.ca>
To: <freebsd-gnats-submit@FreeBSD.org>, <matt@gsicomp.on.ca>,
<sos@FreeBSD.org>
Cc:
Subject: Re: kern/25370: ATA subsystem in 4.x fails to recognize some ATA CD-ROMs
Date: Mon, 19 Mar 2001 14:54:22 -0500
I tested my previous patch using some afd devices, and that caused
undesireable effects.
After considerable time learning the ata code, I've created an updated patch
which should fix the problem.
<PATCH>
--- sys/dev/ata/atapi-all.c.orig Mon Mar 19 14:48:51 2001
+++ sys/dev/ata/atapi-all.c Mon Mar 19 14:49:00 2001
@@ -391,7 +391,7 @@
atapi_read(request, length);
else
atapi_write(request, length);
- /* FALLTHROUGH */
+ return ATA_OP_CONTINUES;
case ATAPI_P_ABORT:
case ATAPI_P_DONE:
</PATCH>
boot output:
(null): MODE_SENSE_BIG command timeout - resetting
ata0: resetting devices .. done
(null): MODE_SENSE_BIG DONEDRQ
(null): read data overrun 65526/1
(null): MODE_SENSE_BIG command timeout - resetting
ata0: resetting devices .. done
(null): read data overrun 29/0
acd0: CDROM <MATSHITA CR-581> at ata0-slave using BIOSPIO
boot -v output:
acd0: <MATSHITA CR-581/1.00> CDROM drive at ata0 as slave
acd0: read 689KB/s (689KB/s), 128KB buffer, BIOSPIO
acd0: Reads: CD-DA
acd0: Audio: play, 256 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked
Clearly, the proper capabilities page is being read, so the command is
succeeding. Mounting disks and performing read actions do not appear to
cause problems.
According to the ATAPI spec that I had access to (Rev 2.6 Proposed,
1/22/96), DRQ is set when the device is ready to accept a packet command,
and is cleared once the device receives the command. In this sense,
ATAPI_P_DONEDRQ is exactly the same as ATAPI_P_READ and ATAPI_P_WRITE, which
are used for successive read/writes of additional data for the same command.
Hence, ATAPI_P_DONEDRQ should return ATA_OP_CONTINUES rather than
fallthrough.
By falling through, the command is returned prematurely with request->error
set (as a result of the command timeout caused by the sluggishness of the
ancient devices in question). The if/then statement immediately after
utimeout() picks it up, queues a REQUEST_SENSE command, which then causes
the driver to bail with "ABORTED COMMAND" (see original comments in PR), as
the initial MODE_SENSE_BIG command has yet to complete.
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?200103192000.f2JK04D85255>