* BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
@ 2007-07-03 7:17 Frank van Maarseveen
2007-07-03 19:39 ` J. Bruce Fields
0 siblings, 1 reply; 5+ messages in thread
From: Frank van Maarseveen @ 2007-07-03 7:17 UTC (permalink / raw)
To: Linux NFS mailing list
I've reported this earlier but now I figured out how to reproduce it:
start nfsd with 50 instances and then try to stop it.
Jul 3 09:10:39 kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
Jul 3 09:10:39 kernel: printing eip:
Jul 3 09:10:39 kernel: c053f594
Jul 3 09:10:39 kernel: *pde = 00000000
Jul 3 09:10:39 kernel: Oops: 0000 [#1]
Jul 3 09:10:39 kernel: SMP
Jul 3 09:10:39 kernel: Modules linked in: vmthrottle
Jul 3 09:10:39 kernel: CPU: 1
Jul 3 09:10:39 kernel: EIP: 0060:[<c053f594>] Not tainted VLI
Jul 3 09:10:39 kernel: EFLAGS: 00010202 (2.6.21.5-x160 #1)
Jul 3 09:10:39 kernel: EIP is at cache_clean+0x124/0x1e0
Jul 3 09:10:39 kernel: eax: 00000000 ebx: 6b6b6b6b ecx: c06dffa0 edx: c0a1f380
Jul 3 09:10:39 kernel: esi: f672d800 edi: 00000000 ebp: f5a11f40 esp: f5a11f34
Jul 3 09:10:39 kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
Jul 3 09:10:39 kernel: Process nfsd (pid: 4420, ti=f5a10000 task=f596c070 task.ti=f5a10000)
Jul 3 09:10:39 kernel: Stack: c06dffa0 f6a3c268 f6a3c234 f5a11f48 c053f69f f5a11f54 c053f6da f6a3c260
Jul 3 09:10:39 kernel: f5a11f5c c020ef47 f5a11f70 c0205632 c06597c8 f6a3c268 f6a3c7ac f5a11f94
Jul 3 09:10:39 kernel: c0537b23 f59b2000 f5a11f94 00000286 f6a3c270 f59b2000 f6a3c7ac f6a3c234
Jul 3 09:10:39 kernel: Call Trace:
Jul 3 09:10:39 kernel: [<c01054a9>] show_trace_log_lvl+0x19/0x30
Jul 3 09:10:39 kernel: [<c010556b>] show_stack_log_lvl+0x8b/0xb0
Jul 3 09:10:39 kernel: [<c01057c6>] show_registers+0x1e6/0x310
Jul 3 09:10:39 kernel: [<c0105a4f>] die+0x10f/0x240
Jul 3 09:10:39 kernel: [<c0115f82>] do_page_fault+0x342/0x610
Jul 3 09:10:39 kernel: [<c054d1ac>] error_code+0x7c/0x90
Jul 3 09:10:39 kernel: [<c053f69f>] cache_flush+0xf/0x30
Jul 3 09:10:39 kernel: [<c053f6da>] cache_purge+0x1a/0x30
Jul 3 09:10:39 kernel: [<c020ef47>] nfsd_export_flush+0x17/0x30
Jul 3 09:10:39 kernel: [<c0205632>] nfsd_last_thread+0x72/0x80
Jul 3 09:10:39 kernel: [<c0537b23>] svc_destroy+0x103/0x140
Jul 3 09:10:39 kernel: [<c0537fca>] svc_exit_thread+0x8a/0x90
Jul 3 09:10:39 kernel: [<c0205ceb>] nfsd+0x24b/0x2a0
Jul 3 09:10:39 kernel: [<c0105317>] kernel_thread_helper+0x7/0x10
Jul 3 09:10:39 kernel: =======================
Jul 3 09:10:39 kernel: Code: c0 8b 51 08 8d 34 82 8b 1e 85 db 75 1e eb 64 8b 0d 88 a6 a4 c0 8b 41 50 39 43 08 7c 25 89 de 8b 1b 85 db 74 4e 8b 0d 88 a6 a4 c0 <8b> 43 04 39 41 5c 7e 07 40 89 41 5c 8b 43 04 3b 05 00 4e 7f c0
Jul 3 09:10:39 kernel: EIP: [<c053f594>] cache_clean+0x124/0x1e0 SS:ESP 0068:f5a11f34
Jul 3 09:10:48 kernel: BUG: soft lockup detected on CPU#1!
Jul 3 09:10:48 kernel: [<c01054a9>] show_trace_log_lvl+0x19/0x30
Jul 3 09:10:48 kernel: [<c01054d2>] show_trace+0x12/0x20
Jul 3 09:10:48 kernel: [<c01055d4>] dump_stack+0x14/0x20
Jul 3 09:10:48 kernel: [<c014a8e2>] softlockup_tick+0xa2/0xc0
Jul 3 09:10:48 kernel: [<c012bf02>] run_local_timers+0x12/0x20
Jul 3 09:10:48 kernel: [<c012bd1d>] update_process_times+0x5d/0x90
Jul 3 09:10:48 kernel: [<c013da4c>] tick_sched_timer+0x5c/0xd0
Jul 3 09:10:48 kernel: [<c01393f7>] hrtimer_interrupt+0x177/0x1e0
Jul 3 09:10:48 kernel: [<c010fb07>] local_apic_timer_interrupt+0x57/0x60
Jul 3 09:10:48 kernel: [<c010fb33>] smp_apic_timer_interrupt+0x23/0x40
Jul 3 09:10:48 kernel: [<c0105158>] apic_timer_interrupt+0x28/0x30
Jul 3 09:10:48 kernel: [<c02944e9>] __delay+0x9/0x10
Jul 3 09:10:48 kernel: [<c0296315>] __spin_lock_debug+0x55/0xd0
Jul 3 09:10:48 kernel: [<c02963e5>] _raw_spin_lock+0x55/0x80
Jul 3 09:10:48 kernel: [<c054cce2>] _spin_lock+0x32/0x40
Jul 3 09:10:48 kernel: [<c053f482>] cache_clean+0x12/0x1e0
Jul 3 09:10:48 kernel: [<c053f69f>] cache_flush+0xf/0x30
Jul 3 09:10:48 kernel: [<c0540925>] write_flush+0x95/0xb0
Jul 3 09:10:48 kernel: [<c016e836>] vfs_write+0x86/0x130
Jul 3 09:10:48 kernel: [<c016e98d>] sys_write+0x3d/0x70
Jul 3 09:10:48 kernel: [<c0104120>] syscall_call+0x7/0xb
Jul 3 09:10:48 kernel: =======================
--
Frank
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
2007-07-03 7:17 BUG: unable to handle kernel paging request at virtual address 6b6b6b6f Frank van Maarseveen
@ 2007-07-03 19:39 ` J. Bruce Fields
2007-07-03 20:22 ` Frank van Maarseveen
0 siblings, 1 reply; 5+ messages in thread
From: J. Bruce Fields @ 2007-07-03 19:39 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: Linux NFS mailing list
On Tue, Jul 03, 2007 at 09:17:35AM +0200, Frank van Maarseveen wrote:
> I've reported this earlier but now I figured out how to reproduce it:
> start nfsd with 50 instances and then try to stop it.
So, all it takes is this?:
rpc.nfsd 50
rpc.nfsd 0
>
> Jul 3 09:10:39 kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
> Jul 3 09:10:39 kernel: printing eip:
> Jul 3 09:10:39 kernel: c053f594
> Jul 3 09:10:39 kernel: *pde = 00000000
> Jul 3 09:10:39 kernel: Oops: 0000 [#1]
> Jul 3 09:10:39 kernel: SMP
> Jul 3 09:10:39 kernel: Modules linked in: vmthrottle
What's vmthrottle, by the way?
> Jul 3 09:10:39 kernel: CPU: 1
> Jul 3 09:10:39 kernel: EIP: 0060:[<c053f594>] Not tainted VLI
> Jul 3 09:10:39 kernel: EFLAGS: 00010202 (2.6.21.5-x160 #1)
> Jul 3 09:10:39 kernel: EIP is at cache_clean+0x124/0x1e0
> Jul 3 09:10:39 kernel: eax: 00000000 ebx: 6b6b6b6b ecx: c06dffa0 edx: c0a1f380
> Jul 3 09:10:39 kernel: esi: f672d800 edi: 00000000 ebp: f5a11f40 esp: f5a11f34
> Jul 3 09:10:39 kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
> Jul 3 09:10:39 kernel: Process nfsd (pid: 4420, ti=f5a10000 task=f596c070 task.ti=f5a10000)
> Jul 3 09:10:39 kernel: Stack: c06dffa0 f6a3c268 f6a3c234 f5a11f48 c053f69f f5a11f54 c053f6da f6a3c260
> Jul 3 09:10:39 kernel: f5a11f5c c020ef47 f5a11f70 c0205632 c06597c8 f6a3c268 f6a3c7ac f5a11f94
> Jul 3 09:10:39 kernel: c0537b23 f59b2000 f5a11f94 00000286 f6a3c270 f59b2000 f6a3c7ac f6a3c234
> Jul 3 09:10:39 kernel: Call Trace:
> Jul 3 09:10:39 kernel: [<c01054a9>] show_trace_log_lvl+0x19/0x30
> Jul 3 09:10:39 kernel: [<c010556b>] show_stack_log_lvl+0x8b/0xb0
> Jul 3 09:10:39 kernel: [<c01057c6>] show_registers+0x1e6/0x310
> Jul 3 09:10:39 kernel: [<c0105a4f>] die+0x10f/0x240
> Jul 3 09:10:39 kernel: [<c0115f82>] do_page_fault+0x342/0x610
> Jul 3 09:10:39 kernel: [<c054d1ac>] error_code+0x7c/0x90
> Jul 3 09:10:39 kernel: [<c053f69f>] cache_flush+0xf/0x30
> Jul 3 09:10:39 kernel: [<c053f6da>] cache_purge+0x1a/0x30
> Jul 3 09:10:39 kernel: [<c020ef47>] nfsd_export_flush+0x17/0x30
So I guess the nfsd export cache is corrupted somehow.
Perhaps turning on more debugging options in the kernel config would
help catch the problem earlier. I'm not having any luck reproducing
this now.
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
2007-07-03 19:39 ` J. Bruce Fields
@ 2007-07-03 20:22 ` Frank van Maarseveen
2007-07-14 3:07 ` J. Bruce Fields
0 siblings, 1 reply; 5+ messages in thread
From: Frank van Maarseveen @ 2007-07-03 20:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Linux NFS mailing list
On Tue, Jul 03, 2007 at 03:39:37PM -0400, J. Bruce Fields wrote:
> On Tue, Jul 03, 2007 at 09:17:35AM +0200, Frank van Maarseveen wrote:
> > I've reported this earlier but now I figured out how to reproduce it:
> > start nfsd with 50 instances and then try to stop it.
>
> So, all it takes is this?:
>
> rpc.nfsd 50
> rpc.nfsd 0
I guess so: On debian etch I adapted /etc/defaults/nfs-kernel-server
(IIRC) to start 50 daemons and after a reboot it sufficed to type
/etc/init.d/nfs-kernel-server stop to make it say BUG. Very reproducable
here (5 machines).
>
> >
> > Jul 3 09:10:39 kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
> > Jul 3 09:10:39 kernel: printing eip:
> > Jul 3 09:10:39 kernel: c053f594
> > Jul 3 09:10:39 kernel: *pde = 00000000
> > Jul 3 09:10:39 kernel: Oops: 0000 [#1]
> > Jul 3 09:10:39 kernel: SMP
> > Jul 3 09:10:39 kernel: Modules linked in: vmthrottle
>
> What's vmthrottle, by the way?
That's a custom module to kill memory hungry processes when the uid
doesn't match the one running the X server (basically). That way 40-50
workstations for software development can also participate in distributed
compiler testing without interfering too much. An unpatched and moduleless
kernel still crashes.
>
> > Jul 3 09:10:39 kernel: CPU: 1
> > Jul 3 09:10:39 kernel: EIP: 0060:[<c053f594>] Not tainted VLI
> > Jul 3 09:10:39 kernel: EFLAGS: 00010202 (2.6.21.5-x160 #1)
> > Jul 3 09:10:39 kernel: EIP is at cache_clean+0x124/0x1e0
> > Jul 3 09:10:39 kernel: eax: 00000000 ebx: 6b6b6b6b ecx: c06dffa0 edx: c0a1f380
> > Jul 3 09:10:39 kernel: esi: f672d800 edi: 00000000 ebp: f5a11f40 esp: f5a11f34
> > Jul 3 09:10:39 kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
> > Jul 3 09:10:39 kernel: Process nfsd (pid: 4420, ti=f5a10000 task=f596c070 task.ti=f5a10000)
> > Jul 3 09:10:39 kernel: Stack: c06dffa0 f6a3c268 f6a3c234 f5a11f48 c053f69f f5a11f54 c053f6da f6a3c260
> > Jul 3 09:10:39 kernel: f5a11f5c c020ef47 f5a11f70 c0205632 c06597c8 f6a3c268 f6a3c7ac f5a11f94
> > Jul 3 09:10:39 kernel: c0537b23 f59b2000 f5a11f94 00000286 f6a3c270 f59b2000 f6a3c7ac f6a3c234
> > Jul 3 09:10:39 kernel: Call Trace:
> > Jul 3 09:10:39 kernel: [<c01054a9>] show_trace_log_lvl+0x19/0x30
> > Jul 3 09:10:39 kernel: [<c010556b>] show_stack_log_lvl+0x8b/0xb0
> > Jul 3 09:10:39 kernel: [<c01057c6>] show_registers+0x1e6/0x310
> > Jul 3 09:10:39 kernel: [<c0105a4f>] die+0x10f/0x240
> > Jul 3 09:10:39 kernel: [<c0115f82>] do_page_fault+0x342/0x610
> > Jul 3 09:10:39 kernel: [<c054d1ac>] error_code+0x7c/0x90
> > Jul 3 09:10:39 kernel: [<c053f69f>] cache_flush+0xf/0x30
> > Jul 3 09:10:39 kernel: [<c053f6da>] cache_purge+0x1a/0x30
> > Jul 3 09:10:39 kernel: [<c020ef47>] nfsd_export_flush+0x17/0x30
>
> So I guess the nfsd export cache is corrupted somehow.
>
> Perhaps turning on more debugging options in the kernel config would
> help catch the problem earlier. I'm not having any luck reproducing
> this now.
Hmm, 6b6b6b6b looks like a poison to me and I have some debugging options on:
CONFIG_DEBUG_KERNEL=y
CONFIG_SLAB=y
CONFIG_DEBUG_SLAB=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_STACKOVERFLOW=y
Full config: http://www.frankvm.com/tmp/dot-config-cachebug
--
Frank
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
2007-07-03 20:22 ` Frank van Maarseveen
@ 2007-07-14 3:07 ` J. Bruce Fields
2007-07-16 12:19 ` Frank van Maarseveen
0 siblings, 1 reply; 5+ messages in thread
From: J. Bruce Fields @ 2007-07-14 3:07 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: Linux NFS mailing list
On Tue, Jul 03, 2007 at 10:22:16PM +0200, Frank van Maarseveen wrote:
> On Tue, Jul 03, 2007 at 03:39:37PM -0400, J. Bruce Fields wrote:
> > On Tue, Jul 03, 2007 at 09:17:35AM +0200, Frank van Maarseveen wrote:
> > > I've reported this earlier but now I figured out how to reproduce it:
> > > start nfsd with 50 instances and then try to stop it.
> >
> > So, all it takes is this?:
> >
> > rpc.nfsd 50
> > rpc.nfsd 0
>
> I guess so: On debian etch I adapted /etc/defaults/nfs-kernel-server
> (IIRC) to start 50 daemons and after a reboot it sufficed to type
> /etc/init.d/nfs-kernel-server stop to make it say BUG. Very reproducable
> here (5 machines).
Could you try this?
--b.
>From b941e6b14f6cf53c6dea17cfb80c5619304afe99 Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Thu, 12 Jul 2007 22:17:34 -0400
Subject: [PATCH] nfsd: fix possible read-ahead cache and export table corruption
The value of nperbucket calculated here is too small--we should be
rounding up instead of down--with the result that the index j in the
following loop can overflow the raparm_hash array. At least in my case,
the next thing in memory turns out to be export_table, so the symptoms I
see are crashes caused by the appearance of four zeroed-out export
entries in the first bucket of the hash table of exports (which were
actually entries in the readahead cache, a pointer to which had been
written to the export table in this initialization code).
It looks like the bug was probably introduced with commit
fce1456a19f5c08b688c29f00ef90fdfa074c79b ("knfsd: make the readahead
params cache SMP-friendly").
Cc: Greg Banks <gnb@melbourne.sgi.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
fs/nfsd/vfs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 7e50da0..dd3604e 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1885,7 +1885,7 @@ nfsd_racache_init(int cache_size)
raparm_hash[i].pb_head = NULL;
spin_lock_init(&raparm_hash[i].pb_lock);
}
- nperbucket = cache_size >> RAPARM_HASH_BITS;
+ nperbucket = DIV_ROUND_UP(cache_size, RAPARM_HASH_SIZE);
for (i = 0; i < cache_size - 1; i++) {
if (i % nperbucket == 0)
raparm_hash[j++].pb_head = raparml + i;
--
1.5.3.rc0.63.gc956
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
2007-07-14 3:07 ` J. Bruce Fields
@ 2007-07-16 12:19 ` Frank van Maarseveen
0 siblings, 0 replies; 5+ messages in thread
From: Frank van Maarseveen @ 2007-07-16 12:19 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Linux NFS mailing list
On Fri, Jul 13, 2007 at 11:07:25PM -0400, J. Bruce Fields wrote:
> On Tue, Jul 03, 2007 at 10:22:16PM +0200, Frank van Maarseveen wrote:
> > On Tue, Jul 03, 2007 at 03:39:37PM -0400, J. Bruce Fields wrote:
> > > On Tue, Jul 03, 2007 at 09:17:35AM +0200, Frank van Maarseveen wrote:
> > > > I've reported this earlier but now I figured out how to reproduce it:
> > > > start nfsd with 50 instances and then try to stop it.
> > >
> > > So, all it takes is this?:
> > >
> > > rpc.nfsd 50
> > > rpc.nfsd 0
> >
> > I guess so: On debian etch I adapted /etc/defaults/nfs-kernel-server
> > (IIRC) to start 50 daemons and after a reboot it sufficed to type
> > /etc/init.d/nfs-kernel-server stop to make it say BUG. Very reproducable
> > here (5 machines).
>
> Could you try this?
>
> --b.
>
> >From b941e6b14f6cf53c6dea17cfb80c5619304afe99 Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Thu, 12 Jul 2007 22:17:34 -0400
> Subject: [PATCH] nfsd: fix possible read-ahead cache and export table corruption
>
> The value of nperbucket calculated here is too small--we should be
> rounding up instead of down--with the result that the index j in the
> following loop can overflow the raparm_hash array. At least in my case,
> the next thing in memory turns out to be export_table, so the symptoms I
> see are crashes caused by the appearance of four zeroed-out export
> entries in the first bucket of the hash table of exports (which were
> actually entries in the readahead cache, a pointer to which had been
> written to the export table in this initialization code).
>
> It looks like the bug was probably introduced with commit
> fce1456a19f5c08b688c29f00ef90fdfa074c79b ("knfsd: make the readahead
> params cache SMP-friendly").
>
> Cc: Greg Banks <gnb@melbourne.sgi.com>
> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
> ---
> fs/nfsd/vfs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 7e50da0..dd3604e 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1885,7 +1885,7 @@ nfsd_racache_init(int cache_size)
> raparm_hash[i].pb_head = NULL;
> spin_lock_init(&raparm_hash[i].pb_lock);
> }
> - nperbucket = cache_size >> RAPARM_HASH_BITS;
> + nperbucket = DIV_ROUND_UP(cache_size, RAPARM_HASH_SIZE);
> for (i = 0; i < cache_size - 1; i++) {
> if (i % nperbucket == 0)
> raparm_hash[j++].pb_head = raparml + i;
> --
> 1.5.3.rc0.63.gc956
Yes, that fixes it for me. I chose 50 daemons just because the server has
about 50 clients and for one time I wanted to think instead of picking
a random power of two. I should have known better ;-)
--
Frank
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-07-16 12:19 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-03 7:17 BUG: unable to handle kernel paging request at virtual address 6b6b6b6f Frank van Maarseveen
2007-07-03 19:39 ` J. Bruce Fields
2007-07-03 20:22 ` Frank van Maarseveen
2007-07-14 3:07 ` J. Bruce Fields
2007-07-16 12:19 ` Frank van Maarseveen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.