* David Miller <davem@davemloft.net> wrote:

quoted text
> Yeah I wish udev would just leave the damn devices alone.
> 
> It even does things like try to rename a network device to the same 
> name it already has, and other strange stuff.
> 
> But that log difference is a good clue.
> 
> Because udev can try to rename a network device stupidly to a name the 
> device already has we added a patch to just short circuit this case in 
> the networking.  We did this because otherwise the generic device 
> layer gives an ugly stack backtrace via dev_rename().
> 
> Therefore, you might want to see if reverting that patch (attached 
> below) has some effect, once you are able to trigger it again.

just to confuse things, i just got a crash with the twiddled network 
setup :-/ I have reverted the same-name optimization and have got a 
similar crash again. So this angle is a red herring.

now that it's reproducible again i'll try more direct debugging. 
(Networking might not even be the cause of this - that was just a quick 
first impression that i had.)

Btw., the .config is the result of automated "make randconfig" x86 
bootup testing QA, so there might be weird combinations in the .config. 
That's how SLOB got randomly enabled in the first place, i dont normally 
use SLOB kernels.

	Ingo
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/