Re: panic in fxp driver
Jonathan Lemon writes: Please consider the case where there are two mbuf chains being transmitted, which look like this: Um. Not Possible. I thought m_copypacket() of a cluster mbuf would yield exactly this situation (two headers pointing to the same data region). -Arcihe __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
On Sat, May 05, 2001 at 04:04:27PM -0700, Archie Cobbs wrote: Jonathan Lemon writes: Please consider the case where there are two mbuf chains being transmitted, which look like this: Um. Not Possible. I thought m_copypacket() of a cluster mbuf would yield exactly this situation (two headers pointing to the same data region). Well, only external mbufs can be shared, not mbuf chains; and clusters are accessed through the (unused) mbuf that comprises the chain. I believe Terry may have been referring to some local modifications that is in his code, which permits the scenario he describes. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
] I would be quite interested in knowing just how you manage
] to accomplish that, given that all the transmit control buffers
] are arranged in a circular linked list:
]
] fxp_init(void *xsc)
] {
] ...
] for (i = 0; i FXP_NTXCB; i++) {
] ...
] txp[i].next = txp[(i + 1) FXP_TXCB_MASK];
] }
]
]
] I would suggest actually examining the rest of the code to see
] how it works before making erroneous proclamations based on the
] myopic examination of a single statement.
I would suggest a less than myopic examination of the subject
line.
In particular, I saw a repeatable panic under extremely heavy
load.
Please consider the case where there are two mbuf chains being
transmitted, which look like this:
A B
header O O
\ /
\ /
\ /
data 1 O
|
data 2 O
|
data 3 O
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
] I would be quite interested in knowing just how you manage
] to accomplish that, given that all the transmit control buffers
] are arranged in a circular linked list:
]
] fxp_init(void *xsc)
] {
] ...
] for (i = 0; i FXP_NTXCB; i++) {
] ...
] txp[i].next = txp[(i + 1) FXP_TXCB_MASK];
] }
]
]
] I would suggest actually examining the rest of the code to see
] how it works before making erroneous proclamations based on the
] myopic examination of a single statement.
I would suggest a less than myopic examination of the subject
line.
I'm quite aware of the subject line; but you're changing the
subject here. Any panic has nothing to do with the next pointer
being NULL, as you stated in the previous email, since this is
not possible, assuming correct operation of the code.
In particular, I saw a repeatable panic under extremely heavy
load.
I'm sorry, my MTA must have dropped your bug report, as it appears
to be missing. Can you please resend? In particular, a stack
backtrace and preferably a crashdump, and leave off any wild
hypothesis of where the bugs are, unless you have supporting evidence.
Please consider the case where there are two mbuf chains being
transmitted, which look like this:
Um. Not Possible.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
txp = txp-next) {
if (txp-mb_head != NULL) {
m_freem(txp-mb_head);
txp-mb_head = NULL;
}
sc-tx_queued--;
}
...notice the for loop doesn't check to see if txp = txp-next
ends up being NULL? You can get this, if you put your system
under extreme load.
If you can repeat the problem with another card, it's a real
problem, otherwise it's probably just FXP driver brain damage...
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
txp = txp-next) {
if (txp-mb_head != NULL) {
m_freem(txp-mb_head);
txp-mb_head = NULL;
}
sc-tx_queued--;
}
...notice the for loop doesn't check to see if txp = txp-next
ends up being NULL? You can get this, if you put your system
under extreme load.
I would be quite interested in knowing just how you manage
to accomplish that, given that all the transmit control buffers
are arranged in a circular linked list:
fxp_init(void *xsc)
{
...
for (i = 0; i FXP_NTXCB; i++) {
...
txp[i].next = txp[(i + 1) FXP_TXCB_MASK];
}
I would suggest actually examining the rest of the code to see
how it works before making erroneous proclamations based on the
myopic examination of a single statement.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic in fxp driver
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 = 0x200, ext_size = 2743468288,
ref_cnt = 0x300, 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\,
'\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õRW\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\,
'\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\,
'\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õRW\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\,
'\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
Re: panic in fxp driver
Kenneth D. Merry wrote: 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 This is a well known problem, and a real gotcha. kgdb does not know how and when variables are stored in registers. It *always* reads the stack values, not the registers. You can disassemble the code and find out what register is currently holding 'm' and either look at the current registers or the trap frame if there is one. I suspect we are missing some magic in our kernel interface code for gdb and it is not running in 'gcc generated .stabs' mode. On the other hand, you might try using dwarf2 debugging, that is pretty complete. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
On Tue, May 01, 2001 at 02:16:33PM -0700, Peter Wemm wrote: On the other hand, you might try using dwarf2 debugging, that is pretty complete. And what we'll be using when GCC 3.0 is imported. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
