libusb: error [get_usbfs_fd] libusb couldn't open USB device /dev/bus/005/020, errno=5 #509
Comments
|
Have you tried without sudo, or with another usb cable? |
|
Welp, it may not matter if that's the fix now. I may have bricked it. I'll let you know if that works. Update: I was surprised to see the battery drained. I may have left it on overnight. <s Should be charged in a week or so! /s> |
|
@Grimler91 I've changed the USB cable and ran without sudo privileges, to no avail. When I start the tablet in download mode, I see: Is there a specific USB cable I should use? Debugging Debugging and |
|
I was having trouble with a USB drive connecting and realized I hadn't restarted my computer after a kernel update (bad form, I know, but I'll always do it now!). That didn't solve it. However, I found this when searching for the @Grimler91 thoughts? |
|
What kind of device, and OS, are you running heimdall on?
Udev rules could help, but I think What information about the device does |
|
This is a custom desktop running Manjaro 15.16.7-1. Here's |
|
And these are the rules in The |
|
That all looks normal. Not really sure what issue is here, but doesn't really seem to be a heimdall issue. Libusb fails to open the device, maybe there is some issue with libusb, or maybe with some hardware (usb cable, usb port, ..) If you have the possibility you could try from another distro, or from another computer and see if it works in that case |
|
Hello again. I'm running Linux Mint 20.3 Una on a separate machine. I ran the logs and they have different outputs, though it still doesn't work. I'm going to read through them and refer to known issues to see if there's a solution. In the event I don't find anything, I'll tag you to determine next steps. Thanks for the help so far! |
|
@dfarmilant what's the error on the other machine? If it at least succeeds to initialize the device, but fails with something else that might be a heimdall issue, then you could also try updated heimdall from here: https://git.sr.ht/~grimler/Heimdall/ and see if it works better |
|
I seem to get the same behaviour with Debian bookworm (amd64, Debian build). The detected usb port seems to always be off by one. That's why it can't be opened with or without sudo. Will try the new version, too. |
|
|
Replugged the USB cable: |
|
Issue persists even with Heimdall v2.0.2 How can we further debug this? |
|
I believe I'm running into the same issue with openSUSE Tumbleweed. The device number is always off by one, because the device is reset and it gets a new ID on a reconnect. I mean, I can link this to these messages in the kernel log: That means, the device ID was originally 1.19, but it got a new number after a USB reset. What I don't know is what causes this USB reset. |
|
I have ftraced the USB reset functions with full stack trace, and I don't really have a clue about the result: This pretty much looks like the kernel is resetting the device when the usbdev file is opened, but such behaviour should break pretty much all of libusb users… FTR I'm running Linux 6.1.1 here. |
|
I had some luck after turning autosuspend off. Interestingly, I was not able to turn off autosuspend for this device specifically, but I had to turn it off globally:
Since my device was already suspended at that point, I also had to wake it up once:
I believe that the latter command should be sufficient, and it is a kernel bug if it isn't. I'll follow up with the kernel folks on that. It may in fact be the only issue here. I mean, if correct operation relied on disabling autosuspend for the target device, then it obviously won't work now. |
|
Back with news from the linux-usb mailing list. As we knew already, the implementation of the USB stack in download mode is crappy. In this case, the kernel sends a GET_STATUS control message to the device after resume to make sure the device is still there (as required by section 10.5.4.5 of the USB standard). The device should respond with two bytes of status in the data stage, but the Samsung download mode sends a zero-length data packet instead (i.e. no data). Since this behaviour is hard-coded in the kernel resume logic, there is no way to resume from suspend without a disconnect and reconnect. That's why autosuspend cannot be disabled on that device when it is already suspended. OTOH udev might be fast enough to disable power control before the device is suspended. In short, I propose to change the corresponding line in This fixes the issue for me. |
|
Thanks a lot for investigating @ptesarik I will try that fix, too. |
|
Hey, @mkesper, did my proposed solution work for you? |
|
Finally got to it. Yes, it works! NB: For Debian, the file is Thanks a lot! 👍 |
|
Had the same issue on Manjaro with Heimdall 1.4.2 Added the proposed fix
to
Success |
I'm attempting to root an SM-P600 Galaxy 10.1 2014 tablet. I'm able to detect a device via heimdall-frontend -> utilities -> detect.
If I attempt to download or print the PIT file in the CLI, I get the following output. I get a similar output to the one below, less the line with the "###".
I've searched this and the libusb-git repos and haven't been found a solution. Any tips?
The text was updated successfully, but these errors were encountered: