When copying to / from USB, using ehci (USB2.0) the copying stops for long period of time, then sometimes resumes or gives error g_vfs_done():da0s1[WRITE(offset=1699840, length=4096)]error = 5 (this particular on msdosfs USB drive) This happens irregularly, but almost every time copying more data, the copying is also followed by ehci interrupt storm. Tried disable firewire controler and Legacy USB support in BIOS, no change. Tried this on i386,FreeBSD 8.0-RELEASE-p1, FreeBSD 8.0-STABLE Fix: disable USB 2.0 in BIOS How-To-Repeat: Copying 100MB+ data to / from USB
Hi, There has been a recent patch to enable a kind of watchdog for the EHCI. You might want to try that patch. See /sys/dev/usb/controller/ehci*.[ch] in 9- current. --HPS
Hi, I tried the latest ehci*.[ch] - patch from current the result is the same, still copy stops, but the ehci interupt storm is gone. I tried to raise the debug level for hw.usb.ehci and get the following messages: Dec 9 14:38:43 honzik kernel: ehci_set_hw_power: Async is active Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0001 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0002 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0003 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0004 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0005 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0006 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0007 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0008 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x0009 Dec 9 14:38:43 honzik kernel: ehci_roothub_exec: type=0xa3 request=0x00 wLen=0x0004 wValue=0x0000 wIndex=0x000a Dec 9 14:38:47 honzik kernel: ehci_set_hw_power:. Dec 9 14:38:47 honzik kernel: ehci_set_hw_power: Async is active any suggestions ?
Hi, Im no sure if I did right, can You check: pcicon -lv | grep ehci ehci0@pci0:0:2:1: class=0x0c0320 card=0x815a1043 chip=0x005b10de rev=0xa3 hdr=0x00 I searched the switch in file ehci_pci.c found case 0x005b10de: return "NVIDIA nForce4 USB 2.0 controller"; so the controller is listed I also found and thought i should edit this switch: /* Dropped interrupts workaround */ switch (pci_get_vendor(self)) { case PCI_EHCI_VENDORID_ATI: case PCI_EHCI_VENDORID_VIA: sc->sc_flags |= EHCI_SCFLG_LOSTINTRBUG; if (bootverbose) device_printf(self, "Dropped interrupts workaround enabled\n"); break; default: break; } I'm not sure if this is what You mean but i updated like this: /* Dropped interrupts workaround */ switch (pci_get_vendor(self)) { case PCI_EHCI_VENDORID_ATI: case PCI_EHCI_VENDORID_NVIDIA: case PCI_EHCI_VENDORID_VIA: sc->sc_flags |= EHCI_SCFLG_LOSTINTRBUG; if (bootverbose) device_printf(self, "Dropped interrupts workaround enabled\n"); break; default: break; } now i get this error message when I connect usb device: Root mount waiting for: usbus1 Root mount waiting for: usbus1 usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus1 usb_alloc_device: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus1 Root mount waiting for: usbus1 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus1 usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus1 Root mount waiting for: usbus1 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus1 usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen1.2: <(null)> at usbus1 (disconnected) uhub_reattach_port: could not allocate new device I'm not so experienced, so maybe I did something wrong. also there are lines in the beginning: #define PCI_EHCI_VENDORID_NVIDIA 0x12D2 #define PCI_EHCI_VENDORID_NVIDIA2 0x10DE not sure if I should also update somehow this because the values 0x12D2, 0x10DE are not in the pciconf -lv listing Thanks for any help Regards Jan
I see that this bug report is quite old, but nobody did anything. I can confirm that the support for the NVIDIA USB controller is definitely broken in the new USB stack from 8.0-RELEASE, while it seems to work OK in 7.3-RELEASE. This bug affects a majority of the computers that use AMD processors and that were produced before the end of the last year when AMD has finally introduced some decent chipsets. Because after a sufficient number of either read or written megabytes the USB memories (I have tested many different types, the type does not matter) become unusable, you can neither install from a USB device, nor install to a USB device. Both these features are essential for me and I suppose for many other users, so I cannot upgrade to 8.0. I will upgrade to 7.3, but that means I will go through another unnecessary hassle to upgrade later to FreeBSD 8, when FreeBSD 7 will no longer be supported. While a FreeBSD user has no right to blame the developers for some unimplemented feature (if he needs it, he should implement it himself), this case is different, being a serious regression, where something that worked has been replaced with something that does not work. Since the old stack worked OK for this (probably buggy) controller, whoever decided to change it should have been more careful to reproduce the actions of the old stack so that the new USB stack would not fail where the old did not.
This should now be fixed in 8-Stable as of revision 206302. This will be included in FreeBSD 8.1. Andrew
State Changed From-To: open->feedback This can be tested by upgrading to 8-stable or applying http://people.freebsd.org/~thompsa/r206302.diff
Responsible Changed From-To: freebsd-usb->thompsa This can be tested by upgrading to 8-stable or applying http://people.freebsd.org/~thompsa/r206302.diff
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped