On Wed, 20 Dec 2000, Petr Vandrovec wrote:
> /usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing
Well, the test looks reasonable if the system load is low. Still the
performance is surprisingly low -- after changing the transfer width to 16
bits I ran the test on my
On Wed, 20 Dec 2000, Petr Vandrovec wrote:
/usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing
Well, the test looks reasonable if the system load is low. Still the
performance is surprisingly low -- after changing the transfer width to 16
bits I ran the test on my
On 20 Dec 00 at 19:52, Maciej W. Rozycki wrote:
> > it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture
> > take 3.48ms, and this does not correspond with needed 200us udelay.
>
> Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a
> read or write
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR',
> yes (as verified in generated code...)? No change, still dies, as expected
> (do not forget that before it dies, it can do ~0x1300 write-read cycles
I've forgotten indeed...
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR',
yes (as verified in generated code...)? No change, still dies, as expected
(do not forget that before it dies, it can do ~0x1300 write-read cycles
I've forgotten indeed...
On 20 Dec 00 at 19:52, Maciej W. Rozycki wrote:
it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture
take 3.48ms, and this does not correspond with needed 200us udelay.
Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a
read or write cycle
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote:
[snip of Petr's system info]
> Okay. Mine, as far as I can tell, only depends on the L2 cache being set
> to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under
> 'Chipset Features Setup' on my BIOS. This is unfortunately the
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
> >
> > Pardon me for not fully groking the issues here and possibly coming to a
> > wrong conclusion, but this has to do with SMP systems crashing at APIC
> > init time, just before penguin display
On 19 Dec 00 at 19:30, Maciej W. Rozycki wrote:
> > When I replaced address with 0xC01B8000 (some cachable memory), it worked
> > fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
> > it is just set as cacheable in chipset), it works too.
>
> Hmm, a read from an uncached
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> Uh. It took couple of hours to find it. Just place
>
> { int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i < 6553600;
>i++) { *p; } }(**)
>
> instead of udelay(300) and this loop does not
> > In the case where it boots does it also report mismatched MTRRs ??
>
> Yes, it complains. But BIOS correctly reports x1/x2 depending on
> number of CPUs I plug into motherboard, so I believe that it did
> some initialization before it start loading OS.
That may explain the hangs. Intel docs
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
>
> Pardon me for not fully groking the issues here and possibly coming to a
> wrong conclusion, but this has to do with SMP systems crashing at APIC
> init time, just before penguin display (with fbcon at least)? If so, I
> have a board that does
On 18 Dec 00 at 23:51, Alan Cox wrote:
> > Yeah. Just do not read video memory when another CPU starts. I'll try
> > disabling cache on both CPUs, maybe it will make some difference, as
> > secondary CPU should start with caches disabled. But maybe that it is
> > just broken AGP bus, and
On 18 Dec 00 at 23:51, Alan Cox wrote:
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else.
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with fbcon at least)? If so, I
have a board that does this
In the case where it boots does it also report mismatched MTRRs ??
Yes, it complains. But BIOS correctly reports x1/x2 depending on
number of CPUs I plug into motherboard, so I believe that it did
some initialization before it start loading OS.
That may explain the hangs. Intel docs don't
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
Uh. It took couple of hours to find it. Just place
{ int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i 6553600;
i++) { *p; } }(**)
instead of udelay(300) and this loop does not finish.
On 19 Dec 00 at 19:30, Maciej W. Rozycki wrote:
When I replaced address with 0xC01B8000 (some cachable memory), it worked
fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
it is just set as cacheable in chipset), it works too.
Hmm, a read from an uncached
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote:
[snip of Petr's system info]
Okay. Mine, as far as I can tell, only depends on the L2 cache being set
to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under
'Chipset Features Setup' on my BIOS. This is unfortunately the latest
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with fbcon at least)? If so, I
have a board that does this with certain cache settings made in the BIOS.
It's a
> Yeah. Just do not read video memory when another CPU starts. I'll try
> disabling cache on both CPUs, maybe it will make some difference, as
> secondary CPU should start with caches disabled. But maybe that it is
> just broken AGP bus, and nothing else. But until I find what's really
> broken
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
> > No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
> > PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
>
> Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
> if accessing one bus or
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
> It is possible. But it is hard to track, as it works with serial console,
> and it is not possible to paint characters to VGA screen, as vgacon uses
> hardware panning instead of scrolling :-( And if it dies, shift-pageup
> apparently does not work...
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote:
> On Mon, 18 Dec 2000, Petr Vandrovec wrote:
>
> > No. Without udelay() before first printk() it just does not boot on my
> > motherboard. There were two choices: either remove all printk() from
> > these loops (define Dprintk to null), or add
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote:
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x),
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
It is possible. But it is hard to track, as it works with serial console,
and it is not possible to paint characters to VGA screen, as vgacon uses
hardware panning instead of scrolling :-( And if it dies, shift-pageup
apparently does not work... And
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
if accessing one bus or another
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else. But until I find what's really
broken on my
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with fbcon at least)? If so, I
have a board that does this with certain cache settings made in the BIOS.
It's a
30 matches
Mail list logo
