kernel oops (__vma_link_list) in linux-image-3.2.0-0.bpo.1-686-pae
I have been having intermittent lockups on my debian server running
kernel linux-image-3.2.0-0.bpo.1-686-pae on a squeeze system from
squeeze-backports. The hardware is a Dell Dimension 4600i with an intel
P4 processor. This time, I was logged in when it happened, and got this
from syslog and the log file:
[544120.565484] BUG: unable to handle kernel paging request at c10ba550
[544120.566595] IP: [<c10ad661>] __vma_link_list+0x25/0x2d
[544120.567685] *pdpt = 0000000001491001 *pde = 00000000010001e1
[544120.568008] Oops: 0003 [#1] SMP
[544120.568008] Modules linked in: btrfs zlib_defla
te crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs reise
rfs ext4 jbd2 crc16 tun binfmt_misc ipt_REJECT ipt_LOG xt_state xt_tcpudp iptabl
e_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf
_defrag_ipv4 tulip ext2 loop fuse tcp_diag inet_diag processor tpm_tis tpm tpm_b
ios i915 drm_kms_helper drm i2c_i801 i2c_algo_bit video i2c_core dcdbas thermal_
sys psmouse rng_core button shpchp pci_hotplug serio_raw evdev pcspkr ext3 jbd m
bcache dm_mod sg sr_mod sd_mod cdrom crc_t10dif usbhid hid ata_generic uhci_hcd
ata_piix libata ehci_hcd usbcore floppy scsi_mod 3c59x mii usb_common [last unlo
aded: scsi_wait_scan]
[544120.568008]
[544120.568008] Pid: 28178, comm: smtpd Not tainted 3.2.0-0.bpo.1-686-pae #1 Dell Computer Corporation Dimension 4600i/0F4491
[544120.568008] EIP: 0060:[<c10ad661>] EFLAGS: 00210282 CPU: 0
[544120.568008] EIP is at __vma_link_list+0x25/0x2d
[544120.568008] EAX: c10ba540 EBX: c10ba560 ECX: 00000000 EDX: f3a5a4f0
[544120.568008] ESI: f0d66380 EDI: f3a5a4f0 EBP: c10ba560 ESP: c0731f24
[544120.568008] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[544120.568008] Process smtpd (pid: 28178, ti=c0730000 task=f063a660 task.ti=c0730000)
[544120.568008] Stack:
[544120.568008] f44bf38c c10b91ad c10ba560 00000000 f3a5a4f0 f0c4ac80 b7253000 08000075
[544120.568008] c10ba5af f3a5ad58 c10ba560 f0d66380 00000000 00000000 0000000a 0000a000
[544120.568008] f44bf2c4 f3a5ad58 00000000 b725d000 f3a5ad50 f0c4ac80 f063a660 00009238
[544120.568008] Call Trace:
[544120.568008] [<c10b91ad>] ? vma_link+0x3a/0x66
[544120.568008] [<c10ba560>] ? mmap_region+0x2da/0x432
[544120.568008] [<c10ba5af>] ? mmap_region+0x329/0x432
[544120.568008] [<c10ba560>] ? mmap_region+0x2da/0x432
[544120.568008] [<c10baa43>] ? sys_mmap_pgoff+0xe3/0x11b
[544120.568008] [<c12cd844>] ? syscall_call+0x7/0xb
[544120.568008] Code: fe ff ff 5b 5e c3 85 c9 53 8b 5c 24 08 89 4a 10 74 08 8b 41 0c 89 51 0c eb 0a 89 10 85 db 8d 43 e0 0f 44 c1 85 c0 89 42 0c 74 03 <89> 50 10 5b c3 31 c0 c3 56 83 e9 14 53 8b 98 c0 20 00 00 0f b7
[544120.568008] EIP: [<c10ad661>] __vma_link_list+0x25/0x2d SS:ESP 0068:c0731f24
[544120.568008] CR2: 00000000c10ba550
[544120.637436] ---[ end trace 7ce99a0ba99e3373 ]---
Take everything I say after this point with a grain of salt, as I'm
not a kernel guru and I'm trying to do my best here, but may be way off:
Using the "Code" included in the oops, I got the following disassemble:
Dump of assembler code for function str:
0x08049580 <str+0>: (bad)
0x08049581 <str+1>: (bad)
0x08049582 <str+2>: lcall *0x5e(%ebx)
0x08049585 <str+5>: ret
0x08049586 <str+6>: test %ecx,%ecx
0x08049588 <str+8>: push %ebx
0x08049589 <str+9>: mov 0x8(%esp),%ebx
0x0804958d <str+13>: mov %ecx,0x10(%edx)
0x08049590 <str+16>: je 0x804959a <str+26>
0x08049592 <str+18>: mov 0xc(%ecx),%eax
0x08049595 <str+21>: mov %edx,0xc(%ecx)
0x08049598 <str+24>: jmp 0x80495a4 <str+36>
0x0804959a <str+26>: mov %edx,(%eax)
0x0804959c <str+28>: test %ebx,%ebx
0x0804959e <str+30>: lea -0x20(%ebx),%eax
0x080495a1 <str+33>: cmove %ecx,%eax
0x080495a4 <str+36>: test %eax,%eax
0x080495a6 <str+38>: mov %eax,0xc(%edx)
0x080495a9 <str+41>: je 0x80495ae <str+46>
0x080495ab <str+43>: mov %edx,0x10(%eax)
0x080495ae <str+46>: pop %ebx
0x080495af <str+47>: ret
0x080495b0 <str+48>: xor %eax,%eax
0x080495b2 <str+50>: ret
0x080495b3 <str+51>: push %esi
0x080495b4 <str+52>: sub $0x14,%ecx
0x080495b7 <str+55>: push %ebx
0x080495b8 <str+56>: mov 0x20c0(%eax),%ebx
0x080495be <str+62>: movzwl (%eax),%eax
End of assembler dump.
If I understand this (and the output of make mm/util.s) correctly,
this implicates a problem in mm/util.c at line 237 (vma->vm_next = next),
but I don't know what to do about it. This is as far as I could go.
If anyone has any ideas on this, I'd love to hear them.
--
Alan Schwartz
Professor and Associate Head, UIC Department of Medical Education
Research Professor, UIC Department of Pediatrics
alansz@uic.edu | http://araw.mede.uic.edu/alansz | PGP: 0x062556CF
Reply to: