Re: [PATCH] usb: gadget: Don't allocate zero-length buffers
Hi Greg, W dniu 20.03.2019 o 15:25, Greg KH pisze: On Wed, Mar 20, 2019 at 01:56:41PM +0100, Andrzej Pietrasiewicz wrote: Don't actually allocate anything if userspace enqueues a zero-length buffer. Otherwise vmalloc of zero-sized area will be attempted in ffs_build_sg_list(). Are you sure this is ok? zero length packets mean something in the USB protocol :) Yeah, I do know they do! What is the problem of trying to allocate a buffer of 0 bytes? My understanding is that if a zero-length buffer is enqueued, then nobody will read from it (the read will be zero bytes, to be precise), so returning ZERO_SIZE_PTR shouldn't hurt. On the other hand, if scatter-gather mode is used (depends on what the underlying UDC declares) then ffs_alloc_buffer() takes the ffs_build_sg_list() branch and then vmalloc does the below: [ 23.637611] some-process: vmalloc: allocation failure: 0 bytes, mode:0x6000c0(GFP_KERNEL), nodemask= (null) [ 23.642435] CPU: 3 PID: 307 Comm: some-process Not tainted 5.0.0-00048-g762eb03d5d27-dirty #151 [ 23.650903] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 23.656983] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 23.664705] [] (show_stack) from [] (dump_stack+0x98/0xc4) [ 23.671906] [] (dump_stack) from [] (warn_alloc+0xd0/0x168) [ 23.679111] [] (warn_alloc) from [] (__vmalloc_node_range+0x230/0x25c) [ 23.687350] [] (__vmalloc_node_range) from [] (__vmalloc_node.constprop.12+0x48/0x 50) [ 23.696904] [] (__vmalloc_node.constprop.12) from [] (vmalloc+0x2c/0x34) [ 23.705328] [] (vmalloc) from [] (ffs_epfile_io+0x4ac/0x750) [ 23.712693] [] (ffs_epfile_io) from [] (ffs_epfile_write_iter+0xb4/0x168) [ 23.721209] [] (ffs_epfile_write_iter) from [] (__vfs_write+0x118/0x17c) [ 23.729623] [] (__vfs_write) from [] (vfs_write+0xa4/0x184) [ 23.736914] [] (vfs_write) from [] (ksys_write+0x4c/0xac) [ 23.744025] [] (ksys_write) from [] (ret_fast_syscall+0x0/0x28) [ 23.751664] Exception stack(0xec8e1fa8 to 0xec8e1ff0) [ 23.756686] 1fa0: b6b02cc0 0004 b57fed53 0004 [ 23.764861] 1fc0: b6b02cc0 0004 b6b02cc0 [ 23.773019] 1fe0: b57fed40 b6de73d0 [ 23.779588] Mem-Info: [ 23.780342] active_anon:1530 inactive_anon:4412 isolated_anon:0 [ 23.780342] active_file:3680 inactive_file:3342 isolated_file:0 [ 23.780342] unevictable:0 dirty:18 writeback:0 unstable:0 [ 23.780342] slab_reclaimable:4245 slab_unreclaimable:4430 [ 23.780342] mapped:2496 shmem:4427 pagetables:79 bounce:0 [ 23.780342] free:478387 free_pcp:1242 free_cma:24244 [ 23.813879] Node 0 active_anon:6120kB inactive_anon:17648kB active_file:14720kB inactive_file:13368kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:9984kB dirty:72kB writeback:0kB shmem:17708k B writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 23.836882] Normal free:696520kB min:3452kB low:4312kB high:5172kB active_anon:0kB inactive_anon:0kB a ctive_file:7576kB inactive_file:1028kB unevictable:0kB writepending:52kB present:786432kB managed:746456k B mlocked:0kB kernel_stack:824kB pagetables:0kB bounce:0kB free_pcp:2624kB local_pcp:508kB free_cma:0kB [ 23.864320] lowmem_reserve[]: 0 9112 9112 [ 23.868056] HighMem free:1217028kB min:512kB low:1860kB high:3208kB active_anon:6120kB inactive_anon:1 7648kB active_file:7144kB inactive_file:12340kB unevictable:0kB writepending:20kB present:1264640kB manag ed:1264640kB mlocked:0kB kernel_stack:0kB pagetables:316kB bounce:0kB free_pcp:2336kB local_pcp:800kB fre e_cma:96976kB [ 23.896900] lowmem_reserve[]: 0 0 0 [ 23.900161] Normal: 2*4kB (UM) 23*8kB (UME) 9*16kB (UM) 0*32kB 1*64kB (M) 2*128kB (UM) 2*256kB (ME) 2* 512kB (UE) 0*1024kB 5*2048kB (UME) 167*4096kB (M) = 696464kB [ 23.914775] HighMem: 1*4kB (U) 0*8kB 2*16kB (UC) 1*32kB (U) 1*64kB (C) 3*128kB (UMC) 0*256kB 2*512kB ( UC) 1*1024kB (M) 3*2048kB (UMC) 295*4096kB (MC) = 1217028kB [ 23.929179] 11488 total pagecache pages [ 23.932933] 0 pages in swap cache [ 23.936179] Swap cache stats: add 0, delete 0, find 0/0 [ 23.941439] Free swap = 0kB [ 23.944246] Total swap = 0kB [ 23.947112] 512768 pages RAM [ 23.949974] 316160 pages HighMem/MovableOnly [ 23.954282] 9994 pages reserved [ 23.957357] 24576 pages cma reserved
[PATCH] usb: gadget: functions: add ftrace export over USB
Allow for ftrace data to be exported over a USB Gadget
Controller. With this, we have a potentially very fast pipe for
transmitting ftrace data to a Host PC for further analysis.
Note that in order to decode the data, one needs access to kernel
symbols in order to convert binary data into function names and what
not.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/Kconfig| 15 +
drivers/usb/gadget/function/Makefile | 2 +
drivers/usb/gadget/function/f-trace.c | 401 ++
3 files changed, 418 insertions(+)
create mode 100644 drivers/usb/gadget/function/f-trace.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 31cce7805eb2..dfd181e0d717 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -191,6 +191,9 @@ config USB_F_MASS_STORAGE
config USB_F_FS
tristate
+config USB_F_TRACE
+ tristate
+
config USB_F_UAC1
tristate
@@ -368,6 +371,18 @@ config USB_CONFIGFS_F_FS
implemented in kernel space (for instance Ethernet, serial or
mass storage) and other are implemented in user space.
+config USB_CONFIGFS_F_TRACE
+ bool "Linux FTrace Export Over USB"
+ depends on USB_CONFIGFS
+ select USB_F_TRACE
+ help
+ The Linux FTrace Export Over USB lets one export ftrace buffer
+ over a USB cable to a host computer for further processing.
+
+ If you want support for that, say Y or M here. Otherwise say N.
+
+ If unsure, say N.
+
config USB_CONFIGFS_F_UAC1
bool "Audio Class 1.0"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/function/Makefile
b/drivers/usb/gadget/function/Makefile
index 5d3a6cf02218..eb851309006c 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -50,3 +50,5 @@ usb_f_printer-y := f_printer.o
obj-$(CONFIG_USB_F_PRINTER)+= usb_f_printer.o
usb_f_tcm-y:= f_tcm.o
obj-$(CONFIG_USB_F_TCM)+= usb_f_tcm.o
+usb_f_trace-y := f-trace.o
+obj-$(CONFIG_USB_F_TRACE) += usb_f_trace.o
diff --git a/drivers/usb/gadget/function/f-trace.c
b/drivers/usb/gadget/function/f-trace.c
new file mode 100644
index ..b5941df128a0
--- /dev/null
+++ b/drivers/usb/gadget/function/f-trace.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * f_trace.c -- USB FTrace Export
+ *
+ * Copyright (C) 2019 Intel Corporation
+ * Author: Felipe Balbi
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License v2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct usb_ftrace {
+ struct trace_export ftrace;
+ struct usb_function function;
+ struct work_struct queue_work;
+ spinlock_t lock;
+
+ struct list_head list;
+ struct list_head pending;
+ struct list_head queued;
+
+ struct usb_ep *in;
+
+ u8 intf_id;
+};
+#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
+#define work_to_trace(w) (container_of((w), struct usb_ftrace,
queue_work))
+#define to_trace(f)(container_of((f), struct usb_ftrace, function))
+
+#define FTRACE_REQUEST_QUEUE_LENGTH250
+
+static inline struct usb_request *next_request(struct list_head *list)
+{
+ return list_first_entry_or_null(list, struct usb_request, list);
+}
+
+struct usb_ftrace_opts {
+ struct usb_function_instance func_inst;
+};
+#define to_opts(fi)(container_of((fi), struct usb_ftrace_opts, func_inst))
+
+static struct usb_interface_descriptor ftrace_intf_desc = {
+ .bLength= USB_DT_INTERFACE_SIZE,
+ .bDescriptorType= USB_DT_INTERFACE,
+
+ .bAlternateSetting = 0,
+ .bNumEndpoints = 1,
+ .bInterfaceClass= USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = USB_SUBCLASS_VENDOR_SPEC,
+};
+
+/* Super-Speed Support */
+static struct usb_endpoint_descriptor ftrace_ss_in_desc = {
+ .bLength= USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType= USB_DT_ENDPOINT,
+
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = cpu_to_le16(1024),
+};
+
+static struct usb_ss_ep_comp_descriptor ftrace_ss_in_comp_desc = {
+ .bLength= USB_DT_SS_EP_COMP_SIZE,
+ .bDescriptorType= USB_DT_SS_ENDPOINT_COMP,
+
+ .bMaxBurst = 15,
+};
+
+static struct usb_descriptor_header *ftrace_ss_function[] = {
+ (struct usb_descriptor_header *) &ftrace_intf_desc,
+ (struct usb_descriptor_header *) &ftrace_ss_in_desc,
+ (struct usb_descriptor_header *) &ftrace_ss_in_comp_desc,
+ NULL,
+};
+
+/* High-Spee
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
Felipe Balbi writes:
> Allow for ftrace data to be exported over a USB Gadget
> Controller. With this, we have a potentially very fast pipe for
> transmitting ftrace data to a Host PC for further analysis.
>
> Note that in order to decode the data, one needs access to kernel
> symbols in order to convert binary data into function names and what
> not.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/Kconfig| 15 +
> drivers/usb/gadget/function/Makefile | 2 +
> drivers/usb/gadget/function/f-trace.c | 401 ++
> 3 files changed, 418 insertions(+)
> create mode 100644 drivers/usb/gadget/function/f-trace.c
>
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index 31cce7805eb2..dfd181e0d717 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -191,6 +191,9 @@ config USB_F_MASS_STORAGE
> config USB_F_FS
> tristate
>
> +config USB_F_TRACE
> + tristate
> +
> config USB_F_UAC1
> tristate
>
> @@ -368,6 +371,18 @@ config USB_CONFIGFS_F_FS
> implemented in kernel space (for instance Ethernet, serial or
> mass storage) and other are implemented in user space.
>
> +config USB_CONFIGFS_F_TRACE
> + bool "Linux FTrace Export Over USB"
> + depends on USB_CONFIGFS
> + select USB_F_TRACE
> + help
> + The Linux FTrace Export Over USB lets one export ftrace buffer
> + over a USB cable to a host computer for further processing.
> +
> + If you want support for that, say Y or M here. Otherwise say N.
> +
> + If unsure, say N.
> +
> config USB_CONFIGFS_F_UAC1
> bool "Audio Class 1.0"
> depends on USB_CONFIGFS
> diff --git a/drivers/usb/gadget/function/Makefile
> b/drivers/usb/gadget/function/Makefile
> index 5d3a6cf02218..eb851309006c 100644
> --- a/drivers/usb/gadget/function/Makefile
> +++ b/drivers/usb/gadget/function/Makefile
> @@ -50,3 +50,5 @@ usb_f_printer-y := f_printer.o
> obj-$(CONFIG_USB_F_PRINTER) += usb_f_printer.o
> usb_f_tcm-y := f_tcm.o
> obj-$(CONFIG_USB_F_TCM) += usb_f_tcm.o
> +usb_f_trace-y:= f-trace.o
> +obj-$(CONFIG_USB_F_TRACE)+= usb_f_trace.o
> diff --git a/drivers/usb/gadget/function/f-trace.c
> b/drivers/usb/gadget/function/f-trace.c
> new file mode 100644
> index ..b5941df128a0
> --- /dev/null
> +++ b/drivers/usb/gadget/function/f-trace.c
> @@ -0,0 +1,401 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * f_trace.c -- USB FTrace Export
> + *
> + * Copyright (C) 2019 Intel Corporation
> + * Author: Felipe Balbi
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License v2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct usb_ftrace {
> + struct trace_export ftrace;
> + struct usb_function function;
> + struct work_struct queue_work;
> + spinlock_t lock;
> +
> + struct list_head list;
> + struct list_head pending;
> + struct list_head queued;
> +
> + struct usb_ep *in;
> +
> + u8 intf_id;
> +};
> +#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
> +#define work_to_trace(w) (container_of((w), struct usb_ftrace,
> queue_work))
> +#define to_trace(f) (container_of((f), struct usb_ftrace, function))
> +
> +#define FTRACE_REQUEST_QUEUE_LENGTH 250
> +
> +static inline struct usb_request *next_request(struct list_head *list)
> +{
> + return list_first_entry_or_null(list, struct usb_request, list);
> +}
> +
> +struct usb_ftrace_opts {
> + struct usb_function_instance func_inst;
> +};
> +#define to_opts(fi) (container_of((fi), struct usb_ftrace_opts, func_inst))
> +
> +static struct usb_interface_descriptor ftrace_intf_desc = {
> + .bLength= USB_DT_INTERFACE_SIZE,
> + .bDescriptorType= USB_DT_INTERFACE,
> +
> + .bAlternateSetting = 0,
> + .bNumEndpoints = 1,
> + .bInterfaceClass= USB_CLASS_VENDOR_SPEC,
> + .bInterfaceSubClass = USB_SUBCLASS_VENDOR_SPEC,
We *may* be able to use the USB_DEBUG_CLASS here with a vendor protocol
which we define to be Linux Ftrace. If folks think it would be best,
then I can go look at the debug class and check whether it would be
feasible.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
On Thu, Mar 21, 2019 at 11:47:48AM +0200, Felipe Balbi wrote: > Allow for ftrace data to be exported over a USB Gadget > Controller. With this, we have a potentially very fast pipe for > transmitting ftrace data to a Host PC for further analysis. > > Note that in order to decode the data, one needs access to kernel > symbols in order to convert binary data into function names and what > not. > > Signed-off-by: Felipe Balbi > --- > drivers/usb/gadget/Kconfig| 15 + > drivers/usb/gadget/function/Makefile | 2 + > drivers/usb/gadget/function/f-trace.c | 401 ++ > 3 files changed, 418 insertions(+) > create mode 100644 drivers/usb/gadget/function/f-trace.c This is funny, nice work :) Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
On Thu, Mar 21, 2019 at 11:50:04AM +0200, Felipe Balbi wrote:
> > +static struct usb_interface_descriptor ftrace_intf_desc = {
> > + .bLength= USB_DT_INTERFACE_SIZE,
> > + .bDescriptorType= USB_DT_INTERFACE,
> > +
> > + .bAlternateSetting = 0,
> > + .bNumEndpoints = 1,
> > + .bInterfaceClass= USB_CLASS_VENDOR_SPEC,
> > + .bInterfaceSubClass = USB_SUBCLASS_VENDOR_SPEC,
>
> We *may* be able to use the USB_DEBUG_CLASS here with a vendor protocol
> which we define to be Linux Ftrace. If folks think it would be best,
> then I can go look at the debug class and check whether it would be
> feasible.
I didn't think that that class allowed vendor protocols, but if it does,
sure, that would be nice.
I don't have access to usb-if specs since they kicked Linux out of the
organization, and because of that, I really don't care about their specs
anymore :)
thanks,
greg k-h
Re: Problem with USB2 devices connected to a hub
On 16.03.19 15:52, Georg Chini wrote: On 15.03.19 17:04, Georg Chini wrote: On 15.03.19 15:48, Mathias Nyman wrote: On 14.3.2019 20.39, Georg Chini wrote: On 14.03.19 15:00, Mathias Nyman wrote: On 14.3.2019 14.38, Georg Chini wrote: Hello, I have a problem with multiple USB2 devices. After purchasing a new motherboard, some USB2 devices (specifically audio devices and bluetooth dongles) do no longer work when connected to a hub, even if they are the only device on the hub. They do work when they are directly connected to an USB (2.0 or 3.0) port of the machine. The error I am getting with the hub in between is "Not enough bandwidth for new device state". Here are example kernel messages for a bluetooth dongle: Mar 14 08:12:33 mini kernel: usb 1-4.1: new full-speed USB device number 15 using xhci_hcd Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=31.64 Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Mar 14 08:12:33 mini kernel: usb 1-4.1: Not enough bandwidth for new device state. I have only one single USB controller: 00:15.0 USB controller: Intel Corporation Atom Processor C3000 Series USB 3.0 xHCI Controller (rev 11) I am using kernel 5.0. lsusb output: Bus 002 Device 004: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 003: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 002: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 013: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 011: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 012: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 010: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 001 Device 008: ID 046d:0994 Logitech, Inc. QuickCam Orbit/Sphere AF Bus 001 Device 016: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 009: ID 0557:2419 ATEN International Co., Ltd Bus 001 Device 006: ID 0557:7000 ATEN International Co., Ltd Hub Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 003: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device Bus 001 Device 002: ID 0b0e:0348 GN Netcom Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The C-Media sound device is directly connected to the machine and is working. The BT dongle is on a hub and does not work. If I connect the C-Media device to a hub, it will also produce the "not enough bandwidth" error. Can anybody help me to debug this problem further? Logs and traces could help, also lsusb -v output. logs: mount -t debugfs none /sys/kernel/debug echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control send output of dmesg traces: mount -t debugfs none /sys/kernel/debug echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable send content of /sys/kernel/debug/tracing/trace -Mathias Thanks for your reply. Please find the output attached. What I did: - I removed all USB devices from the machine, except one USB hub - I plugged the C-Media sound device into the hub and collected the data - For reference I plugged the same device into a free USB 2.0 port on the machine and collected the data. As already said, direct connection to a port works while it does not work on the hub. The files with _working are from plugging into the machine, those with _failed are from plugging into the hub. I also confirmed that the device is working when plugged directly into the USB 3.0 port and also that it does not work on an USB 2.0 hub plugged into an USB 2.0 port. Hi, According to lsusb your Genesys hub(s?) is(are) mess. Can you try with a different hub? As an example it shows you have three USB3 hubs connected, first has 0 ports, and the other two have 42 ports each. (not possible, or allowed) The bandwidth error originates from xhci host. It's a 'Secondary Bandwidth Error' message generated when xHCI calculates that the external hub can't handle the requested bandwidth needed when enabling new endpoints on the connected device behind the hub. -Mathias In my tests there was only a single 10-port hub connected to the (only) USB 3.0 port. This hub seems internally to consist of three 4-port hubs. As already mentioned I tested all possible combinations, which includes an USB 2.0 Hub on an USB 2.0 port. Regardless which hub or which port I am using (I tested two USB 2.0 and two USB 3.0 hubs on different ports), the result is always the same. The device works when connected to the port and throws an error when connected to a hub. Or do you want the debug information with another hub? Regards Georg Some ad
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
hi,
Greg KH writes:
> On Thu, Mar 21, 2019 at 11:50:04AM +0200, Felipe Balbi wrote:
>> > +static struct usb_interface_descriptor ftrace_intf_desc = {
>> > + .bLength= USB_DT_INTERFACE_SIZE,
>> > + .bDescriptorType= USB_DT_INTERFACE,
>> > +
>> > + .bAlternateSetting = 0,
>> > + .bNumEndpoints = 1,
>> > + .bInterfaceClass= USB_CLASS_VENDOR_SPEC,
>> > + .bInterfaceSubClass = USB_SUBCLASS_VENDOR_SPEC,
>>
>> We *may* be able to use the USB_DEBUG_CLASS here with a vendor protocol
>> which we define to be Linux Ftrace. If folks think it would be best,
>> then I can go look at the debug class and check whether it would be
>> feasible.
>
> I didn't think that that class allowed vendor protocols, but if it does,
> sure, that would be nice.
I think it does. That spec is public, actually. Came out as part of usb
3.1. I'll review the spec tomorrow and, hopefully, resend this with
Diagnostic Class for the interface using DvC.Trace subclass and vendor
protocol.
cheers
--
balbi
Re: [regression] USB power management failure to suspend / high CPU usage
On Mon, Mar 4, 2019 at 10:13 AM Mathias Nyman wrote: > > On 26.2.2019 0.11, Ivan Mironov wrote: > > Hi Mathias, > > > > I applied your patch on top of v5.0-rc8 and tested it on my laptop. > > > > It fixes the suspend problem from the kernel side, but there is another > > one: starting with the second suspend, XHCI controller wakes up the > > system just after few seconds after suspending. Laptop keeps looping > > through suspend/resume while lid is closed. > > > > Such behaviour is quite stable: I was able to reproduce this three > > times with reboots in between. Corresponding dmesg and traces are here > > (from one run only): > > https://github.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/tree/master/test-22 > > > > After disabling ACPI wake up on XHC1 (echo XHC1 >/proc/acpi/wakeup), > > everything works as expected: suspend/resume works fine multiple times, > > card reader remains missing after the first suspend/resume. > > > > Thanks, logs show it's no longer in a similar loop attempting so suspend > the bus, but device instead goes between polling, rxDetect and compliance, > modes, sometimes with cold attach status flag seen. > > Most of the time is now spent resetting the device. > > I have yet another patch, this one will just log the portstatus. > I'd like to know if we are doing something odd when resuming the port > that causes it to get stuck. > > Patch attached, can you try it out? > > Also available from my port-debug branch: > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git port-debug Where do we stand with this fix? Were you able to try out this port debug patch, Ivan? I normally run with ACPI wakeup disabled on XHC1 but if more debugging is needed, I can enable wakeup again and try to reproduce what Ivan is seeing. Just let me know. For now, I've been applying Mathias previous patch to the latest kernels and have been suspending, hibernating and resuming successfully with the card reader disabled. Thanks, Eric
Re: [regression] USB power management failure to suspend / high CPU usage
On 21.3.2019 15.32, Eric Blau wrote: On Mon, Mar 4, 2019 at 10:13 AM Mathias Nyman wrote: On 26.2.2019 0.11, Ivan Mironov wrote: Hi Mathias, I applied your patch on top of v5.0-rc8 and tested it on my laptop. It fixes the suspend problem from the kernel side, but there is another one: starting with the second suspend, XHCI controller wakes up the system just after few seconds after suspending. Laptop keeps looping through suspend/resume while lid is closed. Such behaviour is quite stable: I was able to reproduce this three times with reboots in between. Corresponding dmesg and traces are here (from one run only): https://github.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/tree/master/test-22 After disabling ACPI wake up on XHC1 (echo XHC1 >/proc/acpi/wakeup), everything works as expected: suspend/resume works fine multiple times, card reader remains missing after the first suspend/resume. Thanks, logs show it's no longer in a similar loop attempting so suspend the bus, but device instead goes between polling, rxDetect and compliance, modes, sometimes with cold attach status flag seen. Most of the time is now spent resetting the device. I have yet another patch, this one will just log the portstatus. I'd like to know if we are doing something odd when resuming the port that causes it to get stuck. Patch attached, can you try it out? Also available from my port-debug branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git port-debug Where do we stand with this fix? Were you able to try out this port debug patch, Ivan? I normally run with ACPI wakeup disabled on XHC1 but if more debugging is needed, I can enable wakeup again and try to reproduce what Ivan is seeing. Just let me know. For now, I've been applying Mathias previous patch to the latest kernels and have been suspending, hibernating and resuming successfully with the card reader disabled. Just added the patch to my for-usb-linus branch, will send it forward tomorrow -Mathias
Re: Problem with USB2 devices connected to a hub
On 21.3.2019 13.05, Georg Chini wrote: On 16.03.19 15:52, Georg Chini wrote: On 15.03.19 17:04, Georg Chini wrote: On 15.03.19 15:48, Mathias Nyman wrote: On 14.3.2019 20.39, Georg Chini wrote: On 14.03.19 15:00, Mathias Nyman wrote: On 14.3.2019 14.38, Georg Chini wrote: Hello, I have a problem with multiple USB2 devices. After purchasing a new motherboard, some USB2 devices (specifically audio devices and bluetooth dongles) do no longer work when connected to a hub, even if they are the only device on the hub. They do work when they are directly connected to an USB (2.0 or 3.0) port of the machine. The error I am getting with the hub in between is "Not enough bandwidth for new device state". Here are example kernel messages for a bluetooth dongle: Mar 14 08:12:33 mini kernel: usb 1-4.1: new full-speed USB device number 15 using xhci_hcd Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=31.64 Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Mar 14 08:12:33 mini kernel: usb 1-4.1: Not enough bandwidth for new device state. I have only one single USB controller: 00:15.0 USB controller: Intel Corporation Atom Processor C3000 Series USB 3.0 xHCI Controller (rev 11) I am using kernel 5.0. lsusb output: Bus 002 Device 004: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 003: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 002: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 013: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 011: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 012: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 010: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 001 Device 008: ID 046d:0994 Logitech, Inc. QuickCam Orbit/Sphere AF Bus 001 Device 016: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 009: ID 0557:2419 ATEN International Co., Ltd Bus 001 Device 006: ID 0557:7000 ATEN International Co., Ltd Hub Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 003: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device Bus 001 Device 002: ID 0b0e:0348 GN Netcom Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The C-Media sound device is directly connected to the machine and is working. The BT dongle is on a hub and does not work. If I connect the C-Media device to a hub, it will also produce the "not enough bandwidth" error. Can anybody help me to debug this problem further? Logs and traces could help, also lsusb -v output. logs: mount -t debugfs none /sys/kernel/debug echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control send output of dmesg traces: mount -t debugfs none /sys/kernel/debug echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable send content of /sys/kernel/debug/tracing/trace -Mathias Thanks for your reply. Please find the output attached. What I did: - I removed all USB devices from the machine, except one USB hub - I plugged the C-Media sound device into the hub and collected the data - For reference I plugged the same device into a free USB 2.0 port on the machine and collected the data. As already said, direct connection to a port works while it does not work on the hub. The files with _working are from plugging into the machine, those with _failed are from plugging into the hub. I also confirmed that the device is working when plugged directly into the USB 3.0 port and also that it does not work on an USB 2.0 hub plugged into an USB 2.0 port. Hi, According to lsusb your Genesys hub(s?) is(are) mess. Can you try with a different hub? As an example it shows you have three USB3 hubs connected, first has 0 ports, and the other two have 42 ports each. (not possible, or allowed) The bandwidth error originates from xhci host. It's a 'Secondary Bandwidth Error' message generated when xHCI calculates that the external hub can't handle the requested bandwidth needed when enabling new endpoints on the connected device behind the hub. -Mathias In my tests there was only a single 10-port hub connected to the (only) USB 3.0 port. This hub seems internally to consist of three 4-port hubs. As already mentioned I tested all possible combinations, which includes an USB 2.0 Hub on an USB 2.0 port. Regardless which hub or which port I am using (I tested two USB 2.0 and two USB 3.0 hubs on different ports), the result is always the same. The device works when connected to the port and throws an error when connected to a hub. Or do you want the debug information with another hub? Regards Ge
Re: [regression] USB power management failure to suspend / high CPU usage
On Thu, Mar 21, 2019 at 10:51 AM Mathias Nyman wrote: > > On 21.3.2019 15.32, Eric Blau wrote: > > > > Where do we stand with this fix? Were you able to try out this port > > debug patch, Ivan? > > > > I normally run with ACPI wakeup disabled on XHC1 but if more debugging > > is needed, I can enable wakeup again and try to reproduce what Ivan is > > seeing. Just let me know. For now, I've been applying Mathias previous > > patch to the latest kernels and have been suspending, hibernating and > > resuming successfully with the card reader disabled. > > > > Just added the patch to my for-usb-linus branch, will send it forward tomorrow Great, thanks Mathias! -Eric
Re: Problem with USB2 devices connected to a hub
On 21.03.19 16:19, Mathias Nyman wrote: On 21.3.2019 13.05, Georg Chini wrote: On 16.03.19 15:52, Georg Chini wrote: On 15.03.19 17:04, Georg Chini wrote: On 15.03.19 15:48, Mathias Nyman wrote: On 14.3.2019 20.39, Georg Chini wrote: On 14.03.19 15:00, Mathias Nyman wrote: On 14.3.2019 14.38, Georg Chini wrote: Hello, I have a problem with multiple USB2 devices. After purchasing a new motherboard, some USB2 devices (specifically audio devices and bluetooth dongles) do no longer work when connected to a hub, even if they are the only device on the hub. They do work when they are directly connected to an USB (2.0 or 3.0) port of the machine. The error I am getting with the hub in between is "Not enough bandwidth for new device state". Here are example kernel messages for a bluetooth dongle: Mar 14 08:12:33 mini kernel: usb 1-4.1: new full-speed USB device number 15 using xhci_hcd Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=31.64 Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Mar 14 08:12:33 mini kernel: usb 1-4.1: Not enough bandwidth for new device state. I have only one single USB controller: 00:15.0 USB controller: Intel Corporation Atom Processor C3000 Series USB 3.0 xHCI Controller (rev 11) I am using kernel 5.0. lsusb output: Bus 002 Device 004: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 003: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 002: ID 05e3:0617 Genesys Logic, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 013: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 011: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 012: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 010: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 001 Device 008: ID 046d:0994 Logitech, Inc. QuickCam Orbit/Sphere AF Bus 001 Device 016: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 009: ID 0557:2419 ATEN International Co., Ltd Bus 001 Device 006: ID 0557:7000 ATEN International Co., Ltd Hub Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 003: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device Bus 001 Device 002: ID 0b0e:0348 GN Netcom Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The C-Media sound device is directly connected to the machine and is working. The BT dongle is on a hub and does not work. If I connect the C-Media device to a hub, it will also produce the "not enough bandwidth" error. Can anybody help me to debug this problem further? Logs and traces could help, also lsusb -v output. logs: mount -t debugfs none /sys/kernel/debug echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control send output of dmesg traces: mount -t debugfs none /sys/kernel/debug echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable send content of /sys/kernel/debug/tracing/trace -Mathias Thanks for your reply. Please find the output attached. What I did: - I removed all USB devices from the machine, except one USB hub - I plugged the C-Media sound device into the hub and collected the data - For reference I plugged the same device into a free USB 2.0 port on the machine and collected the data. As already said, direct connection to a port works while it does not work on the hub. The files with _working are from plugging into the machine, those with _failed are from plugging into the hub. I also confirmed that the device is working when plugged directly into the USB 3.0 port and also that it does not work on an USB 2.0 hub plugged into an USB 2.0 port. Hi, According to lsusb your Genesys hub(s?) is(are) mess. Can you try with a different hub? As an example it shows you have three USB3 hubs connected, first has 0 ports, and the other two have 42 ports each. (not possible, or allowed) The bandwidth error originates from xhci host. It's a 'Secondary Bandwidth Error' message generated when xHCI calculates that the external hub can't handle the requested bandwidth needed when enabling new endpoints on the connected device behind the hub. -Mathias In my tests there was only a single 10-port hub connected to the (only) USB 3.0 port. This hub seems internally to consist of three 4-port hubs. As already mentioned I tested all possible combinations, which includes an USB 2.0 Hub on an USB 2.0 port. Regardless which hub or which port I am using (I tested two USB 2.0 and two USB 3.0 hubs on different ports), the result is always the same. The device works when connected to the port and throws an error when connected to a hub. Or do
Re: FTDI Serial shutdown
Hi Felipe, I am using 3.14.52 version from NXP codeline. I haven't tried the latest codeline Best Regards, Leonardo On Wed, Mar 20, 2019 at 4:15 PM Felipe Balbi wrote: > > > Hi Leonardo, > > "Leonardo, Sionzon" writes: > > I am Leonardo from Adtec Corporation Japan. > > > > I'm new to USB serial drivers and I have some few questions. > > A bit of background of what I intend to do, we're trying to disable the USB > > port by controlling the USB VBUS via GPIO. For usb storage devices, the > > device is removed and references to /dev/ is removed. For FTDI usb serial > > device, there is still a reference to /dev/ttyUSB . Is this a bug or by > > design? > > What kernel version are you using on the system in question? Have you > tried the latest release (v5.0)? > > Best regards > > -- > balbi
PRIVATE...
I have a business Proposal that will be of benefit to the both of us.Kindly contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
Hi Felipe, I love your patch! Yet something to improve: [auto build test ERROR on balbi-usb/next] [also build test ERROR on v5.1-rc1 next-20190321] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-gadget-functions-add-ftrace-export-over-USB/20190322-081552 base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All error/warnings (new ones prefixed by >>): >> drivers/usb/gadget/function/f-trace.c:26:22: error: field 'ftrace' has >> incomplete type struct trace_export ftrace; ^~ In file included from include/linux/ioport.h:13:0, from include/linux/device.h:15, from drivers/usb/gadget/function/f-trace.c:13: drivers/usb/gadget/function/f-trace.c: In function 'ftrace_write': >> include/linux/kernel.h:998:32: error: dereferencing pointer to incomplete >> type 'struct trace_export' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~ include/linux/compiler.h:324:9: note: in definition of macro '__compiletime_assert' if (!(condition)) \ ^ include/linux/compiler.h:344:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ include/linux/kernel.h:998:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~ include/linux/kernel.h:998:20: note: in expansion of macro '__same_type' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~ >> drivers/usb/gadget/function/f-trace.c:39:29: note: in expansion of macro >> 'container_of' #define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace)) ^~~~ >> drivers/usb/gadget/function/f-trace.c:175:30: note: in expansion of macro >> 'ftrace_to_trace' struct usb_ftrace *trace = ftrace_to_trace(ftrace); ^~~ drivers/usb/gadget/function/f-trace.c: In function 'ftrace_bind': >> drivers/usb/gadget/function/f-trace.c:295:8: error: implicit declaration of >> function 'register_ftrace_export'; did you mean 'register_chrdev_region'? >> [-Werror=implicit-function-declaration] ret = register_ftrace_export(&trace->ftrace); ^~ register_chrdev_region drivers/usb/gadget/function/f-trace.c: In function 'ftrace_unbind': >> drivers/usb/gadget/function/f-trace.c:323:2: error: implicit declaration of >> function 'unregister_ftrace_export'; did you mean >> 'unregister_chrdev_region'? [-Werror=implicit-function-declaration] unregister_ftrace_export(&trace->ftrace); ^~~~ unregister_chrdev_region cc1: some warnings being treated as errors -- drivers/usb//gadget/function/f-trace.c:26:22: error: field 'ftrace' has incomplete type struct trace_export ftrace; ^~ In file included from include/linux/ioport.h:13:0, from include/linux/device.h:15, from drivers/usb//gadget/function/f-trace.c:13: drivers/usb//gadget/function/f-trace.c: In function 'ftrace_write': >> include/linux/kernel.h:998:32: error: dereferencing pointer to incomplete >> type 'struct trace_export' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~ include/linux/compiler.h:324:9: note: in definition of macro '__compiletime_assert' if (!(condition)) \ ^ include/linux/compiler.h:344:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ include/linux/build_bug.h:39:37: note: in expansion of mac
Re: FTDI Serial shutdown
On Fri, Mar 22, 2019 at 08:50:09AM +0900, Leonardo, Sionzon wrote: > Hi Felipe, > > I am using 3.14.52 version from NXP codeline. I haven't tried the > latest codeline We have no idea what that refers to, sorry. Please try the in-kernel driver. If you have problems with an out-of-tree driver, please contact the authors of that code. thanks, greg k-h
