Testers Needed!!

[Wilko Bulte]

On Wed, Mar 17, 2004 at 07:48:36AM -0500, Stephane E. Potvin wrote:
> 
> On 15-Mar-04, at 8:37 PM, Stephane E. Potvin wrote:
> 
> >
> >On 15-Mar-04, at 6:18 PM, Wilko Bulte wrote:
> >
> >>On Mon, Mar 15, 2004 at 01:20:32PM -0500, John Baldwin wrote:
> >>>On Friday 12 March 2004 06:07 pm, Wilko Bulte wrote:
> >>>>On Fri, Mar 12, 2004 at 11:56:26PM +0100, Wilko Bulte wrote:
> >>>>>On Fri, Mar 12, 2004 at 05:15:52PM -0500, John Baldwin wrote:
> >>>>>>On Friday 12 March 2004 04:28 pm, Wilko Bulte wrote:
> >>>>>>>On Fri, Mar 12, 2004 at 03:43:03PM -0500, John Baldwin wrote:
> >>>>>>>>Ok, two patches that I need someone to test.  First off, I have
> >>
> >>>>>>etc. work ok w/o generating a LOR warning (which means you have 
> >>>>>>to have
> >>>>>>WITNESS on for this test).  Thanks for testing these.
> >>>>>
> >>>>>I'm by no standard a gdb specialist but I played with it with a 
> >>>>>WITNESS
> >>>>>equipped kernel and it did not complain about LOR. On a UP DS10 
> >>>>>btw.
> >>>>>
> >>>>>Gonna try the other patch next.
> >>>>
> >>>>Hmm..
> >>>>
> >>...
> >>
> >>>bah, you'll need to add a '<sys/sched.h>' include to interrupt.c.  
> >>>I'll fix it
> >>>in my tree here and commit the ptrace patch.  Thanks!
> >>
> >>I have the interrupt.c patch now in test. Currently the DS10 is doing 
> >>a
> >>plain buildworld, I will move to make -j<big#> next.
> >>
> >>How long would the test need to run for a reliable indication of 
> >>Go/NoGo
> >>
> >
> >Make sure that you have more than 4G swapspace. I had a -j 256 die on 
> >me after
> >48 hours with 768Mb ram and 4G swap. I'll bump the swap to 8G and try 
> >again
> >(crossing fingers). You'll also have to raise kern.ipc.maxpipekva to 
> >at least
> >24Mb too.
> 
> Replying to myself,
> 
> I got the following backtrace 3 times while making a -j 256 buildworld. 
> I had these
> with my earlier attempts but tought that they were somewhat related to 
> the
> machine running out of swap. This time, I got them without the swap 
> issue.
> I'll try again with the ithread preemtion patch removed just to make 
> sure that
> it's not caused by it but I don't beleive that they are related.
> 
> Stack backtrade:
> db_print_backtrace() at 0xfffffc00004b5748 = db_print_backtrace+0x18
> backtrace() at 0xfffffc00003ad08c = backtrace+0x2c
> getdirtybuf() at 0xfffffc0000477c7c = getdirtybuf+0x4c
> flush_deplist() at 0xfffffc0000476a64 = flush_deplist+0x64
> flush_inodedep_deps() at 0xfffffc0000476970 = flush_inodedep_deps+0xa0
> softdep_sync_metadata() at 0xfffffc00004763e8 = 
> softdep_sync_metadata+0xa8
> ffs_fsync() at 0xfffffc000047bcd4 = ffs_fsync+0x434
> fsync() at 0xfffffc000041dbed = fsync+0x16c
> syscall() at 0xfffffc00004c55bc = syscall+0x36c
> XentSys() at 0xfffffc00004b6270 = XentSys+0x64
> --- syscall (95) ---
> --- user mode ---

I had one crash in the fs as well, running -j 128. But given that the
system was still running a background fsck I am not sure what I was
looking at.

-- 
Wilko Bulte				wilko at FreeBSD.org