Radek Kozlowski
2005-Mar-22 05:48 UTC
Panic after plugging in an mp3 usb player, 5.4-PRERELEASE
My 5.4-PRERELEASE/i386 as of today panics almost immediately after
plugging in an mp3 usb player (Qware BeatZkey! Pro 512MB). I don't have
device ehci in the kernel.
Mar 22 13:41:35 ddardaar kernel: umass0: vendor 0x10d6 USB 2.0(FS) FLASH DISK,
rev 1.10/1.00, addr 2
Mar 22 13:41:35 ddardaar kernel: da0 at umass-sim0 bus 0 target 0 lun 0
Mar 22 13:41:35 ddardaar kernel: da0: <GENERIC USB DISK DEVICE 1.00>
Removable Direct Access SCSI-0 device
Mar 22 13:41:35 ddardaar kernel: da0: 1.000MB/s transfers
Mar 22 13:41:35 ddardaar kernel: da0: 497MB (1019617 512 byte sectors: 64H 32S/T
497C)
Mar 22 13:41:36 ddardaar kernel: umass0: BBB reset failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-in clear stall failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-out clear stall failed,
STALLED
Mar 22 13:41:36 ddardaar kernel: (da0:umass-sim0:0:0:0): Synchronize cache
failed, status == 0x4, scsi status == 0x0
Mar 22 13:41:36 ddardaar kernel: umass0: BBB reset failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-in clear stall failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-out clear stall failed,
STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB reset failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-in clear stall failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-out clear stall failed,
STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB reset failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-in clear stall failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-out clear stall failed,
STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB reset failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-in clear stall failed, STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: BBB bulk-out clear stall failed,
STALLED
Mar 22 13:41:36 ddardaar kernel: umass0: at uhub1 port 2 (addr 2) disconnected
Mar 22 13:41:36 ddardaar kernel: (da0:umass-sim0:0:0:0): lost device
Mar 22 13:41:36 ddardaar kernel: (da0:umass-sim0:0:0:0): removing device entry
Mar 22 13:41:36 ddardaar kernel: sysctl_unregister_oid: failed to unregister
sysctl
Mar 22 13:41:36 ddardaar kernel: Opened disk da0 -> 5
Mar 22 13:41:36 ddardaar kernel: umass0: detached
Mar 22 13:41:47 ddardaar kernel: umass0: vendor 0x10d6 USB 2.0(FS) FLASH DISK,
rev 1.10/1.00, addr 2
[panic, fatal trap 12]
#0 doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc0445f02 in db_fncall (dummy1=-1067250851, dummy2=0, dummy3=-734074160,
dummy4=0xd43eea68 "\234?>?@")
at /usr/src/sys/ddb/db_command.c:531
#2 0xc0446298 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349
#3 0xc0447cec in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221
#4 0xc0522e19 in kdb_trap (type=12, code=0, tf=0xd43eebd8) at
/usr/src/sys/kern/subr_kdb.c:418
#5 0xc063ef1a in trap_fatal (frame=0xd43eebd8, eva=296) at
/usr/src/sys/i386/i386/trap.c:804
#6 0xc063f1cf in trap_pfault (frame=0xd43eebd8, usermode=0, eva=296) at
/usr/src/sys/i386/i386/trap.c:727
#7 0xc063f56d in trap (frame {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi =
-1041650752, tf_esi = -1040474112, tf_ebp = -734073832, tf_isp = -734073852,
tf_ebx = 1, tf_edx = -1040474112, tf_ecx = 0, tf_eax = 256, tf_trapno = 12,
tf_err = 0, tf_eip = -1069309535, tf_cs = 8, tf_eflags = 66050, tf_esp =
-734073768, tf_ss = -1069300420}) at /usr/src/sys/i386/i386/trap.c:417
#8 0xc06325ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#9 0x00000018 in ?? ()
#10 0x00000010 in ?? ()
#11 0x00000010 in ?? ()
#12 0xc1e9abc0 in ?? ()
#13 0xc1fba000 in ?? ()
#14 0xd43eec18 in ?? ()
#15 0xd43eec04 in ?? ()
#16 0x00000001 in ?? ()
#17 0xc1fba000 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000100 in ?? ()
#20 0x0000000c in ?? ()
#21 0x00000000 in ?? ()
#22 0xc043a1a1 in xpt_done (done_ccb=0x0) at /usr/src/sys/cam/cam_xpt.c:4834
#23 0xc043c53c in xpt_scan_bus (periph=0xc1d7ca80, request_ccb=0xc1fba000) at
/usr/src/sys/cam/cam_xpt.c:5364
#24 0xc043d55e in camisr (V_queue=0xc06becc0) at /usr/src/sys/cam/cam_xpt.c:7061
#25 0xc04f62a5 in ithread_loop (arg=0xc1d7c980) at
/usr/src/sys/kern/kern_intr.c:547
#26 0xc04f5380 in fork_exit (callout=0xc04f61f0 <ithread_loop>,
arg=0xc1d7c980, frame=0xd43eed48)
at /usr/src/sys/kern/kern_fork.c:790
#27 0xc063262c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
If you need more info, please let me know. Thanks.
-Radek
Marwan Burelle
2005-Mar-22 06:28 UTC
Panic after plugging in an mp3 usb player, 5.4-PRERELEASE
On Tue, Mar 22, 2005 at 02:48:37PM +0100, Radek Kozlowski wrote:> My 5.4-PRERELEASE/i386 as of today panics almost immediately after > plugging in an mp3 usb player (Qware BeatZkey! Pro 512MB). I don't have > device ehci in the kernel.It's a common problem with some USB devices. You have to add some quirk in sys/cam/scsi/scsi_da.c for your player. See more information at : http://www.root.org/~nate/freebsd/quirks.html I've got the same problem with mine, adding the rigth quirk (DA_Q_NO_SYNC_CACHE for me) solves it. The difficult part is to think out what to put to capture your player (and not the others ... ) -- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org (burelle@lri.fr | Marwan.Burelle@ens.fr) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050322/a149fc2a/attachment.bin
In message <20050322134837.GE557@werd>, Radek Kozlowski writes:>My 5.4-PRERELEASE/i386 as of today panics almost immediately after >plugging in an mp3 usb player (Qware BeatZkey! Pro 512MB). I don't have >device ehci in the kernel.Hi, Did this just suddenly stop working when you updated to the latest 5.x-stable, or did it ever work for you before? There were a number of USB changes in 5.4-PRERELEASE yesterday, so it's important to know whether they broke anything. If the problem is not new then it may just require a quirk as already suggested. Thanks, Ian