Linux Mint 19.2 & 19.3 freezes randomly and almost daily [SOLVED]

[Larry78723]

Could this be a RAM mismatch problem? The OP says he added 2 RAM sticks. The Optiplex 7010 requires DDR3 PC3-10600 1333MHz, PC3-12800 1600MHz Non-ECC DIMM memory.

[SMG]

No the kernel is not the problem...I could do an update to either one now if it would help in troubleshooting.

Just because kernel updates include bug fixes and the like, it's usually best to keep it updated. The only time not to do it is when there is a known issue with it and those are usually pretty obvious.

Would bypassing the UPS be a good idea for troubleshooting?

The fact you have the UPS should be a positive and a help to this type of situation as long as it is working properly. I've never tested or checked one, but I think leaving it there is not a negative. If it is working that's good, if it is not then I presume it would the same as not having it installed at all. Someone else with more experience with them might be able to give better advice.

What further memory checks could I run? I've done the built in Dell check and memtest86 and neither indicated problems.

I will follow the steps in your referenced fedoraforum post, I'm just reading it now. FWIW the bios was recently updated to A29 which is the latest for the Optiplex 7010 (Feb 2018).

I do not know much about the MTTR issue beyond what was in the post. As I understood it there might be a BIOS setting related to it? Every BIOS is different, so I can not make specific recommendations of where it might be if it exists.

There have been a lot of changes/improvements to memory over the years, but sometimes things we think should not affect the system do. I do not know if it might be a subtle timing mismatch, a seating alignment issue, or something else.

[boxereighty]

OK, I removed two sticks of RAM. The machine is back to 8gb, just as it was before the freeze issue started. The very same MTRR warnings are showing up in the systems log. So far the machine is running OK. Unfortunately the machine has run up to 6 days without issue before the freeze/autoshutdown issue presents itself. If I can get 7 full days without a freeze I'll call this subject closed then maybe go on Dell forums to see about adding the other sticks back to the machine or adding two sticks of 8gb memory.

I think I have my mind around the MTRR situation. Unfortunately my ignorance is again an obstacle. I'm not sure how to amend the bios menu but it sounds like that would indeed eliminate the warning. I'm not sure if that is contributing to the problem but I'll do that when I can.

[boxereighty]

Here is a follow-up on the MTRR issue I found:

https://askubuntu.com/questions/244473/ ... chunk-size

I'm just not sure exactly how or where to insert the instruction mentioned.

[SMG]

You can run the following to see if those messages are still there since you removed some memory. I noticed the messages I posted indicated they repeated in eight sets with each set having one each 32, 64, 128, 256, 512, 1G, 2G line. You did remove 8GB of memory, so maybe there is a correlation?

Code: Select all

journalctl -b | grep -i "BAD" | tee >(gzip --stdout > journalctl_$USER.gz)

This will print the messages that happened on the current boot (most recent start-up) that have the letter sequence "bad" in them and print them to the file journalctl_(yourname).gz and to your screen. The file will be located in your /home/login_name directory.

Kernel parameters are usually added after "quiet splash" on that particular line in grub, but let's see if the lines are still there. That links seems to indicate a lot of parameters would be needed to clear the message.

I did notice on the link referenced in the original link I gave you that a person commented, "Depending on the age of the motherboard, it might not handle the memory you have (might be a bit too large per unit). Doesn't mean you can't work around it, but loosing memory is a sign that it exceeds the capacity of the CPU. " Didn't realize there might be such a thing, but I'm not a memory expert either.

[boxereighty]

Here is the result of the journalcontrol grep request from this morning:

Code: Select all

journalctl -b | grep -i "BAD" | tee >(gzip --stdout > journalctl_$USER.gz)
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 64K         chunk_size: 32M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 64K         chunk_size: 64M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 64K         chunk_size: 2G         num_reg: 10          lose cover RAM: -1G
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 128K         chunk_size: 32M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 128K         chunk_size: 64M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 128K         chunk_size: 2G         num_reg: 10          lose cover RAM: -1G
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 256K         chunk_size: 32M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 256K         chunk_size: 64M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 256K         chunk_size: 2G         num_reg: 10          lose cover RAM: -1G
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 512K         chunk_size: 32M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 512K         chunk_size: 64M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 512K         chunk_size: 2G         num_reg: 10          lose cover RAM: -1G
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 1M         chunk_size: 32M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 1M         chunk_size: 64M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 1M         chunk_size: 2G         num_reg: 10          lose cover RAM: -1G
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 2M         chunk_size: 32M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 2M         chunk_size: 64M         num_reg: 10          lose cover RAM: -16M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 2M         chunk_size: 2G         num_reg: 10          lose cover RAM: -1G
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 4M         chunk_size: 32M         num_reg: 10          lose cover RAM: -14M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 4M         chunk_size: 64M         num_reg: 10          lose cover RAM: -14M
Jan 10 05:56:04 bcsmith-OptiPlex-7010 kernel: *BAD*gran_size: 4M         chunk_size: 2G         num_reg: 10          lose cover RAM: -1022M

For all I know this message was posted on every start in the three years the computer operated correctly. So far I'm going on three days of no problems since the RAM was reduced to 8gb. Another 4 days and I'll be satisfied. There seems to be some controversy on the Dell site as to what the max ram is for the 7010SFF. It was delivered with 4gb or 8gb I think.

Code: Select all

Jan 10 05:56:05 bcsmith-OptiPlex-7010 kernel: [    0.000000] please specify mtrr_gran_size/mtrr_chunk_size

Obviously the system is looking for the definition of MTRR though and maybe if that was done I could go back to 16gb. I just don't want to screw up the Bios which otherwise seems happy. I'll cross that bridge on Friday. FWIW, I'm wanting to set up an OSX VM and I think it may need the extra RAM for that project.

[SMG]

The prior log info had 8 sets with each set having one each each 32, 64, 128, 256, 512, 1G, 2G lines.
The info run this morning has 7 sets with each set having 32, 64, 2G lines.

I'll compare the two sets and let you know if I notice anything else which might be a clue as to what is occurring.

[SMG]

I compared the initial list from the log to the output this morning. I mentioned in my prior post there were 8 sets in the original log, but only 7 sets this morning. There were two sets of gran_size: 64K in the first set, but only one showed up with the messages this morning.

The lines in blue below are the ones which appeared in both logs. (No way to highlight specific lines when they are inside the code tags, so I apologize for the list.) The amount at the end of the lines in parenthesis is the value from this morning. In each case, less memory was lost. Oddly, the last set of three at the end lost a different amount that the prior sets. To me, it seems there is something different about the memory removed when compared to the memory which remains given the difference in the errors. However, I have not been able to find anything which might give possible advice on the impact.

Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -1536M(-1G)
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: -24M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: -24M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -1536M
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 32M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 64M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 128K chunk_size: 2G num_reg: 10 lose cover RAM: -1536M(-1G)
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 32M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 64M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 256K chunk_size: 2G num_reg: 10 lose cover RAM: -1536M(-1G)
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 32M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 64M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 512K chunk_size: 2G num_reg: 10 lose cover RAM: -1536M(-1G)
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 32M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 64M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 1M chunk_size: 2G num_reg: 10 lose cover RAM: -1536M(-1G)
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 32M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 64M num_reg: 10 lose cover RAM: -24M(-16M)
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 128M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 256M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 512M num_reg: 10 lose cover RAM: -16M
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 1G num_reg: 10 lose cover RAM: -512M
Jan 6 08:39:45 *BAD*gran_size: 2M chunk_size: 2G num_reg: 10 lose cover RAM: -1536M(-1G)
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 32M num_reg: 10 lose cover RAM: -22M(-14M)
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 64M num_reg: 10 lose cover RAM: -22M(-14M)
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 128M num_reg: 10 lose cover RAM: -14M
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 256M num_reg: 10 lose cover RAM: -14M
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 512M num_reg: 10 lose cover RAM: -14M
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 1G num_reg: 10 lose cover RAM: -510M
Jan 6 08:39:45 *BAD*gran_size: 4M chunk_size: 2G num_reg: 10 lose cover RAM: -1534M(-1022M)

[boxereighty]

After eight days of trouble free operation I will consider the freezes SOLVED on the Optiplex since reverting to the original 2 4gb sticks of RAM the machine came with. It is hard to prove a negative and since I was unable to resolve why the extra RAM caused the problem to begin with may have to start another thread if the freezes begin again. I still get multiple daily MTRR warnings about unset chunk size. Maybe that should be another thread since there is no proof that this warning is related to the freezes with 16gb of RAM installed on this machine.

[SMG]

Glad you have been able to find stability.

To mark the thread itself solved, go to the very first post in the thread and edit the title (click the pencil icon) and add [SOLVED] to the title and click Submit for the post.

[Thrasher]

In case you have not in fact resolved this issue...
Your plight sounds a lot like a problem I solved for my son. His Windows PC would periodically restart without explanation. Randomly at first every few days, but eventually could not even complete a boot to desktop. Similar diagnostics, troubleshooting, reinstalls and CMOS / BIOS refreshing did not resolve the issue. Eventually, having removed the mobo to bench test with a separate PSU I had it running stable. Racked my brain as to what about the case could cause the issue. No obvious shorts etc.

His turned out to be the case Power Switch.
Simple to replace, and nary a repeat.

To test this, just remove the PWR switch pin connections from your mobo header. Start the PC by momentarily shorting these mobo pins. For more extensive testing I just swapped the reset switch to the PWR pins and left the PWR switch disconnected.

Pays to think "outside the box", eh?

[boxereighty]

After 6 months of nearly daily use after 2 sticks of 4gb RAM was removed this problem has been resolved. There has never been another glitch of any kind with the operation of the machine/system as described above after the RAM was removed. It begs the question a bit as to whether there was a local problem with one of the sticks or whether the machine itself is somehow limited to only 8gb of RAM. Multiple diagnostics of RAM when all 16gb were installed all indicated there was no organic problem with the RAM as installed which leads me to believe it may be a design limitation of the Optiplex to handle 16gb. Details on that were a little sketchy on the Dell forums. It works adequately on 8gb anyway if operations with multiple VMs is limited so I can live with it as is.

Thanks to all