Re: ndiswrapper and sound - etch
On Tuesday 30 May 2006 8:37 pm, Hamish Moffatt wrote:
>
> Does the kernel (via dmesg or kern.log) report any errors? Unknown codec
> does sound like a problem. It's most likely a driver issue and not
> something you can fix except by upgrading ALSA.
some clues there.
kern.log:
May 30 06:26:53 slt kernel: input: PC Speaker as /class/input/input2
May 30 06:26:53 slt kernel: ACPI: PCI Interrupt 0000:00:14.5[B] -> Link [LNKB]
-
> GSI 10 (level, low) -> IRQ 10
dmesg:
MC'97 0 converters and GPIO not ready (0x1)
input: PC Speaker as /class/input/input2
ACPI: PCI Interrupt 0000:00:14.5[B] -> Link [LNKB] -> GSI 10 (level, low) ->
IRQ 10
From lshw id 14.5 is the sound card:
*-multimedia
description: Multimedia audio controller
product: IXP SB400 AC'97 Audio Controller
vendor: ATI Technologies Inc
physical id: 14.5
bus info: pci@00:14.5
version: 02
width: 32 bits
clock: 66MHz
capabilities: bus_master cap_list
configuration: driver=ATI IXP AC97 controller
resources: iomemory:c0003400-c00034ff irq:10
I notice from these same three locations (dmesg, kern.log and lshw) that
ndiswrapper is also using irq:10. Maybe its the (very old) DOS memories, but
could that be causing the problem?
I noted the entry in the dmesg output saying "If a device doesn't work, try
"pci=routeirq". " That raises two questions: (1) would this apply to my
situation? and (2) is that a kernel param similar to noapic?
> Which kernel do you have?
I have 2.6.15-1-amd64-generic
> > Just an aside, another person responded by saying to "use udev, that
> > should take care of the devices." As far as I can see, udev is being
> > used, but I don't know enough about udev to know how I can correct this
> > problem.
>
> udev creates the relevant entries in /dev/snd, but it won't be the cause
> here.
That helps. Thanks.
Scott
Reply to: