gicv3-its driver crashes in crash dump kernel

Hi, As of the 5.0 kernel we're seeing the crash dump kernel crash when the gicv3-its driver calls gic_reserve_range(): root@bcm958804a8040c:~# echo c > /proc/sysrq-trigger [ 2285.405357] sysrq: SysRq : Trigger a crash [ 2285.409592] Kernel panic - not syncing: sysrq triggered crash [

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel wrote: > For the record, this is an example of why I think backporting those > clang enablement patches is a bad idea. There's always a risk involved with backports of any kind; more CI coverage can help us mitigate some of these risks in an

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, Jun 05, 2019 at 08:42:32PM +0200, Ard Biesheuvel wrote: > On Wed, 5 Jun 2019 at 18:26, Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > > been "running" with kernel

Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

On Sun, Jun 2, 2019 at 10:42 PM Mike Rapoport wrote: > > Hi Dan, > > On Thu, May 30, 2019 at 03:59:43PM -0700, Dan Williams wrote: > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the > > interpretation of the EFI Memory Types as "reserved for a special > > purpose". > > > > The

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, 5 Jun 2019 at 18:26, Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9

[PATCH] efi: Fix TPM code build failure on ARM

asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order to ensure that early_memremap is available. Signed-off-by: Matthew Garrett --- drivers/firmware/efi/tpm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/firmware/efi/tpm.c

[PATCH V2] tpm: Don't duplicate events from the final event log in the TCG2 log

After the first call to GetEventLog() on UEFI systems using the TCG2 crypto agile log format, any further log events (other than those triggered by ExitBootServices()) will be logged in both the main log and also in the Final Events Log. While the kernel only calls GetEventLog() immediately before

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers wrote: > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > > been "running" with kernel 4.9,

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, Jun 5, 2019 at 9:26 AM Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > I decided to dig out a toy project which uses a DragonBoard 410c. This has > been "running" with kernel 4.9, which I would keep this way for unrelated > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was >

Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

I decided to dig out a toy project which uses a DragonBoard 410c. This has been "running" with kernel 4.9, which I would keep this way for unrelated reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was buildable, which was good enough. Upgrading the kernel to 4.9.180 caused

Re: [PATCH 1/1] tpm: Don't dereference event after it's unmapped in __calc_tpm2_event_size

On Wed, Jun 05, 2019 at 12:04:33AM +0100, Chris Coulson wrote: > The pointer to the event header is dereferenced on each loop iteration in > order to obtain the digest count, but when called from > tpm2_calc_event_log_size, the event header is unmapped on the first > iteration of the loop. This

Re: [PATCH 0/1] Fix crash in __calc_tpm2_event_size

On Wed, Jun 05, 2019 at 12:04:32AM +0100, Chris Coulson wrote: > I've been testing the latest code in the linux-tpmdd branch and I'm > experiencing a crash in __calc_tpm2_event_size when it's called to > calculate the size of events in the final log. I hope I'm not stepping on > anyone's toes, but

Re: [PATCH] tpm: Don't duplicate events from the final event log in the TCG2 log

On Tue, Jun 04, 2019 at 12:35:11PM -0700, Matthew Garrett wrote: > After the first call to GetEventLog() on UEFI systems using the TCG2 > crypto agile log format, any further log events (other than those > triggered by ExitBootServices()) will be logged in both the main log and > also in the Final

Quation needed For June Inquiry

Hello dear, We are in the market for your products after meeting at your stand during last expo. Please kindly send us your latest catalog and price list so as to start a new project/order as promised during the exhibition. I would appreciate your response about the above details required