(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
Randy Dunlap wrote:
> On 05/12/17 19:30, PGNet Dev wrote:
>> dmesg | grep -i hpet
>> [8.491738] hpet_acpi_add: no address or irqs in _CRS
>
> Above line marks a big failure.
> ^^^
>
>> Disassembling the firmware acpi tables
>>
Randy Dunlap wrote:
> On 05/12/17 19:30, PGNet Dev wrote:
>> dmesg | grep -i hpet
>> [8.491738] hpet_acpi_add: no address or irqs in _CRS
>
> Above line marks a big failure.
> ^^^
>
>> Disassembling the firmware acpi tables
>>
On 5/13/17 12:45 PM, Clemens Ladisch wrote:
That table is not used by hpet_acpi_add; you have to check for the device
that mentions "PNP0103" in the DSDT table.
But anyway, as far as I can tell from my own machine, the _CRS in the
DSDT table never lists the HPET interrupts, and the HPET
On 5/13/17 12:45 PM, Clemens Ladisch wrote:
That table is not used by hpet_acpi_add; you have to check for the device
that mentions "PNP0103" in the DSDT table.
But anyway, as far as I can tell from my own machine, the _CRS in the
DSDT table never lists the HPET interrupts, and the HPET
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
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 show up then?
>
> yes, it appears so:
>
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 show up then?
>
> yes, it appears so:
>
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 show up then?
yes, it appears so:
cat devices/system/clocksource/clocksource0/available
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 show up then?
yes, it appears so:
cat devices/system/clocksource/clocksource0/available
[adding HPET driver maintainer]
A couple of comments below...
On 05/12/17 19:30, PGNet Dev wrote:
> I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.
>
> HPET's enabled in BIOS, and apparently firmware table data is available.
>
> But, hpet is not an available_clocksource.
>
>
[adding HPET driver maintainer]
A couple of comments below...
On 05/12/17 19:30, PGNet Dev wrote:
> I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.
>
> HPET's enabled in BIOS, and apparently firmware table data is available.
>
> But, hpet is not an available_clocksource.
>
>
I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.
HPET's enabled in BIOS, and apparently firmware table data is available.
But, hpet is not an available_clocksource.
Where's this need to be addressed/fixed? In my config, in kernel code, &/or in
BIOS?
info:
@ the mobo,
I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.
HPET's enabled in BIOS, and apparently firmware table data is available.
But, hpet is not an available_clocksource.
Where's this need to be addressed/fixed? In my config, in kernel code, &/or in
BIOS?
info:
@ the mobo,
48 matches
Mail list logo
