Operation timed out

[oatmealine]

after patching ehci successfully and putting the switch into RCM, the payload gives an error:

❱ sudo python3 ./fusee-launcher.py ../../payloads/fusee-primary.bin

Important note: on desktop Linux systems, we currently require an XHCI host controller.
A good way to ensure you're likely using an XHCI backend is to plug your
device into a blue 'USB 3' port.

Identified a Linux system; setting up the appropriate backend.
Traceback (most recent call last):
  File "./fusee-launcher.py", line 606, in <module>
    raise e
  File "./fusee-launcher.py", line 601, in <module>
    device_id = switch.read_device_id()
  File "./fusee-launcher.py", line 543, in read_device_id
    return self.read(16)
  File "./fusee-launcher.py", line 500, in read
    return self.backend.read(length)
  File "./fusee-launcher.py", line 118, in read
    return bytes(self.dev.read(0x81, length, 1000))
  File "/usr/lib/python3.6/site-packages/usb/core.py", line 988, in read
    self.__get_timeout(timeout))
  File "/usr/lib/python3.6/site-packages/usb/backend/libusb1.py", line 833, in bulk_read
    timeout)
  File "/usr/lib/python3.6/site-packages/usb/backend/libusb1.py", line 936, in __read
    _check(retval)
  File "/usr/lib/python3.6/site-packages/usb/backend/libusb1.py", line 595, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 110] Operation timed out

i have no idea what to do, so all help would be appreciated

[ghost]

I got the same error after pulling latest master branch and using hekate 5.0.2 on macOS. Any ideas?

[AkechiShiro]

I'm having the same error on Linux (Linux pop-os 5.4.0-7634-generic #38~1595345317~20.04~a8480ad-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux), anyone found a fix for it ? On Windows, there is not this error but the fusee-launcher.py script just says uploading payload... never ending nor moving after like 30min so I just stop it, finally it doesn't work.

[ghost]

Try switch your usb port. Preferably a blue port

[AkechiShiro]

Thanks for the suggestion but I already tried with two different computer which had only blue USB port (USB 3.0 at least) and I'm still facing this specific issue of operation timed out on Linux and on Windows the payload never gets delivered, I added some logging code and it seemed that only half the payload got sent and then the program is stuck on Windows 10 that is. The switch I was trying to send the payload was definitely patched since it was kinda of a new one with an improved battery but even then I should still be able to send the payload, just that it wouldn't execute itself.

[ghost]

Well you should double check the model just to confirm, just google "check if switch patched gbatemp" and you should see something

[AkechiShiro]

I already tried, but I know for a fact it is patched since the model number behind is the new model that has an enhanced battery. Nonetheless, patched or not the switch should receive the payload at least no ? I know that on the patched switch it is not possible to execute the payload, I've never heard about a payload not being transmitted because of a patched switch. Hence this issue.

[ghost]

I already tried, but I know for a fact it is patched since the model number behind is the new model that has an enhanced battery. Nonetheless, patched or not the switch should receive the payload at least no ? I know that on the patched switch it is not possible to execute the payload, I've never heard about a payload not being transmitted because of a patched switch. Hence this issue.

Sadly no, if you have the improved battery life model, you are patched :( You can entire RCM mode just fine, but you can't overload the stack and abuse it to run your own stuff.

[AkechiShiro]

Okay I thought that I could at least upload the payload, but if it isn't possible on a patched switch then it's fine I mean I understand, thanks for having made that clear here.