[OpenAFS] linux kernel options ?

[Horst Birthelmer]

On Nov 25, 2004, at 10:31 AM, EC wrote:

>>>>>
>>>>> Are there any =AB=A0must have=A0=BB options in order to make AFSD =
work in a
>>>>> linux
>>>>> kernel ?
>>>>>
>>>>
>>>> Nice question ...
>>>> You mean runtime options??? or configure options for OpenAFS?? or
>>>> options for the compilation of the kernel or start options for=20
>>>> afsd??
>>>>
>>>> The question about runtime options for kernel and afsd I can tell
>>>> there
>>>> are no "must have" options :-).
>>>> If you set up your cache for AFS, afsd should simply work after
>>>> inserting the kernel module.
>>>>
>>>> For the rest you have to be more specific.
>>>
>>> I mean Linux Kernel compilation options.
>>>
>>
>> I never needed something special.
>>
>>> I have a P4 and P3. My scripts for compilation and launching of
>>> OpenAFS work
>>> fine for the P4. The P3 cannot start AFSD..  kernel oopses. (sent
>>> recently a
>>> message about afsd crash... no answer... :( ).
>>>
>>
>> What Kernel are you using on those two platforms?? Maybe you wrote=20
>> that
>> on your recent message. I can't find it right now, sorry.
>
> Linux Kernel 2.4.27 / 2.4.28. No patches applied. AFS 1.2.13.
> Module is loaded correctly (but kernel tainted). Servers start ok. =
AFSD
> oopses the kernel and goes to a sort of infinite loop.

Server always work on linux since they don't need the kernel module.=20
(Just user space ;-) )

>
> Ksymoops gives :
>
>>> EIP; c0110806 <wait_for_completion+66/ac>   <=3D=3D=3D=3D=3D
>
> Trace; d88cd03b <[libafs-2.4.28.4es]afs_DaemonOp+6b/e0>
> Trace; d88ccf90 <[libafs-2.4.28.4es]afsd_launcher+0/40>
> Trace; d88cdb99 <[libafs-2.4.28.4es]afs_syscall_call+ae9/b10>
> Trace; c01296f2 <__alloc_pages+6a/28c>
> Trace; c0127f42 <lru_cache_add+5a/60>
> Trace; c011f893 <do_wp_page+1af/1f0>
> Trace; c011fe53 <handle_mm_fault+7b/b4>
> Trace; c010f6e4 <do_page_fault+160/4a0>
> Trace; d88cdddf <[libafs-2.4.28.4es]afs_syscall+1bf/210>
> Trace; c011be20 <sys_setpriority+5c/d4>
> Trace; c0106b27 <system_call+33/38>
>
> Or :
>
>>> EIP; c01105e6 <__wake_up+32/a4>   <=3D=3D=3D=3D=3D
>
> Trace; d88edba0 <[libafs-2.4.28.4es]afs_waitForever+0/4>
> Trace; d88ca5c0 <[libafs-2.4.28.4es]afs_osi_Wakeup+40/50>
> Trace; d88ccc35 <[libafs-2.4.28.4es]afs_InitSetup+85/90>
> Trace; d88edb30 <[libafs-2.4.28.4es]afs_InitSetup_done+0/4>
> Trace; d88ccbc6 <[libafs-2.4.28.4es]afs_InitSetup+16/90>
> Trace; d88cd077 <[libafs-2.4.28.4es]afs_DaemonOp+a7/e0>
> Trace; d88cdb99 <[libafs-2.4.28.4es]afs_syscall_call+ae9/b10>
> Trace; c01296f2 <__alloc_pages+6a/28c>
> Trace; c0127f42 <lru_cache_add+5a/60>
> Trace; c011f893 <do_wp_page+1af/1f0>
> Trace; c011fe53 <handle_mm_fault+7b/b4>
> Trace; c010f6e4 <do_page_fault+160/4a0>
> Trace; d88cdddf <[libafs-2.4.28.4es]afs_syscall+1bf/210>
> Trace; c011be20 <sys_setpriority+5c/d4>
> Trace; c0106b27 <system_call+33/38>
>

What you see here is some kind of endless loop since the client threads=20=

are waiting during initialization for each other.
One of them doesn't complete.
The good question in this case is which one, and what does it do??

Can you start afsd with -verbose -debug so we're able to see the=20
syscalls?? Maybe there is something wrong there.

Horst=