Re: Test results on Unisys ES7000 64x 256gb using unstablec/s 16693 on 3.2.0 Release Candidate

[Bill Burns <bburns@redhat.com>]

Bill Burns wrote:
> Bill Burns wrote:
>> Bill Burns wrote:
>>> Ian Pratt wrote:
>>>>>>> No, I have not tried on 3.2.0. Will see if I can at some
>>>>>>> point...
>>>>>> Also, do you have any more info to share on what actually goes wrong
>>>>> when
>>>>>> dom0 has 'too much' memory?
>>>>>>
>>>>> The dom0 kernel spits out messages like the following starting around
>>>>> the
>>>>> init of cpu1 time, and periodically thereafter.
>>>>>
>>>>> Timer ISR/0: Time went backwards: delta=-50206266948
>>>> delta_cpu=13733052
>>>>> shadow=8186343367 off=13649733458 processed=72042343367
>>>>> cpu_processed=21822343367
>>>>>
>>>>> Eventually just hanging (or making such slow progress to be
>>>>> effectively hung).
>>>> How many CPUs does the system have? Does the same large memory issue
>>>> occur if you have fewer physical CPUs?
>>>>
>>> The system has 64 but is only built for 32, so the others are
>>> ignored. Don't know if the problem happens with less CPUs at
>>> this point. Hope to get more data soon...
>>>
>> Interestingly, the symptom seems to disappear with a
>> Hypervisor built to support all 64 CPUs. But I need to
>> get more time on the system to say that for sure.
>>
> Disregard the previous. It still happens. Continuing to debug..
> 
>  

<snip>
Ok, some progress. Background is that 3.1.2 (and 3.1.3 at least
as it was a wek or two ago) fails to boot on a 64 CPU es7000 with
over 112GB of memory. This is with both HV & dom0 being x86_64.
The symptom is that the dom0 kernel gets time went backwards
error during init.

The patch at which this first fails is 15137, which is the patch
that introduces using the ACPI PM timer as the clock
source. If I include the next patch (that allows for clock
selection) and choose pit as clock source the system boots
fine. Without the arg the ACPI timer is used and I get the hang.

Don't know if this is unique to this platform or a
general issue with large memory. Seems that most folks
smartly limit the dom0 memory well below 112GB.

Note I have not yet tried 3.2. Also note that the
patch determination was not a pure binary search.
There is a later patch (15194) specific to es7000 that
I pulled in and the second patch (15045) breaks things
during the HV init without some later patches, so it
was left out.

 Bill