a panic on uart_z8530_class?

[Benjamin Kaduk]

On Sat, 8 May 2010, Weongyo Jeong wrote:

> Hello,
>
> Anyone encountered this panic on recent CURRENT kernel?
> db> bt
> Tracing pid 1795 tid 100096 td 0xffffff0003d8b390
> uart_z8530_class() at 0
> ifc_simple_create() at ifc_simple_create+0x89
> if_clone_createif() at if_clone_createif+0x64
> ifioctl() at ifioctl+0x685
> kern_ioctl() at kern_ioctl+0xc5
> ioctl() at ioctl+0xfd
> syscall() at syscall+0x102
> Xfast_syscall() at Xfast_syscall+0xe1
> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffffffe2e8, rbp = 0x7fffffffee36 ---


I haven't seen that particular panic, but I have seen uart_z8530_class (or 
something superficially similar to it) in stack traces that I can't see 
touching a uart device.


> [root at test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> Cannot access memory at address 0xffffff0127ffffe0
> (kgdb) bt
> #0  0x0000000000000000 in ?? ()
> Cannot access memory at address 0x0
> (kgdb) q


I have seen this behavior from kgdb --- it doesn't seem to be able to 
handle coredumps I've made recently.  At first I thought that I managed to 
trash either my kernel image or kgdb binary with all the unclean 
shutdowns I've been having, but if you're seeing kgdb failures, maybe it's 
not just my local system.

Yet I am assuming that this is not broken for *everyone*, or we would have 
heard more noise about it.

I'm running a current snapshot from April 4th; maybe I will try updating 
to a new snapshot tonight and see if kgdb behaves better after everything 
is rebuilt.

-Ben Kaduk