Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 13 May 2003 22:37:47 -0700 | From | William Lee Irwin III <> | Subject | Re: ahc_linux_map_seg() compile/style/data corruption fixes |
| |
On Tue, May 13, 2003 at 09:49:34PM -0700, William Lee Irwin III wrote: > This is basically a compilefix for axel@pearbough.net's compile failure, > with some added cleanup. (2) should cause data corruption on x440, > NUMA-Q, and ES7000 almost every time this is called, so I guess this > qualifies as a runtime bugfix too. Oddly, I'm not seeing any even on > 64GB NUMA-Q, so it's probably bouncing due to some other bug. > For the connoisseur, I've attached before/after disassemblies > demonstrating that the if () whose failure is caused by (2) is a very, > very, very real problem. In order to isolate the code, I uninlined > ahc_linux_map_seg() so the code could be isolated from the rest of > everything. It's clear well over half the function was missing before. > Also note the calls to panic() are made by jmps to the end of the > function. This is 5f in the -'s, and f3 in the +'s. i.e. you can > very easily tell from the disassembly that one of the panic()'s is > missing, i.e. the if () in question is compiled out.
Hmm, 2.5.x is supposed to guarantee most (if not all) of the preconditions the code here is trying to (re)establish. Probably the only use of not ripping out the 4GB spanning code and segment count checks is to keep driver versions synched. As it stands, this doesn't compile and if ever invoked the code not needed for 2.5 will not behave as expected (though thankfully a nop). Maybe a (shudder) #ifdef to rip out the overhead for 2.5 should be added esp. as post gcc-3.0 probably can't compile earlier kernels anyway.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |