gdb internal error when trying to get stack trace from kernel dump

[Dave Huang <khym%azeotrope.org@localhost>]

It seems like ever since I increased some networking-related buffer 
sizes, my system, an AlphaPC 164 with 256MB RAM running 7.0_RC2, 
frequently crashes when a Mac on the network starts a Time Machine 
backup to the Alpha (which is running netatalk/afpd). The sysctls I 
changed are:

kern.sbmax=4194304
net.inet.tcp.recvbuf_max=4194304
net.inet.tcp.sendbuf_max=4194304
net.inet.tcp.recvbuf_inc=131072
net.inet.tcp.sendbuf_inc=131072

and I recompiled the kernel for:
kern.mbuf.nmbclusters = 16384

The alpha crashes with the following messages:

CPU 0: fatal kernel trap:

CPU 0    trap entry = 0x2 (memory management fault)
CPU 0    a0         = 0x78
CPU 0    a1         = 0x1
CPU 0    a2         = 0x0
CPU 0    pc         = 0xfffffc00004c7d00
CPU 0    ra         = 0xfffffc00004c7cc0
CPU 0    pv         = 0xfffffc000044da70
CPU 0    curlwp     = 0xfffffc000fe55980
CPU 0        pid = 0, comm = system

panic: trap
cpu0: Begin traceback...
alpha trace requires known PC =eject=
cpu0: End traceback...

So, I wanted to try to figure out what was going on, but I can't get 
gdb to give me a stack trace:

# gdb netbsd.gdb
GNU gdb (GDB) 7.7.1
[ ... ]
Reading symbols from netbsd.gdb...done.
(gdb) target kvm /var/crash/netbsd.57.core
PC not available
<unavailable> in ?? ()
(gdb) bt
#-1 <unavailable> in ?? ()
#0  <unavailable> in ?? ()
/usr/src/external/gpl3/gdb/dist/gdb/frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

/usr/src/external/gpl3/gdb/dist/gdb/frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n

Is this related to "alpha trace requires known PC" and "PC not 
available"?

The trap message does show a pc though, and the info from that does 
seem to be good:

(gdb) list *0xfffffc00004c7d00
0xfffffc00004c7d00 is in fxp_txintr (/usr/src/sys/dev/ic/i82557.c:1182).
1177                    txstat = le16toh(txd->txd_txcb.cb_status);
1178
1179                    if ((txstat & FXP_CB_STATUS_C) == 0)
1180                            break;
1181
1182                    bus_dmamap_sync(sc->sc_dmat, txs->txs_dmamap,
1183                        0, txs->txs_dmamap->dm_mapsize,
1184                        BUS_DMASYNC_POSTWRITE);
1185                    bus_dmamap_unload(sc->sc_dmat, txs->txs_dmamap);
1186                    m_freem(txs->txs_mbuf);

So, I wanted to mention the gdb problem, and also ask if anyone had 
tips on how to further debug this. I guess I could manually select a 
stack frame using the "frame" command if I knew its address, but I 
don't know where to get that. And why would bus_dmamap_sync() cause a 
memory management fault?

-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym%azeotrope.org@localhost |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++