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

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

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,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>