Re: [PATCH 0/6] USB: OHCI: work with controllers that lose TDs
I (partly) reopen this issue because it fixed the problem we had (lost
TDs lead to random process lockups on FTDI serial), but we're now seeing
another kind of lockup which is also USB-related on the same board, just
at the time we close() the serial port.
We enabled USB debug to gather all available information.
Thank you for any comment
Here's some code that triggers the problem:
==
#include stdio.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
const unsigned char buf[] = 1234567890;
int main(int argc, char **argv)
{
if( argc 2 ) {
fprintf(stderr, Usage: %s serial\n, argv[0]);
return 1;
}
const char *s = argv[1];
fprintf(stderr, Opening serial '%s'\n, s);
int fd = open(s, O_RDWR);
if( fd 0 ) {
fprintf(stderr, Writing buf\n);
write(fd, buf, sizeof(buf));
fprintf(stderr, Closing serial\n);
close(fd);
fprintf(stderr, Serial closed\n);
} else {
fprintf(stderr, Unable to open '%s'\n, s);
return 1;
}
return 0;
}
==
Here's the (longish) debug output:
==
root@LCU.M3:~# /tmp/usbserial_err /dev/ttyUSB0
Opening serial '/dev/ttyUSB0'
Writing buf
Closing serial
Serial closed
root@LCU.M3:~# /tmp/usbserial_err /dev/ttyUSB0
Opening serial '/dev/ttyUSB0'
[..] DEADLOCK
root@LCU.M3:~# mount -t debugfs none /sys/kernel/debug/
root@LCU.M3:~# ls -l /sys/kernel/debug/usb/
-r--r--r--1 root root 0 Jan 1 06:14 devices
drwxr-xr-x3 root root 0 Jan 1 06:14 ohci
root@(none).M3:~#
root@(none).M3:~# cat /sys/kernel/debug/usb/devices
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 4
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.14
S: Manufacturer=Linux 3.14.0 ohci_hcd
S: Product=OHCI PCI host controller
S: SerialNumber=:00:0f.4
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0403 ProdID=6015 Rev=10.00
S: Manufacturer=Sadel S.p.A.
S: Product=sdlaudioctrl
S: SerialNumber=HSXO62L4
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 3.14
S: Manufacturer=Linux 3.14.0 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=:00:0f.5
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
root@(none).M3:~# for file in
/sys/kernel/debug/usb/ohci/\:00\:0f.4/*; do echo == ${file} ==;
cat ${file}; echo; done
== /sys/kernel/debug/usb/ohci/:00:0f.4/async ==
== /sys/kernel/debug/usb/ohci/:00:0f.4/periodic ==
size = 32
== /sys/kernel/debug/usb/ohci/:00:0f.4/registers ==
bus pci, device :00:0f.4
OHCI PCI host controllerkillall ***
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x283 RWC HCFS=operational CBSR=3
cmdstatus 0x2 SOC=0 CLF
intrstatus 0x0024 FNO SF
intrenable 0x805a MIE RHSC UE RD WDH
ed_controlhead 002c
ed_bulkhead 002c0050
hcca frame 0x543d
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80002a17 FRT FR=0x2a17
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 03000204 POTPGT=3 NPS NDP=4(4)
roothub.b PPCM= DR=
roothub.status 8000 DRWE
roothub.portstatus [0] 0x0103 PPS PES CCS
roothub.portstatus [1] 0x0100 PPS
roothub.portstatus [2] 0x0100 PPS
roothub.portstatus [3] 0x0100 PPS
root@LCU.M3:~# dmesg
[0.00] Linux version 3.14.0-x+ () (gcc version 4.9.1
(Debian 4.9.1-16) ) #10 PREEMPT Wed Oct 22 11:49:42 CEST 2014
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009]
reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0x1f7a] usable
[0.00] BIOS-e820: [mem 0x1f7b-0x1f7b2fff]
ACPI NVS
[0.00] BIOS-e820: [mem 0x1f7b3000-0x1f7b]
ACPI data
[0.00] BIOS-e820: [mem 0x-0x]
reserved
[0.00]
Re: [PATCH 0/6] USB: OHCI: work with controllers that lose TDs
Good question, I'll get back to you as soon as I get to build a 3.17 tree rebasing the changes we need for our board to behave properly. Thanks, Matteo 2014-10-22 19:43 GMT+02:00 Alan Stern st...@rowland.harvard.edu: On Wed, 22 Oct 2014, Matteo Fortini wrote: I (partly) reopen this issue because it fixed the problem we had (lost TDs lead to random process lockups on FTDI serial), but we're now seeing another kind of lockup which is also USB-related on the same board, just at the time we close() the serial port. We enabled USB debug to gather all available information. Thank you for any comment root@LCU.M3:~# dmesg [0.00] Linux version 3.14.0-x+ () (gcc version 4.9.1 (Debian 4.9.1-16) ) #10 PREEMPT Wed Oct 22 11:49:42 CEST 2014 Does it work any better if you use a 3.17 kernel? 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
Hi Alan, I was wondering if the patch for the OHCI controller bug could be tested on our system. Thank you, Matteo 2014-04-30 22:29 GMT+02:00 Alan Stern st...@rowland.harvard.edu: On Wed, 30 Apr 2014, Matteo Fortini wrote: Thank you Alan, here you go: http://pastebin.com/txu8M68L we included the register file both before and after the hangup, with a 1s interval. Thanks. This confirms the reason for the problem. It's a hardware bug in the OHCI controller; after completing a transfer, the controller didn't add the Transfer Descriptor to the Done List. I'm working on a patch to detect this sort of mistake and recover from it. I'll let you know when it's ready for testing. 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
Thank you Alan,
here you go: http://pastebin.com/txu8M68L we included the register file
both before and after the hangup, with a 1s interval.
Matteo
Il 25/04/2014 18:29, Alan Stern ha scritto:
On Thu, 24 Apr 2014, Matteo Fortini wrote:
After some time, we finally had another hangup on kernel 3.14.
@Alan: Here's the info we got in the files you mentioned. At any rate,
we're keeping the board in the same state so that we can run/produce any
other needed info.
http://pastebin.com/DZPAqjcd
To find out exactly what's going wrong, I need more information. Below
is a patch you can apply that will add more data to the registers
file in the /sys/kernel/debug/usb/ohci/* directory.
Run with the patched kernel, and the next time you get a similar hang,
see what's in the registers file. In fact, since the contents change
over time, make two copies of the file, a few seconds apart.
Alan Stern
Index: usb-3.14/drivers/usb/host/ohci-dbg.c
===
--- usb-3.14.orig/drivers/usb/host/ohci-dbg.c
+++ usb-3.14/drivers/usb/host/ohci-dbg.c
@@ -108,6 +108,9 @@ ohci_dump_status (struct ohci_hcd *contr
0x03 (temp 4), (temp 0x0f),
(temp 0x0100) ? with : NO,
rh_state_string(controller));
+ ohci_dbg_sw(controller, next, size,
+ WDH count %u SF count %u\n,
+ controller-wdh_count, controller-sf_count);
temp = ohci_readl (controller, regs-control);
ohci_dbg_sw (controller, next, size,
@@ -354,6 +357,48 @@ ohci_dump_ed (const struct ohci_hcd *ohc
}
}
+static void ohci_dump_ed_rm_list(struct ohci_hcd *ohci,
+ char **next, unsigned *size)
+{
+ unsignedtemp;
+ struct ed *ed;
+ struct td *td, *td2;
+ unsignedtdptr, tdptr2;
+ unsignedtddma, tddma2;
+ unsignedinfo;
+
+ temp = scnprintf(*next, *size, ed_rm_list:\n);
+ *size -= temp;
+ *next += temp;
+
+ for (ed = ohci-ed_rm_list; ed; ed = ed-ed_next) {
+ info = hc32_to_cpu(ohci, ed-hwINFO);
+ tdptr = tdptr2 = 0;
+ tddma = tddma2 = 0;
+ if (!list_empty(ed-td_list)) {
+ td = list_first_entry(ed-td_list, struct td, td_list);
+ tdptr = hc32_to_cpu(ohci, ed-hwHeadP) TD_MASK;
+ tddma = (unsigned) td-td_dma;
+
+ if (list_is_last(td-td_list, ed-td_list))
+ td2 = ed-dummy;
+ else
+ td2 = list_first_entry(td-td_list,
+ struct td, td_list);
+ tdptr2 = hc32_to_cpu(ohci, td-hwNextTD) TD_MASK;
+ tddma2 = (unsigned) td2-td_dma;
+ }
+
+ temp = scnprintf(*next, *size,
+ ED dev %d ep %x(%d) tick %04x td1 %x %x td2 %x
%x\n,
+ info 0x7f, (info 7) 0xf,
+ (info 11) 0x3,
+ ed-tick, tddma, tdptr, tddma2, tdptr2);
+ *size -= temp;
+ *next += temp;
+ }
+}
+
/*-*/
static int debug_async_open(struct inode *, struct file *);
@@ -652,6 +697,8 @@ static ssize_t fill_registers_buffer(str
/* roothub */
ohci_dump_roothub (ohci, 1, next, size);
+ ohci_dump_ed_rm_list(ohci, next, size);
+
done:
spin_unlock_irqrestore (ohci-lock, flags);
Index: usb-3.14/drivers/usb/host/ohci-hcd.c
===
--- usb-3.14.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.14/drivers/usb/host/ohci-hcd.c
@@ -866,6 +866,7 @@ static irqreturn_t ohci_irq (struct usb_
if (ints OHCI_INTR_WDH) {
spin_lock (ohci-lock);
dl_done_list (ohci);
+ ++ohci-wdh_count;
spin_unlock (ohci-lock);
}
@@ -902,6 +903,8 @@ static irqreturn_t ohci_irq (struct usb_
spin_lock (ohci-lock);
if (ohci-ed_rm_list)
finish_unlinks (ohci, ohci_frame_no(ohci));
+ if (ints OHCI_INTR_SF)
+ ++ohci-sf_count;
if ((ints OHCI_INTR_SF) != 0
!ohci-ed_rm_list
!ohci-ed_to_check
Index: usb-3.14/drivers/usb/host/ohci.h
===
--- usb-3.14.orig/drivers/usb/host/ohci.h
+++ usb-3.14/drivers/usb/host/ohci.h
@@ -415,6 +415,8 @@ struct ohci_hcd {
struct ed *ed_to_check;
unsignedzf_delay;
+ unsigned sf_count, wdh_count;
+
struct dentry *debug_dir;
struct dentry *debug_async;
struct dentry
Re: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
Great, thank you! Just tell me if you need any help. Matteo Il 30/04/2014 22:29, Alan Stern ha scritto: On Wed, 30 Apr 2014, Matteo Fortini wrote: Thank you Alan, here you go: http://pastebin.com/txu8M68L we included the register file both before and after the hangup, with a 1s interval. Thanks. This confirms the reason for the problem. It's a hardware bug in the OHCI controller; after completing a transfer, the controller didn't add the Transfer Descriptor to the Done List. I'm working on a patch to detect this sort of mistake and recover from it. I'll let you know when it's ready for testing. 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
After some time, we finally had another hangup on kernel 3.14. @Alan: Here's the info we got in the files you mentioned. At any rate, we're keeping the board in the same state so that we can run/produce any other needed info. http://pastebin.com/DZPAqjcd Thank you, Matteo Il 16/04/2014 18:01, Alan Stern ha scritto: On Wed, 16 Apr 2014, Matteo Fortini wrote: It's and AMD Geode single board computer, using CS5535 companion chip. Here's the pertaining lspci -vvv section: 00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10) Subsystem: Device 1022:2094 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffd000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ohci-pci 00:0f.5 Class 0c03: Device 1022:2095 (rev 02) (prog-if 20) Subsystem: Device 1022:2095 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ehci-pci This doesn't answer my question. Which controller was the device attached to when the hang occurred? Was it the EHCI controller or the OHCI controller? If you enable CONFIG_USB_DEBUG, what shows up in the files under the corresponding directory in /sys/kernel/debug/usb/ehci/ or /sys/kernel/debug/usb/ohci/ when the hang occurs? 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
It's and AMD Geode single board computer, using CS5535 companion chip. Here's the pertaining lspci -vvv section: 00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10) Subsystem: Device 1022:2094 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffd000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ohci-pci 00:0f.5 Class 0c03: Device 1022:2095 (rev 02) (prog-if 20) Subsystem: Device 1022:2095 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at efffc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ehci-pci Il 16/04/2014 16:45, Alan Stern ha scritto: On Tue, 15 Apr 2014, Matteo Fortini wrote: Yes, we tried with 3.14 and after less than 24hrs. What could we do to fix the issue? Thank you, Matteo Here's dmesg output: [103200.145660] INFO: task :2341 blocked for more than 120 seconds. [103200.145774] Not tainted 3.14.0-+ #3 [103200.145844] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [103200.145950] X D de7a 0 2341 2263 0x [103200.146163] de79be5c 00200086 c17d8de0 de7a de79be00 c17d8de0 00200246 c17d8e00 [103200.146357] de79be44 de7a de79bfec de7a c179b560 00200246 c17d8e00 de79be44 [103200.146661] de7a 007b c104eb7e c17d ffcf c154c2d5 de79be44 [103200.146853] Call Trace: [103200.146948] [c104eb7e] ? preempt_count_sub+0xb/0xac [103200.147103] [c154c2d5] ? _raw_spin_unlock_irqrestore+0x27/0x45 [103200.147200] [c154c2df] ? _raw_spin_unlock_irqrestore+0x31/0x45 [103200.147308] [c1055899] ? prepare_to_wait_event+0x60/0xb5 [103200.147432] [c134af26] ? usb_put_dev+0x14/0x16 [103200.147525] [c1548be3] schedule+0x22/0x54 [103200.147611] [c1353ac1] usb_kill_urb+0x51/0x80 A process hanging in usb_kill_urb indicates something is wrong with the host controller driver. Which host controller driver does this device use? 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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
Yes, we tried with 3.14 and after less than 24hrs.
What could we do to fix the issue?
Thank you,
Matteo
Here's dmesg output:
[103200.145660] INFO: task :2341 blocked for more than 120 seconds.
[103200.145774] Not tainted 3.14.0-+ #3
[103200.145844] echo 0 /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[103200.145950] X D de7a 0 2341 2263 0x
[103200.146163] de79be5c 00200086 c17d8de0 de7a de79be00 c17d8de0
00200246 c17d8e00
[103200.146357] de79be44 de7a de79bfec de7a c179b560 00200246
c17d8e00 de79be44
[103200.146661] de7a 007b c104eb7e c17d ffcf
c154c2d5 de79be44
[103200.146853] Call Trace:
[103200.146948] [c104eb7e] ? preempt_count_sub+0xb/0xac
[103200.147103] [c154c2d5] ? _raw_spin_unlock_irqrestore+0x27/0x45
[103200.147200] [c154c2df] ? _raw_spin_unlock_irqrestore+0x31/0x45
[103200.147308] [c1055899] ? prepare_to_wait_event+0x60/0xb5
[103200.147432] [c134af26] ? usb_put_dev+0x14/0x16
[103200.147525] [c1548be3] schedule+0x22/0x54
[103200.147611] [c1353ac1] usb_kill_urb+0x51/0x80
[103200.147695] [c10554a7] ? bit_waitqueue+0x54/0x54
[103200.147809] [dfff1408] usb_serial_generic_close+0x63/0x72 [usbserial]
[103200.147921] [dffef01f] serial_port_shutdown+0x1f/0x21 [usbserial]
[103200.148096] [c12c0307] tty_port_shutdown+0x5b/0x7c
[103200.148188] [c12c0a43] tty_port_close+0x20/0x3d
[103200.148285] [dffef595] serial_close+0x23/0x25 [usbserial]
[103200.148377] [c12b94c0] tty_release+0xa4/0x52a
[103200.148492] [c1116a63] ? locks_remove_posix+0xe/0x94
[103200.148584] [c105d432] ? do_raw_spin_unlock+0x9/0x78
[103200.148674] [c110c40f] ? fsnotify+0xe/0x287
[103200.148753] [c110c40f] ? fsnotify+0xe/0x287
[103200.148848] [c10d791e] __fput+0x89/0x1ec
[103200.148933] [c10d7ab5] fput+0xd/0xf
[103200.149011] [c1044225] task_work_run+0x66/0x89
[103200.149161] [c1001f2b] do_notify_resume+0x5c/0x5e
[103200.149246] [c154c759] ? syscall_exit+0x8/0x1b
[103200.149330] [c154c812] work_notifysig+0x24/0x2a
[103200.149450] [c154] ? set_gssp_clnt+0xb3/0x125
[103200.163776] 2 locks held by /2341:
[103200.163856] #0: (tty-legacy_mutex){..}, at: [c154c580]
tty_lock_nested+0x37/0x80
[103200.165368] #1: (port-mutex){..}, at: [c12c02ca]
tty_port_shutdown+0x1e/0x7c
2014-04-11 16:09 GMT+02:00 Greg KH gre...@linuxfoundation.org:
On Fri, Apr 11, 2014 at 12:19:55PM +0200, Matteo Fortini wrote:
We are experiencing stuck processes (D state) which are talking to an
FTD_SIO usb_serial adapter. The process sometimes has to close the
serial device when it detects an error or a timeout.
Does this also happen with 3.14?
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
Deadlock v3.10.35 with FTD_SIO usb-serial adapter
We are experiencing stuck processes (D state) which are talking to an FTD_SIO usb_serial adapter. The process sometimes has to close the serial device when it detects an error or a timeout. We rebuilt the kernel with the CONFIG_DEBUG_USB option and the stuck processes reporting enabled. The output was this: = [89400.258190] INFO: task XX:26743 blocked for more than 120 seconds. [89400.258263] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [89400.258329] XD c132e6a0 0 26743 2260 0x [89400.258397] de2e5e5c 00200082 de2e5dfc c132e6a0 68d4dbc8 511c db24c000 [89400.258506] de2e4000 db24c000 de002c80 dee34000 c1537ea0 de2e5e38 c1315cb0 def5ac00 [89400.258614] c104a7ae de2e5e30 c12a9b48 de2e5e38 c104a7ae de2e5e64 c13169a6 c14eee71 [89400.258722] Call Trace: [89400.258783] [c132e6a0] ? start_ed_unlink+0x19/0x4f [89400.258854] [c1315cb0] ? unlink1+0x29/0x13d [89400.258913] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.258997] [c12a9b48] ? put_device+0x14/0x16 [89400.259099] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.259160] [c13169a6] ? usb_hcd_unlink_urb+0xac/0xbe [89400.259228] [c14eee71] ? mutex_unlock+0x8/0x13 [89400.259283] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.259341] [c10421c3] ? prepare_to_wait+0x49/0x75 [89400.259405] [c14efdbb] schedule+0x22/0x4c [89400.259459] [c1317c2c] usb_kill_urb+0x62/0x92 [89400.259514] [c10423a9] ? finish_wait+0x71/0x71 [89400.259589] [dffd7fb1] usb_serial_generic_close+0x78/0x90 [usbserial] [89400.259660] [dffd601f] serial_port_shutdown+0x1f/0x21 [usbserial] [89400.259727] [c128ac5b] tty_port_shutdown+0x46/0x66 [89400.259787] [c128b59e] tty_port_close+0x20/0x3d [89400.259851] [dffd668c] serial_close+0x1d/0x20 [usbserial] [89400.259920] [c1283b1b] tty_release+0xce/0x525 [89400.260003] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.262022] [c10f341d] ? fsnotify+0xe/0x29f [89400.262280] [c10f8c33] ? timerfd_read+0x1bf/0x27c [89400.262346] [c10f37f1] ? __fsnotify_parent+0xe/0xd3 [89400.262410] [c10c0034] __fput+0x8b/0x205 [89400.262468] [c10c0252] fput+0xd/0xf [89400.262526] [c103f0a1] task_work_run+0x57/0x79 [89400.262584] [c10018c5] do_notify_resume+0x5b/0x5d [89400.262640] [c10be61a] ? SyS_close+0x1b/0x42 [89400.262697] [c14f0e8b] work_notifysig+0x24/0x29 [89400.262764] [c14f] ? wait_for_completion+0x8/0x19 = (also on http://pastebin.com/zTy0uhMN ) I couldn't find the cause, nor a way to trigger this, except waiting for around 24 hours. Is there anything we could look at to help? Thank you in advance, Matteo -- 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
