On Fri, Nov 09, 2007 at 11:50:32AM +0100, Geert Stappers wrote:
> After some research, I found out that my eth1 indeed had no MII ioctl
> support. So the installer was right to ask for choosing a NIC.
>
> People with multiple NICs, that do have MII ioctl support,
> in their installed system and see that the live interface is detected,
> please be carefull with closing this bugreport, because it is merged
> with other bugreports.
>
> Confirming that "link detection" works is appreciated.

We have a number of Dell PowerEdge machines that do not indicate which
interface has link when running d-i. dmesg(8) says the adapters are:

eth0: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
eth1: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet

and mii-tool(8) does detect the presence or absence of link:

eth0: negotiated 100baseTx-FD, link ok
eth1: no link

These interfaces take a while to negotiate a link, probably because spanning
tree is enabled on the switch ports they're attached to, so it necessarily
takes a while for the port to enter the forwarding state. Is there a way to
have d-i/netcfg sleep for a longer (configurable?) period of time before
assuming no link has been negotiated?

john
--
John Morrissey _o /\ ---- __o
jwm@horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wednesday 27 February 2008, John Morrissey wrote:
> These interfaces take a while to negotiate a link, probably because
> spanning tree is enabled on the switch ports they're attached to, so it
> necessarily takes a while for the port to enter the forwarding state. Is
> there a way to have d-i/netcfg sleep for a longer (configurable?) period
> of time before assuming no link has been negotiated?

OK. One way to test this theory would be to run an installation with
'install priority=medium' and wait for some time between the network
hardware detection step and the network configuration step.
And maybe check dmesg or VT4 in between for link detection messages.

Does that result in reliable automatic selection of the connected NIC?

If it does, how long is the delay between the driver being loaded and the
link coming up (/var/log/syslog should be able to tell you)?

Cheers,
FJP



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Mar 02, 2008 at 08:30:17PM +0100, Frans Pop wrote:
> On Wednesday 27 February 2008, John Morrissey wrote:
> > These interfaces take a while to negotiate a link, probably because
> > spanning tree is enabled on the switch ports they're attached to, so it
> > necessarily takes a while for the port to enter the forwarding state. Is
> > there a way to have d-i/netcfg sleep for a longer (configurable?) period
> > of time before assuming no link has been negotiated?
>
> OK. One way to test this theory would be to run an installation with
> 'install priority=medium' and wait for some time between the network
> hardware detection step and the network configuration step.
> And maybe check dmesg or VT4 in between for link detection messages.
>
> Does that result in reliable automatic selection of the connected NIC?
>
> If it does, how long is the delay between the driver being loaded and the
> link coming up (/var/log/syslog should be able to tell you)?

According to the switch, the link comes up when the machine boots (we PXE
boot for our installs), ascends to spanning-tree listening state, and
remains up when d-i starts.

When the module for the interfaces is loaded, the link stays up (on the
switch side; d-i syslogs don't indicate anything about link, and ifconfig(8)
shows them as down: i.e., they do not appear in 'ifconfig' output, but do
appear in 'ifconfig -a' as 'BROADCAST MULTICAST' and not 'UP' or 'RUNNING').

When I hit 'Configure network interfaces,' netcfg must throb the interface
somehow, since it goes from forwarding state to listening state on the
switch:

sw06.roch.ny#sh int g0/31
GigabitEthernet0/31 is up, line protocol is up (connected)
[...]
sw06.roch.ny#sh spanning-tree interface g0/31

Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0090 Desg FWD 4 128.31 P2p

[... select 'Configure Network Interfaces']

sw06.roch.ny#sh spanning-tree interface g0/31

Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0090 Desg LIS 19 128.31 P2p
[... time goes by]
sw06.roch.ny#sh spanning-tree interface g0/31

Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0090 Desg FWD 4 128.31 P2p

The interface list does not indicate that either interface has link, and the
syslogs say:

main-menu[1188]: INFO: Menu item 'netcfg' selected
kernel: bnx2: eth0: using MSI
netcfg[2842]: INFO: eth0 is disconnected. (MII)
netcfg[2842]: INFO: eth0 is not a wireless interface. Continuing.

Once I choose to use DHCP on the interface, dhclient starts and, two seconds
later, the kernel shows that the device has link:

kernel: bnx2: eth0: using MSI
kernel: bnx2: eth0 NIC Link is Up, 1000Mbps full duplex

However, something has again booted the switch port back into spanning-tree
listening state and the port must again ascend to forwarding state. Because
of this, dhclient spins for a while and successfully gets an IP address 37
seconds after link is detected by the kernel.

I don't know what the default timeout is OTTOMH, but without overriding it,
network autoconfiguration fails every time.

john
--
John Morrissey _o /\ ---- __o
jwm@horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org