On Tue, 30 Oct 2001, Carsten Jacobi wrote: > "afsmodname" is returning the name of the uniprocessor module on my > SMP machine. I wondered why he was crashing all the time until I found > out that he just loads the wrong module! > So, here is my patch suggestion for /usr/vice/etc/afsmodname:
This patch indicates that you don't understand what afsmodname is actually doing. The point of afsmodname is that it works by examining kernel symbol versions and loading a module that is compatible with the running kernel. It does not make assumptions about the meaning of the module filenames or the kernel version string; your patch would make it do both. An SMP kernel and a non-SMP kernel which are otherwise configured identically will have different symbol versions, so the wrong module will simply fail to load. This is true in every version of Linux on which OpenAFS will work, and was even true on 2.0.x kernels back when we were supporting a contributed AFS port to that platform. If the wrong module is being loaded, then it is because your kernel has the wrong symbol versions or no symbol versions. You haven't told what versions of OpenAFS or Linux you are using, what Linux distribution you're using, or where you got your kernel. Therefore, I can only guess about what the cause of your problem might be. The most common cause of incorrect symbol versions is building more than one kernel in the same source tree without an intervening 'make mrproper', 'make dep', or explicit removal of include/linux/modules. RedHat used to get this wrong, but they've fixed whatever their problem was. The most common cause of missing symbol versions is building without the CONFIG_MODVERSIONS option defined. This used to be a problem when symbol versions defaulted to 'off', but that hasn't been true for a while. In any case, if you compile without symbol versions, afsmodname won't output a module name at all; instead you'll get a message and the startup script will end up trying to load libafs-`uname -r`.o. This could be your problem, but probably is not. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
