From owner-freebsd-hackers  Thu Mar  6 15:50:56 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA20669
          for hackers-outgoing; Thu, 6 Mar 1997 15:50:56 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA20658
          for <hackers@freebsd.org>; Thu, 6 Mar 1997 15:50:38 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA14405; Thu, 6 Mar 1997 18:50:07 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu,  6 Mar 1997 18:50 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id RAA13242; Thu, 6 Mar 1997 17:15:58 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id RAA08652; Thu, 6 Mar 1997 17:21:42 -0500 (EST)
Date: Thu, 6 Mar 1997 17:21:42 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199703062221.RAA08652@lakes.water.net>
To: ponds!lakes.water.net!rivers, ponds!lambert.org!terry
Subject: Re: "dup alloc" - nope - kern/2875 wasn't it.
Cc: ponds!freebsd.org!hackers
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> > > I guess it would be worth while to take out the printf's until you can
> > > isolate the printf's that "fix" the problem.  Then analyze the effects of
> > > the printfs serializing writes.
> > 
> >  My thinking exactly - I've now gone back to just a pristine kernel and
> > I'm trying to find a missing splbio()/splx(), or something along those
> > lines... so far, no luck...
> 
> 
> I am, of course, unable to duplicate your panics.
> 

 Ok - here's another approach.

 Since I have a machine that readily duplicates the problem; one
issue is to make that available to someone who may be able to 
test..

 I could (possibly) set it up as a diskless machine, then allow
telnet sessions into my machines at home.  From the larger
machines, someone would be able to build kernels... and, if I run
a serial line, and make this headless; a remote person should
be able to have a console, with ddb, etc... and debug this problem.

 Or - maybe not even that involved; a file system on the floppy
with the kernel and enough to duplicate the problem; along with
the serial console, should get it... [as long as the serial console
doesn't mask the problem]

 Then, you could put on the new kernel (on the floppy), reboot
and test away...

 I would be *delighted* to set this up; and stay connected to
my ISP to allow telnets, etc.. to get this resolved...   Would
anyone like to participate?  [A serious remote debugging experiment, 
huh?]

 I'll get started on the serial console stuff later tonight...

	- Dave Rivers -