https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226961
Mark Linimon changed:
What|Removed |Added
Keywords||patch
--
You are receiving this ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226961
Hans Petter Selasky changed:
What|Removed |Added
CC||hsela...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
Bug ID: 226968
Summary: IRQ storm on cpu0 timer when holding down key on USB
keyboard
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #1 from Johannes Lundberg ---
I should mention that I'm using a EVDEV enabled kernel. I have not tried this
on a non-EVDEV kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #2 from Johannes Lundberg ---
Also, the laptop's built-in PS/2 keyboard does not show this behavior, only the
external USB keyboard (tried two different keyboards).
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #3 from Hans Petter Selasky ---
Hi,
I have been discussing some patches with Bruce Evans on this topic. The problem
is the keyboard repeat rate is zero, which cause the timer to trigger
instantly. This issue fell off my radar.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #4 from Johannes Lundberg ---
Hi
I tried a variant of this patch a few weeks ago and it did help a bit to reduce
interrupts but the problem described in this report still remains, even with
the patch you provided.
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #5 from Hans Petter Selasky ---
Can you try to identify the timer causing this?
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225794
--- Comment #38 from Andriy Gapon ---
(In reply to David.Boyd49 from comment #37)
That's interesting and puzzling.
When you rebooted to multi-user, did you still have the patched kernel?
If so, then maybe when you booted the hardware (or V
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #6 from Johannes Lundberg ---
Here output from
# dtrace -n 'profile-997hz /arg0/ { @[func(arg0)]=count(); }'
run for about 10 seconds for each state
First idle state
-- SNIP --
linux_common.ko`linux_kernver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225794
--- Comment #39 from david.boy...@twc.com ---
Andriy,
Yes, the patch disabling dareprobe(s) was/is applied to the kernel in both
single-user and multi-user mode.
In single-user mode the error condition in the dmesg output only appears if t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225794
Warner Losh changed:
What|Removed |Added
CC||i...@freebsd.org
--- Comment #40 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226968
--- Comment #7 from Hans Petter Selasky ---
Can you try to trace the "sbt" argument passed to:
kernel`callout_reset_sbt_on 85
?
It might be some invalid timeout.
--HPS
--
You are receiving this mai
13 matches
Mail list logo