RE: [gentoo-user] udev/initramfs problem
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
[gentoo-user] udev/initramfs problem
Title: udev/initramfs problem
We have several dual cpu systems - half intel, the other half AMD.
For our purposes, we are building to the i686 arch.
The hosts with the below described problem are running on Tyan mother
boards with LSI Logic SCSI controllers embedded in PCI-E bus.
We rescently upgraded to the 2.6.15-r1 kernel and life is great on the
systems that use the adaptec scsi controllers. However, LSI Logic does
not appear to be seen by udev or, more likely, initramfs facilities.
Consequently, no root device is found.
I am missing something but don't know what. Below is the output of
#lshw -short
H/W path Device Class Description
===
system S2895
/0 bus S2895
/0/1 memory BIOS
/0/3 processor Dual Core AMD Opteron(tm) Processor 275
/0/3/6 memory L1 cache
/0/3/7 memory L2 cache
/0/5 processor Dual Core AMD Opteron(tm) Processor 275
/0/5/8 memory L1 cache
/0/5/9 memory L2 cache
/0/d memory System Memory
/0/d/0 memory DIMM DRAM Synchronous [empty]
/0/d/1 memory DIMM DRAM Synchronous [empty]
/0/d/2 memory DIMM DRAM Synchronous
/0/d/3 memory DIMM DRAM Synchronous
/0/d/4 memory DIMM DRAM Synchronous [empty]
/0/d/5 memory DIMM DRAM Synchronous [empty]
/0/d/6 memory DIMM DRAM Synchronous [empty]
/0/d/7 memory DIMM DRAM Synchronous [empty]
/0/4 memory CK804 Memory Controller
/0/0 memory CK804 Memory Controller
/0/100 bridge CK804 ISA Bridge
/0/1.1 bus CK804 SMBus
/0/2 bus CK804 USB Controller
/0/2/1 usb2 bus nVidia Corporation CK804 USB Controller
/0/2/1/1 input Microsoft IntelliMouse
/0/2/1/3 input Logitech USB Keyboard
/0/2.1 bus CK804 USB Controller
/0/2.1/1 usb1 bus nVidia Corporation CK804 USB Controller
/0/c multimedia CK804 AC'97 Audio Controller
/0/6 storage CK804 IDE
/0/6/0 ide0 bus IDE Channel 0
/0/6/0/0 /dev/hda disk PLEXTOR DVDR PX-740A
/0/6/0/1 /dev/hdb disk PLEXTOR DVDR PX-740A
/0/7 storage CK804 Serial ATA Controller
/0/8 storage CK804 Serial ATA Controller
/0/9 bridge CK804 PCI Bridge
/0/9/5 bus TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
/0/101 eth0 bridge CK804 Ethernet Controller
/0/102 eth1 bridge CK804 Ethernet Controller
/0/103 bridge CK804 PCIE Bridge
/0/103/0 display GeForce 7800 GTX
/0/104 bridge CK804 PCIE Bridge
/0/105 bridge K8 [Athlon64/Opteron] HyperTransport Technology Configuration
/0/106 bridge K8 [Athlon64/Opteron] HyperTransport Technology Configuration
/0/107 bridge K8 [Athlon64/Opteron] Address Map
/0/108 bridge K8 [Athlon64/Opteron] Address Map
/0/109 bridge K8 [Athlon64/Opteron] DRAM Controller
/0/10a bridge K8 [Athlon64/Opteron] DRAM Controller
/0/10b bridge K8 [Athlon64/Opteron] Miscellaneous Control
/0/10c bridge K8 [Athlon64/Opteron] Miscellaneous Control
/0/a bridge AMD-8131 PCI-X Bridge
/0/b bridge AMD-8131 PCI-X Bridge
/0/b/6 scsi6 storage 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI
/0/b/6/0.0.0 /dev/sda disk ST373454LW
/0/b/6.1 storage 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI
/0/a.1 system AMD-8131 PCI-X IOAPIC
/0/b.1 system AMD-8131 PCI-X IOAPIC
/0/e memory CK804 Memory Controller
/1 scsi7 storage
/2 eth2 network IEEE1394 interface
===
# udevinfo
looking at device '/block/sda':
KERNEL==sda
SUBSYSTEM==block
SYSFS{stat}== 7619 2368 320031 96813 4146 2814 55474 22018 0 30875 118830
SYSFS{size}==143374744
SYSFS{removable}==0
SYSFS{range}==16
SYSFS{dev}==8:0
looking at device '/devices/pci:08/:08:0b.0/:0a:06.0/host6/target6:0:0/6:0:0:0':
ID==6:0:0:0
BUS==scsi
DRIVER==sd
SYSFS{ioerr_cnt}==0x0
SYSFS{iodone_cnt}==0x2e11
SYSFS{iorequest_cnt}==0x2e11
SYSFS{iocounterbits}==32
SYSFS{timeout}==30
SYSFS{state}==running
SYSFS{rev}==0003
SYSFS{model}==ST373454LW
SYSFS{vendor}==SEAGATE
SYSFS{scsi_level}==4
SYSFS{type}==0
SYSFS{queue_type}==simple
SYSFS{device_blocked}==0
SYSFS{queue_depth}==31
looking at device '/devices/pci:08/:08:0b.0/:0a:06.0/host6/target6:0:0':
ID==target6:0:0
BUS==
DRIVER==
looking at device '/devices/pci:08/:08:0b.0/:0a:06.0/host6':
ID==host6
BUS==
DRIVER==
looking at device '/devices/pci:08/:08:0b.0/:0a:06.0':
ID==:0a:06.0
BUS==pci
DRIVER==mptbase
SYSFS{config}==
SYSFS{modalias}==pci:v1000d0030sv10F1sd2895bc01sc00i00
SYSFS{local_cpus}==0f
SYSFS{irq}==193
SYSFS{class}==0x01
SYSFS{subsystem_device}==0x2895
SYSFS{subsystem_vendor}==0x10f1
SYSFS{device}==0x0030
SYSFS{vendor}==0x1000
looking at device '/devices/pci:08/:08:0b.0':
ID==:08:0b.0
BUS==pci
DRIVER==
SYSFS{modalias}==pci:v1022d7450svsdbc06sc04i00
SYSFS{local_cpus}==0f
SYSFS{irq}==0
SYSFS{class}==0x060400
SYSFS{subsystem_device}==0x
SYSFS{subsystem_vendor}==0x
SYSFS{device}==0x7450
SYSFS{vendor}==0x1022
looking at device '/devices/pci:08':
ID==pci:08
BUS==
DRIVER==
==
Any clues
Re: [gentoo-user] udev/initramfs problem
Hi, On Tue, 18 Apr 2006 09:44:09 -0500 Johnson, Maurice E CTR NSWCDL-K74 [EMAIL PROTECTED] wrote: We rescently upgraded to the 2.6.15-r1 kernel and life is great on the systems that use the adaptec scsi controllers. However, LSI Logic does not appear to be seen by udev or, more likely, initramfs facilities. Consequently, no root device is found. Hm? The initramfs is in charge to load proper modules, if needed. But there shouldn't be a root device if there's an initramfs. Are you talking about the staged root which is going to be pivot'ed when the initramfs is done? I am missing something but don't know what. Below is the output of [...] How has the cited output been made? From initramfs system? My questions would be: - is the driver for the LSI controller compiled into the kernel? - if it isn't, is the module contained in the initramfs? Is it a module for the right kernel? - and how is the module to be loaded by the initramfs? - is there a static or a dynamic /dev in the initramfs? - if dynamic, how is it managed? - what are the commands the initramfs uses to stage into real root? -hwh -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] udev/initramfs problem
The current kernel build process is simply: # genkernel -- menuconfig --install all make.profile=2006.0 gcc=3.4.5-r1 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. 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. 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. So, to answer your questions: - is the driver for the LSI controller compiled into the kernel? I have built the driver both ways - if it isn't, is the module contained in the initramfs? Is it a module for the right kernel? The module is contained within the initramfs and loads (manually) - 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. - if dynamic, how is it managed? - what are the commands the initramfs uses to stage into real root? I will look deeper for this one. Ultimately, when the time comes to pivot, the disk that would be /dev/sda is not available and, therefore, /dev/sda2 is likewise unavailable. 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. Thank you for your time. MEJ -Original Message- From: Hans-Werner Hilse [mailto:[EMAIL PROTECTED] Sent: Tue 4/18/2006 11:05 AM To: gentoo-user@lists.gentoo.org Cc: Subject:Re: [gentoo-user] udev/initramfs problem Hi, On Tue, 18 Apr 2006 09:44:09 -0500 Johnson, Maurice E CTR NSWCDL-K74 [EMAIL PROTECTED] wrote: We rescently upgraded to the 2.6.15-r1 kernel and life is great on the systems that use the adaptec scsi controllers. However, LSI Logic does not appear to be seen by udev or, more likely, initramfs facilities. Consequently, no root device is found. Hm? The initramfs is in charge to load proper modules, if needed. But there shouldn't be a root device if there's an initramfs. Are you talking about the staged root which is going to be pivot'ed when the initramfs is done? I am missing something but don't know what. Below is the output of [...] How has the cited output been made? From initramfs system? My questions would be: - is the driver for the LSI controller compiled into the kernel? - if it isn't, is the module contained in the initramfs? Is it a module for the right kernel? - and how is the module to be loaded by the initramfs? - is there a static or a dynamic /dev in the initramfs? - if dynamic, how is it managed? - what are the commands the initramfs uses to stage into real root? -hwh -- gentoo-user@gentoo.org mailing list winmail.dat
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
