Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
(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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
(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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 (XEN) [VT-D] MSI HPET: :f0:0f.0 (XEN) Platform timer is 14.318MHz HPET [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [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.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.004000] clocksource: xen: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.375709] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [4.656634] clocksource: Switched to clocksource xen [8.912897] clocksource: tsc: mask: 0x 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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 (XEN) [VT-D] MSI HPET: :f0:0f.0 (XEN) Platform timer is 14.318MHz HPET [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [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.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.004000] clocksource: xen: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.375709] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [4.656634] clocksource: Switched to clocksource xen [8.912897] clocksource: tsc: mask: 0x 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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 >> (XEN) [VT-D] MSI HPET: :f0:0f.0 >> (XEN) Platform timer is 14.318MHz HPET >> [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM >> SMCI--MB 01072009 AMI. 00 >> [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 >> [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM >> SMCI--MB 01072009 AMI. 00 >> [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 >> [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.00] clocksource: refined-jiffies: mask: 0x >> max_cycles: 0x, max_idle_ns: 7645519600211568 ns >> [0.004000] clocksource: xen: mask: 0x >> max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns >> [0.375709] clocksource: jiffies: mask: 0x >> max_cycles: 0x, max_idle_ns: 764504178510 ns >> [4.656634] clocksource: Switched to clocksource xen >> [8.912897] clocksource: tsc: mask: 0x >> 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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 >> (XEN) [VT-D] MSI HPET: :f0:0f.0 >> (XEN) Platform timer is 14.318MHz HPET >> [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM >> SMCI--MB 01072009 AMI. 00 >> [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 >> [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM >> SMCI--MB 01072009 AMI. 00 >> [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 >> [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.00] clocksource: refined-jiffies: mask: 0x >> max_cycles: 0x, max_idle_ns: 7645519600211568 ns >> [0.004000] clocksource: xen: mask: 0x >> max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns >> [0.375709] clocksource: jiffies: mask: 0x >> max_cycles: 0x, max_idle_ns: 764504178510 ns >> [4.656634] clocksource: Switched to clocksource xen >> [8.912897] clocksource: tsc: mask: 0x >> 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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 > (XEN) [VT-D] MSI HPET: :f0:0f.0 > (XEN) Platform timer is 14.318MHz HPET > [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM > SMCI--MB 01072009 AMI. 00 > [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 > [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM > SMCI--MB 01072009 AMI. 00 > [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 > [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.00] clocksource: refined-jiffies: mask: 0x > max_cycles: 0x, max_idle_ns: 7645519600211568 ns > [0.004000] clocksource: xen: mask: 0x > max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns > [0.375709] clocksource: jiffies: mask: 0x > max_cycles: 0x, max_idle_ns: 764504178510 ns > [4.656634] clocksource: Switched to clocksource xen > [8.912897] clocksource: tsc: mask: 0x > 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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 > (XEN) [VT-D] MSI HPET: :f0:0f.0 > (XEN) Platform timer is 14.318MHz HPET > [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM > SMCI--MB 01072009 AMI. 00 > [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 > [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM > SMCI--MB 01072009 AMI. 00 > [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 > [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.00] clocksource: refined-jiffies: mask: 0x > max_cycles: 0x, max_idle_ns: 7645519600211568 ns > [0.004000] clocksource: xen: mask: 0x > max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns > [0.375709] clocksource: jiffies: mask: 0x > max_cycles: 0x, max_idle_ns: 764504178510 ns > [4.656634] clocksource: Switched to clocksource xen > [8.912897] clocksource: tsc: mask: 0x > 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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 (XEN) [VT-D] MSI HPET: :f0:0f.0 (XEN) Platform timer is 14.318MHz HPET [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [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.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.004000] clocksource: xen: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.375709] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [4.656634] clocksource: Switched to clocksource xen [8.912897] clocksource: tsc: mask: 0x 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?
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0xfed0 (XEN) [VT-D] MSI HPET: :f0:0f.0 (XEN) Platform timer is 14.318MHz HPET [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 00 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [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.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.004000] clocksource: xen: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.375709] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [4.656634] clocksource: Switched to clocksource xen [8.912897] clocksource: tsc: mask: 0x 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?
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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 > 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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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 > 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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0x8b986000-0x8c06bf60 initrd-4.11.0-4.gcb15206-default: 0x8aab2000-0x8b985978 0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x928a7018 0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x9289e018 0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x9287d018 __ ___ _ ___ ___ ___ _ _ _ _ ___ _ \ \/ /___ _ __ | || | / _ \ / _ \ / _ \| || || || | / _ \___ / \ // _ \ '_ \ | || || (_) | | | | | | | | || |_ __| || || (_) ||_ \ / \ __/ | | | |__ _\__, | |_| | | |_| |__ _|__|__ _\__, |__) | /_/\_\___|_| |_||_|(_)/_(_)___/___\___/ |_| |_| /_// |_| (XEN) Xen version 4.9.0_04-493 (abu...@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: 0x8c20 (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) - 8000 (reserved) (XEN) 8000 - 00048000 (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: 0xfed0 (XEN) [VT-D] MSI HPET: :f0:0f.0 (XEN) Platform timer is 14.318MHz HPET =xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verb
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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: 0x8b986000-0x8c06bf60 initrd-4.11.0-4.gcb15206-default: 0x8aab2000-0x8b985978 0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x928a7018 0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x9289e018 0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x9287d018 __ ___ _ ___ ___ ___ _ _ _ _ ___ _ \ \/ /___ _ __ | || | / _ \ / _ \ / _ \| || || || | / _ \___ / \ // _ \ '_ \ | || || (_) | | | | | | | | || |_ __| || || (_) ||_ \ / \ __/ | | | |__ _\__, | |_| | | |_| |__ _|__|__ _\__, |__) | /_/\_\___|_| |_||_|(_)/_(_)___/___\___/ |_| |_| /_// |_| (XEN) Xen version 4.9.0_04-493 (abu...@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: 0x8c20 (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) - 8000 (reserved) (XEN) 8000 - 00048000 (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: 0xfed0 (XEN) [VT-D] MSI HPET: :f0:0f.0 (XEN) Platform timer is 14.318MHz HPET =xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verb
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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) (ijack...@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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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) (ijack...@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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 0005) [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [1.365876] hpet_acpi_add: no address or irqs in _CRS
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 0005) [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [1.365876] hpet_acpi_add: no address or irqs in _CRS
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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--MB1 INTL 20091013) (XEN) Platform timer is 14.318MHz HPET # dmesg | grep -i hpet [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [ 64.157167] hpet_acpi_add: no address or irqs in _CRS -- Valentin
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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--MB1 INTL 20091013) (XEN) Platform timer is 14.318MHz HPET # dmesg | grep -i hpet [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [ 64.157167] hpet_acpi_add: no address or irqs in _CRS -- Valentin
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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=149464267427111=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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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=149464267427111=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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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?
Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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?
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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=149464267427111=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.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB > 01072009 AMI. 0005) > [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 > [0.00] clocksource: hpet: mask: 0x max_cycles: 0x, > max_idle_ns: 133484882848 ns > [0.00] hpet clockevent registered > [0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed9 > [1.398047] hpet0: at MMIO 0xfed0, 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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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=149464267427111=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.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB > 01072009 AMI. 0005) > [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 > [0.00] clocksource: hpet: mask: 0x max_cycles: 0x, > max_idle_ns: 133484882848 ns > [0.00] hpet clockevent registered > [0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed9 > [1.398047] hpet0: at MMIO 0xfed0, 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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 0005) [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.00] clocksource: hpet: mask: 0x max_cycles: 0x, max_idle_ns: 133484882848 ns [0.00] hpet clockevent registered [0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed9 [1.398047] hpet0: at MMIO 0xfed0, 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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 0005) [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.00] clocksource: hpet: mask: 0x max_cycles: 0x, max_idle_ns: 133484882848 ns [0.00] hpet clockevent registered [0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed9 [1.398047] hpet0: at MMIO 0xfed0, 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
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
[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 0x, DMI type 0, 24 bytes > BIOS Information > Vendor: American Megatrends Inc. > Version: 3.0 > Release Date: 05/26/2015 > Address: 0xF > 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:0021:0001:27ab::0100 > 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=0x8000 > 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.00] Command line: root=/dev/mapper/VG0_ROOT rd.shell >
Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
[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 0x, DMI type 0, 24 bytes > BIOS Information > Vendor: American Megatrends Inc. > Version: 3.0 > Release Date: 05/26/2015 > Address: 0xF > 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:0021:0001:27ab::0100 > 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=0x8000 > 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.00] Command line: root=/dev/mapper/VG0_ROOT rd.shell >
HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 3.0 Release Date: 05/26/2015 Address: 0xF 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:0021:0001:27ab::0100 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=0x8000 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.00] 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
HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
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 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 3.0 Release Date: 05/26/2015 Address: 0xF 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:0021:0001:27ab::0100 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=0x8000 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.00] 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
