Date: Sat, 6 Sep 2014 18:05:32 -0700 From: Justin Hibbits <chmeeedalf@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: freebsd-ppc@freebsd.org Subject: Re: Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)... Message-ID: <20140906180532.35faf018@zhabar.attlocal.net> In-Reply-To: <3B34604D-2EDB-4315-97E9-4C97652E9AE7@dsl-only.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) > > > The svn-src-stable-10/2014-September signal handling commit comments > that I noticed from you this month are for > > "Fix 32-bit signal handling on ppc64." (r261095) > > and for > > "Set the si_code appropriately for exception-caused > signals" (powerpc/aim/trap.c) (MFC r269701) > > 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.) > > 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=??? assignments that were added. > > > > === > Mark Millard > markmi at dsl-only.net > > On Sep 6, 2014, at 5:21 PM, Justin Hibbits <chmeeedalf@gmail.com> > wrote: > > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard <markmi@dsl-only.net> wrote: > > > 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.) > > > > Thus I managed to get a little more information: /usr/local/bin/gdb > > reports for Xorg the likes of: > > > > [Inferior 1 (process 1934) exited with code 026] > > This is the smoking gun. Exit code 026 == 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. > > - Justin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140906180532.35faf018>