From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 Description of problem: I am running kernel-2.6.5-1.358smp with LVM2 and am experiencing intermittent failures that print the following message: Jul 6 01:13:04 dogbert kernel: __find_get_block_slow() failed. block=8195, b_blocknr=18446744073709551615 I'm not sure what other information would be pertinent at this point? I am using the above-mentioned version of the kernel because none of: kernel-2.6.6-1.427 kernel-2.6.6-1.435 kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 boot on the machine (I get an oops at startup). Version-Release number of selected component (if applicable): kernel-2.6.5-1.358 How reproducible: Couldn't Reproduce Steps to Reproduce: 1. Boot machine. 2. Wait a while. 3. Additional info: I had __find_get_block_slow() errors the first few times after booting my new install of FC2. I recently added another volume to my LVM2 setup, and again received the error.
LVM2, hmm, sounds like the butler, err, device-mapper did it. Except that device-mapper doesn't set b_blocknr, which is -1LL here. This is the initial value at the time of create_buffers, so it's most likely an uninitialized buffer sitting on a page cache page. It would be a lot more useful if __find_get_block_slow oopsed here, instead of kprint a warning, then we'll find out which filesystem it's on, or perhaps, a block device. This is about as far as I can go on straight deduction from the microscopic bug report. It would be helpful to know what filesystems he's running and what his lvm2 configuration is (always easiest to blame it on the butler). The next step after that is probably a patch to turn that warning into a BUG, if he's willing.
I have one big ext3 partition spread across 3 disks. I have 2 identical 200 GB SATA disks and 1 120 GB IDE disk. Disk /dev/sda: 203.9 GB, 203928109056 bytes 255 heads, 63 sectors/track, 24792 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 13 104391 83 Linux /dev/sda2 14 144 1052257+ 82 Linux swap /dev/sda3 145 24792 197985060 8e Linux LVM Disk /dev/sdb: 203.9 GB, 203928109056 bytes 255 heads, 63 sectors/track, 24792 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 131 1052226 82 Linux swap /dev/sdb2 132 24792 198089482+ 8e Linux LVM Disk /dev/hda: 120.0 GB, 120034123776 bytes 1 heads, 63 sectors/track, 3721296 cylinders Units = cylinders of 63 * 512 = 32256 bytes Device Boot Start End Blocks Id System /dev/hda1 2 3721296 117220792+ 83 Linux Not sure why this partition isn't marked as Linux LVM. I added the IDE disk after the initial installation and added it to the LV according to the instructions in the LVM2-HOWTO. [root@dogbert albert]# /usr/sbin/lvdisplay -m --- Logical volume --- LV Name /dev/Volume00/LogVol00 VG Name Volume00 LV UUID gATHc2-4H2i-FGEx-Jght-5Pp8-1ie2-eD4aVa LV Write Access read/write LV Status available # open 1 LV Size 489.48 GB Current LE 62654 Segments 3 Allocation next free (default) Read ahead sectors 0 Block device 253:0 --- Segments --- Logical extent 0 to 24167: Type linear Physical volume /dev/sda3 Physical extents 0 to 24167 Logical extent 24168 to 48344: Type linear Physical volume /dev/sdb2 Physical extents 0 to 24176 Logical extent 48345 to 62653: Type linear Physical volume /dev/hda Physical extents 0 to 14308 [root@dogbert albert]# /usr/sbin/lvs --debug LV VG Attr LSize Origin Snap% Move Move% LogVol00 Volume00 -wn-ao 489.48G Let me know if I can provide any more information. Note that I haven't been able to reliably reproduce the failure.
Created attachment 102903 [details] mkdisk-rh.tar.gz package
I can reproduce this message with the attached test case. Note that this is on an Intel Tiger ia64 box, running 2.6 BK as of 8/19/2004. In fact, I get an endless stream of the messages when running the "mkdisk" script in the attached tarball. This script creates a disk image for use with a simulator. It creates an empty file, runs parted to create a partition table and filesystems in the partitions, mounts the partitions using loopback mount, and populates them from an included tar file. It also does "tune2fs -j" on an ext2 partition. If I remove this line, the script runs fine. With the "tune2fs -j", I get an endless stream of this message: __find_get_block_slow() failed. block=8196, b_blocknr=18446744073709551615 b_state=0x00000000, b_size=1024 device blocksize: 1024
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.