freebios/src/arch/i386/lib/pirq_routing.c - Added verification of the copy of pirq routing table.
-Andrew
andrew, what's the current state of your pirq problems?
I am going to cvs update next week but not this week, too much SC02 stuff to do.
ron
Ron,
andrew, what's the current state of your pirq problems? I am going to cvs update next week but not this week, too much SC02 stuff to do.
On pcm-5823, 1. pirq routing table failed to copy when COMPRESS is on 2. When COMPRESS is off, pirq routing table also failed to copy to 0xf0000. However, Linux kernel is able to find the pirq routing table at 0xc00f6c90.
These problem doesn't happen to winfast 6300.
, but it failed
On Thu, 14 Nov 2002, Andrew Ip wrote:
On pcm-5823,
- pirq routing table failed to copy when COMPRESS is on
This one is weird. Oh, wait, I get it, see below. This one is not weird, it makes sense now.
- When COMPRESS is off, pirq routing table also failed to copy to 0xf0000.
However, Linux kernel is able to find the pirq routing table at 0xc00f6c90.
I get this now. So in other words, it is not getting copied, but the kernel is finding the table in FLASH since it is uncompressed. Now I wonder why linuxbios would try to copy to f0000, since that is a FLASH area. I think it is because linuxbios is now thinking that the memory hole at 0xf0000 is not there, and that it is dram. We need to see what assumptions linuxbios is making about the memory hole at 0xf0000. Something has changed recently.
The reason it won't work with COMPRESS: The PIRQ table is compressed, hence unreadable; the copy to 0xf0000 fails because it has no memory. So, in the end, Linux can not find the table in RAM or in FLASH.
It is a good thing in the long term to make the 0xf0000 region RAM, but something has obviously gone wrong somewhere.
I will have to see how the MTRRs are set on the pcm-5823.
ron
On Thu, 2002-11-14 at 13:11, Ronald G. Minnich wrote:
I get this now. So in other words, it is not getting copied, but the kernel is finding the table in FLASH since it is uncompressed. Now I wonder why linuxbios would try to copy to f0000, since that is a FLASH area. I think it is because linuxbios is now thinking that the memory hole at 0xf0000 is not there, and that it is dram. We need to see what assumptions linuxbios is making about the memory hole at 0xf0000. Something has changed recently.
The reason LinuxBIOS copying the table to 0xf0000 is that the kernel will search the table in certain memory regions which includes 643rd Kb and 0xf0000-1Mb. For uncompressed LinuxBIOS in Flash rom, the copy is not neceressary since the table is uncompressed and in the memory region under kernel's search. For DoC, we have to make the F segment mapped to DRAM and copy the table to F segment. I have no idea what to do if you are using a compressed LinuxBIOS with Flash Rom.
Ollie
ollie lho ollie@sis.com.tw writes:
On Thu, 2002-11-14 at 13:11, Ronald G. Minnich wrote:
I get this now. So in other words, it is not getting copied, but the kernel is finding the table in FLASH since it is uncompressed. Now I wonder why linuxbios would try to copy to f0000, since that is a FLASH area. I think it is because linuxbios is now thinking that the memory hole at 0xf0000 is not there, and that it is dram. We need to see what assumptions linuxbios is making about the memory hole at 0xf0000. Something has changed recently.
The reason LinuxBIOS copying the table to 0xf0000 is that the kernel will search the table in certain memory regions which includes 643rd Kb and 0xf0000-1Mb. For uncompressed LinuxBIOS in Flash rom, the copy is not neceressary since the table is uncompressed and in the memory region under kernel's search. For DoC, we have to make the F segment mapped to DRAM and copy the table to F segment. I have no idea what to do if you are using a compressed LinuxBIOS with Flash Rom.
With LinuxBIOS in Flash rom it should be just as safe to make the F segment mapped to DRAM as it is in the DOC case. Until memory is setup we run out of the Rom chip but after that the two cases are effectively identical. But if you are going to use compression, and be more space efficient in the Rom chip the F segment needs to be setup as RAM or you cannot setup the pirq table.
Given the slow speed of flash rom chips i suspect the decompressor will actually speed things up a bit.
Eric
On 14 Nov 2002, Eric W. Biederman wrote:
With LinuxBIOS in Flash rom it should be just as safe to make the F segment mapped to DRAM as it is in the DOC case. Until memory is setup we run out of the Rom chip but after that the two cases are effectively identical.
that's true in most cases. But on some systems (SBC 710) it will be required that we have a hole at 0xd0000, and I can imagine other badly designed hardware that will continue to require a gap at 0xf0000. In other words, the memory gap (or at least pieces of it) is not going away in all cases -- yet.
It would be nice to eliminate the memory hole, it has just not proven to be as easy to kill it as we hoped. So we will have to preserve the ability to operate with the memory hole in place and pointing to flash at 0xf0000, until we know for certain that for 100% of our platforms we can make that area covered by DRAM.
What this means is that the compressor can not be used for every platform.
I'm not even sure yet we can turn off the memory hole on the Geode chipset -- it's on the TODO list as of today.
thanks
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
It would be nice to eliminate the memory hole, it has just not proven to be as easy to kill it as we hoped. So we will have to preserve the ability to operate with the memory hole in place and pointing to flash at 0xf0000, until we know for certain that for 100% of our platforms we can make that area covered by DRAM.
What this means is that the compressor can not be used for every platform.
I'm not even sure yet we can turn off the memory hole on the Geode chipset -- it's on the TODO list as of today.
I've just been skimming the list lately, so what is this discussion about?
On the geode it's possible to map RAM into the whole region from 0xa0000 to 0xfffff. IIRC the memory at 0xa0000 is a bit special since it's usually remapped to somewhere in the GX_BASE region and used to store the VSA BIOS, but if you aren't using VSA at all, it can be used as normal memory.
/Christer
On 14 Nov 2002, Christer Weinigel wrote:
I've just been skimming the list lately, so what is this discussion about?
Some linuxbios instances are failing on the pirq_copy since the pirq_copy function is assuming that the memory at 0xf0000 is RAM. This assumption is dicey for most of our motherboards since we have not verified for each and every chipset that 0xf0000 can be mapped to ram (although it is hard to imagine it is not possible). But in many cases we have not set the mapping to RAM and that is an issue.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On 14 Nov 2002, Christer Weinigel wrote:
I've just been skimming the list lately, so what is this discussion about?
Some linuxbios instances are failing on the pirq_copy since the pirq_copy function is assuming that the memory at 0xf0000 is RAM. This assumption is dicey for most of our motherboards since we have not verified for each and every chipset that 0xf0000 can be mapped to ram (although it is hard to imagine it is not possible). But in many cases we have not set the mapping to RAM and that is an issue.
Ah, ok. When I did the port to the SC2200 I skirted the whole issue by not setting up a pirq table, instead I just wrote the correct values into the interrupt line registers of each PCI device.
I'll try to get the time to look at LinuxBIOS again and set up a RAM mapping for 0xf0000. It's just a few bits in a register that has to be set.,
/Christer
On 15 Nov 2002, Christer Weinigel wrote:
Ah, ok. When I did the port to the SC2200 I skirted the whole issue by not setting up a pirq table, instead I just wrote the correct values into the interrupt line registers of each PCI device.
we're going to have to start doing this, Eric Biederman and others are right. It doesn't look like Linux is going to get fixed in all cases and I have not seen a lot of good IRQ setup code in other OSes either.
Oh, well, so much for "Let Linux do it". I'll start bashing something together.
For the "f000 as memory" setup, send the patch to me and I'll test it too.
ron
we're going to have to start doing this, Eric Biederman and others are right. It doesn't look like Linux is going to get fixed in all cases and I have not seen a lot of good IRQ setup code in other OSes either.
Oh, well, so much for "Let Linux do it". I'll start bashing something together.
Just want to confirm winfast 6300 with flash rom. It behaves as the same as pcm-5823. Looks like copy pirq table only works with DOC. LinuxBIOS with flash rom doesn't need copy pirq table and probably won't work with CONFIG_COMPRESS=1.
-Andrew
On Fri, 15 Nov 2002, Andrew Ip wrote:
Just want to confirm winfast 6300 with flash rom. It behaves as the same as pcm-5823. Looks like copy pirq table only works with DOC. LinuxBIOS with flash rom doesn't need copy pirq table and probably won't work with CONFIG_COMPRESS=1.
the problem is confirmed then.
- Not all mainboard ports are mapping f0000 as RAM.
- It will not be possible to get rid of the memory hole (a0000-fffff) for all ports; some piece of this hole will always be required for some mainboards, at least that is what we have seen so far.
- You can not combine COMPRESS linuxbios with certain mainboards that use FLASH as the IRQ table will not get copied correctly
Conclusions: We will always need the option to turn COMPRESS off, at least until we verify that all our supported platforms can turn F0000 into RAM. But, again, I don't think this is going to be impossible, just a lot of work ;-)
Here are the combinations as I see them:
F0000 is FLASH F0000 is RAM can you COMPRESS? NO YES
Can you NOT COMPRESS? YES YES
Do you have to copy PIRQ? NO YES
did I miss anything?
ron
NEC Machine Again Leads Speed Ranks
SAN FRANCISCO, Nov. 14 The twice-a-year ranking of the world's fastest computers, to be announced Friday at a supercomputer industry conference in Baltimore, will include two new entrants based on personal computers, including one cluster of machines running the Linux operating system.
.... The Linux-based supercomputer is the NetworkX/Quadrics machine at Lawrence Livermore National Laboratories in California. It ranked fifth, and it is based on Intel microprocessors used in the personal computer world. ....
-Steve
On Fri, 15 Nov 2002, Steve M. Gehlbach wrote:
.... The Linux-based supercomputer is the NetworkX/Quadrics machine at Lawrence Livermore National Laboratories in California. It ranked fifth, and it is based on Intel microprocessors used in the personal computer world. ....
note that is not us, it is our sister lab in Ca. But it is a Linux NetworX-build, linuxbios system. Neat stuff.
ron
Christer, I followed the back-and-forth between you and Alan Cox on the PIRQ mess in 2.4.19. I get the impression he is not planning to fix it. Can you maybe fill us in on what is going on? Are we stuck with broken Linux code for good?
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
Christer, I followed the back-and-forth between you and Alan Cox on the PIRQ mess in 2.4.19. I get the impression he is not planning to fix it. Can you maybe fill us in on what is going on? Are we stuck with broken Linux code for good?
No idea. But Alan is usually reasonable, so if most people that have a Geode system can dump their pirq tables and show him that more systems are broken than fixed by his change he'll probably fix it.
I could coordinate this if you want to. How do you dump the PIRQ table from a running system? I assume there is some kind of tool for this? Please mail PIRQ dumps to me and I'll try to bother Alan about it. :-)
/Christer
I could coordinate this if you want to. How do you dump the PIRQ table from a running system? I assume there is some kind of tool for this? Please mail PIRQ dumps to me and I'll try to bother Alan about
You can run free/util/getpir under a normal bios, then you can get irq_tables.c which is the table.
-Andrew
"Ronald G. Minnich" rminnich@lanl.gov writes:
It is a good thing in the long term to make the 0xf0000 region RAM, but something has obviously gone wrong somewhere.
I will have to see how the MTRRs are set on the pcm-5823.
This should not be an mtrr thing. It is at the chipset level where this decision is made unless you are on an Athlon in which case it is set in the cpu.
Eric
On 14 Nov 2002, Eric W. Biederman wrote:
This should not be an mtrr thing. It is at the chipset level where this decision is made unless you are on an Athlon in which case it is set in the cpu.
yes, my mistake.
ron
On Thu, 14 Nov 2002, Andrew Ip wrote:
These problem doesn't happen to winfast 6300.
Hmm, the copy to 0xf0000 succeeds on the winfast?
I wish I had all of the motherboards we support in a lab for regression tests. Oh well. This is interesting.
ron
Ron,
These problem doesn't happen to winfast 6300.
Hmm, the copy to 0xf0000 succeeds on the winfast?
It does work.
-Andrew
On Thu, 2002-11-14 at 13:13, Ronald G. Minnich wrote:
On Thu, 14 Nov 2002, Andrew Ip wrote:
These problem doesn't happen to winfast 6300.
Hmm, the copy to 0xf0000 succeeds on the winfast?
I wish I had all of the motherboards we support in a lab for regression tests. Oh well. This is interesting.
I did not test the compressed linuxbios option. LinuxBIOS for winfast6300 does map 0xF0000 as DRAM (on all case ?).
Ollie
-
Andrew Ip -
Christer Weinigel -
ebiederman＠lnxi.com -
ollie lho -
Ronald G. Minnich -
Steve M. Gehlbach