On Sun, 2010-09-12 at 23:09 +0100, Steven Chamberlain wrote: > Hello, > > Some good news finally! (But perhaps bad for some...) > > I had some time to do a little more investigation myself into these > kernel Oopses, and learned what 'drivers/staging' really means. I > assumed it was to do with binary firmware, but of course it refers to a > certain kernel module having been loaded from the 'drivers/staging' area > for 'lower quality' code -- aufs. > > I'd completely forgotten that OpenVZ VE 1003, running the PHP apps that > appeared to trigger these crashes on my system, was on an aufs > filesystem. I've run OpenVZ VEs on aufs filesystems in the past quite > successfully on 2.6.26 kernels. > > I tar'd and untar'd the VE into a non-aufs filesystem, disabled aufs by > removing it from /etc/fstab, and booted back into 2.6.32-21. Happily > I've so far been unable to reproduce the kernel BUG/Oopses that I was > able to reproduce very reliably before. > > The bad news is that the Debian Live folks could possibly suffer this > issue. The kernel Oopses seem to refer to code that is used for shmfs. > With OpenVZ there is an shmfs within each VE, and one of my VEs was > running on an aufs mount, and I guess the crash has something to do with > that. In a Live environment, I think shmfs is mounted on top of an aufs > root filesystem, so I suspect this issue may arise in that situation, too. > > I understand why this issue may need to be marked 'wontfix'. I don't think it matters that a shmfs is mounted over a mountpoint in an union-filesystem. They would be entirely independent filesystems. If the shmfs was part of the union, however, that might be a problem. It may be that the current version of aufs may be incompatible with OpenVZ's memory accounting. This is unlikely to be a widely tested combination, as both features are developed outside of mainline Linux. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Description: This is a digitally signed message part