[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xen 4.14.3 incorrect (~3x) cpu frequency reported


  • To: James Dingwall <james-xen@xxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 6 Jan 2022 17:00:59 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tKhCCh0AFmvjkEUf+eM5tBqk8NLrqZ5CSvwor2o6/rM=; b=mwUkxQiZhwmBLScAA0iJ6EkP3LECeYGoSt23o/iKS4YRve15jD7WLiewrjE2/3ecXCgx8/5okqKe4dK+NMLnFBaHVAVh5i46S2iGrzGNivmXgh9qGL8xLzDzOHclcyadvGHlWx2reonkz6EBfUOiLLpRXCNBIVYZC8I2Pd+zVvekAs5FoovE8Y/OkhoOWEE13UxzvL008Lh91vT7tjMdwXHMW+3L1Uz/uBV/T0mOyVOCKzu0u/eRPIUcFkgg17RgiPtjc19wIPGJLs5D4VKk+HZcuwJEZyeXzPBBzySKsYiWuE6O6a4m3sBQtg9v1eOE3ZY3uMrghfGbtDAMHvsebw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nvCpeCf3WqcgGm/38I+rtN+5WL+adhEy68QM/nFytRJ1wDFcxnfWUaP+bObguTxX6i2BDOIC7+ITsyTVjBbH1VCrbOvLctcMbLAo5JXW66HNO0de0dbyuVGCsam4J9/PmUBGYHkztcB6+DiXiiv4FOA/ByX1T3ysQmOVatA1YJh0CMZ61k2W5gOZ9LU/UFGkH44sRKoWJMjw4oo6mu2BWzIXHK078feEbGgiPEcvaizt8J1xEtZF2GCxCHtf1zEvSlBYhx63/qmWEqY5XHnHhN9ec/VtFVYL0298QwN7S3LFlUPnTgQc+hFzzu4/HaHISLpEHoQZEy8rdjNhSougyw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: alexander.rossa@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 06 Jan 2022 16:01:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.01.2022 16:08, James Dingwall wrote:
>>> On Wed, Jul 21, 2021 at 12:59:11PM +0200, Jan Beulich wrote:                
>>>                                                             
>>>> On 21.07.2021 11:29, James Dingwall wrote:                                 
>>>>                                                             
>>>>> We have a system which intermittently starts up and reports an incorrect 
>>>>> cpu frequency:                                               
> ...
>>> I'm sorry to ask, but have you got around to actually doing that? Or
>>> else is resolving this no longer of interest?
> 
> We have experienced an occurence of this issue on 4.14.3 with 'loglvl=all'
> present on the xen command line.  I have attached the 'xl dmesg' output for
> the fast MHz boot, the diff from the normal case is small so I've not added
> that log separately:
> 
> --- normal-mhz/xl-dmesg.txt     2022-01-06 14:13:47.231465234 +0000
> +++ funny-mhz/xl-dmesg.txt      2022-01-06 13:45:43.825148510 +0000
> @@ -211,7 +211,7 @@
>  (XEN)  cap enforcement granularity: 10ms
>  (XEN) load tracking window length 1073741824 ns
>  (XEN) Platform timer is 24.000MHz HPET
> -(XEN) Detected 2294.639 MHz processor.
> +(XEN) Detected 7623.412 MHz processor.
>  (XEN) EFI memory map:
>  (XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
>  (XEN)  0000000008000-000000003cfff type=7 attr=000000000000000f
> @@ -616,6 +616,7 @@
>  (XEN) PCI add device 0000:b7:00.1
>  (XEN) PCI add device 0000:b7:00.2
>  (XEN) PCI add device 0000:b7:00.3
> +(XEN) Platform timer appears to have unexpectedly wrapped 10 or more times.
>  (XEN) [VT-D]d0:PCIe: unmap 0000:65:00.2
>  (XEN) [VT-D]d32753:PCIe: map 0000:65:00.2
>  (XEN) [VT-D]d0:PCIe: unmap 0000:65:00.1

Thanks. In an earlier mail the reported value was 6895.384 MHz, but I
guess that was on a different system (with a base freq of 2200 MHz).
I wonder how stable the too high value is ...

For the moment I have only one possibly explanation: A SMI hitting in
the middle of the tail of init_hpet() (or init_pmtimer()), taking long
enough to cause the function to return way too large a number. With a
50ms calibration period that would be about 166ms. I vaguely recall
having heard of SMI potentially taking this long.

While I can see ways to reduce the likelihood of hitting the issue,
for now I lack a good idea how to avoid the problem altogether. I'll
try to get around to at least put together a debugging patch to
hopefully confirm the vague theory.

Jan

> I also have the dom0 kernel dmesg available if that would be useful but I've
> left it off initially because the log is quite large.  I don't see much in
> the diff between boots except where speed/times are reported and where things
> are initialised in a slightly different order.
> 
> Thanks,
> James




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.