[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

--- Comment #4 from John <jlmales at gmail.com> ---
(In reply to pete from comment #3)

Pete,

Thanks for reply and information.

I have a few questions.

I installed FreeBSD just after the 11.3 release.  I used the USB image and
installed all but the sources.  I was expecting the base system and kernel
updates would occur via updates.  So far that appears not to occur assuming no
base/kernel updates since the release of 11.3.

I have used pkg update/upgrade that appears to keep the installed packages up
to date.

About 4 weeks ago I looked into if and why the FreeBSD kernel is or not
upgraded. I ave not determined yet if there have been base/kernel updates since
the 11.3 release.  Should I have installed sources?  Are sources needed for
base/kernel updates?  Why if not needed for installing FreeBSD?  I choose not
to install sources as I did not feel I would have a need to customized the
FreeBSD kernel.  I had for many reasons had to many times (usually about 4-8
times a year, sometimes many more) configure and compile the Linux Kernel many
many times over the past 20 years.  I assumed stable FreeBSD kernel meant
stable and stable updates would occur.  I sense I am incorrect with that
assumption, but not certain what the best approach is for FreeBSD kernel
updates while not destabilizing my DE and installed packages.  My last attempt
at FreeBSD as test system a couple years ago updates to packages and kernel
would cause frequent issues and I could not access any X, DE and/or key DE apps
for months at time. One very very creative effort taking lots of timet dug me
out of one of those instances of many months of no access beyond CLI after
boot.  I have always favoured CLI after boot by choice so I can then choose
what to do next.  Is there a safe approach to update kernel/base so the
packaged installed are not out of sync with the kernel/base?  If so where do I
look to find this.  I have felt safe enough thus far to allow me to use FreeBSD
as my primary system.  Long term ideal is o find a way to create a LiveCD
FreeBSD like OliveBSD for stability handful of systems I have that run 24/7/365
from another Kernel common to LiveCD images. 

I believe the core issue is FreeBSD decided there was too much time and swap
activity being used by Firefox so FreeBSD killed firefox.  The core dump which
I have not looked for nor care about does not take long to create.  The system
was responsive for that 15+ minutes of intense swap activity I am certain was
all due to Firefox.  As I mentioned swap file used dropped to basically no swap
file space once Firefox was killed by FreeBSD.  I have had a few of these
events of intense swap file activity for a shorter time period where FreeBSD
kills firefox, but this is first time after such an set of similar events has
the keyboard been dead from FreeBSD kernel perspective, let alone carry to the
CLI after DE is shut down via mouse still active.

For moment I think to keep all things equal I like to stay with the version of
the FreeBSD kernel I have for one key reason.  The less variables I change the
better it is to isolate the issue.  I believe that once the issue is isolated
then it can be determined with ease if this issue still exists with more
current versions of the FreeBSD Kernel/Base.  The reason I favour this approach
is based on my extensive past professional experience working with bugs that
are difficult to duplicate as well as being complex in factors that are cause
is the less that is changed the better and often such issues become more
difficult to try to duplicate with newer versions as the underlying bug seems
for indirect reasons to become deeper to reach ergo much more difficult to
isolate/duplicate.

I do not know if there are any Free BSD sandboxes where I can attempt to
duplicate the issue only needed CLI based environment that allows me to install
other CLI applications that may help in my duplicating and collecting system
information about the bug.  If there is many that is an option to consider for
this issue. This issue needs to be done bare metal and not via a VM for reasons
I will skip other than to say if it was IBM VM then via VM would be just fine,
but X86 based VM is nowhere close to IBM VM of 1980s, let alone the even more
refined IBM VM of current day.  Suffice to say I have lots of systems and VM
experience dating back to the 1980s and onward for some years agmonst others.

I looked into and tried systat(1) and procstat(1) you suggested.  systat allows
some vmstat information to be displayed, but in awkward manner.  Awkward
meaning not compatible with a table or CSV format of data such as dstat
(<http://dag.wiee.rs/home-made/dstat/> or sar in Linux create that I suspect
bsdsar would also provide.  I used sar via systat in Linux and I used dstat
alot of time Linux to document what was almost always a similar set of
conditions, but caused different variations of issues with the Linux Kernel. 
vmstat -s in my opinion produces the type of information for sure needed for
this FreeBSD issue, but again not in a table or CSV format that can be iterated
over an interval of time.

This means I am still at basic loss of how I can collect information
proactively as once the bug occurs I cannot enter any commands at all including
vmstat, systat, procstat, et al to get a sense of the FreeBSD Kernel bug.  It
means I have to run commands that can just run and collect information with
timestamps proactive so these are running and ideally still able to log their
information when this FreeBSD Kernel bug occurs.

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