Re: Where to find... NOW: update - 2.6.15 on sarge: boots but some problems remain
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.
Reply to: