On Saturday 01 January 2005 2:04 pm, Matthew Brett wrote:
> Hi,
>
> Many thanks for the helpful reply.
>
> > First, just to try and get things working properly, load the usbcore.ko
> > kernel module with the parameter "old_scheme_first=y". Or if you prefer,
> > after usbcore.ko has been loaded you can do
> >
> > echo y >/sys/module/usbcore/parameters/old_scheme_first
> >
> > which will accomplish the same thing.
>
> works, dmesg:
>
> usb 4-3: new high speed USB device using ehci_hcd and address 2
> ub: sizeof ub_scsi_cmd 64 ub_dev 2472
> uba: device 2 capacity nsec 256000 bsize 512
> uba: device 2 capacity nsec 256000 bsize 512
> /dev/ub/a: p1
> usbcore: registered new driver ub
Hmm. Can you try 2.6.10 with this attached patch, and see if it
makes any difference? Both with and without "old_scheme_first".
The idea behind the "new scheme" is to act a bit more like
MS-Windows, but devices get really picky during those early
stages of enumeration.
> > The second experiment requires that you do not use the module parameter;
> > keep things as they used to be. Start out with both uhci_hcd and ehci_hcd
> > unloaded from memory. Plug in the Clipdrive, and then a few seconds later
> > modprobe ehci_hcd. I'm curious to see if that has the same effect as
> > coldplugging.
>
> Also gvies no error. dmesg:
>
> PCI: Found IRQ 11 for device 0000:00:1d.7
> ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0
> EHCI Controller
> PCI: Setting latency timer of device 0000:00:1d.7 to 64
> ehci_hcd 0000:00:1d.7: irq 11, pci mem 0xd0100000
> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
> PCI: cache line size of 32 is not supported by device 0000:00:1d.7
> ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 6 ports detected
> usb 1-3: new high speed USB device using ehci_hcd and address 2
>
> However, /proc/bus/usb/devices lists only a single hub, and no clipdirve.
That's also interesting. Can you repeat that experiment with
CONFIG_USB_DEBUG enabled? Assuming you get the same result,
then include the "dmesg" output (starting with "modprobe ehci"),
and the /sys/class/usb_host/usb1/registers fiile.
And a third experiment to try: just like #2, but "modprobe uhci_hcd"
instead of "ehci_hcd".
- Dave
Now that usbcore is supposed to scrub out the endpoint zero state correctly
whenever it's invalidated, some EHCI code should no longer be needed.
--- 1.63/drivers/usb/host/ehci-q.c Tue Dec 7 13:04:36 2004
+++ edited/drivers/usb/host/ehci-q.c Mon Jan 3 11:52:55 2005
@@ -832,32 +832,6 @@
qtd = list_entry (qtd_list->next, struct ehci_qtd,
qtd_list);
- /* control qh may need patching after enumeration */
- if (unlikely (epnum == 0)) {
- /* set_address changes the address */
- if ((qh->hw_info1 & QH_ADDR_MASK) == 0)
- qh->hw_info1 |= cpu_to_le32 (
- usb_pipedevice (urb->pipe));
-
- /* for full speed, ep0 maxpacket can grow */
- else if (!(qh->hw_info1
- & __constant_cpu_to_le32 (0x3 << 12))) {
- u32 info, max;
-
- info = le32_to_cpu (qh->hw_info1);
- max = urb->dev->descriptor.bMaxPacketSize0;
- if (max > (0x07ff & (info >> 16))) {
- info &= ~(0x07ff << 16);
- info |= max << 16;
- qh->hw_info1 = cpu_to_le32 (info);
- }
- }
-
- /* usb_reset_device() briefly reverts to address 0 */
- if (usb_pipedevice (urb->pipe) == 0)
- qh->hw_info1 &= ~QH_ADDR_MASK;
- }
-
/* just one way to queue requests: swap with the dummy qtd.
* only hc or qh_refresh() ever modify the overlay.
*/
