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
The problems occur with kernel-2.6.9-1.667 (.src.rpm is at
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 <email@example.com> 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
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
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
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:
bh2 = <bitmap buffer>;
err = ext3_journal_get_write_access(handle, bh2);
rc = do_get_write_access(handle, jh, 0, credits);
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
Weird. How reproducible is this? When do they occur --- always
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
> 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
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
But then, all of this should have happened:
printk("__find_get_block_slow() failed. "
(unsigned long long)block, (unsigned long
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 ?