Re: X Display Problem on G3 Series PowerBook (Wallstreet)
On 7/19/21 8:32 AM, Stan Johnson wrote:
> On 7/18/21 10:23 PM, Christian Zigotzky wrote:
>> Hello Stan,
>>
>> We had the same issue during the 5.14 merge window. Please look in the
>> following thread:
>>
>> https://forum.hyperion-entertainment.com/viewtopic.php?p=53511#p53511
>>
>> There is a patch available. Please try it.
>>
>> Thanks,
>> Christian
>> ...
>
> Hello Christian,
>
> Thanks. There were some errors applying the patch, so it wasn't fully
> applied (see below). Of course, I'm using 5.13.2, not 5.14, so maybe
> that's expected.
>
> The patched 5.13.2 kernel still results in a blank screen while trying
> to run wdm. On this attempt, wdm has died (oddly the screen remains
> blank; it should display a text login after X dies). The Xorg.0.log
> looks reasonable enough.
>
> I tried disabling wdm, then rebooted, logged in at the console and ran
> "startx". The screen goes blank, X is running, startx is running:
>
> johnson 1392 0.0 0.2 2572 1452 tty1 S+ 08:06 0:00 /bin/sh
> /usr/bin/startx
> johnson 1414 0.0 0.4 4904 2096 tty1 S+ 08:06 0:00 xinit
> /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth
> /tmp/serverauth.dJ7lSnzjjo
> johnson 1415 1.0 8.2 128436 41924 tty1 Sl 08:06 0:04
> /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth
> /tmp/serverauth.dJ7lSnzjjo
>
> I had to use "kill -KILL" to kill the startx, xinit and Xorg processes.
> After those were killed, the screen was still blank, and even though
> nothing was running, the load average was still around 1.00 several
> minutes later, so something is still taking CPU time:
>
> $ uptime
> 08:25:15 up 20 min, 2 users, load average: 1.00, 1.00, 0.84
>
> I can attempt a git bisect, though that will take some time.
>
> -Stan
>
> ----------
> $ patch -p1
> <../v3-drm-radeon-Fix-NULL-dereference-when-updating-memory-stats.patch
> patching file drivers/gpu/drm/radeon/radeon_object.c
> Hunk #2 FAILED at 76.
> Hunk #3 FAILED at 727.
> 2 out of 3 hunks FAILED -- saving rejects to file
> drivers/gpu/drm/radeon/radeon_object.c.rej
> patching file drivers/gpu/drm/radeon/radeon_object.h
> patching file drivers/gpu/drm/radeon/radeon_ttm.c
> Hunk #1 FAILED at 199.
> Hunk #2 succeeded at 227 (offset 11 lines).
> Hunk #3 succeeded at 275 (offset 11 lines).
> Hunk #4 succeeded at 697 (offset 12 lines).
> 1 out of 4 hunks FAILED -- saving rejects to file
> drivers/gpu/drm/radeon/radeon_ttm.c.rej
> johnson@mac-server:/data/software/working/linux-5.13.2$ cat
> drivers/gpu/drm/radeon/radeon_ttm.c.rej
> --- drivers/gpu/drm/radeon/radeon_ttm.c
> +++ drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -199,7 +199,7 @@ static int radeon_bo_move(struct ttm_buffer_object
> *bo, bool evict,
> struct ttm_resource *old_mem = bo->resource;
> struct radeon_device *rdev;
> struct radeon_bo *rbo;
> - int r;
> + int r, old_type;
>
> if (new_mem->mem_type == TTM_PL_TT) {
> r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);
>
> ---------
>
I ran a git bisect, but I'm not sure whether it identifies the real
problem. There may be multiple or intermittent issues. For example,
5.12.0-rc3-pmac-00258-ga9d2f9bb225f failed, but in a way no other kernel
failed -- screen blinked three times, then went blank, including no
backlight, with no wdm running; the system appeared to be off but
wasn't. Kernels 5.12.0-rc3-pmac-00129-g036fc2cb1dc2,
5.12.0-rc3-pmac-00064-g719e7e212c7e,
5.12.0-rc3-pmac-00032-g96d7a4e06fab,
5.12.0-rc3-pmac-00016-g4b8cda58812c,
5.12.0-rc3-pmac-00008-g1a0e4550fb12,
5.12.0-rc3-pmac-00004-g5c4a4802b9ac,
5.12.0-rc3-pmac-00002-g9634afa67bfd, and
5.12.0-rc3-pmac-00001-g9be77e11dade all had repeatable failures with
30-second repeating segfaults while running the init scripts (I'm using
sysvinit). Their failures may not be related to the current Wallstreet X
issue (the segfault problems were apparently fixed by 5.12.12). Other
failures left wdm (and Xorg) running and the backlight still on.
Here's a question for git experts: Is there a way to specify a minor
kernel version? For example, I was able to confirm separately that
v5.12.18 works, while v5.13 fails. However, I wasn't able to specify
v5.12.18 as working in git, only v5.12. It's possible that the failure
faded in and out during v5.12.x releases dependent on other issues or
interactions between multiple bugs. Also, is there a way to isolate a
git bisect to a specific driver (such as ATI)? Maybe a "git bisect
inconclusive" option if a crash appears to be unrelated to the bug
that's being chased?
Anyway, here's what the git bisect identified, based on v5.12 being
"good" and v5.13 being "bad". If there's some other (or better) way to
identify the issue, please let me know, and I'll give it a try. I
suspect the below identifies an already-fixed issue related to the
repeating 30-second segfault while running the init scripts. Any
suggestions are welcome.
-Stan
-----
$ git bisect bad
9be77e11dade414d2fa63750aa5c754fac49d619 is the first bad commit
commit 9be77e11dade414d2fa63750aa5c754fac49d619
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Fri Feb 19 17:56:48 2021 +0100
powerpc/mm: Move the linear_mapping_mutex to the ifdef where it is used
The mutex linear_mapping_mutex is defined at the of the file while its
only two user are within the CONFIG_MEMORY_HOTPLUG block.
A compile without CONFIG_MEMORY_HOTPLUG set fails on PREEMPT_RT because
its mutex implementation is smart enough to realize that it is unused.
Move the definition of linear_mapping_mutex to ifdef block where it is
used.
Fixes: 1f73ad3e8d755 ("powerpc/mm: print warning in
arch_remove_linear_mapping()")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link:
https://lore.kernel.org/r/20210219165648.2505482-1-bigeasy@linutronix.de
arch/powerpc/mm/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-----
Reply to: