search

sebanc / brunch

Boot ChromeOS on x86_64 PC - Supports Intel CPU/GPU from 8th gen or AMD Ryzen
GNU General Public License v3.0
3.7k stars 393 forks source link

Old ipts driver sometimes stop working after recovering from suspend #814

Open ZZZXXX0110 opened 3 years ago

ZZZXXX0110 commented 3 years ago

My device is Surface Pro 6, lastest version Chrome OS rammus 87 and Brunch r87 stable 20201227, running kernel 4.19 due to the new ipts driver being buggy.

Sometimes after recovering from suspend (S3 enabled via kernel option) the touchscreen would stop working, dmesg shows as follows:

[86849.358109] [drm:intel_ipts_map_buffer [i915]] *ERROR* intel_ipts: Failed attaching GEM object : -12
[86849.358129] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: error read_res_list
[86849.358672] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: do_setup_kernel error : -12
[86849.358729] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: cannot allocate raw data resource
[86849.358749] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: cannot allocate default resource
[86849.358753] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: error in handling resp msg

I tried "sudo modprobe -r intel_ipts" then "sudo modprobe intel_ipts", but the touchscreen still doesn't work and dmesg gives exactly same error message:

[87252.548730] [drm:intel_ipts_map_buffer [i915]] *ERROR* intel_ipts: Failed attaching GEM object : -12
[87252.548841] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: error read_res_list
[87252.550572] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: do_setup_kernel error : -12
[87252.550668] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: cannot allocate raw data resource
[87252.550697] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: cannot allocate default resource
[87252.550702] intel_ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: error in handling resp msg

The only way to get touchscreen back to work seems to be a full reboot.

sebanc commented 3 years ago

"suspend_s3" option is not valid for Surface devices (other than Surface Go), could you try to remove it ?

ZZZXXX0110 commented 3 years ago

I see, that option did seem to work though other than occasionally breaking ipts drivers upon recovering, and seems to give significant battery saving while the device is suspended. What exactly makes it "not valid" on Surface devices other than Surface Go? I remember in old versions of Jakeday's kernel patch there was a systemd script needed to reset wifi devices upon recovering from suspend, but I only wifi problem once here in Brunch which was fixed by resetting the wifi module with modprobe. Is there any other problem with suspend to s3 at the moment?

I removed that option anyway, I will let you know if this problem with ipts driver happens again now without the s3 option.

ZZZXXX0110 commented 3 years ago

Update: The same problem happened too without s3 option, with exactly the same dmesg error messages.

sebanc commented 3 years ago

Unless I am mistaken, S3 suspend has not been implemented by MS on Surface devices other than Surface Go.

Could you try a clean install of the latest brunch (I have no other report of resume issues with the ipts driver) ?

ZZZXXX0110 commented 3 years ago

Sorry for the late reply. Unfortunately my Surface Pro 6 died, the SSD completely failed and it is out of warranty, so I bought a SP7 with Iris GPU so I can't use 4.19 kernel on it anymore. Perhaps you should close this issue.