Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Aug 2003 01:41:55 -0400
From:      Andrew Atrens <atrens@nortelnetworks.com>
To:        freebsd-stable@freebsd.org
Subject:   update: (was: nforce2 usb is broken on -stable )
Message-ID:  <3F4C44A3.2070209@nortelnetworks.com>
In-Reply-To: <3F46F6E6.2070001@nortelnetworks.com>
References:  <3F46F6E6.2070001@nortelnetworks.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F4C44A3.2070209>