Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #3603 > unrolled thread

Intriguing issue

Back to article view | Back to comp.os.linux.hardware

Contents

  Intriguing issue "James H. Markowitz" <noone@nowhere.net> - 2023-01-09 20:17 +0000
    Re: Intriguing issue Marco Moock <mo01@posteo.de> - 2023-01-09 21:36 +0100
    Re: Intriguing issue mjb@signal11.invalid (Mike) - 2023-01-10 20:57 +0000
    Re: Intriguing issue Theo <theom+news@chiark.greenend.org.uk> - 2023-01-11 22:23 +0000
      Re: Intriguing issue "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2023-01-11 18:31 -0500
        Re: Intriguing issue "James H. Markowitz" <noone@nowhere.net> - 2023-01-12 19:21 +0000
          Re: Intriguing issue "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2023-01-12 18:32 -0500
            Re: Intriguing issue "James H. Markowitz" <noone@nowhere.net> - 2023-01-13 15:03 +0000
              Re: Intriguing issue "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2023-01-13 16:23 -0500
        Re: Intriguing issue Theo <theom+news@chiark.greenend.org.uk> - 2023-01-13 12:51 +0000
    Re: Intriguing issue "James H. Markowitz" <noone@nowhere.net> - 2023-01-14 20:04 +0000
      Re: Intriguing issue Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2023-01-15 09:17 +0000
        Re: Intriguing issue "James H. Markowitz" <noone@nowhere.net> - 2023-01-15 13:36 +0000
          Re: Intriguing issue Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2023-01-16 07:14 +0000
            Re: Intriguing issue Andrew <Doug@hyperspace.vogon.gov> - 2023-01-16 10:06 +0100
              Re: Intriguing issue Eric Pozharski <whynot@pozharski.name> - 2023-01-16 15:00 +0000
                Re: Intriguing issue John-Paul Stewart <jpstewart@personalprojects.net> - 2023-01-16 15:28 -0500
              Re: Intriguing issue "Carlos E.R." <robin_listas@es.invalid> - 2023-01-16 20:47 +0100
                Re: Intriguing issue "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2023-01-16 17:08 -0500
        Re: Intriguing issue "Carlos E. R." <robin_listas@es.invalid> - 2024-11-08 13:57 +0100

#3603 — Intriguing issue

	I have an external USB hard drive connected to a Linux system. 
When I invoke dmesg -T I get diagnostics like the following:

        Mon Jan  9 12:28:08 2023] usb 2-1.4: reset high-speed USB device 
number 7 using ehci-pci

I am guessing that there is some hardware issue with this device. The 
thing is, that kind of diagnostic is logged by the kernel exactly every 
50 minutes. Let me emphasize this: exactly every 3,000 seconds. Not 
3,001, or 2,999, but 3,000.

	Anybody have any idea as to why it is exactly 50 minutes? What id 
it that may be so special about 50 minutes?

[toc] | [next] | [standalone]

#3604

Am 09.01.2023 um 20:17:09 Uhr schrieb James H. Markowitz:

> 	Anybody have any idea as to why it is exactly 50 minutes?
> What id it that may be so special about 50 minutes?

Please don't use that annoying indentation.

Maybe that drive goes into a standby mode.

A user in that German forum reported that a faulty device caused these
resets.
https://debianforum.de/forum/viewtopic.php?t=155002

Maybe disconnect all other devices and see if is still occurs.

[toc] | [prev] | [next] | [standalone]

#3605

In article <tphso5$8cv$1@gioia.aioe.org>,
James H. Markowitz <noone@nowhere.net> wrote:

>        Mon Jan  9 12:28:08 2023] usb 2-1.4: reset high-speed USB device 
>number 7 using ehci-pci

>I am guessing that there is some hardware issue with this device. 

Maybe. Maybe not. I have a Topfield TF5800 PVR, whenever it is tranferring files 
over USB to a connected Linux machine, I get a constant stream of these in 
/var/log/messages :-

...
Dec 20 11:17:28 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:17:29 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:21:03 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:21:04 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:23:59 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:24:00 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:26:56 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:26:57 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:31:04 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:31:05 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:36:37 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:36:38 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:39:23 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:39:23 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46

Dec 20 11:41:32 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
Dec 20 11:41:33 posie kernel: usb 1-4: reset high speed USB device using ehci_hcd and address 46
...

But otherwise everything works fine, the PVR is working ok, all files are 
transferred cleanly.

This only occurs during constant file transfer, not with the device just 
"connected and idle", no messages there at all.
-- 
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk  |    http://www.signal11.org.uk

[toc] | [prev] | [next] | [standalone]

#3606

James H. Markowitz <noone@nowhere.net> wrote:
>         Mon Jan  9 12:28:08 2023] usb 2-1.4: reset high-speed USB device 
> number 7 using ehci-pci
> 
> I am guessing that there is some hardware issue with this device. The 
> thing is, that kind of diagnostic is logged by the kernel exactly every 
> 50 minutes. Let me emphasize this: exactly every 3,000 seconds. Not 
> 3,001, or 2,999, but 3,000.
> 
>         Anybody have any idea as to why it is exactly 50 minutes? What id 
> it that may be so special about 50 minutes?

It could be some kind of communication difficulty, which could be a hardware
issue or noisy cabling or something else.  Do you have any electrical
appliances which might kick in on a 50 minute frequency?  If there was a
nearby motor or something and you had a bad USB cable, that might cause
enough to disrupt communication.

Try changing the cable?

Theo

[toc] | [prev] | [next] | [standalone]

#3607

On Wed, 11 Jan 2023 17:23:22 -0500, Theo <theom+news@chiark.greenend.org.uk> wrote:

> James H. Markowitz <noone@nowhere.net> wrote:
>>         Mon Jan  9 12:28:08 2023] usb 2-1.4: reset high-speed USB device
>> number 7 using ehci-pci
>>
>> I am guessing that there is some hardware issue with this device. The
>> thing is, that kind of diagnostic is logged by the kernel exactly every
>> 50 minutes. Let me emphasize this: exactly every 3,000 seconds. Not
>> 3,001, or 2,999, but 3,000.
>>
>>         Anybody have any idea as to why it is exactly 50 minutes? What id
>> it that may be so special about 50 minutes?
>
> It could be some kind of communication difficulty, which could be a hardware
> issue or noisy cabling or something else.  Do you have any electrical
> appliances which might kick in on a 50 minute frequency?  If there was a
> nearby motor or something and you had a bad USB cable, that might cause
> enough to disrupt communication.
>
> Try changing the cable?

From
https://access.redhat.com/solutions/194273
"This error indicates that USB 2.0 may not function on your system, or may function only at USB 1.1 speeds."

See https://bbs.archlinux.org/viewtopic.php?id=89688 for disabling ehci-pci.

Regards, Dave Hodgins

[toc] | [prev] | [next] | [standalone]

#3608

	I tried on a different system with a different cable and at a 
different location, and the same diagnostic keeps getting logged, with 
the same frequency. I'll try disabling ehci_pci.

[toc] | [prev] | [next] | [standalone]

#3609

On Thu, 12 Jan 2023 14:21:23 -0500, James H. Markowitz <noone@nowhere.net> wrote:

> 	I tried on a different system with a different cable and at a
> different location, and the same diagnostic keeps getting logged, with
> the same frequency. I'll try disabling ehci_pci.

If that doesn't resolve the issue, try disabling pci power management instead as
the power management may be affecting the usb controller. To do so add the kernel
boot parameter's "pcie_port_pm=off pcie_aspm=off".

Regards, Dave Hodgins

[toc] | [prev] | [next] | [standalone]

#3611

On Thu, 12 Jan 2023 18:32:53 -0500, David W. Hodgins wrote:

> On Thu, 12 Jan 2023 14:21:23 -0500, James H. Markowitz
> <noone@nowhere.net> wrote:
> 
>> 	I tried on a different system with a different cable and at a
>> different location, and the same diagnostic keeps getting logged, with
>> the same frequency. I'll try disabling ehci_pci.
> 
> If that doesn't resolve the issue, try disabling pci power management
> instead as the power management may be affecting the usb controller. To
> do so add the kernel boot parameter's "pcie_port_pm=off pcie_aspm=off".

	Not only did it not solve anything, but it created major 
problems, for I forgot I have a wireless keyboard/mouse combo that relies 
on it. Fortunately, I could access the system over ssh and re-enable 
ehci_pci.

	At this point I am satisfied (well, not quite satisfied, but you 
know what I mean) that the drive itself is dodgy.

[toc] | [prev] | [next] | [standalone]

#3612

On Fri, 13 Jan 2023 10:03:08 -0500, James H. Markowitz <noone@nowhere.net> wrote:

> On Thu, 12 Jan 2023 18:32:53 -0500, David W. Hodgins wrote:
>
>> On Thu, 12 Jan 2023 14:21:23 -0500, James H. Markowitz
>> <noone@nowhere.net> wrote:
>>
>>> 	I tried on a different system with a different cable and at a
>>> different location, and the same diagnostic keeps getting logged, with
>>> the same frequency. I'll try disabling ehci_pci.
>>
>> If that doesn't resolve the issue, try disabling pci power management
>> instead as the power management may be affecting the usb controller. To
>> do so add the kernel boot parameter's "pcie_port_pm=off pcie_aspm=off".
>
> 	Not only did it not solve anything, but it created major
> problems, for I forgot I have a wireless keyboard/mouse combo that relies
> on it. Fortunately, I could access the system over ssh and re-enable
> ehci_pci.
>
> 	At this point I am satisfied (well, not quite satisfied, but you
> know what I mean) that the drive itself is dodgy.

Disabling power management should not impact the wireless device.

Power management stops devices that are not in use. It improves battery lifetime
on laptops, but is not much use on a system that's plugged in. Disabling power
management keeps the devices turned on all of the time.

I have "pcie_port_pm=off pcie_aspm=off" in my kernel options. It doesn't stop
my wireless keyboard/mouse using a logitech usb dongle from working.

If the reset is not causing any issues, just ignore it. I don't think it's a
sign of a problem with the drive.

Regards, Dave Hodgins

[toc] | [prev] | [next] | [standalone]

#3610

David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> From
> https://access.redhat.com/solutions/194273
> "This error indicates that USB 2.0 may not function on your system, or may function only at USB 1.1 speeds."

Good to see Redhat are following Microsoft in non-answer answers.

EHCI is the USB 2 host controller standard, so it's a problem with USB 2. 
But it doesn't say *why* it's a problem with USB2.  All the message tells us
is the USB stack got to a point where it got nothing sensible out of the
device and was forced to reset it.  It doesn't know why it got like that.

Typically that means either a cabling problem or a device-side problem (much
more likely than a 'replace the motherboard').

> See https://bbs.archlinux.org/viewtopic.php?id=89688 for disabling ehci-pci.

Disabling EHCI will force USB 1.1 speeds (12Mbps), but for most devices that
makes them useless.

It is likely to be a hardware side issue, so things like:
* Changing the cabling
* Remove or change any hubs
* Checking hub power supplies
* Check device firmware is up to date

would be worth trying.

One other thing is to try a USB 3.0 hub, assuming the port supports that. 
That (should) change the offboard communication to use USB 3 signalling (and
the XHCI host controller standard), which might not suffer an issue related
to something USB 2 specific.  If it doesn't work, at least it'll illuminate
the problem.

Theo

[toc] | [prev] | [next] | [standalone]

#3613

On Mon, 9 Jan 2023 20:17:09 -0000 (UTC), James H. Markowitz wrote:

> I have an external USB hard drive connected to a Linux system.
> When I invoke dmesg -T I get diagnostics like the following:
> 
>         Mon Jan  9 12:28:08 2023] usb 2-1.4: reset high-speed USB device
> number 7 using ehci-pci
> 
> I am guessing that there is some hardware issue with this device. The
> thing is, that kind of diagnostic is logged by the kernel exactly every
> 50 minutes. Let me emphasize this: exactly every 3,000 seconds. Not
> 3,001, or 2,999, but 3,000.
> 
> 	Anybody have any idea as to why it is exactly 50 minutes? What id
> it that may be so special about 50 minutes?

	It is getting curioser and curioser: I have tried with three more 
systems, and the diagnostic keeps reappearing in two of them - with the 
same clockwork 50 minutes frequency - but not at all in the third one - 
at least it has not for a few days now. Interestingly, this last system 
is the oldest one of the lot. They are all running exactly the same Linux 
version.

	I am mystified. 

[toc] | [prev] | [next] | [standalone]

#3614

On Sat, 14 Jan 2023 20:04:09 +0000, James H. Markowitz wrote:
> I have tried with three more systems, and the diagnostic keeps
> reappearing in two of them - with the same clockwork 50 minutes
> frequency - but not at all in the third one - at least it has not for a
> few days now. Interestingly, this last system is the oldest one of the
> lot. They are all running exactly the same Linux version.

Could it be that the third, oldest system only has USB1.1 and lacks USB2? 
Is the ehci_pci module loaded also on that system?

lsmod | grep hc
xhci_pci               20480  0
xhci_pci_renesas       16384  1 xhci_pci
ehci_pci               16384  0
xhci_hcd              286720  1 xhci_pci
ehci_hcd               65536  1 ehci_pci

regards Henrik

[toc] | [prev] | [next] | [standalone]

#3615

On Sun, 15 Jan 2023 09:17:56 -0000 (UTC), Henrik Carlqvist wrote:

> On Sat, 14 Jan 2023 20:04:09 +0000, James H. Markowitz wrote:
>> I have tried with three more systems, and the diagnostic keeps
>> reappearing in two of them - with the same clockwork 50 minutes
>> frequency - but not at all in the third one - at least it has not for a
>> few days now. Interestingly, this last system is the oldest one of the
>> lot. They are all running exactly the same Linux version.
> 
> Could it be that the third, oldest system only has USB1.1 and lacks
> USB2?
> Is the ehci_pci module loaded also on that system?
> 
> lsmod | grep hc xhci_pci               20480  0 xhci_pci_renesas      
> 16384  1 xhci_pci ehci_pci               16384  0 xhci_hcd             
> 286720  1 xhci_pci ehci_hcd               65536  1 ehci_pci
> 
> regards Henrik

	This is what I get in that particular system:

smod | grep hci
ohci_pci               16384  0
ohci_hcd               49152  1 ohci_pci
ehci_pci               16384  0
ehci_hcd               65536  1 ehci_pci

In the others, in which the diagnostic does appear, the ohci lines are 
absent.

[toc] | [prev] | [next] | [standalone]

#3616

On Sun, 15 Jan 2023 13:36:01 +0000, James H. Markowitz wrote:
> 	This is what I get in that particular system:
> 
> smod | grep hci ohci_pci               16384  0 ohci_hcd              
> 49152  1 ohci_pci ehci_pci               16384  0 ehci_hcd              
> 65536  1 ehci_pci
> 
> In the others, in which the diagnostic does appear, the ohci lines are
> absent.

The fact that you have both ohci and ehci lines on the older system means 
that it has both USB1.1 (Open Host Controller Interface) and USB2 
(Enhanced Host Controller Interface) controllers.

Could it be that you connected the external USB hard drive to a USB1.1 
port?

regards Henrik

[toc] | [prev] | [next] | [standalone]

#3617

Henrik Carlqvist wrote:
> On Sun, 15 Jan 2023 13:36:01 +0000, James H. Markowitz wrote:
>> 	This is what I get in that particular system:
>>
>> smod | grep hci ohci_pci               16384  0 ohci_hcd
>> 49152  1 ohci_pci ehci_pci               16384  0 ehci_hcd
>> 65536  1 ehci_pci
>>
>> In the others, in which the diagnostic does appear, the ohci lines are
>> absent.
> 
> The fact that you have both ohci and ehci lines on the older system means
> that it has both USB1.1 (Open Host Controller Interface) and USB2
> (Enhanced Host Controller Interface) controllers.
> 
> Could it be that you connected the external USB hard drive to a USB1.1
> port?
> 
> regards Henrik
> 

Just as an aside: were there such systems?  I remember USB2 as having 
replaced 1.1 immediately, not least because they were compatible.  I 
suppose it would have been possible to have had 1.1 on board and 2 via a 
card.
The USB2 specs were released in April 2000, how long would it have taken 
before motherboards with 1.x were no longer being sold?

[toc] | [prev] | [next] | [standalone]

#3618

with <tq342s$f6$1@gioia.aioe.org> Andrew wrote:
> Henrik Carlqvist wrote:
>> On Sun, 15 Jan 2023 13:36:01 +0000, James H. Markowitz wrote:

*SKIP*
>>> In the others, in which the diagnostic does appear, the ohci lines
>>> are absent.
*SKIP*
>> Could it be that you connected the external USB hard drive to a
>> USB1.1 port?
*SKIP*
> The USB2 specs were released in April 2000, how long would it have
> taken before motherboards with 1.x were no longer being sold?

About a decade, apprently

% lsusb -t
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
    |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
    |__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 1.5M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
    |__ Port 2: Dev 2, If 0, Class=stor., Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M

When I've comprehended what that means I was shocked.  I repeat,
SHOCKED.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#3620

On 1/16/23 10:00, Eric Pozharski wrote:
> with <tq342s$f6$1@gioia.aioe.org> Andrew wrote:
>> Henrik Carlqvist wrote:
>>> On Sun, 15 Jan 2023 13:36:01 +0000, James H. Markowitz wrote:
> 
> *SKIP*
>>>> In the others, in which the diagnostic does appear, the ohci lines
>>>> are absent.
> *SKIP*
>>> Could it be that you connected the external USB hard drive to a
>>> USB1.1 port?
> *SKIP*
>> The USB2 specs were released in April 2000, how long would it have
>> taken before motherboards with 1.x were no longer being sold?
> 
> About a decade, apprently
> 
> % lsusb -t
> /:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M
> /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
> /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
>     |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
>     |__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 1.5M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
>     |__ Port 2: Dev 2, If 0, Class=stor., Driver=usb-storage, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
>     |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M
> 
> When I've comprehended what that means I was shocked.  I repeat,
> SHOCKED.

Actually, that's just the way it worked back then.  EHCI didn't replace
OHCI/UHCI, it ran along side them.

From the Wikipedia "Host Controller Interface" article:

"Originally a PC providing high-speed ports had two controllers, one
handling low- and full-speed devices and the second handling high-speed
devices. Typically such a system had EHCI and either OHCI or UHCI drivers."

https://en.wikipedia.org/wiki/Host_controller_interface_(USB%2C_Firewire)#Enhanced_Host_Controller_Interface

[toc] | [prev] | [next] | [standalone]

#3619

On 2023-01-16 10:06, Andrew wrote:
> Henrik Carlqvist wrote:
>> On Sun, 15 Jan 2023 13:36:01 +0000, James H. Markowitz wrote:
>>>     This is what I get in that particular system:
>>>
>>> smod | grep hci ohci_pci               16384  0 ohci_hcd
>>> 49152  1 ohci_pci ehci_pci               16384  0 ehci_hcd
>>> 65536  1 ehci_pci
>>>
>>> In the others, in which the diagnostic does appear, the ohci lines are
>>> absent.
>>
>> The fact that you have both ohci and ehci lines on the older system means
>> that it has both USB1.1 (Open Host Controller Interface) and USB2
>> (Enhanced Host Controller Interface) controllers.
>>
>> Could it be that you connected the external USB hard drive to a USB1.1
>> port?

> Just as an aside: were there such systems? 

Certainly, I have one. I had to add usb 2 with a card.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#3621

On Mon, 16 Jan 2023 14:47:34 -0500, Carlos E.R. <robin_listas@es.invalid> wrote:
>>> The fact that you have both ohci and ehci lines on the older system means
>>> that it has both USB1.1 (Open Host Controller Interface) and USB2
>>> (Enhanced Host Controller Interface) controllers.
>>>
>>> Could it be that you connected the external USB hard drive to a USB1.1
>>> port?
>
>> Just as an aside: were there such systems?
>
> Certainly, I have one. I had to add usb 2 with a card.

I have all three o, e and x for ports on my motherboard with a bios dated
10/16/2012.

# lsusb -t|grep hci
/:  Bus 11.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
/:  Bus 10.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/:  Bus 09.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M

I make sure I use the blue usb 3.0 ports for drives.

Regards, Dave Hodgins

[toc] | [prev] | [next] | [standalone]

#3754

On 2023-01-15 10:17, Henrik Carlqvist wrote:
> On Sat, 14 Jan 2023 20:04:09 +0000, James H. Markowitz wrote:
>> I have tried with three more systems, and the diagnostic keeps
>> reappearing in two of them - with the same clockwork 50 minutes
>> frequency - but not at all in the third one - at least it has not for a
>> few days now. Interestingly, this last system is the oldest one of the
>> lot. They are all running exactly the same Linux version.
> 
> Could it be that the third, oldest system only has USB1.1 and lacks USB2?
> Is the ehci_pci module loaded also on that system?
That would be a two decades old system to lack usb2.

Now, lacking ubs3 would be more reasonable.


-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.hardware

csiph-web