Re: if_wm.c 1.410 sometimes hangs / sndq drops
On Mon, May 30, 2016 at 01:01:06PM +0900, Kengo NAKAHARA wrote: > Hi, > > I think my mistake in if_wm.c:r1.409 causes this problem. I think it is > fixed in if_wm.c:r1.411. Could you try the revision? > > I'm sorry that I don't have ethernet controllers earlier than 82575 > such as 82583. I will borrow them from msaitoh@n.o to test... 1.411 seems to work fine. Thanks, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: if_wm.c 1.410 sometimes hangs / sndq drops
Hi, On 2016/05/30 0:16, Michael van Elst wrote: > kar...@netbsd.org (Frank Kardel) writes: > >> With -current as of 20160526T13Z and if_wm.c 1.410 >> a stuck interface is abserved on following hardware > >> wm1 at pci11 dev 0 function 0: Intel i82583V (rev. 0x00) >> wm1: interrupting at ioapic0 pin 18 >> wm1: PCI-Express bus >> wm1: 2048 words FLASH, version 1.10.0, Image Unique ID >> wm1: Ethernet address bc:5f:f4:98:32:84 >> makphy0 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 > >> when rsyncing. The interface is on the sending side and >> the sndq drops increase dramatically: > >> net.interfaces.wm1.rcvq.drops = 0 >> net.interfaces.wm1.sndq.len = 0 >> net.interfaces.wm1.sndq.maxlen = 256 >> net.interfaces.wm1.sndq.drops = 6077 > >> ifconfig down/up recover the interface. > > > Same here. I'm not sure if that is specific to wm but: > > if_wm.c 1.400 seems to have the problem. > if_wm.c 1.391 does not. > > N.B. the current version 1.410 also has some other issue as it > causes dhcpcd to behave differently. Probably something > with carrier detection. This is something not visible already > with 1.400. I think my mistake in if_wm.c:r1.409 causes this problem. I think it is fixed in if_wm.c:r1.411. Could you try the revision? I'm sorry that I don't have ethernet controllers earlier than 82575 such as 82583. I will borrow them from msaitoh@n.o to test... Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA
Re: if_wm.c 1.410 sometimes hangs / sndq drops
kar...@netbsd.org (Frank Kardel) writes: >With -current as of 20160526T13Z and if_wm.c 1.410 >a stuck interface is abserved on following hardware >wm1 at pci11 dev 0 function 0: Intel i82583V (rev. 0x00) >wm1: interrupting at ioapic0 pin 18 >wm1: PCI-Express bus >wm1: 2048 words FLASH, version 1.10.0, Image Unique ID >wm1: Ethernet address bc:5f:f4:98:32:84 >makphy0 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 >when rsyncing. The interface is on the sending side and >the sndq drops increase dramatically: >net.interfaces.wm1.rcvq.drops = 0 >net.interfaces.wm1.sndq.len = 0 >net.interfaces.wm1.sndq.maxlen = 256 >net.interfaces.wm1.sndq.drops = 6077 >ifconfig down/up recover the interface. Same here. I'm not sure if that is specific to wm but: if_wm.c 1.400 seems to have the problem. if_wm.c 1.391 does not. N.B. the current version 1.410 also has some other issue as it causes dhcpcd to behave differently. Probably something with carrier detection. This is something not visible already with 1.400. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
if_wm.c 1.410 sometimes hangs / sndq drops
With -current as of 20160526T13Z and if_wm.c 1.410 a stuck interface is abserved on following hardware wm1 at pci11 dev 0 function 0: Intel i82583V (rev. 0x00) wm1: interrupting at ioapic0 pin 18 wm1: PCI-Express bus wm1: 2048 words FLASH, version 1.10.0, Image Unique ID wm1: Ethernet address bc:5f:f4:98:32:84 makphy0 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 when rsyncing. The interface is on the sending side and the sndq drops increase dramatically: net.interfaces.wm1.rcvq.drops = 0 net.interfaces.wm1.sndq.len = 0 net.interfaces.wm1.sndq.maxlen = 256 net.interfaces.wm1.sndq.drops = 6077 ifconfig down/up recover the interface. Any ideas? Frank
