Skip site navigation (1)Skip section navigation (2)
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>