tg3 network cards

[Ryan Steele]

Michael Tautschnig wrote:
>> This may or may not be the proper list/outlet for this, so if it's not,  
>> feel free to let me know and I'll pursue it elsewhere, but since it came  
>> up during a FAI installation I'll start here.
>>
>> I've got a server with a Broadcom network card (a 5721) and I'm using  
>> the tg3 driver, and the box with that NIC that just absolutely refuses  
>> to get through the initrd.  The installation hangs in the initramfs in  
>> /scripts/live on the function do_netmount(), and I'm pretty sure it's  
>> because the 'ipconfig' binary included in the initrd is killing  
>> networking.  I've spent a few days now hacking the initrd, the init  
>> script, and it's functions to determine the path it takes to get there,  
>> which appears to be:
>>
>>     
> [...]
>
> What kind of access do you have for debugging this? Console access? 

Yes, I have console access, both via KVM over IP and IPMI.

> Do you get
> it to boot by some other means (e.g., GRML live CD)?
>   

Unfortunately, I don't have easy physical access, hence the KVM over IP 
and IPMI interface.  The server is physically located at a colo facility 
about 30 minutes away.  I'm doing what I can without driving down there.  :)

> ipconfig is part of the klibc-utils package and most likely just tries to get an
> answer from your DHCP server at that very moment. 

Ah, didn't know that's where it came from - thanks for the tip.  Re: 
'most likely tries...' - really?  It doesn't just use the info supplied 
to the card initially when it boots up, DHCP's, and proceeds via PXE?  I 
submit, I tried to dump the binary with 'strings', but not much research 
beyond that yet (I'm exhausted today, been working for a long time).

> If you get your system to boot
> by some other means, you could safely copy over ipconfig from your Debian
>   

Ubuntu.  I apologized for only making a passing reference to that at the 
end of my OP.

> systems and just run it on the console manually to see what happens.
>   

I tested this on a VM, and it also killed networking.  But, the VM has a 
virtual interface, and may not be a very good test, even if the results 
were the same.  I'll try to test ipconfig on a physical network 
interface to see if I hit the same problem.  But, like I said, I've 
installed other servers the same way successfully, the only difference 
being they had nice Intel cards, not a crappy Broadcom card.

> Furthermore, some tcpdump or the like may be useful to find out what ipconfig is
> trying to achieve.
>   

I'll see if the DHCP server picks up anything, though I think I tried 
that and didn't glean much from it.  (Then again, I'm exhausted, so 
maybe when I'm fresh tomorrow I'll get different results.

> Other than that, there is also the frequently discussed issue of systems with
> more than one NIC -- your ipconfig may simply be trying to get a response from
> the DHCP server over some interface that doesn't have any cable plugged in.
>   

I suppose that could be the case - hadn't even occurred to me.  The box 
does have dual on-board NIC's, so that is a viable suggestion.  I'll do 
some more research on that front, see what comes of it.  Thanks for the 
suggestion.

Respectfully,
Ryan