On 07/12/24(Sat) 11:01, Landry Breuil wrote:
> hi,
> 
> so i have this EATON PRO 650 i'm tinkering with on my home gateway. On
> 7.6, if booting with the UPS plugged in, the port is disabled at boot:
> 
> /bsd: uhub0: device problem, disabling port 6

This is a known issue in our USB stack.  I don't know exactly what it
is.

> and the upd(4) device isn't available for sensorsd, which is.. annoying.
> i have yet to figure out which error case in usbd_new_device() is hit.
> 
> if plugging the UPS after boot on that same 7.6-stable box, it is correctly
> detected, and i have a handful of uhidev:
> 
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
> uhidev2 at uhub0 port 6 configuration 1 interface 0 "EATON Ellipse PRO" rev 1.10/1.00 addr 5
> uhidev2: iclass 3/0, 255 report ids
> upd0 at uhidev2
> uhid2 at uhidev2 reportid 2: input=4, output=0, feature=4
> uhid3 at uhidev2 reportid 3: input=5, output=0, feature=5
> uhid4 at uhidev2 reportid 4: input=5, output=0, feature=5
> uhid5 at uhidev2 reportid 6: input=4, output=0, feature=4
> uhid6 at uhidev2 reportid 7: input=0, output=0, feature=2
> uhid7 at uhidev2 reportid 8: input=0, output=0, feature=1
> uhid8 at uhidev2 reportid 9: input=0, output=0, feature=4
> uhid9 at uhidev2 reportid 10: input=0, output=0, feature=4
> uhid10 at uhidev2 reportid 11: input=0, output=0, feature=14
> uhid11 at uhidev2 reportid 12: input=0, output=0, feature=6
> uhid12 at uhidev2 reportid 13: input=0, output=0, feature=3
> uhid13 at uhidev2 reportid 14: input=0, output=0, feature=1
> uhid14 at uhidev2 reportid 15: input=0, output=0, feature=2
> uhid15 at uhidev2 reportid 16: input=0, output=0, feature=6
> uhid16 at uhidev2 reportid 17: input=0, output=0, feature=1
> uhid17 at uhidev2 reportid 18: input=0, output=0, feature=1
> uhid18 at uhidev2 reportid 19: input=0, output=0, feature=2
> uhid19 at uhidev2 reportid 20: input=0, output=0, feature=1
> uhid20 at uhidev2 reportid 21: input=0, output=0, feature=1
> uhid21 at uhidev2 reportid 22: input=0, output=0, feature=1
> uhid22 at uhidev2 reportid 23: input=0, output=0, feature=5
> uhid23 at uhidev2 reportid 24: input=0, output=0, feature=10
> uhid24 at uhidev2 reportid 25: input=0, output=0, feature=1
> uhid25 at uhidev2 reportid 26: input=0, output=0, feature=1
> uhid26 at uhidev2 reportid 31: input=0, output=0, feature=1
> uhid27 at uhidev2 reportid 32: input=0, output=0, feature=1
> uhid28 at uhidev2 reportid 34: input=0, output=0, feature=1
> uhid29 at uhidev2 reportid 253: input=0, output=0, feature=1
> uhid30 at uhidev2 reportid 254: input=0, output=0, feature=10
> uhid31 at uhidev2 reportid 255: input=0, output=0, feature=63
> 
> my understanding is that some of those are used by upd for the various sensors
> reporting, but they're not "claimed", so still available for userland/libusb to
> use them (eg sysutils/nut or sysutils/apcupsd ? i'm not even sure they use the
> uhidXX devices)
> 
> do other people with upd(4) devices also see that many uhid devices ?
> 
> on my laptop running -current, where i play with various diffs to try detecting
> more sensors and fix the broken RunTimeToEmpty one:
> - if i plug the UPS before BIOS POST, it refuses to boot (eg stays on blank
>   screen, not showing the lenovo POST screen)
> - if i plug the UPS after BIOS POST, during boot it detaches all uhid devices
>   because of a 'hotplug queue full', then reattaches them, and from that point

I doubt it is *because of* a 'hotplug queue full'.  This just indicates
that an hotplug message has been lost.

Is it when you see the "uhub0 device problem"?

> works:
> 
> upd: sc_num_sensors=10
> upd_attach: complete
> uhid0 at uhidev0 reportid 2: input=4, output=0, feature=4
> ...
> uhid29 at uhidev0 reportid 255: input=0, output=0, feature=63
> upd0 detached
> uhid0 detached
> uhid1 detached
> ...
> uhid29 detached
> hotplug: event lost, queue full
> uhidev0 detached
> hotplug: event lost, queue full
> uhidev0 at uhub0 port 2 configuration 1 interface 0 "EATON Ellipse PRO" rev 1.10/1.00 addr 2
> uhidev0: iclass 3/0, 255 report ids
> ...
> upd: sc_num_sensors=10
> upd_attach: complete
> uhid0 at uhidev0 reportid 2: input=4, output=0, feature=4
> ...
> uhid29 at uhidev0 reportid 255: input=0, output=0, feature=63
> upd0: read 4 bytes for RunTimeToEmpty, got 524900, adjust=3906250, sensor val=2050390625000
> 
> bumping HOTPLUG_MAXEVENTS makes the UPS attach directly at boot on my laptop,
> but .. i'm not sure this is "right".

Which could indicate there is a timing issue involved.  Bumping this
value changes the behavior of hotplug_device_attach() and make it
execute more non-trivial code.

Does the detach always happen at the same moment?  Could you investigate
where is there some delay missing?

> and i'm not sure either this will fix the 'disabling port 6' issue i'm seeing
> on my gateway.

They might be related.

> Thoughts ? diff below.

Bumping this might make sense if machines with more than 64 devices are
common.  However I'd argue that in the case of your upd(4), which
accounts for 32 devices, it would be better to support more deviceIDs
(sensors) and attach fewer uhid(4).

> Index: hotplug.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/hotplug.c,v
> diff -u -r1.24 hotplug.c
> --- hotplug.c   22 Sep 2023 22:12:32 -0000      1.24
> +++ hotplug.c   7 Dec 2024 09:42:14 -0000
> @@ -29,7 +29,7 @@
>  #include <sys/mutex.h>
>  #include <sys/vnode.h>
>  
> -#define HOTPLUG_MAXEVENTS      64
> +#define HOTPLUG_MAXEVENTS      128
>  
>  /*
>   * Locks used to protect struct members and global data
>