<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu, branch v3.18.9</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/radeon: properly set vm fragment size for TN/RL</title>
<updated>2015-02-11T07:00:54+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2015-01-30T14:52:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4fb5076bf3be220b86b9971e92b68657a6eb9080'/>
<id>4fb5076bf3be220b86b9971e92b68657a6eb9080</id>
<content type='text'>
commit a124d068bf5be6be2ff4b9fab77b1b7509107e68 upstream.

Should be the same as cayman.  We don't use VM by default
on NI parts so this isn't critical.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a124d068bf5be6be2ff4b9fab77b1b7509107e68 upstream.

Should be the same as cayman.  We don't use VM by default
on NI parts so this isn't critical.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix the crash in test functions</title>
<updated>2015-02-11T07:00:54+00:00</updated>
<author>
<name>Ilija Hadzic</name>
<email>ilijahadzic@gmail.com</email>
</author>
<published>2015-01-30T05:38:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=83108f22385e9f34761dc3a0c77bdc985a467e77'/>
<id>83108f22385e9f34761dc3a0c77bdc985a467e77</id>
<content type='text'>
commit 92b712b739811e4aa7c0e1af339d0098989ea024 upstream.

radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from vram BO.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Ilija Hadzic &lt;ihadzic@research.bell-labs.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 92b712b739811e4aa7c0e1af339d0098989ea024 upstream.

radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from vram BO.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Ilija Hadzic &lt;ihadzic@research.bell-labs.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix the crash in benchmark functions</title>
<updated>2015-02-11T07:00:54+00:00</updated>
<author>
<name>Ilija Hadzic</name>
<email>ilijahadzic@gmail.com</email>
</author>
<published>2015-01-30T05:38:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=624ddd1be9fcd6fd30ce5563e87dfd27ab920a68'/>
<id>624ddd1be9fcd6fd30ce5563e87dfd27ab920a68</id>
<content type='text'>
commit 3f5e1b4f58b7b6480cccff4bf965436102db4346 upstream.

radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from destination BO.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Ilija Hadzic &lt;ihadzic@research.bell-labs.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3f5e1b4f58b7b6480cccff4bf965436102db4346 upstream.

radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from destination BO.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Ilija Hadzic &lt;ihadzic@research.bell-labs.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix PLLs on RS880 and older v2</title>
<updated>2015-02-11T07:00:54+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2015-01-29T15:01:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7530584f8c7d2ded28dd72e0dbf17c2bff085107'/>
<id>7530584f8c7d2ded28dd72e0dbf17c2bff085107</id>
<content type='text'>
commit 72edd83cc9e5819ed1ee771519143d7594e059f0 upstream.

This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.

v2: fix signed/unsigned warning

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=91861
https://bugzilla.kernel.org/show_bug.cgi?id=83461

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 72edd83cc9e5819ed1ee771519143d7594e059f0 upstream.

This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.

v2: fix signed/unsigned warning

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=91861
https://bugzilla.kernel.org/show_bug.cgi?id=83461

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: don't init gpuvm if accel is disabled (v3)</title>
<updated>2015-02-11T07:00:54+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2015-01-28T19:36:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2a1398b3317fbc5d2efe1c0089dc56414286dc6b'/>
<id>2a1398b3317fbc5d2efe1c0089dc56414286dc6b</id>
<content type='text'>
commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream.

If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it.  Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.

v2: handle vm_fini as well
v3: handle bo_open/close as well

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream.

If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it.  Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.

v2: handle vm_fini as well
v3: handle bo_open/close as well

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: fix inconsistent brightness after resume</title>
<updated>2015-02-06T06:36:08+00:00</updated>
<author>
<name>Jeremiah Mahler</name>
<email>jmmahler@gmail.com</email>
</author>
<published>2015-01-12T19:01:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=77ca136e76732ec03cc71c8b802c5fef8a70e0dd'/>
<id>77ca136e76732ec03cc71c8b802c5fef8a70e0dd</id>
<content type='text'>
commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream.

commit 6dda730e55f412a6dfb181cae6784822ba463847
Author: Jani Nikula &lt;jani.nikula@intel.com&gt;
Date:   Tue Jun 24 18:27:40 2014 +0300

    drm/i915: respect the VBT minimum backlight brightness

introduced a bug which resulted in inconsistent brightness levels on
different machines. If a suspended was entered with the screen off some
machines would resume with the screen at minimum brightness and others
at maximum brightness.

The following commands can be used to produce this behavior.

  xset dpms force off
  sleep 1
  sudo systemctl suspend
  (resume ...)

The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled.  If it is zero,
it is set to the maximum level.  Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.

Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero.  Also, expand the comparison for
the possible case when the level is less than the minimum.

Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler &lt;jmmahler@gmail.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream.

commit 6dda730e55f412a6dfb181cae6784822ba463847
Author: Jani Nikula &lt;jani.nikula@intel.com&gt;
Date:   Tue Jun 24 18:27:40 2014 +0300

    drm/i915: respect the VBT minimum backlight brightness

introduced a bug which resulted in inconsistent brightness levels on
different machines. If a suspended was entered with the screen off some
machines would resume with the screen at minimum brightness and others
at maximum brightness.

The following commands can be used to produce this behavior.

  xset dpms force off
  sleep 1
  sudo systemctl suspend
  (resume ...)

The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled.  If it is zero,
it is set to the maximum level.  Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.

Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero.  Also, expand the comparison for
the possible case when the level is less than the minimum.

Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler &lt;jmmahler@gmail.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: Init PPGTT before context enable</title>
<updated>2015-02-06T06:36:08+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw2@infradead.org</email>
</author>
<published>2015-01-20T17:21:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=50a466845fafb078ff44be9389ac767347ff8bc6'/>
<id>50a466845fafb078ff44be9389ac767347ff8bc6</id>
<content type='text'>
commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream.

Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing
ppgtt") introduced a regression on Broadwell, triggering the following
IOMMU fault at startup:

  vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
  dmar: DRHD: handling fault status reg 2
  dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000
  DMAR:[fault reason 23] Unknown
  fbcon: inteldrmfb (fb0) is primary device

Further commentary from Daniel:

I sugggested this change to David after staring at the offending patch
for a while. I have no idea and theory whatsoever why this would upset
the gpu less than the other way round. But it seems to work. David
promised to chase hw people a bit more to get a more meaningful answer.

Wrt the comment that this deletes: I've done some digging and afaict
loading context before ppgtt enable was once required before our recent
restructuring of the context/ppgtt init code: Before that context sw
setup (i.e. allocating the default context) and hw setup was smashed
together.  Also the setup of the default context was the bit that
actually allocated the aliasing ppgtt structures. Which is the reason
for the context before ppgtt depency.

Or was, since with all the untangling there's no no real depency any
more (functional, who knows what the hw is doing), so the comment is
just stale.

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream.

Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing
ppgtt") introduced a regression on Broadwell, triggering the following
IOMMU fault at startup:

  vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
  dmar: DRHD: handling fault status reg 2
  dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000
  DMAR:[fault reason 23] Unknown
  fbcon: inteldrmfb (fb0) is primary device

Further commentary from Daniel:

I sugggested this change to David after staring at the offending patch
for a while. I have no idea and theory whatsoever why this would upset
the gpu less than the other way round. But it seems to work. David
promised to chase hw people a bit more to get a more meaningful answer.

Wrt the comment that this deletes: I've done some digging and afaict
loading context before ppgtt enable was once required before our recent
restructuring of the context/ppgtt init code: Before that context sw
setup (i.e. allocating the default context) and hw setup was smashed
together.  Also the setup of the default context was the bit that
actually allocated the aliasing ppgtt structures. Which is the reason
for the context before ppgtt depency.

Or was, since with all the untangling there's no no real depency any
more (functional, who knows what the hw is doing), so the comment is
just stale.

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: BDW Fix Halo PCI IDs marked as ULT.</title>
<updated>2015-02-06T06:36:08+00:00</updated>
<author>
<name>Rodrigo Vivi</name>
<email>rodrigo.vivi@intel.com</email>
</author>
<published>2015-01-20T00:16:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bcee607f44722b338e65f62ac5ff426894c704b8'/>
<id>bcee607f44722b338e65f62ac5ff426894c704b8</id>
<content type='text'>
commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream.

BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.

v2: forgot ammend and v1 doesn't compile

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang &lt;xiong.y.zhang@intel.com&gt;
Cc: Guo Jinxian &lt;jinxianx.guo@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream.

BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.

v2: forgot ammend and v1 doesn't compile

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang &lt;xiong.y.zhang@intel.com&gt;
Cc: Guo Jinxian &lt;jinxianx.guo@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: Only fence tiled region of object.</title>
<updated>2015-02-06T06:36:08+00:00</updated>
<author>
<name>Bob Paauwe</name>
<email>bob.j.paauwe@intel.com</email>
</author>
<published>2014-12-18T17:51:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=817697b83f3c399018c7c6bc25be68c5453b14c8'/>
<id>817697b83f3c399018c7c6bc25be68c5453b14c8</id>
<content type='text'>
commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena &lt;danh@ghs.com&gt;
Signed-off-by: Bob Paauwe &lt;bob.j.paauwe@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena &lt;danh@ghs.com&gt;
Signed-off-by: Bob Paauwe &lt;bob.j.paauwe@intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm: fix fb-helper vs MST dangling connector ptrs (v2)</title>
<updated>2015-02-06T06:36:08+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2015-01-26T15:11:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e63fea163319d9784abc0c82aeaef451cc80116e'/>
<id>e63fea163319d9784abc0c82aeaef451cc80116e</id>
<content type='text'>
commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream.

VT switch back/forth from console to xserver (for example) has potential
to go horribly wrong if a dynamic DP MST connector ends up in the saved
modeset that is restored when switching back to fbcon.

When removing a dynamic connector, don't forget to clean up the saved
state.

v1: original
v2: null out set-&gt;fb if no more connectors to avoid making i915 cranky

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream.

VT switch back/forth from console to xserver (for example) has potential
to go horribly wrong if a dynamic DP MST connector ends up in the saved
modeset that is restored when switching back to fbcon.

When removing a dynamic connector, don't forget to clean up the saved
state.

v1: original
v2: null out set-&gt;fb if no more connectors to avoid making i915 cranky

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
