justine19
Install Broadcom STA wireless driver in openSUSE 11.4 (and other Linux distros)
Broadcom is a real nag. Buying a laptop with Broadcom wireless network card never bothered me until I installed several Linux distros and things started to go less smoothly… especially when you do not have wired ethernet nearby and wireless is all you get.
On the other hand, installing the Broadcom wireless driver for different Linux distros is a great learning experience.
Previously, I talked about how to activate the Broadcom STA wireless driver in Fedora 14. It turns out the activation is slightly different in openSUSE.
The following works on openSUSE 11.3, 11.4, Mint 10 Julia, Ubuntu 10.x, Kubuntu 10.x, and LMDE.
To make Wi-Fi work in openSUSE 11.4, first download the tarball containing Broadcom’s IEEE 802.11a/b/g/n hybrid Linux device driver from http://www.broadcom.com/support/802.11/linux_sta.php
The cards with the following PCI Device IDs are supported with this driver.
Both Broadcom and and Dell product names are described. Cards not listed here
may also work.
BRCM PCI PCI Dell
Product Name Vendor ID Device ID Product ID
------------- ---------- --------- -----------
4311 2.4 Ghz 0x14e4 0x4311 Dell 1390
4311 Dualband 0x14e4 0x4312 Dell 1490
4311 5 Ghz 0x14e4 0x4313
4312 2.4 Ghz 0x14e4 0x4315 Dell 1395
4313 2.4 Ghz 0x14e4 0x4727 Dell 1501
4321 Dualband 0x14e4 0x4328 Dell 1505
4321 Dualband 0x14e4 0x4328 Dell 1500
4321 2.4 Ghz 0x14e4 0x4329
4321 5 Ghz 0x14e4 0x432a
4322 Dualband 0x14e4 0x432b Dell 1510
4322 2.4 Ghz 0x14e4 0x432c
4322 5 Ghz 0x14e4 0x432d
43224 Dualband 0x14e4 0x4353 Dell 1520
43225 2.4 Ghz 0x14e4 0x4357
43227 2.4 Ghz 0x14e4 0x4358
43228 Dualband 0x14e4 0x4359 Dell 1530
To find the Device ID's of Broadcom cards on your machines do:
# lspci -n | grep 14e4
Untar the package:
$ tar -xvf hybrid-portsrc_x86_32-v5_100_82_38.tar.gz
And build this driver from source:
$ make
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
make: *** /lib/modules/2.6.37.6-0.7-desktop/build: No such file or directory. Stop.
make: *** [all] Error 2
Looks like you yet need to install the proper packages, which will create /lib/modules/”release”/build on your system. Take a quick check on what kernel packages you have:
$ rpm -qva | grep kernel
kernel-desktop-2.6.37.6-0.7.1.i586
kernel-default-2.6.37.6-0.7.1.i586
So, just install ‘kernel-devel’ (Development Package for building kernel modules to match the kernel):
$ sudo zypper install kernel-devel
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following NEW packages are going to be installed:
kernel-default-devel kernel-desktop-devel kernel-devel
3 new packages to install.
Overall download size: 20.9 MiB. After the operation, additional 50.0 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package kernel-devel-2.6.37.6-0.7.1.noarch (1/3), 7.2 MiB (35.2 MiB unpacked)
Retrieving: kernel-devel-2.6.37.6-0.7.1.noarch.rpm [done (66.3 KiB/s)]
Retrieving package kernel-desktop-devel-2.6.37.6-0.7.1.i586 (2/3), 7.1 MiB (7.8 MiB unpacked)
Retrieving: kernel-desktop-devel-2.6.37.6-0.7.1.i586.rpm [done (71.3 KiB/s)]
Retrieving package kernel-default-devel-2.6.37.6-0.7.1.i586 (3/3), 6.5 MiB (7.1 MiB unpacked)
Retrieving: kernel-default-devel-2.6.37.6-0.7.1.i586.rpm [done (49.2 KiB/s)]
Installing: kernel-devel-2.6.37.6-0.7.1 [done]
Installing: kernel-desktop-devel-2.6.37.6-0.7.1 [done]
Installing: kernel-default-devel-2.6.37.6-0.7.1 [done]
Also, install the GNU Compiler:
$ sudo zypper install gcc
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following NEW packages are going to be installed:
binutils-gold gcc gcc45
3 new packages to install.
Overall download size: 5.6 MiB. After the operation, additional 18.2 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package binutils-gold-2.21-13.1.i586 (1/3), 699.0 KiB (2.8 MiB unpacked)
Retrieving: binutils-gold-2.21-13.1.i586.rpm [done (36.0 KiB/s)]
Retrieving package gcc45-4.5.1_20101208-9.8.i586 (2/3), 5.0 MiB (15.4 MiB unpacked)
Retrieving: gcc45-4.5.1_20101208-9.8.i586.rpm [done (79.7 KiB/s)]
Retrieving package gcc-4.5-19.1.i586 (3/3), 4.0 KiB (0 B unpacked)
Retrieving: gcc-4.5-19.1.i586.rpm [done (0 B/s)]
Installing: binutils-gold-2.21-13.1 [done]
Installing: gcc45-4.5.1_20101208-9.8 [done]
Installing: gcc-4.5-19.1 [done]
Then, run make again:
$ make KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-2.6.37.6-0.7-obj/i386/desktop' make -C ../../../linux-2.6.37.6-0.7 O=/usr/src/linux-2.6.37.6-0.7-obj/i386/desktop/. CC [M] /home/surfmonkey/broadcom-wl/src/shared/linux_osl.o CC [M] /home/surfmonkey/broadcom-wl/src/wl/sys/wl_linux.o /home/surfmonkey/broadcom-wl/src/wl/sys/wl_linux.c: In function ‘wl_attach’: /home/surfmonkey/broadcom-wl/src/wl/sys/wl_linux.c:485:3: error: implicit declaration of function ‘init_MUTEX’ make[4]: *** [/home/surfmonkey/broadcom-wl/src/wl/sys/wl_linux.o] Error 1 make[3]: *** [_module_/home/surfmonkey/broadcom-wl] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.37.6-0.7-obj/i386/desktop' make: *** [all] Error 2 $ ls -l total 1184 -rw-r--r-- 1 surfmonkey users 8 Aug 13 18:22 built-in.o -rw-r--r-- 1 surfmonkey users 1195817 Aug 13 18:11 hybrid-portsrc_x86_32-v5_100_82_38.tar.gz drwxr-xr-x 2 surfmonkey users 4096 Dec 14 2010 lib -rw-r--r-- 1 surfmonkey users 1134 Dec 14 2010 Makefile drwxr-xr-x 5 surfmonkey users 4096 Dec 14 2010 src
There is still an error building the driver. The expected wl.ko file wasn’t generated.
It turns out there is a compilation problem with kernel versions > 2.6.37. The kernel I have falls right into that range:
$ uname -a
Linux opensuse 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 i686 i686 i386 GNU/Linux
We need to apply a patch to fix the ‘init_MUTEX’ compile problem on newer (> 2.6.37) kernels.
At the top level of the driver source folder (where ”ls” should show at least src, lib, Makefile), create a file which I named “patch.” Fill in the following lines:
--- src/wl/sys/wl_linux.c 2011-05-20 12:07:25.303356739 -0700
+++ src/wl/sys/wl_linux.c.new 2011-05-20 12:07:13.663356735 -0700
@@ -481,9 +481,9 @@
if (WL_ALL_PASSIVE_ENAB(wl)) {
#ifdef WL_ALL_PASSIVE
spin_lock_init(&wl->txq_lock);
#endif
- init_MUTEX(&wl->sem);
+ sema_init(&wl->sem, 1);
}
if (!(wl->wlc = wlc_attach((void *) wl, vendor, device, unit, wl->piomode,
osh, wl->regsva, wl->bcm_bustype, btparam, &err))) {
Save it, and go back to the command line:
$ patch -p0 < patch
patching file src/wl/sys/wl_linux.c
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 481 with fuzz 1.
Try building the driver again:
$ make
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
make[1]: Entering directory `/usr/src/linux-2.6.37.6-0.7-obj/i386/desktop'
make -C ../../../linux-2.6.37.6-0.7 O=/usr/src/linux-2.6.37.6-0.7-obj/i386/desktop/.
CC [M] /home/surfmonkey/broadcom-wl/src/wl/sys/wl_linux.o
CC [M] /home/surfmonkey/broadcom-wl/src/wl/sys/wl_iw.o
LD [M] /home/surfmonkey/broadcom-wl/wl.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: modpost: missing MODULE_LICENSE() in /home/surfmonkey/broadcom-wl/wl.o
see include/linux/module.h for more information
CC /home/surfmonkey/broadcom-wl/wl.mod.o
LD [M] /home/surfmonkey/broadcom-wl/wl.ko
make[1]: Leaving directory `/usr/src/linux-2.6.37.6-0.7-obj/i386/desktop'
Do a quick “ls” to make sure the wl.ko file has been successfully created.
$ ls -l
total 8100
-rw-r--r-- 1 surfmonkey users 8 Aug 13 18:22 built-in.o
drwxr-xr-x 2 surfmonkey users 4096 Dec 14 2010 lib
-rw-r--r-- 1 surfmonkey users 1134 Dec 14 2010 Makefile
-rw-r--r-- 1 surfmonkey users 42 Aug 13 18:30 modules.order
-rw-r--r-- 1 surfmonkey users 0 Aug 13 18:30 Module.symvers
-rw-r--r-- 1 surfmonkey users 437 Aug 13 18:30 patch
drwxr-xr-x 5 surfmonkey users 4096 Dec 14 2010 src
-rw-r--r-- 1 surfmonkey users 3527159 Aug 13 18:30 wl.ko
-rw-r--r-- 1 surfmonkey users 4646 Aug 13 18:30 wl.mod.c
-rw-r--r-- 1 surfmonkey users 39660 Aug 13 18:30 wl.mod.o
-rw-r--r-- 1 surfmonkey users 3488826 Aug 13 18:30 wl.o
Now, let’s do a fresh install of the wl driver, since the system was just upgraded live to openSUSE 11.4 and no previous version of the wl driver has been running.
First, check if there’s any other driver for Broadcom wireless device on the system:
$ lsmod | grep "b43\|ssb\|wl"
$ [blank]
Looks good. If any of these are installed, remove them:
# rmmod b43 # rmmod ssb # rmmod wl
And blacklist these drivers and prevent them from loading in the future:
# echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf # echo "blacklist b43" >> /etc/modprobe.d/blacklist.conf
At root,
# cp wl.ko /lib/modules/`uname -r’/kernel/net/wireless/ # insmod wl.ko insmod: can't read 'wl.ko': No such file or directory
You could skip insmod wl.ko if it doesn’t work.
Make sure you’re root “su –“. Otherwise, you’d get this:
$ sudo insmod wl.ko
root's password:
sudo: insmod: command not found
Proceed to
# modprobe lib80211 # depmod -a # modprobe wl
Now, check your Network Manager, and you should see wireless networks immediately.
In openSUSE, the module will be loaded on boot. In Mint/Ubuntu/Kubuntu/LMDE, users will need to add it manually in /etc/modules file.
- – – – – – – – – –
You can also find this post on my other blog.
Memberi.opensu.se YMP Generator
Bernhard Wiedemann approached me a few days ago to host his YMP generator CGI script on opensu.se.
I wrote it from scratch (it's just a few lines of Perl code really ;)), and it's now up and running on i.opensu.se (follow that link for details and explanation).
In a similar fashion to r.opensu.se, it is meant to be helpful to give support to users, as it is much simpler to hand them a short URL like http://i.opensu.se/utilities/atool than going through the hassle of guiding them through YaST2.
It is especially well suited for twitter, IRC, etc...
The source code is in my git repo at gitorious.
The 5 Ws of contributing to openSUSE
GMime 2.5.10: A Call For Testers
I've just released GMime 2.5.10 which I hope to be the last of the 2.5 releases before I release 2.6.0. I feel that I've stretched the development of 2.6.0 out for far too long (2.5 development began at the end of April, 2009) and even though I didn't get around to doing everything I had hoped to do, I feel that the latest 2.5.x releases are such an improvement over 2.4.x that I just want to get it out there for developers to start using. But before I make a 2.6.0 release, I'm hoping to get some feedback and some testing.
What's new?
New for the release of 2.5.10 is GMimePartIter which replaces the need for g_mime_object_foreach()and its awkward callback requirement, instead allowing you to take the far nicer iterator approach that is popular in the C# and Java worlds (known as IEnumerator in C#). This new iterator, like the foreach function it replaces, iterates over the MIME tree structure in depth-first order.
Inspired by IMAP's FETCH body part-specifier syntax, I've implemented a method allowing you to jump to a part based on a part-specifier string (aka a path): g_mime_part_iter_jump_to(). Also implemented is a function called g_mime_part_iter_get_path(), which can be used to tell you the current part-specifier path of the iterator.
For example, if you had the following MIME message structure:
multipart/related
multipart/alternative
text/plain
text/html
image/jpeg
The body part-specifier paths would be:
1 multipart/alternative 1.1 text/plain 1.2 text/html 2 image/jpeg
This means that g_mime_part_iter_jump_to(iter, "1.2") would jump to the part specified by the path "1.2" which, as we can see above, would be the text/html part. Calling g_mime_part_iter_next(iter) would iterate to the next part, being the image/jpeg, while calling g_mime_part_iter_prev(iter) would iterate backwards to the text/plain part and calling it again would iterate backwards to the multipart/alternative.
What I Need From Testers
My feeling is that developers will want to use this cool new body part-specifier path functionality for aiding them in implementing IMAP servers and/or clients. Because of this, it would be great if GMime's implementation matched IMAP's specification exactly. The problem is that I don't have the time or energy to verify that the paths work out to be identical in all cases. So... if you are one of those developers who is interested in using this functionality and need it to be identical to IMAP's syntax (or would really like it to be), I'm hoping that you could test it out and make sure that it matches. Especially worthwhile of testing, I'd imagine, is having message/rfc822 parts in the tree. I suspect that, if anywhere, this is where differences may be.
If body part-specifier paths aren't something you care about, don't fret; the rest of the iterator API needs testing as well and if you have no interest in the iterator API at all, perhaps you'd be willing to test the S/MIME functionality (especially since I haven't figured out how to test it myself, given that I don't have an S/MIME cert nor have I figured out how to generate one or add one to my gpgsm keyring).
Your help will be greatly appreciated.
redshift and backintime in Factory
Redshift is a little command-line (and GTK) utility which reduces screen brightness at night (via colour temperature, so your screen becomes more red). Given your location in the world, it automatically calculates sunset and sunrise and gradually ramps up/down the brightness at the right times. I find it makes working at night easier on the eyes, and wrote a little plasmoid to control it easily from the desktop, which I will also release when I get some time.
For previous openSUSE versions one can download and install redshift from its OBS devel project, X11:Utilities.
Backintime is a backup program, effectively a rsync frontend, with GUIs for KDE and GNOME. Once configured with which folders you want to back up, and where you want to back up to, it can automatically take backups based on a schedule. Also a very nice feature is that on filesystems that support it (not FAT), it uses hardlinks to the previous backup, so each backup is a full backup but only changed files take up space on the backup disk. Each backup is just a normal copy of all the folders, so no special software is needed for recovery, but backintime offers a GUI that allows you to easily navigate through all your backed up versions of a folder. IMO it's the best userfriendly but complete backup software for Linux desktops. backintime used to be packaged by packman and now lives on the OBS in Archiving:Backup.
Enjoy! If you have other interesting programs that aren't in openSUSE remember that anyone can contribute to Factory now, so if you are willing to maintain them, go ahead and submit them on the OBS! My next target is byobu, a set of preconfigured GNU screen profiles (I never figured out how to write hardstatus lines!)
PackageKit backend for Software Center: week 11 status report
This week in three short achievements:
- personal OBS project (playing around, tutored by DimStar), work in progress
- code tide-up, ready for merging into master
- features, usage and testing documentation, work in progress
I’m now focusing on the gtk3 part, and also documenting things around. Packaging has decreased priority, waiting for the pygobject release.
And done 
Wheelbuilding...
1) Buy "Professional guide to Wheel Building" by Roger Musson, it is going to be the best 9GBP you have spent in a long long while. [HINT1]
2) Read it, twice!
3) Buy the rims and hubs before you buy the spokes (and get the necessary tools too if you haven't already).
4) Measure the ERD (Effective Rim Diameter) using the old-spokes with glued-on nipple method that Roger describes [HINT2].
5) Buy the spokes that spocalc.xls then calculates for you.
5) Lace your wheel like Roger describes, to the letter.
6) Tension your wheel like Roger describes, to the letter [HINT3].
HINT1: Do not read any other sources, Gerd Schraner's book is just pure nostalgia and does not help you much. Especially his explanation for tensioning your spokes should be ignored: while it might get you a straight wheel, your spokes might have wildly varying tension, and are therefor likely to either break due to fatigue or have the wheel go out of true quickly.
HINT2: For creating the cut-off spokes for measuring the ERD as Musson describes; screw your nipples onto your spokes so that your spoke only _just_ comes out of the nipple into the groove for the nipple-driver. This is the measuring length you should use. If you use the absolute top of the nipple for measuring the length, then you will have no room for error, and you will very likely use up all of the thread on the spoke while bringing the wheel up to full tension (this is the experience bit right here). If it is still inside the nipple, then you most likely will end up with too short a spokes, with thread still showing, this too is a nightmare for wheel-building (your nipple-driver will not disengage). Once you bring your wheel up to its final tension, the spoke (especially double butted spokes) will come slightly further out of the nipple as with the measurement-spokes.
HINT3: For the final stage of tensioning, where the spokes tend to turn with the spoke-key, I marked the rim-sides of the spokes with different colour alcohol markers. This gave me the ability to view the turning of the spokes, and to undo it, close to the rim and nipple, without hampering the spoke-key. Since this is an alcohol based marker on stainless steel, you can rub it off afterwards, or you could just take some alcohol to wipe it off. I just kept it on now, knowing full well that most of it will disappear soon enough in the rain and mud.
I am using Extreme Airline 3s, which i got from Rose. These are rather deep rims that are very stable and sturdy, and they have a wear-indicator still. The joint is not done well, and you will always have a third or so of a mm difference in diameter there, but for trekking or mtb tires, this is no issue, it is just annoying when working on the wheels in the stand. Because these rims are so sturdy, the Schraner method becomes quite unreliable, you can much more easily get away with differently tensioned spokes, as the rim is much more likely to even differences out for you instead of showing where the differences are. You actually need to pluck the spokes instead, like Musson describes, early on in the tensioning process, to get rid of the differences in tone and therefor tension.
I ordered a pre-built set of Airline 3s (28" with LX hub and 3N72 dynamo) from Rose more than a year ago, and they seem quite sturdy and have served me well so far. But, sadly, these pre-built wheels were not up to tension, which I could hear on steep climbs as the spokes were rubbing against eachother with heavy and changing load. They were subsequently very hard to tension further, my guess is because of badly oiled nipples before assembly.
Recently I built a first set according to the Schraner method, and while this went well, and the wheels feel good, I am not sure how good they really are as I haven't used them yet. It could be that they go out of true quickly, especially after pumping quite a bit of heat in them going down some slope in the Fränkische Schweiss. The spoke lengths I used for the 28" Extreme Airline 3 rims, triple crossed (of course!) and with 12mm nipples are 276mm for the front, 281/283 for the back.
For the 26" version of the same rim, with the same hubs, same lacing, same nipples, I used 246mm for the front, and 251/253 for the back. This was calculated with spocalc after measuring the rim, according to Musson, and the ERD is 523mm (after correcting for my mistake). These wheels are for a velotraum cross crmo frame that I am just now building up, so there are no kms on them either, but I have a very very good feeling about them, as I did use Mussons book for them, and the wheels came together as good or even better than described. So while my own handiwork is still untested in real-life conditions, at least I can tell the difference between Schraner and Musson, and the spoke lengths are (now) correct too ;)
In any case, if you are into cycling, have done all other jobs around the bicycle, and mastered them, already, then try your hand at wheel-building to complete the skill-set. It is not black magic, it is actually highly logical, but you should not use sentences like "How hard can it be?" or "Right, I'll get my hammer!" when doing so. Read the right book, get the right tools and the correct spokes, and then take your time; it is really very rewarding.
looking for Artists, artworks and graphics for LXDE
openSUSE 12.1 is on its way, and recently LXDE got some major updates.
I’m personally always been really satisfied of how LXDE works and is integrated into the openSUSE user experience, one defect though , that I’m really sorry about, is that i was never able to provide a very nice look&feel.
Since I’m not a graphic, and i realized I’m failing, i decide to ask your help now.
Here is what we need:
1) A gtk2 + openbox theme (including lxpanel background and icon theme)
2) A theme for lxdm (you can use /usr/share/lxdm/themes/Industrial as template), and eventually a background too
Also, i would like to open a contest. Your goal is create a logo for openSUSE-LXDE project.
You’ll have more information as soon as possible about this contest on the opensuse-lxde@o.o mailing list and here on lizards, please keep in mind that we want to print the winning logo on t-shirts too.
Up to date info about the contest will be available in the wiki here
I hope lot’s of you will help.
Andrea
SUSE graphical benchmark test
So finally I put together a standardized graphical benchmark with aspects for all users. And no, it won't output a single number, because that would be meaningless for everybody. But it makes it easy to compare different aspects between different graphics cards and drivers, and there are some surprising results. But more about the results later.
The sources for the benchmark are now on gitorious, and the Wiki entry describes its usage. It's currently somewhat tailored to SLE11SP1, so you might run into minor issues when running it on a different OS version. And of course, it's not very polished yet
.