Announcing libusbx-1.0.16-rc3
Hi All, I'm very happy to announce libusbx-1.0.16-rc3. Changes since 1.0.16-rc2: - * Improve topology API docs (#95) * Make libusb_hotplug_deregister_callback() wake-up libusb_handle_events() * Document how to use an event handling thread, especially how to stop this thread on exit Changes since 1.0.16-rc1: - * Fix crash on exit on openbsd, netbsd wince * Logging now use a single write call per log-message, avoiding log-message interlacing when using multiple threads. * Do not use uninitialized memory for auto_detach_kernel_driver Highlights of changes since 1.0.15: --- * As Nathan Hjelm already announced in his libusb and libusbx merging mail, Nathan has taken over libusb maintenance and this release is a combined effort between the libusb and libusbx projects! * Hotplug support for Darwin and Linux * Superspeed endpoint companion and BOS descriptor support * We finally have a libusb_strerror API You can find 1.0.16-rc2 docs including all the new API-s here: http://people.fedoraproject.org/~jwrdegoede/libusb-reference/ You can download the 1.0.16-rc2 tarbal here: http://downloads.sourceforge.net/libusbx/libusbx-1.0.16-rc2.tar.bz2 Please give it a thorough testing, and report any issues you find. For those interested the full ChangeLog is below. Regards, Hans 2013-07-05: v1.0.16-rc3 * Add hotplug support for Darwin and Linux (#9) * Add superspeed endpoint companion descriptor support (#15) * Add BOS descriptor support (#15) * Make descriptor parsing code more robust * New libusb_get_port_numbers API, this is libusb_get_port_path without the unnecessary context parameter, libusb_get_port_path is now deprecated * New libusb_strerror API (#14) * New libusb_set_auto_detach_kernel_driver API (#17) * Improve topology API docs (#95) * Logging now use a single write call per log-message, avoiding log-message interlacing when using multiple threads. * Android: use Android logging when building on Android (#101) * Darwin: make libusb_reset reenumerate device on descriptors change (#89) * Darwin: add support for the LIBUSB_TRANSFER_ADD_ZERO_PACKET flag (#91) * Darwin: add a device cache (#112, #114) * Examples: Add sam3u_benchmark isochronous example by Harald Welte (#109) * Many other bug fixes and improvements The (#xx) numbers are libusbx issue numbers, see ie: https://github.com/libusbx/libusbx/issues/9 -- 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: Audio I/O parameters
Alan Stern wrote: The first half is audio-out only. About 2 seconds after the start, the audio-in stream starts up. After 2 URBs (2 ms) of data, everything is shut down for no apparent reason -- there were no I/O errors. [...] I can't tell whether all these starts and stops are caused by JACK or by the ALSA layer, let alone figure out the reason for them. Two URBs is the Jack buffer size, isn't it? Does Jack complain? James, pleasy try running aplay and arecord at the same time; something like this: aplay -D hw:x -t raw -c 4 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 /dev/zero arecord -D hw:x-c 2 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 test.wav Regards, Clemens -- 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: Audio I/O parameters
On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch clem...@ladisch.de wrote: Alan Stern wrote: The first half is audio-out only. About 2 seconds after the start, the audio-in stream starts up. After 2 URBs (2 ms) of data, everything is shut down for no apparent reason -- there were no I/O errors. [...] I can't tell whether all these starts and stops are caused by JACK or by the ALSA layer, let alone figure out the reason for them. Two URBs is the Jack buffer size, isn't it? Does Jack complain? James, pleasy try running aplay and arecord at the same time; something like this: aplay -D hw:x -t raw -c 4 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 /dev/zero arecord -D hw:x-c 2 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 test.wav Yes - this works fine, without issue. -- 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: Audio I/O parameters
On Sat, Jul 6, 2013 at 10:36 AM, James Stone jamesmst...@gmail.com wrote: On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch clem...@ladisch.de wrote: Alan Stern wrote: The first half is audio-out only. About 2 seconds after the start, the audio-in stream starts up. After 2 URBs (2 ms) of data, everything is shut down for no apparent reason -- there were no I/O errors. [...] I can't tell whether all these starts and stops are caused by JACK or by the ALSA layer, let alone figure out the reason for them. Two URBs is the Jack buffer size, isn't it? Does Jack complain? James, pleasy try running aplay and arecord at the same time; something like this: aplay -D hw:x -t raw -c 4 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 /dev/zero arecord -D hw:x-c 2 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 test.wav Yes - this works fine, without issue. (I assumed you wanted me to run these without jack running?) The output when I try to start jack with 128 frames/period is: /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512 -S jackdmp 1.9.9.5 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2012 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 creating alsa driver ... hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 USB at usb-:00:12.2-3, high speed configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ^CJack main caught signal 2 ..the device is unusable with the lights flashing on and off. Jack then shuts down as seen above. At 256 frames/period it starts OK. James -- 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/2] usb: dwc3: adapt to use dr_mode device tree helper
This patch adapts the dwc3 to use the device tree helper
of_usb_get_dr_mode for the mode of operation of the dwc3 instance
being probed.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/dwc3/core.c | 51 +--
drivers/usb/dwc3/core.h |5 -
2 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..7b98e4f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -517,14 +517,17 @@ static int dwc3_probe(struct platform_device *pdev)
}
if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
- mode = DWC3_MODE_HOST;
+ mode = USB_DR_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
- mode = DWC3_MODE_DEVICE;
+ mode = USB_DR_MODE_PERIPHERAL;
else
- mode = DWC3_MODE_DRD;
+ mode = of_usb_get_dr_mode(node);
+
+ if (mode == USB_DR_MODE_UNKNOWN)
+ mode = USB_DR_MODE_OTG;
switch (mode) {
- case DWC3_MODE_DEVICE:
+ case USB_DR_MODE_PERIPHERAL:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret) {
@@ -532,7 +535,7 @@ static int dwc3_probe(struct platform_device *pdev)
goto err2;
}
break;
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -540,7 +543,7 @@ static int dwc3_probe(struct platform_device *pdev)
goto err2;
}
break;
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_OTG:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -572,13 +575,13 @@ static int dwc3_probe(struct platform_device *pdev)
err3:
switch (mode) {
- case DWC3_MODE_DEVICE:
+ case USB_DR_MODE_PERIPHERAL:
dwc3_gadget_exit(dwc);
break;
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
dwc3_host_exit(dwc);
break;
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_OTG:
dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
break;
@@ -612,13 +615,13 @@ static int dwc3_remove(struct platform_device *pdev)
dwc3_debugfs_exit(dwc);
switch (dwc-mode) {
- case DWC3_MODE_DEVICE:
+ case USB_DR_MODE_PERIPHERAL:
dwc3_gadget_exit(dwc);
break;
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
dwc3_host_exit(dwc);
break;
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_OTG:
dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
break;
@@ -643,11 +646,11 @@ static int dwc3_prepare(struct device *dev)
spin_lock_irqsave(dwc-lock, flags);
switch (dwc-mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_prepare(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
dwc3_event_buffers_cleanup(dwc);
break;
@@ -666,11 +669,11 @@ static void dwc3_complete(struct device *dev)
spin_lock_irqsave(dwc-lock, flags);
switch (dwc-mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_complete(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
dwc3_event_buffers_setup(dwc);
break;
@@ -687,11 +690,11 @@ static int dwc3_suspend(struct device *dev)
spin_lock_irqsave(dwc-lock, flags);
switch (dwc-mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_suspend(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
/* do nothing */
break;
@@ -720,11 +723,11 @@ static int dwc3_resume(struct device *dev)
dwc3_writel(dwc-regs, DWC3_GCTL, dwc-gctl);
switch (dwc-mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_resume(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h
[PATCH 2/2] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
When the initialization of usb3 phy fails, when enabled in the system
the dwc3_probe deferral is further qualified by the maximum speed.
In devices such as dra7xx, there are multiple dwc3 instances where the
maximum_speed is different between the instances.
This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/dwc3/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7b98e4f..05f2205 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret == -ENXIO)
return ret;
- dev_err(dev, no usb3 phy configured\n);
- return -EPROBE_DEFER;
+ if (dwc-maximum_speed == USB_SPEED_SUPER) {
+ dev_err(dev, no usb3 phy configured\n);
+ return -EPROBE_DEFER;
+ } else
+ dev_dbg(dev, maximum speed is super\n);
}
usb_phy_set_suspend(dwc-usb2_phy, 0);
--
1.7.9.5
--
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: Repeated disconnects of wired mouse
Please use Reply-To-All so that your messages get sent to the mailing list as well as to me. On Sat, 6 Jul 2013, Larry Keegan wrote: On Fri, 5 Jul 2013 17:41:25 -0400 Alan Stern st...@rowland.harvard.edu wrote: On Fri, 5 Jul 2013, Larry Keegan wrote: Dear Chaps, I have a Microsoft Basic Optical mouse. When I used an earlier kernel (2.6 series) it just worked. However, now that I'm using 3.4.51 it suffers from USB disconnects and reconnects every 62 seconds precisely. These disconnects do not occur whilst the mouse device is open. I have tried two different wired mice in different USB slots of different computers with different motherboard types, all to no avail. Can you post a usbmon trace showing some of those disconnects and reconnects? Dear Alan, Thank you very much for helping me to diagnose this problem. The following trace was made by waiting for a disconnect and reconnect event to complete, starting cat, waiting for another event and killing cat a few seconds afterwards. The mouse was plugged directly into the socket on the motherboard. # cat /sys/kernel/debug/usb/usbmon/4u e9921c00 2437517512 C Ii:4:001:1 0:128 1 = 04 e9921c00 2437517523 S Ii:4:001:1 -115:128 2 e7454480 2437517533 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437517543 C Ci:4:001:0 0 4 = 00010300 e7454480 2437517545 S Co:4:001:0 s 23 01 0010 0002 0 e7454480 2437517548 C Co:4:001:0 0 0 e7454480 2437517549 S Co:4:001:0 s 23 01 0011 0002 0 e7454480 2437517551 C Co:4:001:0 0 0 e7454900 2437520222 S Ci:4:001:0 s a3 00 0002 0004 4 e7454900 2437520229 C Ci:4:001:0 0 4 = 0001 e7454480 2437545511 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437545518 C Ci:4:001:0 0 4 = 0001 e4411780 2437571511 S Ci:4:001:0 s a3 00 0002 0004 4 e4411780 2437571517 C Ci:4:001:0 0 4 = 0001 e7454480 2437597511 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437597517 C Ci:4:001:0 0 4 = 0001 e7454480 2437623509 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437623515 C Ci:4:001:0 0 4 = 0001 e9921c00 2439017513 C Ii:4:001:1 0:128 1 = 04 e9921c00 2439017518 S Ii:4:001:1 -115:128 2 e7454480 2439017523 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2439017528 C Ci:4:001:0 0 4 = 01030100 ... This at least confirms that the disconnects do take place at the hardware level. They aren't merely a software artifact. I can supply more if you tell me what configurations are most interesting. No, I don't think usbmon will reveal anything more interesting than this. What is interesting is that if I connect either mouse to the computer via a hub, the timing of the disconnects becomes irregular and unpredictable. I often find all the devices on the bus (ie. everything but the root hub) disconnect themselves at much the same time as the mouse does. Often the mouse doesn't reconnect to the bus. In any case plugging in either mouse makes that entire bus distinctly unreliable. This problem is not peculiar to any particular hub model. It certainly sounds like something in the mice is causing all this disturbance. I am using a virgin kernel and am not using a well-known user-space distribution. I use udev to set up my device nodes, but that's all. To me, this has a distinct whiff of USB suspend problems. I have attempted to turn off USB suspend by repeatedly writing 'on' to all the 'power/control' files under /sys/bus/usb/devices. It did not help. I also re-compiled the kernel with power management and usb suspend support removed. This didn't help either. That's a pretty clear indication that USB suspend is _not_ involved. I'd appreciate some advice. It's possible this is an electrical problem -- the bus may not provide enough power for all the devices on it. I doubt it's a power problem because: - I have tried 3 computers now, each with different motherboards. - One of the computers has had no hardware changes. It worked before I updated the kernel, but fails now. - The computers consist of nothing more than motherboard with integrated graphics, 35W or 65W Celeron CPU, RAM and single HDD. They are powered by 250, 450 and 750W power supplies respectively. One of the computers has a slim-line Radeon graphics card. - I've also tried connecting the mouse via a Startech USB2EXT4 CAT5 USB extender. This device is mains-powered on both the local and remote end. Agreed, lack of power seems unlikely. EMI is also a possibility - both mains-borne and pick up from the unscreened mouse leads. Although I've not done any spectrum analysis, I have tried creating interference (mains and irradiated) and they seem pretty immune to upset. The other thing is, prior to doing the interference tests, the tangle of wires hadn't moved for months, as the dust testified. The other thing which makes me feel that power and EMI are unlikely to be the cause of
Re: [PATCH 2/2] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
Hello.
On 06-07-2013 16:53, Ruchika Kharwar wrote:
When the initialization of usb3 phy fails, when enabled in the system
the dwc3_probe deferral is further qualified by the maximum speed.
In devices such as dra7xx, there are multiple dwc3 instances where the
maximum_speed is different between the instances.
This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Don't indent the changelog please.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/dwc3/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7b98e4f..05f2205 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret == -ENXIO)
return ret;
- dev_err(dev, no usb3 phy configured\n);
- return -EPROBE_DEFER;
+ if (dwc-maximum_speed == USB_SPEED_SUPER) {
+ dev_err(dev, no usb3 phy configured\n);
+ return -EPROBE_DEFER;
+ } else
+ dev_dbg(dev, maximum speed is super\n);
According to Documenation/CodingStyle chapter 3, there should be {}
on both arms of the *if* statement if one arm has it.
WBR, Sergei
--
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
inconsistent {IN-HARDIRQ-W} - {HARDIRQ-ON-W} usage with hcd_urb_list_lock
I didn't even know I still had lockdep on.
The following lockdep splat happened when I plugged in a usb bluetooth dongle,
using
the pre-rc1 3.11 kernel at HEAD b2c311075db
=
[ INFO: inconsistent lock state ]
3.10.0+ #106 Not tainted
-
inconsistent {IN-HARDIRQ-W} - {HARDIRQ-ON-W} usage.
irq/42-xhci_hcd/97 [HC0[0]:SC0[2]:HE1:SE0] takes:
(hcd_urb_list_lock){?.}, at: [8149440e]
usb_hcd_unlink_urb_from_ep+0x28/0x4e
{IN-HARDIRQ-W} state was registered at:
[810afbc6] __lock_acquire+0x861/0x1c2e
[810b1556] lock_acquire+0x87/0x139
[81698a1a] _raw_spin_lock+0x3b/0x4a
[8149440e] usb_hcd_unlink_urb_from_ep+0x28/0x4e
[814a65f1] ehci_urb_done+0x5b/0x9c
[814a8e18] qh_completions+0x311/0x3ca
[814aa613] ehci_handle_intr_unlinks+0xad/0x143
[814a7098] ehci_hrtimer_func+0x6b/0xbd
[8107cfc8] __run_hrtimer+0x61/0x1f9
[8107d7ca] hrtimer_interrupt+0x10a/0x253
[810256c0] local_apic_timer_interrupt+0x38/0x5e
[81025ab5] smp_apic_timer_interrupt+0x46/0x5b
[816a152f] apic_timer_interrupt+0x6f/0x80
irq event stamp: 224
hardirqs last enabled at (224): [8168e8d4] __slab_free+0x1c7/0x2ed
hardirqs last disabled at (223): [8168e846] __slab_free+0x139/0x2ed
softirqs last enabled at (206): [810d8024]
irq_forced_thread_fn+0x49/0x5a
softirqs last disabled at (212): [810d7fff]
irq_forced_thread_fn+0x24/0x5a
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(hcd_urb_list_lock);
Interrupt
lock(hcd_urb_list_lock);
*** DEADLOCK ***
1 lock held by irq/42-xhci_hcd/97:
#0: ((xhci-lock)-rlock){+.-...}, at: [814befdd]
xhci_irq+0x2f/0x143d
stack backtrace:
CPU: 1 PID: 97 Comm: irq/42-xhci_hcd Not tainted 3.10.0+ #106
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
8210c150 88040834da48 81691af4 0007
8804082e20b0 88040834daa8 8168cb10 0002
88040001 8804 8100f4f7 88040834dac4
Call Trace:
[81691af4] dump_stack+0x4f/0x84
[8168cb10] print_usage_bug+0x1f5/0x206
[8100f4f7] ? save_stack_trace+0x2f/0x50
[810af30c] mark_lock+0x276/0x2cf
[810ae8cc] ? check_usage_forwards+0x12f/0x12f
[810af925] __lock_acquire+0x5c0/0x1c2e
[810b1e04] ? mark_held_locks+0x6d/0x117
[8168e8d4] ? __slab_free+0x1c7/0x2ed
[810b1f5a] ? trace_hardirqs_on_caller+0xac/0x1bb
[810b2076] ? trace_hardirqs_on+0xd/0xf
[8149440e] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[810b1556] lock_acquire+0x87/0x139
[8149440e] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[81698a1a] _raw_spin_lock+0x3b/0x4a
[8149440e] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[8149440e] usb_hcd_unlink_urb_from_ep+0x28/0x4e
[814bf55a] xhci_irq+0x5ac/0x143d
[81699171] ? _raw_spin_unlock_irq+0x3b/0x5d
[8108386d] ? finish_task_switch+0x7c/0x101
[81083830] ? finish_task_switch+0x3f/0x101
[81697060] ? __schedule+0x42a/0x885
[810d7fdb] ? irq_thread_fn+0x48/0x48
[814c03fc] xhci_msi_irq+0x11/0x15
[810d8009] irq_forced_thread_fn+0x2e/0x5a
[810d7d36] irq_thread+0x10e/0x131
[810d7ee3] ? irq_finalize_oneshot.part.33+0xe0/0xe0
[810d7c28] ? wake_threads_waitq+0x44/0x44
[81079b61] kthread+0xea/0xef
[81079a77] ? flush_kthread_work+0x19c/0x19c
[816a082c] ret_from_fork+0x7c/0xb0
[81079a77] ? flush_kthread_work+0x19c/0x19c
--
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: Repeated disconnects of wired mouse
On Sat, 6 Jul 2013 09:53:21 -0400 Alan Stern st...@rowland.harvard.edu wrote: Please use Reply-To-All so that your messages get sent to the mailing list as well as to me. Dear Alan, Sorry! As it happened I just noticed this and was about to re-send it when my mailer crashed... On Sat, 6 Jul 2013, Larry Keegan wrote: On Fri, 5 Jul 2013 17:41:25 -0400 Alan Stern st...@rowland.harvard.edu wrote: On Fri, 5 Jul 2013, Larry Keegan wrote: Dear Chaps, I have a Microsoft Basic Optical mouse. When I used an earlier kernel (2.6 series) it just worked. However, now that I'm using 3.4.51 it suffers from USB disconnects and reconnects every 62 seconds precisely. These disconnects do not occur whilst the mouse device is open. I have tried two different wired mice in different USB slots of different computers with different motherboard types, all to no avail. Can you post a usbmon trace showing some of those disconnects and reconnects? Dear Alan, Thank you very much for helping me to diagnose this problem. The following trace was made by waiting for a disconnect and reconnect event to complete, starting cat, waiting for another event and killing cat a few seconds afterwards. The mouse was plugged directly into the socket on the motherboard. # cat /sys/kernel/debug/usb/usbmon/4u e9921c00 2437517512 C Ii:4:001:1 0:128 1 = 04 e9921c00 2437517523 S Ii:4:001:1 -115:128 2 e7454480 2437517533 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437517543 C Ci:4:001:0 0 4 = 00010300 e7454480 2437517545 S Co:4:001:0 s 23 01 0010 0002 0 e7454480 2437517548 C Co:4:001:0 0 0 e7454480 2437517549 S Co:4:001:0 s 23 01 0011 0002 0 e7454480 2437517551 C Co:4:001:0 0 0 e7454900 2437520222 S Ci:4:001:0 s a3 00 0002 0004 4 e7454900 2437520229 C Ci:4:001:0 0 4 = 0001 e7454480 2437545511 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437545518 C Ci:4:001:0 0 4 = 0001 e4411780 2437571511 S Ci:4:001:0 s a3 00 0002 0004 4 e4411780 2437571517 C Ci:4:001:0 0 4 = 0001 e7454480 2437597511 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437597517 C Ci:4:001:0 0 4 = 0001 e7454480 2437623509 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2437623515 C Ci:4:001:0 0 4 = 0001 e9921c00 2439017513 C Ii:4:001:1 0:128 1 = 04 e9921c00 2439017518 S Ii:4:001:1 -115:128 2 e7454480 2439017523 S Ci:4:001:0 s a3 00 0002 0004 4 e7454480 2439017528 C Ci:4:001:0 0 4 = 01030100 ... This at least confirms that the disconnects do take place at the hardware level. They aren't merely a software artifact. I can supply more if you tell me what configurations are most interesting. No, I don't think usbmon will reveal anything more interesting than this. Just a thought, but has the way the kernel 'sets-up' a USB mouse changed over the months? I mean in a way which would mean different numbers in the above usbmon trace? What I'm wondering is if the newer kernel could be eeking out different bugs in the mouse's software, and that is provoking the disconnect. Is that possible? Or is it genuinely an electrical thing? I'm afraid I know zip about USB. What is interesting is that if I connect either mouse to the computer via a hub, the timing of the disconnects becomes irregular and unpredictable. I often find all the devices on the bus (ie. everything but the root hub) disconnect themselves at much the same time as the mouse does. Often the mouse doesn't reconnect to the bus. In any case plugging in either mouse makes that entire bus distinctly unreliable. This problem is not peculiar to any particular hub model. It certainly sounds like something in the mice is causing all this disturbance. I am using a virgin kernel and am not using a well-known user-space distribution. I use udev to set up my device nodes, but that's all. To me, this has a distinct whiff of USB suspend problems. I have attempted to turn off USB suspend by repeatedly writing 'on' to all the 'power/control' files under /sys/bus/usb/devices. It did not help. I also re-compiled the kernel with power management and usb suspend support removed. This didn't help either. That's a pretty clear indication that USB suspend is _not_ involved. I'd appreciate some advice. It's possible this is an electrical problem -- the bus may not provide enough power for all the devices on it. I doubt it's a power problem because: - I have tried 3 computers now, each with different motherboards. - One of the computers has had no hardware changes. It worked before I updated the kernel, but fails now. - The computers consist of nothing more than motherboard with integrated graphics, 35W or 65W Celeron CPU, RAM and single HDD. They are powered by 250, 450 and 750W power supplies respectively. One of the
Re: Audio I/O parameters
On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 6 Jul 2013, James Stone wrote: The output when I try to start jack with 128 frames/period is: /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512 -S jackdmp 1.9.9.5 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2012 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 creating alsa driver ... hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 USB at usb-:00:12.2-3, high speed configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ^CJack main caught signal 2 ..the device is unusable with the lights flashing on and off. Jack then shuts down as seen above. At 256 frames/period it starts OK. What happens if you run JACK with input only, no audio out? Alan Stern It works fine with both input only or output only - down to 16 frames/period. At 8 frames/period it shows the same behaviour as at 256 frames/period in duplex - but that is a ridiculously low latency of 0.2ms, so hardly surprising it won't work. I have now got an error message when jack fails to start in duplex mode: ALSA: prepare error for playback on hw:USB,0 (Protocol error) JackAudioDriver::ProcessAsync: read error, stopping... James -- 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: Audio I/O parameters
On Sat, Jul 6, 2013 at 9:36 PM, James Stone jamesmst...@gmail.com wrote: On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 6 Jul 2013, James Stone wrote: The output when I try to start jack with 128 frames/period is: /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512 -S jackdmp 1.9.9.5 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2012 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 creating alsa driver ... hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 USB at usb-:00:12.2-3, high speed configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ^CJack main caught signal 2 ..the device is unusable with the lights flashing on and off. Jack then shuts down as seen above. At 256 frames/period it starts OK. What happens if you run JACK with input only, no audio out? Alan Stern It works fine with both input only or output only - down to 16 frames/period. At 8 frames/period it shows the same behaviour as at 256 frames/period in duplex - but that is a ridiculously low latency of 0.2ms, so hardly surprising it won't work. I have now got an error message when jack fails to start in duplex mode: ALSA: prepare error for playback on hw:USB,0 (Protocol error) JackAudioDriver::ProcessAsync: read error, stopping... James Sorry - slight misinformation there. I can go down to 16 frames/period for capture only, but for playback only, it will only go down to 128 frames/period. Anything lower: /usr/bin/jackd -dalsa -r44100 -p64 -n2 -Phw:USB,0 -I512 -O512 -S jackdmp 1.9.9.5 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2012 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 creating alsa driver ... hw:USB,0|-|64|2|44100|0|0|nomon|swmeter|-|16bit Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 USB at usb-:00:12.2-3, high speed configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ALSA: poll time out, polled for 2176094 usecs JackAudioDriver::ProcessAsync: read error, stopping... This is a definite reduction in performance compared to earlier kernels. James -- 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: inconsistent {IN-HARDIRQ-W} - {HARDIRQ-ON-W} usage with hcd_urb_list_lock
On Sat, 6 Jul 2013, Maarten Lankhorst wrote:
I didn't even know I still had lockdep on.
The following lockdep splat happened when I plugged in a usb bluetooth
dongle, using
the pre-rc1 3.11 kernel at HEAD b2c311075db
=
[ INFO: inconsistent lock state ]
3.10.0+ #106 Not tainted
-
inconsistent {IN-HARDIRQ-W} - {HARDIRQ-ON-W} usage.
irq/42-xhci_hcd/97 [HC0[0]:SC0[2]:HE1:SE0] takes:
(hcd_urb_list_lock){?.}, at: [8149440e]
usb_hcd_unlink_urb_from_ep+0x28/0x4e
stack backtrace:
CPU: 1 PID: 97 Comm: irq/42-xhci_hcd Not tainted 3.10.0+ #106
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
8210c150 88040834da48 81691af4 0007
8804082e20b0 88040834daa8 8168cb10 0002
88040001 8804 8100f4f7 88040834dac4
Call Trace:
[81691af4] dump_stack+0x4f/0x84
[8168cb10] print_usage_bug+0x1f5/0x206
[8100f4f7] ? save_stack_trace+0x2f/0x50
[810af30c] mark_lock+0x276/0x2cf
[810ae8cc] ? check_usage_forwards+0x12f/0x12f
[810af925] __lock_acquire+0x5c0/0x1c2e
[810b1e04] ? mark_held_locks+0x6d/0x117
[8168e8d4] ? __slab_free+0x1c7/0x2ed
[810b1f5a] ? trace_hardirqs_on_caller+0xac/0x1bb
[810b2076] ? trace_hardirqs_on+0xd/0xf
[8149440e] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[810b1556] lock_acquire+0x87/0x139
[8149440e] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[81698a1a] _raw_spin_lock+0x3b/0x4a
[8149440e] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[8149440e] usb_hcd_unlink_urb_from_ep+0x28/0x4e
[814bf55a] xhci_irq+0x5ac/0x143d
[81699171] ? _raw_spin_unlock_irq+0x3b/0x5d
[8108386d] ? finish_task_switch+0x7c/0x101
[81083830] ? finish_task_switch+0x3f/0x101
[81697060] ? __schedule+0x42a/0x885
[810d7fdb] ? irq_thread_fn+0x48/0x48
[814c03fc] xhci_msi_irq+0x11/0x15
It looks like xhci_msi_irq() needs to call local_irq_save() and
local_irq_restore().
Alan Stern
--
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: Repeated disconnects of wired mouse
On Sat, 6 Jul 2013, Larry Keegan wrote:
Just a thought, but has the way the kernel 'sets-up' a USB mouse
changed over the months? I mean in a way which would mean different
numbers in the above usbmon trace? What I'm wondering is if the newer
kernel could be eeking out different bugs in the mouse's software, and
that is provoking the disconnect. Is that possible? Or is it genuinely an
electrical thing? I'm afraid I know zip about USB.
As far as I know, there haven't been any changes in the way a USB mouse
gets initialized. Besides, even if there were, I have never heard of
any setting that would tell the mouse to disconnect itself every 62
seconds! :-)
The other thing which makes me feel that power and EMI are unlikely
to be the cause of the problem is the precise nature of the events.
Here is a snippet from my syslog:
# tail -f /var/log/messages | grep 'USB disconnect'
2013-07-06T11:27:19.518567Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 126
2013-07-06T11:28:21.518556Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 127
2013-07-06T11:29:23.518567Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 2
2013-07-06T11:30:25.518562Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 3
2013-07-06T11:31:27.518568Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 4
2013-07-06T11:32:29.518567Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 5
2013-07-06T11:33:31.518568Z {0.6} ud1 kernel: usb 4-2: USB
disconnect, device number 6
These events occur with surprising regularity. Too regular for it
to be an uncorrelated external event. Three mice, (two Microsoft,
and one other) but all three containing the same PixArt chip all
exhibit the same timing. If this were power droop I'd expect
capacitor component tolerances to cause slightly different timings
on the different mice, or different computers but they are
microsecond perfect.
Yes. Obviously this is related to a hardware or software timer. The
microsecond perfection may not mean anything, however. Is this bus
connected to a UHCI controller? The uhci-hcd driver uses a software
timer for detecting port-connect changes; the timer runs at a steady
rate of precisely 4 times per second.
Ah ah. I thought the numbers were suspiciously regular. I suppose the
mice, being 1.5Mbps devices will be connected to the UHCI. The ports
are wired to the motherboard's Intel ICH7. The port is definitely also
capable of speaking at 480Mbps.
You didn't say before that your motherboard was Intel. Other brands
use OHCI instead of UHCI, and the ohci-hcd driver uses hardware
interrupts rather than a software timer for detecting port-connect
changes.
However, I'm not sure this explains the essentially-random behaviour of
the most of the bus when the mouse is plugged into a USB 2.0 hub. In
With an external hub, the port-status packets are sent based on a
hardware timer that triggers 8 times per second, with great regularity.
these cases it is my understanding that the controller is EHCI and the
hub buffers these packets and sends them over the 480Mbps link as if
they were 'normal' USB 2.0 packets. That implies the mouse is also
electrically incompatible with my hubs. Umm. I'll look into this.
They aren't electically incompatible, or they wouldn't work at all.
But _something_ is causing them to disconnect.
You said the problems began on one of the computers when you upgraded
the kernel. Can you try using bisection to find the kernel change
that first triggered the problem?
I'm recompiling as we speak.
This seems like the best approach. It wouldn't be surprising to find
that the problem's source lies in some totally unexpected area.
Thank you very much for your help.
You're welcome.
Alan Stern
--
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: musb: dsps: make it work with two instances
Hi Sebastian, On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This enables the two musb instances on am335x to work. I like a lot the idea of splitting the DT representation of the two USB instances. The DT binding looks much better this way. After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. Also, FWIW, I think that having a separate USB phy for am35xx would be much better. Nice job! -- Ezequiel -- 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 2/2] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
On 07:53-20130706, Ruchika Kharwar wrote:
When the initialization of usb3 phy fails, when enabled in the system
the dwc3_probe deferral is further qualified by the maximum speed.
In devices such as dra7xx, there are multiple dwc3 instances where the
maximum_speed is different between the instances.
indentation.
This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Dependencies must be stated in diffstat - it is better to post a
complete series unless this maybe a standalone - which it seems to be..
just my 2 cents.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/dwc3/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7b98e4f..05f2205 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret == -ENXIO)
return ret;
- dev_err(dev, no usb3 phy configured\n);
- return -EPROBE_DEFER;
+ if (dwc-maximum_speed == USB_SPEED_SUPER) {
+ dev_err(dev, no usb3 phy configured\n);
+ return -EPROBE_DEFER;
is deferal always the right solution? just curious if one does not
declare the phy node, would'nt there be an opportunity to giveup
earlier?
+ } else
+ dev_dbg(dev, maximum speed is super\n);
Checkpatch would have asked you to add {} on both branches of the if
condition ;)
}
usb_phy_set_suspend(dwc-usb2_phy, 0);
--
1.7.9.5
--
Regards,
Nishanth Menon
--
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: Chipidea usb otg support for IMX/MXS (device functionality)
Hi Peter, Where can I measure this? Two possible reasons: 1. You have not gpio control for vbus toggle when role switches. This works well. 2. Your hardware has some problems that the vbus can't lower than 0.8v. How can I check that? Just measure the voltage of your otg vbus pin. It's 2.5 volt for me. What am I supposed to observe happening there? Best regards, Marek Vasut -- 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
