Getting Linux to boot on Lenovo Thinkpad E485/E585

Lenovo finally fixed this after 1 year! Install the UEFI update and remove the entries.
 
Please complain in the Lenovo forums about this issue: https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/ThinkPad-E485...
 
It took me a long time to get any Linux Distribution to work. This was a lot of trial and error. My results are:
  • Trying to boot 32bit Linux resulted in immediate reboots. No output before that happened.
  • Most Linux 64bit distributions can be booted by adding noapic (not noacpi!)  intremap=off ivrs_ioapic[32]=00:14.0 ivrs_ioapic[33]=00:00.1 to the kernel boot parameters
  • Recent Ubuntu (and most likely also Debian) based distributions need also the boot parameter spec_store_bypass_disable=prctl spec_store_bypass_disable=seccomp. Maybe other distributions/kernel from 2018 will need this, too. Seems that with Ubuntu 18.04 kernel 4.15.0-33 this is no longer needed. So try this omiting this parameter, and check that all devices you need are initalized (-> dmesg), then try seccomp, which disables the mitigations for less code and if still devices are missing, try prctl. 
 
With these parameters everything I tested works, the only drawback is that the fan(s?) run at full speedan  CPU fan works perfectly, if cold enough it will stop.
Without the noapic the system will crash before giving any output in debug mode. Without the spec_store_bypass_disable there will be a null pointer derefence in the USB driver/subsystem, with the stacktrace looking like
  • null pointer dereference in _raw_spin_lock
  • speculative_store_bypass
  • ssb_prctrl_set
  • arch_seccomp_spec_mitigate
  • do_seccomp
  • SyS_seccomp
  • do_syscall_64
  • entry_SYSCALL_64_after_hwframe
Sometimes the crash was triggered in switch_to_xtra or xhci_pci_suspend.
 

Update

After more testing it narrowed down to amd_iommu=off and then to intremap=off 

The final error is "timer doesn't work through interrupt-remapped IO-APIC".

 

crash stack trace

 

2nd Update

When booting Ubuntu, there is now a stack trace during GPU initialization:

[    1.973028] fbcon: amdgpudrmfb (fb0) is primary device
[    1.992315] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 100 tries - tgn10_lock line:566
[    1.992384] WARNING: CPU: 7 PID: 199 at /build/linux-uT8zSN/linux-4.15.0/drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:190 generic_reg_wait+0xe8/0x120 [amdgpu]
[    1.992384] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc chash i2c_algo_bit aesni_intel ttm aes_x86_64 drm_kms_helper crypto_simd glue_helper syscopyarea cryptd psmouse sysfillrect sysimgblt ahci fb_sys_fops i2c_piix4 libahci drm sdhci_pci r8169 nvme sdhci mii nvme_core wmi video i2c_scmi
[    1.992409] CPU: 7 PID: 199 Comm: systemd-udevd Not tainted 4.15.0-23-generic #25-Ubuntu
[    1.992410] Hardware name: LENOVO 20KU000NGE/20KU000NGE, BIOS R0UET45W (1.25 ) 06/22/2018
[    1.992459] RIP: 0010:generic_reg_wait+0xe8/0x120 [amdgpu]
[    1.992460] RSP: 0018:ffffa857c29bf198 EFLAGS: 00010297
[    1.992462] RAX: 0000000000000001 RBX: 0000000000000065 RCX: 0000000000000001
[    1.992463] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000246
[    1.992463] RBP: ffffa857c29bf1d8 R08: 0000000000000000 R09: 000000000000005e
[    1.992464] R10: 0000000000000002 R11: 0000000000000396 R12: 0000000000000001
[    1.992465] R13: ffff9aadbc798280 R14: 0000000000000100 R15: 0000000000000001
[    1.992466] FS:  00007f85d38bc680(0000) GS:ffff9aadbebc0000(0000) knlGS:0000000000000000
[    1.992467] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.992468] CR2: 00005644b2ea6cf8 CR3: 0000000430046000 CR4: 00000000003406e0
[    1.992469] Call Trace:
[    1.992524]  tgn10_lock+0xa2/0xb0 [amdgpu]
[    1.992574]  program_all_pipe_in_tree+0x804/0x8b0 [amdgpu]
[    1.992621]  ? amdgpu_cgs_write_register+0x14/0x20 [amdgpu]
[    1.992668]  ? generic_reg_update_ex+0xe6/0x150 [amdgpu]
[    1.992714]  ? amdgpu_cgs_read_register+0x14/0x20 [amdgpu]
[    1.992763]  dcn10_apply_ctx_for_surface+0x498/0x4f0 [amdgpu]
[    1.992811]  dc_commit_state+0x2aa/0x500 [amdgpu]
[    1.992862]  amdgpu_dm_atomic_commit_tail+0x2cd/0xa50 [amdgpu]
[    1.992899]  ? amdgpu_bo_pin_restricted+0x1b5/0x2a0 [amdgpu]
[    1.992948]  ? dm_plane_helper_prepare_fb+0x181/0x240 [amdgpu]
[    1.992957]  commit_tail+0x42/0x70 [drm_kms_helper]
[    1.992963]  drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper]
[    1.993010]  amdgpu_dm_atomic_commit+0x87/0xa0 [amdgpu]
[    1.993026]  drm_atomic_commit+0x51/0x60 [drm]
[    1.993031]  restore_fbdev_mode_atomic+0x178/0x1e0 [drm_kms_helper]
[    1.993037]  restore_fbdev_mode+0x32/0x140 [drm_kms_helper]
[    1.993043]  ? _cond_resched+0x19/0x40
[    1.993048]  drm_fb_helper_restore_fbdev_mode_unlocked.part.32+0x28/0x80 [drm_kms_helper]
[    1.993053]  drm_fb_helper_set_par+0x43/0x70 [drm_kms_helper]
[    1.993058]  fbcon_init+0x493/0x670
[    1.993062]  visual_init+0xdc/0x140
[    1.993065]  do_bind_con_driver+0x207/0x420
[    1.993067]  do_take_over_console+0x82/0x1a0
[    1.993070]  do_fbcon_takeover+0x5c/0xb0
[    1.993072]  fbcon_event_notify+0x58d/0x780
[    1.993077]  notifier_call_chain+0x4c/0x70
[    1.993078]  blocking_notifier_call_chain+0x43/0x60
[    1.993081]  fb_notifier_call_chain+0x1b/0x20
[    1.993082]  register_framebuffer+0x24d/0x360
[    1.993088]  __drm_fb_helper_initial_config_and_unlock+0x1fc/0x400 [drm_kms_helper]
[    1.993093]  drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper]
[    1.993130]  amdgpu_fbdev_init+0xcd/0x100 [amdgpu]
[    1.993166]  amdgpu_device_init+0xe6c/0x1620 [amdgpu]
[    1.993202]  amdgpu_driver_load_kms+0x8b/0x2e0 [amdgpu]
[    1.993210]  drm_dev_register+0x149/0x1d0 [drm]
[    1.993245]  amdgpu_pci_probe+0x113/0x150 [amdgpu]
[    1.993250]  local_pci_probe+0x47/0xa0
[    1.993253]  pci_device_probe+0x145/0x1b0
[    1.993257]  driver_probe_device+0x31e/0x490
[    1.993258]  __driver_attach+0xa7/0xf0
[    1.993260]  ? driver_probe_device+0x490/0x490
[    1.993262]  bus_for_each_dev+0x70/0xc0
[    1.993264]  driver_attach+0x1e/0x20
[    1.993265]  bus_add_driver+0x1c7/0x270
[    1.993266]  ? 0xffffffffc0671000
[    1.993268]  driver_register+0x60/0xe0
[    1.993269]  ? 0xffffffffc0671000
[    1.993270]  __pci_register_driver+0x5a/0x60
[    1.993310]  amdgpu_init+0x96/0xa9 [amdgpu]
[    1.993314]  do_one_initcall+0x52/0x19f
[    1.993318]  ? __vunmap+0x81/0xb0
[    1.993320]  ? _cond_resched+0x19/0x40
[    1.993323]  ? kmem_cache_alloc_trace+0xa6/0x1b0
[    1.993326]  ? do_init_module+0x27/0x209
[    1.993328]  do_init_module+0x5f/0x209
[    1.993330]  load_module+0x191e/0x1f10
[    1.993334]  ? ima_post_read_file+0x96/0xa0
[    1.993336]  SYSC_finit_module+0xfc/0x120
[    1.993337]  ? SYSC_finit_module+0xfc/0x120
[    1.993340]  SyS_finit_module+0xe/0x10
[    1.993341]  do_syscall_64+0x73/0x130
[    1.993344]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[    1.993345] RIP: 0033:0x7f85d33c6839
[    1.993346] RSP: 002b:00007fff88d70fc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[    1.993347] RAX: ffffffffffffffda RBX: 00005644b2e8bfc0 RCX: 00007f85d33c6839
[    1.993348] RDX: 0000000000000000 RSI: 00007f85d30a50e5 RDI: 0000000000000014
[    1.993348] RBP: 00007f85d30a50e5 R08: 0000000000000000 R09: 00007fff88d710e0
[    1.993349] R10: 0000000000000014 R11: 0000000000000246 R12: 0000000000000000
[    1.993350] R13: 00005644b2e8aef0 R14: 0000000000020000 R15: 00005644b2e8bfc0
[    1.993351] Code: 31 f6 44 8b 45 10 44 89 e1 48 c7 c7 a1 87 60 c0 89 45 d4 52 48 c7 c2 e8 0d 60 c0 e8 83 ad c9 ff 41 83 7d 20 01 58 8b 45 d4 74 02 <0f> 0b 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 c7 45 c4 23 
[    1.993375] ---[ end trace 7e3e1ff95baa3ffb ]---

That's funny, a colleague had the same issue with systemd-udevd today on ouf our servers. With a completely different driver .

3rd Update (2018-07-29)

Ok, this is really a firmware bug, the ACPI IVRS table lacks at least one entry. Adding ivrs_ioapic[32]=00:14.0 instead of intremap=off is sufficient to make the system boot until Lenovo releases an UEFI update with a working IVRS table. At least UEFI 1.27 (2018-07-24) needs this override. And spec_store_bypass_disable=prctl is still needed for Ubuntu & co. 

The clue is the line "[Firmware Bug]: AMD-Vi: IOAPIC[32] not in IVRS table". I decompiled the ACPI tables, started to read the AMD documentation, but in the end I just guessed the 32 from the error message and 00:14.0 from the lspci output and the Stack Overflow/Ubuntu forum entries.  Interesting stuff, but too much to read in my little time. 

What was helpful is the Linux boot parameter amd_iommu_dump=1 which will dump information from the IVRS table:

[    0.851042] AMD-Vi: Using IVHD type 0x11
[    0.851401] AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: b0 info 0000
[    0.851401] AMD-Vi:        mmio-addr: 00000000feb80000
[    0.851430] AMD-Vi:   DEV_SELECT_RANGE_START  devid: 00:01.0 flags: 00
[    0.851431] AMD-Vi:   DEV_RANGE_END           devid: ff:1f.6
[    0.851870] AMD-Vi:   DEV_ALIAS_RANGE                 devid: ff:00.0 flags: 00 devid_to: 00:14.4
[    0.851871] AMD-Vi:   DEV_RANGE_END           devid: ff:1f.7
[    0.851875] AMD-Vi:   DEV_SPECIAL(HPET[0])           devid: 00:14.0
[    0.851876] AMD-Vi:   DEV_SPECIAL(IOAPIC[33])                devid: 00:14.0
[    0.851877] AMD-Vi:   DEV_SPECIAL(IOAPIC[34])                devid: 00:00.1
[    1.171028] AMD-Vi: IOMMU performance counters supported
 

Resolving devid 00:14.0 was easy via lspci:

 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)

but for 00:00.1 I have not found the device. If anybody knows how to list all device ids and their associate devices/drivers/etc, please mail me. 
 

4th Update (2018-09-01)

At least with Ubuntu kernel 4.15.0-33 spec_store_bypass_disable is no longer needed. At least for my e485. My assumption is that this was a kernel bug in the earlier kernels  with Spectre/Meltdown fixes.. Anyway, if you cannot boot or not all devices initialize, try the option seccomp and if that does not help try prctl. The option seccomp disables less spectre mitigations than prctl: 

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/Mi...

5th Update (2018-09-07) 

Just installed BIOS/UEFI 1.32 which fixes the keyboard issue. But Linux still needs the IVRS Table overrride. 

I am currently testing the Dell Latitude 5495, which boots Linux out of the box, but has also a few warnings/errors in the kernel log. I checked their IVRS Table: 

[    0.000000] AMD-Vi: Using IVHD type 0x11
[    0.000000] AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: b0 info 0000
[    0.000000] AMD-Vi:        mmio-addr: 00000000fd900000
[    0.000000] AMD-Vi:   DEV_SELECT_RANGE_START devid: 00:01.0 flags: 00
[    0.000000] AMD-Vi:   DEV_RANGE_END devid: ff:1f.6
[    0.000000] AMD-Vi:   DEV_ALIAS_RANGE devid: ff:00.0 flags: 00 devid_to: 00:14.4
[    0.000000] AMD-Vi:   DEV_RANGE_END devid: ff:1f.7
[    0.000000] AMD-Vi:   DEV_SPECIAL(HPET[0]) devid: 00:14.0
[    0.000000] AMD-Vi:   DEV_SPECIAL(IOAPIC[32]) devid: 00:14.0
[    0.000000] AMD-Vi:   DEV_SPECIAL(IOAPIC[33]) devid: 00:00.1
[    0.000000] [Firmware Bug]: AMD-Vi: IOAPIC[4] not in IVRS table
[    0.000000] [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found
[    0.000000] AMD-Vi: Disabling interrupt remapping
 

Compare the indexes with the Lenovo IVRS table. My uneducated guess is that these entries should be the same for all mainboards with (Mobile?) Ryzen processors as I assume (guess!! correct me if wrong) that these are CPU internal devices. Maybe the Lenovo IVRS entries are just off by one.

6th Update (2018-09-10)

Pilatomic in the comments pointed out that adding ivrs_ioapic[33]=00:00.1 solves a couple of issues, in his case issues with the SD Card reader. For me this works flawless for all my microSDHC cards, the only write errors I got were caused by ejecting the cards without unmounting them ;-)  Unfortunately I have found no way to remove entry 34 via kernel parameters, the parser will only accept well-formed parameters.So you will have wait for Lenovo to fix this ACPI table. I think by now they should know how to fix this and it's not a big change. But perhaps they do not care for Linux. 

Second Last Update (2018-09-10)

The story ends here for me. I just discarded all data on the SSDs, reimaged the NVMe with the factory image, cleaned up screen, keyboard, touchpad and case. And hopefully I will find a buyer for this fine notebook 

Why not the last update? I hope somebody will notify me when Lenovo releases a new UEFI version which fixes the IVRS ACPI table and Linux distributions will work out of the box. Then there will be a last update....

Another Update (2019-01-11)

According to this comment the IVRS overrides may not be needed anymore. And there are additional settings which should be set.

 

 

 

Comments

Did you manage to get it to boot install and everything in the end?

Yes, running Xubuntu 18.04 from 2nd SSD.

Thanks a lot. I got Devuan (Debian whitout Systemd) installed and working with your help :) Where did you learn about these parameters. I wish to learn more about that :D

After updating kernel and getting firmwares from github (the devuan/debian package is old) I got the graphic card working.
I got also a way to set the battery to charge when have less 40% battery until it have more than 80% using tpacpi-bat ( https://wiki.archlinux.org/index.php/Tp_smapi#2nd_option.2C_tpacpi-bat ) and the module that it needs "acpi_call" which is ready as a dkms deb in Debian and Devuan.

I only have three problems more to solve:
1- I can see wireless networks in Network-Manager, I can click at Connect, it ask me the password, I write it, and... nothing, it does nothing. I tried adding the ath10 firmwares from github but problem is not solved. Just in case I deactivated Kwallet-manager.
2- KDE doesn't ask me a password if I modify things in SystemSettings which need root privileges, so I had to run kdesudo systemsettings5 to run it as root and do that things.
3- Bright- and Bright+ keys and others don't work. I installed an aplication for that for thinkpads, and I have to test it yet. Or maybe thanks to acpi_call module I can associate appropiate commands to get that to that hotkeys.

Thanks again.

Hello Javier,
I am glad to hear that you got Devuan running, and good to hear that notebooks can still run without systemd ;-)

The issues you described are the reasons why I prefer Ubuntu flavours over Debian/Devuan. Ubuntu is not as "pure" as the Debans, and is more open to include firmware and other stuff that comes quite handy in getting the latest hardware to work, so 1+3) both work for me out of the box. 2) sounds more like a KDE bug not related to the hardware.

Making Linux boot was a lot of trial and error. First I tested multiple Live CDs, than I found out that the failsafe mode of clonezilla was able to boot the system. It ran quite bad with only one core and so on, but at least it worked. Then it tested removing various of the extra parameters of the failsafe mode to pinpoint which settings may cause the crashes. Very basic information for all these parameters, you can find at https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt. Of course you need an idea what the parameters change. Replacing parameters like splash or quiet with nosplash & debug. The rest is googling, reading documentation, wikipedia and kernel code (or at least the named backtrace parts ;-)) , With this simple debugging I came to nolapi and spec_store_bypass_disable=prtctl on Ubuntu.

The big problem is that with this setting you will get kernel output very late, when CPUs, memory and other basic stuff is already initiliazed. To start earlier you will need earlyprintk=device[,keep]. The best logging is probably done thru a serial connection, but modern notebooks have none. So earlyprintk=efi,keep or similar must be used and output goes to screen. The ,keep continues logging on the early console after the switch to normal logging happened, most likely duplicating all output. The issue ist, the output is dead slow.. think of the thousand boot log messages coming in at 1 line per second. Arch Linux used a smaller resolution and was much faster, but the of course less information fitted on the screen. And so it narrowed down or amd_iommu=off and then finally to intremap=off. My current guess is that something in the ACPI tables is wrong or so, but I haven't looked further as I cannot fix anything there, I guess...

The big problem is/was that there are at least two issues, the IOMMU interrupt remapping and these spectre (I guess) fixes which crash some drivers..

My notes while testing (and playing Battletech on my PC) can be found here: https://evilazrael.net/tmp/e485_linux_debug.txt

Yes 2 (and 1 maybe) seems some KDE or permissions bug. I solved wireless problem installing Wicd (a daemon+gui similar to Network-Manager). I known it since Network-Manager gave me problems in the past in my old laptop (it tries to monopolize network configuration and you cannot touch some values by hand XD).

Wow, great investigation ;) Thanks for your effort :D

So I only need to solve now the special keys problem.

Could you please post the result of this command so I can see which firmware packages (and their version) have you installed in your Ubuntu?: dpkg -l *firmware* | grep ^ii
And wich kernel version do you use ad the result of this command to see acpi modules used: lsmod | grep acpi
If you prefer not to post it here, you already have my email, since I wrote it in my two messages here.

By the way my EFI version is 1.24, there two upgrades with this changes:
Version 1.25 ( 2018/06/26 )
[Important] Optimize UCSI PPM_RESET command to EC.

Version 1.27 (2018/07/24)
[Important] [Important] Modify SPL/SPPT/FPPT to 8W when battery RSOC to 20%.
[Important] Added notify battery change event when battery RSOC<10%

Bootable ISO downloadable here: https://pcsupport.lenovo.com/es/de/products/laptops-and-netbooks/thinkpa...

Yeah, NetworkManager is sometimes more PITA than useful. For another computer I use I still need a working solution how to tell NetworkManager to use the DNS Server DHCP gives. For some reason NetworkManager/Xubuntu insist on starting an own DNS server (mDNS?) and sending queries there. Which is quite bad as public DNS Servers of course do not know my internal addresses...

inux-firmware 1.173.1

thinkpad_acpi 94208 1
nvram 16384 1 thinkpad_acpi
snd 81920 20 snd_hda_intel,snd_hwdep,snd_hda_codec_conexant,snd_seq,snd_hda_codec,snd_timer,thinkpad_acpi,snd_rawmidi,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_seq_device,snd_pcm
ucsi_acpi 16384 0
typec_ucsi 28672 1 ucsi_acpi
video 45056 1 thinkpad_acpi

Thanks for the heads up with the bios update. I immediately installed 1.25 as it was already available when I received the notebook.

Have you an idea what SPL/SPPT/FPPT mean in this context? May save me googling ;-)

Thanks.

Try Wicd, it only depends in some GTK libraries, not Gnome ones (the wicd-gtk gui, there is also a ncurses one and one for use with commands for scripts).

The firmwares included in Ubuntu are the last available on github at 2018 february the 22nd. I downloaded from github a tar.gz with the last ones two days ago so are newer but I only copied the wireless card ones to my /lib/firmware. I am going to copy and overwrite all of them just in case (making before a security copy of what I have now).

About modules:
I have also loaded acpi_call for battery 40%-80% charging as I said.
I have also acpi_cpufreq loaded.
And "rfkill" and "battery" modules are here also used by thinkpad_acpi module.

Do you have any configuration related to acpi inside /etc/modules file or /etc/modprobe.d/ folder?
If not, after firwares copying i will try unloading extra modules I have, and if not success, I wil dowload a Kubuntu live, and if not Xubuntu 18.04 live (sames as you)

I formated the disk without loading Windows 10 not even once XD. I will try selling the licence. No, I don't know what that means. Google will tell us XD.

Linux was also the first OS i tried to boot, because I like to take a full disk image, so I can reset it any time to the state when it was new. It's pretty annoying if this does not work. I can accept that due to the latest hardware Linux can't be used as the desktop OS (graphics card troubles or), but I need Linux as a rescue, test & debug system. So at least console mode should work without any serious issues like non-working USB or network. It's a bad feeling for me to know that a safety net does not work.

When I find time I will test Wicd, if it needs only GTK, then it should work with Xubuntu.

/etc/modules is empty. The only file I changed is /etc/default/grub for adding the kernel parameters. You can find my /etc/modprobe.d/ folder at https://evilazrael.net/tmp/modprobe.tar.gz . Maybe there is something useful in there.

I don't get more logs with "earlyprintk=efi,keep" in /var/log/messages, only very slow ones in screen :S

That's the purpose of earlyprintk. With this parameter kernel messages will be shown as soon as possible, it does not generate more message. efi means that the messages should go to the screen. Serial is usually more often used, and you can log the messages on the receiving console. netconsole is a network capable alternative, but this of course requires the NIC to be configured. If the earlyprintk target the same where the normal kernel output is sent too, the ",keep" causes messages to shown twice. See earlyprintk in the kernel parameters file.

Thank you for your work.
I probably never would have managed to find all that out by myself, but with your help I managed to boot and install archlinux just fine. For me the kernel parameter intremap=off  was enough to get it to boot.

Yes it boots but without "spec_store_bypass_disable=prctl" as EAzrael said it shows an error.

In my machine acpi_thinkpad module uses battery module because the kernel 4.17(available in Devuan testing ) supports new things in last thinkpads: https://www.reddit.com/r/thinkpad/comments/7yeytz/battery_wear_control_t...

Here https://patchwork.kernel.org/patch/10396271/ I have seen the route of battery things in /sys There is not force_discharge as says there, but there is the routes which content I can see:
cat /sys/class/power_supply/BAT0/charge_start_threshold
cat /sys/class/power_supply/BAT0/charge_stop_threshold

I see they are in 40 and 80 as I have set with acpi_call module and the perl script. System remebers it, great!.

Following suggestion on a comment for the reddit link I have writen
echo 45 > /sys/class/power_supply/BAT0/charge_start_threshold
echo 75 > /sys/class/power_supply/BAT0/charge_stop_threshold

Hopefully soon there will be more options and there will be a GUI that supports that.

Ping
If you want to test something new, replace intremap=off with ivrs_ioapic[32]=00:14.0 . This should do the trick. Everything seems to work fine.

Seems to work fine here too.

Hey, thanks a lot for the work. with ivrs_ioapic[32]=00:14.0 everything works fine for me. I also installed the latest UEFI 1.27 update, but it didn't fix the problem. We might need to wait for another update from lenovo.

The ivrs_ioapic[32]=00:14.0 fixed the boot for me on E585, however the keyboard lags heavily (typed keys show up out of order and there is a visible lag). Does anyone else have this problem?

I do have the keyboard issue as well. I installed Arch probably an hour after receiving my E485 but I was under the impression that the issue was there with Windows. I could be wrong though.

I just got an E585 and I see the same keyboard issue on the pre-installed Windows as well as on Linux. Letters come out of the order when typing at full speed. It seems that other people are having the same issue - check out this post on Reddit:
https://www.reddit.com/r/Amd/comments/99zyl4/just_got_my_lenovo_thinkpad...

"Another thing to note while I am typing this is that I am making quite abit of typing errors, not sure if its the keyboard or just me not being used to it. But it feels as if some keys register faster than the other, maybe its just me but most of the error mistakes got auto corrected by the laptop anyways."

Considering that there are multiple reports of this, it has to be either hardware or firmware (BIOS) issue? If this is an inherent problem with this model, I am considering sending it back and buying a different brand.

Funny, now I realize that I have the same issue with Windows on my e485. I thought I was too stupid to type on the keyboard. It happens so often that two consequent key presses are swapped and I thought that it was due to "timing errors" when typing keys from both hands. 

I did some more testing on this. Windows and Linux are both affected. External Keyboard does  not have this issue. On a German Keyboard the easiest to reproduce combination is e+r like in "center". Put two fingers above these keys the "r" finger slightly higher and then type, do this a couple of times. Some combinations with space and backspace are also affected. And right shift seems to trigger this too (I use right shift more often than left shift, never learned 10 finger typing). 

First sentence is right, the other lines are the one where I am sure I did not type anything wrong, It took me many more tries as somehow it's hard to type correctly when you focus on the actual typing to make no errors.

Dies ist ein langer Text der ziemlich fehlerfrei sein sollte. 

dies ist ein langer Text dre ziemlich fehlrefrei sei nsollte.
Dies is tie nlangre Text dre ziemlich fehlerfrei sei nsollte.
dies is tein langer Text der ziemlich fehlerfrei sei nsolte.
dies is tei ntext dre ziemlich fehlerfrei sei nsollte.
Dies is tie nlanger Text dre ziemlich fehlerfrei sei nsollte.

(yes, forgot "langer" in the second last line)

It looks like there is another person on Redit with the same issue:
https://www.reddit.com/r/Amd/comments/9ajmr1/lenovo_thinkpad_e585_3dmark...

"As for user experience based stuff i do have an issue with the keyboard, not the best keys. Made alot of typos with it and it feels "slow" coming from a mechanical keyboard desktop user"

At this point I'm seriously considering sending it back and looking for another brand laptop w/ Ryzen. :-/

It looks like there are reports of keyboard issues on Lenovo's official forum:
https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/E485-strangel...

Another Reddit post w/ people describing same keyboard issue:
https://www.reddit.com/r/thinkpad/comments/95k1at/e485_arrived_today_ryz...

There's a beta Bios v1.28 that fix the keyboard issue.

Care to share a link? Google isn't helping.

Yeah, I just noticed that. I have replied to that thread as well.

Bios v1.32 has been release. Problem fixed for me.

I managed to install Debian Stretch 9.5 netinst on my E485 thanks to you and the ivrs_ioapic[32]=00:14.0.
I tried many things before this with the latest BIOS update. Only your solution works on my side.
Thank you very much.

Thanks a ton for your blog post. I got my E585 up and running. I still run into some issues however.

The newest kernel I can boot is 4.15.0-30 for some reason. I was using 4.18 RC7 just fine for a while.. rc7 stopped working, 4.18.5 doesn't work, 4.19 rc1 doesn't work. Nothing really changed, it just quit working (Ubuntu Budgie)

4.18.5: https://i.imgur.com/yk1bXWW.png

Also can't seem to get the bluetooth working to save my life. I got it working one time, and quit working again after reboot. Not too concerned since I can upgrade the wifi+bt card if needed

I did a writeup with photos of internals of the e585 if anyone is interested. https://forum.level1techs.com/t/lenovo-thinkpad-e585-ryzen-2500u-vega-8-...

Hi,
can you revert back to the old kernel and boot the system? If yes, if you have syslogs from the failed boots (/var/log/kern.log* syslog* boot.log, etc) please send the logs to me. E-Mail address can be found here: https://www.evilazrael.de/content/impressum

Just ordered a Dell Latitude 5495 with Ryzen 7 2700U Pro. One of these two will end up on ebay in the near future.

I have a similar issue. After a fresh reboot, Bluetooth never work. I have to close the lid (Laptop goes into hibernate mode) and then Bluetooth is available once I return from hibernate.

Hey,

thanks for your work, arch linux just boots and it's wonderful.

however, I think I got a little problem with the graphics card:
powertop keeps telling me to have a discharge rate of around 10W (and thats too much i think).
also the radeon graphics card reports 100% usage all the time, acpi tells me around 4h total time remaining when at 100% charged.

-> this laptop should last way longer according to the lenovo webpage, especially when running arch and not windows.

did any of you guys fixed that the graphics card is not always used to 100%?
I blacklisted radeon and added amdgpu.dc=1 as kernel parameters

thank you in advance :)

ok, after some research I found out that my notebook won't use any cstates >= 3.
can someone report his powertop output?
or his turbostat output?
mine shows just C1 and C2 state

without using these the powersaving performance will be pretty bad :/

Not necessarily. Maybe AMD is at good at C-State 2 as Intel with C-State 6 or whatever.
I think this boils down to the ACPI tables again. I am new to this, but if I read the references correctly, Only C-State 1 and 2 are defined in the ACPI tables on the notebook. I check my 2 other AMD system which are running currently and none of them goes lower than C2. Okay, the other two are desktops ;-)
So I would need confirmation that Raven Ridge CPUs have states C3 and lower. Either somebody confirms this or I have to dig deeper into technical references.
Btw. check the last line of the man page for powertop. I would not put too much trust into this tool ;-)

Need to sleep now. And the keyboard really sucks until I get this UEFI beta update.

Found this at https://support.amd.com/TechDocs/55072_AMD_Family_15h_Models_70h-7Fh_BKD...

2.5.2.2.1 C-state Names and Numbers C-states are often referred to by an alphanumeric naming convention, C1, C2, C3, etc. The mapping between ACPI defined C-states and AMD specified C-states is not direct. AMD specified C-states are referred to as IObased C-states. Up to three IO-based C-states are supported, IO-based C-state 0, 1, and 2. The IO-based C-state index corresponds to the offset added to MSRC001_0073[CstateAddr] to initiate a C-state request. See 2.5.2.2.2 [C-state Request Interface]. The actions taken by the processor when entering a low-power C-state are configured by software. See 2.5.2.2.3 [C-state Actions] for information about AMD specific actions.

This is not for the raven ridge family. Need to find the same document for CPU family 17h.

My discharge rate bounces around just sitting at the desktop, from 18W down to 7W though most of the time sits around 14W, so just over 3 hours. That said looking at windows feedback/reviews the battery life is NO WHERE near what they claim on the lenovo site, the windows review I read earlier agreed this is about what you expect from this laptop?

4 hours - https://www.reddit.com/r/Amd/comments/9ibe0m/lenovo_thinkpad_e585_ryzen_...

I did see another windows review saying between 3 and 4 hours but kind find it again at the moment.

I did see another windows review saying between 3 and 4 hours but kind find it again at the moment.

God, I can't thank you enough! It drove me crazy to only be able to use windows! Thanks a bunch!

Hi,
Owner of a E585 here
First, thank you very much for this page !
Saved me a lot of time !

still having an issue : i can't get the SD-card reader to work !
Anybody experiencing the same thing ?

Hi,

please show me the last lines of the output of dmesg after you inserted the SD card. I got these lines:
[ 358.527941] AMD-Vi: Event logged
[ 358.527946] INVALID_DEVICE_REQUEST device=00:00.1 address=0xfffffffdf8080200 flags=0x0a00]

Looks like I have to tinker with the IVRS table again.

I got this exact same message
Good, so I know for sure that it's not simply a defective reader (haven't booted Windows on it, so I wasn't sure)
Looks like fun times ahead playing with this, I've always avoided messing with ACPI, but looks like i'm not going to cut it this time !
i'll keep you updated if I find a fix

Using your guess that IVRS entries might be off by one, I manager to get a bit further :
adding "ivrs_ioapic[33]=00:00.1" got the reader got the reader to detect my card, but i'm still not able to access it :

[ 297.840099] mmc0: new ultra high speed SDR104 SDHC card at address 0001
[ 297.840418] mmcblk0: mmc0:0001 SD16G 14.6 GiB
[ 307.932066] mmc0: Timeout waiting for hardware interrupt.
[ 307.932075] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 307.932082] mmc0: sdhci: Sys addr: 0x00000008 | Version: 0x00000603
[ 307.932088] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
[ 307.932094] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x0000003b
[ 307.932100] mmc0: sdhci: Present: 0x01ff0000 | Host ctl: 0x00000017
[ 307.932106] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000000
[ 307.932111] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 307.932117] mmc0: sdhci: Timeout: 0x0000000a | Int stat: 0x00000000
[ 307.932122] mmc0: sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[ 307.932128] mmc0: sdhci: AC12 err: 0x00000004 | Slot int: 0x00000000
[ 307.932134] mmc0: sdhci: Caps: 0x25f8c8bf | Caps_1: 0x00002077
[ 307.932139] mmc0: sdhci: Cmd: 0x0000123a | Max curr: 0x005800c8
[ 307.932145] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[ 307.932150] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000800
[ 307.932154] mmc0: sdhci: Host ctl2: 0x0000800b
[ 307.932159] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfffff208
[ 307.932161] mmc0: sdhci: ============================================
[ 318.176035] mmc0: Timeout waiting for hardware interrupt.
[ 318.176042] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 318.176049] mmc0: sdhci: Sys addr: 0x00000008 | Version: 0x00000603
[ 318.176055] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
[ 318.176060] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x0000003b
[ 318.176066] mmc0: sdhci: Present: 0x01ff0000 | Host ctl: 0x00000017
[ 318.176071] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000000
[ 318.176076] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 318.176081] mmc0: sdhci: Timeout: 0x0000000a | Int stat: 0x00000000
[ 318.176087] mmc0: sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[ 318.176092] mmc0: sdhci: AC12 err: 0x00000004 | Slot int: 0x00000000
[ 318.176097] mmc0: sdhci: Caps: 0x25f8c8bf | Caps_1: 0x00002077
[ 318.176102] mmc0: sdhci: Cmd: 0x0000123a | Max curr: 0x005800c8
[ 318.176108] mmc0: sdhci: Resp[0]: 0x00400900 | Resp[1]: 0x00000000
[ 318.176113] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000100
[ 318.176116] mmc0: sdhci: Host ctl2: 0x0000800b
[ 318.176121] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfffff208
[ 318.176123] mmc0: sdhci: ============================================
[ 318.336083] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.396042] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.456053] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.456100] print_req_error: I/O error, dev mmcblk0, sector 0
[ 318.512057] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.512104] print_req_error: I/O error, dev mmcblk0, sector 1
[ 318.572035] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.572082] print_req_error: I/O error, dev mmcblk0, sector 2
[ 318.628086] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.688053] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 318.688104] print_req_error: I/O error, dev mmcblk0, sector 3
[ 318.690140] Buffer I/O error on dev mmcblk0, logical block 0, async page read

still inverstigating ....

Looks like it works with SDXC, but not SDHC card.
This SDHC card works fine on my rasbperry, so I know the card is good

Just simple add iommu=soft to the Kernel Opts, this is also the default value for Intel systems. Work fine on my Fedora 28 install with uefi and Amd-V enabled.

Any idea what the impact if iommu=soft is? The kernel documentation is not so helpful and I have no time to search through the code.

But maybe this is the solution for one of the last mysterious on our Intel servers. I constantly get the message that the SWIOTLB is full or so....

I tried this and fine fedora 28 installs, but suspend and resume don't work, basically once you suspend the screen will come back on but not the keyboard etc and so useless, have to force reboot.

As to eazrael's solution, this works to get mint 19 to boot, but I then let it auto partition etc and it fails to install with uefi errors trying to do grub install.

Seems to be a Mint 19 issue as Ubuntu Budgie 18.04.1 installs fine and doesn't have the suspend/resume issues that fedora had either.. so far so good..

Tempted to try MX Linux but meh, this is working...

Pages

Add new comment