On 2/12/06, Tomas M <[EMAIL PROTECTED]> wrote: > I examined the dmesg again, > and it seems to be related rather to squashfs then unionfs... > So I would like to apologize, for bothering you in wrong mailing list :)
Unfortunately, the dmesg is very inconclusive as to what is going wrong. The kernel isn't panicing (in the one dmesg given in this thread) in SquashFS, but in the lower level block I/O handling code. Again, the SquashFS error messages you reported (off the mailing list), are generated when the block I/O system has reported errors. Given this, I'm inclined to believe the bugs are caused by the kernel operating unreliably because of the previously mentioned ACPI hardware issues. You could try building a non-ACPI SMP kernel to prove it is the ACPI settings causing the problem. SquashFS has been around for quite a while and I've had no SMP problems reported for many years, and so I believe the locking to be pretty stable. if there was problems with SMP I would not expect the erorr messages you're getting and quite different behaviour. Regards Phillip Lougher > > I'm sorry, next time I will be more careful. > > > Tomas M > > > Josef Sipek wrote: > > On Sat, Feb 11, 2006 at 06:38:03PM +0100, Tomas M wrote: > > > >> When I use unionfs in my Linux notebook, everything is OK. But when I > >> use the same unionfs.ko module on the P4 machine (with the same > >> kernel), it causes many SEGFAULTs etc. > >> > > > > What does dmesg say? > > > > > >> Then it works flawlessly. Maybe it's only a bug in Linux kernel ACPI > >> or SMP code, > >> > > > > ACPI is notorious for being mis-implemented by the hardware > > manufacturers, kernel developers can't really do anything about that, > > except blacklist the worst cases, and work around the better ones. > > > > > >> nevertheless I would like to ask a general question: Is > >> it any special case of usage to run unionsf on multiprocessor > >> machines? In other words, do you, developers, think about > >> multiprocessor configuration while developing unionfs? Is there any > >> difference? > >> > > > > I, personally, try to think about concurency issues whenever I can. As > > you may have noticed unionfs code wasn't always written with it in mind > > (for example, branch management is currently quite racy.) This, I think, > > is because UnionFS was developed very quickly on single processor > > systems running 2.4 kernels (which do not have preemption.) 2.6's > > preemption, and now the easy access to "SMP" systems is making many > > kernel bugs appear seemingly out of nowhere. Bugs which for long time > > sat in the code, waiting for the right sequence of circumstances to > > occur. > > > > > >> Basically I don't depend on the answer, just would like to bring this > >> to your attention. > >> > > > > Thank you. I'm sure that once we submit the code for review for eventual > > inclusion into vanilla kernel, we'll get plenty of comments about locking > > :) > > > > Jeff. > > _______________________________________________ > > unionfs mailing list > > [email protected] > > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs > > > > > _______________________________________________ > unionfs mailing list > [email protected] > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs > _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
