I get a kerneloops on 2.6.32 kernels unless CONFIG_LBDAF is yes. This is on a Lenovo W500 thinkpad that only has a 150G hard drive so there shouldn't be any need for LBDAF. The kerneloops is very early in the boot process. I always build my own kernels. I copied the 2.6.30 kernel config for my current kernel to the 2.6.32 source directory and did a make oldconfig. The resulting 2.6.32 kernel gave the kerneloops. After a long process of narrowing down what was causing the problem, I found that LBDAF had to be used for the kernel to boot. The system is an up to date Debian Squeeze/testing. The kerneloops is very early in the boot process before all of the partitions are mounted so the kerneloops doesn't give any output that I can see. Of course, the solution is to use CONFIG_LBDAF but it seems a little silly on a 150G hard drive system. The previous kernel I was using was 2.6.30 which works fine without CONFIG_LBDAF set to yes.
Created attachment 24873 [details] config file that gives kerneloops
Created attachment 24874 [details] config file that works
We really need to see that oops trace, please. Perhaps use netconsole (Documentation/networking/netconsole.txt) or set the display to 50 columns (Documentation/oops-tracing.txt) and take a digital photo? Thanks.
On Wed, 2010-02-03 at 21:54 +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15209 > > > Andrew Morton <akpm@linux-foundation.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |akpm@linux-foundation.org > > > > > --- Comment #3 from Andrew Morton <akpm@linux-foundation.org> 2010-02-03 > 21:54:56 --- > We really need to see that oops trace, please. Perhaps use netconsole > (Documentation/networking/netconsole.txt) or set the display to 50 columns > (Documentation/oops-tracing.txt) and take a digital photo? > > Thanks. > I don't think any of those methods will work because the problem is so early in the boot process. I was able to modify my grub2 configuration and make the screen as high a resolution as possible. It looks like the problem is with mounting the partitions. Before the messages scroll off of the screen, I can see that it looks like it is having the same problem mounting all of the partitions. I have several partitions. The error for the last partition is still visible at the top of the screen. Here is what it says: [ 8.871218] EXT4-fs (sda5):Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF mount: wrong fs type, bad option, bad superblock on /dev/sda5, missing codepage or helper program, or other error In some cases useful info is found in syslog -try dmesg | tail or so That makes sense for why the kernel with CONFIG_LBDAF=y will work. What doesn't make sense is why it thinks there are "huge files" when the whole hard drive is only 150G. I can try and get you more information if you need it. There are more errors later most of them relating to not finding files since the partitions haven't been mounted. My disk is partitioned like this: /dev/sda1 ntfs 17.57GB /dev/sda2 ext4 / 753.05 MB /dev/sda3 ext4 /tmp 2.44 GB /dev/sda4 extended 128.30 GB /dev/sda5 ext4 /var 9.77 GB /dev/sda6 ext4 /var/log 502 MB /dev/sda7 linux-swap 4.15 GB /dev/sda8 ext4 /opt 9.77 GB /dev/sda9 ext4 /usr 41.02 GB /dev/sda10 ext4 /home 63.10 GB Brent
[ 8.871218] EXT4-fs (sda5):Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF Your file system contains huge files - so the behaviour is correct. A "large file" is one that has a length over 2GB, and that can include empty areas (which are not stored on disk). Doesn't seem to be a bug therefore. (see "man find" if you want to go looking for the large files)
Correct that LBDAF is 2TB not 2GB. I think what is happening here is that you have the large file features enabled on the fs, which is the default for ext4 (that is you actually have to mkfs an ext4 file system with special options in order to avoid this). So still not a bug but I misinterpreted it initially. The message is confusing however.