You are not logged in.
dmesg: (last lines)
ata4: EH pending after 5 tries, giving up
ata4: EH complete
ata4: EH pending after 5 tries, giving up
ata4: EH complete
ata4: EH pending after 5 tries, giving up
ata4: EH complete
ata4: EH pending after 5 tries, giving up
ata4: EH complete
ata4: EH pending after 5 tries, giving up
ata4: EH complete
dmesg|grep ata4:
ata4: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xf408 irq 23
ata4: EH pending after 5 tries, giving up
ata4: EH complete
.
.
.
ata4: EH pending after 5 tries, giving up
ata4: EH complete
tail -f /var/log/messages.log:
Sep 14 13:07:37 arch-node ata4: EH complete
Sep 14 13:07:39 arch-node ata4: EH complete
Sep 14 13:07:40 arch-node ata4: EH complete
Sep 14 13:07:42 arch-node ata4: EH complete
and so on. my computer works great but this is worrying me. could this be that my hdd is going to die? this started few days ago.
btw: tail -f /var/log/messages.log:
Sep 14 13:10:30 arch-node ata4: EH complete
Sep 14 13:10:31 arch-node ata4: EH complete
Sep 14 13:10:33 arch-node ata4: EH complete
Sep 14 13:10:35 arch-node ata4: EH complete
Sep 14 13:10:36 arch-node ata4: EH complete
omg! anybody?
Offline
I got the same issue here - I think it is related to my raid device (via dmraid mapper). During bootup I get the message that the system treies to write beyond device (had that in all previous distributions i had, too) but now those error are written to dmesg althiough the raid in functioning properly. I would appreciate a way to supress that messages to be written to the dmesg output as it pulls down the whole system (espacially when trying games it pulls down the fps every second as messages are written to the log)
Last edited by der_acid (2008-09-14 12:25:27)
Offline
friend says that ubuntu 8.10 users have the same problem. seems like kernel bug. i have 2.6.26-ARCH kernel. 32 bit , amd 64 proc. will wait till next kernel update. hope they will work it out.
Offline
same config here - 2.6.26-ARCH, 32bit system on AMD64. I got the nforce 4 chipset - RAID chipset is a silicon Image one.
Offline
It's been introduced in 2.6.26.4 and 2.6.27-rc6, as far as I can tell.
Last edited by lucke (2008-09-14 13:34:50)
Offline
can it be fixed?
i also have nforce chipset(nf3 250gb)
Offline
I get this error as well:
# tail /var/log/messages.log
Sep 15 00:00:24 Yggdrasil ata4: EH complete
Sep 15 00:00:24 Yggdrasil ata3: EH complete
Sep 15 00:00:26 Yggdrasil ata4: EH complete
Sep 15 00:00:26 Yggdrasil ata3: EH complete
Sep 15 00:00:27 Yggdrasil ata4: EH complete
Sep 15 00:00:27 Yggdrasil ata3: EH complete
Sep 15 00:00:29 Yggdrasil ata4: EH complete
Sep 15 00:00:29 Yggdrasil ata3: EH complete
Sep 15 00:00:30 Yggdrasil ata4: EH complete
Sep 15 00:00:30 Yggdrasil ata3: EH complete
#
and
# grep "EH complete" /var/log/messages.log | wc -l
6443
#
It's growing by a few lines every second under heavy disk load. The processes scsi_eh_3 and scsi_eh_4 are taking up 2-3 percent cpu time each, probably from generating this message. This appeared after a reboot of the server after a power outage, bringing kernel 2.6.26.5 with it. I have a software raid setup with mdadm using a 3ware 7500 series card as a controller card, and I am using the nforce4 chipset. One drive of the RAID is on the nforce chipset, but not two. I'm also not using any of the raid capabilities of the motherboard. Any idea of what's causing this? It's obviously been introduced in this latest kernel...
Offline
I have this problem as well -- I found this bug report as well as some email exchanges on kernel mailing lists about it but no solution yet...
Offline
hi, i have it also. it slows down my server a _lot_
root@BOLL:~# grep "EH complete" /var/log/messages.log | wc -l
161909
i will subscribe this thread for a solution
Offline
Just a quick comment, I haven't got raid but I'm getting this as well.
Offline
This "EH complete" problem started for me with last kernel update in Arch (kernel26-2.6.26.5-1). Rolling back to kernel26-2.6.26.3-1 solved it for now.
Offline
ye, same here.
Offline
I have the same problem no raid either.
Has anybody filed a bug yet?
Offline
From my reading it seems to be an upstream thing, a problem with the kernel itself, not the Arch implementation of it so I would imagine that it has made it to the kernel bug system by now.
Offline
I have got the same problem. Removing the sata_nv.patch from the Arch kernel solves it.
Offline
I have got the same problem. Removing the sata_nv.patch from the Arch kernel solves it.
Thanks for the tip -- it all makes sense suddenly, the only references to this problem I was able to find had something to do with a fix for another problem with sata_nv module... Is it worth it to file a bug report for this?
Offline
There is already a bug report by linfan
http://bugs.archlinux.org/task/11535
Offline
Well, just an update. For those unwilling to compile a custom kernel or rollback to the old one, the symptoms (but not the root cause) of the spurious messages may be suppressed by adding the following to /etc/syslog-ng.conf:
filter f_eh {
match("EH complete") or
match ("EH pending");
};
Then, change the filter lines for f_kernel, f_everything, f_messages, and f_err to contain the following:
and not filter(f_eh)
like so:
filter f_kernel { facility(kern) and not filter(f_iptables) and not filter(f_eh); };
filter f_messages { level(info..warn) and not facility(auth, authpriv, mail, news, cron) and not program(syslog-ng) and not filter(f_iptables) and not filter(f_eh); };
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_eh); };
filter f_err { level(err) and not filter(f_eh); };
Assuming you have the default syslog-ng.conf. When this gets fixed you can either blank that f_eh rule so it doesn't match anything or just edit the four lines above back to what they were.
Now, I'm fairly sure this won't cause any problems other than discarding the messages so your logs won't grow to enormous sizes. I did have a drive give me some read errors and drop out of the raid recently (after this bug came into existence) but I'm pretty sure that was coincidental, having nothing to do with the scsi_nv patch because it happened on my 3ware card.
Offline
So, am I the only one seeing this issue now (kernel 2.6.28.5)?
Offline
I haven't seen it for ages
Offline
I dont have it anymore
Offline
So, am I the only one seeing this issue now (kernel 2.6.28.5)?
Nope.
I've it with 2.6.28.7-1 as well
Sincerely,
Gour
Offline
The bug has re-appeared for some ubunutu users. The old report on their bug tracker was reopened the other day. I haven't seen the problem so I've taken myself off the subscription list and don't know what the current state of it is.
Offline
Hm, according to my logfiles (kernel.log) the problem is with me since 16.2., I've noticed it accidentally by calling dmesg. On 15.2. I updated from 2.6.28.4-1 to 2.6.28.5-1. Coincidence? I don't believe it ... Of cause, I'm using sata_nv as well.
Offline
I'm running a vanilla 2.6.28.7 kernel (32 bit) and am getting this problem as well. Can I simply blacklist this module? I don't run a raid or anything.
It's a very deadly weapon to know what you're doing
--- William Murderface
Offline