https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240050
--- Comment #4 from John <jlma...@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. _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
