Yes, it works with Radeon HD 4650

[drm] Initialized drm 1.1.0 20060810
xen: registering gsi 19 triggering 0 polarity 1
xen_allocate_pirq: returning irq 19 for gsi 19
xen: --> irq=19
Already setup the GSI :19
firewire_ohci 0000:05:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
firewire_ohci: Added fw-ohci device 0000:05:03.0, OHCI version 1.10
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
xen: registering gsi 16 triggering 0 polarity 1
xen_allocate_pirq: returning irq 16 for gsi 16
.....
[drm] Initialized drm 1.1.0 20060810
xen: registering gsi 19 triggering 0 polarity 1
xen_allocate_pirq: returning irq 19 for gsi 19
xen: --> irq=19
Already setup the GSI :19
firewire_ohci 0000:05:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
firewire_ohci: Added fw-ohci device 0000:05:03.0, OHCI version 1.10
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
xen: registering gsi 16 triggering 0 polarity 1
xen_allocate_pirq: returning irq 16 for gsi 16
xen: --> irq=16
Already setup the GSI :16
radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
radeon 0000:01:00.0: setting latency timer to 64
name_count maxed, losing inode data: dev=00:05, inode=6900
name_count maxed, losing inode data: dev=00:05, inode=6900
name_count maxed, losing inode data: dev=00:05, inode=6900
name_count maxed, losing inode data: dev=00:07, inode=6749
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:05, inode=6900
name_count maxed, losing inode data: dev=00:05, inode=6900
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0xFE8E0000
[drm] register mmio size: 65536
ATOM BIOS: 11X
[drm] Clocks initialized !
name_count maxed, losing inode data: dev=00:07, inode=6891
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6891
name_count maxed, losing inode data: dev=00:07, inode=6902
mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 4077188 kiB.
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
name_count maxed, losing inode data: dev=00:07, inode=6891
name_count maxed, losing inode data: dev=00:07, inode=6891
name_count maxed, losing inode data: dev=00:07, inode=6902
name_count maxed, losing inode data: dev=00:07, inode=6902
  alloc irq_desc for 284 on node 0
  alloc kstat_irqs on node 0
[drm] radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RV730 Microcode
platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin
xen: registering gsi 22 triggering 0 polarity 1
  alloc irq_desc for 22 on node 0
  alloc kstat_irqs on node 0

Boris


--- On Tue, 3/2/10, M A Young <m.a.yo...@durham.ac.uk> wrote:

From: M A Young <m.a.yo...@durham.ac.uk>
Subject: Re: [Fedora-xen] Dom0 kernels
To: xen@lists.fedoraproject.org
Date: Tuesday, March 2, 2010, 6:48 PM

After a long break here is another dom0  kernel 
(kernel-2.6.32.9-1.2.89.xendom0.fc12) at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2023455 or via the 
repository http://fedorapeople.org/~myoung/dom0/ . This is based on the 
xen/stable branch, and requires xen 4 or a patched version of xen 3.4.2 
(there is a source rpm for xen 4 rc5 at 
http://fedorapeople.org/~myoung/dom0/src/xen-4.0.0-0.3.rc5.fc12.src.rpm ). 
The repository only has the x86_64 packages because I can't get i686 to 
boot. This kernel does fix a long standing problem I have been having with 
X not displaying correctly.

     Michael Young
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen



      
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Reply via email to