Aaron Kulkis wrote: > Richard Creighton wrote: >> I feel like taking my favorite deity's name in vain so he would smite me >> off of the face of the earth because I couldn't be madder in hell than I >> am now at openSuSE's updater program. >> >> I have a raid disk controller that is not directly supported by any >> kernel issued by openSuSE. Worse, there are kernels that will not > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> compile the source of the controller card so when I get a kernel that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Uh... > NO kernel compiles the source of any code written for ANYTHING. > > The kernel is a resource manager and process scheduler. > > Compiling is done by a compiler, such as gcc, g++ or fort77. Um...let me re-phrase it then... while using the new kernel and the syms and internals and whatever support the kernel provides to the compilers, linkers and other such programs, the source code for the disk controller driver would fail to sucessfully compile but WITHOUT CHANGE to the source code or make files or .config, etc., if I booted and ran the compatible kernel, then the code would compile successfully and the resultant rr174x.ko could be insmod ed into the running kernel and the controller would function to allow access to the 2.5TB hardware raid 5 array. Now, I can't say the kernel compiled the driver, but the wrong kernel somehow prevented successful compilation. My guess is that the defective kernels had some internal links, symbols or pointers that a compiler, linker or loader or other support program depended on or that mismanaged a stack pointer or memory allocation that prevented successful compilation or insertion of a previously compiled driver module.
...but the other day, I was way too mad to say all of that and I still may be off base as to why one kernel would prevent sucessful compilation or even use of a driver where previous and subsequent kernels would allow success. All I know is that no updater program should remove my options to recover from whatever errors that cause such behavior by erasing all my functioning alternatives without at least the courtesy of telling me to go ))(*&*^ myself. I do appreciate your feedback however and hopefully your and the support of others in this forum to induce openSuSE to change the way such a critical program functions especially in the case of kernel replacement or patching. Richard -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
