[OpenAFS-devel] reproducible failure with recent changes to i
386_linux*
Neulinger, Nathan R.
nneul@umr.edu
Mon, 5 Feb 2001 14:56:39 -0600
These are the changes that are present since jan 10:
osi_vfs.h: 1.3 - 1.4 : 2.4
osi_vfsops.c: 1.3 - 1.4 : 2.4
osi_vnodeops.c: 1.7 - 1.8 : 2.4
osi_vfs.h: 1.4 - 1.5 : reiserfs (actually large mem not reiser)
osi_vnodeops.c: 1.8 - 1.9 : reiserfs
osi_file.c: 1.5 - 1.6 : IPUT
osi_misc.c: 1.4 - 1.5 : IPUT
osi_vfsops.c: 1.4 - 1.5 : IPUT
osi_vnodeops.c: 1.9 - 1.10 : IPUT
It breaks for me on 2.2.18 as soon as I apply the two reiserfs patches.
Making the following change to osi_vfs.h seems to fix it for me, but as I
don't have a suse+largemem system to test it with, you make want to double
check that pgoff2loff will actually be defined when osi_vfs.h is included.
The problem is that the previous check was checking to see if _REISER_FS_I
was defined, which is not correct - since you're checking for a feature that
has nothing to do with reiserfs.
I assumed checking for pgoff2loff would be the best thing, since that is
what is being done in osi_vnodeops.c for the corresponding change.
infinity(83)>diff -u osi_vfs.h.orig osi_vfs.h
--- osi_vfs.h.orig Mon Feb 5 14:31:00 2001
+++ osi_vfs.h Mon Feb 5 14:31:45 2001
@@ -36,7 +36,7 @@
uid_t i_uid;
gid_t i_gid;
kdev_t i_rdev;
-#if defined(AFS_LINUX24_ENV) || defined(_REISER_FS_I) /* XXX need better
test */
+#if defined(AFS_LINUX24_ENV) || defined(pgoff2loff) /* large mem support */
loff_t i_size;
#else
off_t i_size;
As soon as I make that change, everything is happy again.
-- Nathan
> -----Original Message-----
> From: Neulinger, Nathan R. [mailto:nneul@umr.edu]
> Sent: Monday, February 05, 2001 12:50 PM
> To: 'openafs-devel@openafs.org'
> Subject: [OpenAFS-devel] reproducible failure with recent changes to
> i386_linux*
>
>
> If I back off all the patches to the afs/LINUX directory
> since Jan 10th,
> everything is happy. As soon as I re-apply them, afsd will
> still start up
> ok, but it's hosed. I get segfaults ls'ing /afs, etc.
>
> I'm going to try incrementally applying some of those patches
> and see what
> happens.
>
> Feb 5 12:45:46 triton kernel: current->tss.cr3 = 05aac000,
> %cr3 = 05aac000
> Feb 5 12:45:46 triton kernel: *pde = 00000000
> Feb 5 12:45:46 triton kernel: Oops: 0000
> Feb 5 12:45:46 triton kernel: CPU: 0
> Feb 5 12:45:46 triton kernel: EIP: 0010:[show_registers+653/704]
> Feb 5 12:45:46 triton kernel: EFLAGS: 00010046
> Feb 5 12:45:46 triton kernel: eax: 00000000 ebx: 00000000
> ecx: 0084249c
> edx: c7354000
> Feb 5 12:45:46 triton kernel: esi: 0000002b edi: c5aca000
> ebp: c8800000
> esp: c5ac9e54
> Feb 5 12:45:46 triton kernel: ds: 0018 es: 0018 ss: 0018
> Feb 5 12:45:46 triton kernel: Process ls (pid: 693, process nr: 64,
> stackpage=c5ac9000)
> Feb 5 12:45:46 triton kernel: Stack: 0084249c 08048000
> c02d0fce c8bc9000
> c5ac9f74 c6b3e000 0084249c c8b2ff68
> Feb 5 12:45:46 triton kernel: c8b47e80 00000000
> 0084249c 00010206
> 0084249d c9000000 c010a4c8 c5ac9ed8
> Feb 5 12:45:46 triton kernel: c023c0f6 c023db2e
> 00000000 00000000
> c010f748 c023db2e c5ac9ed8 00000000
> Feb 5 12:45:46 triton kernel: Call Trace: [<c8bc9000>] [<c8b2ff68>]
> [<c8b47e80>] [<c9000000>] [die+48/56] [error_table+2646/9632]
> [error_table+9358/9632]
> Feb 5 12:45:46 triton kernel: [<c8bc9000>]
> [<c8bc9000>] [<c8b08c18>]
> [<c8bc9000>] [<c8b05d0b>] [<c8bc90ac>] [<c8b05d1d>] [<c8bc9000>]
> Feb 5 12:45:46 triton kernel: [<c8bc9000>]
> [<c8bc9000>] [<c8b2fbce>]
> [<c8bc9000>] [<c8b2fb81>] [free_pages+36/40] [__namei+51/88]
> [sys_newlstat+49/96]
> Feb 5 12:45:46 triton kernel: Code: 8a 04 0b 89 44 24 38 50
> 68 ee c0 23 c0
> e8 71 9e 00 00 83 c4
>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8b2ff68 <[libafs-2.2.18]afs_linux_mkdir+0/9c>
> Trace; c8b47e80 <[libafs-2.2.18]afs_shared_mmap_ops+14c0/4b9f>
> Trace; c9000000 <END_OF_CODE+1e581/????>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8b08c18 <[libafs-2.2.18]afs_PutVCache+44/a4>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8b05d0b <[libafs-2.2.18]afs_VerifyVCache2+167/1bc>
> Trace; c8bc90ac <[libafs-2.2.18].bss.end+7db4d/46eaed>
> Trace; c8b05d1d <[libafs-2.2.18]afs_VerifyVCache2+179/1bc>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8b2fbce <[libafs-2.2.18]afs_linux_revalidate+a6/b0>
> Trace; c8bc9000 <[libafs-2.2.18].bss.end+7daa1/46eaed>
> Trace; c8b2fb81 <[libafs-2.2.18]afs_linux_revalidate+59/b0>
> Code; 0084249c Before first symbol
> 00000000 <_EIP>:
> Code; 0084249c Before first symbol
> 0: 8a 04 0b mov (%ebx,%ecx,1),%al
> Code; 0084249f Before first symbol
> 3: 89 44 24 38 mov %eax,0x38(%esp,1)
> Code; 008424a3 Before first symbol
> 7: 50 push %eax
> Code; 008424a4 Before first symbol
> 8: 68 ee c0 23 c0 push $0xc023c0ee
> Code; 008424a9 Before first symbol
> d: e8 71 9e 00 00 call 9e83 <_EIP+0x9e83>
> 0084c31f Before
> first symbol
> Code; 008424ae Before first symbol
> 12: 83 c4 00 add $0x0,%esp
>
>
> 3 warnings and 1 error issued. Results may not be reliable.
>
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger EMail: nneul@umr.edu
> University of Missouri - Rolla Phone: (573) 341-4841
> Computing Services Fax: (573) 341-4216
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
>