[alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38
Now I'm subscribed to the list. It does not seem possible to get a message in without subscription. Would be nice if alsa had and used bug reporting pages outside the mailing list.
Trying again to get this message to the alsa-devel list, as recommended by the Debian maintainer of the kernel, without being subscribed. Does alsa not have a bug report page?
Booting kernel 2.6.38 hangs at: During boot of kernel 2.6.38 (and 2.6.37) udev bugs out: Waiting for /dev to be fully populated BUG: Unable to handle kernel paging request at ffffc90013cd8000 axz_probe+ ... [snd_hda_intel] ...lots of output lost... udevadm timeout 180 sec ... udevd[390]: worker [439] failed while handling '/devices/pci0000:80/0000:80:01.0'
No sound card is recognized after the timeout of the boot as shown above. According to the /proc/asound/cards there are no sound cards
See bug Debian bug #619034 for more information. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619034
This problem was also reported as Debian bug #613979, as kernel ticket
https://bugzilla.kernel.org/show_bug.cgi?id=30552
and sent to this mailing list in February 2011.
snd_hda_intel works properly with 2.6.32-5-amd64 (and earlier kernels).
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
This problem was also reported as Debian bug #613979, as kernel ticket
Did you look at this?
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
Takashi
On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
This problem was also reported as Debian bug #613979, as kernel ticket
Did you look at this?
Yes I did. So you recommend me to compile a new kernel?
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
I know there is little information, but the computer hangs during boot as shown in the bug report and the information there is copied manually during the timeout period. Then everything is blanked out since the boot continues. Any ideas?
Am Dienstag, den 29.03.2011, 12:58 +0200 schrieb Svante Signell:
On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
This problem was also reported as Debian bug #613979, as kernel ticket
Did you look at this?
Yes I did. So you recommend me to compile a new kernel?
Yes, with the ALSA source from Linux kernel 2.6.32.
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
I know there is little information, but the computer hangs during boot as shown in the bug report and the information there is copied manually during the timeout period. Then everything is blanked out since the boot continues. Any ideas?
I got these messages from `dmesg` or `/var/log/syslog`.
Thanks,
Paul
At Tue, 29 Mar 2011 12:58:16 +0200, Svante Signell wrote:
On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
This problem was also reported as Debian bug #613979, as kernel ticket
Did you look at this?
Yes I did. So you recommend me to compile a new kernel?
Yes, at least, we can know whether it's a regression in HD-audio side or in another part. But let's check the Oops first as below.
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
I know there is little information, but the computer hangs during boot as shown in the bug report and the information there is copied manually during the timeout period. Then everything is blanked out since the boot continues. Any ideas?
As mentioned, you can decode the binary dump in Oops to guess which line of the source code corresponds to the Oops point. Use gdb or objdump to figure out the disassembled code. For example,
% objdump -D -l /lib/modules/$(uname -r)/kernel/sound/pci/hda/snd-hda-intel.ko
Then look for azx_probe. Calculate the position from the offset Oops gave, compare the hex codes with the data show in "Code" section of Oops. objdump with -l will show the source code line as well, so you'll see now more exactly where it was triggered.
Takashi
On Tue, 2011-03-29 at 13:10 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:58:16 +0200, Svante Signell wrote:
On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
...
But let's check the Oops first as below.
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
...
As mentioned, you can decode the binary dump in Oops to guess which line of the source code corresponds to the Oops point. Use gdb or objdump to figure out the disassembled code. For example,
% objdump -D -l /lib/modules/$(uname -r)/kernel/sound/pci/hda/snd-hda-intel.ko
Then look for azx_probe. Calculate the position from the offset Oops gave, compare the hex codes with the data show in "Code" section of Oops. objdump with -l will show the source code line as well, so you'll see now more exactly where it was triggered.
Below is the kernel Oops and the objdump output related to azx_probe. Unfortunately I don't know where to find the Oops offset!
Kernel Oops when booting: ========================= [ 4.631033] Oops: 0009 [#1] SMP [ 4.631187] last sysfs file: /sys/devices/virtual/net/lo/operstate [ 4.631243] CPU 0 [ 4.631293] Modules linked in: snd_hda_intel(+) snd_hda_codec tpm_tis tpm pcspkr snd_hwdep tpm_bios shpchp(+) pci_hotplug k8temp nouveau(+) snd_pcm ttm drm_kms_helper drm parport_pc i2c_viapro i2c_algo_bit usblp power_supply i2c_core parport edac_core video edac_mce_amd processor psmouse evdev serio_raw button snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc thermal_sys ext3 jbd mbcache sg sr_mod cdrom usbhid sd_mod crc_t10dif ata_generic hid sata_via uhci_hcd pata_via libata ehci_hcd usbcore scsi_mod via_rhine floppy mii nls_base [last unloaded: scsi_wait_scan] [ 4.632005] [ 4.632005] Pid: 632, comm: work_for_cpu Not tainted 2.6.38-1-amd64 #1 MICRO-STAR INTERNATIONAL CO., LTD MS-7253/MS-7253 [ 4.632005] RIP: 0010:[<ffffffffa061f416>] [<ffffffffa061f416>] azx_probe+0x3ad/0x870 [snd_hda_intel] [ 4.632005] RSP: 0018:ffff88007c05be50 EFLAGS: 00010286 [ 4.632005] RAX: ffffc90013c98000 RBX: ffff880036de6000 RCX: 0000000000000006 [ 4.632005] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 4.632005] RBP: ffff88007c93d000 R08: 0000000000000000 R09: 0000000000000040 [ 4.632005] R10: 0000000000000286 R11: 000000000000a971 R12: ffff880036de5c00 [ 4.632005] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88007c93d090 [ 4.632005] FS: 00007f1cd2afb7a0(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 4.632005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 4.632005] CR2: ffffc90013c98000 CR3: 000000007c00f000 CR4: 00000000000006f0 [ 4.632005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4.632005] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 4.632005] Process work_for_cpu (pid: 632, threadinfo ffff88007c05a000, task ffff88003713a880) [ 4.632005] Stack: [ 4.632005] 0000000000000005 ffffffff81240724 0000000000000001 ffff880036de5c00 [ 4.632005] 0000000000013700 ffff88007c93d000 ffff88007c93d090 ffff88007a7c7dc8 [ 4.632005] ffff88007c93d200 0000000000000000 0000000000000000 ffffffff811b1a42 [ 4.632005] Call Trace: [ 4.632005] [<ffffffff81240724>] ? __pm_runtime_set_status +0x162/0x186 [ 4.632005] [<ffffffff811b1a42>] ? local_pci_probe+0x49/0x92 [ 4.632005] [<ffffffff8105aad2>] ? do_work_for_cpu+0x0/0x1b [ 4.632005] [<ffffffff8105aad2>] ? do_work_for_cpu+0x0/0x1b [ 4.632005] [<ffffffff8105aadd>] ? do_work_for_cpu+0xb/0x1b [ 4.632005] [<ffffffff8105fcdf>] ? kthread+0x7a/0x82 [ 4.632005] [<ffffffff8100a764>] ? kernel_thread_helper+0x4/0x10 [ 4.632005] [<ffffffff8105fc65>] ? kthread+0x0/0x82 [ 4.632005] [<ffffffff8100a760>] ? kernel_thread_helper+0x0/0x10 [ 4.632005] Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be [ 4.632005] RIP [<ffffffffa061f416>] azx_probe+0x3ad/0x870 [snd_hda_intel] [ 4.632005] RSP <ffff88007c05be50> [ 4.632005] CR2: ffffc90013c98000 [ 4.632005] ---[ end trace c6748815fe9ff43b ]---
objdump -D -l /lib/modules/$(uname -r)/kernel/sound/pci/hda/snd-hda-intel.ko
/lib/modules/2.6.38-1-amd64/kernel/sound/pci/hda/snd-hda-intel.ko: file format elf64-x86-64
00000000000001fd <azx_probe>: azx_probe():
(see attachment)
At Wed, 30 Mar 2011 12:25:44 +0200, Svante Signell wrote:
On Tue, 2011-03-29 at 13:10 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:58:16 +0200, Svante Signell wrote:
On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
...
But let's check the Oops first as below.
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
...
As mentioned, you can decode the binary dump in Oops to guess which line of the source code corresponds to the Oops point. Use gdb or objdump to figure out the disassembled code. For example,
% objdump -D -l /lib/modules/$(uname -r)/kernel/sound/pci/hda/snd-hda-intel.ko
Then look for azx_probe. Calculate the position from the offset Oops gave, compare the hex codes with the data show in "Code" section of Oops. objdump with -l will show the source code line as well, so you'll see now more exactly where it was triggered.
Below is the kernel Oops and the objdump output related to azx_probe. Unfortunately I don't know where to find the Oops offset!
This is shown in below:
[ 4.632005] RIP: 0010:[<ffffffffa061f416>] [<ffffffffa061f416>] azx_probe+0x3ad/0x870 [snd_hda_intel]
The offset is 0x3ad. As azx_probe() in the disassembled code begins with 0x1fd, it points to 0x5aa (0x1fd + 0x3ad). You can see the disassembled code matches with the dump in "Code:" in Oops.
However, you objdump output doesn't give the line number. Did you install the corresponding debug package? Usually this is stripped in the main package and provided as an add-on.
thanks,
Takashi
On Wed, 2011-03-30 at 12:59 +0200, Takashi Iwai wrote:
At Wed, 30 Mar 2011 12:25:44 +0200, Svante Signell wrote:
On Tue, 2011-03-29 at 13:10 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:58:16 +0200, Svante Signell wrote:
On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
...
But let's check the Oops first as below.
...
The offset is 0x3ad. As azx_probe() in the disassembled code begins with 0x1fd, it points to 0x5aa (0x1fd + 0x3ad). You can see the disassembled code matches with the dump in "Code:" in Oops.
Sorry, I did not see any match in the objdump and Oops Code. Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be Never mind, tanks anyway.
However, you objdump output doesn't give the line number. Did you install the corresponding debug package? Usually this is stripped in the main package and provided as an add-on.
You mean that I need to install a debug version of the kernel? If yes I will do that when having physical access to that computer again (probably tonight or tomorrow)
Svante Signell wrote:
Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
5: 31 f6 xor %esi,%esi 7: 48 89 df mov %rbx,%rdi a: e8 15 dd ff ff callq 0xffffffffffffdd24 f: 85 c0 test %eax,%eax 11: 0f 88 2b 03 00 00 js 0x342 17: 48 89 ef mov %rbp,%rdi 1a: e8 ee 11 b9 e0 callq 0xffffffffe0b9120d 1f: 8b 7b 40 mov 0x40(%rbx),%edi 22: e8 9f 25 a7 e0 callq 0xffffffffe0a725c6 27: 48 8b 43 38 mov 0x38(%rbx),%rax 2b: 66 8b 10 mov (%rax),%dx <-- crash here 2e: 66 89 14 24 mov %dx,(%rsp) 32: 8b 43 14 mov 0x14(%rbx),%eax 35: 83 e8 03 sub $0x3,%eax 38: 83 f8 01 cmp $0x1,%eax 3b: 77 32 ja 0x6f 3d: 31 d2 xor %edx,%edx
This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is 0xffffc90011c08000 which does look like a valid pointer, but isn't.
Regards, Clemens
On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
Svante Signell wrote:
Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
5: 31 f6 xor %esi,%esi 7: 48 89 df mov %rbx,%rdi a: e8 15 dd ff ff callq 0xffffffffffffdd24 f: 85 c0 test %eax,%eax 11: 0f 88 2b 03 00 00 js 0x342 17: 48 89 ef mov %rbp,%rdi 1a: e8 ee 11 b9 e0 callq 0xffffffffe0b9120d 1f: 8b 7b 40 mov 0x40(%rbx),%edi 22: e8 9f 25 a7 e0 callq 0xffffffffe0a725c6 27: 48 8b 43 38 mov 0x38(%rbx),%rax 2b: 66 8b 10 mov (%rax),%dx <-- crash here 2e: 66 89 14 24 mov %dx,(%rsp) 32: 8b 43 14 mov 0x14(%rbx),%eax 35: 83 e8 03 sub $0x3,%eax 38: 83 f8 01 cmp $0x1,%eax 3b: 77 32 ja 0x6f 3d: 31 d2 xor %edx,%edx
This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is 0xffffc90011c08000 which does look like a valid pointer, but isn't.
Thank you Clemens! Maybe your input is sufficient to solve this problem. I have now installed the debug version of the kernel, the objdump output is attached (please let me know if you are missing something).sorry, I don't know where to find the relevant information in this file, but that is all I have (still very large). (Does not include the error messages on stderr, maybe something is still missing.)
Thanks!
On Thu, 2011-03-31 at 00:42 +0200, Svante Signell wrote:
On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
Svante Signell wrote:
Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
5: 31 f6 xor %esi,%esi 7: 48 89 df mov %rbx,%rdi a: e8 15 dd ff ff callq 0xffffffffffffdd24 f: 85 c0 test %eax,%eax 11: 0f 88 2b 03 00 00 js 0x342 17: 48 89 ef mov %rbp,%rdi 1a: e8 ee 11 b9 e0 callq 0xffffffffe0b9120d 1f: 8b 7b 40 mov 0x40(%rbx),%edi 22: e8 9f 25 a7 e0 callq 0xffffffffe0a725c6 27: 48 8b 43 38 mov 0x38(%rbx),%rax 2b: 66 8b 10 mov (%rax),%dx <-- crash here 2e: 66 89 14 24 mov %dx,(%rsp) 32: 8b 43 14 mov 0x14(%rbx),%eax 35: 83 e8 03 sub $0x3,%eax 38: 83 f8 01 cmp $0x1,%eax 3b: 77 32 ja 0x6f 3d: 31 d2 xor %edx,%edx
This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is 0xffffc90011c08000 which does look like a valid pointer, but isn't.
Thank you Clemens! Maybe your input is sufficient to solve this problem. I have now installed the debug version of the kernel, the objdump output is attached (please let me know if you are missing something).sorry, I don't know where to find the relevant information in this file, but that is all I have (still very large). (Does not include the error messages on stderr, maybe something is still missing.)
Anything happening here with respect to this bug? How can I help further? Booting with 2.6.32 all the time does not feel lika a good solution in long term.
A small except from the objdump output below. The complete file is too big (400k) for the mailing list. Let me know if more is needed.
56c: be 01 00 00 00 mov $0x1,%esi 571: 48 89 ef mov %rbp,%rdi 574: e8 00 00 00 00 callq 579 <azx_probe+0x37c> 579: 85 c0 test %eax,%eax 57b: 79 07 jns 584 <azx_probe+0x387> 57d: 80 a3 f4 01 00 00 ef andb $0xef,0x1f4(%rbx) 584: 31 f6 xor %esi,%esi 586: 48 89 df mov %rbx,%rdi 589: e8 00 00 00 00 callq 58e <azx_probe+0x391> 58e: 85 c0 test %eax,%eax 590: 0f 88 2b 03 00 00 js 8c1 <azx_probe+0x6c4> 596: 48 89 ef mov %rbp,%rdi 599: e8 00 00 00 00 callq 59e <azx_probe+0x3a1> 59e: 8b 7b 40 mov 0x40(%rbx),%edi 5a1: e8 00 00 00 00 callq 5a6 <azx_probe+0x3a9> 5a6: 48 8b 43 38 mov 0x38(%rbx),%rax 5aa: 66 8b 10 mov (%rax),%dx <- crash here 5ad: 66 89 14 24 mov %dx,(%rsp) 5b1: 8b 43 14 mov 0x14(%rbx),%eax 5b4: 83 e8 03 sub $0x3,%eax 5b7: 83 f8 01 cmp $0x1,%eax 5ba: 77 32 ja 5ee <azx_probe+0x3f1> 5bc: 31 d2 xor %edx,%edx
At Mon, 04 Apr 2011 10:42:57 +0200, Svante Signell wrote:
On Thu, 2011-03-31 at 00:42 +0200, Svante Signell wrote:
On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
Svante Signell wrote:
Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
5: 31 f6 xor %esi,%esi 7: 48 89 df mov %rbx,%rdi a: e8 15 dd ff ff callq 0xffffffffffffdd24 f: 85 c0 test %eax,%eax 11: 0f 88 2b 03 00 00 js 0x342 17: 48 89 ef mov %rbp,%rdi 1a: e8 ee 11 b9 e0 callq 0xffffffffe0b9120d 1f: 8b 7b 40 mov 0x40(%rbx),%edi 22: e8 9f 25 a7 e0 callq 0xffffffffe0a725c6 27: 48 8b 43 38 mov 0x38(%rbx),%rax 2b: 66 8b 10 mov (%rax),%dx <-- crash here 2e: 66 89 14 24 mov %dx,(%rsp) 32: 8b 43 14 mov 0x14(%rbx),%eax 35: 83 e8 03 sub $0x3,%eax 38: 83 f8 01 cmp $0x1,%eax 3b: 77 32 ja 0x6f 3d: 31 d2 xor %edx,%edx
This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is 0xffffc90011c08000 which does look like a valid pointer, but isn't.
Thank you Clemens! Maybe your input is sufficient to solve this problem. I have now installed the debug version of the kernel, the objdump output is attached (please let me know if you are missing something).sorry, I don't know where to find the relevant information in this file, but that is all I have (still very large). (Does not include the error messages on stderr, maybe something is still missing.)
Anything happening here with respect to this bug? How can I help further? Booting with 2.6.32 all the time does not feel lika a good solution in long term.
The point where it Oops implies that the problem isn't in the sound driver but rather in a breakage in a deeper level, either PCI core, x86 mm or ACPI/BIOS.
Any chance to bisect the kernel?
thanks,
Takashi
On Mon, 2011-04-04 at 11:12 +0200, Takashi Iwai wrote:
At Mon, 04 Apr 2011 10:42:57 +0200, Svante Signell wrote:
On Thu, 2011-03-31 at 00:42 +0200, Svante Signell wrote:
On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
...
Anything happening here with respect to this bug? How can I help further? Booting with 2.6.32 all the time does not feel like a good solution in long term.
The point where it Oops implies that the problem isn't in the sound driver but rather in a breakage in a deeper level, either PCI core, x86 mm or ACPI/BIOS.
Any chance to bisect the kernel?
Never done that before. Is there a bisect HOWTO somewhere?
Am Montag, den 04.04.2011, 11:21 +0200 schrieb Svante Signell:
On Mon, 2011-04-04 at 11:12 +0200, Takashi Iwai wrote:
At Mon, 04 Apr 2011 10:42:57 +0200, Svante Signell wrote:
On Thu, 2011-03-31 at 00:42 +0200, Svante Signell wrote:
On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
...
Anything happening here with respect to this bug? How can I help further? Booting with 2.6.32 all the time does not feel like a good solution in long term.
The point where it Oops implies that the problem isn't in the sound driver but rather in a breakage in a deeper level, either PCI core, x86 mm or ACPI/BIOS.
The problem is still present with 2.6.39.
Any chance to bisect the kernel?
Never done that before. Is there a bisect HOWTO somewhere?
Ben, I am sorry to bother you directly, but there are so many howtos on the Web, it would be great if you could point us to an “official” one, which has proofed itself. Or maybe you could write up a blog post. ;-)
Anyway I did not find any information here.
$ ls /usr/share/doc/linux-image-2.6.39-1-amd64/ changelog.Debian.gz copyright
Thanks,
Paul
Am Sonntag, den 22.05.2011, 19:56 +0200 schrieb Paul Menzel:
Am Montag, den 04.04.2011, 11:21 +0200 schrieb Svante Signell:
On Mon, 2011-04-04 at 11:12 +0200, Takashi Iwai wrote:
At Mon, 04 Apr 2011 10:42:57 +0200, Svante Signell wrote:
On Thu, 2011-03-31 at 00:42 +0200, Svante Signell wrote:
On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
...
Anything happening here with respect to this bug? How can I help further? Booting with 2.6.32 all the time does not feel like a good solution in long term.
The point where it Oops implies that the problem isn't in the sound driver but rather in a breakage in a deeper level, either PCI core, x86 mm or ACPI/BIOS.
The problem is still present with 2.6.39.
Any chance to bisect the kernel?
Never done that before. Is there a bisect HOWTO somewhere?
Ben, I am sorry to bother you directly, but there are so many howtos on the Web, it would be great if you could point us to an “official” one, which has proofed itself. Or maybe you could write up a blog post. ;-)
Anyway I did not find any information here.
$ ls /usr/share/doc/linux-image-2.6.39-1-amd64/ changelog.Debian.gz copyright
Svante, if you have some time, could you please try to follow the Wiki page DebianKernel/GitBisect [1] in the Debian Wiki. Unfortunately I will not have time until the beginning of July.
Thanks,
Paul
Am Dienstag, den 29.03.2011, 12:31 +0200 schrieb Takashi Iwai:
At Tue, 29 Mar 2011 12:24:40 +0200, Svante Signell wrote:
This problem was also reported as Debian bug #613979, as kernel ticket
Did you look at this?
Also, please try to decode the line from the code shown in the Oops. It's a bit too little information to analyze, unfortunately.
Unfortunately I have not yet had time to compile a Linux kernel 2.6.38, where this problem is also present, with the ALSA source from 2.6.32.
Thanks,
Paul
PS: Svante, for the Debian BTS please always put the submitter into CC because otherwise they do not get the message. To keep threading please import the mbox file retrieved by `bts show --mbox #bugnumber`.
participants (4)
-
Clemens Ladisch -
Paul Menzel -
Svante Signell -
Takashi Iwai