Created attachment 275071 [details]
picture of the screen when kernel panic occured
I am using gentoo on Lenovo g50-45 netbook with AMD APU A6-6310 mullins, and kernel 4.16.
This APU have arm cortex-A5 called AMD's PSP TrustZone processor on-board, and was introduced in April 29th of 2014.
Enabling CONFIG_CRYPTO_DEV_SP_PSP module is causing a kernel panic. (BTW it is enabled by default in kernel's .config file during "make oldconfig")
Since kernel panic occurs very early I cannot get anything in dmesg so I took a picture of the screen when panic happen.
Moreover, I attached dmesg without CONFIG_CRYPTO_DEV_SP_PSP being enabled and full kernel's .config file.
Created attachment 275073 [details]
Created attachment 275075 [details]
dmesg without SP_PSP enabled
Created attachment 275077 [details]
kernel 4.16 config file
Ok than, it seems that I have answered myself.
I have red that this APU does not support PSP/SEV firmware, and have found the LKML post with patch which enable additional checks if PSP/SEV firmware is supported like on Ryzen CPU.
Manually applying this patch resolved problem with kernel panic at boot time.
I also wonder why this patch has not been merged yet to 4.16 tree since is dated 21 Feb 2018, so I will keep this bug open till merge.
I just hit the same issue. I had a working .config from 4.15.14. On 4.16.0 I did a "make oldconfig" and psp seemed like something I could try. Also, I think, it is the default setting when just hitting enter.
I have a Ryzen 7 system (1800X, ASUS PRIME X370-PRO).
With CRYPTO_DEV_SP_PSP enabled, this is the last I see before the kernel panic:
ccp 0000:0d:00.2: enabling device (0000 -> 0002)
ccp 0000:0d:00.2: ccp enabled
ccp 0000:0d:00.2: psp initialization failed
ccp 0000:0d:00.2: enabled
BUG: unable to handle kernel NULL pointer dereference at 0000000000000073
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
Modules linked in:
CPU:5 PID: 1 Comm: swapper/0 Not tainted 4.16.0-gentoo #1
Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 3803 01/22/2018
RSP: 0018:ffffa20bc005be58 EFLAGS: 00010082
RAX: ffffffffb34d0981 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000000000ff RSI: ffff906337bd1000 RDI: ffffffffb3d5da8c
RBP: 0000000000000246 R08: 0000000000000000 R09: ffff906337bd114e
R10: ffff90633a58b268 R11: ffff906337bd1161 R12: ffffffffb3c91640
R13: 0000000000000007 R14: ffffffffb3b63834 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff90635ed40000(0000) knlFS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000073 CR3: 000000026e60a000 CR4: 00000000003406e0
Code: 6e 74 72 79 52 65 62 6f 6f 74 52 65 61 73 6f 6e 00 4c 6f 61 64 65 72 45 6e 74 72 79 4f 6e 65 53 68 6f 74 00 b0 2e 31 2e 30 00 6d <69> 73 73 69 6e 67 20 64 72 69 76 65 72 20 64 61 74 61 0a 00 44
RIP: 0xffffffffb34d0988 RSP: ffffa20bc005be58
---[ end trace c3daf89eade7be35 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00800009
Kernel Offset: 0x31000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00800009
I am closing this bug report since the patch has been pulled in to the 4.16.7 stable kernel.
Is this unresolved issue related?
(In reply to Thomas Biesinger from comment #7)
> Is this unresolved issue related?
If you mean this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=201129 IMHO it is not.
The patch has added only extra checking function to determine if machine firmware support PSP/SEV and then activate the master device on valid hardware. ("i->get_psp_master_device").
Personally I think that good move would be add Brijesh Singh <email@example.com> (the author of this patch) to the CC list of your bug report.
I have forget to add that I have CONFIG_CRYPTO_DEV_SP_PSP=y whole the time in my .config and don't have kernel panic. Machine is using 4.18.7 stable.
Yep, good idea but I do not see how:
CC: firstname.lastname@example.org did not match anything
Sorry that I forgot to attach the link - well spotted.
(In reply to Thomas Biesinger from comment #10)
> Yep, good idea but I do not see how:
> CC: email@example.com did not match anything
> Sorry that I forgot to attach the link - well spotted.
Top, right corner of the screen in your bug report:
CC List: -> (edit) -> paste email adress -> Save Changes.
It looks like only registered addresses can be added. I now have firstname.lastname@example.org on the list.
It seems that you are right about registered users.
email@example.com this is my account email address.
You could send just an email and attach a bug report link from bugzilla and redhat web page to this guy, or post an email in LKML list (firstname.lastname@example.org - presumably, for valid mailing lists please see http://vger.kernel.org/vger-lists.html) and wait if someone will respond, eventually wait if someone in bugzilla will address it properly.
Date: Sat, Sep 15, 2018 at 10:57 AM
Subject: AM4 BIOS AGESA Code 18.104.22.168C & Linux Kernel
To: <email@example.com>, <firstname.lastname@example.org>
Hi, please find below a list of related bugs to a blocker that affects existing systems and even prevents the installation of several Linux distributions:
I read about an upstream fix to 4.20 but this is a long way to go. I guess that anyone who keeps their AM4 BIOS AGESA Code update-to-date and would like to run Linux is affected.
A co-operation between AMD & Linux Kernel experts to achieve a solution fast is encouraged. Thank you!
From: Brijesh Singh <email@example.com>
Date: Sat, Sep 15, 2018 at 1:44 PM
Subject: Re: AM4 BIOS AGESA Code 22.214.171.124C & Linux Kernel
To: <firstname.lastname@example.org>, <email@example.com>
The workaround to handle this FW bug has been submitted last month
And patch is accepted in crypto tree
It will soon show up in Linus tree. After that we will work to get it
backport to stable tree's.