Date: Mon, 8 Sep 2014 00:29:07 -0700 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: freebsd-ppc@freebsd.org Subject: Justin Hibbits' changes avoid Xorg/xfce4 failing/quiting on Dual Processor G4 PowerMac's Message-ID: <E0A8E3FA-C689-4EC1-9275-BF517B50CC95@dsl-only.net> In-Reply-To: <20140906180532.35faf018@zhabar.attlocal.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <EDE36402-30CE-4747-8BDD-EDD82D8C308F@dsl-only.net> <D42F3E26-8D35-4C8B-A695-AA380ED888E1@dsl-only.net> <EF019CAD-6BAB-431D-A239-0644C0634C24@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <D53F6E61-13E3-4473-ABAD-F72BD86E1083@dsl-only.net> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@dsl-only.net> <D960F3AF-7498-4222-96E9-654E9B672EF7@dsl-only.net> <38A1300F-E5A4-4A71-A9CF-A7BED66E0BDF@dsl-only.net> <5408976A.5080106@freebsd.org> <6DE6C98D-F553-4F59-A72A-AEA881DC1C65@dsl-only.net> <3D7C705D-5792-43FA-835C-9FD88AEAE07E@dsl-only.net> <DC6BA46B-C123-41A3-AD07-1212FC084B88@dsl-only.net> <35DA591A-127B-4F46-B779-D76A0F71DA39@dsl-only.net> <20140906172136.59a531d0@zhabar.attlocal.net> <3B34604D-2EDB-4315-97E9-4C97652E9AE7@dsl-only.net> <20140906180532.35faf018@zhabar.attlocal.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I built a 10.1-PRERELEASE r271215 that contains Justin Hibbits recent = changes for powerpc and powerpc64. (I also used portsnap and then = rebuilt my ports from scratch.) r271215 includes the change that Justin = expected would fix Xorg UI hangs (really Xorg silently quitting) when = xfce4 starts up. Based on FreeBSD FBSDG4S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271215: Sat = Sep 6 23:56:15 PDT 2014 root@FBSDG4S0:/usr/obj/usr/src/sys/GENERIC = powerpc Xorg with xfce4 no longer hangs/quits on my Dual Processor PowerMac = G4's. I can still use the G5's. Thanks Justin! (I still have more = PowerMac/Card combinations to check.) Side note for NVIDIA GeForce4 Ti 4600's: The experiment has also shown that there is a separate problem for at = least the NVIDIA GeForce4 Ti 4600 when used at 1680x1050 (at least on an = ADC display from a G4 PowerMac): What should be the last 8 pixels or so = on the right are instead near the left hand side of the display, about 8 = pixels from the left side in fact. (This had been observed before the = fix after a ports update but with the hang/quit status I did not want to = assume much about the incomplete display updates at the time.) In total all the pixels are probably there. There is just a band of = pixels that is way out of place. (So all the pixels after them are then = shifted from where they should be by the width of that band.) Also the about 8 pixel wide bind appears to be shifted down one pixel = from what would be expected. (Easily visible at the edge of the menu bar = across the top.) At 1400x1050 there are no such problem bands. Nor probably at 1280x1024. = (But 1280x1024 is not a nice display in many other ways. I did not look = carefully at 1280x1024.) The Xorg.0.log's do show an alternate Modeline for 1680x1050: [ 73.585] (**) NV(0): *Driver mode "1680x1050": 117.1 MHz, 63.7 kHz, = 59.9 Hz [ 73.585] (II) NV(0): Modeline "1680x1050"x59.9 117.13 1680 1744 = 1776 1840 1050 1053 1056 1062 +hsync +vsync (63.7 kHz ezP) [ 73.585] (**) NV(0): *Driver mode "1680x1050": 119.0 MHz, 64.7 kHz, = 59.9 Hz [ 73.585] (II) NV(0): Modeline "1680x1050"x59.9 119.00 1680 1728 = 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz ez) [ 73.585] (**) NV(0): *Default mode "1400x1050": 122.0 MHz, 64.9 kHz, = 60.0 Hz [ 73.585] (II) NV(0): Modeline "1400x1050"x60.0 122.00 1400 1488 = 1640 1880 1050 1052 1064 1082 +hsync +vsync (64.9 kHz zd) [ 73.585] (**) NV(0): *Default mode "1280x1024": 108.0 MHz, 64.0 kHz, = 60.0 Hz [ 73.585] (II) NV(0): Modeline "1280x1024"x60.0 108.00 1280 1328 = 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz zd) The Radeon's do not show this display problem at all. (The alternate = pixel counts are not allowed for the Radeon's: just 1680x1050.) =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 6, 2014, at 6:05 PM, Justin Hibbits <chmeeedalf@gmail.com> wrote: r261095 is only part of it. The part that fixes powerpc32 is the MFC of r263464, "Mask out SRR1 bits that aren't exported in the MSR". What happens is that sometimes an extra exception bit is stashed away in the mcontext, I believe it's the "external interrupt" bit getting set if memory serves me right. I'm not sure why it gets set and stashed in there, but r263464 masks that out, so X will work again (at least it does for me). - Justin On Sat, 6 Sep 2014 18:00:56 -0700 Mark Millard <markmi@dsl-only.net> wrote: > If I grab sources from svn it will be the first time that I've done > so. I'd probably make a separate SSD and leave my "as distributed" > powerpc/GENERIC SSD alone (it has other uses). Overall it will be > some time before I've a rebuilt context if I try it. (It is probably > a good thing for me to do at this stage.) >=20 >=20 > The svn-src-stable-10/2014-September signal handling commit comments > that I noticed from you this month are for >=20 > "Fix 32-bit signal handling on ppc64." (r261095) >=20 > and for >=20 > "Set the si_code appropriately for exception-caused > signals" (powerpc/aim/trap.c) (MFC r269701) >=20 > ppc64 (G5) is working and ppc32 (G4) is not working as far as the > processor context goes for what I'me been reporting on. Although it > is the powerpc/GENERIC build used for both contexts, not a > powerpc64/GENERIC64 build for the G5's. (All 10.1-PRERELEASE r270981 > now.) >=20 > So I'm guessing that you are expecting the si_code update to be what > fixes things. If so then more than just LLDB would care about the > ucode=3D??? assignments that were added. >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Sep 6, 2014, at 5:21 PM, Justin Hibbits <chmeeedalf@gmail.com> > wrote: >=20 > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard <markmi@dsl-only.net> wrote: >=20 >> I finally asked myself "how many gdb's does FreeBSD have?". This >> lead me to building and using devel/gdb (/usr/local/bin/gdb). >> Experiments indicates /usr/local/bin/gdb works on Xorg on the G4's. >> (Xorg's build installs gcc47 and apparently needs a newer gdb to go >> with it.) >>=20 >> Thus I managed to get a little more information: /usr/local/bin/gdb >> reports for Xorg the likes of: >>=20 >> [Inferior 1 (process 1934) exited with code 026] >=20 > This is the smoking gun. Exit code 026 =3D=3D 22 (decimal), which = just so > happens to be EINVAL, returned by sigreturn(). I finished committing > all my merges to stable/10, so you could try building an updated > kernel, and see that it fixes it. >=20 > - Justin >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0A8E3FA-C689-4EC1-9275-BF517B50CC95>