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

[Dave Huang]

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: kh...@azeotrope.org | 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++

[Christos Zoulas]

In article <D524F481-144F-4CC3...@azeotrope.org>,

Looks like the alpha kvm support has grown stale. Can you compare the register
layout in gdb with the one in the kernel?

christos