Subject: kern/31286: Repeatable panic on NetBSD/alpha 3.99.8.
To: None <,,>
From: None <>
List: netbsd-bugs
Date: 09/10/2005 10:18:00
>Number:         31286
>Category:       kern
>Synopsis:       Repeatable panic on NetBSD/alpha 3.99.8.
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 10 10:18:00 +0000 2005
>Originator:     Lars Nordlund
>Release:        3.99.8
NetBSD ardbeg 3.99.8 NetBSD 3.99.8 (ARDBEG) #0: Sat Sep 10 02:03:24 CEST 2005  lars@ardbeg:/home/lars/tmp/obj_alpha/sys/arch/alpha/compile/ARDBEG alpha


When trying libmicro 0.3.0 [1] on NetBSD/alpha 3.99.8 I got a panic.

(gdb backtrace from kernel core dump)

#0  0xfffffc0000a3026c in dumpsys ()
    at /usr/src/sys/arch/alpha/alpha/machdep.c:1226
#1  0xfffffc0000a2fcfc in cpu_reboot (howto=256, bootstr=0x0)
    at /usr/src/sys/arch/alpha/alpha/machdep.c:1047
#2  0xfffffc00007703d4 in panic (fmt=0xfffffc0000c66b71 "trap")
    at /usr/src/sys/kern/subr_prf.c:244
#3  0xfffffc0000a3a774 in trap (a0=56, a1=1, a2=1, entry=2, 
at /usr/src/sys/arch/alpha/alpha/trap.c:601
#4  0xfffffc0000300400 in XentMM ()
    at /usr/src/sys/arch/alpha/alpha/locore.s:492
#5  0xfffffc0000881250 in amap_alloc (sz=0, padsz=0, waitf=8922840)
    at /usr/src/sys/uvm/uvm_amap.c:257
#6  0xfffffc0000881250 in amap_alloc (sz=1966080, padsz=0, waitf=1)
    at /usr/src/sys/uvm/uvm_amap.c:257
#7  0xfffffc00008826d8 in amap_copy (map=0xfffffc001ab3e420, 
    entry=0xfffffc00139b3968, waitf=1, canchunk=1, startva=6343876608, 
    endva=6343876609) at /usr/src/sys/uvm/uvm_amap.c:775
#8  0xfffffc0000888b4c in uvmfault_amapcopy (ufi=0xfffffe000eaabb20)
    at /usr/src/sys/uvm/uvm_fault.c:245
#9  0xfffffc00008893ec in uvm_fault (orig_map=0xfffffc001ab3e420, 
    vaddr=6343876608, fault_type=1, access_type=2)
    at /usr/src/sys/uvm/uvm_fault.c:657
#10 0xfffffc0000a3a47c in trap (a0=6343880704, a1=1, a2=1, entry=2, 
at /usr/src/sys/arch/alpha/alpha/trap.c:502
#11 0xfffffc0000300400 in XentMM ()
    at /usr/src/sys/arch/alpha/alpha/locore.s:492

The amap variable in #5 contains:

(gdb) p *amap
$4 = {am_l = {lock_data = 8948556}, am_ref = -1024, am_flags =
-2097152, am_maxslot = 1, am_nslot = 246069960, am_nused = -512, 
  am_slots = 0xfffffc00139b3968, am_bckptr = 0xfffffc001ab3e420, 
  am_anon = 0xfffffc00139b3968, am_ppref = 0x100000001, am_list = {
    le_next = 0x17a1fe000, le_prev = 0x17a1fe001}}

Not really sure how useful the information really is, or how much I
should provide. 

Actually, when looking more closely now it seems that the first panic
which I had to type down from screen is a bit different:

panic: trap
Stopped in pid 622.1 (pthread_create) at  netbsd:cpu_Debugger+0x14:
r    zero,s6,sp
db> bt
cpu_Debugger() at netbsd:cpu_Debugger+0x14
panic() at netbsd:panic+0x190
trap() at netbsd:trap+0x93c
XentMM() at netbsd:XentMM+0x20
--- memory management fault (from ipl 0) ---
amap_list_insert() at netbsd:amap_list_insert+0x28
amap_alloc() at netbsd:amap_alloc+0x118
amap_copy() at netbsd:amap_copy+0x18c
uvmfault_amapcopy() at netbsd:uvmfault_amapcopy+0x84
uvm_fault() at netbsd:uvm_fault+0x2bc
trap() at netbsd:trap+0x644
XentMM() at netbsd:XentMM+0x20
--- memory management fault ---
--- user mode ---

Running the same test on NetBSD/i386 3.99.8 gives:

# ./pthread_create
pthread_create: Cannot allocate memory
pthread_create: Cannot allocate memory

To compile [1] I had to ifdef away calls to
pthread_mutexattr_setpshared because that function does not exist in
the NetBSD implementation.

At the moment I am not sure what the test case is trying to do. Perhaps
something illegal, but when running from multiuser, as !root, the
machine still panics.


Compile libMicro 0.3.0 by creating a Makefile.NetBSD and ifdefing away calls to pthread_mutexattr_setpshared(). I used "CFLAGS=-O2 -mcpu=21164a -mieee" and "CPPFLAGS=-DNetBSD -D_REENTRANT"

Run the resulting bin-alpha/pthread_create

The machine should panic shortly after.

Running the program in single user mode, as root.. seems to work, for some reason.