Re: 2.6.12-rc4-mm1

Re: 2.6.12-rc4-mm1

[David Woodhouse]

On Fri, 2005-05-13 at 09:53 -0500, steve would have written, if his mail
client hadn't been broken:
> a bug that appeared after running for about 2 hours:
> 
> May 13 09:32:34 localhost kernel: BUG: atomic counter underflow at:
> May 13 09:32:34 localhost kernel:  [reiserfs_clear_inode+129/176] reiserfs_clear_inode+0x81/0xb0
> May 13 09:32:34 localhost kernel:  [clear_inode+228/304] clear_inode+0xe4/0x130
> May 13 09:32:34 localhost kernel:  [dispose_list+112/304] dispose_list+0x70/0x130
> May 13 09:32:34 localhost kernel:  [prune_icache+191/432] prune_icache+0xbf/0x1b0
> May 13 09:32:34 localhost kernel:  [shrink_icache_memory+20/64] shrink_icache_memory+0x14/0x40
> May 13 09:32:34 localhost kernel:  [shrink_slab+345/416] shrink_slab+0x159/0x1a0
> May 13 09:32:34 localhost kernel:  [balance_pgdat+695/944] balance_pgdat+0x2b7/0x3b0
> May 13 09:32:34 localhost kernel:  [kswapd+210/240] kswapd+0xd2/0xf0 
> May 13 09:32:34 localhost kernel:  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
> May 13 09:32:34 localhost kernel:  [ret_from_fork+6/20] ret_from_fork+0x6/0x14
> May 13 09:32:34 localhost kernel:  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
> May 13 09:32:34 localhost kernel:  [kswapd+0/240] kswapd+0x0/0xf0
> May 13 09:32:34 localhost kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18

Hmmm. We're hitting that bug when posix_acl_release() decrements the
refcount on one of the inode's ACLs and it goes negative.

First glance at this had me suspecting that we were somehow calling
clear_inode() twice... but since we clear the pointer to the ACL after
calling posix_acl_release(), that seems unlikely -- unless you managed
to get two CPUs in reiserfs_clear_inode() simultaneously for the same
inode. Is this SMP? Is preempt enabled?

Can you reproduce it? If so, does it go away if you revert one or both
of these:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/vfs-bugfix-two-read_inode-calles-without.patch
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/__wait_on_freeing_inode-fix.patch

-- 
dwmw2

Re: 2.6.12-rc4-mm1

[steve]

David Woodhouse wrote:

>On Fri, 2005-05-13 at 09:53 -0500, steve would have written, if his mail
>client hadn't been broken:
>  
>
>>a bug that appeared after running for about 2 hours:
>>
>>May 13 09:32:34 localhost kernel: BUG: atomic counter underflow at:
>>May 13 09:32:34 localhost kernel:  [reiserfs_clear_inode+129/176] reiserfs_clear_inode+0x81/0xb0
>>May 13 09:32:34 localhost kernel:  [clear_inode+228/304] clear_inode+0xe4/0x130
>>May 13 09:32:34 localhost kernel:  [dispose_list+112/304] dispose_list+0x70/0x130
>>May 13 09:32:34 localhost kernel:  [prune_icache+191/432] prune_icache+0xbf/0x1b0
>>May 13 09:32:34 localhost kernel:  [shrink_icache_memory+20/64] shrink_icache_memory+0x14/0x40
>>May 13 09:32:34 localhost kernel:  [shrink_slab+345/416] shrink_slab+0x159/0x1a0
>>May 13 09:32:34 localhost kernel:  [balance_pgdat+695/944] balance_pgdat+0x2b7/0x3b0
>>May 13 09:32:34 localhost kernel:  [kswapd+210/240] kswapd+0xd2/0xf0 
>>May 13 09:32:34 localhost kernel:  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
>>May 13 09:32:34 localhost kernel:  [ret_from_fork+6/20] ret_from_fork+0x6/0x14
>>May 13 09:32:34 localhost kernel:  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
>>May 13 09:32:34 localhost kernel:  [kswapd+0/240] kswapd+0x0/0xf0
>>May 13 09:32:34 localhost kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18
>>    
>>
>
>Hmmm. We're hitting that bug when posix_acl_release() decrements the
>refcount on one of the inode's ACLs and it goes negative.
>
>First glance at this had me suspecting that we were somehow calling
>clear_inode() twice... but since we clear the pointer to the ACL after
>calling posix_acl_release(), that seems unlikely -- unless you managed
>to get two CPUs in reiserfs_clear_inode() simultaneously for the same
>inode. Is this SMP? Is preempt enabled?
>
>Can you reproduce it? If so, does it go away if you revert one or both
>of these:
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/vfs-bugfix-two-read_inode-calles-without.patch
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/__wait_on_freeing_inode-fix.patch
>
>  
>
okay, reproduced after a couple hours of running (nothing intensive), 
then doing a grep blah -r /*

here's the new output:
May 13 19:54:16 localhost kernel: BUG: atomic counter underflow at:
May 13 19:54:16 localhost kernel:  [reiserfs_clear_inode+129/176] 
reiserfs_clear_inode+0x81/0xb0
May 13 19:54:16 localhost kernel:  [clear_inode+228/304] 
clear_inode+0xe4/0x130
May 13 19:54:16 localhost kernel:  [dispose_list+112/304] 
dispose_list+0x70/0x130
May 13 19:54:16 localhost kernel:  [prune_icache+191/432] 
prune_icache+0xbf/0x1b0
May 13 19:54:16 localhost kernel:  [shrink_icache_memory+20/64] 
shrink_icache_memory+0x14/0x40
May 13 19:54:16 localhost kernel:  [shrink_slab+345/416] 
shrink_slab+0x159/0x1a0
May 13 19:54:16 localhost kernel:  [try_to_free_pages+226/416] 
try_to_free_pages+0xe2/0x1a0
May 13 19:54:16 localhost kernel:  [__alloc_pages+383/960] 
__alloc_pages+0x17f/0x3c0
May 13 19:54:16 localhost kernel:  [__do_page_cache_readahead+285/352] 
__do_page_cache_readahead+0x11d/0x160
May 13 19:54:16 localhost kernel:  
[blockable_page_cache_readahead+81/208] 
blockable_page_cache_readahead+0x51/0xd0
May 13 19:54:16 localhost kernel:  [make_ahead_window+112/176] 
make_ahead_window+0x70/0xb0
May 13 19:54:16 localhost kernel:  [page_cache_readahead+169/384] 
page_cache_readahead+0xa9/0x180
May 13 19:54:16 localhost kernel:  [file_read_actor+198/224] 
file_read_actor+0xc6/0xe0
May 13 19:54:16 localhost kernel:  [do_generic_mapping_read+1446/1472] 
do_generic_mapping_read+0x5a6/0x5c0
May 13 19:54:16 localhost kernel:  [pg0+542324240/1068651520] 
ieee80211_recv_mgmt+0xed0/0x1d90 [wlan]
May 13 19:54:16 localhost kernel:  [file_read_actor+0/224] 
file_read_actor+0x0/0xe0
May 13 19:54:16 localhost kernel:  [__generic_file_aio_read+484/544] 
__generic_file_aio_read+0x1e4/0x220
May 13 19:54:16 localhost kernel:  [file_read_actor+0/224] 
file_read_actor+0x0/0xe0
May 13 19:54:16 localhost kernel:  [generic_file_read+149/176] 
generic_file_read+0x95/0xb0
May 13 19:54:16 localhost kernel:  [try_to_wake_up+166/192] 
try_to_wake_up+0xa6/0xc0
May 13 19:54:16 localhost kernel:  [autoremove_wake_function+0/80] 
autoremove_wake_function+0x0/0x50
May 13 19:54:16 localhost kernel:  [schedule+791/1616] schedule+0x317/0x650
May 13 19:54:16 localhost kernel:  [vfs_read+156/336] vfs_read+0x9c/0x150
May 13 19:54:16 localhost kernel:  [sys_read+71/128] sys_read+0x47/0x80
May 13 19:54:16 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb


i'll recompile without those two patches, and try it again.

Steve

Re: 2.6.12-rc4-mm1

[Artem B. Bityuckiy]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Steve,

> okay, reproduced after a couple hours of running (nothing intensive), 
> then doing a grep blah -r /*
I can't reproduce your problem using 2.6.12-rc4 + the 2 patches.
I created 50GB Reiserfs partition, copied a lot of data there (built
linux sources in many exemplars) and issued 'grep -r blah *'. I also
tried it with parallel writing to the partition - no help.

I wonder, could you please try 2.6.12-rc4 + the 2 patches and see if the
warning still there ?

The above referred patches are (and they are also attached):
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-
rc4/2.6.12-rc4-mm1/broken-out/vfs-bugfix-two-read_inode-calles-
without.patch 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/__wait_on_freeing_inode-fix.patch

P.S. I wanted to try 2.6.12-rc4-mm2, but it OOPSes during the kernel
load in my system. Then I switched to 2.6.12-rc4 in order not to fight
with -mm2's problems.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

[-- Attachment #2: vfs-bugfix-two-read_inode-calles-without.patch --]
[-- Type: text/x-patch, Size: 1184 bytes --]

diff -puN fs/inode.c~vfs-bugfix-two-read_inode-calles-without fs/inode.c
--- 25/fs/inode.c~vfs-bugfix-two-read_inode-calles-without	Fri May  6 15:12:47 2005
+++ 25-akpm/fs/inode.c	Fri May  6 15:12:47 2005
@@ -282,6 +282,13 @@ static void dispose_list(struct list_hea
 		if (inode->i_data.nrpages)
 			truncate_inode_pages(&inode->i_data, 0);
 		clear_inode(inode);
+
+		spin_lock(&inode_lock);
+		hlist_del_init(&inode->i_hash);
+		list_del_init(&inode->i_sb_list);
+		spin_unlock(&inode_lock);
+
+		wake_up_inode(inode);
 		destroy_inode(inode);
 		nr_disposed++;
 	}
@@ -317,8 +324,6 @@ static int invalidate_list(struct list_h
 		inode = list_entry(tmp, struct inode, i_sb_list);
 		invalidate_inode_buffers(inode);
 		if (!atomic_read(&inode->i_count)) {
-			hlist_del_init(&inode->i_hash);
-			list_del(&inode->i_sb_list);
 			list_move(&inode->i_list, dispose);
 			inode->i_state |= I_FREEING;
 			count++;
@@ -439,8 +444,6 @@ static void prune_icache(int nr_to_scan)
 			if (!can_unuse(inode))
 				continue;
 		}
-		hlist_del_init(&inode->i_hash);
-		list_del_init(&inode->i_sb_list);
 		list_move(&inode->i_list, &freeable);
 		inode->i_state |= I_FREEING;
 		nr_pruned++;


[-- Attachment #3: __wait_on_freeing_inode-fix.patch --]
[-- Type: text/x-patch, Size: 1655 bytes --]

diff -puN fs/inode.c~__wait_on_freeing_inode-fix fs/inode.c
--- 25/fs/inode.c~__wait_on_freeing_inode-fix	2005-05-09 20:09:33.000000000 -0700
+++ 25-akpm/fs/inode.c	2005-05-09 20:09:33.000000000 -0700
@@ -1241,29 +1241,21 @@ int inode_wait(void *word)
 }
 
 /*
- * If we try to find an inode in the inode hash while it is being deleted, we
- * have to wait until the filesystem completes its deletion before reporting
- * that it isn't found.  This is because iget will immediately call
- * ->read_inode, and we want to be sure that evidence of the deletion is found
- * by ->read_inode.
+ * If we try to find an inode in the inode hash while it is being
+ * deleted, we have to wait until the filesystem completes its
+ * deletion before reporting that it isn't found.  This function waits
+ * until the deletion _might_ have completed.  Callers are responsible
+ * to recheck inode state.
+ *
+ * It doesn't matter if I_LOCK is not set initially, a call to
+ * wake_up_inode() after removing from the hash list will DTRT.
+ *
  * This is called with inode_lock held.
  */
 static void __wait_on_freeing_inode(struct inode *inode)
 {
 	wait_queue_head_t *wq;
 	DEFINE_WAIT_BIT(wait, &inode->i_state, __I_LOCK);
-
-	/*
-	 * I_FREEING and I_CLEAR are cleared in process context under
-	 * inode_lock, so we have to give the tasks who would clear them
-	 * a chance to run and acquire inode_lock.
-	 */
-	if (!(inode->i_state & I_LOCK)) {
-		spin_unlock(&inode_lock);
-		yield();
-		spin_lock(&inode_lock);
-		return;
-	}
 	wq = bit_waitqueue(&inode->i_state, __I_LOCK);
 	prepare_to_wait(wq, &wait.wait, TASK_UNINTERRUPTIBLE);
 	spin_unlock(&inode_lock);

Re: 2.6.12-rc4-mm1

[Steve Roemen]

[-- Attachment #1: Type: text/plain, Size: 4331 bytes --]

on 05/18/05 05:06 Artem B. Bityuckiy wrote the following:

>Steve,
>
>  
>
>>okay, reproduced after a couple hours of running (nothing intensive), 
>>then doing a grep blah -r /*
>>    
>>
>I can't reproduce your problem using 2.6.12-rc4 + the 2 patches.
>I created 50GB Reiserfs partition, copied a lot of data there (built
>linux sources in many exemplars) and issued 'grep -r blah *'. I also
>tried it with parallel writing to the partition - no help.
>
>I wonder, could you please try 2.6.12-rc4 + the 2 patches and see if the
>warning still there ?
>
>The above referred patches are (and they are also attached):
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-
>rc4/2.6.12-rc4-mm1/broken-out/vfs-bugfix-two-read_inode-calles-
>without.patch 
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/__wait_on_freeing_inode-fix.patch
>
>P.S. I wanted to try 2.6.12-rc4-mm2, but it OOPSes during the kernel
>load in my system. Then I switched to 2.6.12-rc4 in order not to fight
>with -mm2's problems.
>
>  
>
>------------------------------------------------------------------------
>
>diff -puN fs/inode.c~vfs-bugfix-two-read_inode-calles-without fs/inode.c
>--- 25/fs/inode.c~vfs-bugfix-two-read_inode-calles-without	Fri May  6 15:12:47 2005
>+++ 25-akpm/fs/inode.c	Fri May  6 15:12:47 2005
>@@ -282,6 +282,13 @@ static void dispose_list(struct list_hea
> 		if (inode->i_data.nrpages)
> 			truncate_inode_pages(&inode->i_data, 0);
> 		clear_inode(inode);
>+
>+		spin_lock(&inode_lock);
>+		hlist_del_init(&inode->i_hash);
>+		list_del_init(&inode->i_sb_list);
>+		spin_unlock(&inode_lock);
>+
>+		wake_up_inode(inode);
> 		destroy_inode(inode);
> 		nr_disposed++;
> 	}
>@@ -317,8 +324,6 @@ static int invalidate_list(struct list_h
> 		inode = list_entry(tmp, struct inode, i_sb_list);
> 		invalidate_inode_buffers(inode);
> 		if (!atomic_read(&inode->i_count)) {
>-			hlist_del_init(&inode->i_hash);
>-			list_del(&inode->i_sb_list);
> 			list_move(&inode->i_list, dispose);
> 			inode->i_state |= I_FREEING;
> 			count++;
>@@ -439,8 +444,6 @@ static void prune_icache(int nr_to_scan)
> 			if (!can_unuse(inode))
> 				continue;
> 		}
>-		hlist_del_init(&inode->i_hash);
>-		list_del_init(&inode->i_sb_list);
> 		list_move(&inode->i_list, &freeable);
> 		inode->i_state |= I_FREEING;
> 		nr_pruned++;
>
>  
>
>------------------------------------------------------------------------
>
>diff -puN fs/inode.c~__wait_on_freeing_inode-fix fs/inode.c
>--- 25/fs/inode.c~__wait_on_freeing_inode-fix	2005-05-09 20:09:33.000000000 -0700
>+++ 25-akpm/fs/inode.c	2005-05-09 20:09:33.000000000 -0700
>@@ -1241,29 +1241,21 @@ int inode_wait(void *word)
> }
> 
> /*
>- * If we try to find an inode in the inode hash while it is being deleted, we
>- * have to wait until the filesystem completes its deletion before reporting
>- * that it isn't found.  This is because iget will immediately call
>- * ->read_inode, and we want to be sure that evidence of the deletion is found
>- * by ->read_inode.
>+ * If we try to find an inode in the inode hash while it is being
>+ * deleted, we have to wait until the filesystem completes its
>+ * deletion before reporting that it isn't found.  This function waits
>+ * until the deletion _might_ have completed.  Callers are responsible
>+ * to recheck inode state.
>+ *
>+ * It doesn't matter if I_LOCK is not set initially, a call to
>+ * wake_up_inode() after removing from the hash list will DTRT.
>+ *
>  * This is called with inode_lock held.
>  */
> static void __wait_on_freeing_inode(struct inode *inode)
> {
> 	wait_queue_head_t *wq;
> 	DEFINE_WAIT_BIT(wait, &inode->i_state, __I_LOCK);
>-
>-	/*
>-	 * I_FREEING and I_CLEAR are cleared in process context under
>-	 * inode_lock, so we have to give the tasks who would clear them
>-	 * a chance to run and acquire inode_lock.
>-	 */
>-	if (!(inode->i_state & I_LOCK)) {
>-		spin_unlock(&inode_lock);
>-		yield();
>-		spin_lock(&inode_lock);
>-		return;
>-	}
> 	wq = bit_waitqueue(&inode->i_state, __I_LOCK);
> 	prepare_to_wait(wq, &wait.wait, TASK_UNINTERRUPTIBLE);
> 	spin_unlock(&inode_lock);
>
>  
>
okay,  recompiled with those two files back in, and after an hour of 
running, while doing a
tar -xjvf linux-2.6.11.tar.bz2, it kicks out that error (attached).



Steve

[-- Attachment #2: dmesg_output --]
[-- Type: text/plain, Size: 553 bytes --]

BUG: atomic counter underflow at:
 [<c01aadf1>] reiserfs_clear_inode+0x81/0xb0
 [<c0173484>] clear_inode+0xe4/0x130
 [<c0173540>] dispose_list+0x70/0x130
 [<c017385f>] prune_icache+0xbf/0x1b0
 [<c0173964>] shrink_icache_memory+0x14/0x40
 [<c01471b9>] shrink_slab+0x159/0x1a0
 [<c01486e7>] balance_pgdat+0x2b7/0x3b0
 [<c01488b2>] kswapd+0xd2/0xf0
 [<c0130430>] autoremove_wake_function+0x0/0x50
 [<c0102fd2>] ret_from_fork+0x6/0x14
 [<c0130430>] autoremove_wake_function+0x0/0x50
 [<c01487e0>] kswapd+0x0/0xf0
 [<c010136d>] kernel_thread_helper+0x5/0x18

Re: 2.6.12-rc4-mm1

[David Woodhouse]

On Wed, 2005-05-18 at 11:16 -0500, Steve Roemen wrote:
> okay,  recompiled with those two files back in, and after an hour of 
> running, while doing a tar -xjvf linux-2.6.11.tar.bz2, it kicks out
> that error (attached).

Thanks. Are you using ACLs? If not, I think there's a more fundamental
problem than a race with clear_inode() -- it's not that we're
decrementing the use count on an ACL twice; it's that you think you have
an ACL when there wasn't one. This could be a symptom of memory
corruption... which has already been reported in reiserfs in 2.6.12-rc4.

Do you have CONFIG_REISERFS_CHECK enabled? Do you have preempt enabled?

Could we trouble you to try again on 2.6.12-rc3 with those two patches,
please?

-- 
dwmw2

Re: 2.6.12-rc4-mm1

[Steve Roemen]

on 05/19/05 11:45 David Woodhouse wrote the following:

>On Wed, 2005-05-18 at 11:16 -0500, Steve Roemen wrote:
>  
>
>>okay,  recompiled with those two files back in, and after an hour of 
>>running, while doing a tar -xjvf linux-2.6.11.tar.bz2, it kicks out
>>that error (attached).
>>    
>>
>
>Thanks. Are you using ACLs? If not, I think there's a more fundamental
>problem than a race with clear_inode() -- it's not that we're
>decrementing the use count on an ACL twice; it's that you think you have
>an ACL when there wasn't one. This could be a symptom of memory
>corruption... which has already been reported in reiserfs in 2.6.12-rc4.
>
>Do you have CONFIG_REISERFS_CHECK enabled? Do you have preempt enabled?
>
>Could we trouble you to try again on 2.6.12-rc3 with those two patches,
>please?
>
>  
>
Compiling 2.6.12-rc3 + the 2 patches right now.  I'll let you know in a 
couple of hours if it still does it. 
Artem forwarded you my .config file. 

Steve

Re: 2.6.12-rc4-mm1

[David Woodhouse]

On Thu, 2005-05-19 at 12:55 -0500, Steve Roemen wrote:
> Compiling 2.6.12-rc3 + the 2 patches right now.  I'll let you know in a 
> couple of hours if it still does it. 
> Artem forwarded you my .config file. 

He did. That confirms you have ACLs enabled -- but are you actually
_using_ them though? If not, the ACL fields whose refcount is causing
this problem should never have been set in the first place.

Artem is putting together a patch which will put a magic value into the
struct posix_acl and hence double-check whether we're really freeing one
of them twice, or whether it's just that we're seeing memory corruption
and what's in REISERFS_I(inode)->i_acl_{access,default} is pure noise.

It might also be useful to attempt to reproduce the problem with slab
debugging turned on, but let's not change that variable just yet.

-- 
dwmw2

Re: 2.6.12-rc4-mm1

[Steve Roemen]

on 05/19/05 13:04 David Woodhouse wrote the following:

>On Thu, 2005-05-19 at 12:55 -0500, Steve Roemen wrote:
>  
>
>>Compiling 2.6.12-rc3 + the 2 patches right now.  I'll let you know in a 
>>couple of hours if it still does it. 
>>Artem forwarded you my .config file. 
>>    
>>
>
>He did. That confirms you have ACLs enabled -- but are you actually
>_using_ them though? If not, the ACL fields whose refcount is causing
>this problem should never have been set in the first place.
>
>Artem is putting together a patch which will put a magic value into the
>struct posix_acl and hence double-check whether we're really freeing one
>of them twice, or whether it's just that we're seeing memory corruption
>and what's in REISERFS_I(inode)->i_acl_{access,default} is pure noise.
>
>It might also be useful to attempt to reproduce the problem with slab
>debugging turned on, but let's not change that variable just yet.
>
>  
>

No, I am not using ACLs. I am running the 2.6.12-rc3 with those two 
patches, and I can't get it to error out.

Steve

Re: 2.6.12-rc4-mm1

[David Woodhouse]

On Thu, 2005-05-19 at 15:12 -0500, Steve Roemen wrote:
> No, I am not using ACLs. I am running the 2.6.12-rc3 with those two 
> patches, and I can't get it to error out.

OK, then it sounds like what you've seen is a manifestation of the
already-known reiserfs breakage in 2.6.12-rc4. Artem's patch didn't
cause it; it just made it show itself.

Thanks.

-- 
dwmw2

Re: 2.6.12-rc4-mm1

[Artem B. Bityuckiy]

> i'll try to reproduce it.  this is on an IBM X31 with a pentium M no
> smp.  using reiserfs (not V4)  but did compile it with reiser4

So was the preemption enabled or disabled ?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.