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
On Wed, 28 May 2014, Matteo Fortini wrote: Hi Alan, I was wondering if the patch for the OHCI controller bug could be tested on our system. It isn't finished yet. I have been distracted by lots of other things. I'll let you know when it is ready. 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
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;
+ unsignedsf_count, wdh_count;
+
struct dentry *debug_dir;
struct dentry *debug_async;
struct dentry *debug_periodic;
--
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
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
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
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
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
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
Re: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
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
