irq_out fails after a suspend/ resume cycle

[paroj]

steps to reproduce on master:

1. unload xpad driver
2. suspend
3. resume
4. load the xpad driver
5. connect the controller

results in:

[   58.190382] input: Xbox 360 Wireless Receiver as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/input/input24
[   58.190510] input input24: xpad_send_led_command - dropped, irq_out is active
[   58.200555] xpad 1-9:1.0: xpad_irq_out - urb shutting down with status: -2

any subsequent calls to xpad_send_led_command or xpad_play_effect fail as well until the receiver is plugged in and out again.
Seems like Linux behaves differently than what the "Xbox 360 Wireless Receiver" expects during USB initialization/ deinitialization.

[computerquip]

Unfortunately, I can't get my system to survive a suspend/resume cycle. I don't really ever do it unfortunately... This is apparently a common problem in later kernels.

On another note, I can't get a VM to properly suspend. virsh allows you to suspend a domain via proper PM so the kernel can properly handle them but it throws "error: S3 state is disabled for this domain" which is unfortunately not very useful. Forcing the VM into suspend results in no way to bring it back...

I'll have to wait until I get a working suspend/resume setup to work on this.

[paroj]

I'd imagine we can kill the recieving urb on suspend and start it back up on resume. That's probably the most appropriate. I'm working on getting a virtual machine running again...

EDIT: We also need to set the LED appropriately as if the computer shut off, then make sure no urbs are active.

the URBs are already correctly destroyed/ re-created again. disconnect and probe are called on suspend/ resume.

Here is a full log of the error: (the number denote bInterfaceNumber)

insmod
[   30.636948] xpad_probe 0
[   30.636959] xpad_probe 2
[   30.636965] xpad_probe 4
[   30.636971] xpad_probe 6
[   30.636984] usbcore: registered new interface driver xpad

connect controller
[   30.645157] xpad_open 0
[   30.653762] xpad_close 0
[   30.669891] xpad_open 0
[   30.685885] xpad_close 0

suspend
[   48.604775] xpad 1-9:1.0: xpad_irq_in - urb shutting down with status: -108
[   48.605011] xpad_disconnect 0
[   48.605038] xpad 1-9:1.2: xpad_irq_in - urb shutting down with status: -108
[   48.605044] xpad_disconnect 2
[   48.605073] xpad 1-9:1.4: xpad_irq_in - urb shutting down with status: -108
[   48.605076] xpad_disconnect 4
[   48.605114] xpad 1-9:1.6: xpad_irq_in - urb shutting down with status: -108
[   48.605117] xpad_disconnect 6

resume
[   49.232579] xpad_probe 0
[   49.232587] xpad_probe 2
[   49.232593] xpad_probe 4
[   49.232598] xpad_probe 6

connect controller
[   78.317971] xpad_open 0
[   78.318103] input input25: xpad_send_led_command - dropped, irq_out is active
[   78.331506] xpad_close 0
[   78.331597] xpad 1-9:1.0: xpad_irq_out - urb shutting down with status: -2
[   78.351506] xpad_open 0
[   78.363433] xpad_close 0

[paroj]

regarding your suspend issue: does your system survive suspend/ resume w/o any xpad driver loaded? My system also sometimes fails to resume if xpad is loaded. (thats how I found the issue)

Furthermore the issue really seems not to be related to the driver as it even occurs if you do suspend/ resume without any xpad driver loaded.

[computerquip]

I didn't know this. I also couldn't find any documentation on the matter so I assumed that the resume and suspend callback in the usb_driver structure was used. Apparently, that was a very poor assumption...

For the xpad_irq_out issue, it doesn't appear that usb_kill_urb is ever called on irq_out inside of xpad_disconnect. I don't believe that usb_free_urb does the necessary clean up.

[paroj]

your assumption was not that poor. Actually disconnect and probe only get called if no suspend / resume callbacks are specified.

As unplugging/ plugging the receiver fixes the issue for me, I had the idea to call usb_queue_reset_device on resume - which worked yay. 49177a4

[computerquip]

For what it's worth, this bug ends up seeming different from my bug. I think this bug is caused by the lack of killing the out URB which ends up staying active since it's never killed in the disconnect function. However, I think this solution works because of the inherent unbinding and rebinding which cleans up the left over URB.

My bug is caused by usb_submit_urb timing out in my probe function for reasons that are still not clear to me since I've been unable to reproduce the problem.

I'm sadly still working on a way to suspend my machine reliably. I wonder if kernel developers are aware of the issue with suspend?

[paroj]

Note that the URB is dead when the driver was not even loaded before suspending - so no URBs could have been possibly opened/ left open. (i.e. the out URB does not work after suspend/ resume no matter what happened before)
I think the issue lies deeper in the USB system than the actual xpad driver.

Therefore I also think that the bug in your driver is related - on xpad the out URB just fails, but as you use usb_submit_urb it times out blocking probe. (at least on my machine)

[computerquip]

Oh, I see. You also don't need to kill the urb explicitly in your driver since you don't use soft_unbind unlike my driver. Although soft_unbind will be needed if you ever want to set LED properly on module unload.

I'd still like to figure out the actual cause instead of seemingly working around it though. I was able to get a computer to replicate the issue and it's an odd one.

Sorry for the misleading comment however.