Opened 3 months ago
Closed 2 months ago
#19138 closed bug (fixed)
"bge intr handler" thread using 100% CPU
Reported by: | Morgul | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta6 |
Component: | Drivers/Network/broadcom570x | Version: | R1/beta5 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
One of the two "bge intr handler" threads on kernel_team uses 100% CPU on the CPU core it's assigned to, and it never stops that high CPU usage.
Asking on the IRC channel, I was told bge means "Broadcom Gigabit Ethernet", and that's the network card I have. It's embedded on my motherboard, and it has two ethernet ports (I guess that's why there's two such threads, one per port/network interface).
But aside from that core using 100% CPU, everything else seems to work fine, including the Internet connection through ethernet on those motherboard ports. I can't tell if it's working slower than it should, but it works perfectly alright. So please, don't blacklist this device :) It's the only one I have for network access on this computer, and it works.
The Haiku version I'm using it up-to-date R1/beta5 x86_64, hrev57937+118
Device information on listdev, it appears twice:
device Network controller (Ethernet controller) [2|0|0] vendor 14e4: Broadcom Inc. and subsidiaries device 16b1: NetLink BCM57781 Gigabit Ethernet PCIe
Related listimage entry:
7516 0xffffffff82639000 0xffffffff82666000 0 0 /boot/system/add-ons/kernel/drivers/dev/net/broadcom570x
Attachments (2)
Change History (11)
by , 3 months ago
Attachment: | syslog.txt added |
---|
comment:1 by , 3 months ago
Component: | Drivers → Drivers/Network/broadcom570x |
---|
comment:2 by , 3 months ago
I'm running Haiku on real hardware, by the way, it's not a virtual machine.
follow-up: 6 comment:3 by , 3 months ago
Please also include the PCI configuration information from the syslog for this device.
follow-up: 7 comment:4 by , 3 months ago
I can't immediately see where or how this would be happening. Can you run profile -a -f
for a few seconds, then Ctrl+C it and look for the "bge intr handler" thread in the output, and copy it here?
comment:6 by , 2 months ago
Replying to waddlesplash:
Please also include the PCI configuration information from the syslog for this device.
I have attached it, on syslog_pci.txt
comment:7 by , 2 months ago
Replying to waddlesplash:
I can't immediately see where or how this would be happening. Can you run
profile -a -f
for a few seconds, then Ctrl+C it and look for the "bge intr handler" thread in the output, and copy it here?
Sure, there you go:
profiling results for thread "bge intr handler" (183): tick interval: 1000 us total ticks: 9979 (9979000 us) expected ticks: 10278 (missed 299) unknown ticks: 9979 (9979000 us, 100.00%) dropped ticks: 0 (0 us, 0.00%) samples/tick: 0.0 no functions were hit profiling results for thread "bge intr handler" (184): tick interval: 1000 us total ticks: 1 (1000 us) expected ticks: 1 (missed 0) unknown ticks: 1 (1000 us, 100.00%) dropped ticks: 0 (0 us, 0.00%) samples/tick: 0.0 no functions were hit
comment:8 by , 2 months ago
Replying to waddlesplash:
Please see if hrev58193 improves things here.
Actually, yes! It seems it does! I upgraded my system to the latest nightly, hrev58198, and now all CPU threads are idle!
comment:9 by , 2 months ago
Milestone: | Unscheduled → R1/beta6 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Well, the profile data is useless, but good that the change fixed things for you!
syslog extract