Comment 101 for bug 550559

Just had this show up on an ASUS 1001P. In this case it may be failing hardware, for all I know. Getting a lot of:

Mar 2 08:31:29 boot2 kernel: [ 2958.107227] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar 2 08:31:29 boot2 kernel: [ 2958.107242] ata1.00: irq_stat 0x40000008
Mar 2 08:31:29 boot2 kernel: [ 2958.107254] ata1.00: failed command: READ FPDMA QUEUED
Mar 2 08:31:29 boot2 kernel: [ 2958.107278] ata1.00: cmd 60/08:00:a8:9e:a1/00:00:12:00:00/40 tag 0 ncq 4096 in
Mar 2 08:31:29 boot2 kernel: [ 2958.107283] res 41/40:08:af:9e:a1/00:00:12:00:00/00 Emask 0x409 (media error) <F>
Mar 2 08:31:29 boot2 kernel: [ 2958.107294] ata1.00: status: { DRDY ERR }
Mar 2 08:31:29 boot2 kernel: [ 2958.107303] ata1.00: error: { UNC }
Mar 2 08:31:29 boot2 kernel: [ 2958.111521] ata1.00: configured for UDMA/133
Mar 2 08:31:29 boot2 kernel: [ 2958.111554] ata1: EH complete

both delaying bootup, and while running. This is with Ubuntu 10.04.2 and happens now with both Ubuntu kernels and a vanilla 2.6.34 that I've been using on this for a long time (tweaked to support the Eee better). It suddenly started yesterday - no such errors before - and is no persistent. However there's no such problem if I boot Lucid Puppy from USB, and then mount the partition and read/write files on it. (That I was stupid enough to let Ubuntu encrypt my home directory was a problem - that should not be the default option on install - too dangerous on hardware failure!)

Running fsck was necessary to get the partition even to mount, but even after a pass with -f -cc -k Ubuntu is unhappy booting from the partition - too busy throwing the FPDMA errors. The Windows7 partition still seems to boot with normal speed (i.e., it's always been sluggish to boot).

So on the one hand I'm allowing this is marginal hardware (the build quality on the 1001P is no where near as good as on the older ASUS 700 series, so this doesn't surprise). On the other, with all the suggestions here from others on this issue being somewhat hardware agnostic, it looks like something where the kernel drivers are too highly strung, with hopefully the prospect that tuning them to be more relaxed might result in more dependable performance. Some of the reports here suggest that, even if they're pointing to different parameters. I wonder if there's a single underlying cause in one or more of the ATA drivers.