Testers Needed!!

[Stephane E. Potvin]

On 17-Mar-04, at 7:48 AM, 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 ---
>
One more piece of information that could be relevent, 80% of the 
swapspace
is an md device backed by a 4Gb file so it might be a bug still lurking 
in the
md device.

Steph