kernel since 5.6 do not boot anymore on Apple PowerBook

[Gabriel Paubert]

On Thu, Aug 27, 2020 at 12:39:06PM +0200, Christophe Leroy wrote:
> Hi,
> 
> Le 27/08/2020 à 10:28, Giuseppe Sacco a écrit :
> > Il giorno gio, 27/08/2020 alle 09.46 +0200, Giuseppe Sacco ha scritto:
> > > Il giorno gio, 27/08/2020 alle 00.28 +0200, Giuseppe Sacco ha scritto:
> > > > Hello Christophe,
> > > > 
> > > > Il giorno mer, 26/08/2020 alle 15.53 +0200, Christophe Leroy ha
> > > > scritto:
> > > > [...]
> > > > > If there is no warning, then the issue is something else, bad luck.
> > > > > 
> > > > > Could you increase the loglevel and try again both with and without
> > > > > VMAP_STACK ? Maybe we'll get more information on where it stops.
> > > > 
> > > > The problem is related to the CPU frequency changes. This is where the
> > > > system stop: cpufreq get the CPU frequency limits and then start the
> > > > default governor (performance) and then calls function
> > > > cpufreq_gov_performance_limits() that never returns.
> > > > 
> > > > Rebuilding after enabling pr_debug for cpufreq.c, I've got some more
> > > > lines of output:
> > > > 
> > > > cpufreq: setting new policy for CPU 0: 667000 - 867000 kHz
> > > > cpufreq: new min and max freqs are 667000 - 867000 kHz
> > > > cpufreq: governor switch
> > > > cpufreq: cpufreq_init_governor: for CPU 0
> > > > cpufreq: cpufreq_start_governor: for CPU 0
> > > > cpufreq: target for CPU 0: 867000 kHz, relation 1, requested 867000 kHz
> > > > cpufreq: __target_index: cpu: 0, oldfreq: 667000, new freq: 867000
> > > > cpufreq: notification 0 of frequency transition to 867000 kHz
> > > > cpufreq: saving 133328 as reference value for loops_per_jiffy; freq is 667000 kHz
> > > > 
> > > > no more lines are printed. I think this output only refers to the
> > > > notification sent prior to the frequency change.
> > > > 
> > > > I was thinking that selecting a governor that would run at 667mHz would
> > > > probably skip the problem. I added cpufreq.default_governor=powersave
> > > > to the command line parameters but it did not work: the selected
> > > > governor was still performance and the system crashed.
> > > 
> > > I kept following the thread and found that CPU frequency is changed in
> > > function pmu_set_cpu_speed() in file drivers/cpufreq/pmac32-cpufreq.c.
> > > As first thing, the function calls the macro preempt_disable() and this
> > > is where it stops.
> > 
> > Sorry, I made a mistake. The real problem is down, on the same
> > function, when it calls low_sleep_handler(). This is where the problem
> > probably is.
> > 
> 
> 
> Great, you spotted the problem.
> 
> I see what it is, it is in low_sleep_handler() in
> arch/powerpc/platforms/powermac/sleep.S
> 
> All critical registers are saved on the stack. At restore, they are restore
> BEFORE re-enabling MMU (because they are needed for that). But when we have
> VMAP_STACK, the stack can hardly be accessed without the MMU enabled.
> tophys() doesn't work for virtual stack addresses.
> 
> Therefore, the low_sleep_handler() has to be reworked for using an area in
> the linear mem instead of the stack.

Actually there is already one, at the end of sleep.S, there is a 4 byte
area called sleep_storage. It should be enough to move there the CPU state
which has to be restored before the MMU is enabled:
- SDR1
- BATs
- SPRG (they might stay on the stack by reordering the code unless I
  miss something)

Note that save_cpu_setup/restore_cpu_setup also use another static
storage area to save other SPRs.

Using static area would not work on SMP, but all PPC based Apple laptops
are single core and single thread.

	Gabriel