This bug has been copied from bug #361931 and has been proposed to be backported to 4.6 z-stream (EUS).
Chas, this is slated to be delivered on 13-Mar-08 in the 4.6.z stream.
Jiri, what exactly do you need (and when) from Stratus? Bug 361931 has the exact patch needed... Are we still on schedule for this being released 13-Mar-08?
Hi Adrius, I'm little bit confused here. From the bug activity list I see that you have set the NEEDINFO flag on and now you are asking me what information I need. It looks like you did it by mistake or I missed something or I did some mistake myself. I'm still quite new here so it may be my fault. From the original bug history its obvious that the patch has been tested on 4.6 release and it is working. Also the devel_ack is on in the EUS bug. It looks like the only blocking issue here is the bug status (NEEDINFO). So I'm changing the status to ASSIGNED. Still, the bug shall be delivered as planed originally.
Thanks Jiri - I see Vitaly just spun kernel-2.6.9-67.0.7.EL, and I'm assuming there will be another internal include/spin prior to the 13-Mar-08 GA date...
Patch included in kernel 2.6.9-67.0.7.EL
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0167.html
Gentlemen, while this bug has been closed, I was wondering if there is any possible way that this issue could affect the mpt-fusion drivers and cause a potential Journal Abort error on an EXT3 filesystem. [root@dmx-node5 ~]# Message from syslogd@dmx-node5 at Sat Mar 22 03:42:13 2008 ... dmx-node5 kernel: journal commit I/O error We are running under Vmware ESX 3.5 w/ an iSCSI SAN, and in most cases, I would attribute this to very high load on the SAN. In fact, I've not had issues w/ this until more recent kernels. At the time that this issue is happening (it is not isolated to this VM, but to all machines running 2.6.9-67.0.4) there is nominal load, and no indication of SAN timeout issues or SCSI mid-layer issues in the VM or the logs. Am I chasing a red-herring here? If so, any suggestions on debugging procedures that I should use to diagnose the specific issue? This does not seem to affect anything running RHEL5 w/ latest kernels.
We're running kernel-hugemem-2.6.9-67.EL we have a RAID-10 setup and just recently we noticed issues with "find" spinning in "D" state (uninterruptible sleep) can this be related? time strace -c find . -type d >../find.out q% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 49.44 114.793832 63 1821161 getdents64 18.73 43.484328 16 2731259 lstat64 11.44 26.549265 15 1820837 chdir 5.78 13.427308 15 910426 close 5.31 12.329499 14 910427 open 4.78 11.103291 12 910426 fstat64 4.42 10.251790 11 910419 fcntl64 0.10 0.230356 31 7375 write 0.00 0.000206 69 3 mremap 0.00 0.000203 203 1 execve 0.00 0.000127 21 6 read 0.00 0.000124 31 4 munmap 0.00 0.000103 13 8 old_mmap 0.00 0.000061 12 5 mmap2 0.00 0.000032 11 3 brk 0.00 0.000029 15 2 1 access 0.00 0.000028 14 2 mprotect 0.00 0.000023 12 2 fchdir 0.00 0.000012 12 1 time 0.00 0.000012 12 1 uname 0.00 0.000012 12 1 set_thread_area ------ ----------- ----------- --------- --------- ---------------- 100.00 232.170641 10022369 1 total real 73m26.471s user 1m27.163s sys 5m54.949s And further on two systems at this kernel level we see "First orphan inode" showing up in output of tune2fs -l Like so: First orphan inode: 9519201 On one of these hosts gconf problems appeared and df -hl said /tmp/ was full du -sh did not agree with df and isn't surprising since df keeps track of things differently. Please advise.