NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: port-i386/57197: GENERIC kernel crash on pentium-III and earlier CPUs
The following reply was made to PR port-i386/57197; it has been noted by GNATS.
From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
netbsd-bugs%netbsd.org@localhost
Subject: re: port-i386/57197: GENERIC kernel crash on pentium-III and earlier CPUs
Date: Tue, 24 Jan 2023 19:47:47 +1100
> [ 1.0000030] cpu0: Intel 686-class, 936MHz, id 0x68a
> [ 1.0000030] cpu0: node 0, package 0, core 0, smt 0
> [...]
> [ 30.4197804] fatal page fault in supervisor mode
> [ 30.4197804] trap type 6 code 0 eip 0xc0617718 cs 0x8 eflags 0x10246 c=
r2
can you provide a little more of the dmesg above the 'fatal page fault'
for all instances? ie, what was the previous message / what was going
on the system right now.
some of the fault in the interrupt handler, but some are faulting when
an interrupt is being established.
> intr_biglock_wrapper(c186be80,d7c92f10,0,0,0,0,0,0,0,0) at netbsd:intr_b=
iglock_wrapper+0x68
> --- switch to interrupt stack ---
> Xintr_legacy5() at netbsd:Xintr_legacy5+0xda
> --- interrupt ---
> x86_stihlt(c16ac040,0,c0637e70,0,0,c168f100,c0a10100,c168f100,d7c90000,c=
168f100) at netbsd:x86_stihlt+0x5
> idle_loop(c16ac040,cbb000,cc4000,0,c01005a8,0,0,0,0,0) at netbsd:idle_lo=
op+0x153
panicked after taking an interrupt.
> hardclock(0,0,c57bff6c,c04ac8f1,0,0,0,0,0,0) at netbsd:hardclock+0x23
> clockintr(0,0,0,0,0,0,0,0,c1c72000,c010322a) at netbsd:clockintr+0x2a
> intr_kdtrace_wrapper(c1c33b80,c19f5d9c,0,0,0,0,0,0,0,0) at netbsd:intr_k=
dtrace_wrapper+0x21
> --- switch to interrupt stack ---
> Xintr_legacy0() at netbsd:Xintr_legacy0+0xda
> --- interrupt ---
> outb(c16260c0,c1623f80,0,20,1,0,0,c16c5a80,c19f5e94,0) at netbsd:outb+0x=
9
> intr_establish_xname(0,c16260c0,0,1,7,c04c96b5,0,0,c134f916,0) at netbsd=
:intr_establish_xname+0x2ba
this time, taking an interrupt while setting one up.
> Xintr_legacy0() at netbsd:Xintr_legacy0+0xda
> --- interrupt ---
> outb(c0955480,c0953540,0,20,1,0,0,c099ffc0,c0bfbe94,0) at netbsd:outb+0x=
9
> intr_establish_xname(0,c0955480,0,1,7,c0248305,0,0,c0813d2b,0) at netbsd=
:intr_establish_xname+0x2ba
as above.
i can't tell where the "outb" call in intr_establish_xname() comes
from. in my GENERIC, this ends being:
0xc04b0acd <+693>: call 0xc0f86a47 <__x86_indirect_thunk_eax>
>> 0xc04b0ad2 <+698>: mov %fs:0x304,%edx
0xc04b0ad9 <+705>: mov -0x5c(%ebp),%eax
0xc04b0adc <+708>: cmp %edx,%eax
0xc04b0ade <+710>: je 0xc04b0aed <intr_establish_xname+725>
is intr_establish_xname+0x2ba(). this is x86_curcpu() it seems:
(gdb) l *(intr_establish_xname+0x2ba)
0xc04b0ad2 is in intr_establish_xname (./machine/cpu.h:53).
48 __inline __always_inline static struct cpu_info * __unused
...
53 __asm volatile("movl %%fs:%1, %0" :
54 "=3Dr" (ci) :
55 "m"
56 (*(struct cpu_info * const *)offsetof(struct cpu_info,=
ci_self)));
this turns to for me to be here:
(gdb) l *(intr_establish_xname+708)
...
969 /* All set up, so add a route for the interrupt and unmask=
it. */
970 (*pic->pic_addroute)(pic, ci, pin, idt_vec, type);
971 if (ci =3D=3D curcpu() || !mp_online) {
972 intr_hwunmask_xcall(ih, NULL);
John, can you check your netbsd.gdb and see if you can confirm the
same addresses, or point out where yours are?
Home |
Main Index |
Thread Index |
Old Index