Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-06-23 Thread Svante Signell
 From: Paul Menzel paulepan...@users.sourceforge.net
 To: alsa-de...@alsa-project.org
 Cc: 619...@bugs.debian.org, s...@kth.se, 613...@bugs.debian.org
 Subject: Re: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38
 Date: Tue, 24 May 2011 12:23:31 +0200
...
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.
  
---
 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
 
 
 [1] http://wiki.debian.org/DebianKernel/GitBisect

Sorry, I missed your reply due to [alsa-devel] in the title and the
high traffic in the alsa-devel mailing list. I have now unsubscribed
from that mailing list since the problems are probably due to other
reasons. I will try to bisect when I find the time. Thank you for the
link.




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1308814824.31174.73.ca...@hp.my.own.domain



Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-05-24 Thread Paul Menzel
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


[1] http://wiki.debian.org/DebianKernel/GitBisect


signature.asc
Description: This is a digitally signed message part


Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-05-22 Thread 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


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part


Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-04-04 Thread Takashi Iwai
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 dfmov%rbx,%rdi
  a:   e8 15 dd ff ff  callq  0xdd24
  f:   85 c0   test   %eax,%eax
 11:   0f 88 2b 03 00 00   js 0x342
 17:   48 89 efmov%rbp,%rdi
 1a:   e8 ee 11 b9 e0  callq  0xe0b9120d
 1f:   8b 7b 40mov0x40(%rbx),%edi
 22:   e8 9f 25 a7 e0  callq  0xe0a725c6
 27:   48 8b 43 38 mov0x38(%rbx),%rax
 2b:   66 8b 10mov(%rax),%dx -- crash here
 2e:   66 89 14 24 mov%dx,(%rsp)
 32:   8b 43 14mov0x14(%rbx),%eax
 35:   83 e8 03sub$0x3,%eax
 38:   83 f8 01cmp$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
   0xc90011c08000 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



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/s5h8vvqv0r2.wl%ti...@suse.de



Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-04-04 Thread 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.
 
 Any chance to bisect the kernel?

Never done that before. Is there a bisect HOWTO somewhere?




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1301908906.32453.94.ca...@s1499.it.kth.se



Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-03-30 Thread Svante Signell
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:[a061f416]  [a061f416]
azx_probe+0x3ad/0x870 [snd_hda_intel]
[4.632005] RSP: 0018:88007c05be50  EFLAGS: 00010286
[4.632005] RAX: c90013c98000 RBX: 880036de6000 RCX:
0006
[4.632005] RDX:  RSI: 0246 RDI:
0246
[4.632005] RBP: 88007c93d000 R08:  R09:
0040
[4.632005] R10: 0286 R11: a971 R12:
880036de5c00
[4.632005] R13:  R14:  R15:
88007c93d090
[4.632005] FS:  7f1cd2afb7a0() GS:88007fc0()
knlGS:
[4.632005] CS:  0010 DS:  ES:  CR0: 8005003b
[4.632005] CR2: c90013c98000 CR3: 7c00f000 CR4:
06f0
[4.632005] DR0:  DR1:  DR2:

[4.632005] DR3:  DR6: 0ff0 DR7:
0400
[4.632005] Process work_for_cpu (pid: 632, threadinfo
88007c05a000, task 88003713a880)
[4.632005] Stack:
[4.632005]  0005 81240724 0001
880036de5c00
[4.632005]  00013700 88007c93d000 88007c93d090
88007a7c7dc8
[4.632005]  88007c93d200  
811b1a42
[4.632005] Call Trace:
[4.632005]  [81240724] ? __pm_runtime_set_status
+0x162/0x186
[4.632005]  [811b1a42] ? local_pci_probe+0x49/0x92
[4.632005]  [8105aad2] ? do_work_for_cpu+0x0/0x1b
[4.632005]  [8105aad2] ? do_work_for_cpu+0x0/0x1b
[4.632005]  [8105aadd] ? do_work_for_cpu+0xb/0x1b
[4.632005]  [8105fcdf] ? kthread+0x7a/0x82
[4.632005]  [8100a764] ? kernel_thread_helper+0x4/0x10
[4.632005]  [8105fc65] ? kthread+0x0/0x82
[4.632005]  [8100a760] ? 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  [a061f416] azx_probe+0x3ad/0x870
[snd_hda_intel]
[4.632005]  RSP 88007c05be50
[4.632005] CR2: c90013c98000
[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

01fd azx_probe:
azx_probe():

(see attachment)


/lib/modules/2.6.38-1-amd64/kernel/sound/pci/hda/snd-hda-intel.ko: file 
format elf64-x86-64


01fd azx_probe:
azx_probe():
 1fd:   41 57   push   %r15
 1ff:   41 56   push   %r14
 201:   41 be ed ff ff ff   mov$0xffed,%r14d
 207:   41 55   push   %r13
 209:   41 54   push   %r12
 20b:   55  

Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-03-30 Thread Takashi Iwai
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:[a061f416]  [a061f416]
 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



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/s5hpqp827sv.wl%ti...@suse.de



Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-03-30 Thread Svante Signell
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)





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1301486370.32453.9.ca...@s1499.it.kth.se



Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

2011-03-30 Thread Clemens Ladisch
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 dfmov%rbx,%rdi
   a:   e8 15 dd ff ff  callq  0xdd24
   f:   85 c0   test   %eax,%eax
  11:   0f 88 2b 03 00 00   js 0x342
  17:   48 89 efmov%rbp,%rdi
  1a:   e8 ee 11 b9 e0  callq  0xe0b9120d
  1f:   8b 7b 40mov0x40(%rbx),%edi
  22:   e8 9f 25 a7 e0  callq  0xe0a725c6
  27:   48 8b 43 38 mov0x38(%rbx),%rax
  2b:   66 8b 10mov(%rax),%dx -- crash here
  2e:   66 89 14 24 mov%dx,(%rsp)
  32:   8b 43 14mov0x14(%rbx),%eax
  35:   83 e8 03sub$0x3,%eax
  38:   83 f8 01cmp$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
0xc90011c08000 which does look like a valid pointer, but isn't.


Regards,
Clemens



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d932c71.10...@ladisch.de