Bug 176913 - [ehci] High interrupt load with ehci
Summary: [ehci] High interrupt load with ehci
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-13 10:30 UTC by Christian Jurk
Modified: 2017-12-31 22:27 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Jurk 2013-03-13 10:30:01 UTC
The machine is having constantly high interrupt load.

# vmstat -i
cjurk@nodame:~% vmstat -i
interrupt                          total       rate
irq16: ehci0                  6264477215      85601
irq18: xhci0                    32405333        442
irq23: ehci1                     4689051         64
cpu0:timer                      29846776        407
irq264: hdac0                         62          0
irq265: re0                     93526302       1277
irq267: ahci0                     737621         10
cpu1:timer                      55424818        757
Total                         6481107178      88561

# dmesg | grep ehci
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xf7e08000-0xf7e083ff irq 16 at device 26.0 on pci0
usbus0 on ehci0
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xf7e07000-0xf7e073ff irq 23 at device 29.0 on pci0
usbus2 on ehci1

# top -S
last pid: 75321;  load averages:  0.17,  0.25,  0.24    up 0+20:22:38  11:20:28
70 processes:  2 running, 67 sleeping, 1 waiting
CPU:  0.0% user,  0.0% nice,  0.0% system, 27.4% interrupt, 72.6% idle
Mem: 46M Active, 792M Inact, 2863M Wired, 34M Cache, 408M Buf, 113M Free
Swap: 4096M Total, 7364K Used, 4089M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root          2 155 ki31     0K    32K RUN     1  31.2H 150.29% idle
   12 root         16 -84    -     0K   256K WAIT    0 200:06 50.49% intr
    0 root        156  -8    0     0K  2496K -       1 149:25  0.00% kernel
   15 root         13 -68    -     0K   208K -       0   7:22  0.00% usb
21961 root          4  -8    -     0K    80K tx->tx  0   2:27  0.00% zfskern
80209 cjurk         1  20    0 16560K  1328K select  0   1:22  0.00% top
    9 root          1  16    -     0K    16K syncer  1   1:12  0.00% syncer
   13 root          3  -8    -     0K    48K -       0   0:55  0.00% geom
   14 root          1 -16    -     0K    16K -       1   0:42  0.00% yarrow
22333 root          1  20    0 40724K  1044K nanslp  0   0:16  0.00% nmbd
 1157 root          1  20    0 12052K   532K select  0   0:16  0.00% powerd
29397 cjurk         1  20    0 22928K  1600K select  0   0:11  0.00% screen
 1154 root          1  20    0 22196K  1268K select  1   0:08  0.00% ntpd
   19 root          1 -16    -     0K    16K sdflus  1   0:06  0.00% softdepflu
    5 root          1 -16    -     0K    16K psleep  1   0:05  0.00% pagedaemon
   16 root          1 -16    -     0K    16K tzpoll  1   0:04  0.00% acpi_therm
 1181 root          1  20    0 20252K  2148K select  1   0:03  0.00% sendmail

The only device connected to USB is a external hard disk, which is used as storage disk (ZFS).
Comment 1 HPS 2013-03-13 11:00:23 UTC
Hi,

If you boot a custom kernel without device ehci, is the problem still 
the same? I suspect it is not an USB issue.

--HPS
Comment 2 Christian Jurk 2013-03-13 17:08:28 UTC
Not sure if that problem is directly a USB problem, might be better to =
move it into a more appropriate category if possible.

What I did recently: Did a reboot (by using command `reboot') - the =
system did not reboot on its own. All I got on the screen was:

Syncing disks, vnodes remaining=859 2 2 2 1 1 1 0 0 done
All buffers synced.
Uptime: 14h58m19s
usbus0: Controller shutdown
uhub0: at usbus0, port 1, addr 1 (disconnected)
ugen0.2: <vendor 0x8087> at usbus0 (disconnected)
uhub4: at uhub0, port 1, addr 2 (disconnected)
usbus0: Controller shutdown complete
re0: link state changed to DOWN
re0: link state changed to UP
usbus1: Controller shutdown

After waiting 30 minutes, I decided to power cycle the machine. After =
reboot, the Zpool on the USB disk was not be able to mount because of a =
missing label (the error message referred to =
http://illumos.org/msg/ZFS-8000-5E). Thus, I had to destroy the zpool =
and re-created it. I've copied lots of files to a ZFS volume on top of =
the zpool and tried to reboot the machine. Got the same problem again. =
Seeing usbub1: Controller shutdown but nothing happens. I see a relation =
between the high interrupt rate and the USB device for some reason. =
`zpool iostat 1` shows me that there are no read or write operations on =
the device.=
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:21 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped