Messages in this thread | | | Date | Fri, 07 Nov 1997 21:13:50 +0100 | From | Andre Derrick Balsa <> | Subject | Re: Cyrix patch : Proposal? |
| |
Hi Nigel,
Nigel Metheringham wrote: > > linker@nightshade.z.ml.org said: > } A very good post. I would assume that you approve of minor patching so > } that cpuinfo displays the correct information? > > If this was done then userlevel tools could twiddle happily knowing that > they had the right CPU to play with.
This is correct, but it's not a good enough reason to implement a patch: it's much easier to write a good user-level utility that will correctly detect the CPU type, revision, speed, etc... than to put all of this in the kernel.
IMHO there are 2 valid reasons for kernel patching when it comes to Cyrix CPUs:
1) If the kernel will either not boot at all, or will boot but setup its working parameters incorrectly (e.g. wrong bogomips/udelay settings may cause problems with some drivers that use udelay for timing loops). This was a point I discussed at length with Pavel Machek.
2) There is a feature that *must* be set in the kernel, because it affects basic kernel operation (e.g. VSPM, but I have already explained that VSPM brings nothing in terms of performance, and is a one-of-a-kind implementation of paging).
These two issues are adressed by a very short patch available at: http://www.tux.org/~balsa/linux/cyrix/Cyrix.patch This patch adds less than 50 bytes to the executable and about a dozen lines to the source code. It's totally inocuous on non-6x86 systems.
I would like to have more linux users download and test it. It will patch against 2.0.29, 2.0.30 and 2.0.31. I haven't tried patching against 2.1.6x, but it should patch OK with little or no changes, since it's so simple. It's a subset of the 2.1.39 patch with some small modifications.
I am still trying to sort out a nasty oops that occurs on my 6x86MX rev. 1.3, but the above patch also contains a one-line workaround for the problem. As soon as the cause of the oops will have been exactly established and an adequate solution will have been found, I'll propose a patch for inclusion in the VGER kernel source.
Cheers,
======================================================== Andrew D. Balsa Home Page: http://www.tux.org/~balsa andrewbalsa@usa.net ========================================================
| |