On Thu, 12 Oct 2000, Keith Owens wrote:
> On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
> Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> >one correction -- it was "down and up the interface" that did the trick
> >and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
> >formulated
On Thu, 12 Oct 2000, Keith Owens wrote:
On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
Tigran Aivazian [EMAIL PROTECTED] wrote:
one correction -- it was "down and up the interface" that did the trick
and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
formulated as "when
On Fri, 13 Oct 2000, Richard Guenther wrote:
> On Fri, 13 Oct 2000, Rik van Riel wrote:
> > On Thu, 12 Oct 2000, Richard Guenther wrote:
> >
> > > I reported this BUG on a few days ago but got no response - happens
> > > on UP with only 32M ram, too. (see below). Also note the second
> > > BUG
On Fri, 13 Oct 2000, Rik van Riel wrote:
> On Thu, 12 Oct 2000, Richard Guenther wrote:
>
> > I reported this BUG on a few days ago but got no response - happens
> > on UP with only 32M ram, too. (see below). Also note the second
> > BUG at vmscan.c:538 which I believe never saw reported again.
On Thu, 12 Oct 2000, Richard Guenther wrote:
> I reported this BUG on a few days ago but got no response - happens
> on UP with only 32M ram, too. (see below). Also note the second
> BUG at vmscan.c:538 which I believe never saw reported again.
> > Oct 11 16:05:26 hilbert36 kernel: kernel BUG
Hi,
On Thu, Oct 12, 2000 at 02:19:27PM +0100, Tigran Aivazian wrote:
> Having done a few more reboots I got more info -- one of the eepro100
> interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0
> ; ifup eth0 does help.
Tigran, please check if you have any driver's
Hi,
On Thu, Oct 12, 2000 at 02:19:27PM +0100, Tigran Aivazian wrote:
Having done a few more reboots I got more info -- one of the eepro100
interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0
; ifup eth0 does help.
Tigran, please check if you have any driver's messages,
On Thu, 12 Oct 2000, Richard Guenther wrote:
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
Oct 11 16:05:26 hilbert36 kernel: kernel BUG at
On Fri, 13 Oct 2000, Rik van Riel wrote:
On Thu, 12 Oct 2000, Richard Guenther wrote:
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
On Fri, 13 Oct 2000, Richard Guenther wrote:
On Fri, 13 Oct 2000, Rik van Riel wrote:
On Thu, 12 Oct 2000, Richard Guenther wrote:
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538
} Hi,
}
} > How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
} > __builtin_return_address() yields garbage. Does anybody have a generic
} > solution to this problem, other than "compile with frame pointers"? Or is
} > it fixed in newer versions of gcc?
}
} Are you
Hi,
> How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
> __builtin_return_address() yields garbage. Does anybody have a generic
> solution to this problem, other than "compile with frame pointers"? Or is
> it fixed in newer versions of gcc?
Are you sure? I just I
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> The idea is that when it is sure that _only one_ (or some) CPU will access
> a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to
> contain an entry for that area.
>
> Although there are (must be) common MTRR entries for the
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On 12 Oct 2000, David Wragg wrote:
> > Ok. I'll wait for feedback from Tigran, and if I don't get anything
> > negative I'll submit to Linus. The 2.2 version of my patch fixes
> > problems for other people, VA Linux have included it in their kernel
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> I came up with an idea. The MTRRs are per-cpu things.
> Ingo Molnar's IRQ affinity code helps binding certain
> IRQ sources to certain CPUs.
They are implemented as per-cpu things but the Intel manuals say that
all cpus should have the same MTRR
On 12 Oct 2000, David Wragg wrote:
> Ok. I'll wait for feedback from Tigran, and if I don't get anything
> negative I'll submit to Linus. The 2.2 version of my patch fixes
> problems for other people, VA Linux have included it in their kernel
> for a while with no problems that have been
Richard Gooch <[EMAIL PROTECTED]> writes:
> David Wragg writes:
> > mtrr.c is broken for machines with >=4GB of memory (or less than 4GB,
> > if the chipset reserves an addresses range below 4GB for PCI).
> >
> > The patch against 2.4.0-test9 to fix this is below.
> >
> > Richard: Is there a
Hello,
Ok, I despaired a bit about mtrrs on the Linux side and went into BIOS and
started playing with the cache settings there. The change that fixed the
problem was to disable all "area CXXX-> : cached". Now, I have a really
fast quad Xeon 6G RAM with consistently failing eepro100
interface.
On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>one correction -- it was "down and up the interface" that did the trick
>and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
>formulated as "when highmem is enabled one or both eepro100
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On Thu, 12 Oct 2000, Tigran Aivazian wrote:
>
> > On Wed, 11 Oct 2000, Linus Torvalds wrote:
> > > What happens if MTRR support is entirely disabled?
> >
> > If MTRR support is disabled then both eepro100 interfaces work fine but
> > the system is
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
>
> > echo "base=0 size=0x1 type=write-back" >/proc/mtrr
> > echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr
> > echo "base=0xfe00 size=0x80 type=write-combining"
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote:
> I came up with an idea. The MTRRs are per-cpu things.
> Ingo Molnar's IRQ affinity code helps binding certain
> IRQ sources to certain CPUs.
>
> What if the MTRR driver allows per-CPU settings, maybe only on
> uncached areas?
> On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
>
> > echo "base=0 size=0x1 type=write-back" >/proc/mtrr
this line immediately locks up the machine. But I want to understand where
did you get base=0 and size=0x1 from? Shouldn't it be
base=0x10 and size=0xfccf according
On Thu, 12 Oct 2000 10:45:11 +0100 (BST),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>It would be nice if /proc/mtrr showed eip of
>the caller who set up the entry :)
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Linus Torvalds wrote:
> > What happens if MTRR support is entirely disabled?
>
> If MTRR support is disabled then both eepro100 interfaces work fine but
> the system is still 40x slower. This is the entire bootlog of
>
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> Look at the e820 map in the boot log, mark those areas
> as write-back and tell me what happens.
Here is e820 map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820:
Hi,
someone looked at the XEON errata already, perhaps one can find the problem there?
Just in case.
G16 seems to have something to do with it ... But there are others also. I´ll boot
linux and look into the sources ...
Cheers Markus
Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Linus
Hi!
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
Richard.
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
On Thu, 12 Oct 2000, Matti Aarnio wrote:
> > CPU0: Intel Pentium III (Cascades) stepping 01
> > CPU1: Intel Pentium III (Cascades) stepping 01
> > CPU2: Intel Pentium III (Cascades) stepping 01
> > CPU3: Intel Pentium III (Cascades) stepping 01
> > Total of 4 processors activated (5606.60
On Thu, Oct 12, 2000 at 09:21:00AM +0100, Tigran Aivazian wrote:
> If MTRR support is disabled then both eepro100 interfaces work fine but
> the system is still 40x slower. This is the entire bootlog of
> 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
> output
>
> Two
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem +
On Wed, 11 Oct 2000, Linus Torvalds wrote:
What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem +
On Thu, Oct 12, 2000 at 09:21:00AM +0100, Tigran Aivazian wrote:
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
output
Two
On Thu, 12 Oct 2000, Matti Aarnio wrote:
CPU0: Intel Pentium III (Cascades) stepping 01
CPU1: Intel Pentium III (Cascades) stepping 01
CPU2: Intel Pentium III (Cascades) stepping 01
CPU3: Intel Pentium III (Cascades) stepping 01
Total of 4 processors activated (5606.60 BogoMIPS).
Hi!
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
Richard.
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Rik van Riel wrote:
Hi,
someone looked at the XEON errata already, perhaps one can find the problem there?
Just in case.
G16 seems to have something to do with it ... But there are others also. I´ll boot
linux and look into the sources ...
Cheers Markus
Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Linus
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
Look at the e820 map in the boot log, mark those areas
as write-back and tell me what happens.
Here is e820 map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820:
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Linus Torvalds wrote:
What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
On Thu, 12 Oct 2000 10:45:11 +0100 (BST),
Tigran Aivazian [EMAIL PROTECTED] wrote:
It would be nice if /proc/mtrr showed eip of
the caller who set up the entry :)
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does anybody
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote:
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
What if the MTRR driver allows per-CPU settings, maybe only on
uncached areas? Of
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
echo "base=0 size=0x1 type=write-back" /proc/mtrr
echo "base=0x1 size=0x8000 type=write-back" /proc/mtrr
echo "base=0xfe00 size=0x80 type=write-combining"
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Linus Torvalds wrote:
What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x
On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
Tigran Aivazian [EMAIL PROTECTED] wrote:
one correction -- it was "down and up the interface" that did the trick
and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
formulated as "when highmem is enabled one or both eepro100
Hello,
Ok, I despaired a bit about mtrrs on the Linux side and went into BIOS and
started playing with the cache settings there. The change that fixed the
problem was to disable all "area CXXX- : cached". Now, I have a really
fast quad Xeon 6G RAM with consistently failing eepro100
interface.
Richard Gooch [EMAIL PROTECTED] writes:
David Wragg writes:
mtrr.c is broken for machines with =4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB for PCI).
The patch against 2.4.0-test9 to fix this is below.
Richard: Is there a reason you haven't
On 12 Oct 2000, David Wragg wrote:
Ok. I'll wait for feedback from Tigran, and if I don't get anything
negative I'll submit to Linus. The 2.2 version of my patch fixes
problems for other people, VA Linux have included it in their kernel
for a while with no problems that have been reported
Boszormenyi Zoltan [EMAIL PROTECTED] writes:
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
They are implemented as per-cpu things but the Intel manuals say that
all cpus should have the same MTRR
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On 12 Oct 2000, David Wragg wrote:
Ok. I'll wait for feedback from Tigran, and if I don't get anything
negative I'll submit to Linus. The 2.2 version of my patch fixes
problems for other people, VA Linux have included it in their kernel
for
Boszormenyi Zoltan [EMAIL PROTECTED] writes:
The idea is that when it is sure that _only one_ (or some) CPU will access
a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to
contain an entry for that area.
Although there are (must be) common MTRR entries for the main
Hi,
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does anybody have a generic
solution to this problem, other than "compile with frame pointers"? Or is
it fixed in newer versions of gcc?
Are you sure? I just I tried
} Hi,
}
} How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
} __builtin_return_address() yields garbage. Does anybody have a generic
} solution to this problem, other than "compile with frame pointers"? Or is
} it fixed in newer versions of gcc?
}
} Are you sure?
David Wragg writes:
> Tigran Aivazian <[EMAIL PROTECTED]> writes:
> > b) it detects all memory correctly but creates a write-back mtrr only for
> > the first 2G, is this normal?
>
> mtrr.c is broken for machines with >=4GB of memory (or less than 4GB,
> if the chipset reserves an addresses range
On Wed, 11 Oct 2000, Rik van Riel wrote:
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > > On Wed, 11 Oct 2000, Rik van Riel wrote:
> > > > Could you send me the backtrace of one of the cases where
> > > > you hit the bug ?
> >
> > just to add -- I was following Alan Cox's suggestion of
> >
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> it works fine then. Kernel compiles in 68 seconds as it should. Shall I
> keep incrementing mem= to see what happens next...
I suspect fixing the mtrrs on the machine will fix this problem, as a
38-40 times slowdown on a machine that isn't swapping
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > On Wed, 11 Oct 2000, Rik van Riel wrote:
> > > Could you send me the backtrace of one of the cases where
> > > you hit the bug ?
>
> just to add -- I was following Alan Cox's suggestion of
> incrementing "mem=N" and finding the value where the
Tigran Aivazian <[EMAIL PROTECTED]> writes:
> b) it detects all memory correctly but creates a write-back mtrr only for
> the first 2G, is this normal?
mtrr.c is broken for machines with >=4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB for PCI).
The patch
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > Could you send me the backtrace of one of the cases where
> > you hit the bug ?
>
> here you are:
> Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
> Oct 11 16:05:27 hilbert36 kernel:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > Could you send me the backtrace of one of the cases where
> > you hit the bug ?
just to add -- I was following Alan Cox's suggestion of incrementing
"mem=N" and finding the value where the system stops working normally. It
was ok as high as
On Wed, 11 Oct 2000, Rik van Riel wrote:
> Could you send me the backtrace of one of the cases where
> you hit the bug ?
here you are:
Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
Oct 11 16:05:26 hilbert36 kernel: invalid operand:
Oct 11 16:05:26 hilbert36 kernel: CPU:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > > On Wed, 11 Oct 2000, Mark Hemment wrote:
> > > > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > > >
> > > > > a) one of the eepro100 interfaces (the
On Wed, 11 Oct 2000, Rik van Riel wrote:
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > On Wed, 11 Oct 2000, Mark Hemment wrote:
> > > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > >
> > > > a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> > > > malfunctioning,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Mark Hemment wrote:
> > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> >
> > > a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> > > malfunctioning, interrupts are generated but no traffic gets through
> On Wed, 11 Oct 2000, Alan Cox wrote:
>
> > > I will continue to narrow down by removing some things (like mtrr) from
> > > the equation. Rik, the problem is that when one enables PAE (or just
> > > highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
> >
> > What happens
On Wed, 11 Oct 2000, Alan Cox wrote:
> > I will continue to narrow down by removing some things (like mtrr) from
> > the equation. Rik, the problem is that when one enables PAE (or just
> > highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
>
> What happens if you boot a
> I will continue to narrow down by removing some things (like mtrr) from
> the equation. Rik, the problem is that when one enables PAE (or just
> highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
What happens if you boot a PAE kernel with mem=512M on that box ?
-
To
On Wed, 11 Oct 2000, Boszormenyi Zoltan wrote:
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > I will continue to narrow down by removing some things (like mtrr) from
> > the equation. Rik, the problem is that when one enables PAE (or just
> > highmem-4G) support on a 4-way 6G RAM machine
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> I will continue to narrow down by removing some things (like mtrr) from
> the equation. Rik, the problem is that when one enables PAE (or just
> highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
Will you please try this patch?
Hi Mark,
On Wed, 11 Oct 2000, Mark Hemment wrote:
> Hi Tigran,
>
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
>
> > a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> > malfunctioning, interrupts are generated but no traffic gets through (YES,
> > I did plug it in
ok, confirmed -- it is _not_ PAE-related. Just using a plain highmem (4G)
support causes all these problems -- the machine becomes 38-40 times
slower overall and one of the eepro100 cards stops working.
I will try Zoltan's ideas on 64bit mtrrs but any more ideas are welcome...
Thanks,
Tigran
Hi Tigran,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> malfunctioning, interrupts are generated but no traffic gets through (YES,
> I did plug it in correctly, this time, and I repeat 2.2.16 works!)
I saw this the
Amazing, disabling highmem altogether (not just PAE) i.e. being able to
use only low 896M of RAM got rid of _both_ the eepro100 and slowness
problems!
The system is now very fast (kernel compile in 61 seconds!) and all
eepro100 interfaces work fine. I will now test with plain highmem (4G) but
no
Hi,
I have installed 2.4.0-test10-pre1 on a 4-way Xeon 700MHz 6G RAM machine
and observe various problems, not present in
2.2.16-(redhat69's-number-17).
a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
malfunctioning, interrupts are generated but no traffic gets through
Hi,
I have installed 2.4.0-test10-pre1 on a 4-way Xeon 700MHz 6G RAM machine
and observe various problems, not present in
2.2.16-(redhat69's-number-17).
a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
malfunctioning, interrupts are generated but no traffic gets through
Amazing, disabling highmem altogether (not just PAE) i.e. being able to
use only low 896M of RAM got rid of _both_ the eepro100 and slowness
problems!
The system is now very fast (kernel compile in 61 seconds!) and all
eepro100 interfaces work fine. I will now test with plain highmem (4G) but
no
Hi Tigran,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
malfunctioning, interrupts are generated but no traffic gets through (YES,
I did plug it in correctly, this time, and I repeat 2.2.16 works!)
I saw this the other
ok, confirmed -- it is _not_ PAE-related. Just using a plain highmem (4G)
support causes all these problems -- the machine becomes 38-40 times
slower overall and one of the eepro100 cards stops working.
I will try Zoltan's ideas on 64bit mtrrs but any more ideas are welcome...
Thanks,
Tigran
Hi Mark,
On Wed, 11 Oct 2000, Mark Hemment wrote:
Hi Tigran,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
malfunctioning, interrupts are generated but no traffic gets through (YES,
I did plug it in correctly,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
I will continue to narrow down by removing some things (like mtrr) from
the equation. Rik, the problem is that when one enables PAE (or just
highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
Will you please try this patch?
On Wed, 11 Oct 2000, Boszormenyi Zoltan wrote:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
I will continue to narrow down by removing some things (like mtrr) from
the equation. Rik, the problem is that when one enables PAE (or just
highmem-4G) support on a 4-way 6G RAM machine becomes
I will continue to narrow down by removing some things (like mtrr) from
the equation. Rik, the problem is that when one enables PAE (or just
highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
What happens if you boot a PAE kernel with mem=512M on that box ?
-
To
On Wed, 11 Oct 2000, Alan Cox wrote:
I will continue to narrow down by removing some things (like mtrr) from
the equation. Rik, the problem is that when one enables PAE (or just
highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
What happens if you boot a PAE
On Wed, 11 Oct 2000, Alan Cox wrote:
I will continue to narrow down by removing some things (like mtrr) from
the equation. Rik, the problem is that when one enables PAE (or just
highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
What happens if you boot a
On Wed, 11 Oct 2000, Rik van Riel wrote:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Mark Hemment wrote:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
malfunctioning, interrupts are
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Rik van Riel wrote:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Mark Hemment wrote:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
a) one of the eepro100 interfaces (the onboard one on the
On Wed, 11 Oct 2000, Rik van Riel wrote:
Could you send me the backtrace of one of the cases where
you hit the bug ?
here you are:
Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
Oct 11 16:05:26 hilbert36 kernel: invalid operand:
Oct 11 16:05:26 hilbert36 kernel: CPU:
On Wed, 11 Oct 2000, Rik van Riel wrote:
Could you send me the backtrace of one of the cases where
you hit the bug ?
just to add -- I was following Alan Cox's suggestion of incrementing
"mem=N" and finding the value where the system stops working normally. It
was ok as high as "mem=3096M"
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Rik van Riel wrote:
Could you send me the backtrace of one of the cases where
you hit the bug ?
here you are:
Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
Oct 11 16:05:27 hilbert36 kernel: Call Trace:
Tigran Aivazian [EMAIL PROTECTED] writes:
b) it detects all memory correctly but creates a write-back mtrr only for
the first 2G, is this normal?
mtrr.c is broken for machines with =4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB for PCI).
The patch
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Rik van Riel wrote:
Could you send me the backtrace of one of the cases where
you hit the bug ?
just to add -- I was following Alan Cox's suggestion of
incrementing "mem=N" and finding the value where the system
stops
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
it works fine then. Kernel compiles in 68 seconds as it should. Shall I
keep incrementing mem= to see what happens next...
I suspect fixing the mtrrs on the machine will fix this problem, as a
38-40 times slowdown on a machine that isn't swapping is
On Wed, 11 Oct 2000, Rik van Riel wrote:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
On Wed, 11 Oct 2000, Rik van Riel wrote:
Could you send me the backtrace of one of the cases where
you hit the bug ?
just to add -- I was following Alan Cox's suggestion of
incrementing
David Wragg writes:
Tigran Aivazian [EMAIL PROTECTED] writes:
b) it detects all memory correctly but creates a write-back mtrr only for
the first 2G, is this normal?
mtrr.c is broken for machines with =4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB
92 matches
Mail list logo
