-aa 3.5GB Patch Questions
I've been using Andrea's 2.4.18rc4aa1 patches applied to a generic 2.4.18 kernel running on Intel 32-bit machines with 4GB of memory and usually some sort of Serversorks chipset with 1-2 CPUs of various speeds with great success for almost 6 months now. The primary base has been a SuSE 7.2 distro but others are now being tried, including Slackware 8.1 and RH 7.[23]. The principal reason for this was to use the 00_3.5G-address-space-4 feature. I apply all patches in the directory and have not seen a kernel failure yet with thousands of hours of "big process" CPU time logged across many machines. I consider this to be a pretty stable combination of kernel and patches for what I need.
RH's 2.96 gcc compiles fine but blows up or slows to a crawl (not unexpected) when big jobs are run and the machine starts paging. I've fixed this by putting a 2.95.3 gcc on the machine. I'll leave the editorial comments about 2.96-RH to others.
I'm trying to write some sanitized procedures which will allow me to pass this on to others. Non-2.96 distros (everyone except RH and Mandrake, AFAIK) have run fine without issues, mainly because they have a pretty stable 2.95 compiler included.
I will assume that a gcc 2.95 retrofit is required to make the -aa patches work on RH 7.[23].
What's the correct way to retrofit a 2.95.3 compiler onto an RH 7.[23] distro?
Is it OK to just load it into /usr/local and build it?
Does it require 'make bootstrap' to be entirely santized? Are there other GNU packages that I should be including with the gcc retrofit?
-ms
Just a sanity check, are you using the current (errata) red hat gcc?
Just asking since 2.96 is all I use, and the -aa kernels are completely stable here - do you have a test workload to allow me to try and duplicate your bug?
Joe
Quoted 41 lines · Mitch Sako
I've been using Andrea's 2.4.18rc4aa1 patches applied to a generic 2.4.18 kernel running on Intel 32-bit machines with 4GB of memory and usually some sort of Serversorks chipset with 1-2 CPUs of various speeds with great success for almost 6 months now. The primary base has been a SuSE 7.2 distro but others are now being tried, including Slackware 8.1 and RH 7.[23]. The principal reason for this was to use the 00_3.5G-address-space-4 feature. I apply all patches in the directory and have not seen a kernel failure yet with thousands of hours of "big process" CPU time logged across many machines. I consider this to be a pretty stable combination of kernel and patches for what I need.
RH's 2.96 gcc compiles fine but blows up or slows to a crawl (not unexpected) when big jobs are run and the machine starts paging. I've fixed this by putting a 2.95.3 gcc on the machine. I'll leave the editorial comments about 2.96-RH to others.
I'm trying to write some sanitized procedures which will allow me to pass this on to others. Non-2.96 distros (everyone except RH and Mandrake, AFAIK) have run fine without issues, mainly because they have a pretty stable 2.95 compiler included.
I will assume that a gcc 2.95 retrofit is required to make the -aa patches work on RH 7.[23].
What's the correct way to retrofit a 2.95.3 compiler onto an RH 7.[23] distro?
Is it OK to just load it into/usr/localand build it?
Does it require 'make bootstrap' to be entirely santized? Are there other GNU packages that I should be including with the gcc retrofit?(quoted diff) +0
-2-ms -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I'm (re)installing all of the erratta now on a 7.2 machine. What RH are you running? Unfortunately, I don't have a non-proprietary testcase to give out because the one I have contains proprietary source code.
Mitch
Quoted 10 lines · J Sloan
Just a sanity check, are you using the current (errata) red hat gcc?
Just asking since 2.96 is all I use, and the -aa kernels are completely stable here - do you have a test workload to allow me to try and duplicate your bug?
Joe
Well, 7.1, 7,2 and 7.3 -
all running -aa compiled with latest errata gcc 2.96
Joe
Quoted 20 lines · Mitch Sako
I'm (re)installing all of the erratta now on a 7.2 machine. What RH are you running? Unfortunately, I don't have a non-proprietary testcase to give out because the one I have contains proprietary source code.
Mitch
Quoted 10 lines · J Sloan
Just a sanity check, are you using the current (errata) red hat gcc?
Just asking since 2.96 is all I use, and the -aa kernels are completely stable here - do you have a test workload to allow me to try and duplicate your bug?
Joe