[2.1.101] Double Oops deadlocks SMP kernel

Marcus Meissner (marcus@jet.franken.de)
Tue, 19 May 1998 21:14:33 +0200 (MEST)


Hi,

Using wine I can manage to deadlock the Linux kernel.

Machine is: AMD K6/200, 64MB
Kernel: Linux 2.1.101, SMP (on UP) and UP.

(rest of configuration and .config is irrelevant for this case)

On quitting a debugged WINE executable following Oops appears:

|invalid TSS: 01e4
|CPU: 0
|EIP: 0010:[<c01112c0>]
|EFLAGS: 00000282
|eax: c01e071c ebx: c2820000 ecx: c2821ef0 edx: 00000080
|esi: c0106000 edi: 00001e80 ebp: c2821f04 esp: c2821edc
|ds: 0018 es: 0018 ss: 0018
|Process wine (pid: 182, process nr: 35, stackpage=c2821000)
|Stack: general protection: 01e4
|CPU: 0
|EIP: 0010:[<c010ab75>]
|EFLAGS: 00010046
|eax: c26d8280 ebx: c2821edc ecx: c3a3e000 edx: c01e0a50
|esi: 00000000 edi: c2821edc ebp: c2821ea8 esp: c2821e40
|ds: 0018 es: 0018 ss: 0018
|Process wine (pid: 182, process nr: 35, stackpage=c2821000)
|Stack: 000001e7 c2821ea8 c2821ea8 00001e80 c2821f04 c28201ce 00000202 00000082
| c01f0018 c010accc c2821ea8 c01c0c8f c01c0d0a 000001e4 000001e4 c010af65
| c01c0d0a c2821ea8 000001e4 0000000b c2820000 c2820000 c0106000 c010a8e0
|Call Trace: [<c010accc>] [<c01c0c8f>] [<c01c0d0a>] [<c010af65>] [<c01c0d0a>] [<c0106000>] [<c010a8e0>]
| [<c0106000>] [<c01112c0>] [<c0110d7c>] [<c012d8c0>] [<c012dc31>] [<c010e73a>] [<c010a768>]
|Code: 0f a1 83 c7 04 50 68 5f 0c 1c c0 e8 7b 8d 00 00 83 c4 08 46

# scripts/ksymoops System.map </home/marcus/xx
Using `System.map' to map addresses to symbols.

>>EIP: c01112c0 <schedule+1d0/234>
>>EIP: c010ab75 <show_registers+139/254>
Trace: c010accc <die_if_kernel+3c/48>
Trace: c01c0c8f <stext_lock+ecf/1ac8>
Trace: c01c0d0a <stext_lock+f4a/1ac8>
Trace: c010af65 <do_invalid_TSS+35/3c>
Trace: c01c0d0a <stext_lock+f4a/1ac8>
Trace: c0106000 <this_must_match_init_task>
Trace: c010a8e0 <error_code+30/40>
Trace: c0106000 <this_must_match_init_task>
Trace: c01112c0 <schedule+1d0/234>
Trace: c0110d7c <process_timeout>
Trace: c012d8c0 <do_select+1ac/1ec>
Trace: c012dc31 <sys_select+331/4b4>
Trace: c010e73a <old_select+5a/78>
Trace: c010a768 <system_call+38/40>
Code: c010ab75 <show_registers+139/254>
Code: c010ab75 <show_registers+139/254> 0f a1 popl %fs
Code: c010ab77 <show_registers+13b/254> 83 c7 04 addl $0x4,%ediCode: c010ab7a <show_registers+13e/254> 50 pushl %eax
Code: c010ab7b <show_registers+13f/254> 68 5f 0c 1c c0 pushl $0xc01c0c5f
Code: c010ab86 <show_registers+14a/254> e8 7b 8d 00 00 call c0113900
<printk>
Code: c010ab8b <show_registers+14f/254> 83 c4 08 addl $0x8,%espCode: c010ab8e <show_registers+152/254> 46 incl %esi

This is the output on the #SMP=1 kernel. The SMP=1 kernel hangs on
directly after the first Stack: (where general protection is printed in above
case).

The second Oops is hanging on SMP kernels due to locks already held and
needs to be fixed.

The first Oops is some problem in the schedule code, line 496:
switch_to(prev,next);
the EIP in the UP case is at
"cmpl %1,"SYMBOL_NAME_STR(last_task_used_math)"\n\t" \
in the SMP case it is at 'prev->debugreg[7]', both in in switch_to().
(just after the ljmp).
I don't know why it appears.

Ciao, Marcus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu