Date: Tue, 20 Mar 2001 00:51:31 -0800 From: Mike Smith <msmith@freebsd.org> To: Sean Kelly <smkelly@zombie.org> Cc: Kris Kennaway <kris@obsecurity.org>, freebsd-stable@freebsd.org Subject: Re: Booting with modules Message-ID: <200103200851.f2K8pVg16380@mass.dis.org> In-Reply-To: Your message of "Tue, 20 Mar 2001 02:18:55 CST." <20010320021855.A433@edgemaster.zombie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103200851.f2K8pVg16380>