Here's the info on problems Cristian Gafton hit on a Fedora Core 3 install. One is attached as a log. The other is at http://people.redhat.com/sopwith/install-trace.jpg :) Since the tree he was installing from was *supposed* to be final, the first thing I'm interested in knowing is how many users will be impacted by this problem. And if it has a substantial impact, hopefully a fix will be easy to create. The problems occur with kernel-2.6.9-1.667 (.src.rpm is at http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/kernel-2.6.9-1.667.src.rpm.) The only 'different' thing of note is that these are happening with selinux OFF, which we haven't tested much with FC3 so far. (Everyone wants to run SELinux, right? :)
Created attachment 106174 [details] Log from another oops
From Andrew Morton: This looks like the one Dave is working on - it appears to be a null bh->b_this_page in the buffer ring. Are any non-4k-blocksize devices involved here?
From Andrew Morton: Cristian Gafton <gafton> wrote: > > > Are any non-4k-blocksize devices involved here? > > Nope, these are standard 120G IDE drives that are chopped up in 6 > partitions, with RAID1 across each of the identical partition sets. Any small filesystem will end up with small software blocksize by default. Are there any small filesystems or blockdevices in use during this process? ramdisks? Anything like that? A full `df' after a successful boot would tell us.
From Stephen Tweedie: There are two different problems being exhibited here. The screenshot shows a BUG() in submit_bh(): we failed the check at BUG_ON(!buffer_mapped(bh)); That's during unmount; unmount race for Al? The one from the text log is a null pointer deref, but not on b_this_page. I just checked the disassembly of that build (btw, Dave, there's nothing in the oops that tells us it's an i586 build, not i686 --- we added that for RHEL3, and it would be _really_ useful to have it here too!) It's actually the initial deref in __find_get_block_slow that oopsed: struct inode *bd_inode = bdev->bd_inode; but bdev is NULL. The call chain is: ext3_new_inode(): bh2 = <bitmap buffer>; err = ext3_journal_get_write_access(handle, bh2); rc = do_get_write_access(handle, jh, 0, credits); journal_cancel_revoke(handle, jh); bh2 = __find_get_block(bh->b_bdev, bh->b_blocknr, bh->b_size); yet when we get here, we've got bh->bdev==NULL, bh->blocknr==2, and bh->b_size==0. Weird. How reproducible is this? When do they occur --- always during cleanup/unmount?
Creating a bugzilla report to track all this info...
I did an 'ext3-on-LVM-on-RAID1' install just now without any problems. The setup is: /dev/hda: /boot partition plus six RAID partitions Three RAID-1 arrays (two partitions each, from the six) LVM - three PV's on the three RAID-1 arrays, five LV's of varying sizes, including a couple of filesystems with a 1024-byte block size. So far the two variables that may be in play are whether LVM is in use and whether SELinux is in use.
For whatever it's worth, I've been doing RAID-1 with SELinux off and without LVM. I've not been seeing this.... That's on x86_64, though, not on i386
Cristian adds: > Are there any small filesystems or blockdevices in use during this > process? ramdisks? Anything like that? Yes, there are. The /boot partition is also a RAID1 that is 100M in size, created with a 1K block size.
Can we check whether it's /boot-on-raid1 that's causing the problem here? Elliot's last test did not do that, from what I see.
I just did another install without LVM, but with /boot on RAID1. No problems. gafton has another install or two going that may provide additional insights, but it's not sounding like this is a widespread problem.
Andrew Morton adds: OK. Is it possible to force the mkfs on that partition to use 4k blocks? (mkfs -b 4096)? That'll use a bit more space so you might need to increase the size a bit. If that fixes it then perhaps we've hit a snag when the kernel is switching block sizes on a device. Maybe. IIRC we used to have problems where the fs mount code reads the filesystem using a 1k block size and we then switch to 4k block size but find we hadn't successfully stripped the pagecache page's 1k buffers. But then, all of this should have happened: printk("__find_get_block_slow() failed. " "block=%llu, b_blocknr=%llu\n", (unsigned long long)block, (unsigned long ong)bh->b_blocknr); printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size); printk("device blocksize: %d\n", 1 << bd_inode->i_blkbits); So I dunno, sorry.
Because of an inability to reproduce the problem during several installs, we've decided to go ahead with the FC3 release as-is. The bug still needs fixing, of course. :)
did this bug ever show up again with later kernels ?