On 9/16/2022 8:02 PM, Adam wrote:
> On 09/16/2022 11:31 AM, Paul wrote:
>> On 9/16/2022 10:20 AM, Adam wrote:
>>> On 09/16/2022 01:30 AM, Paul wrote:
>>>> On 9/15/2022 9:00 PM, Adam wrote:
>>>>> On 09/15/2022 07:24 AM, Paul wrote:
>>>>>> On 9/15/2022 1:46 AM, Adam wrote:
>>>>>>
>>>>>>>
>>>>>>> Separate USB annoyance I encountered today while trying to scan a
>>>>>>> document via USB connection between scanner and laptop.  Simple Scan
>>>>>>> kept failing to scan saying Device Not Found until I inserted a USB
>>>>>>> dongle...
>>>>>>>
>>>>>>> Belkin USB 2.0 4-Port Ultra-Mini Hub
>>>>>>> https://www.amazon.com/gp/product/B000Q8UAWY/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Why?  Seems like there's no rhyme or reason.
>>>>>>
>>>>>> Try:
>>>>>>
>>>>>>     lsusb -tv
>>>>>>
>>>>>> both before, and after, the hardware cabling changes.
>>>>>>
>>>>>> Look for differences (other than the obvious ones).
>>>>>>
>>>>>>     Paul
>>>>>>
>>>>>
>>>>> Scanner not connected to laptop...
>>>>>
>>>>> xerus@ThinkPad-T430:~$ lsusb -tv
>>>>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
>>>>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>>>>>          |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class,
>>>>> Driver=, 12M
>>>>>          |__ Port 6: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
>>>>>          |__ Port 6: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
>>>>> xerus@ThinkPad-T430:~$
>>>>>
>>>>>
>>>>> Scanner connected directly to laptop (without Belkin USB 2.0 4-Port
>>>>> Ultra-Mini Hub)...
>>>>>
>>>>> xerus@ThinkPad-T430:~$ lsusb -tv
>>>>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
>>>>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>>>>>          |__ Port 2: Dev 29, If 0, Class=(Defined at Interface level),
>>>>> Driver=, 12M
>>>>>          |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class,
>>>>> Driver=, 12M
>>>>>          |__ Port 6: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
>>>>>          |__ Port 6: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
>>>>> xerus@ThinkPad-T430:~$
>>>>>
>>>>>
>>>>> Scanner connected to Belkin USB 2.0 4-Port Ultra-Mini Hub, which is
>>>>> connected to laptop...
>>>>>
>>>>> xerus@ThinkPad-T430:~$ lsusb -tv
>>>>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
>>>>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>>>>>          |__ Port 2: Dev 25, If 0, Class=Hub, Driver=hub/4p, 480M
>>>>>              |__ Port 3: Dev 26, If 0, Class=(Defined at Interface
>>>>> level), Driver=, 12M
>>>>>          |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class,
>>>>> Driver=, 12M
>>>>>          |__ Port 6: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
>>>>>          |__ Port 6: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
>>>>> xerus@ThinkPad-T430:~$
>>>>
>>>> There's nothing abnormal there, so far. In terms of behavior, like
>>>> something showing up when you expect it to show up.
>>>>
>>>> This is my other machine with the mkusb in it.
>>>>
>>>> ubuntu@ubuntu:~$ lsusb -tv
>>>> /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>>>>      ID 1d6b:0003 Linux Foundation 3.0 root hub
>>>>      |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
>>>>          ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s
>>>> bridge   <=== USB boot drive
>>>> /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>>>>      ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>>>>      ID 1d6b:0003 Linux Foundation 3.0 root hub
>>>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>>>>      ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>>>      ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>>>>          ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
>>>>          |__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
>>>>              ID 05e3:0608 Genesys Logic, Inc. Hub
>>>>              |__ Port 4: Dev 6, If 0, Class=Human Interface Device,
>>>> Driver=usbhid, 1.5M
>>>>                  ID 045e:076c Microsoft Corp. Comfort Mouse 4500
>>>>          |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
>>>>              ID 05e3:0608 Genesys Logic, Inc. Hub
>>>>              |__ Port 4: Dev 7, If 0, Class=Human Interface Device,
>>>> Driver=usbhid, 12M
>>>>                  ID 125f:9318 A-DATA Technology Co., Ltd.
>>>>              |__ Port 4: Dev 7, If 1, Class=Human Interface Device,
>>>> Driver=usbhid, 12M
>>>>                  ID 125f:9318 A-DATA Technology Co., Ltd.
>>>>          |__ Port 7: Dev 5, If 0, Class=Vendor Specific Class,
>>>> Driver=btusb, 12M
>>>>              ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0
>>>> Bluetooth
>>>>          |__ Port 7: Dev 5, If 1, Class=Vendor Specific Class,
>>>> Driver=btusb, 12M
>>>>              ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0
>>>> Bluetooth
>>>>          |__ Port 7: Dev 5, If 2, Class=Vendor Specific Class,
>>>> Driver=btusb, 12M
>>>>              ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0
>>>> Bluetooth
>>>>          |__ Port 7: Dev 5, If 3, Class=Application Specific Interface,
>>>> Driver=, 12M
>>>>              ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0
>>>> Bluetooth
>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>>>      ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>>>>          ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
>>>> ubuntu@ubuntu:~$
>>>>
>>>> *******
>>>>
>>>> Notice how mine has the numbers, like  8087:0024
>>>>
>>>> Yours does not.
>>>>
>>>> This means, somehow, the process to enumerate hardware either
>>>> isn't running, or there is an elevation problem (not enough
>>>> permissions to read the USB config space).
>>>>
>>>> If you can find a log, maybe there's something in there which
>>>> indicates why the devices are not getting read properly.
>>>
>>> Here's the first ~100 lines of /var/log/syslog (showing error)...
>>>
>
> <snip>
>
>>>
>>
>> Comment 1 at the bottom here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1369161
>>
>>    "Dan mentioned the commit [1] there that removed the legacy support
>>     for WEP cipher suites in group cipher announced in RSN IE"
>>
>> The regulatory database for the Wifi appears to have got updated.
>> That affects how the Wifi module behaves in different countries,
>> to follow country specific rules. Even 2.4GHz Wifi, does not have
>> the same band plan and channel numbers, in the US and Europe.
>>
>> So at least the dbus message does not mean that dbus failed.
>>
>> As for the extended period of the supplicant messing about,
>> I don't take that as a hardware failure, or a failure to
>> communicate on the USB bus. I don't think the root cause of the
>> USB problem is in there.
>
> Yes, the wifi error seems separate from the USB issue.
>
>>
>> It might have had something to do with what is in here.
>> But whatever is in cron.daily, could be kicking off a ton of
>> maintenance activity.
>>
>>      anacron[8538]: Job `cron.daily' terminated
>>      anacron[8538]: Normal exit (1 job run)
>>
>>     Paul
>
> xerus@ThinkPad-T430:~$ ls -l /etc/cron.daily/
> total 56
> -rwxr-xr-x 1 root root  311 Dec 28  2014 0anacron
> -rwxr-xr-x 1 root root  376 Mar 31  2016 apport
> -rwxr-xr-x 1 root root 1474 Apr 28  2021 apt-compat
> -rwxr-xr-x 1 root root  355 May 22  2012 bsdmainutils
> -rwxr-xr-x 1 root root  384 Oct  5  2014 cracklib-runtime
> -rwxr-xr-x 1 root root 1597 Nov 26  2015 dpkg
> -rwxr-xr-x 1 root root  372 May  5  2015 logrotate
> -rwxr-xr-x 1 root root 1293 Nov  6  2015 man-db
> -rwxr-xr-x 1 root root  435 Nov 17  2014 mlocate
> -rwxr-xr-x 1 root root  249 Nov 12  2015 passwd
> -rwxr-xr-x 1 root root 3449 Feb 26  2016 popularity-contest
> -rwxr-xr-x 1 root root  383 Sep 24  2018 samba
> -rwxr-xr-x 1 root root  214 Apr 12  2016 update-notifier-common
> -rwxr-xr-x 1 root root 1046 Feb 29  2016 upstart
> xerus@ThinkPad-T430:~$
>
> Should something be removed?
>

As I explained earlier, I was not able to find a match
on "lsusb does not show vid pid". I don't know what
is doing that.

Maintenance tasks can stop and start services, as part
of daily maintenance. It could be such a systemd command
that's screwing something up. I'm just surprised that
lsusb is able to get some information for preparation of
the table, yet cannot flesh out the vid pid numbers.
I'm assuming, the inability to see the scanner, is
somehow related to lsusb being unable to see the
numbers as well.

Perhaps some amount of the USB tree is successfully
detected and drivers loaded, by the boot process, but
the "lights out" problem happens later, and dynamic
detection of hot plug is not working.

They can't go into details of hotplug here, because a
Linux kernel is distro agnostic, and userland is the
responsibility of the distro creator.

https://www.kernel.org/doc/html/latest/driver-api/usb/hotplug.html

I'm not fingering "hotplug" with your symptoms. You can
try plugging in a USB stick, and if that is detected,
then I presume hotplug is working. And the VID and PID
are getting picked up for that device.

It's almost like userland is deprived of the numbers
at the moment, but perhaps the kernel is not. Maybe kernel
module support is still working, but if the scanner is
handled with a userland module, something there is
"blinding it" in the same way that lsusb is blinded.

I can't even find a decent diagram of the USB stack
at the moment. I could find some slide deck from
when they were inventing a USB stack, but that is too
old to be fully fleshed out. And this is very thorough,
but doesn't describe the "helper" that is likely causing
havoc in your case.

https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch13.html

It describes the making of Endpoints (connections) to a USB
device. And that's really an all-or-nothing with hardware.
We stop blaming the hardware, once the OS creates an Endpoint.
The Endpoint cannot be created, unless the hardware PHY is working
and the contacts are touching. lsusb is drawing the table right
now, of your defective device, and that takes Endpoints. Yet, it is
not able to display the VID and PID from that Endpoint. OK, what
part of the USB stack does that ? Dunno.

If lsusb does not require sudo, that implies it does not
access hardware directly. It's using a table created somewhere.
Now, what subsystem keeps that table for us ???

Part of tracking these things down, is finding "breadcrumbs",
keywords to feed into a search, when an earlier search yields
adverts for donuts. Google can be annoying, and almost all the time.

Paul