Re: something at init is taking about 31s to finish
Hi.
On Mon, Aug 31, 2015 at 11:16:57AM +0100, Brian wrote:
> On Mon 31 Aug 2015 at 11:56:09 +0300, Reco wrote:
>
> > On Sun, Aug 30, 2015 at 06:58:10AM -0700, briand@aracnet.com wrote:
> > >
> > > there's this in dmesg:
> > >
> > > [ 6.210098] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts:
> > > (null)
> > > [ 35.827945] r8169 0000:03:00.0: firmware: failed to load rtl_nic/rtl8168f-1.fw (-2)
> > > [ 35.827963] r8169 0000:03:00.0: Direct firmware load failed with error -2
> > > [ 35.827965] r8169 0000:03:00.0: Falling back to user helper
> > > [ 35.828580] r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-12)
> > >
> > > so it is the dreaded r8169 firmware crappola. the system works fine
> > > not loading it.
> >
> > My-my. Calling perfectly good, working out-of-the box r8169 card like
> > that is way too harsh (and violates this list rules btw). I happen to
> > have a similar NIC in one of my PCs, and I can confirm that it works
> > flawlessly without any non-free blobs. I have not tried it with
> > systemd, though.
>
> The Installation Guide mentions that some hardware works well without
> firmware. It's a matter of trying it and seeing how you go on.
Indeed. What the Installation Guide does not mention is the existance of
the hardware that *requests* firmware, but works happily without such.
> > > is there any way to tell the module to not even try and load it ?
> >
> > Why are you so sure that it's the failing firmware loading that adds
> > 30 seconds to your boot sequence? According to the dmesg, the whole
> > ("I need firmware - oh well, I'll try without it") takes whooping
> > 600us.
> >
> > Start with something simple. Like replacing dhcp configuration with
> > static IP assignment.
> >
> > Continue with obligatory "in the case of the doubt fallback to
> > sysvinit".
> >
> > Finally, dump the network traffic during the boot of the offending
> > host (requires and extra host or some trickery, though).
>
> Booting with the firmware loaded should settle the question about the
> 30 second delay being a caused by its lack.
And if it is the case (which I doubt) - it can raise an interesting
question of software liberty. Punishing the user with artificially
increased load time just because the user choose to get rid of non-free
blobs is something to be frowned upon IMO.
Reco
Reply to: