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: > > > > [ 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 __lock_acquire+0xa0/0xa6c > > [ 55.630000] LR is at lock_acquire+0x58/0x6c > > [ 55.630000] ... > > [ 55.630000] [<c005786c>] (__lock_acquire+0xa0/0xa6c) from [<c0058290>] (lock_acquire+0x58/0x6c) > > [ 55.630000] [<c0058290>] (lock_acquire+0x58/0x6c) from [<c0274e74>] > (_spin_lock_irqsave+0x44/0x58) > > [ 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) > > 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. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
