update: (was: nforce2 usb is broken on -stable )
Andrew Atrens
atrens at nortelnetworks.com
Tue Aug 26 22:40:03 PDT 2003
Andrew Atrens wrote:
> Hi All,
>
> I'm running stable from August 19/2003.
>
> I've got a few A7N8X-Deluxe boards. One Rev1.0 and two Rev2.0. While
> the 1.0 board works, the 2.0 boards lock up on boot during the uhub0
> bus discovery.
>
> It's extremely frustrating :) ...
Upon closer examination I found my kernel configs on the three boxes
were not identical..
and by looking at the diff between the working 1.0 board kernel and the
broken 2.0 board kernels, I discovered that the boot hang happens when
pseudo-device crypto # core crypto support
is added. I haven't had time to look but perhaps it's doing some kind
of entropy harvesting on interrupts that's messing up the bus timing.
With this little monster removed I can now boot with usb periphs
attached. And they're even useable! ... Well mostly.
I've got a new Logitech wireless keyboard/mouse combo ... MX700 or
somesuch. And in USB mode the mouse refused to work. Turns out there's
something a bit odd in the ums driver.
I wrote a little patch to work around it.
--- dev/usb.orig/ums.c Tue Aug 26 15:29:45 2003
+++ dev/usb/ums.c Tue Aug 26 15:29:42 2003
@@ -295,6 +295,11 @@
hid_input, &sc->sc_loc_btn[i-1], 0);
sc->sc_isize = hid_report_size(desc, size, hid_input, &sc->sc_iid);
+
+ /* XXX - Can we assume that sc_iid should be 1 or 0 in all cases
? */
+
+ sc->sc_iid = ( sc->sc_iid ) ? 1 : 0;
+
sc->sc_ibuf = malloc(sc->sc_isize, M_USB, M_NOWAIT);
if (!sc->sc_ibuf) {
printf("%s: no memory\n", USBDEVNAME(sc->sc_dev));
@@ -429,8 +434,8 @@
ibuf = sc->sc_ibuf;
if (sc->sc_iid) {
- if (*ibuf++ != sc->sc_iid)
- return;
+ *ibuf++; /* skip first char of data
+ if sc_iid is non-zero */
}
dx = hid_get_data(ibuf, &sc->sc_loc_x);
Turns out the the value of sc_iid is highly suspect (look at
hid_report_size() if you don't believe me). In my case forcinng it to 1,
it was 4 for some strange reason, did the trick.
Now, anyone own an APC UPS with a USB interface on it ? I do, and it's
not too cooperative. It wants to be a modem, and the monitoring software
would like it to be too. But usb_dump reveals that it reports itself as
a device type 0 (instead of 2) and that it doesn't sport a secondary
(data) interface. umodem, ucom, and all the other drivers I looked at
all want a bulkin/bulkout data interface. Instead of doing radical
surgery on one of them, I was hoping that someone could point me to an
example of a very basic usb driver that just reads and writes control
bits and therefore doesn't need the bulking interface... Perhaps ufm ?
Cheers,
Andrew.
More information about the freebsd-stable
mailing list