On Tue, 2005-11-22 at 09:39 +0100, Fabio Coatti wrote:
> Alle 23:36, lunedì 21 novembre 2005, Dave Kleikamp ha scritto:
> 
> >
> > A very similar problem was reported before, but I never did figure out
> > what the cause was:
> > http://www.mail-archive.com/[email protected]/msg00250.h
> >tml
> >
> > I run gentoo myself and haven't seen it firsthand.  I've tried
> > remounting between read-only & read-write under a number of different
> > circumstances, but I still can't recreate the problem.
> >
> > What modules do you have loaded?  That seemed to make a difference.
> 
> Well, the list of loaded modules is in the report below;

Duh.  I asked what modules were loaded, then quoted the list.  :-)

I'm confused.  How do all those modules get loaded
before /etc/init.d/checkroot is run?  Do you use genkernel?  (I don't.)
On my system, the root file system is checked before any modules get
loaded.

>  anyway I've noticed 
> that a similar oop (or BUG) happens often at boot, maybe it can be related to 
> log replay. On this machine I change quite often kernel (at least, at every 
> MM release) and I've noticed that reboot is very "dangerous" moment for my 
> jfs volumes. Say, several reboots with rc4-mm1, no problems. Complied 
> rc4-mm2, booted with BUG. rebooted back with rc4-mm1, BUG. it has no pattern 
> that I can find, but it seems related to some strange state of written data 
> that confuses jfs code.
> Last time, something happened not during boot but where unmerging after glibc 
> merging (so after heavy HD load): unmerge got stuck executing rm (D state) 
> and after reboot all files related to glibc were corrupted or damaged (even 
> lib*so symlinks), maybe jfs was hit hard and was unable to wrote down data in 
> a right way.

This doesn't sound like any current bugs that I'm aware of.

> This happens with mm series kernel, I've no data for vanilla kernel.
> today I've find the following BUG on logs of the same machine, but the system 
> is still up & running (more or less :) ), so if needed it's possible to 
> collect more data.

I can send you a patch to print out some more data in the failing path,
and maybe avoid the BUG.  I'm trying to figure out how to recreate the
problem on my own, but I just can't hit it.
-- 
David Kleikamp
IBM Linux Technology Center



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion

Reply via email to