From nobody Sun Nov 27 21:29:23 2022 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NL1vg4yLjz4hrjC for ; Sun, 27 Nov 2022 21:29:35 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NL1vg2fs1z3M74 for ; Sun, 27 Nov 2022 21:29:35 +0000 (UTC) (envelope-from pprocacci@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x336.google.com with SMTP id a13-20020a9d6e8d000000b00668d65fc44fso5825549otr.9 for ; Sun, 27 Nov 2022 13:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ht7T6jHtGB14/oH1z2i0NEcFRTnM9CFdf3XBPraf3j8=; b=AQ27lt+L/uO2FS+iAZCQ0CBxQ6l29VXuyI4VYWgqKA0RDS2drX8vi3m7aTnuZyKoWO 2evGNOtr+XXgAneevfWYzcgZFDAE6DeOx7IfL/1Gx4j/CXKp6t77yb98yjjrfTtapg4K LM7y3AsLCIxMtQIJ3V4nHT7adjKgIR7JCVGe6TU77IHJCDN7+jEGBWNew6X0izZeVqfm uNmuWvVol5k0biuPS5Glp6/SJQjNjQ9lZOrlijf8DpYyvVPXuQEvNmmwe0TQjznMJiDc NiYmD9AA40gsZevOLBQ+hMz2b81FUd9IkljRb7rbiCwZAIejM64ukjxbVxZJpDtUl3P5 wAyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ht7T6jHtGB14/oH1z2i0NEcFRTnM9CFdf3XBPraf3j8=; b=JPzrNfHyhXQQ1zGd3vkVKsW/SpHsPXbdTSnld8P74YXHOetPwQL1DGTa5154N84UA5 y8BcnxEsnvjibF76TYFY/uyKZpOF7RvmfXgEVPHrMr39jAsct6PdpXMFUXdMbAPW2/Fg RTaAP6L2y8cl9uBKsJpEBOc8FXI1FD1Kn9e4u+BMS+bbn0m04X8I43EMXEnP+0aQdOvB yfbAjGks33WTNuuKzEz9Sz3uN/B3LK2s4IM238ofqmccxdAV6tdHiOAyyH0N2ZOG66RA vbWv60QUWCK7UAAA5y0DOSbX7ok2y+mXINzC9PByDmGx5M7lpYeDC+/wh97jjjfdWbtJ rEww== X-Gm-Message-State: ANoB5plKY5SbE5Q7qWvCqyEmyuaz8Xev7VGsJ3SqDuzL3xZg9OXvBqef 162qJ0gW2lVk/lDT/Z5Q/zNNVNaeSaVojm2mqBKMaZw= X-Google-Smtp-Source: AA0mqf7XYxtOCEABPaxoSJkD7hFOkd7gmmGl8ITrxgCsoDyHHYHqPRQqdCfDt3PZvMn7HZAVzssn5TtxcDcIsOzBpcI= X-Received: by 2002:a9d:7f03:0:b0:66c:e033:2154 with SMTP id j3-20020a9d7f03000000b0066ce0332154mr15739136otq.79.1669584574160; Sun, 27 Nov 2022 13:29:34 -0800 (PST) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Paul Procacci Date: Sun, 27 Nov 2022 16:29:23 -0500 Message-ID: Subject: Re: High CPU usage / high number of interrupts To: 0x1eef <0x1eef@protonmail.com> Cc: "freebsd-questions@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000077248305ee7a7396" X-Rspamd-Queue-Id: 4NL1vg2fs1z3M74 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000077248305ee7a7396 Content-Type: text/plain; charset="UTF-8" I've personally never had to fiddle with event timers so this may be out of my realm. With that said the following man page describes that various timers that one could employ: man eventtimers When I add up all my timer values, their sum is slightly over 1300 so I'm not entirely convinced it's a problem. I'm running around quite a bit today so I'll look a bit later to see if anything stands out and let you know. Thanks, Paul On Sun, Nov 27, 2022 at 1:12 PM 0x1eef <0x1eef@protonmail.com> wrote: > Yes ! That makes a huge difference. I added "net.bluetooth.usb_isoc_enable=0" > to /boot/loader.conf, and rebooted. The interrupts have gone down to > between 0, and 47. > > # vmstat -i > interrupt total rate > irq1: atkbd0 10 0 > irq9: acpi0 9 0 > cpu0:timer 70196 342 > cpu1:timer 51387 250 > cpu2:timer 50952 248 > cpu3:timer 51181 249 > irq128: xhci0 9659 47 > irq130: nvme0:admin 15 0 > irq131: nvme0:io0 3253 16 > irq132: nvme0:io1 3243 16 > irq133: nvme0:io2 3341 16 > irq134: nvme0:io3 3883 19 > irq135: hdac0 13 0 > irq136: vgapci0 37917 185 > Total 285059 1389 > > However, the CPU interrupts seem quite high now. If you combine cpu*:timer > i think it is over 1000, and maybe that relates to the original problem I > reported ? > > Thanks! > > 0x1eef > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Sunday, November 27th, 2022 at 1:45 AM, Paul Procacci < > pprocacci@gmail.com> wrote: > > What's catching my eye here is the values for ugen0.6. It's a usb > bluetooth device. > > With that in mind I searched the bug database for bluetooth usb and xhci. > I came across the following: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238235 > > There does seem to be some sort of weird interaction with bluetooth and > xhci as documented in the above link. > I believe the patch listed in that bug report made it to 13.1....so can > you try: > > sysctl -w net.bluetooth.usb_isoc_enable=0 > > > Does that make any difference? > (This btw is a wild guess just based on the values from the output you > provided me) > > Thanks, > Paul > > On Sat, Nov 26, 2022 at 11:05 PM 0x1eef <0x1eef@protonmail.com> wrote: > >> The results are sort of interesting. At first, UE_INTERRUPT_OK was at 3k+ >> for the USB mouse. I unplugged the mouse, and then the keyboard jumped from >> 0 to 1k+ for UE_INTERRUPT_OK. >> >> I have since reattached the mouse, and now both the mouse and the >> keyboard have a rising interrupt count. I would guess they jump by 20, or >> 30 interrupts every 2-3 seconds, with the keyboard jumping with a higher >> frequency. >> >> Paste >> >> ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER >> (5.0Gbps) pwr=SAVE (0mA) >> >> { >> UE_CONTROL_OK : 0 >> UE_ISOCHRONOUS_OK : 0 >> UE_BULK_OK : 0 >> UE_INTERRUPT_OK : 0 >> UE_CONTROL_FAIL : 0 >> UE_ISOCHRONOUS_FAIL : 0 >> UE_BULK_FAIL : 0 >> UE_INTERRUPT_FAIL : 0 >> } >> >> ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON (350mA) >> >> { >> UE_CONTROL_OK : 7969 >> UE_ISOCHRONOUS_OK : 0 >> UE_BULK_OK : 11224 >> UE_INTERRUPT_OK : 0 >> UE_CONTROL_FAIL : 0 >> UE_ISOCHRONOUS_FAIL : 0 >> UE_BULK_FAIL : 94 >> UE_INTERRUPT_FAIL : 0 >> } >> >> ugen0.4: at usbus0, cfg=0 >> md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) >> >> { >> UE_CONTROL_OK : 10 >> UE_ISOCHRONOUS_OK : 0 >> UE_BULK_OK : 0 >> UE_INTERRUPT_OK : 0 >> UE_CONTROL_FAIL : 0 >> UE_ISOCHRONOUS_FAIL : 0 >> UE_BULK_FAIL : 0 >> UE_INTERRUPT_FAIL : 0 >> } >> >> ugen0.6: at usbus0, cfg=0 md=HOST spd=FULL >> (12Mbps) pwr=ON (100mA) >> >> { >> UE_CONTROL_OK : 16 >> UE_ISOCHRONOUS_OK : 53214 >> UE_BULK_OK : 0 >> UE_INTERRUPT_OK : 9 >> UE_CONTROL_FAIL : 0 >> UE_ISOCHRONOUS_FAIL : 0 >> UE_BULK_FAIL : 0 >> UE_INTERRUPT_FAIL : 0 >> } >> >> ugen0.5: at usbus0, cfg=0 md=HOST >> spd=LOW (1.5Mbps) pwr=ON (100mA) >> >> { >> UE_CONTROL_OK : 11 >> UE_ISOCHRONOUS_OK : 0 >> UE_BULK_OK : 0 >> UE_INTERRUPT_OK : 1707 >> UE_CONTROL_FAIL : 0 >> UE_ISOCHRONOUS_FAIL : 0 >> UE_BULK_FAIL : 0 >> UE_INTERRUPT_FAIL : 0 >> } >> >> ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL >> (12Mbps) pwr=ON (500mA) >> >> { >> UE_CONTROL_OK : 21 >> UE_ISOCHRONOUS_OK : 0 >> UE_BULK_OK : 0 >> UE_INTERRUPT_OK : 1790 >> UE_CONTROL_FAIL : 0 >> UE_ISOCHRONOUS_FAIL : 0 >> UE_BULK_FAIL : 0 >> UE_INTERRUPT_FAIL : 0 >> } >> >> Best, >> 0x1eef >> >> ------- Original Message ------- >> On Sunday, November 27th, 2022 at 12:31 AM, Paul Procacci < >> pprocacci@gmail.com> wrote: >> >> usbconfig dump_stats >> >> Can you provide the output of the above? Run that a couple of times if >> you don't mind and do your very best to provide any rates of increases for >> any of the fields. An estimation would be perfectly fine. >> >> Thanks, >> Paul >> >> On Sat, Nov 26, 2022 at 10:09 PM 0x1eef <0x1eef@protonmail.com> wrote: >> >>> > Can you determine if irq 128 is being shared by any devices? >>> >>> I couldn't determine that from dmesg.boot, but I think there could be >>> some useful information in that file. I attached the file to this e-mail. >>> Thank you! >>> >>> Best, >>> 0x1eef >>> >>> Sent with Proton Mail secure email. >>> >>> ------- Original Message ------- >>> On Saturday, November 26th, 2022 at 8:49 PM, Paul Procacci < >>> pprocacci@gmail.com> wrote: >>> >>> Can you determine if irq 128 is being shared by any devices? >>> Usually this information can be found in `dmesg' or >>> '/var/run/dmesg.boot'. >>> >>> vmstat indeed shows a device but it sometimes doesn't show all the >>> devices sharing that IRQ. It's possible you're being misled by vmstat. >>> Just trying to get the complete picture here of devices. ;) >>> >>> Thanks, >>> Paul Procacci >>> >>> On Sat, Nov 26, 2022 at 6:21 PM 0x1eef <0x1eef@protonmail.com> wrote: >>> >>>> Hi ! >>>> >>>> > Out of curiosity, have you pulled a usb device one by one until the >>>> interrupts disappear? >>>> >>>> I have three USB devices connected: mouse, keyboard, and an ethernet >>>> adapter. >>>> I tried to remove each one by one, and I did not see the interrupt rate >>>> change. >>>> I have also tried a cold boot without any USB devices connected, and >>>> the interrupt rate was about the same too. >>>> >>>> I don't know if it could be related, but there's a trackpad connected >>>> to the laptop that does not work. Maybe it has no relation to the issue, >>>> but setting "hw.psm.synaptics_support" to "0" also did not help. >>>> >>>> When Chromium loses focus, CPU usage usually drops to 0% and does not >>>> go above 10% - for as long as I am not using Chromium. I am using the i915 >>>> / drm kernel modules.. I saw another report of high CPU usage related to >>>> using those two kernel modules, but I wasn't able to identify that as the >>>> problem in my case. >>>> >>>> Thanks for the help. >>>> >>>> Sent with Proton Mail secure email. >>>> >>>> ------- Original Message ------- >>>> On Saturday, November 26th, 2022 at 8:06 PM, Paul Procacci < >>>> pprocacci@gmail.com> wrote: >>>> >>>> Hey, >>>> >>>> Not sure of the problem, but I don't see the correlation between Chrome >>>> and any usb driver. >>>> Out of curiosity, have you pulled a usb device one by one until the >>>> interrupts disappear? >>>> >>>> I'd be curious to know which device is slamming the system. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On Sat, Nov 26, 2022 at 6:02 PM 0x1eef <0x1eef@protonmail.com> wrote: >>>> >>>>> Hi, everyone! >>>>> >>>>> When I use Chromium, I see a high rate of CPU usage across all four >>>>> cores. The rate can be anywhere from 20% to 50%, even above that. I am not >>>>> doing anything intensive, just browsing twitter, reddit, YouTube or GitHub. >>>>> It has been like this since I installed FreeBSD, but since it's not a >>>>> blocker I have been lazy about looking into it. >>>>> >>>>> I don't know why it happens. I can see that there are a high number of >>>>> interrupts on 'xhci0', and that seems to carry over to each CPU core as >>>>> well: >>>>> >>>>> # vmstat -i >>>>> interrupt total rate >>>>> irq1: atkbd0 50 0 >>>>> irq9: acpi0 403 0 >>>>> cpu0:timer 30716618 98 >>>>> cpu1:timer 25457926 81 >>>>> cpu2:timer 34344531 109 >>>>> cpu3:timer 25542867 81 >>>>> irq128: xhci0 328107434 1044 >>>>> irq130: nvme0:admin 15 0 >>>>> irq131: nvme0:io0 701041 2 >>>>> irq132: nvme0:io1 692045 2 >>>>> irq133: nvme0:io2 792760 3 >>>>> irq134: nvme0:io3 693091 2 >>>>> irq135: hdac0 1718425 5 >>>>> irq136: vgapci0 6273295 20 >>>>> Total 455040501 1448 >>>>> >>>>> >>>>> # dmesg | grep xhci0 >>>>> xhci0: mem >>>>> 0x95110000-0x9511ffff at device 20.0 on pci0 >>>>> xhci0: 32 bytes context size, 64-bit DMA >>>>> usbus0 on xhci0 >>>>> >>>>> It might also be helpful to know that I tried OpenBSD on the same >>>>> computer but it was unusable for a similar reason: 95%+ interrupts on CPU. >>>>> The impact that had made all tasks extremely slow. On FreeBSD it is not as >>>>> bad, but I still think think it is not normal. >>>>> >>>>> Can anyone suggest what might be wrong, tips to debug, etc ? If more >>>>> information is needed, please let me know. Thanks for your time. >>>>> >>>>> Best, >>>>> 0x1eef >>>>> >>>>> >>>>> >>>> >>>> -- >>>> __________________ >>>> >>>> :(){ :|:& };: >>>> >>>> >>>> >>> >>> -- >>> __________________ >>> >>> :(){ :|:& };: >>> >>> >>> >> >> -- >> __________________ >> >> :(){ :|:& };: >> >> >> > > -- > __________________ > > :(){ :|:& };: > > > -- __________________ :(){ :|:& };: --00000000000077248305ee7a7396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've personally never had to fiddle with event ti= mers so this may be out of my realm.
With that said the following man pa= ge describes that various timers that one could employ:

man eventtim= ers

When I add up all my timer values, their sum is sligh= tly over 1300 so I'm not entirely convinced it's a problem.
I'm running around quite a bit today so I'll look a bit late= r to see if anything stands out and let you know.

Thanks,=
Paul

On Sun, Nov 27, 2022 at 1:12 PM 0x1eef <0x1eef@protonmail.com> wrote:
<= /div>
Yes ! That makes a huge difference. I added &qu= ot;net.bluetooth.usb_isoc_enable=3D0" to /boot/loader.conf, and = rebooted. The interrupts have gone down to between 0, and 47.=C2=A0<= br>

# vmstat -i
interrupt =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0total =C2=A0 =C2= =A0 =C2=A0 rate
irq1: atkbd0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
irq9: acpi0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A09 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
cpu0:timer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 70196 =C2=A0 =C2=A0 =C2=A0 =C2=A0342
<= div>cpu1:timer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 51387 =C2=A0 =C2=A0 =C2=A0 =C2=A0250=
cpu2:timer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 50952 =C2=A0 =C2=A0 =C2=A0 =C2=A0248=
cpu3:timer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 51181 =C2=A0 =C2=A0 =C2=A0 = =C2=A0249
irq128: xhci0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9659 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 47
irq130: nvme0:admin =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A00
irq131: nvme0:io0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3253 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16<= /span>
irq132: nvme0:io1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 3243 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
irq133: nvme0:io2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 3341 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
<= span>irq134: nvme0:io3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 3883 =C2=A0 =C2=A0 =C2=A0 =C2=A0 19
irq13= 5: hdac0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 13 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
<= span>irq136: vgapci0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A037917 =C2=A0 =C2=A0 =C2=A0 =C2=A0185
Total =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 285059 =C2=A0 =C2=A0 =C2=A0 1389
However, the CPU interrupts seem quite high now. If you combine cpu*:t= imer i think it is over 1000, and maybe that relates to the original proble= m I reported ?

Thanks!

0x1eef

=20
=20
Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, November 27th, 2022 at 1:45 AM, Paul Procacci <pprocacci@gmail.com&= gt; wrote:

What's catching my eye here is the va= lues for ugen0.6. It's a usb bluetooth device.

With that in mind I= searched the bug database for bluetooth usb and xhci.
I came across the= following:

https= ://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238235

There does seem to be some sort of weird interaction with blu= etooth and xhci as documented in the above link.
I bel= ieve the patch listed in that bug report made it to 13.1....so can you try:= 

sysctl -w net.bluetooth.usb_isoc_enable=3D0

=
Does that make any difference?
(This btw is a wild guess= just based on the values from the output you provided me)

Thanks,
Paul

On Sat, Nov 26, 2022 at 11:05 PM 0x1eef &= lt;0x1eef@protonmail.com> wrote:
The results are sort of interesting. At first, UE_INTERRU= PT_OK was at 3k+ for the USB mouse. I unplugged the mouse, and then the key= board jumped from 0 to 1k+ for UE_INTERRUPT_OK.

I have since reattached the mouse, and now both the mouse and the= keyboard have a rising interrupt count. I would guess they jump by 20, or = 30 interrupts every 2-3 seconds, with the keyboard jumping with a higher fr= equency.

Paste

ugen0.1: <Intel XHCI root HUB> at usbus0, cfg=3D0 m= d=3DHOST spd=3DSUPER (5.0Gbps) pwr=3DSAVE (0mA)

<= span>{
UE_CONTROL_OK : 0
= UE_ISOCHRONOUS_OK : 0
UE_BULK_OK = : 0
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRON= OUS_FAIL : 0
UE_BULK_FAIL : 0
UE_INTERRUPT_FAIL : 0
}

ugen0.2: <Realtek USB 10/100/1000 LAN> at= usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (350mA)

{
UE_CONTROL_OK = : 7969
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 11224
UE_INTER= RUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BU= LK_FAIL : 94
UE_INTERRUPT_FAIL : 0
}

ugen0.4: <Son= ix Technology Co., Ltd. Integrated Camera> at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DON (500mA)

{
UE_CONTROL_OK : 10
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK = : 0
UE_INTERRUPT_OK : 0
= UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS= _FAIL : 0
UE_BULK_FAIL : 0
UE_INTERRUPT_FAIL : 0
}
<= div>
ugen0.6: <vendor 0x0cf3 product 0xe500> at u= sbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA)
<= div>
{
UE_CONTROL_OK := 16
UE_ISOCHRONOUS_OK : 53214
UE_BULK_OK : 0
UE_INTERRUPT_= OK : 9
UE_CONTROL_FAIL : 0
<= div> UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FA= IL : 0
UE_INTERRUPT_FAIL : 0
}

ugen0.5: <vendor 0x= 30fa USB OPTICAL MOUSE> at usbus0, cfg=3D0 md=3DHOST spd=3DLOW (1.5Mbps)= pwr=3DON (100mA)

{
= UE_CONTROL_OK : 11
UE_ISOCHRONOU= S_OK : 0
UE_BULK_OK : 0
<= div> UE_INTERRUPT_OK : 1707
UE_CONT= ROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0<= /div>
UE_BULK_FAIL : 0
UE_I= NTERRUPT_FAIL : 0
}

ugen0.3: <SINO WEALTH Gaming KB> at usbus0, cfg=3D0 md=3DHOST= spd=3DFULL (12Mbps) pwr=3DON (500mA)

{
UE_CONTROL_OK : 21
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK = : 0
UE_INTERRUPT_OK : 1790
UE_CONTROL_FAIL : 0
UE_ISOCHRON= OUS_FAIL : 0
UE_BULK_FAIL : 0
UE_INTERRUPT_FAIL : 0
}
Be= st,
0x1eef

------- Original Message -------
On Sunday, November 27th, 2022 at 12:31 AM, Paul Procacci <pprocacci@gmail.com> wrote:

usbconfig dump_stats
Can you provide the output of the above= ? Run that a couple of times if you don't mind and do your very best t= o provide any rates of increases for any of the fields. An estimation woul= d be perfectly fine.

Thanks,
Paul

= On Sat, Nov 26, 2022 at 10:09 PM 0x1eef <0x1eef@pro= tonmail.com> wrote:
> Can you determine if i= rq 128 is being shared by any devices?

I couldn't = determine that from dmesg.boot, but I think there could be some useful info= rmation in that file. I attached the file to this e-mail. Thank you!
<= div style=3D"font-size:14px">
Best,<= /div>
0x1eef

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, November 26th, 2022 at 8:49 PM, Paul Procacci <pprocacci@gmail.com> wrote:

Can you determine if irq 128 is bein= g shared by any devices?
Usually this information can be found in = `dmesg' or '/var/run/dmesg.boot'.

vmstat inde= ed shows a device but it sometimes doesn't show all the devices sharing= that IRQ. It's possible you're being misled by vmstat.
= Just trying to get the complete picture here of devices. ;)

<= div>Thanks,
Paul Procacci

On Sat, Nov 26, 2022 at 6:21 P= M 0x1eef <0x1eef@protonmail.com> wrote:
<= /div>
Hi !

> Out of curio= sity, have you pulled a usb device one by one until the interrupts disappea= r?

I have three USB devices = connected: mouse, keyboard, and an ethernet adapter.
I tried to remove each one by one, and I di= d not see the interrupt rate change.
I have also tried a cold boot without any USB devices connec= ted, and the interrupt rate was about the same too.

I don't know if it could be related, but there's a tra= ckpad connected to the laptop that does not work. Maybe it has no relation = to the issue, but setting "hw.psm.synaptics_support" to &qu= ot;0" also did not help.

When Chromium loses focus, CPU usage usually drops to 0% a= nd does not go above 10% - for as long as I am not using Chromium. I am usi= ng the i915 / drm kernel modules.. I saw another report of high CPU usage r= elated to using those two kernel modules, but I wasn't able to identify= that as the problem in my case.

Thanks for the help.

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, November 26th, 2022 at 8:06 PM, Paul Procacci <pprocacci@gmail.com> wrote:

Hey,

Not sure of= the problem, but I don't see the correlation between Chrome and any us= b driver.
Out of curiosity, have you pulled a usb device one = by one until the interrupts disappear?

I'd be curious= to know which device is slamming the system.

Than= ks,
Paul

On Sat, Nov 26, 2022 at 6:02 PM 0x1eef <0x1eef@protonmail.com> wrote:
Hi, everyone!

When I use Ch= romium, I see a high rate of CPU usage across all four cores. The rate can = be anywhere from 20% to 50%, even above that. I am not doing anything inten= sive, just browsing twitter, reddit, YouTube or GitHub. It has been like th= is since I installed FreeBSD, but since it's not a blocker I have been = lazy about looking into it.

<= div style=3D"line-height:1.5">I don't know why it happens. I can see th= at there are a high number of interrupts on 'xhci0', and that seems= to carry over to each CPU core as well:

# vmstat -i
interrupt total rate
irq1: atkbd0 50 0
irq9: acpi0 403 0
cpu0:timer 30716618 98
cpu1:timer 25457926 81
cpu2:timer 34344531 109
cpu3:timer 25542867 81
irq128: xhci0 328107434 1044
irq130: nvme0:admin 15 0
irq131: nvme0:io0 701041 2
irq132: nvme0:io1 692045 2
irq133: nvme0:io2 792760 3
irq134: nvme0:io3 693091 2
irq135: hdac0 1718425 5
irq136: vgapci0 6273295 20
Total 455040501 1448

# dmesg | grep xhci0
xhci0: = <Intel Ice Lake-LP USB 3.1 controller> mem 0x95110000-0x9511ffff at d= evice 20.0 on pci0
xhci0: 32 bytes context size, 64-= bit DMA
usbus0 on xhci0

It might also be hel= pful to know that I tried OpenBSD on the same computer but it was unusable = for a similar reason: 95%+ interrupts on CPU. The impact that had made all = tasks extremely slow. On FreeBSD it is not as bad, but I still think think= it is not normal.

Can anyone suggest what might be wrong, tips to debug,= etc ? If more information is needed, please let me know. Thanks for your t= ime.

Best,
0x1eef




--
__________= ________

:(){ :|:& };:



--
= __________________

:(){ :|:& };:



--
= __________________

:(){ :|:& };:



--
= __________________

:(){ :|:& };:



--
__________________

:(){ :|:& };:
--00000000000077248305ee7a7396--