Bug#377062: Oops (NULL pointer dereference) on linux-image-2.6.17-1-amd64-k8
hello vitaliy:
On Thu, 06 Jul 2006, Vitaliy Batichko wrote:
> Package: linux-image-2.6.17-1-amd64-k8
> Version: 2.6.17-2
> Severity: normal
>
>
> Ksymoops output below:
>
> Unable to handle kernel NULL pointer dereference at 0000000000000080 RIP:
> <ffffffff8021464b>{__page_set_anon_rmap+0}
> Oops: 0000 [1]
> CPU 0
> Pid: 21650, comm: abiword Not tainted 2.6.17-1-amd64-k8 #1
> RIP: 0010:[<ffffffff8021464b>] <ffffffff8021464b>{__page_set_anon_rmap+0}
> Using defaults from ksymoops -t elf64-x86-64 -a i386:x86-64
> RSP: 0000:ffff810027ad9df0 EFLAGS: 00010297
> RAX: 0000000000000004 RBX: 800000001b4f0067 RCX: ffff810000000000
> RDX: 0000000003e20008 RSI: 0000000000000000 RDI: ffff8100015f9480
> RBP: ffff8100015f9480 R08: 0000000000000000 R09: 0000000000007b64
> R10: 0000000000000000 R11: 0000000000000001 R12: ffff810009117ad8
> R13: ffff81002371b100 R14: 0000000003e20008 R15: ffff81003f2e1b80
> FS: 00002b4f53603100(0000) GS:ffffffff804cc000(0000) knlGS:00000000f72b09d0
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000080 CR3: 000000000e7f6000 CR4: 00000000000006e0
> ffff81003b2ca0f8 0000000000000000 0000000300000007 0000000400000001
> 0000000800000001 0000000c00000003
> Call Trace: <ffffffff80208298>{__handle_mm_fault+562}
> <ffffffff8020a0c4>{do_page_fault+1082} <ffffffff802247fe>{do_brk+452}
> <ffffffff803a5328>{unix_ioctl+173} <ffffffff8035e056>{sock_ioctl+449}
> <ffffffff80252611>{error_exit+0}
> Code: 48 8b 86 80 00 00 00 48 85 c0 75 0a 0f 0b 68 fa 0d 3d 80 c2
>
>
> >>RIP; ffffffff8021464b <__page_set_anon_rmap+0/3f> <=====
>
> >>RBX; 800000001b4f0067 <phys_startup_64+800000001b2eff67/ffffffff7fffff00>
> >>RCX; ffff810000000000 <phys_startup_64+ffff80ffffdfff00/ffffffff7fffff00>
> >>RDX; 0000000003e20008 <phys_startup_64+3c1ff08/ffffffff7fffff00>
> >>RDI; ffff8100015f9480 <phys_startup_64+ffff8100013f9380/ffffffff7fffff00>
> >>RBP; ffff8100015f9480 <phys_startup_64+ffff8100013f9380/ffffffff7fffff00>
> >>R12; ffff810009117ad8 <phys_startup_64+ffff810008f179d8/ffffffff7fffff00>
> >>R13; ffff81002371b100 <phys_startup_64+ffff81002351b000/ffffffff7fffff00>
> >>R14; 0000000003e20008 <phys_startup_64+3c1ff08/ffffffff7fffff00>
> >>R15; ffff81003f2e1b80 <phys_startup_64+ffff81003f0e1a80/ffffffff7fffff00>
>
> Trace; ffffffff80208298 <__handle_mm_fault+232/843>
> Trace; ffffffff8020a0c4 <do_page_fault+43a/7b5>
> Trace; ffffffff803a5328 <unix_ioctl+ad/b4>
> Trace; ffffffff80252611 <error_exit+0/84>
>
> Code; ffffffff8021464b <__page_set_anon_rmap+0/3f>
> 0000000000000000 <_RIP>:
> Code; ffffffff8021464b <__page_set_anon_rmap+0/3f> <=====
> 0: 48 8b 86 80 00 00 00 mov 0x80(%rsi),%rax <=====
> Code; ffffffff80214652 <__page_set_anon_rmap+7/3f>
> 7: 48 85 c0 test %rax,%rax
> Code; ffffffff80214655 <__page_set_anon_rmap+a/3f>
> a: 75 0a jne 16 <_RIP+0x16>
> Code; ffffffff80214657 <__page_set_anon_rmap+c/3f>
> c: 0f 0b ud2a
> Code; ffffffff80214659 <__page_set_anon_rmap+e/3f>
> e: 68 fa 0d 3d 80 pushq $0xffffffff803d0dfa
> Code; ffffffff8021465e <__page_set_anon_rmap+13/3f>
> 13: c2 00 00 retq $0x0
>
> CR2: 0000000000000080
>
is that reproducible?
does that box survive a _long_ memtest run?
regards
--
maks
Reply to: