next »

[stephenw10]

Strange.
Perhaps something to do with the cable routing as you suggest.

Steve

[Bai Shen]

Strange.
Perhaps something to do with the cable routing as you suggest.

Steve

All I did was unplug the Kill-A-Watt from the power cable.  Dunno.

[clarknova]

This looks like a problem I had on an i3 550 that went out the door. I believe the fix was to turn off USB legacy support in the BIOS.

[Bai Shen]

Well, I rebooted due to updating to 2.0-RELEASE and it's back.  Only now it's irq11

[wallabybob]

You are now seeing {irq11: em1 ehci0} taking a lot of CPU?

Please post output of pfSense shell command vmstat -i

[Bai Shen]

You are now seeing {irq11: em1 ehci0} taking a lot of CPU?

Yes.

Please post output of pfSense shell command vmstat -i

Okay.  I'll do that when I get back to the machine.

[wallabybob]

That the irq has changed from 16 to 11 suggests to me you have (possibly inadvertently) disabled multiprocessing in the BIOS or disabled the IOAPIC or disabled acpi.

[thesidetalker]

EHCI provides access for 'high speed' devices as opposed to low and full speed.

The ehci driver has some tunables you could add to /boot/loader.conf.local to try.

LOADER TUNABLES

     Tunables can be set at the loader( prompt before booting the kernel or
     stored in loader.conf(5).

     hw.usb.ehci.lostintrbug
             This tunable enables the lost interrupt quirk.  The default value
             is 0 (off).

     hw.usb.ehci.iaadbug
             This tunable enables the EHCI doorbell quirk.  The default value
             is 0 (off).

     hw.usb.ehci.no_hs
             This tunable disables USB devices to attach like HIGH-speed ones
             and will force all attached devices to attach to the FULL- or
             LOW-speed companion controller.  The default value is 0 (off).

Steve

Steve I had a similar problem to the OP on my X9SCV build. {irq16: ehci0} was using ~50% of one cpu. I did as you suggested and added hw.usb.ehci.no_hs="1" to loader.conf and it seems to have fixed it. I'll keep an eye on it. Thanks

[stephenw10]

Glad that worked for you and thanks for reporting back. 

Steve

[vlad-i-mir]

Dear All, I've read this topic carefully and tried many ways to solve this problem. But there is no result till now.

I use pfsense 2.0.1 release (amd64) with ZOTAC®LGA 1155 Z68-ITX, Intel Celeron G530, Box, 2x2.4 GHz, 2 GB DDR3, HDD WD2500AAKX, 2 x onboard Realtek RTL8111E and AzureWave AR5B95. My ISP gives me 1 Gbps full duplex uplink and static IP. So everything good and I have realy 800-900 Mbps throughput, but only one bad. Last time I noticed interrupts on CPU 30-40%, and I saw this on irq16: ath0 ehci0. I disabled USB3, disabled Audio-controller and other unused things in BIOS. No result. Then I removed the WiFi card AR5B95 and CPU load slow down to 20-30%. I tried to change loader.conf with hw.usb.ehci.no_hs="1" and rebooted the system. But no result again. This is a link to RRD graphs. 

Here is the output from $ vmstat -i and $ devinfo -v, to illustrate the problem:

Code:

interrupt total rate
irq16: ehci0 6679556627 168445     ------> + approx. 450 000 every 1 second
irq19: atapci0+ 57770 1
irq23: ehci1 79325 2
cpu0: timer 79305108 1999
irq256: re0 98275744 2478
irq257: re1 96862546 2442
cpu1: timer 79304926 1999
Total 7033442046 177370

Code:

$ devinfo -v
nexus0
.......
acpi0
.......
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
pci0
.......
ehci0 pnpinfo vendor=0x8086 device=0x1c2d subvendor=0x19da subdevice=0xa198 class=0x0c0320 at slot=26 function=0 handle=\_SB_.PCI0.USBE
usbus0
uhub0
uhub2 pnpinfo vendor=0x8087 product=0x0024 devclass=0x09 devsubclass=0x00 sernum="" release=0x0000 intclass=0x09 intsubclass=0x00 at bus=1 hubaddr=1 port=0 devaddr=2 interface=0
.......
ehci1 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x19da subdevice=0xa198 class=0x0c0320 at slot=29 function=0 handle=\_SB_.PCI0.EUSB
usbus1
uhub1
uhub3 pnpinfo vendor=0x8087 product=0x0024 devclass=0x09 devsubclass=0x00 sernum="" release=0x0000 intclass=0x09 intsubclass=0x00 at bus=1 hubaddr=1 port=1 devaddr=2 interface=0
.......

So may be anybody know what cause this problem, or what I have to do again to track down this? I'm not very experienced with FreeBSD so I don't know what to try next.

[vlad-i-mir]

Update. Problem solved!
Point is that motherboard Z68-ITX has video only with HDMI 1.4a or with DisplayPort (mini-DP). So I connected LCD TV in to HDMI, installed pfsense, assigned interfaces, entered commands for loader.conf, etc. But I did not disconnected the HDMI after it.

Then on the russian pfSense forum guys asked me about HDMI/mini-DP and suggested to disconnect LCD. I did it without shutting down the router and looked into vmstat -i. The interrupts appeared on irq16: ehci0 immediately after I disconnected the cable.

After I disconnected the display then I rebooted the router. After it I haven't seen the problem again.      

[stephenw10]

Thanks for reporting back.
Interesting solution, I wonder if the HDMI implementation on that board supports an ethernet connection?

Steve

[Bai Shen]

So my machine is still acting up.  What's weird is that it works fine for about an hour and then the problems start.

Also, I've since upgraded to 2.0.1 and now it doesn't get past the em1: MSI Interrupt message unless I select to boot with ACPI(I think) disabled.  Not sure if that has any bearing on things or not.

I haven't looked too much into it as everything seems to be working correctly.  The only problem is the extra power it's using.

[Bai Shen]

You are now seeing {irq11: em1 ehci0} taking a lot of CPU?

Please post output of pfSense shell command vmstat -i

Just realized I never did the vmstat check.  So here it is.


interrupt                          total       rate
irq16: em1 ehci0               267777779      57797
irq17: em2                         11528          2
irq18: em3                         11468          2
irq19: atapci0                     37902          8
irq23: ehci1                        9358          2
cpu0: timer                      9309748       2009
irq256: em0                        53580         11
cpu1: timer                      9309520       2009
Total                          286520883      61843

[wallabybob]

The vmstat output shows a very high interrupt rate on irq16 again.

If you don't have a high packet rate on em1 and are bothered by the high interrupt rates I would be inclined to see if I could stop use of of irq16 and see how things change. For example, move USB devices to different USB sockets in an attempt to move them to ehci1, the other USB controller. The BIOS might allow disabling of USB. Does that change the interrupt rate on irq16? Disable em1. Does that change interrupt rate on irq16?

You could also try installing a snapshot build of pfSense 2.1. It is based on a much more recent release of FreeBSD which might work better with your hardware.