loopback interface broken on current

[Gleb Smirnoff]

On Wed, Jan 09, 2013 at 09:56:25AM +0100, Hartmann, O. wrote:
H> Same here.
H> The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes
H> running approximately the same configurations (I share my configs
H> between lab and home), but different hardware, I'm confused.
H> 
H> The symptoms in my case are:
H> 
H> Booting the box is all right until it comes to the start of nfsuserd.
H> Prior to that, ntp adjusts the clock properly with an external time
H> server  - so this implies network connectivity. Start of nfsuserd is
H> stuck forever.
H> Interrupting the start of nfsuserd restarts several other services, but
H> winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt
H> them, there are other services which will not start.
H> 
H> Trying to login as root on the console fails - I never get a password
H> tag after having issued the root login name. Since this machine is bound
H> to a local and remote OpenLDAP backend, I'm used to have an emergency
H> local user which usually works - but this time, neither root nor this
H> user can login!
H> 
H> Bringing up the box in SINGLEUSER allows me to login. Investigating the
H> network interfaces with ifconfig reveals, that the loopback did not get
H> assigned to any inet 127.0.0.1 address. Sometimes there is only inet6
H> linklocal address, some nd6 options, but sometimes even IPv6 assignments
H> do not show up.
H> 
H> In a desperate move I tried to recompile a kernel. In /etc/src.conf, I
H> recompile also the kernel module for the most recent virtual-box kernel
H> module. While the kernel and module (*.ko) get installed properly, the
H> recompilation of the VirtualBox port gets stuck when the system unfolds
H> the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other
H> processes seem to have trouble getting a proper ownership or UID for a
H> file - this is my naiv interpretation what I see at the surface.
H> 
H> The funny thing is, that after several reboots, the box gets up as normal.
H> 
H> I revealed this issue approx. two weeks ago when out of the sudden the
H> amd automounter stopped working and the NFSv4 network drives didn't
H> attach properly and made the whole box being stuck.
H> 
H> Sorry for the more superficial description of the problem ...
H> 
H> Has the problem been identified? Is there a solution? Since it affects
H> only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS
H> mainboard), while a very same setup on older hardware (our local server
H> is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based
H> mainboard), both systems do have Intel NICs, I'm a bit confused.

This looks unrelated to the problem discussed, because r245218 is
later than r244989 which backed out my change.

Can you do a binary search to identify which revision broke things?

-- 
Totus tuus, Glebius.