{irq16: em1 ehci0} taking up 75% of cpu



  • I’m running 2.0 RC3 on an i3.  Shortly after I boot it, one of the cpu cores gets a heavy load on it.  Looking at the System Activity, it shows {irq16: em1 ehci0}

    em1 is my WAN card.  I’m not running any packages, and other than the high cpu activity, everything seems to be working.


  • Administrator

    This can be easily confused with some other device that’s using the same irq.
    Do you have anything else using irq 16?

    Steve



  • @stephenw10:

    This can be easily confused with some other device that’s using the same irq.
    Do you have anything else using irq 16?

    Steve

    I’m not sure.  How do I check in pfSense?  The machine is an i3-2100 running on a DH67CL.  I’m using three Intel PRO 1000GT PCI NICs.  The only other thing is a hard drive plugged in to a SATA 3 port.  I’m using a USB KVM, so I have those two USB devices plugged in.

    This seems to be the same issue.
    http://www.freebsd.org/cgi/query-pr.cgi?pr=156596


  • Administrator

    Yes that seems likely the same issue. Or indeed this one:
    http://forums.freebsd.org/showthread.php?t=24952

    I was going to suggest you disable all usb ports in the bios but it seems you are using them.  ::)
    You may be able to disable ehci though. Have a look through your bios and see what you can disable.

    Steve



  • @stephenw10:

    Yes that seems likely the same issue. Or indeed this one:
    http://forums.freebsd.org/showthread.php?t=24952

    I was going to suggest you disable and usb ports in the bios but it seems you are using them.  ::)
    You may be able to disable ehci though. Have a look through your bios and see what you can disable.

    Steve

    And if I disabled the usb ports, I’d have no way of reenabling them. 🙂

    What’s the difference between ehci and usb?


  • Administrator

    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(8) 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



  • @stephenw10:

    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(8) 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

    Ah, okay.  I’ll take a look when I get home.

    I wonder if it made a difference that I installed pfSense using a usb cd-rom.



  • @Bai:

    I’m running 2.0 RC3 on an i3.  Shortly after I boot it, one of the cpu cores gets a heavy load on it.  Looking at the System Activity, it shows {irq16: em1 ehci0}

    em1 is my WAN card.  I’m not running any packages, and other than the high cpu activity, everything seems to be working.

    I’ve seen this sort of thing happen when the BIOS provides incorrect interrupt data. For example, if the BIOS says a device interrupts on irq18 when it really interrupts on irq16 the driver’s interrupt handler will get attached to irq18 but the real interrupt goes to irq16 where it doesn’t get handled (because the correct handler doesn’t get called) and the interrupt request doesn’t get cleared until there is an irq18 interrupt and the correct handler is called. Do you have the latest BIOS?

    @Bai:

    I wonder if it made a difference that I installed pfSense using a usb cd-rom.

    I think it is unlikely.

    Please post the output of pfSense shell command: pciconf -l -v; vmstat -i and the names of a



  • @wallabybob:

    I’ve seen this sort of thing happen when the BIOS provides incorrect interrupt data. For example, if the BIOS says a device interrupts on irq18 when it really interrupts on irq16 the driver’s interrupt handler will get attached to irq18 but the real interrupt goes to irq16 where it doesn’t get handled (because the correct handler doesn’t get called) and the interrupt request doesn’t get cleared until there is an irq18 interrupt and the correct handler is called. Do you have the latest BIOS?

    Yep.

    @wallabybob:

    I think it is unlikely.

    I figured, but I thought I’d mention it just in case.

    @wallabybob:

    Please post the output of pfSense shell command: pciconf -l -v; vmstat -i and the names of a

    The names of a what?



  • @Bai:

    @wallabybob:

    Please post the output of pfSense shell command: pciconf -l -v; vmstat -i and the names of a

    The names of a what?

    Sorry, just the output of the shell command pciconf -l -v; devinfo -r; vmstat -i will do.



  • Well, I turned off Legacy USB and USB 3 in the BIOS, and the problem seems to have gone away.  It’s now idling at a nice 39W. 🙂

    Will the output of the commands still be worthwhile?



  • @Bai:

    Will the output of the commands still be worthwhile?

    No - seems like a USB related problem.



  • @wallabybob:

    @Bai:

    Will the output of the commands still be worthwhile?

    No - seems like a USB related problem.

    Actually, it looks like it’s not. 😞  It just took a while before it came back. 😞

    Here’s the output.

    
    $ pciconf -l -v; devinfo -r; vmstat -i
    hostb0@pci0:0:0:0:	class=0x060000 card=0x20038086 chip=0x01008086 rev=0x09 hdr=0x00
        class      = bridge
        subclass   = HOST-PCI
    vgapci0@pci0:0:2:0:	class=0x030000 card=0x20038086 chip=0x01028086 rev=0x09 hdr=0x00
        class      = display
        subclass   = VGA
    none0@pci0:0:22:0:	class=0x078000 card=0x20038086 chip=0x1c3a8086 rev=0x04 hdr=0x00
        class      = simple comms
    em0@pci0:0:25:0:	class=0x020000 card=0x20038086 chip=0x15038086 rev=0x05 hdr=0x00
        class      = network
        subclass   = ethernet
    ehci0@pci0:0:26:0:	class=0x0c0320 card=0x20038086 chip=0x1c2d8086 rev=0x05 hdr=0x00
        class      = serial bus
        subclass   = USB
    none1@pci0:0:27:0:	class=0x040300 card=0x20038086 chip=0x1c208086 rev=0x05 hdr=0x00
        class      = multimedia
        subclass   = HDA
    pcib1@pci0:0:28:0:	class=0x060400 card=0x20038086 chip=0x1c108086 rev=0xb5 hdr=0x01
        class      = bridge
        subclass   = PCI-PCI
    ehci1@pci0:0:29:0:	class=0x0c0320 card=0x20038086 chip=0x1c268086 rev=0x05 hdr=0x00
        class      = serial bus
        subclass   = USB
    isab0@pci0:0:31:0:	class=0x060100 card=0x20038086 chip=0x1c4a8086 rev=0x05 hdr=0x00
        class      = bridge
        subclass   = PCI-ISA
    atapci0@pci0:0:31:2:	class=0x010601 card=0x20038086 chip=0x1c028086 rev=0x05 hdr=0x00
        class      = mass storage
        subclass   = SATA
    none2@pci0:0:31:3:	class=0x0c0500 card=0x20038086 chip=0x1c228086 rev=0x05 hdr=0x00
        class      = serial bus
        subclass   = SMBus
    pcib2@pci0:1:0:0:	class=0x060400 card=0x20038086 chip=0x88921283 rev=0x10 hdr=0x01
        class      = bridge
        subclass   = PCI-PCI
    em1@pci0:2:0:0:	class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00
        class      = network
        subclass   = ethernet
    em2@pci0:2:1:0:	class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00
        class      = network
        subclass   = ethernet
    em3@pci0:2:2:0:	class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00
        class      = network
        subclass   = ethernet
    nexus0
      cryptosoft0
      apic0
      ram0
          I/O memory addresses:
              0x0-0x9cfff
              0x100000-0x1fffffff
              0x20200000-0x3fffffff
              0x40200000-0xda969fff
              0xdabc9000-0xdabc9fff
              0xdae8e000-0xdaffffff
      npx0
      acpi0
          Interrupt request lines:
              9
          I/O ports:
              0x10-0x1f
              0x22-0x3f
              0x44-0x5f
              0x62-0x63
              0x65-0x6f
              0x72-0x7f
              0x80
              0x84-0x86
              0x88
              0x8c-0x8e
              0x90-0x9f
              0xa2-0xbf
              0xe0-0xef
              0x400-0x453
              0x454-0x457
              0x458-0x47f
              0x4d0-0x4d1
              0x500-0x57f
              0x1180-0x119f
          I/O memory addresses:
              0xf8000000-0xfbffffff
              0xfec00000-0xfecfffff
              0xfed08000-0xfed08fff
              0xfed10000-0xfed19fff
              0xfed1c000-0xfed1ffff
              0xfed20000-0xfed3ffff
              0xfed90000-0xfed93fff
              0xfee00000-0xfee0ffff
              0xff000000-0xffffffff
        cpu0
            ACPI I/O ports:
                0x414
                0x415
          acpi_perf0
          est0
          p4tcc0
          cpufreq0
        cpu1
            ACPI I/O ports:
                0x414
                0x415
          acpi_perf1
          est1
          p4tcc1
          cpufreq1
        cpu2
            ACPI I/O ports:
                0x414
                0x415
          acpi_perf2
          est2
          p4tcc2
          cpufreq2
        cpu3
            ACPI I/O ports:
                0x414
                0x415
          acpi_perf3
          est3
          p4tcc3
          cpufreq3
        pcib0
          pci0
              I/O ports:
                  0xf000-0xf03f
                  0xf040-0xf05f
                  0xf080-0xf09f
                  0xf0a0-0xf0a3
                  0xf0b0-0xf0b7
                  0xf0c0-0xf0c3
                  0xf0d0-0xf0d7
              I/O memory addresses:
                  0xe0000000-0xefffffff
                  0xfe000000-0xfe3fffff
                  0xfe720000-0xfe723fff
                  0xfe724000-0xfe7240ff
                  0xfe729000-0xfe72900f
            hostb0
            vgapci0
            em0
                Interrupt request lines:
                    256
                I/O memory addresses:
                    0xfe700000-0xfe71ffff
                    0xfe728000-0xfe728fff
            ehci0
                Interrupt request lines:
                    16
                I/O memory addresses:
                    0xfe727000-0xfe7273ff
              usbus0
                uhub0
                  uhub2
            pcib1
              pci1
                pcib2
                  pci2
                      I/O memory addresses:
                          0xfe420000-0xfe43ffff
                          0xfe480000-0xfe49ffff
                          0xfe4e0000-0xfe4fffff
                    em1
                        Interrupt request lines:
                            16
                        I/O ports:
                            0xe080-0xe0bf
                        I/O memory addresses:
                            0xfe500000-0xfe51ffff
                    em2
                        Interrupt request lines:
                            17
                        I/O ports:
                            0xe040-0xe07f
                        I/O memory addresses:
                            0xfe4a0000-0xfe4bffff
                    em3
                        Interrupt request lines:
                            18
                        I/O ports:
                            0xe000-0xe03f
                        I/O memory addresses:
                            0xfe440000-0xfe45ffff
            ehci1
                Interrupt request lines:
                    23
                I/O memory addresses:
                    0xfe726000-0xfe7263ff
              usbus1
                uhub1
                  uhub3
            isab0
              isa0
                pmtimer0
                sc0
                vga0
                    I/O ports:
                        0x3c0-0x3df
                    I/O memory addresses:
                        0xa0000-0xbffff
                ata0
                    Interrupt request lines:
                        14
                    I/O ports:
                        0x1f0-0x1f7
                        0x3f6
                ata1
                    Interrupt request lines:
                        15
                    I/O ports:
                        0x170-0x177
                        0x376
                atkbdc0
                    I/O ports:
                        0x60
                        0x64
                  atkbd0
                      Interrupt request lines:
                          1
            atapci0
                Interrupt request lines:
                    19
                I/O ports:
                    0xf060-0xf07f
                I/O memory addresses:
                    0xfe725000-0xfe7257ff
              ata2
                ad4
                  subdisk4
              ata3
              ata4
              ata5
              ata6
              ata7
        acpi_sysresource0
        acpi_sysresource1
        atpic0
        atdma0
        attimer0
        atrtc0
            Interrupt request lines:
                8
            I/O ports:
                0x70-0x71
        acpi_sysresource2
        npxisa0
        acpi_sysresource3
        acpi_sysresource4
        acpi_button0
        pci_link0
        pci_link1
        pci_link2
        pci_link3
        pci_link4
        pci_link5
        pci_link6
        pci_link7
        acpi_sysresource5
        acpi_sysresource6
        acpi_timer0
            ACPI I/O ports:
                0x408-0x40b
        acpi_hpet0
            I/O memory addresses:
                0xfed00000-0xfed003ff
    interrupt                          total       rate
    irq16: em1 ehci0               779815612      16681
    irq17: em2                         18172          0
    irq18: em3                          4435          0
    irq19: atapci0                     81729          1
    irq23: ehci1                       93211          1
    cpu0: timer                     93493755       2000
    irq256: em0                       604657         12
    cpu1: timer                     93493955       2000
    cpu2: timer                     93493973       2000
    cpu3: timer                     93494072       2000
    Total                         1154593571      24699
    
    


  • I think Steve’s suggestion was that you disable USB2 and USB3. From what you said you disabled USB1 and USB3. Please try Steve’s suggestion. USB keyboard and mouse should work fine with USB1.


  • Administrator

    I would try disabling ‘high speed’ with that loader tunable. You clearly don’t need high speed, ehci, for a keyboard.

    Steve



  • @wallabybob:

    I think Steve’s suggestion was that you disable USB2 and USB3. From what you said you disabled USB1 and USB3. Please try Steve’s suggestion. USB keyboard and mouse should work fine with USB1.

    Those were the only options in the BIOS for USB.

    @stephenw10:

    I would try disabling ‘high speed’ with that loader tunable. You clearly don’t need high speed, ehci, for a keyboard.

    Steve

    I’ll give that a shot.  Which ones do you suggest?  All three or just the last one?


  • Administrator

    I would probably try no_hs first then lost interupt.
    The sysctl OIDs are listed in the 8.1 source code, here, but I don’t have them on my system. Perhaps because I’m not using USB.  😕

    Steve



  • @stephenw10:

    I would probably try no_hs first then lost interupt.
    The sysctl OIDs are listed in the 8.1 source code, here, but I don’t have them on my system. Perhaps because I’m not using USB.  😕

    Steve

    No luck with no_hs.  It ran fine for a little bit, but then quickly returned to it’s previous state.  Is there a way to make sure that it’s recognizing the loader.conf.local?

    And I don’t really have a choice on using USB.  I don’t have any PS2 ports. 🙂


  • Administrator

    I would expect to be able to see the sysctl OIDs but all I see is:

    
    [2.0-RC3][root@pfsense.fire.box]/root(1): sysctl hw.usb
    hw.usb.no_boot_wait: 0
    hw.usb.debug: 0
    hw.usb.usb_lang_mask: 255
    hw.usb.usb_lang_id: 9
    hw.usb.template: 0
    hw.usb.power_timeout: 30
    hw.usb.uath.regdomain: 0
    hw.usb.uath.countrycode: 0
    hw.usb.urtw.preamble_mode: 2
    hw.usb.urtw.debug: 0
    hw.usb.ucom.cons_baud: 9600
    hw.usb.ucom.cons_unit: -1
    
    

    No EHCI at all.

    Steve



  • @stephenw10:

    I would expect to be able to see the sysctl OIDs but all I see is:

    
    [2.0-RC3][root@pfsense.fire.box]/root(1): sysctl hw.usb
    hw.usb.no_boot_wait: 0
    hw.usb.debug: 0
    hw.usb.usb_lang_mask: 255
    hw.usb.usb_lang_id: 9
    hw.usb.template: 0
    hw.usb.power_timeout: 30
    hw.usb.uath.regdomain: 0
    hw.usb.uath.countrycode: 0
    hw.usb.urtw.preamble_mode: 2
    hw.usb.urtw.debug: 0
    hw.usb.ucom.cons_baud: 9600
    hw.usb.ucom.cons_unit: -1
    
    

    No EHCI at all.

    Steve

    I get hw.usb.ehci.no_hs 1 when I do it.  So it’s picking it up.  I guess it’s time to try the others.



  • None of them worked.

    Also, my keyboard no longer works.

    Any other suggestions?



  • @stephenw10:

    The sysctl OIDs are listed in the 8.1 source code, here, but I don’t have them on my system. Perhaps because I’m not using USB.  😕

    Some device drivers don’t register sysctls until they have successfully attached at least one device. I don’t know the specifics of the USB sysctls.

    @Bai:

    None of them worked.

    Also, my keyboard no longer works.

    Any other suggestions?

    Suggestions:

    • Use  a motherboard with a chipset that has been available for at least six months at the time of release of FreeBSD 8.1. (I recall that I saw an older pfSense release lock up on startup on a motherboard with AMD chipset if USB was enabled. The next version of pfSense which had a more recent FreeBSD worked fine on the same motherboard when USB was enabled.)

    • Keep searching - maybe a FreeBSD user has found a solution for FreeBSD 8.1

    • Ignore it, you still have three working cores which is probably much more than you need.

    • Disable motherboard USB entirely and use a PCI USB 2.0 card (which almost certainly will have a  USB chipset that has been around for a while and consequently has well debugged drivers). I don’t know if the BIOS will support this.

    • Disable motherboard USB and set BIOS to ignore “no keyboard”. What do you need the keyboard for once the system is configured.


  • Administrator

    @wallabybob:

    Some device drivers don’t register sysctls until they have successfully attached at least one device. I don’t know the specifics of the USB sysctls.

    That’s what I thought, and yet:

    
    [2.0-RC3][root@pfsense.fire.box]/root(2): sysctl -a | grep ehci
    dev.usbus.2.%parent: ehci0
    dev.ehci.0.%desc: Intel 6300ESB USB 2.0 controller
    dev.ehci.0.%driver: ehci
    dev.ehci.0.%location: slot=29 function=7
    dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x25ad subvendor=0x8086 subdevice=0x25ad class=0x0c0320
    dev.ehci.0.%parent: pci0
    
    

    Hmmm.  😕

    @Bai Shen. If it has disabled your keyboard it is clearly doing something. Do you still have Legacy USB disabled in the bios? Perhaps you have ended up disabling ehci when that is all that was left still functioning.

    Steve



  • @wallabybob:

    • Keep searching - maybe a FreeBSD user has found a solution for FreeBSD 8.1

    Not as far as I can tell.  There’s a bug filed for it, but no resolution so far.

    @wallabybob:

    • Ignore it, you still have three working cores which is probably much more than you need.

    That’s what I’m doing.  The biggest annoyance is that it prevents the processor from idling and therefore uses more power than it should.

    @wallabybob:

    • Disable motherboard USB entirely and use a PCI USB 2.0 card (which almost certainly will have a  USB chipset that has been around for a while and consequently has well debugged drivers). I don’t know if the BIOS will support this.

    Maybe.  But right now I’m using all of the PCI slots for NICs.  I’ll be picking up PCIe NICs later, but for now I’m using the ones I have.

    @wallabybob:

    • Disable motherboard USB and set BIOS to ignore “no keyboard”. What do you need the keyboard for once the system is configured.

    I’ve thought about doing that.  But I’ve had instances before where I had to use the console on the actual box to reset/change configurations.  So I’m hesitant to do that atm.  Plus I’m not sure how it’ll work to turn it back on as there’s no other way to connect a keyboard.



  • @stephenw10:

    @Bai Shen. If it has disabled your keyboard it is clearly doing something. Do you still have Legacy USB disabled in the bios? Perhaps you have ended up disabling ehci when that is all that was left still functioning.

    Steve

    No, I made sure to turn legacy and usb3 back on before messing with the loader.conf.local.


  • Administrator

    Serial console instead of keyboard?
    I would definitely leave USB3 disabled.
    Perhaps you can force one of the two devices onto a different IRQ.

    Steve

    Edit: Assuming you are still using the DH67CL, are you running the lastest bios?

    Edit: It seems (though I can’t find detailed instruction) that you should be able to set IRQ 16 as unavailable to PCI auto configuration. That should force your LAN card onto a different IRQ.



  • @stephenw10:

    Serial console instead of keyboard?

    I don’t think it has a serial port, but I could be wrong.  I don’t have any infrastructure to support that either.

    @stephenw10:

    I would definitely leave USB3 disabled.

    How come?

    @stephenw10:

    Perhaps you can force one of the two devices onto a different IRQ.

    Steve

    Edit: Assuming you are still using the DH67CL, are you running the lastest bios?

    Edit: It seems (though I can’t find detailed instruction) that you should be able to set IRQ 16 as unavailable to PCI auto configuration. That should force your LAN card onto a different IRQ.

    Yep, I’m running the latest bios.

    I’ll have to look through the bios at the PCI config.  I don’t recall seeing anything like that before, but I wasn’t looking for it.  How does setting the NIC to a different IRQ fix the problem?  Wouldn’t I still get the interrupts from the ehci?


  • Administrator

    @Bai:

    @stephenw10:

    I would definitely leave USB3 disabled.

    How come?

    Because it’s highly probable that FreeBSD didn’t support it when 8.1 was released. Does it even support it now?

    @Bai:

    I’ll have to look through the bios at the PCI config.  I don’t recall seeing anything like that before, but I wasn’t looking for it.  How does setting the NIC to a different IRQ fix the problem?  Wouldn’t I still get the interrupts from the ehci?

    It may be an IRQ conflict causing the interrupt storm.

    @Technical:

    Any interrupts set to Available in Setup are considered to be available for
    use by the add-in card.

    Implies that you can set to unavailable.

    Steve



  • @stephenw10:

    Because it’s highly probable that FreeBSD didn’t support it when 8.1 was released. Does it even support it now?

    No idea.  I’m not using them, but figured I’d leave them on so I don’t plug something in down the road and wonder why it’s not working. 🙂

    @stephenw10:

    It may be an IRQ conflict causing the interrupt storm.

    Ah, gotcha.

    @stephenw10:

    @Technical:

    Any interrupts set to Available in Setup are considered to be available for
    use by the add-in card.

    Implies that you can set to unavailable.

    Steve

    -nods-  I’ll take a look when I get home.



  • I ended up being sidetracked by other things and never messed with the box any more.  This weekend, I shut it down to rearrange some cables.  Since I brought it back up, I haven’t seen the problem again.  No idea what the difference is as I don’t recall changing anything.

    Just wanted to give y’all an update.


  • Administrator

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

    Steve



  • @stephenw10:

    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.



  • 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.



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



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

    Please post output of pfSense shell command vmstat -i



  • @wallabybob:

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

    Yes.

    @wallabybob:

    Please post output of pfSense shell command vmstat -i

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



  • 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.



  • @stephenw10:

    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(8) 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


  • Administrator

    Glad that worked for you and thanks for reporting back.  🙂

    Steve



  • 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:

    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
    
    $ 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.


Locked
 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy