public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@transmeta.com>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org, mikpe@csd.uu.se
Subject: Re: UP APIC reenabling vs. cpu type detection ordering
Date: Wed, 07 Feb 2001 09:01:28 -0800	[thread overview]
Message-ID: <3A817F68.1A5C4EC1@transmeta.com> (raw)
In-Reply-To: <20010207135824.A24476@vana.vc.cvut.cz>

Petr Vandrovec wrote:
> 
> Hi,
>   Mikael Pettersson pointed to me that current kernel code should not
> reenable local APIC on AMD K7, as it tests boot_cpu_data.x86_vendor.
> But boot_cpu_data.x86_vendor is uninitialized (or contains wrong
> value) when detect_init_APIC is invoked.
> 
>   As side effect I can confirm that APIC reenabling code works also on
> my AMD K7.
>                                                 Best regards,
>                                                         Petr Vandrovec
>                                                         vandrove@vc.cvut.cz
> 
> P.S.: I'm getting 'spurious 8259A interrupt: IRQ7' few seconds after boot.
> It does not cause any harm AFAIS.
> 
> int detect_init_APIC (void)
> {
>         u32 h, l, dummy, features;
> 
>         if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
>                 printk("No APIC support for non-Intel processors.\n");
>                 return -1;
>         }
> 
>         ...
> 
>                 rdmsr(MSR_IA32_APICBASE, l, h);
>                 if (!(l & MSR_IA32_APICBASE_ENABLE)) {
>                         printk("Local APIC disabled by BIOS -- reenabling.\n");
>                         l &= ~MSR_IA32_APICBASE_BASE;
>                         l |= MSR_IA32_APICBASE_ENABLE | APIC_DEFAULT_PHYS_BASE;
>                         wrmsr(MSR_IA32_APICBASE, l, h);
>                 }
>         }
> 

Why is the test there in the first place?  If the machine has an APIC, it
should be able to use it.  Presumably no other CPU uses the same MSR
address (am I wrong?) for anything else -- if so, it should be able to
poke it as long as the kernel intercepts the #GP(0) that may come if it
is not enabled.  The Linux kernel has pretty sophisticated support for
trapping faults.

In other words, I'd like to see a reason for making any vendor-specific
determinations, and if so, they should ideally be centralized to the CPU
feature-determination code.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

  parent reply	other threads:[~2001-02-07 17:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-07 12:58 UP APIC reenabling vs. cpu type detection ordering Petr Vandrovec
2001-02-07 15:56 ` Maciej W. Rozycki
2001-02-07 17:01 ` H. Peter Anvin [this message]
2001-02-07 17:35   ` Mikael Pettersson
2001-02-07 17:43     ` H. Peter Anvin
2001-02-07 17:55   ` Maciej W. Rozycki
2001-02-07 18:00     ` H. Peter Anvin

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=3A817F68.1A5C4EC1@transmeta.com \
    --to=hpa@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@csd.uu.se \
    --cc=mingo@redhat.com \
    --cc=vandrove@vc.cvut.cz \
    /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