Earlier, I'd installed Debian on a spare partition on my Thinkpad
Z61p, since it offered support for the Intel 3945ABG wireless
adapter. Now, an experimental driver, wpi, was available in
FreeBSD 7.0 for the 3945ABG, so I thought I would try it instead.
Before blowing away the Debian install, I wanted to ensure that the FreeBSD driver actually worked. To do this, I downloaded the FreeBSD 7.0 LiveFS ISO, burnt it to CD and booted the laptop from it.
Running the wpi driver was not totally straightforward. It
is delivered as a module and hence needs to be loaded via
kldload. Furthermore, the sysctl variable
legal.intel_wpi.license_ack has to be set to "1". To set
this, you need get into the FreeBSD boot loader, (entering
6 does this nicely) and type the following:
set legal.intel_wpi.license_ack="1" boot
Once booted and the LiveFS option choosen from the sysintall menu,
to launch the wpi driver and get a DHCP address I had to
issues the following commands:
ln -s /dist/boot/kernel /boot/kernel kldload if_wpi.ko ifconfig wpi0 ssid hydrus nwkey 0xdeadbeef00 ifconfig wpi0 up mkdir /var/db dhclient wpi0
Ok, that worked. I obtained an IP address and could ping the gateway. There was a bit of packet loss, but it is experiemental after all.
The next thing to establish was the existence of a suitable XOrg
driver to support the screen resolution of the Z61p graphics
display, the ATI Mobility FireGL V5200 at 1920x1200 pixels.
There is an experimental XOrg driver, radeonhd
available. I could verify the stability of this driver under the
soon-to-be-deleted Debian install. The build of the
radeonhd driver requires the installation of some XOrg
development ports, in addition to the standard Debian xorg-server
packages. These are:
pkg-config xserver-xorg-dev x11proto-core-dev x11proto-randr-dev x11proto-render-dev x11proto-video-dev x11proto-xext-dev x11proto-fonts-dev
I located these by using apt-cache, for example:
apt-cache search --names-only randr
I followed the build instructions in the README file, with
the exception of using ../configure rather than
../autogen.sh. The new driver is installed in
/usr/local/lib/xorg/modules/drivers, and you need to edit
your /etc/X11/xorg.conf file to add the following line to
the Files section:
ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
so that the newly installed radeonhd driver can be found on
X startup. Naturally, you need to change the Driver name to
"radeonhd" in the Device stanza in the xorg.conf
file.
On firing up X with the new driver, it appeared to be broken, as the
mouse pointer flickered and characters were duplicated in the
terminal screens. Then I remembered the injuction to reboot the
machine after using the fglrx driver. After that, the
performance and stability of the radeonhd driver seemed
fine.
Ok, now I was happy that FreeBSD 7.0 would be able to drive the
Z61p, I attempted to install it from the LiveFS CD. For reasons
that are not clear, sysinstall couldn't find the CD when
trying to load the base distributions. I got: Couldn't find
distribution on acd0, repeated for each distribution package
(twice!). Then the install process received a SIG11 and
aborted. Nor could I persuade sysinstall to use an FTP
site, as I couldn't establish LAN connectivity using the wired lan
port (bge0), either through DHCP or manually configuring the IP
address, netmask and gateway.
In the end I gave up, downloaded the Disc1 ISO and burnt to a new CD. This worked fine, so I can only assume the LiveFS CD was damaged somehow.
Despite my attempts to not install the FreeBSD boot manager
on the MBR, something still went wrong when I rebooted after
completing the FreeBSD installation. Rather than give me the
Windows boot manager, the laptop went straight into the FreeBSD boot
manager. Something like this had happened before after a FreeBSD
install. In order to prevent bad boot behaviour, this time I had
deliberately tried to make the Windows partition active before I
exited the FreeBSD install process. Anyway, I could boot into
Windows using the Supergrub CD, so I
knew nothing was damaged. However, despite restoring the Windows
MBR using MBRWiz.exe,
the laptop still wouldn't bring up the Windows boot manager. It
wasn't until I set the Windows partition as active using SuperGrub
that normal service was resumed. So maybe I hadn't saved the active
partition setting using FreeBSD's fdisk as I had thought...
At this stage, I was connected to the Internet via the wired LAN
port (bge0), so I was able install all the packages I required using
pkg_add.
The wpi driver didn't operate too well in my
environment. After a short period of time, the number of lost
packets skyrocketed, and somewhat later the connection stalled.
After a few experiments, I found this was due to my selection of
Channel 1 for the wireless router. Setting the channel to 6
resulted in near flawless operation. However, an ifconfig wpi0
scan command can still cause the interface to go into space,
but this is a small problem.
No sooner had I posted this, than the wireless went bad on Channel
6. Same symptoms; large packet loss. Then it got into a state
where it wouldn't even associate. I tried applying the patches from
-CURRENT (1.10) and while the error messages regarding
bus_dmamem_alloc disappeared, it still would not associate.
However, I discovered that an ifconfig wpi0 down;ifconfig wpi0
up would make it associate and then a DHCP address would be
assigned. It just wouldn't work in the normal boot sequence - maybe
some timing issue? I took DHCP out of the /etc/rc.conf
ifconfig_wpi0 setting and created an /etc/rc.local
with the following content (it seems necessary to display the wpi0
status before it will associate):
ifconfig wpi0 ssid hydrus nwkey 0xdeadbeef00 channel 6 ifconfig wpi0 up sleep 1 ifconfig wpi0 down sleep 1 ifconfig wpi0 up sleep 1 ifconfig wpi0 dhclient wpi0
The connection then seemed to be reliable, but it's too early to say for sure.
The sound device is an Intel High Definition Audio (HDA) chip. The
driver for it is snd_hda.ko and is loaded via
/boot/loader.conf.
The default GTK font size was enormous. This was particularly
noticable on the Emacs menu bar. No amount of tweaking the X resources
(e.g. Emacs*menu*font: 6x13) would help. The only thing
that worked was setting a small font in the ~/.gtkrc-2.0 file:
gtk-font-name="sans-serif 6"
It turned out that a better solution was to set the resolution in dots per inch when starting X:
startx -- -dpi 100
Then the .gtkrc-2.0 file was not required.
The /boot/loader.conf is as follows:
legal.intel_wpi.license_ack="1" if_wpi_load="YES" wlan_load="YES" wlan_amrr_load="YES" firmware_load="YES" wpifw_load="YES" snd_hda_load="YES"
The /etc/rc.conf file is as follows:
hostname="amber" #ifconfig_bge0="DHCP" inetd_enable="YES" keymap="uk.iso" linux_enable="YES" nfs_client_enable="YES" sshd_enable="YES" # See /etc/rc.local for wpi0 setup #ifconfig_wpi0="ssid hydrus nwkey 0xdeadbeef00 channel 6" font8x8="iso-8x8" allscreens_flags="80x30" powerd_enable="YES" performance_cx_lowest="HIGH" # Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency economy_cx_lowest="LOW" # Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency
