Re: [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dan Kenigsberg wrote:
> On Tue, Aug 21, 2007 at 01:15:22PM -0700, Matthew Kent wrote:
>   
>> On Tue, 2007-21-08 at 21:40 +0200, Luca wrote:
>>     
>>> On 8/21/07, Matthew Kent <mkent-rTVjrLRGJfNWk0Htik3J/w@public.gmane.org> wrote:
>>>       
>>>> On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote:
>>>>         
>>>>> plain text document attachment (clock-hpet)
>>>>> Linux operates the HPET timer in legacy replacement mode, which means that
>>>>> the periodic interrupt of the CMOS RTC is not delivered (qemu won't be able
>>>>> to use /dev/rtc). Add support for HPET (/dev/hpet) as a replacement for the
>>>>> RTC; the periodic interrupt is delivered via SIGIO and is handled in the
>>>>> same way as the RTC timer.
>>>>>
>>>>> Signed-off-by: Luca Tettamanti <kronos.it-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>           
>>>> I must be missing something silly here.. should I be able to open more
>>>> than one instance of qemu with -clock hpet? Because upon invoking a
>>>> second instance of qemu HPET_IE_ON fails.
>>>>         
>>> It depends on your hardware. Theoretically it's possible, but I've yet
>>> to see a motherboard with more than one periodic timer.
>>>       
>> Ah thank you, after re-reading the docs I think I better understand
>> this.
>>     
>
> In a risk of being off-topic, maybe you can help me try the hpet support.
> When I try the hpet Documentation demo I get
>
> # ./hpet poll /dev/hpet 1 1000
> -hpet: executing poll
> hpet_poll: info.hi_flags 0x0
> hpet_poll, HPET_IE_ON failed
>
> while I have
>
> $ dmesg|grep -i HPET
> ACPI: HPET 7D5B6AE0, 0038 (r1 A M I  OEMHPET   5000708 MSFT       97)
> ACPI: HPET id: 0x8086a301 base: 0xfed00000
> hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
> hpet0: 4 64-bit timers, 14318180 Hz
> hpet_resources: 0xfed00000 is busy
> Time: hpet clocksource has been installed.
>
> Any idea what I am misconfiguring?
>   

Maybe the kernel is using the timer, so userspace can't.  Just a guess.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/