Re: (2.2.12) attempt to access beyond end of device
Jan Kara (jack@atrey.karlin.mff.cuni.cz)
Sat, 9 Oct 1999 23:22:16 +0200
> 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:
>
<snip>
> 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
> .
> syslog message entries ended and the machine was rebooted around 10:40.
From the messages it seems there was corrupted partition table. The
number 796095601 is '/stq' in ascii so its a bit suspitious... IMO it
is probably driver problem as if it was problem of ext2 or VFS there
would be more reports but you can be never sure...
> 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
> .
> .
> .
These entries have probably IMMUTABLE bits set. See chattr(1) for
more details.
Honza.
-
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/