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