Bug 1092182

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

The problem still persists in 3.16.2-200.fc20.i686

I debugged it in kernel 3.13.0. Major findings:
- in hid-core.c the function usbhid_parse() is called after the joystick is attached
- usbhid_parse() calls function hid_set_idle(), and this one fails while sending an URB (details see below). Reason: the joystick returns -EPIPE.
- Same thing can be seen, if Wireshark is used to look at the traffic
- According to the documentation, EPIPE means "Endpoint stalled". It furthermore says: "For non-control endpoints, reset this status with usb_clear_halt()."

Unfortunately the return value is not checked in the kernel module. I added this check, and tried to do a "usb_clear_halt" on error. However, I cannot quiet understand how things work in the code, and all my trials ended in crashing the kernel.

---
hid-core.c:usbhid_parse:1006, ret=2
    hid-core.c:hid_set_idle:669
        message.c:usb_control_msg:132
            message.c:usb_internal_control_msg:81
                usb_start_wait_urb: 44
                    submits URB and waits for response with a timeout
                    not: ret = usb_submit_urb() -> ret is zero
                    *actual_length = 1
                    ctx: struct api_context { .done:struct completion, .status:int }
                        completion: struct { done: uint, wait: wait_queue_head_t }
                    expire = msec_to_jiffies(5000) = 1250
                    not: ret = ctx.status or -ETIMEDOUT, since dev_dbg does not appear
                    ret = ctx.status -> so the -32 is ctx.status. This is "broken pipe", as seen in the Wireshark trace

Just found out, that it indeed is an upstream bug. Works in 2.6.38-12.

2.6.38? That is a ways back. When I was doing some research on this, I saw the USB HID kernel code was refactored. I'm guessing that's what broke it. Unfortunately, I couldn't even get as far as you in trying to debug the cause of the problem. Does this section of the kernel have a maintainer here or upstream?

I can narrow it down a bit more: In 3.0.0-12 the problem was not there either. So it came somwhere after that...

Created attachment 980882 [details]
Patch for Microsoft Sidewinder Force Feedback 2

Proposed patch to get the Microsoft Sidewinder Force Feedback 2 working.

Three bugs are addressed:

1) The FF2 driver (usbhid/hid-pidff.c) sends commands to the stick during ff_init. However, this is called inside a block where driver_input_lock is locked, so the results of these initial commands are discarded. This one is the "killer", without this nothing else works.

2) The usbhid driver ignores an endpoint stall when sending control commands, causing the first few commands of the hid-pidff.c initialisation to get lost.

3) The FF2 driver does not set the effect ID when uploading an effect. The result is that the initial upload works but subsequent uploads to modify effect parameters are all directed at the last-created effect.

Patch created against kernel 3.13.0 .

I have tried the patch from comment #7. It compiles and runs great against 3.17.7-300.fc21. fftest uploads and runs the 5 test effects as expected. Great work.

Any chance this can be added against an upcoming F21 kernel or will it need pushed upstream first?

(In reply to Aaron Kling from comment #8)
> I have tried the patch from comment #7. It compiles and runs great against
> 3.17.7-300.fc21. fftest uploads and runs the 5 test effects as expected.
> Great work.
> 
> Any chance this can be added against an upcoming F21 kernel or will it need
> pushed upstream first?

It needs to be rebased against 3.19 and at least sent upstream for review before we'll grab it.  Particularly since it is modifying hid-core.  If anyone wants to do that, we'd appreciate it as we don't have hardware to test this with.

Josh, the patch has already been submitted upstream:
https://patchwork.kernel.org/patch/5653831/

Alan made some feedback that I agree with, and by looking at it, I have a few more comments.

Jim, when your patch gets accepted by Jiri, please mark a comment here and I am pretty sure Josh will be glad to pick it for the Fedora kernel.

Oh excellent!  Thanks for the info.  I'll keep an eye on this bug.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.18.7-100.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.