lkml.org 
[lkml]   [1999]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Fwd: ATAPI device barfing on vanilla 2.2.7 and 2.2.7-ac2
Date

>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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.025 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site