Non stopable vibration on various games / apps

[Erazor84]

With the 0.4 module installed (to prevent the system freeze with codemasters games on ubuntu),
i have problems in many games / programms.

If i start Saints row 4, the controller immideatly starts vibrating without stop. the only way to stop it is to uninstall 0.4 or unplug the controller.

also with the programm "dolphin emulator". every game vibrate without stop.

the "original" kernel module, that is shipped with ubuntu mate 16.04 beta, does not have this problem.

sorry for my english.

i'm using a black wired xbox 360 controller.

[paroj]

can you provide dmesg output after the the error occured?

[MattSturgeon]

I can also reproduce this on Arch.

I have tested on Saints row 4 (present), Bioshock Infinite (present), GRID Autosport (not present)

• Arch Linux 4.4.5 xpad: Issue not present

# starting SR4 without controller connected, no output

# connecting controller with SR4 running
[ 3396.967461] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.0/input/input43

# quitting SR4

# unplugging controller

• (AUR) steamos-xpad-dkms: Issue not present

# starting SR4 without controller connected

# connecting controller with SR4 already running, no issue, functions normally
[ 3035.211409] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.0/input/input40

# quitting SR4

# disconnecting controller

# reconnecting controller
[ 3175.374771] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.0/input/input41

# starting SR4 with controller connected, functions normally, no issue, no output

• (AUR) xpad-dkms-git (this): Issue present.

#Starting SR4 with controller connected, continuous vibration (controller functions normally)
[ 1941.928423] xpad 9-1:1.0: xpad_prepare_next_out_packet - found pending output packet 1

# Quitting game, vibration continues until unplugged, no output from dmesg

# unplugging controller
[ 2299.359742] xpad 9-1:1.0: xpad_irq_in - urb shutting down with status: -108
[ 2299.359773] xpad 9-1:1.0: xpad_prepare_next_out_packet - found pending output packet 2
[ 2299.359779] xpad 9-1:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19

# starting SR4 without controller inserted, no output from dmesg

# plugging controller with SR4 started
# vibrates continuously, functions normally
[ 2414.855741] xpad 8-5:1.0: xpad_prepare_next_out_packet - found pending output packet 2
[ 2414.855856] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:12.0/usb8/8-5/8-5:1.0/input/input39
[ 2414.907553] xpad 8-5:1.0: xpad_irq_in - urb shutting down with status: -2
[ 2414.927506] xpad 8-5:1.0: xpad_prepare_next_out_packet - found pending output packet 1

# vibration continues after quitting SR4, until disconnecting controller

# unplugged controller
[ 2673.511487] xpad 8-5:1.0: xpad_irq_in - nonzero urb status received: -62
[ 2673.523430] xpad 8-5:1.0: xpad_irq_in - nonzero urb status received: -62
[ 2673.530485] xpad 8-5:1.0: xpad_irq_in - urb shutting down with status: -108
[ 2673.530513] xpad 8-5:1.0: xpad_prepare_next_out_packet - found pending output packet 2
[ 2673.530518] xpad 8-5:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19

(some USB logs removed for clarity, let me know if they are actually relevant)

[MattSturgeon]

I just tested with 2fbc567 (correctly handle concurrent LED and FF requests) and the previous commit (f23507b).

It appears this bug was introduced in 2fbc567

When I build f23507b and start SR4 I no errors in dmesg. When I build 2fbc567 and start SR4 I get the constant vibration (and no dmesg errors)

---

Using 2fbc567, if I rmmod and modprobe while its vibrating, I get this output

[  407.985435] usbcore: deregistering interface driver xpad
[  407.986031] xpad 9-1:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -2
[  408.046670] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.0/input/input24
[  408.046782] usbcore: registered new interface driver xpad

Using 2fbc567, if I unplug while vibrating:

[  501.771820] usb 9-1: USB disconnect, device number 2
[  501.772078] xpad 9-1:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19

When I reconnect:

[  576.539446] usb 9-1: new full-speed USB device number 4 using ohci-pci
[  576.708295] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.0/input/input25

---

At one point (I think I was using f23507b) I managed to get this output in dmesg:

[   39.249659] ------------[ cut here ]------------
[   39.249670] WARNING: CPU: 1 PID: 1445 at drivers/usb/core/urb.c:338 usb_submit_urb+0x2ad/0x5a0 [usbcore]()
[   39.249672] URB ffff88021422be40 submitted while active
[   39.249673] Modules linked in: fuse nvidia_modeset(PO) nls_utf8 ntfs snd_hda_codec_hdmi mousedev hid_logitech_hidpp nvidia(PO) eeepc_wmi asus_wmi kvm_amd sparse_keymap video mxm_wmi arc4 kvm irqbypass ath9k crct10dif_pclmul ath3k crc32_pclmul ath9k_common nls_iso8859_1 ath9k_hw crc32c_intel btusb nls_cp437 btrtl vfat input_leds btbcm fat btintel evdev xpad(O) ff_memless ath aesni_intel joydev snd_hda_codec_realtek led_class mac_hid snd_hda_codec_generic bluetooth mac80211 aes_x86_64 lrw snd_hda_intel gf128mul snd_hda_codec glue_helper ablk_helper cryptd cfg80211 snd_hda_core hid_logitech_dj edac_mce_amd r8169 pcspkr snd_hwdep psmouse serio_raw fam15h_power k10temp edac_core rfkill drm mii snd_pcm snd_timer snd sp5100_tco soundcore i2c_piix4 shpchp acpi_cpufreq tpm_infineon tpm_tis tpm fjes wmi processor
[   39.249712]  button sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod atkbd libps2 ahci libahci libata xhci_pci ohci_pci ohci_hcd ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio
[   39.249726] CPU: 1 PID: 1445 Comm: SaintsRow4.i386 Tainted: P           O    4.4.5-1-ARCH #1
[   39.249727] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 R2.0, BIOS 1903 07/11/2013
[   39.249729]  0000000000000086 0000000027c6ca49 ffff8801ece97b48 ffffffff812cb391
[   39.249731]  ffff8801ece97b90 ffffffffa0063c89 ffff8801ece97b80 ffffffff810776e2
[   39.249733]  ffff88021422be40 0000000002080020 ffff8801ece97c88 ffff8802142c3800
[   39.249735] Call Trace:
[   39.249741]  [<ffffffff812cb391>] dump_stack+0x63/0x82
[   39.249744]  [<ffffffff810776e2>] warn_slowpath_common+0x82/0xc0
[   39.249746]  [<ffffffff8107777c>] warn_slowpath_fmt+0x5c/0x80
[   39.249749]  [<ffffffff810e24f6>] ? mod_timer+0x106/0x220
[   39.249754]  [<ffffffffa004d2ed>] usb_submit_urb+0x2ad/0x5a0 [usbcore]
[   39.249757]  [<ffffffffa048d193>] xpad_play_effect+0xd3/0x240 [xpad]
[   39.249759]  [<ffffffffa01a8744>] ml_play_effects+0x104/0x690 [ff_memless]
[   39.249762]  [<ffffffffa01a8d95>] ml_ff_playback+0x85/0x100 [ff_memless]
[   39.249765]  [<ffffffff8142f310>] input_ff_event+0x60/0x90
[   39.249767]  [<ffffffff8142cc83>] input_handle_event+0x73/0x4f0
[   39.249769]  [<ffffffff8142d214>] input_inject_event+0x94/0xa0
[   39.249772]  [<ffffffffa04db98c>] evdev_write+0x12c/0x180 [evdev]
[   39.249775]  [<ffffffff811e0ca7>] __vfs_write+0x37/0x100
[   39.249778]  [<ffffffff81236c1d>] ? compat_SyS_ioctl+0x3dd/0x11f0
[   39.249780]  [<ffffffff811e15b7>] vfs_write+0xa7/0x1a0
[   39.249782]  [<ffffffff811e2295>] SyS_write+0x55/0xc0
[   39.249784]  [<ffffffff81003d30>] do_fast_syscall_32+0xa0/0x160
[   39.249787]  [<ffffffff815996ce>] entry_SYSCALL_compat+0x3e/0x43
[   39.249789] ---[ end trace 5c4cba6527b6ba3b ]---

[MattSturgeon]

Interestingly this regression also occurs when using Sarah Bessmer's URB corruption patch

Perhaps @ValveSoftware were right to use a queue? Or is it more subtle than that? I wonder if @dtor has any imput..

[Turbito]

It happens to me too with the Saints Row 2 port

[paroj]

the dmesg error says that we are using an active URB somewhere. i.e. that the busy URB tracking introduced here missed something.
If this happens the URB basically dies and no commands are sent to the Controller anymore, which explains why the vibration does not stop.

If you can read the code, you could try to review the above commit if you find something suspecious. It will take me a couple of weeks until I can look at it.

[orbea]

Just a heads up that this issue is now present in the 4.5.5 and 4.6.0 kernels as experienced with the mupen64plus libretro core. Reversing the commits until 2fbc567 is a temporary workaround.

[dantob]

@paroj take a look at this, not sure..

https://github.com/dantob/xpad/commit/158cdf40f7a63b7fae179320c80a1630151c5c46

[paroj]

am I correct that this bug only occurs with the wired xbox360 controller?

[MattSturgeon]

I haven't seen any reports using anything other than the wired 360. I've only tested with the wired 360 controller myself.

I'm unable to test @dantob's commit myself currently as I am away from my main computer for the week.

EDIT: having looked around the couple bug reports I found are all for 360 wired. There was one that only specified 360.

[paroj]

anybody affected by this bug could you run the stress_urb_out.sh script in one terminal, while doing fftest /dev/input/by-id/usb-*360*event* (0 to start vibration, -1 to disable) and report whether this reproduces the bug for you?

I own a x360w controller, where this works fine.

[mcphail]

I'm the submitter of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574102 and use a wired 360 controller.

Running stress_urb_out.sh with stock Ubuntu 16.04 xpad driver, aaf6b44 or dantob@158cdf4 does not reproduce the bug. Rumble starts when running option 0 from fftest and stops when selecting -1. All 3 exhibit the bug when opening Saints Row3, so dantob's patch doesn't fix it for me.

Running stress_urb_out.sh with f23507b (which does not exhibit the bug with Saints Row3) will stop the controller from responding at all or completely lock up the computer (? kernel panic).

The maintainer of the Saints Row Linux ports has commented they switch rumble on and off very quickly when the game loads to test rumble functionality. Is the cadence of the on/off signal important? Is this a race, by any chance?

[paroj]

ok, this makes it more likely that the implementation in Saints Row3 is flawed. 2fbc567 changed the way the driver behaves if it gets FF commands faster than it is able to send them.
Sending the commands A B C without waiting in-between will immediately send A, cache B but then overwrite B with C - so effectively only A C is sent.

We do not use a real queue like Valve as it would allow user-space applications to provoke a non-recoverable out of memory condition by spamming the driver with FF commands.

[mcphail]

Is there a way to prioritise FF "off" events so at least one of them is preserved at the end of the queue? That would satisfy both scenarios.

[MattSturgeon]

I think like @mcphail hinted at, I think we should keep track seperatley of different types of events. E.g. if an LED event goes through, it shouldn't wipe a FF event (or any unrelated event).

It makes sense for a FF off to replace a FF on and vice versa, but I think it should be tracked seperatley from other events. Other types of event might make sense to have their own tracking.

You could iterate between types of request each time you dispatch one so that one doesn't take priority

[dtor]

We should be doing proper round-robin of the 3 different types of packets - control, LED and force feedback.

That said, I think we reset "pending" flag on buffer at the wrong time (or on the wrong buffer). I.e. currently reset it only after data has been successfully transmitted to the device and if new packet comes in before that we will effectively lose it. Can you try removing "xpad->out_packets[xpad->last_out_packet].pending = false;" from xpad_irq_out() and adding "packet->pending = false" to the "if (packet)" branch in xpad_prepare_next_out_packet().

Thanks,
Dmitry

[paroj]

@dtor actually I was just investigating the issue and also had the pending flag in mind.

I found out that Saints Row3 was part in one of my Humble Bundles and could reproduce the error. Your suggestion indeed fixes it.

[dtor]

Please send the fix to linux-input so that I can apply.