"bio too big" error

Hi,

I'm getting a "bio too big" error with 2.5.50. I've got a 330G lvm2 partition formatted with ext3 using the -T largefile4 parameter. Everything seems ok at first, but any sort of access will die very unhappily with said error messsage after about 10 seconds of operation or so. The only google search results are the patch submission. Eeek.

Wil

How odd.

Please send the full diagnostic output.

And add this:

@@ -1921,6 +1921,7 @@ end_io:
 			       bdevname(bio->bi_bdev),
 			       bio_sectors(bio),
 			       q->max_sectors);
+			dump_stack();
 			goto end_io;
 		}
 

_

Exact error with debug is:

darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
Convulsion.ogg
bio too big device ide0(3,4) (256 > 255)

Call Trace: [<c020055e>]  [<e09ff46d>]  [<e09ff558>]  [<e09ff5f5>] 
[<c020050a>]  [<c02005f4>]  [<c017048e>]  [<c0170a79>]  [<c0187770>] 
[<c01472e6>]  [<c0187770>]  [<c0140edd>]  [<c01977fc>]  [<c01473e4>] 
[<c01475be>]  [<c0137ac8>]  [<c0137e60>]  [<c0138124>]  [<c0137e60>] 
[<c01381ca>]  [<c014eadb>]  [<c01094cb>]
[<e09def98>]  [<c01113bf>]  [<c0110ac2>]  [<c014ebce>]  [<c014ee6e>] 

[<c010967f>]

I'm guessing its perhaps a 2.5 / lvm issue? Here's 'vgdisplay -v' in case:

Finding all volume groups
Finding volume group "cheese_vg"
--- Volume group ---

  VG Name               cheese_vg
  System ID             darwin1025684717
  Format                lvm2
  Metadata Areas        6
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                256
  Cur LV                1
  Open LV               1
  Max PV                256
  Cur PV                5
  Act PV                5
  VG Size               330.05 GB
  PE Size               16.00 MB
  Total PE              21123
  Alloc PE / Size       21123 / 330.05 GB
  Free  PE / Size       0 / 0
  VG UUID               WF3vAx-k1r3-NUjU-az7z-I4SM-oorx-rvoYSt

--- Logical volume ---

  LV Name                /dev/cheese_vg/blah
  VG Name                cheese_vg
  LV UUID                000000-0000-0000-0000-0000-0000-000000
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                330.05 GB
  Current LE             21123
  Segments               7
  Allocation             next free
  Read ahead sectors     1024
  Block device           254:0

--- Physical volumes ---

  PV Name               /dev/discs/disc1/disc     
  PV Status             allocatable
  Total PE / Free PE    4769 / 0

  PV Name               /dev/ide/host2/bus0/target0/lun0/disc     
  PV Status             allocatable
  Total PE / Free PE    7361 / 0

  PV Name               /dev/ide/host2/bus1/target0/lun0/disc     
  PV Status             allocatable
  Total PE / Free PE    5961 / 0

  PV Name               /dev/discs/disc0/part4     
  PV Status             allocatable
  Total PE / Free PE    2431 / 0

  PV Name               /dev/discs/disc4/disc     
  PV Status             allocatable
  Total PE / Free PE    601 / 0

Wil

Wil Reichert <[email protected]>

Did you try the dm patches that were just posted to lkml today?

thanks,

greg k-h

Just subscribed today, missed 'em. You're refering to

http://people.sistina.com/~thornber/patches/2.5-stable/2.5.50/2.5.50-dm-2.tar.bz2 ?

They result in:

darwin:~# /etc/init.d/lvm2 start
Initializing LVM: device-mapper: device /dev/discs/disc4/disc too small
for target
device-mapper: internal error adding target to table
device-mapper: destroying table
  device-mapper ioctl cmd 2 failed: Invalid argument
  Couldn't load device 'cheese_vg-blah'.
  0 logical volume(s) in volume group "cheese_vg" now active
lvm2.

Guess I'll give 2.5.51 w/ the dm patches a shot.

Wil

Nope, try the ones at:

	http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/

thanks,

greg k-h

Could you please enable CONFIG_KALLSYMS and regenerate the backtrace?

Thanks.

Could you please enable CONFIG_KALLSYMS and regenerate the backtrace?

darwin:~$ cp /a01/movies/metropolis.avi .
bio too big device ide2(33,0) (256 > 255)
Call Trace:
 [<c02035ee>] generic_make_request+0x1ce/0x210
 [<e093046d>] __clone_and_map+0xbd/0x120 [dm_mod]
 [<e0930558>] __split_bio+0x88/0xb0 [dm_mod]
 [<e09305f5>] dm_request+0x75/0xb0 [dm_mod]
 [<c020359a>] generic_make_request+0x17a/0x210
 [<c01dd314>] radix_tree_extend+0x64/0x90
 [<c0203684>] submit_bio+0x54/0xa0
 [<c017209e>] mpage_bio_submit+0x2e/0x40
 [<c0172689>] mpage_readpages+0xc9/0x160
 [<c0189780>] ext3_get_block+0x0/0xb0
 [<c013a526>] read_pages+0x116/0x120
 [<c0189780>] ext3_get_block+0x0/0xb0
 [<c013853d>] __alloc_pages+0x8d/0x290
 [<c013a624>] do_page_cache_readahead+0xf4/0x180
 [<c013a7fe>] page_cache_readahead+0x14e/0x190
 [<c0135168>] do_generic_mapping_read+0xb8/0x410
 [<c0154443>] __block_commit_write+0x93/0xa0
 [<c0135500>] file_read_actor+0x0/0xf0
 [<c01357c4>] __generic_file_aio_read+0x1d4/0x220
 [<c0135500>] file_read_actor+0x0/0xf0
 [<c013586a>] generic_file_aio_read+0x5a/0x80
 [<c015076b>] do_sync_read+0x8b/0xc0
 [<c0136e3c>] generic_file_write+0x5c/0x80
 [<c015085e>] vfs_read+0xbe/0x130
 [<c0150afe>] sys_read+0x3e/0x60
 [<c01096af>] syscall_call+0x7/0xb

Wil

looks like a one-off in the dm merge_bvec function.

Jens Axboe

Nope, we're not using merge_bvec yet. Kevin Corry has convinced me that there is a bug in dms bv splitting code, I'll put out a new patchset later. However the known bug wouldn't have a stack trace like this.

- Joe

Could you try the patchset below please ? (you may need to knock out patch 5 until we get to the bottom of that particular bug).

http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-2.tar.bz2

- Joe

Yeah, ditching patch 5 makes my lvm functional again. Things are definately better now. I haven't attempted to stress it, but the entire hanging console / zombie process bit has gone away. Everything appears to work normally. A couple test cp's shows nothing abnormal, but playing an ogg still results in the following.

Dec 12 13:32:20 darwin kernel: bio too big device ide2(33,0) (256 > 255)
Dec 12 13:32:51 darwin last message repeated 3 times
Dec 12 13:33:55 darwin last message repeated 6 times

Any other tests I should do?

Wil

Wil Reichert <[email protected]>

I'm now seeing some corruption with large files, so I'll fix that and hope that it solves your problem too. wrt. the device size bug that you're experiencing could you mail me (not the list) your .config please ?

- Joe