Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds
On 2013年1月12日 15:48:59, Alex Riesen wrote: On Fri, Jan 11, 2013 at 10:04 PM, Alex Riesen raa.l...@gmail.com wrote: Hi, the USB stick (an Cruzer Titanium 2GB) was not recognized at any of the USB ports of this system (an System76 lemu4 laptop, XHCI device) after it was removed. If I attempt to insert it again in any of the ports (one of the two USB3, or the USB2) the led on the stick lights up shortly and if off again. There is no media detection messages in the dmesg output, only that from the first time: usb 1-1.2: new high-speed USB device number 3 using ehci-pci usb 1-1.2: New USB device found, idVendor=0781, idProduct=5408 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.2: Product: U3 Titanium usb 1-1.2: Manufacturer: SanDisk Corporation usb 1-1.2: SerialNumber: 187A3A60F1E9 scsi6 : usb-storage 1-1.2:1.0 io scheduler deadline registered (default) usb 1-1.2: USB disconnect, device number 3 The kernel is v3.8-rc3. I never had this problem in 3.7. I could almost reproduce the problem later in a simplified setup (init=/bin/bash) on USB3 ports by inserting and removing the stick quickly. Almost - because the USB3 ports recovered after some time, while the USB2 port never experienced the problem. One more detail: I usually use the noop elevator. That time it was the deadline. And I just reproduced it easily with deadline. Can you provide the output of dmesg with CONFIG_USB_DEBUG? This will be helpful. -- 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 -- Best regards Tianyu Lan -- 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] usb: gadget: move the global the_dev variable to their users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jan 10, 2013 at 12:23:49PM +0200, Felipe Balbi wrote: On Thu, Nov 08, 2012 at 07:24:13PM +0100, Sebastian Andrzej Siewior wrote: the u_ether.c file has a global variable named the_dev which keeps a pointer to the network device after it has been created via gether_setup_name(). It is only used internally by u_ether. This patches moves the variable to its users and passes it via the port.ioport where it is saved later anyway. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de care to refresh ? After tripple checking I found it :) Please look at |Subject: [PATCH 18/30] usb/gadget: move the global the_dev variable to their users |Date: Sun, 23 Dec 2012 21:10:12 +0100 |Message-Id: 1356293424-21386-19-git-send-email-bige...@linutronix.de This series should contain all pending patches which were not applied by the time of posting. Sebastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ8USOAAoJEHuW6BYqjPXRdFwP/2k7TAG/mLkaNpYIetJzZxYw H+5Qod/LqJ6yGJtMAF0KcGz6pGMARVnuhRQsc903h1WtPf52qwPfY0EMOUJAajWn nI5ngZ5g8xQbkCIT1+fviFQiN8eprDzGq5H80DpG0ZqJL1pqAqjwGNo4oLytOXkh Y1Nti1hhpKwedUpUx5Lgz3pc9XmP35pEdAd4NjN37HPTho3MqcolayWI3+6CY/S6 y9KHoSUz8kyRpnnCMXQ0VLcuJJfkT/N4vKqxqm3rAIpsoR0aAlA7uFy02Pew7Hci 4rbKF2ziVwdpr+X59VaPQBui2cBzAS9ZnPPdAd1/fG/luxwnUDgFuiGK9KgRLHwd ttuSVTh5lW/Al9whw2mqJEikttrPj8hdRBu3dFHzRRLMEmnJEHuVVF4gCgS0xmY5 McOOZnFeOpugU1mCb6pMl/PQmhrj0EkfW+SxGQROr6vbv2TKN+pZfEtmjBX+wM98 zKxDmEZYAjACPmkgfpdWr3f5wF+puJOQ+FZP1L1hAW0v0pLcFnN4XxSb24155Iid CGDgIZOpMMkQ9VMn2yL3liTrlG27EXAEGumqVMv9tyMUo+kdBvU9mes8MS6EYvou LZfUt5loTBG+z99t7OSCnj47ppKH4GROMQPdCctfz7s5CNFJNVBKT7i/fCLeBqFg 2fAMiiZ4u6cSayhfm8LI =uXk8 -END PGP SIGNATURE- -- 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: TP-LINK HSUPA Modem MA180 2357:0201
Am Mittwoch, 9. Januar 2013, 22:24:14 schrieben Sie: No further work need to be done in the kernel. Are you able to provide the Windows .INF files from the device so we can determine what kernel drivers each interface of the device requires? Basically, instead of modeswitching the device, let the fake CD disk appear, tar+gzip the contents of the fake CD, and mail it to me so I can inspect it. Diagnostics USB\VID_2357PID_0201MI_00\637BC1CE00 NMEAUSB\VID_2357PID_0201MI_01\637BC1CE01 Modem USB\VID_2357PID_0201MI_03\637BC1CE03 Networkcard USB\VID_2357PID_0201MI_04\637BC1CE04 mmc USBSTOR\CDROMVEN_TP-LINKPROD_MMC_STORAGEREV_2.31\77ED6A6108630770103305650 What specific model number is this device? Is it the MA180? Or is it the MA260? What model number is printed on the device? Does it have an FCC ID printed anywhere on it? MA180 FCC ID: T7MA180V2 IC: 8853-MA180V1 The examination at linux I will start later this day. Regards, Thomas -- 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] CDC_NCM adding support IFF_NOARP for infineon modem platform
Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I introduce
a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in driver_info:data. so later
on, if more such buggy devices are found, they could use same flag to handle.
Signed-off-by: Wei Shuai cpuw...@gmail.com
---
drivers/net/usb/cdc_ncm.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 71b6e92..6093e07 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -55,6 +55,9 @@
#defineDRIVER_VERSION 14-Mar-2012
+/* Flags for driver_info::data */
+#define CDC_NCM_DRIVER_DATA_NOARP 1
+
static void cdc_ncm_txpath_bh(unsigned long param);
static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx);
static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *hr_timer);
@@ -573,6 +576,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
return -ENODEV;
#endif
+ if (dev-driver_info-data CDC_NCM_DRIVER_DATA_NOARP) {
+ /* some buggy device cannot do ARP*/
+ dev-net-flags |= IFF_NOARP;
+ }
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
@@ -1155,6 +1162,21 @@ static const struct driver_info wwan_info = {
.tx_fixup = cdc_ncm_tx_fixup,
};
+/* Same as wwan_info, but with IFF_NOARP */
+static const struct driver_info wwan_noarp_info = {
+ .description = Mobile Broadband Network Device (NO ARP),
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET
+ | FLAG_WWAN,
+ .data = CDC_NCM_DRIVER_DATA_NOARP,
+ .bind = cdc_ncm_bind,
+ .unbind = cdc_ncm_unbind,
+ .check_connect = cdc_ncm_check_connect,
+ .manage_power = usbnet_manage_power,
+ .status = cdc_ncm_status,
+ .rx_fixup = cdc_ncm_rx_fixup,
+ .tx_fixup = cdc_ncm_tx_fixup,
+};
+
static const struct usb_device_id cdc_devs[] = {
/* Ericsson MBM devices like F5521gw */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
@@ -1194,6 +1216,13 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)wwan_info,
},
+ /* Infineon(now Intel) HSPA Modem platform */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)wwan_noarp_info,
+ },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: misc: fixup smatch WARNING
This patch fixes the warning,
6a099c63650e50ebf7d1259b859a3d230aec4207 [4/10] USB: misc: Add USB3503
High-Speed Hub Controller
drivers/usb/misc/usb3503.c:238 usb3503_probe() error: we previously assumed
'pdata' could be null (see line 196)
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
drivers/usb/misc/usb3503.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 796d58c..7bc2812 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -182,12 +182,12 @@ int usb3503_probe(struct i2c_client *i2c, const struct
i2c_device_id *id)
{
struct usb3503_platform_data *pdata = i2c-dev.platform_data;
struct usb3503 *hub;
- int err;
+ int err = -ENOMEM;
hub = kzalloc(sizeof(struct usb3503), GFP_KERNEL);
if (!hub) {
dev_err(i2c-dev, private data alloc fail\n);
- return -ENOMEM;
+ return err;
}
i2c_set_clientdata(i2c, hub);
@@ -195,6 +195,7 @@ int usb3503_probe(struct i2c_client *i2c, const struct
i2c_device_id *id)
if (!pdata) {
dev_dbg(i2c-dev, missing platform data\n);
+ goto err_out;
} else {
hub-gpio_intn = pdata-gpio_intn;
hub-gpio_connect = pdata-gpio_connect;
@@ -209,7 +210,7 @@ int usb3503_probe(struct i2c_client *i2c, const struct
i2c_device_id *id)
dev_err(i2c-dev,
unable to request GPIO %d as connect
pin (%d)\n,
hub-gpio_intn, err);
- goto err_gpio_intn;
+ goto err_out;
}
}
@@ -248,7 +249,7 @@ err_gpio_reset:
err_gpio_connect:
if (gpio_is_valid(hub-gpio_intn))
gpio_free(hub-gpio_intn);
-err_gpio_intn:
+err_out:
kfree(hub);
return err;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.8-rc1 - another regression on USB :-(
Hi, Greg, Linus, It sounds insane, but after banging on the issue I have found out that USB problem is caused (also in vanilla kernel) with a config change: USB-all built as modules - bad USB USB core built in, UHCI/EHCI modules - semi functional - but 1Mb/s transfer USB core and UHCI EHCI built-in - bingo - no issues. Could anybody duplicate that, or is it somehow my setup??? Since there was no additional reply here (needed) so far, some of my (questionably relevant?) thoughts on this: There's of course the EHCI vs. UHCI(/OHCI) duality (EHCI host controller responsible for high speed transfers, the other for 1.1 full speed, both serving the same port connectors). So if the coordination between the two is a problem, you might end up with merely full speed on a 2.0 port. And with drivers builtin vs. module, the init sequence/timing might possibly be affected - right? Perhaps this got worsened by semi-recent driver init kernel changes? (AFAIR the kernel was changed to init more things in parallel, for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing. (taking many stabs in the dark here...) I seem to have USB issues as well; for some storage devices I cannot gain high speed currently, while e.g. for USB sticks that works - and of course prior to disabling the BIOS's limit-to-1.1 setting (doh! oh my...) that was very understandable, but AFAIK it's still not reliable (maybe it's some of my local host controller troubleshooting commits... need to git revert them). Due to my woes originally being BIOS-originated I cannot provide any hard evidence about any 3.7.x vs. 3.8.x breakage timeframe. I noticed that I had PSU issues - the 5V rail was dangerously low; resoldering/cleaning the PSU helped. In your case the USB disconnects might hint at that as well - I'd recommend installing an lm-sensors configuration (or check at BIOS health page) like I did. I'm in the process of compiling a small but hopefully helpful USB troubleshooting document (voltage, EMI, ...). I'm usually more or less current (currently on -rc2 plus local commits). Andreas Mohr -- 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 v2] drivers/usb/host/uhci-* : check buffer length to avoid memory overflow
for function uhci_sprint_schedule:
the buffer len is MAX_OUTPUT: 64 * 1024, which may not be enough:
may loop UHCI_NUMFRAMES times (UHCI_NUMFRAMES is 1024)
each time of loop may get more than 64 bytes
so need check the buffer length to avoid memory overflow
this patch fix it like this:
at first, make enough room for buffering the exceeding contents
judge the contents which written whether bigger than buffer length
if bigger (the exceeding contents will be in the exceeding buffer)
break current work flow, and return.
also let the const string contents not seperated in second line.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
drivers/usb/host/uhci-debug.c | 178 +++--
drivers/usb/host/uhci-hcd.c | 31 ---
drivers/usb/host/uhci-q.c |2 +-
3 files changed, 136 insertions(+), 75 deletions(-)
diff --git a/drivers/usb/host/uhci-debug.c b/drivers/usb/host/uhci-debug.c
index fc0b0da..4557375 100644
--- a/drivers/usb/host/uhci-debug.c
+++ b/drivers/usb/host/uhci-debug.c
@@ -16,6 +16,8 @@
#include uhci-hcd.h
+#define EXTRA_SPACE1024
+
static struct dentry *uhci_debugfs_root;
#ifdef DEBUG
@@ -44,10 +46,6 @@ static int uhci_show_td(struct uhci_hcd *uhci, struct
uhci_td *td, char *buf,
char *spid;
u32 status, token;
- /* Try to make sure there's enough memory */
- if (len 160)
- return 0;
-
status = td_status(uhci, td);
out += sprintf(out, %*s[%p] link (%08x) , space, , td,
hc32_to_cpu(uhci, td-link));
@@ -64,6 +62,8 @@ static int uhci_show_td(struct uhci_hcd *uhci, struct uhci_td
*td, char *buf,
(status TD_CTRL_CRCTIMEO) ? CRC/Timeo : ,
(status TD_CTRL_BITSTUFF) ? BitStuff : ,
status 0x7ff);
+ if (out - buf len)
+ goto done;
token = td_token(uhci, td);
switch (uhci_packetid(token)) {
@@ -90,6 +90,9 @@ static int uhci_show_td(struct uhci_hcd *uhci, struct uhci_td
*td, char *buf,
spid);
out += sprintf(out, (buf=%08x)\n, hc32_to_cpu(uhci, td-buffer));
+done:
+ if (out - buf len)
+ out += sprintf(out, ...\n);
return out - buf;
}
@@ -101,8 +104,6 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
int i, nactive, ninactive;
char *ptype;
- if (len 200)
- return 0;
out += sprintf(out, urb_priv [%p] , urbp);
out += sprintf(out, urb [%p] , urbp-urb);
@@ -110,6 +111,8 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, Dev=%d , usb_pipedevice(urbp-urb-pipe));
out += sprintf(out, EP=%x(%s) , usb_pipeendpoint(urbp-urb-pipe),
(usb_pipein(urbp-urb-pipe) ? IN : OUT));
+ if (out - buf len)
+ goto done;
switch (usb_pipetype(urbp-urb-pipe)) {
case PIPE_ISOCHRONOUS: ptype = ISO; break;
@@ -128,6 +131,9 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, Unlinked=%d, urbp-urb-unlinked);
out += sprintf(out, \n);
+ if (out - buf len)
+ goto done;
+
i = nactive = ninactive = 0;
list_for_each_entry(td, urbp-td_list, list) {
if (urbp-qh-type != USB_ENDPOINT_XFER_ISOC
@@ -135,6 +141,8 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, %*s%d: , space + 2, , i);
out += uhci_show_td(uhci, td, out,
len - (out - buf), 0);
+ if (out - buf len)
+ goto tail;
} else {
if (td_status(uhci, td) TD_CTRL_ACTIVE)
++nactive;
@@ -143,10 +151,13 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
}
}
if (nactive + ninactive 0)
- out += sprintf(out, %*s[skipped %d inactive and %d active
- TDs]\n,
+ out += sprintf(out,
+ %*s[skipped %d inactive and %d active TDs]\n,
space, , ninactive, nactive);
-
+done:
+ if (out - buf len)
+ out += sprintf(out, ...\n);
+tail:
return out - buf;
}
@@ -158,10 +169,6 @@ static int uhci_show_qh(struct uhci_hcd *uhci,
__hc32 element = qh_element(qh);
char *qtype;
- /* Try to make sure there's enough memory */
- if (len 80 * 7)
- return 0;
-
switch (qh-type) {
case USB_ENDPOINT_XFER_ISOC: qtype = ISO; break;
case USB_ENDPOINT_XFER_INT: qtype = INT; break;
@@ -175,13 +182,15 @@ static int uhci_show_qh(struct uhci_hcd *uhci,
Re: Re: how to disable usb hub suspend function
On Sat, 12 Jan 2013, gavin.kx wrote: i use it on the android platform, and i can't generate the control file. what can i do ? For questions about Android, you will have to ask the Android developers. We can't help you here, sorry. 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: 回复: 回复: how to disable usb hub suspend function
On Sat, 12 Jan 2013, gavin.kx wrote: not only disable auto suspend, also disable usb suspend when system suspend. There is no way to do that. It oesn't even make sense. How can you suspend the entire system while leaving the hub at full power? 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: Linux 3.8-rc1 - another regression on USB :-(
On Saturday 12 January 2013 14:16:02 Andreas Mohr wrote: Greg, Linus, It sounds insane, but after banging on the issue I have found out that USB problem is caused (also in vanilla kernel) with a config change: USB-all built as modules - bad USB USB core built in, UHCI/EHCI modules - semi functional - but 1Mb/s transfer USB core and UHCI EHCI built-in - bingo - no issues. Could anybody duplicate that, or is it somehow my setup??? Since there was no additional reply here (needed) so far, some of my (questionably relevant?) thoughts on this: There's of course the EHCI vs. UHCI(/OHCI) duality (EHCI host controller responsible for high speed transfers, the other for 1.1 full speed, both serving the same port connectors). So if the coordination between the two is a problem, you might end up with merely full speed on a 2.0 port. And with drivers builtin vs. module, the init sequence/timing might possibly be affected - right? You should try EHCI first. This has always been true, but the likeliehood of seeing trouble is variable. This is testable. EHCI static, UHCI modular - should work EHCI modular, UHCI static - should fail Regards Oliver -- 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: USB device cannot be reconnected and khubd blocked for more than 120 seconds
On Sat, 12 Jan 2013, Alex Riesen wrote: On Fri, Jan 11, 2013 at 10:04 PM, Alex Riesen raa.l...@gmail.com wrote: Hi, the USB stick (an Cruzer Titanium 2GB) was not recognized at any of the USB ports of this system (an System76 lemu4 laptop, XHCI device) after it was removed. If I attempt to insert it again in any of the ports (one of the two USB3, or the USB2) the led on the stick lights up shortly and if off again. There is no media detection messages in the dmesg output, only that from the first time: To make testing simpler, use only the USB-2 ports. The xHCI driver is not as mature as the EHCI driver. usb 1-1.2: new high-speed USB device number 3 using ehci-pci usb 1-1.2: New USB device found, idVendor=0781, idProduct=5408 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.2: Product: U3 Titanium usb 1-1.2: Manufacturer: SanDisk Corporation usb 1-1.2: SerialNumber: 187A3A60F1E9 scsi6 : usb-storage 1-1.2:1.0 io scheduler deadline registered (default) usb 1-1.2: USB disconnect, device number 3 The kernel is v3.8-rc3. I never had this problem in 3.7. I could almost reproduce the problem later in a simplified setup (init=/bin/bash) on USB3 ports by inserting and removing the stick quickly. Almost - because the USB3 ports recovered after some time, while the USB2 port never experienced the problem. For testing, use a kernel with CONFIG_USB_DEBUG and CONFIG_PRINTK_TIME enabled. Do the following: After a normal boot, run dmesg -C to clear the log buffer. Then plug in the stick. After a couple of seconds, type Alt-SysRq-W. Then unplug the stick. After a couple of seconds, type Alt-SysRq-W again. Then collect the output from dmesg and post it. One more detail: I usually use the noop elevator. That time it was the deadline. And I just reproduced it easily with deadline. I doubt the elevator has anything to do with this. 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: USB device cannot be reconnected and khubd blocked for more than 120 seconds
On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 12 Jan 2013, Alex Riesen wrote: One more detail: I usually use the noop elevator. That time it was the deadline. And I just reproduced it easily with deadline. I doubt the elevator has anything to do with this. But it looks like it does: just using the deadline elevator is a sure way to reproduce the bug. The system always recovers (sometimes after a while) with noop. -- 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: USB device cannot be reconnected and khubd blocked for more than 120 seconds
On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 12 Jan 2013, Alex Riesen wrote: On Fri, Jan 11, 2013 at 10:04 PM, Alex Riesen raa.l...@gmail.com wrote: the USB stick (an Cruzer Titanium 2GB) was not recognized at any of the USB ports of this system (an System76 lemu4 laptop, XHCI device) after it was removed. [...] To make testing simpler, use only the USB-2 ports. The xHCI driver is not as mature as the EHCI driver. I used the USB2 port, but enabled the debugging for xHCI too, just because it is not as mature as you say, but in the same machine. And there are some traces from it, even though I didn't touch the USB3 ports. Might be unrelated, but just in case... The kernel is v3.8-rc3. I never had this problem in 3.7. I could almost For the record, I just retested: the problem persists with 3.7.1. reproduce the problem later in a simplified setup (init=/bin/bash) on USB3 ports by inserting and removing the stick quickly. Almost - because the USB3 ports recovered after some time, while the USB2 port never experienced the problem. For testing, use a kernel with CONFIG_USB_DEBUG and CONFIG_PRINTK_TIME enabled. Do the following: After a normal boot, run dmesg -C to clear the log buffer. Then plug in the stick. After a couple of seconds, type Alt-SysRq-W. Then unplug the stick. After a couple of seconds, type Alt-SysRq-W again. Then collect the output from dmesg and post it. Attached. A remount in the middle is me remounting an SATA device to save dmesg output in case the system crashes hard. dmesg2.bz2 Description: BZip2 compressed data
TP-LINK HSUPA Modem MA180 2357:0201
Here are all infos about this device. I think I catched the relevant data. Switching to modem/network-mode works with eject /dev/sr0 It works with option /dev/ttyUSB2 has accepted at-commands and qmi_wwan (in testcase with interface 1 instead of 0) I was able get an IPv4- connection via qmi-interface. I was not able to get online via IPv6. qmi-version-infos are also inside the attachment. This is, what windows says about this device: Diagnostics USB\VID_2357PID_0201MI_00\637BC1CE00 NMEAUSB\VID_2357PID_0201MI_01\637BC1CE01 Modem USB\VID_2357PID_0201MI_03\637BC1CE03 Networkcard USB\VID_2357PID_0201MI_04\637BC1CE04 mmc USBSTOR\CDROMVEN_TP-LINKPROD_MMC_STORAGEREV_2.31\77ED6A6108630770103305650 Labels at the housing: MA180 FCC ID: T7MA180V2 IC: 8853-MA180V1 Windows-software at the stick is identical to http://www.tp-link.com.de/Resources/software/MA180_V1_Easy_Setup_Assistant.zip (same md5) Thomas -- 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 tp-link-ma180.tgz Description: application/compressed-tar
Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds
On Sat, Jan 12, 2013 at 8:39 PM, Alex Riesen raa.l...@gmail.com wrote: On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 12 Jan 2013, Alex Riesen wrote: One more detail: I usually use the noop elevator. That time it was the deadline. And I just reproduced it easily with deadline. I doubt the elevator has anything to do with this. But it looks like it does: just using the deadline elevator is a sure way to reproduce the bug. The system always recovers (sometimes after a while) with noop. And no, it does not. Not by itself, but the fact that deadline elevator was compiled as module certainly helped! This explains the hanging modprobe in the dmesg output (the part after device connect). I still wonder, why didn't it froze at boot, mounting SATA devices (the root, /var, and /home are on an SSD connected by SATA)? And why hanging khubd at reboot? Anyway, building the elevator in the kernel avoids the problem. Sorry for not spotting this earlier. Now, who would be interested to handle this kind of misconfiguration ... -- 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: USB device cannot be reconnected and khubd blocked for more than 120 seconds
On Sat, 12 Jan 2013, Alex Riesen wrote: On Sat, Jan 12, 2013 at 8:39 PM, Alex Riesen raa.l...@gmail.com wrote: On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 12 Jan 2013, Alex Riesen wrote: One more detail: I usually use the noop elevator. That time it was the deadline. And I just reproduced it easily with deadline. I doubt the elevator has anything to do with this. But it looks like it does: just using the deadline elevator is a sure way to reproduce the bug. The system always recovers (sometimes after a while) with noop. And no, it does not. Not by itself, but the fact that deadline elevator was compiled as module certainly helped! This explains the hanging modprobe in the dmesg output (the part after device connect). I still wonder, why didn't it froze at boot, mounting SATA devices (the root, /var, and /home are on an SSD connected by SATA)? And why hanging khubd at reboot? Anyway, building the elevator in the kernel avoids the problem. Sorry for not spotting this earlier. Now, who would be interested to handle this kind of misconfiguration ... So the whole thing was a false alarm? Maybe you should report to the block-layer maintainers that it's possible to mess up the system by building an elevator as a module. That sounds like the sort of thing they'd be interested to hear. 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: linux-3.7.1: kmemleak reports in comm usb-storage?
On Sat, 12 Jan 2013, Martin Mokrejs wrote: Alan Stern wrote: On Fri, 11 Jan 2013, Martin Mokrejs wrote: Hi, I am not sure how should I interpret this but I am attaching the whole kmemleak file I have after # w 23:02:23 up 2 days, 2:43, 16 users, load average: 2.17, 1.85, 1.51 [cut] I have several SATA drives connected over USB 2 and 3 (and mounted) but am not accessing them. Whether or not the drives are being accessed probably doesn't matter much. The mere fact that they are connected can make a difference. Does kmemleak report the same problems after the drives are unplugged? Does the number of leaked memory regions increase if you plug in and unplug a drive repeatedly? I just plugged in one drive, unconnected, a re-connected back again. Right after that the kmemleak file did not show any changes but that is probably updated by a background process? But, after some minutes, here the are few more! I am attaching the diff showing the timestamps. Please note that the number increased once while do physical (dis)connections happened meanwhile (unless that can be explained by the time lag of the background scanning before it reports the problem): [81036.084077] kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [139512.014429] kmemleak: 11 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. 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: linux-3.7.1: kmemleak reports in comm usb-storage?
Alan Stern wrote: On Sat, 12 Jan 2013, Martin Mokrejs wrote: Alan Stern wrote: On Fri, 11 Jan 2013, Martin Mokrejs wrote: Hi, I am not sure how should I interpret this but I am attaching the whole kmemleak file I have after # w 23:02:23 up 2 days, 2:43, 16 users, load average: 2.17, 1.85, 1.51 [cut] I have several SATA drives connected over USB 2 and 3 (and mounted) but am not accessing them. Whether or not the drives are being accessed probably doesn't matter much. The mere fact that they are connected can make a difference. Does kmemleak report the same problems after the drives are unplugged? Does the number of leaked memory regions increase if you plug in and unplug a drive repeatedly? I just plugged in one drive, unconnected, a re-connected back again. Right after that the kmemleak file did not show any changes but that is probably updated by a background process? But, after some minutes, here the are few more! I am attaching the diff showing the timestamps. Please note that the number increased once while do physical (dis)connections happened meanwhile (unless that can be explained by the time lag of the background scanning before it reports the problem): [81036.084077] kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [139512.014429] kmemleak: 11 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. Now it is the only one drive connected. If I disconnect it kmemleak won't change like it did not today for many hours when all the drives were unplugged. I thought you want me to plug it in back and unplug several times. ;) So, did I answer your question now? M. -- 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] CDC_NCM adding support IFF_NOARP for infineon modem platform
From: Wei Shuai cpuw...@gmail.com Date: Sat, 12 Jan 2013 19:34:39 +0800 Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in driver_info:data. so later on, if more such buggy devices are found, they could use same flag to handle. Is it no able to do ARP or, the more likely case, does broadcast not work at all? If it's the latter, IFF_NOARP is just making over the real problem. I'm not applying this, no hardware device should set IFF_NOARP. You probably really want IFF_POINTOPOINT or similar. -- 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: Re: how to disable usb hub suspend function
if i use suspend function, the hub may occur error, if i removed the hub before suspend then can avoid the suspend? if it could, how can i do ? how to remove and add ? gavin.kx From: Alan Stern Date: 2013-01-12 23:37 To: gavin.kx CC: linux-usb Subject: Re:回复: 回复: how to disable usb hub suspend function On Sat, 12 Jan 2013, gavin.kx wrote: not only disable auto suspend, also disable usb suspend when system suspend. There is no way to do that. It oesn't even make sense. How can you suspend the entire system while leaving the hub at full power? Alan Stern ..
Re: Re: how to disable usb hub suspend function
if i use suspend function, the hub may occur error, if i removed the hub before
suspend then can avoid the suspend? if it could, how can i do ? how to remove
and add ?
gavin.kx
From: Ming Lei
Date: 2013-01-11 23:10
To: gavin.kx
CC: linux-usb
Subject: Re: how to disable usb hub suspend function
On Fri, Jan 11, 2013 at 10:16 PM, gavin.kx gavin...@qq.com wrote:
Dear sir:
i have a project that need disable usb hub suspend function, How can i do ?
Suppose you mean USB autosuspend, you can disable it by below command:
echo on /sys/bus/usb/devices/HUB-DEV/power/control
and HUB-DEV is the hub device's name.
Thanks,
--
Ming Lei
.N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
回复: Re: how to disable usb hub suspend function
and does have a way to force to remove the usb device? my hub power is supplied by battery, it can work while CPU sleep. gavin.kx 发件人： gavin.kx 发送时间： 2013-01-13 10:59 收件人： Alan Stern 抄送： linux-usb 主题： Re: Re: how to disable usb hub suspend function if i use suspend function, the hub may occur error, if i removed the hub before suspend then can avoid the suspend? if it could, how can i do ? how to remove and add ? gavin.kx From: Alan Stern Date: 2013-01-12 23:37 To: gavin.kx CC: linux-usb Subject: Re:回复: 回复: how to disable usb hub suspend function On Sat, 12 Jan 2013, gavin.kx wrote: not only disable auto suspend, also disable usb suspend when system suspend. There is no way to do that. It oesn't even make sense. How can you suspend the entire system while leaving the hub at full power? Alan Stern ..
