NetBSD-Bugs archive

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

kern/51169: scsipi-related kernel panic (attaching a phone to USB)

>Number:         51169
>Category:       kern
>Synopsis:       scsipi-related kernel panic (attaching a phone to USB)
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 26 10:15:00 +0000 2016
>Originator:     coypu
>Release:        NetBSD 7.99.29
NetBSD net.Home 7.99.29 NetBSD 7.99.29 (GENERIC) #2: Wed May 25 20:00:55 IDT 2016  fly%net.Home@localhost:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
very recent (May 25) sources.
crash dump:

umass0: at uhub0 port 2 (addr 2) disconnected
uhub0: port 2, device not enabled
uhub0: device problem, disabling port 2
umass0 at uhub0 port 2 configuration 1 interface 0
umass0: Android Android, rev 2.00/2.26, addr 12
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 2 luns per target
sd0 at scsibus0 target 0 lun 0: <Samsung, File-CD Gadget, 0000> disk removable
umass0: BBB reset failed, IOERROR
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
panic: prevented execution of 0x300000002 (SMEP)
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x9e
scsipi_execute_xs() at netbsd:scsipi_execute_xs+0x12c
scsipi_test_unit_ready.part.3() at netbsd:scsipi_test_unit_ready.part.3+0x58
sdattach() at netbsd:sdattach+0x137
config_attach_loc() at netbsd:config_attach_loc+0x17a
scsi_probe_bus() at netbsd:scsi_probe_bus+0x560
scsibus_config() at netbsd:scsibus_config+0x72
scsipi_completion_thread() at netbsd:scsipi_completion_thread+0x23
cpu0: End traceback...
uvm_fault(0xfffffe847b0cc470, 0x0, 2) -> e
fatal page
fault in supervisor mode
dumping to dev 0,1 (offset=1514, size=4150227):
trap type 6 code 2 rip ffffffff80830fbc cs 8 rflags 10286 cr2 84 ilevel 8 rsp fffffe8126a4add0
dump curlwp 0xfffffe84664c5a60 pid 923.90 lowest kstack 0xfffffe8126a472c0

(gdb) target kvm netbsd.15.core
0xffffffff80119915 in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:671
671                     dumpsys();
(gdb) bt
#0  0xffffffff80119915 in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:671
#1  0xffffffff8085f57c in vpanic (fmt=fmt@entry=0xffffffff80ecf580 "prevented execution of %p (SMEP)", ap=ap@entry=0xfffffe811d8b6978) at /usr/src/sys/kern/subr_prf.c:342
#2  0xffffffff8085f630 in panic (fmt=fmt@entry=0xffffffff80ecf580 "prevented execution of %p (SMEP)") at /usr/src/sys/kern/subr_prf.c:258
#3  0xffffffff8011b5ab in trap (frame=0xfffffe811d8b6ab0) at /usr/src/sys/arch/amd64/amd64/trap.c:522
#4  0xffffffff801010ee in alltraps ()
#5  0x0000000300000002 in ?? ()
#6  0xffffffff8015f7ac in sdstart (periph=0xfffffe845d832a50) at /usr/src/sys/dev/scsipi/sd.c:822
#7  0xffffffff80151a57 in scsipi_execute_xs (xs=0xfffffe811da7ef00, xs@entry=0xffffffff80151a57 <scsipi_execute_xs+300>) at /usr/src/sys/dev/scsipi/scsipi_base.c:2039
#8  0xffffffff8014f39c in scsipi_command (periph=periph@entry=0xfffffe845d832a50, cmd=0x5, cmd@entry=0xfffffe811d8b6cb2, cmdlen=cmdlen@entry=6, data_addr=data_addr@entry=0x0, datalen=datalen@entry=0, 
    retries=retries@entry=0, timeout=timeout@entry=10000, bp=bp@entry=0x0, flags=flags@entry=900) at /usr/src/sys/dev/scsipi/scsipiconf.c:100
#9  0xffffffff8014f987 in scsipi_test_unit_ready (periph=periph@entry=0xfffffe845d832a50, flags=flags@entry=900) at /usr/src/sys/dev/scsipi/scsipi_base.c:1045
#10 0xffffffff8015098c in scsipi_test_unit_ready (periph=periph@entry=0xfffffe845d832a50, flags=flags@entry=900) at /usr/src/sys/dev/scsipi/scsipi_base.c:1047
#11 0xffffffff8015e44f in sdattach (parent=<optimized out>, self=0xfffffe8455718308, aux=<optimized out>) at /usr/src/sys/dev/scsipi/sd.c:291
#12 0xffffffff8084923c in config_attach_loc (parent=0xfffffe8450d78d08, cf=<optimized out>, cf@entry=0xffffffff811fcbc0 <cfdata+10368>, locs=locs@entry=0xfffffe811d8b6dc8, 
    aux=aux@entry=0xfffffe811d8b6dd0, print=print@entry=0xffffffff8015557c <scsibusprint>) at /usr/src/sys/kern/subr_autoconf.c:1600
#13 0xffffffff80155c6a in scsi_probe_device (sc=0xfffffe847bd4ab78, sc=0xfffffe847bd4ab78, lun=0, target=0) at /usr/src/sys/dev/scsipi/scsiconf.c:1016
#14 scsi_probe_bus (sc=sc@entry=0xfffffe847bd4ab78, target=0, target@entry=-1, lun=0, lun@entry=-1) at /usr/src/sys/dev/scsipi/scsiconf.c:411
#15 0xffffffff80155f41 in scsibus_config (chan=0xfffffe811da51af0, arg=0xfffffe847bd4ab78) at /usr/src/sys/dev/scsipi/scsiconf.c:290
#16 0xffffffff8015151e in scsipi_completion_thread (arg=0xfffffe811da51af0) at /usr/src/sys/dev/scsipi/scsipi_base.c:2066
#17 0xffffffff80100867 in lwp_trampoline ()
#18 0x0000000000000000 in ?? ()

I could reproduce this by repeatedly attaching and detaching my outdated (and possibly damaged) Android phone to XHCI port. a few seconds after attach, it had panicked.

note: normally, it is not possible to mount the phone unless I click something on the phone itself, which I did not do.

Home | Main Index | Thread Index | Old Index