ifconfig_xxx hangs on boot?

Y

ywil

Hey all,

After spending months messing around with FreeBSD in a VM, I decided to finally install it. Naturally, this was not a seamless transition.

Installation was issue free, except for issues getting an IP address through DHCP. I have 2 different NICs, and both silently failed while getting an IP address (and, in fact, required ctrl+c'ing or a hard reboot). After several attempts at installing, I was finally successful using a different install CD. Must have been a CD problem. Rejoice! All is well!

Not as much as I'd hoped. After installation, the problem returns during boot. As this is a headless server, this is a bit problematic. I've tried both interfaces via DHCP and static addresses. When it comes time to assign either of them an IP address (either static or DHCP), the boot process hangs indefinitely. This happens roughly every other time the system is rebooted.

The hang occurs right after the interface is put down and then back up. Not sure why the down/up happens, but I've been unable to stop it from happening (and it happens on successful boots).

If I have a video card/keyboard plugged in, I can interrupt the process of assigning an IP address after it hangs with ctrl+c. This allows the boot to continue. After logging in, I am then able to assign an IP either through DHCP or statically.

Am I overlooking something obvious? Is there a known bug that hasn't turned up in my (fruitless) search?

Relevant (?) command output below:
Code: 
#pciconf -lv
none0@pci0:0:20:0:      class=0x0c0500 card=0x43851043 chip=0x43851002 rev=0x13 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'IXP SB600 SMBUS Controller'
    class      = serial bus
    subclass   = SMBus
isab0@pci0:0:20:3:      class=0x060100 card=0x438d1002 chip=0x438d1002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'IXP SB600 PCI to LPC Bridge'
    class      = bridge
    subclass   = PCI-ISA
pcib2@pci0:0:20:4:      class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'IXP SB600 PCI to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
vr0@pci0:2:1:0: class=0x020000 card=0x14061186 chip=0x31061106 rev=0x86 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6105M/LOM Rhine III PCI Fast Ethernet Controller'
    class      = network
    subclass   = ethernet
skc0@pci0:2:4:0:        class=0x020000 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = 'Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)'
    class      = network
    subclass   = ethernet

Code: 
$dmesg | egrep 'sk0|vr0'
vr0: <VIA VT6105 Rhine III 10/100BaseTX> port 0xe800-0xe8ff mem 0xfbfffc00-0xfbfffcff irq 21 at device 1.0 on pci2
vr0: Quirks: 0x0
vr0: Revision: 0x86
miibus0: <MII bus> on vr0
vr0: Ethernet address: 00:15:e9:82:02:12
vr0: [ITHREAD]
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:1e:8c:72:f2:f2
miibus2: <MII bus> on sk0
vr0: <VIA VT6105 Rhine III 10/100BaseTX> port 0xe800-0xe8ff mem 0xfbfffc00-0xfbfffcff irq 21 at device 1.0 on pci2
vr0: Quirks: 0x0
vr0: Revision: 0x86
miibus0: <MII bus> on vr0
vr0: Ethernet address: 00:15:e9:82:02:12
vr0: [ITHREAD]
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:1e:8c:72:f2:f2
miibus2: <MII bus> on sk0

Sorry if this is in the wrong forum. Feel free to point and laugh if it is. I'd even suffice a solution wherein the system finishes booting and then runs dhclient automatically, although this would make address binding with server daemons a difficult prospect.

Thanks in advance.
 
Sorry for the double post, but cannot edit my original. After some further testing, it seems to hang on sk0 most of the time. Perhaps vr0 hanging is just a red herring and it is perhaps sk0 failing behind the scenes?
 
What are the relevant parts of /etc/rc.conf and the output in [cmd=]dmesg -a[/cmd]?
 
Code: 
$cat /etc/rc.conf:
hostname="andromeda"
ifconfig_sk0="DHCP"
gateway_enable="YES"
sshd_enable="YES"
ifconfig_vr0="192.168.0.1"

I've tried with both 7.2-GENERIC's default DHCP client and isc-dhcpd31-client; both displayed the same symptoms, so I've moved back to the default.

A note: I'm not sure how the FreeBSD network stack works, but it might be important to note that the subnet sk0 is plugged in to is in the 192.168.1.0/24 range (i.e. does not conflict with vr0's static IP). At the moment, getting sk0 to work is a higher priority since it's gigabit and the primary interface (although since both interfaces have failed, both may get fixed at the same time).

At the risk of overwhelming everyone with `dmesg -a` output, I've again egrepped against the interface names. If you would like all output, let me know and I'll dump it and attach it.

Code: 
$dmesg -a | egrep 'vr0|sk0'
vr0: <VIA VT6105 Rhine III 10/100BaseTX> port 0xe800-0xe8ff mem 0xfbfffc00-0xfbfffcff irq 21 at device 1.0 on pci2
vr0: Quirks: 0x0
vr0: Revision: 0x86
miibus0: <MII bus> on vr0
vr0: Ethernet address: 00:15:e9:82:02:12
vr0: [ITHREAD]
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:1e:8c:72:f2:f2
miibus2: <MII bus> on sk0
vr0: <VIA VT6105 Rhine III 10/100BaseTX> port 0xe800-0xe8ff mem 0xfbfffc00-0xfbfffcff irq 21 at device 1.0 on pci2
vr0: Quirks: 0x0
vr0: Revision: 0x86
miibus0: <MII bus> on vr0
vr0: Ethernet address: 00:15:e9:82:02:12
vr0: [ITHREAD]
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:1e:8c:72:f2:f2
miibus2: <MII bus> on sk0
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 
Code: 
ifconfig_vr0="192.168.0.1"
Click to expand...

How does this show up in [cmd=]ifconfig vr0[/cmd]? I'm not sure what netmask gets assigned if you don't define it. Chances are that you end up with a netmask that actually spans the DHCP range, causing IP conflicts (which may manifest itself as hangs, I don't know).
 
Code: 
$ifconfig vr0
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
        ether 00:15:e9:82:02:12
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        media: Ethernet autoselect (none)
        status: no carrier

Seems to choose 255.255.255.0 by default. I've updated rc.conf to be more explicit (and then subsequently commented it out, see below).

Just for the sake of debugging, I've removed the NIC with interface vr0 from the computer. Issue persists.
 
What happens when you boot with
Code: 
ifconfig_vro="up"
ifconfig_sk0="up"
and then run e.g. [cmd=]dhclient -d sk0[/cmd] from the root shell?
 
Then it works (or at least, didn't hang after 3 trials). I'll give a few more attempts at rebooting once I have physical access to the machine (I'm doing this remotely now, so if it doesn't come back online, it's done for). It's not ideal, however, as I'd really like to run headless... plus it plain bothers me that I have no idea why this is happening.
 
@ywil:
I hope you are not trying to connect both interfaces to the same network at the same time?
That will only give you trouble.
 
tingo said:
@ywil:
I hope you are not trying to connect both interfaces to the same network at the same time?
That will only give you trouble.
Click to expand...

Nope, not the plan. Ideally, I'd eventually have vr0 be outward facing and have sk0 act as a gateway for my apartment's LAN. Haven't gotten that far yet, however, as it often takes upwards of 10 minutes before I can get sk0 up without hanging.

As I mentioned earlier, sk0 seems to choke on both static and dynamically assigned IPs, but only during power on. Once I am able to log in to a root shell, I can assign IPs either way with no problem.

Unless anyone has an idea, I'm thinking of borrowing an Intel NIC from a friend and seeing if that "fixes" the problem. If it does, well, I'll just assume something is horribly wrong with my current NICs.

That said, I'm not quite sure how connecting two interfaces to the same network would be trouble. My primary computer right now is running Arch Linux with two different NICs both on the same network; the only issue I've had is making sure executable bind the correct interface.
 
You must log in or register to reply here.
Back
Top