Re: kern/87506 : [PATCH] Fix alias support on vr interfaces

> On Thu, Oct 20, 2005 at 04:51:21PM -0400, John Baldwin wrote:
>> On Thursday 20 October 2005 02:27 pm, Anish Mistry wrote:
>> > On Thursday 20 October 2005 11:15 am, John Baldwin wrote:
>> > > On Thursday 20 October 2005 10:23 am, Tom McLaughlin wrote:
>> > > > <snip>
>> > > I'm not sure that fix is really the right fix.  The patch just
>> > > makes vr(4) ignore changes to if_flags while the driver is up.
>> > > Probably there is a bug in vr(4)'s handling of alias addresses.  I
>> > > did just reproduce this on my laptop's rl(4) interface though.
>> > > I'll see if I can't figure out what is happening.
>> >
>> > I'm also seeing this too along with the following.
>> >
>> > I'm not sure if this is related, but I'm seeing the following on
>> > RELENG_6 and CURRENT, but and older RELENG_5 as of ~2 months ago
>> > doesn't show this problem.
>> > I'm trying to setup my workstation with a normal DHCP'd address
>> > and an alias IP for a jail running on the system, but the alias
>> > setting wipes out all the other addresses on the interface.
>> > in /etc/rc.conf:
>> > ifconfig_rl0="DHCP"
>> > ifconfig_rl0_alias0="inet 192.168.1.10 netmask 255.255.255.255"
>> >
>> > I've checked the rc boot order (on RELENG_6 and CURRENT) and it seems
>> > correct:
>> > netif
>> > dhclient
>> > netif
>> >
>> > I narrowed it down to:
>> > dhclient rl0
>> > ifconfig rl0 inet 192.168.1.11 netmask 0xffffffff alias
>> > [dhclient prints a message here saying connection closed and exiting]
>> >
>> > All of the other addresses on the card are removed.
>> > I'm also seeing this on dc.  So thinking it to be a problem in
>> > ifconfig I copied over the version from my RELENG_5 box, and that did
>> > the same thing...so this seems to be present several of the network
>> > drivers in RELENG_6/CURRENT.
>>
>> Yes, it seems to be an issue with dhclient.  If I turn dhclient off and
>> manually configure my NIC then the alias works fine:
>> rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>         options=8<VLAN_MTU>
>>         inet6 fe80::290:f5ff:fe0e:c8e5%rl0 prefixlen 64 scopeid 0x2
>>         inet 10.50.41.234 netmask 0xfffffe00 broadcast 10.50.41.255
>>         inet 10.50.41.101 netmask 0xffffffff broadcast 10.50.41.101
>>         ether 00:90:f5:0e:c8:e5
>>         media: Ethernet autoselect (100baseTX <full-duplex>)
>>         status: active
>
> I believe the problem is that adding an address to a NIC causes a call
> to ifp->if_init() which resets the media and triggers a LINK_DOWN event
> in all too many cases.  Using if_init here is rather like driving
> finishing nails with a sledge hammer.
>
> -- Brooks
>

Hi Brooks and John,

I just reproduced this with a bge (Broadcom BCM5789) while attempting an
RC1 install here at work.  I noticed while toying with ifconfig that only
the first alias I set whipes out the previous address on the card.  Any
subsequent aliases leave the previously set addresses in tact.

In addition to that I found another problem with this bge which may or may
not be related.  During the install of the box with the bge I noticed that
it was unable to obtain an address via DHCP.  I checked the link light and
it was out.  When I rebooted the machine after the install I looked at the
link light for the bge and it was still out and ifconfig said the status
of bge 0 was "no carrier".  I watched the boot messages and the link light
on another reboot and I noticed when the OS detected the bge the link
light imediately goes out.

dmesg snippet, light goes out at aproximately the first line:
bge0: <Broadcom BCM5782 Gigabit Ethernet, ASIC rev. 0x3003> mem
0xfc500000-0xfc50ffff irq 20 at device 2.0 on pci5
miibus0: <MII bus> on bge0
brgphy0: <BCM5705 10/100/1000baseTX PHY> on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
1000baseTX-FDX, auto
bge0: Ethernet address: 00:12:79:a7:06:4d

The link light doesn't come back on until the point during boot when
dhclient starts up.  I tried this with acpi loaded and unloaded to rule it
out and results were the same.  I'm not sure if this is a seperate bge bug
or if it's related to the initial problem.  A full boot -v dmesg is
attached.  I'll take a look when I get home at the box with the vr to see
if it too is exhibiting the same behavior wih the link light going down
once the vr is detected.

Thanks,
Tom