Date: Sat, 02 Feb 2008 20:00:58 -0500 From: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> To: Danny Pansters <danny@ricin.com> Cc: freebsd-stable@freebsd.org Subject: Re: kld regression Message-ID: <1202000458.894.9.camel@RabbitsDen> In-Reply-To: <200802011526.23000.danny@ricin.com> References: <47A0B642.9060000@icyb.net.ua> <47A1C198.6090802@icyb.net.ua> <47A1E3D5.6040301@icyb.net.ua> <200802011526.23000.danny@ricin.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Alexandre "Sunny" Kovalenko (Олександр Коваленко)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1202000458.894.9.camel>