[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--