Re: [gentoo-user] ehci-pci resume error What is this?

[Michael]

On Sunday, 10 July 2022 18:13:24 BST Dale wrote:
> Michael wrote:
> > On Sunday, 10 July 2022 16:34:08 BST Dale wrote:
> >> Howdy,
> >>
> >> I ran into a odd problem.  I'm not sure of the cause. I was trying to
> >> get pictures off my deer trail cameras when I noticed it.  I don't know
> >> if that is related or not.  This is the error.  Including a little over
> >> a second's worth so you can see how fast it is generating these entries
> >> in messages.
> >>
> >>
> >> root@fireball / # tail -f /var/log/messages
> >> Jul 10 10:17:21 fireball kernel: ehci-pci 0000:00:12.2: port 3 resume
> >> error -110
> >
> > [snip ...]
> >
> >> I did my usual updates the other day but not real sure how long this has
> >> been going on but log rotate seems to have been busy. The only way I
> >> found to stop it, stop the syslog service.  I did go to boot runlevel
> >> and restart udev and other device related services.  As soon as syslog
> >> starts up, it starts posting that error in messages.  Also, I'm using
> >> the same kernel for several months with no problems. I'm on
> >> 5.14.15-gentoo with a uptime of over 4 months.  Based on log rotation,
> >> I'd say this started about the time I did my updates in the last couple
> >> days.  Give or take. Can't recall command to get last weeks worth of
> >> updates.  Brain freeze.
> >>
> >> I tried google and found nothing helpful.  Anyone have a idea what this
> >> is all about?  Any clues?
> >>
> >> Thanks.
> >>
> >> Dale
> >>
> >> :-)  :-)
> >
> > dmesg ought to show a similar error.  The kernel is trying to read
> > whatever is hanging off your ehci-pci port 3 and it times out.  The error
> > message means "Timeout expired before the transfer completed".  It could
> > be a problematic device controller, or power demands of the device exceed
> > what the MoBo supplies.
> >
> > I've seen the same on USB 3.0 sticks which failed soon after, so you may
> > want to back up your data in the first instance.
>
> I found this info:
>
>
> 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
> SB7x0/SB8x0/SB9x0 USB EHCI Controller
>
>
> Right now, I don't have a lot of USB in use.  Mouse, UPS and a card
> reader, which I just unplugged with no change.  This is my USB devices now:
>
>
> root@fireball / # lsusb
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 002: ID 046d:c077 Logitech, Inc. Mouse
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 007: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 008 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
> Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> root@fireball / #
>
>
> Is there anyway to figure out which part is causing this?  I hope it
> isn't my UPS.  I got a spare rodent if it is that.  Oh, any way to stop
> it from filling dmesg?  It's spitting it out pretty fast. o_O
>
> Thoughts?
>
> Dale
>
> :-)  :-)

Does lsusb shed some light to the port which causes the interruptions?  
Otherwise can you unplug devices and plug them in one at a time?