[Bug 240050] Keyboard Function Lost Post Kernel Intense Swapping after Application Process Killed by Kernel

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 240050
           Summary: Keyboard Function Lost Post Kernel Intense Swapping
                    after Application Process Killed by Kernel
           Product: Base System
           Version: 11.3-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bhyve
          Assignee: virtualization at FreeBSD.org
          Reporter: jlmales at gmail.com

Created attachment 206810
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206810&action=edit
Various Information On Clean Boot of System

I am not new to Unix having used Unix since 1995, and as my only OS since 1999.
 I am new to FreeBSD mostly since mid July 2019, and on/off attempts over last
15 years.

This problem is serious, but likely I or only a few unique types of users will
experience this serious problem.

What makes this bug unique from information gathering and debugging point of
view is the complete loss of the keyboard.  Complete loss does mean no input
from the keyboard is accepted not is any input from the keyboard result in a
beep.

At the time of this FreeBSD Kernel condition I had been and still was in my
XFCE4 DE environment.  The mouse was responsive and applications would respond
to the mouse, but application would respond to any keyboard input.  The
CTL-Alt-Fn keyboard sequence was also unresponsive.  For reasons unknown the
only XFCE4 functions not greyed out was "Log Out".

Various applications were successfully and normally exited via the use of the
DE mouse by selecting the application menu to exit the application.

Upon "Log Out" of XFCE DE the command line appeared as is how my system is so
configured.  I did not install SLIM nor any other DE GUI based login manager. 
The command line would not accept any keyboard input and likewise no error
messages not keyboard beeps.

Two additional observations were also made.

The first and most important is I believe the condition of the keyboard was
directly related to the FreeBSD Kernel in a intense swap file activity for
about 15 minutes before the base system killed Firefox as the almost certain
object of the intense swap file activity.  Be aware I have far more than likely
to ever be needed at present of swap file space.  That means the swap file
capacity would not have been reached.  At the time of the intense swap activity
about 4.78GB of swap was being used as it so happens htop was already running
on a terminal as well as XOSview at time of intense swap file use.  When the
base system killed firefox the swap file use dropped to about 678Mb per htop. 
htop could not be exited via the keyboard "q" normally used to exit htop.

The second by pure chance of circumstance occurred at the terminal prompt after
the successful exit from XFCE DE unresponsive to any keyboard input.  I
happened to plug my phone in to charge via USB cable left in the laptop ongoing
for that purpose.  The Android phone in question has no USB access by design of
the phone (long story, but Samsung disabled any USB access on this specific
version of the phone).  Despite the phone not having USB access to files on the
phone FreeBSD  Kernel did issue messages to the terminal when the phone was
connected to the USB port.  I tried the keyboard again out of curiosity, and
found he keyboard was responsive!  This allowed me to shutdown FreeBSD normally
vs the only other option I did not wish to use being a power off.

Despite issuing a "poweroff" command and then powering on the laptop after
there appeared to be a number of file system repairs done, but I have not been
able to find where FreeBSD keeps the messages that flash by on the booting of
the FreeBSD kernel to save those messages and look at them in more detail.

I had a long career in IT and much of that career was working on bugs that were
often very difficult to find, including difficult to duplicate.  So I know more
information will be needed for when this FreeBSD Kernel bug occurs again.  I
know it will, but I do not know when.

In the process of first sorts of software I like to have on a Unix system 
bsdsar was at top of list after some basic research.  Sadly bsdsar seems to
have been an inactive project for a long time.  I have been unable to find a
alternative to bsdsar that would have at least provided some metrics on th
paging activity, extent, how much and how long before firefox was killed by the
base system.  Wat I need to know is based on the likely limitation of no
keyboard access what can I do that will collect information about this issue
that can be looked at even after I may have to hard power off the laptop vs
using "shutdown" or "poweroff" or "reboot" CLI commands?

-- 
You are receiving this mail because:
You are the assignee for the bug.