[OpenAFS] Re: 1.3.70 comments?

[Tony D'Amato]

>On Wed, 18 Aug 2004, Tony D'Amato wrote:
>
>> * the AIX 4.3.3 install had some minor glitches - one initial discovery
>> was that the cfgafs binary was compiled during the build, but install
>> did not place it into rs_aix42/dest/root.client/usr/vice/etc/dkload
>> like

> this probably means i screwed up a makefile change

I noticed in src/export/Makefile.in has this section of code in it:

---begin---
...
${DEST}/root.client/usr/vice/etc/dkload/cfgexport: cfgexport
        ${INSTALL} $? $@

${DEST}/root.client/usr/vice/etc/dkload/cfgexport64: @AIX64@cfgexport64
@AIX64@ ${INSTALL} $? $@

${DEST}/root.client/usr/vice/etc/dkload/cfgafs: @AIX64@cfgafs
@AIX64@ ${INSTALL} $? $@

${DEST}/root.client/usr/vice/etc/dkload/cfgafs64: @AIX64@cfgafs64
@AIX64@ ${INSTALL} $? $@

...
---end---

Hope this helps... haven't tried to make a patch and test it, sorry...

>> cfgexport was. Another that I'll need to dig into is that if one is
>> using the tcsh shell and performs a tab-complete on a file in AFS
>>space,
>> AIX suffers a kernel panic.

> let me know what you find.Here's a trace from two AIX 'crash' runs -
the first is from the 'tcsh tab-completion' crash, and the second
happened during an AFS backup (this machine uses the Tivoli dsm_afsc
command to backup our cell):

*** tab-completion crash:

> trace
STACK TRACE:
        .[afs.ext.32:rxi_NewCall] ()    2ff3a630
        .[afs.ext.32:rx_NewCall] ()     2ff3a6a0
        .[afs.ext.32:RXAFS_FetchStatus] ()      2ff3a730
        .[afs.ext.32:afs_FetchStatus] ()        2ff3a7b0
        .[afs.ext.32:afs_GetVCache] ()  2ff3a880
        .[afs.ext.32:afs_lookup] ()     2ff3a940
        .[afs.ext.32:afs_gn_lookup] ()  2ff3aae0
        .[afs.ext.32:vn_lookup] ()      2ff3ab30
        .vnop_lookup () 2ff3ab80
        .lookuppn ()    2ff3abc0
        .lookupname_cur ()      2ff3ae60
        .statx ()       2ff3b2d0
        .sys_call_ret ()        2ff3b3c0
IAR not in kernel segment.


*** dsm_afsc crash:

> trace
STACK TRACE:
        .[afs.ext.32:rxi_NewCall] ()    2ff3a780
        .[afs.ext.32:rx_NewCall] ()     2ff3a7f0
        .[afs.ext.32:VL_GetEntryByNameU] ()     2ff3a880
        .[afs.ext.32:afs_NewVolumeByName] ()    2ff3a900
        .[afs.ext.32:afs_GetVolume] ()  2ff3a990
        .[afs.ext.32:afs_GetVCache] ()  2ff3a9f0
        .[afs.ext.32:afs_root_nolock] ()        2ff3aab0
        .[afs.ext.32:afs_root] ()       2ff3ab20
        .[afs.ext.32:vfs_root] ()       2ff3ab70
        .vfs_root ()    2ff3abc0
        .lookuppn ()    2ff3ac00
        .lookupname_cur ()      2ff3aea0
        .chdirec ()     2ff3b310
        paged_text_start ()     2ff3b360
        .sys_call_ret ()        2ff3b3c0
IAR not in kernel segment.


They both appear to me to end up in src/rx/rx.c in rxi_NewCall(), but
I'm not sure where to go from here. Any pointers? I've never done any
kernel coding, but I'll see what I can do...

On a side note, once I got past a bogus kernel-source, I was able to get
the RedHat 9 client working *grin*
-- 
Tony.

He that would make his own liberty secure must guard even his enemy 
from oppression; for if he violates this duty he establishes a precedent
that will reach to himself. --Thomas Paine