[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)
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
