Xen devel - Mar 2010 - [Patch RFC] nouveau accelerated on Xen pv-ops kernel

Hi,
Following is a simple patch that is needed in nouveau to get
accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's
2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
almost the mainline merge), was substituted into the kernel-tree.
All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used
of the same day.

Patch:
diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
--- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
10:19:28.000000000 +0530
+++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10
17:28:59.000000000 +0530
@@ -271,7 +271,10 @@
         */

        vma->vm_private_data = bo;
-       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+       if (!((bo->mem.placement & TTM_PL_MASK_MEM) &
TTM_PL_FLAG_TT))
+               vma->vm_flags |= VM_IO;
+       vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags);
        return 0;
 out_unref:
        ttm_bo_unref(&bo);

This patch is necessary because, in Xen, PFN of a page is virtualised.
So physical addresses
for DMA programming needs to use the MFN. Xen transparently does the
correct translation
using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, then Xen
assumes that the backing
memory is in the IOMEM space, and PFN equals MFN. If not set,
page_to_pfn() returns MFN.

The patch enables the ttm_bo_vm_fault() handler to behave correctly
under Xen, and has no
side-effects on normal (not under Xen) operations. The use of
TTM_PL_FLAG_TT in the
check assumes that all other placements are backed by device memory or
IO. If there are
any other placements that use system memory, that flag has to be OR'ed
into the check.

The above patch has no implications on a normal kernel or a Xen pv_ops
kernel booted without
the Xen hypervisor. My testing is on a debian-lenny environment on a
Core2 processor with
nVidia GeForce 9400 GT.

I'm adding dri-devel@ to CC, since this suggested patch touches
TTM code, and none of the Nouveau code. TTM patches go via
dri-devel at .

Thanks.


On Wed, 10 Mar 2010 18:51:21 +0530
Arvind R <arvino55 at gmail.com> wrote:
> Hi,
> Following is a simple patch that is needed in nouveau to get
> accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's
> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
> almost the mainline merge), was substituted into the kernel-tree.
> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm)
> used of the same day.
> 
> Patch:
> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
> 10:19:28.000000000 +0530
> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10
> 17:28:59.000000000 +0530
> @@ -271,7 +271,10 @@
>          */
> 
>         vma->vm_private_data = bo;
> -       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP |
> VM_DONTEXPAND;
> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP |
> VM_DONTEXPAND;
> +       if (!((bo->mem.placement & TTM_PL_MASK_MEM) &
> TTM_PL_FLAG_TT))
> +               vma->vm_flags |= VM_IO;
> +       vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags);
>         return 0;
>  out_unref:
>         ttm_bo_unref(&bo);
> 
> This patch is necessary because, in Xen, PFN of a page is
> virtualised. So physical addresses
> for DMA programming needs to use the MFN. Xen transparently does
> the correct translation
> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set,
> then Xen assumes that the backing
> memory is in the IOMEM space, and PFN equals MFN. If not set,
> page_to_pfn() returns MFN.
> 
> The patch enables the ttm_bo_vm_fault() handler to behave
> correctly under Xen, and has no
> side-effects on normal (not under Xen) operations. The use of
> TTM_PL_FLAG_TT in the
> check assumes that all other placements are backed by device
> memory or IO. If there are
> any other placements that use system memory, that flag has to be
> OR'ed into the check.
> 
> The above patch has no implications on a normal kernel or a Xen
> pv_ops kernel booted without
> the Xen hypervisor. My testing is on a debian-lenny environment
> on a Core2 processor with
> nVidia GeForce 9400 GT.
-- 
Pekka Paalanen
http://www.iki.fi/pq/

On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi>
wrote:
> I''m adding dri-devel@ to CC, since this suggested patch touches
> TTM code, and none of the Nouveau code. TTM patches go via
> dri-devel@.
>
> Thanks.
>
>
> On Wed, 10 Mar 2010 18:51:21 +0530
> Arvind R <arvino55@gmail.com> wrote:
>
>> Hi,
>> Following is a simple patch that is needed in nouveau to get
>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is
jeremy''s
>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
>> almost the mainline merge), was substituted into the kernel-tree.
>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm)
>> used of the same day.
>>
>> Patch:
>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
>> 10:19:28.000000000 +0530
>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10
>> 17:28:59.000000000 +0530
>> @@ -271,7 +271,10 @@
>>          */
>>
>>         vma->vm_private_data = bo;
>> -       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP |
>> VM_DONTEXPAND;
>> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP |
>> VM_DONTEXPAND;
>> +       if (!((bo->mem.placement & TTM_PL_MASK_MEM) &
>> TTM_PL_FLAG_TT))
>> +               vma->vm_flags |= VM_IO;
>> +       vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags);
>>         return 0;
>>  out_unref:
>>         ttm_bo_unref(&bo);
>>
Sorry for the typo: in the last added line,
vma_get_vm_prot(vma->vm_flags) should be
vma->vm_get_page_prot(vma->vm_flags)

Arvind

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/13/2010 05:03:22 PM:
> On 03/12/2010 01:45 PM, Arvind R wrote:
> > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi>
wrote:
> >> I''m adding dri-devel@ to CC, since this suggested patch
touches
> >> TTM code, and none of the Nouveau code. TTM patches go via
> >> dri-devel@.
> >>
> >> Thanks.
> >>
> >>
> >> On Wed, 10 Mar 2010 18:51:21 +0530
> >> Arvind R <arvino55@gmail.com> wrote:
> >>
> >>> Hi,
> >>> Following is a simple patch that is needed in nouveau to get
> >>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is
jeremy''s
> >>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which
is
> >>> almost the mainline merge), was substituted into the
kernel-tree.
> >>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau,
libdrm)
> >>> used of the same day.
> >>>
> >>> Patch:
> >>> diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
2010-01-27
> >>> 10:19:28.000000000 +0530
> >>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 
2010-03-10
> >>> 17:28:59.000000000 +0530
> >>> @@ -271,7 +271,10 @@
> >>>          */
> >>>
> >>>         vma->vm_private_data = bo;
> >>> -       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP
|
> >>> VM_DONTEXPAND;
> >>> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP |
> >>> VM_DONTEXPAND;
> >>> +       if (!((bo->mem.placement & TTM_PL_MASK_MEM)
&
> >>> TTM_PL_FLAG_TT))
> >>> +               vma->vm_flags |= VM_IO;
> >>> +       vma->vm_page_prot =
vma_get_vm_prot(vma->vm_flags);
> >>>         return 0;
> >>>  out_unref:
> >>>         ttm_bo_unref(&bo);
> >>>
> > sorry for the typo and other procedural errors.
> > the last added line should be
> > +    vma->vm_page_prot = vm_get_page_prot(vma->vm_flags)
> > 
> >>> This patch is necessary because, in Xen, PFN of a page is
> >>> virtualised. So physical addresses
> >>> for DMA programming needs to use the MFN. Xen transparently
does
> >>> the correct translation
> >>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set,
> >>> then Xen assumes that the backing
> >>> memory is in the IOMEM space, and PFN equals MFN. If not set,
> >>> page_to_pfn() returns MFN.
> >>>
> >>> The patch enables the ttm_bo_vm_fault() handler to behave
> >>> correctly under Xen, and has no
> >>> side-effects on normal (not under Xen) operations. The use of
> >>> TTM_PL_FLAG_TT in the
> >>> check assumes that all other placements are backed by device
> >>> memory or IO. If there are
> >>> any other placements that use system memory, that flag has to
be
> >>> OR''ed into the check.
> >>>
> >>> The above patch has no implications on a normal kernel or a
Xen
> >>> pv_ops kernel booted without
> >>> the Xen hypervisor. My testing is on a debian-lenny
environment
> >>> on a Core2 processor with
> >>> nVidia GeForce 9400 GT.
> >>
> > Efficacy of patch:
> > successful flightgear run on dom0 AND bareboot!
> > 
> Jeremy, will you be merging this patch into any of the xen/stable-*
> branches any time soon?
> 
> Thanks,
> joanna.
Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen on 
my two primary test boxes (GeForce 6200, GeForce 7300).  However, on my 
really old machines (AGP GeForce2 MX200), this causes a new crash.  These 
old boxes were actually working fine in Xen prior to this patch, just 
w/out 3d acceleration.  Now I get the following messages in dmesg:

[  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
[  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: 
initialised FIFO 1
[  129.643791] X: Corrupted page table at address 40412000
[  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000 
[  129.643856] Bad pagetable: 000f [#1] SMP 
[  129.643897] last sysfs file: 
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
[  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1 
video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 snd_ac97_codec 
ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss 
snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device 
snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer 
ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac 
snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot 
dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd 
aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
[  129.644024] 
[  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
[  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
[  129.644024] EIP is at 0x40394596
[  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
[  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
[  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110 
task.ti=ea1ce000)
[  129.644024] 
[  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
[  129.644024] ---[ end trace 569eb18d737a8611 ]---
[  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing 
fifo 1


And my X log ends abruptly after this line:
(II) NOUVEAU(0): Opened GPU Channel 1

Any ideas?

-Mike

---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 03/15/2010 07:44 AM, Michael D Labriola wrote:
> Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen on
> my two primary test boxes (GeForce 6200, GeForce 7300).  However, on my
> really old machines (AGP GeForce2 MX200), this causes a new crash.  These
> old boxes were actually working fine in Xen prior to this patch, just
> w/out 3d acceleration.  Now I get the following messages in dmesg:
>
> [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
> initialised FIFO 1
> [  129.643791] X: Corrupted page table at address 40412000
> [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
> [  129.643856] Bad pagetable: 000f [#1] SMP
> [  129.643897] last sysfs file:
> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
> [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1
> video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 snd_ac97_codec
> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device
> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac
> snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot
> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd
> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
> [  129.644024]
> [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
> [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
> [  129.644024] EIP is at 0x40394596
> [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
> [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
> [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
> task.ti=ea1ce000)
> [  129.644024]
> [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
> [  129.644024] ---[ end trace 569eb18d737a8611 ]---
> [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing
> fifo 1
>
>
> And my X log ends abruptly after this line:
> (II) NOUVEAU(0): Opened GPU Channel 1
>
> Any ideas?
>    
Well, this is generally the symptom that someone is confusing mfns and 
pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in 
some pte.  If you run it under strace, can you identify which mapping 
the fault is happening in?

     J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Mar 16, 2010 at 4:43 AM, Jeremy Fitzhardinge <jeremy@goop.org>
wrote:
> On 03/15/2010 07:44 AM, Michael D Labriola wrote:
>>
>> Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen
on
>> my two primary test boxes (GeForce 6200, GeForce 7300).  However, on my
>> really old machines (AGP GeForce2 MX200), this causes a new crash.
 These
>> old boxes were actually working fine in Xen prior to this patch, just
>> w/out 3d acceleration.  Now I get the following messages in dmesg:
>>
>> [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
>> [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
>> initialised FIFO 1
>> [  129.643791] X: Corrupted page table at address 40412000
>> [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
>> [  129.643856] Bad pagetable: 000f [#1] SMP
>> [  129.643897] last sysfs file:
>> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
>> [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1
>> video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0
snd_ac97_codec
>> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
>> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device
>> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
>> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore
i82860_edac
>> snd_page_alloc pata_acpi edac_core parport_pc floppy parport
dm_snapshot
>> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd
>> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
>> [  129.644024]
>> [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
>> [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
>> [  129.644024] EIP is at 0x40394596
>> [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
>> [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
>> [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
>> [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
>> task.ti=ea1ce000)
>> [  129.644024]
>> [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
>> [  129.644024] ---[ end trace 569eb18d737a8611 ]---
>> [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free:
freeing
>> fifo 1
>>
>>
>> And my X log ends abruptly after this line:
>> (II) NOUVEAU(0): Opened GPU Channel 1
>>
>> Any ideas?
>>
>
> Well, this is generally the symptom that someone is confusing mfns and
pfns,
> and therefore ends up incorrectly setting the _PAGE_IO flag in some pte.
 If
> you run it under strace, can you identify which mapping the fault is
> happening in?
>
>    J
>
Just wanted to emphasise that not updating vma->vm_page_prot after updating
the flags correctly failed to provide the solution. Maybe forcing this update in
all places will show up new failures.

Also, maybe the final solution needs to ''or''  TTM_PL_SYSTEM
also into
the conditional.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/15/2010 07:13:20 PM:
> On 03/15/2010 07:44 AM, Michael D Labriola wrote:
> > Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen
on
> > my two primary test boxes (GeForce 6200, GeForce 7300).  However, on 
my
> > really old machines (AGP GeForce2 MX200), this causes a new crash. 
These
> > old boxes were actually working fine in Xen prior to this patch, just
> > w/out 3d acceleration.  Now I get the following messages in dmesg:
> >
> > [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> > [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
> > initialised FIFO 1
> > [  129.643791] X: Corrupted page table at address 40412000
> > [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
> > [  129.643856] Bad pagetable: 000f [#1] SMP
> > [  129.643897] last sysfs file:
> > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
> > [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1
> > video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 
snd_ac97_codec
> > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
> > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device
> > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
> > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore 
i82860_edac
> > snd_page_alloc pata_acpi edac_core parport_pc floppy parport 
dm_snapshot
> > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd
> > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
> > [  129.644024]
> > [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
> > [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
> > [  129.644024] EIP is at 0x40394596
> > [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
> > [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
> > [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> > [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
> > task.ti=ea1ce000)
> > [  129.644024]
> > [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
> > [  129.644024] ---[ end trace 569eb18d737a8611 ]---
> > [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: 
freeing
> > fifo 1
> >
> >
> > And my X log ends abruptly after this line:
> > (II) NOUVEAU(0): Opened GPU Channel 1
> >
> > Any ideas?
> > 
> 
> Well, this is generally the symptom that someone is confusing mfns and 
> pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in 
> some pte.  If you run it under strace, can you identify which mapping 
> the fault is happening in?
I''ve attached the output of ''strace -o strace-Xorg
Xorg''.  Figuring out
which mapping the fault is happening in is a little over my head, I''m 
afraid.  If you need different arguments to strace, let me know and
I''ll
do it again.

Thanks!

-Mike

---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/16/2010 03:18:01 AM:
> On Tue, Mar 16, 2010 at 4:43 AM, Jeremy Fitzhardinge
<jeremy@goop.org>
wrote:
> > On 03/15/2010 07:44 AM, Michael D Labriola wrote:
> >>
> >> Hmm... I just verified that this patch fixes KMS/Nouveau issues in
Xen on
> >> my two primary test boxes (GeForce 6200, GeForce 7300).  However,
on
my
> >> really old machines (AGP GeForce2 MX200), this causes a new crash.
 These
> >> old boxes were actually working fine in Xen prior to this patch,
just
> >> w/out 3d acceleration.  Now I get the following messages in dmesg:
> >>
> >> [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number
1
> >> [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
> >> initialised FIFO 1
> >> [  129.643791] X: Corrupted page table at address 40412000
> >> [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
> >> [  129.643856] Bad pagetable: 000f [#1] SMP
> >> [  129.643897] last sysfs file:
> >> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
> >> [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc 
raid1
> >> video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 
snd_ac97_codec
> >> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
> >> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw
snd_seq_device
> >> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
> >> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore 
i82860_edac
> >> snd_page_alloc pata_acpi edac_core parport_pc floppy parport 
dm_snapshot
> >> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache
jbd
> >> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
> >> [  129.644024]
> >> [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) 
P4DC6
> >> [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU:
0
> >> [  129.644024] EIP is at 0x40394596
> >> [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 
00044000
> >> [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: 
bfe7f780
> >> [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> >> [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
> >> task.ti=ea1ce000)
> >> [  129.644024]
> >> [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP
007b:bfe7f780
> >> [  129.644024] ---[ end trace 569eb18d737a8611 ]---
> >> [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: 
freeing
> >> fifo 1
> >>
> >>
> >> And my X log ends abruptly after this line:
> >> (II) NOUVEAU(0): Opened GPU Channel 1
> >>
> >> Any ideas?
> >>
> >
> > Well, this is generally the symptom that someone is confusing mfnsand 
pfns,
> > and therefore ends up incorrectly setting the _PAGE_IO flag in some 
pte.  If
> > you run it under strace, can you identify which mapping the fault is
> > happening in?
> >
> >    J
> >
> Just wanted to emphasise that not updating vma->vm_page_prot after 
updating
> the flags correctly failed to provide the solution. Maybe forcing 
> this update in
> all places will show up new failures.
I''m not sure I follow, as I''ve gotten in a little over my head
here.

 
> Also, maybe the final solution needs to ''or'' 
TTM_PL_SYSTEM also into
> the conditional.
I''ll kick off a compile with TTM_PL_SYSTEM orred into the conditional
and
see which of my boxes are functional afterwards.

-Mike

---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > And my X log ends abruptly after this line:
> > > (II) NOUVEAU(0): Opened GPU Channel 1
> > >
> > > Any ideas?
> > > 
> > 
> > Well, this is generally the symptom that someone is confusing mfns and
> > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in 
> > some pte.  If you run it under strace, can you identify which mapping 
> > the fault is happening in?
> 
> I''ve attached the output of ''strace -o strace-Xorg
Xorg''.  Figuring out
> which mapping the fault is happening in is a little over my head,
I''m
> afraid.  If you need different arguments to strace, let me know and
I''ll
> do it again.
So just to be sure, you took the 2.6.32 (xen/next or
xen/stable-2.6.32.x), copied the include and nouveu directory from ..?
2.6.33? and then ran this. Did you have to edit your xorg.conf file or
it ran just fine? Was this Fedora 13 or Fedora 12?

Arvind explanation about the Nvidia driver pointed out that the NVidia
driver (drm/nouvue) can operate on different channels. Where channel 1
is the framebuffer, and the other are for well, KMS, and other
applications.

I belive I was looking at the wrong section of the drivers (not the
drivers/video/gpu ones)- this certainly looks to be the issues the Jeremy
mentioned.

Also I would suggest you load drm with the debug variable set to the 255
to get most of what his happening. 

Based on your strace, the last call is:
4000)                          = 0x9324000
write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 
ioctl(11, 0xc0106445, 0x930a908)        = 0  
ioctl(11, 0x400c6444, 0xbfd2a210)       = 0  
+++ killed by SIGKILL +++

I cannot find what 0x45 is in the upstream Linux, so you must be using a
different nouv* driver than that. The 0x44 is:

  DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH),

Which looks to be pretty harmless. I presume it is the next thing (using
the address returned) that the X driver tries to do that makes it go boom.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010 
01:21:35 PM:
> > > > And my X log ends abruptly after this line:
> > > > (II) NOUVEAU(0): Opened GPU Channel 1
> > > >
> > > > Any ideas?
> > > > 
> > > 
> > > Well, this is generally the symptom that someone is confusing
mfns
and 
> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag
in
> > > some pte.  If you run it under strace, can you identify which 
mapping 
> > > the fault is happening in?
> > 
> > I''ve attached the output of ''strace -o strace-Xorg
Xorg''.  Figuring
out 
> > which mapping the fault is happening in is a little over my head,
I''m
> > afraid.  If you need different arguments to strace, let me know and 
I''ll 
> > do it again.
> 
> So just to be sure, you took the 2.6.32 (xen/next or
> xen/stable-2.6.32.x), copied the include and nouveu directory from ..?
> 2.6.33? and then ran this.
I actually took a slightly more sadistic route than Arvind... ;-)  A while 
back, I backported the important stuff from the Nouveau kernel git tree 
back to v2.6.31.  Basically guessed at which commits were important, wrote 
a script to cherry pick each and every one, and spent an entire day 
reading commit logs, resolving conflicts, and figuring out which other 
non-drm commits I needed.  Sounds retarded, I know, but it was a pretty 
interesting way to get myself up to speed with the code base.  The 
resulting 2.6.31-nouveau kernel runs like a champ on all my hardware.

Then I merged that into my clone of Jeremy''s xen/master which I use
with
Xen 3.4.2.

Since then, I''ve been periodically cherry picking all new commits off
the
nouveau tree.  Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new 
libdrm, mesa, and xf86-video-nouveau all from their respective git trees 
as of yesterday.  (drm and xf86-video-nouveau are on their master 
branches, mesa is on the 7.8 branch)

This all works great using xen/master bare metal.  It used to work fine on 
my old GeForce2 MX based systems in Xen.  Arvind''s patch made it work
on
my nice new systems in Xen, but broke it on the old ones.  Everything 
still works fine bare metal.
> Did you have to edit your xorg.conf file or
> it ran just fine? 
Well, I had to create an xorg.conf that looks like this:

Section "Device"
  Identifier "foo"
  Driver "nouveau"
EndSection

Otherwise it uses the ''nv'' driver...  and I haven''t
stumbled onto how to
get nouveau to automatically get used (aside from uninstalling the nv 
driver).

> Was this Fedora 13 or Fedora 12?
This is all being done on a custom 32bit Linux distro that we use for our 
tightly configuration controlled system deliveries.  It was fedora based a 
looooooooong time ago (FC5), but is completely unrecognizable now.

> Arvind explanation about the Nvidia driver pointed out that the NVidia
> driver (drm/nouvue) can operate on different channels. Where channel 1
> is the framebuffer, and the other are for well, KMS, and other
> applications.
> 
> I belive I was looking at the wrong section of the drivers (not the
> drivers/video/gpu ones)- this certainly looks to be the issues the 
> Jeremy mentioned.
> 
> Also I would suggest you load drm with the debug variable set to the 255
> to get most of what his happening. 
I''ll try that.

> Based on your strace, the last call is:
> 4000)                          = 0x9324000
> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 
> ioctl(11, 0xc0106445, 0x930a908)        = 0 
> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0 
> +++ killed by SIGKILL +++
> 
> I cannot find what 0x45 is in the upstream Linux, so you must be using a
> different nouv* driver than that. The 0x44 is:
> 
>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH),
> 
> Which looks to be pretty harmless. I presume it is the next thing (using
> the address returned) that the X driver tries to do that makes it go 
boom.

I''ve never used strace before... how do you map between the ioctl 
definitions and the hex addresses?


---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > So just to be sure, you took the 2.6.32 (xen/next or
> > xen/stable-2.6.32.x), copied the include and nouveu directory from ..?
> > 2.6.33? and then ran this.
> 
> I actually took a slightly more sadistic route than Arvind... ;-)  A while 
> back, I backported the important stuff from the Nouveau kernel git tree 
> back to v2.6.31.  Basically guessed at which commits were important, wrote 
> a script to cherry pick each and every one, and spent an entire day 
> reading commit logs, resolving conflicts, and figuring out which other 
> non-drm commits I needed.  Sounds retarded, I know, but it was a pretty 
> interesting way to get myself up to speed with the code base.  The 
> resulting 2.6.31-nouveau kernel runs like a champ on all my hardware.
That is ambitious.
> 
> Then I merged that into my clone of Jeremy''s xen/master which I
use with
> Xen 3.4.2.
> 
> Since then, I''ve been periodically cherry picking all new commits
off the
> nouveau tree.  Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new 
> libdrm, mesa, and xf86-video-nouveau all from their respective git trees 
> as of yesterday.  (drm and xf86-video-nouveau are on their master 
> branches, mesa is on the 7.8 branch)
> 
> This all works great using xen/master bare metal.  It used to work fine on 
> my old GeForce2 MX based systems in Xen.  Arvind''s patch made it
work on
> my nice new systems in Xen, but broke it on the old ones.  Everything 
> still works fine bare metal.
> 
> > Did you have to edit your xorg.conf file or
> > it ran just fine? 
> 
> Well, I had to create an xorg.conf that looks like this:
> 
> Section "Device"
>   Identifier "foo"
>   Driver "nouveau"
> EndSection
> 
> Otherwise it uses the ''nv'' driver...  and I
haven''t stumbled onto how to
> get nouveau to automatically get used (aside from uninstalling the nv 
> driver).
> 
> 
> > Was this Fedora 13 or Fedora 12?
> 
> This is all being done on a custom 32bit Linux distro that we use for our 
> tightly configuration controlled system deliveries.  It was fedora based a 
> looooooooong time ago (FC5), but is completely unrecognizable now.
Ah, so it is 32-bit, not 64-bit.
> 
> 
> > Arvind explanation about the Nvidia driver pointed out that the NVidia
> > driver (drm/nouvue) can operate on different channels. Where channel 1
> > is the framebuffer, and the other are for well, KMS, and other
> > applications.
> > 
> > I belive I was looking at the wrong section of the drivers (not the
> > drivers/video/gpu ones)- this certainly looks to be the issues the 
> > Jeremy mentioned.
> > 
> > Also I would suggest you load drm with the debug variable set to the
255
> > to get most of what his happening. 
> 
> I''ll try that.
> 
> 
> > Based on your strace, the last call is:
> > 4000)                          = 0x9324000
> > write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 
> > ioctl(11, 0xc0106445, 0x930a908)        = 0 
> > ioctl(11, 0x400c6444, 0xbfd2a210)       = 0 
> > +++ killed by SIGKILL +++
> > 
> > I cannot find what 0x45 is in the upstream Linux, so you must be using
a
> > different nouv* driver than that. The 0x44 is:
> > 
> >   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_AUTH),
> > 
> > Which looks to be pretty harmless. I presume it is the next thing
(using
> > the address returned) that the X driver tries to do that makes it go 
> boom.
> 
> I''ve never used strace before... how do you map between the ioctl 
> definitions and the hex addresses?
The IOCTL numbers are generated by this macro:

#define DRM_IOCTL_BASE                  ''d''
#define DRM_IO(nr)                      _IO(DRM_IOCTL_BASE,nr)

#define _IOC(dir,type,nr,size) \
        (((dir)  << _IOC_DIRSHIFT) | \
         ((type) << _IOC_TYPESHIFT) | \
         ((nr)   << _IOC_NRSHIFT) | \
         ((size) << _IOC_SIZESHIFT))

#define _IO(type,nr)            _IOC(_IOC_NONE,(type),(nr),0)

and the values are:
_IOC_NRSHIFT = 0
_IOC_TYPESHIFT = 8
_IOC_SIZESHIFT = 16
_IOC_DIRSHIFT = 30

Which basically translates that the 0 through 8 bits are the
''nr'' (0x44),
8 throught 16 are the ''type'' (which is the letter
''d''), and the 16
through 30 is the size of the structure, and the last two bits are for
direction, which in this case is the value ''0''.

At least that is what I think it translates too. Now I am not certain
anymore..
> 
> 
> ---
> Michael D Labriola
> Electric Boat
> mlabriol@gdeb.com
> 401-848-8871 (desk)
> 401-848-8513 (lab)
> 401-316-9844 (cell)
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > Also I would suggest you load drm with the debug variable set to
the 255
> > > to get most of what his happening. 
> > 
> > I''ll try that.
> > 
You can also use the attached debug patch and re-jigger it to be in the
nouveau functions that cause this failure. It isn''t compile tested so
be careful.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@gdeb.com>
wrote:
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on 03/16/2010
> 01:21:35 PM:
>
>> > > > And my X log ends abruptly after this line:
>> > > > (II) NOUVEAU(0): Opened GPU Channel 1
>> > > >
>> > > > Any ideas?
>> > > >
>> > >
>> > > Well, this is generally the symptom that someone is confusing
mfns
> and
>> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO
flag in
>
>> > > some pte.  If you run it under strace, can you identify which
> mapping
>> > > the fault is happening in?
>> >
>> > I''ve attached the output of ''strace -o
strace-Xorg Xorg''.  Figuring
> out
>> > which mapping the fault is happening in is a little over my head,
I''m
>> > afraid.  If you need different arguments to strace, let me know
and
> I''ll
>> > do it again.
>>
>> So just to be sure, you took the 2.6.32 (xen/next or
>> xen/stable-2.6.32.x), copied the include and nouveu directory from ..?
>> 2.6.33? and then ran this.
>
> I actually took a slightly more sadistic route than Arvind... ;-)  A while
> back, I backported the important stuff from the Nouveau kernel git tree
> back to v2.6.31.  Basically guessed at which commits were important, wrote
> a script to cherry pick each and every one, and spent an entire day
> reading commit logs, resolving conflicts, and figuring out which other
> non-drm commits I needed.  Sounds retarded, I know, but it was a pretty
> interesting way to get myself up to speed with the code base.  The
> resulting 2.6.31-nouveau kernel runs like a champ on all my hardware.
>
> Then I merged that into my clone of Jeremy''s xen/master which I
use with
> Xen 3.4.2.
>
> Since then, I''ve been periodically cherry picking all new commits
off the
> nouveau tree.  Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new
> libdrm, mesa, and xf86-video-nouveau all from their respective git trees
> as of yesterday.  (drm and xf86-video-nouveau are on their master
> branches, mesa is on the 7.8 branch)
>
> This all works great using xen/master bare metal.  It used to work fine on
> my old GeForce2 MX based systems in Xen.  Arvind''s patch made it
work on
> my nice new systems in Xen, but broke it on the old ones.  Everything
> still works fine bare metal.
>
>> Did you have to edit your xorg.conf file or
>> it ran just fine?
>
> Well, I had to create an xorg.conf that looks like this:
>
> Section "Device"
>  Identifier "foo"
>  Driver "nouveau"
> EndSection
>
> Otherwise it uses the ''nv'' driver...  and I
haven''t stumbled onto how to
> get nouveau to automatically get used (aside from uninstalling the nv
> driver).
>
>
>> Was this Fedora 13 or Fedora 12?
>
> This is all being done on a custom 32bit Linux distro that we use for our
> tightly configuration controlled system deliveries.  It was fedora based a
> looooooooong time ago (FC5), but is completely unrecognizable now.
>
>
>> Arvind explanation about the Nvidia driver pointed out that the NVidia
>> driver (drm/nouvue) can operate on different channels. Where channel 1
>> is the framebuffer, and the other are for well, KMS, and other
>> applications.
>>
>> I belive I was looking at the wrong section of the drivers (not the
>> drivers/video/gpu ones)- this certainly looks to be the issues the
>> Jeremy mentioned.
>>
>> Also I would suggest you load drm with the debug variable set to the
255
>> to get most of what his happening.
>
> I''ll try that.
>
>
>> Based on your strace, the last call is:
>> 4000)                          = 0x9324000
>> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38
>> ioctl(11, 0xc0106445, 0x930a908)        = 0
>> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
>> +++ killed by SIGKILL +++
>>
>> I cannot find what 0x45 is in the upstream Linux, so you must be using
a
>> different nouv* driver than that. The 0x44 is:
>>
>>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_AUTH),
>>
>> Which looks to be pretty harmless. I presume it is the next thing
(using
>> the address returned) that the X driver tries to do that makes it go
> boom.
>
I suspect that the ioctl is prior to a modeset operation. And the
mode-setting is ''booming''.
My kernel config has VGA console built-in fbcon as a module and I do a switch to
nouveaufb at runlevel 2. Also note that the default modeset parameter is -1 and
if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver initialisation
- which maybe the problem. Do you have modeset=1 as module parameter?

As to the implications of Thomas'' remark on the possibility of
placement
migration ''tween mmap and fault; and the over-loading of VM_IO
semantics;
(points 1 and 2), - that seems to be a problem to be resolved. VM_MIXEDMAP
would not be a problem if VM_IO semantics were consistent with Xen, I suspect.
> I''ve never used strace before... how do you map between the ioctl
> definitions and the hex addresses?
>
>
> ---
> Michael D Labriola
> Electric Boat
> mlabriol@gdeb.com
> 401-848-8871 (desk)
> 401-848-8513 (lab)
> 401-316-9844 (cell)
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM:
> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola
<mlabriol@gdeb.com>
wrote:
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on
03/16/2010
> > 01:21:35 PM:
> >
> >> > > > And my X log ends abruptly after this line:
> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1
> >> > > >
> >> > > > Any ideas?
> >> > > >
> >> > >
> >> > > Well, this is generally the symptom that someone is
confusing
mfns
> > and
> >> > > pfns, and therefore ends up incorrectly setting the
_PAGE_IO flag
in
> >
> >> > > some pte.  If you run it under strace, can you identify
which
> > mapping
> >> > > the fault is happening in?
> >> >
> >> > I''ve attached the output of ''strace -o
strace-Xorg Xorg''.  Figuring
> > out
> >> > which mapping the fault is happening in is a little over my
head,
I''m
> >> > afraid.  If you need different arguments to strace, let me
know and
> > I''ll
> >> > do it again.
> >>
> >> So just to be sure, you took the 2.6.32 (xen/next or
> >> xen/stable-2.6.32.x), copied the include and nouveu directory from
..?
> >> 2.6.33? and then ran this.
> >
> > I actually took a slightly more sadistic route than Arvind... ;-)  A 
while
> > back, I backported the important stuff from the Nouveau kernel git 
tree
> > back to v2.6.31.  Basically guessed at which commits were important, 
wrote
> > a script to cherry pick each and every one, and spent an entire day
> > reading commit logs, resolving conflicts, and figuring out which other
> > non-drm commits I needed.  Sounds retarded, I know, but it was a 
pretty
> > interesting way to get myself up to speed with the code base.  The
> > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware.
> >
> > Then I merged that into my clone of Jeremy''s xen/master which
I use
with
> > Xen 3.4.2.
> >
> > Since then, I''ve been periodically cherry picking all new
commits off
the
> > nouveau tree.  Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, 
new
> > libdrm, mesa, and xf86-video-nouveau all from their respective git 
trees
> > as of yesterday.  (drm and xf86-video-nouveau are on their master
> > branches, mesa is on the 7.8 branch)
> >
> > This all works great using xen/master bare metal.  It used to work 
fine on
> > my old GeForce2 MX based systems in Xen.  Arvind''s patch made
it work
on
> > my nice new systems in Xen, but broke it on the old ones.  Everything
> > still works fine bare metal.
> >
> >> Did you have to edit your xorg.conf file or
> >> it ran just fine?
> >
> > Well, I had to create an xorg.conf that looks like this:
> >
> > Section "Device"
> >  Identifier "foo"
> >  Driver "nouveau"
> > EndSection
> >
> > Otherwise it uses the ''nv'' driver...  and I
haven''t stumbled onto how
to
> > get nouveau to automatically get used (aside from uninstalling the nv
> > driver).
> >
> >
> >> Was this Fedora 13 or Fedora 12?
> >
> > This is all being done on a custom 32bit Linux distro that we use for 
our
> > tightly configuration controlled system deliveries.  It was fedora 
based a
> > looooooooong time ago (FC5), but is completely unrecognizable now.
> >
> >
> >> Arvind explanation about the Nvidia driver pointed out that the 
NVidia
> >> driver (drm/nouvue) can operate on different channels. Where
channel
1
> >> is the framebuffer, and the other are for well, KMS, and other
> >> applications.
> >>
> >> I belive I was looking at the wrong section of the drivers (not
the
> >> drivers/video/gpu ones)- this certainly looks to be the issues the
> >> Jeremy mentioned.
> >>
> >> Also I would suggest you load drm with the debug variable set to
the
255
> >> to get most of what his happening.
> >
> > I''ll try that.
> >
> >
> >> Based on your strace, the last call is:
> >> 4000)                          = 0x9324000
> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38
> >> ioctl(11, 0xc0106445, 0x930a908)        = 0
> >> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
> >> +++ killed by SIGKILL +++
> >>
> >> I cannot find what 0x45 is in the upstream Linux, so you must be 
using a
> >> different nouv* driver than that. The 0x44 is:
> >>
> >>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_AUTH),
> >>
> >> Which looks to be pretty harmless. I presume it is the next thing 
(using
> >> the address returned) that the X driver tries to do that makes it
go
> > boom.
> >
> I suspect that the ioctl is prior to a modeset operation. And the
> mode-setting is ''booming''.
> My kernel config has VGA console built-in fbcon as a module and I do
> a switch to
> nouveaufb at runlevel 2. Also note that the default modeset 
> parameter is -1 and
> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver 
> initialisation
> - which maybe the problem. Do you have modeset=1 as module parameter?
I wasn''t setting any module params for nouveau.  Adding
''options nouveau
modeset=1'' to modprobe.conf didn''t seem to make any
difference.

I''ve got the following in my .config:

CONFIG_VGA_CONSOLE=y
CONFIG_FB=y
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_NVIDIA_BACKLIGHT=y

Gonna go comb through the config options and see if anything else looks 
relevant.

How do you force the nouveaufb switch at runlevel 2?  My screen obviously 
switches into KMS mode while udev is starting up.

-Mike

---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola <mlabriol@gdeb.com>
wrote:
> xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM:
>
>> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola
<mlabriol@gdeb.com>
> wrote:
>> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on
03/16/2010
>> > 01:21:35 PM:
>> >
>> >> > > > And my X log ends abruptly after this line:
>> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1
>> >> > > >
>> >> > > > Any ideas?
>> >> > > >
>> >> > >
>> >> > > Well, this is generally the symptom that someone is
confusing
> mfns
>> > and
>> >> > > pfns, and therefore ends up incorrectly setting the
_PAGE_IO flag
> in
>> >
>> >> > > some pte.  If you run it under strace, can you
identify which
>> > mapping
>> >> > > the fault is happening in?
>> >> >
>> >> > I''ve attached the output of ''strace -o
strace-Xorg Xorg''.  Figuring
>> > out
>> >> > which mapping the fault is happening in is a little over
my head,
> I''m
>> >> > afraid.  If you need different arguments to strace, let
me know and
>> > I''ll
>> >> > do it again.
>> >>
>> >> So just to be sure, you took the 2.6.32 (xen/next or
>> >> xen/stable-2.6.32.x), copied the include and nouveu directory
from
> ..?
>> >> 2.6.33? and then ran this.
>> >
>> > I actually took a slightly more sadistic route than Arvind... ;-)
 A
> while
>> > back, I backported the important stuff from the Nouveau kernel git
> tree
>> > back to v2.6.31.  Basically guessed at which commits were
important,
> wrote
>> > a script to cherry pick each and every one, and spent an entire
day
>> > reading commit logs, resolving conflicts, and figuring out which
other
>> > non-drm commits I needed.  Sounds retarded, I know, but it was a
> pretty
>> > interesting way to get myself up to speed with the code base.  The
>> > resulting 2.6.31-nouveau kernel runs like a champ on all my
hardware.
>> >
>> > Then I merged that into my clone of Jeremy''s xen/master
which I use
> with
>> > Xen 3.4.2.
>> >
>> > Since then, I''ve been periodically cherry picking all new
commits off
> the
>> > nouveau tree.  Also had to rebuild Xorg 7.5 to use xorg-server
1.7.5,
> new
>> > libdrm, mesa, and xf86-video-nouveau all from their respective git
> trees
>> > as of yesterday.  (drm and xf86-video-nouveau are on their master
>> > branches, mesa is on the 7.8 branch)
>> >
>> > This all works great using xen/master bare metal.  It used to work
> fine on
>> > my old GeForce2 MX based systems in Xen.  Arvind''s patch
made it work
> on
>> > my nice new systems in Xen, but broke it on the old ones.
 Everything
>> > still works fine bare metal.
>> >
>> >> Did you have to edit your xorg.conf file or
>> >> it ran just fine?
>> >
>> > Well, I had to create an xorg.conf that looks like this:
>> >
>> > Section "Device"
>> >  Identifier "foo"
>> >  Driver "nouveau"
>> > EndSection
>> >
>> > Otherwise it uses the ''nv'' driver...  and I
haven''t stumbled onto how
> to
>> > get nouveau to automatically get used (aside from uninstalling the
nv
>> > driver).
>> >
>> >
>> >> Was this Fedora 13 or Fedora 12?
>> >
>> > This is all being done on a custom 32bit Linux distro that we use
for
> our
>> > tightly configuration controlled system deliveries.  It was fedora
> based a
>> > looooooooong time ago (FC5), but is completely unrecognizable now.
>> >
>> >
>> >> Arvind explanation about the Nvidia driver pointed out that
the
> NVidia
>> >> driver (drm/nouvue) can operate on different channels. Where
channel
> 1
>> >> is the framebuffer, and the other are for well, KMS, and other
>> >> applications.
>> >>
>> >> I belive I was looking at the wrong section of the drivers
(not the
>> >> drivers/video/gpu ones)- this certainly looks to be the issues
the
>> >> Jeremy mentioned.
>> >>
>> >> Also I would suggest you load drm with the debug variable set
to the
> 255
>> >> to get most of what his happening.
>> >
>> > I''ll try that.
>> >
>> >
>> >> Based on your strace, the last call is:
>> >> 4000)                          = 0x9324000
>> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38)
= 38
>> >> ioctl(11, 0xc0106445, 0x930a908)        = 0
>> >> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
>> >> +++ killed by SIGKILL +++
>> >>
>> >> I cannot find what 0x45 is in the upstream Linux, so you must
be
> using a
>> >> different nouv* driver than that. The 0x44 is:
>> >>
>> >>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
> DRM_AUTH),
>> >>
>> >> Which looks to be pretty harmless. I presume it is the next
thing
> (using
>> >> the address returned) that the X driver tries to do that makes
it go
>> > boom.
>> >
>> I suspect that the ioctl is prior to a modeset operation. And the
>> mode-setting is ''booming''.
>> My kernel config has VGA console built-in fbcon as a module and I do
>> a switch to
>> nouveaufb at runlevel 2. Also note that the default modeset
>> parameter is -1 and
>> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver
>> initialisation
>> - which maybe the problem. Do you have modeset=1 as module parameter?
>
> I wasn''t setting any module params for nouveau.  Adding
''options nouveau
> modeset=1'' to modprobe.conf didn''t seem to make any
difference.
>
> I''ve got the following in my .config:
>
> CONFIG_VGA_CONSOLE=y
> CONFIG_FB=y
> CONFIG_FB_VGA16=m
> CONFIG_FB_VESA=y
> CONFIG_FB_EFI=y
> CONFIG_FB_NVIDIA=m
> CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_NVIDIA_BACKLIGHT=y
>
 - EMBEDDED  - this will enable VGA_CONSOLE selection. Set sub-menu
choices as needed
 - VGA_CONSOLE builtin
 - FB as module
 - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau
 * Foll. required to avoid cfb_copyarea, cfb_fillrectangle,
cfb_imageblit linking problems with
    out-of-tree nouveau builds
 - FB_VGA16 as module - supported by all nVidia cards.
   or
 - FB_NVIDIA as module - only works for older cards.

For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers
- that would enable
the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu tree.

For in-tree builds, if nouveau is NOT in the initrd-image, system will
boot on vga console
>
> How do you force the nouveaufb switch at runlevel 2?  My screen obviously
> switches into KMS mode while udev is starting up.
You can switch to the accelerated framebuffer console by
modprobe nouveau
modprobe fbcon
fbcon will take-over console from the built-in VGA. See
Documenation/fb/fbcon.txt

If multiple fb loaded, echo 0/1 to /sys/devices/virtual/vtconsole/vtconX/bind
to unbind/bind fbs and switch - if it is possible (or leave you
without a console)

If the old nvidiafb is loaded, nouveau cannot install (and vice-versa)

BTW, are you sure the older cards support accelerated modes? Channel 1 is
the console channel and unaccelerated X uses only that. AIGLX will
start up channel 2,
and if X is gallium-enabled, channel 3 will start. libGL apps will start
new channels (upto what the card supports - which varies). I assume the patch
does NOT affect unaccelerated X on the older cards?

Whats funny is that, in all my traces, X never opens channel 1 - it is already
opened by the console and all X has to do (using ioctls) is to do is a
kernel-modeset,
if native console and X are in different modes (I''ve not been able to
get the native
console to a lower resolution (got very comfortable with the higher
res. meanwhile!)).
Xorg used to hang saying ''Opened Channel 2'' and not 1.

Late switching will maybe enable you to get traces

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM:
> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola
<mlabriol@gdeb.com>
wrote:
> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08 AM:
> >
> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola 
<mlabriol@gdeb.com>
> > wrote:
> >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote on
03/16/2010
> >> > 01:21:35 PM:
> >> >
> >> >> > > > And my X log ends abruptly after this
line:
> >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1
> >> >> > > >
> >> >> > > > Any ideas?
> >> >> > > >
> >> >> > >
> >> >> > > Well, this is generally the symptom that
someone is confusing
> > mfns
> >> > and
> >> >> > > pfns, and therefore ends up incorrectly setting
the _PAGE_IO
flag
> > in
> >> >
> >> >> > > some pte.  If you run it under strace, can you
identify which
> >> > mapping
> >> >> > > the fault is happening in?
> >> >> >
> >> >> > I''ve attached the output of
''strace -o strace-Xorg Xorg''.
 Figuring
> >> > out
> >> >> > which mapping the fault is happening in is a little
over my
head,
> > I''m
> >> >> > afraid.  If you need different arguments to strace,
let me know
and
> >> > I''ll
> >> >> > do it again.
> >> >>
> >> >> So just to be sure, you took the 2.6.32 (xen/next or
> >> >> xen/stable-2.6.32.x), copied the include and nouveu
directory from
> > ..?
> >> >> 2.6.33? and then ran this.
> >> >
> >> > I actually took a slightly more sadistic route than Arvind...
;-)
 A
> > while
> >> > back, I backported the important stuff from the Nouveau
kernel git
> > tree
> >> > back to v2.6.31.  Basically guessed at which commits were 
important,
> > wrote
> >> > a script to cherry pick each and every one, and spent an
entire day
> >> > reading commit logs, resolving conflicts, and figuring out
which
other
> >> > non-drm commits I needed.  Sounds retarded, I know, but it
was a
> > pretty
> >> > interesting way to get myself up to speed with the code base.
The
> >> > resulting 2.6.31-nouveau kernel runs like a champ on all my 
hardware.
> >> >
> >> > Then I merged that into my clone of Jeremy''s
xen/master which I use
> > with
> >> > Xen 3.4.2.
> >> >
> >> > Since then, I''ve been periodically cherry picking
all new commits
off
> > the
> >> > nouveau tree.  Also had to rebuild Xorg 7.5 to use
xorg-server
1.7.5,
> > new
> >> > libdrm, mesa, and xf86-video-nouveau all from their
respective git
> > trees
> >> > as of yesterday.  (drm and xf86-video-nouveau are on their
master
> >> > branches, mesa is on the 7.8 branch)
> >> >
> >> > This all works great using xen/master bare metal.  It used to
work
> > fine on
> >> > my old GeForce2 MX based systems in Xen.  Arvind''s
patch made it
work
> > on
> >> > my nice new systems in Xen, but broke it on the old ones. 
 Everything
> >> > still works fine bare metal.
> >> >
> >> >> Did you have to edit your xorg.conf file or
> >> >> it ran just fine?
> >> >
> >> > Well, I had to create an xorg.conf that looks like this:
> >> >
> >> > Section "Device"
> >> >  Identifier "foo"
> >> >  Driver "nouveau"
> >> > EndSection
> >> >
> >> > Otherwise it uses the ''nv'' driver...  and I
haven''t stumbled onto
how
> > to
> >> > get nouveau to automatically get used (aside from
uninstalling the
nv
> >> > driver).
> >> >
> >> >
> >> >> Was this Fedora 13 or Fedora 12?
> >> >
> >> > This is all being done on a custom 32bit Linux distro that we
use
for
> > our
> >> > tightly configuration controlled system deliveries.  It was
fedora
> > based a
> >> > looooooooong time ago (FC5), but is completely unrecognizable
now.
> >> >
> >> >
> >> >> Arvind explanation about the Nvidia driver pointed out
that the
> > NVidia
> >> >> driver (drm/nouvue) can operate on different channels.
Where
channel
> > 1
> >> >> is the framebuffer, and the other are for well, KMS, and
other
> >> >> applications.
> >> >>
> >> >> I belive I was looking at the wrong section of the
drivers (not
the
> >> >> drivers/video/gpu ones)- this certainly looks to be the
issues the
> >> >> Jeremy mentioned.
> >> >>
> >> >> Also I would suggest you load drm with the debug variable
set to
the
> > 255
> >> >> to get most of what his happening.
> >> >
> >> > I''ll try that.
> >> >
> >> >
> >> >> Based on your strace, the last call is:
> >> >> 4000)                          = 0x9324000
> >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"...,
38) = 38
> >> >> ioctl(11, 0xc0106445, 0x930a908)        = 0
> >> >> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
> >> >> +++ killed by SIGKILL +++
> >> >>
> >> >> I cannot find what 0x45 is in the upstream Linux, so you
must be
> > using a
> >> >> different nouv* driver than that. The 0x44 is:
> >> >>
> >> >>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO,
nouveau_gem_ioctl_info,
> > DRM_AUTH),
> >> >>
> >> >> Which looks to be pretty harmless. I presume it is the
next thing
> > (using
> >> >> the address returned) that the X driver tries to do that
makes it
go
> >> > boom.
> >> >
> >> I suspect that the ioctl is prior to a modeset operation. And the
> >> mode-setting is ''booming''.
> >> My kernel config has VGA console built-in fbcon as a module and I
do
> >> a switch to
> >> nouveaufb at runlevel 2. Also note that the default modeset
> >> parameter is -1 and
> >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver
> >> initialisation
> >> - which maybe the problem. Do you have modeset=1 as module
parameter?
> >
> > I wasn''t setting any module params for nouveau.  Adding
''options
nouveau
> > modeset=1'' to modprobe.conf didn''t seem to make any
difference.
> >
> > I''ve got the following in my .config:
> >
> > CONFIG_VGA_CONSOLE=y
> > CONFIG_FB=y
> > CONFIG_FB_VGA16=m
> > CONFIG_FB_VESA=y
> > CONFIG_FB_EFI=y
> > CONFIG_FB_NVIDIA=m
> > CONFIG_FB_NVIDIA_I2C=y
> > CONFIG_FB_NVIDIA_BACKLIGHT=y
> >
>  - EMBEDDED  - this will enable VGA_CONSOLE selection. Set sub-menu
> choices as needed
>  - VGA_CONSOLE builtin
>  - FB as module
>  - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau
>  * Foll. required to avoid cfb_copyarea, cfb_fillrectangle,
> cfb_imageblit linking problems with
>     out-of-tree nouveau builds
>  - FB_VGA16 as module - supported by all nVidia cards.
>    or
>  - FB_NVIDIA as module - only works for older cards.
> 
> For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers
> - that would enable
> the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu 
tree.
> 
> For in-tree builds, if nouveau is NOT in the initrd-image, system will
> boot on vga console
> >
> > How do you force the nouveaufb switch at runlevel 2?  My screen 
obviously
> > switches into KMS mode while udev is starting up.
> You can switch to the accelerated framebuffer console by
> modprobe nouveau
> modprobe fbcon
> fbcon will take-over console from the built-in VGA. See
> Documenation/fb/fbcon.txt
Ok, thanks.  Now I''ve got everything compiled as modules and can load
them
post-boot to switch to the nouveau framebuffer console.  That actually 
didn''t change the X behavior at all, though.  I still get the exact
same
"X: Corrupted page table" messages in dmesg and my Xorg.log is just
ending
with "NOUVEAU(0): Opened GPU channel 1".

> If multiple fb loaded, echo 0/1 to 
/sys/devices/virtual/vtconsole/vtconX/bind
> to unbind/bind fbs and switch - if it is possible (or leave you
> without a console)
> 
> If the old nvidiafb is loaded, nouveau cannot install (and vice-versa)
Well, everything seems to load just fine.  I get a nice teeny font and 
dmesg messages saying I''m using nouveaufb.

> BTW, are you sure the older cards support accelerated modes? Channel 1 
is
> the console channel and unaccelerated X uses only that. AIGLX will
> start up channel 2,
> and if X is gallium-enabled, channel 3 will start. libGL apps will start
> new channels (upto what the card supports - which varies). I assume the 
patch
> does NOT affect unaccelerated X on the older cards?
Which accelerated modes are you refering to?  My understanding was that 
the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau 
driver, and gallium''s swrast_dri stuff (via AIGLX), but not
gallium''s new
dri_nouveau stuff.

> Whats funny is that, in all my traces, X never opens channel 1 - it is 
already
> opened by the console and all X has to do (using ioctls) is to do is a
> kernel-modeset,
> if native console and X are in different modes (I''ve not been able
to
> get the native
> console to a lower resolution (got very comfortable with the higher
> res. meanwhile!)).
> Xorg used to hang saying ''Opened Channel 2'' and not 1.
Now that''s strange.  Every single one of my boxes says Opened Channel
1,
with now reference to channel 2 at all.

> Late switching will maybe enable you to get traces
After switching post-boot, Xorg.log is still just ending.  I get errors in 
dmesg, but nothing at all in Xorg.log.  Same exact behavior as before.



---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola <mlabriol@gdeb.com>
wrote:
> xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM:
>
>> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola
<mlabriol@gdeb.com>
> wrote:
>> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010 02:09:08
AM:
>> >
>> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola
> <mlabriol@gdeb.com>
>> > wrote:
>> >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote on 03/16/2010
>> >> > 01:21:35 PM:
>> >> >
>> >> >> > > > And my X log ends abruptly after this
line:
>> >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1
>> >> >> > > >
>> >> >> > > > Any ideas?
>> >> >> > > >
>> >> >> > >
>> >> >> > > Well, this is generally the symptom that
someone is confusing
>> > mfns
>> >> > and
>> >> >> > > pfns, and therefore ends up incorrectly
setting the _PAGE_IO
> flag
>> > in
>> >> >
>> >> >> > > some pte.  If you run it under strace, can
you identify which
>> >> > mapping
>> >> >> > > the fault is happening in?
>> >> >> >
>> >> >> > I''ve attached the output of
''strace -o strace-Xorg Xorg''.
>  Figuring
>> >> > out
>> >> >> > which mapping the fault is happening in is a
little over my
> head,
>> > I''m
>> >> >> > afraid.  If you need different arguments to
strace, let me know
> and
>> >> > I''ll
>> >> >> > do it again.
>> >> >>
>> >> >> So just to be sure, you took the 2.6.32 (xen/next or
>> >> >> xen/stable-2.6.32.x), copied the include and nouveu
directory from
>> > ..?
>> >> >> 2.6.33? and then ran this.
>> >> >
>> >> > I actually took a slightly more sadistic route than
Arvind... ;-)
>  A
>> > while
>> >> > back, I backported the important stuff from the Nouveau
kernel git
>> > tree
>> >> > back to v2.6.31.  Basically guessed at which commits were
> important,
>> > wrote
>> >> > a script to cherry pick each and every one, and spent an
entire day
>> >> > reading commit logs, resolving conflicts, and figuring
out which
> other
>> >> > non-drm commits I needed.  Sounds retarded, I know, but
it was a
>> > pretty
>> >> > interesting way to get myself up to speed with the code
base.  The
>> >> > resulting 2.6.31-nouveau kernel runs like a champ on all
my
> hardware.
>> >> >
>> >> > Then I merged that into my clone of Jeremy''s
xen/master which I use
>> > with
>> >> > Xen 3.4.2.
>> >> >
>> >> > Since then, I''ve been periodically cherry
picking all new commits
> off
>> > the
>> >> > nouveau tree.  Also had to rebuild Xorg 7.5 to use
xorg-server
> 1.7.5,
>> > new
>> >> > libdrm, mesa, and xf86-video-nouveau all from their
respective git
>> > trees
>> >> > as of yesterday.  (drm and xf86-video-nouveau are on
their master
>> >> > branches, mesa is on the 7.8 branch)
>> >> >
>> >> > This all works great using xen/master bare metal.  It
used to work
>> > fine on
>> >> > my old GeForce2 MX based systems in Xen.
 Arvind''s patch made it
> work
>> > on
>> >> > my nice new systems in Xen, but broke it on the old ones.
>  Everything
>> >> > still works fine bare metal.
>> >> >
>> >> >> Did you have to edit your xorg.conf file or
>> >> >> it ran just fine?
>> >> >
>> >> > Well, I had to create an xorg.conf that looks like this:
>> >> >
>> >> > Section "Device"
>> >> >  Identifier "foo"
>> >> >  Driver "nouveau"
>> >> > EndSection
>> >> >
>> >> > Otherwise it uses the ''nv'' driver...
 and I haven''t stumbled onto
> how
>> > to
>> >> > get nouveau to automatically get used (aside from
uninstalling the
> nv
>> >> > driver).
>> >> >
>> >> >
>> >> >> Was this Fedora 13 or Fedora 12?
>> >> >
>> >> > This is all being done on a custom 32bit Linux distro
that we use
> for
>> > our
>> >> > tightly configuration controlled system deliveries.  It
was fedora
>> > based a
>> >> > looooooooong time ago (FC5), but is completely
unrecognizable now.
>> >> >
>> >> >
>> >> >> Arvind explanation about the Nvidia driver pointed
out that the
>> > NVidia
>> >> >> driver (drm/nouvue) can operate on different
channels. Where
> channel
>> > 1
>> >> >> is the framebuffer, and the other are for well, KMS,
and other
>> >> >> applications.
>> >> >>
>> >> >> I belive I was looking at the wrong section of the
drivers (not
> the
>> >> >> drivers/video/gpu ones)- this certainly looks to be
the issues the
>> >> >> Jeremy mentioned.
>> >> >>
>> >> >> Also I would suggest you load drm with the debug
variable set to
> the
>> > 255
>> >> >> to get most of what his happening.
>> >> >
>> >> > I''ll try that.
>> >> >
>> >> >
>> >> >> Based on your strace, the last call is:
>> >> >> 4000)                          = 0x9324000
>> >> >> write(0, "(II) NOUVEAU(0): Opened GPU
chan"..., 38) = 38
>> >> >> ioctl(11, 0xc0106445, 0x930a908)        = 0
>> >> >> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
>> >> >> +++ killed by SIGKILL +++
>> >> >>
>> >> >> I cannot find what 0x45 is in the upstream Linux, so
you must be
>> > using a
>> >> >> different nouv* driver than that. The 0x44 is:
>> >> >>
>> >> >>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO,
nouveau_gem_ioctl_info,
>> > DRM_AUTH),
>> >> >>
>> >> >> Which looks to be pretty harmless. I presume it is
the next thing
>> > (using
>> >> >> the address returned) that the X driver tries to do
that makes it
> go
>> >> > boom.
>> >> >
>> >> I suspect that the ioctl is prior to a modeset operation. And
the
>> >> mode-setting is ''booming''.
>> >> My kernel config has VGA console built-in fbcon as a module
and I do
>> >> a switch to
>> >> nouveaufb at runlevel 2. Also note that the default modeset
>> >> parameter is -1 and
>> >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the
driver
>> >> initialisation
>> >> - which maybe the problem. Do you have modeset=1 as module
parameter?
>> >
>> > I wasn''t setting any module params for nouveau.  Adding
''options
> nouveau
>> > modeset=1'' to modprobe.conf didn''t seem to make
any difference.
>> >
>> > I''ve got the following in my .config:
>> >
>> > CONFIG_VGA_CONSOLE=y
>> > CONFIG_FB=y
>> > CONFIG_FB_VGA16=m
>> > CONFIG_FB_VESA=y
>> > CONFIG_FB_EFI=y
>> > CONFIG_FB_NVIDIA=m
>> > CONFIG_FB_NVIDIA_I2C=y
>> > CONFIG_FB_NVIDIA_BACKLIGHT=y
>> >
>>  - EMBEDDED  - this will enable VGA_CONSOLE selection. Set sub-menu
>> choices as needed
>>  - VGA_CONSOLE builtin
>>  - FB as module
>>  - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau
>>  * Foll. required to avoid cfb_copyarea, cfb_fillrectangle,
>> cfb_imageblit linking problems with
>>     out-of-tree nouveau builds
>>  - FB_VGA16 as module - supported by all nVidia cards.
>>    or
>>  - FB_NVIDIA as module - only works for older cards.
>>
>> For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers
>> - that would enable
>> the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu
> tree.
>>
>> For in-tree builds, if nouveau is NOT in the initrd-image, system will
>> boot on vga console
>> >
>> > How do you force the nouveaufb switch at runlevel 2?  My screen
> obviously
>> > switches into KMS mode while udev is starting up.
>> You can switch to the accelerated framebuffer console by
>> modprobe nouveau
>> modprobe fbcon
>> fbcon will take-over console from the built-in VGA. See
>> Documenation/fb/fbcon.txt
>
> Ok, thanks.  Now I''ve got everything compiled as modules and can
load them
> post-boot to switch to the nouveau framebuffer console.  That actually
> didn''t change the X behavior at all, though.  I still get the
exact same
> "X: Corrupted page table" messages in dmesg and my Xorg.log is
just ending
> with "NOUVEAU(0): Opened GPU channel 1".
This is strange - channel 1 is the console channel. This appears in dmesg on
nouveaufb initialisation before EDID probe to find connected outputs.
Start X manually to avoid confusion of logs.

Have attached ttm_xen.patch which updates vm_page_prot after changing flags.
This is not done in the mainline drm-tree. But in the xen (old)
drm-tree this is done in
BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both,
along with the conditional VM_IO in bo_mmap. And the second vm_page_prot
update is for fbdev_mmap which corresponds to channel 1. Cross fingers and try!
> If the old nvidiafb is loaded, nouveau cannot install (and vice-versa)
>
> Well, everything seems to load just fine.  I get a nice teeny font and
> dmesg messages saying I''m using nouveaufb.
You should have got it earlier too - didn''t you?
>> does NOT affect unaccelerated X on the older cards?
>
> Which accelerated modes are you refering to?  My understanding was that
> the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau
> driver, and gallium''s swrast_dri stuff (via AIGLX), but not
gallium''s new
> dri_nouveau stuff.
Right. But gallium''s swrast_dri AND dri_nouveau are still
''unsupported'',
to be tried at own risk. nouveau_dri was working enough to run fgfs with
mesa-7.7, but now with mesa-7.9, glxgears works not fgfs - segfaults in
libdrm_nouveau.
>> Xorg used to hang saying ''Opened Channel 2'' and not
1.
>
> Now that''s strange.  Every single one of my boxes says Opened
Channel 1,
> with now reference to channel 2 at all.
Channel 1 in dmesg/syslog;  Xorg.log snippet:
(II) LoadModule: "shadowfb"
(II) Loading /usr/lib/xorg/modules/libshadowfb.so
(II) Module shadowfb: vendor="X.Org Foundation"
    compiled for 1.7.5, module version = 1.0.0
    ABI class: X.Org ANSI C Emulation, version 0.4
(--) Depth 24 pixmap format is 32 bpp
(II) NOUVEAU(0): Opened GPU channel 2  <initial hang point>
(II) NOUVEAU(0): [DRI2] Setup complete    <after patch>
(II) NOUVEAU(0): GART: 512MiB available
(II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen
(==) NOUVEAU(0): Backing store disabled
(==) NOUVEAU(0): Silken mouse enabled
(II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
(II) NOUVEAU(0): [XvMC] Extension initialized.


Try with
Option "ShadowFB"  "true"
in Device section of xorg.conf (turns off acceleration) to check. The option
also sets NoAccel on and X should use the FB device

So the cards that don''t work are AGP cards?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM:
> On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola
<mlabriol@gdeb.com>
wrote:
> > xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54 AM:
> >
> >> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola 
<mlabriol@gdeb.com>
> > wrote:
> >> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010
02:09:08
AM:
> >> >
> >> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola
> > <mlabriol@gdeb.com>
> >> > wrote:
> >> >> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote on
03/16/2010
> >> >> > 01:21:35 PM:
> >> >> >
> >> >> >> > > > And my X log ends abruptly after
this line:
> >> >> >> > > > (II) NOUVEAU(0): Opened GPU
Channel 1
> >> >> >> > > >
> >> >> >> > > > Any ideas?
> >> >> >> > > >
> >> >> >> > >
> >> >> >> > > Well, this is generally the symptom
that someone is
confusing
> >> > mfns
> >> >> > and
> >> >> >> > > pfns, and therefore ends up
incorrectly setting the
_PAGE_IO
> > flag
> >> > in
> >> >> >
> >> >> >> > > some pte.  If you run it under strace,
can you identify
which
> >> >> > mapping
> >> >> >> > > the fault is happening in?
> >> >> >> >
> >> >> >> > I''ve attached the output of
''strace -o strace-Xorg Xorg''.
> >  Figuring
> >> >> > out
> >> >> >> > which mapping the fault is happening in is
a little over my
> > head,
> >> > I''m
> >> >> >> > afraid.  If you need different arguments to
strace, let me
know
> > and
> >> >> > I''ll
> >> >> >> > do it again.
> >> >> >>
> >> >> >> So just to be sure, you took the 2.6.32
(xen/next or
> >> >> >> xen/stable-2.6.32.x), copied the include and
nouveu directory
from
> >> > ..?
> >> >> >> 2.6.33? and then ran this.
> >> >> >
> >> >> > I actually took a slightly more sadistic route than
Arvind...
;-)
> >  A
> >> > while
> >> >> > back, I backported the important stuff from the
Nouveau kernel
git
> >> > tree
> >> >> > back to v2.6.31.  Basically guessed at which commits
were
> > important,
> >> > wrote
> >> >> > a script to cherry pick each and every one, and
spent an entire
day
> >> >> > reading commit logs, resolving conflicts, and
figuring out which
> > other
> >> >> > non-drm commits I needed.  Sounds retarded, I know,
but it was a
> >> > pretty
> >> >> > interesting way to get myself up to speed with the
code base.
 The
> >> >> > resulting 2.6.31-nouveau kernel runs like a champ on
all my
> > hardware.
> >> >> >
> >> >> > Then I merged that into my clone of
Jeremy''s xen/master which I
use
> >> > with
> >> >> > Xen 3.4.2.
> >> >> >
> >> >> > Since then, I''ve been periodically cherry
picking all new
commits
> > off
> >> > the
> >> >> > nouveau tree.  Also had to rebuild Xorg 7.5 to use
xorg-server
> > 1.7.5,
> >> > new
> >> >> > libdrm, mesa, and xf86-video-nouveau all from their
respective
git
> >> > trees
> >> >> > as of yesterday.  (drm and xf86-video-nouveau are on
their
master
> >> >> > branches, mesa is on the 7.8 branch)
> >> >> >
> >> >> > This all works great using xen/master bare metal. 
It used to
work
> >> > fine on
> >> >> > my old GeForce2 MX based systems in Xen. 
Arvind''s patch made it
> > work
> >> > on
> >> >> > my nice new systems in Xen, but broke it on the old
ones.
> >  Everything
> >> >> > still works fine bare metal.
> >> >> >
> >> >> >> Did you have to edit your xorg.conf file or
> >> >> >> it ran just fine?
> >> >> >
> >> >> > Well, I had to create an xorg.conf that looks like
this:
> >> >> >
> >> >> > Section "Device"
> >> >> >  Identifier "foo"
> >> >> >  Driver "nouveau"
> >> >> > EndSection
> >> >> >
> >> >> > Otherwise it uses the ''nv''
driver...  and I haven''t stumbled
onto
> > how
> >> > to
> >> >> > get nouveau to automatically get used (aside from
uninstalling
the
> > nv
> >> >> > driver).
> >> >> >
> >> >> >
> >> >> >> Was this Fedora 13 or Fedora 12?
> >> >> >
> >> >> > This is all being done on a custom 32bit Linux
distro that we
use
> > for
> >> > our
> >> >> > tightly configuration controlled system deliveries. 
It was
fedora
> >> > based a
> >> >> > looooooooong time ago (FC5), but is completely
unrecognizable
now.
> >> >> >
> >> >> >
> >> >> >> Arvind explanation about the Nvidia driver
pointed out that the
> >> > NVidia
> >> >> >> driver (drm/nouvue) can operate on different
channels. Where
> > channel
> >> > 1
> >> >> >> is the framebuffer, and the other are for well,
KMS, and other
> >> >> >> applications.
> >> >> >>
> >> >> >> I belive I was looking at the wrong section of
the drivers (not
> > the
> >> >> >> drivers/video/gpu ones)- this certainly looks to
be the issues
the
> >> >> >> Jeremy mentioned.
> >> >> >>
> >> >> >> Also I would suggest you load drm with the debug
variable set
to
> > the
> >> > 255
> >> >> >> to get most of what his happening.
> >> >> >
> >> >> > I''ll try that.
> >> >> >
> >> >> >
> >> >> >> Based on your strace, the last call is:
> >> >> >> 4000)                          = 0x9324000
> >> >> >> write(0, "(II) NOUVEAU(0): Opened GPU
chan"..., 38) = 38
> >> >> >> ioctl(11, 0xc0106445, 0x930a908)        = 0
> >> >> >> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
> >> >> >> +++ killed by SIGKILL +++
> >> >> >>
> >> >> >> I cannot find what 0x45 is in the upstream
Linux, so you must
be
> >> > using a
> >> >> >> different nouv* driver than that. The 0x44 is:
> >> >> >>
> >> >> >>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO,
nouveau_gem_ioctl_info,
> >> > DRM_AUTH),
> >> >> >>
> >> >> >> Which looks to be pretty harmless. I presume it
is the next
thing
> >> > (using
> >> >> >> the address returned) that the X driver tries to
do that makes
it
> > go
> >> >> > boom.
> >> >> >
> >> >> I suspect that the ioctl is prior to a modeset operation.
And the
> >> >> mode-setting is ''booming''.
> >> >> My kernel config has VGA console built-in fbcon as a
module and I
do
> >> >> a switch to
> >> >> nouveaufb at runlevel 2. Also note that the default
modeset
> >> >> parameter is -1 and
> >> >> if VGA-CONSOLE is enabled, then modeset is set to 0 in
the driver
> >> >> initialisation
> >> >> - which maybe the problem. Do you have modeset=1 as
module
parameter?
> >> >
> >> > I wasn''t setting any module params for nouveau. 
Adding ''options
> > nouveau
> >> > modeset=1'' to modprobe.conf didn''t seem to
make any difference.
> >> >
> >> > I''ve got the following in my .config:
> >> >
> >> > CONFIG_VGA_CONSOLE=y
> >> > CONFIG_FB=y
> >> > CONFIG_FB_VGA16=m
> >> > CONFIG_FB_VESA=y
> >> > CONFIG_FB_EFI=y
> >> > CONFIG_FB_NVIDIA=m
> >> > CONFIG_FB_NVIDIA_I2C=y
> >> > CONFIG_FB_NVIDIA_BACKLIGHT=y
> >> >
> >>  - EMBEDDED  - this will enable VGA_CONSOLE selection. Set
sub-menu
> >> choices as needed
> >>  - VGA_CONSOLE builtin
> >>  - FB as module
> >>  - FRAMEBUFFER_CONSOLE as a module. Enables late loading of
nouveau
> >>  * Foll. required to avoid cfb_copyarea, cfb_fillrectangle,
> >> cfb_imageblit linking problems with
> >>     out-of-tree nouveau builds
> >>  - FB_VGA16 as module - supported by all nVidia cards.
> >>    or
> >>  - FB_NVIDIA as module - only works for older cards.
> >>
> >> For out-of-tree nouveau builds, DO NOT select ANY accelerated
drivers
> >> - that would enable
> >> the old in-tree DRM. New TTM / DRM modulesare in the new
driver/gpu
> > tree.
> >>
> >> For in-tree builds, if nouveau is NOT in the initrd-image, system 
will
> >> boot on vga console
> >> >
> >> > How do you force the nouveaufb switch at runlevel 2?  My
screen
> > obviously
> >> > switches into KMS mode while udev is starting up.
> >> You can switch to the accelerated framebuffer console by
> >> modprobe nouveau
> >> modprobe fbcon
> >> fbcon will take-over console from the built-in VGA. See
> >> Documenation/fb/fbcon.txt
> >
> > Ok, thanks.  Now I''ve got everything compiled as modules and
can load
them
> > post-boot to switch to the nouveau framebuffer console.  That actually
> > didn''t change the X behavior at all, though.  I still get the
exact
same
> > "X: Corrupted page table" messages in dmesg and my Xorg.log
is just
ending
> > with "NOUVEAU(0): Opened GPU channel 1".
> This is strange - channel 1 is the console channel. This appears in 
dmesg on
> nouveaufb initialisation before EDID probe to find connected outputs.
> Start X manually to avoid confusion of logs.
I''ve been testing this by booting to runlevel 3 and starting gdm. 
I''ll
double check that I get the same results running Xorg by hand, although 
gdm does something to give me my console back after the X crash...

> Have attached ttm_xen.patch which updates vm_page_prot after changing 
flags.
> This is not done in the mainline drm-tree. But in the xen (old)
> drm-tree this is done in
> BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both,
> along with the conditional VM_IO in bo_mmap. And the second vm_page_prot
> update is for fbdev_mmap which corresponds to channel 1. Cross 
> fingers and try!
I''ll go try that.

> > If the old nvidiafb is loaded, nouveau cannot install (and vice-versa)
> >
> > Well, everything seems to load just fine.  I get a nice teeny font and
> > dmesg messages saying I''m using nouveaufb.
> You should have got it earlier too - didn''t you?
Yeah, I had that before.

> >> does NOT affect unaccelerated X on the older cards?
> >
> > Which accelerated modes are you refering to?  My understanding was 
that
> > the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau
> > driver, and gallium''s swrast_dri stuff (via AIGLX), but not
gallium''s
new
> > dri_nouveau stuff.
> Right. But gallium''s swrast_dri AND dri_nouveau are still
''unsupported'',
> to be tried at own risk. nouveau_dri was working enough to run fgfs with
> mesa-7.7, but now with mesa-7.9, glxgears works not fgfs - segfaults in
> libdrm_nouveau.
Correct.  I''ve been having rather good luck with it until this.  I can 
recompile mesa and leave out the nouveau and swrast stuff to see if that 
helps, but my impression was that this is crashing before any of that code 
even gets used.  And it does work bare-metal and did work in xen prior to 
that last patch.  What''s the fallback if both gallium''s
nouveau and swrast
libs are missing, anyway?

> >> Xorg used to hang saying ''Opened Channel 2'' and
not 1.
> >
> > Now that''s strange.  Every single one of my boxes says Opened
Channel
1,
> > with now reference to channel 2 at all.
> Channel 1 in dmesg/syslog;  Xorg.log snippet:
> (II) LoadModule: "shadowfb"
> (II) Loading /usr/lib/xorg/modules/libshadowfb.so
> (II) Module shadowfb: vendor="X.Org Foundation"
>     compiled for 1.7.5, module version = 1.0.0
>     ABI class: X.Org ANSI C Emulation, version 0.4
> (--) Depth 24 pixmap format is 32 bpp
> (II) NOUVEAU(0): Opened GPU channel 2  <initial hang point>
> (II) NOUVEAU(0): [DRI2] Setup complete    <after patch>
> (II) NOUVEAU(0): GART: 512MiB available
> (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
> (II) EXA(0): Driver allocated offscreen pixmaps
> (II) EXA(0): Driver registered support for the following operations:
> (II)         Solid
> (II)         Copy
> (II)         Composite (RENDER acceleration)
> (II)         UploadToScreen
> (II)         DownloadFromScreen
> (==) NOUVEAU(0): Backing store disabled
> (==) NOUVEAU(0): Silken mouse enabled
> (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured 
Video.
> (II) NOUVEAU(0): [XvMC] Extension initialized.
> 
> 
> Try with
> Option "ShadowFB"  "true"
> in Device section of xorg.conf (turns off acceleration) to check. The 
option
> also sets NoAccel on and X should use the FB device
Which should make it mind-bogglingly slow, right?  I''ll try this as
well.

> 
> So the cards that don''t work are AGP cards?
Yes.  GeForce2 MX200 AGP.


---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM:

*snip*
> > with "NOUVEAU(0): Opened GPU channel 1".
> This is strange - channel 1 is the console channel. This appears in 
dmesg on
> nouveaufb initialisation before EDID probe to find connected outputs.
> Start X manually to avoid confusion of logs.
> 
> Have attached ttm_xen.patch which updates vm_page_prot after changing 
flags.
> This is not done in the mainline drm-tree. But in the xen (old)
> drm-tree this is done in
> BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both,
> along with the conditional VM_IO in bo_mmap. And the second vm_page_prot
> update is for fbdev_mmap which corresponds to channel 1. Cross 
> fingers and try!
Actually, both hunks of that patch are already applied in my tree.  The 
git tree from git://anongit.freedesktop.org/nouveau/linux-2.6 appears to 
already be doing the vm_page_prot update in both places.  Maybe the 
official nouveau dev tree is hosed?  Odd that it would work fine 
bare-metal...


*snip*
> >> Xorg used to hang saying ''Opened Channel 2'' and
not 1.
> >
> > Now that''s strange.  Every single one of my boxes says Opened
Channel
1,
> > with now reference to channel 2 at all.
> Channel 1 in dmesg/syslog;  Xorg.log snippet:
> (II) LoadModule: "shadowfb"
> (II) Loading /usr/lib/xorg/modules/libshadowfb.so
> (II) Module shadowfb: vendor="X.Org Foundation"
>     compiled for 1.7.5, module version = 1.0.0
>     ABI class: X.Org ANSI C Emulation, version 0.4
> (--) Depth 24 pixmap format is 32 bpp
> (II) NOUVEAU(0): Opened GPU channel 2  <initial hang point>
> (II) NOUVEAU(0): [DRI2] Setup complete    <after patch>
> (II) NOUVEAU(0): GART: 512MiB available
> (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
> (II) EXA(0): Driver allocated offscreen pixmaps
> (II) EXA(0): Driver registered support for the following operations:
> (II)         Solid
> (II)         Copy
> (II)         Composite (RENDER acceleration)
> (II)         UploadToScreen
> (II)         DownloadFromScreen
> (==) NOUVEAU(0): Backing store disabled
> (==) NOUVEAU(0): Silken mouse enabled
> (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured 
Video.
> (II) NOUVEAU(0): [XvMC] Extension initialized.
> 
> 
> Try with
> Option "ShadowFB"  "true"
> in Device section of xorg.conf (turns off acceleration) to check. The 
option
> also sets NoAccel on and X should use the FB device
Tried this.  GDM starts fine in Xen and I can log in, but wow slow.  Now 
there''s no reference to any GPU channel being opened in my X log.


---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Mar 23, 2010 at 6:57 PM, Michael D Labriola <mlabriol@gdeb.com>
wrote:
> xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM:
>
> *snip*
>> > with "NOUVEAU(0): Opened GPU channel 1".
>> This is strange - channel 1 is the console channel. This appears in
> dmesg on
>> nouveaufb initialisation before EDID probe to find connected outputs.
>> Start X manually to avoid confusion of logs.
>>
>> Have attached ttm_xen.patch which updates vm_page_prot after changing
> flags.
>> This is not done in the mainline drm-tree. But in the xen (old)
>> drm-tree this is done in
>> BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both,
>> along with the conditional VM_IO in bo_mmap. And the second
vm_page_prot
>> update is for fbdev_mmap which corresponds to channel 1. Cross
>> fingers and try!
>
> Actually, both hunks of that patch are already applied in my tree.  The
> git tree from git://anongit.freedesktop.org/nouveau/linux-2.6 appears to
> already be doing the vm_page_prot update in both places.  Maybe the
> official nouveau dev tree is hosed?  Odd that it would work fine
> bare-metal...
It always did work on bare-metal and on Xen without acceleration.
The patch just enables acceleration on Xen - it seems only on PCI/E cards.
> *snip*
>> >> Xorg used to hang saying ''Opened Channel 2''
and not 1.
>> >
>> > Now that''s strange.  Every single one of my boxes says
Opened Channel
> 1,
>> > with now reference to channel 2 at all.
>> Try with
>> Option "ShadowFB"  "true"
>> in Device section of xorg.conf (turns off acceleration) to check. The
> option
>> also sets NoAccel on and X should use the FB device
>
> Tried this.  GDM starts fine in Xen and I can log in, but wow slow.  Now
> there''s no reference to any GPU channel being opened in my X log.
>
The problem may be due to the initial AGP-memory allocation setting
up the wrong flags. And the older AGP cards seem to work differently
from the newer PCI/E ones.

Until someone resolves the agp issue, I guess your best choice
is to remove the ShadowFB option in the conf file and not install the dri
package (nouveau_dri.so and swrast_dri.so) in the AGP systems. That
means you will have 2D-accel but no glx (3D-accel).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 03/15/2010 07:44 AM, Michael D Labriola wrote:
> xen-devel-bounces@lists.xensource.com wrote on 03/13/2010 05:03:22 PM:
>
>    
>> On 03/12/2010 01:45 PM, Arvind R wrote:
>>      
>>> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen<pq@iki.fi> 
wrote:
>>>        
>>>> I''m adding dri-devel@ to CC, since this suggested
patch touches
>>>> TTM code, and none of the Nouveau code. TTM patches go via
>>>> dri-devel@.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> On Wed, 10 Mar 2010 18:51:21 +0530
>>>> Arvind R<arvino55@gmail.com>  wrote:
>>>>
>>>>          
>>>>> Hi,
>>>>> Following is a simple patch that is needed in nouveau to
get
>>>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is
jeremy''s
>>>>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau
(which is
>>>>> almost the mainline merge), was substituted into the
kernel-tree.
>>>>> All components of X (mesa, Xorg-server-7.5, xf86-nouveau,
libdrm)
>>>>> used of the same day.
>>>>>
>>>>> Patch:
>>>>> diff -Naur
nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
2010-01-27
>>>>> 10:19:28.000000000 +0530
>>>>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 
2010-03-10
>>>>> 17:28:59.000000000 +0530
>>>>> @@ -271,7 +271,10 @@
>>>>>           */
>>>>>
>>>>>          vma->vm_private_data = bo;
>>>>> -       vma->vm_flags |= VM_RESERVED | VM_IO |
VM_MIXEDMAP |
>>>>> VM_DONTEXPAND;
>>>>> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP |
>>>>> VM_DONTEXPAND;
>>>>> +       if (!((bo->mem.placement& 
TTM_PL_MASK_MEM)&
>>>>> TTM_PL_FLAG_TT))
>>>>> +               vma->vm_flags |= VM_IO;
>>>>> +       vma->vm_page_prot =
vma_get_vm_prot(vma->vm_flags);
>>>>>          return 0;
>>>>>   out_unref:
>>>>>          ttm_bo_unref(&bo);
>>>>>
>>>>>            
>>> sorry for the typo and other procedural errors.
>>> the last added line should be
>>> +    vma->vm_page_prot = vm_get_page_prot(vma->vm_flags)
>>>
>>>        
>>>>> This patch is necessary because, in Xen, PFN of a page is
>>>>> virtualised. So physical addresses
>>>>> for DMA programming needs to use the MFN. Xen transparently
does
>>>>> the correct translation
>>>>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit is
set,
>>>>> then Xen assumes that the backing
>>>>> memory is in the IOMEM space, and PFN equals MFN. If not
set,
>>>>> page_to_pfn() returns MFN.
>>>>>
>>>>> The patch enables the ttm_bo_vm_fault() handler to behave
>>>>> correctly under Xen, and has no
>>>>> side-effects on normal (not under Xen) operations. The use
of
>>>>> TTM_PL_FLAG_TT in the
>>>>> check assumes that all other placements are backed by
device
>>>>> memory or IO. If there are
>>>>> any other placements that use system memory, that flag has
to be
>>>>> OR''ed into the check.
>>>>>
>>>>> The above patch has no implications on a normal kernel or a
Xen
>>>>> pv_ops kernel booted without
>>>>> the Xen hypervisor. My testing is on a debian-lenny
environment
>>>>> on a Core2 processor with
>>>>> nVidia GeForce 9400 GT.
>>>>>            
>>>>          
>>> Efficacy of patch:
>>> successful flightgear run on dom0 AND bareboot!
>>>
>>>        
>> Jeremy, will you be merging this patch into any of the xen/stable-*
>> branches any time soon?
>>
>> Thanks,
>> joanna.
>>      
> Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen on
> my two primary test boxes (GeForce 6200, GeForce 7300).  However, on my
> really old machines (AGP GeForce2 MX200), this causes a new crash.  These
> old boxes were actually working fine in Xen prior to this patch, just
> w/out 3d acceleration.  Now I get the following messages in dmesg:
>
> [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
> initialised FIFO 1
> [  129.643791] X: Corrupted page table at address 40412000
> [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
> [  129.643856] Bad pagetable: 000f [#1] SMP
> [  129.643897] last sysfs file:
> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
> [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1
> video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 snd_ac97_codec
> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device
> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore i82860_edac
> snd_page_alloc pata_acpi edac_core parport_pc floppy parport dm_snapshot
> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd
> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
> [  129.644024]
> [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
> [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
> [  129.644024] EIP is at 0x40394596
> [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
> [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
> [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
> task.ti=ea1ce000)
> [  129.644024]
> [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
> [  129.644024] ---[ end trace 569eb18d737a8611 ]---
> [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing
> fifo 1
>
>
> And my X log ends abruptly after this line:
> (II) NOUVEAU(0): Opened GPU Channel 1
>
> Any ideas?
>    
BTW, what chipset does this machine have?  Is it Intel?  AMD?  Other?

     J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 03/12/2010 06:27 AM, Arvind R wrote:
> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> wrote:
>> I''m adding dri-devel@ to CC, since this suggested patch
touches TTM
>> code, and none of the Nouveau code. TTM patches go via dri-devel@.
>> 
>> Thanks.
>> 
>> 
>> On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R <arvino55@gmail.com>
>> wrote:
>> 
>>> Hi, Following is a simple patch that is needed in nouveau to get 
>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is
>>> jeremy''s 2.6.31.6 as of 20100222. The whole gpu tree of
nouveau
>>> (which is almost the mainline merge), was substituted into the
>>> kernel-tree. All components of X (mesa, Xorg-server-7.5,
>>> xf86-nouveau, libdrm) used of the same day.
>>> 
>>> Patch: diff -Naur
>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 
>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c ---
>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 
>>> 10:19:28.000000000 +0530 +++
>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10 
>>> 17:28:59.000000000 +0530 @@ -271,7 +271,10 @@ */
>>> 
>>> vma->vm_private_data = bo; -       vma->vm_flags |=
VM_RESERVED |
>>> VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; +       vma->vm_flags
|>>> VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; +       if
>>> (!((bo->mem.placement & TTM_PL_MASK_MEM) &
TTM_PL_FLAG_TT)) +
>>> vma->vm_flags |= VM_IO; +       vma->vm_page_prot
>>> vma_get_vm_prot(vma->vm_flags); return 0; out_unref:
>>> ttm_bo_unref(&bo);
>>> 
> Sorry for the typo: in the last added line, 
> vma_get_vm_prot(vma->vm_flags) should be
> vma->vm_get_page_prot(vma->vm_flags)
> 
Arvind,

I''ve just tried your patch (with the above correction applied). I tried
it against the latest pvops0 kernel from xen/stable-2.6.32.x with
back-ported nouveau code. Xen 3.4.3-rc4 hypervisor. The actual kernel is
based on Fedora 2.6.32.10.x kernel SRPM, more specifically on the
Michael Young''s SRPM (that integrates pvops patches):

http://fedorapeople.org/~myoung/dom0/src/kernel-2.6.32.10-1.2.92.xendom0.fc12.src.rpm

With your patch I can get my nouveau X driver now working *without*
NoAccel or ShadowFB settings in the xorg.conf, which was not possible
before.

I have enabled desktop composition using XRender in KDE (that runs in
Dom0), but I see a very high "latency" in how e.g. Windows react to me
wanting to move them on screen, or before the KDE''s "Strat"
menu
appears, or when I activate the "Expose effect" (Ctrl-F8), etc. It
looks
like if the composition buffers were still kept in host memory and
transferred to the video memory only when I want to do something with an
object (e.g. move the window). So, e.g. after this delay at the
beginning (e.g. after pressing Ctrl-F8) I can get smooth graphics
effects (e.g. Expose effect), but this initial delay, that manifests
itself before pretty much any action I take, makes the system
practically unusable... I''m using the latest KDE 4.4.

I''ve been wondering if you, or any other of xen-devel readers, have:
1) Tried the patch with some composting X Window manager in Dom0?
2) Got similar results?

FWIW, when I enable ShadowFB in xorg.conf the effect no longer occurs.
But ShadowFB disables H/W acceleration, so even though I can get rid of
the "latency", I''m not getting smooth visual effects anymore
(no smooth
Expose effect :(

Thanks,
joanna.

BTW, this is the patch I used for the recent pvops0 xen/stable-2.6.32.x:

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 3dc8d6b..0f57125 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -271,7 +271,9 @@ int ttm_bo_mmap(struct file *filp, struct
vm_area_struct *vma,
         */

        vma->vm_private_data = bo;
-       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+    vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+    if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT))
+        vma->vm_flags |= VM_IO;
        vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
        return 0;
 out_unref:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 03/25/2010 03:18:42 AM:
> On 03/15/2010 07:44 AM, Michael D Labriola wrote:
> > xen-devel-bounces@lists.xensource.com wrote on 03/13/2010 05:03:22 PM:
> >
> > 
> >> On 03/12/2010 01:45 PM, Arvind R wrote:
> >> 
> >>> On Thu, Mar 11, 2010 at 4:32 PM, Pekka
Paalanen<pq@iki.fi>  wrote:
> >>> 
> >>>> I''m adding dri-devel@ to CC, since this suggested
patch touches
> >>>> TTM code, and none of the Nouveau code. TTM patches go via
> >>>> dri-devel@.
> >>>>
> >>>> Thanks.
> >>>>
> >>>>
> >>>> On Wed, 10 Mar 2010 18:51:21 +0530
> >>>> Arvind R<arvino55@gmail.com>  wrote:
> >>>>
> >>>> 
> >>>>> Hi,
> >>>>> Following is a simple patch that is needed in nouveau
to get
> >>>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel
is jeremy''s
> >>>>> 2.6.31.6 as of 20100222. The whole gpu tree of nouveau
(which is
> >>>>> almost the mainline merge), was substituted into the
kernel-tree.
> >>>>> All components of X (mesa, Xorg-server-7.5,
xf86-nouveau, libdrm)
> >>>>> used of the same day.
> >>>>>
> >>>>> Patch:
> >>>>> diff -Naur
nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>>>> ---
nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
> >>>>> 10:19:28.000000000 +0530
> >>>>> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
2010-03-10
> >>>>> 17:28:59.000000000 +0530
> >>>>> @@ -271,7 +271,10 @@
> >>>>>           */
> >>>>>
> >>>>>          vma->vm_private_data = bo;
> >>>>> -       vma->vm_flags |= VM_RESERVED | VM_IO |
VM_MIXEDMAP |
> >>>>> VM_DONTEXPAND;
> >>>>> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP
|
> >>>>> VM_DONTEXPAND;
> >>>>> +       if (!((bo->mem.placement& 
TTM_PL_MASK_MEM)&
> >>>>> TTM_PL_FLAG_TT))
> >>>>> +               vma->vm_flags |= VM_IO;
> >>>>> +       vma->vm_page_prot =
vma_get_vm_prot(vma->vm_flags);
> >>>>>          return 0;
> >>>>>   out_unref:
> >>>>>          ttm_bo_unref(&bo);
> >>>>>
> >>>>> 
> >>> sorry for the typo and other procedural errors.
> >>> the last added line should be
> >>> +    vma->vm_page_prot = vm_get_page_prot(vma->vm_flags)
> >>>
> >>> 
> >>>>> This patch is necessary because, in Xen, PFN of a page
is
> >>>>> virtualised. So physical addresses
> >>>>> for DMA programming needs to use the MFN. Xen
transparently does
> >>>>> the correct translation
> >>>>> using the _PAGE_IOMEM prot-bit in the PTE. If the bit
is set,
> >>>>> then Xen assumes that the backing
> >>>>> memory is in the IOMEM space, and PFN equals MFN. If
not set,
> >>>>> page_to_pfn() returns MFN.
> >>>>>
> >>>>> The patch enables the ttm_bo_vm_fault() handler to
behave
> >>>>> correctly under Xen, and has no
> >>>>> side-effects on normal (not under Xen) operations. The
use of
> >>>>> TTM_PL_FLAG_TT in the
> >>>>> check assumes that all other placements are backed by
device
> >>>>> memory or IO. If there are
> >>>>> any other placements that use system memory, that flag
has to be
> >>>>> OR''ed into the check.
> >>>>>
> >>>>> The above patch has no implications on a normal kernel
or a Xen
> >>>>> pv_ops kernel booted without
> >>>>> the Xen hypervisor. My testing is on a debian-lenny
environment
> >>>>> on a Core2 processor with
> >>>>> nVidia GeForce 9400 GT.
> >>>>> 
> >>>> 
> >>> Efficacy of patch:
> >>> successful flightgear run on dom0 AND bareboot!
> >>>
> >>> 
> >> Jeremy, will you be merging this patch into any of the
xen/stable-*
> >> branches any time soon?
> >>
> >> Thanks,
> >> joanna.
> >> 
> > Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen
on
> > my two primary test boxes (GeForce 6200, GeForce 7300).  However, on 
my
> > really old machines (AGP GeForce2 MX200), this causes a new crash. 
These
> > old boxes were actually working fine in Xen prior to this patch, just
> > w/out 3d acceleration.  Now I get the following messages in dmesg:
> >
> > [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> > [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
> > initialised FIFO 1
> > [  129.643791] X: Corrupted page table at address 40412000
> > [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
> > [  129.643856] Bad pagetable: 000f [#1] SMP
> > [  129.643897] last sysfs file:
> > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
> > [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1
> > video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 
snd_ac97_codec
> > ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
> > snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device
> > snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
> > ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore 
i82860_edac
> > snd_page_alloc pata_acpi edac_core parport_pc floppy parport 
dm_snapshot
> > dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd
> > aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
> > [  129.644024]
> > [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6
> > [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
> > [  129.644024] EIP is at 0x40394596
> > [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000
> > [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780
> > [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> > [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
> > task.ti=ea1ce000)
> > [  129.644024]
> > [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
> > [  129.644024] ---[ end trace 569eb18d737a8611 ]---
> > [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: 
freeing
> > fifo 1
> >
> >
> > And my X log ends abruptly after this line:
> > (II) NOUVEAU(0): Opened GPU Channel 1
> >
> > Any ideas?
> > 
> 
> BTW, what chipset does this machine have?  Is it Intel?  AMD?  Other?
> 
>      J
It''s a really old Intel Xeon SMP box.  SuperMicro P4DC6+ motherboard.

---
Michael D Labriola
Electric Boat
mlabriol@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sun, Mar 28, 2010 at 3:50 PM, Joanna Rutkowska
<joanna@invisiblethingslab.com> wrote:
> On 03/12/2010 06:27 AM, Arvind R wrote:
>> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi>
wrote:
>>> I''m adding dri-devel@ to CC, since this suggested patch
touches TTM
>>> code, and none of the Nouveau code. TTM patches go via dri-devel@.
>>>
>>> Thanks.
>>>
>>>
>>> On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R
<arvino55@gmail.com>
>>> wrote:
>>>
>>>> Hi, Following is a simple patch that is needed in nouveau to
get
>>>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is
>>>> jeremy''s 2.6.31.6 as of 20100222. The whole gpu tree
of nouveau
>>>> (which is almost the mainline merge), was substituted into the
>>>> kernel-tree. All components of X (mesa, Xorg-server-7.5,
>>>> xf86-nouveau, libdrm) used of the same day.
>>>>
>>>> Patch: diff -Naur
>>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c ---
>>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
>>>> 10:19:28.000000000 +0530 +++
>>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10
>>>> 17:28:59.000000000 +0530 @@ -271,7 +271,10 @@ */
>>>>
>>>> vma->vm_private_data = bo; -       vma->vm_flags |=
VM_RESERVED |
>>>> VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; +       vma->vm_flags
|>>>> VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; +       if
>>>> (!((bo->mem.placement & TTM_PL_MASK_MEM) &
TTM_PL_FLAG_TT)) +
>>>> vma->vm_flags |= VM_IO; +       vma->vm_page_prot
>>>> vma_get_vm_prot(vma->vm_flags); return 0; out_unref:
>>>> ttm_bo_unref(&bo);
>>>>
>> Sorry for the typo: in the last added line,
>> vma_get_vm_prot(vma->vm_flags) should be
>> vma->vm_get_page_prot(vma->vm_flags)
>>
> Arvind,
>
> I''ve just tried your patch (with the above correction applied). I
tried
> it against the latest pvops0 kernel from xen/stable-2.6.32.x with
> back-ported nouveau code. Xen 3.4.3-rc4 hypervisor. The actual kernel is
> based on Fedora 2.6.32.10.x kernel SRPM, more specifically on the
> Michael Young''s SRPM (that integrates pvops patches):
>
>
http://fedorapeople.org/~myoung/dom0/src/kernel-2.6.32.10-1.2.92.xendom0.fc12.src.rpm
>
> With your patch I can get my nouveau X driver now working *without*
> NoAccel or ShadowFB settings in the xorg.conf, which was not possible
> before.
>
> I have enabled desktop composition using XRender in KDE (that runs in
> Dom0), but I see a very high "latency" in how e.g. Windows react
to me
> wanting to move them on screen, or before the KDE''s
"Strat" menu
> appears, or when I activate the "Expose effect" (Ctrl-F8), etc.
It looks
> like if the composition buffers were still kept in host memory and
> transferred to the video memory only when I want to do something with an
> object (e.g. move the window). So, e.g. after this delay at the
> beginning (e.g. after pressing Ctrl-F8) I can get smooth graphics
> effects (e.g. Expose effect), but this initial delay, that manifests
> itself before pretty much any action I take, makes the system
> practically unusable... I''m using the latest KDE 4.4.
>
> I''ve been wondering if you, or any other of xen-devel readers,
have:
> 1) Tried the patch with some composting X Window manager in Dom0?
using ecomp (compiz port for enlightenment) on e17-git. Enabled composite.
Works with software-engine but not with xrender-engine.
> 2) Got similar results?
Works fine - no latencies I can notice - though I''ve tried only the
default
effects settings

The sluggish/jerky keyboard/mouse in domU (SDL) consoles have also
vanished with accel-enabled X. Keypress-repeat does not work in domU.
> FWIW, when I enable ShadowFB in xorg.conf the effect no longer occurs.
> But ShadowFB disables H/W acceleration, so even though I can get rid of
> the "latency", I''m not getting smooth visual effects
anymore (no smooth
> Expose effect :(
>
> Thanks,
> joanna.
>
> BTW, this is the patch I used for the recent pvops0 xen/stable-2.6.32.x:
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 3dc8d6b..0f57125 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -271,7 +271,9 @@ int ttm_bo_mmap(struct file *filp, struct
> vm_area_struct *vma,
>         */
>
>        vma->vm_private_data = bo;
> -       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP |
VM_DONTEXPAND;
> +    vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
> +    if (!((bo->mem.placement & TTM_PL_MASK_MEM) &
TTM_PL_FLAG_TT))
> +        vma->vm_flags |= VM_IO;
>        vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>        return 0;
>  out_unref:
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > >>>         vma->vm_private_data = bo;
> > >>> -       vma->vm_flags |= VM_RESERVED | VM_IO |
VM_MIXEDMAP |
> > >>> VM_DONTEXPAND;
> > >>> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP |
> > >>> VM_DONTEXPAND;
> > >>> +       if (!((bo->mem.placement &
TTM_PL_MASK_MEM) &
> > >>> TTM_PL_FLAG_TT))
> > >>> +               vma->vm_flags |= VM_IO;
> > >>> +       vma->vm_page_prot =
vma_get_vm_prot(vma->vm_flags);
> > >>>         return 0;
> > >>>  out_unref:
> > >>>         ttm_bo_unref(&bo);
> > >>>
.. snip.
> > >>> nVidia GeForce 9400 GT.
..snip..
> 
> Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen on 
> my two primary test boxes (GeForce 6200, GeForce 7300).  However, on my 
> really old machines (AGP GeForce2 MX200), this causes a new crash.  These 
> old boxes were actually working fine in Xen prior to this patch, just 
> w/out 3d acceleration.  Now I get the following messages in dmesg:
> 
> [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: 
> initialised FIFO 1
> [  129.643791] X: Corrupted page table at address 40412000
> [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000 
> [  129.643856] Bad pagetable: 000f [#1] SMP 
.. snip..
> [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing 
> fifo 1
> 
> 
> And my X log ends abruptly after this line:
> (II) NOUVEAU(0): Opened GPU Channel 1

So, I''ve spent the last two weeks trying to get this to work.

What I found out was that the majority of the problems were with the Linux AGP
code
(drivers/char/agp/*). Now I can get Kernel Modesetting 
working under Radeon HD3200 (PCI-e), NVidia GeForce FX5200 (AGP), and I think
other ones too (hadn''t tested yet). However, I am still failing at the
same
spot as Michael: the dreaded Opened GPU Channel 1...

Anyhow.. if you want the patches:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes

(and the "devel/drm.backport" which is a drop of drm/* from 2.6.34-rc7
in
2.6.32 universe).

The explanation:

1). Newer boxes with PCI-e cards with more than 4GB allocated to dom0.
Those cards have their own IOMMU built in on the cards and use the PCI
DMA. The problem is that some of those cards set the DMA mask to 32-bit,
meaning they are only comfortable allocating pages under the 4GB mark.
The Xen-SWIOTLB kicks in and happily gives a bounce buffer for pages
that are above the 32-bit mark, which are then programmed to the IOMMU.
Except that the graphic drivers do not sync the bounce buffer so the
result ends up stored in the bounce buffer and not in the buffer the
graphic drivers expect (oops).  That however should not have happend
as any pages allocated from the TTM library use the
''alloc_page'' with
 _GFP_DMA32 flag, which means that all of those pages WILL be under
4GB under baremetal. However under Xen that flag is useless and the page
can be very well allocated above the 4GB mark (and is if you are using
the debug Xen hypervisor). The patch titled
 "ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under" fixes that by
replacing the PFNs with ones under the 4GB.

It makes my Radeon HD3200 work, and I believe other PCI-e cards too.

2). i915 cards:
The earlier cards (before PCI-e) depend on the AGP to the virtual to
physical address translations.  The old AGP code is safe for specific 
controllers: say i915 - and only if you have CONFIG_DMAR enabled. So
there is a patch if you don''t have that enabled:

      intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.

3) i915 and before.
For older ones, such as the ICH5 (which has an i860 chipset), the Linux
code blindly uses the virt_to_phys and page_to_phys which are not
Xen-safe. For this fancy NV30 card (which is AGP) I''ve gotten to the
point of the framebuffer displaying properly. The patches that fix this
are:
  intel-agp: Use Xen back-door to get page''s physical address for
i8[1,3]0
      agp-backend: Use Xen back-door to get bus address for scratch page.
      agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
      agp: Program the GART with the real physical address under Xen.
      agp: Use Xen back-door to get bus address for legacy code.


4). I did check out the AGP code for the other chipsets, so added
experimental support for AMD64 chipset. Haven''t tested it at all.

Summary:
Most of those patches are not upstream materials. Right now I am
just trying to get those bugs fixed and then later on revisit them with
a more comprehensive patch.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Jun 09, 2010 at 01:43:42PM -0400, Konrad Rzeszutek Wilk
wrote:
> > > >>>         vma->vm_private_data = bo;
> > > >>> -       vma->vm_flags |= VM_RESERVED | VM_IO |
VM_MIXEDMAP |
> > > >>> VM_DONTEXPAND;
> > > >>> +       vma->vm_flags |= VM_RESERVED |
VM_MIXEDMAP |
> > > >>> VM_DONTEXPAND;
> > > >>> +       if (!((bo->mem.placement &
TTM_PL_MASK_MEM) &
> > > >>> TTM_PL_FLAG_TT))
> > > >>> +               vma->vm_flags |= VM_IO;
> > > >>> +       vma->vm_page_prot =
vma_get_vm_prot(vma->vm_flags);
> > > >>>         return 0;
> > > >>>  out_unref:
> > > >>>         ttm_bo_unref(&bo);
> > > >>>
> .. snip.
> > > >>> nVidia GeForce 9400 GT.
> 
> ..snip..
> > 
> > Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen
on
> > my two primary test boxes (GeForce 6200, GeForce 7300).  However, on
my
> > really old machines (AGP GeForce2 MX200), this causes a new crash. 
These
> > old boxes were actually working fine in Xen prior to this patch, just 
> > w/out 3d acceleration.  Now I get the following messages in dmesg:
> > 
> > [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> > [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: 
> > initialised FIFO 1
> > [  129.643791] X: Corrupted page table at address 40412000
> > [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000 
> > [  129.643856] Bad pagetable: 000f [#1] SMP 
> .. snip..
> > [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free:
freeing
> > fifo 1
> > 
> > 
> > And my X log ends abruptly after this line:
> > (II) NOUVEAU(0): Opened GPU Channel 1
> 
> 
> So, I''ve spent the last two weeks trying to get this to work.
> 
> What I found out was that the majority of the problems were with the Linux
AGP code
> (drivers/char/agp/*). Now I can get Kernel Modesetting 
> working under Radeon HD3200 (PCI-e), NVidia GeForce FX5200 (AGP), and I
think
> other ones too (hadn''t tested yet). However, I am still failing at
the same
> spot as Michael: the dreaded Opened GPU Channel 1...
> 
> Anyhow.. if you want the patches:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/kms-fixes
> 
> (and the "devel/drm.backport" which is a drop of drm/* from
2.6.34-rc7 in
> 2.6.32 universe).
> 
> The explanation:
> 
> 1). Newer boxes with PCI-e cards with more than 4GB allocated to dom0.
> Those cards have their own IOMMU built in on the cards and use the PCI
> DMA. The problem is that some of those cards set the DMA mask to 32-bit,
> meaning they are only comfortable allocating pages under the 4GB mark.
> The Xen-SWIOTLB kicks in and happily gives a bounce buffer for pages
> that are above the 32-bit mark, which are then programmed to the IOMMU.
> Except that the graphic drivers do not sync the bounce buffer so the
> result ends up stored in the bounce buffer and not in the buffer the
> graphic drivers expect (oops).  That however should not have happend
> as any pages allocated from the TTM library use the
''alloc_page'' with
>  _GFP_DMA32 flag, which means that all of those pages WILL be under
> 4GB under baremetal. However under Xen that flag is useless and the page
> can be very well allocated above the 4GB mark (and is if you are using
> the debug Xen hypervisor). The patch titled
>  "ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under" fixes that
by
> replacing the PFNs with ones under the 4GB.
> 
> It makes my Radeon HD3200 work, and I believe other PCI-e cards too.
> 
> 2). i915 cards:
> The earlier cards (before PCI-e) depend on the AGP to the virtual to
> physical address translations.  The old AGP code is safe for specific 
> controllers: say i915 - and only if you have CONFIG_DMAR enabled. So
> there is a patch if you don''t have that enabled:
> 
>       intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus
addresses.
> 
> 3) i915 and before.
> For older ones, such as the ICH5 (which has an i860 chipset), the Linux
> code blindly uses the virt_to_phys and page_to_phys which are not
> Xen-safe. For this fancy NV30 card (which is AGP) I''ve gotten to
the
> point of the framebuffer displaying properly. The patches that fix this
> are:
>   intel-agp: Use Xen back-door to get page''s physical address for
i8[1,3]0
>       agp-backend: Use Xen back-door to get bus address for scratch page.
>       agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under
Xen.
>       agp: Program the GART with the real physical address under Xen.
>       agp: Use Xen back-door to get bus address for legacy code.
> 
> 
> 4). I did check out the AGP code for the other chipsets, so added
> experimental support for AMD64 chipset. Haven''t tested it at all.
> 
> Summary:
> Most of those patches are not upstream materials. Right now I am
> just trying to get those bugs fixed and then later on revisit them with
> a more comprehensive patch.
> 
Wow. Impressive work!

Hopefully the "Opened GPU channel 1" -thing gets beaten sooner than
later too..
unfortunately I don''t have Nvidia GPU at the moment so I can''t
really help with that..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> Wow. Impressive work!
Thank you.
> 
> Hopefully the "Opened GPU channel 1" -thing gets beaten sooner
than later too..
> unfortunately I don''t have Nvidia GPU at the moment so I
can''t really help with that..
That is OK. One of the patches in that git tree also fixes ATI Radeon cards
issues (wherein if you had 4GB or more in Dom0, the ATI Radeon cards would not
work, or if you booted Dom0 with a debug enabled Xen it would fail).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > And my X log ends abruptly after this line:
> > (II) NOUVEAU(0): Opened GPU Channel 1
> 
> 
> So, I''ve spent the last two weeks trying to get this to work.
> 
.. 
> other ones too (hadn''t tested yet). However, I am still failing at
the same
> spot as Michael: the dreaded Opened GPU Channel 1...
Fixed! Plus I''ve tested it on:

GeForce 1 256
GeForce 3 NV20
GeForce 4 Ti 4200
GeForce 8600 GT
ICH5 82865G
ICH7 82G33/G31G
ICH8 82Q963/Q965
Matrox G450
Radeon ES1000
Radeon HD 3200
Radeon R100 QD (7200)
Radeon RV100QY (7000)
Radeon RV710 [Radeon HD 4350]
RIVA TNT2 Pro

Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM
There are two bugs that are creeping up. One of the can be disabled by
''nopat'' on the command line. The other, well the other is only
seen
during shutdown.
> 
> Anyhow.. if you want the patches:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/kms-fixes
I rebased the branch and it is now devel/kms.fixes-0.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote:
>>> And my X log ends abruptly after this line:
>>> (II) NOUVEAU(0): Opened GPU Channel 1
>>
>>
>> So, I''ve spent the last two weeks trying to get this to work.
>>
> .. 
>> other ones too (hadn''t tested yet). However, I am still
failing at the same
>> spot as Michael: the dreaded Opened GPU Channel 1...
> 
> Fixed! Plus I''ve tested it on:
> 
> GeForce 1 256
> GeForce 3 NV20
> GeForce 4 Ti 4200
> GeForce 8600 GT
> ICH5 82865G
> ICH7 82G33/G31G
> ICH8 82Q963/Q965
> Matrox G450
> Radeon ES1000
> Radeon HD 3200
> Radeon R100 QD (7200)
> Radeon RV100QY (7000)
> Radeon RV710 [Radeon HD 4350]
> RIVA TNT2 Pro
> 
> Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> There are two bugs that are creeping up. One of the can be disabled by
> ''nopat'' on the command line. The other, well the other is
only seen
> during shutdown.
> 
>>
>> Anyhow.. if you want the patches:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/kms-fixes
> 
> I rebased the branch and it is now devel/kms.fixes-0.3
> 
Which stable branch have you rebased it for (.31, .32, .33?)?

Have you tested it with some composting Window Manager (e.g. in KDE or
Gnome with enables desktop effects)?

Have you also tested it with Xorg 1.8.0? This is now default in F13, and
it used new nouveau driver interface 0.16 (previous Xorgs exprected
version 0.15).

Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31
or .32 support S3 sleep?).

Thanks,
joanna.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska
wrote:
> On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote:
> >>> And my X log ends abruptly after this line:
> >>> (II) NOUVEAU(0): Opened GPU Channel 1
> >>
> >>
> >> So, I''ve spent the last two weeks trying to get this to
work.
> >>
> > .. 
> >> other ones too (hadn''t tested yet). However, I am still
failing at the same
> >> spot as Michael: the dreaded Opened GPU Channel 1...
> > 
> > Fixed! Plus I''ve tested it on:
> > 
> > GeForce 1 256
> > GeForce 3 NV20
> > GeForce 4 Ti 4200
> > GeForce 8600 GT
> > ICH5 82865G
> > ICH7 82G33/G31G
> > ICH8 82Q963/Q965
> > Matrox G450
> > Radeon ES1000
> > Radeon HD 3200
> > Radeon R100 QD (7200)
> > Radeon RV100QY (7000)
> > Radeon RV710 [Radeon HD 4350]
> > RIVA TNT2 Pro
> > 
> > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > There are two bugs that are creeping up. One of the can be disabled by
> > ''nopat'' on the command line. The other, well the
other is only seen
> > during shutdown.
> > 
> >>
> >> Anyhow.. if you want the patches:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/kms-fixes
> > 
> > I rebased the branch and it is now devel/kms.fixes-0.3
> > 
> Which stable branch have you rebased it for (.31, .32, .33?)?
.32.

and then I backported the DRM/TTM/KMS from 2.6.34 to be able to test the
nouveau driver.
> 
> Have you tested it with some composting Window Manager (e.g. in KDE or
> Gnome with enables desktop effects)?
Yes. I think so (isn''t that the default thing?). Played some tuxracer
when testing it on Radeon and I think the i915, so the OpenGL components
worked OK. I know that 3D don''t work on the nouveau driver so
hadn''t
tried that.
> 
> Have you also tested it with Xorg 1.8.0? This is now default in F13, and
> it used new nouveau driver interface 0.16 (previous Xorgs exprected
> version 0.15).
Yes. I used for initial testing with whatever was in F13 Alpha drop?. After
all of that testing I switched my main desktop machine to use F13
with the using xorg-x11-server 1.8.0-12.fc13 and with a GeForce 8600 GT.

It works - thought I keep on getting those PSE warnings whenever an application
has been killed (http://wiki.xensource.com/xenwiki/XenPVOPSDRM, look for
Status).
> 
> Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31
> or .32 support S3 sleep?).
HA! Working on that and S5 right now. Jeremy mentioned he did get S3
working, but hadn''t tried other modes. S5, S3, and S1 on my SuperMicro
XF8TN just don''t work. Not sure if I have the Xen ACPI hypercalls
thought in the code base.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/23/10 14:54, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote:
>> On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote:
>>>>> And my X log ends abruptly after this line:
>>>>> (II) NOUVEAU(0): Opened GPU Channel 1
>>>>
>>>>
>>>> So, I''ve spent the last two weeks trying to get this
to work.
>>>>
>>> .. 
>>>> other ones too (hadn''t tested yet). However, I am
still failing at the same
>>>> spot as Michael: the dreaded Opened GPU Channel 1...
>>>
>>> Fixed! Plus I''ve tested it on:
>>>
>>> GeForce 1 256
>>> GeForce 3 NV20
>>> GeForce 4 Ti 4200
>>> GeForce 8600 GT
>>> ICH5 82865G
>>> ICH7 82G33/G31G
>>> ICH8 82Q963/Q965
>>> Matrox G450
>>> Radeon ES1000
>>> Radeon HD 3200
>>> Radeon R100 QD (7200)
>>> Radeon RV100QY (7000)
>>> Radeon RV710 [Radeon HD 4350]
>>> RIVA TNT2 Pro
>>>
>>> Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM
>>> There are two bugs that are creeping up. One of the can be disabled
by
>>> ''nopat'' on the command line. The other, well the
other is only seen
>>> during shutdown.
>>>
>>>>
>>>> Anyhow.. if you want the patches:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/kms-fixes
>>>
>>> I rebased the branch and it is now devel/kms.fixes-0.3
>>>
>> Which stable branch have you rebased it for (.31, .32, .33?)?
> 
> .32.
> 
> and then I backported the DRM/TTM/KMS from 2.6.34 to be able to test the
> nouveau driver.
>>
>> Have you tested it with some composting Window Manager (e.g. in KDE or
>> Gnome with enables desktop effects)?
> 
> Yes. I think so (isn''t that the default thing?).
No, both KDE and GNOME have composition disabled by default. On KDE, you
need to go to Computer/System Settings/Desktop and then "Enable Desktop
Eff3cts". You might need to click on the "Advanced" tab, and
choose
XRender instead of Open GL (and maybe also tick "Disable Functionality
checks").
> Played some tuxracer when testing it on Radeon and I think the i915,
i915 is the Intel card, right? So, it''s not served by the nouveau code,
is it?
> so the OpenGL components worked OK.
Hmmm, that''s interesting. I think I never got Open GL working on
nouveau, even on baremetal (I tested via KDE -- see above).
> I know that 3D don''t work on the nouveau driver so hadn''t
> tried that.
> 
No worries, 3D desktop effects are overrated ;) All I want is "Expose"
:)
>>
>> Have you also tested it with Xorg 1.8.0? This is now default in F13,
and
>> it used new nouveau driver interface 0.16 (previous Xorgs exprected
>> version 0.15).
> 
> Yes. I used for initial testing with whatever was in F13 Alpha drop?. After
> all of that testing I switched my main desktop machine to use F13
> with the using xorg-x11-server 1.8.0-12.fc13 and with a GeForce 8600 GT.
> 
> It works - thought I keep on getting those PSE warnings whenever an
application
> has been killed (http://wiki.xensource.com/xenwiki/XenPVOPSDRM, look for
> Status).
> 
I know it''s offtopic, but anybody tried Xorg 1.8.0 on Intel HD? I
crashes every 5 minutes or so, when one enables composition in KDE. And
this happens on baremetal F13 too!
>> Finally, have you tested S3 sleep? (Has anybody actually got pvops0 .31
>> or .32 support S3 sleep?).
> 
> HA! Working on that and S5 right now. Jeremy mentioned he did get S3
> working, but hadn''t tried other modes. S5, S3, and S1 on my
SuperMicro
> XF8TN just don''t work. Not sure if I have the Xen ACPI hypercalls
> thought in the code base.
What is the fundamental difference in S3 sleep support between pvops0
vs. xenlinux, which seems to support S3 sleep quite well. At least the
2.6.34-xenlinux, the one from OpenSUSE? Or is it just the .34 kernel,
that apparently is said to have lots of S3 sleep improvements?

joanna.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> >>> I rebased the branch and it is now devel/kms.fixes-0.3
> >>>
> >> Which stable branch have you rebased it for (.31, .32, .33?)?
> > 
> > .32.
> > 
> > and then I backported the DRM/TTM/KMS from 2.6.34 to be able to test
the
> > nouveau driver.
> >>
> >> Have you tested it with some composting Window Manager (e.g. in
KDE or
> >> Gnome with enables desktop effects)?
> > 
> > Yes. I think so (isn''t that the default thing?).
> 
> No, both KDE and GNOME have composition disabled by default. On KDE, you
> need to go to Computer/System Settings/Desktop and then "Enable
Desktop
> Eff3cts". You might need to click on the "Advanced" tab, and
choose
> XRender instead of Open GL (and maybe also tick "Disable Functionality
> checks").
On my nouveau it just says: "Desktop effects required hardware 3D
support." I will try with the Radeon and Intel graphics stuff next
week.
> 
> > Played some tuxracer when testing it on Radeon and I think the i915,
> 
> i915 is the Intel card, right? So, it''s not served by the nouveau
code,
> is it?
Right... I don''t think I actually tested the XRender code then.
But I did test the OpenGL code on Radeon and the Intel chipsets that I
had.
> 
> > so the OpenGL components worked OK.
> 
> Hmmm, that''s interesting. I think I never got Open GL working on
> nouveau, even on baremetal (I tested via KDE -- see above).
Right. That is expected as the 3D components are not in the nouveau driver
yet. Based on "http://nouveau.freedesktop.org/wiki/":
"Any 3-D functionality that might exist is still unsupported. Do not ask
for instructions to try it. But you can read GalliumHowto in case you
are brave enough."
> 
> > I know that 3D don''t work on the nouveau driver so
hadn''t
> > tried that.
> > 
> 
> No worries, 3D desktop effects are overrated ;) All I want is
"Expose" :)
Based on this: http://en.wikipedia.org/wiki/Xlib and the little example
code that comes with it I Expose events do work with Xen dom0
with Xorg 1.8 and with the nouveau driver.

.. snip ..
> >> Finally, have you tested S3 sleep? (Has anybody actually got
pvops0 .31
> >> or .32 support S3 sleep?).
> > 
> > HA! Working on that and S5 right now. Jeremy mentioned he did get S3
> > working, but hadn''t tried other modes. S5, S3, and S1 on my
SuperMicro
> > XF8TN just don''t work. Not sure if I have the Xen ACPI
hypercalls
> > thought in the code base.
> 
> What is the fundamental difference in S3 sleep support between pvops0
> vs. xenlinux, which seems to support S3 sleep quite well. At least the
> 2.6.34-xenlinux, the one from OpenSUSE? Or is it just the .34 kernel,
> that apparently is said to have lots of S3 sleep improvements?
<spreads his arms> Don''t know yet. Jeremy just pinged me and said
he got
on his laptop S3 to suspend working quite well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > so the OpenGL components worked OK.
> > 
> > Hmmm, that''s interesting. I think I never got Open GL working
on
> > nouveau, even on baremetal (I tested via KDE -- see above).
> 
> Right. That is expected as the 3D components are not in the nouveau driver
> yet. Based on "http://nouveau.freedesktop.org/wiki/":
> "Any 3-D functionality that might exist is still unsupported. Do not
ask
> for instructions to try it. But you can read GalliumHowto in case you
> are brave enough."
And actually, I just tried it (the GalliumHowto) and played both OpenArena
and TuxRacer on my Xen Dom0 with the NVidia card. Ok, so 3D effects
do work.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Jun 23, 2010 at 08:54:30AM -0400, Konrad Rzeszutek Wilk
wrote:
> On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote:
> > On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote:
> > >>> And my X log ends abruptly after this line:
> > >>> (II) NOUVEAU(0): Opened GPU Channel 1
> > >>
> > >>
> > >> So, I''ve spent the last two weeks trying to get this
to work.
> > >>
> > > .. 
> > >> other ones too (hadn''t tested yet). However, I am
still failing at the same
> > >> spot as Michael: the dreaded Opened GPU Channel 1...
> > > 
> > > Fixed! Plus I''ve tested it on:
> > > 
> > > GeForce 1 256
> > > GeForce 3 NV20
> > > GeForce 4 Ti 4200
> > > GeForce 8600 GT
> > > ICH5 82865G
> > > ICH7 82G33/G31G
> > > ICH8 82Q963/Q965
> > > Matrox G450
> > > Radeon ES1000
> > > Radeon HD 3200
> > > Radeon R100 QD (7200)
> > > Radeon RV100QY (7000)
> > > Radeon RV710 [Radeon HD 4350]
> > > RIVA TNT2 Pro
> > > 
> > > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > > There are two bugs that are creeping up. One of the can be
disabled by
> > > ''nopat'' on the command line. The other, well
the other is only seen
> > > during shutdown.
> > > 
> > >>
> > >> Anyhow.. if you want the patches:
> > >>
> > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/kms-fixes
> > > 
> > > I rebased the branch and it is now devel/kms.fixes-0.3
> > > 
> > Which stable branch have you rebased it for (.31, .32, .33?)?
> 
> .32.
> 
Hey,

I just tried devel/kms.fixes-0.3:

[root@f13 linux-2.6-xen]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen
..

[root@f13 linux-2.6-xen]# cd linux-2.6-xen/
[root@f13 linux-2.6-xen]# git checkout -b xen/stable-2.6.32.x
origin/xen/stable-2.6.32.x
[root@f13 linux-2.6-xen]# git pull

[root@f13 linux-2.6-xen]# git remote add -f konrad
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
[root@f13 linux-2.6-xen]# git pull
Already up-to-date.

[root@f13 linux-2.6-xen]# git merge konrad/devel/kms.fixes-0.3
Auto-merging drivers/char/agp/intel-agp.c
Auto-merging drivers/gpu/drm/ttm/ttm_bo_vm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo_vm.c
Auto-merging drivers/gpu/drm/ttm/ttm_tt.c
Automatic merge failed; fix conflicts and then commit the result.


Does it merge ok for you with xen/stable-2.6.32.x? 

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Jun 24, 2010 at 10:55:54PM +0300, Pasi Kärkkäinen
wrote:
> On Wed, Jun 23, 2010 at 08:54:30AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 23, 2010 at 12:32:57AM +0200, Joanna Rutkowska wrote:
> > > On 06/17/10 19:51, Konrad Rzeszutek Wilk wrote:
> > > >>> And my X log ends abruptly after this line:
> > > >>> (II) NOUVEAU(0): Opened GPU Channel 1
> > > >>
> > > >>
> > > >> So, I''ve spent the last two weeks trying to get
this to work.
> > > >>
> > > > .. 
> > > >> other ones too (hadn''t tested yet). However, I
am still failing at the same
> > > >> spot as Michael: the dreaded Opened GPU Channel 1...
> > > > 
> > > > Fixed! Plus I''ve tested it on:
> > > > 
> > > > GeForce 1 256
> > > > GeForce 3 NV20
> > > > GeForce 4 Ti 4200
> > > > GeForce 8600 GT
> > > > ICH5 82865G
> > > > ICH7 82G33/G31G
> > > > ICH8 82Q963/Q965
> > > > Matrox G450
> > > > Radeon ES1000
> > > > Radeon HD 3200
> > > > Radeon R100 QD (7200)
> > > > Radeon RV100QY (7000)
> > > > Radeon RV710 [Radeon HD 4350]
> > > > RIVA TNT2 Pro
> > > > 
> > > > Details on: http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > > > There are two bugs that are creeping up. One of the can be
disabled by
> > > > ''nopat'' on the command line. The other,
well the other is only seen
> > > > during shutdown.
> > > > 
> > > >>
> > > >> Anyhow.. if you want the patches:
> > > >>
> > > >>
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/kms-fixes
> > > > 
> > > > I rebased the branch and it is now devel/kms.fixes-0.3
> > > > 
> > > Which stable branch have you rebased it for (.31, .32, .33?)?
> > 
> > .32.
> > 
> 
> Hey,
> 
> I just tried devel/kms.fixes-0.3:
> 
> [root@f13 linux-2.6-xen]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen
> ..
> 
> [root@f13 linux-2.6-xen]# cd linux-2.6-xen/
> [root@f13 linux-2.6-xen]# git checkout -b xen/stable-2.6.32.x
origin/xen/stable-2.6.32.x
> [root@f13 linux-2.6-xen]# git pull
> 
> [root@f13 linux-2.6-xen]# git remote add -f konrad
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> [root@f13 linux-2.6-xen]# git pull
> Already up-to-date.
> 
> [root@f13 linux-2.6-xen]# git merge konrad/devel/kms.fixes-0.3
> Auto-merging drivers/char/agp/intel-agp.c
> Auto-merging drivers/gpu/drm/ttm/ttm_bo_vm.c
> CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo_vm.c
> Auto-merging drivers/gpu/drm/ttm/ttm_tt.c
> Automatic merge failed; fix conflicts and then commit the result.
> 
> 
> Does it merge ok for you with xen/stable-2.6.32.x? 
No. I get the same. The fault is that my patches assumes a bit different
tree. What you need is to fixup to this:

	vma->vm_private_data = bo;
-       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+       man = &bdev->man[bo->mem.mem_type];
+       if (man->flags & TTM_MEMTYPE_FLAG_NEEDS_IOREMAP)
+               vma->vm_flags |= VM_IO;
        vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
        return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel