NetBSD Problem Report #49396

From martin@duskware.de  Sun Nov 16 13:07:49 2014
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B5893A660E
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 16 Nov 2014 13:07:49 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: reproducable panic on puffs
X-Send-Pr-Version: 3.95

>Number:         49396
>Category:       kern
>Synopsis:       reproducable panic on puffs
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 16 13:10:00 +0000 2014
>Last-Modified:  Mon Nov 17 09:50:00 +0000 2014
>Originator:     Martin Husemann
>Release:        NetBSD 7.99.1
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD space-truckin.duskware.de 7.99.1 NetBSD 7.99.1 (CUBIETRUCK) #98: Sun Nov 16 11:22:24 CET 2014 martin@night-owl.duskware.de:/usr/src/sys/arch/evbarm/compile/CUBIETRUCK evbarm
Architecture: earmv7hfeb
Machine: evbarm
>Description:

Running the resize_ffs test reproducably panics my machine:

uvm_fault(0x805462f8, ffffe000, 1) -> e
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xbf109c60                                
FSR=00000005, FAR=fffffffc, spsr=a0070213
r0 =00000001, r1 =e4082000, r2 =00000001, r3 =bf20e3e0
r4 =fffffff0, r5 =be525b80, r6 =bf20e3e0, r7 =be909e00
r8 =bf20e3e0, r9 =805410f8, r10=fffffff0, r11=bf109ccc
r12=bf109cd0, ssp=bf109cb0, slr=80146360, pc =80146378

Stopped in pid 13929.1 (tar) at netbsd:mutex_oncpu+0x30:        ldr     r0, [r4,
 #0x00c]                                                                       
db{1}> bt
0xbf109ccc: netbsd:mutex_oncpu+0xc
0xbf109d2c: netbsd:mutex_enter+0xb0
0xbf109d7c: puffs:puffs_msg_wait+0xd8
0xbf109d9c: puffs:puffs_msg_wait2+0x1c
0xbf109de4: puffs:puffs_vnop_rename+0x188
0xbf109df4: puffs:puffs_vnop_checkop+0x120
0xbf109e34: netbsd:VOP_RENAME+0x80        
0xbf109eec: netbsd:do_sys_renameat+0x478
0xbf109f0c: netbsd:sys_rename+0x38      
0xbf109f7c: netbsd:syscall+0x88   

db{1}> x/i mutex_oncpu 
netbsd:mutex_oncpu:     mov     r12, r13
netbsd:mutex_oncpu+0x4: push    {r4, r11-r12, r14-r15}
netbsd:mutex_oncpu+0x8: sub     r11, r12, #0x00000004
netbsd:mutex_oncpu+0xc: sub     r13, r13, #0x0000000c
netbsd:mutex_oncpu+0x10:        mov     r4, r0



>How-To-Repeat:
On a machine with pseudo-device putter enabled:
# cd /usr/tests/sbin/resize_ffs/
# atf-run t_grow |atf-report 

>Fix:
n/a

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/49396
Date: Sun, 16 Nov 2014 14:26:23 +0100

 Here is mutex_oncpu in full length:

 Reading symbols from netbsd.gdb...done.
 (gdb) x/16i mutex_oncpu
    0x80146348 <mutex_oncpu>:    mov     r12, sp
    0x8014634c <mutex_oncpu+4>:  push    {r4, r11, r12, lr, pc}
    0x80146350 <mutex_oncpu+8>:  sub     r11, r12, #4
    0x80146354 <mutex_oncpu+12>: sub     sp, sp, #12
    0x80146358 <mutex_oncpu+16>: mov     r4, r0
    0x8014635c <mutex_oncpu+20>: bl      0x8015cb18 <kpreempt_disabled>
    0x80146360 <mutex_oncpu+24>: cmp     r0, #0
    0x80146364 <mutex_oncpu+28>: beq     0x801463b0 <mutex_oncpu+104>
    0x80146368 <mutex_oncpu+32>: cmp     r4, #0
    0x8014636c <mutex_oncpu+36>: moveq   r0, r4
    0x80146370 <mutex_oncpu+40>: beq     0x80146394 <mutex_oncpu+76>
    0x80146374 <mutex_oncpu+44>: bic     r4, r4, #15
    0x80146378 <mutex_oncpu+48>: ldr     r0, [r4, #12]
    0x8014637c <mutex_oncpu+52>: cmp     r0, #0
    0x80146380 <mutex_oncpu+56>: beq     0x80146394 <mutex_oncpu+76>
    0x80146384 <mutex_oncpu+60>: ldr     r3, [r0, #392]  ; 0x188
    0x80146388 <mutex_oncpu+64>: cmp     r4, r3
    0x8014638c <mutex_oncpu+68>: movne   r0, #0
    0x80146390 <mutex_oncpu+72>: beq     0x8014639c <mutex_oncpu+84>
    0x80146394 <mutex_oncpu+76>: sub     sp, r11, #16
    0x80146398 <mutex_oncpu+80>: ldm     sp, {r4, r11, sp, pc}
    0x8014639c <mutex_oncpu+84>: ldr     r0, [r0]
    0x801463a0 <mutex_oncpu+88>: subs    r0, r4, r0
    0x801463a4 <mutex_oncpu+92>: movne   r0, #1
    0x801463a8 <mutex_oncpu+96>: sub     sp, r11, #16
    0x801463ac <mutex_oncpu+100>:        ldm     sp, {r4, r11, sp, pc}
    0x801463b0 <mutex_oncpu+104>:        movw    r3, #407        ; 0x197
    0x801463b4 <mutex_oncpu+108>:        movw    r0, #55464      ; 0xd8a8
    0x801463b8 <mutex_oncpu+112>:        str     r3, [sp]
    0x801463bc <mutex_oncpu+116>:        movw    r1, #55516      ; 0xd8dc
    0x801463c0 <mutex_oncpu+120>:        movt    r0, #32824      ; 0x8038
    0x801463c4 <mutex_oncpu+124>:        movw    r2, #59796      ; 0xe994
    0x801463c8 <mutex_oncpu+128>:        movt    r1, #32824      ; 0x8038
    0x801463cc <mutex_oncpu+132>:        movw    r3, #28516      ; 0x6f64
    0x801463d0 <mutex_oncpu+136>:        movt    r2, #32824      ; 0x8038
    0x801463d4 <mutex_oncpu+140>:        movt    r3, #32826      ; 0x803a
    0x801463d8 <mutex_oncpu+144>:        bl      0x80355df8 <kern_assert>
    0x801463dc <mutex_oncpu+148>:        b       0x80146368 <mutex_oncpu+32>

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/49396
Date: Sun, 16 Nov 2014 17:00:15 +0100

 The same test still works on sparc64.

 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/49396
Date: Sun, 16 Nov 2014 19:40:44 +0100

 I added printfs to print the mutex and the owner field and it fails right
 at the first mutex_enter():

 mutex_enter(p->p_lock = 0xbf31db40, owner = 0x0   

 uvm_fault(0x805462f8, ffffe000, 1) -> e
 Fatal kernel mode data abort: 'Translation Fault (S)'
 trapframe: 0xbfccd918                                
 FSR=00000005, FAR=fffffffc, spsr=a0080213
 r0 =00000001, r1 =e4082000, r2 =00000001, r3 =bfd5ab60
 r4 =fffffff0, r5 =bf31db40, r6 =bfd5ab60, r7 =bf305e00
 r8 =bfd5ab60, r9 =805410f8, r10=fffffff0, r11=bfccd984
 r12=bfccd988, ssp=bfccd968, slr=80146360, pc =80146378
 Stopped in pid 393.1 (tar) at   netbsd:mutex_oncpu+0x30:        ldr     r0, [r4,
  #0x00c]                                                                       
 0xbfccd984: netbsd:mutex_oncpu+0xc
 0xbfccd9e4: netbsd:mutex_enter+0xb0
 0xbfccda3c: puffs:puffs_msg_wait+0x7c
 0xbfccda5c: puffs:puffs_msg_wait2+0x1c
 0xbfccda94: puffs:puffs_vnop_strategy+0x2ac
 0xbfccdabc: netbsd:VOP_STRATEGY+0x68       
 0xbfccdb7c: netbsd:genfs_do_io+0x2a0
 0xbfccdbbc: netbsd:genfs_gop_write+0x6c
 0xbfccdd34: netbsd:genfs_do_putpages+0x92c
 0xbfccdd5c: netbsd:genfs_putpages+0x38    
 0xbfccdd9c: netbsd:VOP_PUTPAGES+0x78  
 0xbfccde14: puffs:puffs_vnop_write+0x35c
 0xbfccde24: puffs:puffs_vnop_checkop+0x120
 0xbfccde54: netbsd:VOP_WRITE+0x70         
 0xbfccde84: netbsd:vn_write+0xd8 
 0xbfccdedc: netbsd:dofilewrite+0x94
 0xbfccdf0c: netbsd:sys_write+0x70  
 0xbfccdf7c: netbsd:syscall+0x88  

From: Masao Uebayashi <uebayasi@gmail.com>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/49396
Date: Mon, 17 Nov 2014 18:40:18 +0900

 On Mon, Nov 17, 2014 at 3:57 AM, Martin Husemann <martin@duskware.de> wrote:
 > Are there address space restrictions based on compiler options so
 > we need to move modules closer to kernel text?

 Maybe setup module_map as a submap as amd64 does?

From: Martin Husemann <martin@duskware.de>
To: Masao Uebayashi <uebayasi@gmail.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/49396
Date: Mon, 17 Nov 2014 10:45:56 +0100

 On Mon, Nov 17, 2014 at 06:40:18PM +0900, Masao Uebayashi wrote:
 > Maybe setup module_map as a submap as amd64 does?

 Yes - if there is some technical reason for it. I only see -mcmodel options
 documented for aarch64 and would not have expected restrictions like this
 for 32bit arm kernels.

 This all may as well be a bug in kobj_machdep - looking for input from arm
 experts.

 Martin

Home	PR Database Search