FreeBSD9, better and faster (so far)

D

davidgurvich

In a very short look at 9-CURRENT there seems to be many significant improvements. There have been many changes in the development version and, being a curious individual with a recently rebuilt laptop, I decided to test out a few things.

The recent past saw me dropping the use of FreeBSD on laptops because I couldn't get the wireless range and reliability that Linux provided. So far the network stack hasn't caused any spontaneous system crashes with good speed and reliability. I haven't tested range yet.

There were problems with perceived latency that are entirely gone in 9-CURRENT. That is even more incredible given the fact that all the debugging features are still enabled.

Before you decide that this is an unabashed love-fest for 9-CURRENT there are some minor issues I've found. On the laptop there is a touchpad and pointing stick with mouse buttons. These caused the keyboard and mouse to lock up the system. No combination of hald, moused, dbus, synaptic driver, xorg.conf file, or rc.conf setting seemed to make a difference. The issue was resolved with a relatively obscure fix that I found in the current mailing list. I'm not quite sure what it does but adding
Code: 
machdep.disable_mtrrs="1"
to /boot/loader.conf seems to have resolved that problem.

The other issue has to do with XFCE. The Terminal application fails to start about 80% of the time. I don't know why and am using a different terminal for now. I would be much more comfortable if Terminal failed 100% of the time. There doesn't seem to be any error that I can find.

I'll make updates to this post for a little while. Probably the first thing will be installing the linux flashplayer and testing out some old windows applications with wine.
 
I had the same problem with Xfce4-terminal but found if I clicked on terminal in root menu and moved that mouse away too quick terminal would come up and than disappear. So I found that if I clicked on terminal in root menu and didn't move the mouse away terminal will start 100% of the time.
 
I had the same problem with Xfce4-terminal but found if I clicked on terminal in root menu and moved that mouse away too quick terminal would come up and than disappear.So i found that if I clicked on terminal in root menu and didnt move the mouse away terminal will start 100% of the time.
Click to expand...
That goes, like, 'what the f*ck?'
 
wokko said:
I had the same problem with Xfce4-terminal but found if I clicked on terminal in root menu and moved that mouse away too quick terminal would come up and than disappear.So i found that if I clicked on terminal in root menu and didnt move the mouse away terminal will start 100% of the time.
Click to expand...

Input problems in xorg often point to misuse of AllowEmptyInput: AllowEmptyInput, FreeBSD, and Xorg Input
 
The problem occurs regardless of xorg options. There does seem to be a relation to mouse movement. If I open an xterm and click inside then just type 'Terminal &' a few times the success rate is far higher.
 
Just curious, but if you disable hald support in the Xorg server (requires reinstall of the port), enable moused in /etc/rc.conf (pointing to the correct mouse device in /dev/), and then manually add an Input section into /etc/X11/xorg.conf for the mouse using /dev/sysmouse for the device, does it work better?

FreeBSD has supported hot-pluggable pointer devices for over 10 years now, using moused(8) and the /dev/sysmouse X device. The really nice thing about using moused is that you get a working copy/paste mouse pointer at the text console and working mouse support in the GUI.
 
For now the only plans I have to build from source are relatively small items and possibly the kernel. All the packages use prebuilt binaries installed with pkg_add except for nspluginwrapper-devel. linux+flash were installed through the ports but are also prebuilt binaries.

Xorg is configured through hal and moused is being used. Synaptics capabilities are enabled for moused.
 
If using moused, there's no need for HAL support in the X server. They are two different ways of doing the same thing (automatically detect and configure input devices).

FreeBSD has multiple keyboard support via the kbdmux(4) driver, and multiple mouse support via moused(8), so if using those ... disable HAL support in X.

Trying to use both abstraction layers can cause issues. In theory, it shouldn't, but it can.
 
So disabling hald would require rebuilding the xserver? There is no way to just disable hal?

How would the display be autoconfigured? Right now there is no xorg.conf at all and I thought that was possible because of hald. Is that just dbus?
 
davidgurvich said:
So disabling hald would require rebuilding the xserver?
Click to expand...
Not necessarily. Remove the hald_enable option from /etc/rc.conf and add moused_enable="YES" instead to run the mouse daemon on system startup (don't forget to start the daemon or reboot). You'll now have mouse support in the shell.

In xorg.conf, X should detect and use /dev/sysmouse automatically. Simply add
Code: 
Section "ServerFlags"
	[...]
	Option "AutoAddDevices" "FALSE"
	[...]
EndSection
to tell Xorg it's not using HAL for hardware autodetection.

davidgurvich said:
How would the display be autoconfigured? Right now there is no xorg.conf at all and I thought that was possible because of hald. Is that just dbus?
Click to expand...
Xorg nowadays usually detects everything right by default. But if that's not the case, or you want to add options or override settings (such as HAL support, without recompiling), you'll have to generate a xorg.conf file.
By display, I take it you mean the resolution. You should set a DefaultDepth and Modes. This has been asked many times so you should be able to find all you need by searching the forums.
 
phoenix said:
If using moused, there's no need for HAL support in the X server.
Click to expand...
Yea, I'd go further to say that HAL support should be disabled by default in the port options. It's really unnecessary, and IMHO, undesirable on FreeBSD. Doesn't stop a WM from depending on HAL either...
 
davidgurvich said:
So disabling hald would require rebuilding the xserver? There is no way to just disable hal?
Click to expand...

That's described in that article I linked in post #5.

How would the display be autoconfigured? Right now there is no xorg.conf at all and I thought that was possible because of hald. Is that just dbus?
Click to expand...

xorg-server uses hal to detect input devices only. It has its own code to detect video hardware, not dependent on hal or dbus.
 
The article seems to be pointing out the demerits of AllowEmptyInput. At this point I have no xorg.conf file and don't care about hald unless it gets in the way.

Right now hald seems to be recommended for use with xfce4. In the Makefile there is a note that dbus and hald should both be enabled.

When referring to a display earlier that meant additional displays, perhaps during a presentation, along with multiple input devices. I recall when a presentation was fraught with anxiety, not from stagefright but from worry that some simple configuration was incorrect (testing the equipment in advance not possible).
 
davidgurvich said:
The article seems to be pointing out the demerits of AllowEmptyInput.
Click to expand...

Yes, and also the right way to do what a lot of people think AEI does: "If you run hald but don’t want to use it for input device autodetection, or don’t run hald at all, turn off AutoAddDevices in xorg.conf. You can put the entry in the ServerLayout section, or add a whole new ServerFlags section if you feel the need to complicate things."

Right now hald seems to be recommended for use with xfce4. In the Makefile there is a note that dbus and hald should both be enabled.
Click to expand...

hald really doesn't seem to provide much with the new xfce 4.8, and I stopped running it. dbus is still there because I assume it is required, or at least provides some benefit for programs using it to communicate, but I haven't tested that.
 
I've updated the sources and am now using the new kernel without debugging. The latency is either the same or better. I'm currently using firefox and compiling something in the background without noticing any slowdown.

I've removed the
Code: 
machdep.disable_mtrrs="1"
line from /boot/loader.conf. Oddly that caused the mouse in Xorg to stop working. That was repaired by generating an xorg.conf file with Xorg -configure and adding
Code: 
Option "AutoAddDevices" "false"

There was a problem with a Windows program but that could be unrelated. I haven't noticed anything else failing that couldn't be attributed elsewhere. Flash video had an issue but that might have been the source and I haven't been able to duplicate the issue since upgrading the kernel and userland.

Bridged networking seems to be working much better and so is wireless, compared to 8.x or 7.x. In fact, 9-CURRENT has crashed less than any other FreeBSD version I've tried.

I haven't tested suspend/resume and will get to that shortly. The laptop will not be trying ZFS out but if everything works well then I'll try 9-RELEASE on a server in a while.
 
You may want to play around with SoftUpdates Journaling (see tunefs(8)) for details). It's only available on 9-CURRENT, and speeds up boots after crashes. Plus, it should prevent data loss on power failure.
 
The only crashes came from problems with xorg during installation and configuration. Haven't had any since and no data appears to have been lost. I did have multiple crashes on 8.x that are related to networking, either the driver, the kernel, wpa_supplicant, or something else. Oddly, no data loss then either.
 
I've had crashes on v9 and v8 also largely without data loss (excepting ufs2-on-usb, where sometimes the backup was recoverable with force-mounting... ) maybe usb will improve by the time v9 becomes RELENG. (For that reason for usb etc I tend to use gjournalling).
 
You must log in or register to reply here.
Back
Top