# Voluntary system reboot on video playing in browser



## lefsha (Feb 18, 2018)

Dear all,

First of all many greetings to everyone who are using FreeBSD and participating in that forum! Hello Moderators!

Just recently installed FreeBSD 11 STABLE mainly due to ZFS. My first Unix many years ago was FSBD since 4.0 version, then I switched to Gentoo and end up with Arch. Now  I've made a full turn coming to FBSD back on a single machine.
*(Just observations, not a question! Excuse me the length of my first message)*

It's been few weeks from now where I dig in it. I have to say switching to LLVM bring quite controversial experience. Quite a lot of packages hardly depend on GCC and required it anyway. I did try everything I could, but wasn't able to switch the world and kernel back to GCC to live with a single compiler. Very sad! Even worse is, that some packages do require LLVM, when it is already installed as system compiler anyway. Sounds ridiculous. 11.2 RELEASE does have CLANG 4 and some packages push CLANG 5. Strange enough. World thinks CLANG 5 is not ready yet, but PORTS think CLANG5 is ready. That is while CLANG 7 is available. 11 STABLE has some more consistency. It does install CLANG 5 everywhere. So I ended up having 2 copies of CLANG 5 and one copy of GCC 6. Now few packages which aren't require GCC can't be actually build with CLANG and each time I have to set WITH_GCC on and off. Using GCC for all ports doesn't work either.

I'm pretty aware, that FreeBSD community has moderate resources. Therefore it sounds strange why increase entropy and make more troubles for every one. Back in 4.0 it was more consistent. CLANG will never be drop in replacement for GCC so it is better to stick with a single default compiler. And if the all packages out there are developed with GCC, then it should stay this way. 
Higher complexity can be tolerated if community has enough man power for all that. Just the man power to build every single package with CLANG seems to be more, than available.


*To the problem:*

After starting video playing in a browser (tried Opera, Iridium and Palemoon) the whole system goes to sudden reboot. It does not happen always. Just occasionally, but pretty often. Restart playing the same video (just HTML5, no Flash, no Linux Compatibility) can easily bring the whole system down. That effect I have observed on Linux last time about 10 years ago.

If the video is playing already it is quite stable and no crash has been observed. It's only the starting process which brings the system down! Exactly the time, when I click on start button. As example it can also be observed on youtube or popular streaming services. Exact same video can be played without any issue. Just sequence of stop and continue might trigger the reboot. Its seems that usually 2-3 times restart is necessary. Looks like memory leak to me. IMHO it might be somehow related to Xorg SUID, but I'm not sure.

I would fully accept browser crash or even Xorg crash, but not the whole system reboot. How about kernel and process insulation on FreeBSD nowadays?

Among settings I tuned was setting -march=native and few security setting in sysctl.conf recommended during installation.

I am not asking to solve all the issues, just if possible tell me how to make the system not affected by single program crash.
Don't like it much, but would accept Xorg crash if not avoidable.

*Side question:*

I was told ZFS on Linux is so much worse comparing to FBSD, that was my main reason to try the proven solution. Have to admit, that I love how ZFS works and have no single issue so far, before I started to play with browsers in Xorg. I know I am asking biased people, but would you confirm my decision to stick with FBSD for ZFS? Or it doesn't matter much.

Many thanks and sorry for too many words!


----------



## SirDice (Feb 18, 2018)

lefsha said:


> I would fully accept browser crash or even Xorg crash, but not the whole system reboot. How about kernel and process insulation on FreeBSD nowadays?


Processes and kernel have been and always will be separated (kernel vs. user space). It's the drivers that are a problem. Drivers on FreeBSD (and many other monolithic kernels) live in kernel-space. So it's very easy for a graphics driver to crash the system.


----------



## lefsha (Feb 18, 2018)

SirDice said:


> Processes and kernel have been and always will be separated (kernel vs. user space). It's the drivers that are a problem. Drivers on FreeBSD (and many other monolithic kernels) live in kernel-space. So it's very easy for a graphics driver to crash the system.



Thanks for answering.  I do have both Intel and Nvidia card connected by HDMI cable to the monitor.
Before I could make Nvidia work I had the same issue with Intel built-in GPU and was hoping after all is done it would be
better with Nvidia, but no difference observed. It's hard to believe both drivers are broken.

What would be options I have to control while building the kernel? It seems it all depends on kernel issue then.
In my custom kernel I just turned off modules for hardware I don't have. No USB no.. etc.
Thx


----------



## SirDice (Feb 18, 2018)

lefsha said:


> Before I could make Nvidia work I had the same issue with Intel built-in GPU and was hoping after all is done it would be
> better with Nvidia, but no difference observed. It's hard to believe both drivers are broken.


I think you inadvertently mixed the two drivers. The NVidia binary drivers also replace a few Xorg libraries (quite annoying to be honest). The Intel driver expects the original Xorg libraries. If you switched to the Intel driver make sure you completely uninstall the x11/nvidia-driver so it doesn't interfere.


lefsha said:


> What would be options I have to control while building the kernel? It seems it all depends on kernel issue then.


These are not builtin on the kernel but loaded as modules. The x11/nvidia-driver for example installs the nvidia.ko kernel module.

There's no difference between something builtin or loaded as a module. Even the stuff that's builtin is a module, it's just loaded and linked into the kernel binary. So the 'protection' is the same, there is none. It all runs at the highest privilege level on the CPU (Ring 0) where it is allowed to do what it wants, including crashing the system, unfortunately.


----------



## lefsha (Feb 18, 2018)

Great! Thank you a lot for pointing me where to look!

I will try again to use the single driver each time and report my observations.
The problem is that HDMI cable is physically connected to Nvidia card and it might interfere even if disabled.  IDK for sure.


P.S. The hardware is new, but not hi-end. Nvidia GT 1030. To test it before FBSD installation I put Ubuntu and had no
issue. So I believe from the hardware side it should be OK.

P.P.S. Nvidia installation on FBSD is quite complex it made me young again.  The official manual doesn't help much.
For those who might have the same troubles:

1. One need to enable sc - old console driver to the kernel config, which is not neccesary otherwise nvidia.ko doesn't load properly without it.
2. One has to add this line to rc.conf

```
> kld_list="nvidia-modeset"
```
3. Manually create /usr/local/etc/X11/xorg.conf.d/nvidia.conf with all corresponding input for Nvidia driver, screen and monitor.
Suggestions to keep xorg.conf.d empty don't work in my case.  Xorg can see the nvidia driver, but won't use it.

After that I had to fight sound support and totally broken DPI detection, but that is a different story. The good thing is manual
config patching can bring you anywhere on FBSD. One just need to know what to do. 

Thx


----------



## ShelLuser (Feb 18, 2018)

lefsha said:


> Just recently installed FreeBSD 11 STABLE mainly due to ZFS. My first Unix many years ago was FSBD since 4.0 version, then I switched to Gentoo and end up with Arch. Now  I've made a full turn coming to FBSD back on a single machine.


Sounds like fun!  However, there's one thing I'd like to mention: -STABLE isn't necessarily an indication that you got yourself a stable / ("stability wise") release. In fact, it's a developer snapshot, but one which is less "bleeding edge" than -CURRENT. Some run STABLE without issues, but I still wanted to bring this to your attention.

For example: don't expect the luxury of freebsd-update to keep your system up to date, stuff like that. Doesn't have to be an issue (I haven't used that program in years) but figured I'd mention it.



lefsha said:


> I have to say switching to LLVM bring quite controversial experience. Quite a lot of packages hardly depend on GCC and required it anyway. I did try everything I could, but wasn't able to switch the world and kernel back to GCC to live with a single compiler. Very sad!


GCC is a bit of a non-grata compiler within the BSD environment, mainly due to its license. As such most port maintainers build around the expectation of using Clang, also because it's available within the base system.



lefsha said:


> Even worse is, that some packages do require LLVM, when it is already installed as system compiler anyway. Sounds ridiculous.


Agreed. I still have it on my todo list to try and "prank" some ports by installing a mockup LLVM port just to see how well (or bad) they'll behave during building. I too think that some port maintainers are much too casual with flipping the virtual "requires devel/llvm50" switch.

But that's the FreeBSD project for you. An honest project which consists of many different individuals. Some will know the ports collection (the underlying mechanics) by heart whereas others will barely have made it past the porters handbook. I am convinced though that if you can successfully debunk the requirement and then bring this to their attention that plenty will take your comments into consideration.

As said: I planned on testing but so far haven't found the time yet.



lefsha said:


> Higher complexity can be tolerated if community has enough man power for all that. Just the man power to build every single package with CLANG seems to be more, than available.


But is it really? Have to disagree with you on that one. The default compiler is CLANG, and if a port doesn't say otherwise that's what is going to be used. The rest is fully up to the port maintainer. Such a build dependency is no different from relying on a certain library, there really is no added complexity there.

Even using GCC should for most parts still be possible by setting up the right settings in /etc/make.conf, most notably variables such as CC. make.conf(5) will cover that in more detail. Of course, how well that's going to work is something I can't say.

When I started using FreeBSD (9 series) everything was still evolved around GCC and Clang had just got a bit more exposure (at least that which I could see) and being quite enthusiastic about it I immediately started to replace GCC with Clang, much to my surprise all ports compiled easily. Those which insisted on GCC kept doing so and effectively I used both compilers together. I'm pretty sure that this process will also work the other way around.

SirDice already addressed the other issue and I don't think there's much more I can add to that.


----------



## lefsha (Feb 19, 2018)

ShelLuser said:


> Sounds like fun!  However, there's one thing I'd like to mention: -STABLE isn't necessarily an indication that you got yourself a stable



Dear ShelLuser, thanks for comments. I guess I was too verbose to speak of each particular step I went through during last 2 weeks.
My English knowledge is limited, but roughly I've got the Idea, that STABLE is not stable to be called stable comparing to RELEASE, which is so much stable that has to be called OLD, but from the CURRENT point of view STABLE is more or less stable or if not really at least has similar letter sequence and spelling.

Now jokes aside. Once I found some packages (like nvidia-driver - a kernel module) require LLVM 5 while LLVM 4 is the system compiler, I was naive and curious enough to try STABLE to get rid of second LLVM version.  As you already know I end up with double 5. It does smell like VSOP and I like it, but I feel it's too much for my humble and modest person. The second reason was an attempt to make Nvidia driver work. That was a wrong direction too, but still I like the idea to have the same compiler twice rather than 2 different ones. Well, that was before I discovered I can't get rid of GCC in some cases and lost my trust in humanity of daemons who took over FBSD. Then I decided to get one ring of Toolchain to rule them all. I set on Gandalf the CC and lost with a bang. Now I've got a small Zoo with twins and a foreign animal for few visitors. 



ShelLuser said:


> GCC is a bit of a non-grata compiler within the BSD environment, mainly due to its license. As such most port maintainers build around the expectation of using Clang, also because it's available within the base system.



It sounds too nice to be truth. See above. Some packages push GCC6, some aren't willing compile if not GCC was chosen.
A brief look at src.conf man page and source tree tells us GCC is deeply incorporated into the system. I know it's GPL2 one, but why use more than one compiler if LLVM does have BSD license and works well? It does make source tree more complex. At the same time some compiler options and sources are modified to be compiled only by LLVM. No doubt it's a lot of work. Just before starting a war one need to reserve a certain budget and have enough time in mind. The fight for "truth" can be quite costly.

From performance point of view for those who need a stable system GCC 4.2.1 is good enough to stay with it. Just keep Moore law in mind.
A hardware is getting more powerful faster, than compilers. It's a pure waste of man power just to follow the version number fetish.
99.9% of FBSD users have chosen it not because it does have the most updated compiler. Specially if we do have in mind last LLVM is at 7 now and may be soon will change the increment number to 10 just to keep up with crazy browser racing. I do still remember gcc 2.95 everybody was quite happy with.

Current trend to multiprocessor systems with 100 or 1000 CPU or GPU will require totally different programming concepts, where both GCC and LLVM will fail. In almost exact same way Intel failed on mobile devices where ARM has its dominance. Think of GPUs, TPUs. The old concepts aren't working there. The fetishists are running C code in browser with WebAssembly. People who play in incremental version game aren't much different.
Both will die out once new concept will take over the world.

Why spend time on something we all know will die quite soon? Why not just polish on stability and wait of new technology advent?
Big companies will support that strategy more happier. My hardware should run and not collapse w/o reason. It gives me more, than
0.1s faster program which was made by spending 1e6 of man-hours. It's not worth it. Much better to spend time to find bugs which are always present in any software.



ShelLuser said:


> But that's the FreeBSD project for you. An honest project which consists of many different individuals. Some will know the ports collection (the underlying mechanics) by heart whereas others will barely have made it past the porters handbook. I am convinced though that if you can successfully debunk the requirement and then bring this to their attention that plenty will take your comments into consideration.



I do appreciate great work of the whole FBSD and *BSD community! If I would have time I could contribute, cause quite some packages do not have maintainers, but I wish to understand the whole concept and a direction FBSD team has set. Comparing to nowadays Linux FBSD is simpler,
but I wish to have it even more simple and smaller. It should less rely on things like std=gnu99 and special compiler functions available only
for certain compiler. Just use pure ASM, where architecture allows it or simple library function.



ShelLuser said:


> But is it really? Have to disagree with you on that one. The default compiler is CLANG, and if a port doesn't say otherwise that's what is going to be used. The rest is fully up to the port maintainer. Such a build dependency is no different from relying on a certain library, there really is no added complexity there.



That is a problem for me. Making it up to port maintainer is equal to bring more chaos to the whole system. It wasn't me who decided
to change to LLVM. Why not consistently complete that goal for everything? If every one is free to do what ever he wants why drop GCC then?
Well, some people care of license, but some not! Specially GCC has "Runtime Library Exception, version 3.1" which allows to run closed source
code with it's library. If big companies want it they should pay for it and make ready = production ready.

What we have now is a mess, frankly speaking. Didn't want to say that, but I hope I don't blame people here, which are quite helpful and
did without doubts a great job! I just feel sad, that so much force were wasted.



ShelLuser said:


> When I started using FreeBSD (9 series) everything was still evolved around GCC and Clang had just got a bit more exposure (at least that which I could see) and being quite enthusiastic about it I immediately started to replace GCC with Clang, much to my surprise all ports compiled easily. Those which insisted on GCC kept doing so and effectively I used both compilers together. I'm pretty sure that this process will also work the other way around.



I remember the time of 4.0 release. Back then it was great, but for almost every small thing I required Linux compatibility mode.
Efficiently I was pushed to switch to Linux completely. It was hard time, cause nothing came close to FBSD ports.
First Gentoo was my choice, but because people wish to change working things it is largely broken now.
Arch switched to systemd to follow others. Linux is running towards desktop system, but still is far behind Windows.
For servers it's lacking of descent file system and not able to manage simple cases properly.

If BSD will try to be like Linux it might easily loose its attraction and die some day. And without user base no industry will help to BSD.

To survive it has to be damn stable and damn simple, that every idiot like me should be able to setup it in secure way and working way without troubles within 30 min. Instead I am still fighting with some issues after 2 weeks hard work.

P.S. Don't get it as personal critic of BSD community. It wasn't a purpose.


----------

