It's a laptop - I ran memtest for a while for RAM - that seemed to run fine. For power the charger voltage seemed fine (I mostly keep it plugged in) when measured with a digital voltmeter at a local store.I rather think RAM or PSU are at fault.
Did you do memtest already? Can you run SuperPi?
I was thinking more that you might get some clues from /v/l/messages after it did crash ...
The thing is /var/log/messages doesn't seem to be picking up any obvious errors, but will paste it here in below dmesg. Here is the log for dmesg (had to use pastebin since it was too big)
[CMD]sudo dmesg Password:Copyright (c) 1992-2021 The FreeBSD Project.C - Pastebin.com
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.pastebin.com
Here is the (partial) output (from bottom) of /var/log/messages (had to use pastebin since it was too big)
80C is no way fine, and 100C is critical. Offhand, I'd say that's likely your problem right there, especially when initialising hundreds of browser tabs.
Fan/s, dust, heatsink paste; try getting normal operating temperature down to more like 50-60C, 80C max on big compilations, long rendering jobs etc.
I thought the same initially - but then when FF/Chrome worked in safe mode - it lead me to believe that cpu temp couldn't be the reason - although I do have to get the thermal paste reapplied anyways. Would it still have worked in safe mode if thermal paste was the issue?
Will post dmesg soon below with verbose enabled
wlan0: link state changed to DOWN
pid 97970 (chrome), jid 0, uid 1001: exited on signal 5
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 done
All buffers synced.
GEOM_ELI: Device ada0p2.eli destroyed.
GEOM_ELI: Detached ada0p2.eli on last close.
Uptime: 14m50s
GEOM_ELI: Device ada0p3.eli destroyed.
GEOM_ELI: Detached ada0p3.eli on last close.
---<<BOOT>>---
Chromium uses runtime assertions that cause a TRAP when violated, so if it's crashing, it's very much expected to see this signal. Still there's no reason this should ever lead to a system crash/reboot.I don't know why chrome is dying, can someone tell from that message?
Makes sense. It could be the temperature causing these issues and spiralling into more issues.I should have said "one of your problems". You appear to be seeking a single cause, but these sorts of issues with fairly indeterminate symptoms quite often have multiple causes. .....
You say that safe mode lowered temperatures by maybe 20C. That's huge, and gives you headroom for any other problem, like power or RAM, to not be triggered. Again, don't assume one single cause. .....
Temperature is the greatest enemy of electronics. If you get that under control, other issue/s may not manifest.
Yes , running powerd_enable in rc.conf .... not sure about "{performance,economy}_cx_lowest" - haven't used it. FYI - in safe mode it's working just like a normal laptop until now - no reboots at all.Are you running powerd(8)? Do you have in /etc/rc.conf {performance,economy}_cx_lowest="Cmax"? Both these help greatly to run cooler.
Fan is working fine, can hear it - in case the thermal paste issue doesn't solve it then I might have to discard this (spare parts will cost more than getting a second hand spare machine).While applying premium quality thermal paste, why not give it a new fan, after 10 years?
usingAnother options: what graphic card do you use? And what driver's version with them?
The last time when I got that kind of reboots, it was fault of broken Nvidia driver.
kld_list="i915kms"
in rc.conf - you may be right actually - it could be that the recent updates tinkered with the drivers and the drivers are malfunctioning/heating up and causing the reboot - how does one go about fixing it? (I specifically remember the last updates installing some kind of extra drivers!)usingkld_list="i915kms"
in rc.conf - you may be right actually - it could be that the recent updates tinkered with the drivers and the drivers are malfunctioning/heating up and causing the reboot - how does one go about fixing it? (I specifically remember the last updates installing some kind of extra drivers!)
sysctl dev.cpu | grep temperature
Yes, will likely get the fan cleaned if/when I go to get the thermal paste applied.If it is a thermal issue it might be worth to clean the outlets of the fan
I don't see OpenGL cache files on my system. Probably because it's not present Not sure what to delete from .cacheWith Nvidia, I cleared OpenGL cache. And maybe it helps? Try to delete folder .cache, or only its content, in the home directory.
This seems like a pain - what makes it more complicated (in my mind) is that I tried upgrading it from safe mode and it won't upgrade somehow to 13.1-p7 (from p6) .....the last set of updates that I remember doing manually I saw a lot of what seemed like graphics drivers of sorts in the download and extract phase. I distinctly remember that because it came across as a bit odd (compared to earlier updates). So I'm not entirely sure if they did install or not, or installed partially and are causing this issue. Wonder if there's some easy fix to the situation.And if drivers are really a problem, then it may need to build the older version of the driver from ports and use it.
That's exactly what I've been using to report earlier temperaturesAlso, if it is the temperature problem, CPU can be checked with command:sysctl dev.cpu | grep temperature
uname -a
FreeBSD echo 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
No updates needed to update system to 13.1-RELEASE-p7.
src component not installed, skipped
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
That's normal, to get the version of FreeBSD is better to use commandIs this normal ? it says it's a lower version but won't update to latest patch p7
uname -a
FreeBSD echo 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64
but doing freebsd-update fetch/install gives
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
No updates needed to update system to 13.1-RELEASE-p7.
src component not installed, skipped
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
Isn't it supposed to upgrade to 13.1-p7 ? yet it shows p6
I'm in safe mode fwiw ..... wondering if this could be related to the main reboot issue
freebsd-version -urk
. It will give you versions of userspace, the running kernel and the installed kernel (in that order).This gives the following output belowThat's normal, to get the version of FreeBSD is better to use commandfreebsd-version -urk
. It will give you versions of userspace, the running kernel and the installed kernel (in that order).
freebsd-version -urk
13.1-RELEASE-p6
13.1-RELEASE-p6
13.1-RELEASE-p7
Yes - that's what makes me suspect - the computer functions normally in safe mode but only reboots in normal mode , I'm leaning towards there being some issues with drivers.Temperature can be a problem (80-100 are definitely too high), but in that situation, as far I know, a computer should shut down itself not just rebooted.
Yes - will try that - maybe best to try to disable graphics drivers and give it a shot.Another thing comes to my mind: try to disable the kernel modules one by one and check if the problem persists.
-k Print the version and patch level of the installed kernel.
Unlike uname(1), if a new kernel has been installed but the
system has not yet rebooted, freebsd-version will print the
version and patch level of the new kernel.
-r Print the version and patch level of the running kernel.
Unlike uname(1), this is unaffected by environment variables.
Update - tried disabling quite a few things in rc.conf like ntpd, ntpdate, kld_list, linux and in boot/loader.conf kern.vty ..... but result is the same - it just reboots unless it's in safe mode! :/Yes - will try that - maybe best to try to disable graphics drivers and give it a shot.
Don't have kld_list in loader.conf - its in rc.conf - disabling it didn't work ... as aboveIf you are using the "drm kmod" graphics drivers (i915 or other modeset) I would make sure you don't have them loaded from loader.conf but have them loaded from rc.conf (kld_list variable).
Heck for testing, I'd not have them either place, boot into console, handload the appropriate kmod then do startx
Have you rebooted after doing the update? What your output tells me is:(that it isn't updating to p7 from p6) -
That's the issue - it won't let me even try and work in normal mode with trying to update (already done) and reboot (not done as you pointed out). I tried to login in normal mode and reboot but it still gives the same output (p6 and not p7)Have you rebooted after doing the update? What your output tells me is:
you are currently running a -p6 kernel, have installed a -p7 kernel but have not yet rebooted into the p7 kernel.
That's normal, to get the version of FreeBSD is better to use commandfreebsd-version -urk
. It will give you versions of userspace, the running kernel and the installed kernel (in that order).
Temperature can be a problem (80-100 are definitely too high), but in that situation, as far I know, a computer should shut down itself not just rebooted.
This gives the following output below
freebsd-version -urk
13.1-RELEASE-p6
13.1-RELEASE-p6
13.1-RELEASE-p7
I was under the impression it should update to p7 since it said earlier it was downloading files for the update ("No updates needed to update system to 13.1-RELEASE-p7.") - but didn't update even after reboot(s)/freebsd-update fetch/installs
Yes - that's what makes me suspect - the computer functions normally in safe mode but only reboots in normal mode , I'm leaning towards there being some issues with drivers.
Yes - will try that - maybe best to try to disable graphics drivers and give it a shot.
Maybe I am misunderstanding - I think mer mentioned that it's showing p6 as update and asked me if I had rebooted or not for it to reflect p7 ? If I understand correctlyRight, so both installed (-k) and running (-r) kernel are at p6, and userland (-u) is at p7. So no update is needed, like it said.
What your output tells me is:
you are currently running a -p6 kernel, have installed a -p7 kernel but have not yet rebooted into the p7 kernel.
In normal mode after putting it off - it doesn't go to 100 C - 100 C is usually the highest it used to go to earlier ... but with these reboots I highly doubt it's touching 100 C (it simply doesn't give the change to open programs/allow system load - reboots before that)In safe mode it runs cooler, in normal mode it runs up to 20C hotter, as you've said.
I can't see why heat isn't self-evidently the main problem?
I'm not sure how to check that in safe mode - but it does seem to have normal fonts (as opposed to huge fonts when I disable kld_list in rc.conf ..... if that's, presumably, the same graphics)Is it using different graphics in safe mode, according to dmesgs? If not, it's just another red herring.
Ah, thank you for the clarification. I thought that order of the arguments matter. Then everything is ok.Tracker said:
"Isn't it supposed to upgrade to 13.1-p7 ? yet it shows p6"
No, in the opposite order:
First installed kernel, second running kernel, third userland version. So Tracker's is showing userland last, i.e. userland IS at p7, while last kernel update was at p6.
This is why freebsd-version(1) shows the options in order '-kru' (not '-urk'), though as usual any order of options given will produce the same result. So if you remember it as '-kru' you see results in that order.
If I remember correctly, RAM is ok. A CPU shouldn't even start at boot (instant shutdown again, during the bios test hardware state) if its temperature is too high. At least it was a couple of years ago when I was playing with overclocking.It should, but all bets are off once in the twilight zone of CPU or RAM misbehaviour.
Maybe I am misunderstanding - I think mer mentioned that it's showing p6 as update and asked me if I had rebooted or not for it to reflect p7 ? If I understand correctly
So my question is why does it not show kernel as p7 *despite* reboots ? like was mentioned here :