From owner-freebsd-ppc@FreeBSD.ORG Sun Sep 7 00:05:51 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EAC56EA for ; Sun, 7 Sep 2014 00:05:51 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B00E31747 for ; Sun, 7 Sep 2014 00:05:49 +0000 (UTC) Received: (qmail 4900 invoked from network); 7 Sep 2014 00:05:47 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 7 Sep 2014 00:05:47 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 06 Sep 2014 20:05:47 -0400 (EDT) Received: (qmail 8589 invoked from network); 7 Sep 2014 00:05:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Sep 2014 00:05:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 44BFC1C405C; Sat, 6 Sep 2014 17:05:41 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)... From: Mark Millard In-Reply-To: Date: Sat, 6 Sep 2014 17:05:45 -0700 Message-Id: <35DA591A-127B-4F46-B779-D76A0F71DA39@dsl-only.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 00:05:51 -0000 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] The process number varies but the exit code does not from test to test. This happens with partial screen updates showing on screen, showing that = I have managed to repeat the context fairly well despite = /usr/local/bin/gdb being involved. (I temporarily replaced = /usr/local/bin/X with a script that runs gdb on Xorg, feeding gdb some = commands via -x file-name.) Using Option "NoTrapSignals" in the xorg.conf does not change the = reports or behavior. (Confirmed no-trap use via Xorg.0.log reporting the = likes of: [ 2437.485] (**) Option "NoTrapSignals".) As for the 1920x1200 "Unknown mode" notice... It is not an issue. = Details follow. I put a 1680x1050 ADC Display on a NVIDIA G5 PowerMac to see what would = happen for startxfce4. It both: (A) generated the xfsettingsd Unkown mode '1920x1200 @ 60.0' message = that I reported earlier and (B) worked correctly overall, using the 1680x1050 size. And after shutting down, putting back the 1920x1200 display, and trying = again it reported 1680x1050 in the "Unknown mode" message: It is using a = record of the prior setting to generate that message. So it appears that the new "Unknown mode" message is unimportant. =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 6, 2014, at 8:15 AM, Mark Millard wrote: Overall not much has changed for the original problem in 10.1-PRERELEASE = r270981 with a fresh Xorg/xfce4 build. Details follow. The NVIDIA = context does have a new, additional oddity. Updating to a fresh, from-scratch... > FreeBSD FBSDG4S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r270981: = Wed Sep 3 04:01:09 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC = powerpc using portsnap fetch extract and building Xorg and xfce4 (and = xscreensaver this time) still has the PowerMac G4 X11 UI hangups (well, = Xorg and such quitting) after partial screen updates are (usually) = visible. (I did not explicitly build anything with debug symbols for = this round. I used the MANIFEST file and .txz files and bsdinstall --and = did not buildworld nor did I buildkernel.) The NVIDIA G4 got some interesting information in the script output file = for the NVIDIA PowerMac G4 for a startxfce4 -- -logverbose 9: > failed to set mtrr: File exists >=20 > (xfsettingsd:1053): xfsettingsd-WARNING **: Unknown mode '1920x1200 @ = 60.0' for output default. The ADC display in use on one of the G5's has a 1920x1200 native pixel = area. But the one on the G4 being used here is smaller: 1680x1050. The = SSD had been booted and tested on that G5 first. (So may be that old = size is recorded somewhere and is used even when it is not appropriate?) = The displayed content actually looks to be not sized to match the = display as of when it hangs. (This is new to this build: before as much = as displayed seemed to have the right width/height [no wrap around]. So = the size issue may be a new, independent issue.) After the above 1920x1200 reference is the usual sort of indication of = the Xorg quit: > xfce4-session: Fatal IO error 35 (Resource temporarily unavailable) on = X server :0. > xfwm4: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > Thunar: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0. > xfsettingsd: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > wrapper: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > xinit: connection to X server lost > wrapper: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > root@FBSDG4S1:~ # Assertion failed: (ret !=3D inval_id), function = _XAllocID, file xcb_io.c, line 529. But the "Assertion failed" notice is new, as may be the "wrapper" = references. (ps -aud shows Xorg and the rest are gone while the display = still shows the partial update status.) The Xorg.0.log shows for the = size question: > [ 415.724] (--) NV(0): DDC detected a DFP: > [ 415.724] (II) NV(0): Manufacturer: APP Model: 9219 Serial#: = 50201662 > [ 415.724] (II) NV(0): Year: 2004 Week: 13 > [ 415.724] (II) NV(0): EDID Version: 1.3 > [ 415.724] (II) NV(0): Digital Display Input > [ 415.724] (II) NV(0): Max Image Size [cm]: horiz.: 43 vert.: 27 > [ 415.724] (II) NV(0): Gamma: 2.20 > [ 415.724] (II) NV(0): DPMS capabilities: Off > [ 415.724] (II) NV(0): Supported color encodings: RGB 4:4:4 YCrCb = 4:4:4=20 > [ 415.724] (II) NV(0): Default color space is primary color space > [ 415.725] (II) NV(0): First detailed timing is preferred mode > [ 415.725] (II) NV(0): redX: 0.640 redY: 0.330 greenX: 0.290 = greenY: 0.600 > [ 415.725] (II) NV(0): blueX: 0.150 blueY: 0.060 whiteX: 0.312 = whiteY: 0.329 > [ 415.725] (II) NV(0): Manufacturer's mask: 0 > [ 415.725] (II) NV(0): Supported detailed timing: > [ 415.725] (II) NV(0): clock: 117.1 MHz Image Size: 433 x 270 mm > [ 415.725] (II) NV(0): h_active: 1680 h_sync: 1744 h_sync_end 1776 = h_blank_end 1840 h_border: 0 > [ 415.725] (II) NV(0): v_active: 1050 v_sync: 1053 v_sync_end 1056 = v_blanking: 1062 v_border: 0 > [ 415.725] (II) NV(0): Monitor name: Apple Cinema > [ 415.725] (II) NV(0): Monitor name: Display > ... > [ 415.729] (--) NV(0): CRTC 0 is currently programmed for DFP > [ 415.729] (II) NV(0): Using DFP on CRTC 0 > [ 415.729] (--) NV(0): Panel size is 1680 x 1050 > [ 415.729] (II) NV(0): NOTE: This driver cannot reconfigure the = BIOS-programmed size. > [ 415.729] (II) NV(0): These dimensions will be used as the panel = size for mode validation. > [ 415.729] (II) NV(0): EDID vendor "APP", prod id 37401 > [ 415.729] (II) NV(0): Printing DDC gathered Modelines: > [ 415.729] (II) NV(0): Modeline "1680x1050"x0.0 117.13 1680 1744 = 1776 1840 1050 1053 1056 1062 +hsync +vsync (63.7 kHz eP) > [ 415.729] (II) NV(0): Panel is TMDS > [ 415.729] (--) NV(0): VideoRAM: 131072 kBytes > [ 415.729] (=3D=3D) NV(0): Using gamma correction (1.0, 1.0, 1.0) > [ 415.729] (II) NV(0): Monitor0: Using hsync range of 63.66-64.67 = kHz > [ 415.729] (II) NV(0): Monitor0: Using vrefresh range of 59.88-59.94 = Hz > [ 415.725] (II) NV(0): h_active: 1680 h_sync: 1744 h_sync_end 1776 = h_blank_e > nd 1840 h_border: 0 > [ 415.725] (II) NV(0): v_active: 1050 v_sync: 1053 v_sync_end 1056 = v_blankin > g: 1062 v_border: 0 > [ 415.725] (II) NV(0): Monitor name: Apple Cinema > [ 415.725] (II) NV(0): Monitor name: Display > ... > [ 415.726] (II) NV(0): Probing for EDID on I2C bus B... > [ 415.729] (II) NV(0): ... none found > [ 415.729] (--) NV(0): CRTC 0 is currently programmed for DFP > [ 415.729] (II) NV(0): Using DFP on CRTC 0 > [ 415.729] (--) NV(0): Panel size is 1680 x 1050 > [ 415.729] (II) NV(0): NOTE: This driver cannot reconfigure the = BIOS-programme > d size. > [ 415.729] (II) NV(0): These dimensions will be used as the panel = size for mod > e validation. > [ 415.729] (II) NV(0): EDID vendor "APP", prod id 37401 > [ 415.729] (II) NV(0): Printing DDC gathered Modelines: > [ 415.729] (II) NV(0): Modeline "1680x1050"x0.0 117.13 1680 1744 = 1776 1840 =20 > 1050 1053 1056 1062 +hsync +vsync (63.7 kHz eP) > [ 415.729] (II) NV(0): Panel is TMDS > [ 415.729] (--) NV(0): VideoRAM: 131072 kBytes > [ 415.729] (=3D=3D) NV(0): Using gamma correction (1.0, 1.0, 1.0) > [ 415.729] (II) NV(0): Monitor0: Using hsync range of 63.66-64.67 = kHz > [ 415.729] (II) NV(0): Monitor0: Using vrefresh range of 59.88-59.94 = Hz > [ 415.729] (II) NV(0): Estimated virtual size for aspect ratio = 1.5926 is 1680x1050 > [ 415.729] (II) NV(0): Clock range: 12.00 to 350.00 MHz Then it has the long list of non-working sizes followed by: > [ 415.732] (--) NV(0): Virtual size is 1680x1050 (pitch 1680) > [ 415.732] (**) NV(0): *Driver mode "1680x1050": 117.1 MHz, 63.7 = kHz, 59.9 Hz > [ 415.732] (II) NV(0): Modeline "1680x1050"x59.9 117.13 1680 1744 = 1776 1840 1050 1053 1056 1062 +hsync +vsync (63.7 kHz ezP) > [ 415.732] (**) NV(0): *Driver mode "1680x1050": 119.0 MHz, 64.7 = kHz, 59.9 Hz > [ 415.732] (II) NV(0): Modeline "1680x1050"x59.9 119.00 1680 1728 = 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz ez) > [ 415.732] (**) NV(0): *Default mode "1400x1050": 122.0 MHz, 64.9 = kHz, 60.0 Hz > [ 415.732] (II) NV(0): Modeline "1400x1050"x60.0 122.00 1400 1488 = 1640 1880 1050 1052 1064 1082 +hsync +vsync (64.9 kHz zd) > [ 415.732] (**) NV(0): *Default mode "1280x1024": 108.0 MHz, 64.0 = kHz, 60.0 Hz > [ 415.732] (II) NV(0): Modeline "1280x1024"x60.0 108.00 1280 1328 = 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz zd) > [ 415.732] (**) NV(0): Display dimensions: (430, 270) mm > [ 415.732] (**) NV(0): DPI set to (99, 98) There is no mention of 1920 or of 1200 in the Xorg.0.log file. Nor does = the xorg.conf file have size information. I'd never guess from the Xorg.0.log that there was a problem --either = the original one or the size one. One new thing in the log file is that the tail has: > [ 419.683] select returned 0 > [ 419.739] select returned 0 > [ 419.747] select returned 0 > [ 419.755] select returned 0 > [ 419.763] select returned 0 > [ 419.771] select returned 0 > [ 419.779] select returned 0 > [ 419.787] select returned 0 > ... > [ 420.195] select returned 0 > [ 420.203] select returned 0 > [ 420.211] select returned 0 > [ 420.221] select returned 0 > [ 420.227] select returned 0 > [ 420.251] select returned 0 > [ 420.251] select returned 0 The Radeon board based PowerMac G4 that I tested does not report that = size notice. It also has a 1680x1050 ADC display. Its Xorg.0.log also = shows 1680x1050. Again the Xorg.0.log contents look normal, without an = indication of failure. And the script file again shows a sudden, silent = quit as the mode of failure (ps -aud showing that Xorg and such are gone = while the display is still stuck before any Option-Fn): > ... > best_freq: 117132353 > best_feedback_div: 295 > best_frac_feedback_div: 0 > best_ref_div: 34 > best_post_div: 2 > restore memmap > restore common > restore crtc1 > restore pll1 > finished PLL1 > set RMX > set FP1 > enable FP1 > disable TV > Unhandled monitor type 0 > xfwm4: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > xfce4-panel: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > Thunar: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0. > xinit: connection to X server lost The partial display did not look to be the wrong size. When I tried a PowerMac G5 booted from that same SSD with a 1680x1050 = ADC display and a Radeon board startxfce4 worked fine. This also = suggests that the 1920x1200 size issue is a new, separate problem with = just the nv driver(?). =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 4, 2014, at 6:46 PM, Mark Millard wrote: The radeon G4 contexts do not report "failed to set mtrr: File exists": = They seem to be silent about Xorg quitting early as far as error = messages or warnings go (booted from that same SSD with xorg.conf for = the radeon context). Again Xorg.0.log does not look interesting and = stops before the problem. A script logfile shows: > root@FBSDG4S0:~ # startxfce4 -- -logverbose 9^M > /usr/local/bin/startxfce4: Starting X server >=20 >=20 > X.Org X Server 1.12.4 > Release Date: 2012-08-27 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 10.0-STABLE powerpc=20 > Current Operating System: FreeBSD FBSDG4S0 10.0-STABLE FreeBSD = 10.0-STABLE #0: T > hu Sep 4 00:50:31 PDT 2014 = root@FBSDG4S0:/usr/obj/usr/src/sys/GENERIC power > pc > Build Date: 04 September 2014 06:13:34AM > =20 > Current version of pixman: 0.32.4 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 4 18:20:03 = 2014 > (=3D=3D) Using config file: "/etc/X11/xorg.conf" > XRANDR name: DVI-1 > Connector: DVI-I > CRT2: INTERNAL_DAC2 > DFP1: INTERNAL_TMDS1 > DDC reg: 0x64 > XRANDR name: DVI-0 > Connector: DVI-I > CRT1: INTERNAL_DAC1 > DFP2: INTERNAL_DVO1 > DDC reg: 0x60 > XRANDR name: S-video > Connector: S-video > TV1: INTERNAL_DAC2 > DDC reg: 0x0 > finished output detect: 0 > Unhandled monitor type 0 > finished output detect: 1 > finished output detect: 2 > finished all detect > Unhandled monitor type 0 > Entering TV Save > Save TV timing tables > saveTimingTables: reading timing tables > TV Save done > disable FP1 > disable FP1 > disable TV > disable FP1 > init memmap > init common > init crtc1 > init pll1 > freq: 117130000 > best_freq: 117132353 > best_feedback_div: 295 > best_frac_feedback_div: 0 > best_ref_div: 34 > best_post_div: 2 > restore memmap > restore common > restore crtc1 > restore pll1 > finished PLL1 > set RMX > set FP1 > enable FP1 > disable TV > xfce4-session: Fatal IO error 35 (Resource temporarily unavailable) on = X server :0. > xfwm4: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > xinit: connection to X server lost =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 4, 2014, at 6:00 PM, Mark Millard wrote: The below includes it reporting getting a "failed to set mtrr: File = exists" notice. (A Intel P6+ concept?) I have since rebuilt (buildworld, kernel, installworld; portmaster -af) = from the same /usr/src/... and /usr/ports/... on that same SSD based on = /etc/make.conf having: WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D # because otherwise it leads to buildworld failures = with the above enabled WITH_DEBUG=3D Unfortunately uname -a loses the r268571 reference in the process, = leaving less of a clue what the build is based on. In this context the script logfile for running on a PowerMac G4 ends up = recording "failed to set mtrr: File exists": > root@FBSDG4S0:~ # startxfce4 -- -logverbose 9^M > /usr/local/bin/startxfce4: Starting X server >=20 >=20 > X.Org X Server 1.12.4 > Release Date: 2012-08-27 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 10.0-STABLE powerpc=20 > Current Operating System: FreeBSD FBSDG4S0 10.0-STABLE FreeBSD = 10.0-STABLE #0: Thu Sep 4 00:50:31 PDT 2014 = root@FBSDG4S0:/usr/obj/usr/src/sys/GENERIC powerpc > Build Date: 04 September 2014 06:13:34AM > =20 > Current version of pixman: 0.32.4 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 4 15:14:07 = 2014 > (=3D=3D) Using config file: "/etc/X11/xorg.conf" > failed to set mtrr: File exists > xfce4-session: Fatal IO error 35 (Resource temporarily unavailable) on = X server :0. > xinit: connection to X server lost > root@FBSDG4S0:~ # xfwm4: Fatal IO error 35 (Resource temporarily = unavailable) on X server :0.0. > root@FBSDG4S0:~ #=20 The G5 PowerMac does not display the "failed to set mtrr: File exists" = message when booted from the same boot SSD and startxfce4 -- -logverbose = 9 is used (but with xorg.conf's BusID changed to match the = PowerMac7,11's BusID). The G5 context works fine. (I've not tried the = single processor G4 context yet.) Note: I'm using the G4 NVIDIA PowerMac for most G4 expirements because = it allows me to Option-Fn to get to VTn and see thing there and so I can = avoid reboots. The last thing that dmesg -a shows after the G4 startxfce4 -- = -logverbose 9 is my logging in as root: > $ dmesg -a | tail > Configuring syscons: blanktime. > Performing sanity check on sshd configuration. > Starting sshd. > Starting sendmail_submit. > Starting sendmail_msp_queue. > Starting cron. > Starting background file system checks in 60 seconds. >=20 > Thu Sep 4 14:21:42 PDT 2014 > Sep 4 14:21:48 FBSDG4S0 login: ROOT LOGIN (root) ON ttyv0 I do not see anything earlier that looks to be of interest. About the = only thing remotely error-like are some examples of "hid_get_item: = Number of items truncated to 255". /var/log/Xorg.0.log's ends in: > [ 182.354] (II) Module mouse: vendor=3D"X.Org Foundation" > [ 182.354] compiled for 1.12.4, module version =3D 1.9.0 > [ 182.354] Module class: X.Org XInput Driver > [ 182.354] ABI class: X.Org XInput driver, version 16.0 > [ 182.354] (II) Using input driver 'mouse' for 'Apple Optical USB = Mouse' > [ 182.354] (**) Apple Optical USB Mouse: always reports core events > [ 182.354] (**) Option "Device" "/dev/sysmouse" > [ 182.354] (=3D=3D) Apple Optical USB Mouse: Protocol: "Auto" > [ 182.354] (**) Apple Optical USB Mouse: always reports core events > [ 182.355] (=3D=3D) Apple Optical USB Mouse: Emulate3Buttons, = Emulate3Timeout: 50 > [ 182.355] (**) Apple Optical USB Mouse: ZAxisMapping: buttons 4 and = 5 > [ 182.355] (**) Apple Optical USB Mouse: Buttons: 5 > [ 182.355] (**) Option "config_info" = "hal:/org/freedesktop/Hal/devices/usb_device_5ac_304_noserial_if0" > [ 182.355] (II) XINPUT: Adding extended input device "Apple Optical = USB Mouse" (type: MOUSE, id 7) > [ 182.356] (**) Apple Optical USB Mouse: (accel) keeping = acceleration scheme 1 > [ 182.356] (**) Apple Optical USB Mouse: (accel) acceleration = profile 0 > [ 182.356] (**) Apple Optical USB Mouse: (accel) acceleration = factor: 2.000 > [ 182.356] (**) Apple Optical USB Mouse: (accel) acceleration = threshold: 4 > [ 182.356] (II) Apple Optical USB Mouse: SetupAuto: hw.iftype is 4, = hw.model is 0 > [ 182.356] (II) Apple Optical USB Mouse: SetupAuto: protocol is = SysMouse I.e., the Xorg quit is silent. Again I do not see anything earlier that = looks to be of interest. Xorg is suddenly, silently quitting. And it is leaving all associated = log files with older modification date/times/content from what I can = tell. No core file either. "failed to set mtrr: File exists" may explain = this. I've not started investigating it yet. Side notes: I've not investigated yet if there is a way around gdb Xorg's run :0 = under powerpc/GENERIC getting: > cannot get thread event message: generic error and gdb's cont then getting: > suspend error: generic error I've also seen for other things I've tried with Xorg involved: > cannot find new threads: generic error and > no thread to satisfy query On the G5 PowerMac's using powerpc64/GENERIC64 boot SSD's I have no such = problems with threading for gdb Xorg: only the powerpc/GENERIC boot = SSD's have this problem and the gdb thread issues happen on G4's and = G5's when booted from powerpc/GENERIC boot SSD's. =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 4, 2014, at 9:46 AM, Nathan Whitehorn = wrote: Anything in dmesg or in /var/log/Xorg.0.log? What happens if you set = logverbose 9? -Nathan On 08/31/14 17:27, Mark Millard wrote: > As an example of how sudden and arbitrary the silent-quit of the X = server is: >=20 > The partial display update currently on my ADC display has = approximating the top 1/2 updated and the bottom half not updated (still = black). >=20 > But the boundary is somewhat interesting: The last updated = raster/pixel line has its left side updated (a uniform grey desktop = color) and its right side not updated (still black). >=20 > So the silent abort stopped the update mid-raster/pixel line. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Aug 31, 2014, at 4:49 PM, Mark Millard wrote: >=20 > [E-mail history trimmed this time.] >=20 > I used script to log my startxfce4 command and what it produces. With = only the ADC connected this results in various "Unhandled monitor type = 0" notices as part of normal operation. >=20 > The script output shows that the X server quit. There is no core file = left in the directory. >=20 > Thunar: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0. > xfwm4: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > xinit: connection to X server lost > xfdesktop: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. >=20 > (xfsettingsd:984): GVFS-RemoteVolumeMonitor-WARNING **: invoking = IsSupported() failed for remote volume monitor with dbus name = org.gtk.Private.GPhoto2VolumeMonitor: = org.freedesktop.DBus.Error.Disconnected: Connection was disconnected = before a reply was received > root@FBSDG4S0:~ # xfsettingsd: Fatal IO error 2 (No such file or = directory) on X server :0.0. >=20 > The full script file contents are: >=20 > Script started on Sun Aug 31 16:34:12 2014 > You have mail. > root@FBSDG4S0:~ # startxfce4^M > /usr/local/bin/startxfce4: Starting X server >=20 >=20 > X.Org X Server 1.12.4 > Release Date: 2012-08-27 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 10.0-STABLE powerpc=20 > Current Operating System: FreeBSD FBSDG4S0 10.0-STABLE FreeBSD = 10.0-STABLE #0 r268571: Sun Jul 13 05:15:31 UTC 2014 = root@grind.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC = powerpc > Build Date: 21 July 2014 07:18:49PM > =20 > Current version of pixman: 0.32.4 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 31 16:34:23 = 2014 > (=3D=3D) Using config file: "/etc/X11/xorg.conf" > XRANDR name: DVI-1 > Connector: DVI-I > CRT2: INTERNAL_DAC2 > DFP1: INTERNAL_TMDS1 > DDC reg: 0x64 > XRANDR name: DVI-0 > Connector: DVI-I > CRT1: INTERNAL_DAC1 > DFP2: INTERNAL_DVO1 > DDC reg: 0x60 > XRANDR name: S-video > Connector: S-video > TV1: INTERNAL_DAC2 > DDC reg: 0x0 > finished output detect: 0 > Unhandled monitor type 0 > finished output detect: 1 > finished output detect: 2 > finished all detect > Unhandled monitor type 0 > Entering TV Save > Save TV timing tables > saveTimingTables: reading timing tables > TV Save done > disable FP1 > disable FP1 > disable TV > disable FP1 > init memmap > init common > init crtc1 > init pll1 > freq: 117130000 > best_freq: 117132353 > best_feedback_div: 295 > best_frac_feedback_div: 0 > best_ref_div: 34 > best_post_div: 2 > restore memmap > restore common > restore crtc1 > restore pll1 > finished PLL1 > set RMX > set FP1 > enable FP1 > disable TV > Unhandled monitor type 0 > Thunar: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0. > xfwm4: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. > xinit: connection to X server lost > xfdesktop: Fatal IO error 35 (Resource temporarily unavailable) on X = server :0.0. >=20 > (xfsettingsd:984): GVFS-RemoteVolumeMonitor-WARNING **: invoking = IsSupported() failed for remote volume monitor with dbus name = org.gtk.Private.GPhoto2VolumeMonitor: = org.freedesktop.DBus.Error.Disconnected: Connection was disconnected = before a reply was received > root@FBSDG4S0:~ # xfsettingsd: Fatal IO error 2 (No such file or = directory) on X server :0.0. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >=20 From owner-freebsd-ppc@FreeBSD.ORG Sun Sep 7 00:21:43 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F88794C; Sun, 7 Sep 2014 00:21:43 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B69F318AE; Sun, 7 Sep 2014 00:21:42 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id e89so455341qgf.24 for ; Sat, 06 Sep 2014 17:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=JT8gidBbFxJi1Rj5Io4O05yAs7fPn//9lzO7BsdqPOw=; b=oCgUdYHp3IWoiYVFgnu8rGjZwNtTciqhp0uegy4l+zBa/4PEPxyRtopvcvCAEqU8vq nun/v6+k3T8ex0dGzaJv0aslKUFFHmmxFmnb4F4tE4tNSmCHuKdmm4oZmxBHwSSVQYCc 1Typm7XyYOMrlwwrLOjSAyZnht4+ApioGsYUgfzUkBpX3oYL4UjoliQ5UI10Z1mwgLT1 XZphMlYy/HUK1/CQcSIWIcY+qV8WWKmW7E8UDxSklCLfbHiJcYEq/a86meA+qcuBFIUx 3OtT8dI3UP54E5/KM5XqDOsz6OR94oGOir58ArwsBsKnKPvDAeA6RRqCWGqRCU7WaKEu 9jQQ== X-Received: by 10.224.92.83 with SMTP id q19mr29218301qam.29.1410049301798; Sat, 06 Sep 2014 17:21:41 -0700 (PDT) Received: from zhabar.attlocal.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id 96sm4114946qgf.20.2014.09.06.17.21.40 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 06 Sep 2014 17:21:41 -0700 (PDT) Date: Sat, 6 Sep 2014 17:21:36 -0700 From: Justin Hibbits To: Mark Millard Subject: Re: Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)... Message-ID: <20140906172136.59a531d0@zhabar.attlocal.net> In-Reply-To: <35DA591A-127B-4F46-B779-D76A0F71DA39@dsl-only.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <35DA591A-127B-4F46-B779-D76A0F71DA39@dsl-only.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 00:21:43 -0000 On Sat, 6 Sep 2014 17:05:45 -0700 Mark Millard 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 From owner-freebsd-ppc@FreeBSD.ORG Sun Sep 7 01:01:01 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36CD1DA9 for ; Sun, 7 Sep 2014 01:01:01 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C818E1B94 for ; Sun, 7 Sep 2014 01:01:00 +0000 (UTC) Received: (qmail 12685 invoked from network); 7 Sep 2014 01:00:59 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 7 Sep 2014 01:00:59 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 06 Sep 2014 21:00:59 -0400 (EDT) Received: (qmail 17214 invoked from network); 7 Sep 2014 01:00:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Sep 2014 01:00:58 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id B0CC01C405C; Sat, 6 Sep 2014 18:00:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)... From: Mark Millard In-Reply-To: <20140906172136.59a531d0@zhabar.attlocal.net> Date: Sat, 6 Sep 2014 18:00:56 -0700 Message-Id: <3B34604D-2EDB-4315-97E9-4C97652E9AE7@dsl-only.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <35DA591A-127B-4F46-B779-D76A0F71DA39@dsl-only.net> <20140906172136.59a531d0@zhabar.attlocal.net> To: Justin Hibbits X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 01:01:01 -0000 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 wrote: On Sat, 6 Sep 2014 17:05:45 -0700 Mark Millard 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 From owner-freebsd-ppc@FreeBSD.ORG Sun Sep 7 01:05:39 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DCA6DEA; Sun, 7 Sep 2014 01:05:39 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2019C1BB0; Sun, 7 Sep 2014 01:05:38 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id e89so488800qgf.10 for ; Sat, 06 Sep 2014 18:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=jNnnFhPE3WDd2BgkMHYJdDqve29MlmspF23+tmOEOys=; b=IKJQGABH9nrx253adFRBowBp/casqpOr0T3NVC5aZ0eAP9ka/3h13FeW5ecVVUqyT+ W32qgBHPlJHbHBP2pwWHIufSTtYS4dCgk0YrRYui6vLw1654ZXHGXCTLeJF/lTZ2ZO+Q BfODdNo3fcykziGV2oxNvw9312zOB1zskmdwBeKd4zgb1HK0WmTBzQ6bcEPoJvbj3Jo4 2vV7W9tfesVfn28PWmq5gwuhNg1JKVBf9kSsDsDzmRviXSYSvLs+89N/jAkD5eRDpvYy 5E6vtrQZ11A5qIWXo8HHrdMSlLcKr+RZyij67ETznjLQMFN5SJkQ9DLKHSuxPmho7TIU CZgg== X-Received: by 10.224.129.1 with SMTP id m1mr31673403qas.0.1410051938228; Sat, 06 Sep 2014 18:05:38 -0700 (PDT) Received: from zhabar.attlocal.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id i110sm4178410qgf.29.2014.09.06.18.05.36 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 06 Sep 2014 18:05:37 -0700 (PDT) Date: Sat, 6 Sep 2014 18:05:32 -0700 From: Justin Hibbits To: Mark Millard 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> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <35DA591A-127B-4F46-B779-D76A0F71DA39@dsl-only.net> <20140906172136.59a531d0@zhabar.attlocal.net> <3B34604D-2EDB-4315-97E9-4C97652E9AE7@dsl-only.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 01:05:39 -0000 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 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 > wrote: > > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard 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 > From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 07:29:12 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E2E075D for ; Mon, 8 Sep 2014 07:29:12 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15C851141 for ; Mon, 8 Sep 2014 07:29:11 +0000 (UTC) Received: (qmail 20250 invoked from network); 8 Sep 2014 07:29:10 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 8 Sep 2014 07:29:10 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 08 Sep 2014 03:29:10 -0400 (EDT) Received: (qmail 10494 invoked from network); 8 Sep 2014 07:29:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2014 07:29:09 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 481581C402B; Mon, 8 Sep 2014 00:29:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Justin Hibbits' changes avoid Xorg/xfce4 failing/quiting on Dual Processor G4 PowerMac's From: Mark Millard In-Reply-To: <20140906180532.35faf018@zhabar.attlocal.net> Date: Mon, 8 Sep 2014 00:29:07 -0700 Message-Id: References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <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> To: Justin Hibbits X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 07:29:12 -0000 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 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 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 > wrote: >=20 > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard 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 From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 08:47:55 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAEE9F42 for ; Mon, 8 Sep 2014 08:47:55 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 669CA1B11 for ; Mon, 8 Sep 2014 08:47:54 +0000 (UTC) Received: (qmail 25208 invoked from network); 8 Sep 2014 08:47:53 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 8 Sep 2014 08:47:53 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 08 Sep 2014 04:47:53 -0400 (EDT) Received: (qmail 4784 invoked from network); 8 Sep 2014 08:47:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2014 08:47:53 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id A13531C402B for ; Mon, 8 Sep 2014 01:47:51 -0700 (PDT) From: Mark Millard Subject: Just FYI: GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 display: [mi] EQ overflowing Message-Id: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> Date: Mon, 8 Sep 2014 01:47:48 -0700 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 08:47:55 -0000 FYI: The GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 = display (ADC with converter to DVI) reports the following [mi] EQ overflowing. Additional events will be discarded until existing = events are processed. [mi] These backtraces from mieqEnqueue may point to a culprit higher up = the stack. [mi] mieq is *NOT* the cause. It is a victim. [mi] Increasing EQ size to 512 to prevent dropped events. [mi] EQ processing has resumed after 51 dropped events. [mi] This may be caused my a misbehaving driver monopolizing the = server's resources. Context: I built a 10.1-PRERELEASE r271215 (to test Justin Hibbits' changes for = powerpc). I also used portsnap and then rebuilt my ports from scratch. 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 (I'd be surprised if this was powerpc or PowerMac specific. But use of = these old cards may be more likely for PCI-Express PowerMacs.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 09:56:21 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 211F1D41 for ; Mon, 8 Sep 2014 09:56:21 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B25F61292 for ; Mon, 8 Sep 2014 09:56:19 +0000 (UTC) Received: (qmail 17225 invoked from network); 8 Sep 2014 09:56:18 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 8 Sep 2014 09:56:18 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 08 Sep 2014 05:56:18 -0400 (EDT) Received: (qmail 17801 invoked from network); 8 Sep 2014 09:56:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2014 09:56:17 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 126821C402B for ; Mon, 8 Sep 2014 02:56:16 -0700 (PDT) From: Mark Millard Subject: A PowerMac G4 that FreeBSD will not boot but Mac OS X 10.4 and Lubuntu 14.01 work with... Message-Id: Date: Mon, 8 Sep 2014 02:56:16 -0700 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 09:56:21 -0000 I have access to one PowerMac G4 (the 733 MHz Digital Audio variant) = that FreeBSD 10.x will not boot but Mac OS X 10.4 and lubuntu 14.01 boot = and work fine with. (I've not tested FreeBSD 11.0-CURRENT or 9.x-???? = but I have tried a few vintages of 10.0 since last April and now a = 10.1-PRERELEASE r270981.) The boot messages stop updating instead of outputting the first ada0 = message. As far as I can tell this is too early for me to capture the text. So = I'll use similar text from a 466 MHz PowerMac G4 that does boot for = illustration. ... Sep 8 01:30:22 FBSDG4S0 kernel: uhub1: on usbus1 Sep 8 01:30:22 FBSDG4S0 kernel: uhub0: 2 ports with 2 removable, self = powered Sep 8 01:30:22 FBSDG4S0 kernel: uhub1: 2 ports with 2 removable, self = powered Sep 8 01:30:22 FBSDG4S0 kernel: ugen1.2: at usbus1 Sep 8 01:30:22 FBSDG4S0 kernel: ums0: on usbus1 Sep 8 01:30:22 FBSDG4S0 kernel: ums0: 4 buttons and [XYZW] coordinates = ID=3D0 Sep 8 01:30:22 FBSDG4S0 kernel: ada0 at ata0 bus 0 scbus0 target 0 lun = 0 Sep 8 01:30:22 FBSDG4S0 kernel: ada0: = Removable CD-ROM SCSI-0 device=20 Sep 8 01:30:22 FBSDG4S0 kernel: cd0: 16.700MB/s transfers (WDMA2, ATAPI = 12bytes, PIO 65534bytes) Sep 8 01:30:22 FBSDG4S0 kernel: cd0: Attempt to query device size = failed: NOT READY, Medium not present Sep 8 01:30:22 FBSDG4S0 kernel: WC Mercury Electra 3G SSD 541ABBF0> = ATA-8 SATA 2.x device Sep 8 01:30:22 FBSDG4S0 kernel: ada0: Serial Number ***DELETED*** Sep 8 01:30:22 FBSDG4S0 kernel: ada0: 66.700MB/s transfers (UDMA4, PIO = 512bytes) Sep 8 01:30:22 FBSDG4S0 kernel: ada0: 114473MB (234441648 512 byte = sectors: 16H 63S/T 16383C) Sep 8 01:30:22 FBSDG4S0 kernel: ada0: Previously was known as ad0 ... As far as I can tell all the USB devices are listed on the display if I = vary what is plugged in from boot attempt to boot attempt. But after = that it stops without the "ada0 at ata0 bus 0 scbus0 target 0 lun 0" = message each time (or any more messages). I will note that cd0 is not a = MATSHITA in the 733 MHz PowerMac. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 11:25:05 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C8A8801 for ; Mon, 8 Sep 2014 11:25:05 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB8FA1DEE for ; Mon, 8 Sep 2014 11:25:04 +0000 (UTC) Received: (qmail 21429 invoked from network); 8 Sep 2014 11:25:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Sep 2014 11:25:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 08 Sep 2014 07:25:02 -0400 (EDT) Received: (qmail 12120 invoked from network); 8 Sep 2014 11:25:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2014 11:25:02 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 3CBE81C402B for ; Mon, 8 Sep 2014 04:25:00 -0700 (PDT) From: Mark Millard Subject: iMac G3 vs. Xorg/xfce4: Module fbdevhw does not have a fbdevhwModuleData data object [Unable to test Justin H.'s powerpc fixes on G3] Message-Id: <0602E4A2-12D0-4E3F-A8B1-2FC5FBC34FE8@dsl-only.net> Date: Mon, 8 Sep 2014 04:24:57 -0700 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 11:25:05 -0000 I booted a iMac G3 with=20 FreeBSD FBSDG4S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r270981: Wed = Sep 3 04:01:09 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC = powerpc that had Xorg and xfce4 installed. I generated a xorg.conf file via Xorg = -configure. startxfce4 got (from /var/log/Xorg.0.log): ... [ 383.775] (II) R128: Driver for ATI Rage 128 chipsets: ... [ 383.791] (=3D=3D) R128(0): RGB weight 888 [ 383.791] (II) R128(0): Using 8 bits per RGB (8 bit DAC) [ 383.791] (**) R128(0): Using framebuffer device [ 383.791] (II) Loading sub module "fbdevhw" [ 383.791] (II) LoadModule: "fbdevhw" [ 383.794] (II) Loading /usr/local/lib/xorg/modules/libfbdevhw.so [ 383.796] (EE) LoadModule: Module fbdevhw does not have a = fbdevhwModuleData data object. [ 383.796] (II) UnloadModule: "fbdevhw" [ 383.796] (II) Unloading fbdevhw [ 383.797] (EE) R128: Failed to load module "fbdevhw" (invalid module, = 0) [ 383.797] (II) UnloadModule: "r128" [ 383.797] (EE) Screen(s) found, but none have a usable configuration. [ 383.797]=20 Fatal server error: [ 383.797] no screens found ... I'll note that there is no Chipset line in the file: no identification = of the specific Rage 128 variant. So far I've not found a xorg.conf = variant that makes the iMac G3 work for Xorg/xfce4. So as of yet I've not been able to test Justin Hibitts' recent = powerpc/powerpc64 changes on the only working G3 that I have access to. = (Actually the above boot was an attempt to see the before-change = behavior first: The FreeBSD predates his changes to stable/10.) (Justin's changes fixed Xorg/xfce4 issues that were happening on the = Dual Processor G4 PowerMacs that I have access to. The single-processor = G4 PowerMac that FreeBSD can boot and the G5 Powermacs continue to have = Xorg/xfce4 working before and after Justin's changes.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 11:43:59 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0852AC48 for ; Mon, 8 Sep 2014 11:43:59 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99DC01FBB for ; Mon, 8 Sep 2014 11:43:57 +0000 (UTC) Received: (qmail 26930 invoked from network); 8 Sep 2014 11:43:56 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 8 Sep 2014 11:43:56 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 08 Sep 2014 07:43:56 -0400 (EDT) Received: (qmail 28153 invoked from network); 8 Sep 2014 11:43:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2014 11:43:56 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 57F351C402C for ; Mon, 8 Sep 2014 04:43:54 -0700 (PDT) From: Mark Millard Subject: Xorg/xfce4 vs. NVIDIA GeForce4 Ti 4600 on PowerMac G4: an odd display problem Message-Id: <2150A9D2-7876-4731-B0D1-441E20711441@dsl-only.net> Date: Mon, 8 Sep 2014 04:43:55 -0700 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 11:43:59 -0000 [This message gives what was a side note in another message its own = message.] 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 oddly placed, about 8 pixel wide band 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 other NVIDIA cards and the Radeon's that I tried in various G4 and = G5 PowerMac's do not show this display problem at the pixel counts that = they allow. The display works normally under Mac OS X 10.4 and 10.5. Context: FreeBSD FBSDG4S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271215: Sat = Sep 6 23:56:15 PDT 2014 root at = FBSDG4S0:/usr/obj/usr/src/sys/GENERIC powerpc portsnap was used and all ports were rebuilt from scratch, including = Xorg and xfce4. =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 12:41:12 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BAC1DC6 for ; Mon, 8 Sep 2014 12:41:12 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B78521826 for ; Mon, 8 Sep 2014 12:41:11 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id l4so4036666lbv.8 for ; Mon, 08 Sep 2014 05:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gqocMSyDOW4A6e1LmAzSYPatG4w3TkhYn9XFlhLNfqY=; b=ov8Nj0HUPsWIy/g5RbbymnzNKrjqSnn26kjIwJbsrbHTPjC4zyDl8/l0sFn/N2Wc9O Bz/ur4JxIxtQtbwrPxzxrBqELiuigLQDyYkXZFgr+u9Xx/usXQw5GpLnwDJkJPuG8Gwv ZRsfT99+jhVh/EcF6jx1giXemf9WOrzxNjbKPC6LpAW/38Vfkt1Iz4vn1VJ6bwb9JXwc Tfn1s9+5/lx82SFRN/rl6m0N86x2wrJbxTwmFOB4Bld0gV12yRDYJ+lE6WrBIdp6jliL mHKC7b1En8FA58vX73esdOxCS/t4GC6axSPTgFg2nrE7ZRJFfs+AkOa3yKfrCbAfPKR1 x8ZQ== X-Received: by 10.112.62.229 with SMTP id b5mr27079953lbs.60.1410180068640; Mon, 08 Sep 2014 05:41:08 -0700 (PDT) Received: from [192.168.1.197] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by mx.google.com with ESMTPSA id bw3sm3519917lbd.14.2014.09.08.05.41.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 05:41:07 -0700 (PDT) Message-ID: <540DA3DB.9080200@gmail.com> Date: Mon, 08 Sep 2014 15:40:59 +0300 From: Jukka Ukkonen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: Re: Just FYI: GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 display: [mi] EQ overflowing References: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> In-Reply-To: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 12:41:12 -0000 On 2014-09-08 11:47, Mark Millard wrote: > FYI: The GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 display (ADC with converter to DVI) reports the following > > [mi] EQ overflowing. Additional events will be discarded until existing events are processed. > [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. > [mi] mieq is *NOT* the cause. It is a victim. > [mi] Increasing EQ size to 512 to prevent dropped events. > [mi] EQ processing has resumed after 51 dropped events. > [mi] This may be caused my a misbehaving driver monopolizing the server's resources. This may be a more generic problem and not really related to PowerPC environments only. I have seen similar mi-complaints on a 12 core AMD64 system with a Radeon GPU running 10-stable. These problems have only occurred after the introduction of VT-consoles and KMS enabled X11. Cheers, --jau From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 8 17:41:39 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A41D2C43 for ; Mon, 8 Sep 2014 17:41:39 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DC521F50 for ; Mon, 8 Sep 2014 17:41:38 +0000 (UTC) Received: (qmail 31456 invoked from network); 8 Sep 2014 17:41:36 -0000 Received: from unknown (HELO mail-cs-05.app.dca.reflexion.local) (10.81.19.5) by 0 (rfx-qmail) with SMTP; 8 Sep 2014 17:41:36 -0000 Received: by mail-cs-05.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 08 Sep 2014 13:41:36 -0400 (EDT) Received: (qmail 32450 invoked from network); 8 Sep 2014 17:41:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2014 17:41:36 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 80DCF1C4056 for ; Mon, 8 Sep 2014 10:41:32 -0700 (PDT) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Just FYI: GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 display: [mi] EQ overflowing Date: Mon, 8 Sep 2014 10:41:34 -0700 References: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> To: freebsd-ppc@freebsd.org In-Reply-To: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 17:41:39 -0000 On Mon Sep 8 12:41:12 UTC 2014 Jukka Ukkonen wrote: > This may be a more generic problem and not really related to PowerPC=20= > environments > only. I have seen similar mi-complaints on a 12 core AMD64 system with = a=20 > Radeon GPU > running 10-stable. > These problems have only occurred after the introduction of = VT-consoles=20 > and KMS enabled > X11. The powerpc context that I reported on is still using scons and there is = no NVIDIA KMS to my knowledge, much less a powerpc one spanning NVIDIA = if I understand right. So I'd guess that even if the time frame is similar for when you = observed behavior changes that the actual issue is not VT nor KMS of = themselves. If any more general/generic changes were also made that = would span scons and NVIDIA then such could contribute. But the same kind of NVIDIA card used on the same kind of PowerMac G5 = with a 1920x1200 display does not generate those notices for the same = SSD being used to boot. The notices that I reported seem to be tied to = the card having more pixels to deal with (2560x1440), at least for the = context I reported about. I have no evidence of it being tied to = anything else but I've not tested an older context recently and do not = remember the details from my prior use. (I had reasons to be testing = basic Xorg/xfce4 display behavior recently and so noticed various = notifications more than usual.) I could imagine internal display-handling configuration tradeoffs in = Xorg based on the number of pixels the display has. May be the 2560x1440 = is just more extreme than the management of the display handling is = designed to well span. All guess work on my part. =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 1:47 AM, Mark Millard wrote: FYI: The GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 = display (ADC with converter to DVI) reports the following [mi] EQ overflowing. Additional events will be discarded until existing = events are processed. [mi] These backtraces from mieqEnqueue may point to a culprit higher up = the stack. [mi] mieq is *NOT* the cause. It is a victim. [mi] Increasing EQ size to 512 to prevent dropped events. [mi] EQ processing has resumed after 51 dropped events. [mi] This may be caused my a misbehaving driver monopolizing the = server's resources. Context: I built a 10.1-PRERELEASE r271215 (to test Justin Hibbits' changes for = powerpc). I also used portsnap and then rebuilt my ports from scratch. 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 (I'd be surprised if this was powerpc or PowerMac specific. But use of = these old cards may be more likely for PCI-Express PowerMacs.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 9 01:41:49 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 909C8FE; Tue, 9 Sep 2014 01:41:49 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E310912A8; Tue, 9 Sep 2014 01:22:22 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id m19so243593oag.16 for ; Mon, 08 Sep 2014 18:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xB+VZYdZV1rusA+oKhoSDx1lw6szFQWBRQy74wM71EA=; b=YG4qVEfrdfRzxkQGV4Dwf6a9eRLa272WqySACKRA+DkR283LC6SaDRfCfkgFuQTpBo ubXxaYfh+ez7EN9T1DEW4BSQjyQle+5UyKFYWJNQr6uF9i72oFEgQuDfIAY/sEqVVuxj ZHvWZxlyn4sFUJgTRMKxy7+Y0JC5v81HhaySdNLoEA2aCyFg9S16JvvXEbjEV1IONj5i KAG4RM0DKuCjU2kOcW+h35ZkONfbAkJxgG/WX4oJiJyu1D93+az3jpGl7+uMkHIQXS2V u9DN+fr04CHjoLXUruE2wExMViOPZooTJcyeSc2GkQKoOIQkgYDr1abfpsQnDuX7CatM ziEA== MIME-Version: 1.0 X-Received: by 10.60.161.71 with SMTP id xq7mr17729308oeb.1.1410225742156; Mon, 08 Sep 2014 18:22:22 -0700 (PDT) Received: by 10.182.87.33 with HTTP; Mon, 8 Sep 2014 18:22:22 -0700 (PDT) Date: Mon, 8 Sep 2014 21:22:22 -0400 Message-ID: Subject: Any recent spam that states it is from me is not. From: Joe Nosay To: FreeBSD PowerPC ML , FreeBSD Mailing List , FreeBSD Hackers , freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 01:41:49 -0000 Please check the headers and then ask me. This is for those who may assume that I do such things. From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 9 04:17:42 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FD7CF7F for ; Tue, 9 Sep 2014 04:17:42 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7A3B9EF for ; Tue, 9 Sep 2014 04:17:41 +0000 (UTC) Received: (qmail 8203 invoked from network); 9 Sep 2014 04:17:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Sep 2014 04:17:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 09 Sep 2014 00:17:34 -0400 (EDT) Received: (qmail 11453 invoked from network); 9 Sep 2014 04:17:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Sep 2014 04:17:33 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 306201C4007; Mon, 8 Sep 2014 21:17:27 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: powerpc64/GENERIC64 for NVIDIA now crashes Xorg (backtrace included) for Option-Fn; Radeon gets a display oddity From: Mark Millard In-Reply-To: Date: Mon, 8 Sep 2014 21:17:28 -0700 Message-Id: References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <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> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Justin Hibbits , freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 04:17:42 -0000 Well I built powerpc64/GENERIC64 with a fresh set of ports (all via svn = for a previously unused SSD): FreeBSD FBSDG5S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271278: Mon = Sep 8 12:40:56 PDT 2014 = root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc I built this with /etc/make.conf having: WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D # To avoid the problem with the above. WITH_DEBUG=3D I tried startxfce4 first for a quad-core PowerMac G5 with a NVIDIA = GeForce 7800 GT While startxfce4 works a later Option-Fn (to get to VTn) does not: I end = up stuck at a black screen. The tail of the Xorg.0.log shows that Xorg suddenly quit when I did the = Option-Fn: [ 48.476] (**) Option "XkbLayout" "us" [ 48.476] (**) Option "config_info" = "hal:/org/freedesktop/Hal/devices/usb_device_5ac_24f_noserial_if0" [ 48.476] (II) XINPUT: Adding extended input device "Apple Keyboard" = (type: KEYBOARD, id 8) [ 416.255] [mi] Increasing EQ size to 512 to prevent dropped events. [ 417.012] (II) UnloadModule: "kbd" [ 417.037] (II) UnloadModule: "mouse" [ 417.037] (II) UnloadModule: "kbd" [ 418.103] Server terminated successfully (0). Closing log file. [It is also interesting that the "EQ size" notice seems to be the first = thing from the time that I hit Option-Fn: Until then it did not have = that problem.] /var/log/messages also reports that Xorg coredumped: Sep 8 20:26:34 FBSDG5S0 dbus[909]: [system] Activating service = name=3D'org.freedesktop.UPower' (using servicehelper) Sep 8 20:26:34 FBSDG5S0 dbus[909]: [system] Successfully activated = service 'org.freedesktop.UPower' Sep 8 20:32:36 FBSDG5S0 kernel: pid 1109 (Xorg), uid 0: exited on = signal 11 (core dumped) /usr/local/bin/gdb reports based on the core produced: Core was generated by `Xorg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __jemalloc_bitmap_unset (bit=3D0, binfo=3D, = bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 156 g =3D *gp; (gdb) info threads Id Target Id Frame=20 * 2 Thread 51406400 (LWP 100097) __jemalloc_bitmap_unset (bit=3D0, = binfo=3D, bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 * 1 Thread 51406400 (LWP 100097) __jemalloc_bitmap_unset (bit=3D0, = binfo=3D, bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 (gdb) info stack #0 __jemalloc_bitmap_unset (bit=3D0, binfo=3D, = bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 #1 arena_run_reg_dalloc (ptr=3D, run=3D) = at jemalloc_arena.c:357 #2 __jemalloc_arena_dalloc_bin_locked (arena=3D0x510000c0, = chunk=3D0x51400000, ptr=3D0x5144d140, mapelm=3D) at = jemalloc_arena.c:1709 #3 0x0000000050c07a04 in __jemalloc_arena_dalloc_bin (arena=3D0x510000c0,= chunk=3D0x51400000, ptr=3D0x5144d140, pageind=3D, = mapelm=3D0x514006d8) at jemalloc_arena.c:1733 #4 0x0000000050c07a94 in __jemalloc_arena_dalloc_small = (arena=3D, chunk=3D, ptr=3D, pageind=3D) at jemalloc_arena.c:1749 #5 0x0000000050c1226c in __jemalloc_arena_dalloc (try_tcache=3D, ptr=3D, chunk=3D, arena=3D0x510000c0)= at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h= :1005 #6 __jemalloc_idallocx (try_tcache=3D, ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:913 #7 __jemalloc_iqallocx (try_tcache=3D, ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:932 #8 __jemalloc_iqalloc (ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:939 #9 __free (ptr=3D0x5144d140) at jemalloc_jemalloc.c:1277 #10 0x00000000102a57c4 in _XSERVTransFreeConnInfo (ciptr=3D0x5144d140) = at /usr/local/include/X11/Xtrans/Xtrans.c:146 #11 0x00000000102a72d8 in _XSERVTransClose (ciptr=3D0x5144d140) at = /usr/local/include/X11/Xtrans/Xtrans.c:962 #12 0x00000000102960d0 in CloseWellKnownConnections () at = connection.c:486 #13 0x00000000102aa3ac in AbortServer () at log.c:473 #14 0x00000000102aa974 in FatalError (f=3D0x102d68c0 "Caught signal %d = (%s). Server aborting\n") at log.c:611 #15 0x000000001029c744 in OsSigHandler (signo=3D11, = sip=3D0xffffffffffffd740, unused=3D0xffffffffffffd280) at osinit.c:146 #16 0x00000000506ae478 in handle_signal (actp=3D0xffffffffffffd1a0, = sig=3D11, info=3D0xffffffffffffd740, ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:238 #17 0x00000000506ae790 in thr_sighandler (sig=3D11, = info=3D0xffffffffffffd740, _ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:183 #18 0xffffffffffffe188 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Attempting use of a ATI Radeon 9800PRO NH (AGP) based Dual Processor = PowerMac G5 goes better: Option-Fn works for getting to VTn, including = getting back to the Xorg/xfce4 session. But there is a display oddity when going away from the Xorg/xfce4 = session to other scons VTn's: a band a few pixels wide at the top and = another at the bottom of the screen still show the pixels from the = Xorg/xfce4 session. =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 12:29 AM, Mark Millard wrote: 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 at dsl-only.net On Sep 6, 2014, at 6:05 PM, Justin Hibbits 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 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 > wrote: >=20 > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard 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 From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 9 05:10:23 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE31690C for ; Tue, 9 Sep 2014 05:10:22 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51B4AD81 for ; Tue, 9 Sep 2014 05:10:21 +0000 (UTC) Received: (qmail 32276 invoked from network); 9 Sep 2014 05:10:20 -0000 Received: from unknown (HELO mail-cs-05.app.dca.reflexion.local) (10.81.19.5) by 0 (rfx-qmail) with SMTP; 9 Sep 2014 05:10:20 -0000 Received: by mail-cs-05.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 09 Sep 2014 01:10:20 -0400 (EDT) Received: (qmail 17531 invoked from network); 9 Sep 2014 05:10:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Sep 2014 05:10:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 5A2561C4007; Mon, 8 Sep 2014 22:10:13 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: powerpc64/GENERIC64 for NVIDIA now crashes Xorg (backtrace included) for Option-Fn; Radeon gets a display oddity From: Mark Millard In-Reply-To: Date: Mon, 8 Sep 2014 22:10:18 -0700 Message-Id: <87D45E18-4312-4B74-8309-D35E66F86F99@dsl-only.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <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> To: Nathan Whitehorn , Justin Hibbits X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 05:10:23 -0000 More notes for and the NVIDIA and Radeon contexts for... FreeBSD FBSDG5S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271278: Mon = Sep 8 12:40:56 PDT 2014 = root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc The NVIDIA GeForce 7800 GT also is getting stuck at a black screen for = logging out of xfce4. And that does mean that Xorg/xfce4 are quitting, but not with the same = backtrace as for the NVIDIA Option-Fn crashes: Core was generated by `Xorg'. Program terminated with signal SIGABRT, Aborted. #0 0x0000000050bc49d8 in .__sys_thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) info threads Id Target Id Frame=20 * 2 Thread 51406400 (LWP 100071) 0x0000000050bc49d8 in = .__sys_thr_kill () at thr_kill.S:3 * 1 Thread 51406400 (LWP 100071) 0x0000000050bc49d8 in = .__sys_thr_kill () at thr_kill.S:3 (gdb) info stack #0 0x0000000050bc49d8 in .__sys_thr_kill () at thr_kill.S:3 #1 0x00000000506ae274 in _thr_send_sig (thread=3D, = sig=3D6) at /usr/src/lib/libthr/thread/thr_sig.c:113 #2 0x0000000050ca6068 in abort () at = /usr/src/lib/libc/stdlib/abort.c:65 #3 0x00000000102a0370 in OsAbort () at utils.c:1198 #4 0x00000000100c04a8 in ddxGiveUp (error=3DEXIT_ERR_ABORT) at = xf86Init.c:1009 #5 0x00000000100c064c in AbortDDX (error=3DEXIT_ERR_ABORT) at = xf86Init.c:1053 #6 0x00000000102aa3cc in AbortServer () at log.c:476 #7 0x00000000102aa974 in FatalError (f=3D0x102d68c0 "Caught signal %d = (%s). Server aborting\n") at log.c:611 #8 0x000000001029c744 in OsSigHandler (signo=3D11, = sip=3D0xffffffffffffd740, unused=3D0xffffffffffffd280) at osinit.c:146 #9 0x00000000506ae478 in handle_signal (actp=3D0xffffffffffffd1a0, = sig=3D11, info=3D0xffffffffffffd740, ucp=3D0xffffffffffffd280) at /usr/src/lib/libthr/thread/thr_sig.c:238 #10 0x00000000506ae790 in thr_sighandler (sig=3D11, = info=3D0xffffffffffffd740, _ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:183 #11 0xffffffffffffe188 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) The logout is producing a Xorg core file. It would also appear that Xorg = is not doing the proper cleanup/context-restore in some manor. The ATI Radeon 9800PRO NH (AGP) gets a worse problem when I log out of = xfce4 (compared to what I reported for Radeon's Option-Fn handling): = When it returns to scons (say) VT1 the input from the keyboard is messed = up. Option-Fn to a different VTn and input starts working. Option-F1 (back = to the original) and input is again working there. (The top and bottom pixel bands from the Xorg/xfce4 session can still be = there after Xorg/xfce4 has quit [via SIGABRT for the logout]. But = otherwise the display is working: it is not just stuck at black.) The Radeon xfce4 logout is also producing a Xorg core file but it's = backtrace appears to look normal for SIGABRT from what I can tell. = (Although it is not clear to me why SIGABRT is classified as appropriate = for a core dump.) =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 9:17 PM, Mark Millard wrote: Well I built powerpc64/GENERIC64 with a fresh set of ports (all via svn = for a previously unused SSD): FreeBSD FBSDG5S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271278: Mon = Sep 8 12:40:56 PDT 2014 = root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc I built this with /etc/make.conf having: WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D # To avoid the problem with the above. WITH_DEBUG=3D I tried startxfce4 first for a quad-core PowerMac G5 with a NVIDIA = GeForce 7800 GT While startxfce4 works a later Option-Fn (to get to VTn) does not: I end = up stuck at a black screen. The tail of the Xorg.0.log shows that Xorg suddenly quit when I did the = Option-Fn: [ 48.476] (**) Option "XkbLayout" "us" [ 48.476] (**) Option "config_info" = "hal:/org/freedesktop/Hal/devices/usb_device_5ac_24f_noserial_if0" [ 48.476] (II) XINPUT: Adding extended input device "Apple Keyboard" = (type: KEYBOARD, id 8) [ 416.255] [mi] Increasing EQ size to 512 to prevent dropped events. [ 417.012] (II) UnloadModule: "kbd" [ 417.037] (II) UnloadModule: "mouse" [ 417.037] (II) UnloadModule: "kbd" [ 418.103] Server terminated successfully (0). Closing log file. [It is also interesting that the "EQ size" notice seems to be the first = thing from the time that I hit Option-Fn: Until then it did not have = that problem.] /var/log/messages also reports that Xorg coredumped: Sep 8 20:26:34 FBSDG5S0 dbus[909]: [system] Activating service = name=3D'org.freedesktop.UPower' (using servicehelper) Sep 8 20:26:34 FBSDG5S0 dbus[909]: [system] Successfully activated = service 'org.freedesktop.UPower' Sep 8 20:32:36 FBSDG5S0 kernel: pid 1109 (Xorg), uid 0: exited on = signal 11 (core dumped) /usr/local/bin/gdb reports based on the core produced: Core was generated by `Xorg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __jemalloc_bitmap_unset (bit=3D0, binfo=3D, = bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 156 g =3D *gp; (gdb) info threads Id Target Id Frame=20 * 2 Thread 51406400 (LWP 100097) __jemalloc_bitmap_unset (bit=3D0, = binfo=3D, bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 * 1 Thread 51406400 (LWP 100097) __jemalloc_bitmap_unset (bit=3D0, = binfo=3D, bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 (gdb) info stack #0 __jemalloc_bitmap_unset (bit=3D0, binfo=3D, = bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 #1 arena_run_reg_dalloc (ptr=3D, run=3D) = at jemalloc_arena.c:357 #2 __jemalloc_arena_dalloc_bin_locked (arena=3D0x510000c0, = chunk=3D0x51400000, ptr=3D0x5144d140, mapelm=3D) at = jemalloc_arena.c:1709 #3 0x0000000050c07a04 in __jemalloc_arena_dalloc_bin (arena=3D0x510000c0,= chunk=3D0x51400000, ptr=3D0x5144d140, pageind=3D, = mapelm=3D0x514006d8) at jemalloc_arena.c:1733 #4 0x0000000050c07a94 in __jemalloc_arena_dalloc_small = (arena=3D, chunk=3D, ptr=3D, pageind=3D) at jemalloc_arena.c:1749 #5 0x0000000050c1226c in __jemalloc_arena_dalloc (try_tcache=3D, ptr=3D, chunk=3D, arena=3D0x510000c0)= at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h= :1005 #6 __jemalloc_idallocx (try_tcache=3D, ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:913 #7 __jemalloc_iqallocx (try_tcache=3D, ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:932 #8 __jemalloc_iqalloc (ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:939 #9 __free (ptr=3D0x5144d140) at jemalloc_jemalloc.c:1277 #10 0x00000000102a57c4 in _XSERVTransFreeConnInfo (ciptr=3D0x5144d140) = at /usr/local/include/X11/Xtrans/Xtrans.c:146 #11 0x00000000102a72d8 in _XSERVTransClose (ciptr=3D0x5144d140) at = /usr/local/include/X11/Xtrans/Xtrans.c:962 #12 0x00000000102960d0 in CloseWellKnownConnections () at = connection.c:486 #13 0x00000000102aa3ac in AbortServer () at log.c:473 #14 0x00000000102aa974 in FatalError (f=3D0x102d68c0 "Caught signal %d = (%s). Server aborting\n") at log.c:611 #15 0x000000001029c744 in OsSigHandler (signo=3D11, = sip=3D0xffffffffffffd740, unused=3D0xffffffffffffd280) at osinit.c:146 #16 0x00000000506ae478 in handle_signal (actp=3D0xffffffffffffd1a0, = sig=3D11, info=3D0xffffffffffffd740, ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:238 #17 0x00000000506ae790 in thr_sighandler (sig=3D11, = info=3D0xffffffffffffd740, _ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:183 #18 0xffffffffffffe188 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Attempting use of a ATI Radeon 9800PRO NH (AGP) based Dual Processor = PowerMac G5 goes better: Option-Fn works for getting to VTn, including = getting back to the Xorg/xfce4 session. But there is a display oddity when going away from the Xorg/xfce4 = session to other scons VTn's: a band a few pixels wide at the top and = another at the bottom of the screen still show the pixels from the = Xorg/xfce4 session. =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 12:29 AM, Mark Millard wrote: 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 at dsl-only.net On Sep 6, 2014, at 6:05 PM, Justin Hibbits 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 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 > wrote: >=20 > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard 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 From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 9 16:11:10 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8EEDAD for ; Tue, 9 Sep 2014 16:11:10 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BF2116A for ; Tue, 9 Sep 2014 16:11:10 +0000 (UTC) Received: from [172.29.13.157] ([66.129.239.11]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s89GB8ij011045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Sep 2014 09:11:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: multipart/signed; boundary="Apple-Mail=_CDDAE297-F448-44F9-97F2-68B0A76CED4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: [booke] preloading limited to initial mapping in kernel Message-Id: Date: Tue, 9 Sep 2014 09:11:02 -0700 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:11:10 -0000 --Apple-Mail=_CDDAE297-F448-44F9-97F2-68B0A76CED4F Content-Type: multipart/mixed; boundary="Apple-Mail=_9CBBB915-A277-43BE-8F77-3E9533C47C96" --Apple-Mail=_9CBBB915-A277-43BE-8F77-3E9533C47C96 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All, The kernel creates a single 16MB mapping in locore.S under the assumption that what got preloaded fits that size. With the metadata at the end of what's preloaded, the kernel will simply fail to boot is the total amount preloaded is larger than the initial mapping. Juniper fixed this problem by having the loader create the initial mapping based on the total size preloaded and communicate this to the kernel by virtue of the number of TLBs used. A change was made in locore.S to detect Juniper's loader and skip over the entire TLB1 fiddling. Juniper is currently porting Junos onto the latest FreeBSD version using mostly stock FreeBSD bits and problem described above is back again. Juniper has 2 options: 1. Make the same change to FreeBSD's loader as it did before. The problem with this approach is that newer U-Boot versions use the first few TLB1 entries for itself, meaning that the loader has to jump through a few hoops to make sure it can use the first N entries without destroying the entries used by U-Boot and itself. 2. Change locore.S and map enough to cover all the preloaded bits. The problem here is that the kernel does not know how much is preloaded. While it's easy enough to tell the kernel that, the problem is that the kernel must have a reliable way to detect by which loader it was loaded so that it knows whether the size of preloading is in whatever register we dedicate for that. Juniper's loader swizzled the registers so that the kernel can check for this. To be precise: FreeBSD's loader passes the metadata pointer (MDP) in r3. Juniper's loader sets r3 to 0 and passes the MDP in r4. Note also that I added support for booting directly from U-Boot. I'd like that to continue to work for as much as is possible. I'd like suggestions as to what approach to use. I played with the first (change the loader) and it can be made to work. It just doesn't feel right. I attached the patch for reference. Thanks, -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_9CBBB915-A277-43BE-8F77-3E9533C47C96 Content-Disposition: attachment; filename=booke.diff Content-Type: application/octet-stream; name="booke.diff" Content-Transfer-Encoding: 7bit Index: sys/boot/powerpc/uboot/tlb.c =================================================================== --- sys/boot/powerpc/uboot/tlb.c (revision 0) +++ sys/boot/powerpc/uboot/tlb.c (revision 0) @@ -0,0 +1,215 @@ +/*- + * Copyright (C) 2007-2014 Juniper Networks, Inc. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include + +#define BOOKE +#define BOOKE_E500 +#include +#include + +#include "libuboot.h" + +#define MAX_ENTRIES 4 + +static __inline uint32_t +ilog2(uint32_t num) +{ + uint32_t lz; + + __asm __volatile("cntlzw %0, %1" : "=r" (lz) : "r" (num)); + return (31 - lz); +} + +static void +tlb1_write_entry(int idx, uint32_t pa, uint32_t va, uint32_t sz) +{ + uint32_t mas0, mas1, mas2, mas3, pvr; + + pvr = mfspr(SPR_PVR) >> 16; + sz = ilog2(sz) / 2 - 5; + + mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(idx); + mas1 = MAS1_VALID | MAS1_IPROT | + ((sz << MAS1_TSIZE_SHIFT) & MAS1_TSIZE_MASK); + mas2 = (va & MAS2_EPN_MASK) | MAS2_M; + mas3 = (pa & MAS3_RPN) | MAS3_SR | MAS3_SW | MAS3_SX; + + mtspr(SPR_MAS0, mas0); + __asm volatile("isync"); + mtspr(SPR_MAS1, mas1); + __asm volatile("isync"); + mtspr(SPR_MAS2, mas2); + __asm volatile("isync"); + mtspr(SPR_MAS3, mas3); + __asm volatile("isync"); + mtspr(SPR_MAS7, 0); + switch (pvr) { + case FSL_E500mc: + case FSL_E5500: + __asm volatile("isync"); + mtspr(SPR_MAS8, 0); + break; + default: + break; + } + __asm volatile("isync"); + __asm volatile("tlbwe"); + __asm volatile("isync"); + __asm volatile("msync"); +} + +static int +find_curr_tlb1_entry(void) +{ + uint32_t addr; + uint32_t pid, mas0, idx; + + addr = (uint32_t) find_curr_tlb1_entry; + pid = mfspr(SPR_PID0); + pid = pid << MAS6_SPID0_SHIFT; + mtspr(SPR_MAS6, pid); + __asm volatile("isync"); + __asm volatile("tlbsx 0,%0" :: "r"(addr)); + mas0 = mfspr(SPR_MAS0); + mas0 = mas0 >> 16; + idx = mas0 & 0x3f; + return (idx); +} + +static void +tlb1_invalidate(int skip_idx) +{ + uint32_t mas0, mas1, mas2, mas3, pvr; + int idx, tlb1_size; + + pvr = mfspr(SPR_PVR) >> 16; + tlb1_size = mfspr(SPR_TLB1CFG) & TLBCFG_NENTRY_MASK; + + printf("XXX: %s: skip_idx=%d, tlb1_size=%d\n", __func__, + skip_idx, tlb1_size); + + for (idx = 0; idx < tlb1_size; idx++) { + mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(idx); + mtspr(SPR_MAS0, mas0); + + __asm __volatile("isync; tlbre"); + + mas1 = mfspr(SPR_MAS1); + mas2 = mfspr(SPR_MAS2); + mas3 = mfspr(SPR_MAS3); + + printf("XXX: %02d: mas1=%04x mas2=%04x mas3=%04x\n", idx, + mas1, mas2, mas3); + } + + for (idx = 0; idx < tlb1_size; idx++) { + if (idx == skip_idx) + continue; + + printf("XXX: %s: idx=%d\n", __func__, idx); + + mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(idx); + mas1 = 0x00; + mas2 = 0x00; + mas3 = 0x00; + + mtspr(SPR_MAS0, mas0); + __asm volatile("isync"); + mtspr(SPR_MAS1, mas1); + __asm volatile("isync"); + mtspr(SPR_MAS2, mas2); + __asm volatile("isync"); + mtspr(SPR_MAS3, mas3); + __asm volatile("isync"); + mtspr(SPR_MAS7, 0); + switch (pvr) { + case FSL_E500mc: + case FSL_E5500: + __asm volatile("isync"); + mtspr(SPR_MAS8, 0); + break; + default: + break; + } + __asm volatile("isync"); + __asm volatile("tlbwe"); + __asm volatile("isync"); + __asm volatile("msync"); + } +} + +vm_size_t +uboot_map(vm_paddr_t pa, vm_offset_t va, vm_size_t sz) +{ + vm_size_t pgs[MAX_ENTRIES]; + vm_size_t mapped; + vm_size_t pgsz; + int idx, maxidx; + + sz = roundup(sz, 1048576); + + mapped = 0; + idx = 0; + pgsz = 64*1024*1024; + while (mapped < sz) { + while (mapped < sz && idx < MAX_ENTRIES) { + while (pgsz > (sz - mapped)) + pgsz >>= 2; + pgs[idx++] = pgsz; + mapped += pgsz; + } + /* We under-map. Correct for this. */ + if (mapped < sz) { + while (idx > 0 && pgs[idx - 1] == pgsz) { + idx--; + mapped -= pgsz; + } + /* XXX We may increase beyond out starting point. */ + pgsz <<= 2; + pgs[idx++] = pgsz; + mapped += pgsz; + } + } + + tlb1_invalidate(find_curr_tlb1_entry()); + + maxidx = idx; + for (idx = 0; idx < maxidx; idx++) { + pgsz = pgs[idx]; + tlb1_write_entry(idx, pa, va, pgsz); + pa += pgsz; + va += pgsz; + } + + printf("> mapped=%#x\n", mapped); + + return (mapped); +} Index: sys/boot/powerpc/uboot/Makefile =================================================================== --- sys/boot/powerpc/uboot/Makefile (revision 285901) +++ sys/boot/powerpc/uboot/Makefile (working copy) @@ -10,7 +10,7 @@ MAN= # Architecture-specific loader code SRCS= start.S conf.c vers.c -SRCS+= ucmpdi2.c +SRCS+= tlb.c ucmpdi2.c CFLAGS+= -DBOOTPROG=\"${PROG}\" Index: sys/boot/arm/uboot/conf.c =================================================================== --- sys/boot/arm/uboot/conf.c (revision 285901) +++ sys/boot/arm/uboot/conf.c (working copy) @@ -92,3 +92,9 @@ struct console *consoles[] = { &uboot_console, NULL }; + +vm_size_t +uboot_map(vm_paddr_t pa __unused, vm_offset_t va __unused, vm_size_t sz) +{ + return (sz); +} Index: sys/boot/uboot/lib/libuboot.h =================================================================== --- sys/boot/uboot/lib/libuboot.h (revision 285901) +++ sys/boot/uboot/lib/libuboot.h (working copy) @@ -62,6 +62,7 @@ ssize_t uboot_copyin(const void *src, vm_offset_t ssize_t uboot_copyout(const vm_offset_t src, void *dest, const size_t len); ssize_t uboot_readin(const int fd, vm_offset_t dest, const size_t len); extern int uboot_autoload(void); +vm_size_t uboot_map(vm_paddr_t pa, vm_offset_t va, vm_size_t size); struct preloaded_file; struct file_format; Index: sys/boot/uboot/common/metadata.c =================================================================== --- sys/boot/uboot/common/metadata.c (revision 285901) +++ sys/boot/uboot/common/metadata.c (working copy) @@ -41,10 +41,7 @@ __FBSDID("$FreeBSD$"); #include "api_public.h" #include "bootstrap.h" #include "glue.h" - -#if defined(LOADER_FDT_SUPPORT) #include "libuboot.h" -#endif static int md_getboothowto(char *kargs) @@ -251,11 +248,11 @@ md_load(char *args, vm_offset_t *modulep) struct preloaded_file *kfp, *bfp; struct preloaded_file *xp; struct file_metadata *md; - struct bootinfo *bip; - vm_offset_t kernend; - vm_offset_t addr; - vm_offset_t envp; - vm_offset_t size; + vm_paddr_t kernbase; + vm_paddr_t kernend; + vm_paddr_t addr; + vm_paddr_t envp; + vm_size_t size; vm_offset_t vaddr; #if defined(LOADER_FDT_SUPPORT) vm_offset_t dtbp; @@ -290,33 +287,30 @@ md_load(char *args, vm_offset_t *modulep) /* Try reading the /etc/fstab file to select the root device */ getrootmount(rootdevname); - /* Find the last module in the chain */ - addr = 0; + /* Find the lowest and highest addresses used */ + kernend = 0; + kernbase = ~0; for (xp = file_findfile(NULL, NULL); xp != NULL; xp = xp->f_next) { - if (addr < (xp->f_addr + xp->f_size)) - addr = xp->f_addr + xp->f_size; + if (kernend < (xp->f_addr + xp->f_size)) + kernend = xp->f_addr + xp->f_size; + if (xp->f_addr < kernbase) + kernbase = xp->f_addr; } - /* Pad to a page boundary */ - addr = roundup(addr, PAGE_SIZE); + kernend = roundup(kernend, PAGE_SIZE); /* Copy our environment */ - envp = addr; - addr = md_copyenv(addr); + envp = kernend; + kernend = md_copyenv(kernend); + kernend = roundup(kernend, PAGE_SIZE); - /* Pad to a page boundary */ - addr = roundup(addr, PAGE_SIZE); - #if defined(LOADER_FDT_SUPPORT) /* Handle device tree blob */ - dtbp = addr; - dtb_size = fdt_copy(addr); - - /* Pad to a page boundary */ + dtbp = kernend; + dtb_size = fdt_copy(kernend); if (dtb_size) - addr += roundup(dtb_size, PAGE_SIZE); + kernend += roundup(dtb_size, PAGE_SIZE); #endif - kernend = 0; kfp = file_findfile(NULL, "elf32 kernel"); if (kfp == NULL) kfp = file_findfile(NULL, "elf kernel"); @@ -336,10 +330,15 @@ md_load(char *args, vm_offset_t *modulep) file_addmetadata(kfp, MODINFOMD_KERNEND, sizeof kernend, &kernend); /* Figure out the size and location of the metadata */ - *modulep = addr; + *modulep = addr = kernend; size = md_copymodules(0); - kernend = roundup(addr + size, PAGE_SIZE); + kernend += roundup(size, PAGE_SIZE); + vaddr = kernbase - __elfN(relocation_offset); + size = kernend - kernbase; + size = uboot_map(kernbase, vaddr, size); + kernend = kernbase + size; + /* Provide MODINFOMD_KERNEND */ md = file_findmetadata(kfp, MODINFOMD_KERNEND); bcopy(&kernend, md->md_data, sizeof kernend); --Apple-Mail=_9CBBB915-A277-43BE-8F77-3E9533C47C96 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_9CBBB915-A277-43BE-8F77-3E9533C47C96-- --Apple-Mail=_CDDAE297-F448-44F9-97F2-68B0A76CED4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQPJpYACgkQpgWlLWHuifafhQCfU2o4x9TmUZiKSZH95j09ITOd w/8AnRopZUhBKfUvxSvd/3rkZow6Y+pf =xqXU -----END PGP SIGNATURE----- --Apple-Mail=_CDDAE297-F448-44F9-97F2-68B0A76CED4F-- From owner-freebsd-ppc@FreeBSD.ORG Fri Sep 12 19:08:52 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 042B01AF for ; Fri, 12 Sep 2014 19:08:52 +0000 (UTC) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB101BA0 for ; Fri, 12 Sep 2014 19:08:51 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id l6so1262688qcy.29 for ; Fri, 12 Sep 2014 12:08:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=SsAjtWCco3rnrHkoqmuclzvHRA5zouR8UCGeNU2c2p4=; b=SirxOrgEhGNGf6d8I5Di6DZIp3jxE2KVE4RlTbarLxKsEEPqnOBS7T1K7EKHt8Yv9q dowhxRwl+3IENqgAOfDbgyfItKSLQMzZW3ti5s3Z4+J55Oq6c3GTZOYgkV21j0KLIzAq FuVM01rkcJjWE0m/JXQKAsnyOZ9Vf8ukgJnXSZ94LqdM5FmAbQy6miVVruMKcwDUq1ry xgD5e2J3DfDeVeE/DwMVgXv7KRClOipbZQdzpzSXSPdHoieZ0fktXvPY/ImP/64K/kjd LWgA/u9zLu7Pfl3A8THFk7n7jCIDmMtHptna0e1q6dIsoIKT8fh4UlIispQWF/acNHY8 7rZw== X-Gm-Message-State: ALoCoQnvF3fGvCSLlFlyUqtyf18AZRIDrz2q/CrwyaWOaQkbK7fYGf4CpjvuKwGWKhcVyc9BAFY6 X-Received: by 10.224.88.3 with SMTP id y3mr15090198qal.65.1410548919057; Fri, 12 Sep 2014 12:08:39 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Fri, 12 Sep 2014 12:08:18 -0700 (PDT) X-Originating-IP: [2620:0:1003:1007:5d6c:d71e:6b0d:48d3] From: Julio Merino Date: Fri, 12 Sep 2014 15:08:18 -0400 X-Google-Sender-Auth: UYTlaCL0AwsoeklsrharNSDnZ5A Message-ID: Subject: Mac Mini G4 displays black screen on install boot To: freebsd-ppc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 19:08:52 -0000 Hi all, I recently installed 10.0-RELEASE (and later upgraded to 10.1-PRERELEASE) on a Mac Mini G4. Both worked just fine: the kernel properly detected the DVI-attached 24" screen and selected the 1920x1200 native resolution. However, I just tried to boot an 11.0-CURRENT snapshot installation image (20140903-r270990) and things are very different. The kernel loaded just fine from the OpenFirmware prompt, but then the screen went completely black and the machine apparently locked up (the keyboard is unresponsive; not even caps lock works). I suspect this is because of the new console code but I have no proof of it. Has anyone successfully used newcons on a Mini G4? Any ideas on how to debug this? Thanks! From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 04:58:17 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2486FE5 for ; Sat, 13 Sep 2014 04:58:17 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C7FDA6F for ; Sat, 13 Sep 2014 04:58:16 +0000 (UTC) Received: (qmail 22695 invoked from network); 13 Sep 2014 04:58:09 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 04:58:09 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 00:58:09 -0400 (EDT) Received: (qmail 21044 invoked from network); 13 Sep 2014 04:58:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 04:58:08 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id D74E41C4007 for ; Fri, 12 Sep 2014 21:58:01 -0700 (PDT) From: Mark Millard Message-Id: <31587C4B-8167-4928-A2F2-D73D9FB479C7@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Just FYI: GeForce 7800 GT on a PowerMac Quad-core G5 with a 1920x1200 display: [mi] EQ overflowing Date: Fri, 12 Sep 2014 21:58:04 -0700 References: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> To: freebsd-ppc@freebsd.org In-Reply-To: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 04:58:17 -0000 Hi. I've now had this EQ overflowing notice with a 1920x1200 display on the = GeForce 7800 GT. I'll note that I've updated to ports r368074 which updated Xorg, the = drivers, and even gcc (to 4.8.3). This was 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 but booted on a G5 PowerMac quad-core (so lots of unused RAM for = powerpc/GENERIC). =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 8, 2014, at 1:47 AM, Mark Millard wrote: FYI: The GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 = display (ADC with converter to DVI) reports the following [mi] EQ overflowing. Additional events will be discarded until existing = events are processed. [mi] These backtraces from mieqEnqueue may point to a culprit higher up = the stack. [mi] mieq is *NOT* the cause. It is a victim. [mi] Increasing EQ size to 512 to prevent dropped events. [mi] EQ processing has resumed after 51 dropped events. [mi] This may be caused my a misbehaving driver monopolizing the = server's resources. Context: I built a 10.1-PRERELEASE r271215 (to test Justin Hibbits' changes for = powerpc). I also used portsnap and then rebuilt my ports from scratch. 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 (I'd be surprised if this was powerpc or PowerMac specific. But use of = these old cards may be more likely for PCI-Express PowerMacs.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 05:36:33 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB508684 for ; Sat, 13 Sep 2014 05:36:33 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D738D77 for ; Sat, 13 Sep 2014 05:36:32 +0000 (UTC) Received: (qmail 21988 invoked from network); 13 Sep 2014 05:36:31 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 05:36:31 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 01:36:31 -0400 (EDT) Received: (qmail 14466 invoked from network); 13 Sep 2014 05:34:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 05:34:11 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 0CD5D1C4007; Fri, 12 Sep 2014 22:34:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: For newer XOrg/drivers powerpc64/GENERIC64 for NVIDIA no longer crash but Option-Fn gets nearly black text on black background From: Mark Millard In-Reply-To: <87D45E18-4312-4B74-8309-D35E66F86F99@dsl-only.net> Date: Fri, 12 Sep 2014 22:34:09 -0700 Message-Id: <1F32DFC2-5CEC-4FA7-B0D4-1B02813348E8@dsl-only.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> <1B729E38-6495-4240-B9E2-A48238E4E830@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> <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> <87D45E18-4312-4B74-8309-D35E66F86F99@dsl-only.net> To: Nathan Whitehorn , Justin Hibbits X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 05:36:33 -0000 I've updated to ports r368074 which updated Xorg, the drivers, and even = gcc (to 4.8.3). I used portmaster -t -D -a. This was on both... 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 FreeBSD FBSDG5S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271278: Mon = Sep 8 12:40:56 PDT 2014 = root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc both being booted on Quad Core G5 PowerMacs with the GeForce 7800 GT's = to update and rebooted to test. (Both of these SSDs are builds for = WITH_DEBUG_FILES=3D and WITHOUT_CLANG=3D and WITH_DEBUG=3D in = /etc/make.conf.) The powerpc/GENERIC worked find for Option-Fn use. The powerpc64/GENERIC64 appeared to have the black screen issue. But... ... I noticed something for powerpc64/GENERIC64 due to the lighting = being different than earlier: Option-Fn is(!) displaying the VTn display but just extremely faintly: = instead of the text being a fairly bright white against a black = background for powerpc64/GENERIC64 the text is nearly the same black = color as the background. But it is slightly lighter and in properly set = up conditions I can read it. (It may be monitor dependent on if there is = enough of a difference to actually see it.) Option-F9 gets back to = xfce4's display just fine too. The powerpc64/GENERIC64 Xorg crash is gone as of this update. I've not tried other contexts yet. (Such as NVIDIA GeForce4 Ti 4600 on a = PowerMac G4.) Side notes: Because historically I've had lots of problems with gcc = (re)builds/updates on powerpc or powerpc64 otherwise, I have the = full-bootstrap option enabled for building lang/gcc. The only reason a use WITHOUT_CLANG=3D is because I get failures = otherwise when WITH_DEBUG_FILES=3D is enabled. Specifically: ... = /libclangsema.a(SemaAccess.o): Unknown relocation type ????? for symbol = *UND* =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 10:10 PM, Mark Millard wrote: More notes for and the NVIDIA and Radeon contexts for... FreeBSD FBSDG5S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271278: Mon = Sep 8 12:40:56 PDT 2014 = root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc The NVIDIA GeForce 7800 GT also is getting stuck at a black screen for = logging out of xfce4. And that does mean that Xorg/xfce4 are quitting, but not with the same = backtrace as for the NVIDIA Option-Fn crashes: Core was generated by `Xorg'. Program terminated with signal SIGABRT, Aborted. #0 0x0000000050bc49d8 in .__sys_thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) info threads Id Target Id Frame=20 * 2 Thread 51406400 (LWP 100071) 0x0000000050bc49d8 in = .__sys_thr_kill () at thr_kill.S:3 * 1 Thread 51406400 (LWP 100071) 0x0000000050bc49d8 in = .__sys_thr_kill () at thr_kill.S:3 (gdb) info stack #0 0x0000000050bc49d8 in .__sys_thr_kill () at thr_kill.S:3 #1 0x00000000506ae274 in _thr_send_sig (thread=3D, = sig=3D6) at /usr/src/lib/libthr/thread/thr_sig.c:113 #2 0x0000000050ca6068 in abort () at = /usr/src/lib/libc/stdlib/abort.c:65 #3 0x00000000102a0370 in OsAbort () at utils.c:1198 #4 0x00000000100c04a8 in ddxGiveUp (error=3DEXIT_ERR_ABORT) at = xf86Init.c:1009 #5 0x00000000100c064c in AbortDDX (error=3DEXIT_ERR_ABORT) at = xf86Init.c:1053 #6 0x00000000102aa3cc in AbortServer () at log.c:476 #7 0x00000000102aa974 in FatalError (f=3D0x102d68c0 "Caught signal %d = (%s). Server aborting\n") at log.c:611 #8 0x000000001029c744 in OsSigHandler (signo=3D11, = sip=3D0xffffffffffffd740, unused=3D0xffffffffffffd280) at osinit.c:146 #9 0x00000000506ae478 in handle_signal (actp=3D0xffffffffffffd1a0, = sig=3D11, info=3D0xffffffffffffd740, ucp=3D0xffffffffffffd280) at /usr/src/lib/libthr/thread/thr_sig.c:238 #10 0x00000000506ae790 in thr_sighandler (sig=3D11, = info=3D0xffffffffffffd740, _ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:183 #11 0xffffffffffffe188 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) The logout is producing a Xorg core file. It would also appear that Xorg = is not doing the proper cleanup/context-restore in some manor. The ATI Radeon 9800PRO NH (AGP) gets a worse problem when I log out of = xfce4 (compared to what I reported for Radeon's Option-Fn handling): = When it returns to scons (say) VT1 the input from the keyboard is messed = up. Option-Fn to a different VTn and input starts working. Option-F1 (back = to the original) and input is again working there. (The top and bottom pixel bands from the Xorg/xfce4 session can still be = there after Xorg/xfce4 has quit [via SIGABRT for the logout]. But = otherwise the display is working: it is not just stuck at black.) The Radeon xfce4 logout is also producing a Xorg core file but it's = backtrace appears to look normal for SIGABRT from what I can tell. = (Although it is not clear to me why SIGABRT is classified as appropriate = for a core dump.) =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 9:17 PM, Mark Millard wrote: Well I built powerpc64/GENERIC64 with a fresh set of ports (all via svn = for a previously unused SSD): FreeBSD FBSDG5S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271278: Mon = Sep 8 12:40:56 PDT 2014 = root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc I built this with /etc/make.conf having: WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D # To avoid the problem with the above. WITH_DEBUG=3D I tried startxfce4 first for a quad-core PowerMac G5 with a NVIDIA = GeForce 7800 GT While startxfce4 works a later Option-Fn (to get to VTn) does not: I end = up stuck at a black screen. The tail of the Xorg.0.log shows that Xorg suddenly quit when I did the = Option-Fn: [ 48.476] (**) Option "XkbLayout" "us" [ 48.476] (**) Option "config_info" = "hal:/org/freedesktop/Hal/devices/usb_device_5ac_24f_noserial_if0" [ 48.476] (II) XINPUT: Adding extended input device "Apple Keyboard" = (type: KEYBOARD, id 8) [ 416.255] [mi] Increasing EQ size to 512 to prevent dropped events. [ 417.012] (II) UnloadModule: "kbd" [ 417.037] (II) UnloadModule: "mouse" [ 417.037] (II) UnloadModule: "kbd" [ 418.103] Server terminated successfully (0). Closing log file. [It is also interesting that the "EQ size" notice seems to be the first = thing from the time that I hit Option-Fn: Until then it did not have = that problem.] /var/log/messages also reports that Xorg coredumped: Sep 8 20:26:34 FBSDG5S0 dbus[909]: [system] Activating service = name=3D'org.freedesktop.UPower' (using servicehelper) Sep 8 20:26:34 FBSDG5S0 dbus[909]: [system] Successfully activated = service 'org.freedesktop.UPower' Sep 8 20:32:36 FBSDG5S0 kernel: pid 1109 (Xorg), uid 0: exited on = signal 11 (core dumped) /usr/local/bin/gdb reports based on the core produced: Core was generated by `Xorg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __jemalloc_bitmap_unset (bit=3D0, binfo=3D, = bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 156 g =3D *gp; (gdb) info threads Id Target Id Frame=20 * 2 Thread 51406400 (LWP 100097) __jemalloc_bitmap_unset (bit=3D0, = binfo=3D, bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 * 1 Thread 51406400 (LWP 100097) __jemalloc_bitmap_unset (bit=3D0, = binfo=3D, bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 (gdb) info stack #0 __jemalloc_bitmap_unset (bit=3D0, binfo=3D, = bitmap=3D0xc3ba0f75) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/bitmap.= h:156 #1 arena_run_reg_dalloc (ptr=3D, run=3D) = at jemalloc_arena.c:357 #2 __jemalloc_arena_dalloc_bin_locked (arena=3D0x510000c0, = chunk=3D0x51400000, ptr=3D0x5144d140, mapelm=3D) at = jemalloc_arena.c:1709 #3 0x0000000050c07a04 in __jemalloc_arena_dalloc_bin (arena=3D0x510000c0,= chunk=3D0x51400000, ptr=3D0x5144d140, pageind=3D, = mapelm=3D0x514006d8) at jemalloc_arena.c:1733 #4 0x0000000050c07a94 in __jemalloc_arena_dalloc_small = (arena=3D, chunk=3D, ptr=3D, pageind=3D) at jemalloc_arena.c:1749 #5 0x0000000050c1226c in __jemalloc_arena_dalloc (try_tcache=3D, ptr=3D, chunk=3D, arena=3D0x510000c0)= at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h= :1005 #6 __jemalloc_idallocx (try_tcache=3D, ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:913 #7 __jemalloc_iqallocx (try_tcache=3D, ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:932 #8 __jemalloc_iqalloc (ptr=3D) at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:939 #9 __free (ptr=3D0x5144d140) at jemalloc_jemalloc.c:1277 #10 0x00000000102a57c4 in _XSERVTransFreeConnInfo (ciptr=3D0x5144d140) = at /usr/local/include/X11/Xtrans/Xtrans.c:146 #11 0x00000000102a72d8 in _XSERVTransClose (ciptr=3D0x5144d140) at = /usr/local/include/X11/Xtrans/Xtrans.c:962 #12 0x00000000102960d0 in CloseWellKnownConnections () at = connection.c:486 #13 0x00000000102aa3ac in AbortServer () at log.c:473 #14 0x00000000102aa974 in FatalError (f=3D0x102d68c0 "Caught signal %d = (%s). Server aborting\n") at log.c:611 #15 0x000000001029c744 in OsSigHandler (signo=3D11, = sip=3D0xffffffffffffd740, unused=3D0xffffffffffffd280) at osinit.c:146 #16 0x00000000506ae478 in handle_signal (actp=3D0xffffffffffffd1a0, = sig=3D11, info=3D0xffffffffffffd740, ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:238 #17 0x00000000506ae790 in thr_sighandler (sig=3D11, = info=3D0xffffffffffffd740, _ucp=3D0xffffffffffffd280) at = /usr/src/lib/libthr/thread/thr_sig.c:183 #18 0xffffffffffffe188 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Attempting use of a ATI Radeon 9800PRO NH (AGP) based Dual Processor = PowerMac G5 goes better: Option-Fn works for getting to VTn, including = getting back to the Xorg/xfce4 session. But there is a display oddity when going away from the Xorg/xfce4 = session to other scons VTn's: a band a few pixels wide at the top and = another at the bottom of the screen still show the pixels from the = Xorg/xfce4 session. =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 12:29 AM, Mark Millard wrote: 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 at dsl-only.net On Sep 6, 2014, at 6:05 PM, Justin Hibbits 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 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 > wrote: >=20 > On Sat, 6 Sep 2014 17:05:45 -0700 > Mark Millard 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 From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 06:59:56 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1E2037D for ; Sat, 13 Sep 2014 06:59:56 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23BE03FA for ; Sat, 13 Sep 2014 06:59:55 +0000 (UTC) Received: (qmail 28999 invoked from network); 13 Sep 2014 06:59:54 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 06:59:54 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 02:59:54 -0400 (EDT) Received: (qmail 13964 invoked from network); 13 Sep 2014 06:59:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 06:59:53 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id A0BFE1C4058 for ; Fri, 12 Sep 2014 23:59:52 -0700 (PDT) From: Mark Millard Message-Id: <8625AD3F-B059-482A-954E-F8BCFA189457@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Just FYI: NVIDIA GeForce4 Ti 4600 when used at 1680x1050 on a PowerMac G4 Dual: [mi] EQ overflowing Date: Fri, 12 Sep 2014 23:59:52 -0700 References: <508DA417-7E82-4E4B-B1F4-8A0309F5227A@dsl-only.net> <31587C4B-8167-4928-A2F2-D73D9FB479C7@dsl-only.net> To: freebsd-ppc@freebsd.org In-Reply-To: <31587C4B-8167-4928-A2F2-D73D9FB479C7@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 06:59:56 -0000 Context: I've updated to ports r368074 which updated Xorg, the drivers, = and even gcc (to 4.8.3). I used portmaster -t -D -a. This was 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 After this during an example logout from xfce4 I've gotten an example of = the EQ overflowing notices for: NVIDIA GeForce4 Ti 4600 when used at 1680x1050 on a PowerMac G4 Dual = (1.4 GHz FW800) Generally these EQ overflow messages seem to be tied to logout or = Option-Fn in basic use. (This is still an syscons context by default for = powerpc. At least Xorg.0.log reports that syscons is what is in use.) So far I do not get these kinds of notices systematically for this = context. Just infrequently. =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 12, 2014, at 9:58 PM, Mark Millard = wrote: Hi. I've now had this EQ overflowing notice with a 1920x1200 display on the = GeForce 7800 GT. I'll note that I've updated to ports r368074 which updated Xorg, the = drivers, and even gcc (to 4.8.3). This was 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 but booted on a G5 PowerMac quad-core (so lots of unused RAM for = powerpc/GENERIC). =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 1:47 AM, Mark Millard wrote: FYI: The GeForce 7800 GT on a PowerMac Quad-core G5 with a 2560x1440 = display (ADC with converter to DVI) reports the following [mi] EQ overflowing. Additional events will be discarded until existing = events are processed. [mi] These backtraces from mieqEnqueue may point to a culprit higher up = the stack. [mi] mieq is *NOT* the cause. It is a victim. [mi] Increasing EQ size to 512 to prevent dropped events. [mi] EQ processing has resumed after 51 dropped events. [mi] This may be caused my a misbehaving driver monopolizing the = server's resources. Context: I built a 10.1-PRERELEASE r271215 (to test Justin Hibbits' changes for = powerpc). I also used portsnap and then rebuilt my ports from scratch. 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 (I'd be surprised if this was powerpc or PowerMac specific. But use of = these old cards may be more likely for PCI-Express PowerMacs.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 07:26:28 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DC6D875 for ; Sat, 13 Sep 2014 07:26:28 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 108A383C for ; Sat, 13 Sep 2014 07:26:27 +0000 (UTC) Received: (qmail 30972 invoked from network); 13 Sep 2014 07:26:26 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 07:26:26 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 03:26:26 -0400 (EDT) Received: (qmail 13070 invoked from network); 13 Sep 2014 07:26:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 07:26:26 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 198F41C4058 for ; Sat, 13 Sep 2014 00:26:25 -0700 (PDT) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Xorg/xfce4 vs. NVIDIA GeForce4 Ti 4600 on PowerMac G4: an odd display problem Date: Sat, 13 Sep 2014 00:26:24 -0700 References: <2150A9D2-7876-4731-B0D1-441E20711441@dsl-only.net> To: freebsd-ppc@freebsd.org In-Reply-To: <2150A9D2-7876-4731-B0D1-441E20711441@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 07:26:28 -0000 Context: I've updated to ports r368074 which updated Xorg, the drivers, = and even gcc (to 4.8.3). I used portmaster -t -D -a. This was 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 which was then used on a... NVIDIA GeForce4 Ti 4600 when used at 1680x1050 on a PowerMac G4 Dual = (1.4GHz FW800) The update did not change the display oddity. But I need to correct part = of my description and possibly improve its form. There is a band of = missing pixels. Imagine the display in 5 vertical bands: A,B,C,D,E (left to right). A: 8 pixels wide or so. B: 8 pixels wide or so. D: 8 pixels wide or so. E: 8 pixels wide or so. C: The rest of the width in the middle. So a correct display would have (in order) A, B, C, D, E. What I actually get is (in visual left to right order): A, E, A, B, C. For example if part of the cursor is in A then one sees it twice. One = does not see anything from D. The cursor can be visibly moved from C to = E and back without the cursor traveling in the middle. E also appears to be shifted down a pixel from what it should be. This is not a change from the actual behavior before: I just had the = description wrong before. (xorg.conf is as Xorg -configure generated it. The updated Xorg = generates the same as before.) =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 8, 2014, at 4:43 AM, Mark Millard wrote: [This message gives what was a side note in another message its own = message.] 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 oddly placed, about 8 pixel wide band 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 other NVIDIA cards and the Radeon's that I tried in various G4 and = G5 PowerMac's do not show this display problem at the pixel counts that = they allow. The display works normally under Mac OS X 10.4 and 10.5. Context: FreeBSD FBSDG4S0 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271215: Sat = Sep 6 23:56:15 PDT 2014 root at = FBSDG4S0:/usr/obj/usr/src/sys/GENERIC powerpc portsnap was used and all ports were rebuilt from scratch, including = Xorg and xfce4. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 09:13:04 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 384D9E2C for ; Sat, 13 Sep 2014 09:13:04 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C36CDF1 for ; Sat, 13 Sep 2014 09:13:03 +0000 (UTC) Received: (qmail 23955 invoked from network); 13 Sep 2014 09:13:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 09:13:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 05:13:01 -0400 (EDT) Received: (qmail 7719 invoked from network); 13 Sep 2014 09:12:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 09:12:25 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 6B2831C4057 for ; Sat, 13 Sep 2014 02:12:23 -0700 (PDT) From: Mark Millard Subject: Same boot SSD: 8GByte PowerMac G5 Dual boots fine; 12GByte and 16GByte PowerMac G5 Quad cores usually hang... Message-Id: <40CEB6E7-2DB3-40ED-AE74-81151348A5E8@dsl-only.net> Date: Sat, 13 Sep 2014 02:12:23 -0700 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 09:13:04 -0000 Context: a boot SSD with FreeBSD FBSDG5S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271243: Mon = Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc moved between PowerMacs. One PowerMac kind has no boot problems. The = other kind frequently ends up hung with a blank screen just before the = Copyright would normally show up: the start of the FreeBSD boot messages = never show up. (The fans eventually speed up.) The working PowerMac is the Dual Processor (single core each) PCI-X = based one: FreeBSD 10.1-PRERELEASE #0 r271243: Mon Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc gcc version 4.2.1 20070831 patched [FreeBSD] VT: running with driver "ofwfb". cpu0: IBM PowerPC 970 revision 2.2, 2000.23 MHz cpu0: Features dc000000 cpu0: HID0 511081 real memory =3D 8569122816 (8172 MB) avail memory =3D 8148094976 (7770 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: dev=3Dff887e10 (BSP) cpu1: dev=3Dff889150 [ 277.833] (--) RADEON(0): Chipset: "ATI Radeon 9800PRO NH (AGP)" = (ChipID =3D 0x4e48) An example of the frequently failing-boot kind of PowerMac Quad core G5 = PCI-Express context is: FreeBSD 10.1-PRERELEASE #0 r271278: Mon Sep 8 12:40:56 PDT 2014 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc gcc version 4.2.1 20070831 patched [FreeBSD] VT: running with driver "ofwfb". cpu0: IBM PowerPC 970MP revision 1.1, 2500.34 MHz cpu0: Features dc000000 cpu0: HID0 1511081 real memory =3D 17152716800 (16358 MB) avail memory =3D 16374759424 (15616 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0: dev=3Dff89d680 (BSP) cpu1: dev=3Dff89eb70 cpu2: dev=3Dff89f248 cpu3: dev=3Dff89f920 (The other example I have access to has 12 GBytes of RAM instead. Both = examples behave the same.) [ 3310.669] (--) NV(0): Chipset: "GeForce 7800 GT" Some of the differences are (working context on left of "vs.", failing = on right): PowerPC 970 rev 2.2 vs. PowerPC 970MP rev 1.1 (I.e., two single-core processors vs. two dual-core processors) 8 GBytes RAM vs. 12 or 16 GBytes RAM (and slower vs. faster RAM) ATI Radeon 9800PRO NH (AGP) vs. GeForce 7800 GT clock rate: 2GHz vs. 2.5 GHz PCI-X vs. PCI-Express gem ethernet vs. bge ethernet Whatever the OpenFirmware and such details are for the two kinds of = PowerMacs. Merely having more than 2 GBytes RAM or 4 GBytes RAM is not enough = context for there to be a boot-hang problem. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 11:26:10 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EDD0179 for ; Sat, 13 Sep 2014 11:26:10 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CC0FCFE for ; Sat, 13 Sep 2014 11:26:08 +0000 (UTC) Received: (qmail 16258 invoked from network); 13 Sep 2014 11:26:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 11:26:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 07:26:07 -0400 (EDT) Received: (qmail 29781 invoked from network); 13 Sep 2014 11:26:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 11:26:06 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id CAF521C405D for ; Sat, 13 Sep 2014 04:26:04 -0700 (PDT) From: Mark Millard Message-Id: <16B2E7C6-CB8F-4255-86ED-6F81AC691FC8@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Same boot SSD: 8GByte PowerMac G5 Dual boots fine; 12GByte and 16GByte PowerMac G5 Quad cores usually hang... Date: Sat, 13 Sep 2014 04:26:02 -0700 References: <40CEB6E7-2DB3-40ED-AE74-81151348A5E8@dsl-only.net> To: freebsd-ppc@freebsd.org In-Reply-To: <40CEB6E7-2DB3-40ED-AE74-81151348A5E8@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 11:26:10 -0000 I should have also mentioned that I've never had any PowerMac G5 fail to = boot from powerpc/GENERIC boot SSDs, only from powerpc64/GENERIC64 ones. = For example: 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 always has worked. (This, of course, largely ignores most of the 8GByte+ = of RAM.) This is true no matter what I've done after booting before = trying to reboot (or shutdown -p now then power on), such as use = startxfce4 (which is the way I normally start Xorg). (See below for why = I mention startxfce4 as the example here.) Now narrowing the context down to the problematical Quad Core PowerMac = G5's where I frequently see the boot problem with powerpc64/GENERIC64... But on thinking of this I realized something else: After such a = powerpc/GENERIC boot of a Quad Core G5 PowerMac the first boot after = switching to a powerpc64/GENERIC64 boot SSD also always worked. For = example the fairly modern: FreeBSD FBSDG5S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271243: Mon = Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc does in my experiments. And in experimenting I've discovered that I can = then reboot using that powerpc64/GENERIC64 SSD over and over just fine = --as long as I do not use startxfce4/Xorg at any point. (I've not tried = other Xorg uses in any of my activities.) But if I use startxfce4 then after that I have blank-screen/fans-spin-up = problems for many/most later reboots (or shutdown -p now then power on) = --until I go back and boot from the powerpc/GENERIC SSD. This description holds for both the 12GByte Quad Core PowerMac G5 and = the 16 GByte one. (Both have NVIDIA GeForce 7800 GT's, unfortunately. I = currently do not have access to a Radeon for PCI-Express PowerMacs. Nor = to some other NVIDIA card for them. No comparison/contrast material to = try.) (I'll keep monitoring for a violation of this pattern in my future use. = But I've not noticed an violation of the pattern yet.) This suggests some sort of recording that carries over context across = reboots and even across power-off/power-on --a recording that is messed = up after startxfce4 and cleaned up by powerpc/GENERIC use. Possibly = problems configuring the GeForce 7800 GT cards if they can carry such a = context across off/on. It also tends to mean that just having the large amount of RAM is not = sufficient context to initiate the boot problem. The only other PowerMac G5 I've access to has Radeon video hardware, = PCI-X/AGP instead of PCI-Express, and has 8 GBytes of RAM (its limit), = single-core processors (2 of them). (I do not have access to a NVIDIA = video board for this PowerMac G5.) This PowerMac G5 does not show the = problem when I experiment with it, at least not with modern builds. I = can use startxfce4 and I do not have later boot problems. [I have updated my ports and have picked up the updated Xorg, drivers, = and the change to lang/gcc being 4.8.3. The recent experiments have that = new context involved.] =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 13, 2014, at 2:12 AM, Mark Millard wrote: Context: a boot SSD with FreeBSD FBSDG5S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271243: Mon = Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc moved between PowerMacs. One PowerMac kind has no boot problems. The = other kind frequently ends up hung with a blank screen just before the = Copyright would normally show up: the start of the FreeBSD boot messages = never show up. (The fans eventually speed up.) The working PowerMac is the Dual Processor (single core each) PCI-X = based one: FreeBSD 10.1-PRERELEASE #0 r271243: Mon Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc gcc version 4.2.1 20070831 patched [FreeBSD] VT: running with driver "ofwfb". cpu0: IBM PowerPC 970 revision 2.2, 2000.23 MHz cpu0: Features dc000000 cpu0: HID0 511081 real memory =3D 8569122816 (8172 MB) avail memory =3D 8148094976 (7770 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: dev=3Dff887e10 (BSP) cpu1: dev=3Dff889150 [ 277.833] (--) RADEON(0): Chipset: "ATI Radeon 9800PRO NH (AGP)" = (ChipID =3D 0x4e48) An example of the frequently failing-boot kind of PowerMac Quad core G5 = PCI-Express context is: FreeBSD 10.1-PRERELEASE #0 r271278: Mon Sep 8 12:40:56 PDT 2014 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc gcc version 4.2.1 20070831 patched [FreeBSD] VT: running with driver "ofwfb". cpu0: IBM PowerPC 970MP revision 1.1, 2500.34 MHz cpu0: Features dc000000 cpu0: HID0 1511081 real memory =3D 17152716800 (16358 MB) avail memory =3D 16374759424 (15616 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0: dev=3Dff89d680 (BSP) cpu1: dev=3Dff89eb70 cpu2: dev=3Dff89f248 cpu3: dev=3Dff89f920 (The other example I have access to has 12 GBytes of RAM instead. Both = examples behave the same.) [ 3310.669] (--) NV(0): Chipset: "GeForce 7800 GT" Some of the differences are (working context on left of "vs.", failing = on right): PowerPC 970 rev 2.2 vs. PowerPC 970MP rev 1.1 (I.e., two single-core processors vs. two dual-core processors) 8 GBytes RAM vs. 12 or 16 GBytes RAM (and slower vs. faster RAM) ATI Radeon 9800PRO NH (AGP) vs. GeForce 7800 GT clock rate: 2GHz vs. 2.5 GHz PCI-X vs. PCI-Express gem ethernet vs. bge ethernet Whatever the OpenFirmware and such details are for the two kinds of = PowerMacs. Merely having more than 2 GBytes RAM or 4 GBytes RAM is not enough = context for there to be a boot-hang problem. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Sep 13 13:04:38 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A27A7A49 for ; Sat, 13 Sep 2014 13:04:38 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E24B7A6 for ; Sat, 13 Sep 2014 13:04:37 +0000 (UTC) Received: (qmail 19629 invoked from network); 13 Sep 2014 13:04:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Sep 2014 13:04:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sat, 13 Sep 2014 09:04:35 -0400 (EDT) Received: (qmail 31690 invoked from network); 13 Sep 2014 13:04:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Sep 2014 13:04:35 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id AA67F1C405D for ; Sat, 13 Sep 2014 06:04:32 -0700 (PDT) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Same boot SSD: 8GByte PowerMac G5 Dual boots fine; 12GByte and 16GByte PowerMac G5 Quad cores usually hang... Date: Sat, 13 Sep 2014 06:04:33 -0700 References: <40CEB6E7-2DB3-40ED-AE74-81151348A5E8@dsl-only.net> <16B2E7C6-CB8F-4255-86ED-6F81AC691FC8@dsl-only.net> To: freebsd-ppc@freebsd.org In-Reply-To: <16B2E7C6-CB8F-4255-86ED-6F81AC691FC8@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 13:04:38 -0000 I have kept at the testing and got an example failure without using = startxfce4. Just shutdown -p now then power-on produced the failure on = the PCI-X 8 GByte two single-core processor PowerMac G5. (So much for = that G5 not having the problem. This does make the span include the = radeon card context as well --all using modern 10.1-PRERELEASE builds.) I'll periodically check more and report any more cases of failures that = I come up with. May be the only consistent thing will end up being that = powerpc/GENERIC never has the problem on any of the G5's. =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 13, 2014, at 4:26 AM, Mark Millard wrote: I should have also mentioned that I've never had any PowerMac G5 fail to = boot from powerpc/GENERIC boot SSDs, only from powerpc64/GENERIC64 ones. = For example: 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 always has worked. (This, of course, largely ignores most of the 8GByte+ = of RAM.) This is true no matter what I've done after booting before = trying to reboot (or shutdown -p now then power on), such as use = startxfce4 (which is the way I normally start Xorg). (See below for why = I mention startxfce4 as the example here.) Now narrowing the context down to the problematical Quad Core PowerMac = G5's where I frequently see the boot problem with powerpc64/GENERIC64... But on thinking of this I realized something else: After such a = powerpc/GENERIC boot of a Quad Core G5 PowerMac the first boot after = switching to a powerpc64/GENERIC64 boot SSD also always worked. For = example the fairly modern: FreeBSD FBSDG5S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271243: Mon = Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc does in my experiments. And in experimenting I've discovered that I can = then reboot using that powerpc64/GENERIC64 SSD over and over just fine = --as long as I do not use startxfce4/Xorg at any point. (I've not tried = other Xorg uses in any of my activities.) But if I use startxfce4 then after that I have blank-screen/fans-spin-up = problems for many/most later reboots (or shutdown -p now then power on) = --until I go back and boot from the powerpc/GENERIC SSD. This description holds for both the 12GByte Quad Core PowerMac G5 and = the 16 GByte one. (Both have NVIDIA GeForce 7800 GT's, unfortunately. I = currently do not have access to a Radeon for PCI-Express PowerMacs. Nor = to some other NVIDIA card for them. No comparison/contrast material to = try.) (I'll keep monitoring for a violation of this pattern in my future use. = But I've not noticed an violation of the pattern yet.) This suggests some sort of recording that carries over context across = reboots and even across power-off/power-on --a recording that is messed = up after startxfce4 and cleaned up by powerpc/GENERIC use. Possibly = problems configuring the GeForce 7800 GT cards if they can carry such a = context across off/on. It also tends to mean that just having the large amount of RAM is not = sufficient context to initiate the boot problem. The only other PowerMac G5 I've access to has Radeon video hardware, = PCI-X/AGP instead of PCI-Express, and has 8 GBytes of RAM (its limit), = single-core processors (2 of them). (I do not have access to a NVIDIA = video board for this PowerMac G5.) This PowerMac G5 does not show the = problem when I experiment with it, at least not with modern builds. I = can use startxfce4 and I do not have later boot problems. [I have updated my ports and have picked up the updated Xorg, drivers, = and the change to lang/gcc being 4.8.3. The recent experiments have that = new context involved.] =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 13, 2014, at 2:12 AM, Mark Millard wrote: Context: a boot SSD with FreeBSD FBSDG5S1 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271243: Mon = Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc moved between PowerMacs. One PowerMac kind has no boot problems. The = other kind frequently ends up hung with a blank screen just before the = Copyright would normally show up: the start of the FreeBSD boot messages = never show up. (The fans eventually speed up.) The working PowerMac is the Dual Processor (single core each) PCI-X = based one: FreeBSD 10.1-PRERELEASE #0 r271243: Mon Sep 8 06:28:03 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERI= C64 powerpc gcc version 4.2.1 20070831 patched [FreeBSD] VT: running with driver "ofwfb". cpu0: IBM PowerPC 970 revision 2.2, 2000.23 MHz cpu0: Features dc000000 cpu0: HID0 511081 real memory =3D 8569122816 (8172 MB) avail memory =3D 8148094976 (7770 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: dev=3Dff887e10 (BSP) cpu1: dev=3Dff889150 [ 277.833] (--) RADEON(0): Chipset: "ATI Radeon 9800PRO NH (AGP)" = (ChipID =3D 0x4e48) An example of the frequently failing-boot kind of PowerMac Quad core G5 = PCI-Express context is: FreeBSD 10.1-PRERELEASE #0 r271278: Mon Sep 8 12:40:56 PDT 2014 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64 powerpc gcc version 4.2.1 20070831 patched [FreeBSD] VT: running with driver "ofwfb". cpu0: IBM PowerPC 970MP revision 1.1, 2500.34 MHz cpu0: Features dc000000 cpu0: HID0 1511081 real memory =3D 17152716800 (16358 MB) avail memory =3D 16374759424 (15616 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0: dev=3Dff89d680 (BSP) cpu1: dev=3Dff89eb70 cpu2: dev=3Dff89f248 cpu3: dev=3Dff89f920 (The other example I have access to has 12 GBytes of RAM instead. Both = examples behave the same.) [ 3310.669] (--) NV(0): Chipset: "GeForce 7800 GT" Some of the differences are (working context on left of "vs.", failing = on right): PowerPC 970 rev 2.2 vs. PowerPC 970MP rev 1.1 (I.e., two single-core processors vs. two dual-core processors) 8 GBytes RAM vs. 12 or 16 GBytes RAM (and slower vs. faster RAM) ATI Radeon 9800PRO NH (AGP) vs. GeForce 7800 GT clock rate: 2GHz vs. 2.5 GHz PCI-X vs. PCI-Express gem ethernet vs. bge ethernet Whatever the OpenFirmware and such details are for the two kinds of = PowerMacs. Merely having more than 2 GBytes RAM or 4 GBytes RAM is not enough = context for there to be a boot-hang problem. =3D=3D=3D Mark Millard markmi at dsl-only.net