All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Stucke <ps@roqe.org>
To: linux-kernel@vger.kernel.org
Subject: kernel BUG at include/asm/spinlock.h:136!
Date: Sun, 10 Oct 2004 13:58:50 +0200	[thread overview]
Message-ID: <1097409530.14456.11.camel@localhost> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 5621 bytes --]

Hi,

problem occures when a program (dvbscan) speaks to a usb device (TwinHan
DVB-T Visionplus). Kernel is 2.6.9-rc3-mm3; but it also happened with
earlier kernels (2.6.8, 2.6.8.1, 2.6.9-rc*-mm*). Other USB devices
(chipcard reader) work flawlessly. 

The problem seems to be related to SMP, since if I boot a UP kernel, the
device works as expected.

I've attached .config and dmesg. Please CC me since I'm not subscribed.
I'll provide further information on request.

With kind regards,
Phil

Output of ksymoops:

ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
testing NMI watchdog ... OK.
Machine check exception polling timer started.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:02:08.0: 3Com PCI 3c905C Tornado at 0x9800. Vers LK1.1.19
eip: c02b83e1
kernel BUG at include/asm/spinlock.h:136!
invalid operand: 0000 [#1]
CPU:    1
EIP:    0060:[<c012f2f5>]    Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010092   (2.6.9-rc3-mm3)
eax: 0000000e   ebx: dea6401c   ecx: c02f5494   edx: 00000096
esi: 00000246   edi: 00000000   ebp: db705e1c   esp: db705e04
ds: 007b   es: 007b   ss: 0068
Stack: c02c5fd3 c02b83e1 00000163 00000246 dea6401c 00000000 db705e28
c02b83e1
       dea64000 db705e3c e09c92a4 e09e8000 e09e8000 dea64000 db705e58
e09c9491
       dea6463c db705e50 00000000 e09e8000 dea6463c db705e70 e09d7174
dea64458
Call Trace:
 [<c0104e1a>]
 [<c0104f95>]
 [<c01051a0>]
 [<c0105654>]
 [<c0104a3d>]
 [<c02b83e1>]
 [<e09c92a4>]
 [<e09c9491>]
 [<e09d7174>]
 [<e09d4bb4>]
 [<e09d5425>]
 [<e09d383a>]
 [<e09d551a>]
 [<c0164535>]
 [<c0103f81>]
Code: f8 8b 7d fc c9 c3 8b 55 f0 31 c9 89 d8 e8 34 fd ff ff 66 89 43 02
eb e3 8b 45 04 c7 04 24 d3 5f 2c c0 89 44 24 04 e8 1b a9 fe ff <0f> 0b
88 00 3c 58 2c c0 e9 57 ff ff ff 8b 45 04 c7 04 24 d3 5f


>>EIP; c012f2f5 <_metered_spin_lock_flags+c5/100>   <=====

>>ebx; dea6401c <pg0+1e6c301c/3fc5d400>
>>ecx; c02f5494 <log_wait+8/10>
>>ebp; db705e1c <pg0+1b364e1c/3fc5d400>
>>esp; db705e04 <pg0+1b364e04/3fc5d400>

Trace; c0104e1a <show_stack+7a/90>
Trace; c0104f95 <show_registers+145/1c0>
Trace; c01051a0 <die+f0/180>
Trace; c0105654 <do_invalid_op+d4/f0>
Trace; c0104a3d <error_code+2d/38>
Trace; c02b83e1 <_spin_lock_irqsave+11/20>
Trace; e09c92a4 <pg0+206282a4/3fc5d400>
Trace; e09c9491 <pg0+20628491/3fc5d400>
Trace; e09d7174 <pg0+20636174/3fc5d400>
Trace; e09d4bb4 <pg0+20633bb4/3fc5d400>
Trace; e09d5425 <pg0+20634425/3fc5d400>
Trace; e09d383a <pg0+2063283a/3fc5d400>
Trace; e09d551a <pg0+2063451a/3fc5d400>
Trace; c0164535 <sys_ioctl+1d5/230>
Trace; c0103f81 <sysenter_past_esp+52/71>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  c012f2ca <_metered_spin_lock_flags+9a/100>
00000000 <_EIP>:
Code;  c012f2ca <_metered_spin_lock_flags+9a/100>
   0:   f8                        clc
Code;  c012f2cb <_metered_spin_lock_flags+9b/100>
   1:   8b 7d fc                  mov    0xfffffffc(%ebp),%edi
Code;  c012f2ce <_metered_spin_lock_flags+9e/100>
   4:   c9                        leave
Code;  c012f2cf <_metered_spin_lock_flags+9f/100>
   5:   c3                        ret
Code;  c012f2d0 <_metered_spin_lock_flags+a0/100>
   6:   8b 55 f0                  mov    0xfffffff0(%ebp),%edx
Code;  c012f2d3 <_metered_spin_lock_flags+a3/100>
   9:   31 c9                     xor    %ecx,%ecx
Code;  c012f2d5 <_metered_spin_lock_flags+a5/100>
   b:   89 d8                     mov    %ebx,%eax
Code;  c012f2d7 <_metered_spin_lock_flags+a7/100>
   d:   e8 34 fd ff ff            call   fffffd46 <_EIP+0xfffffd46>
Code;  c012f2dc <_metered_spin_lock_flags+ac/100>
  12:   66 89 43 02               mov    %ax,0x2(%ebx)
Code;  c012f2e0 <_metered_spin_lock_flags+b0/100>
  16:   eb e3                     jmp    fffffffb <_EIP+0xfffffffb>
Code;  c012f2e2 <_metered_spin_lock_flags+b2/100>
  18:   8b 45 04                  mov    0x4(%ebp),%eax
Code;  c012f2e5 <_metered_spin_lock_flags+b5/100>
  1b:   c7 04 24 d3 5f 2c c0      movl   $0xc02c5fd3,(%esp)
Code;  c012f2ec <_metered_spin_lock_flags+bc/100>
  22:   89 44 24 04               mov    %eax,0x4(%esp)
Code;  c012f2f0 <_metered_spin_lock_flags+c0/100>
  26:   e8 1b a9 fe ff            call   fffea946 <_EIP+0xfffea946>

This decode from eip onwards should be reliable

Code;  c012f2f5 <_metered_spin_lock_flags+c5/100>
00000000 <_EIP>:
Code;  c012f2f5 <_metered_spin_lock_flags+c5/100>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c012f2f7 <_metered_spin_lock_flags+c7/100>
   2:   88 00                     mov    %al,(%eax)
Code;  c012f2f9 <_metered_spin_lock_flags+c9/100>
   4:   3c 58                     cmp    $0x58,%al
Code;  c012f2fb <_metered_spin_lock_flags+cb/100>
   6:   2c c0                     sub    $0xc0,%al
Code;  c012f2fd <_metered_spin_lock_flags+cd/100>
   8:   e9 57 ff ff ff            jmp    ffffff64 <_EIP+0xffffff64>
Code;  c012f302 <_metered_spin_lock_flags+d2/100>
   d:   8b 45 04                  mov    0x4(%ebp),%eax
Code;  c012f305 <_metered_spin_lock_flags+d5/100>
  10:   c7                        .byte 0xc7
Code;  c012f306 <_metered_spin_lock_flags+d6/100>
  11:   04 24                     add    $0x24,%al
Code;  c012f308 <_metered_spin_lock_flags+d8/100>
  13:   d3                        .byte 0xd3
Code;  c012f309 <_metered_spin_lock_flags+d9/100>
  14:   5f                        pop    %edi


[-- Attachment #1.2: config.gz --]
[-- Type: application/x-gzip, Size: 7403 bytes --]

[-- Attachment #1.3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 6314 bytes --]

[-- Attachment #1.4: output_ver_linux.gz --]
[-- Type: application/x-gzip, Size: 600 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

                 reply	other threads:[~2004-10-10 11:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1097409530.14456.11.camel@localhost \
    --to=ps@roqe.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.