[ T70 Bug Report ] : TrackPoint 睡眠唤醒后失效( 171212 BIOS 已经修正，关闭)
本帖最后由 zassion 于 2017-12-14 16:57 编辑BIOS版本：
5.12 10/17/2017 11:40:08
OS：
openSUSE 42.3 / Win10 双系统
出现概率：
100%
再现方式：
Win10 或者 Linux 正常使用， TrackPoint 在好用的情况下， 盖上盖子，进行睡眠（ suspend in ram )。
打开盖子，系统唤醒以后， TrackPoint 失效。
失效的时候， linux内核驱动会出现如下LOG：
serio serio2: device_attach() failed for isa0060/serio2 (i8042 AUX1 port), error: -517
当 Tracepoint 失效以后， 热重启电脑， TrackPoint 依然无效。
如果关机再启动，则可以复归。
请 BIOS 开发人员确认 i8042 配置是否正确。
sleep睡眠
hibernate才是休眠。suspend应该是相当于sleep，不是休眠吧？
你说的系统是win10还是Linux？还是两个系统都失效？但是我实测win10是不会失效的。
Hi Hope,
由于我的主系统是Linux，所以是首先在 Linux 失效以后，再重启PC。 无论是重启到 Win10 还是重启到 Linux ， 在不关机的情况下， 重启了多次（ 不同的系统），都是无效的。 我看到的复归条件是关机。
我对那个名词不是很清晰， 一般把 hibernate 叫做 suspend in disk ， 把 sleep 叫做 suspend in ram。
我去确认一下 win10 下合盖子 是否会出现。 一会回复。
Hi Hope，
刚才确认了一下， 关机，启动到 Win10；合上盖子等一小会（一两分钟），开盖， BUG再现。 热重启到Linux， 不复归。
所以应该是和 OS没关。 我猜是不是 PS2 被禁用了， 唤醒的时候没有 重新启用。 zassion 发表于 2017-11-5 21:36
Hi Hope，
刚才确认了一下， 关机，启动到 Win10；合上盖子等一小会（一两分钟），开盖， BUG再现。 ...
我觉得可以检查一下你的机器的问题了。
我测试了几台T70，以及别的很多网友，在Win10睡眠、恢复都是指点杆正常的。 还有，指点杆的英文是TrackPoint。 HOPE 发表于 2017-11-5 21:44
还有，指点杆的英文是TrackPoint。
谢谢指正，修改了。 HOPE 发表于 2017-11-5 21:43
我觉得可以检查一下你的机器的问题了。
我测试了几台T70，以及别的很多网友，在Win10睡眠、恢复都是指点 ...
麻烦请确认一下BIOS的版本 是不是和我这台一致的？ 如果是BIOS的问题我可以再试一试好用的版本是不是解决了这个问题。谢谢。 刚才又特地确认了一下Win10， 还是100%再现的。 zassion 发表于 2017-11-5 22:36
麻烦请确认一下BIOS的版本 是不是和我这台一致的？ 如果是BIOS的问题我可以再试一试好用的版本是不是解决 ...
1017就是专门解决待机之后恢复丢指点杆的问题的。 HOPE 发表于 2017-11-5 23:00
1017就是专门解决待机之后恢复丢指点杆的问题的。
我这台的确是1017的版本， 但是是在我拿到的时候，阿琪就已经帮忙更新的，我不确定《2017.10.17 T70更新BIOS》 这个帖子里面的一些步骤是否有进行，但我认为应该没有关系，因为我主要是用Linux，几乎不进Windows。 我会试一试调试一下Linux内核i8042部分的驱动，看看resume的时候为啥TrackPoint不好用了，但这个可能也只能到i8042协议部分。 你那边是否可以共享 BIOS 中关于PS/2 部分的源代码，如果可以的话也能对照着看一下。 HOPE 发表于 2017-11-5 23:00
1017就是专门解决待机之后恢复丢指点杆的问题的。
HOPE你好，最近概要看了一下linux下的i8042驱动，将其操作i8042寄存器之间的通信debug打开以后，发现一点可能存在问题的地方。 由于添加了 nopnp 参数，相当于由驱动自己去探测设备是否存在。驱动代码中，在进入睡眠的时候将AUX PORT 关闭了; 在退出睡眠的时候启用了AUX PORT。 但从debug信息来看，发送给鼠标的那个PORT没有外设反馈，timeout了。 我理解是外部设备未能正常启动起来， 这可能也解释了为什么reboot到window下，TrackPoint仍然不好用。 从另外一个层面上来猜测的话，可能是驱动逻辑是对的，但是由于某些原因未能在唤醒的时候，重新使能TrackPoint。接下来还需要再确认一下相关command发送是否正确。
2 - 5 就是 AUX PORT0 - 3
i8042: MUX error, status is 35, data is fe
i8042: fe <- i8042 (interrupt, 2, 12, timeout)
i8042: 90 -> i8042 (command)
i8042: ed -> i8042 (parameter)
i8042: MUX error, status is 35, data is fe
i8042: fe <- i8042 (interrupt, 2, 12, timeout)
i8042: 90 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is 35, data is fe
i8042: fe <- i8042 (interrupt, 2, 12, timeout)
i8042: 91 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is 75, data is fe
i8042: fe <- i8042 (interrupt, 3, 12, timeout)
i8042: 91 -> i8042 (command)
i8042: ed -> i8042 (parameter)
i8042: MUX error, status is 75, data is fe
i8042: fe <- i8042 (interrupt, 3, 12, timeout)
i8042: 91 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is 75, data is fe
i8042: fe <- i8042 (interrupt, 3, 12, timeout)
i8042: 92 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is b5, data is fe
i8042: fe <- i8042 (interrupt, 4, 12, timeout)
i8042: 92 -> i8042 (command)
i8042: ed -> i8042 (parameter)
i8042: MUX error, status is b5, data is fe
i8042: fe <- i8042 (interrupt, 4, 12, timeout)
i8042: 92 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is b5, data is fe
i8042: fe <- i8042 (interrupt, 4, 12, timeout)
i8042: 93 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is f5, data is fe
i8042: fe <- i8042 (interrupt, 5, 12, timeout)
i8042: 93 -> i8042 (command)
i8042: ed -> i8042 (parameter)
i8042: MUX error, status is f5, data is fe
i8042: fe <- i8042 (interrupt, 5, 12, timeout)
i8042: 93 -> i8042 (command)
i8042: f2 -> i8042 (parameter)
i8042: MUX error, status is f5, data is fe
i8042: fe <- i8042 (interrupt, 5, 12, timeout)
刚开机的时候是这样的：
[ 2.236555] i8042: MUX error, status is 35, data is fe
[ 2.236556] i8042: fe <- i8042 (interrupt, 2, 12, timeout)
[ 2.236567] i8042: 90 -> i8042 (command)
[ 2.236633] i8042: ed -> i8042 (parameter)
[ 2.236833] i8042: MUX error, status is 35, data is fe
[ 2.236833] i8042: fe <- i8042 (interrupt, 2, 12, timeout)
[ 2.236910] i8042: 91 -> i8042 (command)
[ 2.236980] i8042: f2 -> i8042 (parameter)
[ 2.241653] i8042: fa <- i8042 (interrupt, 3, 12)
[ 2.242737] i8042: 00 <- i8042 (interrupt, 3, 12)
[ 2.242827] i8042: 92 -> i8042 (command)
[ 2.242897] i8042: f2 -> i8042 (parameter)
[ 2.243103] i8042: MUX error, status is b5, data is fe
[ 2.243104] i8042: fe <- i8042 (interrupt, 4, 12, timeout)
[ 2.243156] i8042: 92 -> i8042 (command)
[ 2.243330] i8042: ed -> i8042 (parameter)
[ 2.243579] i8042: MUX error, status is b5, data is fe
[ 2.243580] i8042: fe <- i8042 (interrupt, 4, 12, timeout)
[ 2.243657] i8042: 93 -> i8042 (command)
[ 2.243727] i8042: f2 -> i8042 (parameter)
[ 2.243872] i8042: MUX error, status is f5, data is fe
[ 2.243873] i8042: fe <- i8042 (interrupt, 5, 12, timeout)
[ 2.243915] i8042: 93 -> i8042 (command)
[ 2.243980] i8042: ed -> i8042 (parameter)
[ 2.244185] i8042: MUX error, status is f5, data is fe
[ 2.244186] i8042: fe <- i8042 (interrupt, 5, 12, timeout)
[ 2.244264] i8042: 90 -> i8042 (command)
[ 2.244334] i8042: f2 -> i8042 (parameter)
[ 2.244598] i8042: MUX error, status is 35, data is fe
[ 2.244600] i8042: fe <- i8042 (interrupt, 2, 12, timeout)
本帖最后由 pengrubin 于 2017-11-8 03:28 编辑
zassion 发表于 2017-11-8 00:32
HOPE你好，最近概要看了一下linux下的i8042驱动，将其操作i8042寄存器之间的通信debug打开以后，发现一点 ...
可能是没有重新进行上电复位了。
在不能用的情况下手动把A点与5V碰下看看，1S时间就够了。这样是手动复位.
还有个测试办法。
在红点不能用的情况下把键盘插头拔了后重新插上如果正常了的话也同样可以判定为重新复位电路有问题。 本帖最后由 zassion 于 2017-11-8 18:38 编辑
zassion 发表于 2017-11-5 23:10
我这台的确是1017的版本， 但是是在我拿到的时候，阿琪就已经帮忙更新的，我不确定《2017.10.17 T70更新B ...
HOPE你好，
今天刷了一下0904的版本，发现第一次开机的时候， TrackPoint 的检测是正常的。 睡眠唤醒以后，虽然有合盖/开盖直接关机的BUG，但唤醒以后TrackPoint动作是正常的。 是否可以提供一个基于1017版本+0904输入配置的 BIOS ？ 谢谢。（在0904上linux的声音驱动不对，所以还得是1017以后的版本好用。）
另外一点信息请参考， 我的X200没有touchpanel，TrackPoint接续在i8042的aux0上。T70的TrackPoint无论是0904版本，还是1017版本，显示都是接续在aux1口上，一共4个aux口。T70的touchpad在我的T70上没有进行硬件接续，我不确定它是接续在哪个aux口上。 在window驱动中，有没有可能touchpad和TrackPoint有冲突，当然这只是猜想。 pengrubin 发表于 2017-11-8 03:39
还有个测试办法。
在红点不能用的情况下把键盘插头拔了后重新插上如果正常了的话也同样可以判定为重新复位 ...
pengrubin，谢谢你的建议，我没有硬件工具。但我把BIOS变更为0904版本，TrackPoint就完全好用了。已经将这个现象反馈给HOPE。 都是强烈要求0904版本上加合盖，Hope也没动作啊。没盒盖真的很蛋疼。 更新一下， 0904的 BIOS， 唤醒以后 TrackPoint 也有失效的情况， 目前是这么一个规律：
在 0904版本上，进入休眠， 可以看到屏幕掉电有像一个闭合的波纹逐渐由四周汇聚到中间，最后消失。 在最后消失前唤醒的话，TrackPoint可用， 之后就不能用了。
而 1017 版本， 怎么样都不好用。
有明白的人分析一下么？ 我是有了料机还在没买主板。说实话料机用着就比其他笔记本舒服。想问一下用win7 休眠、睡眠、电源按钮休眠，会有这个问题吗。这个问题是偶发的，还是通病？ glzhaoyi 发表于 2017-11-10 11:18
我是有了料机还在没买主板。说实话料机用着就比其他笔记本舒服。想问一下用win7 休眠、睡眠、电源按钮休眠 ...
我主要是用linux系统， 没怎么去win10下确认。休眠以后TrackPoint不好用的这个问题在我的机器上，无论是window还是里怒下，都是100%再现的。 我不确定别人是否也这样。仅供参考。 本帖最后由 tearme 于 2017-11-12 18:36 编辑
哎，掉键盘都成常态了
@HOPE, 对比了一下Linux下，suspend in ram -> [马上resume]和 [等一会resume],在之前帖子里面提到的波纹消失之前和之后， i8042 的交互信息。 如果等了一会，发送给 Trackpoint 的 cmd 就没有反馈了。 我的猜想是，水波纹可能是电容放电，水波纹消失就代表着整个主板侧底没有供电了。在供电消失之前 resume， trackpoint 的驱动能够正常处理， 之后就够呛了。 关于 trackpooint 和 i8042 这个部分， 硬件上能否提供一些信息， 比如 reset 是如何控制的？ 电源是如何控制的？
zassion 发表于 2017-11-11 14:57
@HOPE, 对比了一下Linux下，suspend in ram -> [马上resume]和 [等一会resume],在之前帖子里面提到的波 ...
请查收PM。 HOPE 发表于 2017-12-9 16:10
请查收PM。
linux 内核中的 u8042 驱动已经内置了 debug 功能，但是默认关闭的，打开就可以。 方法如下：
1传递 kernel-parameter 给到 i8042 驱动程序。
1.1 写死在 grub 的菜单中， /boot/grub2/grub.cfg 中， 找到默认启动的那个，在 linux 后面那一行追加 i8042.debug=1 。 比如这个样子
1.2 不写死， 只是在重启的时候， grub timeout 自动启动之前， 按 TAB 或者 e 键 打断 timeout 过程， 自己临时修改一下 启动参数， 也是一样，追加 i8042.debug=1 。 然后按CTRL + x 直接启动修改后的。
2重启系统
2.1 确认 刚才的修改是否成功
可以通过执行 dmesg 查看 内核 log， dmesg | more是分页查看， 看看内核启动参数中 是不是有刚才添加的 i8042.debug=1 。 比如[ [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.14.0-default root=UUID=ffbc15bd-7358-48be-98ad-bed63db79cec resume=/dev/disk/by-uuid/cb1b5b16-06b5-4988-8837-c5ff7607f
ccd splash=silent quiet showopts i8042.debug=1]
3.如果已经传递参数给了内核的话， 那么 i8042 的 debug log 已经输出给 kernel 的 ring buffer 了， 这时候只需要查看就可以。 查看的 方法就是 dmesg。如果只想查看 i8042 的消息，可以通过 grep 进行过滤。比如dmesg -w | grep 8042
dmesg -w 表示 ring buffer 的内容显示完成后，不要退出， 继续等待。 没有 -w 的话， 程序就退出了， 需要再次输入。
页:
[1]