Update: I'd commented in detail about this bug (post 77,78). I run the live versions of Linux on a 4GB Core-i5 laptop (and another 4GB pentium laptop also.)
Just wanted to add: I've added 4Gb of RAM to the Core-i5 laptop for 8Gb total now. This helps a lot, but it's not a cure. With Fedora 28, the system will still cease up with maybe 2 dozen (or less depending on what's happening (video, etc) ) FF tabs opened/active. I came back here to note that, I'm currently using a Live Debian Stretch (9.5). There are obviously significant differences in the way these variants of Linux manage memory. Why? Because under the same system conditions (Gnome, same s/w programs installed and/or running), I can open WAY more tabs in FF on Debian; open more simultaneous programs, without fear of a sudden system heart- attack. In fact, it is much harder for me to cause the system freeze in Debian, even with approaching 50 tabs opened in FF developer 63... I understand there are underlying Fedora vs Debian system differences like: systemd vs init, and Wayland vs Xorg, Gnome versions (3.28.1 vs 3.22.5) and kernel revisions (4.16.3-301.fc28.x86_64 vs 4.9.110-1 (2018-07-05) ), but in all, I find Debian WAYYYY more forgiving, and more manageable, ESPECIALLY in light of this FATAL flaw, AND the known Gnome memory leak bug which can easily be remediated for in Debian by restarting Gnome (via Alt-F2, r) to free back up that memory. (The only way to accomplish this in Fedora is to actually log out of your session because of Wayland limitations.) Anyway, I jut thought it's another data point to add to the mystery. I still have to keep resource monitor opened even in Stretch, just in case, but I only crashed Stretch once over the past 3 months or so when I was in the 80's (mem % used) and let a video play for 2 hrs without checking up. Normally anyway, that percentage isn't rising above the 70's in my typical "working" environment. Finally, I'd like to mention to those asking for logs, etc., for this issue, realize that WHEN this issue occurs, it *is* essentially a heart- attack for the system. There is no recourse, and no way to gather logs. EVERYTHING ceases up- usually never to come back. A hard power-cycle is the only recourse, and NO logs which would shed light on the issue are written. EVERYTHING stops- including log writing. This is the reality. I *do* have a few logs from and old (non-live) Jesse 8.7.1 install-- for a few times when, the system did revive, after hours-- and there's nothing in there that would shed light on the issue. The (very) few (interesting/odd) entries in the log that I've researched pointed to no other instances/causes of this same issue. It would be nice after 11 or 12 years of this issue, if someone higher up and more knowledgeable in the development "food chain" would would simply replicate the issue, it's not really that hard to do so at all. It honestly is a show-stopper. Ciao. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/159356 Title: When DMA is disabled system freeze on high memory usage Status in linux package in Ubuntu: Incomplete Bug description: I run a batch matlab job server here at my lab, running Dapper 6.06 (for the LTS). One of the users has submitted a very memory-consuming job, which successfully crashes the server. Upon closer inspection, the crash happens like this: 1. I run matlab with the given file (as an ordinary, unpriveleged user) 2. RAM usage quickly fills up 3. Once the RAM meter hits 100%, the system freezes: All SSH connections freeze up, and while switching VTs directly on the machine works, no new processes run - so one can't log in, or do anything if he is logged in. (Sometimes typing doesn't work at all) Note that the swap - while 7 gigs of it are available - is never used. (The machine has 7 gigs of RAM as well) I've tried the same on my Gutsy 32-bit box, and there was no system freezeup - matlab simply notified that the system was out of memory. However, it did this once memory was 100% in use - and still, swap didn't get used at all! (Though it is mounted correctly and shows up in "top" and "free"). So first thing's first - I'd like to eliminate the crash issue. I suppose I could switch the server to 32-bit, but I think that would be a performance loss, considering that it does a lot of heavy computation. There is no reason, however, that this should happen on a 64-bit machine anyway. Why does it? WORKAROUND: Enabling DMA in the BIOS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
