Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 201933
Summary: | X fails on Pegasos for lack of domain support | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Czanik <peter> | ||||||||||
Component: | xorg-x11-server | Assignee: | Adam Jackson <ajax> | ||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | |||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 6 | CC: | 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
Peter Czanik
2006-08-09 20:42:36 UTC
X can't do much if localhost doesn't resolve. Installer guys? Can you attach /tmp/anaconda.log and /tmp/ramfs/X.log? Created attachment 134085 [details]
the requested log file
Created attachment 134086 [details]
the requested log file
Please see the attached log files. Can you attach the output of /sbin/lspci as well please? Created attachment 134147 [details]
output of lspci and lspci -v
Can you tar up /proc/device-tree and attach it to this bug? Created attachment 134252 [details]
content of /proc/device-tree
Please let me know, if you need any more information... 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. 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. Ajax - can you mention what you thought was going on here with the new style scanning and sysfs. 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... 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. 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 Heh. It would help if X's PCI scan code were at all domain-aware. Reassigning to me. 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? 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. 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 (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 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 *** This bug has been marked as a duplicate of 207659 *** |