All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [RFC 2/8] x86/acpi: Warn about multiple HPET tables
Date: Tue, 5 Nov 2013 16:03:10 +0000	[thread overview]
Message-ID: <527916BE.1010408@citrix.com> (raw)
In-Reply-To: <5278DD7A02000078000FF76B@nat28.tlf.novell.com>

On 05/11/13 10:58, Jan Beulich wrote:
>>>> On 04.11.13 at 19:54, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/arch/x86/acpi/boot.c
>> +++ b/xen/arch/x86/acpi/boot.c
>> @@ -289,6 +289,17 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
>>  		return -1;
>>  	}
>>  
>> +	/*
>> +	 * Some BIOSes provide multiple HPET tables. Warn that we will ignore
>> +	 * them.
>> +	 */
>> +	if ( hpet_address )
>> +	{
>> +		printk(KERN_WARNING PREFIX
>> +		       "Found multiple HPET tables. Only using first\n");
>> +		return -1;
>> +	}
> If there really are examples of this, and if those HPETs work
> properly, perhaps we should rather make use of them?
>
> Jan
>

The cause of this was two HPET acpi tables appearing.  This got 'fixed'
by a BIOS update (after which there was only a single HPET table), but I
felt it was worth warning about.

It might be nice to support multiple hpets is such a system existed.  It
would however be another fairly large chunk of work and I do not believe
I have appropriate hardware to test any development work on.

~Andrew

  reply	other threads:[~2013-11-05 16:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 18:54 [RFC 0/8] Improvements to HPET interupts Andrew Cooper
2013-11-04 18:54 ` [RFC 1/8] x86/timing: Command line parameter to disable ARAT Andrew Cooper
2013-11-05 10:57   ` Jan Beulich
2013-11-04 18:54 ` [RFC 2/8] x86/acpi: Warn about multiple HPET tables Andrew Cooper
2013-11-05 10:58   ` Jan Beulich
2013-11-05 16:03     ` Andrew Cooper [this message]
2013-11-04 18:54 ` [RFC 3/8] x86/hpet: Fix ambiguity in broadcast info message Andrew Cooper
2013-11-05 11:02   ` Jan Beulich
2013-11-05 13:28     ` David Vrabel
2013-11-05 13:34       ` Jan Beulich
2013-11-05 13:36         ` David Vrabel
2013-11-04 18:54 ` [RFC 4/8] x86/hpet: Debug and verbose hpet logging Andrew Cooper
2013-11-04 18:54 ` [RFC 5/8] x86/msi: Refactor msi_compose_message() to not requrie an irq_desc Andrew Cooper
2013-11-05 11:05   ` Jan Beulich
2013-11-04 18:54 ` [RFC 6/8] x86/hpet: Adjust pointer vs array semantics of hpet_boot_cfg Andrew Cooper
2013-11-05 11:08   ` Jan Beulich
2013-11-04 18:54 ` [RFC 7/8] x86/hpet: debug keyhandlers Andrew Cooper
2013-11-05 11:11   ` Jan Beulich
2013-11-05 11:16     ` Andrew Cooper
2013-11-04 18:54 ` [RFC 8/8] x86/hpet: Use singe apic vector rather than irq_descs for HPET interrupts Andrew Cooper
2013-11-05 15:10   ` Jan Beulich

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=527916BE.1010408@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.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.