[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: if_wm.c 1.410 sometimes hangs / sndq drops
On 2016/05/30 0:16, Michael van Elst wrote:
> kardel%netbsd.org@localhost (Frank Kardel) writes:
>> With -current as of 20160526T144443Z 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 0000ffff
>> 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 firstname.lastname@example.org to test...
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
Main Index |
Thread Index |