(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 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 /sys/devices/system/clocksource/clo
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
&
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&m=149464267427111&w=2 indicates that
you are using a SuSE hypervisor.
yes, that's corre
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 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
m
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 registra
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 p
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
tsc
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,
dmidec
moving to https://bugzilla.kernel.org/show_bug.cgi?id=195229
I'm running kernel 4.10.8-3.gea9dcd4 (from Opensuse's Kernel:Stable repo) on an
Atom D525 box.
I just noticed an OOPS on *shutdown*; Since it autoreboots, *boots* without
problem, and I hadn't been paying attention until now, I can't say how long
this has been occurring. On this box I follow
13 matches
Mail list logo