panic on one cpu leaves others running...
Brian F. Feldman
green at FreeBSD.org
Thu Apr 8 09:43:36 PDT 2004
Robert Watson <rwatson at FreeBSD.org> wrote:
>
> On Thu, 8 Apr 2004, Brian F. Feldman wrote:
>
> > Robert Watson <rwatson at FreeBSD.org> 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:
>
> http://www.watson.org/~robert/freebsd/netperf/
>
> 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 FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-current
mailing list