Re: Possible regression in wm(4)?
Hi, On Thu, Dec 07, 2017 at 09:40:18AM +0900, Masanobu SAITOH wrote: > On 2017/12/06 22:26, Bert Kiers wrote: > >On Fri, Dec 01, 2017 at 04:40:37PM +0900, Masanobu SAITOH wrote: > >>Hi, all > >> > >>On 2017/11/22 0:21, Bert Kiers wrote: > >>>Hi, > >>> > >>>A different computer with the same type motherboard has the same > >>>problem. A quad I350 (also wm(4)) works fine (with GENERIC netbsd-8 > >>>kernel). > >>> > >>>Still wondering what queue drops are. > >>> > >>>Grtnx, > >> > >> Could you test the following diff? > > > >Yes! Works! > >Thank you! > > Thanks. The diff have been committed now and will be pulled > up to netbsd-8. I would just want to say thank you to everybody that worked on this and to those that helped test it. I got swamped at work for about a month and didn't have enough time to participate. I've just gotten to installing and testing this and I just want to say that it works for us as well. Thanks again and regards, Jimmy
Re: Possible regression in wm(4)?
Hello. That's good news. I'll second that the patch worked perfectly. -thanks -Brian On Dec 7, 9:40am, Masanobu SAITOH wrote: } Subject: Re: Possible regression in wm(4)? } On 2017/12/06 22:26, Bert Kiers wrote: } > On Fri, Dec 01, 2017 at 04:40:37PM +0900, Masanobu SAITOH wrote: } >> Hi, all } >> } >> On 2017/11/22 0:21, Bert Kiers wrote: } >>> Hi, } >>> } >>> A different computer with the same type motherboard has the same } >>> problem. A quad I350 (also wm(4)) works fine (with GENERIC netbsd-8 } >>> kernel). } >>> } >>> Still wondering what queue drops are. } >>> } >>> Grtnx, } >> } >> Could you test the following diff? } > } > Yes! Works! } > Thank you! } } Thanks. The diff have been committed now and will be pulled } up to netbsd-8. } } -- } --- } SAITOH Masanobu (msai...@execsw.org } msai...@netbsd.org) >-- End of excerpt from Masanobu SAITOH
Re: Possible regression in wm(4)?
On 2017/12/06 22:26, Bert Kiers wrote: On Fri, Dec 01, 2017 at 04:40:37PM +0900, Masanobu SAITOH wrote: Hi, all On 2017/11/22 0:21, Bert Kiers wrote: Hi, A different computer with the same type motherboard has the same problem. A quad I350 (also wm(4)) works fine (with GENERIC netbsd-8 kernel). Still wondering what queue drops are. Grtnx, Could you test the following diff? Yes! Works! Thank you! Thanks. The diff have been committed now and will be pulled up to netbsd-8. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Possible regression in wm(4)?
On Fri, Dec 01, 2017 at 04:40:37PM +0900, Masanobu SAITOH wrote: > Hi, all > > On 2017/11/22 0:21, Bert Kiers wrote: > >Hi, > > > >A different computer with the same type motherboard has the same > >problem. A quad I350 (also wm(4)) works fine (with GENERIC netbsd-8 > >kernel). > > > >Still wondering what queue drops are. > > > >Grtnx, > > Could you test the following diff? Yes! Works! Thank you! -- B*E*R*T
Re: Possible regression in wm(4)?
Hi, all
On 2017/11/22 0:21, Bert Kiers wrote:
Hi,
A different computer with the same type motherboard has the same
problem. A quad I350 (also wm(4)) works fine (with GENERIC netbsd-8
kernel).
Still wondering what queue drops are.
Grtnx,
Could you test the following diff?
---
Fix a bug that 8257[56] can't receive packet. For 82575 and 82576, the RX
descriptors must be initialized after the setting of RCTL.EN in
wm_set_filter(). This bug was added in if_wm.c rev. 1.515.
Index: if_wm.c
===
RCS file: /cvsroot/src/sys/dev/pci/if_wm.c,v
retrieving revision 1.546
diff -u -p -r1.546 if_wm.c
--- if_wm.c 30 Nov 2017 09:24:18 - 1.546
+++ if_wm.c 1 Dec 2017 07:36:26 -
@@ -5814,6 +5814,14 @@ wm_init_locked(struct ifnet *ifp)
break;
}
+ /*
+* Set the receive filter.
+*
+* For 82575 and 82576, the RX descriptors must be initialized after
+* the setting of RCTL.EN in wm_set_filter()
+*/
+ wm_set_filter(sc);
+
/* On 575 and later set RDT only if RX enabled */
if ((sc->sc_flags & WM_F_NEWQUEUE) != 0) {
int qidx;
@@ -5828,9 +5836,6 @@ wm_init_locked(struct ifnet *ifp)
}
}
- /* Set the receive filter. */
- wm_set_filter(sc);
-
wm_unset_stopping_flags(sc);
/* Start the one second link check clock. */
@@ -6688,13 +6693,13 @@ wm_init_rx_buffer(struct wm_softc *sc, s
return ENOMEM;
}
} else {
- if ((sc->sc_flags & WM_F_NEWQUEUE) == 0)
- wm_init_rxdesc(rxq, i);
/*
-* For 82575 and newer device, the RX descriptors
-* must be initialized after the setting of RCTL.EN in
+* For 82575 and 82576, the RX descriptors must be
+* initialized after the setting of RCTL.EN in
* wm_set_filter()
*/
+ if ((sc->sc_flags & WM_F_NEWQUEUE) == 0)
+ wm_init_rxdesc(rxq, i);
}
}
rxq->rxq_ptr = 0;
---
The same diff is at:
http://www.netbsd.org/~msaitoh/wm-825756-20171201-0.dif
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: Possible regression in wm(4)?
Hi, A different computer with the same type motherboard has the same problem. A quad I350 (also wm(4)) works fine (with GENERIC netbsd-8 kernel). Still wondering what queue drops are. Grtnx, -- B*E*R*T
Re: Possible regression in wm(4)?
On Wed, Nov 15, 2017 at 11:54:56AM +0100, Bert Kiers wrote: > On Wed, Nov 15, 2017 at 11:31:59AM +0900, Kengo NAKAHARA wrote: > > Hi, > > Hi, > > > > But still no traffic. > > > > Oh, the dmesg is as expected, but the behavior is not. > > Hmm, sorry, could you give me the following information? > > + "intrctl list" result on NetBSD-8 > > - before trying traffic and after it > > - full dmesg on NetBSD-8 which boot with "-xv" option > > - full dmesg on NetBSD-7 (which boot -xv if you can) > > - "acpidump -dt" result > > Most of this you can find in http://netbsd.itsx.net/kern52717/ > The n8 directory contains the output of the original NetBSD-8 > kernel, not with any of the patches. If that was not your plan, > please tell me. > > Not the intrctl output yet, since I only have NetBSD-7 userland. > Building that userland now, so that too will be there in a little > while. The ouput of intrctl list is now there. By the way, ifconfig -v shows an increasing number of queue drops. What are those? root@yvresse:~# uptime 1:44PM up 2:04, 1 user, load averages: 0.00, 0.12, 2.49 root@yvresse:~# while true ; do ifconfig -v wm1 |grep drops ; sleep 10 ; done input: 50 packets, 7200 bytes, 20062 queue drops input: 50 packets, 7200 bytes, 20079 queue drops input: 50 packets, 7200 bytes, 20101 queue drops input: 50 packets, 7200 bytes, 20111 queue drops input: 50 packets, 7200 bytes, 20136 queue drops input: 50 packets, 7200 bytes, 20165 queue drops input: 50 packets, 7200 bytes, 20192 queue drops input: 50 packets, 7200 bytes, 20201 queue drops input: 50 packets, 7200 bytes, 20219 queue drops input: 50 packets, 7200 bytes, 20235 queue drops input: 50 packets, 7200 bytes, 20246 queue drops input: 50 packets, 7200 bytes, 20252 queue drops input: 50 packets, 7200 bytes, 20273 queue drops Tcpdump -i wm1 -n does not show them. I think that is about the number of incoming packets I would expect. I double verified ipf is disabled. Grtnx, -- B*E*R*T
Re: Possible regression in wm(4)?
On Wed, Nov 15, 2017 at 11:31:59AM +0900, Kengo NAKAHARA wrote: > Hi, Hi, > > But still no traffic. > > Oh, the dmesg is as expected, but the behavior is not. > Hmm, sorry, could you give me the following information? > + "intrctl list" result on NetBSD-8 > - before trying traffic and after it > - full dmesg on NetBSD-8 which boot with "-xv" option > - full dmesg on NetBSD-7 (which boot -xv if you can) > - "acpidump -dt" result Most of this you can find in http://netbsd.itsx.net/kern52717/ The n8 directory contains the output of the original NetBSD-8 kernel, not with any of the patches. If that was not your plan, please tell me. Not the intrctl output yet, since I only have NetBSD-7 userland. Building that userland now, so that too will be there in a little while. Grtnx, -- B*E*R*T
Re: Possible regression in wm(4)?
Hi, Sorry, one more thing. On 2017/11/15 11:31, Kengo NAKAHARA wrote: > On 2017/11/14 21:53, Bert Kiers wrote: >> On Tue, Nov 14, 2017 at 08:07:46PM +0900, Kengo NAKAHARA wrote: >>> 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 >>> -#defineWM_DISABLE_MSI 0 >>> +#defineWM_DISABLE_MSI 1 >>> #endif >>> #ifndef WM_DISABLE_MSIX >>> -#defineWM_DISABLE_MSIX 0 >>> +#defineWM_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 >> e606 >> wm1: Ethernet address 00:30:48:9e:a9:2f >> wm1: Copper >> wm1: 0x74440 >> >> But still no traffic. > > Oh, the dmesg is as expected, but the behavior is not. > Hmm, sorry, could you give me the following information? > + "intrctl list" result on NetBSD-8 > - before trying traffic and after it > - full dmesg on NetBSD-8 which boot with "-xv" option > - full dmesg on NetBSD-7 (which boot -xv if you can) > - "acpidump -dt" result And - "ifconfig -v wm0" and "ifconfig -v wm1" result >> I have two wm(4) cards with different chips. I'll put them in the >> machine tomorrow and see what happens. > > I expect it will work. > >> 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 > > Yes, they use pin 16, but wm1 use ioapic1 whereas uhci0 use ioapic0. > Which ioapic's pin 16 interrupts occur? Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA
Re: Possible regression in wm(4)?
Hi, On 2017/11/14 21:53, Bert Kiers wrote: > On Tue, Nov 14, 2017 at 08:07:46PM +0900, Kengo NAKAHARA wrote: >> 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 @@ intwm_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 > e606 > wm1: Ethernet address 00:30:48:9e:a9:2f > wm1: Copper > wm1: 0x74440 > > But still no traffic. Oh, the dmesg is as expected, but the behavior is not. Hmm, sorry, could you give me the following information? + "intrctl list" result on NetBSD-8 - before trying traffic and after it - full dmesg on NetBSD-8 which boot with "-xv" option - full dmesg on NetBSD-7 (which boot -xv if you can) - "acpidump -dt" result > I have two wm(4) cards with different chips. I'll put them in the > machine tomorrow and see what happens. I expect it will work. > 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 Yes, they use pin 16, but wm1 use ioapic1 whereas uhci0 use ioapic0. Which ioapic's pin 16 interrupts occur? Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA
Re: Possible regression in wm(4)?
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 e606 wm1: Ethernet address 00:30:48:9e:a9:2f wm1: Copper wm1: 0x74440 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
Re: Possible regression in wm(4)?
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 > e606 > wm1: Ethernet address 00:30:48:9e:a9:2f > wm1: Copper > wm1: 0x74440 > 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 > e606 > wm1: Ethernet address 00:30:48:9e:a9:2f > wm1: Copper > wm1: 0x74440 > 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 -#defineWM_DISABLE_MSI 0 +#defineWM_DISABLE_MSI 1 #endif #ifndef WM_DISABLE_MSIX -#defineWM_DISABLE_MSIX 0 +#defineWM_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
Re: Possible regression in wm(4)?
On Tue, Nov 14, 2017 at 12:34:40PM +0900, Kengo NAKAHARA wrote: > Hi, Hi, 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 e606 wm1: Ethernet address 00:30:48:9e:a9:2f wm1: Copper wm1: 0x74440 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 e606 wm1: Ethernet address 00:30:48:9e:a9:2f wm1: Copper wm1: 0x74440 igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1 and also no traffic Grtnx, -- B*E*R*T
Re: Possible regression in wm(4)?
Hi, On 2017/11/11 7:23, Bert Kiers wrote: > On Fri, Nov 10, 2017 at 08:23:21PM +0100, Jimmy Johansson wrote: > > Hi, > >> Has anybody else had issues with these interfaces in NetBSD 8 or NetBSD >> current? > > yes, see kern/52717: no wm(4) networking in 8.0_BETA > also with i82576 Hmm, it seems problems related interrupts on dual socket system. Could you try the following patch(A)? If it does not work, could you try patch(B)? Patch (A) uses only two MSI-X vectors, so the all interrupts may be affinity to socket0. That can avoid the problems related dual socket system. Patch (B) uses not MSI-X but MSI. That means it almost the same behavior as NetBSD-7 or older. == (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) == == (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 #defineWM_DISABLE_MSI 0 #endif #ifndef WM_DISABLE_MSIX -#defineWM_DISABLE_MSIX 0 +#defineWM_DISABLE_MSIX 1 #endif int wm_disable_msi = WM_DISABLE_MSI; == (B) == Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA
Re: Possible regression in wm(4)?
On Fri, Nov 10, 2017 at 08:23:21PM +0100, Jimmy Johansson wrote: Hi, > Has anybody else had issues with these interfaces in NetBSD 8 or NetBSD > current? yes, see kern/52717: no wm(4) networking in 8.0_BETA also with i82576 Grtnx, -- B*E*R*T
Possible regression in wm(4)?
Hello current users! We've been trying to install both NetBSD 8 and NetBSD current on a ProLiant DL170h G6 with Intel i82576 network interfaces. Strangely we can set addresses on the interfaces, but we can't send or receive any traffic. We tried NetBSD 7 as well, where everything works as expected. Has anybody else had issues with these interfaces in NetBSD 8 or NetBSD current? Parts of respective dmesg.boot files from NetBSD 7.1, current and the whole dmesg.boot from a NetBSD current compiled today with debug enabled pasted below. Parts of dmesg from (working) NetBSD 7.1: wm0 at pci1 dev 0 function 0: 82576 1000BaseT Ethernet (rev. 0x01) wm0: interrupting at ioapic0 pin 16 wm0: PCI-Express bus wm0: 8192 words (16 address bits) SPI EEPROM, version 1.82, Image Unique ID dc12 wm0: Ethernet address 00:24:81:e1:05:8a wm0: Copper igphy0 at wm0 phy 1: i82566 10/100/1000 media interface, rev. 1 igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01) wm1: interrupting at ioapic0 pin 17 wm1: PCI-Express bus wm1: 8192 words (16 address bits) SPI EEPROM, version 1.82, Image Unique ID dc12 wm1: Ethernet address 00:24:81:e1:05:8b wm1: Copper igphy1 at wm1 phy 1: i82566 10/100/1000 media interface, rev. 1 igphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Parts of dmesg from (non-working) NetBSD current: wm0 at pci1 dev 0 function 0: 82576 1000BaseT Ethernet (rev. 0x01) wm0: for TX and RX interrupting at msix0 vec 0 affinity to 0 wm0: for TX and RX interrupting at msix0 vec 1 affinity to 1 wm0: for TX and RX interrupting at msix0 vec 2 affinity to 2 wm0: for TX and RX interrupting at msix0 vec 3 affinity to 3 wm0: for TX and RX interrupting at msix0 vec 4 affinity to 4 wm0: for TX and RX interrupting at msix0 vec 5 affinity to 5 wm0: for TX and RX interrupting at msix0 vec 6 affinity to 6 wm0: for TX and RX interrupting at msix0 vec 7 affinity to 7 wm0: for LINK interrupting at msix0 vec 8 wm0: PCI-Express bus wm0: 8192 words (16 address bits) SPI EEPROM, version 1.82, Image Unique ID dc12 wm0: Ethernet address 00:24:81:e1:05:8a wm0: Copper wm0: 0x74440 igphy0 at wm0 phy 1: i82566 10/100/1000 media interface, rev. 1 igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto wm1 at pci1 dev 0 function 1: 82576 1000BaseT Ethernet (rev. 0x01) wm1: for TX and RX interrupting at msix1 vec 0 affinity to 0 wm1: for TX and RX interrupting at msix1 vec 1 affinity to 1 wm1: for TX and RX interrupting at msix1 vec 2 affinity to 2 wm1: for TX and RX interrupting at msix1 vec 3 affinity to 3 wm1: for TX and RX interrupting at msix1 vec 4 affinity to 4 wm1: for TX and RX interrupting at msix1 vec 5 affinity to 5 wm1: for TX and RX interrupting at msix1 vec 6 affinity to 6 wm1: for TX and RX interrupting at msix1 vec 7 affinity to 7 wm1: for LINK interrupting at msix1 vec 8 wm1: PCI-Express bus wm1: 8192 words (16 address bits) SPI EEPROM, version 1.82, Image Unique ID dc12 wm1: Ethernet address 00:24:81:e1:05:8b wm1: Copper wm1: 0x74440 Full dmesg from non-working NetBSD current with degug enabled kernel: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.99.6 (GENERIC.DEBUG) #0: Fri Nov 10 15:48:21 CET 2017 root@noname:/netbsd-current/obj/sys/arch/amd64/compile/GENERIC.DEBUG total memory = 24567 MB avail memory = 23831 MB rnd: seeded with 128 bits timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 HP ProLiant DL170h G6 () mainbus0 (root) ACPI: RSDP 0x000FA3B0 24 (v02 HP) ACPI: XSDT 0xBF780100 94 (v01 HP ProLiant 20101217 FOXC 0097) ACPI: FACP 0xBF780290 F4 (v04 HP ProLiant 20101217 FOXC 0097) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/64 (20170831/tbfadt-642) ACPI: DSDT 0xBF780710 005F6B (v02 HP ProLiant 0034 INTL 20051117) ACPI: FACS 0xBF79 40 ACPI: APIC 0xBF780390 000112 (v02 HP ProLiant 20101217 FOXC 0097) ACPI: SPCR 0xBF7804B0 50 (v01 HP ProLiant 20101217 FOXC 0097) ACPI: MCFG 0xBF780500 3C (v01 HP ProLiant 20101217 FOXC 0097) ACPI: SPMI 0xBF780540 41 (v05 HP ProLiant 20101217 FOXC 0097) ACPI: OEMB 0xBF790040 7A (v01 HP ProLiant 20101217 FOXC 0097) ACPI: SRAT 0xBF786680 000150 (v02 HP ProLiant 0001 FOXC 0001) ACPI: HPET 0xBF7867D0 38 (v01 HP ProLiant 2
