[PATCH] PPC: Don't sync timebase when inside VM

[McClintock Matthew-B29882]

On Thu, Mar 8, 2012 at 12:43 PM, Scott Wood <scottwood at freescale.com> wrote:
> On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote:
>> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood at freescale.com> wrote:
>>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>>>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood at freescale.com> wrote:
>>>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>>>
>>>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>>>> hypervisor or no.
>>>>>>
>>>>>> The code says "if the kexec config option is enabled, do the sync". I'm fairly sure it's there for a reason.
>>>>>
>>>>> Sigh.  I forgot about that.  It's because instead of doing kexec the
>>>>> simple way, we actually physically reset the core.  We really shouldn't
>>>>> do that.  And we *really* shouldn't do it just because CONFIG_KEXEC is
>>>>> defined, regardless of whether we're actually booting from kexec.
>>>>
>>>> How would one rocver a core that's off in the weeds?
>>>
>>> System reset?
>>
>> kdump restarts a kernel using a reserved memory region to inspect the
>> memory of the crashed kernel. Wouldn't system reset cause issues here?
>
> Oh, kdump.
>
> Maybe in that case, go ahead and reset the other cores (or halt them via
> some other means), but don't do anything with them.  Just boot a single
> core in the dump kernel, do the dumping, then reset the system?

Yes, we could do one core here... but is it worthwhile to do kexec and
kdump differently?

> Or if you must sync the timebase in Linux, do it the way U-Boot does
> (and skip it if you don't have access to the relevant CCSR bits).

Ok - I've never even looked at how the timebase sync was done in Linux
or u-boot. Just enabled the timebase sync

> Are I/O devices a problem with kdump and not resetting the system,
> especially on some of our chips where certain I/O devices are difficult
> to reset?

Anything still occurring will be problematic and *possibly* prevent us
from determining what caused the actual crash.

-M