| Summary: | ATA subsystem in 4.x fails to recognize some ATA CD-ROMs | ||
|---|---|---|---|
| Product: | Base System | Reporter: | matt |
| Component: | kern | Assignee: | Søren Schmidt <sos> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
matt
2001-02-26 05:40:02 UTC
Here's the patch in a more usuable format.
I realize that this code may cause problems for ATA floppy devices, although
I believe an "aborted command" response from a ATA floppy may be indicative
of a "device powering up" situation which is similar to the case of the
CD-ROM.
--- sys/dev/ata/atapi-all.c.orig Sun Feb 25 16:35:20 2001
+++ sys/dev/ata/atapi-all.c Sun Feb 25 23:50:08 2001
@@ -449,6 +449,17 @@
request->error = EIO;
break;
+ case ATAPI_SK_ABORTED_COMMAND:
+ /* This allows first-generation ATAPI devices (such
+ * as MKE/Panasonic "Creative" CD-ROMs) that don't
+ * respond properly to MODE_SENSE_BIG to still be
+ * detected and recognized by the ata subsystem,
+ * as they were in 3.x)
+ */
+ if (atp->cmd == ATAPI_MODE_SENSE_BIG)
+ break;
+ /* FALLTHROUGH */
+
default:
printf("%s: %s - %s asc=%02x ascq=%02x ",
atp->devname, atapi_cmd2str(atp->cmd),
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.
It seems Matthew Emmerton wrote:
> 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
Hmm, well it still sortof fails, and it breaks devices that actually
use ATAPI_P_DONEDRQ (which by the way is another abuse of the spec),
since it is meant for devices that return the DONE part of the
protocol together with the last part of the data. Now if you
return ATA_OP_CONTINUES the driver will wait for a new interrupt
which wont occur..
-Søren
Responsible Changed From-To: freebsd-bugs->sos sos is Mr ATA State Changed
From-To: open->analyzed
Try this patch, it should restore the sam behavior as 3.x had
(allthough it wrong and needs a try fix)
--- atapi-cd.c 2001/03/27 10:22:50 1.87
+++ atapi-cd.c 2001/04/02 20:00:01
@@ -128,10 +128,12 @@
(caddr_t)&cdp->cap, sizeof(cdp->cap))))
break;
}
+#if 0
if (error) {
free(cdp, M_ACD);
return -1;
}
+#endif
cdp->cap.max_read_speed = ntohs(cdp->cap.max_read_speed);
cdp->cap.cur_read_speed = ntohs(cdp->cap.cur_read_speed);
cdp->cap.max_write_speed = ntohs(cdp->cap.max_write_speed);
State Changed From-To: analyzed->closed This is fixed in current. |