Re: kern/52111: wmX i82574L inoperative in monoprocessor mode (i386)

[Frank Kardel <kardel%netbsd.org@localhost>]

The following reply was made to PR kern/52111; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>, gnats-bugs%NetBSD.org@localhost, 
 kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/52111: wmX i82574L inoperative in monoprocessor mode (i386)
Date: Wed, 29 Mar 2017 08:02:05 +0200

 As for the panic in the boot -1 case the
 panic of "intrctl list" occurred in:
 
 sys/arch/x86/x86/intr.c:
 
 static bool
 intr_is_affinity_intrsource(struct intrsource *isp, const kcpuset_t 
 *cpuset)
 {
          struct cpu_info *ci;
 
          KASSERT(mutex_owned(&cpu_lock));
 
  >>>       ci = isp->is_handlers->ih_cpu;
          KASSERT(ci != NULL);
 
          return kcpuset_isset(cpuset, cpu_index(ci));
 }
 
 due to is_handlers == NULL. The whole struct intrsource seems to be 
 zeroed except fir is_intrid, but
 correctly linked.
 
 Value of the intrsource is:
 (gdb) print *isp
 $2 = {is_maxlevel = 0, is_pin = 0, is_handlers = 0x0, is_pic = 0x0, 
 is_recurse = 0x0, is_resume = 0x0, is_lwp = 0x0, is_evcnt = {ev_count = 
 0, ev_list = {tqe_next = 0x0, tqe_prev = 0x0}, ev_type = 0 '\000', 
 ev_grouplen = 0 '\000',
      ev_namelen = 0 '\000', ev_pad1 = 0 '\000', ev_parent = 0x0, 
 ev_group = 0x0, ev_name = 0x0}, is_flags = 0, is_type = 0, is_idtvec = 
 0, is_minlevel = 0, is_evname = '\000' <repeats 31 times>,
    is_intrid = "irq 9", '\000' <repeats 58 times>, is_xname = '\000' 
 <repeats 255 times>, is_active_cpu = 0, is_saved_evcnt = 0xc3423ba8, 
 is_list = {sqe_next = 0xc3a40e08}}
 (gdb)
 
 Frank
 
 On 03/29/17 05:58, Kengo NAKAHARA wrote:
 > Hi,
 >
 > On 2017/03/28 20:20, Frank Kardel wrote:
 >> From: Frank Kardel <kardel%kardel.name@localhost>
 >>   Further results
 >>   intrctl list MP case (wm interface work):
 >>   Gateway# intrctl list
 >>   interrupt id     CPU0  CPU1  device name(s)
 >>   ioapic0 pin 19   4602*    0  unknown, unknown, unknown, ehci0, unknown,
 >>   unknown, unknown, unknown
 >>   ioapic0 pin 18      0*    0  unknown, unknown
 >>   ioapic0 pin 17 108394*    0  ahcisata0
 >>   ioapic0 pin 16      0*    0  unknown, unknown, unknown, ehci1
 >>   msix0 vec 0     12822*    0  wm0TXRX0
 >>   msix0 vec 1         0  9517* wm0TXRX1
 >>   msix0 vec 2         0*    0  wm0LINK
 >>   msix1 vec 0       827*    0  wm1TXRX0
 >>   msix1 vec 1         0   568* wm1TXRX1
 >>   msix1 vec 2         1*    0  wm1LINK
 >>   msix2 vec 0       559*    0  wm2TXRX0
 >>   msix2 vec 1         0   103* wm2TXRX1
 >>   msix2 vec 2         1*    0  wm2LINK
 >>   msix3 vec 0      4045*    0  wm3TXRX0
 >>   msix3 vec 1         0  2178* wm3TXRX1
 >>   msix3 vec 2         2*    0  wm3LINK
 >>   ioapic0 pin 4    1459*    0  com0
 >>   
 >>   intrctl list in boot -1 case (wm interface don't work)
 >>   interrupt id  CPU0  device name(s)
 >>   pic0 pin 9    2337* unknown, unknown, unknown, ehci0, unknown, unknown,
 >>   unknown, unknown
 >>   pic0 pin 5       0* unknown, unknown
 >>   pic0 pin 11  11421* ahcisata0
 >>   pic0 pin 10      0* unknown, unknown, unknown, ehci1
 >>   msix0 vec 0      0* wm0TXRX0
 >>   msix0 vec 1      0* wm0LINK
 >>   msix1 vec 0      0* wm1TXRX0
 >>   msix1 vec 1      0* wm1LINK
 >>   msix2 vec 0      0* wm2TXRX0
 >>   msix2 vec 1      0* wm2LINK
 >>   msix3 vec 0      0* wm3TXRX0
 >>   msix3 vec 1      0* wm3LINK
 >>   pic0 pin 4    3112* com0
 >>   pic0 pin 0   22874* unknown
 >>   
 >>   boot -1 with your patch - interfaces work, intrctl list causes panic: trap:
 >>   #0  0xc011423e in maybe_dump (howto=260) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/arch/i386/i386/machdep.c:708
 >>   #1  cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/arch/i386/i386/machdep.c:729
 >>   #2  0xc09353c0 in vpanic (fmt=fmt@entry=0xc0cd7a92 "trap",
 >>   ap=ap@entry=0xdc3fbc28 "��?Ü ï¿½?�\001") at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/kern/subr_prf.c:342
 >>   #3  0xc093544a in panic (fmt=fmt@entry=0xc0cd7a92 "trap") at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/kern/subr_prf.c:258
 >>   #4  0xc0116a92 in trap (frame=0xdc3fbca0) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/arch/i386/i386/trap.c:325
 >>   #5  0xc010d4af in alltraps ()
 >>   #6  0xdc3fbca0 in ?? ()
 >>   #7  0xc0145f71 in interrupt_construct_intrids (cpuset=0xc3421ec8) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/arch/x86/x86/intr.c:2199
 >>   #8  0xc0926c1f in interrupt_intrio_list_size () at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/kern/subr_interrupt.c:195
 >>   #9  interrupt_intrio_list (il=il@entry=0x0, length=length@entry=0) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/kern/subr_interrupt.c:220
 >>   #10 0xc09274b2 in interrupt_intrio_list_sysctl (name=0xdc3fbf0c,
 >>   namelen=0, oldp=0x0, oldlenp=0xdc3fbefc, newp=0x0, newlen=0,
 >>   oname=0xdc3fbf00, l=0xc3cd27e0, rnode=0xc343480c)
 >>        at /fs/raid2a/src/NetBSD/act/src/sys/kern/subr_interrupt.c:312
 >>   #11 0xc090fbcc in sysctl_dispatch (name=name@entry=0xdc3fbf00,
 >>   namelen=3, oldp=0x0, oldlenp=oldlenp@entry=0xdc3fbefc, newp=0x0,
 >>   newlen=0, oname=oname@entry=0xdc3fbf00, l=l@entry=0xc3cd27e0,
 >>   rnode=0xc343480c, rnode@entry=0x0)
 >>        at /fs/raid2a/src/NetBSD/act/src/sys/kern/kern_sysctl.c:454
 >>   #12 0xc090fe19 in sys___sysctl (l=0xc3cd27e0, uap=0xdc3fbf68,
 >>   retval=0xdc3fbf60) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/kern/kern_sysctl.c:310
 >>   #13 0xc015059b in sy_call (rval=0xdc3fbf60, uap=0xdc3fbf68,
 >>   l=0xc3cd27e0, sy=0xc0f5f348 <sysent+4040>) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/sys/syscallvar.h:65
 >>   #14 sy_invoke (code=202, rval=0xdc3fbf60, uap=0xdc3fbf68, l=0xc3cd27e0,
 >>   sy=0xc0f5f348 <sysent+4040>) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/sys/syscallvar.h:94
 >>   #15 syscall (frame=0xdc3fbfa8) at
 >>   /fs/raid2a/src/NetBSD/act/src/sys/arch/x86/x86/syscall.c:156
 >>   #16 0xc01006b6 in Xsyscall ()
 >>   #17 0xdc3fbfa8 in ?? ()
 > Hmm..., I think it may be the reason of this panic that wm(4) use
 > shared IRQ of legacy apic. When boot normally, "ahcisata0"'s
 > interrupt id is "ioapic0 pin 17". In contrast, when boot -1,
 > "ahcisata0"'s interrupt id is "pic0 pin 11" that means legacy apic.
 > For comparison, my reproduction environment does not use legacy
 > apic even if boot -1. It seems this difference is the reason of
 > whether reproduce of not.
 >
 >>   So the good news is - boot -1 gives working wm interfaces with the
 >>   workaround. intrctl list is a panic trigger though,
 > Oh, I am glad to hear the news. :)
 > I'm sorry to say please don't use intrctl list when boot -1...
 > I will research intrctl list panic in more detail.
 >
 >
 > Thanks,
 >