Further Info:

The touchpad (/sys/devices/platform/i8042/serio1/input) just totally gone after resume.

before suspend:
#ls /sys/devices/platform/i8042/serio1/
bind_mode drvctl paritycheck reg_10 reg_23 resolution
crc_enabled firmware_id power reg_11 reg_24 resync_time
debug id protocol reg_20 reg_25 subsystem
description input rate reg_21 reg_26 uevent
driver modalias reg_07 reg_22 resetafter

after resume:
#ls /sys/devices/platform/i8042/serio1/
bind_mode drvctl id power uevent
description firmware_id modalias subsystem

The fix/workaraound is to patch "drivers/input/serio/i8042.c" as described here: https://www.mail-archive.com/linux-input@vger.kernel.org/msg19395.html

I had to add my laptop model (K501LX) to the .matches section, so perhaps it would be better to not match against specific laptop models (by listing them one by one), but instead against the offending Elantech device.


$ dmesg | grep -i elantech
[    2.432965] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x381f00)
[    2.446458] psmouse serio1: elantech: Synaptics capabilities query result 0x10, 0x14, 0x0e.
[    2.459954] psmouse serio1: elantech: Elan sample query result 00, 23, 64
[    2.529328] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input5

Two more bugreports about the same issue on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1490130
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519034

Created attachment 214331 [details]
Workaround for devices where the issue is known to exist

Looking through the bugreports about the issue, it seems these Asus models are known to show the issue:
K401LB
K501LX
X302LA
X455LAB
X455LDB

Attached patch (originally by John Hiesey, https://www.mail-archive.com/linux-input@vger.kernel.org/msg19395.html, modified to include those models). If someone could make the patch look at the exact problematic Elantech device instead of the laptop models, that would be nice.

@(In reply to Mihkel Tõnnov from comment #5)
> Attached patch (originally by John Hiesey,
> https://www.mail-archive.com/linux-input@vger.kernel.org/msg19395.html,
> modified to include those models). If someone could make the patch look at
> the exact problematic Elantech device instead of the laptop models, that
> would be nice.

I've slightly modified this patch to apply it on top of Fedora 23 kernel (v4.5) and it works as expected with my Asus X302LA. Thanks!

*** Bug 114661 has been marked as a duplicate of this bug. ***

I am affected as well, model is Asus X455LF.

*** Bug 121851 has been marked as a duplicate of this bug. ***

I have the same problem with my X450LCP.

I have the same issue with ASUS K501LX and K501LB.

Created attachment 224191 [details]
patch to solve problems on ASUS touchpads

This patch was inspired by this one[1]. I just added more ASUS laptop ids and moved this into i8042-x86ia64io.h

The IDs added in the noselftest are from this bug, but many other can be added later.

With this on mind, I had another ideas about how to deal with this problem:

* Should we just filter this option based on ASUS devices? It seems to affect a lot of devices, so this list can become bigger in the future.

* There is a way to enable this by psmouse driver? In this case we can enable noselftest when an Elantech or Focaltech touchpads are detected.

* After looking the wiki.osdev link [2], we can solve this by sending some characters to touchpad device. This can fix these problem on ASUS? If yes, I can try to check it on elantech driver (or maybe on i8042, I'm an input expert...)

But, for now, what about this patch? This can be a palliative solution?

Thanks

[1] https://marc.info/?l=linux-input&m=144312209020616&w=2
[2] http://wiki.osdev.org/%228042%22_PS/2_Controller#Step_3:_Disable_Devices

Also, one the these IDs are from this bug from Arch Linux: https://bbs.archlinux.org/viewtopic.php?id=194810

ASUS K501LB. I have the same problem.

(In reply to Anton from comment #14)
> ASUS K501LB. I have the same problem.

I'll send a new patch today, addressing this problem on your model too. I hope it gets merged soon.

Sent new patch: https://lkml.org/lkml/2016/8/1/186

Can somebody with an Asus laptop test this patch, just to help the review process?

I gonna try on weekend

(In reply to Anton from comment #18)
> I gonna try on weekend

thanks a lot!

I have the same problem with Asus X302LJ. Adding it to the patch fixes the bug.

(In reply to Stas Minakov from comment #20)
> I have the same problem with Asus X302LJ. Adding it to the patch fixes the
> bug.

Thanks for testing. So, maybe, we could add this to every Asus device, since a lot of models have the same problem?

ASUS K501LB fixed kernel with this patch works too.

(In reply to Marcos Souza from comment #21)
> (In reply to Stas Minakov from comment #20)
> > I have the same problem with Asus X302LJ. Adding it to the patch fixes the
> > bug.
> 
> Thanks for testing. So, maybe, we could add this to every Asus device, since
> a lot of models have the same problem?

Yep, I think we should.

I have an ASUS K501LX. The patch worked correctly for me on 4.7.0. Thank you!

The patch works well on K401LB5200 with ubuntu 14.04, kernel K401LB5200, thanks.

(In reply to Marcos Souza from comment #12)
> Created attachment 224191 [details]
> patch to solve problems on ASUS touchpads
> 
> This patch was inspired by this one[1]. I just added more ASUS laptop ids
> and moved this into i8042-x86ia64io.h
> 
> The IDs added in the noselftest are from this bug, but many other can be
> added later.
> 
> With this on mind, I had another ideas about how to deal with this problem:
> 
> * Should we just filter this option based on ASUS devices? It seems to
> affect a lot of devices, so this list can become bigger in the future.
> 
> * There is a way to enable this by psmouse driver? In this case we can
> enable noselftest when an Elantech or Focaltech touchpads are detected.
> 
> * After looking the wiki.osdev link [2], we can solve this by sending some
> characters to touchpad device. This can fix these problem on ASUS? If yes, I
> can try to check it on elantech driver (or maybe on i8042, I'm an input
> expert...)
> 
> But, for now, what about this patch? This can be a palliative solution?
> 
> Thanks
> 
> [1] https://marc.info/?l=linux-input&m=144312209020616&w=2
> [2] http://wiki.osdev.org/%228042%22_PS/2_Controller#Step_3:_Disable_Devices

The patch works well on K401LB5200 with ubuntu 14.04, kernel 3.19.0-66-generic, thanks.

(In reply to Marcos Souza from comment #12)
> Created attachment 224191 [details]
> patch to solve problems on ASUS touchpads
> 
> This patch was inspired by this one[1]. I just added more ASUS laptop ids
> and moved this into i8042-x86ia64io.h
> 
> The IDs added in the noselftest are from this bug, but many other can be
> added later.
> 
> With this on mind, I had another ideas about how to deal with this problem:
> 
> * Should we just filter this option based on ASUS devices? It seems to
> affect a lot of devices, so this list can become bigger in the future.
> 
> * There is a way to enable this by psmouse driver? In this case we can
> enable noselftest when an Elantech or Focaltech touchpads are detected.
> 
> * After looking the wiki.osdev link [2], we can solve this by sending some
> characters to touchpad device. This can fix these problem on ASUS? If yes, I
> can try to check it on elantech driver (or maybe on i8042, I'm an input
> expert...)
> 
> But, for now, what about this patch? This can be a palliative solution?
> 
> Thanks
> 
> [1] https://marc.info/?l=linux-input&m=144312209020616&w=2
> [2] http://wiki.osdev.org/%228042%22_PS/2_Controller#Step_3:_Disable_Devices

I'm affected as well, model Z450LA.

(In reply to Renan Birck from comment #26)
> I'm affected as well, model Z450LA.

Can you please check the new version of the patch? http://www.spinics.net/lists/linux-input/msg46384.html

As a lot of asus laptops (maybe all of them), have the same problem, I just disabled selftest on all asus devices.

It's funny to read this new patch notes, since my K53U (which is a bit older than your new laptops) has the touchpad only working 100% of times when I set i8042.reset=1.

(In reply to mirh from comment #28)
> It's funny to read this new patch notes, since my K53U (which is a bit older
> than your new laptops) has the touchpad only working 100% of times when I
> set i8042.reset=1.

So, this patch was made for you too! Can you please test the patch? I believe this will fix your problem, and for now the i8042.reset parameter won't be necessary anymore.

Please let me know if this helps you too.

(In reply to Marcos Souza from comment #27)
> (In reply to Renan Birck from comment #26)
> > I'm affected as well, model Z450LA.
> 
> Can you please check the new version of the patch?
> http://www.spinics.net/lists/linux-input/msg46384.html
> 
> As a lot of asus laptops (maybe all of them), have the same problem, I just
> disabled selftest on all asus devices.

With this patch the touchpad works perfectly after resume.

Same issue with Asus R409L however the touchpad is referenced in xinput as a Focaltech

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ FocalTechPS/2 FocalTech FocalTech Touchpad	id=14	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Asus Wireless Radio Control             	id=7	[slave  keyboard (3)]
    ↳ Video Bus                               	id=8	[slave  keyboard (3)]
    ↳ Video Bus                               	id=9	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=10	[slave  keyboard (3)]
    ↳ USB Camera                              	id=11	[slave  keyboard (3)]
    ↳ Asus WMI hotkeys                        	id=12	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]

(In reply to Tigre-Bleu from comment #31)
> Same issue with Asus R409L however the touchpad is referenced in xinput as a
> Focaltech
> 
> ⎡ Virtual core pointer                        id=2    [master pointer  (3)]
> ⎜   ↳ Virtual core XTEST pointer                      id=4    [slave  pointer
>  (2)]
> ⎜   ↳ FocalTechPS/2 FocalTech FocalTech Touchpad      id=14   [slave  pointer
>  (2)]
> ⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
>     ↳ Virtual core XTEST keyboard                     id=5    [slave 
>     keyboard (3)]
>     ↳ Power Button                                    id=6    [slave 
>     keyboard (3)]
>     ↳ Asus Wireless Radio Control                     id=7    [slave 
>     keyboard (3)]
>     ↳ Video Bus                                       id=8    [slave 
>     keyboard (3)]
>     ↳ Video Bus                                       id=9    [slave 
>     keyboard (3)]
>     ↳ Sleep Button                                    id=10   [slave 
>     keyboard (3)]
>     ↳ USB Camera                                      id=11   [slave 
>     keyboard (3)]
>     ↳ Asus WMI hotkeys                                id=12   [slave 
>     keyboard (3)]
>     ↳ AT Translated Set 2 keyboard                    id=13   [slave 
>     keyboard (3)]

Hi,

this patch[1] solves your problem?

http://www.spinics.net/lists/linux-input/msg46384.html

Yes, the patch seems to fix the issue. Will it soon be implemented in the vanila kernel?

> So, this patch was made for you too! Can you please test the patch? I believe
> this will fix your problem, and for now the i8042.reset parameter won't be
> necessary anymore.

Nope, sorry. 
Still present on 4.8-rc2 with your patch. 
It's not all that surprise though, considering it's a 2011 laptop in a whole different league than yours.

(In reply to mirh from comment #34)
> > So, this patch was made for you too! Can you please test the patch? I
> believe this will fix your problem, and for now the i8042.reset parameter
> won't be necessary anymore.
> 
> Nope, sorry. 
> Still present on 4.8-rc2 with your patch. 
> It's not all that surprise though, considering it's a 2011 laptop in a whole
> different league than yours.

Can you please send your Asus model? Maybe we should have a special case for your model, to always reset, and another to never reset with specific models. I can work on a new version of the patch as soon as you send me your model.

Lshw and dmidecode says K53U, ASUSTeK Computer Inc. 
 
But aside of that tbh, I always hesitated to complain here or in other similar threads because I fear in the end this is just one of the many problems that all the tiny differences in ACPI handling between Windows and Linux entail, as explained in bug 81331, comment 148

For as much as slowly though ACPICA guys are getting there, so in this sense I'm hopeful. 
Then this at least applies to my case, where I do have acpi-related warnings in dmesg. Wouldn't know in yours.

(In reply to mirh from comment #36)
> Lshw and dmidecode says K53U, ASUSTeK Computer Inc. 
>  
> But aside of that tbh, I always hesitated to complain here or in other
> similar threads because I fear in the end this is just one of the many
> problems that all the tiny differences in ACPI handling between Windows and
> Linux entail, as explained in bug 81331, comment 148
> 
> For as much as slowly though ACPICA guys are getting there, so in this sense
> I'm hopeful. 
> Then this at least applies to my case, where I do have acpi-related warnings
> in dmesg. Wouldn't know in yours.

Yes, I have quite of then, some because of my optimus graphics card(see my attachment).

But, in https://bugzilla.kernel.org/show_bug.cgi?id=121851, Raphael Wysocki said it's likely to be a bug in input, and not in ACPI.

IN this scenario, what do you think? Maybe Dmitry or Raphael could elucidate what is the real problem?

Created attachment 230911 [details]
ACPI warnings

Tbh, *all* of them seems related to your graphics card. 
In that bug though, I see _others_ warnings, with the 'SystemIO range' one similar to one of mine. 

Speaking of that, the stuff mentioned exactly about kbd controller by mjg59 (some machines work 9 times out of 10 and then..) seems exactly to be the ratio of my problem manifesting. 
And then that guy goes on describing how Windows and Linux differently handle reboot (and I guess the former always works, right?)

This was at least pretty pertinent to my issue, but I guess it shouldn't be all that different when talking about standby. 

To recap, I don't know if it's a problem with bare hardware or if some ACPI trick is hidden somewhere, but blacklisting all ASUS hardware seems way too rude to me, especially with no real rationale other than "it works" behind. 
http://mjg59.dreamwidth.org/14475.html


Oh, and I'm using UEFI btw, don't know if it matters. 
http://mjg59.dreamwidth.org/10014.html

Wait, is DMI_MATCH case sensitive?
Because I just noticed your laptop has all "COMPUTER" in capital letters while mine doesn't.

(In reply to mirh from comment #40)
> Wait, is DMI_MATCH case sensitive?
> Because I just noticed your laptop has all "COMPUTER" in capital letters
> while mine doesn't.

I think so. Can you please try changing the DMI_MATCH to your case?

Sure, I had indeed just started to compile rc4, in a handful of hours it should have finished.. 

Btw chances are next kernel version is going to have ACPI finally squared
https://github.com/acpica/acpica/pull/170/commits/0e24fb67cde08d7df7671d7d7b183490dc79707e

Ok, nothing again.

Seeing the same issue with a Gigabyte Aero 14 laptop.

Also an elantech trackpad. Note however that the trackpad typically works after resume but will definitely not work after a hibernate.

The issue is worse when the Nvidia 965M card is disabled (so only the intel IGP is used)

Created attachment 233421 [details]
lspci-aero14-after-hibernate

Created attachment 233441 [details]
lspci-aero14-before-hibernate

Note that Windows 10 anniversary edition had the same issue until a BIOS upgrade was released.

Once the trackpad stops working, the only way to have it working again is to boot into windows and back into linux. Simply rebooting will not make the trackpad work again

*** before hibernate

I: Bus=0011 Vendor=0001 Product=0001 Version=ab83
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd leds event0 
B: PROP=0
B: EV=120013
B: KEY=402000000 3803078f800d001 feffffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0019 Vendor=0000 Product=0005 Version=0000
N: Name="Lid Switch"
P: Phys=PNP0C0D/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:01/PNP0C0D:00/input/input2
U: Uniq=
H: Handlers=event1 
B: PROP=0
B: EV=21
B: SW=1

I: Bus=0019 Vendor=0000 Product=0003 Version=0000
N: Name="Sleep Button"
P: Phys=PNP0C0E/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:01/PNP0C0E:00/input/input3
U: Uniq=
H: Handlers=kbd event2 
B: PROP=0
B: EV=3
B: KEY=4000 0 0

I: Bus=0019 Vendor=0000 Product=0003 Version=0000
N: Name="Sleep Button"
P: Phys=PNP0C0E/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:01/input/input4
U: Uniq=
H: Handlers=kbd event3 
B: PROP=0
B: EV=3
B: KEY=4000 0 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5
U: Uniq=
H: Handlers=kbd event4 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
U: Uniq=
H: Handlers=kbd event5 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0006 Version=0000
N: Name="Video Bus"
P: Phys=LNXVIDEO/video/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
U: Uniq=
H: Handlers=kbd event6 
B: PROP=0
B: EV=3
B: KEY=3e000b00000000 0 0 0

I: Bus=0011 Vendor=0002 Product=000e Version=0000
N: Name="ETPS/2 Elantech Touchpad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input7
U: Uniq=
H: Handlers=mouse1 event8 
B: PROP=5
B: EV=b
B: KEY=e420 10000 0 0 0 0
B: ABS=661800011000003

I: Bus=0003 Vendor=1044 Product=7a06 Version=0110
N: Name="E-Signal Keyboard"
P: Phys=usb-0000:00:14.0-5/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:1044:7A06.0002/input/input10
U: Uniq=
H: Handlers=sysrq kbd leds event9 
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=1044 Product=7a06 Version=0110
N: Name="E-Signal Keyboard"
P: Phys=usb-0000:00:14.0-5/input1
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.1/0003:1044:7A06.0003/input/input11
U: Uniq=
H: Handlers=kbd mouse2 event10 js0 
B: PROP=0
B: EV=10001f
B: KEY=3f0003007f 0 0 483ffff17aff32d bf54444600000000 1f0001 130f938b17c000 677bfad9415fed 9ed68000004400 10000002
B: REL=1c0
B: ABS=100000003
B: MSC=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH Headphone"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input12
U: Uniq=
H: Handlers=event11 
B: PROP=0
B: EV=21
B: SW=4

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=3"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input13
U: Uniq=
H: Handlers=event12 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=7"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input14
U: Uniq=
H: Handlers=event13 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=8"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input15
U: Uniq=
H: Handlers=event14 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0003 Vendor=04f2 Product=b43b Version=6665
N: Name="Chicony USB 2.0 Camera"
P: Phys=usb-0000:00:14.0-9/button
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/input/input16
U: Uniq=
H: Handlers=kbd event15 
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0003 Vendor=046d Product=c077 Version=0111
N: Name="Logitech USB Optical Mouse"
P: Phys=usb-0000:00:14.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/0003:046D:C077.0005/input/input17
U: Uniq=
H: Handlers=mouse0 event7 
B: PROP=0
B: EV=17
B: KEY=ff0000 0 0 0 0
B: REL=103
B: MSC=10

jyavenard@jyaaeroubuntu:~$ sudo pm-hibernate 

jyavenard@jyaaeroubuntu:~$ cat /proc/bus/input/devices 
I: Bus=0011 Vendor=0001 Product=0001 Version=ab83
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd leds event0 
B: PROP=0
B: EV=120013
B: KEY=402000000 3803078f800d001 feffffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0019 Vendor=0000 Product=0005 Version=0000
N: Name="Lid Switch"
P: Phys=PNP0C0D/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:01/PNP0C0D:00/input/input2
U: Uniq=
H: Handlers=event1 
B: PROP=0
B: EV=21
B: SW=1

I: Bus=0019 Vendor=0000 Product=0003 Version=0000
N: Name="Sleep Button"
P: Phys=PNP0C0E/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:01/PNP0C0E:00/input/input3
U: Uniq=
H: Handlers=kbd event2 
B: PROP=0
B: EV=3
B: KEY=4000 0 0

I: Bus=0019 Vendor=0000 Product=0003 Version=0000
N: Name="Sleep Button"
P: Phys=PNP0C0E/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:01/input/input4
U: Uniq=
H: Handlers=kbd event3 
B: PROP=0
B: EV=3
B: KEY=4000 0 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5
U: Uniq=
H: Handlers=kbd event4 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
U: Uniq=
H: Handlers=kbd event5 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0006 Version=0000
N: Name="Video Bus"
P: Phys=LNXVIDEO/video/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
U: Uniq=
H: Handlers=kbd event6 
B: PROP=0
B: EV=3
B: KEY=3e000b00000000 0 0 0

I: Bus=0003 Vendor=1044 Product=7a06 Version=0110
N: Name="E-Signal Keyboard"
P: Phys=usb-0000:00:14.0-5/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:1044:7A06.0002/input/input10
U: Uniq=
H: Handlers=sysrq kbd leds event9 
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=1044 Product=7a06 Version=0110
N: Name="E-Signal Keyboard"
P: Phys=usb-0000:00:14.0-5/input1
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.1/0003:1044:7A06.0003/input/input11
U: Uniq=
H: Handlers=kbd mouse2 event10 js0 
B: PROP=0
B: EV=10001f
B: KEY=3f0003007f 0 0 483ffff17aff32d bf54444600000000 1f0001 130f938b17c000 677bfad9415fed 9ed68000004400 10000002
B: REL=1c0
B: ABS=100000003
B: MSC=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH Headphone"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input12
U: Uniq=
H: Handlers=event11 
B: PROP=0
B: EV=21
B: SW=4

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=3"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input13
U: Uniq=
H: Handlers=event12 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=7"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input14
U: Uniq=
H: Handlers=event13 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=8"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input15
U: Uniq=
H: Handlers=event14 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0003 Vendor=04f2 Product=b43b Version=6665
N: Name="Chicony USB 2.0 Camera"
P: Phys=usb-0000:00:14.0-9/button
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/input/input16
U: Uniq=
H: Handlers=kbd event15 
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0003 Vendor=046d Product=c077 Version=0111
N: Name="Logitech USB Optical Mouse"
P: Phys=usb-0000:00:14.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/0003:046D:C077.0005/input/input17
U: Uniq=
H: Handlers=mouse0 event7 
B: PROP=0
B: EV=17
B: KEY=ff0000 0 0 0 0
B: REL=103
B: MSC=10

applied the patch on 4.4.0-38 ubuntu 16.04 kernel.
Played with i8042.noselftest=1 (both in the boot grub command) and add i8042 noselftest=1 to a /etc/modprobe.d/i8042.conf

I see no difference: trackpad no longer works after hibernating.
Reboot makes no difference, I must reboot into windows first to get the trackpad going.

(In reply to Jean-Yves Avenard from comment #46)
> Created attachment 233441 [details]
> lspci-aero14-before-hibernate
> 
> Note that Windows 10 anniversary edition had the same issue until a BIOS
> upgrade was released.
> 
> Once the trackpad stops working, the only way to have it working again is to
> boot into windows and back into linux. Simply rebooting will not make the
> trackpad work again

That seems like a different issue from the one discussed here.

yes, I think so.. Found that out after posting...

it's also a slightly different elantech, Being hardware version 4.

Will open a new bug.

(In reply to Marcos Souza from comment #16)
> Sent new patch: https://lkml.org/lkml/2016/8/1/186

Excuse me, i'm a neophyte in Linux. I'm using Ubuntu 14 (LTS) on Asus K501LB. I have the same problem with my trackpad as the others. As I've understood, you have somehow solved this problem (somehow - cause I know English very bad and didn't find out all that has been written). So, could you explain me, how to install the programm you've created? I searched how to patch the kernel (I should do it, am I right?), but nothing made out.

I've found only 1 clear sequence of actions:

$sudo apt-get install kernel-package libncurses5-dev fakeroot bzip2 build-essential
$make-kpkg clean
$fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers
$cd ../
$sudo dpkg -i *.deb

But when should I install your patch? And where? 

It is really important for me. Please, help!

OK, guys, i've hardly patched kernel 3.19.8 by patch of Marcos de Souza. And I want to thank you, man! It really works. I hope, this patch will be included in subsequent kernels of Linux.

(In reply to Savel from comment #51)
> (In reply to Marcos Souza from comment #16)
> > Sent new patch: https://lkml.org/lkml/2016/8/1/186
> 
> Excuse me, i'm a neophyte in Linux. I'm using Ubuntu 14 (LTS) on Asus
> K501LB. I have the same problem with my trackpad as the others. As I've
> understood, you have somehow solved this problem (somehow - cause I know
> English very bad and didn't find out all that has been written). So, could
> you explain me, how to install the programm you've created? I searched how
> to patch the kernel (I should do it, am I right?), but nothing made out.
> 
> I've found only 1 clear sequence of actions:
> 
> $sudo apt-get install kernel-package libncurses5-dev fakeroot bzip2
> build-essential
> $make-kpkg clean
> $fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image
> kernel_headers
> $cd ../
> $sudo dpkg -i *.deb
> 
> But when should I install your patch? And where? 
> 
> It is really important for me. Please, help!

Hi Savel,

so, you're a developer? If yes, you should grab kernel source code, apply the patch, compile, install then kernel and then reboot it. By googling you will find a lot of resources talking how to do it.

(In reply to Savel from comment #52)
> OK, guys, i've hardly patched kernel 3.19.8 by patch of Marcos de Souza. And
> I want to thank you, man! It really works. I hope, this patch will be
> included in subsequent kernels of Linux.

How, great, I just saw your last comment right now!

Maybe I should create a new version of this patch, and just point to the specific Asus versions affected, instead of disabling selftest for all asus laptops.

Thanks a lot for testing!

(In reply to Marcos Souza from comment #54)
> Maybe I should create a new version of this patch, and just point to the
> specific Asus versions affected, instead of disabling selftest for all asus
> laptops.
> 
> Thanks a lot for testing!

Yep, probably more elegant. 
I wouldn't even know if they could accept something all that "rude" otherwise upstream.

(In reply to mirh from comment #55)
> (In reply to Marcos Souza from comment #54)
> > Maybe I should create a new version of this patch, and just point to the
> > specific Asus versions affected, instead of disabling selftest for all asus
> > laptops.
> > 
> > Thanks a lot for testing!
> 
> Yep, probably more elegant. 
> I wouldn't even know if they could accept something all that "rude"
> otherwise upstream.

+1, and even more elegant would be to disable selftest on the specific model of Elantech touchpads, as there are possibly more Asus models affected than are listed here so far - sadly I don't know how to do that.

And I also want to inform, that then I patch kernel 3.18.42 there are some mistakes:
root@savelmtr-K501LB:/usr/src/linux# patch -p1 --dry-run </home/savelmtr/patch
checking file drivers/input/serio/i8042-x86ia64io.h
Hunk #2 succeeded at 1126 (offset -10 lines).
checking file drivers/input/serio/i8042.c
Hunk #1 succeeded at 47 (offset -1 lines).
Hunk #2 succeeded at 906 (offset -7 lines).
Hunk #3 succeeded at 1063 (offset -7 lines).
Hunk #4 succeeded at 1137 (offset -7 lines).
Hunk #5 succeeded at 1435 (offset -86 lines).
patch unexpectedly ends in middle of line

But system will work.

When I implemented this patch to the kernel 4.7.4, linux say me

linux# patch -p1 --dry-run </home/savelmtr/patch
checking file drivers/input/serio/i8042-x86ia64io.h
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored
checking file drivers/input/serio/i8042.c
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] r
Skipping patch.
5 out of 5 hunks ignored
patch unexpectedly ends in middle of line

But I didn't check how work this kernel (it is too new for my system).

(In reply to Savel from comment #57)
> And I also want to inform, that then I patch kernel 3.18.42 there are some
> mistakes:
> root@savelmtr-K501LB:/usr/src/linux# patch -p1 --dry-run
> </home/savelmtr/patch
> checking file drivers/input/serio/i8042-x86ia64io.h
> Hunk #2 succeeded at 1126 (offset -10 lines).
> checking file drivers/input/serio/i8042.c
> Hunk #1 succeeded at 47 (offset -1 lines).
> Hunk #2 succeeded at 906 (offset -7 lines).
> Hunk #3 succeeded at 1063 (offset -7 lines).
> Hunk #4 succeeded at 1137 (offset -7 lines).
> Hunk #5 succeeded at 1435 (offset -86 lines).
> patch unexpectedly ends in middle of line
> 
> But system will work.
> 
> When I implemented this patch to the kernel 4.7.4, linux say me
> 
> linux# patch -p1 --dry-run </home/savelmtr/patch
> checking file drivers/input/serio/i8042-x86ia64io.h
> Reversed (or previously applied) patch detected!  Assume -R? [n] n
> Apply anyway? [n] 
> Skipping patch.
> 2 out of 2 hunks ignored
> checking file drivers/input/serio/i8042.c
> Reversed (or previously applied) patch detected!  Assume -R? [n] 
> Apply anyway? [n] r
> Skipping patch.
> 5 out of 5 hunks ignored
> patch unexpectedly ends in middle of line
> 
> But I didn't check how work this kernel (it is too new for my system).

This happens because your kernel is old. On newer kernels, this patch should apply directly, without any offset warnings.

Hi,
I have an ASUS R301L with Mint 17.3 and I confirm that the patch fixes the issue for me. I'm using kernel 3.19.8.
Thanks for the patch! This issue was driving me crazy.
-Maira


$ cat /proc/bus/input/devices
[...]
I: Bus=0011 Vendor=0002 Product=000e Version=0000
N: Name="ETPS/2 Elantech Touchpad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse0 event4 
B: PROP=5
B: EV=b
B: KEY=e420 10000 0 0 0 0
B: ABS=661800011000003
[...]

$ dmesg | grep -i elantech
[    1.268899] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x381f00)
[    1.282523] psmouse serio1: elantech: Synaptics capabilities query result 0x10, 0x14, 0x0e.
[    1.351459] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input5

(The outputs above were generated after successfully resuming from sleep.)

(In reply to kernel.mb from comment #59)
> Hi,
> I have an ASUS R301L with Mint 17.3 and I confirm that the patch fixes the
> issue for me. I'm using kernel 3.19.8.
> Thanks for the patch! This issue was driving me crazy.
> -Maira
> 
> 
> $ cat /proc/bus/input/devices
> [...]
> I: Bus=0011 Vendor=0002 Product=000e Version=0000
> N: Name="ETPS/2 Elantech Touchpad"
> P: Phys=isa0060/serio1/input0
> S: Sysfs=/devices/platform/i8042/serio1/input/input5
> U: Uniq=
> H: Handlers=mouse0 event4 
> B: PROP=5
> B: EV=b
> B: KEY=e420 10000 0 0 0 0
> B: ABS=661800011000003
> [...]
> 
> $ dmesg | grep -i elantech
> [    1.268899] psmouse serio1: elantech: assuming hardware version 4 (with
> firmware version 0x381f00)
> [    1.282523] psmouse serio1: elantech: Synaptics capabilities query result
> 0x10, 0x14, 0x0e.
> [    1.351459] input: ETPS/2 Elantech Touchpad as
> /devices/platform/i8042/serio1/input/input5
> 
> (The outputs above were generated after successfully resuming from sleep.)

Dmitry sent my patch to Linus today, and it was just picked, but it was missing the R301L model, so it should be added until these RCs are finished.

But, for now these models are covered by this fix:
A455LD
K401LB
K501LB
K501LX
R409L
V502LX
X302LA
X450LCP
X450LD
X455LAB
X455LDB
X455LF
Z450LA

Thanks a lot for testing my patch in all these models!

Hi! I have the same problem with my computer Asus F454L, but I don't understand well what I have to do with the file, please Cloud you explain me some one how that works and what I have to do, for dummies? Thanks a lot.

> But, for now these models are covered by this fix:
> A455LD
> K401LB
> K501LB
> K501LX
> R409L
> V502LX
> X302LA
> X450LCP
> X450LD
> X455LAB
> X455LDB
> X455LF
> Z450LA

Hello, would you mind adding my model: X455LB? Looking at the code, matching seems to be done by prefix, hence X455LAB won't cover mine. I actually kinda doubt whether models like X455LAB and X455LDB really exist, from ASUS site, I can only find: X455LA, X455LB, X455LD and X455LF.

(In reply to Mario Ray Mahardhika from comment #62)
> > But, for now these models are covered by this fix:
> > A455LD
> > K401LB
> > K501LB
> > K501LX
> > R409L
> > V502LX
> > X302LA
> > X450LCP
> > X450LD
> > X455LAB
> > X455LDB
> > X455LF
> > Z450LA
> 
> Hello, would you mind adding my model: X455LB? Looking at the code, matching
> seems to be done by prefix, hence X455LAB won't cover mine. I actually kinda
> doubt whether models like X455LAB and X455LDB really exist, from ASUS site,
> I can only find: X455LA, X455LB, X455LD and X455LF.

Hi Mario,

so we need a DMI code that checks for prefixes. I'll try to find if this is already implemented, or create new functions, so the covered version should be:
...
X450
X455
Z450

I hope this fixes this models zoo.

(In reply to Jairo Mejia from comment #61)
> Hi! I have the same problem with my computer Asus F454L, but I don't
> understand well what I have to do with the file, please Cloud you explain me
> some one how that works and what I have to do, for dummies? Thanks a lot.

Hi Jairo,
do you have the kernel source code downloaded? If yes, then execute the patch command (I'm sure there are some good tutorials on web about how to do it!).

But, before applying, change a DMI entry to be like this:
DMI_MATCH(DMI_PRODUCT_NAME, "F454L")

So it will make your kernel avoid selftests in your laptop model. After it, compile and install the new generated kernel image. Again, I'm sure googl will show to you a lot of sites that teaches how to do it.

if you have any problem to apply the patch, let me know.

(In reply to Marcos Souza from comment #63)
> Hi Mario,
> 
> so we need a DMI code that checks for prefixes. I'll try to find if this is
> already implemented, or create new functions, so the covered version should
> be:
> ...
> X450
> X455
> Z450
> 
> I hope this fixes this models zoo.

I believe this is your patch: https://github.com/torvalds/linux/commit/930e192

The patch contains a table filled with DMI_MATCH() entries, that macro will fill .slot and .substr field of the entry struct. The table is passed to dmi_check_system() which in turn calls dmi_matches(). Inside, it will check for .exact_match, which is not filled, so the .substr will be matched by using strstr() instead of strcmp() as the 2nd argument. Correcting myself, it's not a prefix search, but a substring search.

I think your idea of truncating the model names into first 4 characters will fit well, though I'm not sure whether X455Y and X455D also use the same problematic Elantech touchpad as X455L.

(In reply to Mario Ray Mahardhika from comment #65)
> (In reply to Marcos Souza from comment #63)
> > Hi Mario,
> > 
> > so we need a DMI code that checks for prefixes. I'll try to find if this is
> > already implemented, or create new functions, so the covered version should
> > be:
> > ...
> > X450
> > X455
> > Z450
> > 
> > I hope this fixes this models zoo.
> 
> I believe this is your patch:
> https://github.com/torvalds/linux/commit/930e192
> 
> The patch contains a table filled with DMI_MATCH() entries, that macro will
> fill .slot and .substr field of the entry struct. The table is passed to
> dmi_check_system() which in turn calls dmi_matches(). Inside, it will check
> for .exact_match, which is not filled, so the .substr will be matched by
> using strstr() instead of strcmp() as the 2nd argument. Correcting myself,
> it's not a prefix search, but a substring search.
> 
> I think your idea of truncating the model names into first 4 characters will
> fit well, though I'm not sure whether X455Y and X455D also use the same
> problematic Elantech touchpad as X455L.

Better yet, can you attach here the output of "dmidecode --type chassis" ?

Dmitry gave the idea to filter for Asus laptops. This is my output:
Chassis Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Type: Notebook
        Lock: Not Present
        Version: 1.0       
        Serial Number: E6N0B2019875248     
        Asset Tag: No Asset Tag    
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: None
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: 1
        Contained Elements: 0
        SKU Number: To be filled by O.E.M.

So, maybe we can filter by Chassis type as Notebook.

There you for mine:

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x0003, DMI type 3, 25 bytes
Chassis Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Type: Notebook
	Lock: Not Present
	Version: 1.0       
	Serial Number: FCN0WU00205549C     
	Asset Tag: ATN12345678901234567
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 1
		<OUT OF SPEC> (0)
	SKU Number: To be filled by O.E.M.

Created attachment 242001 [details]
New patch to solve Asus touchpad problem

So, this should work on all Asus laptops (at least 3 different models use the same DMI chassis type), so can someone please test?

Thanks in advance!

(In reply to Mario Ray Mahardhika from comment #67)
> There you for mine:
> 
> # dmidecode 3.0
> Getting SMBIOS data from sysfs.
> SMBIOS 2.8 present.
> 
> Handle 0x0003, DMI type 3, 25 bytes
> Chassis Information
>       Manufacturer: ASUSTeK COMPUTER INC.
>       Type: Notebook
>       Lock: Not Present
>       Version: 1.0       
>       Serial Number: FCN0WU00205549C     
>       Asset Tag: ATN12345678901234567
>       Boot-up State: Safe
>       Power Supply State: Safe
>       Thermal State: Safe
>       Security Status: None
>       OEM Information: 0x00000000
>       Height: Unspecified
>       Number Of Power Cords: 1
>       Contained Elements: 1
>               <OUT OF SPEC> (0)
>       SKU Number: To be filled by O.E.M.

Great, your chassis is like others that I listed in my patch, mine being laptop too. Can you please test this patch?

Also, it would be awesome if more people could test this version too.

OBS: This patch was based on 4.9-rc1, so please have a suitable source code.

So this will be applied to ALL ASUS Notebook? OK, I'll try testing it.

(In reply to Mario Ray Mahardhika from comment #70)
> So this will be applied to ALL ASUS Notebook? OK, I'll try testing it.

Yes, so this will avoid the endless "we need to add one more Asus ID" problem... So I hope!

All asus laptops still feel too bruteforce...

Hello, i have a laptop x455LD (latin american version of x455L) and this is my dmicode, shoowing a supported chasis (i think)

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Type: Notebook
	Lock: Not Present
	Version: 1.0       
	Serial Number: E9N0WU33045738G     
	Asset Tag: No Asset Tag    
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: To be filled by O.E.M.

Currently i'm trying to test the patch with my notebook, but this may take a while becuase i don't have experience creating custom kernel and i'm having problems with the boot phase. But i'm pretty sure that x455LD will be supported too.

Re #72: We used not to reset on suspend/resume on all devices, we only started doing this because of some Lenovo models and we did not think that reset would cause issues for anyone.

I think skipping all Asuses should be OK, otherwise the blacklist will grow to be 2 meters long (I see a lot of reports with different Asus models).

(In reply to Dmitry Torokhov from comment #74)
> Re #72: We used not to reset on suspend/resume on all devices, we only
> started doing this because of some Lenovo models and we did not think that
> reset would cause issues for anyone.
> 
> I think skipping all Asuses should be OK, otherwise the blacklist will grow
> to be 2 meters long (I see a lot of reports with different Asus models).

A list of all bugs that I have gather related to the same issue (some of then report more than one device ID affected by the problem):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1490130?comments=all
http://askubuntu.com/questions/622984/touchpad-not-working-after-suspend-on-asus-a450l/837301#837301
http://askubuntu.com/questions/762531/potential-solution-for-asus-x455lb-touchpad-not-working-after-resume/837304#837304
http://askubuntu.com/questions/671910/touchpad-not-working-after-suspending-laptop/837305#837305
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504445
https://forums.linuxmint.com/viewtopic.php?f=49&t=214782&p=1227961#p1227961
https://bugzilla.kernel.org/show_bug.cgi?id=105231
https://bugzilla.kernel.org/show_bug.cgi?id=96901

Along all these reports, maybe, there are a lot more of users that aren't capable of distinguish were the problem really is.

mirh, on your K53U, what exactly happens to the touchpad when you do not use i8042.reset?

BTW, it looks like ASUS changed dmidecode data from "Computer" to "COMPUTER" so Marcos patch will only affect newer devices (which I good I think).

Every let's say 7-8 boots (on average, couldn't really find a specific pattern) it stops to work altogether. Then after in Windows some times, rebooting, waiting, praying and/or removing battery it's finally detected again. 
i8042.reset fixes it with no ifs, and or buts. 

My observation wasn't really a worry for problems anyway.. It was just a wondering on whether "superior" causes couldn't exist.

Can you send me your DMI then? Even if you know what to do with your laptop it may help others to fix theirs. Thanks!

Created attachment 242181 [details]
K53U DMI

Here you are.

*** Bug 96901 has been marked as a duplicate of this bug. ***

(In reply to Marcos Souza from comment #58)
> (In reply to Savel from comment #57)
> > And I also want to inform, that then I patch kernel 3.18.42 there are some
> > mistakes:
> > root@savelmtr-K501LB:/usr/src/linux# patch -p1 --dry-run
> > </home/savelmtr/patch
> > checking file drivers/input/serio/i8042-x86ia64io.h
> > Hunk #2 succeeded at 1126 (offset -10 lines).
> > checking file drivers/input/serio/i8042.c
> > Hunk #1 succeeded at 47 (offset -1 lines).
> > Hunk #2 succeeded at 906 (offset -7 lines).
> > Hunk #3 succeeded at 1063 (offset -7 lines).
> > Hunk #4 succeeded at 1137 (offset -7 lines).
> > Hunk #5 succeeded at 1435 (offset -86 lines).
> > patch unexpectedly ends in middle of line
> > 
> > But system will work.
> > 
> > When I implemented this patch to the kernel 4.7.4, linux say me
> > 
> > linux# patch -p1 --dry-run </home/savelmtr/patch
> > checking file drivers/input/serio/i8042-x86ia64io.h
> > Reversed (or previously applied) patch detected!  Assume -R? [n] n
> > Apply anyway? [n] 
> > Skipping patch.
> > 2 out of 2 hunks ignored
> > checking file drivers/input/serio/i8042.c
> > Reversed (or previously applied) patch detected!  Assume -R? [n] 
> > Apply anyway? [n] r
> > Skipping patch.
> > 5 out of 5 hunks ignored
> > patch unexpectedly ends in middle of line
> > 
> > But I didn't check how work this kernel (it is too new for my system).
> 
> This happens because your kernel is old. On newer kernels, this patch should
> apply directly, without any offset warnings.

I've tried to patch the newest kernel, as you've suggested. But here what i've got:

root@savelmtr-K501LB:/usr/src/linux# patch -p1 -i /home/savelmtr/patch --dry-runchecking file drivers/input/serio/i8042-x86ia64io.h
Hunk #1 FAILED at 510.
Hunk #2 FAILED at 1076.
2 out of 2 hunks FAILED
checking file drivers/input/serio/i8042.c
Hunk #1 FAILED at 48.
Hunk #2 succeeded at 920 (offset 30 lines).
Hunk #3 FAILED at 1047.
Hunk #4 FAILED at 1121.
Hunk #5 FAILED at 1498.
4 out of 5 hunks FAILED
patch unexpectedly ends in middle of line


I think, this isn't right, isn't it? Kernel is 4.8.13. What shall I do?

(In reply to Savel from comment #82)
> (In reply to Marcos Souza from comment #58)
> > (In reply to Savel from comment #57)
> > > And I also want to inform, that then I patch kernel 3.18.42 there are
> some
> > > mistakes:
> > > root@savelmtr-K501LB:/usr/src/linux# patch -p1 --dry-run
> > > </home/savelmtr/patch
> > > checking file drivers/input/serio/i8042-x86ia64io.h
> > > Hunk #2 succeeded at 1126 (offset -10 lines).
> > > checking file drivers/input/serio/i8042.c
> > > Hunk #1 succeeded at 47 (offset -1 lines).
> > > Hunk #2 succeeded at 906 (offset -7 lines).
> > > Hunk #3 succeeded at 1063 (offset -7 lines).
> > > Hunk #4 succeeded at 1137 (offset -7 lines).
> > > Hunk #5 succeeded at 1435 (offset -86 lines).
> > > patch unexpectedly ends in middle of line
> > > 
> > > But system will work.
> > > 
> > > When I implemented this patch to the kernel 4.7.4, linux say me
> > > 
> > > linux# patch -p1 --dry-run </home/savelmtr/patch
> > > checking file drivers/input/serio/i8042-x86ia64io.h
> > > Reversed (or previously applied) patch detected!  Assume -R? [n] n
> > > Apply anyway? [n] 
> > > Skipping patch.
> > > 2 out of 2 hunks ignored
> > > checking file drivers/input/serio/i8042.c
> > > Reversed (or previously applied) patch detected!  Assume -R? [n] 
> > > Apply anyway? [n] r
> > > Skipping patch.
> > > 5 out of 5 hunks ignored
> > > patch unexpectedly ends in middle of line
> > > 
> > > But I didn't check how work this kernel (it is too new for my system).
> > 
> > This happens because your kernel is old. On newer kernels, this patch
> should
> > apply directly, without any offset warnings.
> 
> I've tried to patch the newest kernel, as you've suggested. But here what
> i've got:
> 
> root@savelmtr-K501LB:/usr/src/linux# patch -p1 -i /home/savelmtr/patch
> --dry-runchecking file drivers/input/serio/i8042-x86ia64io.h
> Hunk #1 FAILED at 510.
> Hunk #2 FAILED at 1076.
> 2 out of 2 hunks FAILED
> checking file drivers/input/serio/i8042.c
> Hunk #1 FAILED at 48.
> Hunk #2 succeeded at 920 (offset 30 lines).
> Hunk #3 FAILED at 1047.
> Hunk #4 FAILED at 1121.
> Hunk #5 FAILED at 1498.
> 4 out of 5 hunks FAILED
> patch unexpectedly ends in middle of line
> 
> 
> I think, this isn't right, isn't it? Kernel is 4.8.13. What shall I do?

It worked for me:

[marcos@xfiles linux-stable]$ patch  -p1< asus.patch 
patching file drivers/input/serio/i8042-x86ia64io.h
[marcos@xfiles linux-stable]$ git branch
* (HEAD detached at v4.8.13)
  master

My git url is git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

and my patch is https://bugzilla.kernel.org/attachment.cgi?id=242001

the same setup didn't worked for you? Either way, this patch will be merged in the next weeks, since the merge window opens again. Let me know if you find any other problem.

(In reply to Marcos Souza from comment #83)
> (In reply to Savel from comment #82)
> > (In reply to Marcos Souza from comment #58)
> > > (In reply to Savel from comment #57)
> > > > And I also want to inform, that then I patch kernel 3.18.42 there are
> some
> > > > mistakes:
> > > > root@savelmtr-K501LB:/usr/src/linux# patch -p1 --dry-run
> > > > </home/savelmtr/patch
> > > > checking file drivers/input/serio/i8042-x86ia64io.h
> > > > Hunk #2 succeeded at 1126 (offset -10 lines).
> > > > checking file drivers/input/serio/i8042.c
> > > > Hunk #1 succeeded at 47 (offset -1 lines).
> > > > Hunk #2 succeeded at 906 (offset -7 lines).
> > > > Hunk #3 succeeded at 1063 (offset -7 lines).
> > > > Hunk #4 succeeded at 1137 (offset -7 lines).
> > > > Hunk #5 succeeded at 1435 (offset -86 lines).
> > > > patch unexpectedly ends in middle of line
> > > > 
> > > > But system will work.
> > > > 
> > > > When I implemented this patch to the kernel 4.7.4, linux say me
> > > > 
> > > > linux# patch -p1 --dry-run </home/savelmtr/patch
> > > > checking file drivers/input/serio/i8042-x86ia64io.h
> > > > Reversed (or previously applied) patch detected!  Assume -R? [n] n
> > > > Apply anyway? [n] 
> > > > Skipping patch.
> > > > 2 out of 2 hunks ignored
> > > > checking file drivers/input/serio/i8042.c
> > > > Reversed (or previously applied) patch detected!  Assume -R? [n] 
> > > > Apply anyway? [n] r
> > > > Skipping patch.
> > > > 5 out of 5 hunks ignored
> > > > patch unexpectedly ends in middle of line
> > > > 
> > > > But I didn't check how work this kernel (it is too new for my system).
> > > 
> > > This happens because your kernel is old. On newer kernels, this patch
> should
> > > apply directly, without any offset warnings.
> > 
> > I've tried to patch the newest kernel, as you've suggested. But here what
> > i've got:
> > 
> > root@savelmtr-K501LB:/usr/src/linux# patch -p1 -i /home/savelmtr/patch
> > --dry-runchecking file drivers/input/serio/i8042-x86ia64io.h
> > Hunk #1 FAILED at 510.
> > Hunk #2 FAILED at 1076.
> > 2 out of 2 hunks FAILED
> > checking file drivers/input/serio/i8042.c
> > Hunk #1 FAILED at 48.
> > Hunk #2 succeeded at 920 (offset 30 lines).
> > Hunk #3 FAILED at 1047.
> > Hunk #4 FAILED at 1121.
> > Hunk #5 FAILED at 1498.
> > 4 out of 5 hunks FAILED
> > patch unexpectedly ends in middle of line
> > 
> > 
> > I think, this isn't right, isn't it? Kernel is 4.8.13. What shall I do?
> 
> It worked for me:
> 
> [marcos@xfiles linux-stable]$ patch  -p1< asus.patch 
> patching file drivers/input/serio/i8042-x86ia64io.h
> [marcos@xfiles linux-stable]$ git branch
> * (HEAD detached at v4.8.13)
>   master
> 
> My git url is git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> 
> and my patch is https://bugzilla.kernel.org/attachment.cgi?id=242001
> 
> the same setup didn't worked for you? Either way, this patch will be merged
> in the next weeks, since the merge window opens again. Let me know if you
> find any other problem.

Good afternoon, Marcos, I've tried to use the same patch, but got only this:

root@savelmtr-K501LB:/usr/src/linux# patch -p1</home/savelmtr/patch --dry-run
checking file drivers/input/serio/i8042-x86ia64io.h
patch unexpectedly ends in middle of line

But with the older kernels your patch works. May be it can be connected with the fact, I don't use git?

(In reply to Savel from comment #84)
> (In reply to Marcos Souza from comment #83)
> > (In reply to Savel from comment #82)
> > > (In reply to Marcos Souza from comment #58)
> > > > (In reply to Savel from comment #57)
> > > > > And I also want to inform, that then I patch kernel 3.18.42 there are
> some
> > > > > mistakes:
> > > > > root@savelmtr-K501LB:/usr/src/linux# patch -p1 --dry-run
> > > > > </home/savelmtr/patch
> > > > > checking file drivers/input/serio/i8042-x86ia64io.h
> > > > > Hunk #2 succeeded at 1126 (offset -10 lines).
> > > > > checking file drivers/input/serio/i8042.c
> > > > > Hunk #1 succeeded at 47 (offset -1 lines).
> > > > > Hunk #2 succeeded at 906 (offset -7 lines).
> > > > > Hunk #3 succeeded at 1063 (offset -7 lines).
> > > > > Hunk #4 succeeded at 1137 (offset -7 lines).
> > > > > Hunk #5 succeeded at 1435 (offset -86 lines).
> > > > > patch unexpectedly ends in middle of line
> > > > > 
> > > > > But system will work.
> > > > > 
> > > > > When I implemented this patch to the kernel 4.7.4, linux say me
> > > > > 
> > > > > linux# patch -p1 --dry-run </home/savelmtr/patch
> > > > > checking file drivers/input/serio/i8042-x86ia64io.h
> > > > > Reversed (or previously applied) patch detected!  Assume -R? [n] n
> > > > > Apply anyway? [n] 
> > > > > Skipping patch.
> > > > > 2 out of 2 hunks ignored
> > > > > checking file drivers/input/serio/i8042.c
> > > > > Reversed (or previously applied) patch detected!  Assume -R? [n] 
> > > > > Apply anyway? [n] r
> > > > > Skipping patch.
> > > > > 5 out of 5 hunks ignored
> > > > > patch unexpectedly ends in middle of line
> > > > > 
> > > > > But I didn't check how work this kernel (it is too new for my
> system).
> > > > 
> > > > This happens because your kernel is old. On newer kernels, this patch
> should
> > > > apply directly, without any offset warnings.
> > > 
> > > I've tried to patch the newest kernel, as you've suggested. But here what
> > > i've got:
> > > 
> > > root@savelmtr-K501LB:/usr/src/linux# patch -p1 -i /home/savelmtr/patch
> > > --dry-runchecking file drivers/input/serio/i8042-x86ia64io.h
> > > Hunk #1 FAILED at 510.
> > > Hunk #2 FAILED at 1076.
> > > 2 out of 2 hunks FAILED
> > > checking file drivers/input/serio/i8042.c
> > > Hunk #1 FAILED at 48.
> > > Hunk #2 succeeded at 920 (offset 30 lines).
> > > Hunk #3 FAILED at 1047.
> > > Hunk #4 FAILED at 1121.
> > > Hunk #5 FAILED at 1498.
> > > 4 out of 5 hunks FAILED
> > > patch unexpectedly ends in middle of line
> > > 
> > > 
> > > I think, this isn't right, isn't it? Kernel is 4.8.13. What shall I do?
> > 
> > It worked for me:
> > 
> > [marcos@xfiles linux-stable]$ patch  -p1< asus.patch 
> > patching file drivers/input/serio/i8042-x86ia64io.h
> > [marcos@xfiles linux-stable]$ git branch
> > * (HEAD detached at v4.8.13)
> >   master
> > 
> > My git url is
> git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > 
> > and my patch is https://bugzilla.kernel.org/attachment.cgi?id=242001
> > 
> > the same setup didn't worked for you? Either way, this patch will be merged
> > in the next weeks, since the merge window opens again. Let me know if you
> > find any other problem.
> 
> Good afternoon, Marcos, I've tried to use the same patch, but got only this:
> 
> root@savelmtr-K501LB:/usr/src/linux# patch -p1</home/savelmtr/patch --dry-run
> checking file drivers/input/serio/i8042-x86ia64io.h
> patch unexpectedly ends in middle of line
> 
> But with the older kernels your patch works. May be it can be connected with
> the fact, I don't use git?

I don't think so. I downloaded  the tarball here, and applied the patch in the same way you did:

wget https://bugzilla.kernel.org/attachment.cgi?id=242001 -O asus.patch
marcos@xfiles:~/Downloads/linux-4.8.13$ patch --dry-run -p1< asus.patch 
checking file drivers/input/serio/i8042-x86ia64io.h
marcos@xfiles:~/Downloads/linux-4.8.13$

Maybe your patch was malformed. You just copied the text from the webpage and used as patch?

Good evening, Marcos!
Yes, I've copied the text, but delete the beginning to the "diff". But also i've tried your method:

root@savelmtr-K501LB:/usr/src# wget https://bugzilla.kernel.org/attachment.cgi?id=242001 -O marcos.patch
--2016-12-10 21:57:24--  https://bugzilla.kernel.org/attachment.cgi?id=242001
Распознаётся bugzilla.kernel.org (bugzilla.kernel.org)... 198.145.29.146
Подключение к bugzilla.kernel.org (bugzilla.kernel.org)|198.145.29.146|:443... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 200 OK
Длина: 2999 (2,9K) [text/plain]
Сохранение в каталог: ««marcos.patch»».

100%[======================================>] 2 999       --.-K/s   за 0s      

2016-12-10 21:57:25 (1,32 GB/s) - «marcos.patch» сохранён [2999/2999]

root@savelmtr-K501LB:/usr/src# cd /usr/src/linux
root@savelmtr-K501LB:/usr/src/linux# patch p1</usr/src/marcos.patch --dry-run
checking file p1
Hunk #1 FAILED at 517.
1 out of 1 hunk FAILED

(In reply to Savel from comment #86)
> Good evening, Marcos!
> Yes, I've copied the text, but delete the beginning to the "diff". But also
> i've tried your method:
> 
> root@savelmtr-K501LB:/usr/src# wget
> https://bugzilla.kernel.org/attachment.cgi?id=242001 -O marcos.patch
> --2016-12-10 21:57:24--  https://bugzilla.kernel.org/attachment.cgi?id=242001
> Распознаётся bugzilla.kernel.org (bugzilla.kernel.org)... 198.145.29.146
> Подключение к bugzilla.kernel.org
> (bugzilla.kernel.org)|198.145.29.146|:443... соединение установлено.
> HTTP-запрос отправлен. Ожидание ответа... 200 OK
> Длина: 2999 (2,9K) [text/plain]
> Сохранение в каталог: ««marcos.patch»».
> 
> 100%[======================================>] 2 999       --.-K/s   за 0s   
> 
> 
> 2016-12-10 21:57:25 (1,32 GB/s) - «marcos.patch» сохранён [2999/2999]
> 
> root@savelmtr-K501LB:/usr/src# cd /usr/src/linux
> root@savelmtr-K501LB:/usr/src/linux# patch p1</usr/src/marcos.patch --dry-run
> checking file p1
> Hunk #1 FAILED at 517.
> 1 out of 1 hunk FAILED

Your command is wrong, you passed p1 as the file, and not as a parameter. Look at the error message.

(In reply to Marcos Souza from comment #87)
> (In reply to Savel from comment #86)
> > Good evening, Marcos!
> > Yes, I've copied the text, but delete the beginning to the "diff". But also
> > i've tried your method:
> > 
> > root@savelmtr-K501LB:/usr/src# wget
> > https://bugzilla.kernel.org/attachment.cgi?id=242001 -O marcos.patch
> > --2016-12-10 21:57:24-- 
> https://bugzilla.kernel.org/attachment.cgi?id=242001
> > Распознаётся bugzilla.kernel.org (bugzilla.kernel.org)... 198.145.29.146
> > Подключение к bugzilla.kernel.org
> > (bugzilla.kernel.org)|198.145.29.146|:443... соединение установлено.
> > HTTP-запрос отправлен. Ожидание ответа... 200 OK
> > Длина: 2999 (2,9K) [text/plain]
> > Сохранение в каталог: ««marcos.patch»».
> > 
> > 100%[======================================>] 2 999       --.-K/s   за 0s   
> > 
> > 
> > 2016-12-10 21:57:25 (1,32 GB/s) - «marcos.patch» сохранён [2999/2999]
> > 
> > root@savelmtr-K501LB:/usr/src# cd /usr/src/linux
> > root@savelmtr-K501LB:/usr/src/linux# patch p1</usr/src/marcos.patch
> --dry-run
> > checking file p1
> > Hunk #1 FAILED at 517.
> > 1 out of 1 hunk FAILED
> 
> Your command is wrong, you passed p1 as the file, and not as a parameter.
> Look at the error message.

Oh, thanx! Now it works right! I'm a total noob(

(In reply to Savel from comment #88)
> (In reply to Marcos Souza from comment #87)
> > (In reply to Savel from comment #86)
> > > Good evening, Marcos!
> > > Yes, I've copied the text, but delete the beginning to the "diff". But
> also
> > > i've tried your method:
> > > 
> > > root@savelmtr-K501LB:/usr/src# wget
> > > https://bugzilla.kernel.org/attachment.cgi?id=242001 -O marcos.patch
> > > --2016-12-10 21:57:24-- 
> https://bugzilla.kernel.org/attachment.cgi?id=242001
> > > Распознаётся bugzilla.kernel.org (bugzilla.kernel.org)... 198.145.29.146
> > > Подключение к bugzilla.kernel.org
> > > (bugzilla.kernel.org)|198.145.29.146|:443... соединение установлено.
> > > HTTP-запрос отправлен. Ожидание ответа... 200 OK
> > > Длина: 2999 (2,9K) [text/plain]
> > > Сохранение в каталог: ««marcos.patch»».
> > > 
> > > 100%[======================================>] 2 999       --.-K/s   за 0s 
> > > 
> > > 
> > > 2016-12-10 21:57:25 (1,32 GB/s) - «marcos.patch» сохранён [2999/2999]
> > > 
> > > root@savelmtr-K501LB:/usr/src# cd /usr/src/linux
> > > root@savelmtr-K501LB:/usr/src/linux# patch p1</usr/src/marcos.patch
> --dry-run
> > > checking file p1
> > > Hunk #1 FAILED at 517.
> > > 1 out of 1 hunk FAILED
> > 
> > Your command is wrong, you passed p1 as the file, and not as a parameter.
> > Look at the error message.
> 
> Oh, thanx! Now it works right! I'm a total noob(

No problem, just test the oatch and say if it's working for your. Also, can you add here the output of dmidecode command?

Thanks!

Yes, Marcos, system with patch works, and now it works perfectly, as I think.
Here the output of dmidecode:

# dmidecode 2.12
# SMBIOS entry point at 0x9ce32918
SMBIOS 2.8 present.
27 structures occupying 2156 bytes.
Table at 0x9C7CE000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: K501LB.201
	Release Date: 03/24/2015
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 6464 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		Smart battery is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 5.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Product Name: K501LB
	Version: 1.0       
	Serial Number: F7N0CX142574294     
	UUID: 1D18D028-6355-FF42-975C-7325F8DCB40B
	Wake-up Type: Power Switch
	SKU Number: ASUS-NotebookSKU
	Family: K

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Product Name: K501LB
	Version: 1.0       
	Serial Number: BSN12345678901234567
	Asset Tag: ATN12345678901234567
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: MIDDLE              
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 25 bytes
Chassis Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Type: Notebook
	Lock: Not Present
	Version: 1.0       
	Serial Number: F7N0CX142574294     
	Asset Tag: ATN12345678901234567
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 1
		<OUT OF SPEC> (0)
	SKU Number: To be filled by O.E.M.

Handle 0x0004, DMI type 10, 26 bytes
On Board Device 1 Information
	Type: Video
	Status: Enabled
	Description:  VGA
On Board Device 2 Information
	Type: Ethernet
	Status: Enabled
	Description:  GLAN
On Board Device 3 Information
	Type: Ethernet
	Status: Enabled
	Description:  WLAN
On Board Device 4 Information
	Type: Sound
	Status: Enabled
	Description:  Audio CODEC 
On Board Device 5 Information
	Type: SATA Controller
	Status: Enabled
	Description:  SATA Controller
On Board Device 6 Information
	Type: Other
	Status: Enabled
	Description:  USB 2.0 Controller
On Board Device 7 Information
	Type: Other
	Status: Enabled
	Description:  USB 3.0 Controller
On Board Device 8 Information
	Type: Other
	Status: Enabled
	Description:  SMBus Controller
On Board Device 9 Information
	Type: Other
	Status: Enabled
	Description:  Card Reader
On Board Device 10 Information
	Type: Other
	Status: Enabled
	Description:  Cmos Camera
On Board Device 11 Information
	Type: Other
	Status: Enabled
	Description:  Bluetooth

Handle 0x0005, DMI type 11, 5 bytes
OEM Strings
	String 1:              
	String 2:              
	String 3:              
	String 4: 90NB08P1-M01230
	String 5:  
	String 6:  
	String 7:  
	String 8:  
	String 9:  
	String 10:  

Handle 0x000C, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x000D, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1 Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Parity
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x000E, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1 Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Parity
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x000F, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2 Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 256 kB
	Maximum Size: 256 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 8-way Set-associative

Handle 0x0010, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L3 Cache
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 3072 kB
	Maximum Size: 3072 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Multi-bit ECC
	System Type: Unified
	Associativity: 12-way Set-associative

Handle 0x0011, DMI type 4, 42 bytes
Processor Information
	Socket Designation: SOCKET 0
	Type: Central Processor
	Family: Core i5
	Manufacturer: Intel(R) Corporation
	ID: D4 06 03 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 61, Stepping 4
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
	Voltage: 0.9 V
	External Clock: 100 MHz
	Max Speed: 2200 MHz
	Current Speed: 2200 MHz
	Status: Populated, Enabled
	Upgrade: <OUT OF SPEC>
	L1 Cache Handle: 0x000E
	L2 Cache Handle: 0x000F
	L3 Cache Handle: 0x0010
	Serial Number: NULL
	Asset Tag: To Be Filled By O.E.M
	Part Number: To Be Filled By O.E.M
	Core Count: 2
	Core Enabled: 2
	Thread Count: 4
	Characteristics:
		64-bit capable
		Multi-Core
		Hardware Thread
		Execute Protection
		Enhanced Virtualization
		Power/Performance Control

Handle 0x0012, DMI type 221, 12 bytes
OEM-specific Type
	Header and Data:
		DD 0C 12 00 01 01 00 02 05 00 00 00
	Strings:
		Reference Code - ACPI

Handle 0x0013, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 16 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x0014, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0013
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: SODIMM
	Set: None
	Locator: ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Samsung
	Serial Number: 94021499
	Asset Tag: 9876543210
	Part Number: M471B5173EB0-YK0  
	Rank: 1
	Configured Clock Speed: 1600 MHz

Handle 0x0015, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0013
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: SODIMM
	Set: None
	Locator: ChannelB-DIMM0
	Bank Locator: BANK 2
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Samsung
	Serial Number: 00000000
	Asset Tag: 9876543210
	Part Number: M471B5173EB0-YK0  
	Rank: 1
	Configured Clock Speed: 1600 MHz

Handle 0x0016, DMI type 19, 31 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Array Handle: 0x0013
	Partition Width: 2

Handle 0x0017, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0015
	Memory Array Mapped Address Handle: 0x0016
	Partition Row Position: Unknown
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0018, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0015
	Memory Array Mapped Address Handle: 0x0016
	Partition Row Position: Unknown
	Interleave Position: 2
	Interleaved Data Depth: 1

Handle 0x0019, DMI type 221, 54 bytes
OEM-specific Type
	Header and Data:
		DD 36 19 00 07 01 00 02 05 00 00 00 02 00 02 05
		00 03 00 03 00 02 05 00 00 00 04 05 FF FF FF FF
		FF 06 00 FF FF FF 09 00 07 00 FF FF FF 09 00 08
		00 FF FF FF FF FF
	Strings:
		Reference Code - SA - System Agent
		Reference Code - MRC
		SA - PCIe Version
		SA-CRID Status
		Disabled
		SA-CRID Original Value
		SA-CRID New Value
		OPROM - VBIOS

Handle 0x001A, DMI type 221, 26 bytes
OEM-specific Type
	Header and Data:
		DD 1A 1A 00 03 01 00 02 05 00 00 00 02 00 FF FF
		FF FF 00 03 04 0A 00 1E 30 04
	Strings:
		Reference Code - ME 10.0
		MEBx version
		ME Firmware Version
		1.5MB SKU

Handle 0x001B, DMI type 221, 68 bytes
OEM-specific Type
	Header and Data:
		DD 44 1B 00 09 01 00 02 05 00 00 00 02 03 FF FF
		FF FF FF 04 00 FF FF FF 03 00 05 00 FF FF FF 03
		00 06 00 FF FF FF FF FF 07 00 19 00 00 00 00 08
		00 2C 00 00 00 00 09 00 03 00 00 00 00 0A 00 01
		00 00 00 00
	Strings:
		Reference Code - PCH - Lynxpoint
		PCH-CRID Status
		Disabled
		PCH-CRID Original Value
		PCH-CRID New Value
		OPROM - RST - RAID
		LPTLp Bx Hsio Version
		LPTH Cx Hsio Version
		PCH9S A0 Hsio Version
		WPTLp B0 Hsio Version

Handle 0x001C, DMI type 221, 26 bytes
OEM-specific Type
	Header and Data:
		DD 1A 1C 00 03 01 00 02 05 00 00 00 02 00 00 00
		00 19 00 03 00 00 05 00 00 00
	Strings:
		Reference Code - CPU
		uCode Version
		TXT ACM version

Handle 0x001D, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x001E, DMI type 131, 64 bytes
OEM-specific Type
	Header and Data:
		83 40 1E 00 31 00 00 00 00 00 00 00 00 00 00 00
		F8 00 C3 9C 00 00 00 00 01 40 00 00 00 00 0A 00
		30 04 1E 00 00 00 00 00 C8 00 FF FF 00 00 00 00
		00 00 00 00 26 00 00 00 76 50 72 6F 00 00 00 00

Handle 0x001F, DMI type 14, 20 bytes
Group Associations
	Name: Firmware Version Info
	Items: 5
		0x0012 (<OUT OF SPEC>)
		0x0019 (<OUT OF SPEC>)
		0x001A (<OUT OF SPEC>)
		0x001B (<OUT OF SPEC>)
		0x001C (<OUT OF SPEC>)

Handle 0x0020, DMI type 127, 4 bytes
End Of Table

I hope your patch will be included in the further kernels.

(In reply to Savel from comment #90)
> Yes, Marcos, system with patch works, and now it works perfectly, as I think.
> Here the output of dmidecode:
> 
> # dmidecode 2.12
> # SMBIOS entry point at 0x9ce32918
> SMBIOS 2.8 present.
> 27 structures occupying 2156 bytes.
> Table at 0x9C7CE000.
> 
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
>       Vendor: American Megatrends Inc.
>       Version: K501LB.201
>       Release Date: 03/24/2015
>       Address: 0xF0000
>       Runtime Size: 64 kB
>       ROM Size: 6464 kB
>       Characteristics:
>               PCI is supported
>               BIOS is upgradeable
>               BIOS shadowing is allowed
>               Boot from CD is supported
>               Selectable boot is supported
>               BIOS ROM is socketed
>               EDD is supported
>               5.25"/1.2 MB floppy services are supported (int 13h)
>               3.5"/720 kB floppy services are supported (int 13h)
>               3.5"/2.88 MB floppy services are supported (int 13h)
>               Print screen service is supported (int 5h)
>               8042 keyboard services are supported (int 9h)
>               Serial services are supported (int 14h)
>               Printer services are supported (int 17h)
>               ACPI is supported
>               USB legacy is supported
>               Smart battery is supported
>               BIOS boot specification is supported
>               Targeted content distribution is supported
>               UEFI is supported
>       BIOS Revision: 5.6
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
>       Manufacturer: ASUSTeK COMPUTER INC.
>       Product Name: K501LB
>       Version: 1.0       
>       Serial Number: F7N0CX142574294     
>       UUID: 1D18D028-6355-FF42-975C-7325F8DCB40B
>       Wake-up Type: Power Switch
>       SKU Number: ASUS-NotebookSKU
>       Family: K
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
>       Manufacturer: ASUSTeK COMPUTER INC.
>       Product Name: K501LB
>       Version: 1.0       
>       Serial Number: BSN12345678901234567
>       Asset Tag: ATN12345678901234567
>       Features:
>               Board is a hosting board
>               Board is replaceable
>       Location In Chassis: MIDDLE              
>       Chassis Handle: 0x0003
>       Type: Motherboard
>       Contained Object Handles: 0
> 
> Handle 0x0003, DMI type 3, 25 bytes
> Chassis Information
>       Manufacturer: ASUSTeK COMPUTER INC.
>       Type: Notebook
>       Lock: Not Present
>       Version: 1.0       
>       Serial Number: F7N0CX142574294     
>       Asset Tag: ATN12345678901234567
>       Boot-up State: Safe
>       Power Supply State: Safe
>       Thermal State: Safe
>       Security Status: None
>       OEM Information: 0x00000000
>       Height: Unspecified
>       Number Of Power Cords: 1
>       Contained Elements: 1
>               <OUT OF SPEC> (0)
>       SKU Number: To be filled by O.E.M.
> 
> Handle 0x0004, DMI type 10, 26 bytes
> On Board Device 1 Information
>       Type: Video
>       Status: Enabled
>       Description:  VGA
> On Board Device 2 Information
>       Type: Ethernet
>       Status: Enabled
>       Description:  GLAN
> On Board Device 3 Information
>       Type: Ethernet
>       Status: Enabled
>       Description:  WLAN
> On Board Device 4 Information
>       Type: Sound
>       Status: Enabled
>       Description:  Audio CODEC 
> On Board Device 5 Information
>       Type: SATA Controller
>       Status: Enabled
>       Description:  SATA Controller
> On Board Device 6 Information
>       Type: Other
>       Status: Enabled
>       Description:  USB 2.0 Controller
> On Board Device 7 Information
>       Type: Other
>       Status: Enabled
>       Description:  USB 3.0 Controller
> On Board Device 8 Information
>       Type: Other
>       Status: Enabled
>       Description:  SMBus Controller
> On Board Device 9 Information
>       Type: Other
>       Status: Enabled
>       Description:  Card Reader
> On Board Device 10 Information
>       Type: Other
>       Status: Enabled
>       Description:  Cmos Camera
> On Board Device 11 Information
>       Type: Other
>       Status: Enabled
>       Description:  Bluetooth
> 
> Handle 0x0005, DMI type 11, 5 bytes
> OEM Strings
>       String 1:              
>       String 2:              
>       String 3:              
>       String 4: 90NB08P1-M01230
>       String 5:  
>       String 6:  
>       String 7:  
>       String 8:  
>       String 9:  
>       String 10:  
> 
> Handle 0x000C, DMI type 32, 20 bytes
> System Boot Information
>       Status: No errors detected
> 
> Handle 0x000D, DMI type 7, 19 bytes
> Cache Information
>       Socket Designation: L1 Cache
>       Configuration: Enabled, Not Socketed, Level 1
>       Operational Mode: Write Back
>       Location: Internal
>       Installed Size: 32 kB
>       Maximum Size: 32 kB
>       Supported SRAM Types:
>               Synchronous
>       Installed SRAM Type: Synchronous
>       Speed: Unknown
>       Error Correction Type: Parity
>       System Type: Data
>       Associativity: 8-way Set-associative
> 
> Handle 0x000E, DMI type 7, 19 bytes
> Cache Information
>       Socket Designation: L1 Cache
>       Configuration: Enabled, Not Socketed, Level 1
>       Operational Mode: Write Back
>       Location: Internal
>       Installed Size: 32 kB
>       Maximum Size: 32 kB
>       Supported SRAM Types:
>               Synchronous
>       Installed SRAM Type: Synchronous
>       Speed: Unknown
>       Error Correction Type: Parity
>       System Type: Instruction
>       Associativity: 8-way Set-associative
> 
> Handle 0x000F, DMI type 7, 19 bytes
> Cache Information
>       Socket Designation: L2 Cache
>       Configuration: Enabled, Not Socketed, Level 2
>       Operational Mode: Write Back
>       Location: Internal
>       Installed Size: 256 kB
>       Maximum Size: 256 kB
>       Supported SRAM Types:
>               Synchronous
>       Installed SRAM Type: Synchronous
>       Speed: Unknown
>       Error Correction Type: Single-bit ECC
>       System Type: Unified
>       Associativity: 8-way Set-associative
> 
> Handle 0x0010, DMI type 7, 19 bytes
> Cache Information
>       Socket Designation: L3 Cache
>       Configuration: Enabled, Not Socketed, Level 3
>       Operational Mode: Write Back
>       Location: Internal
>       Installed Size: 3072 kB
>       Maximum Size: 3072 kB
>       Supported SRAM Types:
>               Synchronous
>       Installed SRAM Type: Synchronous
>       Speed: Unknown
>       Error Correction Type: Multi-bit ECC
>       System Type: Unified
>       Associativity: 12-way Set-associative
> 
> Handle 0x0011, DMI type 4, 42 bytes
> Processor Information
>       Socket Designation: SOCKET 0
>       Type: Central Processor
>       Family: Core i5
>       Manufacturer: Intel(R) Corporation
>       ID: D4 06 03 00 FF FB EB BF
>       Signature: Type 0, Family 6, Model 61, Stepping 4
>       Flags:
>               FPU (Floating-point unit on-chip)
>               VME (Virtual mode extension)
>               DE (Debugging extension)
>               PSE (Page size extension)
>               TSC (Time stamp counter)
>               MSR (Model specific registers)
>               PAE (Physical address extension)
>               MCE (Machine check exception)
>               CX8 (CMPXCHG8 instruction supported)
>               APIC (On-chip APIC hardware supported)
>               SEP (Fast system call)
>               MTRR (Memory type range registers)
>               PGE (Page global enable)
>               MCA (Machine check architecture)
>               CMOV (Conditional move instruction supported)
>               PAT (Page attribute table)
>               PSE-36 (36-bit page size extension)
>               CLFSH (CLFLUSH instruction supported)
>               DS (Debug store)
>               ACPI (ACPI supported)
>               MMX (MMX technology supported)
>               FXSR (FXSAVE and FXSTOR instructions supported)
>               SSE (Streaming SIMD extensions)
>               SSE2 (Streaming SIMD extensions 2)
>               SS (Self-snoop)
>               HTT (Multi-threading)
>               TM (Thermal monitor supported)
>               PBE (Pending break enabled)
>       Version: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
>       Voltage: 0.9 V
>       External Clock: 100 MHz
>       Max Speed: 2200 MHz
>       Current Speed: 2200 MHz
>       Status: Populated, Enabled
>       Upgrade: <OUT OF SPEC>
>       L1 Cache Handle: 0x000E
>       L2 Cache Handle: 0x000F
>       L3 Cache Handle: 0x0010
>       Serial Number: NULL
>       Asset Tag: To Be Filled By O.E.M
>       Part Number: To Be Filled By O.E.M
>       Core Count: 2
>       Core Enabled: 2
>       Thread Count: 4
>       Characteristics:
>               64-bit capable
>               Multi-Core
>               Hardware Thread
>               Execute Protection
>               Enhanced Virtualization
>               Power/Performance Control
> 
> Handle 0x0012, DMI type 221, 12 bytes
> OEM-specific Type
>       Header and Data:
>               DD 0C 12 00 01 01 00 02 05 00 00 00
>       Strings:
>               Reference Code - ACPI
> 
> Handle 0x0013, DMI type 16, 23 bytes
> Physical Memory Array
>       Location: System Board Or Motherboard
>       Use: System Memory
>       Error Correction Type: None
>       Maximum Capacity: 16 GB
>       Error Information Handle: Not Provided
>       Number Of Devices: 2
> 
> Handle 0x0014, DMI type 17, 34 bytes
> Memory Device
>       Array Handle: 0x0013
>       Error Information Handle: Not Provided
>       Total Width: 64 bits
>       Data Width: 64 bits
>       Size: 4096 MB
>       Form Factor: SODIMM
>       Set: None
>       Locator: ChannelA-DIMM0
>       Bank Locator: BANK 0
>       Type: DDR3
>       Type Detail: Synchronous
>       Speed: 1600 MHz
>       Manufacturer: Samsung
>       Serial Number: 94021499
>       Asset Tag: 9876543210
>       Part Number: M471B5173EB0-YK0  
>       Rank: 1
>       Configured Clock Speed: 1600 MHz
> 
> Handle 0x0015, DMI type 17, 34 bytes
> Memory Device
>       Array Handle: 0x0013
>       Error Information Handle: Not Provided
>       Total Width: 64 bits
>       Data Width: 64 bits
>       Size: 4096 MB
>       Form Factor: SODIMM
>       Set: None
>       Locator: ChannelB-DIMM0
>       Bank Locator: BANK 2
>       Type: DDR3
>       Type Detail: Synchronous
>       Speed: 1600 MHz
>       Manufacturer: Samsung
>       Serial Number: 00000000
>       Asset Tag: 9876543210
>       Part Number: M471B5173EB0-YK0  
>       Rank: 1
>       Configured Clock Speed: 1600 MHz
> 
> Handle 0x0016, DMI type 19, 31 bytes
> Memory Array Mapped Address
>       Starting Address: 0x00000000000
>       Ending Address: 0x001FFFFFFFF
>       Range Size: 8 GB
>       Physical Array Handle: 0x0013
>       Partition Width: 2
> 
> Handle 0x0017, DMI type 20, 35 bytes
> Memory Device Mapped Address
>       Starting Address: 0x00000000000
>       Ending Address: 0x000FFFFFFFF
>       Range Size: 4 GB
>       Physical Device Handle: 0x0015
>       Memory Array Mapped Address Handle: 0x0016
>       Partition Row Position: Unknown
>       Interleave Position: 1
>       Interleaved Data Depth: 1
> 
> Handle 0x0018, DMI type 20, 35 bytes
> Memory Device Mapped Address
>       Starting Address: 0x00100000000
>       Ending Address: 0x001FFFFFFFF
>       Range Size: 4 GB
>       Physical Device Handle: 0x0015
>       Memory Array Mapped Address Handle: 0x0016
>       Partition Row Position: Unknown
>       Interleave Position: 2
>       Interleaved Data Depth: 1
> 
> Handle 0x0019, DMI type 221, 54 bytes
> OEM-specific Type
>       Header and Data:
>               DD 36 19 00 07 01 00 02 05 00 00 00 02 00 02 05
>               00 03 00 03 00 02 05 00 00 00 04 05 FF FF FF FF
>               FF 06 00 FF FF FF 09 00 07 00 FF FF FF 09 00 08
>               00 FF FF FF FF FF
>       Strings:
>               Reference Code - SA - System Agent
>               Reference Code - MRC
>               SA - PCIe Version
>               SA-CRID Status
>               Disabled
>               SA-CRID Original Value
>               SA-CRID New Value
>               OPROM - VBIOS
> 
> Handle 0x001A, DMI type 221, 26 bytes
> OEM-specific Type
>       Header and Data:
>               DD 1A 1A 00 03 01 00 02 05 00 00 00 02 00 FF FF
>               FF FF 00 03 04 0A 00 1E 30 04
>       Strings:
>               Reference Code - ME 10.0
>               MEBx version
>               ME Firmware Version
>               1.5MB SKU
> 
> Handle 0x001B, DMI type 221, 68 bytes
> OEM-specific Type
>       Header and Data:
>               DD 44 1B 00 09 01 00 02 05 00 00 00 02 03 FF FF
>               FF FF FF 04 00 FF FF FF 03 00 05 00 FF FF FF 03
>               00 06 00 FF FF FF FF FF 07 00 19 00 00 00 00 08
>               00 2C 00 00 00 00 09 00 03 00 00 00 00 0A 00 01
>               00 00 00 00
>       Strings:
>               Reference Code - PCH - Lynxpoint
>               PCH-CRID Status
>               Disabled
>               PCH-CRID Original Value
>               PCH-CRID New Value
>               OPROM - RST - RAID
>               LPTLp Bx Hsio Version
>               LPTH Cx Hsio Version
>               PCH9S A0 Hsio Version
>               WPTLp B0 Hsio Version
> 
> Handle 0x001C, DMI type 221, 26 bytes
> OEM-specific Type
>       Header and Data:
>               DD 1A 1C 00 03 01 00 02 05 00 00 00 02 00 00 00
>               00 19 00 03 00 00 05 00 00 00
>       Strings:
>               Reference Code - CPU
>               uCode Version
>               TXT ACM version
> 
> Handle 0x001D, DMI type 13, 22 bytes
> BIOS Language Information
>       Language Description Format: Long
>       Installable Languages: 1
>               en|US|iso8859-1
>       Currently Installed Language: en|US|iso8859-1
> 
> Handle 0x001E, DMI type 131, 64 bytes
> OEM-specific Type
>       Header and Data:
>               83 40 1E 00 31 00 00 00 00 00 00 00 00 00 00 00
>               F8 00 C3 9C 00 00 00 00 01 40 00 00 00 00 0A 00
>               30 04 1E 00 00 00 00 00 C8 00 FF FF 00 00 00 00
>               00 00 00 00 26 00 00 00 76 50 72 6F 00 00 00 00
> 
> Handle 0x001F, DMI type 14, 20 bytes
> Group Associations
>       Name: Firmware Version Info
>       Items: 5
>               0x0012 (<OUT OF SPEC>)
>               0x0019 (<OUT OF SPEC>)
>               0x001A (<OUT OF SPEC>)
>               0x001B (<OUT OF SPEC>)
>               0x001C (<OUT OF SPEC>)
> 
> Handle 0x0020, DMI type 127, 4 bytes
> End Of Table
> 
> I hope your patch will be included in the further kernels.

Hi,

good to know. Yes, it solved your problem because your DMI data states your "chassis type" as Notebook, and we avoid selftests on all Asus laptops. Yes, it should be merged in next week or so, as it's -next for some weeks.

Thanks for testing!

http://lkml.iu.edu/hypermail/linux/kernel/1612.2/00646.html
God, it actually got accepted. 

I wonder if there really isn't any downside.

(In reply to mirh from comment #92)
> http://lkml.iu.edu/hypermail/linux/kernel/1612.2/00646.html
> God, it actually got accepted. 
> 
> I wonder if there really isn't any downside.

So, it was on next for several months, and as Dmitry said, the selftest was needed by another devices, so they forced it to all of them some time ago.

It fixed problems on a lot of Asus laptops. What would you suggest to fix thisin another way?

Well, my rationale was more about "if in Windows this effort isn't required, then there must be something different which 70% of times means broken" (for witchcrafts I mentioned in comment 36 and 39). 

But if maintainer deemed this ok, then I'm nobody to tell otherwise. 
This should be closed -> CODE FIX.

(In reply to mirh from comment #94)
> Well, my rationale was more about "if in Windows this effort isn't required,
> then there must be something different which 70% of times means broken" (for
> witchcrafts I mentioned in comment 36 and 39). 

I really don't know how Windows handle these pieces of the protocol that should work out of the box, maybe they have patches from each vendor, or maybe they don't try to follow the specs so strict as Linux does (as this patches just avoids sending a selftest to the PS/2 controller, which is part of the protocol and should work)?

> 
> But if maintainer deemed this ok, then I'm nobody to tell otherwise. 
> This should be closed -> CODE FIX.
I'll do it so after the rc1 is launched containing this change. Thanks for your point, it also make me wonder how ti works on Windows so great and on Linux, which he have the source code to figure out the problem, it doesn't.

(In reply to Marcos Souza from comment #95)
> (In reply to mirh from comment #94)
> > Well, my rationale was more about "if in Windows this effort isn't
> required,
> > then there must be something different which 70% of times means broken"
> (for
> > witchcrafts I mentioned in comment 36 and 39). 
> 
> I really don't know how Windows handle these pieces of the protocol that
> should work out of the box, maybe they have patches from each vendor, or
> maybe they don't try to follow the specs so strict as Linux does (as this
> patches just avoids sending a selftest to the PS/2 controller, which is part
> of the protocol and should work)?

I have no idea if fresh installation of retail Windows will work out of box on random hardware, but I highly doubt it. OEMs bundle quite a few system-specific drivers on their installation media, so they have a chance of tweaking the behavior as neeed.

(In reply to Dmitry Torokhov from comment #96)
> I have no idea if fresh installation of retail Windows will work out of box
> on random hardware, but I highly doubt it. OEMs bundle quite a few
> system-specific drivers on their installation media, so they have a chance
> of tweaking the behavior as neeed.

That may be an explanation, but it's definitively not what happens in my case (don't know about this specific issue then). 

And really, it wouldn't surprise me for some of the arcane stuff I linked to be involved.

Fixed on master for all modern Asus laptops [1].

Thanks for the report!

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=77b425399f6d5f1b04c58738bc10ca6decb10c9a

Hi, 

It's 2021 now and I see this issue upon doing a suspend. I came to this page intending to use it to patch my linux (Ubuntu-bionic 18.04). I downloaded the ubuntu kernel from git: (git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git) and when I checked the file that needs to be patched I found that the patch is already there. Furthermore, the patch is so old and I keep my ubuntu updated. This leads me to think that I should already have this patch but I am still seeing the issue. Is my rationale wrong ? Should I try to apply the patch anyway ? 


 Here is some of my hardware info:

neo@neo-PC: ~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic

I: Bus=0011 Vendor=0002 Product=000e Version=0000
N: Name="ETPS/2 Elantech Touchpad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse0 event4 
B: PROP=5
B: EV=b
B: KEY=e420 10000 0 0 0 0
B: ABS=661800011000003

Handle 0x0003, DMI type 3, 25 bytes
Chassis Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Type: Notebook
        Lock: Not Present
        Version: 1.0       
        Serial Number: FAN0CX42642344D     
        Asset Tag: ATN12345678901234567
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: None
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: 1
        Contained Elements: 1
                <OUT OF SPEC> (0)
        SKU Number: To be filled by O.E.M.

01/Apr/2022
The same issue with kernel 5.18.0

Distributor ID: Neon
Description:    KDE neon User - 5.24
Release:        20.04
Codename:       focal


I: Bus=0018 Vendor=04f3 Product=309a Version=0100
N: Name="ELAN2204:00 04F3:309A Mouse"
P: Phys=i2c-ELAN2204:00
S: Sysfs=/devices/platform/AMDI0010:01/i2c-1/i2c-ELAN2204:00/0018:04F3:309A.0001/input/input21
U: Uniq=
H: Handlers=mouse0 event15 
B: PROP=0
B: EV=17
B: KEY=30000 0 0 0 0
B: REL=3
B: MSC=10

I: Bus=0018 Vendor=04f3 Product=309a Version=0100
N: Name="ELAN2204:00 04F3:309A Touchpad"
P: Phys=i2c-ELAN2204:00
S: Sysfs=/devices/platform/AMDI0010:01/i2c-1/i2c-ELAN2204:00/0018:04F3:309A.0001/input/input23
U: Uniq=
H: Handlers=mouse1 event16 
B: PROP=5
B: EV=1b
B: KEY=e520 10000 0 0 0 0
B: ABS=2e0800000000003
B: MSC=20