From owner-freebsd-stable Tue Mar 20 0:54:55 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 9B53C37B718 for ; Tue, 20 Mar 2001 00:54:49 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2K8pVg16380; Tue, 20 Mar 2001 00:51:31 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103200851.f2K8pVg16380@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Sean Kelly Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: Booting with modules In-reply-to: Your message of "Tue, 20 Mar 2001 02:18:55 CST." <20010320021855.A433@edgemaster.zombie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Mar 2001 00:51:31 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I *suspect* that what's happening is that the dependancy checking code is > > incorrectly not registering the if_xl module when it discovers that its > > dependancy (miibus) is already loaded. > > > > You can verify this by reversing the load order, ie. loading if_xl first. > > If this results in if_dc disappearing, then we have a smoking gun. > > Your smoking gun just set itself on fire and burnt to death in a test run: > (2) smkelly@edgemaster:~$ cat /boot/loader.conf > ... > # Network > #miibus_load="YES" > if_xl_load="YES" # 3Com 3c900B-TPO > if_dc_load="YES" # NetGear FA310TX > if_ppp_load="YES" # PPP > ... > > Yet, it still comes up with if_dc.ko loaded and no if_xl.ko. Very poetic. Can you confirm that during the actual load process, if_xl was loaded before if_dc? I'm not certain that the ordering in loader.conf actually represents the order in which things are loaded. > On another similar note, a few minutes ago I realized that the > snd_emu10k1.ko module wasn't loading because: > Preloaded elf module "snd_emu10k1.ko" at 0xc037f544. > link_elf: symbol sndbuf_getbps undefined You need to get a grip on how things work here. The above is not indicative of a failure to load, but a failure to *link*. The process goes basically as follows: - Loader: - boot-conf reads loader.conf and iterates over all the variables in the environment, looking for *_load, and trying to load module files that match the variable name (if set to YES). - Dependancies listed in these module files are also loaded, and the load of a depending module is failed if its dependancies can't be loaded. - As each file is loaded, a record is kept of its name, location and size. This list is subsequently given to the kernel. - Kernel: - Early in the startup phase, the list of module files is scanned, and the kernel linker tries to link each one with the kernel. The result of the link is printed (eg. the link_elf quoted above). - The linking of these files also registers their linker set elements (SYSINITs, driver lists, etc.) > So, after the system was up I figured I'd try to reload it. I figured I > needed snd_pcm.ko or something, so I kldload'd it and locked my system > solid. Did kldstat -v show it already loaded? On the reboot after that, I went back to the 'ok' prompt in loader, > and decided to try 'load /modules/snd.ko'. It registered 5342532 different > sound modules (all of them I think), yet doing 'lsmod' in loader showed > NONE of them except the snd_emu10k1.ko from my loader.conf. lsmost should show loaded files, not modules. It sounds like it may not be working right, however. > Upon boot, > none of them were there. So, what happened to my 'load /modules/snd.ko'? Good question. I'll try to reproduce this, but I'm kinda hard up for time right now, so if anyone else feels like getting involved, I'd be much obliged. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message