Hi All,
On 08/01/2018 03:07 AM, James Morse wrote:
> I did manage to borrow of one of these boxes to discover one additional piece
> of
> information: this firmware bug doesn't exist in the latest released firmware.
I went through and verified the info James provided. The last Moonshot
On Wed, Aug 01, 2018 at 11:07:17AM +0100, James Morse wrote:
> Hi Geoff,
>
> On 31/07/18 16:54, Geoff Levand wrote:
> > This m400 HEST problem is blocking me from enabling APEI support in
> > Debian [1], so I'd like to come to a conclusion on it.
> >
> > In summary from [2], Riku and Graeme
Hi Geoff,
On 31/07/18 16:54, Geoff Levand wrote:
> This m400 HEST problem is blocking me from enabling APEI support in
> Debian [1], so I'd like to come to a conclusion on it.
>
> In summary from [2], Riku and Graeme mention they still have some m400
> systems in use. Mark did some
Hi Will,
This m400 HEST problem is blocking me from enabling APEI support in
Debian [1], so I'd like to come to a conclusion on it.
In summary from [2], Riku and Graeme mention they still have some m400
systems in use. Mark did some investigation and found the cause to be
generated by the
Hi Will,
On 07/13/2018 02:56 AM, Will Deacon wrote:
> On Fri, Jul 13, 2018 at 08:15:26AM +0200, Ard Biesheuvel wrote:
>
>> This is not my call to make, but I would be much less averse to this
>> being merged if we could agree upfront on an expiration time of, say,
>> 2 years (or more?), after
On Fri, 2018-07-13 at 08:15 +0200, Ard Biesheuvel wrote:
> I still think we should not be using DMI, though.
Would a quirk be acceptable if keyed on something other than DMI?
Are there some other options, perhaps some property of the ACPI tables
proper? Something which can be queried from UEFI
On Fri, Jul 13, 2018 at 08:15:26AM +0200, Ard Biesheuvel wrote:
> On 13 July 2018 at 00:22, Geoff Levand wrote:
> > Hi Ard,
> >
> > On 07/04/2018 08:49 AM, Ard Biesheuvel wrote:
> >> efi/libstub: taken contents of LinuxExtraArgs UEFI variable into
> >> account
> >
> > To me this seems an
On 13 July 2018 at 00:22, Geoff Levand wrote:
> Hi Ard,
>
> On 07/04/2018 08:49 AM, Ard Biesheuvel wrote:
>> efi/libstub: taken contents of LinuxExtraArgs UEFI variable into
>> account
>
> To me this seems an overly complicated interface to the kernel, and
> still doesn't in itself solve
Hi Ard,
On 07/04/2018 08:49 AM, Ard Biesheuvel wrote:
> efi/libstub: taken contents of LinuxExtraArgs UEFI variable into
> account
To me this seems an overly complicated interface to the kernel, and
still doesn't in itself solve the problem at hand -- make the
generic distro kernel with
On Thu, 2018-07-12 at 18:01 +0100, Will Deacon wrote:
On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
> >Especially for UEFI systems, if upgrading
> > firmware is a reasonable prerequisite for being able to upgrade to the
> > latest
Is it?
> On 12 Jul 2018, at 19:01, Will Deacon wrote:
>
> Hi Ard,
>
>> On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
>> As noted by Ian, many DMI based quirks for x86 ACPI machines disable
>> features that can also be disabled via the kernel command line. Similarly,
>> a quirk is
Hi Ard,
On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
> As noted by Ian, many DMI based quirks for x86 ACPI machines disable
> features that can also be disabled via the kernel command line. Similarly,
> a quirk is under discussion for a arm64 ACPI machine [0] that explodes
>
As noted by Ian, many DMI based quirks for x86 ACPI machines disable
features that can also be disabled via the kernel command line. Similarly,
a quirk is under discussion for a arm64 ACPI machine [0] that explodes
when enabling support for hardware error reporting via the ACPI HEST table.
When
13 matches
Mail list logo
