tm.c | 45 ++---
1 file changed, 14 insertions(+), 31 deletions(-)
Detailed bisect log is here:
https://bin.privacytools.io/?a88ae63fb95fa1c1#EtrC4qxGWjmgy5C3dBzXFGqjxc7znTKULtz4cxoYFxW5
Best regards,
Luís Mendes
Aparapi developer
PhD Student &am
have the strong suspicion that is just another one of those.
>
> Regards,
> Christian.
>
> Am 24.05.21 um 21:25 schrieb Luís Mendes:
> > Hi,
> >
> > AMDGPU was working fine on my armhf systems with 5.10.x and previous
> > kernels and a RX550 card. Unfortunately
card and hope
for a better future.
Please consider Open-source OpenCL support in amdgpu/mesa.
Best regards,
Luís Mendes
a distro that packages ROCm for you as
> Clover is nowhere near ready
>
> On Fri, 29 Jul 2022 at 11:06, Luís Mendes wrote:
> >
> > Hi,
> >
> > I am an Aparapi project developer that has been struggling for two
> > years to get an RX 5700 properly running Ope
Hi,
Ping? This is actually a regression.
If there is no one available to work this, maybe I can have a look in
my spare time, in accordance with your suggestion.
Regards,
Luís
On Tue, Jan 3, 2023 at 8:44 AM Christian König wrote:
>
> Am 25.12.22 um 20:39 schrieb Luís Mendes:
> >
I'll give it a try this weekend.
Luís
On Fri, Mar 10, 2023 at 1:15 PM Arunpravin Paneer Selvam
wrote:
>
>
>
> On 3/9/2023 3:42 PM, Luís Mendes wrote:
> > Hi,
> >
> > Ping? This is actually a regression.
> > If there is no one available to work this, may
/drivers/gpu/drm/drm_buddy.c
Signed-off-by: Luís Mendes
>8--8<
diff -uprN linux-next/drivers/gpu/drm/drm_buddy.c
linux-nextLM/drivers/gpu/drm/drm_buddy.c
--- linux-next/drivers/gpu/drm/drm_buddy.c2022-12-25
16:29:26.0 +
+++
to go. So I would like to get a second opinion on this, by those
who know.
/include/linux/log2.h
/drivers/gpu/drm/drm_buddy.c
Signed-off-by: Luís Mendes
>8--8<
diff -uprN linux-next/drivers/gpu/drm/drm_buddy.c
linux-nextLM/drivers/g
s indefinitely:
task plymouthd:449 blocked for more than 120 seconds.
Is there any hope on getting this fixed?
On Thu, Jul 12, 2018 at 2:56 PM Luís Mendes wrote:
> Hi Jim,
>
> Replies in between.
>
> Regards,
> Luís
>
> On Thu, Jul 12, 2018 at 3:16 AM, jimqu wrote:
>
&
Hi Christian,
I've been using a Sapphire RX 550 and a Sapphire RX 460 on a custom
armhf board that runs well with Linux 4.19.9 at least, but now
starting with Linux kernel 4.20, I'm having a gpu hang, right after
the console being displayed, but before entering in graphical mode,
when starting X s
Hi Alex,
I am already using drm_arch_can_wc_memory() set to false.
I will try to bisect...
Regards,
Luís
On Tue, Dec 18, 2018 at 7:03 PM Alex Deucher wrote:
>
> On Tue, Dec 18, 2018 at 8:58 AM Luís Mendes wrote:
> >
> > Hi Christian,
> >
> > I've been using
Hi,
Just want to report this issue for the Polaris 12, RX550, with kernel 4.19.9
[ 20.272719] amdgpu: [powerplay] Failed to retrieve minimum clocks.
[ 20.272723] amdgpu: [powerplay] Error in phm_get_clock_info
dmesg excerpt of relevant amdgpu initialization follows below.
Regards,
Luís
Ok, great! Thanks!
Luís
On Wed, Dec 19, 2018 at 6:27 PM Deucher, Alexander
wrote:
>
> Those messages are harmless and can be ignored. I think they have been
> removed in newer kernels.
>
>
> Alex
>
>
> From: amd-gfx on behal
ng periods.
Regards,
Luís Mendes
On Tue, Dec 18, 2018 at 11:16 PM Luís Mendes wrote:
>
> Hi Alex,
>
> I am already using drm_arch_can_wc_memory() set to false.
> I will try to bisect...
>
> Regards,
> Luís
>
> On Tue, Dec 18, 2018 at 7:03 PM Alex Deucher wrote:
>
once
linux-4.21-rc1 comes out.
Regards,
Luís
On Thu, Jan 3, 2019 at 2:12 PM Alex Deucher wrote:
>
> Does this patch help by any chance?
>
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=5e01c09ce3b7263d88873105f21a82eda904664b
>
> Alex
>
>
Reply in between.
On Fri, Jan 4, 2019 at 4:22 PM Michel Dänzer wrote:
>
> On 2019-01-04 4:32 p.m., Luís Mendes wrote:
> > Hi Alex, Christian,
> >
> > I've tested amd-staging-drm-next at commit
> > 9698024e8a191481321574bec1fe886bbce797cf - drm/amdgpu: Cleanup 2
ct 20, 2018 at 6:58 PM Luís Mendes wrote:
> The problems remains with Linux 4.18 and Linux 4.19 kernels. I am unable
> to use AMD RX 460 and AMD RX 550 on my x64 Linux platforms.
>
> I've installed Windows 10 in the same machine along with
> win10-64bit-radeon-software-adrena
with those versions.
If you have additional suggestions I'll be happy to try them.
Regards,
Luís Mendes
On Thu, Feb 1, 2018 at 2:30 AM, Alex Deucher wrote:
> On Wed, Jan 31, 2018 at 6:57 PM, Luís Mendes wrote:
>> Hi everyone,
>>
>> I am getting a new issue with amdgpu
s.
Regards,
Luís
On Fri, Feb 2, 2018 at 7:48 AM, Christian König
wrote:
> Hi Luis,
>
> please enable kmemleak in your build and watch out for any suspicious
> messages in the system log.
>
> Regards,
> Christian.
>
>
> Am 02.02.2018 um 00:03 schrieb Luís Mendes:
>>
kmemleak which I attach along with
the crash dmesg log.
The kernel and patches are the same as on my previous email. I ended
up not changing either the mesa version, nor the kernel version and
patches.
Regards,
Luís
On Fri, Feb 2, 2018 at 6:46 PM, Luís Mendes wrote:
> Hi Christian, Alexan
email.
Regards,
Luís
On Mon, Feb 5, 2018 at 12:40 PM, Luís Mendes wrote:
> Hi everyone,
>
> I have some updates. I left the system idle most of the time during
> the weekend and from time to time I played a video on youtube and
> turned off the screen. Yesterday night I did the same a
buntu 16.04.4 with AMDGPU PRO 17.50
and 18.10 show the same problems, in fact, AMDGPU-PRO 18.10 is even
worse.
However the same set of kernels run happily on armhf with vanilla
Linux 4.16.7 and mesa 18.0 (mesa-opencl-icd and libclc for amdgcn),
Ubuntu 17.10, on an AMD RX460 and an AMD RX 550.
Luís M
__
> From: amd-gfx on behalf of Luís
> Mendes
> Sent: Friday, May 4, 2018 12:27:47 PM
> To: amd-gfx list; Koenig, Christian; Michel Dänzer
> Subject: GPU hang trying to run OpenCL kernels on x86_64
>
> Hi,
>
> I am a collaborator with Syncleus/aparapi project on g
with the exact same Ubuntu 18.04 LTS base installation on
armhf, but won't be able to test it today.
Luís
On Mon, May 7, 2018 at 10:38 AM, Michel Dänzer wrote:
> On 2018-05-05 01:15 AM, Luís Mendes wrote:
>>
>> - On another system with armhf 32 bits, 1GB ram, 512GB SSD, AM
the same on both systems now, as well as the kernel.
I have even tried amdgpu-pro-18.20 with ubuntu 18.04 on x86_64 and it
hangs just the same.
Regards,
Luís
On Mon, May 7, 2018 at 1:31 PM, Luís Mendes wrote:
> Hi Michel,
>
> No, I haven't tried the exact same versions of Mesa, n
i, May 11, 2018 at 1:15 PM, Luís Mendes
wrote:
> Hi Michel,
>
> Just made a fresh Ubuntu 18.04 LTS install for armhf with ubuntu
> default mesa, libdrm and libclc, with the same 4.16.7 kernel and it
> runs fine with the OpenCL applications that cause the hang on x86_64.
> So it
ldn't with RX 460/RX 550.
Regards,
Luís
On Thu, May 24, 2018 at 9:30 AM, Michel Dänzer wrote:
> On 2018-05-24 12:06 AM, Luís Mendes wrote:
> > I've tried Linux 4.17-rc6 with Ubuntu 18.04 on Tyan S7002 and I am not
> even
> > able see lightdm/gdm3 as system hangs w
don't work, or at least I have been unable to make them work.
Regards,
Luís
On Thu, May 24, 2018 at 10:01 AM, Luís Mendes
wrote:
> Hi Michel,
>
> So summarizing with Linux kernel 4.17-rc6 on Ubuntu 18.04 using AMD RX
> 460/RX 550 I am not able to enter X.
> The same system w
also be a Mesa issue, regarding OpenCL on RX 460?
Regards,
Luís
On Thu, May 24, 2018 at 9:55 AM, Luís Mendes
wrote:
> Hi Michel,
>
> I will have to check previous rc releases of 4.17 to see if it wasn't
> already happening, before trying any possible git bisect.
> As an upda
D GPU.
The dmesg log follows attached.
Luís
On Thu, May 24, 2018 at 10:13 AM, Luís Mendes
wrote:
> Hi Michel,
>
> I also work as a researcher at a university and we are considering buying
> AMD cards to do OpenCL computations for numerical modelling, but currently
> I am unable to g
vements.
I have tried amdgpu-pro 18.10 and 17.50 and also no improvements.
./amdgpu-pro-install -opencl=legacy,pal --headless
On Thu, May 24, 2018 at 11:18 AM, Luís Mendes
wrote:
> Additional update...
>
> I was able to boot and enter X by installing an NVIDIA GTX 1050 Ti as the
> pr
05004] [drm] IP block:vce_v3_0 is hung!
[ 548.705005] [drm] GPU recovery disabled.
[ 548.705006] [drm] IP block:vce_v3_0 is hung!
[ 548.705007] [drm] GPU recovery disabled.
Are there any new regarding this issue?
Regards,
Luís
On Fri, May 25, 2018 at 11:23 AM, Luís Mendes
wrote:
> I'v
Hi,
I've tried kernel 4.18-rc2 on a system with a NVIDIA GTX 1050 Ti and an AMD
RX 550 4GB and the RX 550 card is failing the IB ring test.
[5.033217] [drm:gfx_v8_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: ib test
failed (scratch(0xC040)=0x)
[5.033264] [drm:amdgpu_ib_ring_tests [amd
Hi,
Issue remains in kernel 4.18-rc4 using SAPPHIRE RX 550 4GB.
Logs follow attached.
Regards,
Luis
On Tue, Jun 26, 2018 at 10:08 AM, Luís Mendes
wrote:
> Hi,
>
> I've tried kernel 4.18-rc2 on a system with a NVIDIA GTX 1050 Ti and an
> AMD RX 550 4GB and the RX 550 card
block:uvd_v6_0 is hung!
[ 227.443140] [drm] IP block:vce_v3_0 is hung!
[ 227.443141] [drm] GPU recovery disabled.
Regards,
Luís
On Tue, Jun 26, 2018 at 10:03 AM, Luís Mendes
wrote:
>
> I've tested Ubuntu 18.04 with kernel 4.17.2 using libdrm-2.4.92 and
> mesa-18.1.0 and AMD RX 550 4GB is
ould be regression issue on 4.18, you can bisect the kernel patches.
>
> GPU hang:
>
> Fix IB test fail first.
>
>
> Thanks
>
> JimQu
>
>
>
> On 2018年07月11日 17:34, Luís Mendes wrote:
>
> Hi Jim,
>
> Thanks for your interest in this issue. Actually thi
expect later on. So I think we should concentrate on fixing that.
>
> Regards,
> Christian.
>
>
> Am 11.07.2018 um 23:27 schrieb Luís Mendes:
>
> Hi Jim,
>
> I followed your suggestion and was able to bisect the kernel patches.
> T
Hi Jim,
Replies in between.
Regards,
Luís
On Thu, Jul 12, 2018 at 3:16 AM, jimqu wrote:
>
>
> On 2018年07月12日 05:27, Luís Mendes wrote:
>
> Hi Jim,
>
> I followed your suggestion and was able to bisect the kernel patches.
> The offending patch is: drm/amdgpu: defer
tic deadlock which always happen in glmark2 at the start of the
terrain test.
Stack traces follow below.
Regards,
Luís Mendes
Hardware and Software engineer
The stacktrace for glmark2 after deadlock is:
#0 0xb6b9b246 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1 0xb6943dc6 i
8e56098) there is an immediate and
systematic deadlock which always happen in glmark2 at the start of the
terrain test.
Stack traces follow below.
Regards,
Luís Mendes
Hardware and Software engineer
The stacktrace for glmark2 after deadlock is:
#0 0xb6b9b246 in ioctl () at ../sysdeps/unix/sysc
With the AMD RX460:
The commit 7aadd3abc1eedef97fc89adf6bf4602b224af890 - "drm/amdgpu: Fix
amdgpu_sync_add_later to preserve explicit flag" cherry picked into
drm-next-4.16 allows the glmark2 test to run until the end, otherwise
it will deadlock immediately at the start of glmark2 terrain test.
The
rest or time to
look into this.
Regards,
Luís Mendes
Software and Hardware engineer
[ 253.904103] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout, last signaled seq=43831, last emitted seq=43833
[ 253.915041] [drm] IP block:gmc_v8_0 is hung!
[ 253.915047] [drm] IP block:gfx_v8_0 is
Dear Mr. David, Mr. Christian,
First of all, thanks for your replies!
David, I will try the same software versions on x86 to see if I am
able to replicate the problem on x86, but I suspect it is ARM
specific... I'll report back when I have more details.
Christian, I'll collect the data you've re
h_can_wc_memory() in the kernel source and
> try if it helps if you always return false.
>
> Apart from that the only other explanation I have is that some system memory
> isn't accessible for the GPU while some other is working fine.
>
> Please provide the output of "sud
ication seem to work fine... I am
able to run glmark2 tests without issues.
How can I send these apitraces?
On Tue, Jan 2, 2018 at 10:29 PM, Luís Mendes wrote:
> Ok... I've done some of the suggested tests.
>
> I still haven't tested on x86, but I'll get to that.
>
Hi Christian,
Replies follow in between.
Regards,
Luís
On Wed, Jan 3, 2018 at 9:37 AM, Christian König
wrote:
> Hi Luis,
>
> In general please add information like /proc/iomem and dmesg as attachment
> and not mangled inside the mail.
Ok, I'll take that into account next time. Sorry for the in
Hi Christian, David,
David, replying to your question... The issue is indeed reproducible
on x86, I just did it with kodi and the same VP9 video. So it is not
arm specific.
Regards,
Luís
On Wed, Jan 3, 2018 at 11:02 AM, Luís Mendes wrote:
> Hi Christian,
>
> Replies follow i
difference. I will try
amd-staging-drm-next and report back.
Regards,
Luís
On Wed, Jan 3, 2018 at 5:09 PM, Michel Dänzer wrote:
> On 2018-01-03 12:02 PM, Luís Mendes wrote:
>>
>> What I believe it seems to be the case is that the GPU lock up only
>> happens when doing a
imedout [amdgpu]] *ERROR* ring gfx
timeout, last signaled seq=25158, last emitted seq=25160
[ 223.406926] [drm] IP block:tonga_ih is hung!
[ 223.407167] [drm] GPU recovery disabled.
Regards,
Luís
On Wed, Jan 3, 2018 at 5:47 PM, Luís Mendes wrote:
> Hi Michel, Christian,
>
> Christian, I have
Hi Andrey, Johannes,
Sorry for getting into this conversation, but I think I might have
something related to this.
I am getting GPU hangs playing some videos, both on ARMv7 and on x86,
although with slightly different blocking paths. On ARMv7 it always
blocks with amdgpu_dm_do_flip. I suspect the
*ERROR* amdgpu:
writing more dwords to the ring than expected!
[ 591.876945] [drm:amdgpu_ring_insert_nop [amdgpu]] *ERROR* amdgpu:
writing more dwords to the ring than expected!
[ 591.887454] [drm:amdgpu_ring_insert_nop [amdgpu]] *ERROR* amdgpu:
writing more dwords to the ring than expected!
Regar
.
Regards,
Luís Mendes
On Wed, Jan 31, 2018 at 12:47 PM, Luís Mendes wrote:
> Hi Alexander,
>
> I've cherry picked the patch you pointed out into kernel from
> amd-drm-next-4.17-wip at commit
> 9ab2894122275a6d636bb2654a157e88a0f7b9e2 ( drm/amdgpu: set
> DRIVER_ATOMIC flag
52 matches
Mail list logo
