On Sat 09-04-11 11:21:40, Tetsuo Handa wrote: > Jan Kara wrote: > > Hmm, but 2.6.18 is really ancient. I'm afraid I cannot help you much with > > it. There have been numerous bugs fixed since then. > > It is RHEL5.6 kernel which the known bugs have been fixed. I guess that RHEL6.0 Yes, but RHEL (as well as SLES) kernels are generally fixed on as needed basis - i.e., when a customer reports an error, support debugs it and adds the fix to the kernel. So you could well be the first one to spot the issue with RHEL 5.6 kernel... > kernel also has this bug (since this bug is in Ubuntu 10.04 kernels). Yes, Ubuntu 10.04 is more relevant. 2.6.32 is not that old and I don't remember any fixes in that area. > So, I want to try establishing the steps to reproduce. > > Does anybody come up with common characteristics between below hangups? > > (a) Updating rpm packages using rpm executed from zypper. > > Although, the process actually hanged is /bin/sh which > I guess was invoked for pre- or post- install scripts. > > Installing: grub-0.97-173.6 [91%] > > (b) Logging in from console using /bin/login . > > Although, the process actually hanged seems to be auditd process > which attempted to write an audit log immediately after login event. > > (c) PostgreSQL and Apache. > > http://www.mail-archive.com/pgsql-bugs@xxxxxxxxxxxxxx/msg24852.html > > Writing with O_SYNC? Or calling fsync()? Or calling ftruncate()? Or ...? I wouldn't expect any of this. If your original Ubuntu 10.04 report is right, we block on j_barrier_count which is changed only in journal_lock/unlock_updates() which gets called only from a few places. The problem is that the hung process need not be directly related to the hang. It can be just a victim of a race with some other process manipulating j_barrier_count. But I don't see any such race in the code. So I'd need a way to reproduce this so that we can perform some debugging. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
