Re: [uml-user] another gdb trace from a hanging UML process

[Toralf F. <tor...@gm...>]

On 01/02/2013 06:53 AM, Tully Gray wrote:
> Toralf Förster wrote:
>> This is still related to investigate an issue with a hanging UML/crashing UML (32 bit Gentoo Linux as host and guest).
>>
>> The following output was derived from the gdb - does it contain any helpful information ?
>> The host kernel is 3.7.1, the guest ran a linux-v3.7-9431-gfa4c95b kernel
>>
>>
>>
>> 0x0805f27c in from_irq_stack (nested=0) at arch/um/kernel/irq.c:462
>> 462             current->stack = to;
>> (gdb) cont
>> Continuing.                                                                                                                                            
>>                                                                                                                                                        
>> Program received signal SIGSEGV, Segmentation fault.                                                                                                   
>> 0x0805f27c in from_irq_stack (nested=0) at arch/um/kernel/irq.c:462                                                                                    
>> 462             current->stack = to;                                                                                                                   
>> (gdb) bt                                                                                                                                               
>> #0  0x0805f27c in from_irq_stack (nested=0) at arch/um/kernel/irq.c:462                                                                                
>> #1  0x080717dd in hard_handler (sig=<optimized out>, si=0x83fdb0c <cpu0_irqstack+2828>,                                                                
>>     p=0x83fdb8c <cpu0_irqstack+2956>) at arch/um/os-Linux/signal.c:175                                                                                 
>> #2  <signal handler called>                                                                                                                            
>> #75 userspace (regs=0x383ccd50) at arch/um/os-Linux/skas/process.c:426
>> #76 0x0805f7fc in fork_handler () at arch/um/kernel/process.c:160
>> #77 0x00000002 in ?? ()
>> (

> Hi,
> 
> I increased the stack size (CONFIG_KERNEL_STACK_ORDER) in the guest
> kernel and the problem went away.  I think I had a very similar problem
> under 32 bit with Gentoo host/guest.

Well, if I set that value to "3", then the issue happens much more
rarely than before.

Setting it to "5" gives here at an 32 bit Gentoo every time during start :

Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
Kernel panic - not syncing: Kernel mode signal 4
0845f754:  [<0833e1a8>] dump_stack+0x22/0x24
0845f76c:  [<0833e224>] panic+0x7a/0x18b
0845f794:  [<0806224c>] relay_signal+0x4c/0x150
0845f840:  [<08071ab8>] sig_handler_common+0xb8/0xe0
0845fac4:  [<08071bfd>] sig_handler+0x3d/0x50
0845fad4:  [<0807174b>] hard_handler+0x6b/0xa0
0845fafc:  [<b776640c>] 0xb776640c


EIP: 0073:[<b7766424>] CPU: 0 Not tainted ESP: 007b:bfb3d5e4 EFLAGS:
00000286
    Not tainted
EAX: 00000000 EBX: 00001cb3 ECX: 00000013 EDX: 00001cb3
ESI: 00001caf EDI: bfb3d678 EBP: bfb3d618 DS: 007b ES: 007b
0845f708:  [<0807957f>] show_regs+0x10f/0x120
0845f724:  [<0806255c>] panic_exit+0x2c/0x50
0845f734:  [<0809e158>] notifier_call_chain+0x38/0x60
0845f75c:  [<0809e2a3>] atomic_notifier_call_chain+0x23/0x30
0845f76c:  [<0833e24c>] panic+0xa2/0x18b
0845f794:  [<0806224c>] relay_signal+0x4c/0x150
0845f840:  [<08071ab8>] sig_handler_common+0xb8/0xe0
0845fac4:  [<08071bfd>] sig_handler+0x3d/0x50
0845fad4:  [<0807174b>] hard_handler+0x6b/0xa0
0845fafc:  [<b776640c>] 0xb776640c



-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3