Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bios Upgrade from DMCN32WW to DMCN34WW does not support kernel 5.9, works with 5.4 in Ubuntu #14

Open
ko-christ opened this issue Dec 5, 2020 · 8 comments

Comments

@ko-christ
Copy link
Contributor

In https://forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/Yoga-Slim-7-BIOS-update-to-DMCN34WW-breaks-option-Secure-Boot-No/m-p/5046311?page=1#5196561 it was reported that the upgrade with 5.9 is not possible because the kernel is unsigned and it fails to boot. So I thought it would make sense to try with a signed kernel.

Here is what I tried.

While I was in DMCN32WW I installed a self-signed 5.9.12 kernel and then I enabled Secure Boot.
With this setup (DMCN32WW + Secure Boot on) I was also able to boot with my self-signed kernel as well as with the 5.4.0 Ubuntu kernel but I was not able to boot with the unsigned 5.9.12 kernel which was kind of expected.

I then installed DMCN34WW but unfortunately the system didn't boot with the self-signed 5.9.12 kernel.
The system freezes with a message Loading ramdisk and nothing happens.
The unsigned 5.9.12 kernel was raising another error for the unsigned kernel with a message like please load the kernel..
I was only able to boot with the official 5.4.0 kernel but as you may already know this is useless in Yoga Slim 7 especially if you need HDMI.
Disabling Secure Boot in DMCN34WW didn't make any difference. I cannot figure out why 5.9 self-signed kernel fails with DMCN34WW and what was this loading ramdisk message about.
So my attempt to upgrade the BIOS failed and I had to enable version downgrade in the bios and then revert to DMCN32WW.

If anyone has a solution to install a 5.9+ kernel with DMCN34WW please post it.

@ko-christ ko-christ mentioned this issue Dec 5, 2020
@jrandiny
Copy link
Owner

Hi, I have upgraded my BIOS to version DMCN34WW and yes I can't boot the system at first. However after recreating the acpi override everything works fine.

@soupli
Copy link

soupli commented Dec 18, 2020

I just successfully updated the kernel to 5.10.1 on ubuntu 20.04.1 with DMCN34WW.

Also suspending by closing and reactivate by opening the lid seems to work thus far. Suspending via the gui did not seem to work properly, but i haven't properly "tested" this

@rradar
Copy link

rradar commented Dec 18, 2020

I just successfully updated the kernel to 5.10.1 on ubuntu 20.04.1 with DMCN34WW.

Also suspending by closing and reactivate by opening the lid seems to work thus far.

@soupli did you "Modify the system to advertise S3 support" or is this bug finally fixed with the newest bios and a 5.10.1 kernel?

@soupli
Copy link

soupli commented Dec 18, 2020 via email

@ko-christ
Copy link
Contributor Author

ko-christ commented Dec 19, 2020

I have also installed 5.10.1 and then reinstalled BIOS DMCN34WW on ubuntu 20.04.1.
I can boot the OS if I edit GRUB upon boot and remove the /boot/acpi_s3_override

I have verified that suspend still does not work for me (without the S3 patch).

# grep amdgpu_device_ip_resume kern.log
Dec 19 11:04:04 yoga kernel: [  389.954138] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <gfx_v9_0> failed -110
Dec 19 11:04:04 yoga kernel: [  389.954141] amdgpu 0000:03:00.0: amdgpu: amdgpu_device_ip_resume failed (-110).
Dec 19 11:06:33 yoga kernel: [   50.999448] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <gfx_v9_0> failed -110
Dec 19 11:06:33 yoga kernel: [   50.999451] amdgpu 0000:03:00.0: amdgpu: amdgpu_device_ip_resume failed (-110).

Note: 11.04.04 is using lid, 11.06.33 is using the UI menu button, so it failed in both cases for me.

I am now in the process of re-creating the S3 override.

But the iasl -e *.dat -d dsdt.dat has failed too.

External object resolution file         asf!.dat
Input file asf!.dat, Length 0xA5 (165) bytes
    asf!.dat: Table [ASF!] is not an AML table - ignoring
External object resolution file         apic.dat
Input file apic.dat, Length 0x138 (312) bytes
    apic.dat: Table [APIC] is not an AML table - ignoring
Pass 1 parse of [DSDT]
ACPI Error: ^^^UBTC.VER1: Path has too many parent prefixes (^) (20190509/nsaccess-464)
ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190509/psobject-264)
ACPI Error: ^^^UBTC.VER2: Path has too many parent prefixes (^) (20190509/nsaccess-464)
ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190509/psobject-264)
ACPI Error: ^^^UBTC.MGI0: Path has too many parent prefixes (^) (20190509/nsaccess-464)
ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190509/psobject-264)
ACPI Error: ^^^UBTC.MGI1: Path has too many parent prefixes (^) (20190509/nsaccess-464)
ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190509/psobject-264)
..
..
..
ACPI Error: ^^^UBTC.STS7: Path has too many parent prefixes (^) (20190509/nsaccess-464)
ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190509/psobject-264)
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    dsdt.dsl - 505104 bytes

and patch fails

# patch <dsdt.patch
patching file dsdt.dsl
Hunk #1 FAILED at 1.
Hunk #3 succeeded at 974 (offset -3 lines).
Hunk #4 succeeded at 11161 (offset -209 lines).
1 out of 4 hunks FAILED -- saving rejects to file dsdt.dsl.rej

Same issue with both 20200717 & 20201217 acpica versions that I tried.

@ko-christ
Copy link
Contributor Author

ko-christ commented Dec 19, 2020

I have removed the acpi_s3_override S3 settings as well as the mem_sleep_default=deep from grub permanently and applied the following settings in /etc/systemd/logind.conf.

HandleSuspendKey=suspend
HandleLidSwitch=suspend
HandleLidSwitchExternalPower=suspend
HandleLidSwitchDocked=suspend\

Now everything seems to be working in 5.10.1 with DMCN34WW including suspend. I will put an update if I notice anything else.

@jrandiny
Copy link
Owner

Hm interesting, can you check the battery drop after a few hour?

@soupli
Copy link

soupli commented Dec 21, 2020

Hm interesting, can you check the battery drop after a few hour?

I too find that the battery level has drastically dropped when the machine is suspended / paused for a time period of 7-8 hours or so. Charged it 100%, closed the lid (machine is paused), opened it ~8h later and got 33% left.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants