Date: Thu, 6 Mar 1997 17:21:42 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!lakes.water.net!rivers, ponds!lambert.org!terry Cc: ponds!freebsd.org!hackers Subject: Re: "dup alloc" - nope - kern/2875 wasn't it. Message-ID: <199703062221.RAA08652@lakes.water.net>
next in thread | raw e-mail | index | archive | help
> > > > 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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703062221.RAA08652>