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
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
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 at
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 message
} 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 sur
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 trie
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
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 se
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 reporte
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 rea
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. Do
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 inte
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 s
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? O
> 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 anybo
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
> 2.4.0-test
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 Torval
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 BogoMIPS
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 cu
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 + if
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 i
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 syste
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 a
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: Cal
> 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=3096
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 onboa
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, inte
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 (YES,
> 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 i
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 P
> 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 unsu
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 becom
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 corre
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
O
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 oth
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 (YE
47 matches
Mail list logo
