Help me resolve a USB problem

[root]

I run at night. When I finish I come home and connect
my Garmin 305 Forerunner to track my results. Last Thursday
when I connected the Garmin I found the USB device
was busy. After a few tries of connecting and disconnecting
I wanted to go to sleep so I left the problem for Friday
morning.

Friday morning the Garmin connected without any problems.

After running last night the Garmin would not connect again.

This time I tracked the problem down to what happens when
the Garmin is connected: now a directory /sys/bus/usb/drivers/garmin_gps
is created. Prior to this that directory was not present.

In 15.2, USB devices lock up USB storage and you have to
(open) unbind that lockup with a command such as:

echo -n SOMETHING >/sys/bus/usb/drivers/SOMEWHERE/unbind

For my Garmin device SOMETHING is (usually) 1-11:1.0:
and the SOMEWHERE was usb. Now SOMEWHERE has to be
garmin_gps.

My problem is that nothing was intentionally changed between Tuesday
last and last Thursday in my system. Nor was anything changed between
last Thursday night and last Friday morning, nor any change over the
weekend.

What could possibly describe the intermittent changes to
the USB device connection?

[Henrik Carlqvist]

On Mon, 07 Nov 2022 20:25:49 +0000, root wrote:
> What could possibly describe the intermittent changes to the USB device
> connection?

I can only think of 3 things that could cause such changes:

1) Changes in the kernel (did you update the kernel?)

2) Changes in udev settings (did you change anything in /etc/udev/rules.d)

3) Changes in the USB device (check your logs if if still presents itself
with the same vendor and product id)

regards Henrik

[root]

Thanks for responding Henrik. The last time I updated the kernel
was back in August. I only have one entry the 70-net... rule
in udev, and the device itself hasn't ever changed. I can't say
whether dmesg reported some change in the device because of the
passage of time. I have a work-around by issuing (now) two
unbind echoes because an ineffective echo only results in
an error message.

My guess is that there is something undefined in the driver and
that can change from one bootup to the next.

[Henrik Carlqvist]

On Tue, 08 Nov 2022 15:09:58 +0000, root wrote:

> I can't say whether dmesg reported some change in the device because of
> the passage of time.

All messages from dmesg will be reset at each reboot, but if you are
lucky, you will find the things you are looking for in /var/log/messages
which you can compare with the compressed contents of /var/log/
messages.1.gz and others.

regards Henrik

[Joseph Rosevear]

I'm wondering if you rebooted between attempts?

I don't know if that could cause it or not, but I'm wondering if it might
have something to do with the order in which the kernel recognizes and
names the devices.

I ran a test and I could not get a "device busy" response. If a device
is mounted and you mount it again, it seems to work fine--it is just
mounted twice. Do you see where I'm going with this? An fstab file that
refers to devices by name will only trigger a mount at boot when the
kernel has given the device the same name as is in your fstab. But as I
said I could not get a "device busy" response.

Hmmm. Am I barking up the wrong tree?

-Joe