My new
Sager 4750V (Clevo D470K)
and the adventures of getting FreeBSD running on it.

1. Pictures of the laptop
2. Output of certain utilities (dmesg(8), pciconf(8), usbdevs(8), acpidump(8), etc.)
3. Configuration files
4. The saga

Pictures | Top

(hover over small picture above to see larger picture below, or click to open in new window)

Utility Command Output | Top

This stuff will be updated as time goes along. The last update time was Tue Mar 7 17:30:36 EST 2006 .

uname -a
dmesg -a
pciconf -lv
usbdevs -v
devinfo -rv
devinfo -uv
acpidump stuff:
    sysctl dev.cpu
    sysctl hw.acpi

Configuration Files | Top

This stuff will be updated as time goes along. The last update time was Tue Mar 7 17:30:36 EST 2006 .

GAMBIT (kernel config file)
/etc/X11/xorg.conf (this laptop has a massive 17" WSXGA+ LCD -- 1680x1050!!!)

The Saga | Top

Wow, what an adventure this was!  To start with, I was just feeling really good about the whole build/installworld and build/installkernel task flow, and felt I was actually getting pretty darn good at it.  Then, I get this new laptop that gives me fits right from the start.

I got the laptop and immediately downloaded and burned the 5.3-RELEASE/amd64 ISO images. However, when I tried to boot the disc1 ISO, I would get a "RAM parity error" panic after probing the firewire (IEEE1394) controller (fwohci). I Googled for a little while and ran across this thread:

OK, that is from the dfly list, but it applies here, trust me. I used a patch from message:

which was, ironically, posted by the same guy who maintains (or did) the firewire code in FreeBSD.  So, now I am going on the assumption that this patch will help me, but how do I get it on the FreeBSD 5.3-RELEASE/amd64 ISO?  The answer to this led me on quite an adventure, which I will get to shortly.

First, let me touch on a couple of suggestions that I got from the amd64@ mailing list.  The first was from Roland Smith, and he suggested that I try breaking to the boot prompt and entering the command "set boot_userconfig", and then "boot".  I tried this, and there was no change.  Second, he suggested breaking to the boot prompt and unloading the firewire module.  This did not work either, because the firewire wasn't being loaded as a module, it is copiled into the kernel itself.  No joy so far :-\

Next I got an email from "Astrodog", and s/he (not sure since I don't know his/her real name) suggested that I use a hint at the boot prompt to disable the firewire probe.  So, at the boot prompt, I entered the command:

#set hint.fwohci.0.disabled=1

and then issued a "show" command to verify that the variable was set, and it was.  Then I typed "boot -v" and once again, I was greeted with the RAM parity error panic.  GAHHH!

Having reached the end of my list of simple fixes, I decided to go for the jugular: build my very own custom release ISO.  This took a long time, as I kept having failures all over the place, and have since found out that cross-builds from one arch (i386) to another arch (amd64) are not supported.  The fact that I finally got it to work was either luck or divine intervention.

I have one fast machine running 4.9+, so I figured that I would use that box to whip up this new release fairly quickly.  The first thing I had to do was get a local copy of the CVS repo, which I did by installing the cvsup-mirror port.  It is very slick and sets everything up for you.

All right, now I have /usr/home/ncvs on my fast machine running 4.9+, so let's get started.  So that you understand, my 4.9+ box is i386, and I am trying to build a custom release for amd64.  I followed the instructions on the release(7) man page, and this is the process that I followed:

  1. make sure that /etc/make.conf is sanitary
  2. I used the directory /usr/world/make_release_home as the "sandbox" for this work
  3. I saved my custom kernel config file for the base system from /usr/src/sys/i386/conf to a safe place
  4. I then issued the following commands in my shell session (as root, of course)
# export CVSROOT="/home/ncvs"
# chflags -R noschg /usr/world/make_release_home/release_build/*
# rm -rf /usr/obj
# rm -rf /usr/src
# rm -rf /usr/world/make_release_home/release_build
# mkdir /usr/obj
# mkdir /usr/src
# mkdir -p /usr/world/make_release_home/release_build
# cd /usr
# cvs co -rRELENG_5 src

That had to run for a while to checkout the RENELG_5 (aka STABLE) branch out of CVS and into /usr/src.  Once that was done, I manually edited the /usr/src/sys/dev/firewire/fwohci_pci.c file to include the aforementioned patch from simokawa@.  Once my edit was done, I ran a CVS diff as follows to generate a patch file of my change:

# cd src
# cvs diff -rRELENG_5 -u > /usr/world/make_release_home/src.patch
# make -j4 buildworld

Since this machine was fast, it didn't take long to complete that buildworld.  Next, it was time to start building the actual release.  So, via guidance from the release(7) man page, I ran the following commands:

# cd release
# make release \
 TARGET_ARCH=amd64 \
 CHROOTDIR=/usr/world/make_release_home/release_build \
 CVSROOT=/home/ncvs \

This ran for a fair amount of time, before blowing up because there were some missing users and groups (which, upon reflection, I could have probably avoided with a `mergemaster -p' beforehand -- oh well). So, I added those users and groups as follows:

/etc/group: (edited with vi)

/etc/passwd: (edited with vipw)
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/sbin/nologin
_pflogd:*:64:64:pflogd privsep user:/var/empty:/sbin/nologin

OK, with that stuff added into the base system's /etc/ files, I started the `make release' again.  This time, it died with a missing /sbin/mdconfig, which didn't even exist on my 4.9+ machine.  Oh well, it looks like my hopes of getting this done quickly on the fast machine were all for naught.

I have another, much older, laptop (400MHz Pentium II) running -CURRENT (which was now FreeBSD 6 since 5.3 branched 5 into STABLE), and while it would be very slow going, it was my only hope (at this time).  This laptop already had the missing users/groups, and also had the /sbin/mdconfig that was missing on my 4.9+ box, so I was feeling good about making this work.

Since this slow laptop didn't have the CVS repo on it, I mounted it RO via NFS from my 4.9+ box at /usr/home/ncvs.  Once that was mounted, I ran the commands from earlier to erase the existing src and obj dirs, recreate them, cvs co the src, apply my src changes, cvs diff to create a patch file, and then start making the release.

As it happens, the builds on this old laptop were taking between 6 and 8 hours to complete, and after three failed attempts due to some mdconfig errors (sorry, I didn't transcribe them), I was ready to pull my hair out.  I sent one more email to amd64@ to get some help, but it was near Christmas, and the volume was low, so there were few ears for my pleas to fall upon.  I was very frustrated.

I decided to give it one more shot.  I hijacked my wife's machine (which is smokin' fast!!), and use it to make one quick attempt at cross-building the release again.  My plan this time was to install a fresh 5.3-RELEASE on her i386 machine, and then cross-build a 5.3-RELEASE/amd64 release, so the only difference would be the base and target arch, not the versions of the files involved.  In my state of mind, this seemed like a logical thing to try.

So, I ran almost the same commands as before, as follows:

# chflags -R noschg /usr/world/make_release_home/release_build/.
# rm -rf /usr/obj
# rm -rf /usr/src
# rm -rf /usr/world/make_release_home/release_build
# mkdir /usr/obj
# mkdir /usr/src
# mkdir -p /usr/world/make_release_home/release_build
# cd /usr
# cvs -R -d/usr/home/ncvs co -rRELENG_5_3_0_RELEASE src >/dev/null

I stopped here to go make my changes to fwohci_pci.c since I knew it would be a problem.  Once the edit was done, I continued...

# cd src
# cvs -R -d/usr/home/ncvs diff -rRELENG_5_3_0_RELEASE -u > /usr/world/make_release_home/src.patch
# make -j4 buildworld >/dev/null
# cd release
# make release \
 TARGET_ARCH="amd64" \
 CHROOTDIR="/usr/world/make_release_home/release_build" \
 CVSROOT="/usr/home/ncvs" \
 WORLD_FLAGS="-j4" \
 LOCAL_PATCHES=/usr/world/make_release_home/src.patch \

Well, all of the hard work, cursing, and praying finally paid off.  On the first run, in a short period of time, I had some ISO files waiting for me to burn.

The freshly created 5.3-RELEASE installation ISO's worked like a champ, and while I was able to bypass the fwohci problem from the official 5.3-RELEASE/amd64 ISO's, I hit another wall with the cbb (cardbus bridge).  It, too, caused an immediate panic.  Like before, I tried to disable cbb, cardbus, pccard with hints at the boot prompt, all to no avail.  So, I tried once again to boot, only this time disabling ACPI, and it didn't panic!  I hurriedly got a minimal installation done, and then proceeded to upgrade to RELENG_5 (STABLE).

Unfortunately, I also got the same panic with ACPI+cbb on RELENG_5, so I built a custom kernel without any PCMCIA stuff, and it worked fine from then on, even with ACPI enabled.

I decided then to go ahead and upgrade to -CURRENT, and as it turns out, the ACPI+cbb panic I had with RELENG_5 disappeared!  Now, the machine is running just fine with the GENERIC kernel, no worries.  As an added bonus, the included Atheros-based wireless card now works, too, thanks to the massive ath(4) commits to HEAD by sam@.  As of this writing, I have more hardware support with 64bit FreeBSD than I do with 64bit Windows XP!  Can you see why I love this OS?  :D

As of today (2005-01-28 16:41:32), most everything is working fine.  Just yesterday I found out about the acpi_ppc kernel module (noted above) and it works well.  This laptop has a couple of items that aren't supported under FreeBSD, such as a built-in USB camera, and memory card/stick reader.  They are detected (as noted in the above usbdevs and pciconf output files), but have no drivers to support their functions.  I am not losing any sleep over it.

I have posted an email to acpi@ in order to get some assistance with some funky ACPI stuff that I am seeing.  You can see it at the end of the above dmesg file.  I got a response from nate@ saying that my embedded controller isn't responding, and from his tone (if you can detect 'tone' via email), it doesn't sound like a good thing.  I am not sure, though, because this laptop is running so well.

$Id: index.php,v 1.3 2005/04/26 05:13:34 mwoliver Exp mwoliver $