Bug 374201

Summary: anaconda fails to start installation
Product: [Fedora] Fedora Reporter: Stefan Seefeld <stefan>
Component: rhpxlAssignee: Chris Lumens <clumens>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 8CC: ajax, drkludge, dwmw2, julio
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-11 22:57:01 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:

Description Stefan Seefeld 2007-11-10 01:35:18 UTC
Description of problem:
anaconda raises a python exception during display configuration

Version-Release number of selected component (if applicable):


How reproducible:
Run installation on PS3

Steps to Reproduce:
1. Enter F8 installation on PS3
2.
3.
  
Actual results:

Anaconda starts, then stops with a python traceback

(around rhpxl/videocard.py, line 149, in __init__
  elif os.uname()[4].count("ppc") > 0 and card.pcidom > 0:
AttributeError: device instance has no attribute 'pcidom'


Expected results:

installation to proceed normally

Additional info:

(I tried installing in text-only mode but couldn't figure out how.)

Comment 1 David Woodhouse 2007-11-10 03:15:48 UTC
/me looks suspiciously at
http://git.fedoraproject.org/?p=hosted/rhpxl.git;a=commitdiff;h=81fa0773e2da692836b319410ab051b32dffb3de

AFAICT both hunks of that are broken -- the first because of the trace observed,
and the second because it'll change the fallback case on PowerPC machines to
'vesa' instead of fbdev.

Comment 2 David Woodhouse 2007-11-10 21:12:30 UTC
Hm, I think it's even more broken than it seems at first glance. The assumption
that devices in domains > 0 will be mapped above 4GiB is completely bogus in the
first place -- we support machines where that isn't the case, on which X works fine.

If you want to avoid using 'real' X drivers on cards where the resources are
mapped above 4GiB, then perhaps the best way to achieve that is to try checking
where the resources are mapped, rather than making up broken heuristics?

Besides -- if X maps the resources correctly through sysfs, why does it care
about the physical address of them anyway?

Comment 3 Stefan Seefeld 2007-11-11 16:32:34 UTC
For the record: I have reverted the above change, and dropped the modified
module into a RHupdates directory. With this, I was able to get F8 installed on
my PS3.

Thanks a lot for the quick help !

Comment 4 David Woodhouse 2007-11-11 22:57:01 UTC

*** This bug has been marked as a duplicate of 370761 ***

Comment 5 Greg Morgan 2007-11-15 23:27:05 UTC
*** Bug 381541 has been marked as a duplicate of this bug. ***

Comment 6 David Woodhouse 2007-12-07 01:50:05 UTC
Any chance of getting this fixed, please?

Comment 7 David Woodhouse 2008-01-03 17:20:04 UTC
hello?

Comment 8 David Woodhouse 2008-01-04 00:32:22 UTC
*** Bug 389301 has been marked as a duplicate of this bug. ***