On Thu, Aug 31, 2017 at 05:31:28PM +0200, Valentin Vidic wrote:
> The following behavior of the steal counter is observed with
> Xen 4.8.1 in a guest running 4.9 kernel (Debian stretch):
>
> $ while sleep 1; do head -1 /proc/stat; done
> cpu 1556 0 1429 314195002 5529 0 64 143704
On Mon, Jul 31, 2017 at 09:09:19AM +0800, Dongli Zhang wrote:
> To verify whether the above patch would help, please check the nr_grant_frames
> value in guest domU. If this value is exactly the same of maximum grant frames
> (by default, xen mainline uses 32) and the number of free grant reference
| ds0 | pg: 161/1056
[ 2138.179507] xen-blkback: (5.xvda-0): oo 0 | rd 137 | wr 16 | f
3433 | ds0 | pg: 161/1056
[ 2148.187460] xen-blkback: (5.xvda-0): oo 0 | rd0 | wr 25 | f
3448 | ds0 | pg: 161/1056
Signed-off-by: Valentin Vidic
---
drivers/block/xen
On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote:
> Does this perhaps imply that Xen correctly uses HPET
>
> (XEN) [VT-D] MSI HPET: :f0:0f.0
> (XEN) Platform timer is 14.318MHz HPET
I think so, yes.
> but that Dom0 does not
>
> current_clocksource
>
On Sat, May 13, 2017 at 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.
>
> sam
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 y
