2.4 kernels - "attempt to access beyond end of device"

Michal Jaegermann (michal@harddata.com)
Mon, 26 Feb 2001 19:10:09 -0700


I have right now on hands a system with PDC20265 controller, not used
as "raid", and it gives me a hard time. It looks like that after some
number of megabytes copied to a disk, where "number" seems to be
somewhere between 100 and 150, something in a kernel internal structures
get overwritten and the whole thing just blows up. After an oops mostly
anything will end up with errors so even a clean reboot will likely
be not possible.

In particular this prevents me from installing the recent Red Hat public
beta with its kernel based on 2.4.1. I tried also some other variants
of 2.4 kernels and so far results are the same. If there is something
left in logs then I see messages of that sort (21:01 is /dev/hde1).

21:01: rw=0, want=536992869, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992870, limit=4506201
attempt to access beyond end of device

The following log file is for 2.4.2-ac5. It has less extraneous
stuff like LVM, and RAID, and USB support, and whatever...
These were effects of an attempt to copy from one vfat to another
vfat file system. Below is also decoded oops.

Linux version 2.4.2-ac5 (root@smok.home.front) (gcc version 2.96 20000731 (Red Hat Linux 7.0)) #4 Mon Feb 26 18:11:13 MST 2001
BIOS-provided physical RAM map:
BIOS-e820: 000000000009dc00 @ 0000000000000000 (usable)
BIOS-e820: 0000000000002400 @ 000000000009dc00 (reserved)
BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
BIOS-e820: 000000001feec000 @ 0000000000100000 (usable)
BIOS-e820: 0000000000003000 @ 000000001ffec000 (ACPI data)
BIOS-e820: 0000000000010000 @ 000000001ffef000 (reserved)
BIOS-e820: 0000000000001000 @ 000000001ffff000 (ACPI NVS)
BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
On node 0 totalpages: 131052
zone(0): 4096 pages.
zone(1): 126956 pages.
zone(2): 0 pages.
Kernel command line: initrd=initrd.img root=/dev/hdg3 BOOT_IMAGE=vmlinuz auto
Initializing CPU#0
Detected 1109.899 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2215.11 BogoMIPS
Memory: 513140k/524208k available (920k kernel code, 10672k reserved, 351k data, 176k init, 0k highmem)
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:04.0
PCI: Found IRQ 9 for device 00:09.0
PCI: The same IRQ used for device 00:04.2
PCI: The same IRQ used for device 00:04.3
PCI: The same IRQ used for device 00:0d.0
PCI: Found IRQ 11 for device 00:0c.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 341080kB/210008kB, 1024 slots per queue
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1
ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:pio, hdd:pio
PDC20265: IDE controller on PCI bus 00 dev 88
PCI: Found IRQ 10 for device 00:11.0
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x6800-0x6807, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0x6808-0x680f, BIOS settings: hdg:DMA, hdh:pio
hda: CREATIVE CD5233E, ATAPI CD/DVD-ROM drive
hde: IBM-DTLA-307045, ATA DISK drive
hdg: IBM-DTLA-307045, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0x8000-0x8007,0x7802 on irq 10
ide3 at 0x7400-0x7407,0x7002 on irq 10
hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100)
hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100)
hda: ATAPI 52X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
hde: [PTBL] [5606/255/63] hde1
hdg: [PTBL] [5606/255/63] hdg1 hdg2 hdg3 hdg4 < hdg5 hdg6 hdg7 hdg8 hdg9 hdg10 hdg11 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 279k freed
loop: loaded (max 8 devices)
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem).
ncr53c8xx: at PCI bus 0, device 10, function 0
ncr53c8xx: 53c810 detected
ncr53c810-0: rev 0x2 on pci bus 0 device 10 function 0 irq 5
ncr53c810-0: ID 7, Fast-10, Parity Checking
ncr53c810-0: restart (scsi reset).
scsi0 : ncr53c8xx - version 3.3b
Vendor: FUJITSU Model: M2952S-512 Rev: 0122
Type: Direct-Access ANSI SCSI revision: 02
Vendor: DEC Model: DSP3210S Rev: X442
Type: Direct-Access ANSI SCSI revision: 02
ncr53c810-0-<2,0>: tagged command queue depth set to 8
ncr53c810-0-<4,0>: tagged command queue depth set to 8
Attached scsi disk sda at scsi0, channel 0, id 2, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 4, lun 0
ncr53c810-0-<2,0>: sync_msgout: 1-3-1-19-8.
ncr53c810-0-<2,0>: sync msgin: 1-3-1-19-8.
ncr53c810-0-<2,0>: sync: per=25 scntl3=0x10 ofs=8 fak=0 chg=0.
ncr53c810-0-<2,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8)
SCSI device sda: 4693462 512-byte hdwr sectors (2403 MB)
sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
ncr53c810-0-<4,0>: sync_msgout: 1-3-1-19-8.
ncr53c810-0-<4,0>: sync msgin: 1-3-1-19-8.
ncr53c810-0-<4,0>: sync: per=25 scntl3=0x10 ofs=8 fak=0 chg=0.
ncr53c810-0-<4,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8)
SCSI device sdb: 4197520 512-byte hdwr sectors (2149 MB)
sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 >
via-rhine.c:v1.08b-LK1.1.7 8/9/2000 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
PCI: Enabling device 00:09.0 (0094 -> 0097)
PCI: Found IRQ 9 for device 00:09.0
PCI: The same IRQ used for device 00:04.2
PCI: The same IRQ used for device 00:04.3
PCI: The same IRQ used for device 00:0d.0
eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 9.
eth0: MII PHY found at address 8, status 0x7809 advertising 05e1 Link 0000.
PCI: Enabling device 00:0c.0 (0094 -> 0097)
PCI: Found IRQ 11 for device 00:0c.0
eth1: VIA VT3043 Rhine at 0x8800, 00:50:ba:ab:60:64, IRQ 11.
eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link 0000.
VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=3
Trying to unmount old root ... okay
Freeing unused kernel memory: 176k freed
Adding Swap: 136512k swap-space (priority -1)
Filesystem panic (dev 22:02).
fat_free: deleting beyond EOF
File system has been set read-only
attempt to access beyond end of device
21:01: rw=0, want=536992869, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992870, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992870, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992871, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992871, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992872, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992872, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992873, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992869, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992870, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992870, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992871, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992871, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992872, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992872, limit=4506201
attempt to access beyond end of device
21:01: rw=0, want=536992873, limit=4506201
Unable to handle kernel paging request at virtual address 08000004
printing eip:
c0130fbe
*pde = 0b120067
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0130fbe>]
EFLAGS: 00010206
eax: c18a0000 ebx: 00006b93 ecx: 00000003 edx: 08000000
esi: 00007fff edi: 0000000f ebp: 00007562 esp: debe9e14
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 586, stackpage=debe9000)
Stack: 2202cd48 00000000 00000200 c13ecd48 00000000 c0131e36 00002202 00007562
00000200 c13ecd48 00000000 c0132177 ceeb6640 00000000 c0132198 ceed7de0
ceed7de0 cec6e000 debe9e6c 00000200 00000008 ceed7de0 00000002 00011ead
Call Trace: [<c0131e36>] [<c0132177>] [<c0132198>] [<c012a85e>] [<c013179f>] [<c0132860>] [<c015a4f0>]
[<c015bf45>] [<c015a4f0>] [<c0124ddc>] [<c015a641>] [<c015a619>] [<c012fbd6>] [<c0108fb3>]

Code: 39 6a 04 75 f5 66 8b 42 08 25 ff ff 00 00 3b 44 24 20 75 e6

And here are results of ksymoops:

Error (pclose_local): find_objects pclose failed 0x100
Unable to handle kernel paging request at virtual address 08000004
c0130fbe
*pde = 0b120067
Oops: 0000
CPU: 0
EIP: 0010:[<c0130fbe>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: c18a0000 ebx: 00006b93 ecx: 00000003 edx: 08000000
esi: 00007fff edi: 0000000f ebp: 00007562 esp: debe9e14
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 586, stackpage=debe9000)
Stack: 2202cd48 00000000 00000200 c13ecd48 00000000 c0131e36 00002202 00007562
00000200 c13ecd48 00000000 c0132177 ceeb6640 00000000 c0132198 ceed7de0
ceed7de0 cec6e000 debe9e6c 00000200 00000008 ceed7de0 00000002 00011ead
Call Trace: [<c0131e36>] [<c0132177>] [<c0132198>] [<c012a85e>] [<c013179f>] [<c0132860>] [<c015a4f0>]
[<c015bf45>] [<c015a4f0>] [<c0124ddc>] [<c015a641>] [<c015a619>] [<c012fbd6>] [<c0108fb3>]
Code: 39 6a 04 75 f5 66 8b 42 08 25 ff ff 00 00 3b 44 24 20 75 e6

>>EIP; c0130fbe <get_hash_table+7e/b0> <=====
Trace; c0131e36 <unmap_underlying_metadata+26/70>
Trace; c0132177 <__block_prepare_write+e7/2c0>
Trace; c0132198 <__block_prepare_write+108/2c0>
Trace; c012a85e <nr_free_buffer_pages+e/60>
Trace; c013179f <balance_dirty_state+f/50>
Trace; c0132860 <cont_prepare_write+1f0/2b0>
Trace; c015a4f0 <fat_get_block+0/100>
Trace; c015bf45 <fat_prepare_write+25/30>
Trace; c015a4f0 <fat_get_block+0/100>
Trace; c0124ddc <generic_file_write+3ac/5d0>
Trace; c015a641 <default_fat_file_write+21/60>
Trace; c015a619 <fat_file_write+29/30>
Trace; c012fbd6 <sys_write+96/d0>
Trace; c0108fb3 <system_call+33/40>
Code; c0130fbe <get_hash_table+7e/b0>
00000000 <_EIP>:
Code; c0130fbe <get_hash_table+7e/b0> <=====
0: 39 6a 04 cmp %ebp,0x4(%edx) <=====
Code; c0130fc1 <get_hash_table+81/b0>
3: 75 f5 jne fffffffa <_EIP+0xfffffffa> c0130fb8 <get_hash_table+78/b0>
Code; c0130fc3 <get_hash_table+83/b0>
5: 66 8b 42 08 mov 0x8(%edx),%ax
Code; c0130fc7 <get_hash_table+87/b0>
9: 25 ff ff 00 00 and $0xffff,%eax
Code; c0130fcc <get_hash_table+8c/b0>
e: 3b 44 24 20 cmp 0x20(%esp,1),%eax
Code; c0130fd0 <get_hash_table+90/b0>
12: 75 e6 jne fffffffa <_EIP+0xfffffffa> c0130fb8 <get_hash_table+78/b0>

3 errors issued. Results may not be reliable.

Here is a similar one, from another kernel (2.4.1-0.1.9 Red Hat from
"Wolverine"), with what looks like cdrom code inside. As far as I can
tell no VFAT stuff was involved this time.

Unable to handle kernel paging request at virtual address 08000004
c0134336
*pde = 1d3a7067
Oops: 0000
CPU: 0
EIP: 0010:[<c0134336>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: c18a0000 ebx: 00000009 ecx: 000014e0 edx: 08000000
esi: 00040008 edi: 00002202 ebp: 0000000f esp: dd311e14
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 791, stackpage=dd311000)
Stack: 000014e0 00000000 00000e00 cb2b0da0 00000c00 c013517b 00002202 00040008
00000200 cb2b0da0 00000c00 c0135517 cbd54420 00000000 c0135538 cb2b0d40
cb2b0f80 cb2ac000 dd311e6c 00000200 000016ae cb2b0d40 06b60600 00001000
Call Trace: [<c013517b>] [<c0135517>] [<c0135538>] [<c0134b0c>] [<c0134b5c>] [<e086d5f0>] [<c0135cfa>]
[<e086d5f0>] [<e086efd5>] [<e086d5f0>] [<c0127ad9>] [<e086d731>] [<e086d709>] [<c0132fe6>] [<c0109007>]
Code: 39 72 04 75 f5 0f b7 42 08 3b 44 24 20 75 eb 66 39 7a 0c 75

>>EIP; c0134336 <get_hash_table+66/90> <=====
Trace; c013517b <unmap_underlying_metadata+1b/60>
Trace; c0135517 <__block_prepare_write+117/300>
Trace; c0135538 <__block_prepare_write+138/300>
Trace; c0134b0c <balance_dirty_state+c/50>
Trace; c0134b5c <balance_dirty+c/40>
Trace; e086d5f0 <[cdrom]cdrom_ioctl+ab0/e20>
Trace; c0135cfa <cont_prepare_write+22a/370>
Trace; e086d5f0 <[cdrom]cdrom_ioctl+ab0/e20>
Trace; e086efd5 <[cdrom]cdrom_sysctl_info+5a5/5d0>
Trace; e086d5f0 <[cdrom]cdrom_ioctl+ab0/e20>
Trace; c0127ad9 <generic_file_write+3a9/5f0>
Trace; e086d731 <[cdrom]cdrom_ioctl+bf1/e20>
Trace; e086d709 <[cdrom]cdrom_ioctl+bc9/e20>
Trace; c0132fe6 <sys_write+96/d0>
Trace; c0109007 <system_call+33/38>
Code; c0134336 <get_hash_table+66/90>
00000000 <_EIP>:
Code; c0134336 <get_hash_table+66/90> <=====
0: 39 72 04 cmp %esi,0x4(%edx) <=====
Code; c0134339 <get_hash_table+69/90>
3: 75 f5 jne fffffffa <_EIP+0xfffffffa> c0134330 <get_hash_table+60/90>
Code; c013433b <get_hash_table+6b/90>
5: 0f b7 42 08 movzwl 0x8(%edx),%eax
Code; c013433f <get_hash_table+6f/90>
9: 3b 44 24 20 cmp 0x20(%esp,1),%eax
Code; c0134343 <get_hash_table+73/90>
d: 75 eb jne fffffffa <_EIP+0xfffffffa> c0134330 <get_hash_table+60/90>
Code; c0134345 <get_hash_table+75/90>
f: 66 39 7a 0c cmp %di,0xc(%edx)
Code; c0134349 <get_hash_table+79/90>
13: 75 00 jne 15 <_EIP+0x15> c013434b <get_hash_table+7b/90>

Anybody with an insight to offer?

Michal
michal@harddata.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/