Tag: Linux

Linux 4.1 kernel: Finally, a movement in the upwards direction

Playing around with the new Linux 4.1 kernel and some benchmarks on a MacBook Pro for comparison.

No musings yesterday because I was having quite a time getting Linux to play well. I spent yesterday configuring the rest of the kernel until around 21:00, when I started searching for and applying all the patches I wanted. Found a small bug in the CPU optimisation patch that Gentoo uses (via grsecurity); namely, it doesn’t enable P6_NOP for anything higher than a Core 2. I manually edited the patch and applied it.

I built the kernel, ran # emerge @module-rebuild, signed the newly built modules, and rebooted in to my new system… Or I would have, if it had been able to read the init RAM disk. Doing the Apple EFI dance to switch between 3.18 to rebuild and 4.1 to test was not my idea of a good time, but after a while, I found the issue. There’s something broken somewhere and it would not read XZ-compressed ones. I used my fallback algorithm, LZO (chosen because it’s free and very fast), and it booted right up. Only now, I couldn’t start KDE.

Typically, I start KDE by using $ X_SESSION=KDE-4 startx; I don’t use KDM or XDM because I regularly test breaking changes to i915 that may cause X to hardlock, rendering my laptop useless. This time, however, it complained ‘xterm: command not found’. Unsure why it was trying to load xterm, I checked around and I found no answer. I still haven’t figured this out. The workaround I’m using is $ XINITRC=/etc/X11/Sessions/KDE-4 xinit which acts the same as the old command, only it’s longer and less readable.

Then I had a world of i915 bugs that I will omit from my blog mainly because they were mostly configuration error and the ones that weren’t were resolved by re-merging media-libs/mesa.

After all of that was over, I checked on my wireless chip. Lo and behold, for the first time since I’ve started using draft-n wireless networking on Linux in 2009, it was actually associating successfully to a 5GHz 802.11n AP! The speed is only 150mbit/s; the chip supports 300mbit, so I am not sure why that is, but I am still happy to be finally untethered from my Ethernet cord!

Some benchmarks.

Running emerge -1 openssl

Kernel / Sched Wall Time System Time
3.18 / CFQ 5m 3s 59s
4.1 / CFQ 4m 57s 55s
4.1 / BFQ 4m 53s 52s

That’s a pretty nice win for BFQ, and a huge improvement over 3.18. Note this is all on the same hardware, on a fresh boot, with nothing in fscache.

Playing 720p MPEG-4 video in VLC

Kernel On-Die Temperature CPU % used
3.18 71° C 31.2%
4.1 63° C 46.3%

Each measurement was taken at 2 minutes into playing the video. Not sure why the CPU’s a bit more active, but wow, that temperature reduction is serious!

Overall, I am very, very happy with this upgrade. The Linux 4 series seems to be all about making things smoother, faster, and more battery-friendly. I’ll update later with a benchmark of battery life.

If you have a MacBook Pro from the 2011 era (or you’re just curious), you can view my config file online. Special thanks to Elly and Horst for guidance, patchsets, and keeping me company while I was going insane with menuconfig. 🙂

Musings: Just another lazy Sunday.

Okay, I guess I’m doing this daily. Sundays are usually pretty lazy for me, so this will be short.

Found more interesting tidbits, still configuring the 4.1 kernel for my laptop. RC8 came out before I even finished, so now I have some oldconfiging to do.

Still felt dizzy from yesterday, so spent 20 minutes on the treadmill. Blew all the cobwebs out of my blood, I suppose. Almost completely better afterwards, so that’s a good thing.

Found a really intricate resource pack for Minecraft, S&K Photo Realism. I’ll have to try it out the next time I’m on the desktop with the Radeon 5700HD. My laptop can’t handle resource packs; the poor little Sandy Bridge HD Graphics is too overwhelmed.

Helped Horst debug an i915_drm driver issue on 4.0.5. Not sure the root cause, will have to probe further tomorrow.

Started planning how to install Foxtoo, my own little brand of Gentoo, on to my Pentium-100 laptop. I think I have a way and it’s going to make for quite an article if I manage to make it happen.

Actually excited for work tomorrow. Lots of cool things in the works there.

 

FreeBSD on Apple MacBook Pro 8,2: Epilogue.

Why I left FreeBSD.

It is with a fairly heavy heart that I write I am no longer running FreeBSD on my MacBook Pro.

What happened to improving?

Part of the problem is that I finally received gainful employment in March, and that work is almost impossible to do on FreeBSD. A lot of it involves Chrome (which I still have been unable to run on FreeBSD), Qt5-based applications (which crash due to known bugs in libv8 that Google do not care to resolve), and some Python libraries that have truly terrible performance on FreeBSD.

Why not run Linux in a VM for work?

Sure, I could have, if VirtualBox ever worked…

Weren’t you excited to fix up FreeBSD?

I was. I still am, but something just feels different. For over a decade, FreeBSD has for me been the go-to operating system for any use case: servers, embedded projects, desktop systems, and more. But the current heading of development seems to strongly suggest this is no longer encouraged or desired.

When I first started out with Gentoo nine years ago, they were pretty much bent on making it for newer hardware only. Back then, Pentium computers were like the Pentium 4s of now – something you give your grandma or little sister for web browsing, but nothing too serious. And Gentoo developers did not really care if they broke compatibility with these older systems. I can understand that, given that compiling the entire system by hand is something that is pretty taxing for older hardware.

The nice thing about FreeBSD was their community never looked down on you for using these older machines, and realised they still have use. My first interactions with #FreeBSDHelp on EFnet were in 2006 and related to getting SLIP support working in sysinstall so I could remotely install FreeBSD 6 on my Pentium 90 laptop. They were happy to help.

The roles have largely reversed now. Running into issues with older hardware get me looks of disdain and “great, upgrade your hardware and try again” from the FreeBSD community. Meanwhile, the Gentoo team was happy to help me with an issue regarding my retro Intel486 box, in 2015. This computer has no business still functioning, and they were still willing to help me configure a kernel that would boot on it with its anaemic 20 MB RAM.

The other thing I have noticed is that even now, months later, none of my Ports bugs have been handled. In the same amount of time, I have filed three bugs against Portage packages… and all of them were closed within one week of being opened. I feel like my contributions matter to the Gentoo Linux team.

What have you learned?

FreeBSD is more fun to hack on than Gentoo. FreeBSD is harder to get things done on than Gentoo.

FreeBSD is lighter on resources than Gentoo. FreeBSD is heavier on bug backlog than Gentoo.

FreeBSD on Apple MacBook Pro (13", Late 2011): Initial thoughts

Some background on why I left glibc Linux distros and went to FreeBSD. Includes tips on how to install FreeBSD on a MacBook Pro.

Background.

I rely on my laptop, an Apple MacBook Pro 8,2 (13″, Late 2011), for most of my work. For the past year or so I have been using Gentoo Linux on it. Gentoo is probably the best distribution of Linux out there today, but that isn’t really saying a lot about it. Underneath the beautiful and easy-to-use Portage system lies the same glibc, the same turmoil over a switch to a less-than-ideal init system, and the same kernel-level bugs that bring my productivity down.

I had considered sticking it out, and possibly even picking up maintaining OpenRC if it is abandoned as some people seem to want. However, I have been having many glibc-related bugs lately:

  • Almost all GTK apps keep locking up in waitpid.
  • gdb locks up when I try to attach to processes – even after checking /proc/sys/kernel/yama/ptrace_scope and the like (no error, just hang).
  • Starting VirtualBox VMs cause the entire machine to lock up for up to two minutes before returning to normal. This isn’t from starting the VM either; it occurs before the VM can even begin.

I don’t take system-level changes lightly, but it was time to try something else. Trying to rebuild everything against something like musl seemed like an interesting idea, but it still wouldn’t solve the eventuality of systemd. Additionally, there are still other compatibility issues using musl. And if I was having to rebuild everything anyway, I might as well try something completely different…

Enter FreeBSD.

I have been playing around with FreeBSD on my UltraSPARC system, as I wrote earlier. It is pretty snappy on there, even though it is a very old and slow system. Therefore, I decided to research about FreeBSD on MacBooks. There are a few requirements I have with a primary OS:

  • It absolutely must boot natively via EFI. I do not have the time to wait 90+ seconds for BIOS boot, and some of the hardware in the MacBook won’t even perform correctly under that mode; the DVD drive and the Bluetooth are very fickle, at least in my experience.
  • It must be able to run a performant virtualisation solution, like VirtualBox, which is my go-to system emulator. I use virtualisation heavily, so this is a requirement.
  • It must work with the hardware components I use on my computer. This is primarily Gigabit Ethernet, FireWire, the SD card reader, and the Bluetooth radio.

I had enough disk space free on my Mac OS X partition to resize it down and give FreeBSD a “comfortable” 64 GB. Since this is just for testing, I left my Gentoo install and its LVM PV alone. I resized the Mac OS X partition and moved down the LVM PV to put FreeBSD in the middle (otherwise the space would be oddly divided) using GParted running on the Gentoo install. I was horrified when it, too, was locked in waitpid. I waited over three hours before it finally became responsive again, and hilariously enough, it reported that the operations completed in just 49 minutes.

I created a 300MB HFS+ partition used for the EFI loader, since Apple’s firmware really likes having EFI code on HFS+. This also allows it to show up native in Chooser. You can also use FAT16 or FAT32, but I prefer to use HFS+ for this since it is just a single file. The rest of the 64 GB was given to a single FreeBSD UFS partition.

Next, I did something that I absolutely do not recommend for any reason unless you are willing to accept permanent data loss: I ran a Qemu instance with /dev/sda as the virtual hard disk. This allowed me to manipulate the disk directly from Qemu, which was convenient since the FreeBSD UEFI USB install image does not yet support Apple’s firmware. However, if I typed even one letter or number wrong, this could have erased my entire drive so please do not do this! I fetched the sets manually from FreeBSD’s FTP archive and extracted them to the new FreeBSD UFS partition on my disk. I shut down the Qemu instance after I configured /etc/rc.conf to my liking.

Finally, back in Gentoo, I copied the /boot/boot1.efi file from the FreeBSD UFS partition to the HFS+ partition, using the name boot.efi. The directory tree on the HFS+ partition, to boot natively and show up in Chooser (and Startup Disk in Mac OS X), is as follows:

  • /mach_kernel – 0 byte file, must be present to show in Startup Disk.
  • /EFI – copy this directory from the ESP. It contains the encrypted firmware used to start the computer’s components.
  • /System/Library/CoreServices/boot.efi – this is the FreeBSD /boot/boot1.efi file.
  • /System/Library/CoreServices/SystemVersion.plist – this is an XML file that you can put the details of your FreeBSD install into to show what version it is and such. This file isn’t strictly necessary but adds a very nice touch of professionalism to the install.

Booting the FreeBSD: EFI on the First Try!

I snuck in a /.VolumeIcon.icns file with the FreeBSD Beastie head logo, then rebooted my system. I waved goodbye to Gentoo, but wasn’t sure if my FreeBSD installation was fully successful. Lo and behold!

I pressed RETURN and hoped for the best… and the best is what I received!

I was overjoyed to see how fast it boots; under 20 seconds from Chooser to a login prompt. I spent the rest of the night installing binary packages using pkg for software which I could tolerate the default options, but actually installed most things from the Ports system. Xorg support was native and flawless, including DRM for acceleration using my laptop’s Intel HD Graphics 3000. The next morning I had the entire KDE 4 base system built and working in just two hours! KWin’s compositing looks just as good as it did in Linux, but now uses much less CPU and memory – the entire thing boots up (using KDM4 to start my KDE session) using just 290 MB RAM, and will actually idle at 0.0% CPU (Linux would idle around 1.1-1.5%).

Some Issues.

While FreeBSD appears to be a panacea for everything I had wrong in Gentoo Linux, all is not immediately well. Of course, as with any new system, there are some more things I need to fix and figure out:

WiFi/Bluetooth
These will need some configuring and driver twiddling, but I have high hopes based on what I read on the very useful FreeBSD forums and mailing lists.
Ext2FS crashes
I backed up my system before installing FreeBSD, of course, but my backup disk (along with my primary disk which was unharmed) is formatted as ext4 (Linux FS). FreeBSD has a module to be able to read it, but when I try and access almost any file, it has a kernel panic. I am currently looking in to what is causing this and how to fix it.
Sensor readings
Currently, my laptop thinks it is -273.1 °C. This is quite obviously impossible, so I will need to investigate how to fix KDE’s system monitor widget 🙂
Touchpad
While the FreeBSD kernel has a great touchpad driver merged in to 11.0-CURRENT, and it shows up in my kernel log as I boot up, Xorg only sees my mouse as having one button with no gesture support either. This means no scrolling on the side or with two fingers, no right clicking, no middle click for pasteboards, and so on. This will also need some fixing.

Overall Thoughts.

FreeBSD is very performant on this hardware, and seems to be doing a good job driving it. There are some quirks to it, but this is a new system and the kernel I am running is a beta anyway, so it of course will not be perfect. I am happy with this switch though and probably will not go back to Linux any time soon unless they can sort out their issues. I hope they can, because the Linux kernel itself is actually decent, and has a lot of commercial support which is good for open-source going forward. However, FreeBSD’s performance is amazing and gives me renewed hope for the quality of systems that can be made in open-source communities.

Now playing: Devil in a New Dress – Kanye West (Double entendre… FreeBSD’s logo is Beastie, and my laptop is a devil of a computer wearing a new dress with FreeBSD.)