Launcher rarely reports launch completed when that doesn't seem to be the case

[Qyriad]

I've had some reports of Fusée Launcher reporting launch complete but, for example, when launching a payload that should show output, seemingly nothing happens on the Switch. I have experienced this myself. It seems to be extremely intermittent.

[CTCaer]

FYI, this was only happening to me, when I was using VirtualBox with a linux guest and windows host.

[Qyriad]

@CTCaer You haven't had it happen on native Windows?

[CTCaer]

Nope, not for me. Also, I was lucky enough and the classic windows problem, where a USB port gets stuck by re-plugging, and then you need to reboot or change port, didn't happen to me, not even once.

[natinusala]

This could be unrelated but sometimes when using Shofel2 Linux boots but the LCD stays off (I know it booted because of SSH). This may be the same issue, with the LCD staying black here you think nothing happens.

[neobrain]

For reference, I've had similar symptoms, and my fix is probably very specific to my situation:

• I'm on Linux
• My laptop's blue USB 3.0 port somehow always uses EHCI
• I was using the EHCI driver patch provided in https://github.com/fail0verflow/shofel2/blob/master/linux-ehci-enable-large-ctl-xfers.patch (or rather, the variant of it that hotpatches kernel memory, labeled "Cursed Code.")

fusee-launcher would only succeed about 4 out of 10 tries for me with this USB 3.0 port. Simple as it sounds, using the USB 2.0 port (with the aforementioned patch) increased success rate to 100%.

[nitro322]

Hello. I'm unable to get fusee-launcher to work from my Linux system hardly at all. Not sure if it's related to this or something different (in my case, it's not rarely fails but rarely fails). I was able to successfully exploit this a single time (out of maybe 30 attempts) from my Linux desktop with fusee-launcher. I finally tried using TegraRcmGUI on my GPD Win 2 (the only native Windows device I have in my house) and it worked first try, and consistently every try.

I'd really like to get this working properly from my main desktop, though. Posting troubleshooting info below. Happy to move this to another bug report or perhaps another forum if appropriate - would just appreciate any guidance or assistance.

I'm running Gentoo amd64 - kernel 4.16.17, python 3.5.5, libusb 1.0.21, pyusb 1.0.2. Not sure what other version info would be useful.

Switch is running firmware 4.1.0. I've tried multiple payloads, but currently using hekate - CTCaer mod v3.1. I've tried multiple packages on the SD card as well, but currently using hekate All-in-One Package (SDFilesSwitch) v5.1.1. I'm reasonably confident both the payload and SD files are configured and working correctly due to the aforementioned successes with TegraRcmGUI on Windows.

When launching the switch in RCM mode, it shows up like this in dmesg:

[ 2006.649323] usb 1-8: new high-speed USB device number 17 using xhci_hcd
[ 2006.857826] usb 1-8: New USB device found, idVendor=0955, idProduct=7321
[ 2006.857829] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2006.857831] usb 1-8: Product: APX
[ 2006.857832] usb 1-8: Manufacturer: NVIDIA Corp.

Switch is connected to a USB 3.1 Gen1 port (my desktop only has USB 3 ports), and from the dmesg output I'm pretty certain it's using XHCI. I launch fusee-launcher as root and get this:

$ sudo ./fusee-launcher.py ../../hekate_ctcaer_3.1.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.
Found a Tegra with Device ID: b'\xc0\x82\x03\x02\x00\x00\x00<snip>'

Setting ourselves up to smash the stack...
Uploading payload...
Smashing the stack...
The USB device stopped responding-- sure smells like we've smashed its stack. :)
Launch complete!

(Note: edited out the last few digits of the Device ID. Not sure if that's sensitive info, but just in case would rather not have it pasted on the internet.)

Everything looks successful, but nothing happens on the switch. I have to hold the power button to shut it down, then try again. The one time it did work I believe I had used the -w option and connected the switch after it was running, but I can't get that to work again, either.

Again, would appreciate any guidance or assistance in helping to get this working. I'm happy to provide any additional details or troubleshooting info. Thanks for this awesome project!

[nicman23]

same exact issue on x370 platform as @nitro322

[nicman23]

I found the issue. I think it was to do with handoff of usb3 to the os instead of the mobo fw. If you enable win7 usb wake compatability, everything works.

Not sure if a kernel or fw issue but it ought to be added as a troubleshooting note somewhere.

[nitro322]

@nicman23, thanks for the comments. When you mention win7 wake compatibility, to confirm, are you referring to a BIOS setting? Not at my main computer at the moment, but if so I'll look for that same setting and see if I can confirm it works for me as well.

Also on x370, btw. Hadn't even considered that might factor in.

[nicman23]

yes it is a bios setting that disables xhci handoff

[MetalNeo]

Was having same problem. Culprit turned out to be BIOS setting. This should really be added to the readme/wiki.

[LyricLy]

Disabling XHCI handoff didn't work for me on Arch. Same details as @nitro322.

[nitro322]

I forgot to follow up on this, but I still can't get this to work on my system reliably. I couldn't find an explicit option to disable XHCI handoff in my ASRock Taichi x370 motherboard. I've seen that in the past, so I'm pretty sure I know what I'm looking for, but that wording doesn't seem to exist in any of the settings. Tried toggling a few USB settings that may be related, but no luck.

[nicman23]

for me a different cable also seemed to help

[nicman23]

@nitro322 it is called windows 7 compatibility something or rather in my asrock x370 fatal1ty

[nitro322]

@nicman23 Appreciate the follow-up. I can't find anything like that, either. Reviewed my BIOS settings multiple times - only thing mentioning Windows 7 compatibility I could find was something relating to resume. Did some more searching and it looks like ASRock just removed those settings from newer firmwares:

https://linustechtips.com/main/topic/772564-asrock-x370-bios-usb-configuration-missing/

So... crap.

Edit: I've tried two different cables as well, and have the same issue with both.

[nicman23]

i really do not think it is an firmware issue because i have my machine overclocked to the edge of not being stable and it works 100% - while stock didn't. i really think you ought to buy a short not cheap cable

[mgueji]

Same problem here, I didn't try with another cable, but switching off the XHCI Handoff didn't help for me, using XHCI in a USB 3.0 I'll update if I can isolate the problem.

Ubuntu 19.04 Motherboard B450M

[LyricLy]

None of my 3 USB-C cables that I own resolve the issue.

[nicman23]

also 2 ports in my 8 port motherboard straight up do not work for some reason

[mgueji]

With a USB C to USB C cable in my motherboard works every single time I tried it.

Motherboard: MSI Gaming Plus B450M

[Igetin]

I tried to send the Hekate 5.0.2 payload on an ARM Linux system a few times, but the Switch’s screen stays black after the launch is “complete”. Though I had to add 'platform/drivers/xhci-hcd' to the SUPPORTED_USB_CONTROLLERS in fusee-launcher.py for the script to work with my system. The device has only USB 3.0 ports, and it should be using the XHCI controller according to dmesg.

Output of fusee-launcher.py -w hekate_ctcaer_5.0.2.bin:

Waiting for a TegraRCM device to come online...

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.
Found a Tegra with Device ID: (device ID here)

Setting ourselves up to smash the stack...
Uploading payload...
Smashing the stack...
The USB device stopped responding-- sure smells like we've smashed its stack. :)
Launch complete!

dmesg:

[ 1204.433451@3] usb 1-1.1: new high-speed USB device number 7 using xhci-hcd
[ 1204.558155@3] usb 1-1.1: New USB device found, idVendor=0955, idProduct=7321
[ 1204.558159@3] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1204.558161@3] usb 1-1.1: Product: APX
[ 1204.558162@3] usb 1-1.1: Manufacturer: NVIDIA Corp.