From owner-freebsd-current@FreeBSD.ORG Thu Apr 8 09:43:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 409DC16A4D2; Thu, 8 Apr 2004 09:43:36 -0700 (PDT) Received: from localhost (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i38GhZhX092335; Thu, 8 Apr 2004 12:43:35 -0400 (EDT) (envelope-from green@green.homeunix.org) Message-Id: <200404081643.i38GhZhX092335@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Robert Watson In-Reply-To: Message from Robert Watson From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Apr 2004 12:43:35 -0400 Sender: green@green.homeunix.org cc: current@FreeBSD.org Subject: Re: panic on one cpu leaves others running... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2004 16:43:36 -0000 Robert Watson wrote: > > On Thu, 8 Apr 2004, Brian F. Feldman wrote: > > > Robert Watson 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@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\