Startup IPI (was: Re: test13-pre3)
Quoted 10 lines · Maciej W. Rozycki
Quoted 5 lines · Petr Vandrovec
No. Without
udelay()before firstprintk()it just does not boot on my motherboard. There were two choices: either remove allprintk()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...
Quoted 6 lines
Quoted 3 lines
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...
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Petr Vandrovec
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. ;-)
Quoted 2 lines
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.
Quoted 3 lines
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).
Quoted 3 lines
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 firstprintk()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...).
Quoted 1 line
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. ;-)
Quoted 3 lines
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
Signature · 8 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/