From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 01:01:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15FD616A417 for ; Sun, 3 Feb 2008 01:01:06 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id C189013C447 for ; Sun, 3 Feb 2008 01:01:05 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so468999anc.13 for ; Sat, 02 Feb 2008 17:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=OdMXD8+amQhAX3+p/pLFln55N50jAYJTrai7zLh9w/I=; b=EfIm731UdELu+Zets8OVLhbxOBsi7deMQlRzGAn4bCJBwUwrXZx1aThMM/0w4aI4LjMZYJg4tseYpiIKeyrZgjfE1vnE8wro0pP4h+MhJZeNFWjjTAICmjwlYj7NMf0/d8RsaKowzG4eAJgqzk/JrU9mZOMo0plMcE52hyvCt30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=i5F2ZWOmpqBjZcBWeegHS3POtcEm9j57by9U7IqGgS77+H7393xfldOaDfdNRSwLQldQzU21xZkJpcNOwlOZsDx1Cs2YX3jf5XHpVcdJtB+eiWY8yw39YHA1BezP2v7RIcf2h1vgTXdluhKVWRWTHI8++u1kzKlsQd1crRQUTeY= Received: by 10.100.216.3 with SMTP id o3mr11177927ang.95.1202000464739; Sat, 02 Feb 2008 17:01:04 -0800 (PST) Received: from ?10.0.3.231? ( [70.111.176.151]) by mx.google.com with ESMTPS id o61sm12728529hsc.10.2008.02.02.17.01.03 (version=SSLv3 cipher=RC4-MD5); Sat, 02 Feb 2008 17:01:04 -0800 (PST) From: "Alexandre \"Sunny\" Kovalenko" To: Danny Pansters 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> Content-Type: text/plain; charset=utf-8 Date: Sat, 02 Feb 2008 20:00:58 -0500 Message-Id: <1202000458.894.9.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: kld regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 01:01:06 -0000 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 (Олександр Коваленко)