Re: Oops with dwc3 in device mode and functionfs
Hi, Vincent Pelletier writes: > Hello, > > On Sun, Mar 26, 2017 at 9:20 PM, Andy Shevchenko > wrote: >> On Sat, 2017-03-25 at 08:06 +0900, Vincent Pelletier wrote: >>> FWIW, at home enumeration happens much more reliably behind a hub than >>> directly on a host (both being xHCI). Maybe my edison board has some >>> electrical issue a hub would tolerate better ? > > Re-reading what I wrote, I realize my vocabulary is misleading. > Rephrasing for the record: > > Enumeration (HS chirp, bus address attribution) typically works, even > directly on an xHCI. It is SET_CONFIGURATION (including the one done > by the kernel after enumerating and before any driver tries to access > the device) which very often fails on an xHCI, but very often succeeds > when a hub (in my case, USB3) is inserted between the edison and the > same xHCI. I noticed that too and I still have no idea what's going on :-s -- balbi signature.asc Description: PGP signature
Re: Oops with dwc3 in device mode and functionfs
Hello, On Sun, Mar 26, 2017 at 9:20 PM, Andy Shevchenko wrote: > On Sat, 2017-03-25 at 08:06 +0900, Vincent Pelletier wrote: >> FWIW, at home enumeration happens much more reliably behind a hub than >> directly on a host (both being xHCI). Maybe my edison board has some >> electrical issue a hub would tolerate better ? Re-reading what I wrote, I realize my vocabulary is misleading. Rephrasing for the record: Enumeration (HS chirp, bus address attribution) typically works, even directly on an xHCI. It is SET_CONFIGURATION (including the one done by the kernel after enumerating and before any driver tries to access the device) which very often fails on an xHCI, but very often succeeds when a hub (in my case, USB3) is inserted between the edison and the same xHCI. Having had issues with an electrically non-compliant USB2 device before (chirp was of the wrong duration), it was confusing my USB protocol analyzer, and it would help to place it behind a hub (the hub being more tolerant and hiding the non-compliance from the analyzer - allowing it to switch from FS to HS and actually capture traffic). Hence my suspicion for some kind of electrical issue, but I have no proof for this. > We don't know (yet?) Basin Cove PMIC relations with USB mux / vbus / > etc. It might be involved. Since you IIRC were looking to some PMIC > related stuff The ADC part ? Yes. I think I have fixed all the issues you pointed out but the two big ones: using regmap and the IRQ cascading issue found on drivers of its chip family. I'm not sure how I should declare registers for the former (platform data ?), and need to catch up with the IRQ fixes from other drivers. > can you at some point check if it has anything possible effect on USB? Like, looking if some driver touching the PMIC in the original firmware source would mention USB ? Yep, I can do. Regards, -- Vincent Pelletier -- 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: Oops with dwc3 in device mode and functionfs
On Sat, 2017-03-25 at 08:06 +0900, Vincent Pelletier wrote: > Hello Andy, Felipe, > > Sorry for the late reply. > > On Mon, Mar 20, 2017 at 6:23 PM, Felipe Balbi > wrote: > > Andy Shevchenko writes: > > > Can you check my latest snapshot? > > I built your github eds branch as of cfa21022e (based on 4.11.0-rc3), > but I still get enumeration issues (see below). I did not merge any > other branches above it for this test (especially, not Felipe's usb > branches) just in case. Noted. > FWIW, at home enumeration happens much more reliably behind a hub than > directly on a host (both being xHCI). Maybe my edison board has some > electrical issue a hub would tolerate better ? We don't know (yet?) Basin Cove PMIC relations with USB mux / vbus / etc. It might be involved. Since you IIRC were looking to some PMIC related stuff can you at some point check if it has anything possible effect on USB? -- Andy Shevchenko Intel Finland Oy -- 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: Oops with dwc3 in device mode and functionfs
Hello Andy, Felipe, Sorry for the late reply. On Mon, Mar 20, 2017 at 6:23 PM, Felipe Balbi wrote: > Andy Shevchenko writes: >> Can you check my latest snapshot? I built your github eds branch as of cfa21022e (based on 4.11.0-rc3), but I still get enumeration issues (see below). I did not merge any other branches above it for this test (especially, not Felipe's usb branches) just in case. >> It has been discovered that ep1 and ep8 are not usable for USB (tracing >> related stuff). Felipe did a quick hack for that. Ah, thanks for the info, I did not keep track at all lately. > yeah, I have been writing a functionfs "driver" myself to test stuff > out. It's still pretty early but at least enumeration is rather solid. Mar 25 07:43:14 vincent-tkpad kernel: [1582082.400893] usb 1-1: USB disconnect, device number 22 Mar 25 07:43:16 vincent-tkpad kernel: [1582084.028746] usb 1-1: new high-speed USB device number 23 using xhci_hcd Mar 25 07:43:16 vincent-tkpad kernel: [1582084.159290] usb 1-1: New USB device found, idVendor=1d6b, idProduct=0104 Mar 25 07:43:16 vincent-tkpad kernel: [1582084.159294] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mar 25 07:43:16 vincent-tkpad kernel: [1582084.159296] usb 1-1: Product: tesla Mar 25 07:43:16 vincent-tkpad kernel: [1582084.159297] usb 1-1: Manufacturer: vpelletier Mar 25 07:43:16 vincent-tkpad kernel: [1582084.159298] usb 1-1: SerialNumber: FZED443D01T42501 Mar 25 07:43:21 vincent-tkpad kernel: [1582089.156950] usb 1-1: can't set config #1, error -110 Mar 25 07:43:21 vincent-tkpad mtp-probe: checking bus 1, device 23: "/sys/devices/pci:00/:00:14.0/usb1/1-1" Mar 25 07:43:21 vincent-tkpad mtp-probe: bus: 1, device: 23 was not an MTP device After a few plug/unplug cycles the device gets stuck and does not enumerate at all (instead of only failing to set the configuration) until device reboot. FWIW, at home enumeration happens much more reliably behind a hub than directly on a host (both being xHCI). Maybe my edison board has some electrical issue a hub would tolerate better ? Regards, -- Vincent Pelletier -- 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: Oops with dwc3 in device mode and functionfs
Hi, Andy Shevchenko writes: > On Sat, 2017-01-07 at 04:07 +, Vincent Pelletier wrote: >> On Fri, 6 Jan 2017 15:21:17 +, Vincent Pelletier >> wrote: >> > The next issue is that often (>9 times out of 10) the dwc3 fails to >> > respond to the SET_CONFIGURATION standard request. As a result, only >> > EP0 works. >> >> I captured a successful enumeration, there are also corrupted pids: > > Can you check my latest snapshot? > > It has been discovered that ep1 and ep8 are not usable for USB (tracing > related stuff). Felipe did a quick hack for that. yeah, I have been writing a functionfs "driver" myself to test stuff out. It's still pretty early but at least enumeration is rather solid. -- balbi -- 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: Oops with dwc3 in device mode and functionfs
On Sat, 2017-01-07 at 04:07 +, Vincent Pelletier wrote: > On Fri, 6 Jan 2017 15:21:17 +, Vincent Pelletier > wrote: > > The next issue is that often (>9 times out of 10) the dwc3 fails to > > respond to the SET_CONFIGURATION standard request. As a result, only > > EP0 works. > > I captured a successful enumeration, there are also corrupted pids: Can you check my latest snapshot? It has been discovered that ep1 and ep8 are not usable for USB (tracing related stuff). Felipe did a quick hack for that. -- Andy Shevchenko Intel Finland Oy -- 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: Oops with dwc3 in device mode and functionfs
On Fri, 6 Jan 2017 15:21:17 +, Vincent Pelletier wrote: > The next issue is that often (>9 times out of 10) the dwc3 fails to > respond to the SET_CONFIGURATION standard request. As a result, only > EP0 works. I captured a successful enumeration, there are also corrupted pids: 002:03.271'422"583n SETUP @054.00 DATA0 8B ACK 000 80 06 03 03 09 04 ff 00 002:03.271'425"200n IN @054.00 NAK 002:03.271'446"233n IN @054.00 NAK 002:03.271'478"233n IN @054.00 NAK 002:03.271'499"233n IN @054.00 DATA134B ACK 000 22 03 46 00 5a 00 45 00 44 00 34 00 34 00 33 00 ..F.Z.E.D.4.4.3. 010 44 00 30 00 31 00 54 00 34 00 32 00 35 00 30 00 D.0.1.T.4.2.5.0. 020 31 001. 002:03.271'502"133n OUT @054.00 DATA1 0B NAK 002:03.271'523"216n PING@054.00 NAK 002:03.271'556"233n PING@054.00 NAK 002:03.271'581"666n PING@054.00 ACK 002:03.271'583"050n OUT @054.00 DATA1 0B ACK 002:03.272'345"833n SETUP @054.00 DATA0 8B ACK 000 00 09 01 00 00 00 00 00 002:03.272'348"350n IN @054.00 NAK 002:03.272'369"350n IN @054.00 NAK [...] 002:03.273'082"100n IN @054.00 NAK 002:03.273'119"633n (bad pid) 0xf0 0x3e 0x88 002:03.273'103"450n IN @054.00 NAK (incomplete transaction) 002:03.273'123"333n (bad pid) 0xf0 0x3e 0x88 002:03.273'127"033n (bad pid) 0xf0 0x3e 0x88 002:03.273'145"450n IN @054.00 NAK 002:03.273'166"466n IN @054.00 NAK [...] 002:03.278'582"600n IN @054.00 NAK 002:03.278'604"200n IN @054.00 DATA1 0B ACK There are 285 NAKs between SETUP and the final ACK. A note about "incomplete transaction": this is a bug in my trace parser, the NAK transaction is complete, it is the next token (the bad pid) which confuses the state tracker, which also causes the timestamp non-monotonicity in parser's output too. There is one bad-CRC DATA0 packet after each bad pid. > There seems to be another issue (or is it just a consequence of this > one ?) where it may become completely silent, unable to join the bus > when udc identifier is written to UDC file. From what I can reproduce, it always happens in 3 stages: - first enumeration (whether SET_CONFIGURATION succeeds or not seems irrelevant) - second enumeration, which SET_CONFIGURATION always times-out in my experience (but given the low success rate, having two consecutive successes would be hard anyway) - 3rd enumeration attempt fails, no event on the bus. -- Vincent Pelletier -- 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: Oops with dwc3 in device mode and functionfs
On Tue, 3 Jan 2017 18:18:02 +0100, Vincent Pelletier wrote: > Sadly, this fix alone is not enough to get a functional device. I did > not investigate much yet, and need to get some sleep. I investigated more. The next issue is that often (>9 times out of 10) the dwc3 fails to respond to the SET_CONFIGURATION standard request. As a result, only EP0 works. Host-side, syslog contains a -110 (ETIMEDOUT) error. Re-triggering a SET_CONFIGURATION causes the same timeout to happen again. Device-side, functionfs does trigger the "ENABLE" event. Altogether, ep0 does work (vendor-specific requests from host do get received by the program on device which listens to events on ep0 file). Host (comprehensibly) refuses to emit requests to endpoints which are not considered as configured, so I cannot test this part. Plugging my USB protocol analyser, I see corrupted USB PIDs. Here is a capture, starting at the beginning od the last GET_DESCRIPTOR transaction before the SET_CONFIGURATION one: 001:23.273'515"383n SETUP @054.00 DATA0 8B ACK 000 80 06 03 03 09 04 ff 00 001:23.273'518"000n IN @054.00 NAK 001:23.273'539"966n IN @054.00 NAK 001:23.273'582"983n IN @054.00 NAK 001:23.273'604"666n IN @054.00 DATA134B ACK 000 22 03 46 00 5a 00 45 00 44 00 34 00 34 00 33 00 ..F.Z.E.D.4.4.3. 010 44 00 30 00 31 00 54 00 34 00 32 00 35 00 30 00 D.0.1.T.4.2.5.0. 020 31 001. 001:23.273'607"666n OUT @054.00 DATA1 0B NAK 001:23.273'628"966n PING@054.00 NAK 001:23.273'649"650n PING@054.00 NAK 001:23.273'683"966n PING@054.00 ACK 001:23.273'685"300n OUT @054.00 DATA1 0B ACK 001:23.274'459"183n (bad pid) 0xf0 0x36 0xf8 001:23.275'036"750n (bad pid) 0x03 0x00 0x00 0x00 0x96 0x52 0x68 0xfa 001:23.275'037"266n SETUP @054.00 DATA0 8B ACK 000 00 09 01 00 00 00 00 00 001:23.275'039"750n IN @054.00 NAK 001:23.275'067"183n IN @054.00 NAK 001:23.275'110"183n IN @054.00 NAK 001:23.275'131"866n IN @054.00 NAK 001:23.275'153"183n IN @054.00 NAK 001:23.275'196"200n IN @054.00 NAK 001:23.275'217"883n IN @054.00 NAK 001:23.275'239"200n IN @054.00 NAK 001:23.275'260"883n IN @054.00 NAK 001:23.275'287"300n IN @054.00 NAK 001:23.275'308"900n IN @054.00 NAK 001:23.275'329"900n IN @054.00 NAK 001:23.275'356"216n IN @054.00 NAK 001:23.275'377"900n IN @054.00 NAK 001:23.275'399"216n IN @054.00 NAK 001:23.275'442"233n IN @054.00 NAK 001:23.275'463"916n IN @054.00 NAK 001:23.275'485"233n IN @054.00 NAK 001:23.275'506"916n IN @054.00 NAK 001:23.275'528"233n IN @054.00 NAK 001:23.275'571"250n IN @054.00 NAK 001:23.275'592"933n IN @054.00 NAK 001:23.275'614"250n IN @054.00 NAK 001:23.275'635"933n IN @054.00 NAK 001:23.275'662"350n IN @054.00 NAK 001:23.275'683"950n IN @054.00 NAK 001:23.275'706"266n IN @054.00 NAK 001:23.275'727"950n IN @054.00 NAK 001:23.275'749"266n IN @054.00 NAK 001:23.275'770"950n IN @054.00 NAK 001:23.275'811"200n (bad pid) 0xf0 0x36 0xf8 001:23.275'792"266n IN @054.00 NAK (incomplete transaction) 001:23.278'811"983n HS idle The format being: timestamp token_type "@"device"."endpoint data_type bytes"B" handshake_type data_stage_hexdump Strangely, when plugging the device on a hub seems to improve the situation. Sadly, my protocol analyser gets confused when plugged between that hub and the device, and fails to capture anything (it likely fails to detect the chirp handshake). There seems to be another issue (or is it just a consequence of this one ?) where it may become completely silent, unable to join the bus when udc identifier is writted to UDC file. Regards, -- Vincent Pelletier -- 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: Oops with dwc3 in device mode and functionfs
Checking more, I think the 3 "do {...} while(--count)" loops in f_fs.c
are wrong: they should be "while(count--){...}" ("git format-patch"
attached, sorry, I'm on a dev-hostile mail client at the moment):
- count covers function-specific endpoint, so it is 0 when no endpoint
is declared, which leads to an integer underflow and exceeding eps
array end.
- a function enabling/disabling endpoint 0 does not make sense to me
(they are only supposed to care about their own descriptor, don't they
?)
On Tue, Jan 3, 2017 at 3:49 PM, Vincent Pelletier wrote:
> The functionfs side of things is a bit complicated, as I'm writing a
> python module[2] for it, and I am still very new to functionfs. It
> does not crash on 4.9-rc7 though.
As per the above, this was not the whole truth: a device declared with
2 endpoints does not crash on 4.9-rc7, crashes on 4.10-rc2, including
with the upcomming rc3 fixes. A zero endpoint version crashes *and*
made me realise the loop error.
Sadly, this fix alone is not enough to get a functional device. I did
not investigate much yet, and need to get some sleep.
--
Vincent Pelletier
From 85815ce5c82022ccfbb2c0184589c4766325b517 Mon Sep 17 00:00:00 2001
From: Vincent Pelletier
Date: Tue, 3 Jan 2017 16:47:23 +0100
Subject: [RFC] usb: gadget: f_fs: Fix iterations on endpoints.
When zero endpoints are declared for a function, there is no endpoint
to disable, enable or free, so replace do...while loops with while loops.
Change pre-decrement to post-decrement to iterate the same number of times
when there are endpoints to process.
Signed-off-by: Vincent Pelletier
---
drivers/usb/gadget/function/f_fs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 5e746adc8a2d..5490fc51638e 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1806,7 +1806,7 @@ static void ffs_func_eps_disable(struct ffs_function *func)
unsigned long flags;
spin_lock_irqsave(&func->ffs->eps_lock, flags);
- do {
+ while (count--) {
/* pending requests get nuked */
if (likely(ep->ep))
usb_ep_disable(ep->ep);
@@ -1817,7 +1817,7 @@ static void ffs_func_eps_disable(struct ffs_function *func)
__ffs_epfile_read_buffer_free(epfile);
++epfile;
}
- } while (--count);
+ }
spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
}
@@ -1831,7 +1831,7 @@ static int ffs_func_eps_enable(struct ffs_function *func)
int ret = 0;
spin_lock_irqsave(&func->ffs->eps_lock, flags);
- do {
+ while(count--) {
struct usb_endpoint_descriptor *ds;
int desc_idx;
@@ -1867,7 +1867,7 @@ static int ffs_func_eps_enable(struct ffs_function *func)
++ep;
++epfile;
- } while (--count);
+ }
spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
return ret;
@@ -3448,12 +3448,12 @@ static void ffs_func_unbind(struct usb_configuration *c,
/* cleanup after autoconfig */
spin_lock_irqsave(&func->ffs->eps_lock, flags);
- do {
+ while (count--) {
if (ep->ep && ep->req)
usb_ep_free_request(ep->ep, ep->req);
ep->req = NULL;
++ep;
- } while (--count);
+ }
spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
kfree(func->eps);
func->eps = NULL;
--
2.11.0
Re: Oops with dwc3 in device mode and functionfs
On Tue, 2017-01-03 at 17:00 +0200, Andy Shevchenko wrote: > On Tue, 2017-01-03 at 15:49 +0100, Vincent Pelletier wrote: > > Hello, > > > > I am hitting the following oops with 4.10-rc2 (on an intel edison, > > so > > this is with Andy's patchset[1] which is currently based on 4.10-rc2 > > and does not seem to touch usb code) with Felipe's fixes-for-v4.10- > > rc3 > > merged on top of it. > > > > Let me check, I might missed some patches to cherry-pick. I just pushed an updated version where I merged balbi/usb.git (branch fixes) completely. I have got a nice warning (which doesn't prevent to work), though it's another and not related case. -- Andy Shevchenko Intel Finland Oy -- 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: Oops with dwc3 in device mode and functionfs
On Tue, 2017-01-03 at 15:49 +0100, Vincent Pelletier wrote:
> Hello,
>
> I am hitting the following oops with 4.10-rc2 (on an intel edison, so
> this is with Andy's patchset[1] which is currently based on 4.10-rc2
> and does not seem to touch usb code) with Felipe's fixes-for-v4.10-rc3
> merged on top of it.
>
Let me check, I might missed some patches to cherry-pick.
> The oops + kdb traceback:
>
> [ 42.537029] file system registered
> [ 45.048685] systemd-hostnam (1666) used greatest stack depth: 5680
> bytes left
> [ 51.643687] read descriptors
> [ 51.648273] read strings
> [ 53.921220] configfs-gadget gadget: high-speed config #1: c
> [ 53.927231] BUG: unable to handle kernel paging request at 00040905
> [ 53.933683] IP: usb_ep_enable+0x23/0xb0 [udc_core]
> [ 53.938585] *pde =
> [ 53.938591]
> [ 53.943060] Oops: [#1] SMP
>
> Entering kdb (current=0xf40a8f00, pid 1866) on processor 0 Oops:
> (null)
> due to oops @ 0xf812a023
> CPU: 0 PID: 1866 Comm: irq/34-dwc3 Not tainted
> 4.10.0-rc2-edison-00061-g1a2e83d30e6d #18
> Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
> 2015.01.21:18.19.48
> task: f40a8f00 task.stack: f4d3a000
> EIP: usb_ep_enable+0x23/0xb0 [udc_core]
> EFLAGS: 00010046 CPU: 0
> EAX: f4d996d4 EBX: f4d996c0 ECX: 00040905 EDX: f4d996dd
> ESI: f4fa4200 EDI: f4d996d4 EBP: f4d3bdec ESP: f4d3bddc
> DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> CR0: 80050033 CR2: 00040905 CR3: 01d62000 CR4: 001006d0
> Call Trace:
> ffs_func_set_alt+0x243/0x290 [usb_f_fs]
> composite_setup+0xcf1/0x1ba0 [libcomposite]
> ? dwc3_gadget_exit+0x140/0x1c0 [dwc3]
> dwc3_ep0_delegate_req+0x2d/0x40 [dwc3]
> dwc3_ep0_interrupt+0x409/0xad0 [dwc3]
> ? dwc3_thread_interrupt+0x22/0xe80 [dwc3]
> ? _raw_spin_lock_irqsave+0x43/0x50
> dwc3_thread_interrupt+0x120/0xe80 [dwc3]
> ? __schedule+0x65e/0x850
> irq_thread_fn+0x18/0x30
> irq_thread+0xef/0x180
> ? irq_finalize_oneshot+0xd0/0xd0
> ? wake_threads_waitq+0x40/0x40
> ? free_percpu_irq+0x60/0x60
> kthread+0xfb/0x100
> ? free_percpu_irq+0x60/0x60
> ? kthread_stop+0x150/0x150
> ret_from_fork+0x19/0x24
> Code: 11 85 c0 89 45 f0 75 04 c6 47 19 01 3e 8d 74 26 00 eb 41 89
> f6
>
> same traceback, in (k)gdb:
> (gdb) bt
> #0 0xf812a023 in usb_ep_enable (ep=0xf4d996d4) at
> drivers/usb/gadget/udc/core.c:109
> #1 0xf967b533 in ffs_func_eps_enable (func=) at
> drivers/usb/gadget/function/f_fs.c:1857
> #2 ffs_func_set_alt (f=, interface=,
> alt=) at drivers/usb/gadget/function/f_fs.c:3146
> #3 0xf8179791 in set_config (ctrl=, number= out>, cdev=) at drivers/usb/gadget/composite.c:814
> #4 0xf8b4030d in dwc3_ep0_delegate_req (dwc=0xf557b814,
> ctrl=0xf4f2c000) at drivers/usb/dwc3/ep0.c:603
> #5 0xf8b412a9 in dwc3_ep0_set_config (ctrl=,
> dwc=) at drivers/usb/dwc3/ep0.c:622
> #6 dwc3_ep0_std_request (ctrl=, dwc=)
> at drivers/usb/dwc3/ep0.c:778
> #7 dwc3_ep0_inspect_setup (event=, dwc= out>) at drivers/usb/dwc3/ep0.c:818
> #8 dwc3_ep0_xfer_complete (event=, dwc= out>) at drivers/usb/dwc3/ep0.c:977
> #9 dwc3_ep0_interrupt (dwc=0xf557b814, event=) at
> drivers/usb/dwc3/ep0.c:1139
> #10 0xf8b3d930 in dwc3_endpoint_interrupt (event=,
> dwc=) at drivers/usb/dwc3/gadget.c:2245
> #11 0xc10b1818 in irq_thread_fn (desc=0xf4d26600, action=0xf4d99200)
> at kernel/irq/manage.c:896
> #12 0xc10b1caf in irq_thread (data=0xf4d99200) at
> kernel/irq/manage.c:973
> #13 0xc1074a6b in kthread (_create=0xf4c14f20) at kernel/kthread.c:227
> #14 0xc185de01 in ret_from_fork () at arch/x86/entry/entry_32.S:295
> (gdb) print *ep
> $1 = {driver_data = 0xf4d996c0, name = 0xff00 memory at address 0xff00>, ops = 0x40905, ep_list = {next = 0xff,
> prev = 0x500 }, caps =
> {type_control = 0, type_iso = 0, type_bulk = 0, type_int = 0, dir_in =
> 0, dir_out = 0}, claimed = false,
> enabled = false, maxpacket = 0, maxpacket_limit = 0, max_streams = 0,
> mult = 0, maxburst = 0, address = 0 '\000', desc = 0xf4d996dd,
> comp_desc = 0x0}
>
> Note "name" and "ep_list.prev" are also broken, as likely
> ep_list.next.
>
> Last command:
> # echo dwc3.1.auto > /sys/kernel/config/usb_gadget/g1/UDC
>
> Host's syslog:
> Jan 3 15:20:23 vincent-tkpad kernel: [876929.788285] usb 2-1: new
> high-speed USB device number 86 using xhci_hcd
> Jan 3 15:20:23 vincent-tkpad kernel: [876929.918767] usb 2-1: New USB
> device found, idVendor=1d6b, idProduct=0104
> Jan 3 15:20:23 vincent-tkpad kernel: [876929.918771] usb 2-1: New USB
> device strings: Mfr=1, Product=2, SerialNumber=3
> Jan 3 15:20:23 vincent-tkpad kernel: [876929.918774] usb 2-1:
> Product: tesla
> Jan 3 15:20:23 vincent-tkpad kernel: [876929.918776] usb 2-1:
> Manufacturer: vpelletier
> Jan 3 15:20:23 vincent-tkpad kernel: [876929.918777] usb 2-1:
> SerialNumber: FZED443D01T42501
> Jan 3 15:20:28 vincent-tkpad kernel: [876934.916146] usb 2-1: can't
> set config #1, error -110
> Jan 3 15:20:28 vincent-tkpad mtp-probe: checking bus 2, device 86:
> "/sys/devices/pci:00/:00:14.0/usb2/2-1"
> Jan
Oops with dwc3 in device mode and functionfs
Hello,
I am hitting the following oops with 4.10-rc2 (on an intel edison, so
this is with Andy's patchset[1] which is currently based on 4.10-rc2
and does not seem to touch usb code) with Felipe's fixes-for-v4.10-rc3
merged on top of it.
The oops + kdb traceback:
[ 42.537029] file system registered
[ 45.048685] systemd-hostnam (1666) used greatest stack depth: 5680 bytes left
[ 51.643687] read descriptors
[ 51.648273] read strings
[ 53.921220] configfs-gadget gadget: high-speed config #1: c
[ 53.927231] BUG: unable to handle kernel paging request at 00040905
[ 53.933683] IP: usb_ep_enable+0x23/0xb0 [udc_core]
[ 53.938585] *pde =
[ 53.938591]
[ 53.943060] Oops: [#1] SMP
Entering kdb (current=0xf40a8f00, pid 1866) on processor 0 Oops: (null)
due to oops @ 0xf812a023
CPU: 0 PID: 1866 Comm: irq/34-dwc3 Not tainted
4.10.0-rc2-edison-00061-g1a2e83d30e6d #18
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
task: f40a8f00 task.stack: f4d3a000
EIP: usb_ep_enable+0x23/0xb0 [udc_core]
EFLAGS: 00010046 CPU: 0
EAX: f4d996d4 EBX: f4d996c0 ECX: 00040905 EDX: f4d996dd
ESI: f4fa4200 EDI: f4d996d4 EBP: f4d3bdec ESP: f4d3bddc
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 80050033 CR2: 00040905 CR3: 01d62000 CR4: 001006d0
Call Trace:
ffs_func_set_alt+0x243/0x290 [usb_f_fs]
composite_setup+0xcf1/0x1ba0 [libcomposite]
? dwc3_gadget_exit+0x140/0x1c0 [dwc3]
dwc3_ep0_delegate_req+0x2d/0x40 [dwc3]
dwc3_ep0_interrupt+0x409/0xad0 [dwc3]
? dwc3_thread_interrupt+0x22/0xe80 [dwc3]
? _raw_spin_lock_irqsave+0x43/0x50
dwc3_thread_interrupt+0x120/0xe80 [dwc3]
? __schedule+0x65e/0x850
irq_thread_fn+0x18/0x30
irq_thread+0xef/0x180
? irq_finalize_oneshot+0xd0/0xd0
? wake_threads_waitq+0x40/0x40
? free_percpu_irq+0x60/0x60
kthread+0xfb/0x100
? free_percpu_irq+0x60/0x60
? kthread_stop+0x150/0x150
ret_from_fork+0x19/0x24
Code: 11 85 c0 89 45 f0 75 04 c6 47 19 01 3e 8d 74 26 00 eb 41 89 f6
same traceback, in (k)gdb:
(gdb) bt
#0 0xf812a023 in usb_ep_enable (ep=0xf4d996d4) at
drivers/usb/gadget/udc/core.c:109
#1 0xf967b533 in ffs_func_eps_enable (func=) at
drivers/usb/gadget/function/f_fs.c:1857
#2 ffs_func_set_alt (f=, interface=,
alt=) at drivers/usb/gadget/function/f_fs.c:3146
#3 0xf8179791 in set_config (ctrl=, number=, cdev=) at drivers/usb/gadget/composite.c:814
#4 0xf8b4030d in dwc3_ep0_delegate_req (dwc=0xf557b814,
ctrl=0xf4f2c000) at drivers/usb/dwc3/ep0.c:603
#5 0xf8b412a9 in dwc3_ep0_set_config (ctrl=,
dwc=) at drivers/usb/dwc3/ep0.c:622
#6 dwc3_ep0_std_request (ctrl=, dwc=)
at drivers/usb/dwc3/ep0.c:778
#7 dwc3_ep0_inspect_setup (event=, dwc=) at drivers/usb/dwc3/ep0.c:818
#8 dwc3_ep0_xfer_complete (event=, dwc=) at drivers/usb/dwc3/ep0.c:977
#9 dwc3_ep0_interrupt (dwc=0xf557b814, event=) at
drivers/usb/dwc3/ep0.c:1139
#10 0xf8b3d930 in dwc3_endpoint_interrupt (event=,
dwc=) at drivers/usb/dwc3/gadget.c:2245
#11 0xc10b1818 in irq_thread_fn (desc=0xf4d26600, action=0xf4d99200)
at kernel/irq/manage.c:896
#12 0xc10b1caf in irq_thread (data=0xf4d99200) at kernel/irq/manage.c:973
#13 0xc1074a6b in kthread (_create=0xf4c14f20) at kernel/kthread.c:227
#14 0xc185de01 in ret_from_fork () at arch/x86/entry/entry_32.S:295
(gdb) print *ep
$1 = {driver_data = 0xf4d996c0, name = 0xff00 , ops = 0x40905, ep_list = {next = 0xff,
prev = 0x500 }, caps =
{type_control = 0, type_iso = 0, type_bulk = 0, type_int = 0, dir_in =
0, dir_out = 0}, claimed = false,
enabled = false, maxpacket = 0, maxpacket_limit = 0, max_streams = 0,
mult = 0, maxburst = 0, address = 0 '\000', desc = 0xf4d996dd,
comp_desc = 0x0}
Note "name" and "ep_list.prev" are also broken, as likely ep_list.next.
Last command:
# echo dwc3.1.auto > /sys/kernel/config/usb_gadget/g1/UDC
Host's syslog:
Jan 3 15:20:23 vincent-tkpad kernel: [876929.788285] usb 2-1: new
high-speed USB device number 86 using xhci_hcd
Jan 3 15:20:23 vincent-tkpad kernel: [876929.918767] usb 2-1: New USB
device found, idVendor=1d6b, idProduct=0104
Jan 3 15:20:23 vincent-tkpad kernel: [876929.918771] usb 2-1: New USB
device strings: Mfr=1, Product=2, SerialNumber=3
Jan 3 15:20:23 vincent-tkpad kernel: [876929.918774] usb 2-1: Product: tesla
Jan 3 15:20:23 vincent-tkpad kernel: [876929.918776] usb 2-1:
Manufacturer: vpelletier
Jan 3 15:20:23 vincent-tkpad kernel: [876929.918777] usb 2-1:
SerialNumber: FZED443D01T42501
Jan 3 15:20:28 vincent-tkpad kernel: [876934.916146] usb 2-1: can't
set config #1, error -110
Jan 3 15:20:28 vincent-tkpad mtp-probe: checking bus 2, device 86:
"/sys/devices/pci:00/:00:14.0/usb2/2-1"
Jan 3 15:20:28 vincent-tkpad mtp-probe: bus: 2, device: 86 was not an
MTP device
Device is a single-configuration, single-function, single alt-setting,
zero endpoints, once-string, functionfs-based device.
The functionfs side of things is a bit complicated, as I'm writing a
python module[2] for it, and I am still very new to functionfs. It
does not crash on 4.9-rc7 though.
Is something else ne
