(apologies re: the empty 'double tap' :-/ )
On 5/14/17 8:39 AM, Andrew Cooper wrote:
>> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
>
> What are you trying to achieve? It is still not clear despite all on
> this thread.
>
> The Linux HEPT error messages are non-ideal,
(apologies re: the empty 'double tap' :-/ )
On 5/14/17 8:39 AM, Andrew Cooper wrote:
>> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
>
> What are you trying to achieve? It is still not clear despite all on
> this thread.
>
> The Linux HEPT error messages are non-ideal,
On 2017-05-13 19:17, PGNet Dev wrote:
On 5/13/17 3:15 PM, Valentin Vidic wrote:
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
select xen by default:
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
On 2017-05-13 19:17, PGNet Dev wrote:
On 5/13/17 3:15 PM, Valentin Vidic wrote:
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
select xen by default:
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
On 05/14/17 08:39, Andrew Cooper wrote:
> On 14/05/17 00:17, PGNet Dev wrote:
>> On 5/13/17 3:15 PM, Valentin Vidic wrote:
>>> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
>>> select xen by default:
>> Nope. Well, not quite ...
>>
>> With both
>>
>>
On 05/14/17 08:39, Andrew Cooper wrote:
> On 14/05/17 00:17, PGNet Dev wrote:
>> On 5/13/17 3:15 PM, Valentin Vidic wrote:
>>> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
>>> select xen by default:
>> Nope. Well, not quite ...
>>
>> With both
>>
>>
On 13/05/17 22:16, Andrew Cooper wrote:
> On 13/05/2017 21:05, PGNet Dev wrote:
>> On 5/13/17 12:59 PM, Andrew Cooper wrote:
>>> Ok. Lack of a clocksource is to be expected.
>>>
>>> The reason why the HPETs are unavailable is that dom0 is not a position
>>> to program them; dom0 doesn't know what
On 13/05/17 22:16, Andrew Cooper wrote:
> On 13/05/2017 21:05, PGNet Dev wrote:
>> On 5/13/17 12:59 PM, Andrew Cooper wrote:
>>> Ok. Lack of a clocksource is to be expected.
>>>
>>> The reason why the HPETs are unavailable is that dom0 is not a position
>>> to program them; dom0 doesn't know what
On 14/05/17 00:17, PGNet Dev wrote:
> On 5/13/17 3:15 PM, Valentin Vidic wrote:
>> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
>> select xen by default:
> Nope. Well, not quite ...
>
> With both
>
> 'hpet=force,verbose clocksource=hpet'
>
> removed, I end up with
On 14/05/17 00:17, PGNet Dev wrote:
> On 5/13/17 3:15 PM, Valentin Vidic wrote:
>> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
>> select xen by default:
> Nope. Well, not quite ...
>
> With both
>
> 'hpet=force,verbose clocksource=hpet'
>
> removed, I end up with
On 5/13/17 3:15 PM, Valentin Vidic wrote:
> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
> select xen by default:
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
cat
On 5/13/17 3:15 PM, Valentin Vidic wrote:
> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
> select xen by default:
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
cat
On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote:
> Does this perhaps imply that Xen correctly uses HPET
>
> (XEN) [VT-D] MSI HPET: :f0:0f.0
> (XEN) Platform timer is 14.318MHz HPET
I think so, yes.
> but that Dom0 does not
>
> current_clocksource
>
On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote:
> Does this perhaps imply that Xen correctly uses HPET
>
> (XEN) [VT-D] MSI HPET: :f0:0f.0
> (XEN) Platform timer is 14.318MHz HPET
I think so, yes.
> but that Dom0 does not
>
> current_clocksource
>
On 5/13/17 2:32 PM, Valentin Vidic wrote:
> On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
>> xl dmesg | grep -i hpet | grep -vi command
>> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>
> Ah, guess this is
On 5/13/17 2:32 PM, Valentin Vidic wrote:
> On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
>> xl dmesg | grep -i hpet | grep -vi command
>> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>
> Ah, guess this is
On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
> xl dmesg | grep -i hpet | grep -vi command
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
Ah, guess this is caused by console_to_ring boot option.
Better check
On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
> xl dmesg | grep -i hpet | grep -vi command
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
Ah, guess this is caused by console_to_ring boot option.
Better check
On 5/13/17 1:16 PM, Andrew Cooper wrote:
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.
noted
http://marc.info/?l=linux-kernel=149464267427111=2 indicates that
you are using a SuSE hypervisor.
yes, that's correct
On 5/13/17 1:16 PM, Andrew Cooper wrote:
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.
noted
http://marc.info/?l=linux-kernel=149464267427111=2 indicates that
you are using a SuSE hypervisor.
yes, that's correct
On 5/13/17 1:28 PM, Valentin Vidic wrote:
On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:
back to the error at hand ...
xl dmesg | grep -i hpet
[1.365876] hpet_acpi_add: no address or irqs in _CRS
[1.365876] hpet_acpi_add: no address or irqs in _CRS
again, only
On 5/13/17 1:28 PM, Valentin Vidic wrote:
On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:
back to the error at hand ...
xl dmesg | grep -i hpet
[1.365876] hpet_acpi_add: no address or irqs in _CRS
[1.365876] hpet_acpi_add: no address or irqs in _CRS
again, only
On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:
> back to the error at hand ...
>
> xl dmesg | grep -i hpet
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>
> again, only present when booting with Xen.
>
>
On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:
> back to the error at hand ...
>
> xl dmesg | grep -i hpet
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
> [1.365876] hpet_acpi_add: no address or irqs in _CRS
>
> again, only present when booting with Xen.
>
>
On 13/05/2017 21:05, PGNet Dev wrote:
> On 5/13/17 12:59 PM, Andrew Cooper wrote:
>> Ok. Lack of a clocksource is to be expected.
>>
>> The reason why the HPETs are unavailable is that dom0 is not a position
>> to program them; dom0 doesn't know what Xen has set up in the IDT.
>>
>> Use `xl
On 13/05/2017 21:05, PGNet Dev wrote:
> On 5/13/17 12:59 PM, Andrew Cooper wrote:
>> Ok. Lack of a clocksource is to be expected.
>>
>> The reason why the HPETs are unavailable is that dom0 is not a position
>> to program them; dom0 doesn't know what Xen has set up in the IDT.
>>
>> Use `xl
On 5/13/17 12:59 PM, Andrew Cooper wrote:
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
On 5/13/17 12:59 PM, Andrew Cooper wrote:
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
On 13/05/2017 20:28, Randy Dunlap wrote:
> On 05/13/17 11:26, PGNet Dev wrote:
>> On 5/13/17 10:41 AM, Randy Dunlap wrote:
>>> [adding HPET driver maintainer]
>> Thanks
>>
>>> A couple of comments below...
In BIOS, HPET's enabled.
>>> How about if you just boot Linux without Xen? Does HPET
On 13/05/2017 20:28, Randy Dunlap wrote:
> On 05/13/17 11:26, PGNet Dev wrote:
>> On 5/13/17 10:41 AM, Randy Dunlap wrote:
>>> [adding HPET driver maintainer]
>> Thanks
>>
>>> A couple of comments below...
In BIOS, HPET's enabled.
>>> How about if you just boot Linux without Xen? Does HPET
On 13/05/2017 20:49, PGNet Dev wrote:
> On 5/13/17 12:38 PM, Andrew Cooper wrote:
>> What is the issue here?
>>
>> Xen owns (and may use) any HPETs in the system. They are purposefully
>> unavailable to even dom0.
> The issue is that, when booting to Xen, hpet is not advertised as an
> available
On 13/05/2017 20:49, PGNet Dev wrote:
> On 5/13/17 12:38 PM, Andrew Cooper wrote:
>> What is the issue here?
>>
>> Xen owns (and may use) any HPETs in the system. They are purposefully
>> unavailable to even dom0.
> The issue is that, when booting to Xen, hpet is not advertised as an
> available
On 5/13/17 12:38 PM, Andrew Cooper wrote:
> What is the issue here?
>
> Xen owns (and may use) any HPETs in the system. They are purposefully
> unavailable to even dom0.
The issue is that, when booting to Xen, hpet is not advertised as an available
clocksource, AND reports the hpet boot error
On 5/13/17 12:38 PM, Andrew Cooper wrote:
> What is the issue here?
>
> Xen owns (and may use) any HPETs in the system. They are purposefully
> unavailable to even dom0.
The issue is that, when booting to Xen, hpet is not advertised as an available
clocksource, AND reports the hpet boot error
36 matches
Mail list logo
