Date: Thu, 14 Nov 2002 11:13:59 -0800 (PST) From: Nate Lawson <nate@root.org> To: Kutulu <kutulu@kutulu.org> Cc: freebsd-current@freebsd.org Subject: Re: panic when removing umass device (USB Camera) Message-ID: <Pine.BSF.4.21.0211141104510.43663-100000@root.org> In-Reply-To: <00b701c28ba3$a69dba40$6d673244@KutuluWare>
index | next in thread | previous in thread | raw e-mail
On Thu, 14 Nov 2002, Kutulu wrote:
> I have an HP digital camera w/ CompactFlash that acts as a USB mass-storage
> device that's panic'ing my system when I remove it.
>
> If I do not load the umass driver, then the camera is detected as a simple
> generic ugen0 device, and I can safely add/remove the device at will. If I
> load the umass driver, the camera is correctly detected as a mass-storage
> device as such:
>
> umass0: HP USB DIGITAL CAMERA, rev 1.10/1.00, addr4
> umass0: Residue incorrect, was 0, should've been 252
> umass0: Residue incorrect, was 0, should've been 252
> umass0: Residue incorrect, was 0, should've been 252
> umass0: Residue incorrect, was 0, should've been 252
> umass0: Residue incorrect, was 0, should've been 252
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <HP USB CAMERA 1.00> Removeable Direct Access SCSI-0 device
> da0: 1.000 MB/s transfers
> da0: 30 MB (62657 512 byte sectors: 64H 32S/T 30C)
>
> At this point, if I detach the camera (or, if the camera puts itself to
> sleep as it will do after 5 minutes of inactivity), I get the following
> errors:
>
> umass0: BBB reset failed, IOERROR
> umass0: BBB bulk-in clear stall failed, IOERROR
> umass0: BBB bulk-out clear stall failed, IOERROR
> (these are repeated 4 more times...)
> umass0: at uhub1 port 4 (addr 4) disconnected
> (da0: umass-sim0:0:0:)): lost device
> umass0: detached
Try this patch for the BBB stall:
Index: /sys/cam/scsi/scsi_da.c
===================================================================
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.113
diff -u -r1.113 scsi_da.c
--- /sys/cam/scsi/scsi_da.c 17 Oct 2002 18:04:41 -0000 1.113
+++ /sys/cam/scsi/scsi_da.c 14 Nov 2002 19:04:40 -0000
@@ -416,7 +416,7 @@
* HP 315 Digital Camera
* PR: kern/41010
*/
- {T_DIRECT, SIP_MEDIA_REMOVABLE, "HP", "USB Camera*", "*"},
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "HP", "USB CAMERA*", "*"},
/*quirks*/ DA_Q_NO_6_BYTE
}
};
> followed by a panic:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xdeadc10a
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01ea9d6
> stack pointer = 0x10:0xc5e42b74
> frame pointers = 0x10:0xc5e42b74
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def 32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL0
> current process = 23 (usb0)
> kernel: type 12 trap, code=0
> Stopped at device_get_nameunit+0x6: movl 0x2c(%eax), %eax
Something is attempting to access memory that has already been freed (note
the 0xdead). I need a stacktrace from a kernel with symbols to know more
about who is calling device_get_nameunit. You can set a dumpdev and get a
core or run gdb over a serial line against the kernel.debug. If you don't
have that yet, just a "tr" in ddb would help.
> The really odd part is, if I haven't done anything between attaching and
> detaching, then I now get dropped into DDB and cannot continue without
> rebooting. However, if I *have* tried to access the device (even so much as
> cat /dev/da0) before detaching, I get the panic then get returned
> immediately to my console. The SCSI device disappears when I rescan the
> SCSI bus with camcontrol, and if I reattach the camera is doesn't come back,
> but otherwise the system keeps going like normal. (The actual devfs nodes
> /dev/da0 and /dev/umass0 are still there, however)
Page fault != panic although it often results in one. Once you access
/dev/da0, it gets SI_NAMED and thus the data isn't freed twice in the same
matter. The bug is still there, it's just being masked.
> Should I be able to remove this device at run-time, or am I trying to do
> something that's presently unsupported? And if so, what else do I need to
> do?
This should work. As long as you don't have an fs mounted on the device,
you should be able to detach it.
-Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211141104510.43663-100000>