5:21 p.m.
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
7:51 p.m.
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
7:12 a.m.
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
--
dwmw2
9:41 a.m.
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
10:38 a.m.
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'?
--
dwmw2
11:04 a.m.
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
11:16 a.m.
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.
--
dwmw2
11:47 a.m.
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
12:08 p.m.
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.
--
dwmw2
11:12 a.m.
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
--
dwmw2
6:32 p.m.
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.
12:59 a.m.
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.
--
dwmw2
1:04 a.m.
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.
1:20 a.m.
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.
--
dwmw2
1:30 a.m.
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.
1:48 a.m.
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.
--
dwmw2
2:13 a.m.
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.
3:29 a.m.
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.
--
dwmw2
11:44 a.m.
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
6:36 p.m.
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.
2:22 a.m.
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.
--
dwmw2
2:53 a.m.
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
11:57 a.m.
[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).
6:51 p.m.
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.
8:55 a.m.
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(a)lists.infradead.org
http://lists.infradead.org/mailman/listinfo/fedora-ppc
6:38 p.m.
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(a)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(a)lists.infradead.org
http://lists.infradead.org/mailman/listinfo/fedora-ppc
2:09 p.m.
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
6932
days inactive
6933
days old
26 comments
9 participants
participants (9)
-
Andrew Cagney -
Benjamin Herrenschmidt -
Christian Walther -
David Woodhouse -
David Zeuthen -
Jeremy Katz -
Jimmy D.Burrell -
Justin Kelly -
Kristian Høgsberg