Re: wm(4)

[SAITOH Masanobu <msaitoh%execsw.org@localhost>]

On 2015/10/29 6:00, Mike Pumford wrote:
> Robert Swindells wrote:
>>
>> Robert Swindells wrote:
>>> Anyone else having problems with wm(4) in current ?
>>>
>>> Works fine in a kernel from Oct 5, doesn't do anything in latest version.
>>
>> Some more info, it is sending packets but not responding to incoming
>> ones.
>>
> I have some intermittent issues on NetBSD 7.0-RELEASE but only on one machine and pretty much all my x86 systems have wm adapters of one sort or another. Occasionally it will fail to get an address via DHCP. Next time it goes odd I'll grab the ifconfig -v output and see if I can grab some packet dumps from the DHCP server side. For reference the systems which have no problems at all ever:
> 
> NetBSD 7.0/amd64:
> wm0 at pci4 dev 3 function 0: Intel i82541PI 1000BASE-T Ethernet (rev. 0x05)
> wm0: interrupting at ioapic0 pin 22
> wm0: 32-bit 33MHz PCI bus
> wm0: 64 words (6 address bits) MicroWire EEPROM
> wm0: Ethernet address 00:0e:0c:72:67:5a
> igphy0 at wm0 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
> 
> NetBSD 6.1-STABLE/i386:
> wm0 at pci5 dev 0 function 0: Intel i82574L (rev. 0x00)
> wm0: interrupting at ioapic0 pin 19
> wm0: PCI-Express bus
> wm0: 2048 words (8 address bits) SPI EEPROM
> wm0: Ethernet address 00:00:24:d0:a1:fc
> ukphy0 at wm0 phy 1: OUI 0x000ac2, model 0x000b, rev. 1
> 
> And the intermittently problematic system:
> NetBSD 7.0/amd64 (exactly the same build and kernel as the first system)
> 
> wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x00)
> wm0: interrupting at ioapic0 pin 20
> wm0: PCI-Express bus
> wm0: 2048 words FLASH
> wm0: Ethernet address 10:c3:7b:95:20:ed
> ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5
> 
> 
> This is the ifconfig -v from the intermittent system:
> wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
>         capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
>         capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
>         enabled=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
>         enabled=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
>         enabled=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
>         ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
>         ec_enabled=0
>         address: 10:c3:7b:95:20:ed
>         media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause)
>         status: active
>         input: 99078965 packets, 12756425569 bytes, 1639632 multicasts
>         output: 19942431 packets, 225995936552 bytes, 194 multicasts, 1 error
>         inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
>         inet6 fe80::12c3:7bff:fe95:20ed%wm0 prefixlen 64 temporary scopeid 0x1
>         inet6 2001:8b0:84:1:12c3:7bff:fe95:20ed prefixlen 64
> 
> I'm guessing the one error in those stat counters corresponds to this in my dmesg:
> wm0: device timeout (txfree 4068 txsfree 55 txnext 690)

 This device timeout might be related to PR#40981.

	http://gnats.netbsd.org/40981

> As I say next time I see a failure to acquire an address I'll acquire the ifconfig -v output again. On this particular boot the system got its DHCP allocation fine and has been running reliably ever since apart from that one glitch.
> 
> Mike

 By the way, wm(4) has an small problem. When we use "ifconfig wm0 up" on
some chips with copper media, the following sequence is observed:

	0) link goes up

	1) after 1 second, it goes down

	2) and a few seconds later, link goes up again

I fixed this problem yesterday. The change also fixes a problem
that "some" ICH8+82566 systems does link up with 100M in above 2)
with 1G switch with "ifconfg wm0 auto". I'll commit the change
in a few days.

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)