Re: Missing USB XHCI and EHCI reset for kexec
On Tue, 2014-04-15 at 20:54 +0200, Stefani Seibold wrote: > > > > > [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller > > > > > [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered, > > > > > assigned bus number 1 > > > > > [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000 > > > > > microseconds. > > > > > [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110 > > > > > [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered > > > > > [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110 > > > > > [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error > > > > > -110 > > > > > Cascardo, Alan, Bringing back that old thread.. I'm trying to kexec from our OPAL FW bootloader (3.10.23 based) to a fedora 3.14.3 on a new machine and am still seeing the above. A reset brings the chip back. Do we have any resolution here ? It looks like the xHCI remains active on the way out and is clagged up on the way back in, at least in a state the driver really doesn't like. And this is a "clean" kexec, not a forced one... This is killing USB on the upcoming OpenPower dev machines. Cheers, Ben. -- 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 v2] leds: USB: Add support for MSI GT683R led panels
> First of all, please reply to the original thread and make sure to not
> drop people or lists from CC.
Sorry this is my first patch and i didn't know that. Now I know.
> For arrays you can use the ARRAY_SIZE() macro if that was the reason for
> this change. I should have mentioned that when I pointed out that you
> cannot use strlen().
That wasn't the reason. I just thought it might be better to use u64
than char[8]. I know why I can't use strlen and that was only careless
error. And there was lot of them :( I will be more careful next time.
> Where did you get these (HID report) values from by the way?
I got them by reverse engineering.
>> +
>> +static void gt683r_brightness_set(struct led_classdev *led_cdev,
>> + enum led_brightness brightness)
>> +{
>> + struct gt683r_led *led =
>> + container_of(led_cdev, struct gt683r_led, led_dev);
>> +
>> + mutex_lock(&led->lock);
>
> You cannot grab a mutex here since this function can be called from
> interrupt context (if I remember correctly). Either way, you shouldn't
> be holding the lock until the work task has finished...
I thought use asked me to put some lock there:
>> +
>> +static void gt683r_brightness_set(struct led_classdev *led_cdev,
>> + enum led_brightness brightness)
>> +{
>> + struct gt683r_led *led =
>> + container_of(led_cdev, struct gt683r_led, led_dev);
>> +
>> + led->brightness = brightness;
>
> Missing locking?
Janne
--
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] [usb] Fixed a few typos
Signed-off-by: Mickael Maison
---
drivers/usb/gadget/mv_udc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index fcff3a5..040fb16 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -332,7 +332,7 @@ static int queue_dtd(struct mv_ep *ep, struct mv_req *req)
/* clear active and halt bit, in case set from a previous error */
dqh->size_ioc_int_sts &= ~(DTD_STATUS_ACTIVE | DTD_STATUS_HALTED);
- /* Ensure that updates to the QH will occure before priming. */
+ /* Ensure that updates to the QH will occur before priming. */
wmb();
/* Prime the Endpoint */
@@ -1656,7 +1656,7 @@ static void handle_setup_packet(struct mv_udc *udc, u8
ep_num,
dev_dbg(&udc->dev->dev, "SETUP %02x.%02x v%04x i%04x l%04x\n",
setup->bRequestType, setup->bRequest,
setup->wValue, setup->wIndex, setup->wLength);
- /* We process some stardard setup requests here */
+ /* We process some standard setup requests here */
if ((setup->bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (setup->bRequest) {
case USB_REQ_GET_STATUS:
--
1.8.3.2
--
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 usb 3.0 logitech c920 not working
On 2014-06-03 10:29, Oliver Neukum wrote:
No, if you are using the current upstream, xhci_hcd can do dynamic
debugging. No need to recompile.
Can you please provide me with instructions (console commands) on how to
enable and capture xhci_hcd dynamic debugging verbatim with the current
upstream (3.15.0-031500rc8)? I don't know what information/logs you
require ... or how to get them.
Regards
Martin
Addendum
I'm really sorry about the way I posted this. This is how my
Upstream-Bugreport to your Mailing-List should have looked like to begin
with. Well, better late than never ...
Summary:
Logitech c920 usb webcam not working when plugged into USB 3.0 port
Description:
My logitech c920 usb webcam doesn't work when connected to my usb 3.0
host controller (Etron EJ168a). When i connect my usb 3.0 stick to the
same port it's recognized and also works - just not the webcam.
disabling usb 3.0 legacy mode (xhci) in my bios doesn't change anything,
it's still used instead of ehci.
Workaround:
When connected to a usb 2.0 port it works perfectly.
Launchpad Bug-Report-Link:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1319443
Kernel-Version:
Linux version 3.15.0-031500rc8-generic (apw@gomeisa) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201406012235 SMP Mon Jun 2 02:36:11
UTC 2014
Environment:
Description:Ubuntu 14.04 LTS
Release:14.04
Bios-Information:
dmi.bios.date: 06/29/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P2.30
dmi.board.name: Z68 Pro3 Gen3
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvrP2.30:bd06/29/2012:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ68Pro3Gen3:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
I know the various logs should be put into the body of the mail but then
it would be blocked by Majordomo ('Message size exceeding 100 000
characters causes blocking'). So I uploaded the following Information to
an external server (pastebin):
Software/lspci-v.for.the.c920/CPU-Info/Module
Information/ioports/iomem/lspci-vvv/Scsi-Info/Interrupts. It is also
attached separately at the Launchpad-Link posted above.
http://pastebin.com/XcDiM83S
Please tell me which commands to run to track down the problem or
provide useful debug-information.
Regards
Martin
--
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: Missing USB XHCI and EHCI reset for kexec
[Added Mathias to CC: list] On Sat, 7 Jun 2014, Benjamin Herrenschmidt wrote: > I'm trying to kexec from our OPAL FW bootloader (3.10.23 based) to a > fedora 3.14.3 on a new machine and am still seeing the above. > > A reset brings the chip back. > > Do we have any resolution here ? It looks like the xHCI remains active > on the way out and is clagged up on the way back in, at least in a > state the driver really doesn't like. > > And this is a "clean" kexec, not a forced one... This is killing USB on > the upcoming OpenPower dev machines. The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP) that causes the shutdown routine to reset the controller. It wasn't meant for fixing kexec problems, but I bet you could use it for that purpose. In addition, it's possible that a reset is needed in the probe pathway. 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: Missing USB XHCI and EHCI reset for kexec
On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote: > The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP) > that causes the shutdown routine to reset the controller. It wasn't > meant for fixing kexec problems, but I bet you could use it for that > purpose. > > In addition, it's possible that a reset is needed in the probe pathway. Ok, thanks. I'll have a look. A reset in the probe means fixing distros, I'd rather find a way to fix it from the kexec path entirely, even if that involves adding a quirk on the way out to reset it in shutdown() I'll see what I can come up with that works and will come back to you. Cheers, Ben. -- 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
sleeping function called with IRQs disabled
Just got the below when I plugged in a new webcam. Not sure it's a bug
in xhci (using GFP_KERNEL presumably) or (less likely?) in the USB
autosuspend code.
johannes
[ 141.317464] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 141.558966] usb 1-1: New USB device found, idVendor=058f, idProduct=5608
[ 141.559035] usb 1-1: New USB device strings: Mfr=3, Product=1, SerialNumber=0
[ 141.559094] usb 1-1: Product: USB 2.0 PC Camera
[ 141.559160] usb 1-1: Manufacturer: Alcor Micro, Corp.
[ 141.566501] uvcvideo: Found UVC 1.00 device USB 2.0 PC Camera (058f:5608)
[ 141.571136] input: USB 2.0 PC Camera as
/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/input/input11
[ 143.809835] BUG: sleeping function called from invalid context at
mm/slab.c:2946
[ 143.809922] in_atomic(): 1, irqs_disabled(): 1, pid: 39, name: kworker/2:1
[ 143.809994] 4 locks held by kworker/2:1/39:
[ 143.810041] #0: ("pm"){.+.+.+}, at: []
process_one_work+0x171/0x40a
[ 143.810268] #1: ((&dev->power.work)){+.+.+.}, at: []
process_one_work+0x171/0x40a
[ 143.810483] #2: (&port_dev->status_lock){+.+.+.}, at: []
usb_lock_port+0x12/0x14 [usbcore]
[ 143.810709] #3: (&(&xhci->lock)->rlock){-.-...}, at: []
xhci_stop_device.constprop.10+0x4e/0x13f [xhci_hcd]
[ 143.810955] irq event stamp: 91782
[ 143.811007] hardirqs last enabled at (91781): []
debug_check_no_locks_freed+0x12b/0x141
[ 143.89] hardirqs last disabled at (91782): []
_raw_spin_lock_irqsave+0x1a/0x55
[ 143.811228] softirqs last enabled at (91684): []
neigh_periodic_work+0x102/0x27e
[ 143.811337] softirqs last disabled at (91680): []
neigh_periodic_work+0x2f/0x27e
[ 143.811450] CPU: 2 PID: 39 Comm: kworker/2:1 Not tainted 3.15.0-rc8+ #37
[ 143.811529] Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09
12/13/2012
[ 143.811605] Workqueue: pm pm_runtime_work
[ 143.811699] 0027 8802153fb718 813e53fc
0006
[ 143.811896] 8802153f4a50 8802153fb748 81063def
0001
[ 143.812092] 880213758000 88021d800280 8010
8802153fb758
[ 143.812288] Call Trace:
[ 143.812338] [] dump_stack+0x4e/0x68
[ 143.812397] [] __might_sleep+0x19c/0x1a4
[ 143.812470] []
cache_alloc_debugcheck_before.isra.34+0x1d/0x24
[ 143.812554] [] __kmalloc+0x4c/0x11c
[ 143.812617] [] ? kzalloc+0xf/0x11 [xhci_hcd]
[ 143.812683] [] kzalloc+0xf/0x11 [xhci_hcd]
[ 143.812747] [] xhci_alloc_command+0x27/0xaf [xhci_hcd]
[ 143.812813] [] xhci_stop_device.constprop.10+0x76/0x13f
[xhci_hcd]
[ 143.812893] [] xhci_hub_control+0x89d/0xd6a [xhci_hcd]
[ 143.812966] [] usb_hcd_submit_urb+0x5c7/0x777 [usbcore]
[ 143.813034] [] ? rcu_read_lock_held+0x36/0x38
[ 143.813094] [] ? __module_address+0x9a/0xc6
[ 143.813160] [] usb_submit_urb+0x43a/0x467 [usbcore]
[ 143.813222] [] ? lockdep_init_map+0x142/0x154
[ 143.813288] [] usb_start_wait_urb+0x59/0xcf [usbcore]
[ 143.813362] [] usb_control_msg+0xc9/0xfb [usbcore]
[ 143.813453] [] set_port_feature+0x43/0x45 [usbcore]
[ 143.813524] [] usb_port_suspend+0x1b7/0x2a0 [usbcore]
[ 143.813594] [] ? trace_hardirqs_on+0xd/0xf
[ 143.813662] [] generic_suspend+0x21/0x27 [usbcore]
[ 143.813730] [] usb_suspend_both+0xf5/0x193 [usbcore]
[ 143.813799] [] usb_runtime_suspend+0x2a/0x58 [usbcore]
[ 143.813867] [] ? usb_probe_device+0x3b/0x3b [usbcore]
[ 143.813931] [] __rpm_callback+0x2f/0x56
[ 143.813998] [] rpm_callback+0x51/0x74
[ 143.814062] [] rpm_suspend+0x294/0x40a
[ 143.814120] [] ? _raw_spin_lock_irq+0x42/0x49
[ 143.814180] [] ? spin_lock_irq+0x9/0xb
[ 143.814237] [] pm_runtime_work+0x8c/0xac
[ 143.814295] [] process_one_work+0x23e/0x40a
[ 143.814353] [] ? process_one_work+0x171/0x40a
[ 143.814428] [] worker_thread+0x12f/0x1fd
[ 143.814488] [] ? process_scheduled_works+0x2a/0x2a
[ 143.814557] [] ? process_scheduled_works+0x2a/0x2a
[ 143.814618] [] kthread+0xb5/0xbd
[ 143.814673] [] ? __kthread_parkme+0x5c/0x5c
[ 143.814733] [] ret_from_fork+0x7c/0xb0
[ 143.814789] [] ? __kthread_parkme+0x5c/0x5c
--
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: Mass storage disconnects after few seconds of unuse
On mer., 2014-05-21 at 13:50 -0400, Alan Stern wrote: > On Wed, 21 May 2014, Mildred Ki'Lya wrote: > > > Hi, > > > > I have a problem with a USB device (4255:1000), running various kernels > > from 3.12.6 (Fedora) up to 2.14.4 (ArchLinux). When I connect the > > device, it appears all right. But after a few seconds of idle, it > > disconnects itself. ... > > It's possible that the device can't handle Link Power Management. > You can test this by writing 0 to the usb2_hardware_lpm file in the > device's sysfs power directory: > > echo 0 >/sys/bus/usb/device/1-6/power/usb2_hardware_lpm > Thank you for your answer. I didn't have the opportunity to test until today, and unfortunately I couldn't try this. There is no file usb2_hardware_lpm for that device. It's possible the device doesn't support this feature. Do you have an idea of what else could go wrong with this device? Here is the complete lsusb -v output for that device, it may help: Bus 003 Device 032: ID 4255:1000 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x4255 idProduct 0x1000 bcdDevice0.00 iManufacturer 1 Ambarella iProduct2 Storage iSerial 3 123456789ABC bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower4mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered Many thanks, Mildred -- 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: disable VBUS?
>> Can I disable VBUS while keeping the rest of USB functional for a >> device that does not require bus power? > > unfortunately not, your device would see a disconnection. The reason is > that even though you don't really put any load on the bus, the PHY still > samples VBUS levels to know when the session is valid (VBUS > 4.4V). What if I use a USB cable with a separate DC input for the VBUS? - Grant -- 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: Missing USB XHCI and EHCI reset for kexec
On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote: > The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP) > that causes the shutdown routine to reset the controller. It wasn't > meant for fixing kexec problems, but I bet you could use it for that > purpose. > > In addition, it's possible that a reset is needed in the probe pathway. Looking at the code a bit more ... that xhci_shutdown() worries me. It basically just whacks xhci_halt() and optionally reset() but nothing is done that I can see to ensure that we aren't concurrently doing things like queuing URBs, polling the root hub etc... That's definitely not clean and while it might work (most of the time at least) on actual shutdown it's definitely not right for kexec I reckon. Now there's a separate discussion that we had a while ago and might want to resume which is to say that kexec shouldn't be calling shutdown() anyway, but instead remove() on all drivers which is a much better code path for the purpose of leaving the device in a state where a driver can reconnect to it. However, in the case of XHCI that leads to another issue described here: http://marc.info/?l=linux-usb&m=139483181809062&w=2 For which there was little / no discussion at all... I suppose we could do a quirk but I don't think the problem is fundamentally specific to the TI chip, we should probably stop both root hubs before we halt both HCDs. Cheers, Ben. -- 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: disable VBUS?
On Sat, 7 Jun 2014, Grant wrote: > >> Can I disable VBUS while keeping the rest of USB functional for a > >> device that does not require bus power? > > > > unfortunately not, your device would see a disconnection. The reason is > > that even though you don't really put any load on the bus, the PHY still > > samples VBUS levels to know when the session is valid (VBUS > 4.4V). > > What if I use a USB cable with a separate DC input for the VBUS? What would be the point? I mean, if you've got a separate DC input for Vbus then you aren't really saving any power or disabling anything. If you did this and then turned off the separate DC power, your device wouldn't work afterward. As Felipe pointed out, the device would think the cable had been disconnected. 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: Missing USB XHCI and EHCI reset for kexec
On Sun, 8 Jun 2014, Benjamin Herrenschmidt wrote: > Looking at the code a bit more ... that xhci_shutdown() worries me. > > It basically just whacks xhci_halt() and optionally reset() but nothing > is done that I can see to ensure that we aren't concurrently > doing things like queuing URBs, polling the root hub etc... > > That's definitely not clean and while it might work (most of the time > at least) on actual shutdown it's definitely not right for kexec I > reckon. Yes, it really was meant for actual system shutdown. > Now there's a separate discussion that we had a while ago and might > want to resume which is to say that kexec shouldn't be calling > shutdown() anyway, but instead remove() on all drivers which is > a much better code path for the purpose of leaving the device in > a state where a driver can reconnect to it. > > However, in the case of XHCI that leads to another issue described > here: > > http://marc.info/?l=linux-usb&m=139483181809062&w=2 > > For which there was little / no discussion at all... I suppose we could > do a quirk but I don't think the problem is fundamentally > specific to the TI chip, we should probably stop both root hubs > before we halt both HCDs. The issue described in that email seems valid to me. Maybe the patch should be resubmitted. Now that xhci-hcd has changed maintainership, the discussion might move forward. In any case, you certainly can try testing with that patch installed. After all, xhci-hcd should work properly after a rmmod/modprobe sequence, and this is pretty much the same thing. 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: Mass storage disconnects after few seconds of unuse
On Sat, 7 Jun 2014, Mildred Ki'Lya wrote: > On mer., 2014-05-21 at 13:50 -0400, Alan Stern wrote: > > On Wed, 21 May 2014, Mildred Ki'Lya wrote: > > > > > Hi, > > > > > > I have a problem with a USB device (4255:1000), running various kernels > > > from 3.12.6 (Fedora) up to 2.14.4 (ArchLinux). When I connect the > > > device, it appears all right. But after a few seconds of idle, it > > > disconnects itself. > ... > > > > It's possible that the device can't handle Link Power Management. > > You can test this by writing 0 to the usb2_hardware_lpm file in the > > device's sysfs power directory: > > > > echo 0 >/sys/bus/usb/device/1-6/power/usb2_hardware_lpm > > > > Thank you for your answer. I didn't have the opportunity to test until > today, and unfortunately I couldn't try this. There is no file > usb2_hardware_lpm for that device. It's possible the device doesn't > support this feature. > > Do you have an idea of what else could go wrong with this device? No, I don't. It might just be buggy. 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
