Intriguing issue

[James H. Markowitz]

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?

[Marco Moock]

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.

[Mike]

In article <tphso5$8cv$1...@gioia.aioe.org>,

James H. Markowitz <no...@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

[Theo]

James H. Markowitz <no...@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

[David W. Hodgins]

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

[James H. Markowitz]

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.

[David W. Hodgins]

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

[Theo]

David W. Hodgins <dwho...@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

[James H. Markowitz]

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.

[David W. Hodgins]

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

[James H. Markowitz]

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.

[Henrik Carlqvist]

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

[James H. Markowitz]

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.

[Henrik Carlqvist]

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

[Andrew]

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?

[Eric Pozharski]

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

[Carlos E.R.]

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.

[John-Paul Stewart]

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

[David W. Hodgins]

On Mon, 16 Jan 2023 14:47:34 -0500, Carlos E.R. <robin_...@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