On Tue, 2017-07-18 at 10:08 +0200, Borislav Petkov wrote:
> On Tue, Jul 18, 2017 at 08:00:07AM +0200, Borislav Petkov wrote:
> > And I think we should try this first: have the firmware disable
> > detection methods so that the platform drivers don't load.
>
> Btw, in looking at this more, what about the firmware-first thing?
>
> I.e., the firmware-first detection with apei_osc_setup() at the end
> of ghes_init().
>
> Can we make ghes_edac loading dependent on that? I mean, that was
> *the* predicate for exactly that - to have the firmware look at the
> errors first. No need for platform whitelisting and so on.
I agree that 'osc_sb_apei_support_acked' should be checked when
enabling ghes_edac. I do not know the details of existing issues, but
it sounds unlikely that this will address all of them since bugs can be
everywhere. For instance, ghes_edac relies on DMI/SMBIOS info, unlike
other EDAC drivers, which can be buggy regardless of this _OSC info.
> I'd still decouple ghes_edac loading from ghes_probe() even though
> loading the platform driver should've been done *after* the
> firmware-first detection regardless.
>
> So what we could do is make ghes_edac a normal module and have the
> relevant x86 EDAC modules query FF mode and if enabled, fail loading.
I agree that making ghes_edac as a normal module is a good thing, but I
do not think it's going to solve this issue.
Thanks,
-Toshi
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
