Bug 746410

Summary: [MGA_CARD_TYPE_G550] Add /lib/firmware/matrox/g400_warp.fw into initramfs
Product: [Fedora] Fedora Reporter: Brent Baude <bbaude>
Component: xorg-x11-drv-mgaAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: dennis, gansalmon, itamar, jonathan, karsten, kernel-maint, madhu.chinakonda, mcepl, notting, wwoods, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard: [cat:others]
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-20 15:47:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 718276    
Attachments:
Description Flags
all logs from /tmp
none
anaconda.log from the archive
none
anaconda-yum.conf from the archive
none
program.log from the archive
none
storage.log from the archive
none
syslog from the archive
none
Xorg.0.log from the archive
none
1103 anaconda log
none
1103 syslog
none
1103 X log none

Description Brent Baude 2011-10-15 13:47:09 UTC
Description of problem:

As of now, the only supported card on IBM ppc64 is matrox g400 warp.  It requires firmware to be loaded before X (graphical) can be used.  I think in Fedora this means the driver has to be in the initramfs.  Given the preference to keep the initramfs small, I am proposing just the matrox driver be added though I am not sure this can be done in Fedora.  This can be used to start discussion.

V

Comment 1 Karsten Hopp 2011-10-17 11:18:10 UTC
this firmware file already is in firmware/matrox/ directory in the rootfs.img that is inside the LiveOS/squashfs.img
If it doesn't get loaded automatically, we need to take a closer look at what's going on here.

Comment 2 Bill Nottingham 2011-10-17 15:33:20 UTC
Kernel would be what would have to request the firmware, pushing there for now.

Comment 3 Chuck Ebbert 2011-10-18 14:54:59 UTC
Nothing needs to be in the initramfs if the driver isn't a DRM driver. Is X not working for you?

Comment 4 Will Woods 2011-10-18 19:51:55 UTC
The requested firmware is already present. So what's the actual problem? (Please include relevant error messages from /tmp/{Xorg.0.log,syslog} if possible.)

Comment 5 Brent Baude 2011-10-18 21:07:16 UTC
Chuck and Will, I believe you are correct. I may have been confused by working with RHEL versions.

Nevertheless, the here are the logs from the system, which tries to go into graphical anaconda and fails.  Each console is also basically murdered and corrupted.

Comment 6 Brent Baude 2011-10-18 21:08:28 UTC
Created attachment 528893 [details]
all logs from /tmp

Comment 7 Bill Nottingham 2011-10-19 19:43:01 UTC
Looking at it, there are no errors about missing firmware - in fact, it looks as if graphical anaconda started OK, and X started OK to configure a 1024x768 display.

If that's not working, then it's something in the driver.

Comment 8 Matěj Cepl 2011-10-19 21:38:38 UTC
Created attachment 529112 [details]
anaconda.log from the archive

Comment 9 Matěj Cepl 2011-10-19 21:38:50 UTC
Created attachment 529113 [details]
anaconda-yum.conf from the archive

Comment 10 Matěj Cepl 2011-10-19 21:39:10 UTC
Created attachment 529114 [details]
program.log from the archive

Comment 11 Matěj Cepl 2011-10-19 21:39:24 UTC
Created attachment 529115 [details]
storage.log from the archive

Comment 12 Matěj Cepl 2011-10-19 21:39:35 UTC
Created attachment 529116 [details]
syslog from the archive

Comment 13 Matěj Cepl 2011-10-19 21:39:45 UTC
Created attachment 529117 [details]
Xorg.0.log from the archive

Comment 14 Adam Jackson 2011-10-20 17:53:49 UTC
Reporter, can I get a more elaborate description of the problem than "corrupted"?  A screenshot from a phone camera perhaps?

Comment 15 Will Woods 2011-10-20 18:00:28 UTC
If I understand correctly, the corruption reported here is the same as bug #742613 - that is, this is a bug with setfont and not Xorg.

If the reporter can confirm this fact, let's close this as a duplicate of #742613.

Comment 16 Adam Jackson 2011-10-20 18:05:34 UTC
Actually, now that I'm thinking about it, I bet I know what this is.  Try building xorg-x11-drv-mga-1.4.13-9.fc17 (in the 'master' branch in package git) for ppc and see if that works any better.

Comment 17 Brent Baude 2011-10-20 18:12:13 UTC
Adam, can you elaborate?

Comment 18 Adam Jackson 2011-10-20 20:06:26 UTC
(In reply to comment #17)
> Adam, can you elaborate?

$ sudo yum-builddep -y xorg-x11-drv-mga
$ fedpkg co -a xorg-x11-drv-mga
$ cd xorg-x11-drv-mga
$ fedpkg local
$ sudo yum localinstall ./ppc64/*.rpm

and restart X.

Comment 19 Brent Baude 2011-10-20 21:11:19 UTC
Adam, thanks.  Actually I was asking you to elaborate on "I bet I know what this is."

Comment 20 Adam Jackson 2011-10-24 14:52:14 UTC
(In reply to comment #19)
> Adam, thanks.  Actually I was asking you to elaborate on "I bet I know what
> this is."

Oh that.  There was a bug found and fixed in RHEL6 [1] where the mga driver would clobber the byte swizzle setup register to something that worked fine for little-endian but not big-endian.  Said bug, near as I can tell, had been there forever, but we'd never noticed previously because PPC machines always used the fbdev userspace driver, which doesn't do any direct register access.

[1] - Not merged back to upstream yet because I'm not totally happy with how it's implemented, it puts a register read into the blit path which is probably a small performance hit, should just be precomputed at server init time.

Comment 21 IBM Bug Proxy 2011-11-07 18:45:17 UTC
Created attachment 532118 [details]
1103 anaconda log

Comment 22 IBM Bug Proxy 2011-11-07 18:45:54 UTC
Created attachment 532119 [details]
1103 syslog

Comment 23 IBM Bug Proxy 2011-11-07 18:46:18 UTC
Created attachment 532120 [details]
1103 X log

Comment 24 Brent Baude 2011-11-07 18:47:29 UTC
I have tried Karstens 1103 image it did not fix X as it goes into the graphical anaconda.  I did not pass any special options to anaconda either.

Comment 25 Adam Jackson 2011-11-07 19:22:59 UTC
Can I get some additional details about what the graphical failure looks like?  Screenshot for example?

Comment 26 Brent Baude 2011-11-07 22:13:21 UTC
Using the DVD media for F16 alpha and Karsten's 1103 ISO (both appear to behave the same), order of events are as such:

* Boot media
* Skip media check, and it continues to boot in Anaconda
* When anaconda loads and X is normally loaded, the monitor goes black and no X is loaded.
* there is an error generated on the monitor and presumable BY the monitor which basically says resolution out of range.  I can double check the exact error in the morning.

Same behaviour is being seen in RHEL6.1 as well.

Comment 27 Karsten Hopp 2011-12-21 12:56:14 UTC
reported to work with xorg-x11-drv-mga-1.4.13-12.fc16

Comment 28 Brent Baude 2011-12-21 14:08:58 UTC
Definitely works with a running system.  if you want to create an ISO I can test.

Comment 29 Karsten Hopp 2011-12-21 14:55:45 UTC
F16-RC1 from the usual place already has this package

Comment 30 Fedora End Of Life 2013-01-17 01:58:10 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 '16'.

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 16'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 16 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, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

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