Slow CD access while ripping music CD

Bill Davidsen davidsen at tmr.com
Mon Jun 28 14:59:04 UTC 2010


JD wrote:
> 
> On 06/25/2010 02:04 AM, Alan Cox was caught red-handed while writing::
>>> Jun 24 20:48:29 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x0
>>> SErr 0x0 action 0x6 frozen
>>> Jun 24 20:48:29 localhost kernel: sr 1:0:0:0: [sr0] CDB: Volume set
>>> (in), Read cd: be 00 00 03 f9 0f 00 00 1b f8 00 00
>>> Jun 24 20:48:29 localhost kernel: ata2.00: cmd
>>> a0/00:00:00:10:f8/00:00:00:00:00/a0 tag 0 pio 63504 in
>>> Jun 24 20:48:29 localhost kernel:         res
>>> 58/00:02:00:30:09/00:00:00:00:00/a0 Emask 0x6 (timeout)
>>> Jun 24 20:48:29 localhost kernel: ata2.00: status: { DRDY DRQ }
>>> Jun 24 20:48:34 localhost kernel: ata2: link is slow to respond, please
>>> be patient (ready=0)
>>> Jun 24 20:48:37 localhost kernel: ata2: soft resetting link
>>> Jun 24 20:48:37 localhost kernel: ata2.00: configured for PIO0
>>> Jun 24 20:48:37 localhost kernel: ata2: EH complete
>>>
>>> What can cause such a dramatic slow down?  I've tried ripping it several
>>> times with the same results.
>>>      
>> It got errors from the controller while tryimg to do some sort of volume
>> change I guess at the same time as the CD ripping. Hard to tell what
>> occurred without more logs.
>>
>> We eventually ended up in PIO0 as with the drive not responding or making
>> sense we will keep slowing down in the hope of getting sanity
>>    
> You mean the kernel does this dynamically - putting the drive in PIO0 mode?
> Is there a sysctl to put it back into udma33 mode?
> 
In case you missed the sense of Alan's post, it does this when it gets errors in 
DMA mode. I suspect Einstein's quote on doing the same thing and expecting 
different results applies.

I would read the logs and find out why it "downshifted" in the first place.

Other thought, use 'free' to look at memory use, see if the disk on the laptop 
is so slow that memory is full of ripped data not yet written to the disk. The 
fact that the first ten tracks went fast suggests that either the disk is the 
bottleneck, or the typical thin optical drive in the laptop isn't as good at 
reading as your desktop, and is getting errors near the end of the media. If you 
have a CD on a USB setup, trying that might give you more information.

I suspect the CD is returning errors as the base cause, read your logs and see.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


More information about the users mailing list