On 06/11/2016 09:15 PM, Cameron Gutman wrote:
Sorry, I misremembered what I thought I read in your email - you said you didn't see a call to ml_ff_destroy()
in the disconnect case.
I also don't see this call with the xpad driver!
Though that is quite strange to me, as the comments on ff_device indicate that it should be the right spot:
483 * @destroy: called by input core when parent input device is being
484 * destroyed
What does "input device is being destroyed" actually mean in this case?
I tried with the xpad driver and as long as fftest is running (it will
keep running until it detects that the device has been disconnected)
there is no ml_ff_destroy event. So, if I want, there can be hours
between actual USB disconnect and ml_ff_destroy.
So what does it mean to the kernel that fftest is keeping an open file
handle to this input device? Is it really gone if there is at least one
process still holding a reference to it?
And. It actually seems possible to trigger the bug with the xpad driver.
I didn't have the crash, but there is a good chance to get it. This is
what I managed to get:
[ 267.006873] ml_effect_timer start
[ 267.256399] ml_effect_timer end
[ 268.286814] xpad 1-2:1.0: xpad_try_sending_next_out_packet -
usb_submit_urb failed with result -19
[ 268.331112] xpad 1-2:1.0: xpad_try_sending_next_out_packet -
usb_submit_urb failed with result -19
[ 268.384689] xpad 1-2:1.0: xpad_try_sending_next_out_packet -
usb_submit_urb failed with result -19
[ 268.452146] xpad 1-2:1.0: xpad_try_sending_next_out_packet -
usb_submit_urb failed with result -19
[ 273.813537] ml_effect_timer start
[ 273.816845] usb ȵ�<: xpad_try_sending_next_out_packet -
usb_submit_urb failed with result -19
[ 274.400668] ml_effect_timer end
Starting with 268.286814 the USB device is gone! That's why the xpad
driver is throwing errors.
Some time later at 273.813537 (USB device is gone!) there is a new call
to the timer callback. "Unfortunately" no crash.
I want to be sure we're on the right track though. Can you please resolve the address in the RIP register to a
line number in hid-sony.c?
Can you point me to some instructions on how to do this? The only way to
debug things, I currently know, is the "good old print(f/k)" debugging...
Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
