On Thu, Mar 8, 2012 at 12:43 PM, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: > 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? 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 -- 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
