> Sounds like a true-to-God bug. Possibly in the form of incorrect MTRR
> settings. Make sure you enable MTRR support.
MTRR is enabled - here's the dump from /proc/mtrr:
reg00: base=0xc000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x ( 0MB), size=4096MB: write-back, c
Hi Paul,
> 2) Other block I/O output (eg dd if=/dev/zero of=/dev/sdi bs=4M) also
> run very slowly
What do you notice when running "top" and doing the above?
Does the "buff" value grow high (+700MB), with high CPU usage?
If so, I think this might be down to nr_free_buffer_pages().
This fu
On 15 Jan 2001, Linus Torvalds wrote:
> The performance problem is _probably_ due to the kernel having to
> double-buffer the IO requests, coupled with bad MTRR settings (ie
> memory above the 4GB range is probably marked as non-cacheable or
> something, which means that you'll get really bad pe
In article <[EMAIL PROTECTED]>,
Paul Hubbard <[EMAIL PROTECTED]> wrote:
>
>We're having some problems with the 2.4.0 kernel on our SGI 1450, and
>were hoping for some help.
> The box is a quad Xeon 700/2MB, with 4GB of memory, ServerSet III HE
>chipset, RH6.1 (slightly modified for local configur
We're having some problems with the 2.4.0 kernel on our SGI 1450, and
were hoping for some help.
The box is a quad Xeon 700/2MB, with 4GB of memory, ServerSet III HE
chipset, RH6.1 (slightly modified for local configuration) distribution.
a) If we compile the kernel with no high memory support,
5 matches
Mail list logo
