From nobody Sun Nov 27 04:45:46 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 4NKbdp0KP0z4j2nq for ; Sun, 27 Nov 2022 04:46:06 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) (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 4NKbdn4bTsz3sh4 for ; Sun, 27 Nov 2022 04:46:05 +0000 (UTC) (envelope-from pprocacci@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-13bd2aea61bso9596226fac.0 for ; Sat, 26 Nov 2022 20:46:05 -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=on31LOwNfoZWk4bPs1SnzUYZHLjgWcw1ZbyMFrGsDSw=; b=HpkkY5vRABuQa3LHVCPewEv5H/PNEdPTwcsndQltPfAxYEKwz271zUZH2jbIZ0nR3n 1RJRVECp3kkBo22zDnuZgEIPRtYQO5t4Z7dYgGpRJnnWSELUDcWvWwTXHiJdkLsWPGV3 ujV1i56KKO0aTofuNE4oOHEyT4SZXMLXajbPqeBIYooxRi2NF7sh61AC8RwsnIF4BtWe nvKnZ7br75M2xW0GMgvtWvvxNr1q/eRqWKuoaTU/aikLt/bvPDBb3BfgIit/fOMhylxp cqYd3E05tkBXGZCwLopZCR70p8XQyllLxZVautxLFrN99vilkJvJ1Le8tuU7ACDkroEt ZvFQ== 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=on31LOwNfoZWk4bPs1SnzUYZHLjgWcw1ZbyMFrGsDSw=; b=cSDxIBrhNFmlCDgj5SFMHUp45bTbvpHO4STyAjoj2Z4PYmeahvFSEfCVRFHZQwQPCC L9Pgy9JY/N9UybSWbEMUIUKGPcgeQtOhTsb0wuFSGXX7BJ2Nbu1WyPe1Nu2OQUvvGWsI A9HqHQ3vGX73nYq5whHVRJaiP8HEoYJfBg2+v2VT582BFKDX3YipMHXMSohKmpO1Diet tn5fAGGxjMYRt9JYs0fEr55Q7eOO+tA/4y5bn4ChTI+w9vfanBkz6Nq7ga1o+Tx4gH56 lUdyIqaclxJWPhy8gnukDhbUcaYZl44pyg0JyeFWDBG6IArhXFPwQ8WGZ4QuxDw4BFIk 7A6Q== X-Gm-Message-State: ANoB5pnrVbpuo16dTdO7Go2KqmuPY5BbZBBob0LsNQiKuFQuNAc9WYro vgjwrWYzxK2njClWIscdMyclbS3Ossx2HqumqA== X-Google-Smtp-Source: AA0mqf5tIdU55c0z2P1T5thpJrft2SUzXjmmbAEbdZFthgRV6tnwvbfWYP1rRGtmFqc3Fs7KORz4+WehHDR1zydzv0o= X-Received: by 2002:a05:6870:7b89:b0:13c:e644:d7a9 with SMTP id jf9-20020a0568707b8900b0013ce644d7a9mr27137311oab.148.1669524358639; Sat, 26 Nov 2022 20:45:58 -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: Sat, 26 Nov 2022 23:45:46 -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="00000000000057368905ee6c6e4d" X-Rspamd-Queue-Id: 4NKbdn4bTsz3sh4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000057368905ee6c6e4d Content-Type: text/plain; charset="UTF-8" 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 >>>> >>>> >>>> >>> >>> -- >>> __________________ >>> >>> :(){ :|:& };: >>> >>> >>> >> >> -- >> __________________ >> >> :(){ :|:& };: >> >> >> > > -- > __________________ > > :(){ :|:& };: > > > -- __________________ :(){ :|:& };: --00000000000057368905ee6c6e4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's catching my eye here is the values for=20 ugen0.6.=C2=A0 It's a usb bluetooth device.

With that in m= ind I searched the bug database for bluetooth usb and xhci.
I came acros= s the following:

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

There does seem to be some sort of w= eird interaction with bluetooth and xhci as documented in the above link.
I believe the patch listed in that bug report made it t= o 13.1....so can you try:

sysctl -w net.bluetooth.usb_isoc_enabl=
e=3D0

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

Thanks,
Paul
On Sat, N= ov 26, 2022 at 11:05 PM 0x1eef <0x1eef@protonmail.com> wrote:
The r= esults are sort of interesting. At first, UE_INTERRUPT_OK was at 3k+ for th= e USB mouse. I unplugged the mouse, and then the keyboard jumped from 0 to = 1k+ for UE_INTERRUPT_OK.=C2=A0

I have s= ince reattached the mouse, and now both the mouse and the keyboard have a r= ising interrupt count. I would guess they jump by 20, or 30 interrupts ever= y 2-3 seconds, with the keyboard jumping with a higher frequency.

Paste

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

{
=C2=A0 =C2=A0 UE_CONTROL_OK =C2=A0 =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 UE_ISOCHRONOUS_OK =C2=A0 : 0
=C2=A0 =C2=A0 UE_BULK_OK =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRUPT_OK =C2=A0 =C2=A0 : 0
=
=C2=A0 =C2=A0 UE_CONTROL_FAIL =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 UE_ISOCHRONOUS_FAIL : 0
=C2=A0 = =C2=A0 UE_BULK_FAIL =C2=A0 =C2=A0 =C2=A0 =C2=A0: 0
= =C2=A0 =C2=A0 UE_INTERRUPT_FAIL =C2=A0 : 0
}<= /div>

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

{
=C2=A0 =C2=A0 UE_CO= NTROL_OK =C2=A0 =C2=A0 =C2=A0 : 7969
=C2=A0 =C2=A0 U= E_ISOCHRONOUS_OK =C2=A0 : 0
=C2=A0 =C2=A0 UE_BULK_OK= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 11224
=C2=A0 = =C2=A0 UE_INTERRUPT_OK =C2=A0 =C2=A0 : 0
=C2=A0 =C2= =A0 UE_CONTROL_FAIL =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 = UE_ISOCHRONOUS_FAIL : 0
=C2=A0 =C2=A0 UE_BULK_FAIL = =C2=A0 =C2=A0 =C2=A0 =C2=A0: 94
=C2=A0 =C2=A0 UE_INT= ERRUPT_FAIL =C2=A0 : 0
}

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

{
=C2=A0 =C2=A0 UE_CONTR= OL_OK =C2=A0 =C2=A0 =C2=A0 : 10
=C2=A0 =C2=A0 UE_ISO= CHRONOUS_OK =C2=A0 : 0
=C2=A0 =C2=A0 UE_BULK_OK =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_= INTERRUPT_OK =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 UE_CONT= ROL_FAIL =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 UE_ISOCHRON= OUS_FAIL : 0
=C2=A0 =C2=A0 UE_BULK_FAIL =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRUPT_FAIL= =C2=A0 : 0
}

= ugen0.6: <vendor 0x0cf3 product 0xe500> at usbus0, cfg=3D0 md=3DHOST = spd=3DFULL (12Mbps) pwr=3DON (100mA)

= {
=C2=A0 =C2=A0 UE_CONTROL_OK =C2=A0 =C2=A0 =C2=A0 := 16
=C2=A0 =C2=A0 UE_ISOCHRONOUS_OK =C2=A0 : 53214
=C2=A0 =C2=A0 UE_BULK_OK =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRUPT_OK =C2=A0 =C2= =A0 : 9
=C2=A0 =C2=A0 UE_CONTROL_FAIL =C2=A0 =C2=A0 = : 0
=C2=A0 =C2=A0 UE_ISOCHRONOUS_FAIL : 0
=C2=A0 =C2=A0 UE_BULK_FAIL =C2=A0 =C2=A0 =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRUPT_FAIL =C2=A0 : 0
<= div>}

ugen0.5: <vendor 0x30f= a USB OPTICAL MOUSE> at usbus0, cfg=3D0 md=3DHOST spd=3DLOW (1.5Mbps) pw= r=3DON (100mA)

{
=C2=A0 =C2=A0 UE_CONTROL_OK =C2=A0 =C2=A0 =C2=A0 : 11
<= span>=C2=A0 =C2=A0 UE_ISOCHRONOUS_OK =C2=A0 : 0
=C2= =A0 =C2=A0 UE_BULK_OK =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRUPT_OK =C2=A0 =C2=A0 : 1707
=C2=A0 =C2=A0 UE_CONTROL_FAIL =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 UE_ISOCHRONOUS_FAIL : 0
=C2=A0 =C2= =A0 UE_BULK_FAIL =C2=A0 =C2=A0 =C2=A0 =C2=A0: 0
=C2= =A0 =C2=A0 UE_INTERRUPT_FAIL =C2=A0 : 0
}

ugen0.3: <SINO WEALTH Gaming KB> at usbus= 0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (500mA)
=
{
=C2=A0 =C2=A0 UE_CONTROL_OK = =C2=A0 =C2=A0 =C2=A0 : 21
=C2=A0 =C2=A0 UE_ISOCHRONO= US_OK =C2=A0 : 0
=C2=A0 =C2=A0 UE_BULK_OK =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRU= PT_OK =C2=A0 =C2=A0 : 1790
=C2=A0 =C2=A0 UE_CONTROL_= FAIL =C2=A0 =C2=A0 : 0
=C2=A0 =C2=A0 UE_ISOCHRONOUS_= FAIL : 0
=C2=A0 =C2=A0 UE_BULK_FAIL =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 0
=C2=A0 =C2=A0 UE_INTERRUPT_FAIL =C2= =A0 : 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 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




--
__________= ________

:(){ :|:& };:



--
= __________________

:(){ :|:& };:



--
= __________________

:(){ :|:& };:



--
__________________

:(){ :|:& };:
--00000000000057368905ee6c6e4d--