endless "starting X" loop after boot on braswell laptop

Hi,

I've gotten a new "playbook", an 11" Braswell post-modern netbook with a Celeron N3150 aboard (made by Clevo) which has an IGP identified as "Cherryview" by Mesa.

This machine works fine with X.org 1.15.1 under Linux (Ubuntu 14.04.4 with a home-built 4.5.6 kernel), hardly the latest X.org version.

Not so after I installed FreeBSD (rather, ahem, PC-BSD 10.3): it will either sit in an endless "starting X" loop after boot, or it will somehow manage to start X in the correct 1366x768 resolution, put up a dialog telling me the previous attempt failed and then give me a dialog to configure the graphics system. Whatever I pick in there (intel, intel-3d or vesa) will lead to failure and a frozen mouse cursor leaving me no option but to hit Ctrl-Alt-Del and start over. I managed to run `pkg update ; pkg upgrade` on the console yesterday (in 640x480...) despite the "starting X" loop, hoping that would update something that'd resolve the issue, but no such luck.

So what can I do to fix this? I can access the pool from Linux (direct using ZoL or over ssh). The Clevo does have Intel iwl WiFi which should be supported once FreeBSD 11 makes it to PC-BSD. Those should be unrelated (and I have wired connections too) but should I simply wait for that release?
 
Yes, I know. Reason I'm asking here is that as far as I can tell the X server is part of the FreeBSD subsystem, and I'd prefer to get an answer how this would be resolved on a pure FreeBSD system. IOW, what would the correct settings for my kind of hardware be on such a system.
 
Xorg is not part of the FreeBSD subsystem. It's a third party application.

And as far as I can tell, "Braswell" is not yet supported.

https://wiki.freebsd.org/Graphics

To elaborate more, PC-BSD does its own customizations to FreeBSD ports tree. It has its own defaults, local preferences on how to use certain other third party libraries (such as OpenSSL). What applies to ports on vanilla FreeBSD may not apply to ports on PC-BSD at all in some cases.
 
Still, I'd like to know if and how this hardware is supposed to work with FreeBSD (esp. v11). I presume that it's possible to install a KDE desktop on FreeBSD too so if the hardware works with that OS but not PC-BSD I can always decide to use that. (As a bit of a last resort; I've already spent so much time figuring how to get the dual-boot install I want that I'd rather tinker with what I have first.)

Anyway, Xorg does support the graphics in the N3150 using the i915 driver. As I said the video works fine under Linux with an older Xorg, but with a very recent kernel. Following the link above it would seem that it's that kernel driver support which will only be updated in FreeBSD 11 (it'd be nice if the docs made a link between the "version 3.8 linux i915 driver" and the Linux corresponding Linux kernel version(s)...).

In the meantime, it is clearly possible to get an acceptable image using a fallback driver (VESA? Framebuffer?) which will probably lack all forms of acceleration.
 
It's complicated for sure when it comes to supporting display hardware. The kernel drivers are supposed to implement the mode switching and direct rendering mode services and the Xorg server implements the rest. Since the kernel drivers are part of the base system they are impossible to update on release versions because on FreeBSD nothing gets committed on release versions unless there is dire reason such as a security vulnerability that has to be fixed or a clear error that needs an errata release to fix it. The Xorg server part is easy to update since it comes from a port but FreeBSD ports doesn't really add anything to the Xorg servers, what is supported by the upstream Xorg server is supported on FreeBSD assuming the FreeBSD kernel drivers for the hardware exist.
 
That indeed doesn't make things easier - if there is no ("easy") way to build your own kernel like there is on Linux.
 
It's really easy to build the kernel but the kernel and the rest of the OS (Xorg is not part of the OS) are a complete "set". So, on FreeBSD you simply cannot use a 11-CURRENT kernel with a 10.x-RELEASE userland.
 
It's really easy to build the kernel but the kernel and the rest of the OS (Xorg is not part of the OS) are a complete "set". So, on FreeBSD you simply cannot use a 11-CURRENT kernel with a 10.x-RELEASE userland.

Well, that way works for most part. Otherwise you couldn't run FreeBSD 10 and earlier jails on FreeBSD 11 kernels. It's however not recommended to keep running on newer kernel and older userland on the host itself because they are meant to be in sync on the host. The other way around doesn't work of course, FreeBSD 10 kernel and FreeBSD 11 userland just doesn't work.
 
I was surprised to see there was nothing special to building and running a Linux 4 kernel with a 4yo (but up-to-date) distribution that would otherwise probably still be using a 3.13 kernel.

Anyway it'll be a long time before I attempt that kind of trick on any BSD, but I suppose that building a recent development version of the major (?) release version should be much less of a problem. Who knows, maybe it would even be relatively trivial to backport that new i915 driver to the 10.3 kernel (supposing 11.0 wasn't already released).

In short, I'll be waiting for 11.0 to land in PC-BSD, and then we'll see. That version should also have the required driver for the WiFi chipset, which will make it a lot easier to start tinkering.
 
I was surprised to see there was nothing special to building and running a Linux 4 kernel with a 4yo (but up-to-date) distribution that would otherwise probably still be using a 3.13 kernel.
That's because on Linux the kernel is its own entity. The rest of the Linux "OS" has no real relation to the kernel, the Linux userland is cobbled together from various different sources. On FreeBSD the kernel and userland are a single entity. It's a complete OS.
supposing 11.0 wasn't already released
Current planning puts 11.0-RELEASE somewhere in September of this year: https://www.freebsd.org/releases/11.0R/schedule.html
I'm sure PC-BSD will follow quite quickly.
 
Oops. I'm not sure what I saw that made me think 11.0 was already released :-/ Possibly I mistook the June 10th code freeze for a release, or else one of the sources my news reader scavenges did that.

That's a longer wait than I foresaw, guess I'll have to find a way to get the X server to work in a compatibility mode, since it's clearly capable to do so. And since it's the PC-BSD installer that manages that trick quite nicely I'll indeed have to go ask on their forum.
 
Oops. I'm not sure what I saw that made me think 11.0 was already released :-/ Possibly I mistook the June 10th code freeze for a release, or else one of the sources my news reader scavenges did that.
You may have seen the Alpha release snapshots. Those are available. But it's still going to take a while for the full 11.0-RELEASE.
 
I saw them, yes. Being relatively new to *BSD (except that BSD descendent with the Mach/XNU kernel ;)) on (too) recent hardware and a graphical installer that handled graphics just fine I thought it better to stay clear of them for the time being. Esp. since I did not yet see if you get rolling updates between snapshots or from the alpha releases to the final. If there's a way to update the current install to "rolling" then that might indeed be a solution - all I have to lose is more time.
 
Updating/upgrading can only be done using the source (this will give you the 'rolling' release). Updating with freebsd-update(8) only works for RELEASE versions. That said, I've been running 11-CURRENT for a while now and besides a couple of issues I had it runs quite well, I won't recommend using it for production machines just yet but now is certainly the time to test with it. As it's now in the Alpha stage there shouldn't be any major changes until the release.
 
Back
Top