Gavin Atkinson
2005-May-26 13:35 UTC
Semi-reproduceable panic (console/TTY/X/USB keyboard related?)
Hey,
I have a panic which I can reproduce quite easily (approx. 25% success)
on a "5.4-STABLE #12: Sun May 8 16:03:04 BST 2005" system. The stack
seems to be corrupt but hopefully I've been able to extract enough
information to help analysis.
Some background:
I have a USB keyboard on UHCI controller. The panic happens when using
the system console, but I have not been able to reproduce the panic
unless I am running X. Note that the entry in /etc/ttys for the ttyv0
getty is set to "off". I suspect this is significant.
To reproduce:
Load up X, then press Ctrl-Alt-F1 to get backl to the system console.
When the console is visible, press up-arrow. *boom*. I cannot get a
crashdump on this system, but hopefully I've managed to get enough from
ddb for somebody to at least understand what's happening.
Other info:
As far as I can tell, switching to a console which is running a getty
then pressing up-arrow does not cause the crash. Once that's been done,
switching to one that isn't running getty and pressing up-arrow does not
panic.
Result (and a bit of commentary):
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xae87
fault code = supervisor read, page not present
instruction pointer = 0x8:0xae87
stack pointer = 0x10:0xcbc4cbb8
frame pointer = 0x10:0xcbc4cbd4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 26 (irq16: uhci0 uhci3)
[thread pid 26 tid 100020 ]
Stopped at 0xae87: *** error reading from address ae87 ***
db> tr
Tracing pid 26 tid 100020 td 0xc1525000
db>
[Never seen tr not work before. OK, lets look at the stack pointer]
db> x/x 0xcbc4cb78,10
0xcbc4cb78: c2d90018 10 10 c08db962
0xcbc4cb88: c09403a0 cbc4cbd4 cbc4cba4 c16d3e00
0xcbc4cb98: c0642060 3 1b c
0xcbc4cba8: 0 ae87 8 10283
db> x/x 0xcbc4cbb8,10
0xcbc4cbb8: c07955db 1b c16d3e00 2
0xcbc4cbc8: c08da4e0 6 c08da4f0 cbc4cc10
0xcbc4cbd8: c05b2f57 c08da400 0 c09403a0
0xcbc4cbe8: 45a1fb2c 3756 0 0
db>
For those values within the kernel (starting from the addresses higher
up in the stack and working down), addr2line and/or disassembling the
kernel itself gives:
0xc05b2f57 is the following call within dev/usb/ukbd.c:ukbd_interrupt()
/* let the callback function to process the input */
(*kbd->kb_callback.kc_func)(kbd, KBDIO_KEYINPUT,
kbd->kb_callback.kc_arg);
- here kbd = the address of the default_kbd structure in dev/usb/ukbd.c
0xc07955db is the return address of the following call to ttyld_rint
(which is inlined) in dev/syscons/syscons.c:sckbdevent()
case FKEY: /* function key, return string */
cp = kbd_get_fkeystr(thiskbd, KEYCHAR(c), &len);
if (cp != NULL) {
while (len-- > 0)
ttyld_rint(cur_tty, *cp++);
}
break;
I guess, from the stack, cur_tty = 0xc16d3e00 and *cp++ = 0x1b (ESC),
which would make sense given it was up-arrow I pressed - I guess that
generates an escape character as it's first byte.
And three which are probably noise on the stack:
0xc0642060 is the entry point of ttymodem() in kern/tty.c
0xc08da4e0 is the address of the default_kbd_state structure in
dev/usb/ukbd.c
0xc08da400 is the address of the default_kbd structure in dev/usb/ukbd.c
ttyld_rint is the following code:
return ((*linesw[tp->t_line]->l_rint)(c, tp));
So I guess either l_rint is invalid, or whatever the function points to
is trashing the stack before returning.
>From here, I don't know how to progress. what should l_rint point to?
I'm happy to crash my machine again if I can tease more information out
of ddb, but as I say I can't get a crashdump. I'd be interested to know
if anyone else can recreate this, too.
Gavin