From: Borislav Petkov <bp@alien8.de>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: "Joshi, Mukul" <Mukul.Joshi@amd.com>, x86-ml <x86@kernel.org>,
"Kasiviswanathan, Harish" <Harish.Kasiviswanathan@amd.com>,
lkml <linux-kernel@vger.kernel.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Register bad page handler for Aldebaran
Date: Thu, 13 May 2021 16:30:39 +0200 [thread overview]
Message-ID: <YJ04D8a6LaVRMuGH@zn.tnic> (raw)
In-Reply-To: <CADnq5_Or5maEWTZFzS6iksyoFC=q9=y=-YmPTdPuWRKFhdw0yg@mail.gmail.com>
On Thu, May 13, 2021 at 10:17:47AM -0400, Alex Deucher wrote:
> The bad pages are stored in an EEPROM on the board and the next time
> the driver loads it reads the EEPROM so that it can reserve the bad
> pages at init time so they don't get used again.
And that works automagically on the next boot? Because that sounds like
the right thing to do.
So practically, what happens to a GPU in such a case where the VRAM
starts going bad? It might get exhausted eventually and the driver will
say something along the lines of:
"VRAM bad pages: 80%, consider replacing the GPU. It is operating
currently with degrated performance."
or so?
Yap, from a RAS perspective, that makes good sense as you're prolonging
the life of the component while still remains operational as good as it
can and the only user interaction you need is she/he replacing it.
Sounds good.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-05-13 14:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210512013058.6827-1-mukul.joshi@amd.com>
2021-05-12 9:36 ` [PATCH] drm/amdgpu: Register bad page handler for Aldebaran Borislav Petkov
2021-05-12 19:00 ` Joshi, Mukul
2021-05-12 21:05 ` Borislav Petkov
2021-05-13 3:20 ` Joshi, Mukul
2021-05-13 9:53 ` Borislav Petkov
2021-05-13 14:17 ` Alex Deucher
2021-05-13 14:30 ` Borislav Petkov [this message]
2021-05-13 14:32 ` Alex Deucher
2021-05-13 14:57 ` Borislav Petkov
2021-05-13 15:02 ` Alex Deucher
2021-05-13 23:14 ` Joshi, Mukul
2021-05-14 7:03 ` Borislav Petkov
2021-05-27 19:54 ` Joshi, Mukul
2021-06-03 21:13 ` Yazen Ghannam
2021-07-29 23:59 ` Joshi, Mukul
2021-09-13 1:31 ` Joshi, Mukul
2021-05-13 23:10 ` Joshi, Mukul
2021-05-14 7:05 ` Borislav Petkov
2021-05-14 13:06 ` Joshi, Mukul
2021-05-14 14:38 ` Borislav Petkov
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=YJ04D8a6LaVRMuGH@zn.tnic \
--to=bp@alien8.de \
--cc=Harish.Kasiviswanathan@amd.com \
--cc=Mukul.Joshi@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).