> I'm wondering whether this would help also with other 64-Bit machines. > Doing some handhacking and selecting the right #defines with 1.5.2, get's > me past this rlim error --- due to SMP EXIT_ZOMBIE has to be put in > afs_osi.c a couple of times, but then it complains about > > /usr/src/openafs-1.5.2/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_vnop_flock.c:176: > > error: struct task_struct has no member named p_opptr > > Any ideas on that? This seems to be another macro gone wild, but I can't > really tell where and how... > > The machine in question is a x86_64 running 2.6.16.13-4 (seems to be a > SuSE 10 default installation --- in case you're more happy w/ another > distro I'll talk to the guy who has to work with this thing). I've tried > OpenAFS 1.5.1, 1.5.2, 1.4.1. I just need a pointer in the right direction > --- haven't looked at Linux kernel for years and it looks quite different > to me ;)
I managed to build OpenAFS 1.4.1 on 2.6.17 (kernel.org) on a PPC64 machine, using "CFLAGS='-m64' ./configure --with-linux-kernel-headers=/usr/src/linux-2.6.17" However, I also patched either osi_probe.co or osi_syscall.c to completely skip the syscall table probeing. The patch is at work, so I can't post it right now. If you don't do the syscall table patch, you won't have correct PAG support, but you can at least have a working afs client instead of one that panics the kernel. (And while I'm talking about the syscall table patching, does anyone have time and/or resources to try using the kernel keyring support that is in the 2.6.16 (and newer) kernels instead of having to use the PAG and group-based hacks? What code needs to change to make this work? _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
