My First Impressions
The SLES SP1 x64 is able to boot my system right into X11 after installation. Nonetheless, a lot of glitches remain. First, the screen is always stuck after a couple of second before the system can respond to user input again. The WLAN adapter (Broadcom BCM4318) is _not_ working. The bluetooth adapter (Broadcom 2025?) is not working. However, everything else is just fine.
Fixing Things
The first step is to update the aging Linux kernel 2.6.16-x that comes out of the box with kernel 2.6.24.3.
It's pretty easy, I just get the old optimized kernel config from my previous Slackware 12 (32-bit) and change some parameters, and then build the kernel RPM as follows:
make mrproper
make ARCH=x86_64 menuconfig
make -j4 binrpm-pkg
Upon completion, the kernel build process will show you where the resulting kernel RPM located.
Using: rpm -iv <kernel_rpm> , the kernel is installed. Unfortuntele, upgrading the kernel is not enough, because the kernel mismatch with the udev utilities which links the kernel with the user application through /dev. So, udev is upgraded to version 118 (previously version 085 with the default install). Note that the psmouse module is not loaded by default by the kernel so, it must be added to the module loaded on boot in the /etc/sysconfig editor in Yast2.
The second thing to do is installing the propietary ATI Xpress 200M display driver. This is needed because I want ultimate performance when using X11. It's pretty trivial, all you have to do is make sure the links (build and source links) in the kernel module directory points to the _real_ kernel source that you have configured and has right module version file. You can run "make modules" in the kernel source to obtain the required kernel source level. After that, driver installation is trivial.
The third thing is to get the WLAN working. This is one of those mundane task. First, I have to find a working Windows XP x64 WLAN driver because Ndiswrapper currently a bit problematic when dealing with Vista driver. I don't go the native-linux-driver way because it's not working after a few tries. It's a bit of a guess work to find the driver, but after some searching I found it at: ftp://ftp.acer-euro.com/notebook/aspire_5020/driver/xp64/Wlan Driver Ambit Broadcom Ver. 3.100.64.0.zip. I found this link upon reading: http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,list_b/
The post at Ndiswrapper is a bit misleading because Acer Europe seems to have reorganized the directories in the FTP server. So, obtain the driver and use ndiswrapper to use the driver. The approach is the same as 32-bit driver. Note that I'm using Ndiswrapper version 1.52
make uninstall
make -j2
su -
make install
ndiswrapper -i bcmwl5.inf
Then disable the native linux driver by making it a blacklisted driver. To do this,
edit /etc/modprobe.d/blacklist
# Disable the default Broadcom BCM43xx and mac80211 driver
# because we are using ndiswrapper
blacklist mac80211
blacklist ssb
blacklist b43
Then go to Yast2 /etc/sysconfig editor and change the module loaded on boot, add ndiswrapper there.
We're not done yet. The wireless tools that comes with SLES 10 SP1 cannot work with the current 2.6.24 kernel so, it has to be replaced with newer wireless tools. I'm using wireless tools version 29 and it can work correctly.
To make all of these wireless setting to work, the machine must be rebooted.
Now, the thing left unhandled is the bluetooth. I'll post about it when I'm done.
So, after one day of struggling to find the solution, I finally managed to make my bluetooth Dial-up Networking (DUN) works, even if there's still a catch. These are the steps to make it work:
1. Download the bluez sources from www.bluez.org. You need to download the mandatory bluez-libs, bluez-utils packages. I chose to download bluez-hcidump and bluez-firmware as well because my bluetooth dongle is Broadcom bcm2045 and I need the hcidump tools to debug the bluetooth connection.
2. The packages other than bluez-utils need to be configured using the following parameters:
export CFLAGS=" -m64 -O2 -mtune=athlon64 -funroll-loops -fexpensive-optimizations "
export CXXFLAGS=${CFLAGS}
./configure --prefix=/usr --libdir=/usr/lib64
It has to be like that because I'm running SLES 10 SP1 64-bit which uses multilib. In systems that uses multilib, the 64-bit libraries are placed in a different directory, e.g. /usr/lib64, /lib64, while the "old" 32-bit libraries remain in the old places, such as /lib, /usr/lib. This is of course outside of the 64-bit kernel modules which are placed in /lib/modules/`uname -r`.
3. The configuration of the bluez-utils package as follows:
export CFLAGS=" -m64 -O2 -mtune=athlon64 -funroll-loops -fexpensive-optimizations "
export CXXFLAGS=${CFLAGS}
./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc \
--localstatedir=/var --libexecdir=/lib64 --disable-debug --enable-hal \
--enable-usb --disable-alsa --enable--obex --enable-glib --disable-gstreamer \
--disable-audio --enable-input --enable-serial --enable-network \
--enable-sync --enable-echo --enable-hcid --enable-sdpd --enable-hidd \
--enable-pand --enable-dund --enable-test --enable-manpages \
--enable-configfiles --enable-initscripts --enable-tools --enable-bccmd \
--enable-hid2hci --enable-dfutool --enable-dfubabel
It's a pretty complex configuration due to the quite outdated development packages in SLES 10 SP1.
4. Next up is compiling the packages. It's as easy as invoking
make -j2
in the package directory.
5. Then install the packages under root privilege with:
make install
After installing the package, then configure the configuration files as mentioned in my previous bluetooth setting post.
Once the configuration files has been adjusted, we are ready to go. What you need to do now is fire up the needed services and setup the rfcomm device as follows.
opunaga:~ # /etc/rc.d/bluetooth start
opunaga:~ # rfcomm bind rfcomm0
The bluez-utils package installs the bluetooth initialization code in /etc/rc.d/bluetooth. I'm a bit lost previously and I find this file by accident when I was reading the scripts in /etc/rc.d directory.
Then this is where the weird bluetooth authentication bug occurs. No matter how hard I try, I never managed to connect the phone directly by only invoking wvdial and then typing the bluetooth passcode in the phone. To solve this problem, I have to pair the phone first hand before invoking wvdial, otherwise it will stop with messages like "rfcomm connection refused". Therefore, pair the bluetooth connection by opening the bluetooth setting in the phone first, then you can invoke wvdial as usual. In this case, wvdial won't need authentication anymore, because the hci interface (bluetooth USB dongle) has been paired with the phone. So, just invoke:
wvdial bluetooth
There you have it. The bluetooth is working in my x86_64 system. Anyway, I noticed that the bluetooth connection in my x86_64 SLES 10 SP1 is much more robust and quicker in terms of connection setup time apart from the weird passcode authentication bug I mentioned above.
Post a Comment
