panic on one cpu leaves others running...

Brian F. Feldman green at
Thu Apr 8 09:43:36 PDT 2004

Robert Watson <rwatson at> wrote:
> On Thu, 8 Apr 2004, Brian F. Feldman wrote:
> > Robert Watson <rwatson at> wrote:
> > > 
> > > panic: m 0 so->so_rcv.sb_cc 17
> > > at line 860 in file ../../../kern/uipc_socket.c
> > 
> > What made you receive that panic?  I remember having that exact panic
> > (sb_cc size being a little different, obviously) months ago... and
> > having it disappear.  Did you have networking out from Giant where it
> > shouldn't have yet been? ;) 
> This is running without Giant over most of the network stack.  However,
> I'm still working on tracking down the source of the problem -- I'm
> beginning to wonder if it's not an existing race opened up by releasing
> locks in areas where only memory allocations required sleeping would have
> opened the race previously.  I got this panic during local UNIX domain
> socket IPC between the sshd bits.  I suspect what's going on, but need to
> look in more detail, is that something is messed up relating to control
> mbufs -- I.e., ancillary data transfer.  If you're interested in taking a
> look at the current work-in-progress, take a look at the rwatson_netperf
> branch in perforce, or at:
> I can also add you to the CC list for new patch versions if you like.
> Pretty shortly, I'll be sending them to arch@ instead, but I need to
> resolve a few problems in socket locking (including this one).

My first suspicion would also be MT_CONTROL botches.  I'll take a look, 
since I'm recently re-familiarized with soreceive (turning mbuf tags into 
control messages... *barf*).  I'll just check it out from perforce if I get 
the time to start running more than one branch :)

Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\

More information about the freebsd-current mailing list