public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ray Lee <ray-lk@madrabbit.org>
To: tglx@linutronix.de
Cc: Adrian Bunk <bunk@stusta.de>, LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, john stultz <johnstul@us.ibm.com>,
	Len Brown <len.brown@intel.com>, Andi Kleen <ak@suse.de>,
	linux-acpi@vger.kernel.org
Subject: Re: 2.6.21-rc[123] regression with NOAPIC
Date: Thu, 22 Mar 2007 22:35:20 -0700	[thread overview]
Message-ID: <46036718.7060502@madrabbit.org> (raw)
In-Reply-To: <1174576601.10840.189.camel@localhost.localdomain>

Thomas Gleixner wrote:
> On Thu, 2007-03-22 at 15:16 +0100, Adrian Bunk wrote:
>>>> Does it work if you do _not_ revert the commits, and instead replace in
>>>> drivers/acpi/processor_idle.c the
>>>>   #ifdef ARCH_APICTIMER_STOPS_ON_C3
>>>> with an
>>>>   #if 0
>>>> ?
>>> Then NOAPIC probably works again, but booting w/o NOAPIC fails.
>> But we'll know that it's this code that has a problen with noapic
>> in the CONFIG_GENERIC_CLOCKEVENTS=n case.
> 
> Nope. This code does not have a problem. It causes a problem elsewhere:

I can still try the above if it ends up being a useful data point.

> 
> It calls switch_ipi_to_APIC_timer() or switch_APIC_timer_to_ipi(), which
> sets/clears a bit in the broadcast mask and enables / disables the local
> APIC timer.
> 
> I don't see right now, why this causes the box to lock up hard, but
> maybe the debug printk's below give us some hint.
> 
> 	tglx
> 
> diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
> index 723417d..29376e2 100644
> --- a/arch/x86_64/kernel/apic.c
> +++ b/arch/x86_64/kernel/apic.c
> @@ -886,6 +886,8 @@ void disable_APIC_timer(void)
>  	if (using_apic_timer) {
>  		unsigned long v;
>  
> +		printk("Disabling local APIC timer %d\n", apic_runs_main_timer);
> +
>  		v = apic_read(APIC_LVTT);
>  		/*
>  		 * When an illegal vector value (0-15) is written to an LVT
> @@ -910,6 +912,7 @@ void enable_APIC_timer(void)
>  	    !cpu_isset(cpu, timer_interrupt_broadcast_ipi_mask)) {
>  		unsigned long v;
>  
> +		printk("Enabling local APIC timer: %d\n", apic_runs_main_timer);
>  		v = apic_read(APIC_LVTT);
>  		apic_write(APIC_LVTT, v & ~APIC_LVT_MASKED);
>  	}
> @@ -934,6 +937,7 @@ void smp_send_timer_broadcast_ipi(void)
>  
>  	cpus_and(mask, cpu_online_map, timer_interrupt_broadcast_ipi_mask);
>  	if (!cpus_empty(mask)) {
> +		printk("Send IPI\n");
>  		send_IPI_mask(mask, LOCAL_TIMER_VECTOR);
>  	}
>  }
> 
> 

I didn't see the first two print, but I'm having to watch the bad
bootups (with NOAPIC) by eyesight alone, as I don't have a second system
to run netconsole on at the moment.

However, on the NOAPIC, locking boot, the last thing that prints out is
the final printk, Send IPI.

On the boots without NOAPIC, at the same spot roughly a thousand
(estimated) "Send IPI" messages hit the screen before transitioning to
the initramfs and continuing normally.

In the morning, I can rework the patch to set a global in the first two
cases (Disabling/Enabling local APIC timer), and print the result of
those in the last case, as we know the system will hang there. (I would
have done this before sending the message, but given our timezone
difference, figured this was a good start.)

Ray

  reply	other threads:[~2007-03-23  5:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4601573A.8070602@madrabbit.org>
2007-03-22 13:42 ` 2.6.21-rc[123] regression with NOAPIC Adrian Bunk
2007-03-22 14:10   ` Thomas Gleixner
2007-03-22 14:16     ` Adrian Bunk
2007-03-22 15:16       ` Thomas Gleixner
2007-03-23  5:35         ` Ray Lee [this message]
2007-03-09  1:44 Ray Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46036718.7060502@madrabbit.org \
    --to=ray-lk@madrabbit.org \
    --cc=ak@suse.de \
    --cc=bunk@stusta.de \
    --cc=johnstul@us.ibm.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox