From owner-freebsd-ppc@FreeBSD.ORG Sun Aug 31 23:02:13 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 3E1B0B92 for ; Sun, 31 Aug 2014 23:02:13 +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 9609B155A for ; Sun, 31 Aug 2014 23:02:11 +0000 (UTC) Received: (qmail 4465 invoked from network); 31 Aug 2014 23:02:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Aug 2014 23:02:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sun, 31 Aug 2014 19:02:10 -0400 (EDT) Received: (qmail 10677 invoked from network); 31 Aug 2014 23:02:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Aug 2014 23:02:09 -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 7478AB1E001; Sun, 31 Aug 2014 16:02:04 -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: Sun, 31 Aug 2014 16:02:08 -0700 Message-Id: <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@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> 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, 31 Aug 2014 23:02:13 -0000 Here are a couple of top snapshots from while the display is hung up = (before any Option-Fn). I set the update interval to 10s so I'd have = time to capture between updates. last pid: 983; load averages: 0.25, 0.35, 0.17 = up 0+00:03:27 15:56:54 32 processes: 1 running, 31 sleeping CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle Mem: 49M Active, 20M Inact, 49M Wired, 34M Buf, 1855M Free Swap: 10G Total, 10G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 893 haldaemon 2 29 0 22488K 5540K select 1 0:00 0.00% = hald 983 markmi 1 20 0 11764K 2604K CPU0 0 0:00 0.00% = top 898 root 2 52 0 20256K 7092K select 1 0:00 0.00% = hald-runner 964 root 1 24 0 20320K 7708K select 0 0:00 0.00% = sshd 924 root 1 20 0 11224K 2596K select 0 0:00 0.00% = hald-addon-storage 880 root 1 23 0 11944K 2644K wait 0 0:00 0.00% = login 897 root 3 36 0 29468K 7992K kqread 0 0:00 0.00% = polkitd 895 root 18 20 0 46428K 8520K waitvt 0 0:00 0.00% = console-kit-daemon 919 root 1 42 0 13836K 5024K kqread 1 0:00 0.00% = hald-addon-mouse-sy 725 messagebus 1 20 0 10996K 1976K select 0 0:00 0.00% = dbus-daemon 791 root 1 20 0 13060K 2272K select 1 0:00 0.00% = ntpd 930 root 1 37 0 11472K 3120K ttyin 0 0:00 0.00% = csh 828 root 1 20 0 13564K 3924K select 0 0:00 0.00% = sendmail 980 markmi 1 20 0 20320K 4072K select 1 0:00 0.00% = sshd 600 root 1 20 0 10348K 1416K select 1 0:00 0.00% = syslogd 981 markmi 1 20 0 10864K 2400K wait 1 0:00 0.00% sh 884 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 825 root 1 20 0 16840K 2896K select 0 0:00 0.00% = sshd 882 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 883 root 1 52 0 10336K 1824K ttyin 0 0:00 0.00% = getty 839 root 1 20 0 10460K 1412K nanslp 0 0:00 0.00% = cron 453 root 1 20 0 9024K 888K select 0 0:00 0.00% = devd 886 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 887 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 881 root 1 52 0 10336K 1824K ttyin 0 0:00 0.00% = getty 831 smmsp 1 52 0 13564K 2136K pause 1 0:00 0.00% = sendmail 885 root 1 52 0 10336K 1824K ttyin 0 0:00 0.00% = getty 888 root 1 52 0 10336K 1820K ttydcd 1 0:00 0.00% = getty 950 root 1 52 0 15860K 1804K select 0 0:00 0.00% = ssh-agent 572 _dhcp 1 49 0 10464K 1056K select 0 0:00 0.00% = dhclient 536 root 1 52 0 10464K 1108K select 1 0:00 0.00% = dhclient 436 root 1 52 0 10556K 816K select 0 0:00 0.00% = moused last pid: 983; load averages: 0.64, 0.37, 0.20 = up 0+00:05:35 15:59:02 32 processes: 1 running, 31 sleeping CPU: 0.0% user, 0.0% nice, 0.2% system, 0.2% interrupt, 99.7% idle Mem: 49M Active, 20M Inact, 49M Wired, 34M Buf, 1855M Free Swap: 10G Total, 10G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 893 haldaemon 2 29 0 22488K 5540K select 1 0:00 0.00% = hald 983 markmi 1 20 0 11764K 2604K CPU0 0 0:00 0.00% = top 898 root 2 52 0 20256K 7092K select 1 0:00 0.00% = hald-runner 964 root 1 24 0 20320K 7708K select 0 0:00 0.00% = sshd 924 root 1 20 0 11224K 2596K select 1 0:00 0.00% = hald-addon-storage 880 root 1 23 0 11944K 2644K wait 0 0:00 0.00% = login 897 root 3 36 0 29468K 7992K kqread 0 0:00 0.00% = polkitd 895 root 18 20 0 46428K 8520K waitvt 0 0:00 0.00% = console-kit-daemon 919 root 1 42 0 13836K 5024K kqread 1 0:00 0.00% = hald-addon-mouse-sy 725 messagebus 1 20 0 10996K 1976K select 0 0:00 0.00% = dbus-daemon 791 root 1 20 0 13060K 2272K select 1 0:00 0.00% = ntpd 930 root 1 37 0 11472K 3120K ttyin 0 0:00 0.00% = csh 828 root 1 20 0 13564K 3924K select 0 0:00 0.00% = sendmail 980 markmi 1 20 0 20320K 4072K select 0 0:00 0.00% = sshd 600 root 1 20 0 10348K 1416K select 1 0:00 0.00% = syslogd 981 markmi 1 20 0 10864K 2400K wait 1 0:00 0.00% sh 884 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 825 root 1 20 0 16840K 2896K select 0 0:00 0.00% = sshd 882 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 839 root 1 20 0 10460K 1412K nanslp 0 0:00 0.00% = cron 883 root 1 52 0 10336K 1824K ttyin 0 0:00 0.00% = getty 453 root 1 20 0 9024K 888K select 0 0:00 0.00% = devd 886 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 887 root 1 52 0 10336K 1824K ttyin 1 0:00 0.00% = getty 881 root 1 52 0 10336K 1824K ttyin 0 0:00 0.00% = getty 831 smmsp 1 52 0 13564K 2136K pause 1 0:00 0.00% = sendmail 885 root 1 52 0 10336K 1824K ttyin 0 0:00 0.00% = getty 888 root 1 52 0 10336K 1820K ttydcd 1 0:00 0.00% = getty 950 root 1 52 0 15860K 1804K select 0 0:00 0.00% = ssh-agent 572 _dhcp 1 49 0 10464K 1056K select 0 0:00 0.00% = dhclient 536 root 1 52 0 10464K 1108K select 1 0:00 0.00% = dhclient 436 root 1 52 0 10556K 816K select 0 0:00 0.00% = moused =3D=3D=3D Mark Millard markmi at dsl-only.net On Aug 31, 2014, at 2:39 PM, Mark Millard wrote: Yes: Initially X hangs. That is the original problem and the problem = that applies to more contexts. I can try set up ssh to do a "top" but it may take a bit before I can = get to it and finish it. =3D=3D=3D Mark Millard markmi@dsl-only.net On Aug 31, 2014, at 2:30 PM, Nathan Whitehorn = wrote: So X is hanging, then? Can you ssh into the machine to figure out what = it's doing? Even just looking at its CPU usage in top would be helpful. -Nathan On 08/31/14 14:04, Mark Millard wrote: > No. The Black Screen is from Option-Fn (switching to a VTn) for = Radeon contexts. I attempt that after the original problem. >=20 > For NVIDIA Option-Fn (switching to VTn) works after the original = problem. This is a difference between Radeon and NIVIDA contexts. >=20 > The original problem is as follows and applies to both Radeon and = NVIDIA contexts when Dual G4 processors are involved: >=20 > UI hangs during the initial xfce4 screen display, frequently without = the background being finished (or sometimes even started). What is = displayed seems fine as far as it got. But how far the screen update = gets before hanging varies from one attempt to the next. >=20 > (I changed the wording since the G5 and single processor G4 = experiments got past the initial "welcome screen" so the initial screen = is now a normal xfce4 desktop.) >=20 > The cursor does not track mouse motions. But that may be just part of = the screen-update-hang status. I've no evidence that after startxfce4 = but before Option-Fn any input other than Option-Fn works on any Dual = Processor PowerMac. >=20 > This "original problem" wording applies to both the Radeon contexts = and the NVIDIA context on Dual Processor G4 PowerMacs. The after = Option-Fn details do vary between Radeon and NVIDIA. (See above.) >=20 > I have also tried a 1 GHz Dual Processor Mirrored Drive Door PowerMac = G4 (no FW800) with a Radeon. It behaves like the 1.4GHz FW800 Dual = Processor G4 PowerMac contexts (Radeon and NVIDIA) as far as the = original problem goes. But for after Option-Fn it behaves like the other = Radeon examples, not like the NVIDIA example. >=20 >=20 > I can try connecting a monitor to the other connector. Once I do I'll = let you know if it proves interesting for what happens when I Option-Fn. = But unless screen updates switching card outputs sometimes happens = mid-first screen update that extra monitor test probably will not = produce interesting results for the "original problem". >=20 >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net >=20 > On Aug 31, 2014, at 1:34 PM, Nathan Whitehorn = wrote: >=20 > So the bug is that on dual-processor G4 systems, you get a black = screen when starting X, but input works? Is it a dual-head graphics = card? Sometimes X's logic about which connector is the primary display = goes wonky and it picks the other one. > -Nathan >=20 > On 08/31/14 04:27, Mark Millard wrote: >> I plugged the boot SSD configured for Radeon's into a 466 MHz = PowerMac3,4 that has a Radeon card (a single processor G4 model, unlike = all prior tests) and did not change the xorg.conf compared to there = other 2 Radeon PowerMac tests done with that SSD. >>=20 >> Xorg with xfce4 worked fine! >>=20 >> So as near as I can tell 10.0-STABLE powerpc r268571 (July-13) for = Xorg with xfce4 from around 9 days later has Xorg-with-xfce4 problems = for dual-procesor G4's only. >>=20 >> Single processor G4's and Dual processor G5's and two dual-core = processors contexts all work fine. The problem is not specific to Radeon = or to NVIDIA cards. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi@dsl-only.net >>=20 >> On Aug 31, 2014, at 3:35 AM, Mark Millard = wrote: >>=20 >> I should have mentioned the following: >>=20 >> These SSD's are as they were when I originally reported the original = issues on July-23: the ports used match that time frame. That includes = Xorg and xfce4. 10.0-STABLE for powerpc is as of July-13 (r268571: the = most recent available for non-source downloading) --so also as it was = back then. >>=20 >> As reported before: swapping the Radeon-tied SSD and NVIDIA-tied SSD = and swapping back the xorg.conf files used gets the same results. In = other words: I can do this with one SSD moving between 4 PowerMacs and = the G4's fail and the G5's work, all booted from the same SSD with only = minimal xorg.conf changes to be appropriate to the cards: >>=20 >> A) NVIDIA needs the BusID change relative to the other NVIDIA. = (AGP/PCI-X vs. PCI-express context change.) >>=20 >> B) Both Radeon's need NoAccel (or "False" for DRI) but their = xorg.conf files can be identical. >>=20 >> C) Of course nv vs. radeon and the list of option line differences is = fairly extensive for (A) vs. (B) comparisons but the Options are all = disabled (# in front), other than the Radeon's disabling DRI one way or = another. These and related (A) vs. (B) differences are not relevant to = the general point as far as I can tell. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On Aug 31, 2014, at 2:51 AM, Mark Millard = wrote: >>=20 >> The prior report was for the Radeon G4 and G5 PowerMacs. It turns out = that NVIDIA GeForce PowerMacs also have the G4-fails to G5-works status! >>=20 >> So both G5's work and both G4's do not, despite the differences in = card types (Radeon's vs. GeForces). And part of the G4's failures = description is the same for each card type. >>=20 >> The details... >>=20 >>=20 >> The same sort of thing happens for the NVIDIA G4 and G5 PowerMacs: = Moving the boot SSD from the G4 to the G5, booting from it, and changing = the xorg.conf BusID (since it was different in the G5) took a X11 with = xfce4 that was not working to a context where the same SSD has X11 with = xfce4 working fine with no other changes involved! >>=20 >>> PowerMac G4 (3,6), GeForce4 Ti 4600: UI hangs during the initial = xfce4 "welcome" screen update, frequently without the background being = finished. What is displayed seems fine as far as it got. Can still = Option-Fn just fine to get back to VTn and use it. >> with a boot SSD >>=20 >> FreeBSD FBSDG4S0 10.0-STABLE FreeBSD 10.0-STABLE #0 r268571: Sun Jul = 13 05:15:31 UTC 2014 root at = grind.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC powerpc >>=20 >> moved to >>=20 >> PowerMac G5 (7,11), GeForce 7800 GT >>=20 >> with the BusID adjusted but being otherwise unchanged has X11 with = xfce4 working just fine. >>=20 >> For the NVIDIA examples no explicit change from the default = -configure xorg.conf content was involved: Option NoAccel did not have = to be turned on. (It may well be that something automatically did an = equivalent for all I know.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On Aug 31, 2014, at 2:02 AM, Mark Millard = wrote: >>=20 >> The following eventually reports that moving a PowerMac G4 FreeBSD = boot SSD to a PowerMac G5 and booting from it makes X11 with xfce4 go = from not working to working. (No other changes are involved.) >>=20 >>=20 >> Earlier when trying the "/dev/mem instead of /dev/console for = memory-mapping frame buffers in X11 on PowerPC" testing I had reported = that I was unable to get to the point of a reasonable test on PowerMac = G4's, including for NVIDIA. = (http://lists.freebsd.org/pipermail/freebsd-ppc/2014-July/007124.html) >>=20 >>> PowerMac G4 (3,6), GeForce4 Ti 4600: UI hangs during the initial = xfce4 "welcome" screen update, frequently without the background being = finished. What is displayed seems fine as far as it got. Can still = Option-Fn just fine to get back to VTn and use it. >> The "PowerMac G4 (3,6), ATI Radeon 9000/PRO If (AGP/PCI)" was far = worse off for as much as I tested back then: random varying garbage = displayed and it ignored my input after attempting to switch back to to = a VTn. Forced power switch based shutdown. >>=20 >> Now that I've access to the Power Mac's again I experimented more = with "PowerMac G4 (3,6), ATI Radeon 9000/PRO If (AGP/PCI)" and I managed = to make it work better then what I reported before. Avoiding DRI (use = NoAccel or use "False" for DRI) makes the Radeon behave the similar to = the NVIDIA GeForce4 Ti 4600 as indicated above. The difference is that = the VTn stays black when I switch to it. But it does take what I type = and executes the commands, such as reboot. (Yep: still syscons.) >>=20 >> In both G4 contexts the Xorg.0.log that results appears to have no = information indicating any failure. Of course in each case = /etc/X11/xorg.conf was generated (-configure) for the card in use, but = with NoAccel in use. >>=20 >> The SSD has: >>=20 >> FreeBSD FBSDG4S0 10.0-STABLE FreeBSD 10.0-STABLE #0 r268571: Sun Jul = 13 05:15:31 UTC 2014 root at = grind.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC powerpc >>=20 >>=20 >>=20 >> BUT... >>=20 >> Now switching that SSD to a G5 PowerMac and booting from it: PowerMac = G5 (7,2), Radeon 9800PRO NH (AGP) >>=20 >> Using the same Radeon /etc/X11/xorg.conf (with NoAccel enabled or = with "False" for DRI in each context): X11 with xfce4 works fine! >>=20 >> Even switching to a VTn works fine on the G5 PowerMac: it is displays = correctly instead of ending up with a black screen. >>=20 >>=20 >>=20 >> The generated -configure xorg.conf.new is the same for the two Radeon = contexts. But in each case I need to pick an option that disables DRI = use in order to get reasonable behavior. >>=20 >> Without NoAccel/"False"-for-DRI for the G5: text does not display = correctly and if composite is enabled with shadows then the shadowing is = messed up. Bit/Byte order/alignment issues when accelerated? >>=20 >> The Radeon 9000 with DRI enabled gets a Xorg.0.log report that = r200_dri.so is not found and the Radeon 9800 with DRI enabled gets a = report that r300_dri.so is not found. (As is probably expected in each = case.) So the behaviors are examples of the error handling for "not = found". >>=20 >>=20 >>=20 >> Mac OS X 10.4 works fine in all the PowerMacs involved: no evidence = of problems. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to = "freebsd-ppc-unsubscribe@freebsd.org" >>=20 >=20 >=20