[OpenAFS-devel] Unable to access /afs with 2.4.0-ac9 and openafs 1.0.2

Jeremy Katz katzj@linuxpower.org
Mon, 22 Jan 2001 20:21:18 -0800


--H6o9R95t2FPeZmf3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Monday, January 22 2001, Jeremy Katz said:

> Having a problem wiht OpenAFS 1.0.2 and Linux 2.4.0-ac9.  afsd starts
> fine and reports that the AFS root is mounted on /afs without any errors
> when afsd is run with -debug and -verbose.  But an ls of /afs returns
> the contents of the root directory as opposed to /afs.  Anyone seen this
> or have any clue as to why it might be occurring?

And now to reply to myself...  the strangeness on the mounting of /afs
begins in 2.4.0-ac1, but doesn't happen in stock 2.4.  In vanilla 2.4.0,
I instead get a nice oops.  ksymoops gives

EFLAGS: 00010202
eax: 00000301   ebx: 00000000   ecx: ca0ecbc0   edx: 00000000
esi: 0806af80   edi: cb084c9c   ebp: 00000000   esp: ca0d3c34
ds: 0018   es: 0018   ss: 0018
Process afsd (pid: 1022, stackpage=3Dca0d3000)
Stack: cc8b0000 00003121 ca0ecbc0 cc858bc1 cb084c80 00003121 00000001
cb084c81=20
       cb084c81 cc8b0000 00000007 cc887a2e cc8b0000 00003121 cc8e71d0
cc8e71d0=20
       cbf36100 0806ae80 cb084c80 cc88bd23 cb084c80 00000296 c02d94a0
c01ac064=20
Call Trace: [<cc8b0000>] [<cc858bc1>] [<cc8b0000>] [<cc887a2e>]
[<cc8b0000>] [<cc8e71d0>] [<cc8e71d0>]=20
       [<cc88bd23>] [<c01ac064>] [<c014ea33>] [<c01330a8>] [<c01330a8>]
[<c014ee4f>] [<c014ef2d>] [<c014ee4f>]=20
       [<c014ef2d>] [<cc888fc4>] [<c011c810>] [<cc888d9f>] [<cc8a5350>]
[<c014f2ea>] [<c014f2c0>] [<c0108fd0>]=20
       [<c013f154>] [<c0150f95>] [<c014dd23>] [<c014ddf4>] [<c013b070>]
[<c0112aca>] [<c0144b12>] [<cc88c178>]=20
       [<c013ecca>] [<c0131e31>] [<c0108f27>]=20
Code: 8b 42 0c 83 ec 0c a3 ec ba 89 cc 51 89 15 38 bc 89 cc e8 26=20
>>EIP; cc888703 <[libafs-2.4.0]osi_InitCacheInfo+4b/6c>   <=3D=3D=3D=3D=3D
Trace; cc8b0000 <.bss.end+60e1/???
Trace; cc858bc1 <[libafs-2.4.0]afs_InitCacheInfo+31/f8>
Trace; cc8b0000 <.bss.end+60e1/???
Trace; cc887a2e <[libafs-2.4.0]osi_linux_alloc+9a/100>
Trace; cc8b0000 <.bss.end+60e1/???
Trace; cc8e71d0 <END_OF_CODE+3d2b1/???
Trace; cc8e71d0 <END_OF_CODE+3d2b1/???
Trace; cc88bd23 <[libafs-2.4.0]afs_syscall_call+7b3/ae8>
Trace; c01ac064 <ide_intr+124/150>
Trace; c014ea33 <grok_partitions+25d3/215a0>
Trace; c01330a8 <bread+18/9a0>
Trace; c01330a8 <bread+18/9a0>
Trace; c014ee4f <grok_partitions+29ef/215a0>
Trace; c014ef2d <grok_partitions+2acd/215a0>
Trace; c014ee4f <grok_partitions+29ef/215a0>
Trace; c014ef2d <grok_partitions+2acd/215a0>
Trace; cc888fc4 <[libafs-2.4.0]afs_osi_Wakeup+30/3c>
Trace; c011c810 <del_timer+4f0/c30>
Trace; cc888d9f <[libafs-2.4.0]AfsWaitHack+13/18>
Trace; cc8a5350 <[libafs-2.4.0]waitV+0/4>
Trace; c014f2ea <grok_partitions+2e8a/215a0>
Trace; c014f2c0 <grok_partitions+2e60/215a0>
Trace; c0108fd0 <__rwsem_wake+1200/2450>
Trace; c013f154 <dcache_readdir+464/570>
Trace; c0150f95 <grok_partitions+4b35/215a0>
Trace; c014dd23 <grok_partitions+18c3/215a0>
Trace; c014ddf4 <grok_partitions+1994/215a0>
Trace; c013b070 <path_release+50/150>
Trace; c0112aca <__verify_write+2ba/840>
Trace; c0144b12 <inode_setattr+82/150>
Trace; cc88c178 <[libafs-2.4.0]afs_syscall+cc/1f4>
Trace; c013ecca <vfs_readdir+5a/80>
Trace; c0131e31 <fput+71/d0>
Trace; c0108f27 <__rwsem_wake+1157/2450>
Code;  cc888703 <[libafs-2.4.0]osi_InitCacheInfo+4b/6c>
00000000 <_EIP>:
Code;  cc888703 <[libafs-2.4.0]osi_InitCacheInfo+4b/6c>   <=3D=3D=3D=3D=3D
   0:   8b 42 0c                  mov    0xc(%edx),%eax   <=3D=3D=3D=3D=3D
Code;  cc888706 <[libafs-2.4.0]osi_InitCacheInfo+4e/6c>
   3:   83 ec 0c                  sub    $0xc,%esp
Code;  cc888709 <[libafs-2.4.0]osi_InitCacheInfo+51/6c>
   6:   a3 ec ba 89 cc            mov    %eax,0xcc89baec
Code;  cc88870e <[libafs-2.4.0]osi_InitCacheInfo+56/6c>
   b:   51                        push   %ecx
Code;  cc88870f <[libafs-2.4.0]osi_InitCacheInfo+57/6c>
   c:   89 15 38 bc 89 cc         mov    %edx,0xcc89bc38
Code;  cc888715 <[libafs-2.4.0]osi_InitCacheInfo+5d/6c>
  12:   e8 26 00 00 00            call   3d <_EIP+0x3d> cc888740
<[libafs-2.4.0]osi_rdwr+1c/c4>


Any more thoughts?  I'm going to try to test 2.4.1-pre<latest> either
tonight or first thing tomorrow morning as well, but ac9 has quite a bit
of the substance of the first few prepatches at least.

Jeremy

--=20
Jeremy Katz
katzj@linuxpower.org	| jlkatz@eos.ncsu.edu
http://linuxpower.org	| Developer, NCSU Realm Kit for Red Hat Linux
GPG fingerprint: 367E 8B6B 5E57 2BDB 972A 4D73 C83C B4E8 89FE 392D

--H6o9R95t2FPeZmf3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6bQa+yDy06In+OS0RArHSAJ0RXqNRqzehETsQpf73nGqwWTvYRwCeOIq6
pHZ1BgJFPrehMDh9cy29i8g=
=/0vd
-----END PGP SIGNATURE-----

--H6o9R95t2FPeZmf3--