Date: Sun, 31 Aug 2014 16:02:08 -0700 From: Mark Millard <markmi@dsl-only.net> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-ppc@freebsd.org Subject: Re: Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)... Message-ID: <2B74B670-7463-47D1-B0AF-BDBFEE8823A4@dsl-only.net> In-Reply-To: <D53F6E61-13E3-4473-ABAD-F72BD86E1083@dsl-only.net> References: <4D86DDCB-FF04-4EA2-9703-8B74BBF31C7E@dsl-only.net> <EDE36402-30CE-4747-8BDD-EDD82D8C308F@dsl-only.net> <D42F3E26-8D35-4C8B-A695-AA380ED888E1@dsl-only.net> <EF019CAD-6BAB-431D-A239-0644C0634C24@dsl-only.net> <540386C6.4060004@freebsd.org> <7AFF7E0F-6BB0-4972-A629-61910CE001C2@dsl-only.net> <540393F3.5060508@freebsd.org> <D53F6E61-13E3-4473-ABAD-F72BD86E1083@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <markmi@dsl-only.net> 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 <nwhitehorn@freebsd.org> =
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 <nwhitehorn@freebsd.org> =
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 <markmi@dsl-only.net> =
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 <markmi@dsl-only.net> =
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 <markmi@dsl-only.net> =
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2B74B670-7463-47D1-B0AF-BDBFEE8823A4>