Hi. I've got an ISO for quick testing of anaconda's X configuration setup available that's a little bit smaller than a full tree. All you should have to do is download the ISO, burn it to a CD, boot and see if X starts up. Then, you can reboot and go back to your normal doings.
Note that this is entirely non-destructive. So you can even run it if you are running OS X. *ANY* results would be helpful. Please be sure to include what you see happen as well as what type of hardware you're using (cpu, video, monitor).
The iso is located at http://people.redhat.com/~katzj/mac-x-test.iso. The md5sum is 34234b3cdf2d89e4e94031a50f819285
Thanks in advance for testing this and helping to make test3 (and thus, the Fedora Core 4 release) better on PPC hardware!
Jeremy
On Mon, 2005-05-02 at 18:21 -0400, Jeremy Katz wrote:
Hi. I've got an ISO for quick testing of anaconda's X configuration setup available that's a little bit smaller than a full tree. All you should have to do is download the ISO, burn it to a CD, boot and see if X starts up. Then, you can reboot and go back to your normal doings.
Note that this is entirely non-destructive. So you can even run it if you are running OS X. *ANY* results would be helpful. Please be sure to include what you see happen as well as what type of hardware you're using (cpu, video, monitor).
The iso is located at http://people.redhat.com/~katzj/mac-x-test.iso. The md5sum is 34234b3cdf2d89e4e94031a50f819285
Thanks in advance for testing this and helping to make test3 (and thus, the Fedora Core 4 release) better on PPC hardware!
OK, I tried this on my Powerbook G4 12" 867MHz (the 1st generation PB12) and X starts fine in 800x600x16 bit using the nv driver.
Probing for video card: NVIDIA GeForce 4 (generic) Probing for monitor type: Unknown monitor Probing for mouse type: Generic - 3 Button Mouse (PS/2)
Great work.
Cheers, David
On Mon, 2005-05-02 at 18:21 -0400, Jeremy Katz wrote:
Hi. I've got an ISO for quick testing of anaconda's X configuration setup available that's a little bit smaller than a full tree. All you should have to do is download the ISO, burn it to a CD, boot and see if X starts up. Then, you can reboot and go back to your normal doings.
Note that this is entirely non-destructive. So you can even run it if you are running OS X. *ANY* results would be helpful. Please be sure to include what you see happen as well as what type of hardware you're using (cpu, video, monitor).
The iso is located at http://people.redhat.com/~katzj/mac-x-test.iso. The md5sum is 34234b3cdf2d89e4e94031a50f819285
PowerBook1,1 (Rage 128): Works fine.
PowerBook5,3 (Radeon 9600): Kills machine hard. The kernel has enabled dynamic clocks and unless X also does so, I see this...
(II) RADEON(0): Dynamic Clock Scaling Disabled (WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and newer cards (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): Idle timed out, resetting engine... ... and then it dies.
Ben, is this expected behaviour if the kernel and X disagree about the use of dynamic clocks? Is this addressed by one of the patches you have outstanding at http://gate.crashing.org/~benh/xorg/ ?
The second problem with the PB5,3 is that rhpl explicitly specifies 800x600 instead of letting X honour the DDC information. I can see that rhpl has code to parse this, but it doesn't seem to be doing so...
(II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 96.2 MHz Image Size: 367 x 230 mm (II) RADEON(0): h_active: 1440 h_sync: 1504 h_sync_end 1536 h_blank_end 1760 h_border: 0 (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 906 v_blanking: 912 v_border: 0 <...> (II) RADEON(0): Panel size found from DDC: 1440x900 (II) RADEON(0): Valid Mode from Detailed timing table: 1440x900
This patch to the rhpl-generated XConfig.test makes it work:
--- XConfig.test.orig 2005-05-03 12:51:18.000000000 +0100 +++ XConfig.test 2005-05-03 12:51:05.000000000 +0100 @@ -104,2 +104,3 @@ Option "UseFBDev" "true" + Option "DynamicClocks" "true" EndSection @@ -114,3 +115,2 @@ Depth 16 - Modes "800x600" "640x480" EndSubSection
Full log at http://david.woodhou.se/Xorg.1.log
On Tue, 2005-05-03 at 13:12 +0100, David Woodhouse wrote:
The second problem with the PB5,3 is that rhpl explicitly specifies 800x600 instead of letting X honour the DDC information. I can see that rhpl has code to parse this, but it doesn't seem to be doing so...
We only parse it if the X startup fails. If the X startup _succeeds_, then parsing the log, killing X, and restarting it may lead to X not starting back up, which ends up being worse. But this basically sounds like us not being worse off on ppc laptops than on x86 ones.
This gets back to the discussion we had a few weeks ago about X configuration :-)
Jeremy
On Tue, 2005-05-03 at 10:41 -0400, Jeremy Katz wrote:
We only parse it if the X startup fails. If the X startup _succeeds_, then parsing the log, killing X, and restarting it may lead to X not starting back up, which ends up being worse. But this basically sounds like us not being worse off on ppc laptops than on x86 ones.
Couldn't we just refrain from specifying a mode in this case, since we _know_ we're just pulling it out of our wossname? Or if we _must_ specify a mode, what's wrong with the one we get from 'fbset -x'?
On Tue, 2005-05-03 at 16:38 +0100, David Woodhouse wrote:
On Tue, 2005-05-03 at 10:41 -0400, Jeremy Katz wrote:
We only parse it if the X startup fails. If the X startup _succeeds_, then parsing the log, killing X, and restarting it may lead to X not starting back up, which ends up being worse. But this basically sounds like us not being worse off on ppc laptops than on x86 ones.
Couldn't we just refrain from specifying a mode in this case, since we _know_ we're just pulling it out of our wossname? Or if we _must_ specify a mode, what's wrong with the one we get from 'fbset -x'?
The problem is that adding a "if this looks like this, and this looks like this and this looks like something else" to do a workaround like not specifying the modes does *not* lead to the code being maintainable. It's already bad enough, there's no need to make things worse. :-)
But, doing a hack to look at the fb mode on ppc and try that resolution probably isn't terrible to do in anaconda [1]. I'm afraid it still isn't going to help with some of the radeon problems, though :/
Jeremy
[1] In fact, it's not -- committed the following Index: anaconda =================================================================== RCS file: /usr/local/CVS/anaconda/anaconda,v retrieving revision 1.340 diff -u -u -r1.340 anaconda --- anaconda 3 May 2005 02:00:45 -0000 1.340 +++ anaconda 3 May 2005 15:54:51 -0000 @@ -911,6 +911,14 @@ # if no monitor probed lets guess based on runres hsync = monitorhw.getMonitorHorizSync() vsync = monitorhw.getMonitorVertSync() + + # if we're on a pmac, try to use the fb resolution + if not runres_override and iutil.getPPCMachine() == "PMac": + fbinfo = isys.fbinfo() + fbres = "%sx%s" %(fbinfo[0], fbinfo[1]) + if monitor.monitor_supports_mode(hsync, vsync, fbres): + runres = fbres + res_supported = monitor.monitor_supports_mode(hsync, vsync, runres)
# XXX: this is a bit of a hack, but there are a reasonable number of
On Tue, 2005-05-03 at 12:04 -0400, Jeremy Katz wrote:
The problem is that adding a "if this looks like this, and this looks like this and this looks like something else" to do a workaround like not specifying the modes does *not* lead to the code being maintainable. It's already bad enough, there's no need to make things worse. :-)
The logic I was thinking of would be "If we have information about supported modes, then specify a mode. Else keep quiet and let X work it out for itself".
But, doing a hack to look at the fb mode on ppc and try that resolution probably isn't terrible to do in anaconda [1].
Does it need to be ppc-specific? If DDC fails, just try to get a sane modeline from the framebuffer.
I'm afraid it still isn't going to help with some of the radeon problems, though :/
See separate mail re the dynamic clock lockup.
On Tue, 2005-05-03 at 17:16 +0100, David Woodhouse wrote:
But, doing a hack to look at the fb mode on ppc and try that resolution probably isn't terrible to do in anaconda [1].
Does it need to be ppc-specific? If DDC fails, just try to get a sane modeline from the framebuffer.
We use vga16fb on i386/x86_64/ia64 to get CJK text consoles. And trying to get fbinfo from that isn't going to give results that we want or expect :)
Jeremy
On Tue, 2005-05-03 at 12:47 -0400, Jeremy Katz wrote:
We use vga16fb on i386/x86_64/ia64 to get CJK text consoles. And trying to get fbinfo from that isn't going to give results that we want or expect :)
Hm. Use what we get from the fb if it's better than 640x480, perhaps? Or if the driver _isn't_ vga16fb? But we're rapidly descending into the realm of the not-pretty, I agree.
On Tue, 2005-05-03 at 13:12 +0100, David Woodhouse wrote:
PowerBook5,3 (Radeon 9600): Kills machine hard. The kernel has enabled dynamic clocks and unless X also does so, I see this...
(II) RADEON(0): Dynamic Clock Scaling Disabled (WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and newer cards (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): Idle timed out, resetting engine...... and then it dies.
This is actually a caused by a patch we have in our xorg-x11 RPM. Stock 6.8.2 works fine (albeit at 800x600) with dynamic clocks off.
cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152648
On Tue, 2005-05-03 at 17:12 +0100, David Woodhouse wrote:
Well, this is weird. But first of all, why are you disabling Dynamic Clocks ? Isn't this a laptop ? You should disable them most of the time. Also, the driver is supposed not to "touch" dynamic clocks at all on non-mobility chips.
There are several issues adressed by my patches, I can't say for sure about this one, but you should certainly merge them if you want things like working VGA output etc...
I'll try current CVS head with dynclk off on Paulus 5,3 today. There used to be a bug in the dynclk code "off" that would mixup "OUPLL" and "OUTREG" that I fixed at some point, I'm not sure if that fix is in your tree. There may be some other problem as well.
Ben.
On Wed, 2005-05-04 at 09:32 +1000, Benjamin Herrenschmidt wrote:
Well, this is weird. But first of all, why are you disabling Dynamic Clocks ? Isn't this a laptop ? You should disable them most of the time.
I assume you mean "You should _enable_ them most of the time".?
We're not explicitly disabling Dynamic Clocks. It's just that the installer knows nothing of Dynamic Clocks and so doesn't explicitly _enable_ them.
There are several issues adressed by my patches, I can't say for sure about this one, but you should certainly merge them if you want things like working VGA output etc...
AFAICT this is already fixed in 6.8.2, but the patch which fixes it causes other problems and was hence backed out in the RPM -- that's what bug #152648 is about.
http://david.woodhou.se/xorg-x11-6.8.1-ati-radeon-dynamic-clocks-fix-2.patch is being applied to our latest xorg-x11 package. If I use a radeon_drv.o from a version immediately before that patch was added, the machine no longer dies.
On Wed, 2005-05-04 at 06:59 +0100, David Woodhouse wrote:
On Wed, 2005-05-04 at 09:32 +1000, Benjamin Herrenschmidt wrote:
Well, this is weird. But first of all, why are you disabling Dynamic Clocks ? Isn't this a laptop ? You should disable them most of the time.
I assume you mean "You should _enable_ them most of the time".?
Yup, sorry.
We're not explicitly disabling Dynamic Clocks. It's just that the installer knows nothing of Dynamic Clocks and so doesn't explicitly _enable_ them.
Yes, I know, and that should be fixed I suppose ... Note that I've tested with current X.org CVS HEAD on paulus laptop (5,3 as well) and disabling them doesn't cause any problem. I'll see if I can find something, but in the meantime, can you send me a tarball of your xc/programs/Xserver/hw/xfree86/drivers/ati ?
There are several issues adressed by my patches, I can't say for sure about this one, but you should certainly merge them if you want things like working VGA output etc...
AFAICT this is already fixed in 6.8.2, but the patch which fixes it causes other problems and was hence backed out in the RPM -- that's what bug #152648 is about.
I'm not sure what you are talking about, and I find bug #152648 more confusing than anything else anyway.
http://david.woodhou.se/xorg-x11-6.8.1-ati-radeon-dynamic-clocks-fix-2.patch is being applied to our latest xorg-x11 package. If I use a radeon_drv.o from a version immediately before that patch was added, the machine no longer dies.
That patch looks totally bogus, where does it come from ?
Ben.
On Wed, 2005-05-04 at 16:04 +1000, Benjamin Herrenschmidt wrote:
I'm not sure what you are talking about, and I find bug #152648 more confusing than anything else anyway.
Yeah, I couldn't make much sense of it either.
The problem with dynamic clocks is already fixed in xorg-x11 6.8.2, but the fix seems to cause problems with DRI for some i386 users. Those DRI problems are bug #152648.
That patch looks totally bogus, where does it come from ?
It came from our RPM, and is the supposed 'fix' for bug #152648. I believe it's just an attempt to revert to what was in 6.8.1.
On Wed, 2005-05-04 at 07:20 +0100, David Woodhouse wrote:
On Wed, 2005-05-04 at 16:04 +1000, Benjamin Herrenschmidt wrote:
I'm not sure what you are talking about, and I find bug #152648 more confusing than anything else anyway.
Yeah, I couldn't make much sense of it either.
The problem with dynamic clocks is already fixed in xorg-x11 6.8.2, but the fix seems to cause problems with DRI for some i386 users. Those DRI problems are bug #152648.
That patch looks totally bogus, where does it come from ?
It came from our RPM, and is the supposed 'fix' for bug #152648. I believe it's just an attempt to revert to what was in 6.8.1.
Ok, this is all not very clear.
What is happening with X.org 6.8.2 plus all my patches ? I have a hard time understanding anything about what's in that bug report, it's messy and confusing, Kristian talks for example about "identifyign the regression" but doesn't say what he found nor doesn't attach a patch etc...
One of my patches does indeed fix a bug which could happen with radeon mobility M7 (7500) and dynamic clocks enable (among others), and fixes a couple of bugs with dynamic clocks disable. There are still "issues" with the dynamic clocks code imho, but it should be stable. So please make sure you have all the patches in and get that user to try with DynamicClocks both enabled or disabled (though if it's not a mobility chip, the stuff won't do anything).
If that still doesn't work, I'll try to find out something more precise in the dynamic clocks code on these models that may not be appropriate.
Ben.
On Wed, 2005-05-04 at 16:30 +1000, Benjamin Herrenschmidt wrote:
What is happening with X.org 6.8.2 plus all my patches ?
6.8.2 even without your patches is fine for me.
One of my patches does indeed fix a bug which could happen with radeon mobility M7 (7500) and dynamic clocks enable (among others)
Sounds like we should apply your patches to the RPM, remove the bogus 'ati-radeon-dynamic-clocks-fix-2.patch' and get the reporter of bug #152648 to retest.
On Wed, 2005-05-04 at 07:48 +0100, David Woodhouse wrote:
On Wed, 2005-05-04 at 16:30 +1000, Benjamin Herrenschmidt wrote:
What is happening with X.org 6.8.2 plus all my patches ?
6.8.2 even without your patches is fine for me.
You haven't tried dual head and/or not using UseFBDev :)
Anyway, My question was more what about this user who complains on #152648. I don't have time at the moment to track the details and his reports are very confusing.
One of my patches does indeed fix a bug which could happen with radeon mobility M7 (7500) and dynamic clocks enable (among others)
Sounds like we should apply your patches to the RPM, remove the bogus 'ati-radeon-dynamic-clocks-fix-2.patch' and get the reporter of bug #152648 to retest.
Exactly.
Ben.
On Wed, 2005-05-04 at 17:13 +1000, Benjamin Herrenschmidt wrote:
You haven't tried dual head and/or not using UseFBDev :)
Or DRI, for that matter -- but I was limiting my observations to merely "manages to display something" vs. "takes the entire machine out" :)
Anyway, My question was more what about this user who complains on #152648. I don't have time at the moment to track the details and his reports are very confusing.
OK. I'll build a package for him to test.
Benjamin Herrenschmidt wrote: ...
http://david.woodhou.se/xorg-x11-6.8.1-ati-radeon-dynamic-clocks-fix-2.patch is being applied to our latest xorg-x11 package. If I use a radeon_drv.o from a version immediately before that patch was added, the machine no longer dies.
That patch looks totally bogus, where does it come from ?
Ben.
Alex Deucher and I came up with the current patch in
https://bugs.freedesktop.org/show_bug.cgi?id=1912
It is supposed to reestablish the clock setup code from 6.7.0, which so far have worked pretty well. When 6.8.0 introduced the dynamic clocks feature we started seeing hard lockups on radeon 7000s, typically on x86 smp boxes. I tracked it down to the dynamic clocks feature, and it triggers wether or not you enable dynamic clocks. So for our FC-3 6.8.1 RPMs I added this patch
https://bugs.freedesktop.org/attachment.cgi?id=1432
to revert to the previous clock initialization code, which worked pretty well. When 6.8.2 came out it had a slightly different patch applied
https://bugs.freedesktop.org/attachment.cgi?id=1433
which didn't put the 6.7.0 clock code back in, but it only invoked the dynamic clock code for mobility chips. When we updated our RPMs to the 6.8.2 release and dropped the first patch, we got the regression bug mentioned earlier. Apparently some radeon 7000s (I can't reproduce the regression on my radeon 7000 box) require the 6.7.0 clock setup to work, so I put back the patch we used with 6.8.1, which is what we have now.
David, thanks for building the RPMs with Bens patches and posting it in the bug, I've been meaning to do that. If these patches work well, we'll included them in FC5, but I'm reluctant to change this much for FC4.
cheers, Kristian
Alex Deucher and I came up with the current patch in
https://bugs.freedesktop.org/show_bug.cgi?id=1912
It is supposed to reestablish the clock setup code from 6.7.0, which so far have worked pretty well. When 6.8.0 introduced the dynamic clocks feature we started seeing hard lockups on radeon 7000s, typically on x86 smp boxes. I tracked it down to the dynamic clocks feature, and it triggers wether or not you enable dynamic clocks. So for our FC-3 6.8.1 RPMs I added this patch
https://bugs.freedesktop.org/attachment.cgi?id=1432
to revert to the previous clock initialization code, which worked pretty well. When 6.8.2 came out it had a slightly different patch applied
Well, the patch that was in RH was sort-of mixing up the dynamic clocks code and the "old style" clock forcing. The end result craps out on rv350 at least. I don't like the big hammer of just disabling the dynamic clocks code, this is a significant loss on laptops.
On the other hands, I have posted fixes for the Dynamic Clocks "off" case which indeed was bogus, plus workarounds for chip erratas around PLL accesses that triggered, among others, lockups on rv250, in addition to the fact that we don't touch dynamic clocks on non-mobility chips. So I suppose that my patch set should be tried first, and if the problem still happen, get me in touch with the user so I can try to find out precisely what bit of dynamic clocking is causing the problem.
https://bugs.freedesktop.org/attachment.cgi?id=1433
which didn't put the 6.7.0 clock code back in, but it only invoked the dynamic clock code for mobility chips. When we updated our RPMs to the 6.8.2 release and dropped the first patch, we got the regression bug mentioned earlier. Apparently some radeon 7000s (I can't reproduce the regression on my radeon 7000 box) require the 6.7.0 clock setup to work, so I put back the patch we used with 6.8.1, which is what we have now.
David, thanks for building the RPMs with Bens patches and posting it in the bug, I've been meaning to do that. If these patches work well, we'll included them in FC5, but I'm reluctant to change this much for FC4.
We may want to force some clocks on some desktop 7000's. It may be that the BIOS is indeed improperly enabling some dynamic clcoks. If you find somebody with a repro case, please point that person to me and I'll chase the problem with him/her.
Ben.
On Wed, 2005-05-04 at 12:44 -0400, Kristian Høgsberg wrote:
Apparently some radeon 7000s (I can't reproduce the regression on my radeon 7000 box) require the 6.7.0 clock setup to work, so I put back the patch we used with 6.8.1, which is what we have now.
What we have now will lock my laptop up hard. 6.8.1 with the same configuration works.
David, thanks for building the RPMs with Bens patches and posting it in the bug, I've been meaning to do that. If these patches work well, we'll included them in FC5, but I'm reluctant to change this much for FC4.
A relatively simple workaround for FC4 might be for rhpl to turn DynamicClocks _on_ for the Radeon -- perhaps only on PPC, or when it finds that the kernel has done so.
On Fri, 2005-05-06 at 08:22 +0100, David Woodhouse wrote:
On Wed, 2005-05-04 at 12:44 -0400, Kristian Høgsberg wrote:
Apparently some radeon 7000s (I can't reproduce the regression on my radeon 7000 box) require the 6.7.0 clock setup to work, so I put back the patch we used with 6.8.1, which is what we have now.
What we have now will lock my laptop up hard. 6.8.1 with the same configuration works.
David, thanks for building the RPMs with Bens patches and posting it in the bug, I've been meaning to do that. If these patches work well, we'll included them in FC5, but I'm reluctant to change this much for FC4.
A relatively simple workaround for FC4 might be for rhpl to turn DynamicClocks _on_ for the Radeon -- perhaps only on PPC, or when it finds that the kernel has done so.
Put them ON unconditionally on ppc. I yet have to get a report of a problem related to dynamic clocks on these. I'd be curious if your DELL still crashes with my patches too btw.
Ben
[ah, need to reply to this thread]
I tried the CD on a G4 Ti 15" original. It did the "LCD meltdown" effect (thanks to andrewo for prodding me with the cd).
On Fri, 2005-05-06 at 12:57 -0400, Andrew Cagney wrote:
[ah, need to reply to this thread]
I tried the CD on a G4 Ti 15" original. It did the "LCD meltdown" effect (thanks to andrewo for prodding me with the cd).
It would be useful if you could give a more detailed report :) This is one of those tipb with an M3 chip ? (r128). I can probably access one of these and run some tests, I haven't given much attention to X r128 driver lately I must admit.
On r128 on ppc, it's generally necessary to have UseFBDev in X config and eventually put a modeline there based on the output of fbset -x (the kernel has a hard coded list of modes for various machine models as those older laptops don't have DDC).
Ben.
Jeremy,
Worked great on my old standby G4 system...
PowerMac 3,1 400MHz cpu 7400, altivec supported motherboard: PowerMac3,1 MacRISC2 PowerMac G4 AGP Graphics
ATI Rage 128 PF/Pro AGP 4x TMDS
Never got to boot the kernel on my iMac G5 .... Got this instead... (this may be expected behavior for the 64bit G5 though)
... ok opening display /pci@0,f0000000 /NVDA, Parent@10/NVDA,Display-B@1... ok copying 0F device tree...done Initializing fake screen: NVDA,Display-A Calling quiesce ... returning 0x01400000 from prom_init
Invalid memory access at %SRR0: 00000000.01403b7c %SRR1: 100000000.00083030
Apple PowerMac8,1 5.2.2f1 BootROM build on 08/18/04 at 16:38:24 . . <snip> . . To continue booting type "mac-boot" and press return
Please find attached the OS X 'system profile' of the G5 if you need it...
I'll try my G4 Powerbook 1GHz when I get home.
Hope this helps,
Jim...
On May 2, 2005, at 5:21 PM, Jeremy Katz wrote:
Hi. I've got an ISO for quick testing of anaconda's X configuration setup available that's a little bit smaller than a full tree. All you should have to do is download the ISO, burn it to a CD, boot and see if X starts up. Then, you can reboot and go back to your normal doings.
Note that this is entirely non-destructive. So you can even run it if you are running OS X. *ANY* results would be helpful. Please be sure to include what you see happen as well as what type of hardware you're using (cpu, video, monitor).
The iso is located at http://people.redhat.com/~katzj/mac-x-test.iso. The md5sum is 34234b3cdf2d89e4e94031a50f819285
Thanks in advance for testing this and helping to make test3 (and thus, the Fedora Core 4 release) better on PPC hardware!
Jeremy
Fedora-ppc mailing list Fedora-ppc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/fedora-ppc
PowerMac G4 400 (ATI Rage 128) works great
though on my Apple 17" CRT studio display X doesn't take up the entire screen - about 90% of it
Cheers
Justin
On 5/3/05, Jeremy Katz katzj@redhat.com wrote:
Hi. I've got an ISO for quick testing of anaconda's X configuration setup available that's a little bit smaller than a full tree. All you should have to do is download the ISO, burn it to a CD, boot and see if X starts up. Then, you can reboot and go back to your normal doings.
Note that this is entirely non-destructive. So you can even run it if you are running OS X. *ANY* results would be helpful. Please be sure to include what you see happen as well as what type of hardware you're using (cpu, video, monitor).
The iso is located at http://people.redhat.com/~katzj/mac-x-test.iso. The md5sum is 34234b3cdf2d89e4e94031a50f819285
Thanks in advance for testing this and helping to make test3 (and thus, the Fedora Core 4 release) better on PPC hardware!
Jeremy
Fedora-ppc mailing list Fedora-ppc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/fedora-ppc
Jeremy Katz wrote:
Hi. I've got an ISO for quick testing of anaconda's X configuration setup available that's a little bit smaller than a full tree. All you should have to do is download the ISO, burn it to a CD, boot and see if X starts up.
PowerBook G4 Titanium 15" 867 MHz (PowerBook3,5); Radeon Mobility 9000 M9 (R250 Lf); internal 1280x854 LCD: Works fine, except that the 800x600 resolution stretched to fill the 3:2 widescreen looks ugly.
-Christian
-
Andrew Cagney -
Benjamin Herrenschmidt -
Christian Walther -
David Woodhouse -
David Zeuthen -
Jeremy Katz -
Jimmy D.Burrell -
Justin Kelly -
Kristian Høgsberg