Nate Lawson wrote: > I have gotten fxp running with MPSAFE and did a large scp transfer. It > ran for a few minutes and then paniced. It was trap 12 (page fault) at > address 0x24. Here is where it crashed: > > fxp_start+0xcc > 0xc0194a4c is in fxp_start (../../../dev/fxp/if_fxp.c:1263). > 1258 * been computed and stored in the checksum field > 1259 * in the TCP header. The stack should have > 1260 * already done this for us. > 1261 */ > 1262 > 1263 if (mb_head->m_pkthdr.csum_flags) { > 1264 if (mb_head->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > 1265 txp->tx_cb->ipcb_ip_activation_high = > 1266 FXP_IPCB_HARDWAREPARSING_ENABLE; > 1267 txp->tx_cb->ipcb_ip_schedule = > > The deref of mb_head->m_pkthdr is invalid. Note that my fxp_intr function > acquires the fxp lock right away so this shouldn't be a race in fxp. Since fxp_start() will usually be called by ether_output(), I don't see how acquiring the lock in fxp_intr() can protect you from such a race. You need to acquire the lock in fxp_start() before touching the interface queue, otherwise it may be preempted by an interrupt and this will lead to a race if fxp_intr() ends up calling fxp_start(). It really looks like that's what happened. Cheers, MaximeReceived on Fri Apr 04 2003 - 02:28:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:02 UTC