Good morning all:
We rely on being able to manually set entries in /proc/mtrr for our
proprietary PCI frame grabbing hardware to go into PCI burst mode and
run faster. We've always been on Dell PowerEdge 1800 hardware running
FC3 (stock) with the 2.6.16.16 kernel. Dell has changed their product
line on us and we're now forced to use a Dell Precision 490. FC3 won't
load on this new box because of newer hardware so we're using FC5 but
we're using the exact same 2.6.16.16 kernel.
On the Precision 490 workstation we can no longer control the /proc/mtrr
settings manually and in fact, the /proc/mtrr file even looks totally
different.
Here is a /proc/mtrr from a Dell PE1800 running FC3 with a 2.6.16.16
kernel that works just fine
:
Before we turn on PCI burst for our hardware:
reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xf0000000 (3840MB), size= 16MB: write-combining, count=1
After we turn on PCI burst for our hardware:
reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xf0000000 (3840MB), size= 16MB: write-combining, count=1
reg02: base=0xb8000000 (2944MB), size= 128MB: write-back, count=1
And this is good on a Dell PE1800/FC3/2.6.16.16.
However, on the Dell Precision 490 workstation/FC5/2.6.16.16 kernel the
base /proc/mtrr file looks like this:
reg00: base=0x00000000 ( 0MB), size=65536MB: write-back, count=1
reg01: base=0x3ff00000 (1023MB), size= 1MB: uncachable, count=1
reg02: base=0x40000000 (1024MB), size=1024MB: uncachable, count=1
reg03: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
reg04: base=0xff0000000 (65280MB), size= 256MB: uncachable, count=1
And when we try and change anything so our cards go into PCI burst mode,
there is no apparent change.
Both the Dell PE1800 and the Precision 490 are using the same Xeon 5130
CPU but with different motherboards.
There is no problem running the code on FC5 and no error is given; it
just doesn't change /proc/mtrr and we run extremely slow!
What am I missing here? Not being able to burst on the PCI bus is
killing us!
Thanks!
-brian
Brian D. McGrew { brian@xxxxxxxxxxxxx ||
brian@xxxxxxxxxxxxxxxxxxx }
--
> Do not read this email while waxing that cat!
