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), where x >= 200,
> > before first printk. I sent patch twice to linux-kernel, and to
> > [email protected], and nobody said anything against it.
>
> I see. But are you sure this is the right fix? You may be covering
> the real problem with this arbitrary delay.
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 filling whole 32KB with some char
does not work, as it changes timing too much...
> > analyzer (or if I should come with motherboard), I'm willing to continue
> > testing. But current idea is that inb/outb done by cursor positioning
> > code is incompatible with something else done in secondary CPU startup.
>
> Have you tried putting explicit display adapter (other ISA) I/O accesses
> after sending the IPI to see if they trigger the problem? IPIs are
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...
> > Without delay() both CPU die, and board does not react to anything except
> > hard reset anymore (and sometime it does not react even to hard reset; lookup
> > for my messages during last week).
>
> Now THAT is weird. It might mean a chipset bug. Still no idea how an
> inter-APIC message might trigger it -- it completely bypasses MB
Yes. I could understand if I had to place bigger udelay() after INIT IPI,
as this can cause some specific PIII initialization and Intel says that
there should not be any MESI traffic during this init (at least I understand
it that way). But after startup IPI it should just start executing code...
I tried to put 'wbinvd' here and there, but it did not make any change,
only udelay() between startup IPI cmd and first printk() did.
> chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's
> 82093AA) or integrated? It appears there are vendors manufacturing I/O
> APIC clones and this may imply new problems, sigh...
I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge,
and VT82C686 (rev 22) ISA bridge. I tried to request documentation
of 694X from VIA, but I did not heard from them. They have probably
some secrets hidden in their hardware...
Best regards,
Petr Vandrovec
[email protected]
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 filling whole 32KB with some char
> does not work, as it changes timing too much...
Just disable the problematic printk()s for making tests (you may just
undefine APIC_DEBUG in include/asm-i386/apic.h) -- we already know what is
going to be printed here. ;-)
> 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 changes the behaviour.
> Yes. I could understand if I had to place bigger udelay() after INIT IPI,
> as this can cause some specific PIII initialization and Intel says that
> there should not be any MESI traffic during this init (at least I understand
Hmm, weird -- for integrated APICs an INIT IPI is about the same as
shutdown apart from the fact an NMI won't wake up a CPU (that might
actually be the local APIC not passing NMIs to the CPU in this case,
though).
> it that way). But after startup IPI it should just start executing code...
> I tried to put 'wbinvd' here and there, but it did not make any change,
> only udelay() between startup IPI cmd and first printk() did.
Hmm, a startup IPI is rather fast so the code just after issuing it may
somehow interact with the application's CPU trampoline. But try to
disable CONFIG_X86_GOOD_APIC, yet (you may configure for classic Pentium,
for example), and see if that changes anything (it shouldn't, but who
knows...).
> I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge,
Just look at the board and search for an I/O APIC chip. ;-)
> and VT82C686 (rev 22) ISA bridge. I tried to request documentation
> of 694X from VIA, but I did not heard from them. They have probably
> some secrets hidden in their hardware...
They wan't to keep the competition from being bug-compatible, it would
seem...
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +