"Stopping EP_IN, because of status 6" and LIBUSB_ERROR_OVERFLOW

[MakerStuff]

Hi, i don't know what is going on here. I seem to have a one way connection between mixxx and my DJ Hercules MP3 e2 which does not react to button presses but lights up the LEDs when i enable for example the headphone output using my mouse (or keyboard shortcut).

I am using Ubuntu 20.04 LTS and installed mixxx via:

$ sudo add-apt-repository ppa:mixxx/mixxx
$ sudo apt update
$ sudo apt install mixxx

This is what i did to install hdjd:

git clone https://github.com/nealey/hdjd.git
cd hdjd
make

And this is what i expect to be executet in a different way:

$ ./hdjd

Locating Hercules USB devices...
(You can also use the lsusb command to locate this information)
Vendor:Device = 06f8:b105
Opened [Hercules DJ Control MP3 e2]
usb.c:115 Fatal: Stopping EP_IN, because of status 6.
Software needs restarting
Aborted (core dumped)

and

$ ./explore

Opened a Hercules DJ Control MP3 e2
ERROR: LIBUSB_ERROR_OVERFLOW

Any help is appreciated.

[MakerStuff]

Nevermind. It works now. I don't know why. I am sure i restarted my computer after the installation, but i just connected my controller to mixxx and it responded in the way i wanted it to.

[funnyflowerpot]

I have exactly the same issue as described here. I tried several times to turn it off and on again (laptop, the device), but to no avail.

The buttons of the DJ Hercules MP3 e2 light up as in Mixxx, but my computer does not seem to receive any data from the device. hdjd and explore deliver exactly the same results. I followed the same steps as above to install hdjd. I am using Gentoo Linux and Mixxx 2.2.4 from the official repository.

A bit of internet search got me thinking, that there might be something off with the udev rules. I changed some parts temporarily, without notable effects. I installed them manually as described in Mixxx' troubleshooting docs, but this did not seem to change anything. I am using eudev as a replacement of udev and I do not use systemd. In the udev rules the builtin uaccess functionality is used, which apparently works differently in eudev, but I could not find any specifics. (I was following this lead for quite some time.) However, a feeling remains that the problem might have something to do with permissions or ACLs, but I might be totally off there. I couldn't find any other hints for it.

Another idea might be that hdjd (or libusb?) depends on some functionality of the kernel, which I currently do not have enabled.

Any help or hints would be greatly appreciated.

[funnyflowerpot]

Update. I tried a USB 2.0 socket instead of an USB 3.0 socket and Mixxx worked right away. Duh. :-) Sorry for the noise and thanks nevertheless!

[nealey]

This sounds like a bug, then. It should work on a USB 3.0 port. The fact that it isn't may have something to do with how I'm using the USB library.

I'm reopening this bug so other people can find it if they have the same problem. If that describes you, the person reading this, please leave a comment here, with any additional information. In particular, it would be nice to know if plugging into a USB 2.0 port fixes the issue.

[nealey]

It's also possible this is the same issue as #9

[funnyflowerpot]

Good suggestions! Please let me know, if you think posting any details (command output etc.) might help for diagnosis.

This sounds like a bug, then. It should work on a USB 3.0 port.

This might be. But since my kernel is heavily customised, I do not want to exclude that the problems are due to misconfiguration on my end. I would need to do more testing to exclude that case.

It's also possible this is the same issue as #9

I had a look earlier at the issue, but I think it might be different. When I compare the OPs output of explore with mine (i.e. as described above), I find that in #9 explore accepts input, while for me explore (and hdjd) die quickly.

[lenainjaune]

Hi all :)

Sorry to necrobump, but I just wanted to make a feedback here for what I discovered on the same subject.

I discovered that when I unpluged my controller (for example to reorganize my USB devices), it could not be detected no more by hdjd and showed this error :

usb.c:115 Fatal: Stopping EP_IN, because of status 6.
Software needs restarting

As I do not found a way to correct the problem I had no more choice than reboot my computer which was really annoying and frustrated me a lot.

Today after testing multiple supposed solutions, I discovered this link which gave me the solution :
the usbreset program (code in C to be compiled ; the original source in case of unavailability), then give its the execution right and run it TWICE to reset the controller port (given by lsusb). I do not understand why the hell the controller can not be unppluged in the normal way and why we must execute usbreset twice to correct the problem but I discovered by test that works perfectly. As it is not my technical expertise domain I have no explication why this works and why we must make this. If someone have expertise on this subject ...

Which gives in my case :

root@host:~# cc usbreset.c -o usbreset
root@host:~# chmod +x usbreset 
root@host:~# lsusb | grep Guillemot
Bus 003 Device 011: ID 06f8:b105 Guillemot Corp. DJ Control MP3 e2
root@host:~# ./usbreset /dev/bus/usb/003/011
root@host:~# ./usbreset /dev/bus/usb/003/011

So after resetting (without rebooting) I can start again hdjd without problem :D

Note : in my case the problem seems not bound to USB2/USB3 in any way ...

Hope it can be useful for someone ...

With adelphity
lnj

[nealey]

Excellent sleuthing. So if I'm reading this right, when we get status 6, we need to run whatever code is in usbreset, and try again. I'm assuming we'll get status 6 a second time, run it a second time, and then things will come back.

If that sounds about right, I'll try to integrate this code in a development branch that people can test.

[lenainjaune]

So if I'm reading this right, when we get status 6, we need to run whatever code is in usbreset, and try again. I'm assuming we'll get status 6 a second time, run it a second time, and then things will come back.

Yes you must compile usbreset.c with cc and with the created binary you can reset the device connection's port.

---

As I was not sure of the reliability of my feedback, I dug further (but may have gotten a little lost).

Environment tests :

• Debian 11 Bullseye (tested from 2 distinct physical systems)
• Kernels : 5.10.0-8-amd64 kernel and a real time kernel (in my case 5.18.0-16.1-liquorix-amd64)
• mixxx v2.3.3 64 bits compiled from sources
• hdjd v??? (downloaded and compiled from here in 07/2022)

Use cases (UC) :

• system boot or reboot without or with a changing of USB port
• plug controller in an online system
• start mixxx without hdjd before with / without using the controller

Note: I confirm that we can use the USB2 or USB3 ports indiscriminately ; they do not seem to produce a noticeable difference

The UCs focused to avoid reboot always follow this process :

• make hdjd operational
• test hdjd and mixxx OK
• kill hdjd and explore
• make hdjd operational again
• test hdjd and mixxx OK

---

Furthermore, as I did not know the explore program and I never used it, I understood the following (correct me if I am wrong) :

• if the explore program receive button events this means that the controller is operational
• if hdjd is started explore can not access the controller
• if explore is started there is a hook on the controller, so if I unplug it there is an error (like when hdjd running)

Too, sometimes explore displays some codes, as if it was emptying a buffer before throwing the error or starting, like this :

user@host:~$ /data/noinstall/hdjd-master/explore
Opened a Hercules DJ Control MP3 e2
b0 38 0c
ERROR: LIBUSB_ERROR_OVERFLOW

---

What my tests reveal (I can post the full results if you want or need it) :

• if we boot with USB connected before => 1 unique usbreset is NECESSARY
• while the controller remains connected to the same port => NO need to usbreset
• if we change port (even after killing hdjd's and explore's hooks) => 1 or 2 usbreset are NECESSARY
• if we forget hdjd before starting mixxx, if we touch the controller => 1 or 2 usbreset are NECESSARY (if you do not touch anything, you can start hdjd afterwards)
• in the process to avoid reboot (see above), after killing hooks (hdjd + explore) => NO need to use resetusb

Note : I did not manage to isolate why sometimes we must use usbreset once and sometimes twice !

The commands used and the results obtained

Get the port where the controller is plugged

user@host:~$ lsusb | grep Guillemot
Bus 002 Device 005: ID 06f8:b105 Guillemot Corp. DJ Control MP3 e2

Test the controller events

user@host:~$ /data/noinstall/hdjd-master/explore
Opened a Hercules DJ Control MP3 e2

... followed by ...

ERROR: LIBUSB_ERROR_OVERFLOW

... when the controller is NOT operational ; usbreset is NECESSARY !

... or followed by ...

ERROR: LIBUSB_ERROR_IO

... when the hdjd is yet ran, so we can not use explore and must kill hdjd before.

... or followed by ...

b0 3c 53 
...
^C

... when the controller is operational.

Start hdjd

user@host:~$ /data/noinstall/hdjd-master/hdjd &
Locating Hercules USB devices...
(You can also use the lsusb command to locate this information)
Vendor:Device = 06f8:b105
Opened [Hercules DJ Control MP3 e2]

=> if there is no extra text, hdjd is operational

... but if there is this text :

usb.c:115 Fatal: Stopping EP_IN, because of status 6.
Software needs restarting

the controller is NOT operational ; usbreset is NECESSARY

Start mixxx

user@host:~$ /data/noinstall/mixxx_2_3_3/build/mixxx
...
usb.c:290 Warning: usb.c:290 1(r)+100(w) = 101 outstanding USB transactions!
...

Nota : some systems show the previous warning, some not

Reset the port in trouble (by default root only)

root@host:~# /data/noinstall/usbreset /dev/bus/usb/002/003
Resetting USB device /dev/bus/usb/002/003
Reset successful

Unplug the controller without killing hooks before

The hooks seems to be set from hdjd and explore.

usb.c:115 Fatal: Stopping EP_IN, because of status 5.
Software needs restarting

OR

usb.c:115 Fatal: Stopping EP_IN, because of status 1.
Software needs restarting

Note : I did not manage isolate why sometimes it returns status 1 or sometimes 5

---

If that sounds about right, I'll try to integrate this code in a development branch that people can test.

Cool :D

Could you give me a return when you will test it ?

I am not sure my contribution help to resolve the OP problem. I have some identical symptoms but as I do not understand the whole process I do not guarantee this will working for you but it worked for me.

[nealey]

My time to work on this is extremely limited lately. I'm going to leave a note to myself here:

The code in question is the following:

        int rc = ioctl(fd, USBDEVFS_RESET, 0);
	if (rc < 0) {
		perror("Error in ioctl");
		return 1;
	}

This needs to be run if there's a USB error. Apparently we might need to do it more than once, so I'll have to implement it in a loop with fallthrough. Like:

1. Try the USB operation
2. If it succeeds, fall through
3. If we've reset more than twice, exit with error
4. reset (code above), and restart at step 1

[nealey]

I'll also note that I would love it if somebody else implemented this in a merge proposal. Realistically, if I'm the only one doing the work, it probably isn't going to happen before June 2023.