Date: Fri, 23 Aug 2019 18:45:53 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 240050] Keyboard Function Lost Post Kernel Intense Swapping after Application Process Killed by Kernel Message-ID: <bug-240050-27103-PtJmsWKNpv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-240050-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-240050-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240050 --- Comment #4 from John <jlmales@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 s= ince 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 n= ot 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 m= any 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 atte= mpt 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 d= o I look to find this. I have felt safe enough thus far to allow me to use Fre= eBSD 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.=20 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 wh= ich I have not looked for nor care about does not take long to create. The sys= tem was responsive for that 15+ minutes of intense swap activity I am certain w= as 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 h= as 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 isolat= ed 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 appr= oach 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 cau= se 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 see= ms 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 ins= tall 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 rea= sons I will skip other than to say if it was IBM VM then via VM would be just fi= ne, but X86 based VM is nowhere close to IBM VM of 1980s, let alone the even mo= re 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 other= s. I looked into and tried systat(1) and procstat(1) you suggested. systat al= lows 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= .=20 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 iter= ated 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 inclu= ding 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 the= ir information when this FreeBSD Kernel bug occurs. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240050-27103-PtJmsWKNpv>