On Wed, 2014-12-10 at 17:50 -0600, Scott Wood wrote: > On Wed, 2014-12-10 at 13:14 +1100, Michael Ellerman wrote: > > On Tue, 2014-12-09 at 18:14 -0600, Scott Wood wrote: > > > What benefit is there to ignoring "scripture" here? Going from an easy > > > to use command line option to needing to mess around with the dts file > > > is not a usability improvement. If you want to make it Freescale-only, > > > fine. If you want to push me to fix the problems with the > > > implementation, fine. > > > > It's easy to use but it doesn't necessarily work. > > > > You said in your other mail to Greg "Sometimes it's useful to ensure that > > the > > second thread has never run when debugging a problem.". > > > > But you don't know that, for all you know your firmware has started the > > thread > > and it's busy looping somewhere. Perhaps you guys know that your firmware > > doesn't do that, but it's still a hack. > > I know that our firmware doesn't do that, and I can verify by reading > the relevant register.
Lucky you :) > > We end up with cpus in the present map, but we have no idea where they are > > or > > what they are doing. > > Can we check smt-enabled a little earlier and refrain from marking the > secondary threads as present if smt is disabled? We could, and that would make the semantics much saner. But it would actually be exactly the opposite of what the folks who originally hit this bug want to happen. They are using it as a shortcut for cpu hotunplug, ie. they want the threads asleep in Linux ready to be hotplugged back in. This is why I wanted to remove it, because those are both valid expectations of what smt-enabled=off should do, but they are mutually exclusive. Not to mention that the current code doesn't implement either of those properly. Anyway for now we should just ignore it on powernv. We can look at doing something saner in general in future. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
