Andrew Perrin <[EMAIL PROTECTED]> writes: > Package: openafs-modules-source > Version: 1.4.7.dfsg1-2 > Severity: grave > Justification: renders package unusable
I think that's a little strong. I downgraded the bug. > adorno:/etc/openafs# /etc/init.d/openafs-client force-reload > Stopping AFS services:afsd: Shutting down all afs processes and afs state > openafs. > Starting AFS services:FATAL: Error inserting openafs > (/lib/modules/2.6.24/fs/openafs.ko): Cannot allocate memory > > Failed to load AFS kernel module, not starting AFS > adorno:/etc/openafs# modprobe openafs > FATAL: Error inserting openafs (/lib/modules/2.6.24/fs/openafs.ko): Cannot > allocate memory How many times have you unloaded and reloaded the module on that system since the last reboot? I can't duplicate this on any of my systems at the moment, but I have seen this after some period of time of testing various versions without a reboot and the AFS module does tend to leak at least some memory when it's unloaded. I suspect that eventually it fragments the kernel's internal memory allocator. (The Linux kernel interface keeps changing and it's very hard to keep up with the changes in areas like this.) I suspect the system will be fine after a reboot. Unloading and reloading the module *mostly* works but is not the best thing to do when it can be avoided. It's not something that I consider critical to support, although I'll report this upstream and hopefully someone will have a chance to take a look and figure out where we're leaking memory. If you have more useful debugging information (dmesg, for example), that will be helpful; I can provide upstream with the details of the memory leak that I see, but I can reload the module anyway. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
