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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)