dapper upgrade no sound

Indra Polak indra at feeddex.nl
Fri Jul 21 08:54:45 UTC 2006


On Thu, 2006-07-20 at 13:26 -0400, Daniel T. Chen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Indra Polak wrote:
> > before the upgrade the right driver gets loaded before restoring
> > settings, after the upgrade the right driver is not loaded at all.
> > Why not? Can anyone explain to me in plain English why after the upgrade
> > the driver is not loaded?
> 
> In plain English, the sound driver does not recognise your card.
> 
> What is the output from ``lspci -nv''?
> 

Here it comes. I used lspci -v, but if you know your numbers:
0000:00:00.0 0600: 8086:2530 (rev 04)
        Subsystem: 1028:0145
        Flags: bus master, fast devsel, latency 0
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Capabilities: <available only to root>

0000:00:01.0 0604: 8086:2532 (rev 04)
        Flags: bus master, 66MHz, fast devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 0000e000-0000efff
        Memory behind bridge: ff800000-ff9fffff
        Prefetchable memory behind bridge: f8000000-fbffffff

0000:00:1e.0 0604: 8086:244e (rev 04)
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: ff600000-ff7fffff

0000:00:1f.0 0601: 8086:2440 (rev 04)
        Flags: bus master, medium devsel, latency 0

0000:00:1f.1 0101: 8086:244b (rev 04) (prog-if 80 [Master])
        Subsystem: 1028:0145
        Flags: bus master, medium devsel, latency 0
        I/O ports at ffa0 [size=16]

0000:00:1f.3 0c05: 8086:2443 (rev 04)
        Subsystem: 1028:0145
        Flags: medium devsel, IRQ 11
        I/O ports at ccf0 [size=16]

0000:01:00.0 0300: 1002:5446
        Subsystem: 1002:0408
        Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
IRQ 16
        Memory at f8000000 (32-bit, prefetchable) [size=64M]
        I/O ports at ec00 [size=256]
        Memory at ff8fc000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at 80000000 [disabled] [size=128K]
        Capabilities: <available only to root>

0000:02:01.0 0c03: 1106:3038 (rev 50)
        Subsystem: 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 19
        I/O ports at dce0 [size=32]
        Capabilities: <available only to root>

0000:02:01.1 0c03: 1106:3038 (rev 50)
        Subsystem: 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 18
        I/O ports at dcc0 [size=32]
        Capabilities: <available only to root>

0000:02:01.2 0c03: 1106:3104 (rev 51) (prog-if 20)
        Subsystem: 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 16
        Memory at ff6ffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: <available only to root>

0000:02:02.0 0c03: 1106:3038 (rev 50)
        Subsystem: 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 18
        I/O ports at dca0 [size=32]
        Capabilities: <available only to root>

0000:02:02.1 0c03: 1106:3038 (rev 50)
        Subsystem: 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 17
        I/O ports at dc80 [size=32]
        Capabilities: <available only to root>

0000:02:02.2 0c03: 1106:3104 (rev 51) (prog-if 20)
        Subsystem: 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 19
        Memory at ff6ff800 (32-bit, non-prefetchable) [size=256]
        Capabilities: <available only to root>

0000:02:07.0 0401: 1102:0002 (rev 08)
        Subsystem: 1102:8027
        Flags: bus master, medium devsel, latency 64, IRQ 16
        I/O ports at dc60 [size=32]
        Capabilities: <available only to root>

0000:02:07.1 0980: 1102:7002 (rev 08)
        Subsystem: 1102:0020
        Flags: bus master, medium devsel, latency 64
        I/O ports at dc58 [size=8]
        Capabilities: <available only to root>

0000:02:0c.0 0200: 8086:1229 (rev 10)
        Subsystem: 1028:0145
        Flags: bus master, medium devsel, latency 64, IRQ 18
        Memory at ff6fe000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at dc00 [size=64]
        Memory at ff6c0000 (32-bit, non-prefetchable) [size=128K]
        Capabilities: <available only to root>

The relevant entries from lspci -v:

0000:02:07.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
(rev 08)
        Subsystem: Creative Labs CT4832 SBLive! Value
        Flags: bus master, medium devsel, latency 64, IRQ 16
        I/O ports at dc60 [size=32]
        Capabilities: <available only to root>

0000:02:07.1 Input device controller: Creative Labs SB Live! MIDI/Game
Port (rev 08)
        Subsystem: Creative Labs Gameport Joystick
        Flags: bus master, medium devsel, latency 64
        I/O ports at dc58 [size=8]
        Capabilities: <available only to root>


Looks ok to me?


> > How are devices to be configured which have dynamically loaded drivers?
> 
> They do so via udev already. If your hardware is not activated
> automatically, then either there is no active driver for it (not
> relevant in your case) or the kernel has a driver but does not recognise
> it (relevant in your case based on missing pci {sub,}system &
> {sub,}vendor ids - and yes, pci ids are juggled from release to release
> upstream).
> 


Some things I do not understand:

"If your hardware is not activated automatically..." it is activated
automatically because its driver gets loaded at boot time using an entry
in /etc/modules. There is no manual 
action involved. I think you mean "If some piece of code (udev) does not
recognize your card at some time (when udev runs) in the boot process".

Then there is the fact that it did work before the upgrade, it is an old
card so why would there be a change in the {sub,}system & {sub,}vendor
ids?
What is the point of having these ID's when they change overnight for
older cards?
--O yeah, we changed the ids, so from now on some (version) of the card
has the old id, and some (newer) version (but the same card of course) 
can be recognized using the new id.

Then someone thinks: well, lets change the recognition process by
assuming every card has the newer id, so everyone with a card 
bought before date X must buy a new card. This makes no sense.


I have a kernel Oops in my dmesg, maybe this destroys the proper
recognision?
But here the module is already loaded (because of the entry
in /etc/modules? when I remove that line I get the same Oops
but without the snd_... modules)
...
[4294695.976000] Intel ISA PCIC probe: not found.
[4294695.976000] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[4294695.976000]  printing eip:
[4294695.976000] c0112cac
[4294695.976000] *pde = 00000000
[4294695.976000] Oops: 0000 [#1]
[4294695.976000] Modules linked in: i82365 rsrc_nonstatic pcmcia_core
ipv6 af_packet reiserfs dm_mod md snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_seq_dummy snd_seq_oss snd_seq_midi
snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_seq_device
snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer
snd_page_alloc snd_util_mem snd_hwdep snd soundcore psmouse mousedev
parport_pc lp parport ext3 jbd thermal processor fan usbhid e100 mii
ehci_hcd uhci_hcd usbcore ide_cd cdrom ide_disk ide_generic piix
ide_core unix vesafb capability commoncap vga16fb vgastate softcursor
cfbimgblt cfbfillrect cfbcopyarea fbcon tileblit font bitblit
[4294695.976000] CPU:    0
[4294695.976000] EIP:    0060:[<c0112cac>]    Not tainted VLI
[4294695.976000] EFLAGS: 00010086   (2.6.12-9-386)
[4294695.976000] EIP is at __wake_up_common+0xf/0x47
[4294695.976000] eax: f8c83c48   ebx: 00000001   ecx: f8c7fe30   edx:
00000000
[4294695.976000] esi: c02ea2c8   edi: f8c83c48   ebp: df9adf38   esp:
df9adf28
[4294695.976000] ds: 007b   es: 007b   ss: 0068
[4294695.976000] Process modprobe (pid: 3752, threadinfo=df9ac000
task=df8d8a20)
[4294695.976000] Stack: c02ea2e0 00000286 c02ea2c8 c02ea2e0 df9adf58
c0112d5a f8c83c48 00000003
[4294695.976000]        00000001 00000000 00000000 f8c8296c c02ea5c4
c019965b f8c82948 f8c82984
[4294695.976000]        c0199680 c0000000 df9ac000 c0199d92 f8c8296c
00000000 f8c828c0 c01996a0
[4294695.976000] Call Trace:
[4294695.976000]  [<c0112d5a>] complete+0x1a/0x24
[4294695.976000]  [<c019965b>] kobject_cleanup+0x40/0x65
[4294695.976000]  [<c0199680>] kobject_release+0x0/0xa
[4294695.976000]  [<c0199d92>] kref_put+0x46/0x54
[4294695.976000]  [<c01996a0>] kobject_put+0x16/0x19
[4294695.976000]  [<c0199680>] kobject_release+0x0/0xa
[4294695.976000]  [<f8c5dda8>] init_i82365+0x70/0x165 [i82365]
[4294695.976000]  [<c0129682>] sys_init_module+0xb5/0x172
[4294695.976000]  [<c0102e9f>] sysenter_past_esp+0x54/0x75
[4294695.976000] Code: 08 03 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 8b 45 08
8b 50 04 89 55 08 5d e9 07 f8 ff ff 55 89 e5 57 56 53 57 8b 7d 08 8b 5d
10 8b 17 <8b> 02 39 fa 89 45 f0 74 27 8b 72 f4 ff 75 18 8d 42 f4 ff 75
14
[4294695.976000]  <6>Real Time Clock Driver v1.12

Maybe here the module tries to load but fails for some reason (because
it is done by udev), while later (when it is done by
S15module-init-tools) it succeeds.
Or maybe it fails because it is already loaded, or...? It probably has
nothing to do with the sound config since at this point the driver is
already 
loaded.

My thoughts: this udev thingy is not doing its job. You say well the
udev system should also handle dynamic modules, but as I already
showed, 
then the sound does not get restored. So even though a dynamic driver is
loaded which should trigger the udev init action, and at that point 
the card is recognized and operational, udev does not restore its
settings. So udev only restores when it ADD's the module itself, not
when done later 
by another process. 

How can it be that some parts of the OS do know that the sound card is
present and operational (I hear sound after unmuting) while other parts 
(this udev part) is ignorant (since it is not restoring the settings by
itself).

I looked in 
/usr/share/misc/pci.ids
for my card id.

Here it is:

1102  Creative Labs
        0002  SB Live! EMU10k1
                1102 0020  CT4850 SBLive! Value
                1102 0021  CT4620 SBLive!
                1102 002f  SBLive! mainboard implementation
                1102 4001  E-mu APS
                1102 8022  CT4780 SBLive! Value
                1102 8023  CT4790 SoundBlaster PCI512
                1102 8024  CT4760 SBLive!
                1102 8025  SBLive! Mainboard Implementation
                1102 8026  CT4830 SBLive! Value
                1102 8027  CT4832 SBLive! Value
^^^^^^^^^^^^^^^^^^^^^^^^^^That's the one
                1102 8028  CT4760 SBLive! OEM version
                1102 8031  CT4831 SBLive! Value
                1102 8040  CT4760 SBLive!
                1102 8051  CT4850 SBLive! Value
                1102 8061  SBLive! Player 5.1
                1102 8064  SBLive! 5.1 Model SB0100
                1102 8065  SBLive! 5.1 Digital Model SB0220
                1102 8067  SBLive! 5.1 eMicro 28028



> > (Solution now follows.)
> 
> It happens to work in your case, but it is not correct. The ultimate
> issue is that the kernel driver (snd-emu10k1) does not contain the pci
> id for your hardware. Fix that, and you have fixed the real issue.
> 


The kernel driver snd-emu10k1 can look in /usr/share/misc/pci.ids to get
the id?


Correct, correct...it works for me. The "correct" way does not work for
me. Probably 
some other changed component after the upgrade is not totally correct
either.

Thanks,

Indra Polak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20060721/20bb1597/attachment.html>


More information about the ubuntu-users mailing list