Bug 10407 - kernel message: "bio too big device md0 (248 > 240)"
Summary: kernel message: "bio too big device md0 (248 > 240)"
Status: CLOSED OBSOLETE
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: MD (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: io_md
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-06 12:42 UTC by karme
Modified: 2012-05-18 10:38 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.24
Subsystem:
Regression: No
Bisected commit-id:


Attachments
lvmdump (107.77 KB, application/x-compressed-tar)
2008-04-06 12:45 UTC, karme
Details
lshal output (125.44 KB, text/plain)
2008-04-06 12:52 UTC, karme
Details
sudo lsusb output (14.89 KB, text/plain)
2008-04-06 12:52 UTC, karme
Details

Description karme 2008-04-06 12:42:00 UTC
Latest working kernel version: Earliest failing kernel version: Distribution: Hardware Environment: Software Environment: Problem Description:  Steps to reproduce:
Comment 1 karme 2008-04-06 12:45:07 UTC
Created attachment 15635 [details]
lvmdump
Comment 2 karme 2008-04-06 12:48:25 UTC
Somehow the bug description got lost :-(

Earliest failing kernel version: 2.6.18
Distribution: debian/lenny (testing)

Problem Description:
I have a Lenovo Z61m Laptop and use md1 raid mostly in degraded state.
From time to time I connect an external usb disk, that is part of the same
raid and do an incremental resync. (md1 raid with internal bitmap).

On top of the md1 raid I use lvm and dm-crypt
(see also attached lvmdump).

Without lvm snapshots:
jens@thialfi:~$ sudo dmsetup ls --tree -o inverted
 (9:0)
 ├─thialfi-lvcrypt (253:2)
 │  └─thialfi-lvcrypt_crypt (253:3)
 │     ├─vgcrypt-home (253:14)
 │     ├─vgcrypt-debianroot (253:5)
 │     ├─vgcrypt-var (253:10)
 │     └─vgcrypt-swap (253:8)
 ├─thialfi-boot (253:1)
 └─thialfi-rescue (253:0)

With lvm snapshots:
jens@thialfi:~$ sudo dmsetup ls --tree -o inverted
 (9:0)
 ├─thialfi-lvcrypt (253:2)
 │  └─thialfi-lvcrypt_crypt (253:3)
 │     ├─vgcrypt-s0804061608_debianroot-cow (253:7)
 │     │  └─vgcrypt-s0804061608_debianroot (253:4)
 │     ├─vgcrypt-debianroot-real (253:6)
 │     │  ├─vgcrypt-s0804061608_debianroot (253:4)
 │     │  └─vgcrypt-debianroot (253:5)
 │     ├─vgcrypt-home-real (253:15)
 │     │  ├─vgcrypt-home (253:14)
 │     │  └─vgcrypt-s0804061608_home (253:13)
 │     ├─vgcrypt-s0804061608_var-cow (253:12)
 │     │  └─vgcrypt-s0804061608_var (253:9)
 │     ├─vgcrypt-var-real (253:11)
 │     │  ├─vgcrypt-var (253:10)
 │     │  └─vgcrypt-s0804061608_var (253:9)
 │     ├─vgcrypt-swap (253:8)
 │     └─vgcrypt-s0804061608_home-cow (253:16)
 │        └─vgcrypt-s0804061608_home (253:13)
 ├─thialfi-boot (253:1)
 └─thialfi-rescue (253:0)

If I re-add the external usb disk to the raid1 and I don't keep lvm snapshots around
I get lots of kernel messages:
,----
| bio too big device md0 (248 > 240)
| bio too big device md0 (248 > 240)
| bio too big device md0 (248 > 240)
| bio too big device md0 (248 > 240)
| bio too big device md0 (248 > 240)
| bio too big device md0 (248 > 240)
| bio too big device md0 (248 > 240)
| ...
`----
on read or write of large files.
It seems this results in raid desynchronization/corruption on write.

I think I run into the same problem as described in a thread on the lkml:
"[dm-devel] bio too big device md1 (16 > 8)"
Message-Id   <87irc84bcq.87hcrs4bcq@87fy7c4bcq.message.id>
http://lkml.org/lkml/2007/4/7/81

A related thread on dm-devel about a patch that probably doesn't help:
"[dm-devel] [2.6.22 PATCH 01/26] dm: merge max_hw_sector"
http://www.redhat.com/archives/dm-devel/2007-May/msg00007.html

As workaround I keep the LVM snapshots around and the message disappears.

The 240 in the error message I guess is related to the usb disk max_sectors?
cat /sys/block/sdb/device/max_sectors
240

lspci:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752M Gigabit Ethernet PCI Express (rev 02)
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
15:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
15:00.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
15:00.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
15:00.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

sudo sh -c 'for i in $(find /sys/block/sda); do test -f "$i" && { echo $i; cat $i; } ; done'
/sys/block/sda/uevent
/sys/block/sda/dev
8:0
/sys/block/sda/range
16
/sys/block/sda/removable
0
/sys/block/sda/size
156301488
/sys/block/sda/stat
  712394  1622091 175462126 23250700  1451351   934929 19543234 411426860        0 11069144 434705620
/sys/block/sda/capability
12
/sys/block/sda/sda1/uevent
/sys/block/sda/sda1/dev
8:1
/sys/block/sda/sda1/start
63
/sys/block/sda/sda1/size
156296322
/sys/block/sda/sda1/stat
 2337774 175460998  2387671 19101454
/sys/block/sda/queue/nr_requests
128
/sys/block/sda/queue/read_ahead_kb
128
/sys/block/sda/queue/max_hw_sectors_kb
32767
/sys/block/sda/queue/max_sectors_kb
512
/sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq] 
/sys/block/sda/queue/iosched/quantum
4
/sys/block/sda/queue/iosched/fifo_expire_sync
124
/sys/block/sda/queue/iosched/fifo_expire_async
248
/sys/block/sda/queue/iosched/back_seek_max
16384
/sys/block/sda/queue/iosched/back_seek_penalty
2
/sys/block/sda/queue/iosched/slice_sync
100
/sys/block/sda/queue/iosched/slice_async
40
/sys/block/sda/queue/iosched/slice_async_rq
2
/sys/block/sda/queue/iosched/slice_idle
8


sudo sh -c 'for i in $(find /sys/block/sda); do test -f "$i" && { echo $i; cat $i; } ; done'
/sys/block/sda/uevent
/sys/block/sda/dev
8:0
/sys/block/sda/range
16
/sys/block/sda/removable
0
/sys/block/sda/size
156301488
/sys/block/sda/stat
  712394  1622091 175462126 23250700  1451351   934929 19543234 411426860        0 11069144 434705620
/sys/block/sda/capability
12
/sys/block/sda/sda1/uevent
/sys/block/sda/sda1/dev
8:1
/sys/block/sda/sda1/start
63
/sys/block/sda/sda1/size
156296322
/sys/block/sda/sda1/stat
 2337774 175460998  2387671 19101454
/sys/block/sda/queue/nr_requests
128
/sys/block/sda/queue/read_ahead_kb
128
/sys/block/sda/queue/max_hw_sectors_kb
32767
/sys/block/sda/queue/max_sectors_kb
512
/sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq] 
/sys/block/sda/queue/iosched/quantum
4
/sys/block/sda/queue/iosched/fifo_expire_sync
124
/sys/block/sda/queue/iosched/fifo_expire_async
248
/sys/block/sda/queue/iosched/back_seek_max
16384
/sys/block/sda/queue/iosched/back_seek_penalty
2
/sys/block/sda/queue/iosched/slice_sync
100
/sys/block/sda/queue/iosched/slice_async
40
/sys/block/sda/queue/iosched/slice_async_rq
2
/sys/block/sda/queue/iosched/slice_idle
8


sudo sh -c 'for i in $(find /sys/block/sda/device/); do test -f "$i" && { echo $i; cat $i; } ; done'
/sys/block/sda/device/uevent
DEVTYPE=scsi_device
DRIVER=sd
PHYSDEVBUS=scsi
PHYSDEVDRIVER=sd
MODALIAS=scsi:t-0x00
/sys/block/sda/device/device_blocked
0
/sys/block/sda/device/type
0
/sys/block/sda/device/scsi_level
6
/sys/block/sda/device/vendor
ATA     
/sys/block/sda/device/model
TOSHIBA MK8034GS
/sys/block/sda/device/rev
AH30
/sys/block/sda/device/rescan
/sys/block/sda/device/delete
/sys/block/sda/device/state
running
/sys/block/sda/device/timeout
30
/sys/block/sda/device/iocounterbits
32
/sys/block/sda/device/iorequest_cnt
0x22be46
/sys/block/sda/device/iodone_cnt
0x22be45
/sys/block/sda/device/ioerr_cnt
0x2
/sys/block/sda/device/modalias
scsi:t-0x00
/sys/block/sda/device/evt_media_change
0
/sys/block/sda/device/power/wakeup

/sys/block/sda/device/queue_depth
1
/sys/block/sda/device/queue_type
none


sudo sh -c 'for i in $(find /sys/block/sdb/device/); do test -f "$i" && { echo $i; cat $i; } ; done'
/sys/block/sdb/device/uevent
DEVTYPE=scsi_device
DRIVER=sd
PHYSDEVBUS=scsi
PHYSDEVDRIVER=sd
MODALIAS=scsi:t-0x00
/sys/block/sdb/device/device_blocked
0
/sys/block/sdb/device/type
0
/sys/block/sdb/device/scsi_level
0
/sys/block/sdb/device/vendor
ST332062
/sys/block/sdb/device/model
0A              
/sys/block/sdb/device/rev
0000
/sys/block/sdb/device/rescan
/sys/block/sdb/device/delete
/sys/block/sdb/device/state
running
/sys/block/sdb/device/timeout
30
/sys/block/sdb/device/iocounterbits
32
/sys/block/sdb/device/iorequest_cnt
0xd1
/sys/block/sdb/device/iodone_cnt
0xd1
/sys/block/sdb/device/ioerr_cnt
0x7
/sys/block/sdb/device/modalias
scsi:t-0x00
/sys/block/sdb/device/evt_media_change
0
/sys/block/sdb/device/power/wakeup

/sys/block/sdb/device/queue_depth
1
/sys/block/sdb/device/queue_type
none
/sys/block/sdb/device/max_sectors
240


Let me know if you need additional info.

Thanks in advance
Jens
Comment 3 karme 2008-04-06 12:52:18 UTC
Created attachment 15636 [details]
lshal output
Comment 4 karme 2008-04-06 12:52:52 UTC
Created attachment 15637 [details]
sudo lsusb output
Comment 5 Milan Broz 2008-04-07 00:33:39 UTC
Please read
http://bugzilla.kernel.org/show_bug.cgi?id=9401#c3
I think it is the same problem
(stacking block devices and change of max_sectors lower the stack without notifying upper layer).

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