Date: Sat, 6 Sep 2014 18:00:56 -0700 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <chmeeedalf@gmail.com> 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: <3B34604D-2EDB-4315-97E9-4C97652E9AE7@dsl-only.net> In-Reply-To: <20140906172136.59a531d0@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D??? assignments that were added. =3D=3D=3D 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.) >=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] 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. - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B34604D-2EDB-4315-97E9-4C97652E9AE7>