Re: Huawei E3131
Hi Dan and Bjorn,
thank you both for your detailed answers on this thread.
Bjørn Mork wrote:
Martin Mokrejs mmokr...@fold.natur.cuni.cz writes:
Hi Bjorn,
my have a new USB 3G modem sold in Czech Republic by T-Mobile. So
far it works for me only using the option driver and pppd. The
'qmi-network /dev/cdc-wdm0' does not work for me. Maybe it has no
QMI interface ('modprobe qmi_wwan' does not log any new device
found through dmesg but maybe that is because it is already claimed
by cdc_ncm driver)? I haven't seen the virtual CD-ROM associated
media errors with my old Huawei E372. I believe I can ignore them
but is that because of the modem firmware being ... suboptimal?
BTW, usb_modeswitch used to log that it flipped a device. Isn't
this needed anymore?
Dont' know. Your log shows that the device is switched from 12d1:15ca
to 12d1:1506. I assume that is usb_modeswitch doint its job:
you are right, I forgot it is not logged in dmesg, here are the lines from
syslog:
Aug 12 21:23:19 vostro usb_modeswitch[3541]: switch device 12d1:15ca on 001/003
Aug 12 21:23:21 vostro root[3589]: usb_modeswitch: switched to 12d1:1506 on
001/004
[ 301.850141] usb 1-1.1: new high-speed USB device number 3 using xhci_hcd
[ 301.954975] usb 1-1.1: New USB device found, idVendor=12d1, idProduct=15ca
[ 301.954989] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 301.954995] usb 1-1.1: Product: HUAWEI Mobile
[ 301.955000] usb 1-1.1: Manufacturer: HUAWEI
[ 301.955014] usb 1-1.1: SerialNumber:
[ 302.002613] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[ 302.003190] scsi host7: usb-storage 1-1.1:1.0
[ 303.016259] scsi 7:0:0:0: CD-ROMHUAWEI Mass Storage 2.31
PQ: 0 ANSI: 2
[ 303.025890] sr 7:0:0:0: [sr1] scsi-1 drive
[ 303.026802] sr 7:0:0:0: Attached scsi CD-ROM sr1
[ 303.027482] sr 7:0:0:0: Attached scsi generic sg3 type 5
[ 303.031504] scsi 7:0:0:1: Direct-Access HUAWEI TF CARD Storage 2.31
PQ: 0 ANSI: 2
[ 303.032127] sd 7:0:0:1: Attached scsi generic sg4 type 0
[ 303.049740] sd 7:0:0:1: [sdc] Attached SCSI removable disk
[ 303.106042] Buffer I/O error on dev sr1, logical block 512, async page read
[ 303.359262] usb 1-1.1: USB disconnect, device number 3
[ 304.032875] usb 1-1.1: new high-speed USB device number 4 using xhci_hcd
[ 304.137604] usb 1-1.1: New USB device found, idVendor=12d1, idProduct=1506
[ 304.137617] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 304.137624] usb 1-1.1: Product: HUAWEI Mobile
[ 304.137629] usb 1-1.1: Manufacturer: HUAWEI
[ 304.554118] huawei_cdc_ncm 1-1.1:1.1: MAC-Address: 82:a9:4a:09:84:2e
[ 304.576776] huawei_cdc_ncm 1-1.1:1.1: cdc-wdm0: USB WDM device
[ 304.577728] huawei_cdc_ncm 1-1.1:1.1 wwan0: register 'huawei_cdc_ncm' at
usb-:0b:00.0-1.1, Huawei CDC NCM device, 82:a9:4a:09:84:2e
[ 304.579135] usb-storage 1-1.1:1.4: USB Mass Storage device detected
[ 304.579425] scsi host8: usb-storage 1-1.1:1.4
[ 304.579984] usb-storage 1-1.1:1.5: USB Mass Storage device detected
[ 304.580141] scsi host9: usb-storage 1-1.1:1.5
[ 304.640300] huawei_cdc_ncm 1-1.1:1.1 wwp11s0u1u1i1: renamed from wwan0
And the last part here shows that your modem has a Huawei specific NCM
interface, handled by the huawei_cdc_ncm driver. This is not a QMI
modem.
The huawei_cdc_ncm driver also provides a /dev/cdc-wdm0 device, but this
device speaks AT commands, not QMI. You can use the /dev/cdc-wdm0
device with Huawei specific commands like AT^NDISDUP etc. Google that
or use a ModemManager supporting it (not sure about the status here,
though...).
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 22
iInterface 8 CDC Network Control Model (NCM)
The string descriptor is right. 255/2/22 is one of the
class/subclass/protocol sets Huawei use for their vendor specific NCM
variants.
OK, thank you, so I will stay with pppd talking to ttyUSB0 at 460800 baudrate.
It
is puzzling Huawei sells a different hardware. I thought I could go with my old
setup for Huawei E372 ..., well does not really matter.
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Huawei E3131
Hi Bjorn,
my have a new USB 3G modem sold in Czech Republic by T-Mobile. So far it
works for me only using the option driver and pppd. The 'qmi-network
/dev/cdc-wdm0' does not work for me. Maybe it has no QMI interface ('modprobe
qmi_wwan' does not log any new device found through dmesg but maybe that is
because it is already claimed by cdc_ncm driver)? I haven't seen the virtual
CD-ROM associated media errors with my old Huawei E372. I believe I can ignore
them but is that because of the modem firmware being ... suboptimal? BTW,
usb_modeswitch used to log that it flipped a device. Isn't this needed anymore?
Here is what is logged on linux-4.1.3 kernel:
# lsmod
...
ppp_async 8045 0
ppp_generic30220 1 ppp_async
slhc5971 1 ppp_generic
option 37732 0
usb_wwan8415 1 option
usb_storage57183 3 uas,ums_realtek
#
# gzip -dc /proc/config.gz | grep -i USB_NET
CONFIG_USB_NET_DRIVERS=y
# CONFIG_USB_NET_AX8817X is not set
# CONFIG_USB_NET_AX88179_178A is not set
# CONFIG_USB_NET_CDCETHER is not set
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
CONFIG_USB_NET_HUAWEI_CDC_NCM=y
CONFIG_USB_NET_CDC_MBIM=y
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SR9700 is not set
# CONFIG_USB_NET_SR9800 is not set
# CONFIG_USB_NET_SMSC75XX is not set
# CONFIG_USB_NET_SMSC95XX is not set
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
CONFIG_USB_NET_QMI_WWAN=m
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
#
[ 301.850141] usb 1-1.1: new high-speed USB device number 3 using xhci_hcd
[ 301.954975] usb 1-1.1: New USB device found, idVendor=12d1, idProduct=15ca
[ 301.954989] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 301.954995] usb 1-1.1: Product: HUAWEI Mobile
[ 301.955000] usb 1-1.1: Manufacturer: HUAWEI
[ 301.955014] usb 1-1.1: SerialNumber:
[ 302.002613] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[ 302.003190] scsi host7: usb-storage 1-1.1:1.0
[ 303.016259] scsi 7:0:0:0: CD-ROMHUAWEI Mass Storage 2.31
PQ: 0 ANSI: 2
[ 303.025890] sr 7:0:0:0: [sr1] scsi-1 drive
[ 303.026802] sr 7:0:0:0: Attached scsi CD-ROM sr1
[ 303.027482] sr 7:0:0:0: Attached scsi generic sg3 type 5
[ 303.031504] scsi 7:0:0:1: Direct-Access HUAWEI TF CARD Storage 2.31
PQ: 0 ANSI: 2
[ 303.032127] sd 7:0:0:1: Attached scsi generic sg4 type 0
[ 303.049740] sd 7:0:0:1: [sdc] Attached SCSI removable disk
[ 303.106042] Buffer I/O error on dev sr1, logical block 512, async page read
[ 303.359262] usb 1-1.1: USB disconnect, device number 3
[ 304.032875] usb 1-1.1: new high-speed USB device number 4 using xhci_hcd
[ 304.137604] usb 1-1.1: New USB device found, idVendor=12d1, idProduct=1506
[ 304.137617] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 304.137624] usb 1-1.1: Product: HUAWEI Mobile
[ 304.137629] usb 1-1.1: Manufacturer: HUAWEI
[ 304.554118] huawei_cdc_ncm 1-1.1:1.1: MAC-Address: 82:a9:4a:09:84:2e
[ 304.576776] huawei_cdc_ncm 1-1.1:1.1: cdc-wdm0: USB WDM device
[ 304.577728] huawei_cdc_ncm 1-1.1:1.1 wwan0: register 'huawei_cdc_ncm' at
usb-:0b:00.0-1.1, Huawei CDC NCM device, 82:a9:4a:09:84:2e
[ 304.579135] usb-storage 1-1.1:1.4: USB Mass Storage device detected
[ 304.579425] scsi host8: usb-storage 1-1.1:1.4
[ 304.579984] usb-storage 1-1.1:1.5: USB Mass Storage device detected
[ 304.580141] scsi host9: usb-storage 1-1.1:1.5
[ 304.640300] huawei_cdc_ncm 1-1.1:1.1 wwp11s0u1u1i1: renamed from wwan0
[ 304.843014] usbcore: registered new interface driver option
[ 304.843433] usbserial: USB Serial support registered for GSM modem (1-port)
[ 304.843550] option 1-1.1:1.0: GSM modem (1-port) converter detected
[ 304.844256] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB0
[ 304.844361] option 1-1.1:1.2: GSM modem (1-port) converter detected
[ 304.844661] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB1
[ 304.844694] option 1-1.1:1.3: GSM modem (1-port) converter detected
[ 304.844987] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB2
[ 305.589216] scsi 9:0:0:0: Direct-Access HUAWEI TF CARD Storage 2.31
PQ: 0 ANSI: 2
[ 305.589671] scsi 8:0:0:0: CD-ROMHUAWEI Mass Storage 2.31
PQ: 0 ANSI: 2
[ 305.592228] sr 8:0:0:0: [sr1] scsi-1 drive
[ 305.592488] sd 9:0:0:0: Attached scsi generic sg3 type 0
[ 305.598458] sr 8:0:0:0: Attached scsi CD-ROM sr1
[ 305.599261] sr 8:0:0:0: Attached scsi generic sg4 type 5
[ 305.599643] sd 9:0:0:0: [sdc] Attached SCSI removable disk
[ 305.656874] sr 8:0:0:0: [sr1] FAILED Result: hostbyte=DID_OK
Re: [RFT 2/2] xhci: Disable D3cold for buggy TI redrivers.
Hi Sarah and Alan,
I am curious whether the the PME- to PME+ happening on a suspended
TI host controller could be used as some hack to signal the mis-behaving
redriver. Could such transition be used as a trigger for linux kernel to
wakeup the TI host manually? I am referring to step 4. of my test
in http://marc.info/?l=linux-acpim=136735488916468w=3 showing the
suspended TI controller (in step 3) is not completely dead and at least
some part of it gets power enabled (PME+) as a result of port status change
event (mouse connect):
quote
4. Interestingly, if I connect a mouse to the socket to show it is dead there
is a tiny change in lspci:
---
lspci_vvv_initial__1c.4_and_0b:00_to_auto__mouse_attached_and_works__detached.txt
2013-04-20 01:10:06.0 +0200
+++
lspci_vvv_initial__1c.4_and_0b:00_to_auto__mouse_attached_and_works__detached__reattached_but_dead.txt
2013-04-20 01:10:28.0 +0200
@@ -491,7 +491,7 @@
Region 2: Memory at f7d1 (64-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
- Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
+ Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME+
Capabilities: [48] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: Data:
Capabilities: [70] Express (v2) Endpoint, MSI 00
/quote
The suspended TI host controller was in PME- state. A mouse connect to the
xHCI port resulted in deadly suspend (TI host now in PME+) or maybe I could
better say it was woken up only partially (mouse gets NO power whereas the PCI
device DOES get its power (PME+)? I used to say a deadly suspend happened
but after I realized this PME- to PME+ change I thing the situation is not that
bad for us, users.
sure, the mouse still does not get power at step 4. (mouse red light is off)
but if this PME- to PME+ could be used a a sign for the broken redriver, I wish
linux could do
echo on /sys/bus/pci/devices/\:0b\:00.0/power/control
for me automatically, right?
I remember the initial posting in May 2012:
http://markmail.org/message/n3qbgspt76yyxvky
Workaround required for Texas Instruments USB3 re-driver
while I have now realized that there was an on ongoing discussion later on:
http://marc.info/?l=linux-kernelm=134402069909506w=2
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
I propose you add relevant URLs to the patch.
Martin
P.S.: Have Dell Vostro 3550 with likely the broken redriver but did not
physically crack the laptop, sorry.
Sarah Sharp wrote:
Some xHCI hosts contain a redriver from TI that silently drops port
status connect changes if the port slips into Compliance Mode. If the
port slips into compliance mode while the host is in D0, there will not
be a port status change event. If the port slips into compliance mode
while the host is in D3, the host will not send a PME. This includes
when the system is suspended (S3) or hibernated (S4).
If this happens when the system is in S3/S4, there is nothing software
can do. Other port status change events that would normally cause the
host to wake the system from S3/S4 may also be lost. This includes
remote wakeup, disconnects and connects on other ports, and overrcurrent
events. A decision was made to _NOT_ disable system suspend/hibernate
on these systems, since users are unlikely to enable wakeup from S3/S4
for the xHCI host.
Software can deal with this issue when the system is in S0. A work
around was put in to poll the port status registers for Compliance Mode.
The xHCI driver will continue to poll the registers while the host is
runtime suspended. Unfortunately, that means we can't allow the PCI
device to go into D3cold, because power will be removed from the host,
and the config space will read as all Fs.
Disable D3cold in the xHCI PCI runtime suspend function.
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: Huang Ying ying.hu...@intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c |8
drivers/usb/host/xhci.c |4 ++--
drivers/usb/host/xhci.h |3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1a30c38..cc24e39 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -221,6 +221,14 @@ static void xhci_pci_remove(struct pci_dev *dev)
static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct pci_dev *pdev = to_pci_dev(hcd-self.controller);
+
+ /*
+ * Systems with the
Re: USB 3 to SATA ASM1042 dies under I/O load
Hi Stefan, I can only tell you that I had success with ASM1051 on the drive side (SilverStone Treasure TS04) against both NEC uPD720200 (rev. 3) controller and TI controller on the computer side. But ASM1051 does not propagate S.M.A.R.T. values back from the drive. Once I had a bad firmware in ASM2105 in SilverStone Treasure TS04B. That one I returned. I am happy with 4 pcs of Manhattan Superspeed USB to SATA adapter giving me each 150MB/s, working with 2.7TiB Seagate SV35 and Barracuda drives despite the fact the retail box claims the adapter support 48-bit addressing up to 2TB drives only. gdisk shows the drives report 512B sectors while should be physically 4kB sector drives. I am handling files of up to 250GB and shuffling data between 5 such drives. When things work on my laptop through one 2-port XHCI TexasInstruments-based controller, 1 eSATA port of SandyBridge and 2-port XHCI NEC-based express card I can read/write between all the drives (including writes to /dev/null) to total 2.5Gbps as shown by vmstat. From each single SATAIII drive I can get stably 140-150MBps with 5 drives I could not saturate the system throughput (well, just reads and writes to /dev/null as I said). A chase for working USB3 to SATA converters might take you to http://forums.whirlpool.net.au/archive/1558885 and from there to https://docs.google.com/spreadsheet/ccc?key=0AqniL4H-VGJSdEJPZTNjbFlEWlFEbU5adnFYRFRxeFE I have added some items to the table and also am attaching my old benchmarks. Maybe check if your express card works quickly enough? Maybe play with tehse kernel command line pci=option,option2,... parameters (from kernel-parameters.txt file): pcie_bus_tune_off Disable PCIe MPS (Max Payload Size) tuning and use the BIOS-configured MPS defaults. pcie_bus_safe Set every device's MPS to the largest value supported by all devices below the root complex. pcie_bus_perf Set device MPS to the largest allowable MPS based on its parent bus. Also set MRRS (Max Read Request Size) to the largest supported value (no larger than the MPS that the device or bus can support) for best performance. pcie_bus_peer2peer Set every device's MPS to 128B, which every device is guaranteed to support. This configuration allows peer-to-peer DMA between any pair of devices, possibly at the cost of reduced performance. This also guarantees that hot-added devices will work. Martin Stephan Diestelhorst wrote: Hi, I am using a salvaged (from an external Toshiba spinning disk) SATA - USB 3 adaptor with a VLI701-04 chip behind a ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (ExpressCard slot). I have attached a Samsung sereis 840 SSD and whenever I dd some data onto the disk, the drive disconnects and then reconnects as a different /dev/sd*. Running 3.9 kernel (also happened with an older one). I know that I should not reuse that controller for such high bandwidth operation, but maybe there is a tweak (using USB 2 works, but I was hoping to get more than 30 MB/s from this thing ;-) to make it work? Many thanks for pointers! Stephan lspci -vv 05:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 [XHCI]) Subsystem: Device 174c:2104 Physical Slot: 3 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at f1f0 (64-bit, non-prefetchable) [size=32K] Capabilities: access denied Kernel driver in use: xhci_hcd lsusb -vv Bus 010 Device 005: ID 0480:a009 Toshiba America Info. Systems, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0480 Toshiba America Info. Systems, Inc. idProduct 0xa009 bcdDevice 37.10 iManufacturer 1 TOSHIBA iProduct2 External USB 3.0 iSerial 3 290118E5 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 44 bNumInterfaces 1 bConfigurationValue 1 iConfiguration
linux-next-20130501: INFO: HARDIRQ-safe - HARDIRQ-unsafe lock order detected
Hi,
I was asked due to some HDMI/i915 bug to test
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs/tags/next-20130501
and it is failing badly on my Dell Vostro 3550 in usb. Please refer tot he full
dmesg at
https://bugs.freedesktop.org/attachment.cgi?id=78738
(which is attached to a i915 bug
https://bugs.freedesktop.org/show_bug.cgi?id=64133).
Here is a relevant snippet from dmesg.
[5.204810] usbhid 2-1.2.3:1.0: usb_probe_interface
[5.204815] usbhid 2-1.2.3:1.0: usb_probe_interface - got id
[5.213159] input: CHICONY USB Keyboard as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/2-1.2.3/2-1.2.3:1.0/input/input12
[5.213516] ==
[5.213624] [ INFO: HARDIRQ-safe - HARDIRQ-unsafe lock order detected ]
[5.213733] 3.9.0-next-20130501-default #1 Not tainted
[5.213836] --
[5.213943] khubd/543 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[5.214049] (hdev-debug_list_lock){+.+...}, at: [8149733d]
hid_debug_event+0x28/0xca
[5.214385]
and this task is already holding:
[5.214541] ((usbhid-lock)-rlock){-.}, at: [814a1cf8]
usb_hidinput_input_event+0x94/0xd1
[5.214876] which would create a new lock dependency:
[5.214980] ((usbhid-lock)-rlock){-.} -
(hdev-debug_list_lock){+.+...}
[5.215375]
but this new dependency connects a HARDIRQ-irq-safe lock:
[5.215534] ((usbhid-lock)-rlock){-.}
... which became HARDIRQ-irq-safe at:
[5.215819] [810c711b] __lock_acquire+0x2c2/0xe7e
[5.215969] [810c80e2] lock_acquire+0x82/0x98
[5.216114] [81635b28] _raw_spin_lock+0x2c/0x3b
[5.216262] [814a1f1e] hid_ctrl+0x32/0x14b
[5.216408] [813c1195] usb_hcd_giveback_urb+0x75/0xbc
[5.216558] [813d6452] ehci_urb_done+0x79/0x8c
[5.216705] [813d6887] qh_completions+0x422/0x490
[5.216851] [813d8d0d] ehci_work+0x8d/0x689
[5.216996] [813d9702] ehci_irq+0x373/0x3b9
[5.217141] [813c0733] usb_hcd_irq+0x33/0x5b
[5.217288] [810e07aa] handle_irq_event_percpu+0x2a/0x12a
[5.217438] [810e08e6] handle_irq_event+0x3c/0x5e
[5.217582] [810e2f25] handle_fasteoi_irq+0x7a/0xb0
[5.217729] [81004212] handle_irq+0x1a/0x24
[5.217874] [81003ef7] do_IRQ+0x48/0xa0
[5.218016] [8163642f] ret_from_intr+0x0/0x13
[5.218162] [8147b537] cpuidle_idle_call+0xc4/0x114
[5.218311] [81009e8f] arch_cpu_idle+0x9/0x15
[5.218455] [810bd7e7] cpu_startup_entry+0x97/0xf8
[5.218603] [8161f033] rest_init+0xb7/0xbe
[5.218747] [81a52cc0] start_kernel+0x378/0x385
[5.218894] [81a52485] x86_64_start_reservations+0x2a/0x2c
[5.219043] [81a52554] x86_64_start_kernel+0xcd/0xd1
[5.219191]
to a HARDIRQ-irq-unsafe lock:
[5.219345] (hdev-debug_list_lock){+.+...}
... which became HARDIRQ-irq-unsafe at:
[5.219630] ... [810c718a] __lock_acquire+0x331/0xe7e
[5.219816] [810c80e2] lock_acquire+0x82/0x98
[5.219961] [81633fff] __mutex_lock_common+0x4c/0x37e
[5.220108] [81634390] mutex_lock_nested+0x16/0x18
[5.220252] [8149733d] hid_debug_event+0x28/0xca
[5.220398] [81497722] hid_dump_input+0x5f/0x88
[5.220543] [81499910] hid_set_field+0x37/0xc2
[5.220689] [814a23fc] usbhid_set_leds+0x7a/0x8d
[5.220834] [814a307f] usbhid_start+0x40d/0x47c
[5.220979] [8149a89e] hid_device_probe+0xc4/0x14a
[5.221125] [81346b72] driver_probe_device+0x99/0x1c7
[5.221272] [81346d34] __device_attach+0x25/0x38
[5.221418] [8134518f] bus_for_each_drv+0x4f/0x8b
[5.221565] [81346a9c] device_attach+0x66/0x87
[5.221709] [81346062] bus_probe_device+0x30/0xa8
[5.221855] [813447d8] device_add+0x3ff/0x5d2
[5.222001] [8149a4f3] hid_add_device+0x208/0x247
[5.222146] [814a1a20] usbhid_probe+0x3f6/0x43f
[5.91] [813c7006] usb_probe_interface+0x17e/0x214
[5.222438] [81346b72] driver_probe_device+0x99/0x1c7
[5.222584] [81346d34] __device_attach+0x25/0x38
[5.222731] [8134518f] bus_for_each_drv+0x4f/0x8b
[5.222877] [81346a9c] device_attach+0x66/0x87
[5.223021] [81346062] bus_probe_device+0x30/0xa8
[5.223167] [813447d8] device_add+0x3ff/0x5d2
[5.223313] [813c593d] usb_set_configuration+0x63d/0x69e
[5.223461] [813cd8f0] generic_probe+0x40/0x74
[5.223609] [813c70e3] usb_probe_device+0x47/0x5a
[5.223754] [81346b72] driver_probe_device+0x99/0x1c7
[5.223900] [81346d34] __device_attach+0x25/0x38
Re: xhci_hcd 0000:11:00.0: HW died, polling stopped.
Alan Stern wrote: On Wed, 1 May 2013, Martin Mokrejs wrote: Sarah Sharp wrote: The HW died, polling stopped message is harmless. It happens when the xHCI host goes into a PCI low power state (D3). When the PCI host goes into D3cold, the registers will read as all Fs, and the polling loop will mistakenly believe the hardware has been removed. However, this bug only effects the debug code. It does not effect any other part of the xHCI driver. I think I do not mind it affects just the XHCI_DEBUG stuff. I just refer to those places in the source code where something else *could* happen: a detection of a silently ejected or dead hardware. I really did unplug the express card providing second USB3.0 controller (11:00). My point was that although pciehp did not propagate the hot eject to downstream drivers (xhci_hcd) I believe xhci_hcd could have realized it by itself because it does polling time to time and this, albeit debugging code, shows where roughly something more clever could happen. Ideally in place of the HC error bitmask = 0x4 (due to un-notified hot removal) or at least at the time when HW died, polling stopped was printed (un-notified hot-reinsert) xhci_hcd could realize a device is gone. That's not how drivers work in Linux. They don't unbind all by themselves; they wait until the bus-level code tells them to unbind. xhci-hcd is not alone in this respect; all the drivers behave this way. I don't believe that. From my tests only the USB3 express card suffered the problem unlike firewire_ohci and sata_sil24 -based cards. Do you remember the thread https://lkml.org/lkml/2012/4/16/566 ... where about 60 sec timeout was needed to have usb working again? I think I saw meanwhile other talking about 30 sec delay but I believe this would all be easier if xhci_hcd did unbind itself from a dead device. I am naively thinking that PCI has no way to detect a card was hot unplugged if e.g. hotplug was completely left out of a kernel .config or when acpiphp/pciehp don't work, for whatever reason. But, xhci_hcd has the unique advantage that it does polling and it know the device is dead. Probably same applies to uhci/ehci. I just don't believe if an upper level realizes a problem why it could not take an action. Other drivers probably don't do polling, by design, so they are in another situation. So what can be done so that the user does not have to run echo 1 /sys/bus/pci/devices/:11:00.0/remove manually? Couldn't xhci_hcd detect somehow that the device is dead or ejected? It could detect that the device is dead. In fact, it probably detects that now. But even if it could tell that the device had been ejected, it would not unbind itself. What can be done is to fix the PCIe core code so that it correctly realizes when an eject takes place. I believe once that will be fixed as I found that pciehp is broken in its action by pcie_aspm=off whereas it works when pcie_aspm=native. That in turn points to bad ASPM L0/L1 handling and seems similar to issues others had with PCIe LnkCtl on iwlwifi. That is somehow related to those OSC_ trickeries in acpi. Finally, seems other hit ASPM issues with Dell Vostro laptops. :( This will all hopefully get fixed. But I want usb fix as well. ;-) Martin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
xhci_hcd 0000:11:00.0: HW died, polling stopped.
Hi, I just tried 3.9 kernel with pcie_aspm=off and in another attempt with pcie_aspm=native. I realized the message HW died happens only in the former case. I believe this is a bug. If I unplug an express card with a NEC-based USB3 host it should be properly terminated, and xhci_hcd should unbind *even* when HW died happened. It is not the case now so I have to do: echo 1 /sys/bus/pci/devices/:11:00.0/remove to get rid of the stale 11:00 device from my system (sysfs entries): /proc/iomem f1104000-f1104fff : r8169 f680-f6bf : :00:02.0 f6c0-f7cf : PCI Bus :11 -f6c0-f6c01fff : :11:00.0 - f6c0-f6c01fff : xhci_hcd f7d0-f7df : PCI Bus :0b f7d0-f7d0 : :0b:00.0 f7d0-f7d0 : xhci_hcd /proc/interrupts: - 45: 1 0 PCI-MSI-edge xhci_hcd - 46: 0 0 PCI-MSI-edge xhci_hcd - 47: 0 0 PCI-MSI-edge xhci_hcd Let's say that when pcie_aspm=off the first hot eject of the express card with the USB3.0 controller does not result in HW died but in HC error bitmask = 0x4, whatever that means. That is because of pciehp being broken under pcie_aspm=off (unlike under pcie_aspm=native) but is not the story for linux-usb. [ 62.960729] xhci_hcd :0b:00.0: Poll event ring: 4294943584 [ 62.960732] xhci_hcd :11:00.0: Poll event ring: 4294943584 [ 62.960757] xhci_hcd :11:00.0: op reg status = 0x0 [ 62.960763] xhci_hcd :11:00.0: ir_set 0 pending = 0x2 [ 62.960764] xhci_hcd :11:00.0: HC error bitmask = 0x4 [ 62.960765] xhci_hcd :11:00.0: Event ring: [ 62.960768] xhci_hcd :11:00.0: @d6020400 d602 01003028 c001 [ 62.960769] xhci_hcd :0b:00.0: op reg status = 0x0 [ 62.960771] xhci_hcd :11:00.0: @d6020410 [ 62.960772] xhci_hcd :11:00.0: @d6020420 [ 62.960773] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 [ 62.960775] xhci_hcd :11:00.0: @d6020430 [ 62.960776] xhci_hcd :0b:00.0: HC error bitmask = 0x0 [ 62.960777] xhci_hcd :11:00.0: @d6020440 The kernel is still looking for the device, silly, the device is ejected from the express card slot already: +[ 62.961160] xhci_hcd :11:00.0: // xHC command ring deq ptr low bits + flags = @0008 +[ 62.961161] xhci_hcd :11:00.0: // xHC command ring deq ptr high bits = @ A subsequent hot re-insert of the card is unnoticed by pciehp (due to a bug cause by pcie_aspm=off) and therefore, xhci_hcd is puzzled and spits out: +[ 123.191537] xhci_hcd :0b:00.0: Poll event ring: 4294949600 +[ 123.191547] xhci_hcd :11:00.0: Poll event ring: 4294949600 +[ 123.191557] xhci_hcd :11:00.0: op reg status = 0x +[ 123.191563] xhci_hcd :0b:00.0: op reg status = 0x0 +[ 123.191570] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 +[ 123.191574] xhci_hcd :11:00.0: HW died, polling stopped. +[ 123.191580] xhci_hcd :0b:00.0: HC error bitmask = 0x0 At this step xhci_hcd should unbind the dead device so that it's sysfs entries could be removed (bot iomem and interrupts). If that doe not happen or is not done manually a subsequent hot insert has no chance to succeed and will silently proceed but device is left unconfigured and sysfs entries show just crappy cached values. This can be demonstrated when a desperate users inserts a different express card (a mixture of both is shown in lspci entries but only the old data in sysfs entries). Lets cleanup the mess and ensure xhci_hcd releases resources allocated by the dead device. I speculate the HC error bitmask = 0x4 should result in a HW died case as well. Thank you, Martin P.S.: Collected dmesg/lspci/iomem/interrupts data are at: http://195.113.57.32/~mmokrejs/tmp/20130430.tar.bz2 in 3.9/off subdirectory (the pcie_aspm=off case). The working pcie_aspm=native behavior is documented under 3.9/native subdirectory. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci_hcd 0000:11:00.0: HW died, polling stopped.
Sarah Sharp wrote: The HW died, polling stopped message is harmless. It happens when the xHCI host goes into a PCI low power state (D3). When the PCI host goes into D3cold, the registers will read as all Fs, and the polling loop will mistakenly believe the hardware has been removed. However, this bug only effects the debug code. It does not effect any other part of the xHCI driver. I think I do not mind it affects just the XHCI_DEBUG stuff. I just refer to those places in the source code where something else *could* happen: a detection of a silently ejected or dead hardware. I really did unplug the express card providing second USB3.0 controller (11:00). My point was that although pciehp did not propagate the hot eject to downstream drivers (xhci_hcd) I believe xhci_hcd could have realized it by itself because it does polling time to time and this, albeit debugging code, shows where roughly something more clever could happen. Ideally in place of the HC error bitmask = 0x4 (due to un-notified hot removal) or at least at the time when HW died, polling stopped was printed (un-notified hot-reinsert) xhci_hcd could realize a device is gone. Are we talking about the same? And is the express card with NEC chip allowed to enter D3cold at all? pcie_aspm=off: [1.680882] pci :00:1c.7: PME# supported from D0 D3hot D3cold [1.680888] pci :00:1c.7: PME# disabled [1.724471] pci :11:00.0: PME# supported from D0 D3hot [1.724481] pci :11:00.0: PME# disabled pcie_aspm=native: [1.681021] pci :00:1c.7: PME# supported from D0 D3hot D3cold [1.681027] pci :00:1c.7: PME# disabled [1.753353] pci :11:00.0: PME# supported from D0 D3hot [1.753363] pci :11:00.0: PME# disabled Please disregard the HW died, polling stopped messages in dmesg. So what can be done so that the user does not have to run echo 1 /sys/bus/pci/devices/:11:00.0/remove manually? Couldn't xhci_hcd detect somehow that the device is dead or ejected? Sarah Sharp Thank you, Martin On Wed, May 01, 2013 at 01:07:48AM +0200, Martin Mokrejs wrote: Hi, I just tried 3.9 kernel with pcie_aspm=off and in another attempt with pcie_aspm=native. I realized the message HW died happens only in the former case. I believe this is a bug. If I unplug an express card with a NEC-based USB3 host it should be properly terminated, and xhci_hcd should unbind *even* when HW died happened. It is not the case now so I have to do: echo 1 /sys/bus/pci/devices/:11:00.0/remove to get rid of the stale 11:00 device from my system (sysfs entries): /proc/iomem f1104000-f1104fff : r8169 f680-f6bf : :00:02.0 f6c0-f7cf : PCI Bus :11 -f6c0-f6c01fff : :11:00.0 - f6c0-f6c01fff : xhci_hcd f7d0-f7df : PCI Bus :0b f7d0-f7d0 : :0b:00.0 f7d0-f7d0 : xhci_hcd /proc/interrupts: - 45: 1 0 PCI-MSI-edge xhci_hcd - 46: 0 0 PCI-MSI-edge xhci_hcd - 47: 0 0 PCI-MSI-edge xhci_hcd Let's say that when pcie_aspm=off the first hot eject of the express card with the USB3.0 controller does not result in HW died but in HC error bitmask = 0x4, whatever that means. That is because of pciehp being broken under pcie_aspm=off (unlike under pcie_aspm=native) but is not the story for linux-usb. [ 62.960729] xhci_hcd :0b:00.0: Poll event ring: 4294943584 [ 62.960732] xhci_hcd :11:00.0: Poll event ring: 4294943584 [ 62.960757] xhci_hcd :11:00.0: op reg status = 0x0 [ 62.960763] xhci_hcd :11:00.0: ir_set 0 pending = 0x2 [ 62.960764] xhci_hcd :11:00.0: HC error bitmask = 0x4 [ 62.960765] xhci_hcd :11:00.0: Event ring: [ 62.960768] xhci_hcd :11:00.0: @d6020400 d602 01003028 c001 [ 62.960769] xhci_hcd :0b:00.0: op reg status = 0x0 [ 62.960771] xhci_hcd :11:00.0: @d6020410 [ 62.960772] xhci_hcd :11:00.0: @d6020420 [ 62.960773] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 [ 62.960775] xhci_hcd :11:00.0: @d6020430 [ 62.960776] xhci_hcd :0b:00.0: HC error bitmask = 0x0 [ 62.960777] xhci_hcd :11:00.0: @d6020440 The kernel is still looking for the device, silly, the device is ejected from the express card slot already: +[ 62.961160] xhci_hcd :11:00.0: // xHC command ring deq ptr low bits + flags = @0008 +[ 62.961161] xhci_hcd :11:00.0: // xHC command ring deq ptr high bits = @ A subsequent hot re-insert of the card is unnoticed by pciehp (due to a bug cause by pcie_aspm=off) and therefore, xhci_hcd is puzzled and spits out: +[ 123.191537] xhci_hcd :0b:00.0: Poll event ring
Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled
Hi Sarah, in this particular thread, the USB3 socket of the laptop works once I plugin a device. When I unplug it and insert same or another device it appears to be dead until I use 'lsusb -vvv'. After that, I see in dmesg the two lines: [ 1445.597641] pcieport :00:1c.4: PME# disabled [ 1445.617667] xhci_hcd :0b:00.0: PME# disabled That's the whole story. Thank you, Martin Sarah Sharp wrote: Hi Martin, I'm really having trouble following you here. Please don't try to tell me what you think the root cause of the issue is. Just tell me exactly (in a paragraph or less) what your symptoms are. Sending lots of log files and lsusb output at me isn't helpful if I don't know what your issue is. Sarah Sharp On Thu, Mar 14, 2013 at 06:30:53PM +0100, Martin Mokrejs wrote: [resend, no dmesg attached] Hi, happened to me again that I plugged in some devcie into my USB3 socket in my laptop (usually use an external HUB). Don't believe this is a new issue as a whole, I am facing this time to time since 3.3 time when I bought the laptop. But now, I realized the first device works but subsequently plugged in devices do not show up until until I run 'lsusb -vv'. Simple 'lsusb -v' or 'lsusb -t' is not enough. The port starts to work after dmesg logs: [ 1445.597641] pcieport :00:1c.4: PME# disabled [ 1445.617667] xhci_hcd :0b:00.0: PME# disabled I believe lsusb -vv while querying for the detailed device info triggers a fix. Funny, but maybe this will help us to understand why my express card slot somehow relates to the USB3 proivided by the TexasInstruments chip. This is a SandyBridge-based Dell Vostro 3550 laptop. I should add that on the usb mailing list about a year ago some TexasInstruments developer published that they had a hardware bug in a USB redriver, and as my laptop was made in fall 2011 I am likely having having the buggy HW. If I remember right, the report was about the problem that once you pluging a USB2 device into the XHCI slot, subsequently plugged in USB3 devices won't negotiate at SuperSpeed until you power off computer. So, I think I face a different issue but had to mention this. I use pcie_aspm=off on my kernel command line. I tried to catch some usb traffic on the dead port but the file from usbmon is really empty until I do the 'lsusb -vv'. I tried to turn off the usb powersaving at runtime but I do not have the file to do: # echo -n -1 /sys/bus/usb/devices/3-0\:1.0/power/autosuspend :( # ls -la /sys/bus/usb/devices/3-0\:1.0/power/ total 0 drwxr-xr-x 2 root root0 Mar 14 13:11 . drwxr-xr-x 6 root root0 Mar 14 13:58 .. -rw-r--r-- 1 root root 4096 Mar 14 13:11 async -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_active_kids -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_enabled -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_status -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_usage # I feel related could be patches under thread: usb: add usb port auto power off mechanism Below is a dmesg since a cold boot. I plugged in a mouse into the USB3 socket. [ 91.463285] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0 [ 91.463377] xhci_hcd :0b:00.0: PME# enabled [ 447.389700] xhci_hcd :0b:00.0: PME# disabled [ 447.389711] xhci_hcd :0b:00.0: enabling bus mastering [ 447.389787] xhci_hcd :0b:00.0: hcd_pci_runtime_resume: 0 [ 447.389819] usb usb3: usb wakeup-resume Was detected. Unplugged the mouse. [ 459.600056] usb 3-2: USB disconnect, device number 2 [ 459.600058] usb 3-2: unregistering device [ 459.600059] usb 3-2: unregistering interface 3-2:1.0 [ 459.600622] xhci_hcd :0b:00.0: shutdown urb 88040a641870 ep1in-intr [ 459.702564] usb 3-2: usb_disable_device nuking all URBs [ 459.707948] usb 3-2: Successful Endpoint Configure command [ 459.860892] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 [ 459.860910] hub 3-0:1.0: hub_suspend [ 459.860917] usb usb3: bus auto-suspend, wakeup 1 [ 459.860981] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0 [ 459.861070] xhci_hcd :0b:00.0: PME# enabled Then I put the mouse back, I think it was not detected after until I did the lsusb trick. I am not sure, sorry, but is not that important. I was repeating test once again and just forgot now this detail. So below just that the mouse got detected, either thanks to lsusb -vv or not. [ 536.745422] xhci_hcd :0b:00.0: PME# disabled [ 536.745435] xhci_hcd :0b:00.0: enabling bus mastering [ 536.745487] xhci_hcd :0b:00.0: hcd_pci_runtime_resume: 0 [ 536.745493] usb usb3: usb auto-resume [ 536.745509] hub 3-0:1.0: hub_resume [ 536.745579] hub 3-0:1.0: port 2: status 0301 change 0001 Then a mouse disconnect: [ 652.232958] usb 3-2: USB disconnect, device number 3 [ 652.232960] usb 3-2: unregistering device [ 652.232961] usb 3-2: unregistering interface 3-2:1.0 [ 652.233148
Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled
Sarah Sharp wrote: On Mon, Mar 18, 2013 at 06:20:12PM +0100, Martin Mokrejs wrote: Hi Sarah, in this particular thread, the USB3 socket of the laptop works once I plugin a device. When I unplug it and insert same or another device it appears to be dead until I use 'lsusb -vvv'. After that, I see in dmesg the two lines: Which kernel are you running on? We had a regression that involved dead As the subject says, 3.8.2. I really started last week several different email threads, each independent. ports after a USB disconnect in 3.8. This was was fixed in 3.8.3. Can you please retest with that kernel version? Hmm, will do. What change do you mean exactly? BTW, how about this bugfix which just appeared at linux-pci? [PATCH] PCI: Remove not needed check in disable aspm link Thank you, Martin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.8.2: xhci port is dead until pcieport PME# goes to disabled
[resend, no dmesg attached] Hi, happened to me again that I plugged in some devcie into my USB3 socket in my laptop (usually use an external HUB). Don't believe this is a new issue as a whole, I am facing this time to time since 3.3 time when I bought the laptop. But now, I realized the first device works but subsequently plugged in devices do not show up until until I run 'lsusb -vv'. Simple 'lsusb -v' or 'lsusb -t' is not enough. The port starts to work after dmesg logs: [ 1445.597641] pcieport :00:1c.4: PME# disabled [ 1445.617667] xhci_hcd :0b:00.0: PME# disabled I believe lsusb -vv while querying for the detailed device info triggers a fix. Funny, but maybe this will help us to understand why my express card slot somehow relates to the USB3 proivided by the TexasInstruments chip. This is a SandyBridge-based Dell Vostro 3550 laptop. I should add that on the usb mailing list about a year ago some TexasInstruments developer published that they had a hardware bug in a USB redriver, and as my laptop was made in fall 2011 I am likely having having the buggy HW. If I remember right, the report was about the problem that once you pluging a USB2 device into the XHCI slot, subsequently plugged in USB3 devices won't negotiate at SuperSpeed until you power off computer. So, I think I face a different issue but had to mention this. I use pcie_aspm=off on my kernel command line. I tried to catch some usb traffic on the dead port but the file from usbmon is really empty until I do the 'lsusb -vv'. I tried to turn off the usb powersaving at runtime but I do not have the file to do: # echo -n -1 /sys/bus/usb/devices/3-0\:1.0/power/autosuspend :( # ls -la /sys/bus/usb/devices/3-0\:1.0/power/ total 0 drwxr-xr-x 2 root root0 Mar 14 13:11 . drwxr-xr-x 6 root root0 Mar 14 13:58 .. -rw-r--r-- 1 root root 4096 Mar 14 13:11 async -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_active_kids -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_enabled -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_status -r--r--r-- 1 root root 4096 Mar 14 13:11 runtime_usage # I feel related could be patches under thread: usb: add usb port auto power off mechanism Below is a dmesg since a cold boot. I plugged in a mouse into the USB3 socket. [ 91.463285] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0 [ 91.463377] xhci_hcd :0b:00.0: PME# enabled [ 447.389700] xhci_hcd :0b:00.0: PME# disabled [ 447.389711] xhci_hcd :0b:00.0: enabling bus mastering [ 447.389787] xhci_hcd :0b:00.0: hcd_pci_runtime_resume: 0 [ 447.389819] usb usb3: usb wakeup-resume Was detected. Unplugged the mouse. [ 459.600056] usb 3-2: USB disconnect, device number 2 [ 459.600058] usb 3-2: unregistering device [ 459.600059] usb 3-2: unregistering interface 3-2:1.0 [ 459.600622] xhci_hcd :0b:00.0: shutdown urb 88040a641870 ep1in-intr [ 459.702564] usb 3-2: usb_disable_device nuking all URBs [ 459.707948] usb 3-2: Successful Endpoint Configure command [ 459.860892] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 [ 459.860910] hub 3-0:1.0: hub_suspend [ 459.860917] usb usb3: bus auto-suspend, wakeup 1 [ 459.860981] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0 [ 459.861070] xhci_hcd :0b:00.0: PME# enabled Then I put the mouse back, I think it was not detected after until I did the lsusb trick. I am not sure, sorry, but is not that important. I was repeating test once again and just forgot now this detail. So below just that the mouse got detected, either thanks to lsusb -vv or not. [ 536.745422] xhci_hcd :0b:00.0: PME# disabled [ 536.745435] xhci_hcd :0b:00.0: enabling bus mastering [ 536.745487] xhci_hcd :0b:00.0: hcd_pci_runtime_resume: 0 [ 536.745493] usb usb3: usb auto-resume [ 536.745509] hub 3-0:1.0: hub_resume [ 536.745579] hub 3-0:1.0: port 2: status 0301 change 0001 Then a mouse disconnect: [ 652.232958] usb 3-2: USB disconnect, device number 3 [ 652.232960] usb 3-2: unregistering device [ 652.232961] usb 3-2: unregistering interface 3-2:1.0 [ 652.233148] xhci_hcd :0b:00.0: shutdown urb 88040b1ee288 ep1in-intr [ 652.25] usb 3-2: usb_disable_device nuking all URBs [ 652.337096] usb 3-2: Successful Endpoint Configure command [ 652.492164] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 [ 652.492183] hub 3-0:1.0: hub_suspend [ 652.492190] usb usb3: bus auto-suspend, wakeup 1 [ 652.492254] xhci_hcd :0b:00.0: hcd_pci_runtime_suspend: 0 [ 652.492341] xhci_hcd :0b:00.0: PME# enabled [ 652.522157] pcieport :00:1c.4: PME# enabled [ 688.128198] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Note above two things pcieport started to mess in. I you look what xhci_hcd printed in previous attempts the was NO pcieport involved around, at all. Now, provided that I reported the kmemleak multiple times this year: unreferenced object 0x88040b4a0690 (size 256):
nousb kernel commandline does NOT prevent usb-storage from loading
Hi, while testing how my computer behaves with USB disabled I see this line still in dmesg output: Initializing USB Mass Storage driver... Is there any driver able to use it under 'nousb' situation at all? Shouldn't it be prevented from loading as well? This was tested on 3.9-rc1. Thank you, Martin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-3.7.10: 'nousb' causes repeated PME# enabled/disabled messages when 'pcie_aspm=off' and causes only partial acpiphp hotplug detection
Martin Mokrejs wrote: Hi, I booted same kernel under same BIOS settings with the only difference that in the latter case I added 'nousb'. While inspecting the diffs in dmesg outputs I see that something is happening with my network card and +r8169 :05:00.0: PME# disabled +r8169 :05:00.0: PME# enabled +r8169 :05:00.0: PME# disabled but also with SandyBridge PCI Express Root Port 5 +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled The pcieport messages are repeating every second, until forever, funny. This is probably related to the 'pcie_aspm=off' on kernel commandline, but so far it was necessary to get acpiphp working on kernels above 3.5. Could that be related some udev or other userspace tool misbehaving when there is no USB available? Or is that a purely kernel driver issue? 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=0b, subordinate=0c, sec-latency=0 I/O behind bridge: f000-0fff Memory behind bridge: f7d0-f7df Prefetchable memory behind bridge: fff0-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #5, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us ClockPM- Surprise- LLActRep+ BwNot- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt+ SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #4, PowerLimit 10.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [90] Subsystem: Dell Device 04b3 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- Kernel driver in use: pcieport 00: 86 80 18 1c 07 00 10 00 b5 00 04 06 10 00 81 00 10: 00 00 00 00 00 00 00 00 00 0b 0c 00 f0 00 00 20 20: d0 f7 d0 f7 f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00
Re: linux-3.7.10: 'nousb' causes repeated PME# enabled/disabled messages when 'pcie_aspm=off' and causes only partial acpiphp hotplug detection
Martin Mokrejs wrote: Martin Mokrejs wrote: Hi, I booted same kernel under same BIOS settings with the only difference that in the latter case I added 'nousb'. While inspecting the diffs in dmesg outputs I see that something is happening with my network card and +r8169 :05:00.0: PME# disabled +r8169 :05:00.0: PME# enabled +r8169 :05:00.0: PME# disabled but also with SandyBridge PCI Express Root Port 5 +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled +pcieport :00:1c.4: PME# enabled +pcieport :00:1c.4: PME# disabled The pcieport messages are repeating every second, until forever, funny. This is probably related to the 'pcie_aspm=off' on kernel commandline, but so far it was necessary to get acpiphp working on kernels above 3.5. Could that be related some udev or other userspace tool misbehaving when there is no USB available? Or is that a purely kernel driver issue? 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=0b, subordinate=0c, sec-latency=0 I/O behind bridge: f000-0fff Memory behind bridge: f7d0-f7df Prefetchable memory behind bridge: fff0-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #5, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us ClockPM- Surprise- LLActRep+ BwNot- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt+ SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #4, PowerLimit 10.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [90] Subsystem: Dell Device 04b3 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- Kernel driver in use: pcieport 00: 86 80 18 1c 07 00 10 00 b5 00 04 06 10 00 81 00 10: 00 00 00 00 00 00 00 00 00 0b 0c 00 f0 00 00 20 20: d0 f7 d0 f7 f1 ff 01 00 00 00 00 00 00 00
Re: nousb kernel commandline does NOT prevent usb-storage from loading
Hi Greg, Greg KH wrote: On Tue, Mar 12, 2013 at 11:45:39AM +0100, Martin Mokrejs wrote: Hi, while testing how my computer behaves with USB disabled I see this line still in dmesg output: Initializing USB Mass Storage driver... Did you build the driver into the kernel? Or is it being automatically loaded by something? No, it is statically included in the kernel, like ehci and xhci is. For testing I wanted to disable all USB stuff. Is there any driver able to use it under 'nousb' situation at all? Shouldn't it be prevented from loading as well? This was tested on 3.9-rc1. If userspace loads a driver, there's nothing the kernel can do about it :) Is there a problem of it being loaded? Just don't build the module at all if you don't want it. No, I just wondered why 'nousb' disables on the runtime ehci/xhci (also included statically in the kernbel binary) while not other USB-related modules. Maybe it was thought that no downstream modules will load because of unmet dependencies ... but looks usb-storage can load fine without them. The question is whether there is any module at all capable of using usb-storage while ehci/uhci/xhci are NOT available. I don't have that much a problem with the behavior as it is now. ;) Just FYI that it was a bit unexpected to see it loaded at all. Martin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: XHCI: fix memory leak of URB-private data
Hi Sarah and Alan, I just saw 3.7.5 patches announced by Greg but I don't see this path in there. And, don't know but maybe this applies to older stable kernels as well? Where will this patch posted originally to linux-usb land? Ah, is that because the email was actually NOT sent to stable@? ;-) Date: Thu, 17 Jan 2013 10:32:16 -0500 (EST) From: Alan Stern st...@rowland.harvard.edu To: Sarah Sharp sarah.a.sh...@linux.intel.com cc: Martin Mokrejs mmokr...@fold.natur.cuni.cz, USB list linux-usb@vger.kernel.org Subject: [PATCH] USB: XHCI: fix memory leak of URB-private data Message-ID: pine.lnx.4.44l0.1301171031260.1339-100...@iolanthe.rowland.org Thank you, Martin Alan Stern wrote: This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv data structure isn't always deallocated in the handle_tx_event() routine for non-control transfers. The patch adds a kfree() call so that all paths end up freeing the memory properly. Signed-off-by: Alan Stern st...@rowland.harvard.edu Reported-and-tested-by: Martin Mokrejs mmokr...@fold.natur.cuni.cz CC: sta...@vger.kernel.org --- drivers/usb/host/xhci-ring.c |2 ++ 1 file changed, 2 insertions(+) Index: usb-3.7/drivers/usb/host/xhci-ring.c === --- usb-3.7.orig/drivers/usb/host/xhci-ring.c +++ usb-3.7/drivers/usb/host/xhci-ring.c @@ -2580,6 +2580,8 @@ cleanup: (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); + else + kfree(urb_priv); usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus), urb); if ((urb-actual_length != urb-transfer_buffer_length -- 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 -- 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: XHCI: fix memory leak of URB-private data
Greg KH wrote: On Thu, Jan 24, 2013 at 10:53:25PM +0100, Martin Mokrejs wrote: Hi Sarah and Alan, I just saw 3.7.5 patches announced by Greg but I don't see this path in there. And, don't know but maybe this applies to older stable kernels as well? Where will this patch posted originally to linux-usb land? Ah, is that because the email was actually NOT sent to stable@? ;-) No. It's because the patch isn't in Linus's tree yet, which is one of the requirements for a patch to be able to get into the stable kernel releases. Please read the kernel file, Documentation/stable_kernel_rules.txt for more details if you are curious. Thank you Greg! Aside from the fact that I do not know how much serious a memleak is and whether it is eligible for -stable. Other than that, it was helpful to read the file. Will see what happens. Meanwhile will continue running my patched kernel. ;-) Martin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-3.7.1: kmemleak reports in comm usb-storage?
Sarah Sharp wrote: On Wed, Jan 16, 2013 at 12:22:59PM -0500, Alan Stern wrote: On Wed, 16 Jan 2013, Martin Mokrejs wrote: A corresponding diff of dmesg output is attached. Note that the first kmemleak in there happened just without any prior fiddling with a USB drive. For about two days I haven't connected a drive. However, usb-storage might be in a wrong shape since several days when it happened for the first time. Did you want me to reboot? ;-) I did not. Sarah, I looked through the xhci-hcd driver. There does appear to be a leak in xhci-ring.c:handle_tx_event(). Thanks for catching that. The routine looks like this: /* Leave the TD around for the reset endpoint function * to use(but only if it's not a control endpoint, * since we already queued the Set TR dequeue pointer * command for stalled control endpoints). */ if (usb_endpoint_xfer_control(urb-ep-desc) || (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); ... /* EHCI, UHCI, and OHCI always unconditionally set the * urb-status of an isochronous endpoint to 0. */ if (usb_pipetype(urb-pipe) == PIPE_ISOCHRONOUS) status = 0; usb_hcd_giveback_urb(bus_to_hcd(urb-dev-bus), urb, status); If the condition on the first if statement fails, urb_priv won't be deallocated. It needs something like if (...) xhci_urb_free_priv(xhci, urb_priv); +else +kfree(urb_priv); Ok, so you're proposing freeing the urb_priv, but leaving the TD allocated for the Set TR dequeue functions to use? Yes, that looks like the right solution, feel free to submit a patch. Martin, can you tell if adding these two lines fixes the problem? Hi Alan, yes, the following change has helped. I managed to get twice the error -71 message (one case is shown here) Jan 16 23:07:56 vostro kernel: usb 3-1.2: Device not responding to set address. Jan 16 23:07:56 vostro kernel: usb 3-1.2: Device not responding to set address. Jan 16 23:07:56 vostro kernel: usb 3-1.2: device not accepting address 17, error -71 Jan 16 23:07:56 vostro kernel: hub 3-1:1.0: unable to enumerate USB device on port 2 but the kmemleak did not report anything after next unplug of the disk anymore. --- linux-3.7.1/drivers/usb/host/xhci-ring.c.ori2013-01-16 22:51:25.0 +0100 +++ linux-3.7.1/drivers/usb/host/xhci-ring.c2013-01-16 22:53:03.0 +0100 @@ -2580,6 +2580,8 @@ (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); + else + kfree(urb_priv); usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus), urb); if ((urb-actual_length != urb-transfer_buffer_length Thanks, Martin P.S.: The other kmemleak is still in there but is probably not your business: ;-) # cat /sys/kernel/debug/kmemleak unreferenced object 0x88040b60a578 (size 256): comm swapper/0, pid 1, jiffies 4294937575 (age 688.030s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff 8?]. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [81302bd5] kzalloc.constprop.14+0xe/0x10 [81303036] device_private_init+0x14/0x63 [81305110] dev_set_drvdata+0x19/0x2f [815c1ed4] i801_probe+0x5e/0x451 [81280fb3] local_pci_probe+0x5b/0xa2 [81282074] pci_device_probe+0xc8/0xf7 [813056cd] driver_probe_device+0xa9/0x1c1 [8130583f] __driver_attach+0x5a/0x7e [81303f7a] bus_for_each_dev+0x57/0x83 [81305276] driver_attach+0x19/0x1b [81304e48] bus_add_driver+0xa8/0x1fa [81305cb1] driver_register+0x8c/0x106 [81281c6d] __pci_register_driver+0x5a/0x5e -- 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 Sun, 13 Jan 2013, Martin Mokrejs wrote: 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. ;) I did want you to plug it in and unplug it several times. But pay attention only to what kmemleak says when the drive is unplugged. I did not retry yet but I got the same kmemleak reported again. And, after quitting my seamonkey I realized system is uncovering another kmemleak. So, I am, attaching a diff to a previous stage. I can assure you that those new lines are not related to any new USB device being plugged in or out meanwhile. So, did I answer your question now? I can't tell. I don't really understand what you are doing. I think you wanted to say: cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.0 # plugin USB drive cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.1 # unplug the drive cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.2 And if kmemleak.1 and kmemleak.2 differ then report, otherwise not. I haven't realized the kmemleak being different when the drive was just plugged in, the new items always popped up just after unplug. My uncertainty was whether there is some delay in updating the file, and whether I can be sure it is up-to-date, always. I think those new items attached show yet another system path so I hope it will help you. Those about tty could be related to the fact that i tried to do # less /sys/kernel/debug/kmemleak and it somehow blocked. cancel;ling that and using cat command was not much helpful. After some seconds it got through and gave me the output but less would have probably succeeded as well. Please let me know whether I should report the kmemleaks elsewhere. Martin --- /tmp/kmemleak 2013-01-12 19:34:43.0 +0100 +++ /sys/kernel/debug/kmemleak 2013-01-09 21:19:19.800324883 +0100 @@ -1,5 +1,5 @@ unreferenced object 0x88040b1c5230 (size 256): - comm swapper/0, pid 1, jiffies 4294937570 (age 256523.410s) + comm swapper/0, pid 1, jiffies 4294937570 (age 540111.170s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff 8?]. @@ -21,7 +21,7 @@ [81305cb1] driver_register+0x8c/0x106 [81281c6d] __pci_register_driver+0x5a/0x5e unreferenced object 0x88034b2fe578 (size 16): - comm usb-storage, pid 5508, jiffies 4302958885 (age 176310.350s) + comm usb-storage, pid 5508, jiffies 4302958885 (age 459898.040s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: @@ -42,7 +42,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fee10 (size 16): - comm usb-storage, pid 5508, jiffies 4302958885 (age 176310.350s) + comm usb-storage, pid 5508, jiffies 4302958885 (age 459898.040s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: @@ -63,7 +63,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe488 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.040s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: @@ -84,7 +84,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe528 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff ..m. backtrace: @@ -105,7 +105,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe4b0 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff ..m. backtrace: @@ -126,7 +126,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe460 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.380s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff ..m. backtrace: @@ -147,7 +147,7
Re: linux-3.7.1: kmemleak reports in comm usb-storage?
Martin Mokrejs wrote: Alan Stern wrote: On Sun, 13 Jan 2013, Martin Mokrejs wrote: 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. ;) I did want you to plug it in and unplug it several times. But pay attention only to what kmemleak says when the drive is unplugged. I did not retry yet but I got the same kmemleak reported again. And, after quitting my seamonkey I realized system is uncovering another kmemleak. So, I am, attaching a diff to a previous stage. I can assure you that those new lines are not related to any new USB device being plugged in or out meanwhile. A corresponding diff of dmesg output is attached. Note that the first kmemleak in there happened just without any prior fiddling with a USB drive. For about two days I haven't connected a drive. However, usb-storage might be in a wrong shape since several days when it happened for the first time. Did you want me to reboot? ;-) I did not. Martin --- /tmp/dmesg.new 2013-01-12 20:18:14.0 +0100 +++ /tmp/dmesg.22013-01-16 02:33:34.0 +0100 @@ -1933,3 +1933,100 @@ [257099.029790] hub 3-1:1.0: port 1, status 0100, change 0001, 12 Mb/s [257099.181584] hub 3-1:1.0: debounce: port 1: total 100ms stable 100ms status 0x100 [257855.985369] kmemleak: 14 new suspected memory leaks (see /sys/kernel/debug/kmemleak) +[267293.258370] usb usb2: usb auto-resume +[267293.258376] ehci_hcd :00:1d.0: resume root hub +[267293.295290] hub 2-0:1.0: hub_resume +[267293.295328] hub 2-0:1.0: port 1: status 0507 change +[267293.295422] usb 2-1: usb auto-resume +[267293.296110] hub 2-0:1.0: state 7 ports 2 chg evt +[267293.335231] ehci_hcd :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT +[267293.355095] usb 2-1: finish resume +[267293.355346] hub 2-1:1.0: hub_resume +[267293.356336] ehci_hcd :00:1d.0: reused qh 88040aceac78 schedule +[267293.356339] usb 2-1: link qh256-0001/88040aceac78 start 1 [1/0 us] +[267293.356967] hub 2-1:1.0: state 7 ports 8 chg evt +[267295.711589] hub 2-1:1.0: hub_suspend +[267295.711597] usb 2-1: unlink qh256-0001/88040aceac78 start 1 [1/0 us] +[267295.732900] usb 2-1: usb auto-suspend, wakeup 1 +[267297.748460] hub 2-0:1.0: hub_suspend +[267297.748470] usb usb2: bus auto-suspend, wakeup 1 +[267297.748472] ehci_hcd :00:1d.0: suspend root hub +[267310.610920] usb usb2: usb auto-resume +[267310.610925] ehci_hcd :00:1d.0: resume root hub +[267310.649159] hub 2-0:1.0: hub_resume +[267310.649199] hub 2-0:1.0: port 1: status 0507 change +[267310.649278] usb 2-1: usb auto-resume +[267310.650700] hub 2-0:1.0: state 7 ports 2 chg evt +[267310.689142] ehci_hcd :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT +[267310.709046] usb 2-1: finish resume +[267310.709247] hub 2-1:1.0: hub_resume +[267310.710248] ehci_hcd :00:1d.0: reused qh 88040aceac78 schedule +[267310.710250] usb 2-1: link qh256-0001/88040aceac78 start 1 [1/0 us] +[267310.710270] hub 2-1:1.0: state 7 ports 8 chg evt +[267312.706389] hub 2-1:1.0: hub_suspend +[267312.706398] usb 2-1: unlink qh256-0001/88040aceac78 start 1 [1/0 us] +[267312.726266] usb 2-1: usb auto-suspend, wakeup 1 +[267314.742955] hub 2-0:1.0: hub_suspend +[267314.742964] usb usb2: bus auto-suspend, wakeup 1 +[267314.742966] ehci_hcd :00:1d.0: suspend root hub +[270107.716006] [sched_delayed] sched: RT throttling activated +[272687.284828] traps: python2.7[23538] general protection ip:7fe8be5a5f08 sp:7fff3c479b10 error:0 in libpython2.7.so.1.0[7fe8be495000+173000] +[273262.853094] hub 4-1:1.0: state 7 ports 4 chg evt 0002 +[273262.878070] hub 4-1:1.0: port 1, status 02a0, change 0041, 5.0 Gb/s +[273262.878075] usb 4-1.1: USB disconnect, device number 6 +[273262.878077] usb 4-1.1: unregistering device +[273262.878078] usb 4-1.1: unregistering interface 4-1.1:1.0 +[273262.884593] usb 4-1.1: usb_disable_device nuking all URBs +[273262.884653] usb 4-1.1: Successful Endpoint Configure command +[273263.056046] hub 4-1:1.0: debounce: port 1: total 100ms stable 100ms status 0x2a0 +[273263.056062] usb 4-1: remote wakeup needed for autosuspend +[277337.650821] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) +[279422.737427] r8169 :05:00.0 eth0: link down +[306258.609520] r8169 :05:00.0 eth0: link up +[306276.021745] r8169 :05:00.0 eth0: link down +[306303.361392] r8169 :05:00.0 eth0: link up +[306310.846349] r8169 :05:00.0 eth0: link down +[306313.082271] r8169 :05:00.0 eth0: link up +[311084.323583] r8169 :05:00.0 eth0: link down +[311084.323593
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
linux-3.7.1: kmemleak reports in comm usb-storage?
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. Maybe there is even a way to check whether the ext3/4 filesystem was modified since the mount time? Maybe it does not matter to you anyways. Picking just one of the reports, the whole file is attached to this email. unreferenced object 0x8803d9328528 (size 16): comm usb-storage, pid 5611, jiffies 4302959774 (age 102275.730s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 80 75 2c 5f 03 88 ff ff .u,_ backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [8138f418] kzalloc+0xf/0x11 [81391c6c] xhci_urb_enqueue+0xc1/0x3af [81373d82] usb_hcd_submit_urb+0x60b/0x6d2 [81374bf7] usb_submit_urb+0x3dd/0x3f3 [8139cb64] usb_stor_msg_common+0xb0/0x144 [8139ceb6] usb_stor_bulk_transfer_buf+0x57/0x99 [8139d224] usb_stor_Bulk_transport+0x151/0x2a0 [8139da01] usb_stor_invoke_transport+0x162/0x455 [8139ca29] usb_stor_transparent_scsi_command+0x9/0xb [8139eb62] usb_stor_control_thread+0x151/0x233 [8108fde6] kthread+0xac/0xb4 [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x Please let me know if you need more info, like lsusb or whatever. Martin unreferenced object 0x88040b1c5230 (size 256): comm swapper/0, pid 1, jiffies 4294937570 (age 182492.630s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff 8?]. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [81302bd5] kzalloc.constprop.14+0xe/0x10 [81303036] device_private_init+0x14/0x63 [81305110] dev_set_drvdata+0x19/0x2f [815c1ed4] i801_probe+0x5e/0x451 [81280fb3] local_pci_probe+0x5b/0xa2 [81282074] pci_device_probe+0xc8/0xf7 [813056cd] driver_probe_device+0xa9/0x1c1 [8130583f] __driver_attach+0x5a/0x7e [81303f7a] bus_for_each_dev+0x57/0x83 [81305276] driver_attach+0x19/0x1b [81304e48] bus_add_driver+0xa8/0x1fa [81305cb1] driver_register+0x8c/0x106 [81281c6d] __pci_register_driver+0x5a/0x5e unreferenced object 0x88034b2fe578 (size 16): comm usb-storage, pid 5508, jiffies 4302958885 (age 102279.640s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [8138f418] kzalloc+0xf/0x11 [81391c6c] xhci_urb_enqueue+0xc1/0x3af [81373d82] usb_hcd_submit_urb+0x60b/0x6d2 [81374bf7] usb_submit_urb+0x3dd/0x3f3 [8139cb64] usb_stor_msg_common+0xb0/0x144 [8139ceb6] usb_stor_bulk_transfer_buf+0x57/0x99 [8139d224] usb_stor_Bulk_transport+0x151/0x2a0 [8139d8d5] usb_stor_invoke_transport+0x36/0x455 [8139ca29] usb_stor_transparent_scsi_command+0x9/0xb [8139eb62] usb_stor_control_thread+0x151/0x233 [8108fde6] kthread+0xac/0xb4 [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fee10 (size 16): comm usb-storage, pid 5508, jiffies 4302958885 (age 102279.640s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [8138f418] kzalloc+0xf/0x11 [81391c6c] xhci_urb_enqueue+0xc1/0x3af [81373d82] usb_hcd_submit_urb+0x60b/0x6d2 [81374bf7] usb_submit_urb+0x3dd/0x3f3 [8139cb64] usb_stor_msg_common+0xb0/0x144 [8139ceb6] usb_stor_bulk_transfer_buf+0x57/0x99 [8139d224] usb_stor_Bulk_transport+0x151/0x2a0 [8139d8d5] usb_stor_invoke_transport+0x36/0x455 [8139ca29] usb_stor_transparent_scsi_command+0x9/0xb [8139eb62] usb_stor_control_thread+0x151/0x233 [8108fde6] kthread+0xac/0xb4 [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe488 (size 16): comm usb-storage, pid 5508, jiffies 4302958886 (age 102279.660s) hex dump (first 16 bytes): 01 00
Re: Remove CONFIG_USB_SUSPEND?
Hi, I just subscribed to the linux-usb list as an occasional user ... I glanced through this thread backwards ... and am somehow surprised nobody objects. I am no expert but it is my impression a lot of us want CPU powersaving, maybe LCD powersaving and don't care about external USB devices. It is only causing a hassle if the mouse goes sleep every 2 seconds or first keyboard keystroke goes away because it just woke up the keyboard. Even worse if a usb-storage device goes sleep and kernel chokes on subsequent file access. Sure, it is because of broken devices, firmware, sometimes linux ... but why do I have to sacrifice all power-saving to avoid potential issues. I just do not want to hit new bugs here or there in powersaving features in USB devices, really. They are cheap, crappy and I accepted it. But please, don't make me either use their power-saving or disable powersaving altogether. I believe you know very well what in kernel is affected and if you say few lines of code are affected, but do you really want laptop-mode-tools and all other to change their documentation, config files and make all the whitelists and blacklists in their config files useless? If I get it right I either use the tool as a whole or not at all? Really? I must be missing something. sorry for my incompetence taht I am not so knowledgeable of power-saving in general. Am just a 'looser'. ;) Martin Greg KH wrote: On Tue, Dec 18, 2012 at 11:11:15AM -0500, Alan Stern wrote: I suggest that we remove the CONFIG_USB_SUSPEND option, starting in 3.9. Practically everyone enables it, and the amount of code it protects is fairly small (just portions of usbcore, nothing in the drivers). Basically, if people don't want their kernels to save power then they should turn off CONFIG_PM. Objections, anyone? None from me. thanks, greg k-h -- 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 -- 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: Remove CONFIG_USB_SUSPEND?
Greg KH wrote: On Wed, Dec 19, 2012 at 03:24:34PM +0100, Martin Mokrejs wrote: Hi, I just subscribed to the linux-usb list as an occasional user ... I glanced through this thread backwards ... and am somehow surprised nobody objects. I am no expert but it is my impression a lot of us want CPU powersaving, maybe LCD powersaving and don't care about external USB devices. It is only causing a hassle if the mouse goes sleep every 2 seconds or first keyboard keystroke goes away because it just woke up the keyboard. Even worse if a usb-storage device goes sleep and kernel chokes on subsequent file access. Sure, it is because of broken devices, firmware, sometimes linux ... Do you currently have this problem with your devices? Which ones are they, as we need to know in order to get this fixed. Oh, thanks but luckily not. The missed first keystroke was about 3.2/3.3 series and I know I was not the only one. I don't have the problem now, with recent kernels. And the mouse going sleep ... I think it is my ignorance to configure kernel on the fly, or use the laptop-mode-tools to do it. I just haven't settled on a single power management tool. cpufreutils is now obsolete, I have some issues with laptop-mode-tools ... but, no, no kernel bug to report at the moment. Don't worry. ;-) I believe I can prevent mouse falling a sleep once I find where do I have to send the echo with it's USB ID if I don't go the laptop-mode-tools direction. But it is only an issue for me when on battery, so not urgent. Martin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
