n pgprot.
>
> Remove the NULL pointer check for the map. These functions return a valid
> address for valid pages and the return was bogus anyway as it would have
> left preemption and pagefaults disabled.
>
> Signed-off-by: Thomas Gleixner
> Cc: VMware Graphics
> Cc: Rola
The vmwgfx ones look all good to me, so for
23-53: Reviewed-by: Roland Scheidegger
That said, they were already signed off by Zack, so not sure what
happened here.
Roland
On 03.03.21 14:42, Lee Jones wrote:
> This is a resend. All of these patches have been sent before.
>
> The vm
he node pointer to NULL. Unfortunately
> vmwgfx still had two places where it was explicitly converting
> -ENOSPC to 0 causing regressions. This fixes those spots by
> allowing -ENOSPC to be returned. That seems to fix recent
> regressions with vmwgfx.
>
> Signed-off-by: Zack Rusin
>
Signed-off-by: Zack Rusin
> Reviewed-by: Roland Scheidegger
> Reviewed-by: Martin Krastev
> Sigend-off-by: Roland Scheidegger
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +-
>
I'm now able to reproduce this, looking into it. (The crash looks
actually similar to what was also happening with the next commit,
drm/ttm: make TT creation purely optional v3, but that got reverted
already.)
Roland
Am 19.08.20 um 09:47 schrieb 허종만:
>
> Hi,
>
>
> I'm running Linux guest OS (
Thanks, I've put the fix in the vmwgfx-next branch.
Roland
Am 10.08.20 um 12:04 schrieb Colin King:
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_ERROR message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> 1 file changed, 1
I've commited this to our next branch, thanks!
(I'm actually kind of impressed this can be found automatically...)
Roland
Am 17.06.20 um 23:51 schrieb Gustavo A. R. Silva:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
>
I've pulled that into our tree, thanks!
Roland
Am 07.05.20 um 13:07 schrieb Jason Yan:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:518:9-10: WARNING: return of 0/1
> in function 'vmw_fence_obj_signaled' with return type bool
>
> Signed-off-by: Jason Yan
>
I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger
Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> su
rectly because the TSC would change).
(And I'd guess better avoid an armed deadline timer while changing
TSC_ADJ...)
In any case, I've tested the two patches on top of x86-timers and they
work just fine - all TSC_ADJ values get set to zero both on boot and
resume, no lockups, and tsc clocks
Am 13.12.2016 um 17:46 schrieb Thomas Gleixner:
> On Tue, 13 Dec 2016, Roland Scheidegger wrote:
>
>> Am 13.12.2016 um 14:14 schrieb Thomas Gleixner:
>>> Roland reported interesting TSC ADJUST register wreckage on his DELL
>>> machine, which seems to populate
Am 13.12.2016 um 14:14 schrieb Thomas Gleixner:
> Roland reported interesting TSC ADJUST register wreckage on his DELL
> machine, which seems to populate that MSR with a random number generator.
FWIW, I thought about the actual values some more and I don't actually
think they are all that random a
Am 10.12.2016 um 02:55 schrieb Roland Scheidegger:
> Am 09.12.2016 um 23:59 schrieb Thomas Gleixner:
>> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>>
>> Cc'ed someone from Dell.
>>
>>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner:
>>>> C
Am 09.12.2016 um 23:59 schrieb Thomas Gleixner:
> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>
> Cc'ed someone from Dell.
>
>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner:
>>> Can you add the patch below to gather more information? There is a hunk in
>
Am 09.12.2016 um 18:33 schrieb Thomas Gleixner:
> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>> Am 09.12.2016 um 10:59 schrieb Thomas Gleixner:
>>> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>>>>
>>>> I saw some system lockups though:
>>>>
Am 09.12.2016 um 10:59 schrieb Thomas Gleixner:
> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>>
>> I saw some system lockups though:
>> When doing a cold boot, this kernel never managed to boot up. The last
>> message seen is:
>> x86: Booting SMP configuration:
From: Roland Scheidegger <[EMAIL PROTECTED]>
The i8042 driver fails detection of the AUX port with some chips,
because they apparently do not change the I8042_CTR_AUXDIS bit
immediately. This is known to affect at least HP500 / HP510 notebooks,
consequently the built-in touchpad will no
Helge Hafting wrote:
Since it crashes even without 3d sometimes, the problem does not
seem to be related to dri (as in, dri driver).
Stable as rock, _if_ Load "dri" is commented out from xorg.conf (or
from XF86Config-4)
Well, commenting that out makes the 2d ddx driver not to use the CP, drm
etc
Helge Hafting wrote:
I have reported this before, but now I have some more data.
I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE]
In previous reports I found that starting xfree or xorg with dri support
cause a hang after a
19 matches
Mail list logo
