This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 201933 - X fails on Pegasos for lack of domain support
X fails on Pegasos for lack of domain support
Status: CLOSED DUPLICATE of bug 207659
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
6
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-09 16:42 EDT by Peter Czanik
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-12 12:07:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
the requested log file (9.57 KB, text/plain)
2006-08-12 11:41 EDT, Peter Czanik
no flags Details
the requested log file (17.28 KB, text/plain)
2006-08-12 11:42 EDT, Peter Czanik
no flags Details
output of lspci and lspci -v (5.70 KB, text/plain)
2006-08-14 11:18 EDT, Peter Czanik
no flags Details
content of /proc/device-tree (49.42 KB, application/x-compressed-tar)
2006-08-15 15:13 EDT, Peter Czanik
no flags Details

  None (edit)
Description Peter Czanik 2006-08-09 16:42:36 EDT
Description of problem:

Graphical installation does not start on Pegasos. The video card is found, but
at the end it writes, that it can't open display. The actual messages on screen:

Running anaconda, the Fedora Core system installer - please wait...
Probing for video card: ATI Technologies Inc RV280 [Radeon 9200 SE]
Attemtpting to start native X server
Waiting for X server to start ... log located in /tmp/ramfs/X.log
1...2...3...4...5... X server started succcessfullyy.
_X11TransSocketINETConnect() can't get address for localhost:6001: Temporary
failure in name resolution

(mini-wm:437): Gtk-WARNING **: cannot open display: :1


Version-Release number of selected component (if applicable):
Fedora 6 test 2

How reproducible:

Always

Steps to Reproduce:

Start installation on Pegasos
  
Actual results:
See output above.

Expected results:
Working graphical installer

Additional info:
Installed from Fedora 6 Test 2 PPC DVD.
Comment 1 Adam Jackson 2006-08-10 13:48:35 EDT
X can't do much if localhost doesn't resolve.  Installer guys?
Comment 2 David Cantrell 2006-08-11 13:36:06 EDT
Can you attach /tmp/anaconda.log and /tmp/ramfs/X.log?
Comment 3 Peter Czanik 2006-08-12 11:41:38 EDT
Created attachment 134085 [details]
the requested log file
Comment 4 Peter Czanik 2006-08-12 11:42:46 EDT
Created attachment 134086 [details]
the requested log file
Comment 5 Peter Czanik 2006-08-12 11:59:05 EDT
Please see the attached log files.
Comment 6 Adam Jackson 2006-08-14 10:03:18 EDT
Can you attach the output of /sbin/lspci as well please?
Comment 7 Peter Czanik 2006-08-14 11:18:05 EDT
Created attachment 134147 [details]
output of lspci and lspci -v
Comment 8 Chris Lumens 2006-08-15 11:40:05 EDT
Can you tar up /proc/device-tree and attach it to this bug?
Comment 9 Peter Czanik 2006-08-15 15:13:49 EDT
Created attachment 134252 [details]
content of /proc/device-tree
Comment 10 Peter Czanik 2006-08-15 15:17:33 EDT
Please let me know, if you need any more information...
Comment 11 Paul Nasrat 2006-08-15 15:49:59 EDT
Some working notes - we believe the issue is when building up the map from sysfs
in X which may mean something is incorrect along the way.  The first thing which
looks clearly incorrect to me is:

cd /home/pauln/tmp/pegasos/device-tree/pci@C0000000/display@8
[pauln@enki display@8]$ cat device_type 
serial

OF1275 section 3.7 describes basic device types, really this should be "display"
type (see 3.7.1 vs 3.7.5).

Is this the most recent Smart Firmware on the board?  If not please can you
contact Genesi for an update and retest.

If you can could you also backup /sys and attach - I tend to do this as you'll
get read errors from various files:

mkdir /var/tmp/sysfs
cd /var/tmp/sysfs
rsync -avP /sys/ .
then tar up /var/tmp/sysfs.
Comment 12 Matt Sealey, Genesi 2006-08-16 10:55:32 EDT
If the display is in VGA console mode, the device_type is rightfully set to
"serial" - simply so that "find_device_by_type()" style functions do not find it
and expect that there is a linear framebuffer attached.

Firmware revision 1.3 will have real framebuffer support package and console,
and if you run it in this, it is rightly set to "display".

I do not think X gives a flying monkey's tail feather what the device_type is.
It should simply do a PCI bus scan and find a Radeon and start the Radeon driver.
Comment 13 Paul Nasrat 2006-08-16 11:20:46 EDT
Ajax - can you mention what you thought was going on here with the new style
scanning and sysfs.
Comment 14 Peter Czanik 2006-08-16 12:17:06 EDT
Hello,

(In reply to comment #11)
> Is this the most recent Smart Firmware on the board?  If not please can you
> contact Genesi for an update and retest.
Yes, it's the most recent. SUSE and Ubuntu installers work with it fine.

> If you can could you also backup /sys and attach - I tend to do this as you'll
> get read errors from various files:
> 
> mkdir /var/tmp/sysfs
> cd /var/tmp/sysfs
> rsync -avP /sys/ .
> then tar up /var/tmp/sysfs.

The machine freezes when I do the rsync...
Comment 15 Adam Jackson 2006-08-17 22:44:13 EDT
Reporter, please attach the output of:

find /sys/bus/pci/devices/

and

find /proc/bus/pci/

I suspect they don't report the same tree, and whichever one X is picking to use
doesn't include any of the devices behind the bridge - including the radeon
card.  X's PCI scan clearly lacks for any ATI devices.
Comment 16 Matt Sealey, Genesi 2006-08-18 11:29:52 EDT
sh-3.1# find /sys/bus/pci/devices
/sys/bus/pci/devices
/sys/bus/pci/devices/0001:01:08.1
/sys/bus/pci/devices/0001:01:08.0
/sys/bus/pci/devices/0001:01:00.0
/sys/bus/pci/devices/0000:00:0d.0
/sys/bus/pci/devices/0000:00:0c.6
/sys/bus/pci/devices/0000:00:0c.5
/sys/bus/pci/devices/0000:00:0c.4
/sys/bus/pci/devices/0000:00:0c.3
/sys/bus/pci/devices/0000:00:0c.2
/sys/bus/pci/devices/0000:00:0c.1
/sys/bus/pci/devices/0000:00:0c.0
/sys/bus/pci/devices/0000:00:01.0
/sys/bus/pci/devices/0000:00:00.0

sh-3.1# fine /proc/bus/pci
/proc/bus/pci
/proc/bus/pci/01
/proc/bus/pci/01/08.1
/proc/bus/pci/01/08.0
/proc/bus/pci/01/00.0
/proc/bus/pci/00
/proc/bus/pci/00/0d.0
/proc/bus/pci/00/0c.6
/proc/bus/pci/00/0c.5
/proc/bus/pci/00/0c.4
/proc/bus/pci/00/0c.3
/proc/bus/pci/00/0c.2
/proc/bus/pci/00/0c.1
/proc/bus/pci/00/0c.0
/proc/bus/pci/00/01.0
/proc/bus/pci/00/00.0
/proc/bus/pci/devices

The Radeon is at 0001:01:08.1 and I can see it just fine. Vendor/device is
0x1002/0x5964
Comment 17 Adam Jackson 2006-08-18 21:23:49 EDT
Heh.  It would help if X's PCI scan code were at all domain-aware.  Reassigning
to me.
Comment 19 Adam Jackson 2006-09-29 16:23:06 EDT
Fixed in 1.1.1-43 by backing out the domain-hostile portion of the offending
patch.  Still not really domain aware, but as long as the kernel renumbers
busses for us it should work.
Comment 20 David Woodhouse 2007-03-06 11:54:07 EST
I think this bug has returned in F7. When X enumerates the PCI buses, it doesn't
seem to find the Radeon at 0001:01:08.0
Comment 21 David Woodhouse 2007-03-06 12:32:37 EST
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 11ab,6460 card 0000,0000 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,3044 card 1106,3044 rev 46 class 0c,00,10 hdr 00
(II) PCI: 00:05:0: chip 109e,0350 card 0000,0000 rev 12 class 04,00,00 hdr 00
(II) PCI: 00:0c:0: chip 1106,8231 card 0000,0000 rev 10 class 06,01,00 hdr 80
(II) PCI: 00:0c:1: chip 1106,0571 card 0000,0000 rev 06 class 01,01,8f hdr 00
(II) PCI: 00:0c:2: chip 1106,3038 card 0925,1234 rev 1e class 0c,03,00 hdr 00
(II) PCI: 00:0c:3: chip 1106,3038 card 0925,1234 rev 1e class 0c,03,00 hdr 00
(II) PCI: 00:0c:4: chip 1106,8235 card 0000,0000 rev 10 class 06,80,00 hdr 00
(II) PCI: 00:0c:5: chip 1106,3058 card 0000,0000 rev 40 class 04,01,00 hdr 00
(II) PCI: 00:0c:6: chip 1106,3068 card 0000,0000 rev 20 class 07,80,00 hdr 00
(II) PCI: 00:0d:0: chip 1106,3065 card 3065,1106 rev 51 class 02,00,00 hdr 00
(II) PCI: End of PCI scan
Comment 22 David Woodhouse 2007-03-06 12:36:03 EST
When it's _working_, as it was in FC6, it looks more like this:

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 11ab,6460 card 0000,0000 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,3044 card 1106,3044 rev 46 class 0c,00,10 hdr 00
(II) PCI: 00:0c:0: chip 1106,8231 card 0000,0000 rev 10 class 06,01,00 hdr 80
(II) PCI: 00:0c:1: chip 1106,0571 card 0000,0000 rev 06 class 01,01,8f hdr 00
(II) PCI: 00:0c:2: chip 1106,3038 card 0925,1234 rev 1e class 0c,03,00 hdr 00
(II) PCI: 00:0c:3: chip 1106,3038 card 0925,1234 rev 1e class 0c,03,00 hdr 00
(II) PCI: 00:0c:4: chip 1106,8235 card 0000,0000 rev 10 class 06,80,00 hdr 00
(II) PCI: 00:0c:5: chip 1106,3058 card 0000,0000 rev 40 class 04,01,00 hdr 00
(II) PCI: 00:0c:6: chip 1106,3068 card 0000,0000 rev 20 class 07,80,00 hdr 00
(II) PCI: 00:0d:0: chip 1106,3065 card 3065,1106 rev 51 class 02,00,00 hdr 00
(II) PCI: 01:00:0: chip 11ab,6460 card 0000,0000 rev 03 class 06,00,00 hdr 00
(II) PCI: 01:08:0: chip 1002,5960 card 1002,5960 rev 01 class 03,00,00 hdr 80
(II) PCI: 01:08:1: chip 1002,5940 card 1002,5961 rev 01 class 03,80,00 hdr 00
(II) PCI: End of PCI scan
Comment 23 Adam Jackson 2007-03-12 12:07:07 EDT

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

Note You need to log in before you can comment on or make changes to this bug.