NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-powerpc/46591: Doing "ktrace -p <pid>" triggered panic

>Number:         46591
>Category:       port-powerpc
>Synopsis:       Doing "ktrace -p <pid>" triggered panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 12 09:00:00 +0000 2012
>Originator:     Havard Eidnes
>Release:        NetBSD 6.0_BETA2
System: NetBSD 6.0_BETA2 NetBSD 6.0_BETA2 (GENERIC) #5: 
Wed May 30 20:32:20 CEST 2012 
Architecture: powerpc
Machine: macppc
        During a pkgsrc bulk build, an awk process appeared to be
        spinning on the CPU checking for "porbability" of a Bourne
        shell script.  I wanted to see if it was doing any system
        calls, and what they were, so did a

        ktrace -p <pid>

        on the process, something which triggered an instant panic.

        This was what was left in the messages file after the machine
        came back up again:

panic: cpu_uarea_alloc: uvm_pglistalloc failed: 12
cpu0: Begin traceback...
0xd9d5bc40: at panic+0x4c
0xd9d5bc80: at cpu_uarea_alloc+0x78
0xd9d5bcb0: at uarea_system_poolpage_alloc+0x20
0xd9d5bcc0: at pool_grow+0x48
0xd9d5bce0: at pool_get+0x58
0xd9d5bd00: at pool_cache_get_slow+0x1a4
0xd9d5bd50: at pool_cache_get_paddr+0x104
0xd9d5bd90: at uvm_uarea_system_alloc+0x1c
0xd9d5bda0: at kthread_create+0x60
0xd9d5be00: at ktrace_common+0x390
0xd9d5be40: at sys_ktrace+0xf4
0xd9d5bec0: at syscall_plain+0x1f0
0xd9d5bf20: user SC trap #45 by 0xfde8120c: srr1=0xd032
           r1=0xffffd760 cr=0x28000044 xer=0x20000000 ctr=0xfde81204
cpu0: End traceback...
dumpsys: TBD

        Since there doesn't appear to be any code to dump kernel core,
        that's all I'm left with.

        12 is ENOMEM.

        ...and since uarea_system_poolpage_alloc() calls
        cpu_uarea_alloc with "true", it panics.  It appears that
        uarea_system_poolpage_alloc() is prepared to deal with a NULL
        return from cpu_uarea_alloc(), though, but on powerpc, it
        appears that cpu_uarea_alloc() will never return NULL, but
        will instead panic if called with system=true and there's a
        memory shortage "somewhere".

        This is different from x86, where the code doesn't check the
        "system" argument, and doesn't panic() inside

        I'm not sure how repeatable this is...

        Sorry, don't know.

Home | Main Index | Thread Index | Old Index