kld regression

Alexandre "Sunny" Kovalenko gaijin.k at gmail.com
Sun Feb 3 01:01:06 UTC 2008


On Fri, 2008-02-01 at 15:26 +0100, Danny Pansters wrote:
> On Thursday 31 January 2008 16:05:57 Andriy Gapon wrote:
> > on 31/01/2008 14:39 Andriy Gapon said the following:
> > > on 31/01/2008 13:07 John Baldwin said the following:
> > >> On Wednesday 30 January 2008 12:39:14 pm Andriy Gapon wrote:
> > >>> The problem is as follows:
> > >>> 1. put udf_load="YES" in loader.conf
> > >>> 2. you can mount and unmount udf filesystems
> > >>> 3. you can kldunload udf if no udf filesystems are mounted
> > >>> 4. now mount udf fs while udf.ko is unloaded
> > >>> 5. udf is auto loaded and fs is mounted
> > >>> 6. unmount fs
> > >>> 7. try to kldunload udf
> > >>> kldunload: can't unload file: Device busy
> > >>> kernel message: kldunload: attempt to unload file that was loaded by
> > >>> the kernel
> > >>>
> > >>> Yeah, it was loaded by kernel indeed, but WTF - what is the difference
> > >>> from manual/loader.conf loading and why I can not manage my modules as
> > >>> I wish?
> > >>
> > >> Hmm, the relevant code (vfs_init.c) hasn't changed in 6.x since 6.0. 
> > >> There were some changes in 7.0, but this should work in both branches. 
> > >> What is the previous release that this worked on?
> > >
> > > Maybe I was wrong when I called this regression, but this was very
> > > surprising behavior for me. And in 5.X I did a lot of udf
> > > debugging/experimenting and never encountered such a problem. Maybe I
> > > always did kldload before mount, I can't tell now.
> > > Anyway, this seems like an annoyance at the very least, pinning a kernel
> > > module without any important reasons.
> >
> > Hmm, I found one difference with previous setups: in step 1 I also have
> > udf_iconv_load="YES" and udf_iconv.ko module is what seems to prevent
> > udf.ko from unloading in step 7. I can actually unload udf_iconv and
> > then I am able again to unload udf.
> >
> > Still don't understand what is a big difference here.
> >
> > And if I had UDF_ICONV built into kernel then I wouldn't have this
> > work-around.
> 
> The way I understand it, there are two different things:
> 
> 1. kldload will load "child" modules on demand, but kldunload does not attempt 
> to unload any other modules than the one you ask for. I don't think it's 
> material whether the kldload was done via the loader (before the kernel kmod 
> gets loaded, kernel is also a kmod), or after. It's also possible to have 
> modules who need to access the filesystem (other than /boot partition) when 
> kldloaded, and such modules can obviously not be loaded via the loader at 
> all.
> 
> 2. There may be modules (such as bktr) that allocate memory in kernel space. 
> These can not be unloaded, because that memory may not be deallocated while 
> the kernel is up and running (the latter is my assumption).
> 
> Anyhow, unless you're very tight on RAM, it hardly matters if you have some 
> kmods loaded but left unused. Kmods are small, typically 10-100 kB.
I have two reasons for wanting to unload modules, neither have anything
to do with the memory consumption:

1. hw.pci.do_power_nodriver setting allows me not to power up bits and
pieces, resulting in longer battery life. I would really like to unload
unneeded modules when I am taking laptop away from my desk where I have
USB and Firewire peripherals and power supply. 
2. usb.ko effectively prevents CPU from going into C3 state, which,
again, negatively impacts battery life.

For both of these reasons, I tend to reboot my laptop when I am planning
on working away from my desk for prolonged time.

> 
> If all your kmods are built into the kernel, you have the footprint of all of 
> them and you can't disable any at runtime.
> 
> Feel free to correct me, anyone, if you think the above is not correct or 
> complete.
> 
> Dan
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
-- 
Alexandre "Sunny" Kovalenko (Олександр Коваленко)



More information about the freebsd-stable mailing list