Chromium/Firefox rebooting system upon startup after updates - how to fix it?

[cracauer@]

I rather think RAM or PSU are at fault.

Did you do memtest already? Can you run SuperPi?

 

[Tracker]

I rather think RAM or PSU are at fault.

Did you do memtest already? Can you run SuperPi?

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.

FWIW - right now I'm in safe mode and able to run iridium browser since a couple of hours! (Even chromium worked but was slow due to 2k tabs perhaps). So I'm really confused that it might not be a hardware issue after all? Not sure how to find the culprit anymore

 

[smithi]

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

pastebin is fine, though first time I tried the above it gave me an error message, so I tried the second one:

Here is the (partial) output (from bottom) of /var/log/messages (had to use pastebin since it was too big)

https://pastebin.com/pv7p9mHR

But that one consistently throws this message:

"This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff."

So I tried the first one again, to copy its error message, and it worked! so I have the dmesg.

Argh, dual message quoting rearrangement disaster.

More anon ...

 

[smithi]

.

 

[smithi]

Sorry, having trouble with the damn Post button, way too easy to hit while moving around on a phone. I will get there ...

 

[smithi]

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.

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.

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.

My T430s idles between 40 and 45C, and hits 60C when pretty busy - and it's summer here, mid -30C days.

Running 'stress -c 4 -t 120' will get up to 80C, but that's still 20C of headroom from maximum junction temps.

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?

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.

Are you running powerd(8)? Do you have in /etc/rc.conf {performance,economy}_cx_lowest="Cmax"? Both these help greatly to run cooler.

While applying premium quality thermal paste, why not give it a new fan, after 10 years?

 

[thindil]

Another 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.

 

[smithi]

Will post dmesg soon below with verbose enabled

Ok, dmesg had one run first without verbose, that ended:

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>>---

So, chrome exits on signal 5 (TRAP), then a clean reboot, followed by a verbose boot, but ending before next exit.

I don't know why chrome is dying, can someone tell from that message?

 

[zirias@]

I don't know why chrome is dying, can someone tell from that message?

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.

 

[Tracker]

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.

Makes sense. It could be the temperature causing these issues and spiralling into more issues.

Are you running powerd(8)? Do you have in /etc/rc.conf {performance,economy}_cx_lowest="Cmax"? Both these help greatly to run cooler.

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.

While applying premium quality thermal paste, why not give it a new fan, after 10 years?

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).

Another 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.

using 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!)

 

[chrbr]

If it is a thermal issue it might be worth to clean the outlets of the fan. It might not be easy with a laptop. In best case the laptop is service friendly and can be opened by a few screws. This would at least fix the root cause of the degradation in case of a thermal issue.

 

[thindil]

using 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!)

With Nvidia, I cleared OpenGL cache. And maybe it helps? Try to delete folder .cache, or only its content, in the home directory. And if drivers are really a problem, then it may need to build the older version of the driver from ports and use it.

Also, if it is the temperature problem, CPU can be checked with command: sysctl dev.cpu | grep temperature

 

[Tracker]

If it is a thermal issue it might be worth to clean the outlets of the fan

Yes, will likely get the fan cleaned if/when I go to get the thermal paste applied.

With Nvidia, I cleared OpenGL cache. And maybe it helps? Try to delete folder .cache, or only its content, in the home directory.

I don't see OpenGL cache files on my system. Probably because it's not present Not sure what to delete from .cache

And if drivers are really a problem, then it may need to build the older version of the driver from ports and use it.

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.

Also, if it is the temperature problem, CPU can be checked with command: sysctl dev.cpu | grep temperature

That's exactly what I've been using to report earlier temperatures

 

[Tracker]

Is 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

 

[thindil]

Is 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

That's normal, to get the version of FreeBSD is better to use command freebsd-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.

Another thing comes to my mind: try to disable the kernel modules one by one and check if the problem persists.

 

[Tracker]

That's normal, to get the version of FreeBSD is better to use command 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 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

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 - 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.

Another thing comes to my mind: try to disable the kernel modules one by one and check if the problem persists.

Yes - will try that - maybe best to try to disable graphics drivers and give it a shot.

 

[mer]

    -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.

r and k can show difference if you've done freebsd-update but have not yet rebooted.
If 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

 

[Tracker]

Yes - will try that - maybe best to try to disable graphics drivers and give it a shot.

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! :/

If 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

Don't have kld_list in loader.conf - its in rc.conf - disabling it didn't work ... as above

Not sure what is wrong - does the update issue above make sense? (that it isn't updating to p7 from p6) - could that be the issue? ....... so far that seems to be the other aspect besides thermal paste application - which would have caused shutdowns iiuc

 

[mer]

(that it isn't updating to p7 from p6) -

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.

 

[Tracker]

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 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)

When I try in safe mode and try to install updates - it says nothing to download, ebooting from safe mode doesn't solve the issue either.

Does this seem like a case of a bad update? How do I fix it?

PS : I had changed Boot Environment later to try and fix this reboot issue, does that possibly affect this inability to update?

 

[smithi]

Tracker said:
"Isn't it supposed to upgrade to 13.1-p7 ? yet it shows p6"

That's normal, to get the version of FreeBSD is better to use command freebsd-version -urk. It will give you versions of userspace, the running kernel and the installed kernel (in that order).

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.

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.

It should, but all bets are off once in the twilight zone of CPU or RAM misbehaviour.

 

[smithi]

This gives the following output below

freebsd-version -urk
13.1-RELEASE-p6
13.1-RELEASE-p6
13.1-RELEASE-p7


Right, 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.

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

If you can remember '-kru' you won't get confused.

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.

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?

Yes - will try that - maybe best to try to disable graphics drivers and give it a shot.

Is it using different graphics in safe mode, according to dmesgs? If not, it's just another red herring.

 

[Tracker]

Right, 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.

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 :

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 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?

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)

Is it using different graphics in safe mode, according to dmesgs? If not, it's just another red herring.

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)

 

[thindil]

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.

Ah, thank you for the clarification. I thought that order of the arguments matter. Then everything is ok.

It should, but all bets are off once in the twilight zone of CPU or RAM misbehaviour.

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.

 

[smithi]

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

This really needs a solid entry in the FreeBSD FAQ, it's certainly arising frequently.

I'm afraid mer is mistaken or misled in this case, uncharacteristically.

All I can suggest is RTFMs: freebsd-version(1) and freebsd-update(8)

So my question is why does it not show kernel as p7 *despite* reboots ? like was mentioned here :

Kernel is only updated when there are updates to kernel. In this case some userland program/s were updated but kernel was not, hence p7 userland with still p6 kernel.

Strictly speaking reboots are only necessary for updated kernels, but if in any doubt, rebooting is always safe.

Yoir kernel won't go to p7 until some future update. Is that clear enough?