From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5C64C433ED for ; Thu, 13 May 2021 14:30:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 738D560FE7 for ; Thu, 13 May 2021 14:30:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234472AbhEMOcA (ORCPT ); Thu, 13 May 2021 10:32:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230252AbhEMOb5 (ORCPT ); Thu, 13 May 2021 10:31:57 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 781AAC061574 for ; Thu, 13 May 2021 07:30:46 -0700 (PDT) Received: from zn.tnic (p200300ec2f0e440021f4b7a45291c72c.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:4400:21f4:b7a4:5291:c72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 4340E1EC032C; Thu, 13 May 2021 16:30:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1620916242; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=Q/FWCwRMgsRKVUM9zO85vUS6qMZ5capc4M5/7Qx9MH4=; b=h1Qbg54LGvKZ62jWfecfrcp4a3gGhPK6L4FS5qF50E3tXNDsNktWaZyOs8Qau1U+w1gqd3 +ig/uJT6i7HPfQpaEg0+ibjNAuCdy0nI9A9k1zlFCXUPZekk5HQQlax28ig1a7Y7N4HQg0 gTtCxo2S0OigQUnlkZFnAB0KxlATcR8= Date: Thu, 13 May 2021 16:30:39 +0200 From: Borislav Petkov To: Alex Deucher Cc: "Joshi, Mukul" , x86-ml , "Kasiviswanathan, Harish" , lkml , "amd-gfx@lists.freedesktop.org" Subject: Re: [PATCH] drm/amdgpu: Register bad page handler for Aldebaran Message-ID: References: <20210512013058.6827-1-mukul.joshi@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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