On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote: > On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: >> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote: >>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@xxxxxxxxxxxxx> 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? 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). 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? -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
