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=ca0d3000)
Stack: cc8b0000 00003121 ca0ecbc0 cc858bc1 cb084c80 00003121 00000001
cb084c81
cb084c81 cc8b0000 00000007 cc887a2e cc8b0000 00003121 cc8e71d0
cc8e71d0
cbf36100 0806ae80 cb084c80 cc88bd23 cb084c80 00000296 c02d94a0
c01ac064
Call Trace: [<cc8b0000>] [<cc858bc1>] [<cc8b0000>] [<cc887a2e>]
[<cc8b0000>] [<cc8e71d0>] [<cc8e71d0>]
[<cc88bd23>] [<c01ac064>] [<c014ea33>] [<c01330a8>] [<c01330a8>]
[<c014ee4f>] [<c014ef2d>] [<c014ee4f>]
[<c014ef2d>] [<cc888fc4>] [<c011c810>] [<cc888d9f>] [<cc8a5350>]
[<c014f2ea>] [<c014f2c0>] [<c0108fd0>]
[<c013f154>] [<c0150f95>] [<c014dd23>] [<c014ddf4>] [<c013b070>]
[<c0112aca>] [<c0144b12>] [<cc88c178>]
[<c013ecca>] [<c0131e31>] [<c0108f27>]
Code: 8b 42 0c 83 ec 0c a3 ec ba 89 cc 51 89 15 38 bc 89 cc e8 26
>>EIP; cc888703 <[libafs-2.4.0]osi_InitCacheInfo+4b/6c> <=====
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> <=====
0: 8b 42 0c mov 0xc(%edx),%eax <=====
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
--
Jeremy Katz
[EMAIL PROTECTED] | [EMAIL PROTECTED]
http://linuxpower.org | Developer, NCSU Realm Kit for Red Hat Linux
GPG fingerprint: 367E 8B6B 5E57 2BDB 972A 4D73 C83C B4E8 89FE 392D
PGP signature
