Message-ID: <3A0C3C53.1A8E7981@itc.nrcs.usda.gov>
Date: Fri, 10 Nov 2000 11:20:03 -0700
From: John Miller
Message-ID: <200011101407200819.4EC288AE@exchange1>
Date: Fri, 10 Nov 2000 14:07:20 -0500
From: "Tim Duggan"
We loaded SuSE 7.0 on our Compaq with 4 processors and 3 RAID controllers. It installed the 2.2.16 SMP kernel which makes sense for the multiprocessing. When we boot we get a choice of two kernels the first is Linux and the other is suse. By default it boots the linux kernel. Is this correct?
Difficult to say, do # uname -a see if that gives you more information.
We tried booting the suse kernel and it couldn't see all of our RAID controllers. It could only see one. I would appreciate if someone could shed some light on this.
I also noticed some patches for 7.0 in the kernel/compaq directory on the suse ftp site. Any clues what they are for?
Looking at the directory bootdisk = disk image compaq-update-2.2.17-SuSE.gz = patch for kernel cpqarray-smp.o = multiprocessor module for compaq array adapter cpqarray.o = uniprocessor version of above cpqfc-smp.o = multiprocessor module for compaq fiber channel adapter cpqfc.o = uniprocessor ver. of above my guess is the modules were compiled under 2.2.17 but maybe not as the kernel in 7.0, IIRC, is 2.2.16 so they might be compiled under that. Either way they should simply plug in. HTH, Tim
Message-ID: <3A0C4AC0.CEDFE180@itc.nrcs.usda.gov>
Date: Fri, 10 Nov 2000 12:21:36 -0700
From: John Miller
Difficult to say, do # uname -a see if that gives you more information.
Linux nasisdb 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown That is the default. We can't boot the suse kernel because of the problem with it only seeing one controller.
Looking at the directory bootdisk = disk image compaq-update-2.2.17-SuSE.gz = patch for kernel cpqarray-smp.o = multiprocessor module for compaq array adapter cpqarray.o = uniprocessor version of above cpqfc-smp.o = multiprocessor module for compaq fiber channel adapter cpqfc.o = uniprocessor ver. of above
my guess is the modules were compiled under 2.2.17 but maybe not as the kernel in 7.0, IIRC, is 2.2.16 so they might be compiled under that. Either way they should simply plug in.
Any idea on how to plug them in and do we want to do that? I am trying to figure out what we would gain from the suse kernel assuming we got it working. Thanks for the response. John
Message-ID: <200011101522580133.4F07C490@exchange1>
Date: Fri, 10 Nov 2000 15:22:58 -0500
From: "Tim Duggan"
Difficult to say, do # uname -a see if that gives you more information.
Linux nasisdb 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown
That is the default. We can't boot the suse kernel because of the problem with it only seeing one controller.
I'd say that was the right kernel as it has the proper support for your hardware.
Looking at the directory bootdisk = disk image compaq-update-2.2.17-SuSE.gz = patch for kernel cpqarray-smp.o = multiprocessor module for compaq array adapter cpqarray.o = uniprocessor version of above cpqfc-smp.o = multiprocessor module for compaq fiber channel adapter cpqfc.o = uniprocessor ver. of above
my guess is the modules were compiled under 2.2.17 but maybe not as the kernel in 7.0, IIRC, is 2.2.16 so they might be compiled under that. Either way they should simply plug in.
Any idea on how to plug them in and do we want to do that?
Normal modules are added with either # modprobe module_name or # insmod module_name _Do not_ insert the modules into the kernel that works, that might be the fastest way to lock up the machine tight. Since these are required to boot they would have to be in the initial ramdisk (initrd). That would require you to make another one, being careful that it is only used for the proper kernel. I just had a thought concerning initrd. Is the array support compiled into one kernel and loaded as a module in the other? If initrd is being used for both kernels and is trying to load the array controller module into the kernel that has support built in, it is very likely that it will stop the boot process cold. (This has happened to me when first intorduced to initrd.) The file /etc/lilo.conf will tell you which kernels are using it (assuming you are using lilo). When you try to boot the suse kernel does it stop while initializing the array? If so, try to use <shift>+<Pg Up> and see if it has already initialized them. If that is the case and the driver is being loaded twice, all you have to do is edit /etc/lilo.conf so that initrd only applies to the appropriate kernel. You can also search the archives at www.geocrawler.com as there was some discussion on this list with the introduction of initrd. also see http://sdb.suse.de/sdb/en/html/initrd.html
I am trying to figure out what we would gain from the suse kernel assuming we got it working.
AFAIK, the suse kernel will give you USB support and the ability to use LVM and reiserfs. There might be a couple of other things but those are the biggies that I am aware of. If you don't need the enhanced support then you are probably no worse off with the kernel that you have. Later, Tim
Message-ID: <3A0D0AF4.48BF0C73@technologist.com>
Date: Sat, 11 Nov 2000 10:01:41 +0100
From: Arjen Runsink
We tried booting the suse kernel and it couldn't see all of our RAID controllers. It could only see one. I would appreciate if someone could shed some light on this.
The kernel usually has the parameters set up for the first device which is on the standard adress/dma etc. So for the second and third you need to supply them at boot time from the lilo boot-menu or /etc/lilo.conf. You can get the info from the system menu you can enter at boot time. Also read the docs in /usr/src/kernel/Documents and maybe browse through the source to get some pointers. I have no experience with RAID controllers but this is the way to do it for NIC of the same make and type. BB, Arjen
From: Bernd Felsche
participants (4)
-
arjen＠technologist.com -
bernie＠innovative.iinet.net.au -
jmiller＠itc.nrcs.usda.gov -
tduggan＠dekaresearch.com