On Tue, Feb 15, 2022 at 09:33:23AM +0530, Sai Prakash Ranjan wrote: > Hi Mark, > > On 2/14/2022 8:46 PM, Mark Rutland wrote: > > Hi, > > > > On Thu, Feb 10, 2022 at 07:26:32PM +0530, Sai Prakash Ranjan wrote: > > > From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx> > > > > > > Some debuggers, such as Trace32 from Lauterbach GmbH, do not handle > > > reads/writes from/to DCC on secondary cores. Each core has its > > > own DCC device registers, so when a core reads or writes from/to DCC, > > > it only accesses its own DCC device. Since kernel code can run on > > > any core, every time the kernel wants to write to the console, it > > > might write to a different DCC. > > > > > > In SMP mode, Trace32 creates multiple windows, and each window shows > > > the DCC output only from that core's DCC. The result is that console > > > output is either lost or scattered across windows. > > This has been the Linux behaviour since the dawn of time, so why is this not > > considered to be a bug in the tools? Why can't Lauterbach add an option to > > treat the cores as one? > > More like a feature request than a bug? And why would tools add such a > feature when > it is the kernel which runs in SMP mode? Shouldn't kernel be the one having > such a feature > because there would be number of such tools with the same issue and we can't > send a feature > request to all those tool vendors to add this feature right. Instead adding > this in the kernel would > avoid all these centrally at one place. Please fix this in userspace. > > Importantly, with hotplug we *cannot* guarantee that all messages will go to > > the same CPU anyway, since that could be offlined (even if it is CPU 0), so in > > general we cann't provide a guarantee here. > > Right that is true, in case of CPU hotplug this would be pretty much broken > if CPU0 is offlined. > We use these during initial bringup stage of SoCs when we don't have debug > UART console up and running > and at the time we don't much care for testing out hotplugging the CPUs and > let alone trying out > to offline CPU0 which we use and shoot our own foot :) > > Given this is mostly a debug feature, we don't mind if this doesn't > guarantee to work in hotplug scenario. We do not get to choose this type of thing. Either it will work properly, or not. Offlineing cpu 0 happens with power management situations, right? Especially with big/little systems, if CPU0 was a big one, you would remove it while only the little ones were running. I still feel this should all be handled in userspace. Especially given the problems that this patch is having with being tested properly :( thanks, greg k-h
