| I emailed the developer again yesterday, and he told me that he | believes the problem to be gcc-4.1 in FC5 (and not its kernel). That | at least makes more sense than blaming the kernel, when the problem | also existed with an official kernel.org kernel too. Interesting. If this is correct, it still probably indicates a bug in the driver code rather than GCC. Usually what has happened is that the C compiler has gotten better at optimization, exposing new places where the driver needed to use "volatile" or some similar mechanism. Not always: there was a horrible bug in FC4's X last summer that was caused by a subtle GCC bug in handling casts to volatile qualified types. It took several of us to convince the GCC folk that they were reading the C standard unreasonably. See the thread starting here: http://gcc.gnu.org/ml/gcc/2005-07/msg00664.html Here's how to test the hypothesis: recompile the driver with no optimization. This may seem to require spelunking makefiles that are very convoluted and obscure. If so, there is a cheating shortcut that might work: capture the makefile log, manually edit out the optimization flags, and manually rerun the commands. If the driver works when compiled without optimization, this is a strong indication that the driver is not getting along with GCC changes. This is a good start to diagnosing the problem. If the driver does not work when compiled without optimization, it is very probably not a compiler/code mismatch. I admire the effort to which you (plural) have gone to chase this down. Many would just wait until someone else diagnosed it.
