I've noticed some posts in the last few days that relate to the the disk
subsystem trying to access blocks beyond the limits of the device.
I've seen the same problem on one of the machines I administrate. In my
situation, syslogd logged the messages until the machine ground to a halt.
The machine would respond to console changes but when a login was attempted,
login name name and password could be entered but an endless hang followed
due to load/inactivity of disk subsystem? So, the kernel didn't panic;
processes were still running. The machine has a DPT SmartRAID V adapter
in it; it had no audible alarm which leads me to believe there was no
hardware problem with the disk array. The machine was than chunked.
Unfortunately the person that chunked the machine didn't know 'magic sysrq
keys' was built in. So no sync/mount-ro was attempted before the reboot.
When the machine booted, the kernel panicked because of massive filesystem
corruption on the root partition. When the fs was finally fixed via
e2fsck, the lost+found dir had numerous unreferenced inode entries.
That didn't concern me too much until I examined them; all of which
are special char/block files that can't be unlinked!? 'unlink: Operation
not permitted' My question is whether this is a 2.2.12 or driver issue
that causes the 'attempt to access beyond end of device' kernel messages?
The machine has the following hardware:
Intel SC450NX MP server/mainboard
4 Intel 500MHz/512KB PIII Xeon CPUs
1GB memory
1 SmartRAID V PM3754U2 with 3 channels and 128MB ecc memory
RAID-5 array composed from 6 IBM DNES-309170 9GB/10K disks aprox: 43GB
array is split into 4 partitions (from fdisk):
Command (m for help): p
Disk /dev/sda: 255 heads, 63 sectors, 5575 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 2 16033+ 83 Linux
/dev/sda2 3 19 136552+ 82 Linux swap
/dev/sda3 20 150 1052257+ 83 Linux
/dev/sda4 151 5575 43576312+ 83 Linux
The kernel is the stock 2.2.12 kernel tree with driver patch from DPT.
The kernel was built with RedHat 6.0 gcc:
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Driver info:
#cat /proc/scsi/dpt/3
Vendor: DPT Model: PM3754U2 Rev: 204C, scsi 3:
DPT I2O Driver Version: 1.05/1.1:
cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 2
sg_tablesize = 39, irq = 19, OutstandingMsgs = 1
maxfromiopmsgs = 16, maxtoiopmsgs = 210
Devices:
Channel = 0, Target = 0, Lun = 0
Channel = 0, Target = 6, Lun = 0
It comes to my attention that this driver is a revision behind from a prior
post. However, the newer driver possibly still has problems according to
another post?
I've contacted DPT and inquired if they had heard any problems with their
kernel patch with the stock 2.2.12 kernel. No was the answer I got.
If this is not a 2.2.12 issue, then is there anyone else out there that
has had similar problems with their DPT SRV RAID arrays?
syslog messages:
Oct 4 09:52:55 linux kernel: attempt to access beyond end of device
Oct 4 09:52:55 linux kernel: 08:04: rw=0, want=936743908, limit=43576312
Oct 4 09:52:55 linux kernel: dev 08:04 blksize=1024 blocknr=936743907 sector=1873487814 size=1024 count=1
Oct 4 09:52:55 linux kernel: attempt to access beyond end of device
Oct 4 09:52:55 linux kernel: 08:04: rw=0, want=796095601, limit=43576312
Oct 4 09:52:55 linux kernel: dev 08:04 blksize=1024 blocknr=796095600 sector=1592191200 size=1024 count=1
.
.
.
Oct 4 10:00:23 linux kernel: attempt to access beyond end of device
Oct 4 10:00:23 linux kernel: 08:04: rw=0, want=936743908, limit=43576312
Oct 4 10:00:23 linux kernel: dev 08:04 blksize=1024 blocknr=936743907 sector=1873487814 size=1024 count=1
Oct 4 10:00:23 linux kernel: attempt to access beyond end of device
Oct 4 10:00:23 linux kernel: 08:04: rw=1, want=936743908, limit=43576312
Oct 4 10:00:23 linux kernel: dev 08:04 blksize=1024 blocknr=936743907 sector=1873487814 size=1024 count=1
.
.
.
Oct 4 10:05:28 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 1394126
Oct 4 10:07:37 linux last message repeated 134 times
Oct 4 10:07:37 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 104455
Oct 4 10:07:37 linux last message repeated 27 times
.
.
.
Oct 4 10:12:31 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 468518
Oct 4 10:12:33 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 197878
Oct 4 10:16:03 linux kernel: attempt to access beyond end of device
Oct 4 10:16:03 linux kernel: 08:04: rw=0, want=870990273, limit=43576312
Oct 4 10:16:03 linux kernel: dev 08:04 blksize=1024 blocknr=870990272 sector=1741980544 size=1024 count=1
Oct 4 10:16:03 linux kernel: EXT2-fs error (device sd(8,4)): read_block_bitmap: Cannot read block bitmap - block_group = 56, block_bitmap = 870990272
syslog message entries ended and the machine was rebooted around 10:40.
lost+found unlinkable inodes (424 entries):
#ls -apln /lost+found
total 325701634130
drwxr-x--- 2 0 0 26624 Oct 8 12:47 ./
drwxr-xr-x 16 0 0 1024 Oct 8 00:00 ../
b--xr-Sr-x 1 26473 25975 106, 10 Mar 25 1995 #24658
br-xrwSrwx 1 28263 24954 109, 111 May 9 20:07 #24660
br-srwS-wT 1 25975 25199 101, 109 Feb 28 1996 #24664
b--sr-Sr-x 1 12396 27749 116, 110 Dec 8 2000 #24684
b--sr-s--t 1 29743 12602 108, 101 Mar 3 1996 #24685
br-srwSr-T 1 14958 29811 119, 97 Mar 17 1995 #24699
br-sr-s--- 1 28257 25449 105, 109 Dec 26 2026 #24715
br-xrw-r-T 1 26739 12594 104, 108 Aug 15 1995 #24717
br-xr-s--x 1 27491 25961 111, 99 Sep 1 2021 #24719
.
.
.
br-S--s-w- 1 28001 24909 47, 101 Oct 23 1998 #26620
br-xrwSr-- 1 28704 29548 115, 119 Dec 4 2023 #411987
br-srwS-wT 1 29287 26478 101, 112 Jul 19 1975 #411991
br-xr-xrwx 1 29548 25441 32, 110 Aug 20 2021 #411992
c--xrw-r-- 1 26223 26479 32, 32 Jan 14 2026 #411994
c--xr-xrw- 1 27507 8265 65, 32 Jan 29 2029 #411996
c--xr--r-- 1 25970 25970 101, 82 Oct 19 2021 #411997
b--sr-s--x 1 29801 11886 116, 105 Jan 29 2029 #411999
.
.
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
subsystem trying to access blocks beyond the limits of the device.
I've seen the same problem on one of the machines I administrate. In my
situation, syslogd logged the messages until the machine ground to a halt.
The machine would respond to console changes but when a login was attempted,
login name name and password could be entered but an endless hang followed
due to load/inactivity of disk subsystem? So, the kernel didn't panic;
processes were still running. The machine has a DPT SmartRAID V adapter
in it; it had no audible alarm which leads me to believe there was no
hardware problem with the disk array. The machine was than chunked.
Unfortunately the person that chunked the machine didn't know 'magic sysrq
keys' was built in. So no sync/mount-ro was attempted before the reboot.
When the machine booted, the kernel panicked because of massive filesystem
corruption on the root partition. When the fs was finally fixed via
e2fsck, the lost+found dir had numerous unreferenced inode entries.
That didn't concern me too much until I examined them; all of which
are special char/block files that can't be unlinked!? 'unlink: Operation
not permitted' My question is whether this is a 2.2.12 or driver issue
that causes the 'attempt to access beyond end of device' kernel messages?
The machine has the following hardware:
Intel SC450NX MP server/mainboard
4 Intel 500MHz/512KB PIII Xeon CPUs
1GB memory
1 SmartRAID V PM3754U2 with 3 channels and 128MB ecc memory
RAID-5 array composed from 6 IBM DNES-309170 9GB/10K disks aprox: 43GB
array is split into 4 partitions (from fdisk):
Command (m for help): p
Disk /dev/sda: 255 heads, 63 sectors, 5575 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 2 16033+ 83 Linux
/dev/sda2 3 19 136552+ 82 Linux swap
/dev/sda3 20 150 1052257+ 83 Linux
/dev/sda4 151 5575 43576312+ 83 Linux
The kernel is the stock 2.2.12 kernel tree with driver patch from DPT.
The kernel was built with RedHat 6.0 gcc:
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Driver info:
#cat /proc/scsi/dpt/3
Vendor: DPT Model: PM3754U2 Rev: 204C, scsi 3:
DPT I2O Driver Version: 1.05/1.1:
cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 2
sg_tablesize = 39, irq = 19, OutstandingMsgs = 1
maxfromiopmsgs = 16, maxtoiopmsgs = 210
Devices:
Channel = 0, Target = 0, Lun = 0
Channel = 0, Target = 6, Lun = 0
It comes to my attention that this driver is a revision behind from a prior
post. However, the newer driver possibly still has problems according to
another post?
I've contacted DPT and inquired if they had heard any problems with their
kernel patch with the stock 2.2.12 kernel. No was the answer I got.
If this is not a 2.2.12 issue, then is there anyone else out there that
has had similar problems with their DPT SRV RAID arrays?
syslog messages:
Oct 4 09:52:55 linux kernel: attempt to access beyond end of device
Oct 4 09:52:55 linux kernel: 08:04: rw=0, want=936743908, limit=43576312
Oct 4 09:52:55 linux kernel: dev 08:04 blksize=1024 blocknr=936743907 sector=1873487814 size=1024 count=1
Oct 4 09:52:55 linux kernel: attempt to access beyond end of device
Oct 4 09:52:55 linux kernel: 08:04: rw=0, want=796095601, limit=43576312
Oct 4 09:52:55 linux kernel: dev 08:04 blksize=1024 blocknr=796095600 sector=1592191200 size=1024 count=1
.
.
.
Oct 4 10:00:23 linux kernel: attempt to access beyond end of device
Oct 4 10:00:23 linux kernel: 08:04: rw=0, want=936743908, limit=43576312
Oct 4 10:00:23 linux kernel: dev 08:04 blksize=1024 blocknr=936743907 sector=1873487814 size=1024 count=1
Oct 4 10:00:23 linux kernel: attempt to access beyond end of device
Oct 4 10:00:23 linux kernel: 08:04: rw=1, want=936743908, limit=43576312
Oct 4 10:00:23 linux kernel: dev 08:04 blksize=1024 blocknr=936743907 sector=1873487814 size=1024 count=1
.
.
.
Oct 4 10:05:28 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 1394126
Oct 4 10:07:37 linux last message repeated 134 times
Oct 4 10:07:37 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 104455
Oct 4 10:07:37 linux last message repeated 27 times
.
.
.
Oct 4 10:12:31 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 468518
Oct 4 10:12:33 linux kernel: EXT2-fs warning (device sd(8,4)): ext2_free_blocks: bit already cleared for block 197878
Oct 4 10:16:03 linux kernel: attempt to access beyond end of device
Oct 4 10:16:03 linux kernel: 08:04: rw=0, want=870990273, limit=43576312
Oct 4 10:16:03 linux kernel: dev 08:04 blksize=1024 blocknr=870990272 sector=1741980544 size=1024 count=1
Oct 4 10:16:03 linux kernel: EXT2-fs error (device sd(8,4)): read_block_bitmap: Cannot read block bitmap - block_group = 56, block_bitmap = 870990272
syslog message entries ended and the machine was rebooted around 10:40.
lost+found unlinkable inodes (424 entries):
#ls -apln /lost+found
total 325701634130
drwxr-x--- 2 0 0 26624 Oct 8 12:47 ./
drwxr-xr-x 16 0 0 1024 Oct 8 00:00 ../
b--xr-Sr-x 1 26473 25975 106, 10 Mar 25 1995 #24658
br-xrwSrwx 1 28263 24954 109, 111 May 9 20:07 #24660
br-srwS-wT 1 25975 25199 101, 109 Feb 28 1996 #24664
b--sr-Sr-x 1 12396 27749 116, 110 Dec 8 2000 #24684
b--sr-s--t 1 29743 12602 108, 101 Mar 3 1996 #24685
br-srwSr-T 1 14958 29811 119, 97 Mar 17 1995 #24699
br-sr-s--- 1 28257 25449 105, 109 Dec 26 2026 #24715
br-xrw-r-T 1 26739 12594 104, 108 Aug 15 1995 #24717
br-xr-s--x 1 27491 25961 111, 99 Sep 1 2021 #24719
.
.
.
br-S--s-w- 1 28001 24909 47, 101 Oct 23 1998 #26620
br-xrwSr-- 1 28704 29548 115, 119 Dec 4 2023 #411987
br-srwS-wT 1 29287 26478 101, 112 Jul 19 1975 #411991
br-xr-xrwx 1 29548 25441 32, 110 Aug 20 2021 #411992
c--xrw-r-- 1 26223 26479 32, 32 Jan 14 2026 #411994
c--xr-xrw- 1 27507 8265 65, 32 Jan 29 2029 #411996
c--xr--r-- 1 25970 25970 101, 82 Oct 19 2021 #411997
b--sr-s--x 1 29801 11886 116, 105 Jan 29 2029 #411999
.
.
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/