linux-kernel - sata

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 04 Apr 2008 16:51:20 -0400
From:	Rich West <Rich.West@...mo.com>
To:	linux-kernel@...r.kernel.org
Subject: sata_via

On my mythtv backend system, the recordings volume tends to get pounded
rather hard (up to 5 recordings (some HD) at once with multiple frontend
systems reading from that same volume).  I recently (4 months ago)
upgraded the system to a motherboard that happened to have the VIA
chipset on it.

Since that time, I have had some bizarre problems with that volume. 
After a seemingly random amount of time, the kernel would report an
error with the volume and put it in read-only mode.  However, it would
not really be in read-only mode, but it would be completely
inaccessible.  Unmounting the volume would be successful, but
re-mounting the volume would fail.

I've replaced the drive (with an identical one), tested memory, changed
filesystems (it was LVM + ext3, then just ext3) and the problem persists.

Running 2.6.24.4-64 (Fedora 8).

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

It is almost as if I am hitting some bug that is causing the drive to
fall off, but I really don't know where else to look or where else to
turn...

I'm tempted to just go back to using a PATA drive (smaller.  :(  ) to
avoid the problem.  I'm just at a loss as to how it can actually be solved.

-Rich

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/