[Kernel-packages] [Bug 1732894] Re: CPU call trace on AMD Raven Ridge after S3
Hi all, Verified with hwe-edge-4.13.0-18 and hwe-edge-4.13.0-19. Both of them fix the CPU(mce) calltrace during S3. Jerry -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1732894 Title: CPU call trace on AMD Raven Ridge after S3 Status in linux package in Ubuntu: Confirmed Status in linux source package in Artful: Fix Committed Bug description: [Impact] Dmesg shows a call trace after S3 cycle. This has been fixed in v4.14-rc1 with commit 9662d43f523dfc0dc242ec29c2921c43898d6ae5 Author: Yazen Ghannam Date: Mon Jul 24 12:12:28 2017 +0200 x86/mce/AMD: Allow any CPU to initialize the smca_banks array Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU 0 seemed like a good candidate to do the populating. However, it's possible that CPU 0 is not enabled in which case the smca_banks array won't be populated. Rather than try to figure out another master thread to do the populating, we should just allow any CPU to populate the array. Drop the CPU 0 check and return early if the bank was already initialized. Also, drop the WARNing about an already initialized bank, since this will be a common, expected occurrence. The smca_banks array is only populated at boot time and CPUs are brought online sequentially. So there's no need for locking around the array. If the first CPU up is a master thread, then it will populate the array with all banks, core and non-core. Every CPU afterwards will return early. If the first CPU up is not a master thread, then it will populate the array with all core banks. The first CPU afterwards that is a master thread will skip populating the core banks and continue populating the non-core banks. Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Acked-by: Jack Miller Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tony Luck Cc: linux-edac Link: http://lkml.kernel.org/r/20170724101228.17326-4...@alien8.de Signed-off-by: Ingo Molnar [Test case] Suspend/resume Raven Ridge, see that it doesn't show the call trace any more. [Regression potential] 4.14 released with it, and it fixes code which "for now" checked only CPU 0, so regressions potential is slim to none. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1732894/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1736862] [NEW] [Raven1] EFI FB driver cannot get 64-bit FB address with "Above 4G MMIO" enabled in Ubuntu16.04.3
Private bug reported: With "Above 4G MMIO" enabled in BIOS, EFI FB driver cannot get 64-bit FB address on Raven1 platform. Then fail to initialize EFI FB driver. That results in black-screen for console mode or installing Ubuntu system. e.g. if the FB address is 0x7fc8000, EFI FB could only get the low 32-bit FB address. [0.992990] efifb: probing for efifb [0.992995] efifb: cannot reserve video memory at 0x8000 [0.992999] ioremap on RAM at 0x8000 - 0x808c As my investigation, it looks Ubuntu efi boot stub cannot get 64-bit address by GOP. 1) create a EFI shell app to get the fb address, it’s 64-bit 2) Build bzImage.efi to load 4.13 custom kernel, efifb driver also could get 64-bit address. ** Affects: amd Importance: High Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1736862 Title: [Raven1] EFI FB driver cannot get 64-bit FB address with "Above 4G MMIO" enabled in Ubuntu16.04.3 Status in amd: New Bug description: With "Above 4G MMIO" enabled in BIOS, EFI FB driver cannot get 64-bit FB address on Raven1 platform. Then fail to initialize EFI FB driver. That results in black-screen for console mode or installing Ubuntu system. e.g. if the FB address is 0x7fc8000, EFI FB could only get the low 32-bit FB address. [0.992990] efifb: probing for efifb [0.992995] efifb: cannot reserve video memory at 0x8000 [0.992999] ioremap on RAM at 0x8000 - 0x808c As my investigation, it looks Ubuntu efi boot stub cannot get 64-bit address by GOP. 1) create a EFI shell app to get the fb address, it’s 64-bit 2) Build bzImage.efi to load 4.13 custom kernel, efifb driver also could get 64-bit address. To manage notifications about this bug go to: https://bugs.launchpad.net/amd/+bug/1736862/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1736862] Re: [Raven1] EFI FB driver cannot get 64-bit FB address with "Above 4G MMIO" enabled in Ubuntu16.04.3
** Attachment added: "check_fb_in_efi_shell.JPG" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1736862/+attachment/5019590/+files/check_fb_in_efi_shell.JPG ** Information type changed from Public to Private ** Package changed: linux (Ubuntu) => amd ** Changed in: amd Importance: Undecided => High ** Information type changed from Private to Proprietary -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1736862 Title: [Raven1] EFI FB driver cannot get 64-bit FB address with "Above 4G MMIO" enabled in Ubuntu16.04.3 Status in amd: New Bug description: With "Above 4G MMIO" enabled in BIOS, EFI FB driver cannot get 64-bit FB address on Raven1 platform. Then fail to initialize EFI FB driver. That results in black-screen for console mode or installing Ubuntu system. e.g. if the FB address is 0x7fc8000, EFI FB could only get the low 32-bit FB address. [0.992990] efifb: probing for efifb [0.992995] efifb: cannot reserve video memory at 0x8000 [0.992999] ioremap on RAM at 0x8000 - 0x808c As my investigation, it looks Ubuntu efi boot stub cannot get 64-bit address by GOP. 1) create a EFI shell app to get the fb address, it’s 64-bit 2) Build bzImage.efi to load 4.13 custom kernel, efifb driver also could get 64-bit address. To manage notifications about this bug go to: https://bugs.launchpad.net/amd/+bug/1736862/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1736862] Re: [Raven1] EFI FB driver cannot get 64-bit FB address with "Above 4G MMIO" enabled in Ubuntu16.04.3
** Attachment added: "boot_4.13_custom_kernel_with_bzImage.efi.JPG" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1736862/+attachment/5019589/+files/boot_4.13_custom_kernel_with_bzImage.efi.JPG -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1736862 Title: [Raven1] EFI FB driver cannot get 64-bit FB address with "Above 4G MMIO" enabled in Ubuntu16.04.3 Status in amd: New Bug description: With "Above 4G MMIO" enabled in BIOS, EFI FB driver cannot get 64-bit FB address on Raven1 platform. Then fail to initialize EFI FB driver. That results in black-screen for console mode or installing Ubuntu system. e.g. if the FB address is 0x7fc8000, EFI FB could only get the low 32-bit FB address. [0.992990] efifb: probing for efifb [0.992995] efifb: cannot reserve video memory at 0x8000 [0.992999] ioremap on RAM at 0x8000 - 0x808c As my investigation, it looks Ubuntu efi boot stub cannot get 64-bit address by GOP. 1) create a EFI shell app to get the fb address, it’s 64-bit 2) Build bzImage.efi to load 4.13 custom kernel, efifb driver also could get 64-bit address. To manage notifications about this bug go to: https://bugs.launchpad.net/amd/+bug/1736862/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1742759] Re: boot failure on AMD Raven + WestonXT
Verified the hwe kernel 4.13.0-36.40~16.04.1, including the fix patch. The WestenXT is able to be controlled by pm-runtime normally. Jerry -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1742759 Title: boot failure on AMD Raven + WestonXT Status in amd: New Status in linux package in Ubuntu: Fix Released Status in linux-oem package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Status in linux-oem source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux-oem source package in Artful: Invalid Bug description: This issue has been fixed with with patch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm- next-4.16&id=052c299080cd6859f82a8154a7a673fafabe644c drm/amdgpu: add atpx quirk handling (v2) Add quirks for handling PX/HG systems. In this case, add a quirk for a weston dGPU that only seems to properly power down using ATPX power control rather than HG (_PR3). v2: append a new weston XT To manage notifications about this bug go to: https://bugs.launchpad.net/amd/+bug/1742759/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
