On Sun, Nov 12, 2000 at 11:22:02PM -0700, "Jeff V. Merkey"
<[EMAIL PROTECTED]> wrote:
> I can go and get the text from our discussion, and I distinctly remember
> your answer to this question on PII and you said "lots". This was also a
Well, my mail certainly contained the words "lot" (not
On Mon, 13 Nov 2000, Jeff V. Merkey wrote:
> On Sat, Nov 11, 2000 at 08:26:55PM +0100, Marc Lehmann wrote:
> > On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey"
><[EMAIL PROTECTED]> wrote:
> > >
> > > Marc Lehman verified that PII systems will generate tons of AGIs with
> > > gcc.
> >
On Mon, 13 Nov 2000, Jeff V. Merkey wrote:
On Sat, Nov 11, 2000 at 08:26:55PM +0100, Marc Lehmann wrote:
On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey"
[EMAIL PROTECTED] wrote:
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc.
It is a bit
On Sun, Nov 12, 2000 at 11:22:02PM -0700, "Jeff V. Merkey"
[EMAIL PROTECTED] wrote:
I can go and get the text from our discussion, and I distinctly remember
your answer to this question on PII and you said "lots". This was also a
Well, my mail certainly contained the words "lot" (not
On Sat, Nov 11, 2000 at 08:26:55PM +0100, Marc Lehmann wrote:
> On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" <[EMAIL PROTECTED]>
>wrote:
> >
> > Marc Lehman verified that PII systems will generate tons of AGIs with
> > gcc.
>
> It is a bit late (just came back from the
On Sat, Nov 11, 2000 at 08:26:55PM +0100, Marc Lehmann wrote:
On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" [EMAIL PROTECTED]
wrote:
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc.
It is a bit late (just came back from the systems'00 fair), but
On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" <[EMAIL PROTECTED]>
wrote:
>
> Marc Lehman verified that PII systems will generate tons of AGIs with
> gcc.
It is a bit late (just came back from the systems'00 fair), but Jeff
Merkey just acknowledged that indeed he meant me with
On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" [EMAIL PROTECTED]
wrote:
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc.
It is a bit late (just came back from the systems'00 fair), but Jeff
Merkey just acknowledged that indeed he meant me with "Marc
On Wed, Nov 08, 2000 at 09:28:54AM -0500, Richard B. Johnson wrote:
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> >
> > Marc Lehman verified that PII systems will generate tons of AGIs with
> > gcc. Perhaps this is the cause of this problem. You could run EMON and
> > see if there is
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> Marc Lehman verified that PII systems will generate tons of AGIs with
> gcc. Perhaps this is the cause of this problem. You could run EMON and
> see if there is something obvious in the numbers ...
>
> Jeff
>
Here are some tests:
Before the
On Wed, Nov 08, 2000 at 09:28:54AM -0500, Richard B. Johnson wrote:
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc. Perhaps this is the cause of this problem. You could run EMON and
see if there is something
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc. Perhaps this is the cause of this problem. You could run EMON and
see if there is something obvious in the numbers ...
Jeff
"Richard B. Johnson" wrote:
>
> On Wed, 8 Nov 2000, Keith Owens wrote:
>
> > On Tue, 7 Nov
On Wed, 8 Nov 2000, Keith Owens wrote:
> On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> >Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
> >
> >Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master
On Tue, 07 Nov 2000 23:31:19 Richard B. Johnson wrote:
> On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
..
> > 15:111130 IO-APIC-level bttv
> > NMI: 190856196 190856196
> > LOC: 190858464 190858463
> > ERR: 0
> >
..
>
>CPU0 CPU1
> 0:
On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
>
>Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master browser
>for workgroup LINUX on subnet 204.178.40.224
On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
> > This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> > chipset.
>
> Strange, I've got a dual Katmai (non-Xeon) and notice the same...
>
>CPU0 CPU1
> 0: 95135438 95720832IO-APIC-edge
On Tue, 7 Nov 2000, Jan-Benedict Glaw wrote:
> [...]
> > NMI: 190856196 190856196
> > LOC: 190858464 190858463
>
> ...are these two lines okay? I've noticed that as well, but I've not
> seen that on UP machines as well...
Yes, please don't worry, it's just the NMI watchdog doing its
On Tue, Nov 07, 2000 at 02:02:23PM -0800, Dr. Kelsey Hudson wrote:
> > This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> > chipset.
>
> Strange, I've got a dual Katmai (non-Xeon) and notice the same...
I've just gotten a dual PIII (Coppermine) to my hands. I *think*
> This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> chipset.
Strange, I've got a dual Katmai (non-Xeon) and notice the same...
CPU0 CPU1
0: 95135438 95720832IO-APIC-edge timer
1: 579101 572402IO-APIC-edge keyboard
2:
This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
chipset.
Strange, I've got a dual Katmai (non-Xeon) and notice the same...
CPU0 CPU1
0: 95135438 95720832IO-APIC-edge timer
1: 579101 572402IO-APIC-edge keyboard
2:
On Tue, Nov 07, 2000 at 02:02:23PM -0800, Dr. Kelsey Hudson wrote:
This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
chipset.
Strange, I've got a dual Katmai (non-Xeon) and notice the same...
I've just gotten a dual PIII (Coppermine) to my hands. I *think* that
On Tue, 7 Nov 2000, Jan-Benedict Glaw wrote:
[...]
NMI: 190856196 190856196
LOC: 190858464 190858463
...are these two lines okay? I've noticed that as well, but I've not
seen that on UP machines as well...
Yes, please don't worry, it's just the NMI watchdog doing its work.
On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
chipset.
Strange, I've got a dual Katmai (non-Xeon) and notice the same...
CPU0 CPU1
0: 95135438 95720832IO-APIC-edge timer
1:
On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
"Richard B. Johnson" [EMAIL PROTECTED] wrote:
Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master browser
for workgroup LINUX on subnet 204.178.40.224
Nov 7
On Tue, 07 Nov 2000 23:31:19 Richard B. Johnson wrote:
On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
..
15:111130 IO-APIC-level bttv
NMI: 190856196 190856196
LOC: 190858464 190858463
ERR: 0
..
CPU0 CPU1
0: 10945
On Wed, 8 Nov 2000, Keith Owens wrote:
On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
"Richard B. Johnson" [EMAIL PROTECTED] wrote:
Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master
browser for
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc. Perhaps this is the cause of this problem. You could run EMON and
see if there is something obvious in the numbers ...
Jeff
"Richard B. Johnson" wrote:
On Wed, 8 Nov 2000, Keith Owens wrote:
On Tue, 7 Nov 2000
On Fri, 3 Nov 2000, bert hubert wrote:
>> Thanks! That patch did the trick - our machine is now running lovely.
>
>Your very rare problem was solved in 3 hours and 50 minutes. Most commercial
>support shops try and fail to deliver 4 hour response times - this makes me
>feel warm inside :-)
To be
On Fri, 3 Nov 2000, bert hubert wrote:
Thanks! That patch did the trick - our machine is now running lovely.
Your very rare problem was solved in 3 hours and 50 minutes. Most commercial
support shops try and fail to deliver 4 hour response times - this makes me
feel warm inside :-)
To be fair,
> > I'm seeing this as well, but only with PIII Xeon systems, not PII
> > Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> > and LOC increment on every CPU.
> >
> >CPU0 CPU1
> > 0: 146727 153389IO-APIC-edge timer
> > [...]
> > NMI:
On Thu, Nov 02, 2000 at 05:39:03PM +, Dr. David Gilbert wrote:
> > So, here is David's mtrr patch. Although in his case ("only" 4G) it
> > shouldn't be needed it is for 36bit MTRRs I assume.
>
> Thanks! That patch did the trick - our machine is now running lovely.
Your very rare
On Thu, 2 Nov 2000, Chris Meadors wrote:
> On 2 Nov 2000, Ulrich Drepper wrote:
>
> > I'm seeing this as well, but only with PIII Xeon systems, not PII
> > Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> > and LOC increment on every CPU.
> >
> >CPU0
On 2 Nov 2000, Ulrich Drepper wrote:
> I'm seeing this as well, but only with PIII Xeon systems, not PII
> Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> and LOC increment on every CPU.
>
>CPU0 CPU1
> 0: 146727 153389IO-APIC-edge
On 2 Nov 2000, Ulrich Drepper wrote:
> I'm seeing this as well, but only with PIII Xeon systems, not PII
> Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> and LOC increment on every CPU.
>
>CPU0 CPU1
> 0: 146727 153389IO-APIC-edge
On Thu, Nov 02, 2000 at 10:09:36AM -0800, Ulrich Drepper wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> > Yes. Look at the NMI count. Looks like every access produces a
> > NMI.
>
> I'm seeing this as well, but only with PIII Xeon systems, not PII
> Xeon. Every single timer
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> Yes. Look at the NMI count. Looks like every access produces a
> NMI.
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
On Thu, 2 Nov 2000, Tigran Aivazian wrote:
> yes, that someone was me :) It did indeed help to my 4way 6G RAM Xeon --
> the performance improved 40x!. Also, using David's mtrr.patch helped with
> the problem of eepro100 interfaces sometimes not coming up properly (and
> generally, it is nice to
On Thu, 2 Nov 2000 [EMAIL PROTECTED] wrote:
> On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
>
> > I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
> > config (2.4.0-test10).
>
> > CONFIG_MTRR=y
>
> I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
>
On Thu, 2 Nov 2000 [EMAIL PROTECTED] wrote:
> On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
>
> > I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
> > config (2.4.0-test10).
>
> > CONFIG_MTRR=y
>
> I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
>
On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
> I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
> config (2.4.0-test10).
> CONFIG_MTRR=y
I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
that if you disable the cachable settings in the BIOS for the
Hi,
We have a dual Xeon machine with 4GB of RAM; when running with an SMP
kernel (either the SMP one with RH7 or a freshly compiled 2.4.0-test10) it
is INCREDIBLY slow. e.g. X takes a minute to start the server - I haven't
bothered waiting for anything more. Just from a command line it feels
Hi,
We have a dual Xeon machine with 4GB of RAM; when running with an SMP
kernel (either the SMP one with RH7 or a freshly compiled 2.4.0-test10) it
is INCREDIBLY slow. e.g. X takes a minute to start the server - I haven't
bothered waiting for anything more. Just from a command line it feels
On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
config (2.4.0-test10).
CONFIG_MTRR=y
I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
that if you disable the cachable settings in the BIOS for the
On Thu, 2 Nov 2000 [EMAIL PROTECTED] wrote:
On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
config (2.4.0-test10).
CONFIG_MTRR=y
I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
that if you
On Thu, 2 Nov 2000 [EMAIL PROTECTED] wrote:
On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
config (2.4.0-test10).
CONFIG_MTRR=y
I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
that if you
On Thu, 2 Nov 2000, Tigran Aivazian wrote:
yes, that someone was me :) It did indeed help to my 4way 6G RAM Xeon --
the performance improved 40x!. Also, using David's mtrr.patch helped with
the problem of eepro100 interfaces sometimes not coming up properly (and
generally, it is nice to see
"Richard B. Johnson" [EMAIL PROTECTED] writes:
Yes. Look at the NMI count. Looks like every access produces a
NMI.
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
On Thu, Nov 02, 2000 at 10:09:36AM -0800, Ulrich Drepper wrote:
"Richard B. Johnson" [EMAIL PROTECTED] writes:
Yes. Look at the NMI count. Looks like every access produces a
NMI.
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any
On 2 Nov 2000, Ulrich Drepper wrote:
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
CPU0 CPU1
0: 146727 153389IO-APIC-edge timer
On 2 Nov 2000, Ulrich Drepper wrote:
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
CPU0 CPU1
0: 146727 153389IO-APIC-edge timer
On Thu, 2 Nov 2000, Chris Meadors wrote:
On 2 Nov 2000, Ulrich Drepper wrote:
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
CPU0 CPU1
On Thu, Nov 02, 2000 at 05:39:03PM +, Dr. David Gilbert wrote:
So, here is David's mtrr patch. Although in his case ("only" 4G) it
shouldn't be needed it is for 36bit MTRRs I assume.
Thanks! That patch did the trick - our machine is now running lovely.
Your very rare problem was
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
CPU0 CPU1
0: 146727 153389IO-APIC-edge timer
[...]
NMI: 300035
53 matches
Mail list logo
