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?
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
