Bug 80361 - [umass] [patch] mounting of Dell usb-stick fails
Summary: [umass] [patch] mounting of Dell usb-stick fails
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2005-04-26 14:10 UTC by Fridtjof Busse
Modified: 2022-10-17 12:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fridtjof Busse 2005-04-26 14:10:21 UTC
If I try to mount my Dell Memory Stick 256 MB, I only get /dev/da0 (and
not /dev/da0s1) and this appears in dmesg:

umass0: M-SysT5 Dell Memory Key, rev 2.00/2.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <M-SysT5 Dell Memory Key 5.00> Removable Direct Access SCSI-0 device 
da0: 1.000MB/s transfers
da0: Attempt to query device size failed: UNIT ATTENTION, Medium not present
(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0
(da0:umass-sim0:0:0:0): Medium not present

The "Medium not present" error is displayed multiple times until it fails with:

(da0:umass-sim0:0:0:0): Retries Exhausted
Opened disk da0 -> 6

The only way to get /dev/da0s1 is to do the following:
cat /dev/null > /dev/da0s1
Then I get da0s1 and everything works fine, filesystem ist FAT32.  But
I'd like to be able to mount the stick without this "workaround", it works
under Linux-2.6 without any problems at all.

The dmesg during the "cat" is:

(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
(da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)

How-To-Repeat: Try to mount a current Dell Memory Stick. There's been a report on
questions@ about the same behavior with a Kingston Elite
Comment 1 Marc Olzheim 2005-04-26 17:12:09 UTC
I can confirm this for my Kingston Elite.
dd if=/dev/da0 of=/dev/null bs=100k count=1 does the trick of making
da0s1 known for me.

It seems as though the geom auto detection doesn't run anymore.
It stil worked a few weeks ago.

Marc
Comment 2 Marc Olzheim 2005-05-04 00:05:31 UTC
On today's stable it works again on my amd64 (with a Kingston
DataTraveler Elite).

Marc
Comment 3 Fridtjof Busse 2005-05-04 07:05:53 UTC
My Dell still fails to mount without the workaround on 5.4-RC4/x86.
Comment 4 Dan Olson 2005-05-10 23:01:02 UTC
I may have access to a patch that will fix this. As root with the usb 
stick in, run usbdev -v.  This shows the vendor and product id.

A reference email to freebsd-current is at: 
http://lists.freebsd.org/pipermail/freebsd-current/2005-March/047827.html

Thanks

Dan
Comment 5 Fridtjof Busse 2005-05-14 17:04:39 UTC
This patch fixes the problem at least for me (Dell Memory Stick).
The USB_PORT_POWERUP_DELAY didn't help me, but the patch works just
fine.
Any chance to get this into stable?
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2007-06-30 07:29:06 UTC
State Changed
From-To: open->feedback

Unfortunately, the mailing list stripped the patch.  Does anyone have 
a copy of the patch still? 


Comment 7 Mark Linimon freebsd_committer freebsd_triage 2007-06-30 07:29:06 UTC
Responsible Changed
From-To: freebsd-usb->linimon
Comment 8 Mark Linimon 2007-07-02 08:51:50 UTC
----- Forwarded message from Michal Mertl <mime@traveller.cz> -----

From: Michal Mertl <mime@traveller.cz>

Hello.

Unfortunatley I do not remember all the details anymore but I have
found the old emails and the patch (attached).

HTH

Index: umass.c
===================================================================
RCS file: /home/fcvs/cvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.119
diff -u -3 -r1.119 umass.c
--- umass.c	14 Feb 2005 02:17:53 -0000	1.119
+++ umass.c	24 Mar 2005 23:17:55 -0000
@@ -314,6 +314,8 @@
 #	define NO_INQUIRY		0x0400
 	/* Device cannot handle INQUIRY EVPD, return CHECK CONDITION */
 #	define NO_INQUIRY_EVPD		0x0800
+	/* Device needs time to settle down /2s/ XXX */
+#	define UMASS_ADD_DELAY		0x1000
 };
 
 Static struct umass_devdescr_t umass_devdescrs[] = {
@@ -387,6 +389,10 @@
 	  UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
 	  NO_QUIRKS
 	},
+	{ USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DELLMEMKEY, RID_WILDCARD,
+	  UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+	  UMASS_ADD_DELAY
+	},
 	{ USB_VENDOR_NEODIO, USB_PRODUCT_NEODIO_ND3260, RID_WILDCARD,
 	  UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
 	  FORCE_SHORT_INQUIRY
@@ -891,6 +897,7 @@
 	(void) umass_match_proto(sc, sc->iface, uaa->device);
 
 	id = usbd_get_interface_descriptor(sc->iface);
+
 #ifdef USB_DEBUG
 	printf("%s: ", USBDEVNAME(sc->sc_dev));
 	switch (sc->proto&UMASS_PROTO_COMMAND) {
@@ -2262,6 +2269,7 @@
 Static int
 umass_cam_attach(struct umass_softc *sc)
 {
+	int delay_len;
 #ifndef USB_DEBUG
 	if (bootverbose)
 #endif
@@ -2278,7 +2286,11 @@
 		 * completed, when interrupts have been enabled.
 		 */
 
-		usb_callout(sc->cam_scsi_rescan_ch, MS_TO_TICKS(200),
+		if (sc->quirks && UMASS_ADD_DELAY)
+			delay_len = 2000;
+		else
+			delay_len = 200;
+		usb_callout(sc->cam_scsi_rescan_ch, MS_TO_TICKS(delay_len),
 		    umass_cam_rescan, sc);
 	}
 
Index: usbdevs
===================================================================
RCS file: /home/fcvs/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.226
diff -u -3 -r1.226 usbdevs
--- usbdevs	21 Mar 2005 08:43:54 -0000	1.226
+++ usbdevs	24 Mar 2005 22:39:48 -0000
@@ -1188,6 +1188,7 @@
 /* M-Systems products */
 product MSYSTEMS DISKONKEY	0x0010	DiskOnKey
 product MSYSTEMS DISKONKEY2	0x0011	DiskOnKey
+product MSYSTEMS DELLMEMKEY	0x0015  Dell Memory Key
 
 /* National Semiconductor */
 product NATIONAL BEARPAW1200	0x1000	BearPaw 1200


----- End forwarded message -----
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2007-07-03 07:32:04 UTC
State Changed
From-To: feedback->open

Patch retrieved.
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2007-07-06 09:46:24 UTC
Responsible Changed
From-To: linimon->freebsd-usb

Over to maintainer(s).
Comment 11 Matthias Apitz 2008-08-06 10:30:54 UTC
I have the same problem in FreeBSD 7.0-REL with the following USB key:

$ usbdevs -v
...
port 2 addr 2: high speed, power 94 mA, config 1, Store'n'go(0x0020), Verbatim(0x08ec), rev 2.00

which only works (fine) when plug'ed in at boot time:

da0 at umass-sim0 bus 0 target 0 lun 0
da0: <VBTM Store'n'go 6.51> Removable Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: 3812MB (7807999 512 byte sectors: 255H 63S/T 486C)

if you plug it in later you will get:

Aug  6 10:19:36 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0
Aug  6 10:19:36 rebelion kernel: da0: <VBTM Store'n'go 6.51> Removable Direct Access SCSI-0 device 
Aug  6 10:19:36 rebelion kernel: da0: 40.000MB/s transfers
Aug  6 10:19:36 rebelion kernel: da0: Attempt to query device size failed: UNIT ATTENTION, Medium not present

and the devices /dev/da0s* does not show up; you only may access
/dev/da0 with fdisk(8) or even with dd(1);

-- 
Matthias Apitz
Comment 12 eisvogel 2008-08-07 20:58:47 UTC
I just fished this device

port 1 addr 2: high speed, power 140 mA, config 1, DT Elite HS 2.0(0x0015), Kingston(0x08ec), rev 2.00

out of my electronic devices dumpster and got it working with USB hot
plugging using an adapted version of the patch by Mark Linimon. This is
a 7-STABLE kernel. I tweaked the new quirk to cause a delay before bus
rescan of 5000ms.

As you can see its a Kingston brand outside, yet the vendor id points to
M-Systems. I guess Kingston OEMed those using their own casing. What is
interesting is the blue/red dual color LED on this stick, it will blink
for a few seconds when you plug the device in and only then begin the
idle "glowing" routine (after it has initialized?). My guess is that this
particular device takes its time after power on in the order of a
handful of seconds before becoming ready. Maybe it is scanning its flash
banks or something instead of accepting commands right away.

Other  operating systems appear to have a retry mechanism (WinXP, Linux)
whereas in BSD its all or nothing after 200ms of device attach.

Regards,
Stephan
Comment 13 Remko Lodder freebsd_committer freebsd_triage 2010-07-14 17:19:03 UTC
State Changed
From-To: open->feedback

Is this still seen on 8.x? That had been completely rewritten and might 
no longer suffer from this problem.
Comment 14 dantavious313 2010-11-21 14:26:09 UTC
	I am using 8.1-STABLE and I continue to have this problem. At boot time 
if my Android phone is attached to system I get a device entry /dev/da0s1 
however, if I detach and attempt to reattach I can not get an device entry. An 
cat /dev/null > /dev/da0 produces an /dev/da0s1 entry however, that is not 
optimal. Any help would be great.

ugen6.3: <Android Phone HTC> at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=ON

Derrick
Comment 15 Alexander Best freebsd_committer freebsd_triage 2010-11-22 22:35:21 UTC
State Changed
From-To: feedback->open

Feedback received. This problem still exists in the new USB stack.
Comment 16 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:31 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 17 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:37:13 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>