MSFT0004:00 06CB:CD98 Touchpad/trackpad mouse randomly not recognized from any given boot

This change was made by a bot.

Please attach your acpi dump info:

  $ sudo apt install acpica-tools
  $ sudo acpidump -o acpi.dump

And attach that `acpi.dump` file.

Hello,

Thanks a lot for having a look, please find enclosed acpi.dump
Do not hesitate if I can provide anything else.

Regards,

@AdrienM, so you can decompile your ACPI blob shipped by the device vendor:

  $ acpixtract acpi.dump
  $ iasl -d *.dat

And from the decompiled `dsdt.dsl` file, it has:

  Name (_HID, "XXXX0000") // _HID: Hardware ID
  Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID: Compatible ID
  ...

I'm not sure what will it be like in the runtime, so we need your to run:

  $ cd /sys/bus/acpi/devices
  $ for d in $(ls -1 */hid); do d=${d%/*}; grep -q PNP0C50 $d/modalias && echo $d; done

And, please re-attach your dmesg log with following kernel boot parameters. For detailed steps, please see https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter:

  dyndbg="file drivers/hid/* +pt" i2c-hid.debug=1 log_buf_len=16M

Hello,

Result from

...
for d in $(ls -1 */hid); do d=${d%/*}; grep -q PNP0C50 $d/modalias && echo $d; done
...

=> MSFT0004:01

And attached dmesg output using the boot parameter you mention.

Regards,
Adrien

Sorry, I missed one parameter "hid.debug=1". Could you attach dmesg one more time with that appended? It makes:

  dyndbg="file drivers/hid/* +pt" hid.debug=1 i2c-hid.debug=1 log_buf_len=16M

Thank you.

Here it is !

Hello,

Anything else I can provide ?

Regards,

I also have the same problem, under Linux this touchpad doesn't work.

This bug report has more information than bug #1880172.
This one should be main thread no ?

i dont know why but sometimes the touchpad work and sometimes the touchpad doesnt work ..

@TheTakylo: What is your OS and what is your kernel version ? Do you have the exact same ideaPad 5 - 14IIL05 ?

Actually the touchpad doesnt work.
This is my computer details

       _,met$$$$$gg.
    ,g$$$$$$$$$$$$$$$P. --------------------------
  ,g$$P" """Y$$.". OS: Debian GNU/Linux bullseye/sid x86_64
 ,$$P' `$$$. Host: 81YH IdeaPad 5 14IIL05
',$$P ,ggs. `$$b: Kernel: 5.6.0-1-amd64
`d$$' ,$P"' . $$$ Uptime: 49 mins
 $$P d$' , $$P Packages: 1830 (dpkg)
 $$: $$. - ,d$$' Shell: bash 5.0.16
 $$; Y$b._ _,d$P' Resolution: 1920x1080
 Y$$. `.`"Y$$$$P"' DE: GNOME
 `$$b "-.__ WM: Mutter
  `Y$$ WM Theme: Adwaita
   `Y$$. Theme: Adwaita [GTK2/3]
     `$$b. Icons: Adwaita [GTK2/3]
       `Y$$b. Terminal: gnome-terminal
          `"Y$b._ CPU: Intel i5-1035G1 (8) @ 3.600GHz
              `""" GPU: Intel Iris Plus Graphics G1
                              GPU: NVIDIA GeForce MX330
                              Memory: 2906MiB / 15758MiB

Hello,

I have it working after installation of Ubuntu 19.10. However it stop as soon as I do an apt upgrade . Will try to understand which package break it.

Ok so for the moment , I have a working install of Ubuntu 19.10.
Seems that the issue is happening when you update/change xorg-server, which I was doing almost at first to load nvidia driver.
Therefore, for the moment :
Make sure to be in UEFI
Install from Ubuntu 19.10 ISO
Install from apt nvidia-driver-440 nvidia-prime mesa-utils
(Do not use the Additional Driver GUI interface of Ubuntu)
Then do apt update && apt upgrade && apt autoremove

Not sure it will work for every one as it seems really random , will keep on trying to understand exactly what is happening.

Ok in fact the issue is still randomly happening.
Found some bug report on Arch forum too , seems to be an issue of how i2c_hid controler is working and especially how it is shutdown.

I have a 14IIL05 here, and the same issue with Ubuntu 20.04 and Kernel 5.7. The Touchpad does not respond in any way (though it works in Windows, but only after installation of drivers).

Normally you can have it working from time to time ( just being lucky on startup I guess ).
Try to shutdown & start ( and not reboot )

Did you try enabling SecureBoot ?

Am 01.06.20 um 18:45 schrieb AdrienM:
> Normally you can have it working from time to time ( just being lucky on startup I guess ).
> Try to shutdown & start ( and not reboot )
>
No, Touchpad never worked in Ubuntu.

Am 01.06.20 um 19:11 schrieb AdrienM:
> Did you try enabling SecureBoot ?
>

Yes, I did two times now, but it doesn't change anything.

For a few days the touchpad worked every other day, for a week it hadn't worked at all for me :/

Hi
Just to add some informations.
Just got today a Lenovo Ideapad 14ILI05, Core i5 based, and no touchpad working.
I've tried with kubuntu 19.10 since AdrienM said it was working with this release, but no more luck with it (only tried Live).

I saw a BIOS update on Lenovo support page from 5 days ago, not yet installed it, but I doubt it will make it work !

If I can provide some logs or dumps, or even try patches, I'm willing to help !

Just some follow-up :
It seems that my touchpad is not the same as AdrienM, since my acpi dump is about ELAN0001 and AdrienM's is ELAN2097.

Following some recommendations found on askubuntu.com, I'm currently trying to compile a 5.7.2 kernel with added ELAN0001 id to include/linux/input/elan-i2c-ids.h, and also made the elan touchscreen driver as a module, since this driver recognizes the ELAN0001 as a touch screen, and not a mouse.

I'll post an update when I'll have tested.

So, tried with kernel 5.7.2, disabled elants-i2c module, and added device ID in elan-i2c-ids.h, same problem.

Don't know where to look now :(

Did you all confirm the issue? I think this is very important to estimate the priority for the developers.

thx for ur feedback..

same here on Lenovo IdeaPad 3 14IIL05 Core i3-1005G1 (81WD004MGE)

sudo acpidump | grep -C3 ELAN

 27EC0: 70 47 4E 55 4D 0C 10 00 01 06 49 4E 54 31 70 49 pGNUM.....INT1pI
 27ED0: 4E 55 4D 0C 10 00 01 06 49 4E 54 32 A0 34 93 54 NUM.....INT2.4.T
 27EE0: 50 54 59 01 70 0D 4D 53 46 54 30 30 30 31 00 5F PTY.p.MSFT0001._
 27EF0: 48 49 44 70 0D 45 4C 41 4E 30 30 30 31 00 5F 53 HIDp.ELAN0001._S
 27F00: 55 42 70 0A 15 42 41 44 52 70 01 48 49 44 32 A4 UBp..BADRp.HID2.
 27F10: 00 A0 36 93 54 50 54 59 0A 02 70 0D 4D 53 46 54 ..6.TPTY..p.MSFT
 27F20: 30 30 30 31 00 5F 48 49 44 70 0D 53 59 4E 41 30 0001._HIDp.SYNA0

this old fix wont work

https://forums.gentoo.org/viewtopic-t-1086512-start-0.html

greetz

perhaps the same issue?!

The main culprit was CONFIG_PINCTRL_SUNRISEPOINT that provides an interface that allows configuring of PCH pins and using them as GPIOs. Apparently the touchpad port needs to be unlocked by the signal raised by PCH's GPIO pins, so this module is required for it to work. It is called pinctrl_sunrisepoint, and it is a feature of my motherboard's chipset, Sunrise Point.

greetz

I also confirm the error, here is the error of my computer: IdeaPad 5 14IIL05

and the touchpad is not detected.

sudo acpidump | grep -C3 ELAN
   30C80: 30 93 54 50 4C 54 0A 02 70 0D 41 54 4D 4C 32 39 0.TPLT..p.ATML29
   30C90: 35 32 00 5F 48 49 44 70 00 48 49 44 32 70 0A 4A 52._HIDp.HID2p.J
   30CA0: 42 41 44 52 70 0C 80 1A 06 00 53 50 45 44 A4 00 BADRp.....SPED..
   30CB0: A0 30 93 54 50 4C 54 0A 03 70 0D 45 4C 41 4E 32 .0.TPLT..p.ELAN2
   30CC0: 30 39 37 00 5F 48 49 44 70 01 48 49 44 32 70 0A 097._HIDp.HID2p.
   30CD0: 10 42 41 44 52 70 0C 80 1A 06 00 53 50 45 44 A4 .BADRp.....SPED.
   30CE0: 00 A0 30 93 54 50 4C 54 0A 04 70 0D 4E 54 52 47 ..0.TPLT..p.NTRG

Please all click on "This bug affecty you and 7 other people" and then "Does this bug affect you?" "Yes". Thank you!

Perhaps it has something to do with CONFIG_PINCTRL_SUNRISEPOINT, but how can we be sure that our motherboard is including SUNRISE POINT ?

Same issue, got a latest Ideapad 5 and found trackpad and brightness adjustment not working. Tried couple of things like changing distro, changing Kernel version etc, nothing worked.

Hello,

I don't know why, my touchpad is working today and it's detected!

⎜ ↳ MSFT0004:00 06CB:CD98 Mouse id=13 [slave pointer (2)]
⎜ ↳ MSFT0004:00 06CB:CD98 Touchpad id=14 [slave pointer (2)]

Doesnt work toaday ... too strange !

This bug is still unassigned for a month now, Not sure when we can have an update. Has anyone from the affected users found an alternative to this ?.

nope..some old workarounds that don't work for us, this is all.

What I learned by using Linux is patience. In the meantime I use a bluetooth mouse. Works fine, but you have to activate bluetooth with another device ;-) Lucky, that everything else is doing well.

Hi there,

My problem is same as yours.

I have an Ideapad 81YH with intel i7 chipset. I installed ubuntu 20.04 with kernel 5.4 and touchpad doesn't seem to work as well.

2-3 days ago I modified the grub in /etc/default, it made my touchpad working for a few boots. Unfortunately, it's gone..

IDK what to do to fix this. If someone has some ideas or tests to improve touchpad behaviour, it could be great !

Got at Lenovo ideapad 5 14IIL05 intel i7. Fresh install of ubuntu 20.04 touchpad never worked a single time so seems to be the same issue. Any information i can share to help with the issue?

I found a weird work around updated the kernel to 5.7.1.
Then i disabled legacy support uefi only.
Then secure boot then booted up. Ubuntu told me it couldn't.
Then disabled secure boot and then it worked.

When it stops working redo these last steps in BIOS makes it work.

The attachment "[PATCH] PCI/ACPI: Make acpi_pci_root_validate_resources() reject IOMEM resources which start at address 0" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Ditto, if an Ubuntu Dev can build a test kernel with the patch I would be happy to throw it into my installation.

Thanks for the instructions. So I added the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nocrs" and updated grub. I rebooted the machine at least five times and the touchpad never worked - I had to use an external mouse. This is a bit different in a sense that this seems to be consistent whereas usually the touchpad completely randomly works every now and then.

I think I will keep the settings as they are just to see if the touchpad randomly starts to work again. I mean the position of the moon might have an effect on this ;-)

Let me know if I can be of any help in further testing.

Btw, my kernel was just updated to 5.8.0-55-generic.

Regarding my previous post what happened is that the touchpad started to work again out of the blue. Before this the system had difficulties to shutdown. The shutdwown process lasted for minutes and during that the system displayed a message "i2c_designware AMDI0010:00: controller times out". This lasted for a long time. So long that I had time to take a photo of it which is attached.

Eventually the system managed to shutdown and now I that I turned on the system the touchpad works again. Bizarre.

Here is the dmesg output as well.

I can report that this device seems also affected:
Lenovo V15-IIL Iron Grey, Core i5-1035G1, 8GB RAM, 512GB SSD, DE (82C500JUGE)

This is with running a Debian testing kernel 5.10.0-7-amd64/5.10.40-1.

Adding the pci=nocrs makes the touchpad work, but unfortunately this does
not survive a standby or hibernate cycle.

@j-w-r-degoede: Do you still need your patch to be tested?

Bernhard, no in the mean time I've learned that my patch is no good. I'm currently debugging this with a Fedora user who also needs pci=nocrs to get the touchpad to work:
https://bugzilla.redhat.com/show_bug.cgi?id=1868899

But this is going quite slow because the cycle between me providing the user with a kernel with some extra debugging logging added; and me getting a dmesg output for that test kernel back is quite slow.

@Hans de Goede (j-w-r-degoede) is the patch working for Ideapad 3 15iil05? Then I would compile a kernel myself and test it on my laptop.

Ratul, the patch which I attached won 't help you. The patch is basically no good, because the problem is not what I thought it was.

I've been working with a Fedora reporter to try and solve the case where pci=nocrs helps to get a working touchpad, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1868899

Thanks to the latest set of logs attached there, I now am finally starting to 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://<email address hidden>/

@Hans de Goede Hi, I am using lenovo Ideapad 5 14IIL05 also. After I installed ubuntu 20.04,I can't even boot the ubuntu, I stuck at the black screen with blinking underscore. Is there anything I can do to solve this? I try to use ctrl alt f1 to f10 but no respond from ubuntu. Thanks in advance for your help.

@Jayden: Did you verify the image? Ubuntu 20.04 worked on my 14IIL05, of
course without touchpad. I know that all that is something off topic,
but we should clarify that very fast, so we know, if Jaydens Problem has
something to do with the Touchpad problem.

Am 08.07.21 um 04:27 schrieb Jayden:
> @Hans de Goede Hi, I am using lenovo Ideapad 5 14IIL05 also. After I
> installed ubuntu 20.04,I can't even boot the ubuntu, I stuck at the
> black screen with blinking underscore. Is there anything I can do to
> solve this? I try to use ctrl alt f1 to f10 but no respond from ubuntu.
> Thanks in advance for your help.
>

As this bug exists for more than a year now, it would be great if we
could re-activate Bluetooth-Mice with Keybord only after they say
goodbye occasionally.

Hi. I did verify the image. Now, I manage to get through the black screen by using win+fn+f2 to go to tty2 then win+fn+f1 to go to login screen. Sometimes if it stuck at black screen, I would use the method mentioned above. Sometimes it manage to get to the login screen directly. But I do think this issue has sth to do with the touchpad. Cuz I will see the error messages controller timeout when I shut the system down (if the touchpad is nit working). For my laptop, the touchpad works sometimes while sometimes it doesn't.

Can we get a fix after over a year now? I think we have enough people suffering to deserve a fix for this bug.

I had similar issue.

Lenovo Ideapad 5 14ARE05 dual boot Windows 10 and Ubuntu 20.04 (Kernel 5.11 after update)

Solution steps:

(1) Update your Ubuntu 20.04 installation with all the latest update. This should update your Kernel too (mine updated to 5.11).

(2) Reboot

(3) Go to Windows 10 and Download and install Latest BIOS update and install it. In my case BIOS updated from V1.09 to 1.10.
***Be careful and pay close attention to the instructions shown by the BIOS update installer. Ideally you should fully charge your laptop before performing BIOS update and keep your charger connected.***

Running BIOS update will reboot your system and change BIOS settings to default. If you had disabled secure boot to install and dual boot Ubuntu then this will enable secure boot option. You will need to disable it again. Once BIOS update is completed reboot and go to BIOS (F2)

(4) Disable secure boot in BIOS again

(5) Boot to Ubuntu. (Tip: Use F12 key to boot to Ubuntu if you do not get Ubuntu Grub Bootloader Menu. You can change the boot order from BIOS settings (F2) permanently)

Your touchpad should start working.

I am not sure what has happened with my Ideapad 5-14ARE05 laptop, but it just seems that this problem has disappeared. I assume some update fixed it finally.

I am unning 5.11.0-34-generic #36~20.04.1-Ubuntu

I have many other problems with the machine such as it does not suspend when the lid is closed and behaves strangely with my bluetooth headset. This laptop with Linux has really worn me out...

This is a follow-up to comment #123

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 also hope that this option will not cause the stability issues seen when using pci=nocrs and that it will remove the need to specify i8042.nopnp=1 .

I'll attach my patch here and then hopefully one of the Ubuntu devs can build a test-kernel for people who need pci=nocrs to test.

Alternatively you can build your own kernel with this patch added, see the Ubuntu docs for how to do this.

Once you have a kernel with this patch, remove pci=nocrs and i8042.nopnp=1 from the kernel-commandline and instead add only "pci=no_e820".

If this helps please provide DMI strings for your laptop, so that I can add a quirk to the kernel to automatically enable "pci=no_e820" on your laptop model. Run the following command *as normal user* to collect the DMI strings for your laptop:

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

And copy and paste the output here.

Please test a kernel build with this patch, combined with adding "pci=no_e820" added to the kernel commandline. See comment 133 for more details.

A test kernel with the patch can be found here:
https://people.canonical.com/~khfeng/lp1878279/

Kai-Heng, thank you for providing the test kernel.

Folks, if you need to add pci=nocrs to your kernel-commandline to get your touchpad to work, please test this kernel:

https://people.canonical.com/~khfeng/lp1878279/

With pci=no_e820 on the kernel commandline (replacing pci=nocrs). If the touchpad works this way, please provide DMI strings for your laptop, so that I can add a quirk to the kernel to automatically enable "pci=no_e820" on your laptop model. Run the following command *as normal user* to collect the DMI strings for your laptop:

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

And copy and paste the output here.

Hello there.

the pci=nocrs on Ubuntu 22.04 doesn't allow boot. So this is again a problem in the last LTS (22.04).

It has never been no problem. A bug that can be solved by a workaround
that works most times with many people is not solved.

In my opinion the case can be closed when the new Touchpad used by
Lenovo works after booting into the official image. I am waiting for
that for two years now on different Notebooks.

Am 26.04.22 um 22:11 schrieb Noctis Bennington:
> Hello there.
>
> the pci=nocrs on Ubuntu 22.04 doesn't allow boot. So this is again a
> problem in the last LTS (22.04).
>

Yeah...I'm agree Michael. At least in 20.04 that workaround was working with me and a lot of users (but as I said, I'm agree with you). Now in 22.04 it's impossible to make it works. Let's see if we can do something about it...

PS: In case you need see what's going on with pci=nocrs on 22.04

https://i.stack.imgur.com/KZtIy.jpg

Hi! @Hans de Goede @j-w-r-degoede

I tested that patch in that kernel (5.14) and it definitely works!

This is the info I received with "grep . /sys/class/dmi/id/* 2> /dev/null"

/sys/class/dmi/id/bios_date:01/28/2022
/sys/class/dmi/id/bios_release:1.52
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:EMCN52WW
/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: NO DPK
/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.52
/sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvrEMCN52WW:bd01/28/2022:br1.52:efr1.52:svnLENOVO:pn81WE:pvrIdeaPad315IIL05:rvnLENOVO:rnLNVNB161216:rvrNODPK: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:bvrEMCN52WW:bd01/28/2022:br1.52:efr1.52:svnLENOVO:pn81WE:pvrIdeaPad315IIL05:rvnLENOVO:rnLNVNB161216:rvrNODPK:cvnLENOVO:ct10:cvrIdeaPad315IIL05:skuLENOVO_MT_81WE_BU_idea_FM_IdeaPad315IIL05:

Sorry that it is taking so long to fix this. There have been several attempts at fixing this upstream already, but all of them had to be reverted/dropped because they were causing issues on other laptop models.

The latest attempt at fixing this is here:
https://<email address hidden>/

And this patch, or something close to it will hopefully go upstream soon.

Perhaps one of the Ubuntu kernel devs can provide a test kernel with this patch for Ubuntu users with this problem to test?

It could be awesome if some of the Ubuntu Kernel devs help us to test the 5.15 kernel with the patch.

I wanna try to build a custom kernel with the patch but I don't have time and I'm not an expert with it.

Someone can help us with this?

Note if someone wants to build a kernel with:
https://<email address hidden>/

This patch applies on top of the 3 patches from:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource

I tried with pci=nocrs on Linux 5.18 and now it works, just to let you know.

I had an update yesterday on Ubuntu 20.04.5. Today I recognized that the
Touchpad works. SOLVED!!!

After 2,5 years I am lucky.

Michael Amplatz

Am 05.06.22 um 19:18 schrieb Noctis Bennington:
> I tried with pci=nocrs on Linux 5.18 and now it works, just to let you
> know.
>

The current upstream resolution to this problem is https://git.kernel.org/linus/d341838d776a ("x86/PCI: Disable E820 reserved region clipping via quirks"), which relies on quirks that match DMI Vendor, Product Version, Product Name, and Board Name. This isn't an ideal solution because there are likely other systems we don't know about that need a similar fix.

The patch I'm attaching here is an experimental idea to work around this issue without the maintenance burden of the quirks.

If anybody would be willing to test this patch, I would be very grateful. To test it, apply this patch to your kernel, boot with "pci=use_e820 efi=debug", and collect the dmesg log.

N.B. Comment #149 came from bugzilla.kernel.org, NOT from launchpad, and the bug 216565 mentioned is a kernel.org bug number: https://bugzilla.kernel.org/show_bug.cgi?id=216565.

Launchpad mistakenly linkified "bug 216565" it to an unrelated launchpad bug with the same number.