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
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.