Re: [PATCH 1/3] usb: rename bU2DevExitLat to wU2DevExitLat
On 09/06/16 08:44, Felipe Balbi wrote: Hi, Felipe Balbi writes: > According to USB 3.1 Specification, that field is 2 > bytes wide and is named with a 'w' prefix, not 'b'. > > Just to make grepping in the spec easier, let's > match the name. > > Signed-off-by: Felipe Balbi I'll wait for another week or so, if nobody has any objections to this series, I plan on sending it to Greg on my pull request. FYI: Affects Linux's libusb header files too. They have the same mis-spelling. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci
On 09/12/14 15:26, Mathias Nyman wrote: Hi On 09/11/2014 05:18 PM, Jay Larson wrote: Mathias, I was not able to locate an official method of inquiring about issues with xhci, so I'm writing directly to you. If this is not the appropriate method please accept my apologies and kindly direct me to the proper place. Me, including the linux usb mailing list (added to cc), is the right combination to ask questions regarding xhci. We have had a failure for which I have been asked to provide an explanation. A process that was accessing a USB 3.0 disk unexpectedly failed (Killed). We have had other issues where users have had to reboot to restore USB connectivity (possibly just reloading the module would have had the same effect). I can only surmise that there is either a problem with the hardware, or xhci. I am in particular curious if we could expect any significant benefits to using a more recent kernel. You should definitely use a more recent kernel, there are tons of changes since 2.6.32, and It's impossible for me to support old kernels. [uname -a] Linux kdmlinux3 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [lcpci -vv] 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev ... Hi, I thought I'd drop you guys a message about the "USB 3.0 NEC uPD720200" hoping that some hardware guys are hanging around on this list. After we added 64-bit support to the XHCI driver in FreeBSD we've had several identical reports, that the "USB 3.0 NEC uPD720200" is refusing to work correctly. Timeout errors start happening exactly after the first data transfer to/from a DMA address above 4GBytes. Is this a known issue? Until further we've added a quirk to mask away the 64-bit capability of the XHCI controller: https://svnweb.freebsd.org/changeset/base/279563 We currently don't believe this is a XHCI driver problem in FreeBSD, hence other XHCI controllers work just fine. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] for HID core dot c
Hi Greg, Thank you for the pointer. Will try to remember that till next time. Sorry about the noise! Please use scripts/get_maintainer.pl to determine who and what mailing lists to send a patch to so that the right maintainer(s) get the patch. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Correct argument for Module parameter description.
Signed-off-by: Hans Petter Selasky --- drivers/hid/hid-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, "Ignore any special drivers and handle all devices by generic driver"); +MODULE_PARM_DESC(ignore_special_drivers, "Ignore any special drivers and handle all devices by generic driver"); /* * Register a new report for a device. -- 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] for HID core dot c
On 09/05/14 16:20, Frans Klaver wrote: Hi, On Fri, Sep 5, 2014 at 4:07 PM, Hans Petter Selasky wrote: See attachment. It's preferred that you send your patches in the body of the email. Please read Documentation/SubmittingPatches. Frans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, I'll re-send it. Not sending patches that frequently. Thank you! --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] for HID core dot c
Hi, Looks like the first argument for MODULE_PARAM_DESC() is incorrect. --HPS commit 862e8673263b82652b5738ccda4f8367959fa234 Author: Hans Petter Selasky Date: Fri Sep 5 11:07:15 2014 +0200 Correct argument for Module parameter description. Signed-off-by: Hans Petter Selasky diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, "Ignore any special drivers and handle all devices by generic driver"); +MODULE_PARM_DESC(ignore_special_drivers, "Ignore any special drivers and handle all devices by generic driver"); /* * Register a new report for a device. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] for HID core dot c
See attachment. Thank you! --HPS commit 862e8673263b82652b5738ccda4f8367959fa234 Author: Hans Petter Selasky Date: Fri Sep 5 11:07:15 2014 +0200 Correct argument for Module parameter description. Signed-off-by: Hans Petter Selasky diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, "Ignore any special drivers and handle all devices by generic driver"); +MODULE_PARM_DESC(ignore_special_drivers, "Ignore any special drivers and handle all devices by generic driver"); /* * Register a new report for a device.
Re: Slow boot due to USB errors
On 05/11/14 19:07, Alan Stern wrote: On Sun, 11 May 2014, drago01 wrote: I know that 1-4 is the touchscreen (its an ultrabook with a touchscreen) ... the touchscreen itself works just fine though. So if it takes more time / attempts to enumerate it and it works eventually anyway why do we block boot on it? That is a question for the systemd people / list. systemd-devel@, WTF!? :) systemd ain't kernel! As I understand it (and my understanding could easily be wrong), device probing happens asynchronously during boot-up. Then when the kernel is about to mount the real root fs, it waits for all those async probes to finish so that the real root device will have been found and is ready for use. Thus, a device that introduces a long delay during probing can block booting, even if it doesn't contain the root filesystem. It's a heavy-handed approach. Maybe it would be possible to cut the wait short when the root device has been found, maybe not. I'm not an expert on this. Part of the problem is that the USB stack contains too many nested retry loops with long delays in the device initialization pathway. It's not clear which of them should be removed, however. Hi, echo "hw.usb.no_boot_wait=0" >> /boot/loader.conf --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow boot due to USB errors
Hi, Hi, echo "hw.usb.no_boot_wait=0" >> /boot/loader.conf --HPS Maybe not directly related to this list, but in FreeBSD we have a tunable to not wait for synchronous device probing at boot. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: xHCI out of order events on BSD, was Re: xhci and other woes
Hi, -Original message- > From:Sarah Sharp <mailto:sarah.a.sh...@linux.intel.com> > > Sent: Saturday 15th February 2014 0:02 > To: Hans Petter Selasky <mailto:hans.petter.sela...@bitfrost.no> > > Cc: linux-usb@vger.kernel.org <mailto:linux-usb@vger.kernel.org> > Subject: xHCI out of order events on BSD, was Re: xhci and other woes > > On Thu, Feb 06, 2014 at 11:30:29AM +0100, Hans Petter Selasky wrote: >> On 02/04/14 20:10, Sarah Sharp wrote: >>> And there's code in the xHCI driver to ignore the second successful >>> event. See ep->last_td_was_short. Yes, this is a slight race >>> condition, and we should wait for the successful event. However, we >>> have not seen any issues with this race condition. >> >> Hi, >> >> Some comments from the side-line: >> >> I've observed some XHCI controllers sending special case events, >> like IO-errors for ISOCHRONOUS endpoints, out of order. In not sure >> if the XHCI specification is clear about this, or not, that when you >> have bunch of TD's on an endpoint, you should not receive the >> completion event for the next timeslot / TD, before receiving the >> IO-error for the previous failed TRB/TD. I'm not sure what tests HW >> guys are doing these days regarding XHCI. This has been observed >> during driver development of FreeBSD's XHCI driver a long time ago, >> and I though I'd mention it for you guys. > Do you mean you get a missed service event, and then an event for some > later TD? Or an event for that later TD, and then a missed service > interval? Or maybe that you queue TD 1 and TD 2, and then receive > events for TD 2 and then TD 1? What's the exact sequence of events > here? No, let me explain. I have a DVB USB adapter which would sometimes overflow the wMaxPacket data transfer length, due to a design flaw or so-called firmware/hardware bug. When that happened, I observed the completions for the faulty transfers would be received out of order, and would confuse the driver logic. This was not a missed service event error. So actually: ISOC TD frame1: OK ISOC TD frame2: too long (IO-ERROR) ISOC TD frame3: OK ISOC TD frame4: OK Resulted in: ISOC TD EVENT complete frame1 ISOC TD EVENT complete frame3 ISOC TD EVENT complete frame4 Some delay: ISOC TD EVENT complete frame2 w/error in status code. Hardware "ASM1042 SuperSpeed USB Host Controller". > > ISTR the xHCI spec does say you could get out-of-order TDs when the host > is actually an SR-IOV virtualized host. However, I had hoped that > wouldn't happen when running on bare hardware. No virtualization here. > >> FreeBSD's XHCI driver: http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup <http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup> > > I can't look at that for licensing reasons, sorry. However, we can have > a conversation about observed hardware behavior. That's fine. I don't read yours driver either BTW: There is something called a dual BSD/GPL license --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci and other woes
On 02/04/14 20:10, Sarah Sharp wrote: And there's code in the xHCI driver to ignore the second successful event. See ep->last_td_was_short. Yes, this is a slight race condition, and we should wait for the successful event. However, we have not seen any issues with this race condition. Hi, Some comments from the side-line: I've observed some XHCI controllers sending special case events, like IO-errors for ISOCHRONOUS endpoints, out of order. In not sure if the XHCI specification is clear about this, or not, that when you have bunch of TD's on an endpoint, you should not receive the completion event for the next timeslot / TD, before receiving the IO-error for the previous failed TRB/TD. I'm not sure what tests HW guys are doing these days regarding XHCI. This has been observed during driver development of FreeBSD's XHCI driver a long time ago, and I though I'd mention it for you guys. --HPS FreeBSD's XHCI driver: http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb scheduler
On Friday 27 July 2012 17:12:51 Alan Stern wrote: > On Fri, 27 Jul 2012, Hans Petter Selasky wrote: > > On Friday 27 July 2012 10:52:11 Alexey Filin wrote: > > > USB is a good choice for some bus adapters, it is used widely, cheap, > > > simple. For 2-byte read/write we could use either two bulk IN/OUT > > > endpoints (131 * 8kHz ~ 1 MHz) or one control endpoint (table 5-3, 42 > > > * 8 kHz = 336 kHz). Ethernet is overkill for the task even if it could > > > provide 1 us delay. > > > > Hi, > > > > If you submit one million URB's per second, you will have a significant > > system overhead? Right? Have you ever tried this application under > > FreeBSD 8+ ? There we allow so-called multi-frame transfers, that means > > you sort of bind toghether multiple jobs into a single URB submit. > > > > For example you can submit 100 2-byte short-packet-jobs in a single > > submit, and have only one completion interrupt from the EHCI controller! > > > > For the XHCI you can even double buffer such transfers. > > The problem is that Alexey needs to use the data returned by the > previous transfer in order to compute the data for the next transfer. > Therefore the transfers must be made sequentially; they cannot be done > concurrently. I see. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb scheduler
On Friday 27 July 2012 10:52:11 Alexey Filin wrote: > USB is a good choice for some bus adapters, it is used widely, cheap, > simple. For 2-byte read/write we could use either two bulk IN/OUT > endpoints (131 * 8kHz ~ 1 MHz) or one control endpoint (table 5-3, 42 > * 8 kHz = 336 kHz). Ethernet is overkill for the task even if it could > provide 1 us delay. Hi, If you submit one million URB's per second, you will have a significant system overhead? Right? Have you ever tried this application under FreeBSD 8+ ? There we allow so-called multi-frame transfers, that means you sort of bind toghether multiple jobs into a single URB submit. For example you can submit 100 2-byte short-packet-jobs in a single submit, and have only one completion interrupt from the EHCI controller! For the XHCI you can even double buffer such transfers. This discussion gets me thinking of once i stress-tested some USB code, by hacking into the EHCI DMA schedule, repeating each control request 128 times or more. This allows for submitting more than 8000 control requests per second for the EHCI controller and can be useful to find timing related issues in the device side. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb scheduler
On Thursday 26 July 2012 17:47:11 Alan Stern wrote: > To get maximum throughput you should submit multiple URBs originally, > and then submit a new URB whenever an URB completes. I recommand using > a pipeline depth of 10-20 ms. For bulk transfers at high speed, that > comes out to between 500 KB and 1 MB of concurrent URB data. Some EHCI hardware will scan for new QH's and TD's when you set the EHCI doorbell bit. This bit is only supposed to be used when you remove QH's/TD's from the ASYNC schedule, but can also be abused when entering QH's/TD's into the schedule. How this works for your EHCI controller, depends on the actual hardware implementation. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb scheduler
On Thursday 26 July 2012 17:47:11 Alan Stern wrote: > > * Is there a USB controller with scheduling in current microframe? > > They all do it. But they won't generate completion IRQs any faster > than 8 KHz. Hi, Maybe a bit off-topic: I've noticed that if you STALL a USB transfer, this rule might not apply. Anyway, STALL is not considered a successful completion. Abusing STALL PID to get higher IRQ rates for the EHCI/XHCI is more or less a hack :-) --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
