https://bugzilla.novell.com/show_bug.cgi?id=462368 Summary: ata lockups on asus m2v mobo (via vt8237a) Product: openSUSE 11.1 Version: Final Platform: i686 OS/Version: openSUSE 11.1 Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: desdiv@gmail.com QAContact: qa@suse.de CC: desdiv@gmail.com Found By: --- I have an Asus M2V motherboard with Via VT8237A southbridge chipset and the following disk devices connected to it: 1 pata hdd (/dev/sda), 1 pata dvd-rw (/dev/sr0), 1 sata hdd (/dev/sdb). The problem is that whenever I'm reading or writing data on the sata hdd, sooner or later cpu usage goes up to 100%, the sata disk becomes unavailable and the below entries are logged in /var/log/messages: Dec 24 11:56:26 macigep kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 24 11:56:26 macigep kernel: ata3.00: cmd 25/00:08:7d:09:be/00:00:38:00:00/e0 tag 0 dma 4096 in Dec 24 11:56:26 macigep kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 24 11:56:26 macigep kernel: ata3.00: status: { DRDY } Dec 24 11:56:26 macigep kernel: ata3: soft resetting link Dec 24 11:56:31 macigep kernel: ata3.00: qc timeout (cmd 0x27) Dec 24 11:56:31 macigep kernel: ata3.00: failed to read native max address (err_mask=0x4) Dec 24 11:56:31 macigep kernel: ata3.00: revalidation failed (errno=-5) Dec 24 11:56:31 macigep kernel: ata3: soft resetting link Dec 24 11:56:42 macigep kernel: ata3.00: qc timeout (cmd 0x27) Dec 24 11:56:42 macigep kernel: ata3.00: failed to read native max address (err_mask=0x4) Dec 24 11:56:42 macigep kernel: ata3.00: revalidation failed (errno=-5) Dec 24 11:56:42 macigep kernel: ata3: soft resetting link Dec 24 11:56:52 macigep kernel: ata3.00: qc timeout (cmd 0x27) Dec 24 11:56:52 macigep kernel: ata3.00: failed to read native max address (err_mask=0x4) Dec 24 11:56:52 macigep kernel: ata3.00: revalidation failed (errno=-5) Dec 24 11:56:52 macigep kernel: ata3.00: disabled Dec 24 11:56:52 macigep kernel: ata3: soft resetting link Dec 24 11:56:52 macigep kernel: ata3: EH complete Dec 24 11:56:52 macigep kernel: sd 2:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Dec 24 11:56:52 macigep kernel: end_request: I/O error, dev sdb, sector 951978365 Dec 24 11:56:52 macigep kernel: sd 2:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Dec 24 11:56:52 macigep kernel: end_request: I/O error, dev sdb, sector 951978365 Dec 24 11:56:52 macigep kernel: sd 2:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Dec 24 11:56:52 macigep kernel: end_request: I/O error, dev sdb, sector 951978357 Dec 24 11:56:52 macigep kernel: Buffer I/O error on device sdb6, logical block 102357963 Dec 24 11:56:52 macigep kernel: lost page write due to I/O error on sdb6 Dec 24 11:56:52 macigep kernel: sd 2:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Dec 24 11:56:52 macigep kernel: end_request: I/O error, dev sdb, sector 949141797 This error is reproducable, it always happens when I'm accessing the sata disk, only the time when it happens is different i.e. sometimes it happens after 15 minutes of using the disk, other times it happens after 1 minute. I've already lost some data due to this bug. Sometimes it also happens with the dvd drive. BIOS is the latest version, hardware profile is http://www.smolts.org/show?uuid=pub_1b7a86ad-460c-424a-92b6-69b4d0abfeb7 The only working workaround is booting with "noapic" kernel parameter, then the system is stable and I can use the sata disk. On different forums I read other users also have this issue with M2V motherboard. Ps: when I tried opensuse 11.1 beta2, it addresses my disks in the "old way", i.e. pata disks were /dev/hda and /dev/hdb, only the sata disk was /dev/sda. I did not epxerienced this bug in that version, although I didn't play much with beta2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.