Re: [PATCH] - silence UBSAN complaint in ehci-hcd.
On Thu, 19 May 2016 17:50:31 -0700, Greg Kroah-Hartman said:
> On Thu, May 19, 2016 at 05:19:00PM -0400, Valdis Kletnieks wrote:
> > UBSAN throws a complaint:
> >
> > [2.418579] UBSAN: Undefined behaviour in
> > drivers/usb/host/ehci-hub.c:877:47
> > [2.418582] index -1 is out of range for type 'u32 [1]'
> >
> > though it's only on the hostpc[] part, not on the port_status[] on the
> > previous line which has the same exact index calculation. The root cause is
> > that the first declaration is port_status[0], which uses a GCC extension and
> > UBSAN is smart enough to realize the programmer is doing something
> > intentionally odd.
> >
> > However, the problematic declaration is hostpc[1], which doesn't have
> > the "I know what I'm doing" semantics of [0]. Change the declaration to
> > match.
> >
> > Signed-Off-By: Valdis Kletnieks
> >
> > --- a/include/linux/usb/ehci_def.h 2015-01-06 01:04:24.342436706 -0500
> > +++ b/include/linux/usb/ehci_def.h 2016-05-19 13:57:20.869304540 -0400
> > @@ -180,11 +180,11 @@ struct ehci_regs {
> > * PORTSCx
> > */
> > /* HOSTPC: offset 0x84 */
> > - u32 hostpc[1]; /* HOSTPC extension */
> > + u32 hostpc[0]; /* HOSTPC extension */
> > #define HOSTPC_PHCD(1<<22) /* Phy clock disable */
> > #define HOSTPC_PSPD(3<<25) /* Port speed detection */
>
> Hm, this is odd, you really do want hostpc to be 1 u32 value, don't make
> it 0 please. If you walk off the end of hostpc, well, let's fix that
> properly.
Well, UBSAN doesn't complain about the *other* use of the same exact index,
apparently because 'u32 port_status[0]' tells it to shut up we know what we're
doing.
And I'm pretty sure that if hostpc was supposed to be exactly one u32 rather
than an array, it wouldn't have the [] semantics everyplace...
pgpElcphFdg3w.pgp
Description: PGP signature
[PATCH] - silence UBSAN complaint in ehci-hcd.
UBSAN throws a complaint:
[2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47
[2.418582] index -1 is out of range for type 'u32 [1]'
though it's only on the hostpc[] part, not on the port_status[] on the
previous line which has the same exact index calculation. The root cause is
that the first declaration is port_status[0], which uses a GCC extension and
UBSAN is smart enough to realize the programmer is doing something
intentionally odd.
However, the problematic declaration is hostpc[1], which doesn't have
the "I know what I'm doing" semantics of [0]. Change the declaration to match.
Signed-Off-By: Valdis Kletnieks
--- a/include/linux/usb/ehci_def.h 2015-01-06 01:04:24.342436706 -0500
+++ b/include/linux/usb/ehci_def.h 2016-05-19 13:57:20.869304540 -0400
@@ -180,11 +180,11 @@ struct ehci_regs {
* PORTSCx
*/
/* HOSTPC: offset 0x84 */
- u32 hostpc[1]; /* HOSTPC extension */
+ u32 hostpc[0]; /* HOSTPC extension */
#define HOSTPC_PHCD(1<<22) /* Phy clock disable */
#define HOSTPC_PSPD(3<<25) /* Port speed detection */
- u32 reserved5[16];
+ u32 reserved5[17];
/* USBMODE_EX: offset 0xc8 */
u32 usbmode_ex; /* USB Device mode extension */
--
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
UBSAN whinge in ihci-hub.c
So, not content in the amount of breakage I generate already, I compiled with UBSAN enabled... The immediately relevant part: [2.418576] [2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47 [2.418582] index -1 is out of range for type 'u32 [1]' The code there: 875 u32 __iomem *status_reg = &ehci->regs->port_status[ 876 (wIndex & 0xff) - 1]; 877 u32 __iomem *hostpc_reg = &ehci->regs->hostpc[(wIndex & 0xff) - 1]; 878 u32 temp, temp1, status; I'm guessing that the only reason that port_status[] didn't throw an error because that's declared as 'u32 port_status[0]' with a 'u32 reserved3[9]' behind it, while it's 'u32 hostpc[1]'. So we have (possibly) 2 bugs: 1) hostpc should possibly be a 'u32 hostpc[0]' I'd attach a patch, except I'm low on caffeine and unsure if the 'u32 reserved5[16]' that follows needs to be a [17] to compensate. Either that, or port_status[] and hostpc[] should *both* be explicitly sized so range-checking works better. 2) We need to figure out who passed a 0 wIndex down the stack, resulting in the busted indexing... The entire splat: [2.418567] hub 1-0:1.0: USB hub found [2.418576] [2.418579] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47 [2.418582] index -1 is out of range for type 'u32 [1]' [2.418587] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.6.0-next-20160517-1-gede618fce89c-dirty #279 [2.418590] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A17 08/19/2015 [2.418599] ac1ab326 88022ca232e8 aa690aea [2.418605] 88022ca23300 ac1ab326 88022ca23310 [2.418613] 88022ca23300 aa7087ad abd5aee0 88022ca23358 [2.418615] Call Trace: [2.418628] [] dump_stack+0x7b/0xd1 [2.418633] [] ubsan_epilogue+0xd/0x40 [2.418639] [] __ubsan_handle_out_of_bounds+0x75/0xa0 [2.418644] [] ? syscall_slow_exit_work+0x1ed/0x310 [2.418649] [] ? usb_hcd_submit_urb+0x368/0xe00 [2.418655] [] ehci_hub_control+0xd9c/0xdc0 [2.418662] [] usb_hcd_submit_urb+0x8b1/0xe00 [2.418667] [] usb_submit_urb+0x2e1/0x8f0 [2.418672] [] ? __init_waitqueue_head+0x52/0xa0 [2.418677] [] usb_start_wait_urb+0x7d/0x130 [2.418682] [] usb_control_msg+0xdc/0x120 [2.418691] [] hub_probe+0x4e9/0x1110 [2.418696] [] ? _raw_spin_unlock_irqrestore+0x87/0x90 [2.418701] [] ? preempt_count_sub+0x4a/0x90 [2.418706] [] ? _raw_spin_unlock_irqrestore+0x74/0x90 [2.418711] [] usb_probe_interface+0x139/0x3e0 [2.418717] [] driver_probe_device+0x131/0x3c0 [2.418723] [] __device_attach_driver+0xc3/0x180 [2.418728] [] ? __driver_attach+0x100/0x100 [2.418732] [] bus_for_each_drv+0x8d/0x100 [2.418737] [] __device_attach+0xe8/0x170 [2.418742] [] device_initial_probe+0x13/0x20 [2.418746] [] bus_probe_device+0xe7/0x150 [2.418750] [] device_add+0x49b/0x690 [2.418756] [] usb_set_configuration+0x5bb/0xc80 [2.418762] [] generic_probe+0x36/0xa0 [2.418766] [] usb_probe_device+0x3b/0x80 [2.418770] [] driver_probe_device+0x131/0x3c0 [2.418775] [] __device_attach_driver+0xc3/0x180 [2.418779] [] ? __driver_attach+0x100/0x100 [2.418783] [] bus_for_each_drv+0x8d/0x100 [2.418788] [] __device_attach+0xe8/0x170 [2.418793] [] device_initial_probe+0x13/0x20 [2.418797] [] bus_probe_device+0xe7/0x150 [2.418801] [] device_add+0x49b/0x690 [2.418807] [] usb_new_device+0x319/0x970 [2.418812] [] usb_add_hcd+0x67b/0xa40 [2.418817] [] usb_hcd_pci_probe+0x4c3/0x770 [2.418822] [] ? trace_hardirqs_on_caller+0x16/0x2c0 [2.418827] [] ? preempt_count_sub+0x4a/0x90 [2.418832] [] ehci_pci_probe+0x36/0x40 [2.418837] [] pci_device_probe+0xdc/0x180 [2.418842] [] driver_probe_device+0x131/0x3c0 [2.418846] [] __driver_attach+0xb9/0x100 [2.418851] [] ? driver_probe_device+0x3c0/0x3c0 [2.418855] [] bus_for_each_dev+0x8a/0xf0 [2.418860] [] driver_attach+0x27/0x50 [2.418864] [] bus_add_driver+0x116/0x2b0 [2.418868] [] driver_register+0x9f/0x160 [2.418873] [] __pci_register_driver+0x8f/0xe0 [2.418879] [] ? ehci_hcd_init+0x90/0x90 [2.418885] [] ehci_pci_init+0x65/0x67 [2.418890] [] do_one_initcall+0x5f/0x210 [2.418896] [] kernel_init_freeable+0x33d/0x3d4 [2.418903] [] kernel_init+0xf/0x120 [2.418907] [] ret_from_fork+0x1f/0x40 [2.418911] [] ? rest_init+0x170/0x170 [2.418915] [2.418934] hub 1-0:1.0: 2 ports detected [2.419850] ehci-pci :00:1d.0: EHCI Host Controller [2.41999
Re: Kernel Debugging Support
On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said: > Ah, you didn't read far enough down the page :) I'm willing to bet a large pizza with everything but anchovies that out in the real world, a lot of implementors didn't read further either. :) > So I have to believe there are a *lot* of systems out there that do support > xHCI debug. Possibly. But enough to make an actual critical mass to motivate somebody to write code? Or do you get more bang-for-buck by fixing kgdb to support debugging over Ethernet? pgpuOmP4vfTn8.pgp Description: PGP signature
Re: Kernel Debugging Support
On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said: > Are you sure about that? Last I heard, xHCI debug support was a logo > requirement from Microsoft for Windows 8 and above, so I would have > thought that most vendors would have implemented it by now. There's a lot of gear out in the real world that was manufactured before Windows 8 was released. And the actual requirement, as listed at: http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256 doesn't actually require USB debug -it requires a debug port, and xHCI is below ethernet on the preference list. As it says: --- The next version of Windows will support several different debug transports. They are listed below in the preferred order of implementation. Hardware Debugging Transports Ethernet Network Interface Card from the supported list: http://msdn.microsoft.com/en-us/library/windows/hardware/hh830880 USB 3.0 - xHCI controller compliant to xHCI debug specification. 1394 OHCI compliant Firewire controllers. USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead). USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy Serial (16550 compatible programming interface). ADDITIONAL REQUIREMENTSFOR ALL OF THE ABOVE IMPLEMENTATIONS THE FOLLOWING MUST APPLY: There must be at least one user accessible debug port on the machine. It is acceptable on systems which choose to not expose a USB port or any other acceptable port from the list above to instead require a separate debugging board or device that provides the ability to debug via one (or more) of the transports above. That device/board must terminate in the same standard port as would be used for the transport if it were \u2018onboard\u2019 the machine. If this device is required it must be documented in the system specifications, be user serviceable, be user installable on the machine, and available for sale from the machine\u2019s vendor. pgp1GeZsoThIw.pgp Description: PGP signature
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, 05 Jun 2014 12:05:56 -0700, Dan Williams said: > Subject: usb: fix ->update_hub_device() vs hdev->maxchild > > From: Dan Williams > > Commit d8521afe3586 "usb: assign default peer ports for root hubs" > delayed marking a hub valid (set hdev->maxchild) until it had been fully > configured and to enable the publishing of valid hubs to be serialized > by usb_port_peer_mutex. > > However, xhci_update_hub_device() in some cases depends on > hdev->maxchild already being set. Do the minimal fix and move it after > the setting of hdev->maxchild. > > Cc: Mathias Nyman > Reported-by: Valdis Kletnieks > Signed-off-by: Dan Williams Applied cleanly, booted without complaint, the keyboard that's behind the PS2-USB converter works. uname -r reports 3.15.0-rc8-next-20140605-dirty as expected. So feel free to stick a Tested-By: on there. :) pgpHluJIkfaj6.pgp Description: PGP signature
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said: > Actually, on second look I bet xhci_alloc_tt_info() is being called > while hdev->maxchild is not set. Let me throw together a debug > patch... Sure, no problem - just let me know what variant of linux-next you want it applied against. :) pgp9PIoAPZAjs.pgp Description: PGP signature
Re: linux-next crash in xhci_add_ep_to_interval
On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:
> > On a working boot, it progresses:
>
> Is a working boot after reverting that change, or it intermittently
> works? If it's the latter I'm not sure I trust the bisect result,
> yet.
Oh, it's a 100% guaranteed crash. The following is from a good kernel:
> > [3.823139] usb 3-4.1: New USB device found, idVendor=0e8f,
> > idProduct=0020
> > [3.823160] usb 3-4.1: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [3.823174] usb 3-4.1: Product: PS2toUSB Adapter
> > [3.823187] usb 3-4.1: Manufacturer: GASIA
> > [3.842836] input: GASIA PS2toUSB Adapter as
> > /devices/pci:00/:00:14.0/usb3/3-4/3-4.1/3-4.1:1.0/0003:0E8F:0020.0001/input/input14
> > [3.848598] hid-generic 0003:0E8F:0020.0001: input,hidraw0: USB HID
> > v1.10 Keyboard [GASIA PS2toUSB Adapter] on usb-:00:14.0-4.1/input0
> > [3.863592] input: GASIA PS2toUSB Adapter as
> > /devices/pci:00/:00:14.0/usb3/3-4/3-4.1/3-4.1:1.1/0003:0E8F:0020.0002/input/input15
> > [3.878608] hid-generic 0003:0E8F:0020.0002: input,hidraw1: USB HID
> > v1.10 Mouse [GASIA PS2toUSB Adapter] on usb-:00:14.0-4.1/input1
I'm booted on next-20140519
> It's a really odd place to crash relative to the peer port changes
> since those do not affect any xhci internals. At first glance this
> also does not look related to the command queue changes. Mathias, any
> ideas?
>
> Valdis, can you get me the output of:
>
> $ gdb drivers/usb/host/xhci-hcd.ko
> (gdb) li *(xhci_add_ep_to_interval_table+0xc8)
(gdb) li *(xhci_add_ep_to_interval_table+0xc8)
0x10c9 is in xhci_add_ep_to_interval_table (drivers/usb/host/xhci.c:2446).
2441normalized_interval = ep_bw->ep_interval - 3;
2442
2443if (normalized_interval == 0)
2444bw_table->interval0_esit_payload +=
ep_bw->max_esit_payload;
2445interval_bw = &bw_table->interval_bw[normalized_interval];
2446interval_bw->num_packets += ep_bw->num_packets;
2447switch (udev->speed) {
2448case USB_SPEED_LOW:
2449interval_bw->overhead[LS_OVERHEAD_TYPE] += 1;
2450break;
Note that's as of the end of the git bisect. Looks like it picked up
a duff value for interval_bw somehow, but I have no idea why.
Yeah, you're right, the bisected commit doesn't seem to have anything
to do with it. Weird. ;)
pgpFUydoULgmQ.pgp
Description: PGP signature
linux-next crash in xhci_add_ep_to_interval
Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval when it's docked in a newer dock that has USB3. It's very possible that the BIOS is buggy - it isn't like I haven't found BIOS bugs in every single Dell laptop I've had. :) But that shouldn't make the kernel crash lsusb reports: Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor Bus 002 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 413c:5534 Dell Computer Corp. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter Bus 003 Device 002: ID 413c:2134 Dell Computer Corp. Bus 003 Device 004: ID 045e:0023 Microsoft Corp. Trackball Optical Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Git bisect comes down to this: commit d8521afe35862f4fbe3ccd6ca37897c0a304edf3 Author: Dan Williams Date: Tue May 20 18:08:28 2014 -0700 usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. Thanks to pstore, we have the explosion: [3.974159] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020 [3.974173] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.974247] usb 3-4.1: Product: PS2toUSB Adapter [3.974259] usb 3-4.1: Manufacturer: GASIA [3.975475] BUG: unable to handle kernel NULL pointer dereference at 0080 [3.975643] IP: [] xhci_add_ep_to_interval_table+0xc8/0x172 [3.975795] PGD 0 [3.975849] Oops: 0002 [#1] PREEMPT SMP [3.975954] Modules linked in: [3.976029] CPU: 0 PID: 37 Comm: khubd Not tainted 3.15.0-rc5-00299-g7e73be2 #234 [3.976169] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013 [3.976304] task: 880128e809d0 ti: 880128e84000 task.ti: 880128e84000 [3.976441] RIP: 0010:[] [] xhci_add_ep_to_interval_table+0xc8/0x172 [3.976631] RSP: 0018:880128e85608 EFLAGS: 00010006 [3.976732] RAX: 0003 RBX: RCX: 8800c5861800 [3.976863] RDX: 0001 RSI: 0078 RDI: 0005 [3.976997] RBP: 880128e85640 R08: 8801288f2228 R09: [3.977125] R10: 880128e85968 R11: 0004 R12: 8801288f22fc [3.977255] R13: 8800c5861800 R14: 88003f878000 R15: 0007 [3.977353] FS: () GS:88012dc0() knlGS: [3.977440] CS: 0010 DS: ES: CR0: 80050033 [3.977503] CR2: 0080 CR3: c5eb4000 CR4: 001407f0 [3.977578] Stack: [3.977606] 8801288f2228 8801288f2000 8801288f22fc [3.977708] 88003f878000 8800c5d8b000 0003 880128e85990 [3.977808] 8139c76d 880128e85700 880128e85680 00010007 [3.977910] Call Trace: [3.977948] [] xhci_reserve_bandwidth+0x158/0x534 [3.978022] [] ? mark_held_locks+0x5d/0x74 [3.978086] [] ? mark_lock+0x2a/0x203 [3.978148] [] ? __lock_acquire+0x696/0xedf [3.978215] [] ? dma_pool_alloc+0x188/0x225 [3.978281] [] ? mark_lock+0x2a/0x203 [3.980065] [] ? mark_lock+0x2a/0x203 [3.981976] [] ? mark_held_locks+0x5d/0x74 [3.984302] [] ? mark_lock+0x2a/0x203 [3.986919] [] ? __lock_acquire+0x696/0xedf [3.989317] [] ? xhci_configure_endpoint+0x3b/0x4b0 [3.991817] [] ? mark_lock+0x2a/0x203 [3.994396] [] ? mark_held_locks+0x5d/0x74 [3.996896] [] ? lock_acquire+0xc1/0x14e [3.998795] [] ? xhci_configure_endpoint+0x3b/0x4b0 [4.000407] [] ? xhci_dbg_trace+0x3f/0x47 [4.002724] [] xhci_configure_endpoint+0x13f/0x4b0 [4.005076] [] xhci_check_bandwidth+0x11e/0x231 [4.007457] [] usb_hcd_alloc_bandwidth+0x21d/0x2bd [4.009787] [] usb_set_configuration+0x282/0x6f9 [4.012008] [] ? usb_hub_to_struct_hub+0x30/0x32 [4.014085] [] generic_probe+0x40/0x72 [4.015894] [] usb_probe_device+0x28/0x3b [4.017332] [] driver_probe_device+0xda/0x202 [4.019226] [] ? driver_probe_device+0x202/0x202 [4.021241] [] __device_attach+0x25/0x38 [4.023357] [] bus_for_each_drv+0x80/0x85 [4.025480] [] device_attach+0x66/0x87 [4.027587] [] bus_probe_device+0
next-20140529 - BUG: sleeping function called from invalid context at mm/slab.c:2946
This seems to be a repeateable BUG in next-20140529 (have hit it in
2 boots out of 2). Seeing it on a Dell Latitude E6530 while it's
enumerating the internal USB hubs. Whatever trips it, it's new since
next-20140519.
% lsusb
Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications
Processor with fingerprint swipe sensor
Bus 002 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port
Replicator
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 413c:5534 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter
Bus 003 Device 003: ID 413c:2134 Dell Computer Corp.
Bus 003 Device 002: ID 045e:0023 Microsoft Corp. Trackball Optical
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Anybody recognize this, before I go off to bisect land?
[3.717306] usb 3-4: New USB device found, idVendor=413c, idProduct=2134
[3.717316] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[3.717322] usb 3-4: Product: USB2134
[3.717327] usb 3-4: Manufacturer: SMSC
[3.718174] hub 3-4:1.0: USB hub found
[3.718217] hub 3-4:1.0: 3 ports detected
[3.720133] BUG: sleeping function called from invalid context at
mm/slab.c:2946
[3.720235] in_atomic(): 1, irqs_disabled(): 1, pid: 39, name: kworker/2:1
[3.720308] 3 locks held by kworker/2:1/39:
[3.720311] #0: ("pm"){.+.+.+}, at: []
process_one_work+0x1fa/0x4be
[3.720330] #1: ((&dev->power.work)){+.+.+.}, at: []
process_one_work+0x1fa/0x4be
[3.720346] #2: (&(&xhci->lock)->rlock){-.-...}, at: []
xhci_stop_device.constprop.7+0x61/0x14a
[3.720363] irq event stamp: 7490
[3.720366] hardirqs last enabled at (7489): []
debug_check_no_locks_freed+0x123/0x131
[3.720374] hardirqs last disabled at (7490): []
_raw_spin_lock_irqsave+0x17/0x4e
[3.720382] softirqs last enabled at (7426): []
__do_softirq+0x2ab/0x403
[3.720388] softirqs last disabled at (7413): []
irq_exit+0x4c/0xbb
[3.720396] CPU: 2 PID: 39 Comm: kworker/2:1 Not tainted
3.15.0-rc7-next-20140526-dirty #215
[3.720400] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11
03/12/2013
[3.720406] ^AdWorkqueue: pm pm_runtime_work
[3.720411] 880128edb768 8167d3af
0027
[3.720423] 880128ee0a50 880128edb790 81065fe4
8010
[3.720435] 88012d000280 88012d000280 880128edb7a0
8112fe1e
[3.720446] Call Trace:
[3.720453] [] dump_stack+0x51/0xaa
[3.720462] [] __might_sleep+0x1b7/0x1be
[3.720470] []
cache_alloc_debugcheck_before.isra.45+0x1d/0x1f
[3.720477] [] __kmalloc+0x62/0x10d
[3.720485] [] ? kzalloc+0xf/0x11
[3.720492] [] kzalloc+0xf/0x11
[3.720499] [] xhci_alloc_command+0x25/0xac
[3.720506] [] xhci_stop_device.constprop.7+0x86/0x14a
[3.720513] [] xhci_hub_control+0x9ca/0xdb6
[3.720521] [] ? trace_hardirqs_on_caller+0x18f/0x1ab
[3.720529] [] usb_hcd_submit_urb+0x598/0x7cf
[3.720536] [] ? mark_held_locks+0x5d/0x74
[3.720543] [] ? debug_check_no_locks_freed+0x123/0x131
[3.720550] [] ? trace_hardirqs_on_caller+0x18f/0x1ab
[3.720556] [] ? trace_hardirqs_on+0xd/0xf
[3.720563] [] usb_submit_urb+0x448/0x481
[3.720570] [] usb_start_wait_urb+0x72/0x119
[3.720577] [] usb_control_msg+0xcd/0xf2
[3.720585] [] ? __mutex_unlock_slowpath+0x19d/0x1af
[3.720592] [] set_port_feature+0x30/0x32
[3.720599] [] usb_port_suspend+0x167/0x24a
[3.720605] [] generic_suspend+0x21/0x27
[3.720612] [] usb_suspend_both+0xe9/0x190
[3.720619] [] usb_runtime_suspend+0x2e/0x69
[3.720626] [] ? usb_probe_interface+0x1db/0x1db
[3.720633] [] __rpm_callback+0x34/0x5b
[3.720640] [] rpm_callback+0x6f/0x85
[3.720646] [] rpm_suspend+0x26e/0x405
[3.720654] [] ? do_raw_spin_lock+0xdf/0x19f
[3.720661] [] __pm_runtime_suspend+0x56/0x80
[3.720668] [] ? usb_runtime_resume+0x17/0x17
[3.720674] [] usb_runtime_idle+0x25/0x2d
[3.720681] [] __rpm_callback+0x34/0x5b
[3.720687] [] rpm_idle+0x17d/0x22e
[3.720695] [] pm_runtime_work+0x59/0x8f
[3.720702] [] process_one_work+0x29c/0x4be
[3.720710] [] worker_thread+0x40d/0x561
[3.720717] [] ? cancel_delayed_work+0xb7/0xb7
[3.720724] [] kthread+0xd6/0xde
[3.720732] [] ? __kthread_parkme+0x62/0x62
[3.720738] [] ret_from_fork+0x7c/0xb0
[3.720745] [] ? __kthread_parkme+0x62/0x62
[3.782223] usb 2-1.7: new high-speed USB device number 3 using ehci-pci
[3.856396] systemd-udevd[238]: starting version 212
[3.867694] usb 2-1.7: New USB device found, idVen
Re: Wonky PS2-USB converter issues...
On Wed, 20 Feb 2013 16:07:49 -0800, Greg Kroah-Hartman said: > PS-2 connectors can not normally handle hotplugging, the protocol > doesn't allow it, and for some unlucky devices, it could actually fry > the motherboard or the PS-2 device. > > So that's probably the issue here, the device just doesn't support it, > sorry. You mis-understood the problem. This works: PS/2 keyboard plugged into this device: Bus 006 Device 002: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter USB side of device plugged into USB port on the Latitude laptop. Power up, boot - the keyboard works. If you plug the USB side of the GreenAsia adapter into a USB slot on the dock, the keyboard is dead and not recognized by the system. However, replugging the USB, or unplug/plug the PS/2 side, and it becomes recognized and starts working. This tells me that the dock is doing something busted with USB that the laptop does correctly, and not enumerating devices until something happens to whack it upside the head. I was hoping to identify it and maybe quirk it. pgpz8SBNr_8yy.pgp Description: PGP signature
Wonky PS2-USB converter issues...
Quite some time ago, I posted about a problematic PS2-USB converter that I used to connect an old PS2-connector keyboard to my laptop dock, where the keyboard wouldn't be recognized at boot unless I unplugged and reconnected it. Well, I've recently figured out (partly by obtaining a converter from a different vendor) that the converters both work correctly when plugged into a USB port that's physically on my Dell Latitude laptop - but they have issues and require a reconnect cycle when plugged into the docking station for the laptop. (It took a long time to figure this out, because *of course* you plug this sort of stuff into the docking station specifically so you don't have to plug it in every morning). So obviously, it isn't the converter that is the problem, but the docking station is doing "something stupid". Anybody have suggestions on figuring out what it's doing wrong? pgptVuWKDGiDg.pgp Description: PGP signature
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sun, 10 Feb 2008 05:50:17 +0100, Marcel Holtmann said: > go ahead and create an application that uses a GPL only library. Then > ask a lawyer if it is okay to distribute your application in binary only > form without making the source code available (according to the GPL). > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL What happens if I ship a binary-only program that uses *either* a GPL library or a custom library with the same API? "If you don't have the Frobozz-Foo library, you'll have to supply your own work-alike" (Note that this is in fact the *usual* case - very few programs actually check that they are linking against a Genuine GPL(tm) library, they just want the *API*, so providing a work-alike is sufficient) pgp3nFcTnLkY9.pgp Description: PGP signature
Re: [PATCH] USB: mark USB drivers as being GPL only
On Fri, 08 Feb 2008 10:15:01 +0100, Marcel Holtmann said: > And while you are talking to a lawyer. Ask him/her if it is okay to > create a binary only application that uses a GPL library. Tell him/her It's perfectly legal to create such an application. It only gets interesting if you *distribute* it... (And yes, this is where you *have* to be pedantic about the wording used)... pgpq2qJTXM6Sl.pgp Description: PGP signature
Re: [PATCH] USB: mark USB drivers as being GPL only
On Wed, 06 Feb 2008 22:12:54 +0100, Christer Weinigel said: > If I use an in kernel API, but from a piece of code which is external > to the kernel, is that really a derived work? If you say it is, do you > realise that you are advocating something which is very close to an API > copyright, something which I think most open source people are very > adverse to. And in fact, at least in the US, current case law states that when there's only one practical way to write something (which is the case in an API, you either code it the way the API says or you don't get a correctly functioning program), it's not copyrightable. See "scenes a faire" in http://www.copyright-laws.com/pgs/protect-rights.html pgpqmjWVSPPWt.pgp Description: PGP signature
