Port-alpha archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
gdb internal error when trying to get stack trace from kernel dump
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++
Home |
Main Index |
Thread Index |
Old Index