Eric, how much heartburn is there if we set the default value of CONFIG_COMPRESS to 0?
I've just hit another platform where it is trouble. At this point I believe there are only a small number of platforms for which it works well if set to 1. Do you have any issues if we have it default to 0, not 1, so it is only enabled on platforms it is "known good" on?
thanks
ron
On a related note:
Anyone have a problem with me moving statically generated PIRQ tables from the compressed section to the uncompressed session?
On Monday 18 November 2002 12:05, Ronald G. Minnich wrote:
Eric, how much heartburn is there if we set the default value of CONFIG_COMPRESS to 0?
I've just hit another platform where it is trouble. At this point I believe there are only a small number of platforms for which it works well if set to 1. Do you have any issues if we have it default to 0, not 1, so it is only enabled on platforms it is "known good" on?
thanks
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Mon, 18 Nov 2002, Kevin Hester wrote:
Anyone have a problem with me moving statically generated PIRQ tables from the compressed section to the uncompressed session?
I've thought about this, but in the long term we don't want to do it.
Long term, we want to get rid of the memory hole at 0xf0000 and have DRAM there. The kernel searches there, however. I think it makes sense for a given motherboard to just require that we get rid of the memory hole and then COMPRESS will work with no further hacking.
ron
On Tue, 2002-11-19 at 04:50, Ronald G. Minnich wrote:
On Mon, 18 Nov 2002, Kevin Hester wrote:
Anyone have a problem with me moving statically generated PIRQ tables from the compressed section to the uncompressed session?
I've thought about this, but in the long term we don't want to do it.
Long term, we want to get rid of the memory hole at 0xf0000 and have DRAM there. The kernel searches there, however. I think it makes sense for a given motherboard to just require that we get rid of the memory hole and then COMPRESS will work with no further hacking.
Ron, If it is really a HW limitation, how does this "long term" thing going to happen ?? Unless you can redesign the HW in some way.
Ollie
On 19 Nov 2002, ollie lho wrote:
If it is really a HW limitation, how does this "long term" thing going to happen ?? Unless you can redesign the HW in some way.
for every motherboard and chipset I have seen to date, it is possible to make the f0000 area RAM. Ollie, are there systems for which this is not possible?
ron
If it is really a HW limitation, how does this "long term" thing going to happen ?? Unless you can redesign the HW in some way.
for every motherboard and chipset I have seen to date, it is possible to make the f0000 area RAM. Ollie, are there systems for which this is not possible?
ron
I would be really surprised if there is a motherboard in use that does not have the ability to turn on ram at 0xf0000. If someone is having problems with ram at this location, surely it must be an issue of setting a bit in a chipset register somewhere.
-Steve
On Mon, 18 Nov 2002, Kevin Hester wrote:
Anyone have a problem with me moving statically generated PIRQ tables from the compressed section to the uncompressed session?
kevin, if you really want this, it has to be #ifdef via a CONFIG option.
But, if you really want it, send me patches.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
Eric, how much heartburn is there if we set the default value of CONFIG_COMPRESS to 0?
I've just hit another platform where it is trouble. At this point I believe there are only a small number of platforms for which it works well if set to 1. Do you have any issues if we have it default to 0, not 1, so it is only enabled on platforms it is "known good" on?
My gut reaction says to keep the default as is, and just change it for known problem boards.
Long term we want memory at 0xf0000.
In addition we have another way to solve this problem. Write the code to assign irqs, given a pirq table. And that is something long term we need to do as well.
But I guess it depends on where we are on the stabilization curve. If this was code in a stable series I would say to disable the compression by default. Since this seems to be a more or less development series, and problems are caused not by the compression but by a side effect of the compression I recommend not hiding the problems.
Eric
On Tue, 2002-11-19 at 05:25, Eric W. Biederman wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
Eric, how much heartburn is there if we set the default value of CONFIG_COMPRESS to 0?
I've just hit another platform where it is trouble. At this point I believe there are only a small number of platforms for which it works well if set to 1. Do you have any issues if we have it default to 0, not 1, so it is only enabled on platforms it is "known good" on?
My gut reaction says to keep the default as is, and just change it for known problem boards.
Long term we want memory at 0xf0000.
In addition we have another way to solve this problem. Write the code to assign irqs, given a pirq table. And that is something long term we need to do as well.
If the problem only occurs for IRQ table, why do we copy them to EBDA instead of 0xf0000 ?? Is the 639kB used for other purpose ??
Ollie
On Tue, 2002-11-19 at 09:01, ollie lho wrote:
On Tue, 2002-11-19 at 05:25, Eric W. Biederman wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
Eric, how much heartburn is there if we set the default value of CONFIG_COMPRESS to 0?
I've just hit another platform where it is trouble. At this point I believe there are only a small number of platforms for which it works well if set to 1. Do you have any issues if we have it default to 0, not 1, so it is only enabled on platforms it is "known good" on?
My gut reaction says to keep the default as is, and just change it for known problem boards.
Long term we want memory at 0xf0000.
In addition we have another way to solve this problem. Write the code to assign irqs, given a pirq table. And that is something long term we need to do as well.
If the problem only occurs for IRQ table, why do we copy them to EBDA instead of 0xf0000 ?? Is the 639kB used for other purpose ??
OOPS, I am wrong. It is MP table that is searched in 639kB not PIRQ table (although they can be used for the same purpose). I must done too much debug in this Intel Hyperthread/APIC stuff.
Ollie
-
ebiederman＠lnxi.com -
Kevin Hester -
ollie lho -
Ronald G. Minnich -
Steve M. Gehlbach