What's happening to my system ? I see some ugly errors of various type.

ZioMario said:
I can't use drm-61 shipped with the 14.2-RELEASE ; my monitor does not turn on. It does not work.
I don't want to use 13.4. I would like that you fix the problem with the drm-61 on 14.2. thanks.
Click to expand...
drm-515 was built for 13.X. drm-61 was built for 14-CURRENT, now 14.X.

Open a PR if your monitor doesn't work with drm-61.
 
cracauer@ said:
That rule is very obsolete, if it ever was valid.
Click to expand...

That was a rule for Solaris systems back in the day. Later the recommendation was 1-for-1 swap to RAM. For DBMS systems, i.e. Oracle, the recommendation is no swap whatsoever.

cracauer@ said:
On FreeBSD a good rule is just RAM + a little extra so that you can save any kernel core dump.
Click to expand...

I think it depends on your application of FreeBSD. Ideally one shouldn't use any but professionally I see a lot of systems using swap because systems were initially sized correctly but as users put more apps on their servers they start using swap.

One can direct kernel core dumps to an unused swap partition. Use it for kernel dumps and not for swap.

cracauer@ said:
Otherwise it depends on what you are doing with your system. A good reason to have at least a little bit of swap is that you can use it to figure out when you are running out of RAM.
Click to expand...

At home I use 1x or 2x swap to RAM ratio for new systems. As RAM is added no additional swap is assigned. That's a compromise. At $JOB we assign only 4 GB swap regardless of RAM installed.
 
cy@ said:
drm-515 was built for 13.X. drm-61 was built for 14-CURRENT, now 14.X.

Open a PR if your monitor doesn't work with drm-61.
Click to expand...

In the while I fixed that problem,by compiling the module from the ports. Instead,it does not work if it is installed from packages.
 
ZioMario said:
In the while I fixed that problem,by compiling the module from the ports. Instead,it does not work if it is installed from packages.
Click to expand...
This is because packages are built for the lowest supported version. 14.1 is still supported and as such the package is distributed for it, not 14.2. This should fix itself when 14.1 is desupported and packages are rebuilt for 14.2.
 
I found another problem. I saw that the bhyve vm with Windows 11 inside is eating the 140% of the cpu's power. I killed it. And no,it was not doing special tasks. I will investigate more.
 
ZioMario said:
I can't use drm-61 shipped with the 14.2-RELEASE ; my monitor does not turn on. It does not work.
Click to expand...
This is probably because drm-61 package is built against 14.1. You need to built it by yourself for 14.2.
BTW, I have this running very well on my installations.
 
ZioMario said:
View attachment 21442
Click to expand...
This screenie clearly says you have too many firefox processes out there... A commonly overlooked offender of low RAM is frankly having a lot of tabs open in Firefox. This thread mentioned that VMs were a suspect for low RAM - but I see just 2 VMs.

Not a fun idea to consider, because it would be incredibly inconvenient - but I'm gonna lay it out there anyway, because it's the proverbial elephant in the room: Clean up your Firefox tabs, close what you're not using - you'll see a difference in your RAM right away.
 
Hello bro.

your help is appreciated. I've investigated and I detected more problems :

1) thunar was eating all the power as root : I don't know why. I've reinstalled thunar and now it stopped

2) two qemu vms with 1 gb of memory each were eating 100% of the cpu : don't know why. I've reinstalled qemu and now it stopped

3) not sure about firefox : I keep open only two firefox applications with 6 tabs each one not in the vm,but on the host. I'm not sure that these tabs only can eat all the cpu's power.
 
ZioMario said:
3) not sure about firefox : I keep open only two firefox applications with 6 tabs each one not in the vm,but on the host. I'm not sure that these tabs only can eat all the cpu's power.
Click to expand...
Did you know that Discord.com, in just one Firefox tab, can eat up to 2 GB of RAM, easy? There's lots of other sites that force a browser to use a ton of RAM: espn.com comes to mind, and news sites.

In the past, I did notice that the tab with Discord ate up a ton of CPU power as well. Discord is a site with lots of dynamic content, which does require CPU and RAM usage. Very much in contrast with sites like cgit.freebsd.org, where content is pretty much static.

Up-to-date apps generally do make an effort to be disciplined with their usage of hardware resources.
 
I've just realized that when I start firefox like this :

[marietto@marietto ~]==> firefox

the "top" command shows that there are 3 sessions of firefox opened (3 firefox executables at the same time !). Just like this :

Code: 
[marietto@marietto ~]==> ps ax | grep firefox

5509 v0  S      1:00.63 firefox
5515 v0  I      0:00.04 /usr/local/lib/firefox/firefox -contentproc -appDir /usr/local/lib/firefox/brows
5516 v0  S      0:00.70 /usr/local/lib/firefox/firefox -contentproc 2 tab
5517 v0  I      0:01.76 /usr/local/lib/firefox/firefox -contentproc -appDir /usr/local/lib/firefox/brows
5519 v0  I      0:00.16 /usr/local/lib/firefox/firefox -contentproc -appDir /usr/local/lib/firefox/brows
5521 v0  S      0:14.98 /usr/local/lib/firefox/firefox -contentproc 7 tab
5524 v0  S      0:44.46 /usr/local/lib/firefox/firefox -contentproc 10 tab
5538 v0  S      0:00.11 /usr/local/lib/firefox/firefox -contentproc 17 tab
5558 v0  S      0:00.08 /usr/local/lib/firefox/firefox -contentproc 18 tab
5570 v0  S      0:00.07 /usr/local/lib/firefox/firefox -contentproc 19 tab
5572 v0  S      0:00.56 /usr/local/lib/firefox/firefox -contentproc 21 tab

Is this a normal behavior ? I really want to know why.

I'm using :

Code: 
[marietto@marietto ~]==> firefox --version
Mozilla Firefox 134.0

on :

[marietto@marietto ~]==> uname -a
FreeBSD marietto 14.2-RELEASE FreeBSD 14.2-RELEASE #0 releng/14.2-n269506-c8918d6c7412-dirty: Fri Dec 20 23:41:14 CET 2024     marietto@marietto:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
 
ok,but here there is something that's not normal,because I see a lot of firefox crashes with heavy production of core files.
 
Yeah, browser crashes are what gave me the push to ditch pre-compiled pkg and switch to ports, even for Firefox. And these days, it takes less than 3 hours to compile, esp. with 32 GB of RAM.
 
astyle said:
Yeah, browser crashes are what gave me the push to ditch pre-compiled pkg and switch to ports, even for Firefox. And these days, it takes less than 3 hours to compile, esp. with 32 GB of RAM.
Click to expand...

All these firefox crashes are a novelty for me. They never happened until some months ago.
Are they due to Firefox ? Because I'm reading about more and more people being unhappy with the way Firefox works recently,even on Linux.
 
I had massive problems with Firefox crashing too.

Turned out this happened if sites wanted to use WebGL. Don't know if it is related to your problem, but try to disable WebGL for a quick test.

See my old thread on how to do it.
 
You must log in or register to reply here.
Back
Top