Re: Possible regression in wm(4)?

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

Hi,

On 2017/11/14 19:33, Bert Kiers wrote:
> On Tue, Nov 14, 2017 at 12:34:40PM +0900, Kengo NAKAHARA wrote:
> 
> I am sorry to have to say they both do not fix the problem.
> 
>> ========== (A) ==========
>> --- a/sys/dev/pci/if_wm.c
>> +++ b/sys/dev/pci/if_wm.c
>> @@ -4883,8 +4883,8 @@ wm_adjust_qnum(struct wm_softc *sc, int nvectors)
>>  		hw_nrxqueues = 4;
>>  		break;
>>  	case WM_T_82576:
>> -		hw_ntxqueues = 16;
>> -		hw_nrxqueues = 16;
>> +		hw_ntxqueues = 1;
>> +		hw_nrxqueues = 1;
>>  		break;
>>  	case WM_T_82580:
>>  	case WM_T_I350:
>> ========== (A) ==========
> 
> With this patch, it probes as
> 
> yvresse# cat dmesg.netbsd8wmfixA|grep wm1
> wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
> wm1: for TX and RX interrupting at msix1 vec 0 affinity to 1
> wm1: for LINK interrupting at msix1 vec 1
> 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>
> igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1
> 
> but there is no incoming traffic
>  
>> ========== (B) ==========
>> --- a/sys/dev/pci/if_wm.c
>> +++ b/sys/dev/pci/if_wm.c
>> @@ -177,7 +177,7 @@ int	wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | WM_DEBUG_LINK | WM_DEBUG_GMII
>>  #define	WM_DISABLE_MSI 0
>>  #endif
>>  #ifndef WM_DISABLE_MSIX
>> -#define	WM_DISABLE_MSIX 0
>> +#define	WM_DISABLE_MSIX 1
>>  #endif
>>  
>>  int wm_disable_msi = WM_DISABLE_MSI;
>> ========== (B) ==========
> 
> With this one,
> 
> yvresse# cat dmesg.netbsd8wmfixB|grep wm1
> wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01)
> wm1: interrupting at msi1 vec 0
> 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>
> igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1
> 
> and also no traffic

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;
====================


Thanks,

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

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

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