Fwd: Fwd: X stopped working with 5.14 on iBook

Wed Nov 3 09:27:46 AEDT 2021

On Mon Nov 1, 2021 at 9:20 PM CDT, Finn Thain wrote:
> Hi Christopher,
>
> After many builds and tests, Stan and I were able to determine that this
> regression only affects builds with CONFIG_USER_NS=y. That is,
>
> d3ccc9781560 + CONFIG_USER_NS=y --> fail
> d3ccc9781560 + CONFIG_USER_NS=n --> okay
> d3ccc9781560~ + CONFIG_USER_NS=y --> okay
> d3ccc9781560~ + CONFIG_USER_NS=n --> okay
>
> Stan also tested a PowerMac G3 system and found that the regression is
> not
> present there. Thus far, only PowerMac G4 systems are known to be
> affected
> (Stan's Cube and Riccardo's PowerBook).
>
> I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
> Unexpectedly, this build had the same issue. So, it appears there are
> multiple bad commits that produce this Xorg failure, of which
> d3ccc9781560
> is just the first.
>
> But there's no easy way to identify the other bad commits using
> bisection.
> So I've addressed this message to you. Can you help fix this regression?

Hi,

I switched email addresses a few times since that patch - also I am not
employed at IBM any longer so that @linux.ibm.com email doesn't work
either. In any case, I'll take a look and see if I can figure out what's
going on. I do actually have a PowerBook G4 here (if it can be coaxed to
boot) that could help me root cause this.

Thanks!
Chris R.

>
> Regards,
> Finn
>
> On Fri, 22 Oct 2021, Christophe Leroy wrote:
>
> > ...
> > > 
> > > -------- Forwarded Message --------
> > > Subject: Fwd: X stopped working with 5.14 on iBook
> > > Date: Fri, 22 Oct 2021 11:35:21 -0600
> > > From: Stan Johnson
> > > To: Christopher M. Riedl <cmr at codefail.de>
> > > CC: Finn Thain <fthain at fastmail.com.au>
> > > 
> > > Hello Christopher Riedl,
> > > 
> > > Please see the message below, in which a git bisect identifies a commit
> > > which may have stopped X from working on some PowerPC G4 systems
> > > (specifically the G4 PowerBook and Cube, possibly others).
> > > 
> > > I'm not sure how to proceed with further tests. If the identified commit
> > > could not have caused the problem, then further testing may be needed.
> > > Please let me know if you need any additional information.
> > > 
> > > Hopefully your e-mail filter will allow messages from yahoo.com addresses.
> > > 
> > > thanks for your help
> > > 
> > > -Stan Johnson
> > > 
> > > -------- Forwarded Message --------
> > > Subject: Re: X stopped working with 5.14 on iBook
> > > Date: Fri, 22 Oct 2021 11:25:14 -0600
> > > From: Stan Johnson
> > > To: debian-powerpc at lists.debian.org
> > > CC: Riccardo Mottola <riccardo.mottola at libero.it>
> > > 
> > > On 10/14/21 9:21 PM, Stan Johnson wrote:
> > > > ...
> > > > Debian's 5.10.0-8 config file works (as expected) with Debian's 5.10.0-8
> > > > kernel source.
> > > > ...
> > > > X works with 5.14 using a tuned config file derived from 5.13 testing.
> > > > ...
> > > 
> > > Update:
> > > 
> > > The issue originally reported by Riccardo Mottola was that X wasn't
> > > working on a PowerBook G4 using Debian's default
> > > vmlinux-5.14.0-2-powerpc kernel. I was able to confirm that the X
> > > failure also occurs on a G4 Cube. My G4 Cube has Debian SID,
> > > sysvinit-core, Xfce and wdm installed. To test whether X works, I
> > > disabled wdm, then I log in at the text console and run "startx". When X
> > > fails, the screen goes blank and the backlight stays on; when X works,
> > > the normal desktop comes up.
> > > 
> > > X works in mainline v5.12 built using a config file based on Debian's
> > > config-5.10.0-8-powerpc.
> > > 
> > > X fails in mainline v5.13 built using a config file based on Debian's
> > > config-5.10.0-8-powerpc.
> > > 
> > > With much help and advice from Finn Thain, I was able to run a bisect
> > > using a config file based on Debian's config-5.10.0-8-powerpc, with
> > > v5.12 "good" and v5.13 "bad".
> > > 
> > > $ git reset --hard
> > > HEAD is now at 62fb9874f5da Linux 5.13
> > > $ git bisect start v5.13
> > > Updating files: 100% (12992/12992), done.
> > > Previous HEAD position was 62fb9874f5da Linux 5.13
> > > HEAD is now at 9f4ad9e425a1 Linux 5.12
> > > $ git bisect bad v5.13
> > > $ git bisect good v5.12
> > > Bisecting: 8739 revisions left to test after this (roughly 13 steps)
> > > > 85f3f17b5db2dd9f8a094a0ddc665555135afd22] Merge branch 'md-fixes' of
> > > https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.13
> > > 
> > > After the bisect, git reports this:
> > > 
> > > ----------
> > > 
> > > d3ccc9781560af051554017c702631560bdc0811 is the first bad commit
> > > commit d3ccc9781560af051554017c702631560bdc0811
> > > Author: Christopher M. Riedl <cmr at codefail.de>
> > > Date:   Fri Feb 26 19:12:59 2021 -0600
> > > 
> > >      powerpc/signal: Use __get_user() to copy sigset_t
> > > 
> > >      Usually sigset_t is exactly 8B which is a "trivial" size and does not
> > >      warrant using __copy_from_user(). Use __get_user() directly in
> > >      anticipation of future work to remove the trivial size optimizations
> > >      from __copy_from_user().
> > > 
> > >      The ppc32 implementation of get_sigset_t() previously called
> > >      copy_from_user() which, unlike __copy_from_user(), calls access_ok().
> > >      Replacing this w/ __get_user() (no access_ok()) is fine here since both
> > >      callsites in signal_32.c are preceded by an earlier access_ok().
> > > 
> > >      Signed-off-by: Christopher M. Riedl <cmr at codefail.de>
> > >      Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
> > >      Link: https://lore.kernel.org/r/20210227011259.11992-11-cmr@codefail.de
> > > 
> > >   arch/powerpc/kernel/signal.h    | 7 +++++++
> > >   arch/powerpc/kernel/signal_32.c | 2 +-
> > >   arch/powerpc/kernel/signal_64.c | 4 ++--
> > >   3 files changed, 10 insertions(+), 3 deletions(-)
> > > 
> > 