Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)...

Nathan Whitehorn nwhitehorn at freebsd.org
Sun Aug 31 21:30:29 UTC 2014 

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 <mailto:markmi at dsl-only.net>
>
> On Aug 31, 2014, at 1:34 PM, Nathan Whitehorn <nwhitehorn at freebsd.org 
> <mailto: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 <mailto: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