Hi, When I say that the driver structure (modular build) has changed, I mean to say that in previous encarnations only two modules were loaded (mptbase, mptscsih). Now, the transport portion is also loaded as, in this case, mptspi.
Genkernel creates the initramfs. unfortunately, I am not as familiar with that process as I would like to be - working that also. Within the initramfs building process under genkernel, all required modules are specified along with the creation of klibc, busybox and ash with udevd and coldplug - (which also includes hotplug) I have also noticed that the device in question is not seen in the 2006.0 Gentoo livecd which uses kernel 2.6.15-r5. Again, the modules are loadable but the LSI hardware is not seen. And, of course no machine without the LSI chipset has this problem. You bring up and interesting question with respect to hotplug. I'm going to build a kernel the old fassioned way (without genkernel) and see where it gets me. I'm not sure, given the additional failure on the part of the 2006.0 livecd, exactly where the problem is - udev or initramfs. MEJ -----Original Message----- From: Hans-Werner Hilse [mailto:[EMAIL PROTECTED] Sent: Tue 4/18/2006 4:59 PM To: gentoo-user@lists.gentoo.org Cc: Subject: Re: [gentoo-user] udev/initramfs problem Hi, On Tue, 18 Apr 2006 11:25:52 -0500 "Johnson, Maurice E CTR NSWCDL-K74" <[EMAIL PROTECTED]> wrote: > # genkernel -- menuconfig --install all Hm, I don't really know genkernel. Does it create the initramfs? > When in the ash shell environment, I notice that there are few static > nodes in /dev. ( i.e. console, pty etc.) In this environment, I am > able to load the modules manually, but still no device is visible in /dev. Then there's either no daemon that creates the devices (udev) or it isn't somehow configured correctly. > I note that the MPT driver structure has changed as well for this > kernel - which, I have built both modularly and strait into the kernel. Somehow I doubt that. Usually you have it either the one way or the other. But as you said you could load them, I guess they're modules. You might want to try to recompile a kernel with all drivers compiled in. > I have been doing a great deeal of reading and have found that klibc > may be an issue, however, building older (2.6.12-r4) kernels works > without error. Also noted here is that 2.6.12-r4 still has devfs > features available. That would explain it. udev would be needed in the initramfs to create devices upon module loading. > >>> The module is contained within the initramfs and loads (manually) So there's no hotplugging or similar. Try to compile the drivers directly into the kernel. > - and how is the module to be loaded by the initramfs? > >>> My presumption is that the rules within 50-udev.rules provide for this. > - is there a static or a dynamic /dev in the initramfs? > >>> My best discription here is dynamic with a few static nodes present. Ah, this _is_ in the initramfs? Is there a udevd spawned in initramfs? > I beleive that it is at the PCI level where this failure occures, > because, if the PCI interface ti the controler were properly handled, > then the scsi bus it provides would be available. Is "dmesg" available in initramfs? It may contain hints upon module loading. But at that time those hints should be print out to console, anyway. You're shure that those are the correct drivers, aren't you? -hwh -- gentoo-user@gentoo.org mailing list
<<winmail.dat>>
