* HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
@ 2017-05-13 2:30 PGNet Dev
2017-05-13 17:41 ` Randy Dunlap
0 siblings, 1 reply; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 2:30 UTC (permalink / raw)
To: linux-kernel
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,
dmidecode
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
81 structures occupying 3317 bytes.
Table at 0x000EC200.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 3.0
Release Date: 05/26/2015
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 16384 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6
In BIOS, HPET's enabled.
On boot to Xen on linux64
xl info
release : 4.11.0-4.gcb15206-default
version : #1 SMP PREEMPT Thu May 11 07:36:09 UTC 2017 (cb15206)
machine : x86_64
nr_cpus : 4
max_cpu_id : 3
nr_nodes : 1
cores_per_socket : 4
threads_per_core : 1
cpu_mhz : 3092
hw_caps : bfebfbff:77faf3ff:2c100800:00000021:00000001:000027ab:00000000:00000100
virt_caps : hvm hvm_directio
total_memory : 32493
free_memory : 25899
sharing_freed_memory : 0
sharing_used_memory : 0
outstanding_claims : 0
free_cpus : 0
xen_major : 4
xen_minor : 9
xen_extra : .0_04-493
xen_version : 4.9.0_04-493
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit2
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset :
xen_commandline : dom0_mem=4096M,max:4096M dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false sync_console=true
cc_compiler : gcc (SUSE Linux) 4.8.5
cc_compile_by : abuild
cc_compile_domain : suse.de
cc_compile_date : Wed May 10 21:26:38 UTC 2017
build_id : dde541fac1512c7b1ce17e7496aab57a
xend_config_format : 4
grep -i hpet /boot/config-4.11.0-4.gcb15206-default
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HPET_MMAP_DEFAULT=y
, dmesg reports
dmesg | grep -i hpet
[ 0.000000] Command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005)
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] Kernel command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8
[ 8.491738] hpet_acpi_add: no address or irqs in _CRS
After boot, however, no hpet clocksource is available
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
Disassembling the firmware acpi tables
cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out
iasl -d /var/tmp/hpet.out
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140214-64
Copyright (c) 2000 - 2014 Intel Corporation
Loading Acpi table from file /var/tmp/hpet.out - Length 00000056 (000038)
Acpi Data Table [HPET] decoded
Formatted output: /var/tmp/hpet.dsl - 1835 bytes
cat /var/tmp/hpet.dsl
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20140214-64
* Copyright (c) 2000 - 2014 Intel Corporation
*
* Disassembly of /var/tmp/hpet.out, Fri May 12 18:46:28 2017
*
* ACPI Data Table [HPET]
*
* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
*/
[000h 0000 4] Signature : "HPET" [High Precision Event Timer table]
[004h 0004 4] Table Length : 00000038
[008h 0008 1] Revision : 01
[009h 0009 1] Checksum : 89
[00Ah 0010 6] Oem ID : "SUPERM"
[010h 0016 8] Oem Table ID : "SMCI--MB"
[018h 0024 4] Oem Revision : 01072009
[01Ch 0028 4] Asl Compiler ID : "AMI."
[020h 0032 4] Asl Compiler Revision : 00000005
[024h 0036 4] Hardware Block ID : 8086A701
[028h 0040 12] Timer Block Register : [Generic Address Structure]
[028h 0040 1] Space ID : 00 [SystemMemory]
[029h 0041 1] Bit Width : 40
[02Ah 0042 1] Bit Offset : 00
[02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy]
[02Ch 0044 8] Address : 00000000FED00000
[034h 0052 1] Sequence Number : 00
[035h 0053 2] Minimum Clock Ticks : 37EE
[037h 0055 1] Flags (decoded below) : 00
4K Page Protect : 0
64K Page Protect : 0
Raw Table Data: Length 56 (0x38)
0000: 48 50 45 54 38 00 00 00 01 89 53 55 50 45 52 4D HPET8.....SUPERM
0010: 53 4D 43 49 2D 2D 4D 42 09 20 07 01 41 4D 49 2E SMCI--MB. ..AMI.
0020: 05 00 00 00 01 A7 86 80 00 40 00 00 00 00 D0 FE .........@......
0030: 00 00 00 00 00 EE 37 00 ......7.
and for ref
cat /proc/sys/dev/hpet /proc/sys/dev/hpet
cat /proc/sys/dev/hpet/max-user-freq /proc/driver/rtc
64
rtc_time : 01:44:28
rtc_date : 2017-05-13
alrm_time : 21:02:26
alrm_date : 2017-05-13
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1024
max user IRQ frequency : 64
24hr : yes
periodic_IRQ : no
update_IRQ : no
HPET_emulated : no
BCD : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 2:30 HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? PGNet Dev
@ 2017-05-13 17:41 ` Randy Dunlap
2017-05-13 18:26 ` PGNet Dev
2017-05-13 19:45 ` Clemens Ladisch
0 siblings, 2 replies; 24+ messages in thread
From: Randy Dunlap @ 2017-05-13 17:41 UTC (permalink / raw)
To: pgnet.dev, linux-kernel, Clemens Ladisch
[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.
>
> Where's this need to be addressed/fixed? In my config, in kernel code, &/or in BIOS?
>
> info:
>
> @ the mobo,
>
> dmidecode
> # dmidecode 3.0
> Getting SMBIOS data from sysfs.
> SMBIOS 2.7 present.
> 81 structures occupying 3317 bytes.
> Table at 0x000EC200.
>
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
> Vendor: American Megatrends Inc.
> Version: 3.0
> Release Date: 05/26/2015
> Address: 0xF0000
> Runtime Size: 64 kB
> ROM Size: 16384 kB
> Characteristics:
> PCI is supported
> BIOS is upgradeable
> BIOS shadowing is allowed
> Boot from CD is supported
> Selectable boot is supported
> BIOS ROM is socketed
> EDD is supported
> 5.25"/1.2 MB floppy services are supported (int 13h)
> 3.5"/720 kB floppy services are supported (int 13h)
> 3.5"/2.88 MB floppy services are supported (int 13h)
> Print screen service is supported (int 5h)
> 8042 keyboard services are supported (int 9h)
> Serial services are supported (int 14h)
> Printer services are supported (int 17h)
> ACPI is supported
> USB legacy is supported
> BIOS boot specification is supported
> Targeted content distribution is supported
> UEFI is supported
> BIOS Revision: 4.6
>
> In BIOS, HPET's enabled.
How about if you just boot Linux without Xen? Does HPET show up then?
> On boot to Xen on linux64
>
> xl info
> release : 4.11.0-4.gcb15206-default
> version : #1 SMP PREEMPT Thu May 11 07:36:09 UTC 2017 (cb15206)
> machine : x86_64
> nr_cpus : 4
> max_cpu_id : 3
> nr_nodes : 1
> cores_per_socket : 4
> threads_per_core : 1
> cpu_mhz : 3092
> hw_caps : bfebfbff:77faf3ff:2c100800:00000021:00000001:000027ab:00000000:00000100
> virt_caps : hvm hvm_directio
> total_memory : 32493
> free_memory : 25899
> sharing_freed_memory : 0
> sharing_used_memory : 0
> outstanding_claims : 0
> free_cpus : 0
> xen_major : 4
> xen_minor : 9
> xen_extra : .0_04-493
> xen_version : 4.9.0_04-493
> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler : credit2
> xen_pagesize : 4096
> platform_params : virt_start=0xffff800000000000
> xen_changeset :
> xen_commandline : dom0_mem=4096M,max:4096M dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false sync_console=true
> cc_compiler : gcc (SUSE Linux) 4.8.5
> cc_compile_by : abuild
> cc_compile_domain : suse.de
> cc_compile_date : Wed May 10 21:26:38 UTC 2017
> build_id : dde541fac1512c7b1ce17e7496aab57a
> xend_config_format : 4
>
> grep -i hpet /boot/config-4.11.0-4.gcb15206-default
> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y
> CONFIG_HPET=y
> CONFIG_HPET_MMAP=y
> CONFIG_HPET_MMAP_DEFAULT=y
>
>
> , dmesg reports
>
> dmesg | grep -i hpet
> [ 0.000000] Command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8
> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005)
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 0.000000] Kernel command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8
> [ 8.491738] hpet_acpi_add: no address or irqs in _CRS
Above line marks a big failure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> After boot, however, no hpet clocksource is available
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc xen
>
> Disassembling the firmware acpi tables
>
> cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out
> iasl -d /var/tmp/hpet.out
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20140214-64
> Copyright (c) 2000 - 2014 Intel Corporation
>
> Loading Acpi table from file /var/tmp/hpet.out - Length 00000056 (000038)
> Acpi Data Table [HPET] decoded
> Formatted output: /var/tmp/hpet.dsl - 1835 bytes
>
> cat /var/tmp/hpet.dsl
> /*
> * Intel ACPI Component Architecture
> * AML Disassembler version 20140214-64
> * Copyright (c) 2000 - 2014 Intel Corporation
> *
> * Disassembly of /var/tmp/hpet.out, Fri May 12 18:46:28 2017
> *
> * ACPI Data Table [HPET]
> *
> * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
> */
>
> [000h 0000 4] Signature : "HPET" [High Precision Event Timer table]
> [004h 0004 4] Table Length : 00000038
> [008h 0008 1] Revision : 01
> [009h 0009 1] Checksum : 89
> [00Ah 0010 6] Oem ID : "SUPERM"
> [010h 0016 8] Oem Table ID : "SMCI--MB"
> [018h 0024 4] Oem Revision : 01072009
> [01Ch 0028 4] Asl Compiler ID : "AMI."
> [020h 0032 4] Asl Compiler Revision : 00000005
>
> [024h 0036 4] Hardware Block ID : 8086A701
>
> [028h 0040 12] Timer Block Register : [Generic Address Structure]
> [028h 0040 1] Space ID : 00 [SystemMemory]
> [029h 0041 1] Bit Width : 40
> [02Ah 0042 1] Bit Offset : 00
> [02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy]
> [02Ch 0044 8] Address : 00000000FED00000
>
> [034h 0052 1] Sequence Number : 00
> [035h 0053 2] Minimum Clock Ticks : 37EE
> [037h 0055 1] Flags (decoded below) : 00
> 4K Page Protect : 0
> 64K Page Protect : 0
>
> Raw Table Data: Length 56 (0x38)
>
> 0000: 48 50 45 54 38 00 00 00 01 89 53 55 50 45 52 4D HPET8.....SUPERM
> 0010: 53 4D 43 49 2D 2D 4D 42 09 20 07 01 41 4D 49 2E SMCI--MB. ..AMI.
> 0020: 05 00 00 00 01 A7 86 80 00 40 00 00 00 00 D0 FE .........@......
> 0030: 00 00 00 00 00 EE 37 00 ......7.
>
> and for ref
>
> cat /proc/sys/dev/hpet /proc/sys/dev/hpet
> cat /proc/sys/dev/hpet/max-user-freq /proc/driver/rtc
> 64
> rtc_time : 01:44:28
> rtc_date : 2017-05-13
> alrm_time : 21:02:26
> alrm_date : 2017-05-13
> alarm_IRQ : no
> alrm_pending : no
> update IRQ enabled : no
> periodic IRQ enabled : no
> periodic IRQ frequency : 1024
> max user IRQ frequency : 64
> 24hr : yes
> periodic_IRQ : no
> update_IRQ : no
> HPET_emulated : no
> BCD : yes
> DST_enable : no
> periodic_freq : 1024
> batt_status : okay
>
--
~Randy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 17:41 ` Randy Dunlap
@ 2017-05-13 18:26 ` PGNet Dev
2017-05-13 19:28 ` Randy Dunlap
2017-05-13 19:45 ` Clemens Ladisch
1 sibling, 1 reply; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 18:26 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel, Clemens Ladisch
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 hpet acpi_pm
>> [ 8.491738] hpet_acpi_add: no address or irqs in _CRS
>
> Above line marks a big failure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I suspected that's problematic.
In the non-Xen case
dmesg | grep -i hpet
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM
SMCI--MB 01072009 AMI. 00000005)
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 133484882848 ns
[ 0.000000] hpet clockevent registered
[ 0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed90000
[ 1.398047] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 1.404226] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 1.412080] clocksource: Switched to clocksource hpet
[ 3.627234] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes
nvram, hpet irqs
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 18:26 ` PGNet Dev
@ 2017-05-13 19:28 ` Randy Dunlap
2017-05-13 19:38 ` [Xen-devel] " Andrew Cooper
0 siblings, 1 reply; 24+ messages in thread
From: Randy Dunlap @ 2017-05-13 19:28 UTC (permalink / raw)
To: pgnet.dev, linux-kernel, Clemens Ladisch, xen-devel
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:
>
> cat devices/system/clocksource/clocksource0/available
> tsc hpet acpi_pm
Adding xen mailing list:
Is HPET support a known issue in Xen?
release : 4.11.0-4.gcb15206-default
xen_version : 4.9.0_04-493
Original message is here:
http://marc.info/?l=linux-kernel&m=149464267427111&w=2
Thanks.
>>> [ 8.491738] hpet_acpi_add: no address or irqs in _CRS
>>
>> Above line marks a big failure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I suspected that's problematic.
>
> In the non-Xen case
>
> dmesg | grep -i hpet
> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005)
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
> [ 0.000000] hpet clockevent registered
> [ 0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed90000
> [ 1.398047] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
> [ 1.404226] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
> [ 1.412080] clocksource: Switched to clocksource hpet
> [ 3.627234] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
>
--
~Randy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 19:28 ` Randy Dunlap
@ 2017-05-13 19:38 ` Andrew Cooper
2017-05-13 19:49 ` PGNet Dev
0 siblings, 1 reply; 24+ messages in thread
From: Andrew Cooper @ 2017-05-13 19:38 UTC (permalink / raw)
To: Randy Dunlap, pgnet.dev, linux-kernel, Clemens Ladisch, xen-devel
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 show up then?
>> yes, it appears so:
>>
>> cat devices/system/clocksource/clocksource0/available
>> tsc hpet acpi_pm
> Adding xen mailing list:
>
> Is HPET support a known issue in Xen?
What is the issue here?
Xen owns (and may use) any HPETs in the system. They are purposefully
unavailable to even dom0.
~Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 17:41 ` Randy Dunlap
2017-05-13 18:26 ` PGNet Dev
@ 2017-05-13 19:45 ` Clemens Ladisch
2017-05-13 19:52 ` PGNet Dev
1 sibling, 1 reply; 24+ messages in thread
From: Clemens Ladisch @ 2017-05-13 19:45 UTC (permalink / raw)
To: pgnet.dev; +Cc: Randy Dunlap, linux-kernel
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
>>
>> cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out
>> iasl -d /var/tmp/hpet.out
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 registration is
always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c.
Try adding logging to hpet_late_init() to find out why it aborts.
Regards,
Clemens
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 19:38 ` [Xen-devel] " Andrew Cooper
@ 2017-05-13 19:49 ` PGNet Dev
2017-05-13 19:59 ` Andrew Cooper
0 siblings, 1 reply; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 19:49 UTC (permalink / raw)
To: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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 pointed out by Randy.
Following
https://wiki.xen.org/wiki/Xen_power_management#HPET_as_broadcast_timer_source_.28clocksource.29_.3D
there's discussion there re: 'if HPET is available / not missing'.
It appears to be available only booting to non-Xen.
What specific indication does one look for that Xen's using available hpet?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 19:45 ` Clemens Ladisch
@ 2017-05-13 19:52 ` PGNet Dev
0 siblings, 0 replies; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 19:52 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Randy Dunlap, linux-kernel
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 registration is
> always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c.
> Try adding logging to hpet_late_init() to find out why it aborts.
I assume you mean in kernel source code?
I'm using distro packages for both kernel & Xen -- not DIY building.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 19:49 ` PGNet Dev
@ 2017-05-13 19:59 ` Andrew Cooper
2017-05-13 20:05 ` PGNet Dev
0 siblings, 1 reply; 24+ messages in thread
From: Andrew Cooper @ 2017-05-13 19:59 UTC (permalink / raw)
To: pgnet.dev, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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 clocksource, AND reports the hpet boot error pointed out by Randy.
>
> Following
>
> https://wiki.xen.org/wiki/Xen_power_management#HPET_as_broadcast_timer_source_.28clocksource.29_.3D
>
> there's discussion there re: 'if HPET is available / not missing'.
>
> It appears to be available only booting to non-Xen.
>
> What specific indication does one look for that Xen's using available hpet?
>
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
mention of the HPET in there if Xen has found it.
~Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 19:59 ` Andrew Cooper
@ 2017-05-13 20:05 ` PGNet Dev
2017-05-13 20:16 ` Andrew Cooper
2017-05-13 20:28 ` Valentin Vidic
0 siblings, 2 replies; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 20:05 UTC (permalink / raw)
To: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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
> mention of the HPET in there if Xen has found it.
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.
same kernel, no Xen, no such error.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 20:05 ` PGNet Dev
@ 2017-05-13 20:16 ` Andrew Cooper
2017-05-13 21:07 ` PGNet Dev
2017-05-14 17:13 ` Juergen Gross
2017-05-13 20:28 ` Valentin Vidic
1 sibling, 2 replies; 24+ messages in thread
From: Andrew Cooper @ 2017-05-13 20:16 UTC (permalink / raw)
To: pgnet.dev, Randy Dunlap, linux-kernel, Clemens Ladisch,
xen-devel, Juergen Gross
Cc: Jan Beulich
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 dmesg` to get to the hypervisor dmesg log. You should see
>> mention of the HPET in there if Xen has found it.
>
> 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.
>
> same kernel, no Xen, no such error.
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.
http://marc.info/?l=linux-kernel&m=149464267427111&w=2 indicates that
you are using a SuSE hypervisor.
Jan/Juergen: Any ideas? This looks as if it is something local to your
patch queue.
~Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 20:05 ` PGNet Dev
2017-05-13 20:16 ` Andrew Cooper
@ 2017-05-13 20:28 ` Valentin Vidic
2017-05-13 21:06 ` PGNet Dev
1 sibling, 1 reply; 24+ messages in thread
From: Valentin Vidic @ 2017-05-13 20:28 UTC (permalink / raw)
To: PGNet Dev
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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.
>
> same kernel, no Xen, no such error.
Are you sure this is `xl dmesg` and not `dmesg` output?
On Debian jessie it looks like the hypervisor is using
HPET by default as expected:
# xl dmesg | grep -i hpet
(XEN) ACPI: HPET 7986E860, 0038 (r1 SUPERM SMCI--MB 1 INTL 20091013)
(XEN) Platform timer is 14.318MHz HPET
# dmesg | grep -i hpet
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 64.157167] hpet_acpi_add: no address or irqs in _CRS
--
Valentin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 20:28 ` Valentin Vidic
@ 2017-05-13 21:06 ` PGNet Dev
2017-05-13 21:32 ` Valentin Vidic
0 siblings, 1 reply; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 21:06 UTC (permalink / raw)
To: Valentin Vidic
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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 present when booting with Xen.
>>
>> same kernel, no Xen, no such error.
>
> Are you sure this is `xl dmesg`
yep.
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
> and not `dmesg` output?
AND
dmesg | grep -i hpet | grep -vi command
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM
SMCI--MB 01072009 AMI. 00000005)
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 20:16 ` Andrew Cooper
@ 2017-05-13 21:07 ` PGNet Dev
2017-05-14 17:13 ` Juergen Gross
1 sibling, 0 replies; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 21:07 UTC (permalink / raw)
To: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch,
xen-devel, Juergen Gross
Cc: Jan Beulich
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 correct
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 21:06 ` PGNet Dev
@ 2017-05-13 21:32 ` Valentin Vidic
2017-05-13 21:58 ` PGNet Dev
0 siblings, 1 reply; 24+ messages in thread
From: Valentin Vidic @ 2017-05-13 21:32 UTC (permalink / raw)
To: PGNet Dev
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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 you are not missing info from the Xen ring buffer.
It should start with the Xen version like this:
# xl dmesg | head
(XEN) Xen version 4.4.1 (Debian 4.4.1-9+deb8u9) (ijackson@chiark.greenend.org.uk) (gcc (Debian 4.9.2-10) 4.9.2) debug=n Mon May 8 16:01:37 UTC 2017
(XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
(XEN) Command line: placeholder dom0_mem=2048M com2=115200,8n1 console=com2,vga
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
--
Valentin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 21:32 ` Valentin Vidic
@ 2017-05-13 21:58 ` PGNet Dev
2017-05-13 22:15 ` Valentin Vidic
0 siblings, 1 reply; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 21:58 UTC (permalink / raw)
To: Valentin Vidic
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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 caused by console_to_ring boot option.
>
> Better check you are not missing info from the Xen ring buffer.
> It should start with the Xen version like this:
>
Interesting.
With, currently,
GRUB_CMDLINE_LINUX_XEN_REPLACE="... systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8"
and
GRUB_CMDLINE_XEN=" ... console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false sync_console=true"
I've only
xl dmesg | head
299] sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
[ 9.449299] sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
[ 9.449300] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[ 9.449300] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[ 9.449328] sd 1:0:0:0: [sdb] Write Protect is off
[ 9.449328] sd 1:0:0:0: [sdb] Write Protect is off
[ 9.449329] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 9.449329] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 9.449347] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 9.449347] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Whereas in serial console,
Booting `OpenSUSE, with Xen hypervisor'Booting `OpenSUSE, with Xen hypervisor'
Loading Xen 4.9.0_04-493 with Linux 4.11.0-4.gcb15206-default ...Loading Xen 4.9.0_04-493 wit
h Linux 4.11.0-4.gcb15206-default ...
/EndEntire
/EndEntire
file path: file path: /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/
PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1:
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 ]]/HD(2,1000,96000,c5cc9661271
ee648
,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)
/File(\EFI\OPENSUSE)/File(xen-4.9.0_04-493.efi)/File(xen-4.9.0_04-493.efi)/EndEntire
/EndEntire
Xen 4.9.0_04-493 (c/s ) EFI loader
Using configuration file 'xen-4.9.0_04-493.cfg'
vmlinuz-4.11.0-4.gcb15206-default: 0x000000008b986000-0x000000008c06bf60
initrd-4.11.0-4.gcb15206-default: 0x000000008aab2000-0x000000008b985978
0x0000:0x00:0x19.0x0: ROM: 0x10000 bytes at 0x928a7018
0x0000:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x9289e018
0x0000:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x9287d018
__ __ _ _ ___ ___ ___ _ _ _ _ ___ _____
\ \/ /___ _ __ | || | / _ \ / _ \ / _ \| || | | || | / _ \___ /
\ // _ \ '_ \ | || || (_) | | | | | | | | || |_ __| || || (_) ||_ \
/ \ __/ | | | |__ _\__, | |_| | | |_| |__ _|__|__ _\__, |__) |
/_/\_\___|_| |_| |_|(_)/_(_)___/___\___/ |_| |_| /_/____/
|_____|
(XEN) Xen version 4.9.0_04-493 (abuild@suse.de) (gcc (SUSE Linux) 4.8.5) debug=y Wed May 10
21:26:38 UTC 2017
(XEN) Latest ChangeSet:
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=4096M,max:4096M dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=11520
0,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 s
ched_debug reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_
loglvl=all noreboot=false sync_console=true
(XEN) Xen image load base address: 0x8c200000
(XEN) Video information:
(XEN) VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN) 0000000000000000 - 0000000000008000 (reserved)
(XEN) 0000000000008000 - 0000000000048000 (usable)
...
Searching the *console* output for 'hpet',
grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verb
ose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_aspm=off m
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=for
ce,verbose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_asp
=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verb
ose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_aspm=off m
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=for
ce,verbose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_asp
[ 8.489692] hpet_acpi_add: no address or irqs in _CRS
[ 8.489692] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 21:40:15] HVM1 save: HPET
and, still
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Does this perhaps imply that Xen correctly uses HPET
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
, noting:
"If h/w supports per-channel MSI delivery mode (intr via FSB)," it's the best broadcast mechanism known so far"
but that Dom0 does not
current_clocksource
tsc
?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 21:58 ` PGNet Dev
@ 2017-05-13 22:15 ` Valentin Vidic
2017-05-13 23:17 ` PGNet Dev
0 siblings, 1 reply; 24+ messages in thread
From: Valentin Vidic @ 2017-05-13 22:15 UTC (permalink / raw)
To: PGNet Dev
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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: 0000:f0:0f.0
> (XEN) Platform timer is 14.318MHz HPET
I think so, yes.
> but that Dom0 does not
>
> current_clocksource
> tsc
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
select xen by default:
# dmesg | grep -i clocksource
[ 58.944215] Switched to clocksource xen
--
Valentin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 22:15 ` Valentin Vidic
@ 2017-05-13 23:17 ` PGNet Dev
2017-05-14 15:39 ` Andrew Cooper
2017-05-15 18:06 ` Austin S. Hemmelgarn
0 siblings, 2 replies; 24+ messages in thread
From: PGNet Dev @ 2017-05-13 23:17 UTC (permalink / raw)
To: Valentin Vidic
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
But with
clocksource=xen
*explicitly* added
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen
and in *console*, NOT dmesg, output,
grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET
and
dmesg | grep -i clocksource | grep -v line:
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 4.656634] clocksource: Switched to clocksource xen
[ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 23:17 ` PGNet Dev
@ 2017-05-14 15:39 ` Andrew Cooper
2017-05-14 17:41 ` Randy Dunlap
2017-05-15 18:06 ` Austin S. Hemmelgarn
1 sibling, 1 reply; 24+ messages in thread
From: Andrew Cooper @ 2017-05-14 15:39 UTC (permalink / raw)
To: pgnet.dev, Valentin Vidic
Cc: Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc xen
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
>
> But with
>
> clocksource=xen
>
> *explicitly* added
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc xen
> cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
> xen
>
> and in *console*, NOT dmesg, output,
>
> grep -i hpet tmp.txt
> (XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
> (XEN) [VT-D] MSI HPET: 0000:f0:0f.0
> (XEN) Platform timer is 14.318MHz HPET
> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 8.515245] hpet_acpi_add: no address or irqs in _CRS
> [ 8.515245] hpet_acpi_add: no address or irqs in _CRS
> (XEN) [2017-05-13 23:04:27] HVM1 save: HPET
>
>
>
> and
>
> dmesg | grep -i clocksource | grep -v line:
> [ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
> [ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
> [ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 4.656634] clocksource: Switched to clocksource xen
> [ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
>
> jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
>
> 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, but there is no way dom0
will ever be able to use clocksource=hpet when running under Xen.
~Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 20:16 ` Andrew Cooper
2017-05-13 21:07 ` PGNet Dev
@ 2017-05-14 17:13 ` Juergen Gross
1 sibling, 0 replies; 24+ messages in thread
From: Juergen Gross @ 2017-05-14 17:13 UTC (permalink / raw)
To: Andrew Cooper, pgnet.dev, Randy Dunlap, linux-kernel,
Clemens Ladisch, xen-devel
Cc: Jan Beulich
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 Xen has set up in the IDT.
>>>
>>> Use `xl dmesg` to get to the hypervisor dmesg log. You should see
>>> mention of the HPET in there if Xen has found it.
>>
>> 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.
>>
>> same kernel, no Xen, no such error.
>
> We don't have code like that in upstream Xen. No function with that
> name, or a string which looks like that error message.
This is a Linux kernel message.
Juergen
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-14 15:39 ` Andrew Cooper
@ 2017-05-14 17:41 ` Randy Dunlap
0 siblings, 0 replies; 24+ messages in thread
From: Randy Dunlap @ 2017-05-14 17:41 UTC (permalink / raw)
To: Andrew Cooper, pgnet.dev, Valentin Vidic
Cc: linux-kernel, Clemens Ladisch, xen-devel
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
>>
>> 'hpet=force,verbose clocksource=hpet'
>>
>> removed, I end up with
>>
>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> tsc xen
>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> tsc
>>
>> But with
>>
>> clocksource=xen
>>
>> *explicitly* added
>>
>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> tsc xen
>> cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
>> xen
>>
>> and in *console*, NOT dmesg, output,
>>
>> grep -i hpet tmp.txt
>> (XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
>> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
>> (XEN) [VT-D] MSI HPET: 0000:f0:0f.0
>> (XEN) Platform timer is 14.318MHz HPET
>> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
>> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
>> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
>> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
>> [ 8.515245] hpet_acpi_add: no address or irqs in _CRS
>> [ 8.515245] hpet_acpi_add: no address or irqs in _CRS
>> (XEN) [2017-05-13 23:04:27] HVM1 save: HPET
>>
>>
>>
>> and
>>
>> dmesg | grep -i clocksource | grep -v line:
>> [ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
>> [ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
>> [ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
>> [ 4.656634] clocksource: Switched to clocksource xen
>> [ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
>>
>> jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
>>
>> 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.
I agree. Are you (pgnet.dev) just curious about why the Xen kernel does
not expose HPET as a clocksource or is not having it causing some problem
for you or some specific software application?
> The Linux HEPT error messages are non-ideal, but there is no way dom0
> will ever be able to use clocksource=hpet when running under Xen.
--
~Randy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-13 23:17 ` PGNet Dev
2017-05-14 15:39 ` Andrew Cooper
@ 2017-05-15 18:06 ` Austin S. Hemmelgarn
2017-05-17 0:12 ` PGNet Dev
2017-05-17 0:15 ` PGNet Dev
1 sibling, 2 replies; 24+ messages in thread
From: Austin S. Hemmelgarn @ 2017-05-15 18:06 UTC (permalink / raw)
To: pgnet.dev, Valentin Vidic
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
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
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc xen
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
>
> But with
>
> clocksource=xen
>
> *explicitly* added
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc xen
> cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
> xen
>
> and in *console*, NOT dmesg, output,
>
> grep -i hpet tmp.txt
> (XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
> (XEN) [VT-D] MSI HPET: 0000:f0:0f.0
> (XEN) Platform timer is 14.318MHz HPET
> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
> [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [ 8.515245] hpet_acpi_add: no address or irqs in _CRS
> [ 8.515245] hpet_acpi_add: no address or irqs in _CRS
> (XEN) [2017-05-13 23:04:27] HVM1 save: HPET
>
>
>
> and
>
> dmesg | grep -i clocksource | grep -v line:
> [ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
> [ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
> [ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 4.656634] clocksource: Switched to clocksource xen
> [ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
>
> jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
>
> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
That depends on what you mean by everything correctly using the HPET.
Using clocksource=xen (or autoselecting it) will cause the kernel to get
timing info from Xen. If you're running as a guest, this is absolutely
what you want (unless you're using HVM), and with possible limited and
extremely specific exceptions, this is almost certainly what you want in
Domain-0 as well. Given that Xen is using the HPEt for timing itself,
using clocksource=xen will result in Linux _indirectly_ using the HPET
through Xen without involving the HPET driver (in essence, Xen is your
HPET driver in this situation), which will get you essentially the same
precision that you would get by using the HPET directly.
So, if you just want the precision offered by the HPET, then yes, you
are getting the same thing through the Xen clocksource.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-15 18:06 ` Austin S. Hemmelgarn
@ 2017-05-17 0:12 ` PGNet Dev
2017-05-17 0:15 ` PGNet Dev
1 sibling, 0 replies; 24+ messages in thread
From: PGNet Dev @ 2017-05-17 0:12 UTC (permalink / raw)
To: Austin S. Hemmelgarn, Valentin Vidic
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
2017-05-15 18:06 ` Austin S. Hemmelgarn
2017-05-17 0:12 ` PGNet Dev
@ 2017-05-17 0:15 ` PGNet Dev
1 sibling, 0 replies; 24+ messages in thread
From: PGNet Dev @ 2017-05-17 0:15 UTC (permalink / raw)
To: Austin S. Hemmelgarn, Valentin Vidic
Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel
(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, but there is no way dom0
> will ever be able to use clocksource=hpet when running under Xen.
What I'm trying to achieve is to
(a) understand, in general
(b) correctly implement HPET usage in Xen
&
(c) understand &, as needed, remediate the warnings/error message that seem(ed) to be associated
I.e. -- what exactly needs be done, and what should be the observable results, when "using" HPET with Xen. It's simply not obvious from the docs.
The docs here,
https://wiki.xen.org/wiki/Xen_power_management
are ... somewhat challenging:
"By far Xen3.4 supports PIT/HPET as the broadcast source.
...
HPET as broadcast timer source (clocksource) =
...
HPET can delivery timely wakeup event to CPUs sleep in deep C-states with negligible overhead, as stated earlier. But HPET mode being used does make some differences to worthy of our noting:
If h/w supports per-channel MSI delivery mode (intr via FSB), it's the best broadcast mechanism known so far.
...
"
??
OTOH, this comment:
On 5/15/17 11:06 AM, Austin S. Hemmelgarn wrote:
> That depends on what you mean by everything correctly using the HPET.
> Using clocksource=xen (or autoselecting it) will cause the kernel to get
> timing info from Xen. If you're running as a guest, this is absolutely
> what you want (unless you're using HVM), and with possible limited and
> extremely specific exceptions, this is almost certainly what you want in
> Domain-0 as well. Given that Xen is using the HPEt for timing itself,
> using clocksource=xen will result in Linux _indirectly_ using the HPET
> through Xen without involving the HPET driver (in essence, Xen is your
> HPET driver in this situation), which will get you essentially the same
> precision that you would get by using the HPET directly.
>
> So, if you just want the precision offered by the HPET, then yes, you
> are getting the same thing through the Xen clocksource.
Is legible, understandable & helpfully informative. (Thanks, Austin! Valentin's comments helped as well.)
'tho further detail on common &/or "limited and extremely specific exceptions" use-cases of PVH, HVM, PVHVM & HVM2 will be useful, I'd heartily recommend that some version of Austin's comment be added to the docs/wiki as a nice doc-step forward.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-05-17 0:15 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-13 2:30 HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? PGNet Dev
2017-05-13 17:41 ` Randy Dunlap
2017-05-13 18:26 ` PGNet Dev
2017-05-13 19:28 ` Randy Dunlap
2017-05-13 19:38 ` [Xen-devel] " Andrew Cooper
2017-05-13 19:49 ` PGNet Dev
2017-05-13 19:59 ` Andrew Cooper
2017-05-13 20:05 ` PGNet Dev
2017-05-13 20:16 ` Andrew Cooper
2017-05-13 21:07 ` PGNet Dev
2017-05-14 17:13 ` Juergen Gross
2017-05-13 20:28 ` Valentin Vidic
2017-05-13 21:06 ` PGNet Dev
2017-05-13 21:32 ` Valentin Vidic
2017-05-13 21:58 ` PGNet Dev
2017-05-13 22:15 ` Valentin Vidic
2017-05-13 23:17 ` PGNet Dev
2017-05-14 15:39 ` Andrew Cooper
2017-05-14 17:41 ` Randy Dunlap
2017-05-15 18:06 ` Austin S. Hemmelgarn
2017-05-17 0:12 ` PGNet Dev
2017-05-17 0:15 ` PGNet Dev
2017-05-13 19:45 ` Clemens Ladisch
2017-05-13 19:52 ` PGNet Dev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).