On Mon, 27 Nov 2017 11:17:54 +0200, Felipe Balbi
wrote:
> as I said, the *only* thing that schedules from inside
> dwc3_gadget_ep_dequeue() is wait_event_lock_irq(). Which works fine
> unless usb_ep_dequeue() is called with locks held and IRQs disabled.
This I understand, yes.
What puzzles me is
Hi,
Vincent Pelletier writes:
> On Sat, 25 Nov 2017 16:39:52 +, Vincent Pelletier
> wrote:
>> To my surprise, the error symptom do not seem to change:
>
> Having read some more on kernel debugging and especially critical
> sections, I realise that while the general issue is still there, the
On Sat, 25 Nov 2017 16:39:52 +, Vincent Pelletier
wrote:
> To my surprise, the error symptom do not seem to change:
Having read some more on kernel debugging and especially critical
sections, I realise that while the general issue is still there, the
symptom did change consistently with modif
On Fri, 24 Nov 2017 14:04:35 +, Vincent Pelletier
wrote:
> What seem to be the relevant pieces are:
> - at least one AIO transfers submitted for reading from EP2OUT
> - upon receiving data from stdin, a synchronous write happens on EP2IN,
> which blocks if host did not submit a transfer (nor
On Fri, 24 Nov 2017 15:55:02 +, Vincent Pelletier
wrote:
> write(6, "bla\n", 4)= -1 EINTR (Interrupted system call)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=1931, si_uid=1000} ---
I discovered this is not the whole truth: it is not the interruption
itself w
On Fri, 24 Nov 2017 15:10:55 +, Vincent Pelletier
wrote:
> It sadly does not help, though it does something: now serial output
> stops early (tried twice, happened twice):
>
> [ 103.274725] BUG: scheduling while atomic: swapper/1/0/0x0100
> [ 103.280990] 3 locks held by swapper/1/0:
> [
On Fri, 24 Nov 2017 16:45:53 +0200, Felipe Balbi
wrote:
> no, it's not. This is because of our call to wait_event_lock_irq() in
> dwc3_gadget_ep_dequeue(). That call works fine in all other cases
> because dequeue is never called with IRQs disabled, apart from this one
> case in f_fs.c :-)
>
> Ca
Hi,
Vincent Pelletier writes:
> On Fri, 24 Nov 2017 16:10:17 +0200, Felipe Balbi
> wrote:
>> $ gdb vmlinux
>> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
>>
>>
>> what does that give you?
>
> Note: this is a different debugging session, different traceback, but
> same kernel.
>
> $ gdb ./vmlinu
On Fri, 24 Nov 2017 16:10:17 +0200, Felipe Balbi
wrote:
> $ gdb vmlinux
> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
>
>
> what does that give you?
Note: this is a different debugging session, different traceback, but
same kernel.
$ gdb ./vmlinux
[...]
(gdb) target remote /dev/ttyUSB0
[...]
(gd
Hi,
Vincent Pelletier writes:
> Hello,
>
> I'm triggering a reproducible panic using a DWC3 in gadget mode
> (intel edison board). Built kernel is a 4.14 with all patches from
> Andy Shevchenko's tree for the edison (including ones to the dwc3 to
> skip EP1 & 8). It is available here:
> https:
Hello,
I'm triggering a reproducible panic using a DWC3 in gadget mode
(intel edison board). Built kernel is a 4.14 with all patches from
Andy Shevchenko's tree for the edison (including ones to the dwc3 to
skip EP1 & 8). It is available here:
https://github.com/vpelletier/linux/tree/eds_4.14
T
11 matches
Mail list logo
