https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240339
--- Comment #9 from Greg V <greg@unrelenting.technology> --- (In reply to Vladimir Kondratyev from comment #7) oh cool, you already wrote the ACPI lookup of parameters, I was thinking about doing that haha. Though the values that it ends up applying seem really high (564, 480 on i2c2 for SCL). I commented that out again Unfortunately the problem is still there. Some more testing: - after the lockup in FreeBSD, Linux cannot recover that i2c bus either — rebooting (not shutting down and powering up) into Chrome OS results in 'i2c_designware.2: controller timed out' and the touchpad not working; - the EC interface on the same bus allows reading the console of the touchpad's firmware, but that's impossible when the controller is locked up.. I'm waiting for a debug cable to ship, but the documentation doesn't say that it's possible to access the touchpad console through that; - I added some logging to the error handling, on i2c0 (working touchscreen) after reading the touchscreen's descriptor for setup there's an RX underflow, but here (touchpad) that did not happen, none of these errors happened; - with HAVE_IG4_POLLING in iichid, there's no RX underflow there (obviously), but it does not fix the lockup. I wonder if it might actually be iichid/imt doing something that causes the touchpad to do something wrong with the bus… log: https://gist.github.com/myfreeweb/67b3ca690c22b31f502079b11263f0f4 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
