NetBSD Problem Report #51093

From cjb@brushtail.apana.org.au  Mon Apr 25 19:06:08 2016
Return-Path: <cjb@brushtail.apana.org.au>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(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 5CE8B7A466
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 25 Apr 2016 19:06:08 +0000 (UTC)
Message-Id: <20160425174656.0AAEF48DF91@brushtail.apana.org.au>
Date: Tue, 26 Apr 2016 03:46:56 +1000 (AEST)
From: cjb@brushtail.apana.org.au
Reply-To: cjb@brushtail.apana.org.au
To: gnats-bugs@netbsd.org
Subject:
X-Send-Pr-Version: 3.95

>Number:         51093
>Category:       kern
>Synopsis:       Accessing USB hid device results in crash
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    skrll
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 25 19:10:00 +0000 2016
>Closed-Date:    
>Last-Modified:  Thu Sep 05 05:24:12 +0000 2019
>Originator:     Chris Baird
>Release:        NetBSD 7.99.28 -- Apr 25 12:26 AEST (3 hours ago..)
>Organization:
Australian Public Access Network Assocation
>Environment:
System: NetBSD brushtail 7.99.28 NetBSD 7.99.28 (BRUSHTAIL) #640: Tue Apr 26 03:07:01 AEST 2016 cjb@brushtail:/root/Brushtail amd64
Architecture: x86_64
Machine: amd64
>Description:

	Recent USB changes will make a kernel panic when an
	application attempts direct access of USB hid devices.

console:
----------------------------------------------------------------------

uvm_fault(0xfffffe8428d23e90, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff8036c8b4 cs 8 rflags 10246 cr2 36 ilevel 0 rsp fffffe811f57aa10
curlwp 0xfffffe8439876000 pid 1185.1 lowest kstack 0xfffffe811f5782c0
kernel: page fault trap, code=0
Stopped in pid 1185.1 (x64) at  netbsd:vmem_alloc+0x3e: movq    0(%rax),%rdi
vmem_alloc() at netbsd:vmem_alloc+0x3e
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0x46
kmem_intr_alloc() at netbsd:kmem_intr_alloc+0x6d
uhidopen() at netbsd:uhidopen+0xaf
cdev_open() at netbsd:cdev_open+0xbe
spec_open() at netbsd:spec_open+0x265
VOP_OPEN() at netbsd:VOP_OPEN+0x33
vn_open() at netbsd:vn_open+0x1eb
do_open() at netbsd:do_open+0x112
do_sys_openat() at netbsd:do_sys_openat+0x68
sys_open() at netbsd:sys_open+0x24
syscall() at netbsd:syscall+0x9c
--- syscall (number 5) ---
7f7ff203d60a:
ds          aa10
es          84b0
fs          8000
gs          e04a
rdi         ffffffff80803340    kmem_va_arena_store
rsi         1
rbp         fffffe811f57aa40
rbx         fffffe811f57aa68
rdx         0
rcx         c
rax         36
r8          0
r9          fffffe8436a16800
r10         200
r11         0
r12         fffffe811d8e9818
r13         0
r14         1001
r15         fffffe811f57aab8
rip         ffffffff8036c8b4    vmem_alloc+0x3e
cs          8
rflags      10246
rsp         fffffe811f57aa10
ss          10
netbsd:vmem_alloc+0x3e: movq    0(%rax),%rdi
db{7}> reboot
rebooting...
----------------------------------------------------------------------

>How-To-Repeat:

	# install pkgsrc/emulators/vice
	$ /usr/pkg/bin/x64

>Fix:
	Fnord.


>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->skrll
Responsible-Changed-By: skrll@NetBSD.org
Responsible-Changed-When: Mon, 25 Apr 2016 19:39:28 +0000
Responsible-Changed-Why:
Take




From: Nick Hudson <skrll@netbsd.org>
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/51093:
Date: Mon, 25 Apr 2016 20:44:09 +0100

 On 04/25/16 20:10, cjb@brushtail.apana.org.au wrote:

 dmesg, please

 Thanks,
 Nick

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: kern/51093: 
Date: Tue, 26 Apr 2016 05:46:44 +1000

 can you show the dmesg of the usb controller and devices you have?

 > Stopped in pid 1185.1 (x64) at  netbsd:vmem_alloc+0x3e: movq    0(%rax),%rdi
 > vmem_alloc() at netbsd:vmem_alloc+0x3e
 > uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0x46
 > kmem_intr_alloc() at netbsd:kmem_intr_alloc+0x6d
 > uhidopen() at netbsd:uhidopen+0xaf
 > cdev_open() at netbsd:cdev_open+0xbe
 > spec_open() at netbsd:spec_open+0x265

 and:

 > rax         36

 is a NULL deref, i guess.  usually when kmem_alloc fails it's cuz
 some prior user broke something (freed to the wrong size?).  which
 makes it a little harder to track down.

 can you try a DEBUG kernel?  and if possible, also a test with the
 kmguard feature enabled.  see the "OPTIONS" section of kmem_alloc(9)
 manual for details on enabling kmguard.

 thanks.


 .mrg.

State-Changed-From-To: open->feedback
State-Changed-By: skrll@NetBSD.org
State-Changed-When: Thu, 05 Sep 2019 05:24:12 +0000
State-Changed-Why:
feedback requested


>Unformatted:

Home	PR Database Search