On Sun, Jan 15, 2006 at 01:19:15AM +0000, Adam James wrote: > On Sat, 2006-01-14 at 18:45 -0500, A. F. Cano wrote: > > > If you intend to generate an initrd image for your kernel, you'll need > > > to backport an unstable initrd generator (such as yaird or initramfs) > > > for it to play nice. > > > > Mmm... What's the advantage of doing this? Can I do without? Ok, > > I've downloaded the latest of both, just in case... > > An initrd image is a small ramdisk, which enables the kernel to load > modules without having to mount the partition containing /lib/modules. > > This is useful for distributions, as the kernel can remain small and > modular while supporting all possible hardware types. Essentially an > initrd image allows you to generate a "one size fits all" kernel that > will boot on the vast majority of hardware. > > If you ensure support for your disk controller is compiled into the > kernel, then there is no real need for an initrd image.
Thanks for the clarification (and to everyone else that replied). I was actually wondering if one of those two packages that don't exist in sarge were necessary. I had already found out long ago that a custom kernel based on the .config file of the standard distribution kernel wouldn't boot without an initrd image. In any case, here's what I did and, although I overcame some problems and the sarge computer in question now runs a 2.6.15 kernel, I still don't get anything on the input section of the second soundcard (SB0090 Audigy) in Kmix and can't record anything. Still, playback works and Kmix shows both sound cards. It appears that all the relevant drivers were loaded correctly, although there's some odd behavior in the assigning of the IRQs, which are probably the cause of the input part not working. It is not possible to remove the first sound card as it is built into the motherboard. One other thing: it appears that the kernel assigns devices (such as /dev/dsp and /dev/dsp1) randomly. Even though at the moment /dev/dsp is assigned to the audigy card and so xmms and other audio software work as expected, it has not been the case before. It would be nice if there were some application like ifrename to bind a specific sound card to /dev/dsp, /dev/dsp1, /dev/dspn, in the same way that ifrename binds eth0, eth1, etc... to specific hardware. Is there such an application? Or is there a way (via config files maybe) to force some order in the sound cards? I have used alsaconf to configure (and load the drivers for) only one sound card, but that doesn't solve the (likely) problem of lower level interrupt routing. Ok, so here's what I did: Downloaded the linux-source-2.6.15 deb file, installed it with dpkg -i. Used make-kpkg to create the kernel-image-2.6.15 deb file, after copying the /boot/config-2.6.8-1-i386 (the standard sarge kernel) to .config and answering (mostly with the default answers) all the new questions. Installed the resulting kernel-image-2.6.15 deb file with dpkg -i. Ran "mkinitrd -o /boot/initrd-2.6.15 /lib/modules/2.6.15" and then added "initrd /boot/initrd-2.6.15" to the /boot/menu.lst file under the proper entries for the new kernel. This was enough to get the system to boot the 2.6.15 kernel, but the first immediate result was that neither the sound card nor the old legacy ISA network card worked anymore. Out of the box the 2.6.15 kernel doesn't assign the IRQs properly, most likely it ignored the BIOS reserving irq 10 for the "legacy ISA card". I have sent a bug report about it. The only way to avoid this was to boot with the option pci=noacpi. Booting with this option, IRQ 10 was left alone for the network card and IRQ 9 was used for the following devices: 0a.0 (Audigy Audio), 0c.0 (Yamaha Audio, the on-board sound card), 0a.2 (the IEEE1394 interface on the Audigy sound card). Hopefully some tweaking of kernel options and manual setting of IRQs will fix this. Does anyone have any settings that work with the SB Audigy cards and kernel 2.6.15 (or any other 2.6 kernel)? Or should the kernel allocate properly the IRQs? Is it a problem that IRQ 9 is shared between these devices? or should all of them work as it stands now? If anyone wants to see the dmesg output, it's in the bug report (bug #348463) Thanks for any further help. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
