Argh, just found this one in the logs:

May 19 09:58:18 fornax kernel BUG at slab.c:1930!
May 19 09:58:18 fornax invalid operand: 0000
May 19 09:58:18 fornax CPU:    0
May 19 09:58:18 fornax EIP:    0010:[<c01372a5>]    Not tainted
May 19 09:58:18 fornax EFLAGS: 00010002
May 19 09:58:18 fornax eax: c7d8b000   ebx: 00000000   ecx: 0000001e   
edx: c12c72b0
May 19 09:58:18 fornax esi: 00003ab6   edi: c12c72b0   ebp: c12c72b0   
esp: ca329f10
May 19 09:58:18 fornax ds: 0018   es: 0018   ss: 0018
May 19 09:58:18 fornax Process vmstat (pid: 27441, stackpage=ca329000)
May 19 09:58:18 fornax Stack: cb69a7e0 c02724f2 0000007c 0000003e 
000047ce 00000200 00000a42 00000a42
May 19 09:58:18 fornax 00000001 c0000000 000001f5 00000246 00001000 
00000000 000047ce 00000000
May 19 09:58:18 fornax cb69a7e0 c12c72b0 00000756 c015e8e3 cb69a7e0 
c12c72b0 ca329f74 cb69a7f8
May 19 09:58:18 fornax Call Trace:    [<c015e8e3>] [<c0140d27>] [<c010773f>]
May 19 09:58:18 fornax
May 19 09:58:18 fornax Code: 0f 0b 8a 07 bc 24 27 c0 ff 44 24 28 01 ce 
8b 00 39 e8 75 e7

but no trace of the other one, which was deffinately a lockd process 
(nfs related afaik).  Oh well, thanks for the help.  At least this 
confirms (for me at least) that there is a problem in the server side 
nfs code.  And now I know about ksymoops.

Jaco

Manfred Spraul wrote:

> Hi,
>
>> The following OOPS occured this morning.  This is on a dual CPU 
>> machine, there were two oopses, unfortunately the other scrolled off 
>> the screen but the process was lockd (nfs related afaik).
>>  
>>
> Unfortunately the first one is the important one :-(
>
>> Here is the oops (written off and typed up), unfortunately I don't 
>> know how to convert this to nicely readable symbols ...
>>
>> Kernel BUG at slab.c:1930
>>
> That's an oops caused by a consistency check while printing 
> /proc/slabinfo. Probably a side effect of the first oops.
>
> -- 
>    Manfred
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
As long as there are ill-defined goals, bizarre bugs, and unrealistic 
schedules, there will be Real Programmers willing to jump in and Solve 
The Problem, saving the documentation for later.
===========================================
This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
===========================================