Bug 1868899 - Touchpad not working on Lenovo Ideapad Slim 3
Summary: Touchpad not working on Lenovo Ideapad Slim 3
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-14 07:05 UTC by Matt
Modified: 2021-10-12 07:55 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
kernel logs (84.29 KB, text/plain)
2020-08-14 07:05 UTC, Matt
no flags Details
dmesg output (75.27 KB, text/plain)
2021-06-20 05:52 UTC, Matt
no flags Details
dmesg output (with pci cmdline arg) (75.41 KB, text/plain)
2021-06-27 07:11 UTC, Matt
no flags Details
dmesg output (without pci cmdline arg) (77.03 KB, text/plain)
2021-06-27 07:13 UTC, Matt
no flags Details
dmesg output for 5.12.13-300 (85.55 KB, text/plain)
2021-07-01 12:41 UTC, Matt
no flags Details
dmesg output for 5.12.13-300 (94.68 KB, text/plain)
2021-07-01 13:15 UTC, Matt
no flags Details
dmesg output with no_e820 pci cmdline arg (74.50 KB, text/plain)
2021-10-05 08:05 UTC, Matt
no flags Details

Description Matt 2020-08-14 07:05:32 UTC
Created attachment 1711424 [details]
kernel logs

1. Please describe the problem:
Touchpad does not work at all. For reference, hardware is functional as touchpad works under Win10. USB and BT mice work. 

output of system info:
# dmidecode 
System Information
	Manufacturer: LENOVO
	Product Name: 81WE
	Version: IdeaPad 3 15IIL05
	Serial Number: PF25BWBN
	UUID: 58961da7-bdb8-2020-0425-103601000000
	Wake-up Type: Power Switch
	SKU Number: LENOVO_MT_81WE_BU_idea_FM_IdeaPad 3 15IIL05
	Family: IdeaPad 3 15IIL05



2. What is the Version-Release number of the kernel:
5.7.14-200.fc32.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
No previous Fedora releases tested - F32 only.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Boot laptop to desktop Wayland session. Touchpad non-functional at any time since F32 installation.


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
Not tested rawhide due to GPG key issue using the repo, however problem exists in latest updates-testing kernel 5.7.15-200.fc32.x86_64.


6. Are you running any modules that not shipped with directly Fedora's kernel?:
No


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
Attached.


I believe the following info may be relevant from dmesg? This happens every boot and is reported as an kerneloops in kernel-core package via ABRT:
[    9.820184] irq 9: nobody cared (try booting with the "irqpoll" option)
[    9.820186] CPU: 1 PID: 844 Comm: rngd Not tainted 5.7.14-200.fc32.x86_64 #1
[    9.820186] Hardware name: LENOVO 81WE/LNVNB161216, BIOS EMCN37WW 06/24/2020
[    9.820187] Call Trace:
[    9.820189]  <IRQ>
[    9.820194]  dump_stack+0x64/0x88
[    9.820197]  __report_bad_irq+0x35/0xa7
[    9.820198]  note_interrupt.cold+0xb/0x6a
[    9.820199]  handle_irq_event+0x88/0x8a
[    9.820201]  handle_fasteoi_irq+0x78/0x1c0
[    9.820203]  do_IRQ+0x50/0xe0
[    9.820205]  common_interrupt+0xf/0xf
[    9.820206]  </IRQ>
[    9.820207] RIP: 0033:0x7f01133a49df
[    9.820208] Code: 48 8b 45 e0 48 c1 e8 1b 83 e0 01 48 31 45 f0 48 8b 45 e0 48 c1 e8 16 83 e0 01 48 31 45 f0 48 d1 65 e0 48 8b 45 f0 48 31 45 e0 <83> 45 d4 01 83 7d d4 40 0f 86 72 ff ff ff 48 83 45 d8 01 48 8b 45
[    9.820209] RSP: 002b:00007f0111cb0bc0 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffde
[    9.820210] RAX: 0000000000000001 RBX: 000000000000000a RCX: 000000000000002e
[    9.820210] RDX: 099c400000000000 RSI: 0000000000000000 RDI: 0000000000000001
[    9.820211] RBP: 00007f0111cb0c10 R08: 0000000000000000 R09: 0000000000000035
[    9.820211] R10: 00007f0111cb0a77 R11: 0000000000000000 R12: 00007f00fc004c00
[    9.820211] R13: 00007fff3323cf5f R14: 00007f0111cb0d10 R15: 000055d8d442b4c0
[    9.820213] handlers:
[    9.820215] [<0000000094f280d8>] acpi_irq
[    9.820216] Disabling IRQ #9

Comment 1 Matt 2020-09-02 01:07:49 UTC
FYI, latest kernel 5.8.4-200.fc32 of the new 5.8 branch still contains this touchpad issue. 
Are there any temporary fixes or official patches forthcoming to support this hardware 
functionality available here or upstream?

Comment 2 Matt 2020-12-06 09:37:18 UTC
Updated Fedora version to the current 33rd edition as problem still exists.

Comment 3 Matt 2021-05-29 05:33:15 UTC
Updated to latest Fedora release 34.

Is there a timeline that could be conjected by anyone cc'd in this bug to 
illuminate when one on average sees hardware such as this touchpad reach 
supported status in Fedora once a new device is released to market?

Are there some proactive steps I could take to expedite the process toward 
driver support for this hardware in Fedora?

Comment 4 Hans de Goede 2021-05-30 11:12:46 UTC
(In reply to Matt from comment #3)
> Updated to latest Fedora release 34.
> 
> Is there a timeline that could be conjected by anyone cc'd in this bug to 
> illuminate when one on average sees hardware such as this touchpad reach 
> supported status in Fedora once a new device is released to market?
> 
> Are there some proactive steps I could take to expedite the process toward 
> driver support for this hardware in Fedora?

Sorry that it is taking so long to resolve this issue. I've been working on fixing touchpad issues on various Lenovo Ideapad laptops, but there are multiple issues at play. Twice now I thought I had fixed things and I did fix things for some Ideapad models, but others still do not work.

Let me copy and paste a large comment which I added to another bug. I'll put this in a separate comment here for clarity.

Comment 5 Hans de Goede 2021-05-30 11:13:16 UTC
So this is a bit of a mess which I'm trying to sort out ATM, there are at least 4 different issues with Ideapad touchpads that I'm aware of:

1. There was a Linux ACPI issue where the resource-list (_CRS) for the touchpad given to Linux was not correct, this has been fixed for a while now by these 2 commits from me:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21653a4181ff292480599dad996a2b759ccf050f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8058d69905058ec8f467a120b5ec5bb831ea67f3
These commits should be in recent Ubuntu kernels so if you are still seeing issues then this issue was not the root cause for your laptop model.

2. On some Ideapad models the elants_i2c driver takes control of handling the touchpad, but the touchpad does not talk the elants protocol at all, it uses the standard I2C-HID protocol so this does not work. If adding "initcall_blacklist=elants_i2c_driver_init" to your kernel commandline fixes things, then your Ideapad model is hit by this. This is fixed now by this commit from me:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65299e8bfb24774e6340e93ae49f6626598917c8
This commit was added to the 5.10.y and 5.12.y stable kernel series a couple of days ago, so hopefully it will get added to the Ubuntu kernels soon too.

3. On some Ideapads the BIOS seems to corrupt its own settings (often after a BIOS update) and as a result of this the BIOS is returning bogus addresses (NULL or 0xffffffff) as base-address from the ACPI _CRS call for some PCI devices, including the I2C controller connected to the touchpad. If adding "pci=nocrs" as a workaround helps then your model Ideapad is affected by this issue.

4. On some Ideapads something goes wrong with the OSYS code in the ACPI tables, this code is responsible for detecting which Windows version the ACPI tables think they are dealing with (or which Windows version Linux mimicks in case you are running Linux). To see if your Ideapad is affected by this issue try running:
"cat /sys/bus/acpi/devices/XXXX0000\:00/status"
from a terminal, if the output of this command is "15" then your model is affected by this issue. At least the "Lenovo Thinkbook 14-ILL" is known to be affected by this. The exact root cause of this is unknown atm. If your laptop is affected by this please run "acpidump -o acpidump" and attach the acpidump here, in combination with specifying the exact model of your laptop.

Comment 6 Hans de Goede 2021-05-30 11:20:29 UTC
Translating this to your situation / laptop:

1. Is fixed in Fedora 34, so you are not hit by 1.

2. Is fixed in kernel 5.12.6, 5.12.7 is in the Fedora 34 updates repo now, so if you run "sudo dnf update 'kernel*'" then you should get a kernel >= 5.12.6 installed. If you reboot after this and things work now, then 2. was the root cause and you can stop reading here :)

3. To test if you are hit by this run:
"sudo grubby --update-kernel=ALL --args=pci=nocrs"
and then reboot. If this works around the issue please let me know, I'm still investigating this variant of the problem.
If this does not work, run the following command to undo the change:
"sudo grubby --update-kernel=ALL --remove-args=pci=nocrs"

4. As the comment says (and if 1-3 do not help), try running:
"cat /sys/bus/acpi/devices/XXXX0000\:00/status"
from a terminal, if the output of this command is "15" then your model is affected by this issue

Comment 7 Matt 2021-06-13 07:26:39 UTC
(In reply to Hans de Goede from comment #6)
> Translating this to your situation / laptop:
> 
> <snip>
> 
> 3. To test if you are hit by this run:
> "sudo grubby --update-kernel=ALL --args=pci=nocrs"
> and then reboot. If this works around the issue please let me know, I'm
> still investigating this variant of the problem.
> If this does not work, run the following command to undo the change:
> "sudo grubby --update-kernel=ALL --remove-args=pci=nocrs"

Hi Hans, 

Apologies for the delay in responding. I can happily confirm this 
3rd workaround fixes the problem for my laptop touchpad functionality! :-)
I also tested gestures and the 2-fingered combo works however the new 3-finger 
Gnome 40 gesturing doesn't seem to work. (perhaps I'm just not doing it correctly) 
> 
> 4. As the comment says (and if 1-3 do not help), try running:
> "cat /sys/bus/acpi/devices/XXXX0000\:00/status"
> from a terminal, if the output of this command is "15" then your model is
> affected by this issue
Note, this device path doesn't exist on my system. Is this out of the oridinary?

-Matt

Comment 8 Hans de Goede 2021-06-15 10:13:39 UTC
(In reply to Matt from comment #7)
> Apologies for the delay in responding. I can happily confirm this 
> 3rd workaround fixes the problem for my laptop touchpad functionality! :-)

That is good news. I think I know what is going on here and I've written a kernel fix which should make things work without the workaround.

I've build a test-kernel with the fix which I wrote added:
https://koji.fedoraproject.org/koji/taskinfo?taskID=70106533

Here are some generic instructions for installing a kernel directly from koji (the Fedora buildsystem):
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Can you please undo the workaround by running:

sudo grubby --update-kernel=ALL --remove-args=pci=nocrs

And then give this new kernel a try. After booting the new kernel please run:

dmesg > dmesg-patched-kernel.txt

And attach the generated dmesg-patched-kernel.txt. Also please let me know if the touchpad still works with the patches kernel without the workaround.

> > 4. As the comment says (and if 1-3 do not help), try running:
> > "cat /sys/bus/acpi/devices/XXXX0000\:00/status"
> > from a terminal, if the output of this command is "15" then your model is
> > affected by this issue
> Note, this device path doesn't exist on my system. Is this out of the
> oridinary?

The path NOT existing is normal. If the path exists then that actually is indicative of another bug which is also causing touchpads to not work on some models.

Comment 9 Matt 2021-06-20 05:52:33 UTC
Created attachment 1792465 [details]
dmesg output

Comment 10 Matt 2021-06-20 05:56:54 UTC
(In reply to Hans de Goede from comment #8)
> (In reply to Matt from comment #7)
> > Apologies for the delay in responding. I can happily confirm this 
> > 3rd workaround fixes the problem for my laptop touchpad functionality! :-)
> 
> That is good news. I think I know what is going on here and I've written a
> kernel fix which should make things work without the workaround.
> 
> I've build a test-kernel with the fix which I wrote added:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=70106533
> 
> Here are some generic instructions for installing a kernel directly from
> koji (the Fedora buildsystem):
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
> 
> Can you please undo the workaround by running:
> 
> sudo grubby --update-kernel=ALL --remove-args=pci=nocrs
> 
> And then give this new kernel a try. After booting the new kernel please run:
> 
> dmesg > dmesg-patched-kernel.txt
> 
> And attach the generated dmesg-patched-kernel.txt. Also please let me know
> if the touchpad still works with the patches kernel without the workaround.

Hi Hans,

Unfortunately this patched kernel does not fix the bug for my touchpad. The 
dmesg output is attached.

Regards, Matt

Comment 11 Hans de Goede 2021-06-21 11:36:48 UTC
Thank you, I've been discussing this problem upstream and my initial patch was no good, sorry about that.

We think we have some idea what is going on, but we need some more info. So I've prepared another test kernel with a patch which prints some extra debugging included:
https://koji.fedoraproject.org/koji/taskinfo?taskID=70539682

ATM this is still building, this takes a couple of hours.

Can you please install this kernel once it is done building and collect dmesg output both with and without "pci=nocrs" on the kernel commandline; and then attach both dmesg files here ?   Note this is not expected to work without "pci=nocrs", the goal is purely to gather some information.

Comment 12 Matt 2021-06-27 07:11:16 UTC
Created attachment 1794948 [details]
dmesg output (with pci cmdline arg)

Comment 13 Matt 2021-06-27 07:13:31 UTC
Created attachment 1794960 [details]
dmesg output (without pci cmdline arg)

Comment 14 Matt 2021-06-27 07:18:41 UTC
(In reply to Hans de Goede from comment #11)
> Thank you, I've been discussing this problem upstream and my initial patch
> was no good, sorry about that.
> 
> We think we have some idea what is going on, but we need some more info. So
> I've prepared another test kernel with a patch which prints some extra
> debugging included:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=70539682
> 
> ATM this is still building, this takes a couple of hours.
> 
> Can you please install this kernel once it is done building and collect
> dmesg output both with and without "pci=nocrs" on the kernel commandline;
> and then attach both dmesg files here ?   Note this is not expected to work
> without "pci=nocrs", the goal is purely to gather some information.

Hi Hans, I've attached the two dmesg files as requested. HTH the debugging and patching
process.

-Matt

Comment 15 Hans de Goede 2021-06-30 13:43:12 UTC
Thank you for the logs, here is another test-kernel with more debugging added:
https://koji.fedoraproject.org/koji/taskinfo?taskID=71078980

ATM this is still building, this takes a couple of hours.

Can you please install this kernel once it is done building and collect dmesg output with "log_buf_len=50M pci=nocrs" on the kernel commandline ?

Comment 16 Matt 2021-07-01 12:41:32 UTC
Created attachment 1796782 [details]
dmesg output for 5.12.13-300

Hi Hans, dmesg attached. HTH.

-Matt.

Comment 17 Hans de Goede 2021-07-01 12:55:31 UTC
Matt, thank you.

I'm afraid I made a mistake I actually need the dmesg output without the "pci=nocrs", so with just "log_buf_len=50M", note the log_buf_len is probably not necessary but better safe then sorry.

If you can grab the dmesg without the "pci=nocrs", that would be great.

Comment 18 Matt 2021-07-01 13:15:09 UTC
Created attachment 1796799 [details]
dmesg output for 5.12.13-300

(In reply to Hans de Goede from comment #17)
> Matt, thank you.
> 
> I'm afraid I made a mistake I actually need the dmesg output without the
> "pci=nocrs", so with just "log_buf_len=50M", note the log_buf_len is
> probably not necessary but better safe then sorry.
> 
> If you can grab the dmesg without the "pci=nocrs", that would be great.

No worries Hans. I've attached the updated dmesg without the pci kernel arg. 

-Matt

Comment 19 Hans de Goede 2021-07-01 14:26:51 UTC
Thanks, the last set of logs has helped to finally understand what is going on here.

Your BIOS claims that any memory between 0x000000004bc50000-0x00000000cfffffff is reserved:

[    0.000000] BIOS-e820: [mem 0x000000004bc50000-0x00000000cfffffff] reserved

But then continuous with placing the iomem window for PCI devices inside that reserved range:

[    0.609988] pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window]

This confuses the kernel and makes it unable to assign PCI iomem to devices which have not already been assigned iomem by the BIOS, like the I2C-controller used for the touchpad.

If you are interested in / curious about the low level details, I'm discussing this with the kernel PCI developers (including figuring out how to deal with this) here:
https://lore.kernel.org/linux-pci/7d80f639-0768-850b-5313-3bdedf0a5579@redhat.com/

Comment 20 Matt 2021-07-02 09:35:34 UTC
(In reply to Hans de Goede from comment #19)
> Thanks, the last set of logs has helped to finally understand what is going
> on here.
> 
> Your BIOS claims that any memory between
> 0x000000004bc50000-0x00000000cfffffff is reserved:
> 
> [    0.000000] BIOS-e820: [mem 0x000000004bc50000-0x00000000cfffffff]
> reserved
> 
> But then continuous with placing the iomem window for PCI devices inside
> that reserved range:
> 
> [    0.609988] pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff
> window]
> 
> This confuses the kernel and makes it unable to assign PCI iomem to devices
> which have not already been assigned iomem by the BIOS, like the
> I2C-controller used for the touchpad.
> 
> If you are interested in / curious about the low level details, I'm
> discussing this with the kernel PCI developers (including figuring out how
> to deal with this) here:
> https://lore.kernel.org/linux-pci/7d80f639-0768-850b-5313-
> 3bdedf0a5579@redhat.com/

Hi Hans, thanks for the informative summary of the low-level details from the 
discussion at the linux-pci list. It's always interesting to read about a bug 
being unravelled and eventually squashed. 

I will try to respond promptly over the next few days if further logs/data
are required.

-Matt

Comment 21 Hans de Goede 2021-10-04 16:05:36 UTC
Hi,

Sorry for the long silence on this bug. I was hoping one of the upstream pci-subsys devs would help out with this...

Since that did not happen I've been looking into fixing this myself now. I've come up with a solution which still involves a kernel cmdline option for now, but this one is a much smaller hammer (almost a scalpel) and once it is confirmed that this works I can enable this by default through a DMI quirk.

I've build a test-kernel with support for the new kernel cmdline option here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=76687852

Here are some generic instructions for installing a kernel directly from koji (the Fedora buildsystem):
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please undo the pci=nocrs workaround by running:

sudo grubby --update-kernel=ALL --remove-args=pci=nocrs

And then enable the new workaround by:

sudo grubby --update-kernel=ALL --args=pci=no_e820

Also please run the following command *as normal user* to collect the DMI strings for your laptop, so that they can be used to add a quirk:

grep . /sys/class/dmi/id/* 2> /dev/null

And copy and paste the output here.

Comment 22 Hans de Goede 2021-10-04 16:12:11 UTC
p.s.

Please also provide dmesg output for the new kernel after booting it with pci=no_e820 on the kernel cmdline.

Comment 23 Matt 2021-10-05 08:02:19 UTC
(In reply to Hans de Goede from comment #21)
> Hi,
> 
> Sorry for the long silence on this bug. I was hoping one of the upstream
> pci-subsys devs would help out with this...

Since the nocrs cmdline arg solution has been available to use as a workaround, 
there's no problems with waiting. :)

> Since that did not happen I've been looking into fixing this myself now.
> I've come up with a solution which still involves a kernel cmdline option
> for now, but this one is a much smaller hammer (almost a scalpel) and once
> it is confirmed that this works I can enable this by default through a DMI
> quirk.

Can confirm the more refined no_e820 cmdline arg works and imo it seems to 
offer a more responsive/smoother engagement when using the touchpad.

 
> Also please run the following command *as normal user* to collect the DMI
> strings for your laptop, so that they can be used to add a quirk:
> 
> grep . /sys/class/dmi/id/* 2> /dev/null
> 
> And copy and paste the output here.

/sys/class/dmi/id/bios_date:12/23/2020
/sys/class/dmi/id/bios_release:1.44
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:EMCN44WW
/sys/class/dmi/id/board_asset_tag:NO Asset Tag
/sys/class/dmi/id/board_name:LNVNB161216
/sys/class/dmi/id/board_vendor:LENOVO
/sys/class/dmi/id/board_version:SDK0J40700 WIN
/sys/class/dmi/id/chassis_asset_tag:NO Asset Tag
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:LENOVO
/sys/class/dmi/id/chassis_version:IdeaPad 3 15IIL05
/sys/class/dmi/id/ec_firmware_release:1.44
/sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvrEMCN44WW:bd12/23/2020:br1.44:efr1.44:svnLENOVO:pn81WE:pvrIdeaPad315IIL05:rvnLENOVO:
rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrIdeaPad315IIL05:skuLENOVO_MT_81WE_BU_idea_FM_IdeaPad315IIL05:
/sys/class/dmi/id/product_family:IdeaPad 3 15IIL05
/sys/class/dmi/id/product_name:81WE
/sys/class/dmi/id/product_sku:LENOVO_MT_81WE_BU_idea_FM_IdeaPad 3 15IIL05
/sys/class/dmi/id/product_version:IdeaPad 3 15IIL05
/sys/class/dmi/id/sys_vendor:LENOVO
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnLENOVO:bvrEMCN44WW:bd12/23/2020:br1.44:efr1.44:svnLENOVO:pn81WE:pvrIdeaPad315IIL05:rvnLENOVO:
rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrIdeaPad315IIL05:skuLENOVO_MT_81WE_BU_idea_FM_IdeaPad315IIL05:


Cheers, Matt.

Comment 24 Matt 2021-10-05 08:05:25 UTC
Created attachment 1829283 [details]
dmesg output with no_e820 pci cmdline arg

Comment 25 Hans de Goede 2021-10-05 09:55:47 UTC
Matt, thank you for the quick turn-around time on testing this.

I've one more kernel for you to test. This automatically activates the pci=no_e820 behavior on your model laptop, so this one should work without needing any kernel cmdline options at all:

https://koji.fedoraproject.org/koji/taskinfo?taskID=76736063

(note this is still building ATM)

After booting this (without special kernel cmdline options), 'dmesg | grep "E820 reservations"' should still show:

[    0.558144] PCI: Ignoring E820 reservations for host bridge windows

As it does with yesterdays test kernel when adding pci=no_e820 to the kernel cmdline.

And your touchpad should still work :)

If you can confirm this then I'll submit the new version with the DMI quirk to automatically enable this upstream and then cross my fingers that my workaround for this is acceptable upstream.

I'll also try to get testing feedback from people seeing the same issue on a "Lenovo IdeaPad 5 14IIL05" and other related models. Hopefully we will be able to fix this for those other models by adding DMI quirks for them too.

Thank you very much for all your help with testing things to get this resolved.

Comment 26 Matt 2021-10-05 12:13:49 UTC
(In reply to Hans de Goede from comment #25)

> After booting this (without special kernel cmdline options), 'dmesg | grep
> "E820 reservations"' should still show:
> 
> [    0.558144] PCI: Ignoring E820 reservations for host bridge windows
> 
> As it does with yesterdays test kernel when adding pci=no_e820 to the kernel
> cmdline.
> 
> And your touchpad should still work :)
> 
> If you can confirm this then I'll submit the new version with the DMI quirk
> to automatically enable this upstream and then cross my fingers that my
> workaround for this is acceptable upstream.

Hi Hans,

I'm happy to confirm your latest kernel build with the new DMI quirk works as 
expected without the cmdline arg and the dmesg output still includes the above
message regarding ignoring E820 reservations. :)

> I'll also try to get testing feedback from people seeing the same issue on a
> "Lenovo IdeaPad 5 14IIL05" and other related models. Hopefully we will be
> able to fix this for those other models by adding DMI quirks for them too.
> 
> Thank you very much for all your help with testing things to get this
> resolved.

Happy to help - we got there in the end! :) Thanks for your work on this bug and
finding a solution. Hopefully it will be suitable upstream and will be useful for 
applying a fix to similar laptops to mine.

Regards, Matt.

Comment 27 Hans de Goede 2021-10-05 15:16:13 UTC
Thank you, I've submitted the patch upstream now:

https://lore.kernel.org/linux-pci/20211005150956.303707-1-hdegoede@redhat.com/T/#u

Comment 28 Hans de Goede 2021-10-11 09:36:38 UTC
Hi Matt,

Upstream review/discussion has noted that many different models are impacted by this problem. And the conclusion is that the no_e820 behavior should be the default, but to avoid causing regressions with some older boards which needed the use_e820 behavior the plan (my plan) for now is to keep the old use_e820 behavior for any devices where the cat /sys/class/dmi/id/bios_date year is less then 2018 (so the latest BIOS update is from 2017 or older). This replaces the per model DMI matching from my previous patch.

Leading to this new version of the patch:
https://lore.kernel.org/linux-pci/20211011090531.244762-1-hdegoede@redhat.com/T/#u

I've started a new scratch/test-kernel build with the new version of the patch:
https://koji.fedoraproject.org/koji/taskinfo?taskID=77061333

(note this is still building ATM)

After booting this (without special kernel cmdline options), 'dmesg | grep "E820 reservations"' should still show:

[    0.558144] PCI: Ignoring E820 reservations for host bridge windows

as before and your touchpad should still work :)

If you can find some time to test this and confirm that I did not break things, that would be great.

Regards,

Hans

Comment 29 Matt 2021-10-12 07:15:03 UTC
(In reply to Hans de Goede from comment #28)
> Hi Matt,
> 
> Upstream review/discussion has noted that many different models are impacted
> by this problem. And the conclusion is that the no_e820 behavior should be
> the default, but to avoid causing regressions with some older boards which
> needed the use_e820 behavior the plan (my plan) for now is to keep the old
> use_e820 behavior for any devices where the cat /sys/class/dmi/id/bios_date
> year is less then 2018 (so the latest BIOS update is from 2017 or older).
> This replaces the per model DMI matching from my previous patch.

Hi Hans,

This BIOS date matching logic definitely seems like the more efficient way to 
scale the application of this patch. :)

> 
> After booting this (without special kernel cmdline options), 'dmesg | grep
> "E820 reservations"' should still show:
> 
> [    0.558144] PCI: Ignoring E820 reservations for host bridge windows
> 
> as before and your touchpad should still work :)
> 
> If you can find some time to test this and confirm that I did not break
> things, that would be great.
> 
> Regards,
> 
> Hans

The dmesg output still correctly logs the E820 reservations as being ignored
and touchpad functions as expected - you did not break things. :)

Regards, 
Matt.

Comment 30 Hans de Goede 2021-10-12 07:55:19 UTC
Great, thank you for testing!


Note You need to log in before you can comment on or make changes to this bug.