HEADSUP!!! USB MFC committed..

Barry Bouwsma freebsd-misuser at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Tue Jun 8 10:08:59 GMT 2004


[drop the above ipv6-only address that only sometimes works from the
 recipients and I'll catch up later from the archives, thanks]

[dropped hackers for now]


Just over two months ago, Julian Elischer begged:

> let me have your patches..
> 4.10 goes into code freeze tomorrow
> so I need them asap. I can get a pass from release engineering to

Arrrgh, please accept my sincerest apologies.  Right after sending that
message some two months ago, I went offline and wasn't able to go
back online to get your plea for well over a month, as Real Life reared
its ugly head and I had to get busy moving to a place with no possibility
of Internet access, sigh...

Anyway, I didn't see this until a couple hours after the 4.10 release
tag hit the tree, so I guess I deserve whatever I've got coming to me.
Anyway, here's what I have, now based on RELENG_4 source of the time
of 4.10, and -current of the same timeframe...


What I'd done is to both try to merge in the diff mentioned earlier
into the -stable umass.c code, and also to try to take the latest
-current umass.c code and massage it to play nicely with -stable.
I've had success with both (also redoing my hacks against the latest
source to try and clean out any lingering problems), but personally
I prefer my hacks against -current, for several of my peripherals
work with the result out-of-the-box, while I needed to fudge around
with quirks under RELENG_4 and not always with success.  Nonetheless,
I'll supply both sets of hacks for those who want to play things a
bit more conservatively and review the diffs, as well as for those
who gladly throw caution to the winds -- perhaps because -current
has worked better for their devices.


The following is taking HEAD's umass.c around 4.10-tag-time and adding
the hacks below to it.  With limited testing, it gives the desired da*
entries from every slot of the card reader, and appears to mostly work
with other umass devices, both usb1 and usb2, subject to problems known
to exist without this hack (and which seem to be able to be solved
with other patches).

While I was hanging around the neighbourhood, I decided to implement
the NO_GETMAXLUN quirk that is mentioned, and add my USB disk that
can benefit from this (well, actually, I benefit as my reboots are
shortened significantly).


--- /stand/FreeBSD4-src/source-hacks/sys/dev/usb/umass.c-CURRENT	Thu May 27 22:00:19 2004
+++ /stand/FreeBSD4-src/source-hacks/sys/dev/usb/umass.c	Tue Jun  8 11:48:37 2004
@@ -112,6 +112,8 @@
 #include <sys/module.h>
 #include <sys/bus.h>
 #include <sys/sysctl.h>
+/* HACK stable below... */
+#include <machine/clock.h>
 
 #include <dev/usb/usb.h>
 #include <dev/usb/usbdi.h>
@@ -125,6 +127,8 @@
 #include <cam/scsi/scsi_all.h>
 #include <cam/scsi/scsi_da.h>
 
+/* HACK stable below... */
+#include <sys/devicestat.h>
 #include <cam/cam_periph.h>
 
 #ifdef USB_DEBUG
@@ -369,6 +373,12 @@
 	  UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
 	  NO_QUIRKS
 	},
+/* XXX HACK */
+	{ USB_VENDOR_MAXTOR,  USB_PRODUCT_MAXTOR_5000, RID_WILDCARD,
+	  UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+	  NO_GETMAXLUN
+	},
+/* XXX HACK */
 	{ USB_VENDOR_MELCO,  USB_PRODUCT_MELCO_DUBPXXG, RID_WILDCARD,
 	  UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
 	  FORCE_SHORT_INQUIRY | NO_START_STOP | IGNORE_RESIDUE
@@ -437,6 +447,10 @@
 	  UMASS_PROTO_ATAPI | UMASS_PROTO_CBI_I,
 	  FORCE_SHORT_INQUIRY
 	},
+	{ 0x090a,  0x1100, RID_WILDCARD,
+	  UMASS_PROTO_UFI | UMASS_PROTO_CBI,
+	  NO_QUIRKS
+	},
 	{ VID_EOT, PID_EOT, RID_EOT, 0, 0 }
 };
 
@@ -1055,7 +1069,8 @@
 
 	/* Get the maximum LUN supported by the device.
 	 */
-	if ((sc->proto & UMASS_PROTO_WIRE) == UMASS_PROTO_BBB)
+	if ((sc->proto & UMASS_PROTO_WIRE) == UMASS_PROTO_BBB &&
+	    !(sc->quirks & NO_GETMAXLUN))
 		sc->maxlun = umass_bbb_get_max_lun(sc);
 	else
 		sc->maxlun = 0;
@@ -1392,6 +1407,8 @@
 {
 	struct umass_softc *sc = (struct umass_softc *) priv;
 	usbd_xfer_handle next_xfer;
+/* HACK from below */
+	int Residue;
 
 	KASSERT(sc->proto & UMASS_PROTO_BBB,
 		("%s: umass_bbb_state: wrong sc->proto 0x%02x\n",
@@ -1565,7 +1582,6 @@
 		    UGETDW(sc->csw.dCSWSignature) == CSWSIGNATURE_OLYMPUS_C1)
 			USETDW(sc->csw.dCSWSignature, CSWSIGNATURE);
 
-		int Residue;
 		Residue = UGETDW(sc->csw.dCSWDataResidue);
 		if (Residue == 0 &&
 		    sc->transfer_datalen - sc->transfer_actlen != 0)
@@ -2515,7 +2531,36 @@
 	}
 	case XPT_CALC_GEOMETRY:
 	{
-		cam_calc_geometry(&ccb->ccg, /*extended*/1);
+		/* XXX HACK take this from -CURRENT cam/cam.c */
+		/* cam_calc_geometry(&ccb->ccg, / *extended* /1); */
+		/*
+		 * Common calculate geometry fuction
+		 *
+		 * Caller should set ccg->volume_size and block_size.
+		 * The extended parameter should be zero if extended translation
+		 * should not be used.
+		 */
+		/* void
+		cam_calc_geometry(struct ccb_calc_geometry *ccg, int extended)
+		{ */
+
+		struct ccb_calc_geometry *ccg = &ccb->ccg;
+		int extended = 1;
+		uint32_t size_mb, secs_per_cylinder;
+
+		size_mb = ccg->volume_size / ((1024L * 1024L) / ccg->block_size);
+		if (size_mb > 1024 && extended) {
+			ccg->heads = 255;
+			ccg->secs_per_track = 63;
+		} else {
+			ccg->heads = 64;
+			ccg->secs_per_track = 32;
+		}
+		secs_per_cylinder = ccg->heads * ccg->secs_per_track;
+		ccg->cylinders = ccg->volume_size / secs_per_cylinder;
+		ccg->ccb_h.status = CAM_REQ_CMP;
+/* XXX end cut'n'paste		} */
+
 		xpt_done(ccb);
 		break;
 	}



As mentioned, my other approach was to take the RELENG_4 umass.c code
and merge in the hacks from the earlier-mentioned diff.

This includes quirks I seemed to need to add to get my digital camera
to be found, as well as an in-progress snapshot against a card reader
which never wanted to completely cooperate with 4.x code.


    [ AIEEE.  This diff is littered with in-progress clutter.
      I'll spare you this until I clean it up for presentation.
      Sorry. ]



In all cases, for my aforementioned digital camera to be identified
in a pleasing way, I needed to merge in the usbdevs* patches below
in part taken from NetBSD with the Jenoptik manufacturer ID.  I also
added the product ID based on the re-branded camera (from the discounter
chain Aldi) without knowing if this particular unit is only available
with this ID as a rebranded product, or if Jenoptik cameras themselves
with different model numbers (available not rebranded) also use this ID.



--- /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usbdevs_data.h-4.10-ORIG	Wed May 26 21:18:34 2004
+++ /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usbdevs_data.h	Thu May 27 12:29:00 2004
@@ -1552,6 +1552,18 @@
 	    "Zip 250",
 	},
 	{
+	    USB_VENDOR_JENOPTIK, USB_PRODUCT_JENOPTIK_JD350,
+	    0,
+	    "Jenoptik",
+	    "JD 350 Camera/mp3 player",
+	},
+	{
+	    USB_VENDOR_JENOPTIK, USB_PRODUCT_JENOPTIK_DC5300,
+	    0,
+	    "Jenoptik",
+	    "DC-5300 Camera (Traveler)",
+	},
+	{
 	    USB_VENDOR_JVC, USB_PRODUCT_JVC_GR_DX95,
 	    0,
 	    "JVC",
@@ -4519,6 +4531,12 @@
 	    USB_VENDOR_SANDISK, 0,
 	    USB_KNOWNDEV_NOPROD,
 	    "SanDisk Corp",
+	    NULL,
+	},
+	{
+	    USB_VENDOR_JENOPTIK, 0,
+	    USB_KNOWNDEV_NOPROD,
+	    "Jenoptik",
 	    NULL,
 	},
 	{



--- /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usbdevs-4.10-ORIG	Wed May 26 21:18:34 2004
+++ /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usbdevs	Tue Jun  1 12:53:27 2004
@@ -258,6 +258,7 @@
 vendor LINKSYS2		0x077b	Linksys
 vendor GRIFFIN		0x077d	Griffin Technology
 vendor SANDISK		0x0781	SanDisk Corp
+vendor JENOPTIK		0x0784  Jenoptik
 vendor LOGITEC		0x0789	Logitec Corp
 vendor BRIMAX		0x078e	Brimax
 vendor AXIS		0x0792	Axis Communications
@@ -355,7 +356,9 @@
 vendor SMC3		0x0d5c  Standard Microsystems
 vendor PNY		0x0d7d	PNY
 vendor MSI		0x0db0	Micro Star International
+vendor MAXTOR		0x0d49	Maxtor
 vendor HAWKING		0x0e66	Hawking Technologies
+vendor OTI		0x0ea0	OTi
 vendor QUALCOMM		0x1004	Qualcomm
 vendor MOTOROLA		0x1063	Motorola
 vendor PLX		0x10b5	PLX
@@ -797,6 +800,10 @@
 /* Iomega products */
 product IOMEGA ZIP100		0x0001	Zip 100
 product IOMEGA ZIP250		0x0030	Zip 250
+
+/* Jenoptik products */
+product JENOPTIK JD350		0x5300  JD 350 Camera/mp3 player
+product JENOPTIK DC5300		0x1689  DC-5300 Camera (Traveler)
 
 /* JVC products */
 product	JVC GR_DX95		0x000a	GR-DX95



--- /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usbdevs.h-4.10-ORIG	Wed May 26 21:18:34 2004
+++ /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usbdevs.h	Tue Jun  1 12:55:32 2004
@@ -265,6 +265,7 @@
 #define	USB_VENDOR_LINKSYS2	0x077b		/* Linksys */
 #define	USB_VENDOR_GRIFFIN	0x077d		/* Griffin Technology */
 #define	USB_VENDOR_SANDISK	0x0781		/* SanDisk Corp */
+#define	USB_VENDOR_JENOPTIK	0x0784		/* Jenoptik */
 #define	USB_VENDOR_LOGITEC	0x0789		/* Logitec Corp */
 #define	USB_VENDOR_BRIMAX	0x078e		/* Brimax */
 #define	USB_VENDOR_AXIS	0x0792		/* Axis Communications */
@@ -362,7 +363,9 @@
 #define	USB_VENDOR_SMC3	0x0d5c		/* Standard Microsystems */
 #define	USB_VENDOR_PNY	0x0d7d		/* PNY */
 #define	USB_VENDOR_MSI	0x0db0		/* Micro Star International */
+#define	USB_VENDOR_MAXTOR	0x0d49		/* Maxtor */
 #define	USB_VENDOR_HAWKING	0x0e66		/* Hawking Technologies */
+#define	USB_VENDOR_OTI	0x0ea0		/* OTi */
 #define	USB_VENDOR_QUALCOMM	0x1004		/* Qualcomm */
 #define	USB_VENDOR_MOTOROLA	0x1063		/* Motorola */
 #define	USB_VENDOR_PLX	0x10b5		/* PLX */
@@ -805,6 +808,10 @@
 #define	USB_PRODUCT_IOMEGA_ZIP100	0x0001		/* Zip 100 */
 #define	USB_PRODUCT_IOMEGA_ZIP250	0x0030		/* Zip 250 */
 
+/* Jenoptik products */
+#define	USB_PRODUCT_JENOPTIK_JD350	0x5300		/* JD 350 Camera/mp3 player */
+#define	USB_PRODUCT_JENOPTIK_DC5300	0x1689		/* DC-5300 Camera (Traveler) */
+
 /* JVC products */
 #define	USB_PRODUCT_JVC_GR_DX95	0x000a		/* GR-DX95 */
 
@@ -919,6 +926,9 @@
 #define	USB_PRODUCT_FTDI_MX4_5	0xfa02		/* Matrix Orbital MX4 or MX5 */
 #define	USB_PRODUCT_FTDI_LK202	0xfa03		/* Matrix Orbital VK/LK202 Family */
 #define	USB_PRODUCT_FTDI_LK204	0xfa04		/* Matrix Orbital VK/LK204 Family */
+
+/* Maxtor products */
+#define	USB_PRODUCT_MAXTOR_5000	0x5000		/* Maxtor 5000XT */
 
 /* MCT Corp. */
 #define	USB_PRODUCT_MCT_HUB0100	0x0100		/* Hub */


(as you may see, I also hand-added a few more definitions for some
other hardware I had or needed quirks for.)


The only thing of note with my camera is that the SYNC_CACHE command
at unmounting and similar results in kernel messages of the form
(da5:umass-sim2:2:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da5:umass-sim2:2:0:0): MEDIUM ERROR asc:11,0
(da5:umass-sim2:2:0:0): Unrecovered read error
which is not a fatal error, and I don't know if it's even noteworthy.

I had earlier hacks to -stable based on half-year-or-so-old source,
before SYNC_CACHE was translated, which ignored the command so that
I never got this error, but attempts to include such a hack these days
seem to result in inability to use the device (though I have not
confirmed this with my latest source).



Some notes:
Devices attached to the EHCI controller still appear in kernel messages
with the USB full-speed transfer rate of 1MB/sec, even though they
can deliver high-speed transfers in excess of this.  I haven't tried
to worm my way through the code and see how easy it would be to set
the transfer rate printed out to that of the underlying interface
(ehci, or not-ehci).

There were times when access to a disk failed, when earlier it had worked
or when it worked at another boot without problems (BBB resets and other
timeout failures).  I don't know if this is peculiar to my hardware.
It also seems that this happens if I wait a while before trying to
access the drive, so this may be related to the recently-posted patch
against -current concerning contiguous buffers (the controller I have
now is UHCI), or maybe not.  UPDATE:  This problem seems no longer
present with the -current patch, yay.

When a device is attached, it's still possible to panic the system
by detaching it before the probe+attach routine is finished.  This
was most obvious with the codebase from 4.x when it took a minute
or more to attach to my card reader, but I was also able to induce
such a panic during the much shorter fraction of a second that it
took the -current codebase to attach to the device.  The 4.x code
seemed to be more eager to send resets that I couldn't completely
eliminate with limited quirk entries; before the timeouts of which
there was a dangerous window if one were to decide to unplug the
device.

Inserting a memory card after attachment provides no kernel messages
but is nonetheless immediately available (insert; `fdisk /da2' or
whatever works; remove; no longer works; insert; works again; etc).
This may be expected behaviour with this sort of media/device.

While I was merging in the patch against -current posted shortly
before 4.10 release (which only required minor massaging; apologies
if it's already been posted as a patch against -stable while I've
been offline), I decided that the usb kernel modules needed a hack
to get the debug sysctl to appear, as follows.  Both this patch and
the posted patch concerning memory are working fine with a few minutes
(or hours) of operation.  (meaning nothing since I haven't tried
to enable debugging, oh well)


--- /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usb.c-BEFORE_DIFF	Mon Mar  1 01:07:22 2004
+++ /stand/FreeBSD4-src/source-hacks/sys/dev/usb/usb.c	Wed Jun  2 20:56:20 2004
@@ -104,27 +104,34 @@
 /* Define this unconditionally in case a kernel module is loaded that
  * has been compiled with debugging options.
  */
+/* XXX Hm, seems like it's impossible to enable debugging in kernel
+       modules without explicitly recompiling...  Looks as if the
+       default of 0 doesn't do anything disruptive, so let's play
+       like firewire and always define these too...  */
+int	usbdebug = 0;
 SYSCTL_NODE(_hw, OID_AUTO, usb, CTLFLAG_RW, 0, "USB debugging");
+SYSCTL_INT(_hw_usb, OID_AUTO, debug, CTLFLAG_RW,
+	   &usbdebug, 0, "usb debug level");
 
-#ifdef USB_DEBUG
 #define DPRINTF(x)	if (usbdebug) logprintf x
 #define DPRINTFN(n,x)	if (usbdebug>(n)) logprintf x
-int	usbdebug = 0;
-SYSCTL_INT(_hw_usb, OID_AUTO, debug, CTLFLAG_RW,
-	   &usbdebug, 0, "usb debug level");
+#ifdef USB_DEBUG
 /*
  * 0  - do usual exploration
  * 1  - do not use timeout exploration
  * >1 - do no exploration
  */
 int	usb_noexplore = 0;
-#else
+/* XXXX HACK see above   #else
 #define DPRINTF(x)
-#define DPRINTFN(n,x)
+#define DPRINTFN(n,x) */
 #endif
 
 struct usb_softc {
 	USBBASEDEVICE	sc_dev;		/* base device */
+#ifdef __FreeBSD__
+	dev_t		sc_usbdev;	/* /dev/usbN device */
+#endif
 	usbd_bus_handle sc_bus;		/* USB controller */
 	struct usbd_port sc_port;	/* dummy port for root hub */
 

(the last three added lines come from the patch of a few weeks
ago against -current)


I suppose if the mentioned -current patch has not yet been posted
for application against -stable, I can submit my diffs (well over
two weeks from the original post, and also as part of the complete
set of hacks I have based on -current's umass.c and the like. I've
attempted to reproduce the case where my umass access times out
(after I've started other processes, so that the amount of free
memory drops to its nadir of 532k free, before mounting the disk)
so far without problems in one test, which could motivate me to
try re-adding EHCI support to my module and see if the problem I
had observed there is also addressed by this patchkit.

Umm, having done so (included ehci under -stable with the patch
for -current) I now see immediate panics at boot when the umass
USB2 device is plugged in, when the umass device is detached and
then reattached (this is how I'm able to use a USB2 hub at USB1
speeds with my -stable); it seems okay when I plug the drive in
after boot, but more time is needed...  This panic is identical
as far as I can see to that reported in the -current mailing list
on 17.Apr and followups within a couple days.  Also, this panic
can be avoided by the suggested hack of changing `#if 1' in
usb.c -- no problem for my attached devices (mouse, storage).

However, with at least the particular card I have installed,
I still get hangs (and then panics) after a period of time
accessing a USB2 disk, which had initially appeared to be
solved with the memory -current patch.  I had problems (but
not panics) accessing one of my two card readers with EHCI
that this patch seemed to help, for what it's worth, but with
my external hard drive, no improvement (other than perhaps a
decrease in the random frequency of occurrence) was noted.


(argh, sorry for the long-winded messages i compose)



Otherwise, things seem to be just fine, and I've settled on my hacks
against -current source, due to Just Work[tm]ing with my hardware.
With the entirety of my hacks and the patches to -current, I've
not had any problems so far.  Whee!


thanks
barry bouwsma

(I'll post cleaned patches based on -stable umass.c sometime)



More information about the freebsd-stable mailing list