From: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
To: "amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Daniel Kasak
<d.j.kasak.dk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: Hard lockups with ROCM
Date: Thu, 16 May 2019 19:03:34 +0000 [thread overview]
Message-ID: <03ca98c6-aef5-b7d2-976b-c736cb874fef@amd.com> (raw)
In-Reply-To: <CAF73Y=QuYq3ALtP6xiPyqS+jm_TJCQQDyQ+WA5ZJG8EhWSKiTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Daniel,
On 2019-05-12 9:44 p.m., Daniel Kasak wrote:
> [CAUTION: External Email]
> Hi all. I had version 2.2.0 of the ROCM stack running on a 5.0.x and
> 5.1.0 kernel. Things were going great with various boinc GPU tasks.
> But there is a setiathome GPU task which reliably gives me a hard
> lockup within about 30 minutes of running. I actually had to do *two*
> emergency re-installs over the past week.
Sorry to hear about your trouble. Do you have a second computer you can
use to remote login into your system? Chances are that it's still
responsive and only the screen is frozen.
Also, you could try booting in console mode (without an xserver). The
console usually still works even when the GPU compute units or SDMA
engines are hanging.
If you manage to do an emergency reboot with sysrq (remount-RO and
reboot), you should see the kernel log of your previous session in
/var/log. On Ubuntu it's in /var/log/kern.log. Not sure where it is on
Gentoo. There is a good chance the log contains helpful information
(e.g. if the driver detected a hang but failed to reset the GPU, or
maybe a driver bug that leads to a deadlock or kernel panic).
> Perhaps part of this was my fault ( running btrfs with lzo compression
> on my root partition ... ). But absolutely part of this was the hard
> lockups. I've tested all kinds of other things ( eg rebuilding lots of
> stuff under Gentoo ) ... I don't have a general stability issue even
> under hours of high load. But after restarting boinc with that same
> setiathome task ... <bang>!
>
> If someone wants me to sacrifice another installation, they can point
> me to instructions for trying to gather more information.
If you want to risk another installation, it may be a good idea to do it
on a spare hard drive, or a spare partition on your existing hard drive.
Also, use a more conventional choice of file system. A simple ext4 is
pretty robust in my experience. We get hard lockups all the time. I
usually only reinstall my system for big OS upgrades or if I'm stupid
and mess something up myself.
Which GPU are you using?
There are some things you could try to narrow down the cause of your
problem.
1. Monitor GPU temperature while running setiathome
2. If you're building your own kernel, enable some helpful kernel debug
options that can provide very helpful diagnostic info: lock
debugging, memory debugging, lockup/hang debugging
3. Try running with lower GPU clocks (rocm-smi --setperflevel low). If
that fixes it, you may have inadequate cooling or power supply
4. Try running in console mode (without Xserver or other graphical UI
running). If that fixes it, there may be a bad interaction between
graphics and compute
5. Try updating your firmware. The DKMS package included in our ROCm
releases includes the latest firmware. You should be able to extract
it from there and drop it into /lib/firmware/amdgpu
6. Try to find a regression point. Is there any known version of ROCm
or the kernel where it worked correctly?
Regards,
Felix
>
> Anyway ... perhaps more work around detecting and recovering from GPU
> lockups is in order?
>
> Dan
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
prev parent reply other threads:[~2019-05-16 19:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-13 1:44 Hard lockups with ROCM Daniel Kasak
[not found] ` <CAF73Y=QuYq3ALtP6xiPyqS+jm_TJCQQDyQ+WA5ZJG8EhWSKiTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-16 0:33 ` Daniel Kasak
[not found] ` <CAF73Y=R96zUxCAEKopSvGReqB+sEFWcHhXSKnR98rpetMbKf4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-16 1:43 ` Alex Deucher
[not found] ` <CADnq5_OOEP+YsQx12cOBaM3NdjM=eGAbbbudEusqf5rNRz8C2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-16 11:52 ` Daniel Kasak
[not found] ` <CAF73Y=TfsjO+-cnvzZ8s7VnuCTcu3KT0ZG3KtzbYGTTYKK-PzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-16 15:56 ` Paul Menzel
2019-05-16 19:03 ` Kuehling, Felix [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03ca98c6-aef5-b7d2-976b-c736cb874fef@amd.com \
--to=felix.kuehling-5c7gfcevmho@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=d.j.kasak.dk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox