[mythtv-users] Mythtv recording filesystem (sata) goes read only

[Rich West]

Sam Varshavchik wrote:
> Rich West writes:
>
>> A larger snippet from the messages log is (dmesg gets cleared after 
>> reboot):
>> Apr  3 16:47:27 mythtv1 kernel: ata4.00: exception Emask 0x0 SAct 0x0
>> SErr 0x0 action 0x2 frozen
>> Apr  3 16:47:27 mythtv1 kernel: ata4.00: cmd
>> c8/00:00:77:31:21/00:00:00:00:00/e1 tag 0 dma 131072 in
>> Apr  3 16:47:27 mythtv1 kernel:          res
>> 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
>> Apr  3 16:47:27 mythtv1 kernel: ata4.00: status: { DRDY }
>> Apr  3 16:47:27 mythtv1 kernel: ata4: soft resetting link
>> Apr  3 16:47:57 mythtv1 kernel: ata4.00: qc timeout (cmd 0x27)
>> Apr  3 16:47:57 mythtv1 kernel: ata4.00: failed to read native max
>> address (err_mask=0x4)
>> Apr  3 16:47:57 mythtv1 kernel: ata4.00: HPA support seems broken, will
>> skip HPA handling
>> Apr  3 16:47:57 mythtv1 kernel: ata4.00: revalidation failed (errno=-5)
>> Apr  3 16:47:57 mythtv1 kernel: ata4: failed to recover some devices,
>> retrying in 5 secs
>> Apr  3 16:48:02 mythtv1 kernel: ata4: soft resetting link
>> Apr  3 16:48:02 mythtv1 kernel: ata4.00: configured for UDMA/133
>> Apr  3 16:48:02 mythtv1 kernel: ata4: EH complete
>> Apr  3 16:49:02 mythtv1 kernel: ata4.00: exception Emask 0x0 SAct 0x0
>> SErr 0x0 action 0x2 frozen
>> Apr  3 16:49:02 mythtv1 kernel: ata4.00: cmd
>> c8/00:00:77:31:21/00:00:00:00:00/e1 tag 0 dma 131072 in
>> Apr  3 16:49:02 mythtv1 kernel:          res
>> 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
>> Apr  3 16:49:02 mythtv1 kernel: ata4.00: status: { DRDY }
>> Apr  3 16:49:02 mythtv1 kernel: ata4: soft resetting link
>> Apr  3 16:49:03 mythtv1 kernel: ata4.00: configured for UDMA/133
>> Apr  3 16:49:03 mythtv1 kernel: ata4: EH complete
>
> The best way to get an answer as to what this means, is to post this 
> whole thing on the linux-kernel and linux-ide mailing lists, together 
> with your hardware details, and the specific kernel version you're 
> running.

This is good advice.  Another person who responded included a link to a 
similar issue which was in a thread on the linux-kernel list, which led 
me to that list.

For what it is worth, I posted there and got some responses back rather 
quickly.  Apparently, this has been reported a number of times and 
should be fixed in the 2.6.25-rc kernel (I have not tried it yet) if it 
is indeed a problem with libata.  To eliminate the potential for this 
actually being an ACPI issue, it was recommended to try running with 
'noapic' and/or 'acpi=off' added to the kernel boot args.

-Rich