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>