Messages in this thread | | | From | Monty <> | Subject | Re: Fwd: ATAPI device barfing on vanilla 2.2.7 and 2.2.7-ac2 | Date | Wed, 12 May 1999 16:13:06 EDT |
| |
>Can't really tell if sg and ide-scsi are involved so it is >hard to say if I have any part in this.
I see inexplicable errors with ATAPI drives under Linux all the time, both with the 'native' ATAPI driver and IDE-SCSI. I seriously doubt that ide-scsi or sg are at fault, although they *do* seem to exacerbate error recovery (essentially, but the time an IDE-SCSI device gets to 'bus reset', I've never seen IDE-SCSI recover).
My guess is that the problem in these cases is underlying ATAPI infrastructure that is used by both the ATAPI ioctl layer and IDE-SCSI. It's a hunch with all the obvious caveats, because I've taken 'troublesome' ATAPI drives and seen identical problem behavior under ATAPI ioctl() and IDE-SCSI SG; the most common 'weird' error is reproducable DMA underruns with some drives. Note that booting the machine to NetBSD makes the 'weird' behavior disappear, so the hardware is at worst marginal wrt spec, but functioning 'properly'.
*HOWEVER*
In the case posted below, this looks like a fairly standard drive behavior that is annoying but not a bug, but that confuses the ATAPI driver badly (in fact, the ATAPI driver couldn't be doing a worse thing unless, perhaps, it panicked the machine :-). I'll go into more detail....
>Im getting this error on the 14th track of my Philip Glass CD when using >cdparanoia. Can anyone give a prelim diagnostic? Is it like to be a >cdparanoia bug, ide/atapi driver bug, or an error in the cdrom itself? The >cd isn't scratched or warped, and it plays just fine on a regular cd player.
>UPDATE: Its not a cd error, because I get it on the last track of my Gypsy >Kings CD, and some others. So its either a cdparanoia error or a kernel >bug. How could cdparanoia cause this though? I haven't heard of anyone else >getting this error from it.
cdparanoia only reports what the kernel tells it in this case. This is a kernel/hardware issue.
>These error packets just keep on coming and coming and coming until I kill >the process. Im not getting the error with other CD's. >---------------------- Error Here ------------------------- >hdb: packet command error: status=0x51 { DriveReady SeekComplete Error } >hdb: packet command error: error=0x54 >ATAPI device hdb: > Error: Illegal request -- (Sense key=0x05) > Illegal mode for this track or incompatible medium -- (asc=0x64, >ascq=0x00) > The failed "<NULL>" packet command was: > "be 04 00 04 06 fb 00 00 08 f8 00 00 "
[...]
OK, we're near the very end of the disc, perhaps *at* the very end. You're using the ATAPI ioctl() driver, which is probably a bad idea for two reasons: When it gets an error like this (a command that can never succeed) it just keeps retrying it, rendering the process unkillable, until you reboot the machine (IDE-SCSI reports the error back to the application). It will give up eventually... but it takes a *really* long time (especially on a large fraction of drives that require 15-20 seconds to report this exception, like most NECs with a three digit model number). Secondly, the ATAPI driver seems to occasionally add seek offsets to the reported TOC values resulting in tracks that don't line up and falling off the end of the session more easily.
Note that falling off the end of a session can happen in normal circumstances; the CDROM spec does not mandate that the disc end exactly where the TOC says it will. The TOC is treated as a 'helpful hint' collection.
So, my guess is just that you've fell off the end of the last track and the ATAPI ioctl() decided to repeatedly shoot itself in the head.
How to deal? Use IDE-SCSI emulation, which allows cdparanoia to decide how to handle the error. Note that this is not yet a 100% fix, but it will get you successful last-track track rips in a more reasonable period of time until I can code a better work-around.
Monty (author of cdparanoia)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |