public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Jens Axboe <axboe@suse.de>
Cc: Sebastian <sebastian_ml@gmx.net>, linux-kernel@vger.kernel.org
Subject: Re: Digital Audio Extraction with ATAPI drives far from perfect
Date: Tue, 10 Jan 2006 23:43:23 +0100	[thread overview]
Message-ID: <43C4388B.4060905@keyaccess.nl> (raw)
In-Reply-To: <20060109100322.GP3389@suse.de>

Jens Axboe wrote:

> Well it's actually a good thing, because then at least it's not a bug
> with the multi-frame extraction. So my guess would still be at the
> error correction possibilities that the application has, in which
> case CDROMREADAUDIO is just an inferior interface for this sort of
> thing. It also doesn't give the issuer a chance to look at potential
> error reasons, since the extended status isn't available.

For what it's worth; when allowing only flawless rips with cdparanoia 
(*) standard cdparanoia 9.8 and the SG_IO patched version of the same 
give me the exact same rips always, on my ATAPI Plextor "PlexWriter 
Premium", a drive that's specifically good at CDDA.

One thing that _is_ different is that the SG_IO version very frequently 
(soft) locks up the machine, with:

===
hdc: DMA timeout retry
hdc: timeout waiting for DMA
hdc: status error: status=0x7f { DriveReady DeviceFault SeekComplete 
DataRequest CorrectedError Index Error }
hdc: status error: error=0x7f { IllegalLengthIndication EndOfMedia 
AbortedCommand MediaChangeRequested LastFailedSense=0x07 }
ide: failed opcode was: unknown
hdc: drive not ready for command
hdc: ATAPI reset complete
hdc: irq timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: ATAPI reset complete
hdc: irq timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: status timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: drive not ready for command
hdc: status timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: DMA disabled
hdc: drive not ready for command
hdc: ATAPI reset complete
hdc: irq timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: ATAPI reset complete
hdc: irq timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: status timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: drive not ready for command
BUG: soft lockup detected on CPU#0!

Pid: 0, comm:              swapper
EIP: 0060:[<c01d111f>] CPU: 0
EIP is at ide_inb+0x3/0x7
  EFLAGS: 00000206    Not tainted  (2.6.15-local-wc)
EAX: 00000180 EBX: c0329184 ECX: 2cb065ff EDX: 00000177
ESI: 00000282 EDI: 001403db EBP: c03290f0 DS: 007b ES: 007b
CR0: 8005003b CR2: b7c5d004 CR3: 1fd1f000 CR4: 000006d0
  [<c01d16ca>] ide_wait_stat+0xa0/0xfd
  [<c01d07cb>] start_request+0x10c/0x1a7
  [<c01d0b42>] ide_do_request+0x2bb/0x2f9
  [<c01d00c5>] ide_atapi_error+0x53/0x78
  [<c01da977>] cdrom_newpc_intr+0x0/0x2fd
  [<c01d0dfd>] ide_timer_expiry+0x195/0x1bf
  [<c0118ebe>] run_timer_softirq+0x140/0x181
  [<c01d0c68>] ide_timer_expiry+0x0/0x1bf
  [<c0115b01>] __do_softirq+0x35/0x7d
  [<c0103c54>] do_softirq+0x38/0x3f
  =======================
  [<c0115bda>] irq_exit+0x29/0x34
  [<c0103b84>] do_IRQ+0x46/0x4e
  [<c01026ce>] common_interrupt+0x1a/0x20
  [<c0100a73>] default_idle+0x2b/0x53
  [<c0100af0>] cpu_idle+0x41/0x63
  [<c02ea621>] start_kernel+0x13d/0x13f
hdc: status timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
hdc: drive not ready for command
hdc: status timeout: status=0x80 { Busy }
ide: failed opcode was: unknown
===

Ad infitum. Needless to say, I switched back to regular (unpatched from 
upstream) cdparanoia which doesn't show this problem. The patching I did 
was from this message earlier in this thread:

http://marc.theaimsgroup.com/?l=linux-kernel&m=113665002702563&w=2

First I tried with only the .sgio and .labels patches from that src.rpm 
applied, saw the problem, then retried with all of redhat's patches 
applied (just in case) but did not see an improvement.

As said, when things do work, the rips are exactly the same as the rips 
made with the standard cdparanoia.

(*) by "allowing only flawless rips" I mean using "cdparanoia -v -z -B" 
and only ever allowing spaces in the progressbar cdparanoia leaves 
behind as it goes along. When anything else (-, +, !, ...) appears, I 
re-rip the entire track, or the bit in which the error occured, until I 
have a "spaces only" copy. Two of such rips are always the same while on 
the other hand a non-spaces-only rip generally differs from any other 
rip made of that same track.

Rene.


  reply	other threads:[~2006-01-10 22:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-03 22:20 Digital Audio Extraction with ATAPI drives far from perfect Sebastian
2006-01-04  9:20 ` Jens Axboe
2006-01-04  9:24   ` Jens Axboe
2006-01-04 15:08     ` Mark Lord
2006-01-04 15:13       ` Jens Axboe
2006-01-04 15:50     ` Sebastian
2006-01-04 19:36       ` Alistair John Strachan
2006-01-04 21:54         ` Sebastian
2006-01-06 13:39       ` jerome lacoste
2006-01-05  6:43     ` Sebastian
2006-01-06  8:06 ` Joshua Kwan
2006-01-06 23:25   ` Sebastian
2006-01-06 23:30     ` Mark Knecht
2006-01-07 10:39       ` Sebastian
2006-01-07 10:56         ` Jens Axboe
2006-01-07 11:00           ` Jens Axboe
2006-01-07 11:53             ` Sebastian
2006-01-07 11:57               ` Jens Axboe
     [not found]           ` <20060107112443.GA18749@section_eight.mops.rwth-aachen.de>
     [not found]             ` <20060107115340.GW3389@suse.de>
     [not found]               ` <20060107115449.GB20748@section_eight.mops.rwth-aachen.de>
     [not found]                 ` <20060107115947.GY3389@suse.de>
2006-01-07 14:08                   ` Sebastian
2006-01-07 14:22                     ` Jens Axboe
2006-01-07 16:06                       ` Sebastian
2006-01-07 17:44                         ` Brad Campbell
2006-01-07 18:02                           ` Sebastian
2006-01-07 18:39                             ` Lee Revell
2006-01-07 18:45                             ` Brad Campbell
2006-01-09  9:30                               ` Jens Axboe
2006-01-09  9:49                                 ` Sebastian
2006-01-09 10:03                                   ` Jens Axboe
2006-01-10 22:43                                     ` Rene Herman [this message]
2006-01-10 22:52                                       ` Lee Revell
2006-01-10 23:05                                         ` Rene Herman
2006-01-07 17:24                       ` Sebastian
2006-01-07 19:18                     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43C4388B.4060905@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sebastian_ml@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox