[PATCH 1/1] lsusb: Added support for Billboard Capability descriptor
Added support for Billboard Capability descriptor as per Universal
Serial Bus Device Class Definition for Billboard Devices Revision 1.1
Signed-off-by: Muthu M
---
lsusb.c | 82 +
1 file changed, 82 insertions(+)
diff --git a/lsusb.c b/lsusb.c
index 774caed..dae7c6c 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -70,6 +70,7 @@
#define USB_DC_SUPERSPEED 0x03
#define USB_DC_CONTAINER_ID0x04
#define USB_DC_SUPERSPEEDPLUS 0x0a
+#define USB_DC_BILLBOARD 0x0d
/* Conventional codes for class-specific descriptors. The convention is
* defined in the USB "Common Class" Spec (3.11). Individual class specs
@@ -118,6 +119,22 @@ static const char * const encryption_type[] = {
"RSA_1",
"RESERVED"
};
+static const char * const vconn_power[] = {
+ "1W",
+ "1.5W",
+ "2W",
+ "3W",
+ "4W",
+ "5W",
+ "6W",
+ "reserved"
+};
+static const char * const alt_mode_state[] = {
+ "Unspecified Error",
+ "Alternate Mode configuration not attempted",
+ "Alternate Mode configuration attempted but unsuccessful",
+ "Alternate Mode configuration successful"
+};
static void dump_interface(libusb_device_handle *dev, const struct
libusb_interface *interface);
static void dump_endpoint(libusb_device_handle *dev, const struct
libusb_interface_descriptor *interface, const struct libusb_endpoint_descriptor
*endpoint);
@@ -3771,6 +3788,68 @@ static void
dump_container_id_device_capability_desc(unsigned char *buf)
get_guid(&buf[4]));
}
+static void dump_billboard_device_capability_desc(libusb_device_handle *dev,
unsigned char *buf)
+{
+ char *url, *alt_mode_str;
+ int w_vconn_power, alt_mode, i, svid, state;
+ const char *vconn;
+ unsigned char *bmConfigured;
+
+ if (buf[0] < 40) {
+ printf(" Bad Billboard Capability descriptor.\n");
+ return;
+ }
+ url = get_dev_string(dev, buf[3]);
+ w_vconn_power = buf[6] | (buf[7] << 8);
+ vconn = (w_vconn_power & (1 << 15)) ? "VCONN power not required" :
vconn_power[w_vconn_power & 0x7];
+ printf(" Billboard Capability:\n"
+ "bLength %5u\n"
+ "bDescriptorType %5u\n"
+ "bDevCapabilityType %5u\n"
+ "iAddtionalInfoURL %5u %s\n"
+ "bNumberOfAlternateModes %5u\n"
+ "bPreferredAlternateMode %5u\n"
+ "VCONN Power %5u %s\n",
+ buf[0], buf[1], buf[2],
+ buf[3], url,
+ buf[4], buf[5],
+ w_vconn_power, vconn);
+ bmConfigured = &buf[8];
+ printf(
+ "bmConfigured "
+ );
+ dump_bytes(bmConfigured, 32);
+ printf(
+ "bcdVersion %2x.%02x\n"
+ "bAdditionalFailureInfo %5u\n"
+ "bReserved %5u\n",
+ (buf[41] == 0) ? 1 : buf[41], buf[40],
+ buf[42], buf[43]);
+
+ printf(
+ "Alternate Modes supported by Device Container:\n"
+ );
+ i = 44; /* Alternate mode 0 starts at index 44 */
+ for (alt_mode = 0; alt_mode < buf[4]; alt_mode++) {
+ svid = buf[i] | (buf[i+1] << 8);
+ alt_mode_str = get_dev_string(dev, buf[i+3]);
+ state = ((bmConfigured[alt_mode >> 2]) >> ((alt_mode & 0x3) <<
1)) & 0x3;
+ printf(
+ "Alternate Mode %d : %s\n"
+ " wSVID[%d]0x%04X\n"
+ " bAlternateMode[%d] %5u\n"
+ " iAlternateModeString[%d] %5u %s\n",
+ alt_mode, alt_mode_state[state],
+ alt_mode, svid,
+ alt_mode, buf[i+2],
+ alt_mode, buf[i+3], alt_mode_str);
+ free(alt_mode_str);
+ i += 4;
+ }
+
+ free (url);
+}
+
static void dump_bos_descriptor(libusb_device_handle *fd)
{
/* Total length of BOS descriptors varies.
@@ -3849,6 +3928,9 @@ static void dump_bos_descriptor(libusb_device_handle *fd)
case USB_DC_CONTAINER_ID:
dump_container_id_device_capability_desc(buf);
break;
+ case USB_DC_BILLBOARD:
+ dump_billboard_device_capability_desc(fd, buf);
+ break;
default:
printf(" ** UNRECOGNIZED: ");
dump_bytes(buf, buf[0]);
--
1.8.3
Re: [PATCH 1/1] lsusb: Added support for Billboard Capability descriptor
Hi,
Muthu M writes:
> Added support for Billboard Capability descriptor as per Universal
> Serial Bus Device Class Definition for Billboard Devices Revision 1.1
>
> Signed-off-by: Muthu M
I didn't confirm with the billboard class to make sure all details are
correct (will do that on Monday, hopefully), but great work :-) A few
minor nits below
> ---
> lsusb.c | 82
> +
> 1 file changed, 82 insertions(+)
>
> diff --git a/lsusb.c b/lsusb.c
> index 774caed..dae7c6c 100644
> --- a/lsusb.c
> +++ b/lsusb.c
> @@ -70,6 +70,7 @@
> #define USB_DC_SUPERSPEED0x03
> #define USB_DC_CONTAINER_ID 0x04
> #define USB_DC_SUPERSPEEDPLUS0x0a
> +#define USB_DC_BILLBOARD 0x0d
>
> /* Conventional codes for class-specific descriptors. The convention is
> * defined in the USB "Common Class" Spec (3.11). Individual class specs
> @@ -118,6 +119,22 @@ static const char * const encryption_type[] = {
> "RSA_1",
> "RESERVED"
> };
add a blank line here
> +static const char * const vconn_power[] = {
> + "1W",
> + "1.5W",
> + "2W",
> + "3W",
> + "4W",
> + "5W",
> + "6W",
> + "reserved"
> +};
and here
> +static const char * const alt_mode_state[] = {
> + "Unspecified Error",
> + "Alternate Mode configuration not attempted",
> + "Alternate Mode configuration attempted but unsuccessful",
> + "Alternate Mode configuration successful"
> +};
>
> static void dump_interface(libusb_device_handle *dev, const struct
> libusb_interface *interface);
> static void dump_endpoint(libusb_device_handle *dev, const struct
> libusb_interface_descriptor *interface, const struct
> libusb_endpoint_descriptor *endpoint);
> @@ -3771,6 +3788,68 @@ static void
> dump_container_id_device_capability_desc(unsigned char *buf)
> get_guid(&buf[4]));
> }
>
> +static void dump_billboard_device_capability_desc(libusb_device_handle *dev,
> unsigned char *buf)
most other dump functions define a prototype above, you might wanna do
the same to keep consistency.
> +{
> + char *url, *alt_mode_str;
> + int w_vconn_power, alt_mode, i, svid, state;
> + const char *vconn;
> + unsigned char *bmConfigured;
> +
> + if (buf[0] < 40) {
> + printf(" Bad Billboard Capability descriptor.\n");
this should probably be printed to stderr.
> + return;
> + }
another blank line here
> + url = get_dev_string(dev, buf[3]);
> + w_vconn_power = buf[6] | (buf[7] << 8);
> + vconn = (w_vconn_power & (1 << 15)) ? "VCONN power not required" :
> vconn_power[w_vconn_power & 0x7];
> + printf(" Billboard Capability:\n"
> + "bLength %5u\n"
> + "bDescriptorType %5u\n"
> + "bDevCapabilityType %5u\n"
> + "iAddtionalInfoURL %5u %s\n"
> + "bNumberOfAlternateModes %5u\n"
> + "bPreferredAlternateMode %5u\n"
> + "VCONN Power %5u %s\n",
> + buf[0], buf[1], buf[2],
> + buf[3], url,
> + buf[4], buf[5],
> + w_vconn_power, vconn);
add a blank line here
> + bmConfigured = &buf[8];
and here
> + printf(
> + "bmConfigured "
> + );
and here
> + dump_bytes(bmConfigured, 32);
and here
> + printf(
> + "bcdVersion %2x.%02x\n"
> + "bAdditionalFailureInfo %5u\n"
> + "bReserved %5u\n",
> + (buf[41] == 0) ? 1 : buf[41], buf[40],
> + buf[42], buf[43]);
> +
> + printf(
> + "Alternate Modes supported by Device Container:\n"
> + );
> + i = 44; /* Alternate mode 0 starts at index 44 */
> + for (alt_mode = 0; alt_mode < buf[4]; alt_mode++) {
> + svid = buf[i] | (buf[i+1] << 8);
> + alt_mode_str = get_dev_string(dev, buf[i+3]);
> + state = ((bmConfigured[alt_mode >> 2]) >> ((alt_mode & 0x3) <<
> 1)) & 0x3;
> + printf(
> + "Alternate Mode %d : %s\n"
> + " wSVID[%d]0x%04X\n"
> + " bAlternateMode[%d] %5u\n"
> + " iAlternateModeString[%d] %5u %s\n",
> + alt_mode, alt_mode_state[state],
> + alt_mode, svid,
> + alt_mode, buf[i+2],
> + alt_mode, buf[i+3], alt_mode_str);
> + free(alt_mode_str);
> + i += 4;
> + }
> +
> + free (url);
> +}
> +
> static void dump_bos_descriptor(libusb_device_handle *fd)
> {
> /
[GIT PULL] USB driver fixes for 4.3-rc5
The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c: Linux 4.3-rc3 (2015-09-27 07:50:08 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.3-rc5 for you to fetch changes up to 72194739f54607bbf8cfded159627a2015381557: usb: Add device quirk for Logitech PTZ cameras (2015-10-04 11:01:13 +0100) USB fixes for 4.3-rc5 Here are some small USB and PHY fixes and quirk updates for 4.3-rc5. Nothing major here, full details in the shortlog, and all of these have been in linux-next for a while. Signed-off-by: Greg Kroah-Hartman Alexander Inyukhin (1): USB: chaoskey read offset bug Greg Kroah-Hartman (2): Merge tag 'fixes-for-v4.3-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'phy-for-4.3-rc' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Luis de Bethencourt (1): phy: berlin-sata: Fix module autoload for OF platform driver Sudip Mukherjee (1): usb: gadget: bdc: fix memory leak Vincent Palatin (1): usb: Add device quirk for Logitech PTZ cameras Yaniv Gardi (1): phy: qcom-ufs: fix build error when the component is built as a module Yao-Wen Mao (1): USB: Add reset-resume quirk for two Plantronics usb headphones. Yoshihiro Shimoda (2): usb: renesas_usbhs: fix build warning if 64-bit architecture usb: renesas_usbhs: Add support for R-Car H3 huang lin (1): phy: rockchip-usb: power down phy when rockchip phy probe Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 + drivers/phy/phy-berlin-sata.c | 1 + drivers/phy/phy-qcom-ufs.c | 11 +++ drivers/phy/phy-rockchip-usb.c | 6 ++ drivers/usb/core/quirks.c | 13 + drivers/usb/gadget/udc/bdc/bdc_ep.c | 4 +++- drivers/usb/misc/chaoskey.c | 2 +- drivers/usb/renesas_usbhs/common.c | 7 ++- include/linux/usb/renesas_usbhs.h | 2 +- 9 files changed, 43 insertions(+), 4 deletions(-) -- 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
Workaround for "can't set config #1, error -71" (or error -110) with SSD via USB
Hi, I've an internal SSD and have recently bought a 2nd SSD for backup purposes. Both are same make and size (Samsung 850 Evo 500 GB, USB3). The SSD works fine in the laptop, but attaching it externally via an USB3 docking station (ASMedia Technology Inc. Transcend StoreJet 25M3) didn't work, the log file had such entries: Oct 10 01:56:56 c22-local vmunix: [ 449.063428] usb 2-1: new SuperSpeed USB device number 13 using xhci_hcd Oct 10 01:57:01 c22-local vmunix: [ 454.076750] usb 2-1: New USB device found, idVendor=174c, idProduct=5106 Oct 10 01:57:01 c22-local vmunix: [ 454.076759] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Oct 10 01:57:01 c22-local vmunix: [ 454.076764] usb 2-1: Product: AS2105 Oct 10 01:57:01 c22-local vmunix: [ 454.076768] usb 2-1: Manufacturer: ASMedia Oct 10 01:57:01 c22-local vmunix: [ 454.078681] usb 2-1: can't set config #1, error -71 Oct 10 01:57:01 c22-local mtp-probe: checking bus 2, device 13: "/sys/devices/pci:00/:00:10.0/usb2/2-1" Oct 10 01:57:01 c22-local mtp-probe: bus: 2, device: 13 was not an MTP device Oct 10 01:57:01 c22-local vmunix: [ 454.244186] usb 2-1: USB disconnect, device number 13 When attaching via an external USB hub the error number is -110, if attaching directly to the laptop the error number is -71. I tried all solutions (actually 3) of other people but they unfortunately didn't help in my case. Then today I tried a cheap Icy-Box case (about 14 euros), it has USB3, and what shall I say: it works like a charm! So, maybe this experience can help also other people in similar situation: just try also a different docking station or adapter. My OS: debian 8 (jessie) with std kernel (3.16.0-4-amd64); yesterday I had also tried with the latest 4.3.rc4 kernel, but negative) cu -- 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 behaviour
On 06 Oct 2015, at 13:26, Paul Zimmerman wrote: > On Tue, Oct 6, 2015 at 10:01 AM, Alan Stern wrote: >> On Tue, 6 Oct 2015, Felipe Balbi wrote: >> > In my experience, you need to do at least the following to get max > performance from the mass storage gadget: > > - Use Windows 8 or higher on the host. It's much faster than Linux. >> >> Why is Windows so much faster? Or to put it another way, why is Linux >> slow? How can we improve things? > > I don't know. We were doing our performance demos using Windows, so we > never looked into why Linux was slower. But I do know the Microsoft > engineers put some effort into tuning their stack for good performance > at USB 3.0 speeds. I don't think anyone has done that for Linux yet. It seems that Mac OSX is faster when using a file system on an emulated device. dd directly to the block device on my Mac gives me around 137MB/s, whilst copying data onto a mounted filesystem (also with dd) runs at over 180MB/s. Paul.-- 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
Crash in usb_f_mass_storage
I came across the following kernel message on the latest 4.3-rc4 whilst performance testing on a USB3380 device connected to a Mac (10.9.5): [ 51.613838] WARNING: CPU: 2 PID: 0 at drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 [usb_f_mass_storage]() [ 51.613838] Modules linked in: usb_f_mass_storage libcomposite configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw i2c_designware_core acpi_pad lp mac_hid parport [ 51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW 4.3.0-rc4+ #4 [ 51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015 [ 51.613860] a03e9e10 88021eb03d70 81393f5d [ 51.613861] 88021eb03da8 81075856 880037be4400 88020b3023c8 [ 51.613862] 880037be4400 ffa1 88021eb03db8 [ 51.613863] Call Trace: [ 51.613864][] dump_stack+0x44/0x57 [ 51.613867] [] warn_slowpath_common+0x86/0xc0 [ 51.613868] [] warn_slowpath_null+0x1a/0x20 [ 51.613870] [] fsg_setup+0x12a/0x170 [usb_f_mass_storage] [ 51.613872] [] composite_setup+0x173/0x16b0 [libcomposite] [ 51.613873] [] ? ktime_get+0x3a/0x90 [ 51.613874] [] ? lapic_next_deadline+0x29/0x30 [ 51.613875] [] ? ktime_get+0x3a/0x90 [ 51.613877] [] net2280_irq+0xba2/0x10db [net2280] [ 51.613879] [] handle_irq_event_percpu+0x39/0x180 [ 51.613880] [] handle_irq_event+0x45/0x70 [ 51.613881] [] handle_edge_irq+0x99/0x150 [ 51.613883] [] handle_irq+0x1d/0x30 [ 51.613883] [] do_IRQ+0x4d/0xd0 [ 51.613885] [] common_interrupt+0x87/0x87 [ 51.613885][] ? cpuidle_enter_state+0xb8/0x220 [ 51.613888] [] cpuidle_enter+0x17/0x20 [ 51.613889] [] call_cpuidle+0x32/0x60 [ 51.613890] [] ? cpuidle_select+0x13/0x20 [ 51.613891] [] cpu_startup_entry+0x21c/0x2e0 [ 51.613891] [] start_secondary+0x104/0x130 [ 51.613892] ---[ end trace bda1c37ade46c57d ]— I can also reliable reproduce this by connecting the USB3380 to a USB port on the same Linux machine. In that case I also see an error: net2280 : net2280_enable: error=-22 Perhaps unrelated, but there is also a message: configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511 Paul.-- 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 behaviour
On Sat, 10 Oct 2015, Paul Jones wrote: > >> Why is Windows so much faster? Or to put it another way, why is Linux > >> slow? How can we improve things? > > > > I don't know. We were doing our performance demos using Windows, so we > > never looked into why Linux was slower. But I do know the Microsoft > > engineers put some effort into tuning their stack for good performance > > at USB 3.0 speeds. I don't think anyone has done that for Linux yet. > It seems that Mac OSX is faster when using a file system on an emulated > device. > dd directly to the block device on my Mac gives me around 137MB/s, whilst > copying data onto a mounted filesystem (also with dd) runs at over 180MB/s. I don't see how this comment is relevant to the question at hand, namely, why does the mass-storage gadget run faster when attached to a Windows host than when attached to a Linux host. I also don't see how "an emulated device" fits in here. In both tests, you copied data to a block device: once directly and once through the filesystem. Nothing was emulated. Finally, are you sure you are seeing the actual throughput and not just the rate of copying into a page cache? It would be better to test using reads instead of writes, because a read can't complete before the data is retrieved from the device. Getting back to the earlier problem, it's true there are some things we could do in usb-storage to speed up transfer rates. We don't have to wait for the CBW to complete before we start the data phase, and we don't have to wait for the data phase to complete before we submit the CSW URB (although this can get tricky if the device ends a write transfer with a STALL). It's not clear how much these changes would help, but they wouldn't hurt. 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 behaviour
On 10 Oct 2015, at 16:34, Alan Stern wrote: > On Sat, 10 Oct 2015, Paul Jones wrote: > Why is Windows so much faster? Or to put it another way, why is Linux slow? How can we improve things? >>> >>> I don't know. We were doing our performance demos using Windows, so we >>> never looked into why Linux was slower. But I do know the Microsoft >>> engineers put some effort into tuning their stack for good performance >>> at USB 3.0 speeds. I don't think anyone has done that for Linux yet. >> It seems that Mac OSX is faster when using a file system on an emulated >> device. >> dd directly to the block device on my Mac gives me around 137MB/s, whilst >> copying data onto a mounted filesystem (also with dd) runs at over 180MB/s. > > I don't see how this comment is relevant to the question at hand, > namely, why does the mass-storage gadget run faster when attached to a > Windows host than when attached to a Linux host. > > I also don't see how "an emulated device" fits in here. In both tests, > you copied data to a block device: once directly and once through the > filesystem. Nothing was emulated. It’s emulated in the sense that I’m using a gadget to provide a RAM based device. > Finally, are you sure you are seeing the actual throughput and not just > the rate of copying into a page cache? It would be better to test > using reads instead of writes, because a read can't complete before > the data is retrieved from the device. Oops, the numbers above are for reading (not writing which is somewhat slower). Paul. -- 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] ohci-pci: use USB_DT_*
Toshiba Portege 4000 quirk entry can be written shorter using the
PCI_DEVICE_SUB() macro.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
drivers/usb/host/ohci-pci.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Index: usb/drivers/usb/host/ohci-pci.c
===
--- usb.orig/drivers/usb/host/ohci-pci.c
+++ usb/drivers/usb/host/ohci-pci.c
@@ -192,10 +192,8 @@ static const struct pci_device_id ohci_p
},
{
/* Toshiba portege 4000 */
- .vendor = PCI_VENDOR_ID_AL,
- .device = 0x5237,
- .subvendor = PCI_VENDOR_ID_TOSHIBA,
- .subdevice = 0x0004,
+ PCI_DEVICE_SUB(PCI_VENDOR_ID_AL, 0x5237,
+ PCI_VENDOR_ID_TOSHIBA, 0x0004),
.driver_data= (unsigned long) broken_suspend,
},
{
--
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: Crash in usb_f_mass_storage
On 10 Oct 2015, at 16:32, Paul Jones wrote: > I came across the following kernel message on the latest 4.3-rc4 whilst > performance testing on a USB3380 device connected to a Mac (10.9.5): > > [ 51.613838] WARNING: CPU: 2 PID: 0 at > drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170 > [usb_f_mass_storage]() > [ 51.613838] Modules linked in: usb_f_mass_storage libcomposite configfs > drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915 mac80211 > snd_hda_codec_realtek snd_hda_codec_generic hid_generic intel_rapl iosf_mbi > x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi kvm_intel cfg80211 kvm > drm_kms_helper drm snd_hda_intel snd_hda_codec btusb btrtl crct10dif_pclmul > crc32_pclmul btbcm snd_hda_core ghash_clmulni_intel btintel bluetooth > snd_hwdep e1000e aesni_intel aes_x86_64 lrw snd_pcm gf128mul glue_helper > ablk_helper cryptd serio_raw alx mei_me lpc_ich usbhid mei snd_timer snd > net2280 i2c_algo_bit ptp udc_core fb_sys_fops mdio syscopyarea pps_core > sysfillrect soundcore sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp > i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw > i2c_designware_core acpi_pad lp mac_hid parport > [ 51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW > 4.3.0-rc4+ #4 > [ 51.613859] Hardware name: Gigabyte Technology Co., Ltd. > H97N-WIFI/H97N-WIFI, BIOS F7 04/21/2015 > [ 51.613860] a03e9e10 88021eb03d70 81393f5d > > [ 51.613861] 88021eb03da8 81075856 880037be4400 > 88020b3023c8 > [ 51.613862] 880037be4400 ffa1 > 88021eb03db8 > [ 51.613863] Call Trace: > [ 51.613864][] dump_stack+0x44/0x57 > [ 51.613867] [] warn_slowpath_common+0x86/0xc0 > [ 51.613868] [] warn_slowpath_null+0x1a/0x20 > [ 51.613870] [] fsg_setup+0x12a/0x170 > [usb_f_mass_storage] > [ 51.613872] [] composite_setup+0x173/0x16b0 > [libcomposite] > [ 51.613873] [] ? ktime_get+0x3a/0x90 > [ 51.613874] [] ? lapic_next_deadline+0x29/0x30 > [ 51.613875] [] ? ktime_get+0x3a/0x90 > [ 51.613877] [] net2280_irq+0xba2/0x10db [net2280] > [ 51.613879] [] handle_irq_event_percpu+0x39/0x180 > [ 51.613880] [] handle_irq_event+0x45/0x70 > [ 51.613881] [] handle_edge_irq+0x99/0x150 > [ 51.613883] [] handle_irq+0x1d/0x30 > [ 51.613883] [] do_IRQ+0x4d/0xd0 > [ 51.613885] [] common_interrupt+0x87/0x87 > [ 51.613885][] ? cpuidle_enter_state+0xb8/0x220 > [ 51.613888] [] cpuidle_enter+0x17/0x20 > [ 51.613889] [] call_cpuidle+0x32/0x60 > [ 51.613890] [] ? cpuidle_select+0x13/0x20 > [ 51.613891] [] cpu_startup_entry+0x21c/0x2e0 > [ 51.613891] [] start_secondary+0x104/0x130 > [ 51.613892] ---[ end trace bda1c37ade46c57d ]— > > I can also reliable reproduce this by connecting the USB3380 to a USB port on > the same Linux machine. > In that case I also see an error: > net2280 : net2280_enable: error=-22 > > Perhaps unrelated, but there is also a message: > configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511 The same crash happens in 4.2 as well but not in 4.1. Paul. -- 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
