[Bug 577796] [NEW] Filling disk with data leads to [sda] Unhandled error code. [sda] Result hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT

[Alexander Konovalenko]

Public bug reported:

I'm running things like badblocks -w that fill the whole hard disk with
data and then attempt to read it. Once in a while errors like this
occur:

May  9 01:13:53 ubuntu kernel: [29838.149173] sd 0:0:0:0: [sda] Unhandled error code
May  9 01:13:53 ubuntu kernel: [29838.149193] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
May  9 01:13:53 ubuntu kernel: [29838.149216] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 01 36 c8 00 00 08 00
May  9 01:13:53 ubuntu kernel: [29838.149272] end_request: I/O error, dev sda, sector 79560

This error occurred while writing to the disk through a dm-crypt device
with dd bs=512. But the kernel log says 'Read', so I'm confused whether
it actually happened during a read or a write. The system was otherwise
idle and no other processes should have accessed the disk.

After an error occurs, the faulty sector and the LBAs around it can be
both read and written to without any further errors. So the condition is
not reliably reproducible.

There is some evidence that the error messages might indicate a bug in
the kernel and not just faulty hardware:

1) The SMART error log is empty and reallocated sector count is 0. The
SMART data gives no indication that the disk is aware of any read or
write errors.

2) Someone has encountered very similar error messages in a virtual machine guest, while the host OS didn't complain about the actual hardware:
http://forums.virtualbox.org/viewtopic.php?f=3&t=25568

The disk has a sector size of 512 bytes (both physical and logical).
Sometimes I used 512-byte blocks for dd (dd bs=512) and badblocks
(badblocks -b 512). dd with bs=512 is much slower than with 4096-byte
blocks, and when writing through a dm-crypt device it is painfully slow
(less than 1 MB/s). Not sure if that can be relevant.

Another interesting thing is that when the laptop is idle it often
freezes until I move the mouse or start typing. I observe the freeze by
looking at the current time (including seconds) on the GNOME panel which
stops updating. Once I move the mouse, the clock catches up, but it
still tends to be slow, roughly 10 minutes per hour or so. (date output
is consistent with the GNOME clock.) That's certainly a separate bug.
I'm describing it here in case it might be related to the I/O timeout.

How can I further debug this?

I'm not sure how to tell unstable or faulty hardware (motherboard, CPU,
memory, or the disk itself) from a kernel problem here. I tested the
memory with Memtest86+ and it found no errors. Everything else seems to
work fine. Any pointers would be highly appreciated.

I'm running Ubuntu 10.04 from a live DVD. The Linux kernel package
version is 2.6.32-21.32; it is based on mainline kernel
2.6.32.11+drm33.2. Hardware: an Asus Eee PC 1101HA laptop with a Seagate
Momentus 5400.6 SATA 250 GB HDD (model ST9250315AS).

** Affects: linux
     Importance: Unknown
         Status: Unknown

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

-- 
Filling disk with data leads to [sda] Unhandled error code. [sda] Result hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
https://bugs.launchpad.net/bugs/577796
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.