Created attachment 142935 [details]
Kernel 4.20 log showing firmware loading crash

Could you give me a list of all files in /lib/firmware/amdgpu/?
And if it contains a file called raven_dmcu.bin, please attach that file.

Created attachment 142978 [details]
List of files in /lib/firmware/amdgpu

Created attachment 142979 [details]
Raven dmcu firmware

Created attachment 143105 [details]
Kernel log on 5.0.0-rc2 showing firmware loading crash

I'm getting the exact same issue on 5.0.0 rc2; kernel log attached. Both the list of files in /lib/firmware/amdgpu/ and the raven_dmcu.bin are identical to the ones already attached.

Still having the same bug in kernel 5.0-rc4 and my raven_dmcu.bin also matches to the previously attached bin file(sha256 a45972418d1c078afbd7884ffd58784954220759bc0d5464ce60165ffe1775bd).

However, in one of my tests I got it to work! So the time it worked I got lucky I somehow misplaced raven_dmcu.bin so when I rebooted the kernel 5.0rc4 and checked /lib/firmware/amdgpu/raven_dmcu.bin it wasn't there. As soon as I put raven_dmcu.bin back in the folder /lib/firmware/amdgpu/ I got this bug again. So the workaround is to delete raven_dmcu.bin from /lib/firmware/amdgpu for now until they fix it. Laptop seems to work just fine. I don't know what that firmware is for but it doesn't look like it's a required file for my HP x360 AMD Ryzen 2500U laptop

Can confirm that removing raven_dmcu.bin allows amdgpu to load.  Note that kernel 4.20 also requires iommu=pt kernel option.

I encounter the same bug on my HP Envy x360, Ryzen 2500U.
Deleting raven_dcmu.bin and setting iommu=pt on kernel 4.20.5 still doesn't solve the bug.

Raven_dmcu.bin can get packed in the initramfs Image if amdgpu is loaded at boot.  Check the initramfs by running “lsinitcpio /boot/name of initramfs.img”.  If you see raven_dmcu.bin in the image from the previous command, remove raven_dmcu.bin from /lib/firmware then run “mkinitcpio -p linux”.

I also encounter this bug on my HP Envy x360 Ryzen 5 2500U.

What worked for me as a workaround was to first upgrade the kernel to 4.20.7, then remove "raven_dmcu.bin" and finally run "mkinitcpio -p linux".

This is the exact same issue I had and the above solution for removing /lib/firmware/amdgpu/raven_dmcu.bin worked for me. 

For Ubuntu Users on 4.20 you'll need to also run 

sudo update-initramfs -u

to update the bootimage. Thanks Chris.

(In reply to matrix8967 from comment #11)
> This is the exact same issue I had and the above solution for removing
> /lib/firmware/amdgpu/raven_dmcu.bin worked for me. 
> 
> For Ubuntu Users on 4.20 you'll need to also run 
> 
> sudo update-initramfs -u
> 
> to update the bootimage. Thanks Chris.

Removing this file and updating my initramfs allows my 2500u HP x360 to actually boot to the desktop.  Unfortunately, the moment you try to load any game or even the Steam client, the laptop will hard lock.

The desktop is otherwise functional.

I get hard lock during LibreOffice start after this workaround. Nothing interesting in logs can be found.

I'd recommend updating the System BIOS.

Early BIOSes on HP Envy x360 (and possibly other Raven laptops) had trouble loading the DMCU FW.

Can you see if this patch fixes it: https://patchwork.freedesktop.org/patch/277181/

Is it possible to upgrade the Bios from Linux? I think it's just a windows-only bios upgrade from HP right? Will it work in Freedos?

I don't have that laptop but this link mentions a method to "Update the BIOS when Windows does not start": https://support.hp.com/ca-en/document/c00042629

I'd be more curious to know if the patch I posted fixes it.

(In reply to Adrian Garay from comment #12)
> (In reply to matrix8967 from comment #11)
> > This is the exact same issue I had and the above solution for removing
> > /lib/firmware/amdgpu/raven_dmcu.bin worked for me. 
> > 
> > For Ubuntu Users on 4.20 you'll need to also run 
> > 
> > sudo update-initramfs -u
> > 
> > to update the bootimage. Thanks Chris.
> 
> Removing this file and updating my initramfs allows my 2500u HP x360 to
> actually boot to the desktop.  Unfortunately, the moment you try to load any
> game or even the Steam client, the laptop will hard lock.
> 
> The desktop is otherwise functional.

Possibly related to https://bugzilla.redhat.com/show_bug.cgi?id=1562530

(In reply to Harry Wentland from comment #15)
> Can you see if this patch fixes it:
> https://patchwork.freedesktop.org/patch/277181/


Wasn't able to get that patch to apply cleanly to either 4.20 or 5.0rc2. I did attempt to manually edit the function in the amdgpu_psp.c file according to the patch, but now have in my log:

"[drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2! type 0 expected 3" 

I'm assuming I attempted to apply the patch to the wrong revision. Behavior for me is somewhat changed, before the patch I got about 4 lines of scrambled pixels about 4/5ths of the way down my screen on anything above kernel 4.19, with the patch applied to 5.0rc2 those lines appear for a couple of seconds and then the screen goes and remains totally blank.

I can attach the full log if you want, but considering I wasn't able to directly apply the patch and instead manually modified the "psp_cmd_submit_buf" function to warn instead of error and not return -EINVAL as described in the patch, I'd rather not clutter this with potentially bad log data. Should that patch be applied to drm-next instead of what is in the mainline kernel?

I changed my kernel to the linux-amd-staging-drm-next-git which already has patch applied.  System boots, X starts fine, and I am able to run intensive 3d app without any performance/rendering issues, no special kernel commandline required.  I get same error message as comment #19, but no “scrambled pixels.”

NB For users with HP Envy x360 15m-bq1**** model laptops, the latest BIOS is F.20 which is not listed in the downloads section of HP support site, but rather under Advisories, https://support.hp.com/us-en/product/hp-envy-15m-bq100-x360-convertible-pc/16851057/model/18967057/document/c06219875 .

NB2 For system stability, I added kernel option idle=nomwait which seems to have made the laptop far less crashy, YMMV.

I can confirm that the amd-staging-drm-next kernel also works for my system.

Created attachment 143560 [details]
logged when modprobe amdgpu is run

I am on firmware F.20 and the above does not work for me.  I still see the scrambled line of garbage at boot, but instead of crashing my screen just goes blank. 

If I add modprobe.blacklist=amdgpu to the kernel I can boot, where I then SSH in and record the log file while running modprobe amdgpu from the laptop (attached.)

Since I didn't clearly specify above, my result was with amd-staging-drm-next, but the behavior is identical to the current 5.0 release.  When the screen goes blank the machine stops responding, but it appears systemd still periodically logs work such as cron jobs.  Laptop has to be hard powered down by holding the power switch.

(In reply to Harry Wentland from comment #17)
> I don't have that laptop but this link mentions a method to "Update the BIOS
> when Windows does not start": https://support.hp.com/ca-en/document/c00042629
> 
> I'd be more curious to know if the patch I posted fixes it.

I tried the linux-amd-staging-drm-next kernel (which should already have the patch if the other comments are to be trusted). I have the same error as comment #19, but the screen goes completely blank while the system stays responsive. I can even start X and run glxgears in it, although the screen still stays black and I can't see anything. It runs at 60 FPS for the first ~5 seconds, then drops to a steady 1 FPS.

Edit to my above statement about the amd-staging-drm-next kernel working. Either, I had forgotten to return the raven_dmcu.bin file to it's appropriate folder when I tested it, or upgrading my bios to F.20 messed it up again. I'm now back at the point I was before (Same as comment #24). If Magic SysReq is enabled on the system it can be used to reboot the system safely rather than a hard powerdown.

I am following 7 serious bug reports on kernel, redhat, freedesktop bugzillas.
This one is by far the most critical when one can not boot the machine. I am happy to try to test things. I am not set up to compile a kernel, but I can try release candidates. If anyone sees something that might work, please let me know.

model name	: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx

Command line: BOOT_IMAGE=/vmlinuz-4.19.15-300.fc29.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8 idle=nomwait iommu=pt processor.max_cstate=1

DMI: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018

I'm not sure if I want to delete raven_dcmu.bin on my system, would renaming it or moving it have the same effect? I have the same system as JerryD and am running Fedora 29 KDE.

Also, it seems that for the HP Envy x360 laptop, the latest BIOS is back to F.10; F.20 is listed in "previous versions".

https://support.hp.com/us-en/drivers/selfservice/hp-envy-15-bq100-x360-convertible-pc/16851053

Unfortunately there doesn't seem to be a way to downgrade.

(In reply to Talha Khan from comment #29)
> Also, it seems that for the HP Envy x360 laptop, the latest BIOS is back to
> F.10; F.20 is listed in "previous versions".
> 
> https://support.hp.com/us-en/drivers/selfservice/hp-envy-15-bq100-x360-
> convertible-pc/16851053
> 
> Unfortunately there doesn't seem to be a way to downgrade.

Yes renaming should work. I didn't want to delete it either so I just backed up the file and deleted it. F20 is the latest, their site is just wonky. Although I hate that you can't downgrade I partially agree with the decision since it includes security updates you shouldn't roll back. They take that very seriously and I can objectively appreciate that

I moved the raven_dcmu.bin file to another directory, but unfortunately I am still unable to boot any kernel newer 4.20. For me at least, I get a black screen with a horizontal line near the bottom of orange pixels. I will attach the journalctl output from my last boot into kernel 5.0.5.

There was a bug filed in Red Hat bugzilla related to this:

https://bugzilla.redhat.com/show_bug.cgi?id=1668647

Created attachment 143893 [details]
Journalctl output for kernel 5.0.5-200.fc29.x86_64

(In reply to Talha Khan from comment #31)
> I moved the raven_dcmu.bin file to another directory, but unfortunately I am
> still unable to boot any kernel newer 4.20. For me at least, I get a black
> screen with a horizontal line near the bottom of orange pixels. I will
> attach the journalctl output from my last boot into kernel 5.0.5.

Make sure you update your initrd if you move the file, otherwise, the driver will pick it up from the initrd at load time.

(In reply to Alex Deucher from comment #33)
> (In reply to Talha Khan from comment #31)
> > I moved the raven_dcmu.bin file to another directory, but unfortunately I am
> > still unable to boot any kernel newer 4.20. For me at least, I get a black
> > screen with a horizontal line near the bottom of orange pixels. I will
> > attach the journalctl output from my last boot into kernel 5.0.5.
> 
> Make sure you update your initrd if you move the file, otherwise, the driver
> will pick it up from the initrd at load time.

Thanks Alex.

This time after I moved the raven_dcmu.bin file, I ran the following to update the initramfs image as root:

dracut --kver 5.0.6-200.fc29.x86_64 --force

This time:
1. The black screen with the horizontal line of pixels appeared, but for a split second, and then things started working like normal.
2. I was able to log into KDE Plasma like normal.

I did a quick suspend/resume and that worked also (although there was a split second of scrambled pixels).

Does this mean that there's something wrong with the raven_dcmu.bin file?

Well, I just ran Fedora updates which brought kernel to 5.0.7-200.fc29 and there was also an update to mesa-dri-drivers.x86_64 18.3.6-1.fc29. My laptop failed to boot with or without the raven_dmcu.bin file after this update.

I then also noted that the 5.06 kernel will boot with or without the raven_dmcu.bin file.  I am leaving that firmware file in place and using 5.06 kernel at the moment.

I suspect we have a "whack-a-mole" bug, also affectionately known as a Heisenbug. Or at least more than one problem overlapping another. Hard to say whether the problem is in the kernel or somewhere else. For sure, I can not boot the 5.07.

(In reply to JerryD from comment #35)
> Well, I just ran Fedora updates which brought kernel to 5.0.7-200.fc29 and
> there was also an update to mesa-dri-drivers.x86_64 18.3.6-1.fc29. My laptop
> failed to boot with or without the raven_dmcu.bin file after this update.
> 
> I then also noted that the 5.06 kernel will boot with or without the
> raven_dmcu.bin file.  I am leaving that firmware file in place and using
> 5.06 kernel at the moment.
> 
> I suspect we have a "whack-a-mole" bug, also affectionately known as a
> Heisenbug. Or at least more than one problem overlapping another. Hard to
> say whether the problem is in the kernel or somewhere else. For sure, I can
> not boot the 5.07.

I also updated my system to kernel 5.0.7-200.fc29 and mesa-dri-drivers.x86_64 version 18.3.6-1.fc29, and here are the results for me:
original initramfs image with raven_dmcu.bin file: Unable to boot, same issue as before.
updated initramfs image without raven_dmcu.bin file: able to boot fine.

It's unfortunate that the issue is so hard to reproduce.

The issue occurs (and workaround works) on kernels 5.0.8 and 5.0.9.

(In reply to Alex Deucher from comment #33)
> (In reply to Talha Khan from comment #31)
> > I moved the raven_dcmu.bin file to another directory, but unfortunately I am
> > still unable to boot any kernel newer 4.20. For me at least, I get a black
> > screen with a horizontal line near the bottom of orange pixels. I will
> > attach the journalctl output from my last boot into kernel 5.0.5.
> 
> Make sure you update your initrd if you move the file, otherwise, the driver
> will pick it up from the initrd at load time.

Alex, is there a known issue with raven_dmcu.bin and this chipset or is it specific to this laptop?  

No distro with a recent kernel is installable on my laptop unless I nomodeset the kernel and remove this firmware file from the initramfs.

Thanks.

(In reply to Adrian Garay from comment #38)
> (In reply to Alex Deucher from comment #33)
> > (In reply to Talha Khan from comment #31)
> > > I moved the raven_dcmu.bin file to another directory, but unfortunately I am
> > > still unable to boot any kernel newer 4.20. For me at least, I get a black
> > > screen with a horizontal line near the bottom of orange pixels. I will
> > > attach the journalctl output from my last boot into kernel 5.0.5.
> > 
> > Make sure you update your initrd if you move the file, otherwise, the driver
> > will pick it up from the initrd at load time.
> 
> Alex, is there a known issue with raven_dmcu.bin and this chipset or is it
> specific to this laptop?  

I think it's specific to the sbios version.

Issue still present on Fedora30 with Kernel 5.0.9-301.fc30.x86_64

Workaround 

sudo mv /usr/lib/firmware/amdgpu/raven_dmcu.bin /home/XXX/
sudo dracut -f --kver 5.0.9-301.fc30.x86_64


Tested and working on 

HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.17 03/29/2018

Thanks for the update Jay. Did you upgrade or do a fresh install?

This was an upgrade from Fedora 29 with the above workaround applied to a v5 kernel.

Booting from the KDE spin of Fedora 30 would only work with limited graphics (nomodset) as the default boot hung.

I do not have access to that machine at the moment but will pull any required logs later.

I updated my Fedora KDE spin system from Fedora 29 to Fedora 30 and had the same experience as Jay's.

Created attachment 144316 [details]
Kernel log 5.1.3 showing amdgpu drm crash

Experiencing the same problem. On boot with any kernel > 4.20, the graphics is not initialized, few scrambled lines appear at the bottom of the screen and then the screen goes blank. The system actually boots as when I entered my credentials (on the black screen) and did "cat dmesg > dmesg.txt", when I rebooted with kernel 4.19 the file was there (I have attached it to this thread). The relevant portion of the dmesg log is:

[    5.133929] [drm] REG_WAIT timeout 1us * 100000 tries - mpc1_assert_idle_mpcc line:103
[    5.134034] WARNING: CPU: 2 PID: 367 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:277 generic_reg_wait.cold.0+0x29/0x30 [amdgpu]
...
[    5.134925]  drm_dev_register+0x111/0x150 [drm]
[    5.135335] [drm] Display Core initialized with v3.2.17!
[    5.642999] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!
[    6.142512] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!
[    6.143119] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    6.143121] [drm] Driver supports precise vblank timestamp query.
[    6.158613] [drm] VCN decode and encode initialized successfully(under SPG Mode).
[    6.161822] [drm] Cannot find any crtc or sizes
[    6.188933] [drm] Initialized amdgpu 3.30.0 20150101 for 0000:04:00.0 on minor 0

I can also confirm that as a workaround, removing/moving file /lib/firmware/amdgpu/raven_dmcu.bin and regenerating the initramfs ("mkinitcpio -p linux" on Arch linux) allows the 5.1.3 kernel to boot normally (I can also start an X session and everything seems to be fine) and there are no drm errors in dmesg anymore.

System:
HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018
Kernel: 5.1.3-arch1-1-ARCH
Grub kernel parameters: amd_iommu=on iommu=pt idle=nomwait

If you need anything else let me know

I just came across this article, which seems to suggest a fix for the issue mentioned in this thread is coming in a future linux-firmware update:

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Raven1-Skip-The-DMCU

It seem s patch has already been proposed to the kernel tree so hopefully this will fix the problem with some laptop models with the Raven Ridge 1 CPUs.

Patch url:

https://lists.freedesktop.org/archives/amd-gfx/2019-May/034307.html

Thanks for the update Ondrej. It seems that the patch may be in place. Since I've updated my Fedora 30 system's kernel to 5.1.6, I haven't had to run dracut to rebuild my initramfs. The raven_dmcu.bin file remains renamed as raven_dmcu.bin.old. Previously, I've had to move/rename the file and run dracut every time a kernel update came out.

The patch is not part of the kernel package itself, it is part of the linux-firmware package, there was no new release of linux-firmware since I tested this.

I think the reason why you did not have to rebuld the initramfs is that there was no linux-firmware update, which would again put the raven_dmcu.bin file in /lib/firmware/amdgpu/ folder and also in the initramfs, so you would need to rename/move it again and run dracut to rebuild the initramfs.

once a new version of linux-firmware comes out (with the patch) I will re-test and report results here.

The patch is for the kernel.

I updated my kernel to 5.1.7 and did not need to run dracut to rebuild my initramfs. I was able to boot just fine.

I tested this yesterday with kernel 5.1.8 and if the file raven_dmcu.bin is present in the /lib/firmware/amdgpu/ folder when you are updating the kernel (or manually rebuilding the initramfs), the computer will boot with a blank screen next time.

There are 2 pieces to this. The linux-firmware package provides the binary files (i.e. the raven_dmcu.bin) so every time this package gets updated, you should rename/move the file and rebuild the initramfs. The linux-firmware updates are not as frequent as the kernel updates so if you do the workaround, you might go through several kernel updates without issues, but once linux-firmware updates, you have to repeat the workaround...

All the patch in the kernel will do is to ignore the raven_dmcu.bin file automatically (for raven 1 cpus) when building the initramfs so you don't have to rename/move it every time linux-firmware updates.

Also cannot boot without nomodeset or modprobe.blacklist=amdgpu. With the latter, I get a black screen if I run `modprobe amdgpu`.

I have Ryzen 2400G.

The trick with moving raven_dmcu.bin (as per below) didn't help.

```
mv /lib/firmware/amdgpu/raven_dmcu.bin ~/
update-initramfs -u
```

On Ubuntu/Linux 5.1.0.

(In reply to Ondrej Lang from comment #50)
> I tested this yesterday with kernel 5.1.8 and if the file raven_dmcu.bin is
> present in the /lib/firmware/amdgpu/ folder when you are updating the kernel
> (or manually rebuilding the initramfs), the computer will boot with a blank
> screen next time.
> 
> There are 2 pieces to this. The linux-firmware package provides the binary
> files (i.e. the raven_dmcu.bin) so every time this package gets updated, you
> should rename/move the file and rebuild the initramfs. The linux-firmware
> updates are not as frequent as the kernel updates so if you do the
> workaround, you might go through several kernel updates without issues, but
> once linux-firmware updates, you have to repeat the workaround...
> 
> All the patch in the kernel will do is to ignore the raven_dmcu.bin file
> automatically (for raven 1 cpus) when building the initramfs so you don't
> have to rename/move it every time linux-firmware updates.

You're right, I had updated to 5.1.15 and it seemed the firmware files were updated as well. I then had to perform the workaround in order to boot into the system.

According to the linux kernel 5.2 changelog (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2), the fix for the DMCU firmware issue on raven1 platform is included in that release.

I went ahead and tested this and can confirm that I was able to boot without a blank screen into my machine with kernel 5.2 without needing to use the workaround.

I tested with:
1.) re-installed latest linux-firmware package
2.) installed kernel 5.2
3.) re-generated the initramfs
4.) booted into linux using kernel 5.2 and had no blank screen, dmesg output is clean with no erros for amdgpu

Tested on:
HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.21 04/29/2019

I guess if someone else can confirm my findings, maybe on different raven1 hardware, this ticket can be closed.

Ondrej - I'm on a fresh install of Ubuntu 19.04 with no workarounds applied, using a similar setup to yours (HP Envy x360 15m-bq121dx.)  I installed kernel 5.2 RC7 (since the AMD64 build of 5.2 final on kernel.ubuntu.com is broken), and updated to the latest linux-firmware package available on the disco feed (1.178.2).  I should also note I'm on HP BIOS firmware version 21.  While the system boots to the desktop environment, there's tons of garbage, and when using Firefox, screen writes are occuring on random parts of the screen.  Also, I attempted running Basemark Web 3.0 in Firefox, and can consistently lock up the machine.  For reference, the kernel version is 5.2.0-050200rc7-lowlatency.

(In reply to Joe Coutcher from comment #54)
> Ondrej - I'm on a fresh install of Ubuntu 19.04 with no workarounds applied,
> using a similar setup to yours (HP Envy x360 15m-bq121dx.)  I installed
> kernel 5.2 RC7 (since the AMD64 build of 5.2 final on kernel.ubuntu.com is
> broken), and updated to the latest linux-firmware package available on the
> disco feed (1.178.2).  I should also note I'm on HP BIOS firmware version
> 21.  While the system boots to the desktop environment, there's tons of
> garbage, and when using Firefox, screen writes are occuring on random parts
> of the screen.  Also, I attempted running Basemark Web 3.0 in Firefox, and
> can consistently lock up the machine.  For reference, the kernel version is
> 5.2.0-050200rc7-lowlatency.

Hi Joe,

I'm quite sure your issue is not related to this ticket. The problem in this bug report is quite specific and is related to the raven_dmcu.bin firmware. It has a specific symptom where the screen is not initialized during boot (stays blank / black) so I think you need to report your problem somewhere else. Also, it would be good if you can check the kernel log after crash and see what error messages you have and then google for that specific message to find if someone else already created a bug report for it.

I have been running kernel 5.2 since yesterday and had no issues whatsoever. I also just run the Basemark Web 3.0 benchmark and had no issues.

As for your lockups, I know that the AMD APU had problems with random lockups in earlier kernels (if I remember correctly it was related to the C-state changes of the CPU), I myself had the problem and for me the fix was to add "idle=nomwait" to my kernel parameters. That fixed the random lockups for me. Now I don't know if this issue has already been addressed, last time I tried without the parameter was kernel 5.0 I think and still had lockups, so this might not be related to your specific problem, but as I said, best course of action for you is to inspect the kernel log after a crash, check the error message and then search for a bug report with that error and report your findings there.

(In reply to Ondrej Lang from comment #53)
> According to the linux kernel 5.2 changelog
> (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2), the fix for
> the DMCU firmware issue on raven1 platform is included in that release.
> 
> I went ahead and tested this and can confirm that I was able to boot without
> a blank screen into my machine with kernel 5.2 without needing to use the
> workaround.
> 
> I tested with:
> 1.) re-installed latest linux-firmware package
> 2.) installed kernel 5.2
> 3.) re-generated the initramfs
> 4.) booted into linux using kernel 5.2 and had no blank screen, dmesg output
> is clean with no erros for amdgpu
> 
> Tested on:
> HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.21 04/29/2019
> 
> I guess if someone else can confirm my findings, maybe on different raven1
> hardware, this ticket can be closed.


Hi Ondrej

While I have not been able to test the 5.2 kernel on my Fedora system I have installed the 5.3 kernel from rawhide and am seeing the same results:

[root@envy ~]# cp /home/XXX/raven_dmcu.bin /usr/lib/firmware/amdgpu/
[root@envy ~]# dracut -f --kver 5.3.0-0.rc0.git2.2.fc31.x86_64
[root@envy ~]# reboot

Tested on HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018
Kernel version 5.3.0-0.rc0.git2.2.fc31.x86_64 

Installing rawhide kernel on Fedora without debug enabled:
sudo dnf config-manager --add-repo=http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo
sudo yum upgrade

(In reply to Ondrej Lang from comment #55)
> Hi Joe,
> 
> I'm quite sure your issue is not related to this ticket. The problem in this
> bug report is quite specific and is related to the raven_dmcu.bin firmware.
> It has a specific symptom where the screen is not initialized during boot
> (stays blank / black) so I think you need to report your problem somewhere
> else. Also, it would be good if you can check the kernel log after crash and
> see what error messages you have and then google for that specific message
> to find if someone else already created a bug report for it.
> 
> I have been running kernel 5.2 since yesterday and had no issues whatsoever.
> I also just run the Basemark Web 3.0 benchmark and had no issues.
> 
> As for your lockups, I know that the AMD APU had problems with random
> lockups in earlier kernels (if I remember correctly it was related to the
> C-state changes of the CPU), I myself had the problem and for me the fix was
> to add "idle=nomwait" to my kernel parameters. That fixed the random lockups
> for me. Now I don't know if this issue has already been addressed, last time
> I tried without the parameter was kernel 5.0 I think and still had lockups,
> so this might not be related to your specific problem, but as I said, best
> course of action for you is to inspect the kernel log after a crash, check
> the error message and then search for a bug report with that error and
> report your findings there.

Sorry...I was using the Lynx browser to type out the reply last night and didn't include all the details.  :-)

My report was related to this issue.  On every distro I've tried (Ubuntu 19.04, Fedora 30, OpenSuSE Tumbleweed), whenever it tries to initialize the firmware, the system goes to a black screen.  The only way for me to get around it is to boot with nomodeset, remove raven_dmcu.bin, update my initrd, and reboot.

My tests were to provide a baseline: fresh install, no workarounds applied, with kernel 5.2rc7 and latest linux-firmware package (AFAIK.)  Under those conditions, raven_dmcu.bin loads, I can get to the GUI, but seeing garbage on the screen.

When I have some time this weekend, I'll do some more testing/sift through the logs/try building 5.2 final and see if anything jumps out at me.  I'll also retry my tests with idle=nomwait.

Update - After adding init=nomwait and iommu=pt to my kernel parameters, I'm no longer seeing garbage on the display, and the system has been stable for the past hour on 5.2rc7.

(In reply to Jay Fitzpatrick from comment #56)
> (In reply to Ondrej Lang from comment #53)
> > According to the linux kernel 5.2 changelog
> > (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2), the fix for
> > the DMCU firmware issue on raven1 platform is included in that release.
> > 
> > I went ahead and tested this and can confirm that I was able to boot without
> > a blank screen into my machine with kernel 5.2 without needing to use the
> > workaround.
> > 
> > I tested with:
> > 1.) re-installed latest linux-firmware package
> > 2.) installed kernel 5.2
> > 3.) re-generated the initramfs
> > 4.) booted into linux using kernel 5.2 and had no blank screen, dmesg output
> > is clean with no erros for amdgpu
> > 
> > Tested on:
> > HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.21 04/29/2019
> > 
> > I guess if someone else can confirm my findings, maybe on different raven1
> > hardware, this ticket can be closed.
> 
> 
> Hi Ondrej
> 
> While I have not been able to test the 5.2 kernel on my Fedora system I have
> installed the 5.3 kernel from rawhide and am seeing the same results:
> 
> [root@envy ~]# cp /home/XXX/raven_dmcu.bin /usr/lib/firmware/amdgpu/
> [root@envy ~]# dracut -f --kver 5.3.0-0.rc0.git2.2.fc31.x86_64
> [root@envy ~]# reboot
> 
> Tested on HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018
> Kernel version 5.3.0-0.rc0.git2.2.fc31.x86_64 
> 
> Installing rawhide kernel on Fedora without debug enabled:
> sudo dnf config-manager
> --add-repo=http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/
> fedora-rawhide-kernel-nodebug.repo
> sudo yum upgrade

--Update--

While kernel versions 5.3.0-0.rc0.git2.2.fc31.x86_64 and 5.3.0-0.rc0.git2.4.fc31.x86_64 versions of the kernel seemed to be pretty stable when it came to booting the system / touchscreen working etc, there was a massive amount of video tearing (within Chrome / Konsole) within my KDE session, enough to force me to roll back to 5.1.16-300.fc30.x86_64

Jay

Created attachment 144787 [details]
attachment-8612-0.html

I am seeing reports with old BIOS, such as F.19.
I have a 15-cp0001na
https://support.hp.com/ie-en/drivers/selfservice/hp-envy-15-cp0000-x360-convertible-pc/20270303/model/23086446
Latest available is F.42 Rev.A
I am wondering if by any chance would be a match to other models also.

(In reply to Michael Eagle from comment #60)
> Created attachment 144787 [details]
> attachment-8612-0.html
> 
> I am seeing reports with old BIOS, such as F.19.
> I have a 15-cp0001na
> https://support.hp.com/ie-en/drivers/selfservice/hp-envy-15-cp0000-x360-
> convertible-pc/20270303/model/23086446
> Latest available is F.42 Rev.A
> I am wondering if by any chance would be a match to other models also.

The latest BIOS for my HP Envy x360 15-bq100 is F.21:
https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-envy-15-bq100-x360-convertible-pc/16851053/model/18706859/swItemId/ob-232955-1?sku=1ZA02AV

My current kernel is 5.1.17-300 and so far there hasn't been any boot issues yet.

Just wanted to say that on Kernel 5.2rc7, BIOS F.21 I'm able to boot with raven_dmcu.bin in /lib/firmware/amdgpu. I also updated raven_dmcu.bin from the linux firmware git. Not sure which part helped though or all of them together.

I updated my kernel to 5.1.19, and the firwmare files were updated, but I wasn't able to boot. I had to boot back into 5.1.16 and perform the workaround before being able to boot into 5.1.19.

Created attachment 145952 [details]
Journal boot from hp envy x360 cp0xxx

The bug caused the Raven Ridge firmware to fail is back on kernel 5.3.11. Even the latest git version is affected

Change the title reflecting the impact on Raven Ridge

The dmcu firmware is no longer loaded on affected raven systems.

(In reply to Luya Tshimbalanga from comment #65)
> Change the title reflecting the impact on Raven Ridge

This is completely unrelated to your issue.  Please don't appropriate other bugs for unrelated issues.

(In reply to Alex Deucher from comment #67)
> (In reply to Luya Tshimbalanga from comment #65)
> > Change the title reflecting the impact on Raven Ridge
> 
> This is completely unrelated to your issue.  Please don't appropriate other
> bugs for unrelated issues.

Sorry about that.

Upgraded to 5.3.11-300.fc31.x86_64 this morning with linux-firmware-20191022-103.fc31.noarch and no evidence of regression

Jay