search

home-assistant / operating-system

:beginner: Home Assistant Operating System
Apache License 2.0
4.77k stars 956 forks source link

Honeywell HGI80 USB Serial Device nonzero urb status, -75 #3287

Closed brucemiranda closed 5 months ago

brucemiranda commented 5 months ago

Describe the issue you are experiencing

I have an official Honeywell HGI80 USB to Serial device that has been working fine on HAOS for many years. However recently it has started having issues. The integration that reads this device just stops getting any data from it. The device uses the driver drivers/usb/serial/ti_usb_3410_5052.c

The HA Host logs show the following messages.

homeassistant kernel: usb 2-1: ti_bulk_in_callback - nonzero urb status, -75 2024-04-04 08:05:32.615 homeassistant kernel: usb 2-1: ti_bulk_in_callback - stopping read!

Then I looked in include/uapi/asm-generic/errno.h to find what error condition corresponds to the 75

define EOVERFLOW 75 /* Value too large for defined data

type */

So.. it looks like whatever value the driver read is larger (wrong datatype, probably) for where it was told to store it.

Unless anyone can think of some other reason for this this smells to me like the result of some other kernel or driver change that inadvertently broke something that my setup needs.

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

6.6.20-haos

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

Currently, as a work around I have an Automation that simply reloads the integration that is reading the USB serial device, and then everything starts to work again.

Anything in the Supervisor logs that might be useful for us?

NA

Anything in the Host logs that might be useful for us?

homeassistant kernel: usb 2-1: ti_bulk_in_callback - nonzero urb status, -75
2024-04-04 08:05:32.615 homeassistant kernel: usb 2-1: ti_bulk_in_callback - stopping read!

System information

System Information

version core-2024.4.0
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.12.2
os_name Linux
os_version 6.6.20-haos
arch x86_64
timezone Europe/London
config_dir /config
Home Assistant Community Store GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 5000 Installed Version | 1.34.0 Stage | running Available Repositories | 1410 Downloaded Repositories | 9
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Home Assistant OS 12.1 -- | -- update_channel | stable supervisor_version | supervisor-2024.03.1 agent_version | 1.6.0 docker_version | 24.0.7 disk_total | 62.3 GB disk_used | 12.3 GB healthy | true supported | true board | ova supervisor_api | ok version_api | ok installed_addons | Advanced SSH & Web Terminal (17.2.0), File editor (5.8.0), Dasshio (0.3.8), ESPHome (2024.3.1), Duck DNS (1.16.0), Nginx Proxy Manager (1.0.1), MariaDB (2.6.1)
Dashboards dashboards | 9 -- | -- resources | 2 views | 10 mode | storage
Recorder oldest_recorder_run | 25 March 2024 at 20:41 -- | -- current_recorder_run | 3 April 2024 at 21:21 estimated_db_size | 1083.05 MiB database_engine | sqlite database_version | 3.44.2

Additional information

I reached out to the original author of the driver

sairon commented 5 months ago

I see you already did your homework and found a same issue on the Domoticz forums. What seems suspicious to me is that the thread is almost 4 years old and the error manifests also on a way older kernel, so it doesn't seem like a standard stable kernel regressions we encounter. Or were you able to pinpoint HAOS version where it started to happen? You can upgrade/downgrade to a specific version using ha os upgrade --version X.Y, and it's generally without major side-effects within latest two major versions. Knowing what version is the breaking could give us some clues, otherwise we're quite in the dark...

brucemiranda commented 5 months ago

what I have managed to find now is that, if I enable USB 3.0 support for my VM running HSOS then the HGI80 has stayed up for over 24 hours. I have no idea if this is coincidence or something else has allowed this to stop failing.

maartenv86 commented 1 month ago

what I have managed to find now is that, if I enable USB 3.0 support for my VM running HSOS then the HGI80 has stayed up for over 24 hours. I have no idea if this is coincidence or something else has allowed this to stop failing.

Is it still running without any problems? At times I get the same problems on my HGI-80 module connected to my Synology NAS and running HAOS on a virtual machine. However, on the Synology if I set USB3.0 integration on the VM the HGI-80 will not connect so I have USB2.0 set.

brucemiranda commented 1 month ago

Yes everything is still running. I think this has nothing to do with the Linux kernel. It probably is a bug in the NAS VM software that manifests in this way. I also think that the HGI80 and it's driver need time to process stuff. And depending on what software you are using at the front end the HGI80 either struggles or not.