Date: Mon, 1 Jun 1998 16:24:47 +1000 From: Bruce Evans <bde@zeta.org.au> To: dg@root.com, scrappy@hub.org Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? Message-ID: <199806010624.QAA13930@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> It appears that the mbuf chain is getting corrupted somehow. The above
>trap info indicates that the m_data pointer is bogus, resulting in a panic
>when the system attempts to get the physical address from the page tables.
>I don't see anything obvious in the 'de' driver that could cause this, so
>I suspect the buffer corruption is external to the driver.
I recently fixed one source of mbuf chain corruption:
diff -c2 uipc_socket.c~ uipc_socket.c
*** uipc_socket.c~ Sun May 17 04:45:15 1998
--- uipc_socket.c Thu May 28 14:21:40 1998
***************
*** 689,694 ****
orig_resid = 0;
if (psa)
! *psa = dup_sockaddr(mtod(m, struct sockaddr *),
! mp0 == 0);
if (flags & MSG_PEEK) {
m = m->m_next;
--- 689,693 ----
orig_resid = 0;
if (psa)
! *psa = dup_sockaddr(mtod(m, struct sockaddr *), 0);
if (flags & MSG_PEEK) {
m = m->m_next;
It is apparently not OK for the MALLOC() in dup_sockaddr() to wait if the
call is from here. Even lowering the ipl is not OK. To see corruption,
add a reverse splx()/splnet() here and do a `ping -f' to an ethernet host.
This normally causes a panic in sbdrop() within a second or two. OTOH,
the reverse splx()/splnet() doesn't seem to cause any problems under
light network loads, and MALLOC() doesn't normally sleep, so this bug
probably only shows up under very heavy loads.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806010624.QAA13930>