Bug 201933

Summary: X fails on Pegasos for lack of domain support
Product: [Fedora] Fedora Reporter: Peter Czanik <peter>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: matt, mcepl, mcepl, rob, xgl-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-12 16:07:07 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:
Attachments:
Description Flags
the requested log file
none
the requested log file
none
output of lspci and lspci -v
none
content of /proc/device-tree none

Description Peter Czanik 2006-08-09 20:42:36 UTC 
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 17:48:35 UTC 
X can't do much if localhost doesn't resolve.  Installer guys?
Comment 2 David Cantrell 2006-08-11 17:36:06 UTC 
Can you attach /tmp/anaconda.log and /tmp/ramfs/X.log?
Comment 3 Peter Czanik 2006-08-12 15:41:38 UTC 
Created attachment 134085 [details]
the requested log file
Comment 4 Peter Czanik 2006-08-12 15:42:46 UTC 
Created attachment 134086 [details]
the requested log file
Comment 5 Peter Czanik 2006-08-12 15:59:05 UTC 
Please see the attached log files.
Comment 6 Adam Jackson 2006-08-14 14:03:18 UTC 
Can you attach the output of /sbin/lspci as well please?
Comment 7 Peter Czanik 2006-08-14 15:18:05 UTC 
Created attachment 134147 [details]
output of lspci and lspci -v
Comment 8 Chris Lumens 2006-08-15 15:40:05 UTC 
Can you tar up /proc/device-tree and attach it to this bug?
Comment 9 Peter Czanik 2006-08-15 19:13:49 UTC 
Created attachment 134252 [details]
content of /proc/device-tree
Comment 10 Peter Czanik 2006-08-15 19:17:33 UTC 
Please let me know, if you need any more information...
Comment 11 Paul Nasrat 2006-08-15 19:49:59 UTC 
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 14:55:32 UTC 
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 15:20:46 UTC 
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 16:17:06 UTC 
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-18 02:44:13 UTC 
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 15:29:52 UTC 
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-19 01:23:49 UTC 
Heh.  It would help if X's PCI scan code were at all domain-aware.  Reassigning
to me.
Comment 18 Matt Sealey, Genesi 2006-09-25 09:54:14 UTC 
https://bugs.freedesktop.org/show_bug.cgi?id=7248
https://bugzilla.novell.com/show_bug.cgi?id=202133
https://launchpad.net/distros/ubuntu/+source/xorg/+bug/61410

This bug is making it's rounds :D

What's the progress?
Comment 19 Adam Jackson 2006-09-29 20:23:06 UTC 
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 16:54:07 UTC 
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 17:32:37 UTC 
(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 17:36:03 UTC 
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 16:07:07 UTC 

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