Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)...
Mark Millard
markmi at dsl-only.net
Sun Aug 31 23:02:13 UTC 2014
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
===
Mark Millard
markmi at dsl-only.net
On Aug 31, 2014, at 2:39 PM, Mark Millard <markmi at 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.
===
Mark Millard
markmi at dsl-only.net
On Aug 31, 2014, at 2:30 PM, Nathan Whitehorn <nwhitehorn at 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.
>
> For NVIDIA Option-Fn (switching to VTn) works after the original problem. This is a difference between Radeon and NIVIDA contexts.
>
> The original problem is as follows and applies to both Radeon and NVIDIA contexts when Dual G4 processors are involved:
>
> 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.
>
> (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.)
>
> 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.
>
> 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.)
>
> 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.
>
>
> 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".
>
>
>
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On Aug 31, 2014, at 1:34 PM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
>
> 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
>
> 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.
>>
>> Xorg with xfce4 worked fine!
>>
>> 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.
>>
>> 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.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> On Aug 31, 2014, at 3:35 AM, Mark Millard <markmi at dsl-only.net> wrote:
>>
>> I should have mentioned the following:
>>
>> 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.
>>
>> 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:
>>
>> A) NVIDIA needs the BusID change relative to the other NVIDIA. (AGP/PCI-X vs. PCI-express context change.)
>>
>> B) Both Radeon's need NoAccel (or "False" for DRI) but their xorg.conf files can be identical.
>>
>> 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.
>>
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> On Aug 31, 2014, at 2:51 AM, Mark Millard <markmi at dsl-only.net> wrote:
>>
>> 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!
>>
>> 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.
>>
>> The details...
>>
>>
>> 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!
>>
>>> 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
>>
>> 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
>>
>> moved to
>>
>> PowerMac G5 (7,11), GeForce 7800 GT
>>
>> with the BusID adjusted but being otherwise unchanged has X11 with xfce4 working just fine.
>>
>> 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.)
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> On Aug 31, 2014, at 2:02 AM, Mark Millard <markmi at dsl-only.net> wrote:
>>
>> 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.)
>>
>>
>> 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)
>>
>>> 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.
>>
>> 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.)
>>
>> 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.
>>
>> The SSD has:
>>
>> 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
>>
>>
>>
>> BUT...
>>
>> Now switching that SSD to a G5 PowerMac and booting from it: PowerMac G5 (7,2), Radeon 9800PRO NH (AGP)
>>
>> Using the same Radeon /etc/X11/xorg.conf (with NoAccel enabled or with "False" for DRI in each context): X11 with xfce4 works fine!
>>
>> Even switching to a VTn works fine on the G5 PowerMac: it is displays correctly instead of ending up with a black screen.
>>
>>
>>
>> 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.
>>
>> 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?
>>
>> 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".
>>
>>
>>
>> Mac OS X 10.4 works fine in all the PowerMacs involved: no evidence of problems.
>>
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>>
>>
>>
>> _______________________________________________
>> freebsd-ppc at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"
>>
>
>
More information about the freebsd-ppc
mailing list