Bug 141313 - [usb8] nvidia USB 2.0 controller - stops copying on USB [regression]
Summary: [usb8] nvidia USB 2.0 controller - stops copying on USB [regression]
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 8.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-09 08:20 UTC by Jan Marek
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Marek 2009-12-09 08:20:01 UTC
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
Comment 1 Hans Petter Selasky 2009-12-09 08:43:15 UTC
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
Comment 2 jan.marek 2009-12-09 13:46:12 UTC
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 ?
Comment 3 Jan Marek 2009-12-10 06:25:07 UTC
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
Comment 4 Adrian Bocaniciu 2010-04-08 21:44:11 UTC
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.
Comment 5 Andrew Thompson freebsd_committer 2010-04-09 07:26:48 UTC
This should now be fixed in 8-Stable as of revision 206302. This will
be included in FreeBSD 8.1.


Andrew
Comment 6 Andrew Thompson freebsd_committer 2010-04-09 07:47:06 UTC
State Changed
From-To: open->feedback

This can be tested by upgrading to 8-stable or applying http://people.freebsd.org/~thompsa/r206302.diff 


Comment 7 Andrew Thompson freebsd_committer 2010-04-09 07:47:06 UTC
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
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:22 UTC
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