I'm updating a machine (Pentium II 350, 128MB RAM) to -current, and ran
into this panic in the fxp driver. Sources are from today (5/1/2001).
I believe the chip is an 82557.
I compiled and installed a kernel, rebooted and started running an
installworld over NFS. The installworld stopped here:
===> usr.bin/basename
install -c -s -o root -g wheel -m 555 basename /usr/bin
install -c -o root -g wheel -m 444 basename.1.gz /usr/share/man/man1
/usr/share/man/man1/dirname.1.gz -> /usr/share/man/man1/basename.1.gz
===> usr.bin/biff
install -c -s -o root -g wheel -m 555 biff /usr/bin
install -c -o root -g wheel -m 444 biff.1.gz /usr/share/man/man1
===> usr.bin/brandelf
install -c -s -o root -g wheel -m 555 brandelf /usr/bin
The stack trace:
(kgdb) where
#0 m_freem (m=0xc0b84d00) at ../../kern/uipc_mbuf.c:572
#1 0xc018ef76 in fxp_intr (xsc=0xc1372800) at ../../dev/fxp/if_fxp.c:993
#2 0xc01fe533 in ithread_loop (arg=0xc136be80) at ../../kern/kern_intr.c:517
#3 0xc01fd0e0 in fork_exit (callout=0xc01fe1c8 <ithread_loop>,
arg=0xc136be80, frame=0xc926ffa8) at ../../kern/kern_fork.c:731
It blew up on line 572 of uipc_mbuf:
(kgdb) list
567 /*
568 * we do need to check non-first mbuf, since some of existing
569 * code does not call M_PREPEND properly.
570 * (example: call to bpf_mtap from drivers)
571 */
572 if ((m->m_flags & M_PKTHDR) != 0 && m->m_pkthdr.aux) {
573 m_freem(m->m_pkthdr.aux);
574 m->m_pkthdr.aux = NULL;
575 }
576 MFREE(m, n);
It looks like the mbuf pointer is bogus:
(kgdb) print m
$2 = (struct mbuf *) 0xf0006b00
(kgdb) print *m
Cannot access memory at address 0xf0006b00.
Although in the next frame up the stack, the mbuf pointer looks okay:
(kgdb) up
#1 0xc018ef76 in fxp_intr (xsc=0xc1372800) at ../../dev/fxp/if_fxp.c:993
(kgdb) print txp->mb_head
$3 = (struct mbuf *) 0xc0b84d00
(kgdb) print *txp->mb_head
$4 = {m_hdr = {mh_next = 0xc0b8ea00, mh_nextpkt = 0x0,
mh_data = 0xc0b84dd6 "", mh_len = 42, mh_type = 0, mh_flags = 2}, M_dat = {
MH = {MH_pkthdr = {rcvif = 0x0, len = 178, header = 0xcb90adb,
csum_flags = 0, csum_data = 6, aux = 0x0}, MH_dat = {MH_ext = {
ext_buf = 0x1f943403 <Address 0x1f943403 out of bounds>,
ext_free = 0, ext_args = 0x2000000, ext_size = 2743468288,
ref_cnt = 0x3000000, ext_type = 50331648},
MH_databuf =
"\0034\224\037\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\0000",
'\000' <repeats 19 times>,
"\a\000\000\000\000\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\024\000\000\000\037\000\000\000\000\000\000\000\000C\235(J¡àaëÏ\220V¦ý\037\002#¹Î3+\005\233üñôç\036D\a\212wõR<W\0034\224\036\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\0000",
'\000' <repeats 15 times>,
"°Ð{Ñ\036\000 ɳ¼G\b\000E\000\000¤¸\233\000\000@\021RÅ¢>\2256¢>\2255\003õ\b\001\000\220ÜC"}},
M_databuf =
"\000\000\000\000²\000\000\000Û\n¹\f\000\000\000\000\006\000\000\000\000\000\000\000\0034\224\037\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\0000",
'\000' <repeats 19 times>,
"\a\000\000\000\000\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\024\000\000\000\037\000\000\000\000\000\000\000\000C\235(J¡àaëÏ\220V¦ý\037\002#¹Î3+\005\233üñôç\036D\a\212wõR<W\0034\224\036\000\000\000\000\000\000\000\002\000\001\206£\000\000\000\003\000\000\000\003\000\000\000\001\000\000\0000",
'\000' <repeats 15 times>, "°Ð{Ñ\036\000 ɳ¼G\b\000E\000\000¤¸\233"...}}
(kgdb) list
988
989 for (txp = sc->cbl_first; sc->tx_queued &&
990 (txp->cb_status & FXP_CB_STATUS_C) != 0;
991 txp = txp->next) {
992 if (txp->mb_head != NULL) {
993 m_freem(txp->mb_head);
994 txp->mb_head = NULL;
995 }
996 sc->tx_queued--;
997 }
(kgdb)
So I'm not sure what's going on here.
Anyone seen anything like this recently?
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message