offending pages around when vxd392 attaches - i.e. we need to check the
attached device's dma masks and if there's something offending, migrate
the buffer with a differen shmem allocation mask. Iirc Alan Cox had
patches to do just that (but for swapoff, still the same idea though).
On Sat, 2014-03-08 at 11:25 -0800, Sean V Kelley wrote:
On Saturday 08 Mar 2014 at 09:25:54 (+), Chris Wilson writes :
On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
On VLV systems addressing 4GB of memory or greater, memory corruption was
seen
when initializing
On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
On VLV systems addressing 4GB of memory or greater, memory corruption was seen
when initializing and attempting to render VP8 hardware decode surfaces using
the VXD392 HW IP block.
The VXD MMU has a limitation to addressing only
On Sat, Mar 08, 2014 at 09:25:54AM +, Chris Wilson wrote:
On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
On VLV systems addressing 4GB of memory or greater, memory corruption was
seen
when initializing and attempting to render VP8 hardware decode surfaces
using
the
On Saturday 08 Mar 2014 at 09:25:54 (+), Chris Wilson writes :
On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
On VLV systems addressing 4GB of memory or greater, memory corruption was
seen
when initializing and attempting to render VP8 hardware decode surfaces
using
On Saturday 08 Mar 2014 at 11:07:50 (+0100), Daniel Vetter writes :
On Sat, Mar 08, 2014 at 09:25:54AM +, Chris Wilson wrote:
On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
On VLV systems addressing 4GB of memory or greater, memory corruption was
seen
when
