Semi-reproduceable panic (console/TTY/X/USB keyboard related?)

Gavin Atkinson gavin.atkinson at
Thu May 26 06:35:01 PDT 2005


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

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

[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

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,

 - 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++);
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
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.


More information about the freebsd-stable mailing list