Hello,
I would like to ask if someone has successfully used g-serial USB gadget driver with kernel 2.6.29 or 2.6.30? I'm developing a low level hardware driver for USB gadgets on ARM S3C6410 platform. This driver is working quite fine (I've used it a lot with g-ether CDC/RNDIS ethernet gadget driver). During my development I've found the following bug in g-serial driver:
On Linux host:
# cat /dev/ttyACM0
On device:
# cat >/dev/ttyGS0
[ 1897.350000] BUG: sleeping function called from invalid context at kernel/mutex.c:94
[ 1897.360000] in-atomic(): 1, irqs-disabled(): 0, pid: 0, name: swapper
[ 1897.370000] [<c0024afc>] (unwind-backtrace+0x0/0xdc) from [<c0267218>] (mutex-lock+0x14/0x30)
[ 1897.380000] [<c0267218>] (mutex-lock+0x14/0x30) from [<c014ceac>] (echo-char-raw+0x1c/0x48)
[ 1897.390000] [<c014ceac>] (echo-char-raw+0x1c/0x48) from [<c014ecdc>] (n-tty-receive-buf+0x9dc/0xec4)
[ 1897.390000] [<c014ecdc>] (n-tty-receive-buf+0x9dc/0xec4) from [<c01513bc>] (flush-to-ldisc+0x104/0x1b0)
[ 1897.400000] [<c01513bc>] (flush-to-ldisc+0x104/0x1b0) from [<bf001ce8>] (gs-rx-push+0x118/0x1cc [g-serial])
[ 1897.410000] [<bf001ce8>] (gs-rx-push+0x118/0x1cc [g-serial]) from [<c003c7c0>] (tasklet-action+0x78/0xc8)
[ 1897.420000] [<c003c7c0>] (tasklet-action+0x78/0xc8) from [<c003cc54>] ([ 1897.480000] 9fa0: c0349fc0 c0349fb8 c0020394 c0020398 20000013 ffffffff
[ 1897.480000] [<c001ea28>] (
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Peter Korsgaard on
2009-06-22T12:34:47+00:00
>>>>> "Marek" == Marek Szyprowski <m.szyprowski@samsung.com> writes:
Marek> Hello,
Marek> I would like to ask if someone has successfully used g-serial
Marek> USB gadget driver with kernel 2.6.29 or 2.6.30? I'm developing
Marek> a low level hardware driver for USB gadgets on ARM S3C6410
Marek> platform. This driver is working quite fine (I've used it a
Marek> lot with g-ether CDC/RNDIS ethernet gadget driver). During my
Marek> development I've found the following bug in g-serial driver:
You are aware that Ben Dooks has written an UDC driver for the OTG
controller on the s3c6410 which is now in mainline, right?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5b7d70c6dbf2db786395cbd21750a1a4ce222f84
I've used the g-serial driver on 2.6.29 without problems (not on
s3c6410 though).
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-22T13:56:44+00:00
Hello,
On Monday, June 22, 2009 2:34 PM, Peter Korsgaard wrote:
> Marek> I would like to ask if someone has successfully used g-serial
> Marek> USB gadget driver with kernel 2.6.29 or 2.6.30? I'm developing
> Marek> a low level hardware driver for USB gadgets on ARM S3C6410
> Marek> platform. This driver is working quite fine (I've used it a
> Marek> lot with g-ether CDC/RNDIS ethernet gadget driver). During my
> Marek> development I've found the following bug in g-serial driver:
>
> You are aware that Ben Dooks has written an UDC driver for the OTG
> controller on the s3c6410 which is now in mainline, right?
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> 2.6.git;a=commit;h=5b7d70c6dbf2db786395cbd21750a1a4ce222f84
Yes, I am aware. That driver does not work well for me (but this is the
other case). However I did a test with his driver and the result was also
a kernel oops:
[ 162.520000] BUG: sleeping function called from invalid context at
kernel/mutex.c:94
[ 162.530000] in-atomic(): 1, irqs-disabled(): 0, pid: 504, name: cat
[ 162.540000] [<c0024afc>] (unwind-backtrace+0x0/0xdc) from [<c0268a28>]
(mutex-lock+0x14/0x30)
[ 162.540000] [<c0268a28>] (mutex-lock+0x14/0x30) from [<c014ceb4>]
(echo-set-canon-col+0x1c/0x44)
[ 162.550000] [<c014ceb4>] (echo-set-canon-col+0x1c/0x44) from [<c014eeb0>]
(n-tty-receive-buf+0xbf0/0xec4)
[ 162.560000] [<c014eeb0>] (n-tty-receive-buf+0xbf0/0xec4) from
[<c015137c>] (flush-to-ldisc+0x104/0x1b0)
[ 162.570000] [<c015137c>] (flush-to-ldisc+0x104/0x1b0) from [<bf002238>]
(gs-rx-push+0x118/0x1cc [g-serial])
[ 162.580000] [<bf002238>] (gs-rx-push+0x118/0x1cc [g-serial]) from
[<c003c780>] (tasklet-action+0x78/0xc8)
[ 162.590000] [<c003c780>] (tasklet-action+0x78/0xc8) from [<c003cc14>]
([ 162.620000] Exception stack(0xc6567e78 to 0xc6567ec0)
[ 162.630000] 7e60:
c6c883c0 00000013
[ 162.640000] 7e80: ffffffff 00000001 00000013 00000004 c64df800 00000013
c6566000 c659c0a0
[ 162.640000] 7ea0: c6526c30 c64df800 c6567e80 c6567ec0 c02699bc c02699d0
60000013 ffffffff
[ 162.650000] [<c001ea28>] ((tty-write+0x180/0x21c)
[ 162.690000] [<c014b078>] (tty-write+0x180/0x21c) from [<c008c4d4>]
(vfs-write+0xac/0x158)
[ 162.700000] [<c008c4d4>] (vfs-write+0xac/0x158) from [<c008c638>]
(sys-write+0x40/0x6c)
[ 162.700000] [<c008c638>] (sys-write+0x40/0x6c) from [<c001ede0>]
(ret-fast-syscall+0x0/0x2c)
[ 162.710000] [ 69.830000] CPU: 0 Not tainted (2.6.30 #336)
[ 69.830000] PC is at gs-write+0x50/0x58 [g-serial]
[ 69.840000] LR is at check-preempt-wakeup+0x24/0x114
[ 69.840000] pc : [<bf000a48>] lr : [<c002fc5c>] psr: 60000013
[ 69.840000] sp : c6553ed0 ip : c64698e0 fp : c6469c00
[ 69.850000] r10: c6469b80 r9 : c6ffd300 r8 : c6552000
[ 69.860000] r7 : 00000005 r6 : 00000004 r5 : 00000013 r4 : c6ffd980
[ 69.860000] r3 : 00000004 r2 : 00000000 r1 : 00000001 r0 : 00000000
[ 69.870000] Flags: nZCv IRQs on FIQs on Mode SVC-32 ISA ARM Segment
user
[ 69.880000] Control: 00c5387d Table: 56580008 DAC: 00000015
> I've used the g-serial driver on 2.6.29 without problems (not on
> s3c6410 though).
On what hardware you use the g-serial driver? It is ARM-based? I
understand that this might be also related to the way that low level
hardware gadget driver is implemented, but I really have no idea how
to hunt for this bug.
Best regards
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Peter Korsgaard on
2009-06-22T14:07:12+00:00
>>>>> "Marek" == Marek Szyprowski <m.szyprowski@samsung.com> writes:
Hi,
Marek> Yes, I am aware. That driver does not work well for me (but
Marek> this is the other case). However I did a test with his driver
Marek> and the result was also a kernel oops:
Ok :/
Any plans on merging your stuff with Ben's driver?
>> I've used the g-serial driver on 2.6.29 without problems (not on
>> s3c6410 though).
Marek> On what hardware you use the g-serial driver? It is ARM-based?
Marek> I understand that this might be also related to the way that
Marek> low level hardware gadget driver is implemented, but I really
Marek> have no idea how to hunt for this bug.
No, it was on PowerPC (mpc8347).
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Alan Stern on
2009-06-22T14:07:31+00:00
On Mon, 22 Jun 2009, Marek Szyprowski wrote:
> Hello,
>
> On Monday, June 22, 2009 2:34 PM, Peter Korsgaard wrote:
>
> > Marek> I would like to ask if someone has successfully used g-serial
> > Marek> USB gadget driver with kernel 2.6.29 or 2.6.30? I'm developing
> > Marek> a low level hardware driver for USB gadgets on ARM S3C6410
> > Marek> platform. This driver is working quite fine (I've used it a
> > Marek> lot with g-ether CDC/RNDIS ethernet gadget driver). During my
> > Marek> development I've found the following bug in g-serial driver:
> >
> > You are aware that Ben Dooks has written an UDC driver for the OTG
> > controller on the s3c6410 which is now in mainline, right?
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> > 2.6.git;a=commit;h=5b7d70c6dbf2db786395cbd21750a1a4ce222f84
>
> Yes, I am aware. That driver does not work well for me (but this is the
> other case). However I did a test with his driver and the result was also
> a kernel oops:
>
> [ 162.520000] BUG: sleeping function called from invalid context at
> kernel/mutex.c:94
> [ 162.530000] in-atomic(): 1, irqs-disabled(): 0, pid: 504, name: cat
> [ 162.540000] [<c0024afc>] (unwind-backtrace+0x0/0xdc) from [<c0268a28>]
> (mutex-lock+0x14/0x30)
> [ 162.540000] [<c0268a28>] (mutex-lock+0x14/0x30) from [<c014ceb4>]
> (echo-set-canon-col+0x1c/0x44)
> [ 162.550000] [<c014ceb4>] (echo-set-canon-col+0x1c/0x44) from [<c014eeb0>]
> (n-tty-receive-buf+0xbf0/0xec4)
> [ 162.560000] [<c014eeb0>] (n-tty-receive-buf+0xbf0/0xec4) from
> [<c015137c>] (flush-to-ldisc+0x104/0x1b0)
> [ 162.570000] [<c015137c>] (flush-to-ldisc+0x104/0x1b0) from [<bf002238>]
> (gs-rx-push+0x118/0x1cc [g-serial])
> [ 162.580000] [<bf002238>] (gs-rx-push+0x118/0x1cc [g-serial]) from
> [<c003c780>] (tasklet-action+0x78/0xc8)
> [ 162.590000] [<c003c780>] (tasklet-action+0x78/0xc8) from [<c003cc14>]
> (> [ 162.620000] Exception stack(0xc6567e78 to 0xc6567ec0)
> [ 162.630000] 7e60:
> c6c883c0 00000013
> [ 162.640000] 7e80: ffffffff 00000001 00000013 00000004 c64df800 00000013
> c6566000 c659c0a0
> [ 162.640000] 7ea0: c6526c30 c64df800 c6567e80 c6567ec0 c02699bc c02699d0
> 60000013 ffffffff
> [ 162.650000] [<c001ea28>] (> (tty-write+0x180/0x21c)
> [ 162.690000] [<c014b078>] (tty-write+0x180/0x21c) from [<c008c4d4>]
> (vfs-write+0xac/0x158)
> [ 162.700000] [<c008c4d4>] (vfs-write+0xac/0x158) from [<c008c638>]
> (sys-write+0x40/0x6c)
> [ 162.700000] [<c008c638>] (sys-write+0x40/0x6c) from [<c001ede0>]
> (ret-fast-syscall+0x0/0x2c)
> [ 162.710000] the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-22T14:13:35+00:00
Hello,
On Monday, June 22, 2009 4:07 PM, Alan Stern wrote:
> > > Marek> I would like to ask if someone has successfully used
> g-serial
> > > Marek> USB gadget driver with kernel 2.6.29 or 2.6.30? I'm
> developing
> > > Marek> a low level hardware driver for USB gadgets on ARM S3C6410
> > > Marek> platform. This driver is working quite fine (I've used it a
> > > Marek> lot with g-ether CDC/RNDIS ethernet gadget driver). During
> my
> > > Marek> development I've found the following bug in g-serial
> driver:
> > >
> > > You are aware that Ben Dooks has written an UDC driver for the OTG
> > > controller on the s3c6410 which is now in mainline, right?
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> > > 2.6.git;a=commit;h=5b7d70c6dbf2db786395cbd21750a1a4ce222f84
> >
> > Yes, I am aware. That driver does not work well for me (but this is
> the
> > other case). However I did a test with his driver and the result was
> also
> > a kernel oops:
> >
> > [...]
> >
> > > I've used the g-serial driver on 2.6.29 without problems (not on
> > > s3c6410 though).
> >
> > On what hardware you use the g-serial driver? It is ARM-based? I
> > understand that this might be also related to the way that low level
> > hardware gadget driver is implemented, but I really have no idea how
> > to hunt for this bug.
>
> This is just a guess... But there's a good possibility that the oops
> was caused by recent changes to the serial layer which have not been
> propagated through to the g-serial driver.
How recent these changes are? I did a test on another ARM-based Linux
platform with old 2.6.28 kernel and the result was exactly the same as
above...
Best regards
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Alan Stern on
2009-06-22T15:02:45+00:00
On Mon, 22 Jun 2009, Marek Szyprowski wrote:
> > This is just a guess... But there's a good possibility that the oops
> > was caused by recent changes to the serial layer which have not been
> > propagated through to the g-serial driver.
>
> How recent these changes are? I did a test on another ARM-based Linux
> platform with old 2.6.28 kernel and the result was exactly the same as
> above...
I think the changes are new in 2.6.30. So they aren't the reason for
you oops, after all.
Alan Stern
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-23T03:27:11+00:00
On Monday 22 June 2009, Marek Szyprowski wrote:
>
> > This is just a guess... But there's a good possibility that the oops
> > was caused by recent changes to the serial layer which have not been
> > propagated through to the g-serial driver.
>
> How recent these changes are? I did a test on another ARM-based Linux
> platform with old 2.6.28 kernel and the result was exactly the same as
> above...
Just for the record, the reworked g-serial code merged in 2.6.27
and was mostly developed on 2.6.25 and 2.6.26 ... and it included
a lot of stress testing. No such mutex-lock() in-irq() bug showed
up at that time. And that was running with all practical kernel
debug options, so it should have showed up if it were that easy.
I do however recall turning up several regressions in how "sparse"
lock checking behaved. As in, it broke when faced with common
idioms like needing to temporarily drop a lock deep in a call stack.
Now, the serial layer has been getting a *LONG* overdue incremental
overhaul since before that started. So there's been plenty of time
for incompatible changes to sneak in; I believe Alan Cox focuses on
host side things, out of defensive necessity.
Like, oh, changing a spinlock to a mutex. You might change the
low-latency setting and review how that's now supposed to behave.
- Dave
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-23T06:43:05+00:00
Hello,
On Tuesday, June 23, 2009 5:27 AM, David Brownell wrote:
> > > This is just a guess...
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-23T07:22:58+00:00
On Monday 22 June 2009, Marek Szyprowski wrote:
>
> > Like, oh, changing a spinlock to a mutex. You might change the
> > low-latency setting and review how that's now supposed to behave.
>
> In in gs-open() function in drivers/usb/gadget/u-serial.c, after the
> line 780 I've added:
>
> tty->low-latency = 1;
That's already how it's set. Try instead *REMOVING* the line
which sets that flag.
> This helped a bit, but after a few serial transfers I got the same
> bug again.
Of course. You didn't change anything.
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-23T08:39:03+00:00
Hello,
On Tuesday, June 23, 2009 9:23 AM, David Brownell wrote:
> > > Like, oh, changing a spinlock to a mutex.
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Alan Cox on
2009-06-23T09:21:01+00:00
> that g-serial driver interacts with tty layer in that packet-done callback,
> so this is the source of the problems. I noticed that some other UDC
> drivers also does all its job from an interrupt, so they also might be
> affected. How this bug should be properly resolved?
Either by not setting ->low-latency or by running the data paths from a
non IRQ context.
Basically: don't set tty->low-latency if you are handling the processing
from the IRQ path. The only case low-latency is useful is handling data
from a non-IRQ path where you have latency concerns for tx/rx switching.
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-23T09:35:08+00:00
Hello,
On Tuesday, June 23, 2009 11:21 AM, Alan Cox wrote:
> > that g-serial driver interacts with tty layer in that packet-done
> callback,
> > so this is the source of the problems. I noticed that some other UDC
> > drivers also does all its job from an interrupt, so they also might
> be
> > affected. How this bug should be properly resolved?
>
> Either by not setting ->low-latency or by running the data paths from a
> non IRQ context.
>
> Basically: don't set tty->low-latency if you are handling the
> processing
> from the IRQ path. The only case low-latency is useful is handling data
> from a non-IRQ path where you have latency concerns for tx/rx
> switching.
I know that, but I wonder how this should be handled in g-serial gadget
driver, which might be working on top of both types of low level
drivers (doing callback from irq or tasklet).
Are there any drawbacks of disabling low-latency mode if callbacks are
done from tasklet not from interrupt? If no then the low latency mode
should be disabled in g-serial driver.
Best regards
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Alan Cox on
2009-06-23T09:53:59+00:00
> Are there any drawbacks of disabling low-latency mode if callbacks are
> done from tasklet not from interrupt?
Not really no
Alan
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-23T15:02:13+00:00
Hello,
On Tuesday, June 23, 2009 11:55 AM, Alan Cox wrote:
> > Are there any drawbacks of disabling low-latency mode if callbacks
> are
> > done from tasklet not from interrupt?
>
> Not really no
David: do you want to update a g-serial driver and disable the low latency
mode, or should I post a patch that does it? Or do you have other plan to
solve this issue? I tested the g-serial driver with low latency mode
disabled and it works quite fine here on ARM S3C6410.
Best regards
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-23T16:48:04+00:00
On Tuesday 23 June 2009, Marek Szyprowski wrote:
> David: do you want to update a g-serial driver and disable the low latency
> mode, or should I post a patch that does it? Or do you have other plan to
> solve this issue? I tested the g-serial driver with low latency mode
> disabled and it works quite fine here on ARM S3C6410.
I'd like you to submit that.
- Dave
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-23T16:53:09+00:00
On Tuesday 23 June 2009, Marek Szyprowski wrote:
> /* low-latency means ldiscs work in tasklet context, without
> * needing a workqueue schedule ... easier to keep up.
> */
>
> So in low latency mode calls are made from a tasklet.
... and that has, at some point since 2.6.26 or so, become a
problem that caused oopsing.
> This is not true in
> my case, as the S3C OTG UDC driver does all its job in interrupts. This
> way also a (usb) packet-done callback is done from an interrupt. I expect
> that g-serial driver interacts with tty layer in that packet-done callback,
> so this is the source of the problems. I noticed that some other UDC
> drivers also does all its job from an interrupt, so they also might be
> affected. How this bug should be properly resolved?
Change the u-serial.c code so that this newish tty behavior
stops causing problems: don't set low-latency.
But also try and sort through any consequences of that, and
don't forget to update the comments which talk about how the
low-latency setting is affecting code flow.
- Dave
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-24T07:08:55+00:00
Hello,
On Tuesday, June 23, 2009 6:53 PM David Brownell wrote:
> > /* low-latency means ldiscs work in tasklet context, without
> >
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Alan Cox on
2009-06-24T08:42:08+00:00
> [ 55.630000] [<c0274e74>] (-spin-lock-irqsave+0x44/0x58) from [<c019d608>] (gs-write-room+0x10/0x58)
> [ 55.630000] [<c019d608>] (gs-write-room+0x10/0x58) from [<c0156058>] (tty-write-room+0x20/0x28)
> [ 55.630000] [<c0156058>] (tty-write-room+0x20/0x28) from [<c01538e0>] (process-echoes+0x4c/0x288)
> [ 55.630000] [<c01538e0>] (process-echoes+0x4c/0x288) from [<c0155a40>] (n-tty-receive-buf+0x9ec/0xecc)
> [ 55.630000] [<c0155a40>] (n-tty-receive-buf+0x9ec/0xecc) from [<c0158174>] (flush-to-ldisc+0x104/0x1b0)
> [ 55.630000] [<c0158174>] (flush-to-ldisc+0x104/0x1b0) from [<c00498e0>] (worker-thread+0x1d0/0x2cc)
> [ 55.630000] [<c00498e0>] (worker-thread+0x1d0/0x2cc) from [<c004d55c>] (kthread+0x58/0x90)
> [ 55.630000] [<c004d55c>] (kthread+0x58/0x90) from [<c003c03c>] (do-exit+0x0/0x5d0)
> [ 55.630000] [<c003c03c>] (do-exit+0x0/0x5d0) from [<c6c26180>] (0xc6c26180)
> [ 55.630000] Code: ea000076 e59d100c e3510000 1a000002 (e5994004)
> [ 55.640000] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-24T08:50:16+00:00
On Wednesday 24 June 2009, Marek Szyprowski wrote:
> I did some additional tests and found another bug. When I enabled debug in my
> low level udc driver then I can easily trigger the following bug:
>
> [ 55.630000] Unable to handle kernel NULL pointer dereference at virtual address 00000014
> [ 55.630000] pgd = c0004000
> [ 55.630000] [00000014] *pgd=00000000
> [ 55.630000] Internal error: Oops: 17 [#1] PREEMPT
> [ 55.630000] Modules linked in:
> [ 55.630000] CPU: 0 Not tainted (2.6.30 #355)
> [ 55.630000] PC is at
So it's looking like tty->driver-data is somehow NULL. That's
never supposed to happen. Did gs-open() fail or something?
> [ 55.630000] [<c0156058>] (tty-write-room+0x20/0x28) from [<c01538e0>] (process-echoes+0x4c/0x288)
> [ 55.630000] [<c01538e0>] (process-echoes+0x4c/0x288) from [<c0155a40>] (n-tty-receive-buf+0x9ec/0xecc)
> [ 55.630000] [<c0155a40>] (n-tty-receive-buf+0x9ec/0xecc) from [<c0158174>] (flush-to-ldisc+0x104/0x1b0)
> [ 55.630000] [<c0158174>] (flush-to-ldisc+0x104/0x1b0) from [<c00498e0>] (worker-thread+0x1d0/0x2cc)
> [ 55.630000] [<c00498e0>] (worker-thread+0x1d0/0x2cc) from [<c004d55c>] (kthread+0x58/0x90)
> [ 55.630000] [<c004d55c>] (kthread+0x58/0x90) from [<c003c03c>] (do-exit+0x0/0x5d0)
> [ 55.630000] [<c003c03c>] (do-exit+0x0/0x5d0) from [<c6c26180>] (0xc6c26180)
> [ 55.630000] Code: ea000076 e59d100c e3510000 1a000002 (e5994004)
> [ 55.640000]
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-24T08:54:54+00:00
On Wednesday 24 June 2009, Alan Cox wrote:
> Looks to me like the gs-write-room function takes a lock already held
> when the driver calls tty-flip-buffer-push() - which will and can call
> back into the driver (eg for echo processing)
That doesn't seem to explain whatever null pointer was being
traversed though.
A lock-already-held problem would self-deadlock, not oops.
RE: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by Marek Szyprowski on
2009-06-24T10:33:08+00:00
Hello,
On Wednesday, June 24, 2009 10:50 AM, David Brownell wrote:
> > I did some additional tests and found another bug. When I enabled debug in my
> > low level udc driver then I can easily trigger the following bug:
> >
> > [
Re: PROBLEM: kernel oops with g_serial USB gadget on 2.6.30 by David Brownell on
2009-06-24T23:44:09+00:00
On Wednesday 24 June 2009, Marek Szyprowski wrote:
>
> > So it's looking like tty->driver-data is somehow NULL. That's
> > never supposed to happen. Did gs-open() fail or something?
>
> I've triggered this bug by running a 'getty -L 115200 ttyGS0 vt100' and trying
> to login on that usb console and then pressing 'enter' key for longer time.
> getty might abort after a few failed logins, so the /dev/ttyGS0 file might be
> closed before all characters that need to be echoed were processed (usb udc debug
> messages really slows it down). This is however a pure guessing, I know nothing
> about tty framework and internals.
Hmm, that would mean the shutdown processing isn't behaving
right. Plausible, it's tricky to test.
Patches accepted. ;)