Re: Possible regression in wm(4)?

[Bert Kiers <kiers%original.xs4all.nl@localhost>]

On Tue, Nov 14, 2017 at 08:07:46PM +0900, Kengo NAKAHARA wrote:
> Hi,

Hi,

> I'm sorry I cannot solve it...
> Hmm, now I think this problem may relate to MSI/MSI-X interrupts
> setting about ioapic. If it is not a problem, could you try the
> following patch?
> I believe this patch let wm(4) do the same behavior as NetBSD-7,
> that is, wm(4) uses INTx interrupt instead of MSI/MSI-X interrupt.
> 
> ====================
> --- a/sys/dev/pci/if_wm.c
> +++ b/sys/dev/pci/if_wm.c
> @@ -174,10 +174,10 @@ int	wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | WM_DEBUG_LINK | WM_DEBUG_GMII
>  #define WM_MAX_NINTR		(WM_MAX_NQUEUEINTR + 1)
>  
>  #ifndef WM_DISABLE_MSI
> -#define	WM_DISABLE_MSI 0
> +#define	WM_DISABLE_MSI 1
>  #endif
>  #ifndef WM_DISABLE_MSIX
> -#define	WM_DISABLE_MSIX 0
> +#define	WM_DISABLE_MSIX 1
>  #endif
>  
>  int wm_disable_msi = WM_DISABLE_MSI;
> ====================

That still does not work.  The NIC probes as

yvresse# grep ^wm1 dmesg.netbsd8wmfixC
wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
wm1: interrupting at ioapic1 pin 16
wm1: PCI-Express bus
wm1: 16384 words (16 address bits) SPI EEPROM, version 1.43, Image Unique ID e6060000
wm1: Ethernet address 00:30:48:9e:a9:2f
wm1: Copper
wm1: 0x74440<SPI,IOH_VALID,PCIE,NEWQUEUE,ASF_FIRM,ARC_SUBSYS>

But still no traffic.

I have two wm(4) cards with different chips.  I'll put them in the
machine tomorrow and see what happens.

Btw, this is the only device that tries to use MSI(X) in this box.

Two devices use ioapic pin 16:

wm1: interrupting at ioapic1 pin 16
uhci0: interrupting at ioapic0 pin 16

and systat vmstat shows between 0 and 10 interrupts per second there on
that pin

Grtnx,
-- 
B*E*R*T