On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:
> What is this change about?
>
> diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
> --- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
> +++ linux/arch/i386/kernel/smpboot.c Thu Dec 14 14:54:40 2000
> @@ -694,6 +694,11 @@
> apic_write_around(APIC_ICR, APIC_DM_STARTUP
> | (start_eip >> 12));
>
> + /*
> + * Give the other CPU some time to accept the IPI.
> + */
> + udelay(300);
> +
> Dprintk("Startup point 1.\n");
>
> Dprintk("Waiting for send to finish...\n");
>
> There is the following code is just after it, making the above change
> just useless garbage:
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
mingo@redhat.com, and nobody said anything against it.
> timeout = 0;
> do {
> Dprintk("+");
> udelay(100);
> send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
> } while (send_status && (timeout++ < 1000));
>
> /*
> * Give the other CPU some time to accept the IPI.
> */
> udelay(200);
>
> If we need 600usecs of delay for certain systems, then why not just make
> it like below?
No. If there is no udelay() before first printk(), on my GA-6VXD7 board
(SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting
for send to finish...'. So maybe we do not need udelay(200) below loop,
but for sure we need udelay() before first printk(). (my board works
without ANY udelay() in smpboot.c, except one I added... This one is
required.) If somebody lives in Prague, and wants to come with logical
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.
(it boots also without any kernel change with 'console=ttyS0,9600', but
it may be caused by slow serial line)
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).
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 23 2000 - 21:00:22 EST