Created attachment 186785 [details] DSDT file for HP EliteBook 9470m On my HP EliteBook 9470m, the Synaptics touchpad is detected as a Generic PS/2 Mouse. dmesg snippet: psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 This is similar to Bug 214480 about the 2570p (I no longer have that laptop), except that the 9470m detects the touchpad as a Generic PS/2 Mouse. The DSDT file is attached.
Did you try to place following line in /boot/loader.conf as Oleksandr suggested in bug 214480? hw.psm.synaptics_support="1"
(In reply to Vladimir Kondratyev from comment #1) I did do this. It still detects as a PS/2 Mouse. Partially related, but one thing that the HP EliteBook does is that they consolidate the pointing stick and the trackpad as one device. This seems to also happens with the EliteBook 840 G2 (https://wiki.freebsd.org/Laptops/HP_EliteBook_840_G2), with the 840 being tested by someone else. The trackpad on my 9470m works with Windows and Linux, so looking at how Linux manages the EliteBook's trackpad is probably a good idea.
(In reply to Neel Chauhan from comment #2) Could you place following lines to /boot/loader.conf and than post psm-related part of boot log here? ------CUT------- hw.psm.synaptics_support=1 hw.psm.elantech_support=1 hw.psm.trackpoint_support=1 debug.psm.loglevel=5 ------CUT------- P.S. You can obtain boot log with dmesg command or in /var/log/messages file right after boot
Created attachment 187151 [details] psm snippet from 9470m dmesg Since the psm snippets are quite long, I have included it in a file.
(In reply to Neel Chauhan from comment #4) Seems that your touchpad does not return proper answer on synaptics magic knock psm: SET_SCALING11 return code:00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 46 12 ---------------^^ 47 is correct answer, not 46 Linux also expects 47 here. Did you try run it on your laptop? What type of mouse/touchpad it detects?
(In reply to Vladimir Kondratyev from comment #5) The result is from the 9470m. This laptop is owned by me, and FreeBSD detects the mouse as a Generic PS/2 Mouse. A Ubuntu 17.10 LiveUSB on the same laptop detects the trackpad as a Synaptics: [ 15.077254] psmouse serio4: synaptics: queried max coordinates: x [..5660], y [..4742] [ 15.113855] psmouse serio4: synaptics: queried min coordinates: x [1282..], y [1110..] [ 15.113861] psmouse serio4: synaptics: Your touchpad (PNP: SYN019e SYN0100 SYN0002 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org. [ 15.184760] psmouse serio4: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x27c00/0x0, board id: 2251, fw id: 1241283 [ 15.229048] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input12
I have found a OS X Hackintosh driver for Synaptics. It does cover the EliteBook 8460p (although it calls it a ProBook). The link is as follows: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller
(In reply to Neel Chauhan from comment #7) There is interesting comment in your link https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller/blob/master/VoodooPS2Trackpad/VoodooPS2SynapticsTouchPad.cpp line 353 // some synaptics touchpads return 0x46 in byte2 and have a different numbering scheme // this is all experimental for those touchpads
Created attachment 187245 [details] synaptics-identify-0x46.patch Try rebuild kernel with attached patch
Created attachment 187246 [details] synaptics-identify-0x46.patch Ooops. Previous version was wrong. Updated version uploaded. It is POC, so if it would work, I would make other patch
Created attachment 187251 [details] psm snippet from 9470m dmesg (w/ synaptics-identify-0x46.patch) Unfortunately, the patch did not work. The trackpad is still detected as a Generic PS/2 Mouse and two-finger scrolling does not work. I attached psm snippets from dmesg with the patch synaptics-identify-0x46.patch.
(In reply to Neel Chauhan from comment #11) > I attached psm snippets from dmesg with the patch synaptics-identify-0x46.patch. Could you place raw (not grepped) chunk of dmesg output starting from > psm0: current command byte:0067 and finishing with > psm0: syncmask:c0, syncbits:00 lines?
Created attachment 187252 [details] dmesg log from "psm0: current command byte:0067" to "psm0: syncmask:c0, syncbits:00" I have added the bits here.
Created attachment 187253 [details] synaptics-identify-0x46.patch Patch updated
Still no luck. Synaptics not working. psm: SET_RESOLUTION (2) 00fa psm: SET_SAMPLING_RATE (100) 00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 02 64 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00
Created attachment 187255 [details] synaptics-identify-0x46.patch Arghh. There is one more occurrence of the "Magic byte" check. Patch updated.
It finally works! Thank you so much! Along with your patch, I set this in /boot/loader.conf: hw.psm.synaptics_support=1 Along with this in /etc/sysctl.conf (to get two-finger scrolling): hw.psm.synaptics.two_finger_scroll=1 And Synaptics works! And if you want a dmesg snippet: psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0
(In reply to Neel Chauhan from comment #17) > It finally works! Thank you so much! Great! it would be much harder if you would not provided link to working driver! > Along with your patch, I set this in /boot/loader.conf: > hw.psm.synaptics_support=1 > And Synaptics works! Does your guest (trackpoint) device work? On Lenovo laptops its possible to expose some extra trackpoint control sysctl after placing of following in to /boot/loader.conf: hw.psm.trackpoint_support=1 Not sure if it works for HP > And if you want a dmesg snippet: Yes, please post it here in "from 'current command' to 'psm0: syncmask'" format. It`s possible that we should not trust all data retrieved from touchpad during initialization. I`ll make final version of the patch within week or two and will post it here for testing.
Created attachment 187284 [details] Full dmesg snippet with working patch The trackpoint acts more like a scrolling tool than a mouse on the 9470m with the patch. I also attached the dmesg snippet with the parts you requested.
Created attachment 187503 [details] Image of kernel panic with psm patch I occasionally get this kernel panic (the one in the image attached). It happened only two times to me.
If you install gdb from ports, then: gdbX, where X is the number typically 801 or something. Then enter the following inside gdb: file /boot/kernel/kernel info line *(void *)(psmintr+0x163) It should print the code line which caused the panic.
(In reply to Hans Petter Selasky from comment #21) Thank you so much. The output is: (gdb) info line *(void *)(psmintr+0x163) Line 2954 of "/usr/src/sys/dev/atkbdc/psm.c" starts at address 0xffffffff80f3aad2 <psmintr+338> and ends at 0xffffffff80f3aae7 <psmintr+359>. (gdb)
(In reply to Neel Chauhan from comment #22) Hi, Neal. Please: If you have a kernel dump, load it in gdb (https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html): # cd /usr/obj/usr/src/sys/<YOUR KERNCONF> # kgdb kernel.debug /var/crash/vmcore.<YOUR KERNELDUMP NUMBER> <YOUR KERNELDUMP NUMBER> is printed on first boot after panic. than make stack backtrace (kgdb) bt #0 __curthread () at ./machine/pcpu.h:225 #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xc057940e in db_dump (dummy=-1060412150, dummy2=<error reading variable: access outside bounds of object referenced via synthetic pointer>, dummy3=-1, dummy4=0xee9cb90c "") at /usr/src/sys/ddb/db_command.c:572 #3 0xc05791e1 in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=<optimized out>) at /usr/src/sys/ddb/db_command.c:479 #4 0xc0578f40 in db_command_loop () at /usr/src/sys/ddb/db_command.c:532 #5 0xc057bfea in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:248 #6 0xc0cb6cbe in kdb_trap (type=<optimized out>, code=<optimized out>, tf=0xee9cbb7c) at /usr/src/sys/kern/subr_kdb.c:654 #7 0xc12282cd in trap (frame=<optimized out>) at /usr/src/sys/i386/i386/trap.c:680 #8 <signal handler called> #9 kdb_enter (why=0xc162ab65 "panic", msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:444 #10 0xc0c709b0 in vpanic (fmt=<optimized out>, ap=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:772 #11 0xc0c709eb in panic (fmt=0xc1628b04 "1") at /usr/src/sys/kern/kern_shutdown.c:710 #12 0xc112dbb9 in psmintr (arg=0xc7c0e000) at /usr/src/sys/dev/atkbdc/psm.c:2954 #13 0xc0c31bbe in intr_event_execute_handlers (p=0xee9cbcac, ie=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1336 #14 0xc0c321d0 in ithread_execute_handlers (ie=<optimized out>, p=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1349 #15 ithread_loop (arg=0xc6ef1ef0) at /usr/src/sys/kern/kern_intr.c:1430 #16 0xc0c2edfe in fork_exit (callout=0xc0c32130 <ithread_loop>, arg=<optimized out>, frame=<optimized out>) at /usr/src/sys/kern/kern_fork.c:1044 #17 <signal handler called> Than find a frame with psmintr(). It looks like #12 0xc112dbb9 in psmintr (arg=0xc7c0e000) at /usr/src/sys/dev/atkbdc/psm.c:2954 Take first column value and place it after frame command: (kgdb) frame 12 2954 pb->ipacket[pb->inputbytes++] = c; Than list adjacent sources line to ensure that we are debugging the same files (kgdb) list 2949 } 2950 sc->inputtimeout.tv_sec = PSM_INPUT_TIMEOUT / 1000000; 2951 sc->inputtimeout.tv_usec = PSM_INPUT_TIMEOUT % 1000000; 2952 timevaladd(&sc->inputtimeout, &now); 2953 2954 pb->ipacket[pb->inputbytes++] = c; 2955 2956 if (sc->mode.level == PSM_LEVEL_NATIVE) { 2957 VLOG(4, (LOG_DEBUG, "psmintr: %02x\n", pb->ipacket[0])); And than, please, post sc->pqueue.inputbytes values here (kgdb) p sc->pqueue.inputbytes $4 = 0
(In reply to Vladimir Kondratyev from comment #23) Unfortunately, I don't have a kernel dump as of this crash, but if I crash again and have one, I will submit it.
(In reply to Neel Chauhan from comment #24) After some digging around faulty line of code I found one bug in synaptics driver error handling code and was able to simulate very similar kernel panic after it has been exploited. I`m not sure that it is your case. Try new patch. It does not include previous one, so apply both.
Created attachment 187547 [details] fix-for-panic-following-soon-after-synaptics-driver-rejected-mouse-packet.patch
(In reply to Vladimir Kondratyev from comment #26) Thank you so much for your patch. Also, how would I simulate the action which would cause the kernel panic without the patch?
(In reply to Neel Chauhan from comment #27) > Also, how would I simulate the action which would cause the kernel panic without the patch? Just use it as before for some time and report if your kernel panicing or not here. This patch fixes panic caused by processing of unknown format PS\2 packets by kernel driver. As my hardware was not able to send such a packets, I had to simulate them. There is some probability that your unusual hardware sends some data in unexpected format so in this case the patch would fix the panic for you.
I can also confirm that this bug does not exist on the HP EliteBook 1040 G1 as the 1040 lacks a trackpoint (but has another problem with Synaptics two finger scrolling). I will still test any new patches on the 9470m as they come out.
(In reply to Neel Chauhan from comment #29) > I can also confirm that this bug does not exist on the HP EliteBook 1040 G1 as the 1040 lacks a trackpoint Which bug? Undetectable trackpad? Or kernel panic? > (but has another problem with Synaptics two finger scrolling). Does "HP EliteBook 1040 G1" have so called "forcepad" (Forcepad has no buttons at all, nor separate buttons below, nor common button under surface)? If so, place output of 'devinfo -rv | grep psmcpnp0' command here. It does not seem to be a hard work to port Linux forcepad support bits to FreeBSD > I will still test any new patches on the 9470m as they come out. Unfortunately, patches I published before appeared to be only workaround not a solution, so I would prefer investigate this problem after kernel panic and forcepad? issues get resolved. Could you provide root access to your HP 9470m to me to make some experiments?
(In reply to Vladimir Kondratyev from comment #30) The 1040 G1 has a ForcePad, but is detected as a Synaptics without any patch, but lacks a pointing stick. I have a separate bug report for the 1040: Bug 223369. The 9470m does not have a ForcePad, instead it has a traditional touchpad with two physical buttons on the bottom, along with a pointing stick and two additional buttons for it (like the ThinkPad X220/T420). This bug report (Bug 222667) is for EliteBooks which don't report Synaptics out of the box like the 9470m (usually because of a pointing stick). About root access, I can give it, but you will need to contact me via email so I can do this (I don't want to give a password to the open Internet)
(In reply to Neel Chauhan from comment #31) Also, I forgot to mention that this laptop won't be available at all times because it is being shared with someone else (who uses Windows), and I will remove any tools relating to partitioning (e.g. gpart, zpool, etc.) so you don't accidentally remove any partitions.
Created attachment 187790 [details] move-synaptics-init-to-front.patch (In reply to Neel Chauhan from comment #32) > Also, I forgot to mention that this laptop won't be available at all times because it is being shared with someone else (who uses Windows), Ouch. I do not want to interfere with someone. > and I will remove any tools relating to partitioning (e.g. gpart, zpool, etc.) so you don't accidentally remove any partitions. You should remove all /dev/ada* device nodes to block unauthorized access to disk :-) So, lets start. I attached a patch which does 3 things: 1. Move synaptics touchpad initialization to front of other drivers. 2. Send "Set defaults" PS/2 mouse command. 3. Send "Reset" PS/2 mouse command. p 2 and 3 are commented out. To check if your hardware detected properly find "Synaptics Touchpad v2.0" line in dmesg output. It should change to something like "Synaptics Touchpad v8.1" on success. There is no need to revert previous patches. Start with patch as is. Than on success (v8.1) move touchpad initialization to it common place step by step (in between A4 Tech 4D+ Mouse and Elantech touchpad) in steps of 1 record (2 lines) to find exact probe which broke your touchpad. On failure (v2.0) try uncomment mouse commands in different combinations. If you succeed post dmesg and what you did here. Dmesg's psm part should be very similar to 1040.
You can add following lines to /etc/make.conf to speedup kernel recompilation process: NO_KERNELCLEAN=yes NO_KERNELCONFIG=yes NO_KERNELDEPEND=yes NO_KERNELOBJ=yes
By Saturday morning (Eastern time), this laptop is going to be available via SSH for your testing. I will email you the login details. It will be available for this whole weekend. Also, the person who was going to get my 9470m doesn't want it, so I don't need to do any security.
(In reply to Neel Chauhan from comment #35) > It will be available for this whole weekend. OK. Thanks! Could you install editors/joe to your laptop as well?
Created attachment 188126 [details] synaptics-identify-0x46.patch Add a kludge to switch "HP EliteBook 9470m" touchpad to multitouch mode if that particular model has been detected by controller's PnP Id To check if the kludge is working just do multi-finger gesture like "2-finger scroll" and look in to /var/log/messages, you'll see lines starting with "smoother1". Following is a sample of /var/log/messages contents after "two-finger scroll" has been done: Nov 12 13:23:27 hp kernel: psmintr: 84 23 b3 e0 78 11 Nov 12 13:23:27 hp kernel: psmintr: 80 fb 42 c0 bd 41 Nov 12 13:23:27 hp kernel: synaptics: ipacket: [3005, 3905], 66, 0 Nov 12 13:23:27 hp kernel: smoother0: ipacket: [3005, 3905], 66, 0 Nov 12 13:23:27 hp kernel: smoother0: cursor[7]: x=3005, y=3905, dx=-58, dy=-139 Nov 12 13:23:27 hp kernel: smoother1: ipacket: [4166, 3942], 66, 1 Nov 12 13:23:27 hp kernel: smoother1: cursor[8]: x=4166, y=3942, dx=-10, dy=-132
(In reply to Vladimir Kondratyev from comment #37) Hi, Neal Could your check multitouch feature of "HP EliteBook 9470m" touchpad as described in message before? The patch is already applied to its kernel.
Multitouch gestures do work on the 9470m.
Keep in mind that I sold my 9470m. I still have my 1040.
If you are looking for another tester (for EliteBooks with pointing sticks), you don't need to look for the 9470m explicitly. Any EliteBook not in the 1000 series or the Revolve 810 can be used in place of the 9470m. Other models such as the 8470p, 2570p, and 840 probably has this issue also. I'm saying 'probably' because I don't have access to other EliteBooks as I'm not an IT professional, my college internship is not in IT, and where I work, it's not at all a HP shop. Keep in mind that the issue with the 9470m was also on the 2570p which I gave away as well, and I can continue to test for the 1040 G1 as long as I have this laptop.
(In reply to Neel Chauhan from comment #41) > If you are looking for another tester I do not think that extra testing is required to commit that patch as it does not add any new features. It just replaces synaptics capability checks with conservative defaults. It is not committed yet as I was taking long trip on vacations and had no access to my desktop. Thanks for reminder. I`ll commit the patch soon.
A commit references this bug: Author: wulf Date: Wed Jan 31 22:17:53 UTC 2018 New revision: 328640 URL: https://svnweb.freebsd.org/changeset/base/328640 Log: psm: Add a kludge to support 0x46 identity middle byte Synaptics touchpads Most synaptics touchpads return 0x47 in middle byte in responce to identify command as stated in p.4.4 of "Synaptics PS/2 TouchPad Interfacing Guide". But some devices e.g. found on HP EliteBook 9470m return 0x46 here. Allow them to be identified as Synaptics as well as 0x47. ExtendedQueries return incorrect data on such a touchpads so we ignore their result and set conservative defaults. PR: 222667 Reported by: Neel Chauhan <neel@neelc.org> Tested by: Neel Chauhan <neel@neelc.org> Approved by: gonzo Changes: head/sys/dev/atkbdc/psm.c
A commit references this bug: Author: wulf Date: Sun Feb 4 23:01:48 UTC 2018 New revision: 328864 URL: https://svnweb.freebsd.org/changeset/base/328864 Log: psm(4): Fix panic occuring soon after PS/2 packet has been rejected by synaptics or elantech sanity checker. After packet has been rejected contents of packet buffer is not cleared with setting of inputbytes counter to 0. So when this packet buffer is filled again being an element of circular queue, new data appends to old data rather than overwrites it. This leads to packet buffer overflow after 10 rounds. Fix it with setting of packet's inputbytes counter to 0 after rejection. While here add extra logging of rejected packets. PR: 222667 (for reference) Reported by: Neel Chauhan <neel@neelc.org> Tested by: Neel Chauhan <neel@neelc.org> MFC after: 1 week Changes: head/sys/dev/atkbdc/psm.c
A commit references this bug: Author: wulf Date: Sun Feb 18 22:04:42 UTC 2018 New revision: 329532 URL: https://svnweb.freebsd.org/changeset/base/329532 Log: MFC r328864: psm(4): Fix panic occuring soon after PS/2 packet has been rejected by synaptics or elantech sanity checker. After packet has been rejected contents of packet buffer is not cleared with setting of inputbytes counter to 0. So when this packet buffer is filled again being an element of circular queue, new data appends to old data rather than overwrites it. This leads to packet buffer overflow after 10 rounds. Fix it with setting of packet's inputbytes counter to 0 after rejection. While here add extra logging of rejected packets. PR: 222667 (for reference) Reported by: Neel Chauhan <neel@neelc.org> Tested by: Neel Chauhan <neel@neelc.org> Changes: _U stable/11/ stable/11/sys/dev/atkbdc/psm.c
A commit references this bug: Author: wulf Date: Sun Feb 18 22:12:21 UTC 2018 New revision: 329533 URL: https://svnweb.freebsd.org/changeset/base/329533 Log: MFC r328864 (Synaptics part only): psm(4): Fix panic occuring soon after PS/2 packet has been rejected by synaptics sanity checker. After packet has been rejected contents of packet buffer is not cleared with setting of inputbytes counter to 0. So when this packet buffer is filled again being an element of circular queue, new data appends to old data rather than overwrites it. This leads to packet buffer overflow after 10 rounds. Fix it with setting of packet's inputbytes counter to 0 after rejection. While here add extra logging of rejected packets. PR: 222667 (for reference) Reported by: Neel Chauhan <neel@neelc.org> Tested by: Neel Chauhan <neel@neelc.org> Changes: _U stable/10/ stable/10/sys/dev/atkbdc/psm.c
A commit references this bug: Author: eadler Date: Mon Mar 19 03:49:55 UTC 2018 New revision: 331172 URL: https://svnweb.freebsd.org/changeset/base/331172 Log: MFC r328640: psm: Add a kludge to support 0x46 identity middle byte Synaptics touchpads Most synaptics touchpads return 0x47 in middle byte in responce to identify command as stated in p.4.4 of "Synaptics PS/2 TouchPad Interfacing Guide". But some devices e.g. found on HP EliteBook 9470m return 0x46 here. Allow them to be identified as Synaptics as well as 0x47. ExtendedQueries return incorrect data on such a touchpads so we ignore their result and set conservative defaults. PR: 222667 Changes: _U stable/11/ stable/11/sys/dev/atkbdc/psm.c