Oops immediately following dbench 192 on 2.5.3

Oops immediately following dbench 192 on 2.5.3

[rwhron]

System has reiserfs root filesystem and other filesystems, except
for the ext2 filesystem that was running dbench 192.  IDE.

Oops occured right after dbench 192 completed, but before
"sync;sync;sync" completed in the "runtests" wrapper script executing 
dbench.  (CLIENTS directory was still on system, after e2fsck 
- this directory is removed when dbench terminates)  An echo
statement did print that dbench 192 completed though.

Earlier, dbench 64 completed without a problem.

Here is the oops:

PAP-5580: reiserfs_cut_from_item: item to convert does not exist ([6 17330 0x1 IND])invalid operand: 0000
CPU:    0
EIP:    0010:[<c015e919>]    Not tainted
EFLAGS: 00010286
eax: 00000057   ebx: c01f69c0   ecx: 00000001   edx: d7014000
esi: d7ea2800   edi: 00000000   ebp: d69c5e40   esp: d69c5c44
ds: 0018   es: 0018   ss: 0018
Process runtests (pid: 68, stackpage=d69c5000)
Stack: c01f553a c0265360 c01f69c0 d69c5c68 d69c5ca0 00000000 c01658ab d7ea2800
       c01f69c0 d69c5e80 c0840de0 00000003 00000000 00000002 00001000 00000000
       00000001 d69c5ca4 00000f60 00000001 00000f60 d7ea2800 63eb2120 00000000
Call Trace: [<c01658ab>] [<c0165e89>] [<c0157cc8>] [<c0158a3c>] [<c012bd64>]
   [<c012af0b>] [<c0135f73>] [<c01085f3>]

Code: 0f 0b 68 60 53 26 c0 b8 40 55 1f c0 85 f6 74 06 8d 86 cc 00
CPU:    0
EIP:    0010:[<c015e919>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000057   ebx: c01f69c0   ecx: 00000001   edx: d7014000
esi: d7ea2800   edi: 00000000   ebp: d69c5e40   esp: d69c5c44
ds: 0018   es: 0018   ss: 0018
Process runtests (pid: 68, stackpage=d69c5000)
Stack: c01f553a c0265360 c01f69c0 d69c5c68 d69c5ca0 00000000 c01658ab d7ea2800
       c01f69c0 d69c5e80 c0840de0 00000003 00000000 00000002 00001000 00000000
       00000001 d69c5ca4 00000f60 00000001 00000f60 d7ea2800 63eb2120 00000000
Call Trace: [<c01658ab>] [<c0165e89>] [<c0157cc8>] [<c0158a3c>] [<c012bd64>]
   [<c012af0b>] [<c0135f73>] [<c01085f3>]
Code: 0f 0b 68 60 53 26 c0 b8 40 55 1f c0 85 f6 74 06 8d 86 cc 00

>>EIP; c015e918 <reiserfs_panic+28/4c>   <=====
Trace; c01658aa <reiserfs_cut_from_item+1b2/450>
Trace; c0165e88 <reiserfs_do_truncate+2f8/424>
Trace; c0157cc8 <reiserfs_truncate_file+c4/158>
Trace; c0158a3c <reiserfs_file_release+31c/340>
Trace; c012bd64 <fput+4c/d0>
Trace; c012af0a <filp_close+5e/68>
Trace; c0135f72 <sys_dup2+8a/b0>
Trace; c01085f2 <syscall_traced+6/a>
Code;  c015e918 <reiserfs_panic+28/4c>
00000000 <_EIP>:
Code;  c015e918 <reiserfs_panic+28/4c>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c015e91a <reiserfs_panic+2a/4c>
   2:   68 60 53 26 c0            push   $0xc0265360
Code;  c015e91e <reiserfs_panic+2e/4c>
   7:   b8 40 55 1f c0            mov    $0xc01f5540,%eax
Code;  c015e924 <reiserfs_panic+34/4c>
   c:   85 f6                     test   %esi,%esi
Code;  c015e926 <reiserfs_panic+36/4c>
   e:   74 06                     je     16 <_EIP+0x16> c015e92e <reiserfs_panic+3e/4c>
Code;  c015e928 <reiserfs_panic+38/4c>
  10:   8d 86 cc 00 00 00         lea    0xcc(%esi),%eax

K6-2/475
00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 02)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15)

config:
CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_EXPERIMENTAL=y
CONFIG_MK6=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BLK_DEV_FD=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=64
CONFIG_REISERFS_FS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_VGA_CONSOLE=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y

I'll try 2.5.3-dj1, which I see has some reiserfs fixes.
-- 
Randy Hron

Re: Oops immediately following dbench 192 on 2.5.3

[Dave Jones]

On Thu, 31 Jan 2002 rwhron@earthlink.net wrote:

> System has reiserfs root filesystem and other filesystems, except
> for the ext2 filesystem that was running dbench 192.  IDE.

Does the patch Oleg posted earlier for 2.5.2-dj7 fix this problem ?
I was wondering why that bug was showing up in -dj but not mainline,
so I'm expecting it to solve your problem.

Subject was Re: Current Reiserfs Update / 2.5.2-dj7 Oops

(Or just grab the reiserfs changes from 2.5.3-dj1)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Oops immediately following dbench 192 on 2.5.3

[rwhron]

> > System has reiserfs root filesystem and other filesystems, except
> > for the ext2 filesystem that was running dbench 192.  IDE.
> 
> Does the patch Oleg posted earlier for 2.5.2-dj7 fix this problem ?
> I was wondering why that bug was showing up in -dj but not mainline,
> so I'm expecting it to solve your problem.

Hmm, I don't see my similar report on 2.5.2-dj7 in the archive.
Basically the exact same behaviour I got with 2.5.3.
Between 2.5.2-dj7 and 2.5.3 runs; 2.4.17 and 2.4.18pre7aa1 ran
the same tests without a problem.

Here is the report on 2.5.2-dj7:

I got the following oops on 2.5.2-dj7 during the "runtests"
benchmark.  The logfiles suggest it was after dbench 192
completed on ext2, but before the next test (LTP) got
started.  I.E. in the "echo;sync;sleep" part of the
"runtests" wrapper.  Filesystems are reiserfs other than
the one that runs dbench.

It did not reboot.  It does appear livelocked though.
2.5.2-dj[1-6] completed the tests with no problem.

ksymoops:

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
CPU:    0
EIP:    0010:[<c015f4b9>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000057   ebx: c01f69e0   ecx: 00000001   edx: d7962000
esi: d7ea2800   edi: 00000000   ebp: d735fe40   esp: d735fc44
ds: 0018   es: 0018   ss: 0018
Process runtests (pid: 68, stackpage=d735f000)
Stack: c01f555a c02612c0 c01f69e0 d735fc68 d735fca0 00000000 c016644b d7ea2800
       c01f69e0 d735fe80 c237f4e0 00000003 00000006 00000008 00001000 00000000
       00000001 d735fca4 00000f58 00000001 00000f58 d7ea2800 63eb3120 00000000
Call Trace: [<c016644b>] [<c0166a29>] [<c015884c>] [<c01595cc>] [<c012c484>]
   [<c012b66b>] [<c0136d03>] [<c01085c3>]
Code: 0f 0b 68 c0 12 26 c0 b8 60 55 1f c0 85 f6 74 06 8d 86 cc 00

>>EIP; c015f4b8 <reiserfs_panic+28/4c>   <=====
Trace; c016644a <reiserfs_cut_from_item+1b2/450>
Trace; c0166a28 <reiserfs_do_truncate+2f8/424>
Trace; c015884c <reiserfs_truncate_file+c4/154>
Trace; c01595cc <reiserfs_file_release+31c/340>
Trace; c012c484 <fput+4c/d0>
Trace; c012b66a <filp_close+5e/68>
Trace; c0136d02 <sys_dup2+8a/b0>
Trace; c01085c2 <system_call+32/40>
Code;  c015f4b8 <reiserfs_panic+28/4c>
00000000 <_EIP>:
Code;  c015f4b8 <reiserfs_panic+28/4c>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c015f4ba <reiserfs_panic+2a/4c>
   2:   68 c0 12 26 c0            push   $0xc02612c0
Code;  c015f4be <reiserfs_panic+2e/4c>
   7:   b8 60 55 1f c0            mov    $0xc01f5560,%eax
Code;  c015f4c4 <reiserfs_panic+34/4c>
   c:   85 f6                     test   %esi,%esi
Code;  c015f4c6 <reiserfs_panic+36/4c>
   e:   74 06                     je     16 <_EIP+0x16> c015f4ce <reiserfs_panic+3e/4c>
Code;  c015f4c8 <reiserfs_panic+38/4c>
  10:   8d 86 cc 00 00 00         lea    0xcc(%esi),%eax

-- 
Randy Hron

Re: Oops immediately following dbench 192 on 2.5.3

[Dave Jones]

On Thu, 31 Jan 2002 rwhron@earthlink.net wrote:

> Hmm, I don't see my similar report on 2.5.2-dj7 in the archive.

The patches in question..

--- linux-2.5.3/fs/reiserfs/inode.c.orig	Thu Jan 31 19:28:57 2002
+++ linux-2.5.3/fs/reiserfs/inode.c	Thu Jan 31 19:31:01 2002
@@ -888,6 +888,8 @@
     copy_key (INODE_PKEY (inode), &(ih->ih_key));
     inode->i_blksize = PAGE_SIZE;

+    INIT_LIST_HEAD(&(REISERFS_I(inode)->i_prealloc_list ));
+
     if (stat_data_v1 (ih)) {
 	struct stat_data_v1 * sd = (struct stat_data_v1 *)B_I_PITEM (bh, ih);
 	unsigned long blocks;
@@ -1532,6 +1534,7 @@
     REISERFS_I(inode)->i_first_direct_byte = S_ISLNK(mode) ? 1 :
       U32_MAX/*NO_BYTES_IN_DIRECT_ITEM*/;

+    INIT_LIST_HEAD(&(REISERFS_I(inode)->i_prealloc_list ));
     REISERFS_I(inode)->i_flags = 0;
     REISERFS_I(inode)->i_prealloc_block = 0;
     REISERFS_I(inode)->i_prealloc_count = 0;
--- linux-2.5.3/fs/reiserfs/stree.c.orig	Thu Jan 31 19:24:47 2002
+++ linux-2.5.3/fs/reiserfs/stree.c	Thu Jan 31 19:26:54 2002
@@ -126,19 +126,19 @@
   retval = comp_short_keys (le_key, cpu_key);
   if (retval)
       return retval;
-  if (le_key_k_offset (cpu_key->version, le_key) < cpu_key_k_offset (cpu_key))
+  if (le_key_k_offset (le_key_version(le_key), le_key) < cpu_key_k_offset (cpu_key))
       return -1;
-  if (le_key_k_offset (cpu_key->version, le_key) > cpu_key_k_offset (cpu_key))
+  if (le_key_k_offset (le_key_version(le_key), le_key) > cpu_key_k_offset (cpu_key))
       return 1;

   if (cpu_key->key_length == 3)
       return 0;

   /* this part is needed only when tail conversion is in progress */
-  if (le_key_k_type (cpu_key->version, le_key) < cpu_key_k_type (cpu_key))
+  if (le_key_k_type (le_key_version(le_key), le_key) < cpu_key_k_type (cpu_key))
     return -1;

-  if (le_key_k_type (cpu_key->version, le_key) > cpu_key_k_type (cpu_key))
+  if (le_key_k_type (le_key_version(le_key), le_key) > cpu_key_k_type (cpu_key))
     return 1;

   return 0;
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Oops immediately following dbench 192 on 2.5.3

[rwhron]

> > Hmm, I don't see my similar report on 2.5.2-dj7 in the archive.
> 
> The patches in question..

Cool!  thanks!  It appears you already have them in 2.5.3-dj1.  
I applied the patch to 2.5.3 and will give it a go.

-- 
Randy Hron

Re: Oops immediately following dbench 192 on 2.5.3

[rwhron]

On Fri, Feb 01, 2002 at 04:24:57AM +0100, Dave Jones wrote:
> 
> The patches in question..

Success!  With Oleg's patch on 2.5.3, dbench 192 completes
and the other tests are underway.  :)

-- 
Randy Hron