On Wed, Jan 04, 2012 at 04:35:16PM -0500, Konrad Rzeszutek Wilk wrote:
> This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
> when we unbind the device we get this:
> sh-4.1# echo ":00:0d.0" > unbind
> BUG: unable to handle kernel NULL pointer dereference at
On Wed, Jan 04, 2012 at 04:35:16PM -0500, Konrad Rzeszutek Wilk wrote:
This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
when we unbind the device we get this:
sh-4.1# echo :00:0d.0 unbind
BUG: unable to handle kernel NULL pointer dereference at (null)
This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
when we unbind the device we get this:
sh-4.1# echo :00:0d.0 unbind
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [a011ab1
CPU 1
Modules linked in: iscsi_boot_sysfs iscsi_tcp
Hey,
When I use the drm-next tree without the patch it works fine.
(albeit slowly - but I posted the patches for that).
With the patch mentioned I get this:
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE
nForce 430] (rev a2)
sh-4.1# cd :00:0d.0
sh-4.1# cd driver
Hey,
When I use the drm-next tree without the patch it works fine.
(albeit slowly - but I posted the patches for that).
With the patch mentioned I get this:
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE
nForce 430] (rev a2)
sh-4.1# cd :00:0d.0
sh-4.1# cd driver
change v4
Hello Jerome Glisse,
This is a semi-automatic email about new static checker warnings.
The patch dc97b3409a79: "drm/ttm: callback move_notify any time bo
placement change v4" from Nov 18, 2011, leads to the following Smatch
complaint:
drivers/gpu/drm/nouveau/nouveau
change v4
Hello Jerome Glisse,
This is a semi-automatic email about new static checker warnings.
The patch dc97b3409a79: drm/ttm: callback move_notify any time bo
placement change v4 from Nov 18, 2011, leads to the following Smatch
complaint:
drivers/gpu/drm/nouveau/nouveau_bo.c +818
Updated patch
Reviewed-by: Thomas Hellstrom
On 11/20/2011 10:02 PM, Jerome Glisse wrote:
> On Sat, Nov 19, 2011 at 3:45 PM, Thomas Hellstrom
> wrote:
>
>> On 11/19/2011 12:32 AM, j.glisse at gmail.com wrote:
>>
>>> From: Jerome Glisse
>>>
>>> Previously we were calling back
Updated patch
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
On 11/20/2011 10:02 PM, Jerome Glisse wrote:
On Sat, Nov 19, 2011 at 3:45 PM, Thomas Hellstromthellst...@vmware.com wrote:
On 11/19/2011 12:32 AM, j.gli...@gmail.com wrote:
From: Jerome Glissejgli...@redhat.com
em);
>> +
>>
>
>> ?moved:
>> ? ? ? ?if (bo->evicted) {
>> ? ? ? ? ? ? ? ?ret = bdev->driver->invalidate_caches(bdev,
>> bo->mem.placement);
>> @@ -1872,9 +1878,12 @@ static int ttm_bo_swapout(struct ttm_mem_shrink
>> *shrink)
>> ? ? ? ?if (bo->bde
once used for exactly the same
purpose.
ret = ttm_tt_swapout(bo-ttm, bo-persistent_swap_storage);
-out:
+out:
Whitespace.
/Thomas
Attached updated patch
Cheers,
Jerome
0001-drm-ttm-callback-move_notify-any-time-bo-placement-c.patch
Description: Binary data
On 11/19/2011 12:32 AM, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Previously we were calling back move_notify in error path when the
> bo is returned to it's original position or when destroy the bo.
> When destroying the bo set the new mem placement as NULL when calling
> back in the
On 11/19/2011 12:32 AM, j.gli...@gmail.com wrote:
From: Jerome Glissejgli...@redhat.com
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back
On 11/18/2011 06:32 PM, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Previously we were calling back move_notify in error path when the
> bo is returned to it's original position or when destroy the bo.
> When destroying the bo set the new mem placement as NULL when calling
> back in the
From: Jerome Glisse
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with
From: Jerome Glisse
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with
From: Jerome Glisse
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with
From: Jerome Glisse jgli...@redhat.com
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with NULL
On 11/18/2011 06:32 PM, j.gli...@gmail.com wrote:
From: Jerome Glissejgli...@redhat.com
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back
19 matches
Mail list logo