Bug 127285 - Crash: __find_get_block_slow fails
Summary: Crash: __find_get_block_slow fails
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Daniel Phillips
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-05 23:30 UTC by Albert Strasheim
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 05:32:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mkdisk-rh.tar.gz package (39.25 KB, application/octet-stream)
2004-08-19 22:21 UTC, Bjorn Helgaas
no flags Details

Description Albert Strasheim 2004-07-05 23:30:56 UTC
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:


boot on the machine (I get an oops at startup).

Version-Release number of selected component (if applicable):

How reproducible:
Couldn't Reproduce

Steps to Reproduce:
1. Boot machine.
2. Wait a while.

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.

Comment 1 Daniel Phillips 2004-07-06 06:50:22 UTC
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. 

Comment 2 Albert Strasheim 2004-07-06 15:30:41 UTC
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.

Comment 3 Bjorn Helgaas 2004-08-19 22:21:01 UTC
Created attachment 102903 [details]
mkdisk-rh.tar.gz package

Comment 4 Bjorn Helgaas 2004-08-19 22:24:05 UTC
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_state=0x00000000, b_size=1024  
device blocksize: 1024  

Comment 5 Dave Jones 2005-04-16 05:32:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.