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 <c...@codefail.de> > > > CC: Finn Thain <fth...@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-powe...@lists.debian.org > > > CC: Riccardo Mottola <riccardo.mott...@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 <c...@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 <c...@codefail.de> > > > Signed-off-by: Michael Ellerman <m...@ellerman.id.au> > > > Link: > > > https://lore.kernel.org/r/20210227011259.11992-11-...@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(-) > > > > >