On Tue, Mar 16, 2021 at 08:46:27PM +0000, Edd Barrett wrote: > Hi, > > If I unplug the following device, the kernel crashes every time: > ``` > uhidev5 at uhub0 port 1 configuration 1 interface 0 "HAILUCK CO.,LTD Usb > Touch" rev 1.10/1.00 addr 7 > uhidev5: iclass 3/1 > ukbd3 at uhidev5: 8 variable keys, 6 key codes > wskbd4 at ukbd3 mux 1 > wskbd4: connecting to wsdisplay0 > uhidev6 at uhub0 port 1 configuration 1 interface 1 "HAILUCK CO.,LTD Usb > Touch" rev 1.10/1.00 addr 7 > uhidev6: iclass 3/0, 189 report ids > umt0 at uhidev6: clickpad, 4 contacts > wsmouse1 at umt0 mux 0 > ums1 at uhidev6 reportid 1: 5 buttons, Z and W dir > wsmouse2 at ums1 mux 0 > ``` > > I'd been using this device for a week or so prior without issue, and I > did a fair amount of plugging/unplugging when I was getting the > wsconsctl settings right. I upgraded my snapshot today, so this may be > the root of the problem, but I can't be sure. My old snapshot was a week > or two old. > > I also noticed that my tapping settings stopped working with the upgrade > (wsconstctl mouse1.tp.tapping=3,1,2). That's probably another issue. > > I tried different USB ports and cables just in case, but no change. > > Photos of ddb info (sorry, no serial): > https://theunixzoo.co.uk/random/IMG_20210316_201134_HDR.jpg > https://theunixzoo.co.uk/random/IMG_20210316_201355_HDR.jpg > https://theunixzoo.co.uk/random/IMG_20210316_201418_HDR.jpg > > (I forgot to do a `ps`. I can get that if needed. The crash is easily > reproducible).
Does reverting the following commit get rid of the panic? commit f31b43ced9cf4cbf056e9d8aceb4fa40a73e00cd Author: jcs <[email protected]> Date: Mon Mar 8 14:35:57 2021 +0000 Allow uhidev child devices to claim selective report ids There may be multiple matching devices on a single uhidev device but the first device that responds to UHIDEV_CLAIM_ALLREPORTID will block the others from attaching. Change this to UHIDEV_CLAIM_MULTIPLE_REPORTID and require any devices wanting some/all report ids to fill in the claimed array in uhidev_attach_arg with just the reports it needs. uhidev can then run match routines for other drivers with the available report ids. ok anton I'm wondering if the umt device is detached more than once since it claims multiple report ids. I ran into the same problem while developing uhidpp: https://github.com/openbsd/src/blob/master/sys/dev/usb/uhidpp.c#L437-L443 Also, the output of `show registers` in ddb would be helpful.
