[alsa-devel] [BUG] NULL pointer dereference in patch_sigmatel.c
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I'm attaching the alsa-info output on a working system with 1.0.18a. The kernel version in subject is 2.6.25.20.
Thanks, Ozan
------------------------
First the BUG's trace: ------------------------
BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f8cdb83a>] :snd_hda_codec_idt:stac92xx_add_jack+0x84/0x9e *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: snd_hda_codec_idt snd_hda_intel(+) snd_hda_codec aes_i586 aes_generic ipv6 af_packet bridge bnep rfcomm l2cap microcode acpi_cpufreq cpufreq_powersave cpufreq_userspace cpufreq_conservative ndiswrapper vboxdrv pcmcia snd_hwdep rtc_cmos rtc_core yenta_socket tpm_infineon snd_seq_dummy rtc_lib tpm snd_seq_oss rsrc_nonstatic tpm_bios tifm_7xx1 iTCO_wdt snd_seq_midi_event tifm_core i2c_i801 snd_seq iTCO_vendor_support pcmcia_core r5u870 arc4 joydev snd_seq_device snd_pcm_oss nvidia(P) battery sg usbcam snd_mixer_oss ecb ac videobuf_dma_sg videobuf_core sony_laptop snd_pcm uvcvideo iwl4965 video compat_ioctl32 snd_timer output hci_usb iwlcore videodev thermal bluetooth snd processor v4l1_compat rfkill button led_class soundcore firmware_class snd_page_alloc mac80211 intel_agp i2c_core sky2 cfg80211 agpgart ext3 jbd mbcache sr_mod cdrom sd_mod ata_piix uhci_hcd pata_acpi ehci_hcd usbcore ohci1394 ieee1394 ata_generic libata scsi_mod dock
Pid: 1977, comm: modprobe Tainted: P (2.6.25.20-114 #1) EIP: 0060:[<f8cdb83a>] EFLAGS: 00210206 CPU: 0 EIP is at stac92xx_add_jack+0x84/0x9e [snd_hda_codec_idt] EAX: 00000000 EBX: f8c7973e ECX: 00000004 EDX: f8cdeb1a ESI: 03211020 EDI: f675c600 EBP: f68d7d20 ESP: f68d7cd4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 1977, ti=f68d6000 task=f69ece60 task.ti=f68d6000) Stack: f68d7cf4 f8cdeb0a f8c796d5 f8c7973e f8c79793 00000001 000a69e0 f8c79793 4f205048 61207475 78452074 654c2074 4a207466 006b6361 f6898800 f6898800 00000000 f6898800 f6898800 f68d7d4c f8cdbac0 f65ef000 f6970000 00000001 Call Trace: [<f8cdbac0>] ? stac92xx_build_controls+0x26c/0x2d0 [snd_hda_codec_idt] [<f8c73aa9>] ? snd_hda_codec_build_controls+0x31/0x3d [snd_hda_codec] [<f8c750d3>] ? snd_hda_build_controls+0x18/0x67 [snd_hda_codec] [<f8c69138>] ? azx_probe+0x79e/0x840 [snd_hda_intel] [<f8c68857>] ? azx_send_cmd+0x0/0x101 [snd_hda_intel] [<f8c686a6>] ? azx_get_response+0x0/0x1b1 [snd_hda_intel] [<f8c67ece>] ? azx_attach_pcm_stream+0x0/0x15c [snd_hda_intel] [<f8c67b84>] ? azx_bus_reset+0x0/0x56 [snd_hda_intel] [<f8c67a40>] ? azx_power_notify+0x0/0x57 [snd_hda_intel] [<c01e7a37>] ? pci_device_probe+0x39/0x59 [<c024395f>] ? driver_probe_device+0xa0/0x136 [<c0243a50>] ? __driver_attach+0x5b/0x91 [<c024333c>] ? bus_for_each_dev+0x3b/0x63 [<c0243804>] ? driver_attach+0x14/0x16 [<c02439f5>] ? __driver_attach+0x0/0x91 [<c0242d3a>] ? bus_add_driver+0x9d/0x1ba [<c0243bc4>] ? driver_register+0x47/0xa7 [<c0168681>] ? __vunmap+0x93/0x9b [<c01e7bec>] ? __pci_register_driver+0x35/0x61 [<f8afd017>] ? alsa_card_azx_init+0x17/0x19 [snd_hda_intel] [<c0141f9c>] ? sys_init_module+0x18ad/0x19ca [<c0109c77>] ? do_syscall_trace+0x138/0x17f [<c0104a2e>] ? syscall_call+0x7/0xb ======================= Code: f9 ff 89 45 d0 89 f0 e8 29 68 f9 ff 89 c3 89 f0 e8 32 68 f9 ff ff 75 d0 53 50 68 0a eb cd f8 8d 45 d4 50 e8 45 25 50 c7 8b 47 08 <89> 78 74 8b 47 08 83 c4 14 c7 40 78 7f a2 cd f8 31 c0 8d 65 f4 EIP: [<f8cdb83a>] stac92xx_add_jack+0x84/0x9e [snd_hda_codec_idt] SS:ESP 0068:f68d7cd4 ---[ end trace 4a628a5b4fc302e7 ]---
alsa-info output: -------------------
upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.4.52 !!################################
!!Script ran on: Sun Feb 8 19:15:27 EET 2009
!!Linux Distribution !!------------------
Pardus 2008.2 Canis aureus
!!Kernel Information !!------------------
Kernel release: 2.6.25.20-114 Operating System: GNU/Linux Architecture: i686 Processor: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz SMP Enabled: Yes
!!ALSA Version !!------------
Driver version: 1.0.18a Library version: 1.0.18 Utilities version: 1.0.18
!!Loaded ALSA modules !!-------------------
snd_hda_intel
!!Soundcards recognised by ALSA !!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfc300000 irq 21
!!PCI Soundcards installed in the system !!--------------------------------------
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 09:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
!!Advanced information - PCI Vendor/Device/Susbsystem ID's !!--------------------------------------------------------
00:1b.0 0403: 8086:284b (rev 03) Subsystem: 104d:9008
!!Modprobe options (Sound related) !!--------------------------------
snd-hda-intel: model=vaio
!!Loaded sound module options !!--------------------------
!!Module: snd_hda_intel bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1 enable : Y,Y,Y,Y,Y,Y,Y,Y enable_msi : 0 id : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL> index : -1,-1,-1,-1,-1,-1,-1,-1 model : vaio,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL> position_fix : 0,0,0,0,0,0,0,0 power_save : 0 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1 single_cmd : N
!!HDA-Intel Codec information !!--------------------------- --startcollapse--
Codec: SigmaTel STAC9872AK Address: 0 Vendor Id: 0x83847662 Subsystem Id: 0x104d1e00 Revision Id: 0x100201 No Modem Function Group found Default PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1 GPIO: io=5, o=0, i=0, unsolicited=1, wake=1 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Amp-Out caps: N/A Amp-Out vals: [0x7f 0x7f] Converter: stream=0, channel=0 Power: setting=D0, actual=D0 Delay: 13 samples Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 Power: setting=D0, actual=D0 Delay: 13 samples Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Amp-Out caps: N/A Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 Power: setting=D0, actual=D0 Delay: 13 samples Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Amp-Out caps: N/A Amp-Out vals: [0x7f 0x7f] Converter: stream=0, channel=0 Power: setting=D0, actual=D0 Delay: 13 samples Node 0x06 [Audio Input] wcaps 0x1d0541: Stereo Converter: stream=0, channel=0 SDI-Select: 0 Power: setting=D0, actual=D0 Delay: 13 samples Connection: 1 0x07 Processing caps: benign=0, ncoeff=0 Node 0x07 [Audio Selector] wcaps 0x300903: Stereo Amp-In R/L Amp-In caps: N/A Amp-In vals: [0x00 0x00] Connection: 1 0x0e Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo Converter: stream=0, channel=0 SDI-Select: 0 Power: setting=D0, actual=D0 Delay: 13 samples Connection: 1 0x09 Processing caps: benign=0, ncoeff=0 Node 0x09 [Audio Selector] wcaps 0x300903: Stereo Amp-In R/L Amp-In caps: N/A Amp-In vals: [0x0d 0x0d] Connection: 1 0x15 Node 0x0a [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0000173c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x03211020: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x80: HP VREF_HIZ Unsolicited: tag=04, enabled=1 Connection: 1 0x02 Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x00000014: OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 1 0x04 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x00000014: OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 1 0x03 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0000173c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x03a15030: [Jack] Mic at Ext Left Conn = 1/8, Color = Red DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 1 0x02 Node 0x0e [Pin Complex] wcaps 0x400081: Stereo Pincap 0x00000024: IN Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x00000014: OUT Detect Pin Default 0x90170110: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x05 Node 0x10 [Audio Output] wcaps 0x40211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x3e0]: 44100 48000 88200 96000 176400 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Delay: 4 samples Node 0x11 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Connection: 2 0x10* 0x09 Node 0x12 [Audio Input] wcaps 0x140311: Stereo Digital Converter: stream=0, channel=0 SDI-Select: 0 Digital: Digital category: 0x0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Delay: 4 samples Connection: 1 0x13 Node 0x13 [Pin Complex] wcaps 0x440381: Stereo Digital Pincap 0x00000034: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Delay: 4 samples Connection: 1 0x18 Node 0x14 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x00000020: IN Pin Default 0x90a7013e: [Fixed] Mic at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x3, Sequence = 0xe Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=1 Amp-Out vals: [0x00 0x00] Connection: 4 0x0a 0x0d 0x14* 0x02 Node 0x16 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00] Node 0x17 [Volume Knob Widget] wcaps 0x600000: Mono Volume-Knob: delta=1, steps=127, direct=0, val=127 Connection: 4 0x02* 0x03 0x04 0x05 Node 0x18 [Audio Output] wcaps 0x40201: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 Delay: 4 samples Codec: Conexant ID 2c06 Address: 1 Vendor Id: 0x14f12c06 Subsystem Id: 0x104d1700 Revision Id: 0x100000 Modem Function Group: 0x2 --endcollapse--
!!ALSA Device nodes !!-----------------
crw-rw----+ 1 root audio 116, 0 Şub 8 2009 /dev/snd/controlC0 crw-rw----+ 1 root audio 116, 4 Şub 8 2009 /dev/snd/hwC0D0 crw-rw----+ 1 root audio 116, 5 Şub 8 2009 /dev/snd/hwC0D1 crw-rw----+ 1 root audio 116, 24 Şub 8 19:14 /dev/snd/pcmC0D0c crw-rw----+ 1 root audio 116, 16 Şub 8 19:15 /dev/snd/pcmC0D0p crw-rw----+ 1 root audio 116, 1 Şub 8 2009 /dev/snd/seq crw-rw----+ 1 root audio 116, 33 Şub 8 2009 /dev/snd/timer
!!ALSA configuration files !!------------------------
!!System wide config file (/etc/asound.conf)
# PulseAudio plugin configuration
# Let's create a virtual device "pulse" for mixer and PCM
pcm.pulse { type pulse hint { description "PulseAudio Sound Server" } }
ctl.pulse { type pulse hint { description "PulseAudio Sound Server" } }
# Let's make it the default!
pcm.!default { type pulse hint { description "Default" } }
ctl.!default { type pulse hint { description "Default" } }
!!Aplay/Arecord output !!------------
APLAY
**** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 1/1 Subdevice #0: subdevice #0
ARECORD
**** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 1/1 Subdevice #0: subdevice #0
!!Amixer output !!-------------
!!-------Mixer controls for card 0 [Intel]
Card hw:0 'Intel'/'HDA Intel at 0xfc300000 irq 21' Mixer name : 'SigmaTel STAC9872AK' Components : 'HDA:83847662,104d1e00,00100201 HDA:14f12c06,104d1700,00100000' Controls : 10 Simple ctrls : 7 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 127 Mono: Playback 127 [100%] [0.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 127 [100%] [0.00dB] [on] Front Right: Playback 127 [100%] [0.00dB] [on] Simple mixer control 'PCM',0 Capabilities: pvolume cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Playback channels: Front Left - Front Right Capture channels: Mono Limits: Playback 0 - 255 Mono: Capture [off] Front Left: Playback 0 [0%] [-51.00dB] Front Right: Playback 0 [0%] [-51.00dB] Simple mixer control 'Mic Jack',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 13 [87%] [19.50dB] [on] Front Right: Capture 13 [87%] [19.50dB] [on] Simple mixer control 'Internal Mic',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 127 [100%] [0.00dB] [on] Front Right: Playback 127 [100%] [0.00dB] [on]
!!Alsactl output !!-------------
--startcollapse-- state.Intel { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 127' comment.dbmin -9525 comment.dbmax 0 iface MIXER name 'Headphone Playback Volume' value.0 127 value.1 127 } control.2 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true } control.3 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 127' comment.dbmin -9525 comment.dbmax 0 iface MIXER name 'Speaker Playback Volume' value.0 127 value.1 127 } control.4 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Speaker Playback Switch' value.0 true value.1 true } control.5 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 15' comment.dbmin 0 comment.dbmax 2250 iface MIXER name 'Capture Volume' value.0 13 value.1 13 } control.6 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' value.0 true value.1 true } control.7 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Mic Jack' comment.item.1 'Internal Mic' comment.item.2 PCM iface MIXER name 'Capture Source' value 'Internal Mic' } control.8 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 127' comment.dbmin -9525 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value 127 } control.9 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Master Playback Switch' value true } control.10 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 0 value.1 0 } } --endcollapse--
!!All Loaded Modules !!------------------
Module aes_i586 aes_generic ipv6 bridge bnep af_packet rfcomm l2cap microcode acpi_cpufreq cpufreq_powersave cpufreq_userspace ndiswrapper r5u870 usbcam videobuf_dma_sg snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event videobuf_core nvidia snd_seq uvcvideo snd_seq_device snd_pcm_oss arc4 compat_ioctl32 ecb snd_mixer_oss intel_agp snd_pcm iwl4965 snd_timer snd_page_alloc snd_hwdep snd pcmcia hci_usb rtc_cmos bluetooth yenta_socket rsrc_nonstatic tpm_infineon pcmcia_core tifm_7xx1 sky2 battery videodev iTCO_wdt agpgart ac thermal processor iwlcore rfkill led_class firmware_class i2c_i801 mac80211 video output tpm tpm_bios rtc_core rtc_lib joydev iTCO_vendor_support tifm_core sony_laptop v4l1_compat i2c_core sg button soundcore cfg80211 ext3 jbd mbcache sr_mod cdrom sd_mod ata_piix ohci1394 ieee1394 uhci_hcd pata_acpi ata_generic libata scsi_mod dock ehci_hcd usbcore
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
I'm attaching the alsa-info output on a working system with 1.0.18a. The kernel version in subject is 2.6.25.20.
Thanks, I'll take a look.
Takashi
At Fri, 17 Jul 2009 11:33:08 +0200, I wrote:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
Looking through the stack trace, it's not...
But, I don't see any problem in the current code. It could be a bug in the wrapper for older kernels. Anyway, checking with the very latest snapshot would be helpful.
Takashi
Takashi Iwai wrote On 17-07-2009 12:45:
At Fri, 17 Jul 2009 11:33:08 +0200, I wrote:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
Looking through the stack trace, it's not...
But, I don't see any problem in the current code. It could be a bug in the wrapper for older kernels. Anyway, checking with the very latest snapshot would be helpful.
Hi again.
We've had another NULL ptr deref with the very same 20090624 snapshot on 2.6.25.20. The codecs are not the same, this is a conexant one.
I've now compiled and tried 20090805 snapshot and it's the same. So yes, I think that there's a problem with the wrapper or anything else but not the driver code itself because both laptops are very popular models, there would at least someone except me to notice that.
Seen that I've now have a faulty computer at my hand, I can help debugging the issue but don't know exactly how. Sending the dmesg output booted with 20090805 snapshot.
Thanks,
BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93cbda9>] :snd_hda_codec_conexant:cxt5051_init+0x90/0x1ea *pde = 00000000· Oops: 0002 [#1] SMP· Modules linked in: snd_hda_codec_conexant snd_hda_intel(+) snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event arc4 snd_seq ecb snd_seq_device uvcvideo snd_pcm_oss snd_mixer_oss snd_pcm compat_ioctl32 iwl3945 rfkill snd_timer thermal nvidia(P) processor snd soundcore ac rtc_cmos videodev rtc_core sdhci rtc_lib firmware_class wmi video output snd_page_alloc battery button iTCO_wdt mac8 0211 hci_usb led_class sky2 usbhid mmc_core cfg80211 intel_agp v4l1_compat joydev iTCO_vendor_support i2c_i801 bluetooth serio_raw agpgart i2c_core hid ff_memless sg ext3 jbd mbcache sd_mod sr_mod cdrom ata_piix uhci_hcd pata_acpi ehci_hcd usbcore ohci1394 ieee1394 ata_generic ahci libata scsi_mod dock
Pid: 278, comm: modprobe Tainted: P (2.6.25.20-114 #1) EIP: 0060:[<f93cbda9>] EFLAGS: 00210246 CPU: 1 EIP is at cxt5051_init+0x90/0x1ea [snd_hda_codec_conexant] EAX: 00000000 EBX: f7b70016 ECX: 00000000 EDX: f7a76a00 ESI: f7b78000 EDI: 00000000 EBP: f7987d4c ESP: f7987d18 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 278, ti=f7986000 task=f7984000 task.ti=f7986000) Stack: f7944e00 f7a76c00 f78a4194 f78a4134 f93cfa20 00000000 f78a4000 f7b78000· 00000002 001c0001 f7b78000 f7944e00 f785232c f7987d58 f93b96ec f7b78000· f7987d6c f93ba298 f7852324 f7944e00 00000000 f7987dcc f93ae2e8 00000000· Call Trace: [<f93b96ec>] ? snd_hda_codec_build_controls+0x20/0x3d [snd_hda_codec] [<f93ba298>] ? snd_hda_build_controls+0x18/0x67 [snd_hda_codec] [<f93ae2e8>] ? azx_probe+0x863/0x8fb [snd_hda_intel] [<f93ad91a>] ? azx_send_cmd+0x0/0x126 [snd_hda_intel] [<f93ad733>] ? azx_get_response+0x0/0x1e7 [snd_hda_intel] [<f93acf50>] ? azx_attach_pcm_stream+0x0/0x15c [snd_hda_intel] [<f93acc06>] ? azx_bus_reset+0x0/0x56 [snd_hda_intel] [<f93acaae>] ? azx_power_notify+0x0/0x57 [snd_hda_intel] [<c01e7a37>] ? pci_device_probe+0x39/0x59 [<c024395f>] ? driver_probe_device+0xa0/0x136 [<c0243a50>] ? __driver_attach+0x5b/0x91 [<c024333c>] ? bus_for_each_dev+0x3b/0x63 [<c0243804>] ? driver_attach+0x14/0x16 [<c02439f5>] ? __driver_attach+0x0/0x91 [<c0242d3a>] ? bus_add_driver+0x9d/0x1ba [<c0243bc4>] ? driver_register+0x47/0xa7 [<c0168681>] ? __vunmap+0x93/0x9b [<c01e7bec>] ? __pci_register_driver+0x35/0x61 [<f8860017>] ? alsa_card_azx_init+0x17/0x19 [snd_hda_intel] [<c0141f9c>] ? sys_init_module+0x18ad/0x19ca [<c0175bc9>] ? sys_read+0x3b/0x60 [<c01049b4>] ? sysenter_past_esp+0x6d/0xa5 ======================= Code: 00 00 c7 80 b4 01 00 00 20 00 00 00 05 a8 01 00 00 e8 6d b6 fe ff 85 c0 89 c2 74 1c 66 89 18 31 ff c7 40 04 01 00 00 00 8b 40 08 <89> 50 74 8b 42 08 c7 40 78 18 b1 3c f9 8b 45 dc 31 db 8b 4e 60· EIP: [<f93cbda9>] cxt5051_init+0x90/0x1ea [snd_hda_codec_conexant] SS:ESP 0068:f7987d18 ---[ end trace c2899a0d94365408 ]---
Takashi Iwai wrote On 17-07-2009 12:45:
At Fri, 17 Jul 2009 11:33:08 +0200, I wrote:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
Looking through the stack trace, it's not...
Okay I've founded the problem. Here's the relevant code portion that I've got from gdb:
(gdb) list *cxt5051_init+0x90 0xdf4 is in cxt5051_init (/var/pisi/alsa-driver-1.0.20_20090805-41/work/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_conexant.c:384). 379 jack->type = type; 380 381 err = snd_jack_new(codec->bus->card, name, type, &jack->jack); 382 if (err < 0) 383 return err; 384 jack->jack->private_data = jack; 385 jack->jack->private_free = conexant_free_jack_priv; 386 return 0; 387 } 388
and then I've checked the mainline linus-2.6 and found out the following commit:
commit 95c0909961bc5ff18c78b2ab0d093cddc0a8b0b5 Author: Takashi Iwai tiwai@suse.de Date: Tue Apr 14 16:15:29 2009 +0200
ALSA: hda - Avoid call of snd_jack_report at release
Don't call snd_jack_report at release of sigmatel and conexnat codecs which results in Oops at unloading the module.
The Oops is triggered by the power-up sequence during the free due to the pincfg restoration. Since the power-up sequence is involved with the unsol handling, the jack reporting may be issued during that. The Oops occurs with this jack reporting because the jack instances have been already released but the codec doesn't do the proper book-keeping.
This patch adds the book-keeping of jack instances to avoid the access to bogus pointers.
Reverting this fixed the problem on the machine which has the conexant cx codec. Seen that the commit patches also the sigmatel one, it explains the other oops in the beginning of this thread.
I'm not currently able to test the two machines on a newer kernel than 2.6.25.20 so I don't know if the problem is in the code or in the wrappers/ABI-API patches in alsa-driver, etc.
Regards, Ozan
At Thu, 06 Aug 2009 16:41:27 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 17-07-2009 12:45:
At Fri, 17 Jul 2009 11:33:08 +0200, I wrote:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
Looking through the stack trace, it's not...
Okay I've founded the problem. Here's the relevant code portion that I've got from gdb:
(gdb) list *cxt5051_init+0x90 0xdf4 is in cxt5051_init (/var/pisi/alsa-driver-1.0.20_20090805-41/work/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_conexant.c:384). 379 jack->type = type; 380 381 err = snd_jack_new(codec->bus->card, name, type, &jack->jack); 382 if (err < 0) 383 return err; 384 jack->jack->private_data = jack; 385 jack->jack->private_free = conexant_free_jack_priv; 386 return 0; 387 } 388
So, either jack or jack->jack is a wrong value, likely NULL. Could you add a debug print to verify that?
and then I've checked the mainline linus-2.6 and found out the following commit:
commit 95c0909961bc5ff18c78b2ab0d093cddc0a8b0b5 Author: Takashi Iwai tiwai@suse.de Date: Tue Apr 14 16:15:29 2009 +0200
ALSA: hda - Avoid call of snd_jack_report at release Don't call snd_jack_report at release of sigmatel and conexnat codecs which results in Oops at unloading the module. The Oops is triggered by the power-up sequence during the free due to the pincfg restoration. Since the power-up sequence is involved with the unsol handling, the jack reporting may be issued during that. The Oops occurs with this jack reporting because the jack instances have been already released but the codec doesn't do the proper book-keeping. This patch adds the book-keeping of jack instances to avoid the access to bogus pointers.Reverting this fixed the problem on the machine which has the conexant cx codec. Seen that the commit patches also the sigmatel one, it explains the other oops in the beginning of this thread.
Yes.
Takashi
Takashi Iwai wrote On 06-08-2009 17:13:
At Thu, 06 Aug 2009 16:41:27 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 17-07-2009 12:45:
At Fri, 17 Jul 2009 11:33:08 +0200, I wrote:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
Looking through the stack trace, it's not...
Okay I've founded the problem. Here's the relevant code portion that I've got from gdb:
(gdb) list *cxt5051_init+0x90 0xdf4 is in cxt5051_init (/var/pisi/alsa-driver-1.0.20_20090805-41/work/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/patch_conexant.c:384). 379 jack->type = type; 380 381 err = snd_jack_new(codec->bus->card, name, type, &jack->jack); 382 if (err < 0) 383 return err; 384 jack->jack->private_data = jack; 385 jack->jack->private_free = conexant_free_jack_priv; 386 return 0; 387 } 388
So, either jack or jack->jack is a wrong value, likely NULL. Could you add a debug print to verify that?
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
2009/8/7 Ozan Çağlayan ozan@pardus.org.tr:
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Need more of the dmesg output. I.e. to see which print statements succeeded. Alternatively, attach the snd_hda.ko so one can see where in that file offset 0x57 is. But a more useful print would be: if (!jack) printk(KERN_INFO "jack null\n"); else if (!(jack->jack)) printk(KERN_INFO "jack->jack null\n"); else if (!(jack->jack->private_data)) printk(KERN_INFO "jack->jack->private_data null\n");
At Fri, 7 Aug 2009 10:43:07 +0100, James Courtier-Dutton wrote:
2009/8/7 Ozan Çağlayan ozan@pardus.org.tr:
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Need more of the dmesg output. I.e. to see which print statements succeeded. Alternatively, attach the snd_hda.ko so one can see where in that file offset 0x57 is. But a more useful print would be: if (!jack) printk(KERN_INFO "jack null\n"); else if (!(jack->jack)) printk(KERN_INFO "jack->jack null\n"); else if (!(jack->jack->private_data)) printk(KERN_INFO "jack->jack->private_data null\n");
Well, it's fairly obvious that jack->jack is NULL as the second output is NULL, and the third one hits Oops.
Ozan, could you check whether CONFIG_SND_JACK is set in stac92xx_add_jack, e.g. like below?
Takashi
--- diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index a75d6a0..e131e0d 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -4185,6 +4185,9 @@ static int stac92xx_add_jack(struct hda_codec *codec, hda_nid_t nid, int type) { #ifdef CONFIG_SND_HDA_INPUT_JACK +#ifndef CONFIG_SND_JACK +#error XXX +#endif struct sigmatel_spec *spec = codec->spec; struct sigmatel_jack *jack; int def_conf = snd_hda_codec_get_pincfg(codec, nid);
2009/8/7 Takashi Iwai tiwai@suse.de:
0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Well, it's fairly obvious that jack->jack is NULL as the second output is NULL, and the third one hits Oops.
Oh yes, I missed the 0xf777a614 and 0x00000000
Takashi Iwai wrote On 07-08-2009 12:56:
At Fri, 7 Aug 2009 10:43:07 +0100, James Courtier-Dutton wrote:
2009/8/7 Ozan Çağlayan ozan@pardus.org.tr:
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Need more of the dmesg output. I.e. to see which print statements succeeded. Alternatively, attach the snd_hda.ko so one can see where in that file offset 0x57 is. But a more useful print would be: if (!jack) printk(KERN_INFO "jack null\n"); else if (!(jack->jack)) printk(KERN_INFO "jack->jack null\n"); else if (!(jack->jack->private_data)) printk(KERN_INFO "jack->jack->private_data null\n");
Well, it's fairly obvious that jack->jack is NULL as the second output is NULL, and the third one hits Oops.
Ozan, could you check whether CONFIG_SND_JACK is set in stac92xx_add_jack, e.g. like below?
Nope it seems that it's not set as the #error pragma is executed. I looked into the configure script and found the following:
if alsa_check_kconfig_option "hda-input-jack"; then if ( test "$CONFIG_SND_PCI" = "y" -o "$CONFIG_SND_PCI" = "m" ) && ( test "$CONFIG_SND_HDA_INTEL" = "y" -o "$CONFIG_SND_HDA_INTEL" = "m" ) && ( test "$CONFIG_INPUT" = "y" -o "$CONFIG_INPUT" = "m" ); then test "$kversion.$kpatchlevel" = "2.6" -a $ksublevel -ge 27 && CONFIG_SND_JACK="y" CONFIG_SND_HDA_INPUT_JACK="y" fi
SND_JACK is set if sublevel >= 27 but SND_HDA_INPUT_JACK is set regardless of anything. Why the lower limit is 27 for that functionality?
At Fri, 07 Aug 2009 13:36:46 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 07-08-2009 12:56:
At Fri, 7 Aug 2009 10:43:07 +0100, James Courtier-Dutton wrote:
2009/8/7 Ozan Çağlayan ozan@pardus.org.tr:
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Need more of the dmesg output. I.e. to see which print statements succeeded. Alternatively, attach the snd_hda.ko so one can see where in that file offset 0x57 is. But a more useful print would be: if (!jack) printk(KERN_INFO "jack null\n"); else if (!(jack->jack)) printk(KERN_INFO "jack->jack null\n"); else if (!(jack->jack->private_data)) printk(KERN_INFO "jack->jack->private_data null\n");
Well, it's fairly obvious that jack->jack is NULL as the second output is NULL, and the third one hits Oops.
Ozan, could you check whether CONFIG_SND_JACK is set in stac92xx_add_jack, e.g. like below?
Nope it seems that it's not set as the #error pragma is executed. I looked into the configure script and found the following:
if alsa_check_kconfig_option "hda-input-jack"; then if ( test "$CONFIG_SND_PCI" = "y" -o "$CONFIG_SND_PCI" = "m" ) && ( test "$CONFIG_SND_HDA_INTEL" = "y" -o "$CONFIG_SND_HDA_INTEL" = "m" ) && ( test "$CONFIG_INPUT" = "y" -o "$CONFIG_INPUT" = "m" ); then test "$kversion.$kpatchlevel" = "2.6" -a $ksublevel -ge 27 && CONFIG_SND_JACK="y" CONFIG_SND_HDA_INPUT_JACK="y" fi
SND_JACK is set if sublevel >= 27 but SND_HDA_INPUT_JACK is set regardless of anything. Why the lower limit is 27 for that functionality?
Because of kernel API change, it can't be built with older kernels.
The patch below should fix the problem. Give it a try.
thanks,
Takashi
--- diff --git a/include/config.h.in b/include/config.h.in index 5c7a96c..eefc0ee 100644 --- a/include/config.h.in +++ b/include/config.h.in @@ -88,3 +88,8 @@ #undef CONFIG_HAVE_GFP_DMA32 #undef CONFIG_HAVE_PAGE_TO_PFN #undef CONFIG_HAVE_VIDEO_DRVDATA + +/* hack - CONFIG_SND_HDA_INPUT_JACK can be wrongly set for older kernels */ +#ifndef CONFIG_SND_JACK +#undef CONFIG_SND_HDA_INPUT_JACK +#endif
Takashi Iwai wrote On 07-08-2009 13:49:
At Fri, 07 Aug 2009 13:36:46 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 07-08-2009 12:56:
At Fri, 7 Aug 2009 10:43:07 +0100, James Courtier-Dutton wrote:
2009/8/7 Ozan Çağlayan ozan@pardus.org.tr:
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Need more of the dmesg output. I.e. to see which print statements succeeded. Alternatively, attach the snd_hda.ko so one can see where in that file offset 0x57 is. But a more useful print would be: if (!jack) printk(KERN_INFO "jack null\n"); else if (!(jack->jack)) printk(KERN_INFO "jack->jack null\n"); else if (!(jack->jack->private_data)) printk(KERN_INFO "jack->jack->private_data null\n");
Well, it's fairly obvious that jack->jack is NULL as the second output is NULL, and the third one hits Oops.
Ozan, could you check whether CONFIG_SND_JACK is set in stac92xx_add_jack, e.g. like below?
Nope it seems that it's not set as the #error pragma is executed. I looked into the configure script and found the following:
if alsa_check_kconfig_option "hda-input-jack"; then if ( test "$CONFIG_SND_PCI" = "y" -o "$CONFIG_SND_PCI" = "m" ) && ( test "$CONFIG_SND_HDA_INTEL" = "y" -o "$CONFIG_SND_HDA_INTEL" = "m" ) && ( test "$CONFIG_INPUT" = "y" -o "$CONFIG_INPUT" = "m" ); then test "$kversion.$kpatchlevel" = "2.6" -a $ksublevel -ge 27 && CONFIG_SND_JACK="y" CONFIG_SND_HDA_INPUT_JACK="y" fi
SND_JACK is set if sublevel >= 27 but SND_HDA_INPUT_JACK is set regardless of anything. Why the lower limit is 27 for that functionality?
Because of kernel API change, it can't be built with older kernels.
The patch below should fix the problem. Give it a try.
The patch below doesn't undef CONFIG_SND_HDA_INPUT_JACK after configuring. Actually there are config1.h* and config.h* and both contains def/undefs for *JACK* stuff. But I'll undefine it after configure and then compile to see it the error goes.
I don't have the computer right now, will continue to debug Monday.
Thanks.
At Fri, 07 Aug 2009 16:39:19 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 07-08-2009 13:49:
At Fri, 07 Aug 2009 13:36:46 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 07-08-2009 12:56:
At Fri, 7 Aug 2009 10:43:07 +0100, James Courtier-Dutton wrote:
2009/8/7 Ozan Çağlayan ozan@pardus.org.tr:
Added the following lines:
printk(KERN_INFO "0x%p\n", jack); printk(KERN_INFO "0x%p\n", jack->jack); printk(KERN_INFO "0x%p\n", jack->jack->private_data);
dmesg:
NVRM: loading NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:1b.0 to 64 0xf777a614 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000074 IP: [<f93f2d97>] :snd_hda_codec_conexant:conexant_add_jack+0x57/0x81 *pde = 00000000· Oops: 0000 [#1] SMP
Need more of the dmesg output. I.e. to see which print statements succeeded. Alternatively, attach the snd_hda.ko so one can see where in that file offset 0x57 is. But a more useful print would be: if (!jack) printk(KERN_INFO "jack null\n"); else if (!(jack->jack)) printk(KERN_INFO "jack->jack null\n"); else if (!(jack->jack->private_data)) printk(KERN_INFO "jack->jack->private_data null\n");
Well, it's fairly obvious that jack->jack is NULL as the second output is NULL, and the third one hits Oops.
Ozan, could you check whether CONFIG_SND_JACK is set in stac92xx_add_jack, e.g. like below?
Nope it seems that it's not set as the #error pragma is executed. I looked into the configure script and found the following:
if alsa_check_kconfig_option "hda-input-jack"; then if ( test "$CONFIG_SND_PCI" = "y" -o "$CONFIG_SND_PCI" = "m" ) && ( test "$CONFIG_SND_HDA_INTEL" = "y" -o "$CONFIG_SND_HDA_INTEL" = "m" ) && ( test "$CONFIG_INPUT" = "y" -o "$CONFIG_INPUT" = "m" ); then test "$kversion.$kpatchlevel" = "2.6" -a $ksublevel -ge 27 && CONFIG_SND_JACK="y" CONFIG_SND_HDA_INPUT_JACK="y" fi
SND_JACK is set if sublevel >= 27 but SND_HDA_INPUT_JACK is set regardless of anything. Why the lower limit is 27 for that functionality?
Because of kernel API change, it can't be built with older kernels.
The patch below should fix the problem. Give it a try.
The patch below doesn't undef CONFIG_SND_HDA_INPUT_JACK after configuring. Actually there are config1.h* and config.h* and both contains def/undefs for *JACK* stuff. But I'll undefine it after configure and then compile to see it the error goes.
Yeah I realized it, now fixed alsa-driver GIT tree to undef in adriver.h instead.
Takashi
Takashi Iwai wrote:
The patch below doesn't undef CONFIG_SND_HDA_INPUT_JACK after configuring. Actually there are config1.h* and config.h* and both contains def/undefs for *JACK* stuff. But I'll undefine it after configure and then compile to see it the error goes.
Yeah I realized it, now fixed alsa-driver GIT tree to undef in adriver.h instead.
Takashi
I've compiled the latest snapshot which includes that fix and made it try to the guy who has the sigmatel codec. It still oopses but in another place. I've double checked with #error that SND_HDA_INPUT_JACK and SND_JACK is unset. The new oops backtrace:
BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<f8c774ba>] :snd_hda_codec_idt:stac92xx_init+0x280/0x504 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: snd_hda_codec_idt snd_hda_intel(+) snd_hda_codec aes_i586 aes_generic ipv6 af_packet bridge bnep rfcomm l2cap microcode acpi_cpufreq cpufreq_powersave cpufreq_userspace cpufreq_conservative ndiswrapper vboxdrv snd_hwdep nvidia(P) arc4 snd_seq_dummy ecb iwl4965 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm hci_usb snd_timer intel_agp iwlcore thermal bluetooth rfkill led_class processor agpgart r5u870 sky2 battery mac80211 usbcam videobuf_dma_sg pcmcia firmware_class videobuf_core sony_laptop uvcvideo compat_ioctl32 videodev v4l1_compat iTCO_wdt tpm_infineon cfg80211 video output tifm_7xx1 tifm_core yenta_socket rsrc_nonstatic snd soundcore snd_page_alloc button rtc_cmos ac rtc_core joydev iTCO_vendor_support tpm tpm_bios i2c_i801 i2c_core pcmcia_core rtc_lib sg ext3 jbd mbcache sr_mod cdrom sd_mod ata_piix uhci_hcd pata_acpi ehci_hcd usbcore ohci1394 ieee1394 ata_generic libata scsi_mod dock
Pid: 1899, comm: modprobe Tainted: P (2.6.25.20-114 #1) EIP: 0060:[<f8c774ba>] EFLAGS: 00210246 CPU: 0 EIP is at stac92xx_init+0x280/0x504 [snd_hda_codec_idt] EAX: 00000000 EBX: 00000040 ECX: 00000000 EDX: 0000000a ESI: f592dc00 EDI: f6a05800 EBP: f6705d4c ESP: f6705d28 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 1899, ti=f6704000 task=f670c000 task.ti=f6704000) Stack: 00000000 f6705d5c f8c5b24a f6e61800 00000001 00080002 f592dc00 f67ac200 f679856c f6705d58 f8c5a6ec f592dc00 f6705d6c f8c5b298 f6798564 f67ac200 00000000 f6705dcc f8c6e2e8 f6ea2146 f6705da4 f74a3c00 00000004 00000008 Call Trace: [<f8c5b24a>] ? snd_hda_codec_build_pcms+0x216/0x24c [snd_hda_codec] [<f8c5a6ec>] ? snd_hda_codec_build_controls+0x20/0x3d [snd_hda_codec] [<f8c5b298>] ? snd_hda_build_controls+0x18/0x67 [snd_hda_codec] [<f8c6e2e8>] ? azx_probe+0x863/0x8fb [snd_hda_intel] [<f8c6d91a>] ? azx_send_cmd+0x0/0x126 [snd_hda_intel] [<f8c6d733>] ? azx_get_response+0x0/0x1e7 [snd_hda_intel] [<f8c6cf50>] ? azx_attach_pcm_stream+0x0/0x15c [snd_hda_intel] [<f8c6cc06>] ? azx_bus_reset+0x0/0x56 [snd_hda_intel] [<f8c6caae>] ? azx_power_notify+0x0/0x57 [snd_hda_intel] [<c01e7a37>] ? pci_device_probe+0x39/0x59 [<c024395f>] ? driver_probe_device+0xa0/0x136 [<c0243a50>] ? __driver_attach+0x5b/0x91 [<c024333c>] ? bus_for_each_dev+0x3b/0x63 [<c0243804>] ? driver_attach+0x14/0x16 [<c02439f5>] ? __driver_attach+0x0/0x91 [<c0242d3a>] ? bus_add_driver+0x9d/0x1ba [<c0243bc4>] ? driver_register+0x47/0xa7 [<c0168681>] ? __vunmap+0x93/0x9b [<c01e7bec>] ? __pci_register_driver+0x35/0x61 [<f8a4b017>] ? alsa_card_azx_init+0x17/0x19 [snd_hda_intel] [<c0141f9c>] ? sys_init_module+0x18ad/0x19ca [<c0109c77>] ? do_syscall_trace+0x138/0x17f [<c0104a2e>] ? syscall_call+0x7/0xb [<c02d0000>] ? pci_bus_size_bridges+0x362/0x36d ======================= Code: 0f b7 94 5f a4 02 00 00 b9 01 00 00 00 89 f0 43 e8 90 ef ff ff 3b 9f 9c 02 00 00 7c e3 f6 47 18 40 74 40 8b 87 08 01 00 00 31 c9 <0f> b7 10 89 f0 6a 00 68 01 07 00 00 e8 0c 1e fe ff 0f b7 97 28 EIP: [<f8c774ba>] stac92xx_init+0x280/0x504 [snd_hda_codec_idt] SS:ESP 0068:f6705d28 ---[ end trace fc30bda5826e9f63 ]---
markup_oops output:
No vmlinux specified, assuming /lib/modules/2.6.25.20-114/build/vmlinux */ stac92xx_auto_set_pinctl(codec, spec->autocfg.line_out_pins[0], AC_PINCTL_OUT_EN); /* fake event to set up pins */ stac_issue_unsol_event(codec, spec->autocfg.hp_pins[0]); } else { f8c774a4: 3b 9f 9c 02 00 00 cmp 0x29c(%edi),%ebx | %edi = f6a05800 %ebx => 40 f8c774aa: 7c e3 jl f8c7748f <stac92xx_init+0x255> stac92xx_auto_init_multi_out(codec); stac92xx_auto_init_hp_out(codec); for (i = 0; i < cfg->hp_outs; i++) f8c774ac: f6 47 18 40 testb $0x40,0x18(%edi) | %edi = f6a05800 f8c774b0: 74 40 je f8c774f2 <stac92xx_init+0x2b8> stac_toggle_power_map(codec, cfg->hp_pins[i], 1); } f8c774b2: 8b 87 08 01 00 00 mov 0x108(%edi),%eax | %edi = f6a05800 %eax => 0 f8c774b8: 31 c9 xor %ecx,%ecx | %ecx => 0 *f8c774ba: 0f b7 10 movzwl (%eax),%edx | %eax = 0 %edx = a <--- faulting instruction f8c774bd: 89 f0 mov %esi,%eax f8c774bf: 6a 00 push $0x0 f8c774c1: 68 01 07 00 00 push $0x701 f8c774c6: e8 fc ff ff ff call f8c774c7 <stac92xx_init+0x28d> if (spec->auto_mic) { /* initialize connection to analog input */ f8c774cb: 0f b7 97 28 01 00 00 movzwl 0x128(%edi),%edx f8c774d2: b9 06 00 00 00 mov $0x6,%ecx f8c774d7: 89 f0 mov %esi,%eax f8c774d9: e8 8d fc ff ff call f8c7716b <enable_pin_detect> f8c774de: 59 pop %ecx f8c774df: 5b pop %ebx f8c774e0: 85 c0 test %eax,%eax f8c774e2: 74 0e je f8c774f2 <stac92xx_init+0x2b8> snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, f8c774e4: 0f b7 97 28 01 00 00 movzwl 0x128(%edi),%edx f8c774eb: 89 f0 mov %esi,%eax f8c774ed: e8 8d ed ff ff call f8c7627f <stac_issue_unsol_event> f8c774f2: c7 45 f0 00 00 00 00 movl $0x0,-0x10(%ebp) ...
I had troubles to decode this faulty instruction to the current source code but I've added some printk's to suspicious dereferences and told the guy to retry.
I'll be able to test the conexant one tomorrow. Thanks,
At Sun, 09 Aug 2009 15:10:31 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote:
The patch below doesn't undef CONFIG_SND_HDA_INPUT_JACK after configuring. Actually there are config1.h* and config.h* and both contains def/undefs for *JACK* stuff. But I'll undefine it after configure and then compile to see it the error goes.
Yeah I realized it, now fixed alsa-driver GIT tree to undef in adriver.h instead.
Takashi
I've compiled the latest snapshot which includes that fix and made it try to the guy who has the sigmatel codec. It still oopses but in another place. I've double checked with #error that SND_HDA_INPUT_JACK and SND_JACK is unset. The new oops backtrace:
BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<f8c774ba>] :snd_hda_codec_idt:stac92xx_init+0x280/0x504 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: snd_hda_codec_idt snd_hda_intel(+) snd_hda_codec aes_i586 aes_generic ipv6 af_packet bridge bnep rfcomm l2cap microcode acpi_cpufreq cpufreq_powersave cpufreq_userspace cpufreq_conservative ndiswrapper vboxdrv snd_hwdep nvidia(P) arc4 snd_seq_dummy ecb iwl4965 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm hci_usb snd_timer intel_agp iwlcore thermal bluetooth rfkill led_class processor agpgart r5u870 sky2 battery mac80211 usbcam videobuf_dma_sg pcmcia firmware_class videobuf_core sony_laptop uvcvideo compat_ioctl32 videodev v4l1_compat iTCO_wdt tpm_infineon cfg80211 video output tifm_7xx1 tifm_core yenta_socket rsrc_nonstatic snd soundcore snd_page_alloc button rtc_cmos ac rtc_core joydev iTCO_vendor_support tpm tpm_bios i2c_i801 i2c_core pcmcia_core rtc_lib sg ext3 jbd mbcache sr_mod cdrom sd_mod ata_piix uhci_hcd pata_acpi ehci_hcd usbcore ohci1394 ieee1394 ata_generic libata scsi_mod dock
Pid: 1899, comm: modprobe Tainted: P (2.6.25.20-114 #1) EIP: 0060:[<f8c774ba>] EFLAGS: 00210246 CPU: 0 EIP is at stac92xx_init+0x280/0x504 [snd_hda_codec_idt] EAX: 00000000 EBX: 00000040 ECX: 00000000 EDX: 0000000a ESI: f592dc00 EDI: f6a05800 EBP: f6705d4c ESP: f6705d28 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 1899, ti=f6704000 task=f670c000 task.ti=f6704000) Stack: 00000000 f6705d5c f8c5b24a f6e61800 00000001 00080002 f592dc00 f67ac200 f679856c f6705d58 f8c5a6ec f592dc00 f6705d6c f8c5b298 f6798564 f67ac200 00000000 f6705dcc f8c6e2e8 f6ea2146 f6705da4 f74a3c00 00000004 00000008 Call Trace: [<f8c5b24a>] ? snd_hda_codec_build_pcms+0x216/0x24c [snd_hda_codec] [<f8c5a6ec>] ? snd_hda_codec_build_controls+0x20/0x3d [snd_hda_codec] [<f8c5b298>] ? snd_hda_build_controls+0x18/0x67 [snd_hda_codec] [<f8c6e2e8>] ? azx_probe+0x863/0x8fb [snd_hda_intel] [<f8c6d91a>] ? azx_send_cmd+0x0/0x126 [snd_hda_intel] [<f8c6d733>] ? azx_get_response+0x0/0x1e7 [snd_hda_intel] [<f8c6cf50>] ? azx_attach_pcm_stream+0x0/0x15c [snd_hda_intel] [<f8c6cc06>] ? azx_bus_reset+0x0/0x56 [snd_hda_intel] [<f8c6caae>] ? azx_power_notify+0x0/0x57 [snd_hda_intel] [<c01e7a37>] ? pci_device_probe+0x39/0x59 [<c024395f>] ? driver_probe_device+0xa0/0x136 [<c0243a50>] ? __driver_attach+0x5b/0x91 [<c024333c>] ? bus_for_each_dev+0x3b/0x63 [<c0243804>] ? driver_attach+0x14/0x16 [<c02439f5>] ? __driver_attach+0x0/0x91 [<c0242d3a>] ? bus_add_driver+0x9d/0x1ba [<c0243bc4>] ? driver_register+0x47/0xa7 [<c0168681>] ? __vunmap+0x93/0x9b [<c01e7bec>] ? __pci_register_driver+0x35/0x61 [<f8a4b017>] ? alsa_card_azx_init+0x17/0x19 [snd_hda_intel] [<c0141f9c>] ? sys_init_module+0x18ad/0x19ca [<c0109c77>] ? do_syscall_trace+0x138/0x17f [<c0104a2e>] ? syscall_call+0x7/0xb [<c02d0000>] ? pci_bus_size_bridges+0x362/0x36d ======================= Code: 0f b7 94 5f a4 02 00 00 b9 01 00 00 00 89 f0 43 e8 90 ef ff ff 3b 9f 9c 02 00 00 7c e3 f6 47 18 40 74 40 8b 87 08 01 00 00 31 c9 <0f> b7 10 89 f0 6a 00 68 01 07 00 00 e8 0c 1e fe ff 0f b7 97 28 EIP: [<f8c774ba>] stac92xx_init+0x280/0x504 [snd_hda_codec_idt] SS:ESP 0068:f6705d28 ---[ end trace fc30bda5826e9f63 ]---
markup_oops output:
No vmlinux specified, assuming /lib/modules/2.6.25.20-114/build/vmlinux */ stac92xx_auto_set_pinctl(codec, spec->autocfg.line_out_pins[0], AC_PINCTL_OUT_EN); /* fake event to set up pins */ stac_issue_unsol_event(codec, spec->autocfg.hp_pins[0]); } else { f8c774a4: 3b 9f 9c 02 00 00 cmp 0x29c(%edi),%ebx | %edi = f6a05800 %ebx => 40 f8c774aa: 7c e3 jl f8c7748f <stac92xx_init+0x255> stac92xx_auto_init_multi_out(codec); stac92xx_auto_init_hp_out(codec); for (i = 0; i < cfg->hp_outs; i++) f8c774ac: f6 47 18 40 testb $0x40,0x18(%edi) | %edi = f6a05800 f8c774b0: 74 40 je f8c774f2 <stac92xx_init+0x2b8> stac_toggle_power_map(codec, cfg->hp_pins[i], 1); } f8c774b2: 8b 87 08 01 00 00 mov 0x108(%edi),%eax | %edi = f6a05800 %eax => 0 f8c774b8: 31 c9 xor %ecx,%ecx | %ecx => 0 *f8c774ba: 0f b7 10 movzwl (%eax),%edx | %eax = 0 %edx = a <--- faulting instruction f8c774bd: 89 f0 mov %esi,%eax f8c774bf: 6a 00 push $0x0 f8c774c1: 68 01 07 00 00 push $0x701 f8c774c6: e8 fc ff ff ff call f8c774c7 <stac92xx_init+0x28d> if (spec->auto_mic) { /* initialize connection to analog input */ f8c774cb: 0f b7 97 28 01 00 00 movzwl 0x128(%edi),%edx f8c774d2: b9 06 00 00 00 mov $0x6,%ecx f8c774d7: 89 f0 mov %esi,%eax f8c774d9: e8 8d fc ff ff call f8c7716b <enable_pin_detect> f8c774de: 59 pop %ecx f8c774df: 5b pop %ebx f8c774e0: 85 c0 test %eax,%eax f8c774e2: 74 0e je f8c774f2 <stac92xx_init+0x2b8> snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, f8c774e4: 0f b7 97 28 01 00 00 movzwl 0x128(%edi),%edx f8c774eb: 89 f0 mov %esi,%eax f8c774ed: e8 8d ed ff ff call f8c7627f <stac_issue_unsol_event> f8c774f2: c7 45 f0 00 00 00 00 movl $0x0,-0x10(%ebp) ...
I had troubles to decode this faulty instruction to the current source code but I've added some printk's to suspicious dereferences and told the guy to retry.
Could you load the module with probe_only=1 option and give alsa-info.sh output (or at least codec#* proc file)?
thanks,
Takashi
Takashi Iwai wrote:
At Sun, 09 Aug 2009 15:10:31 +0300,
Could you load the module with probe_only=1 option and give alsa-info.sh output (or at least codec#* proc file)?
Ok, will provide that info too. BTW,
CPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ** codec:0xf5846800 ** spec->dmux_nids:0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<f8c7b4d5>] :snd_hda_codec_idt:stac92xx_init+0x29b/0x520 *pde = 00000000 Oops: 0000 [#1] SMP
spec->dmux_nids is NULL. Found the following commit:
From: Takashi Iwai tiwai@suse.de Date: Wed, 29 Jul 2009 14:32:55 +0000 (+0200) Subject: ALSA: hda - Add missing DMUX initialization for auto-mic with STAC/IDT X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftiwai%2Fsound-2.6.git;a=comm...
ALSA: hda - Add missing DMUX initialization for auto-mic with STAC/IDT
Added the missing initialization of DMUX connection (to analog input) for auto-mic mode with STAC/IDT codecs.
Signed-off-by: Takashi Iwai tiwai@suse.de ---
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index abc44db..2405f84 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -4359,6 +4359,9 @@ static int stac92xx_init(struct hda_codec *codec) stac_toggle_power_map(codec, cfg->hp_pins[i], 1); } if (spec->auto_mic) { + /* initialize connection to analog input */ + snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, + AC_VERB_SET_CONNECT_SEL, 0); if (enable_pin_detect(codec, spec->ext_mic.pin, STAC_MIC_EVENT)) stac_issue_unsol_event(codec, spec->ext_mic.pin); }
At Mon, 10 Aug 2009 02:02:06 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote:
At Sun, 09 Aug 2009 15:10:31 +0300,
Could you load the module with probe_only=1 option and give alsa-info.sh output (or at least codec#* proc file)?
Ok, will provide that info too. BTW,
CPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ** codec:0xf5846800 ** spec->dmux_nids:0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<f8c7b4d5>] :snd_hda_codec_idt:stac92xx_init+0x29b/0x520 *pde = 00000000 Oops: 0000 [#1] SMP
spec->dmux_nids is NULL. Found the following commit:
Good catch. How about the patch below?
Thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index a75d6a0..7da4dc4 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3701,7 +3701,7 @@ static int set_mic_route(struct hda_codec *codec, if (i < 0) return -1; mic->mux_idx = i; - } else { + } else if (spec->dmux->nids) { /* digital pin */ mic->mux_idx = 0; i = get_connection_index(codec, spec->dmux_nids[0], pin); @@ -4404,7 +4404,8 @@ static int stac92xx_init(struct hda_codec *codec) } if (spec->auto_mic) { /* initialize connection to analog input */ - snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, + if (dmux->nids) + snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, AC_VERB_SET_CONNECT_SEL, 0); if (enable_pin_detect(codec, spec->ext_mic.pin, STAC_MIC_EVENT)) stac_issue_unsol_event(codec, spec->ext_mic.pin);
At Mon, 10 Aug 2009 07:39:28 +0200, I wrote:
At Mon, 10 Aug 2009 02:02:06 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote:
At Sun, 09 Aug 2009 15:10:31 +0300,
Could you load the module with probe_only=1 option and give alsa-info.sh output (or at least codec#* proc file)?
Ok, will provide that info too. BTW,
CPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ** codec:0xf5846800 ** spec->dmux_nids:0x00000000 BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<f8c7b4d5>] :snd_hda_codec_idt:stac92xx_init+0x29b/0x520 *pde = 00000000 Oops: 0000 [#1] SMP
spec->dmux_nids is NULL. Found the following commit:
Good catch. How about the patch below?
Doh, sorry a totally broken patch. The fixed one is below.
I could reproduce the bug with the emulator, and this patch fixes the issue. Updated sound GIT tree and snapshot now.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index a75d6a0..a695558 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3701,7 +3701,7 @@ static int set_mic_route(struct hda_codec *codec, if (i < 0) return -1; mic->mux_idx = i; - } else { + } else if (spec->dmux_nids) { /* digital pin */ mic->mux_idx = 0; i = get_connection_index(codec, spec->dmux_nids[0], pin); @@ -4404,7 +4404,8 @@ static int stac92xx_init(struct hda_codec *codec) } if (spec->auto_mic) { /* initialize connection to analog input */ - snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, + if (spec->dmux_nids) + snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, AC_VERB_SET_CONNECT_SEL, 0); if (enable_pin_detect(codec, spec->ext_mic.pin, STAC_MIC_EVENT)) stac_issue_unsol_event(codec, spec->ext_mic.pin);
Takashi Iwai wrote On 10-08-2009 08:48:
Doh, sorry a totally broken patch. The fixed one is below.
I could reproduce the bug with the emulator, and this patch fixes the issue. Updated sound GIT tree and snapshot now.
Both conexant one and the sigmatel one are now fixed. Thanks for all the efforts :)
At Mon, 10 Aug 2009 10:01:03 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 10-08-2009 08:48:
Doh, sorry a totally broken patch. The fixed one is below.
I could reproduce the bug with the emulator, and this patch fixes the issue. Updated sound GIT tree and snapshot now.
Both conexant one and the sigmatel one are now fixed. Thanks for all the efforts :)
Good to hear. Thanks for quick testing!
Takashi
Takashi Iwai wrote On 17-07-2009 12:33:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
It was a snapshot from http://www.kernel.org/pub/linux/kernel/people/tiwai/alsa/alsa-driver/
At Fri, 17 Jul 2009 12:53:49 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 17-07-2009 12:33:
At Thu, 16 Jul 2009 22:51:50 +0300, Ozan Çağlayan wrote:
Hi,
One of our users is having a NULL ptr dereference upon loading the snd_hda_intel module with 20090624's snapshot. There's only one commit after that date in patch_sigmatel.c so I didn't tell him to try with the latest snapshot but if you think that the bug may be related to another part of the ALSA codebase, I can make him try the latest snapshot.
I suppose you are using unstable tree, right?
It was a snapshot from http://www.kernel.org/pub/linux/kernel/people/tiwai/alsa/alsa-driver/
Yes, but there are two different snapshots there, the stable one (alsa-driver-snapshot.tar.gz) and the unstable one (alsa-driver-unstable-snapshot.tar.gz).
Takashi
At Fri, 17 Jul 2009 13:35:39 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote On 17-07-2009 13:01:
Yes, but there are two different snapshots there, the stable one (alsa-driver-snapshot.tar.gz) and the unstable one (alsa-driver-unstable-snapshot.tar.gz).
Yep I'm always using the ones with timestamps, never the unstable one.
Then it's the stable one.
Note that alsa-driver-snapshot.tar.gz is always the newest version. The tarballs with dates are daily snapshots that are generated at each midnight (CET). So, for testing purpose, it's always good to use alsa-driver-snapshot.tar.gz unless you try the older one intentionally.
For reference the current position, check alsa-driver/HEAD and alsa-driver/alsa-kernel/HEAD files contained in the tarball. These are the recent GIT commit ids, so it makes easier to track which version it really is.
thanks,
Takashi
participants (3)
-
James Courtier-Dutton -
Ozan Çağlayan -
Takashi Iwai