From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, eswierk@aristanetworks.com,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:irq/numa] x86: read apic ID in the !acpi_lapic case
Date: Tue, 12 May 2009 21:27:10 +0400 [thread overview]
Message-ID: <20090512172710.GD12820@lenovo> (raw)
In-Reply-To: <4A09ADE5.3010102@kernel.org>
[Yinghai Lu - Tue, May 12, 2009 at 10:12:05AM -0700]
| Cyrill Gorcunov wrote:
| > [Ingo Molnar - Tue, May 12, 2009 at 06:46:17PM +0200]
| > |
| > | got this on a testbox:
| > |
| > | [ 0.113333] WARNING: at arch/x86/kernel/apic/apic.c:253 warn_slowpath_null+0x28/0x50()
| > |
| > | Ingo
| > |
| >
| > It's expected (unfortunately). If we have SMP compiled kernel
| > we still rely on apic_read heavily. Since for fake'ed apic
| > we just return 0 for any reading I suspect we could just drop
| > WARN_ON_ONCE for native_apic_read_dummy. Yinghai?
| >
| > (well, actually we should clean up callees but it would require
| > some effort)
|
| 32bit seems doesn't have this warning.
|
| and on 64bit, we always assumed have local APIC there. so could be that
| noapic is not cleanly enforced
|
yes, that is why I said that we need to cleanup the call-pathes.
And since it requires some effort we either could save WARN_ON_ONCE
here (so it hit us everyday provoking to do cleanup) and keep
in mind that it's expected behaviour at moment, or if it's that
annoying -- remove it (though it would be just a hidding of code
defect I think). Unfortunatelly I have a number of tasks to be done
before I could start such a checking/cleanups.
|
| YH
|
-- Cyrill
next prev parent reply other threads:[~2009-05-12 17:27 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090430084145.GD21699@elte.hu>
2009-05-02 4:48 ` [PATCH] x86: read apic id if it is not acpi_lapic Yinghai Lu
2009-05-02 7:02 ` Cyrill Gorcunov
2009-05-02 17:40 ` [PATCH] x86: read apic id if it is not acpi_lapic -v2 Yinghai Lu
[not found] ` <20090502184108.GC4791@lenovo>
[not found] ` <49FC9BFC.4040904@kernel.org>
[not found] ` <20090502192441.GE4791@lenovo>
[not found] ` <49FC9F28.2070802@kernel.org>
[not found] ` <20090502193203.GG4791@lenovo>
2009-05-02 22:27 ` [PATCH] x86: change apic_version array to bsp apic ver only Yinghai Lu
2009-05-11 9:20 ` [PATCH] x86: read apic id if it is not acpi_lapic -v2 Ingo Molnar
2009-05-11 9:26 ` Ingo Molnar
2009-05-11 9:40 ` Cyrill Gorcunov
2009-05-11 11:06 ` Ingo Molnar
2009-05-11 9:53 ` [tip:x86/apic] x86: read apic ID in the !acpi_lapic case tip-bot for Yinghai Lu
2009-05-11 11:02 ` Ingo Molnar
2009-05-11 13:41 ` Cyrill Gorcunov
2009-05-11 13:49 ` Ingo Molnar
2009-05-11 17:43 ` Yinghai Lu
2009-05-11 18:05 ` Cyrill Gorcunov
2009-05-11 20:01 ` Ingo Molnar
2009-05-11 20:05 ` Cyrill Gorcunov
2009-05-11 20:14 ` Yinghai Lu
2009-05-11 13:54 ` [tip:x86/apic] x86: apic: Fixmap apic address even if apic disabled tip-bot for Cyrill Gorcunov
2009-05-11 16:11 ` [tip:x86/apic] x86: read apic ID in the !acpi_lapic case Yinghai Lu
2009-05-12 10:36 ` [tip:irq/numa] " tip-bot for Yinghai Lu
2009-05-12 11:22 ` Ingo Molnar
2009-05-12 14:51 ` Cyrill Gorcunov
2009-05-12 14:58 ` Ingo Molnar
2009-05-12 15:00 ` Cyrill Gorcunov
2009-05-12 15:04 ` Yinghai Lu
2009-05-12 15:06 ` Ingo Molnar
2009-05-12 16:46 ` Ingo Molnar
2009-05-12 17:02 ` Cyrill Gorcunov
2009-05-12 17:12 ` Yinghai Lu
2009-05-12 17:27 ` Cyrill Gorcunov [this message]
2009-05-12 18:31 ` Yinghai Lu
2009-05-12 18:33 ` Ingo Molnar
2009-05-12 18:35 ` Yinghai Lu
2009-05-12 19:05 ` Ingo Molnar
2009-05-12 19:23 ` Yinghai Lu
2009-05-13 13:14 ` Ingo Molnar
2009-05-13 16:41 ` Yinghai Lu
2009-05-18 7:39 ` [tip:irq/numa] x86: don't call read_apic_id if !cpu_has_apic tip-bot for Yinghai Lu
2009-05-12 16:48 ` [tip:irq/numa] x86/pci: add 4 more return parameters to IO_APIC_get_PCI_irq_vector(), fix tip-bot for Cyrill Gorcunov
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=20090512172710.GD12820@lenovo \
--to=gorcunov@gmail.com \
--cc=eswierk@aristanetworks.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.