Bug 445419

Created attachment 304678 [details]
Xorg.0.log file

Hm, why isn't it using /dev/fb0? Does it work if you remove the UseFbdev option?

Well, it's at least opening it. 
/dev/fb0 does exist. 

If you remove the 'UseFbdev' option it tries to use it anyhow, as its default on
ppc apparently. If you set it to "false" it blows up like so: 

(II) R128(0): initializing int10
(II) R128(0): No legacy BIOS found -- trying PCI

Backtrace:
0: /usr/bin/Xorg(xf86SigHandler+0x94) [0x10082e34]
1: [0x100364]
2: /usr/lib/xorg/modules//libint10.so(LockLegacyVGA+0x50) [0xf09ec50]
3: /usr/lib/xorg/modules//libint10.so(xf86ExtendedInitInt10+0x1e4) [0xf0a2f84]
4: /usr/lib/xorg/modules//libint10.so(xf86InitInt10+0x28) [0xf09eac8]
5: /usr/lib/xorg/modules/drivers//r128_drv.so(R128PreInit+0x65c) [0xf14e49c]
6: /usr/bin/Xorg(InitOutput+0xa00) [0x10066140]
7: /usr/bin/Xorg(main+0x288) [0x10022178]
8: /lib/libc.so.6 [0x481618f0]
9: /lib/libc.so.6 [0x48161ab0]

Fatal server error:
Caught signal 7.  Server aborting

If you use 'driver "fbdev"' it works and brings up X. 

Not sure where the fail is here... r128 driver? installer not defaulting to
'fbdev' ? /dev/fb0 not working?

I've got a powerbook g3 here has the same problem (also r128). I've threatened
to take it downstairs and slap it in front of ajax, but haven't got around to it
yet.

The mga driver is equally broken on a ppc64 box I've got (Matrox G450 card).

Interesting. It's working fine here with a G550 on Efika. What machine?

Mine is a G4 tower... 
smolt profile: 

http://www.smolts.org/client/show/pub_f3216f28-fbb5-4888-af2e-0d3f0eb3a55c

My ppc64 box is an IBM IntelliStation something or other, dual PPC970... Can dig
up further details in the morning.

# cat /proc/cpuinfo 
processor       : 0
cpu             : PPC970MP, altivec supported
clock           : 2519.967993MHz
revision        : 1.1 (pvr 0044 0101)

processor       : 1
cpu             : PPC970MP, altivec supported
clock           : 2519.967993MHz
revision        : 1.1 (pvr 0044 0101)

timebase        : 14318000
platform        : pSeries
machine         : CHRP IBM,7047-185

Can you attach the logfile generated with '--logverbose 255'? We should probably
have a separate bug for the MGA failure.

Created attachment 305140 [details]
Xorg 'startx -- -logverbose 255' log file with mga driver and usefbdev true

Attached log output is from trying to fire up X via 'startx -- -logverbose 255'
with the below inlined xorg.conf. I'm pretty sure its identical to what I was
getting with r128 in my powerbook.

Section "ServerLayout"
	Identifier     "Default Layout"
	Screen	    0  "Screen0" 0 0
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver	    "mga"
	Option	    "UseFBDev" "true"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device	   "Videocard0"
	DefaultDepth	 24
	SubSection "Display"
		Viewport   0 0
		Depth	  24
	EndSubSection
EndSection

Created attachment 305141 [details]
Xorg 'startx -- -logverbose 255' log file with mga driver and usefbdev false

If UseFBDev is set to false, the X log seems to suggest things started up okay,
but all I see is a blank screen. The light on the monitor is green though, not
orange, so it apparently thinks its getting a signal... However, running 'ps ax
|grep Xorg' doesn't show any running X server process.

Oddly, trying --logverbose 255 here doesn't seem to get any additional output. 
It takes the argument, but just logs the same amount of stuff. ;( 

I will poke at it a bit more and see if I can get it to take it...

Sorry, it should be just '-logverbose 255'. Not two dashes. And just 'Xorg
-logverbose 255' would be better than startx. Or even run it in GDB. If it
crashes, show the backtrace.

ajax has my powerbook in front of him. The primary problem is an altered path in
sysfs, so he's got r128 coming up on my powerbook now. Not sure when to expect
an updated package... ajax?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #15)
> ajax has my powerbook in front of him. The primary problem is an altered path in
> sysfs, so he's got r128 coming up on my powerbook now. Not sure when to expect
> an updated package... ajax?

Note, that putting bug in NEEDINFO against many developers is one of the most
secure ways how to get bug lost.

I had to install F9 via text mode on my Powerbook (lspci reports 'Rage Mobility
M3' using driver 'aty128fb'), and system-config-display can't start either
9screen 'blooms').. Does this card fall under 'r128', or should I file a
separate bug?

(I tried F8 too, same result)

Kevin, Jarod,
Does this still happen on F10 ?
Thanks

Not sure. The machine is running rawhide now. 
I can see if it's ok in rawhide, and possibly do a f10 install on it to test if you like. 
Will come back with more info soon.

Yeah, it still blows up in rawhide:

(II) R128(0): Using 8 MB AGP aperture
(II) R128(0): Using 1 MB for the ring buffer
(II) R128(0): Using 2 MB for vertex/indirect buffers
(II) R128(0): Using 5 MB for AGP textures
(II) R128(0): Memory manager initialized to (0,0) (800,2457)
(II) R128(0): Reserved area from (0,600) to (800,602)
(II) R128(0): Largest offscreen area available: 800 x 1855
(II) R128(0): Reserved back buffer from (0,602) to (800,1202)
(II) R128(0): Reserved depth buffer from (0,1202) to (800,1803)
(II) R128(0): Reserved depth span from (0,1802) offset 0x57fd00
(II) R128(0): Reserved 8704 kb for textures at offset 0x77f880
(II) R128(0): Using XFree86 Acceleration Architecture (XAA)
        Screen to screen bit blits
        Solid filled rectangles
        8x8 mono pattern filled rectangles
        Indirect CPU to Screen color expansion
        Solid Lines
        Dashed Lines
        Setting up tile and stipple cache:
                30 128x128 slots
(II) R128(0): Acceleration enabled
(==) R128(0): Backing store disabled
(==) R128(0): Silken mouse enabled
(II) R128(0): Using hardware cursor (scanline 7212)
(II) R128(0): Largest offscreen area available: 800 x 651
(II) R128(0): DPMS enabled

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x50) [0x100ffda0]
1: /usr/bin/Xorg(xf86SigHandler+0xd8) [0x10085838]
2: [0x100364]
3: /usr/lib/xorg/modules/extensions//libdri.so(DRIFinishScreenInit+0x3c) [0xe6da27c]
4: /usr/lib/xorg/modules/drivers//r128_drv.so(R128DRIFinishScreenInit+0x60) [0xe65cab0]
5: /usr/lib/xorg/modules/drivers//r128_drv.so(R128ScreenInit+0x1064) [0xe658df4]
6: /usr/bin/Xorg(AddScreen+0x1ec) [0x1002129c]
7: /usr/bin/Xorg(InitOutput+0x83c) [0x1006a27c]
8: /usr/bin/Xorg(main+0x224) [0x10021a04]
9: /lib/libc.so.6 [0xfd6ec64]
10: /lib/libc.so.6 [0xfd6ee20]

Fatal server error:
Caught signal 11.  Server aborting


Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

I can try and provide more info, or try f10 on it soon.

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.