Bug 33004

Comment 1 Sheldon Hearn 2001-12-30 14:01:08 UTC

Responsible Changed
From-To: freebsd-bugs->n_hibma

Over to the USB maintainer.

[ it's about http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33004 ]

Here is what I experienced on my system.  It's a noname notebook
with an SiS630 chipset.

$ uname -a
FreeBSD 4.4-STABLE #0: Sat Dec  1 00:06:24 CET 2001
root@mops.gsinet.sittig.org:/usr/obj/usr/src/sys/MOPS

$ dmesg
[ ... ]
ohci0: <SiS 5571 USB controller> mem 0xe8001000-0xe8001fff irq 5 at device 1.2 on pci0
usb0: OHCI version 1.0, legacy support
usb0: <SiS 5571 USB controller> on ohci0
usb0: USB revision 1.0
uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
[ ... ]


An out of the box FreeBSD system shows the following message
soon after an USB device gets plugged in:

  uhub0: device problem, disabling port 1

This happens on any of the two plugs.  It's a pity I don't have
too much devices, but I tried several Logitech mice (with and
without wires, optical and mechanical), none of them worked.  At
first I suspected the wireless and the inside lit devices to
suck too much current.  But even the regular cable mouse with
mechanical ball sensors refused to work on this machine.  While
all of them worked flawlessly at a desktop system (Asus A7V,
FreeBSD 4.3-STABLE).


"Inspired" by Th. Greiner's patch I applied the below diff to
the ohci.c source.  Suddenly I get an El Cheapo(TM) mouse to
work like it should have done right from the start. :)

  ums0: Cypress Sem Cypress USB Mouse, rev 1.00/4.7b, addr 2, iclass 3/1
  ums0: 3 buttons
  ...
  ums0: at uhub0 port 1 (addr 2) disconnected
  ums0: detached
  unable to open /dev/ums0: Device not configured

I guess now it's time for me to get back to trying out all
the devices I tried before but returned since I actually only
wanted an external mouse with more than the two buttons the
Synaptics touchpad has.  I never cared enough that they worked
at the desktop to keep them. :>

Now here is the diff:

diff -u -w -b -r1.16.2.3 ohci_pci.c
--- ohci_pci.c  2001/08/15 17:03:08     1.16.2.3
+++ ohci_pci.c  2002/01/13 14:03:04
@@ -153,6 +153,7 @@
        ohci_softc_t *sc = device_get_softc(self);
        int err;
        int rid;
+       u_int32_t csr;
 
        /* XXX where does it say so in the spec? */
        sc->sc_bus.usbrev = USBREV_1_0;
@@ -229,6 +230,11 @@
                ohci_pci_detach(self);
                return ENXIO;
        }
+ 
+       /* Enable the device. */
+       csr = pci_read_config(self, PCI_COMMAND_STATUS_REG, 4);
+       pci_write_config(self, PCI_COMMAND_STATUS_REG,
+               csr | PCIM_CMD_BUSMASTEREN, 4);
 
        err = ohci_init(sc);
        if (!err)

Not at all am I aquainted enough with USB's internals and
kernel hacking in general to judge if this is appropriate or
if it even does harm to other devices.  It's merely doing at
the ohci initialisation stage what worked for Thorsten for
uhci.  But I felt you would like to know about this (kind of)
success story ...


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.

Daniel O' Connor (oconnor@gsoft.com.au) writes to me:
> I modified it to set the bus master bit in resume as well - I've
> attached what I have.

I have attached his patch.

Regards

	-Thorsten

Comment 4 Tilman Keskinoz 2003-06-22 12:36:57 UTC

Hi,

[ Joe, I am CCing you, since you have done most of the USB stuff in CURRENT ]

Today I upgraded my Notebook to 5.1, and this patch is still necessary
to get USB working.

Relevant parts of dmesg with patch:
uhci0: <Intel 82443MX USB controller> port 0x1c00-0x1c1f irq 11 at device 7.2 
on pci0
usb0: <Intel 82443MX USB controller> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ums0: Cypress Sem Cypress USB Mouse, rev 1.00/4.9c, addr 2, iclass 3/1
ums0: 3 buttons and Z dir.

without patch:
uhci0: <Intel 82443MX USB controller> port 0x1c00-0x1c1f irq 11 at device 7.2 
on pci0
usb0: <Intel 82443MX USB controller> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: device problem, disabling port 1

Some things changed since Thorsten submitted the patch, so here is a diff
relative to CURRENT.

Since PCI_COMMAND_STATUS_REG has been removed in CURRENT, I defined it,
but probably PCIR_COMMAND should be used, but neither am I a PCI hacker nor  
did I found any documentation about the purpose of this defines.

regards
tilman

Index: uhci_pci.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/usb/uhci_pci.c,v
retrieving revision 1.47
diff -u -r1.47 uhci_pci.c
--- uhci_pci.c	12 Jun 2003 05:29:15 -0000	1.47
+++ uhci_pci.c	22 Jun 2003 11:17:58 -0000
@@ -138,7 +138,7 @@
 static const char *uhci_device_generic = "UHCI (generic) USB controller";
 
 #define PCI_UHCI_BASE_REG               0x20
-
+#define PCI_COMMAND_STATUS_REG		0x04
 
 static int uhci_pci_attach(device_t self);
 static int uhci_pci_detach(device_t self);
@@ -164,8 +164,13 @@
 uhci_pci_resume(device_t self)
 {
 	uhci_softc_t *sc = device_get_softc(self);
+	u_int32_t csr;
 
 	uhci_power(PWR_RESUME, sc);
+	/* Enable the device. */
+	csr = pci_read_config(self, PCI_COMMAND_STATUS_REG, 4);
+	pci_write_config(self, PCI_COMMAND_STATUS_REG, 
+		csr | PCIM_CMD_BUSMASTEREN, 4);
 	bus_generic_resume(self);
 
 	return 0;
@@ -244,6 +249,7 @@
 	uhci_softc_t *sc = device_get_softc(self);
 	int rid;
 	int err;
+	u_int32_t csr;
 
 	pci_enable_busmaster(self);
 
@@ -304,6 +310,11 @@
 		sc->sc_bus.usbrev = USBREV_UNKNOWN;
 		break;
 	}
+
+	/* Enable the device. */
+	csr = pci_read_config(self, PCI_COMMAND_STATUS_REG, 4);
+	pci_write_config(self, PCI_COMMAND_STATUS_REG, 
+		csr | PCIM_CMD_BUSMASTEREN, 4);
 
 	err = bus_setup_intr(self, sc->irq_res, INTR_TYPE_BIO,
 	    (driver_intr_t *) uhci_intr, sc, &sc->ih);

Comment 5 Mark Linimon 2004-08-27 23:32:15 UTC

State Changed
From-To: open->feedback

Is this still a problem with recent versions of FreeBSD? 

Comment 6 Mark Linimon 2004-08-27 23:32:15 UTC

Responsible Changed
From-To: n_hibma->freebsd-bugs

With permission of assignee, reset assignment.

Comment 7 Mark Linimon 2004-08-28 08:28:14 UTC

Responsible Changed
From-To: freebsd-bugs->joe

Reassignment suggested by previous assignee.

Comment 8 joe 2004-11-10 11:03:32 UTC

Responsible Changed
From-To: joe->freebsd-usb

Hand this over to the usb mailling list.

Does this problem persist with 5.3-RELEASE, 5-STABLE, or 6-CURRENT?

-- 
Anish Mistry

Comment 10 Tilman Keskinoz 2004-11-11 08:29:41 UTC

* Anish Mistry [2004-11-11 03:27]:
> Does this problem persist with 5.3-RELEASE, 5-STABLE, or 6-CURRENT?

Sorry, my old Laptop dropped on the floor shortly before 5.2-RELEASE.
At that time the patch was still necessary.

On Sunday 14 November 2004 06:18 am, you wrote:
> * Anish Mistry <mistry.7@osu.edu> [2004-11-11 08:10]:
> > Does this problem persist with 5.3-RELEASE, 5-STABLE, or 6-CURRENT?
>
> Just tested the 5-STABLE branch: the patch is no longer necessary,
> USB works 'out of the box'.
>
> Best regards
>
>         -Thorsten

This PR can be closed now.

-- 
Anish Mistry

Comment 12 iedowse 2004-11-15 02:18:12 UTC

State Changed
From-To: feedback->closed


Submitter confirms that the patch is no longer necessary. Thanks!