patch: avoid wm(4) resets when adding/deleting vlan(4)

[David Young]

After a wm(4) is reset, it takes about 30 seconds for the NIC to get
back "on net." It's really painful.

I've attached a patch for -current that stops wm(4) from needlessly
resetting when you add or delete a vlan(4):

ifconfig vlan0 create vlan 2 vlanif wm0
ifconfig vlan0 destroy

Please give it a look or give it a try. I will commit it next week.

A patch for netbsd-5 is on the way.

Dave

[der Mouse]

Post by David Young
After a wm(4) is reset, it takes about 30 seconds for the NIC to get
back "on net." It's really painful.

Are you sure it's the wm's fault? This sounds suspiciously like a
spanning tree holddown time, in which case anything that interrupts
link will cause the same symptom, and the proper cure is to not run
spanning tree on ports connected to hosts.

Indeed, I just now tried your example (on 4.0.1, that being the only
wm-using NetBSD machine I have easy root access to as far as I know)
and the wm dropped off the net for almost exactly five seconds. (The
machine has an fxp, and I was logged in to it, pinging out through the
wm.)

Post by David Young
I've attached a patch for -current that stops wm(4) from needlessly

This strikes me as a good thing regardless.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by der Mouse

Post by David Young
After a wm(4) is reset, it takes about 30 seconds for the NIC to get
back "on net." It's really painful.

Are you sure it's the wm's fault? This sounds suspiciously like a

It's typically a combination of wm and the link partner behavior. The
minimum interval appears to be several seconds.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Thor Lancelot Simon

Post by der Mouse

Post by David Young
After a wm(4) is reset, it takes about 30 seconds for the NIC to get
back "on net." It's really painful.

Are you sure it's the wm's fault? This sounds suspiciously like a

It's typically a combination of wm and the link partner behavior. The
minimum interval appears to be several seconds.

FWIW, I have my wm(4) under test plugged into a 24-port 3Com gigabit
switch, and the delay seems to be partly the fault of the switch. When
I plug my MacBook Pro into the same switch in the morning, there is
a long delay before a DHCP lease is acquired. My MacBook Pro uses a
Marvell chip:

Marvell Yukon Gigabit Adapter 88E8053 Singleport Copper SA:

Name: ethernet
Type: Ethernet Controller
Bus: PCI
Vendor ID: 0x11ab
Device ID: 0x4362
Subsystem Vendor ID: 0x11ab
Subsystem ID: 0x5321
Revision ID: 0x0022
Link Width: x1
BSD name: en0
Kext name: AppleYukon2.kext
Location: /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleYukon2.kext
Version: 3.2.1b1

Dave