Re: [PATCH 0/6] USB: OHCI: work with controllers that lose TDs

2014-10-22 Thread Matteo Fortini
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

2014-10-22 Thread Matteo Fortini
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

2014-05-28 Thread Matteo Fortini
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

2014-04-30 Thread Matteo Fortini

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

2014-04-30 Thread Matteo Fortini

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

2014-04-24 Thread Matteo Fortini

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

2014-04-16 Thread Matteo Fortini

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

2014-04-15 Thread Matteo Fortini
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

2014-04-11 Thread Matteo Fortini
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