[GIT PULL] devel/pat + devel/kms.fixes-0.5

[GIT PULL] devel/pat + devel/kms.fixes-0.5

[Konrad Rzeszutek Wilk]

Hey Jeremy,

Please pull from devel/pat (based off your xen/dom0/core tree) which
has one patch:

Konrad Rzeszutek Wilk (1):
      xen/pat: make pte_flags(x) a pvops function.

which is neccessary for the drivers/gpu/drm/radeon driver to work
properly with AGP based cards (which look to be the only ones that
try to set WC on pages).

Also please pull from devel/kms.fixes-05 (based off your xen/dom0/agp)
which has the following patches:

Daniel De Graaf (1):
      fb: propagate VM_IO to VMA.

Konrad Rzeszutek Wilk (10):
      ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under 4GB under Xen.
      ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set.
      agp: Use Xen back-door to get bus address for legacy code.
      agp: Program the GART with the real physical address under Xen.
      agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
      agp-backend: Use Xen back-door to get bus address for scratch page.
      intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.
      intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0
      amd64-agp:Use Xen back-door to get page's physical address for AMD64 chipsets.
      ttm: Change VMA flags if they != to the TTM flags.

Some of them are marked as not for upstream consumption, while some of
the other are OK (and Daniel's is upstream). Those patches from both
branches make it possible to have Xorg working with the following
graphics cards on the PVOPS kernel:

RIVA TNT2 Pro
GeForce 1 256
GeForce 4 Ti 4200
GeForce 6150
GeForce 6200
GeForce 7300
GeForce 8600 GT
Radeon R100 QD (7200)
Radeon RV100QY (7000)
Radeon HD 3200
Radeon HD 3450
Radeon RV710 [Radeon HD 4350]
Radeon ES1000
ICH5 82865G
ICH7 82G33/G31G
ICH8 82Q963/Q965
Matrox G450
XGI Z7/Z9 (XG20 core)

Testing was carried out using Fedora Core 13, Fedora Core 11, and Ubuntu
Lucid 10.04 with the PVOPS kernel.

The details are located at http://wiki.xensource.com/xenwiki/XenPVOPSDRM 
For the NVidia cards I backported the 2.6.34 nouvoua driver in 2.6.32
and used that - it is pretty stable and even the experimental Gallium
drivers (3D) work well.

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5

[Jeremy Fitzhardinge]

  On 08/06/2010 07:06 AM, Konrad Rzeszutek Wilk wrote:
> Hey Jeremy,
>
> Please pull from devel/pat (based off your xen/dom0/core tree) which
> has one patch:
>
> Konrad Rzeszutek Wilk (1):
>        xen/pat: make pte_flags(x) a pvops function.
>
> which is neccessary for the drivers/gpu/drm/radeon driver to work
> properly with AGP based cards (which look to be the only ones that
> try to set WC on pages).

Hm.  I introduced pte_flags() so that code which wants to get the flags 
but not the pfn can do so without needing to make a pvops call, which 
significantly reduces the number of pvops calls in the mm code.

However, the original rationale for making it non-pvops - nobody fiddles 
with pte flags - is no longer true with the PAT translation.  And it is 
pretty ugly that pte_val and pte_flags will return different flags for a 
pte.  But I'm still leery about imposing the cost of making pte_flags a 
pvop.

Why is it needed?  Could the AGP/Radeon code use pte_val to get the 
flags values it wants?

> Also please pull from devel/kms.fixes-05 (based off your xen/dom0/agp)
> which has the following patches:
>
> Daniel De Graaf (1):
>        fb: propagate VM_IO to VMA.
>
> Konrad Rzeszutek Wilk (10):
>        ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under 4GB under Xen.
>        ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set.
>        agp: Use Xen back-door to get bus address for legacy code.
>        agp: Program the GART with the real physical address under Xen.
>        agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
>        agp-backend: Use Xen back-door to get bus address for scratch page.
>        intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.
>        intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0
>        amd64-agp:Use Xen back-door to get page's physical address for AMD64 chipsets.
>        ttm: Change VMA flags if they != to the TTM flags.
>
> Some of them are marked as not for upstream consumption, while some of
> the other are OK (and Daniel's is upstream). Those patches from both
> branches make it possible to have Xorg working with the following
> graphics cards on the PVOPS kernel:

I assume this depends on the pte_flags change?

> RIVA TNT2 Pro
> GeForce 1 256
> GeForce 4 Ti 4200
> GeForce 6150
> GeForce 6200
> GeForce 7300
> GeForce 8600 GT
> Radeon R100 QD (7200)
> Radeon RV100QY (7000)
> Radeon HD 3200
> Radeon HD 3450
> Radeon RV710 [Radeon HD 4350]
> Radeon ES1000
> ICH5 82865G
> ICH7 82G33/G31G
> ICH8 82Q963/Q965
> Matrox G450
> XGI Z7/Z9 (XG20 core)
>
> Testing was carried out using Fedora Core 13, Fedora Core 11, and Ubuntu
> Lucid 10.04 with the PVOPS kernel.
>
> The details are located at http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> For the NVidia cards I backported the 2.6.34 nouvoua driver in 2.6.32
> and used that - it is pretty stable and even the experimental Gallium
> drivers (3D) work well.

     J

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5

[Konrad Rzeszutek Wilk]

On Fri, Aug 06, 2010 at 09:03:01AM -0700, Jeremy Fitzhardinge wrote:
>  On 08/06/2010 07:06 AM, Konrad Rzeszutek Wilk wrote:
> >Hey Jeremy,
> >
> >Please pull from devel/pat (based off your xen/dom0/core tree) which
> >has one patch:
> >
> >Konrad Rzeszutek Wilk (1):
> >       xen/pat: make pte_flags(x) a pvops function.
> >
> >which is neccessary for the drivers/gpu/drm/radeon driver to work
> >properly with AGP based cards (which look to be the only ones that
> >try to set WC on pages).
> 
> Hm.  I introduced pte_flags() so that code which wants to get the
> flags but not the pfn can do so without needing to make a pvops
> call, which significantly reduces the number of pvops calls in the
> mm code.
> 
> However, the original rationale for making it non-pvops - nobody
> fiddles with pte flags - is no longer true with the PAT translation.
> And it is pretty ugly that pte_val and pte_flags will return
> different flags for a pte.  But I'm still leery about imposing the
> cost of making pte_flags a pvop.
> 
> Why is it needed?  Could the AGP/Radeon code use pte_val to get the
> flags values it wants?

So it isn't really the radeon code that fiddles with this. It is the 
CPA code.

The first fix I came with was this:

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index dd38bfb..42fc7fb 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -23,7 +23,7 @@
 #include <asm/pgalloc.h>
 #include <asm/proto.h>
 #include <asm/pat.h>
-
+#include <xen/xen.h>
 /*
  * The current flushing context - we pass it instead of 5 arguments:
  */
@@ -616,6 +616,10 @@ repeat:
 		pgprot_t new_prot = pte_pgprot(old_pte);
 		unsigned long pfn = pte_pfn(old_pte);
 
+		if (xen_pv_domain() && (pgprot_val(new_prot) & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
+                	pgprot_val(new_prot) = (pgprot_val(new_prot) & ~_PAGE_PAT) | _PAGE_PWT;
+        	}
+
 		pgprot_val(new_prot) &= ~pgprot_val(cpa->mask_clr);
 		pgprot_val(new_prot) |= pgprot_val(cpa->mask_set);
 
(just typed it up, the machine with the patch is offline). But it is kind of ugly.

The other option is to remove the WARN_ON in the arch/x86xen/mmu.c for
xen_make_pte and also copy some of the logic from xen_pte_val to remove
the offending flag. 


>  
> >Also please pull from devel/kms.fixes-05 (based off your xen/dom0/agp)
> >which has the following patches:
> >
> >Daniel De Graaf (1):
> >       fb: propagate VM_IO to VMA.
> >
> >Konrad Rzeszutek Wilk (10):
> >       ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under 4GB under Xen.
> >       ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set.
> >       agp: Use Xen back-door to get bus address for legacy code.
> >       agp: Program the GART with the real physical address under Xen.
> >       agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen.
> >       agp-backend: Use Xen back-door to get bus address for scratch page.
> >       intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses.
> >       intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0
> >       amd64-agp:Use Xen back-door to get page's physical address for AMD64 chipsets.
> >       ttm: Change VMA flags if they != to the TTM flags.
> >
> >Some of them are marked as not for upstream consumption, while some of
> >the other are OK (and Daniel's is upstream). Those patches from both
> >branches make it possible to have Xorg working with the following
> >graphics cards on the PVOPS kernel:
> 
> I assume this depends on the pte_flags change?

It only appeared on the Radeon R100 (7000) which is an ancient AGP video card.
(and also on the Radeon 7200)

And the problem you encounter if you don't have the fix is a stream of
WARN in the kernel, nothing else. So you can pull in this branch without
affecting negativly folks and I can work on a providing a better
solution for the pte_flags(x) issue next week.


> >RIVA TNT2 Pro
> >GeForce 1 256
> >GeForce 4 Ti 4200
> >GeForce 6150
> >GeForce 6200
> >GeForce 7300
> >GeForce 8600 GT
> >Radeon R100 QD (7200)
> >Radeon RV100QY (7000)
> >Radeon HD 3200
> >Radeon HD 3450
> >Radeon RV710 [Radeon HD 4350]
> >Radeon ES1000
> >ICH5 82865G
> >ICH7 82G33/G31G
> >ICH8 82Q963/Q965
> >Matrox G450
> >XGI Z7/Z9 (XG20 core)
> >
> >Testing was carried out using Fedora Core 13, Fedora Core 11, and Ubuntu
> >Lucid 10.04 with the PVOPS kernel.
> >
> >The details are located at http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> >For the NVidia cards I backported the 2.6.34 nouvoua driver in 2.6.32
> >and used that - it is pretty stable and even the experimental Gallium
> >drivers (3D) work well.
> 
>     J

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5

[Pasi Kärkkäinen]

On Fri, Aug 06, 2010 at 10:06:09AM -0400, Konrad Rzeszutek Wilk wrote:
> 
> Some of them are marked as not for upstream consumption, while some of
> the other are OK (and Daniel's is upstream). Those patches from both
> branches make it possible to have Xorg working with the following
> graphics cards on the PVOPS kernel:
> 
> RIVA TNT2 Pro
> GeForce 1 256
> GeForce 4 Ti 4200
> GeForce 6150
> GeForce 6200
> GeForce 7300
> GeForce 8600 GT
> Radeon R100 QD (7200)
> Radeon RV100QY (7000)
> Radeon HD 3200
> Radeon HD 3450
> Radeon RV710 [Radeon HD 4350]
> Radeon ES1000
> ICH5 82865G
> ICH7 82G33/G31G
> ICH8 82Q963/Q965
> Matrox G450
> XGI Z7/Z9 (XG20 core)
> 
> Testing was carried out using Fedora Core 13, Fedora Core 11, and Ubuntu
> Lucid 10.04 with the PVOPS kernel.
> 
> The details are located at http://wiki.xensource.com/xenwiki/XenPVOPSDRM 
> For the NVidia cards I backported the 2.6.34 nouvoua driver in 2.6.32
> and used that - it is pretty stable and even the experimental Gallium
> drivers (3D) work well.
> 

Hello,

I just tried the latest 2.6.32.19 kernel from xen/stable-2.6.32.x branch,
which now includes the kms.fixes-0.5, on my radeon/supermicro testbox.

.. And KMS modesetting works properly now in Xen dom0! 
My onboard ATI Radeon is the following:

# lspci -v | grep VGA
11:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller])

It seems also X starts OK, and I can use the Gnome desktop. 
I could even run multiple OpenGL 3D applications! (ok, glxgears :)

Thanks, great work!

-- Pasi

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5 / dma-api check_unmap() warning

[Pasi Kärkkäinen]

On Sun, Aug 15, 2010 at 11:41:25PM +0300, Pasi Kärkkäinen wrote:
> On Fri, Aug 06, 2010 at 10:06:09AM -0400, Konrad Rzeszutek Wilk wrote:
> > 
> > Some of them are marked as not for upstream consumption, while some of
> > the other are OK (and Daniel's is upstream). Those patches from both
> > branches make it possible to have Xorg working with the following
> > graphics cards on the PVOPS kernel:
> > 
> > RIVA TNT2 Pro
> > GeForce 1 256
> > GeForce 4 Ti 4200
> > GeForce 6150
> > GeForce 6200
> > GeForce 7300
> > GeForce 8600 GT
> > Radeon R100 QD (7200)
> > Radeon RV100QY (7000)
> > Radeon HD 3200
> > Radeon HD 3450
> > Radeon RV710 [Radeon HD 4350]
> > Radeon ES1000
> > ICH5 82865G
> > ICH7 82G33/G31G
> > ICH8 82Q963/Q965
> > Matrox G450
> > XGI Z7/Z9 (XG20 core)
> > 
> > Testing was carried out using Fedora Core 13, Fedora Core 11, and Ubuntu
> > Lucid 10.04 with the PVOPS kernel.
> > 
> > The details are located at http://wiki.xensource.com/xenwiki/XenPVOPSDRM 
> > For the NVidia cards I backported the 2.6.34 nouvoua driver in 2.6.32
> > and used that - it is pretty stable and even the experimental Gallium
> > drivers (3D) work well.
> > 
> 
> Hello,
> 
> I just tried the latest 2.6.32.19 kernel from xen/stable-2.6.32.x branch,
> which now includes the kms.fixes-0.5, on my radeon/supermicro testbox.
> 
> .. And KMS modesetting works properly now in Xen dom0! 
> My onboard ATI Radeon is the following:
> 
> # lspci -v | grep VGA
> 11:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller])
> 
> It seems also X starts OK, and I can use the Gnome desktop. 
> I could even run multiple OpenGL 3D applications! (ok, glxgears :)
> 
> Thanks, great work!
> 

Hmm, actually it seems I got this in dom0 dmesg:

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:802 check_unmap+0x18f/0x615()
Hardware name: X7SB4/E
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000002eecc000] [size=4096 bytes]
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xen_gntdev xen_evtchn xenfs uinput e1000e shpchp iTCO_wdt serio_raw i2c_i801 iTCO_vendor_support joydev pcspkr floppy usb_storage video aic79xx output scsi_transport_spi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 15, comm: events/0 Not tainted 2.6.32.19 #1
Call Trace:
 [<ffffffff81059e05>] warn_slowpath_common+0x7c/0x94
 [<ffffffff81059e74>] warn_slowpath_fmt+0x41/0x43
 [<ffffffff8124d6d5>] ? check_unmap+0x100/0x615
 [<ffffffff8124a7ab>] ? xen_virt_to_bus+0x11/0x13
 [<ffffffff8124d764>] check_unmap+0x18f/0x615
 [<ffffffff8100eca1>] ? xen_force_evtchn_callback+0xd/0xf
 [<ffffffff8100f3d2>] ? check_events+0x12/0x20
 [<ffffffff8124dc56>] debug_dma_free_coherent+0x6c/0x7a
 [<ffffffffa00411d3>] ttm_tt_free_alloced_pages+0x129/0x180 [ttm]
 [<ffffffffa00415fd>] ttm_tt_destroy+0x4d/0x8f [ttm]
 [<ffffffffa0041c00>] ttm_bo_release_list+0x96/0xd5 [ttm]
 [<ffffffffa0041b6a>] ? ttm_bo_release_list+0x0/0xd5 [ttm]
 [<ffffffff8123cc75>] kref_put+0x43/0x4d
 [<ffffffffa0042c1d>] ttm_bo_delayed_delete+0xad/0x121 [ttm]
 [<ffffffffa0042cb0>] ttm_bo_delayed_workqueue+0x1f/0x34 [ttm]
 [<ffffffff810754a2>] worker_thread+0x257/0x350
 [<ffffffff8107544a>] ? worker_thread+0x1ff/0x350
 [<ffffffffa0042c91>] ? ttm_bo_delayed_workqueue+0x0/0x34 [ttm]
 [<ffffffff81079f26>] ? autoremove_wake_function+0x0/0x39
 [<ffffffff8107524b>] ? worker_thread+0x0/0x350
 [<ffffffff81079c54>] kthread+0x7f/0x87
 [<ffffffff81013dea>] child_rip+0xa/0x20
 [<ffffffff81013750>] ? restore_args+0x0/0x30
 [<ffffffff81013de0>] ? child_rip+0x0/0x20
---[ end trace 84e813abe3a8bd4d ]---
fuse init (API version 7.13)
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
DMA-API: debugging out of memory - disabling


The system is up-to-date Fedora 13, with xen/stable-2.6.32.x dom0 kernel.

Not fatal, things still seem to work..


-- Pasi

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5 / dma-api check_unmap() warning

[Konrad Rzeszutek Wilk]

> > Hello,
> > 
> > I just tried the latest 2.6.32.19 kernel from xen/stable-2.6.32.x branch,
> > which now includes the kms.fixes-0.5, on my radeon/supermicro testbox.
> > 
> > .. And KMS modesetting works properly now in Xen dom0! 
> > My onboard ATI Radeon is the following:
> > 
> > # lspci -v | grep VGA
> > 11:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller])
> > 
> > It seems also X starts OK, and I can use the Gnome desktop. 
> > I could even run multiple OpenGL 3D applications! (ok, glxgears :)
> > 
> > Thanks, great work!
> > 
> 
> Hmm, actually it seems I got this in dom0 dmesg:

Good. I had seen this a month ago when I upgraded to FC13 (when it was
rawhide) and it disappeared once I upgraded to the real FC13. So I
blamed it on the alpha-rawhide X org driver. I could not reproduce this on
FC13 with an ES1000 in a SuperMicro (some X8DBN+).

So, can you send to me, please:

 - lspci -vvvv
 - cat /var/log/Xorg.0.log
 - rpm -qa
 - dmidecode
 - dmesg
 - xl dmesg

That way I should have enough data to see if I can track this errant
issue down.
> 
> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:802 check_unmap+0x18f/0x615()
> Hardware name: X7SB4/E
> NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000002eecc000] [size=4096 bytes]
> Modules linked in: ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xen_gntdev xen_evtchn xenfs uinput e1000e shpchp iTCO_wdt serio_raw i2c_i801 iTCO_vendor_support joydev pcspkr floppy usb_storage video aic79xx output scsi_transport_spi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
> Pid: 15, comm: events/0 Not tainted 2.6.32.19 #1
> Call Trace:
>  [<ffffffff81059e05>] warn_slowpath_common+0x7c/0x94
>  [<ffffffff81059e74>] warn_slowpath_fmt+0x41/0x43
>  [<ffffffff8124d6d5>] ? check_unmap+0x100/0x615
>  [<ffffffff8124a7ab>] ? xen_virt_to_bus+0x11/0x13
>  [<ffffffff8124d764>] check_unmap+0x18f/0x615
>  [<ffffffff8100eca1>] ? xen_force_evtchn_callback+0xd/0xf
>  [<ffffffff8100f3d2>] ? check_events+0x12/0x20
>  [<ffffffff8124dc56>] debug_dma_free_coherent+0x6c/0x7a
>  [<ffffffffa00411d3>] ttm_tt_free_alloced_pages+0x129/0x180 [ttm]
>  [<ffffffffa00415fd>] ttm_tt_destroy+0x4d/0x8f [ttm]
>  [<ffffffffa0041c00>] ttm_bo_release_list+0x96/0xd5 [ttm]
>  [<ffffffffa0041b6a>] ? ttm_bo_release_list+0x0/0xd5 [ttm]
>  [<ffffffff8123cc75>] kref_put+0x43/0x4d
>  [<ffffffffa0042c1d>] ttm_bo_delayed_delete+0xad/0x121 [ttm]
>  [<ffffffffa0042cb0>] ttm_bo_delayed_workqueue+0x1f/0x34 [ttm]
>  [<ffffffff810754a2>] worker_thread+0x257/0x350
>  [<ffffffff8107544a>] ? worker_thread+0x1ff/0x350
>  [<ffffffffa0042c91>] ? ttm_bo_delayed_workqueue+0x0/0x34 [ttm]
>  [<ffffffff81079f26>] ? autoremove_wake_function+0x0/0x39
>  [<ffffffff8107524b>] ? worker_thread+0x0/0x350
>  [<ffffffff81079c54>] kthread+0x7f/0x87
>  [<ffffffff81013dea>] child_rip+0xa/0x20
>  [<ffffffff81013750>] ? restore_args+0x0/0x30
>  [<ffffffff81013de0>] ? child_rip+0x0/0x20
> ---[ end trace 84e813abe3a8bd4d ]---
> fuse init (API version 7.13)
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> DMA-API: debugging out of memory - disabling
> 
> 
> The system is up-to-date Fedora 13, with xen/stable-2.6.32.x dom0 kernel.
> 
> Not fatal, things still seem to work..

Is this during shutdown or startup?

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5 / dma-api check_unmap() warning

[Pasi Kärkkäinen]

On Mon, Aug 16, 2010 at 12:31:33PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Hello,
> > > 
> > > I just tried the latest 2.6.32.19 kernel from xen/stable-2.6.32.x branch,
> > > which now includes the kms.fixes-0.5, on my radeon/supermicro testbox.
> > > 
> > > .. And KMS modesetting works properly now in Xen dom0! 
> > > My onboard ATI Radeon is the following:
> > > 
> > > # lspci -v | grep VGA
> > > 11:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller])
> > > 
> > > It seems also X starts OK, and I can use the Gnome desktop. 
> > > I could even run multiple OpenGL 3D applications! (ok, glxgears :)
> > > 
> > > Thanks, great work!
> > > 
> > 
> > Hmm, actually it seems I got this in dom0 dmesg:
> 
> Good. I had seen this a month ago when I upgraded to FC13 (when it was
> rawhide) and it disappeared once I upgraded to the real FC13. So I
> blamed it on the alpha-rawhide X org driver. I could not reproduce this on
> FC13 with an ES1000 in a SuperMicro (some X8DBN+).
> 
> So, can you send to me, please:
> 
>  - lspci -vvvv
>  - cat /var/log/Xorg.0.log
>  - rpm -qa
>  - dmidecode
>  - dmesg
>  - xl dmesg
> 
> That way I should have enough data to see if I can track this errant
> issue down.
>

All of that is now here:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeon-info-for-konrad/



> > 
> > ------------[ cut here ]------------
> > WARNING: at lib/dma-debug.c:802 check_unmap+0x18f/0x615()
> > Hardware name: X7SB4/E
> > NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000002eecc000] [size=4096 bytes]
> > Modules linked in: ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xen_gntdev xen_evtchn xenfs uinput e1000e shpchp iTCO_wdt serio_raw i2c_i801 iTCO_vendor_support joydev pcspkr floppy usb_storage video aic79xx output scsi_transport_spi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
> > Pid: 15, comm: events/0 Not tainted 2.6.32.19 #1
> > Call Trace:
> >  [<ffffffff81059e05>] warn_slowpath_common+0x7c/0x94
> >  [<ffffffff81059e74>] warn_slowpath_fmt+0x41/0x43
> >  [<ffffffff8124d6d5>] ? check_unmap+0x100/0x615
> >  [<ffffffff8124a7ab>] ? xen_virt_to_bus+0x11/0x13
> >  [<ffffffff8124d764>] check_unmap+0x18f/0x615
> >  [<ffffffff8100eca1>] ? xen_force_evtchn_callback+0xd/0xf
> >  [<ffffffff8100f3d2>] ? check_events+0x12/0x20
> >  [<ffffffff8124dc56>] debug_dma_free_coherent+0x6c/0x7a
> >  [<ffffffffa00411d3>] ttm_tt_free_alloced_pages+0x129/0x180 [ttm]
> >  [<ffffffffa00415fd>] ttm_tt_destroy+0x4d/0x8f [ttm]
> >  [<ffffffffa0041c00>] ttm_bo_release_list+0x96/0xd5 [ttm]
> >  [<ffffffffa0041b6a>] ? ttm_bo_release_list+0x0/0xd5 [ttm]
> >  [<ffffffff8123cc75>] kref_put+0x43/0x4d
> >  [<ffffffffa0042c1d>] ttm_bo_delayed_delete+0xad/0x121 [ttm]
> >  [<ffffffffa0042cb0>] ttm_bo_delayed_workqueue+0x1f/0x34 [ttm]
> >  [<ffffffff810754a2>] worker_thread+0x257/0x350
> >  [<ffffffff8107544a>] ? worker_thread+0x1ff/0x350
> >  [<ffffffffa0042c91>] ? ttm_bo_delayed_workqueue+0x0/0x34 [ttm]
> >  [<ffffffff81079f26>] ? autoremove_wake_function+0x0/0x39
> >  [<ffffffff8107524b>] ? worker_thread+0x0/0x350
> >  [<ffffffff81079c54>] kthread+0x7f/0x87
> >  [<ffffffff81013dea>] child_rip+0xa/0x20
> >  [<ffffffff81013750>] ? restore_args+0x0/0x30
> >  [<ffffffff81013de0>] ? child_rip+0x0/0x20
> > ---[ end trace 84e813abe3a8bd4d ]---
> > fuse init (API version 7.13)
> > end_request: I/O error, dev fd0, sector 0
> > end_request: I/O error, dev fd0, sector 0
> > DMA-API: debugging out of memory - disabling
> > 
> > 
> > The system is up-to-date Fedora 13, with xen/stable-2.6.32.x dom0 kernel.
> > 
> > Not fatal, things still seem to work..
> 
> Is this during shutdown or startup?
>

That warning/calltrace happens when starting X ..


-- Pasi

Re: [GIT PULL] devel/pat + devel/kms.fixes-0.5 / dma-api check_unmap() warning

[Konrad Rzeszutek Wilk]

> All of that is now here:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeon-info-for-konrad/

Ok, now I can reproduce it with an updated version of Xorg. For weird reasons
using Xorg 1.8.0 didn't trigger this, while Xorg 1.8.2 did.

The xorg-x11-drv-ati remained at the same version, so did the kernel.