tg3 network cards

[Ryan Steele]

Hi Ralf,
> I had similar problems with  FSC RX300S3 systems, which have an
> onboard Broadcom 5715 dual port interface. My systems have an
> additional Intel quad port card, so I end up with 6 interfaces, and the
> one I need for FAI install is never eth0. This was no problem with
> my etch environment, I see these problems only since I started with
> lenny/FAI3.2.14.
>
> I thought if we have an 'ip=dhcp' in the kernel command line of the
> pxelinux config file then ipconfig from klibc-utils would just try 
> all interfaces and use the one, where it gets an answer. At least, that's
> how I understand Documentation/nfsroot in the kernel sources.
>   

That would seem logical, though admittedly I've only glossed through the 
kernel source (panic.c, exit.c, etc.), and not enough to know it very well.

> My first try was to use entries like 'ip=:::::eth1:dhcp', but the systems
> was still hanging before the nfsroot mount.
>
> My current solution with the FAI3.2.14/lenny server is to use a
> specific initrd and nfsroot for these boxes and fix the interface 
> naming with an udev rules file in the initrd. Then the dhcp-connected
> interface is forced to be eth0 and it works.
> [As I have a couple of systems with identical setup for the interface
> cards, I use the PCI slot id for naming, with entries like
> ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:12:04.1", NAME="eth0"
> ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:12:04.0", NAME="eth1"
> This is included in the initrd with a initramfs-tools/hooks script.]
>
> Though this works I would still like to understand why the default
> setup did not. I'll follow this thread and hope to learn ...
>   

Yeah, I have a similar custom script that runs near the end of my FAI 
installation, because we have a convention of making the main interface 
eth1 - the intranet port, since many boxes are not public facing.  It 
basically swaps the interfaces via some udev hand-waving.  I never 
considered doing this in the initrd, but that may be a possible solution. 

However, I don't know if probing all interfaces is a solution, since 
ipconfig seems to hang indefinitely if it probes an interface that 
doesn't have a cable or is otherwise unavailable.  It may be that a bug 
needs to be filed against the klibc-utils package; a binary that hangs 
after trying one interface is a horrible implementation - it cripples 
PXE functionality.  I'll keep you and the list in the loop as to how I 
end up solving this.

Thanks for your input - it could certainly prove useful!

Respectfully,
Ryan