Description of problem: As soon as I disable my onboard ethernet port, either by bios configuration, by software or by hardware (pulling the ethernet cable), I get SATA bus errors almost immediately. (the board is a ABIT IP35V LGA775 FSB1333 SATA) Version-Release number of selected component (if applicable): kernel-PAE-2.6.33.5-124.fc13.i686 also tested with kernel-PAE-2.6.32.12-115.fc12.i686 (same results) How reproducible: always Steps to Reproduce: 1. do one of the following: a) pull ethernet cable b) /sbin/ifdown eth0 c) boot with onboard NIC disabled completely in BIOS ie anything that turns off the onboard ethernet port LED 2. dd if=/dev/sda of=/dev/null 3. wait 10 to 20 seconds Actual results: for 2a and 2b, the message Jun 26 19:45:22 helen kernel: sky2 eth0: disabling interface is logged. After step 3, the kernel starts reporting varying bus errors sometimes this: Jun 26 22:32:28 helen kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Jun 26 22:32:28 helen kernel: ata3.00: BMDMA stat 0x66 Jun 26 22:32:28 helen kernel: ata3.00: failed command: WRITE DMA Jun 26 22:32:28 helen kernel: ata3.00: cmd ca/00:08:cd:17:78/00:00:00:00:00/e3 tag 0 dma 4096 out Jun 26 22:32:28 helen kernel: res 51/84:01:d4:17:78/00:00:00:00:00/e3 Emask 0x30 (host bus error) Jun 26 22:32:28 helen kernel: ata3.00: status: { DRDY ERR } Jun 26 22:32:28 helen kernel: ata3.00: error: { ICRC ABRT } Jun 26 22:32:28 helen kernel: ata3: soft resetting link Jun 26 22:32:28 helen kernel: ata3.00: configured for UDMA/133 Jun 26 22:32:28 helen kernel: ata3.01: configured for UDMA/133 Jun 26 22:32:28 helen kernel: ata3: EH complete sometimes this: Jun 26 19:41:16 helen kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Jun 26 19:41:16 helen kernel: ata3.00: failed command: WRITE DMA Jun 26 19:41:16 helen kernel: ata3.00: cmd ca/00:48:05:38:08/00:00:00:00:00/e3 tag 0 dma 36864 out Jun 26 19:41:16 helen kernel: res 40/00:00:e5:10:34/00:00:00:00:00/e1 Emask 0x4 (timeout) Jun 26 19:41:16 helen kernel: ata3.00: status: { DRDY } Jun 26 19:41:21 helen kernel: ata3: link is slow to respond, please be patient (ready=0) Jun 26 19:41:26 helen kernel: ata3: device not ready (errno=-16), forcing hardreset Jun 26 19:41:26 helen kernel: ata3: soft resetting link Jun 26 19:41:26 helen kernel: ata3.00: configured for UDMA/133 Jun 26 19:41:26 helen kernel: ata3.01: configured for UDMA/133 Jun 26 19:41:26 helen kernel: ata3: EH complete Using a different disk (here /dev/sdb instead of /dev/sda) makes no difference: Jun 26 19:45:32 helen kernel: ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Jun 26 19:45:32 helen kernel: ata3.01: BMDMA stat 0x66 Jun 26 19:45:32 helen kernel: ata3.01: failed command: READ DMA Jun 26 19:45:32 helen kernel: ata3.01: cmd c8/00:00:e0:60:01/00:00:00:00:00/f0 tag 0 dma 131072 in Jun 26 19:45:32 helen kernel: res 51/84:a3:3d:61:01/00:00:00:00:00/f0 Emask 0x30 (host bus error) Jun 26 19:45:32 helen kernel: ata3.01: status: { DRDY ERR } Jun 26 19:45:32 helen kernel: ata3.01: error: { ICRC ABRT } Jun 26 19:45:32 helen kernel: ata3: soft resetting link Jun 26 19:45:32 helen kernel: ata3.00: configured for UDMA/133 Jun 26 19:45:32 helen kernel: ata3.01: configured for UDMA/133 Jun 26 19:45:32 helen kernel: ata3: EH complete The log then starts filling with these errors, about one every 10 to 20 seconds. After the "Emask 0x4 (timeout)" kind of errors, the system freezes for about 10 to 20 seconds. Sometimes, the system freezes with a message different from the ones above and does not wake up anymore (I can see this message with dmesg shortly before it freezes). Sometimes, switching console still works, sometimes, it's completely frozen. Expected results: Problems after step 3 do not happen. Additional info: - I think that this is not a hardware problem because KNOPPIX 6.2 does not have the problem. - The dd is not actually necessary. It can be caused by any disk access (but one has to wait for one then). - disk info: ata3.00: ATA-7: SAMSUNG HD200HJ, KF100-06, max UDMA7 ata3.00: 390721968 sectors, multi 16: LBA48 NCQ (depth 0/32) ata3.01: ATA-7: SAMSUNG HD103UJ, 1AA01113, max UDMA7 ata3.01: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) ata3.00: configured for UDMA/133 ata3.01: configured for UDMA/133 ata3.00 = sda; ata3.01 = sdb
Can you post the boot messages (contents of /var/log/dmesg after booting)?
Created attachment 430457 [details] boot messages (contents of /var/log/dmesg after booting)
I got the same problem here, and i have a 500Gb Samsung SATA disk. Linux localhost.localdomain 2.6.33.6-147.2.4.fc13.i686 #1 SMP Fri Jul 23 17:27:40 UTC 2010 i686 i686 i386 GNU/Linux Aug 9 20:42:32 localhost kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Aug 9 20:42:32 localhost kernel: ata3.00: failed command: WRITE DMA EXT Aug 9 20:42:32 localhost kernel: ata3.00: cmd 35/00:00:80:29:f7/00:04:07:00:00/e0 tag 0 dma 524288 out Aug 9 20:42:32 localhost kernel: res 40/00:08:b0:41:97/84:00:0b:00:00/e6 Emask 0x4 (timeout) Aug 9 20:42:32 localhost kernel: ata3.00: status: { DRDY } Aug 9 20:42:37 localhost kernel: ata3: link is slow to respond, please be patient (ready=0) Aug 9 20:42:42 localhost kernel: ata3: device not ready (errno=-16), forcing hardreset Aug 9 20:42:42 localhost kernel: ata3: soft resetting link Aug 9 20:42:43 localhost kernel: ata3.00: configured for UDMA/33 Aug 9 20:42:43 localhost kernel: ata3: EH complete
pcie_aspm=off makes the problem go away
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.