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