Hi Harry,
As suggested I created the issue here
https://gitlab.freedesktop.org/drm/amd/issues/2 with a picture of the
problem attached.
Please take a look, thx!
Julien
On Mon, Nov 11, 2019 at 1:11 PM Harry Wentland wrote:
> On 2019-10-08 2:15 p.m., Julien Isorce wrote:
> >
Hi, gentle ping ? Thx in advance.
On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce
wrote:
> Hi Harry,
>
> I can reproduce on LG, Samsung and NEC monitors.
>
> "Have you checked whether the driver picks RGB or YCBCR420 without your
> patch?" -> it was selecting
Hi,
Gentle ping ?
Thx
Julien
On Fri, Oct 11, 2019 at 12:31 PM Julien Isorce
wrote:
> Hi Harry,
>
> Do you need more information ?
>
> Thx
> Julien
>
> On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce
> wrote:
>
>> Hi Harry,
>>
>> I can reproduce
Hi Harry,
Do you need more information ?
Thx
Julien
On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce
wrote:
> Hi Harry,
>
> I can reproduce on LG, Samsung and NEC monitors.
>
> "Have you checked whether the driver picks RGB or YCBCR420 without your
> patch?&q
nderstand how the pinkish color issue looks. Do you see
> a pinkish color at the transition from grey to another color? Or is the
> entire grey area pinkish?
>
> Thanks,
> Harry
>
> On 2019-10-08 12:06 p.m., Julien Isorce wrote:
> > Hi,
> >
> > Gen
Hi,
Gentle ping ?
Thx
Julien
On Tue, Oct 1, 2019 at 3:21 PM Julien Isorce
wrote:
> Fix pinkish color issue around grey areas. This also happens
> when not using any dongle so directly with a usb-c to Display
> Port cable. Meaning there is something wrong when using pixel
>
HDMI without dongle.
This way users will see the same thing on 2 identical screens when
one is connected with hdmi-to-hdmi and the other is connected with
usb-c-to-hdmi.
Signed-off-by: Julien Isorce
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
1 file changed, 5 insertions
Hi Monk,
It was more a general question. So you never need to do an electrical
reboot when a gpu reset fails ?
Thx
Julien
On 10 November 2017 at 07:51, Liu, Monk <monk@amd.com> wrote:
> Please share the dmesg log, and what’s the chip are you using ?
>
>
>
>
euc...@gmail.com> wrote:
> On Thu, Nov 9, 2017 at 4:35 AM, Julien Isorce <julien.iso...@gmail.com>
> wrote:
> > Hi Monk.
> >
> > I am interested on this. Currently when a "ring X stalled for more than N
> > sec" happens it usually goes into the
Hi Monk.
I am interested on this. Currently when a "ring X stalled for more than N
sec" happens it usually goes into the gpu reset routine.
Does it always cause the vram to be lost ? Could you explain what happens
if the vram remains lost ?
I am asking this because I experienced some recurrent
Encountered a dozen of exact same backtraces when mesa's
pb_cache_release_all_buffers is called after that a gpu reset failed.
v2: Remove superfluous error message added in v1.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96271
Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
d
_close.
But it will only work if the vm_manager succeeded to be re-enabled
after a gpu reset.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=96271
Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
drivers/gpu/drm/radeon/radeon_object.c | 8 +++-
1 file changed, 7 insertions(+)
led after
a gpu reset while the GFX ring was not responding so accel was disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=96271
Signed-off-by: Julien Isorce <jiso...@oblong.com>
---
drivers/gpu/drm/radeon/radeon_gem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/d
On 24 April 2017 at 10:51, Christian König <deathsim...@vodafone.de> wrote:
> Am 24.04.2017 um 11:42 schrieb Julien Isorce:
>
>> But re-add the flag is the bo is moved back to vram.
>>
>> This fixes "ring 0/3 stalled" issue which happens when the driver
But re-add the flag is the bo is moved back to vram.
This fixes "ring 0/3 stalled" issue which happens when the driver
evicts bo from vram to gtt, at least on TAHITI and CAPVERDE.
I do not know the exact reason among the following:
- si_copy_dma from vram to gtt is slow if WC
(only for
17 um 10:59 schrieb Michel Dänzer:
>>>
>>>> On 28/03/17 08:00 PM, Julien Isorce wrote:
>>>>
>>>>> On 28 March 2017 at 10:36, Michel Dänzer <mic...@daenzer.net
>>>>> <mailto:mic...@daenzer.net>> wrote:
>>>>>
>>>&
On 28 March 2017 at 10:36, Michel Dänzer <mic...@daenzer.net> wrote:
> On 28/03/17 05:24 PM, Julien Isorce wrote:
> > Hi Michel,
> >
> > About the hard lockup, I noticed that I cannot have it with the
> > following conditions:
> >
> > 1. soft lockup fi
erde 2048M )
I am happy to try any other suggestion.
Thx
Julien
On 24 March 2017 at 19:01, Julien Isorce <julien.iso...@gmail.com> wrote:
> Hi Michel,
>
> No this change does not help on the other issue (hard lockup).
> I have no tried it in combination with the 0 -> i c
> results in an infinite loop.
>>
>> Fixes: 2a85aedd117c ("drm/radeon: Try evicting from CPU accessible to
>> inaccessible VRAM first")
>> Reported-by: Zachary Michaels <zmicha...@oblong.com>
>> Reported-and-Tested-by: Julie
Hi Michel,
No this change does not help on the other issue (hard lockup).
I have no tried it in combination with the 0 -> i change.
Thx anyway.
Julien
On 24 March 2017 at 10:03, Michel Dänzer wrote:
> On 24/03/17 12:31 AM, Zachary Michaels wrote:
> >
> > I should also
Hi Michel,
I double checked and you are right, the change 0 -> i works.
Cheers
Julien
On 24 March 2017 at 09:59, Michel Dänzer <mic...@daenzer.net> wrote:
> On 24/03/17 06:50 PM, Julien Isorce wrote:
> > Hi Michel,
> >
> > (Just for other readers my reply has bee
this other issue has some similarities (same ioctl call).
But in general, isn't "radeon_lockup_timeout" supposed to detect this
situation ?
Thx
Julien
On 24 March 2017 at 09:24, Michel Dänzer <mic...@daenzer.net> wrote:
> On 23/03/17 06:26 PM, Julien Isorce wrote:
> >
Hi Michel,
When it happens, the main thread of our gl based app is stuck on a
ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same
thing happens if true. Other threads are only si_shader:0,1,2,3 and are
doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof
23 matches
Mail list logo