Kernel: usb 2-6: usbfs: USBDEVFS_CONTROL failed cmd asterisk rqt 161 rq 1 len 4 ret -71

App_rpt-users
1

I’m having a problem where on average every 3 days to a week- my system “goes out”.
And I have no communications via USB to the radio/audio interface, and I have to reboot it to get it working again.
My Interface is the well-known DMK URIxB 9180B With internal EEPROM. And was purchased and installed recently.
I have ASL3 fully up to date and is running on a Dell Optiplex Desktop (Gen4 i5 CPU).
I have tried changing ports, checking/changing the cable and all that usual stuff.
And yes am using a beefy short high quality cable, also tried a cheaper thinner longer cable.
And no difference.
The PC has USB3 and USB ports (I’ve tried both) I do not know if it matters generally?
But I tried both.
I left DMK a message on their webpage contact form and left these details,
I have not heard back from them. It’s been about a week.
I will next: try changing to a different PC (something completely different) and I will contact DMK sales as well as make a phone call to them at that point if that does not fix it.
Throwing this out here in case anyone else may have had this or a similar problem and might have some advice.
When it happens the kernel log flood with:
kernel: usb 2-6: usbfs: USBDEVFS_CONTROL failed cmd asterisk rqt 161 rq 1 len 4 ret -71

This seems to imply it has something to do with a USB filesystem.
There are NO other devices on the computer USB aside from the radio Interface.
I wonder if it could possibly have anything to do with the URIXB having built in EEPROM for settings?
I have never used this feature, and I’ve not investigated how to use it.
I’m not sure if ASL3 “automatically” uses it and writes/syncs setting to it? Or does this have to be done manually somehow if it were to be used.

-SteveG
N8LBV

2

May as well include this info:
root@ASL3:/proc# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 223.6G 0 disk
├─sda1 8:1 0 222.6G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 975M 0 part [SWAP]
root@ASL3:/proc# lsusb
Bus 004 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:8008 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0d8c:0013 C-Media Electronics, Inc. USB Audio Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

3

That is essentially a generic error that the kernel issued a command to a device and it failed to complete. The return was an unknown and unrecoverable error. This usually but not always means the device is having issues. Do you have a second adapter to test?

4

I do not have another handy…

5

Just thinking out loud, “161” (10) would be “A1” (16) or “10100001” (2) and likely maps to the EEPROM read operation. From the source code in …/app_rpt/res/res_usbradio.c :

void ast_radio_hid_get_inputs(struct usb_dev_handle *handle, unsigned char *inputs)
{
        usleep(1500);
        usb_control_msg(handle, USB_ENDPOINT_IN + USB_TYPE_CLASS + USB_RECIP_INTERFACE,
                HID_REPORT_GET, 0 + (HID_RT_INPUT << 8), C108_HID_INTERFACE, (char *) inputs, 4, 5000);
}

with “…/usb.h” providing :

#define USB_ENDPOINT_IN			0x80
#define USB_TYPE_CLASS			(0x01 << 5)
#define USB_RECIP_INTERFACE		0x01

To me, this sounds like asterisk can’t read the EEPROM data.

and to get you going, maybe change “eeprom = 1” to “eeprom = 0” in your .conf file ?

6

So not just a “generic error” as was mentioned above then?
Also eeprom=0 is already set this way and is the default.
I have not changed this.

7

Actually, if not specified in the simpleusb.conf (or usbradio.conf) file the default value for the “eeprom” variable is “1”.

And, for all looking at this thread, the code looks for the “eeprom” variable in the settings for the nodes device (e.g. [12345] or [node-main] if your configuration is setup to use the templates).

8

My simpleusb.conf came out of the box as: (I am using simpleusb).
node-main
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;; Template for all your SimpleUSB nodes ;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

eeprom = 0 ; EEPROM installed: 0,1
; 0 = no (default)
; 1 = yes

This is ASL3 current release and up to date.

Also rpt.conf has zero entries that contain the string “eeprom” case insensitive.
Or anything that looks related.
Seems opposite of what you are stating.
Am I missing something?
Thanks,
Steve

9

Well, all I can say is that I read your message, I looked around to see if I could understand the reported error, and I shared what I found.

It’s certainly possible that the code I was looking at is unrelated and that there’s some “other” code that is interacting with the USB device but nothing jumped out to me.

10

All good and thanks!
Parts of your report might come in handy too!
We’ll see where this goes.
Problem is getting it to happen. So random.
Been up for almost 3-days now and not happened.
Like it will go as soon as I leave and go on the road.

11

This seems to have “fixed” this problem.
This is a mainstrream Dell i5 Desktop “business” computer.
It’s not a laptop or anything like that- where I might expect more sleep or power saving tendencies out of the box on a Debian 12 install.
I can’t be the only guy out here that has ran into this problem.
My actual config line that fixed it:
GRUB_CMDLINE_LINUX_DEFAULT=“quiet usbcore.autosuspend=-1”

From: How to disable USB autosuspend on kernel 3.7.10 or above? - Unix & Linux Stack Exchange
Edit the /etc/default/grub file and change the GRUB_CMDLINE_LINUX_DEFAULT line to add the usbcore.autosuspend=-1 option:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1"

Note that quiet splash were already present options. So keep other options you have too.

After save the file, update grub:

sudo update-grub
12

Hi WA3WCO,
I was gently calling out that the defaults (regarding EEPROM Installed:) that you stated in a previous reply are not the actual defaults on my recent ASL3 installs.
Did something change? I’m curious where that information came from.
Thanks.
SteveG N8LBV

13

Glad that you found a solution :slight_smile:

The template “simpleusb.conf” and “usbradio.conf” files both have “eeprom = 0”.

My comments about the default value for the “eeprom” variable were driven by what I was seeing in the source code and the messages you reported being logged. The ast_radio_hid_get_inputs() function I noted should not have been called if your configuration file had “eeprom = 0”. If that function was the source of the error messages then somehow the “eeprom” variable was non-zero. This could happen if the line was missing (or commented out) as the source code would end up using its own default value of “1”.

14

Guess I am a bit confused (but that’s ok).
The defaults are set to “0” and are not commented out.
Interesting that the source sets it to “1”.
The comments in the config file suggest it is set to “0” "if you do nothing.
Which may also mean the fact that it is set to “0” by the config file (if you do nothing). :slight_smile:
As that would be overidden by the not commented out setting it to zero as it is.

15

Let’s try this again :

  • The channel driver starts up and initializes all of its variables. For the “eeprom” variable the value is set to “1”
  • The channel driver then starts to process the configuration file.
    • If we do not find an “eeprom = 0/1” line in the file (or the line is present but it’s a comment) then the value is still “1”
    • If we do find an “eeprom = 0/1” line in the file then this value overrides the initial value

As the channel driver code is executed the “eeprom” variable is checked. If the value is “0” then there should be no EEPROM reads/writes. If the value is “1” then the driver code looked like it would be reading (accessing) the EEPROM.

My assumption was that the code was being executed, that the reads were failing, and that the log messages were driven by the read errors… If the .conf file included “eeprom = 0” then my assumptions (or what I was seeing in the code) must be off.