This weekend I finally updated my LG X130 netbook to Slackware 13.37. This is one of my “stable” machines that I use all the time for day-to-day tasks, so I do not run -current on it, as I depend on it too much. Slackware-current is very interesting for research and testing all the new stuff, but it can break when you least expect it. And then you need a “stable” installation to at least access the internet, pay the bills, read e-mail, etc. So I left this netbook as one of the last machines to update to Slackware 13.37.

And it went quite smoothly. Except for one thing: the wireless adapter was not working…

Old problem returning?

I remembered that when I first installed Slackware on this netbook about a year ago, I also had a problem with this rt3090 card. The kernel confused it with the rt2800 and tried to load the rt2800pci module – which did not work with this adapter.
At the time, I found a simple solution by ‘Googling”: putting the rt2800pci module on the blacklist by creating a simple text file in /etc/modprobe.d/ with a single line:

blacklist rt2800pci

So I checked if that file was still there, and it was…
I did a “lsmod | grep rt2” and the result was:

rt2860sta 483303 1
crc_ccitt 1087 1 rt2860sta

So the correct module was loaded!

More investigation was needed

“ifconfig” did not show the wlan0 interface, but “ifconfig -a” did.
I tried “ifconfig wlan0 up” but it returned with:

SIOCSIFFLAGS: Operation not permitted

So what do we do when a kernel module has problems? Check the dmesg log…
I did a “dmesg | grep -i rt” and found this interesting line:

rt2860 0000:02:00.0: firmware file rt3090.bin request failed (-2)

So, the rt2860 module is looking for the rt3090.bin firmware and not finding it!

But isn’t the rt2860 driver used for the rt3090? I remembered reading (don’t know where, probably when I first installed Slackware 13.1 on this netbook) that the rt3090 adapter was handled 100% by the rt2860 driver.
I decided to check the /lib/firmware directory, where all the firmware files are installed in Slackware. There were several rt2xxx.bin files, but no rt3090.bin.

This is where I decided to get bold

I thought: It’s not working anyway, so what can I loose?
And I created a symlink rt3090.bin to rt2860.bin They are the same in the kernel anyway, right?
I rebooted, and… It worked!

My wireless adapter was working again and my netbook was fully operational as before the update.

But was this really the correct solution?

I decided to go straight to the source and browse around on kernel.org. And in their git repository I found this commit:

rt2860sta: Use latest firmware for RT3090

author Ben Hutchings
Sat, 30 Apr 2011 18:31:32 +0000 (19:31 +0100)
committer Ben Hutchings
Tue, 17 May 2011 04:22:12 +0000 (05:22 +0100)

Ralink’s original drivers for RT2800P/RT2800E-family chips used
multiple different versions of the firmware for different chips. The
rt2860sta driver in staging was briefly converted to load different
files for different chips. However, the current rt2860.bin is
supposed to work on all of them, so replace rt3090.bin with a symlink.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Well, well! So the official solution was to create a symlink as well!
I checked the tree in their git repository and there you can see they have the symlink “rt3090.bin” pointing to the rt2860.bin file, just as I did.
I also noticed a second symlink: rt3070.bin is pointing to rt2870.bin.

Report it back to “The Man”

Now that I was reassured that my solution was the correct one, I sent an e-mail to Pat Volkerding about my findings.
It would be nice to see the rt2860-firmware-26-fw-1 package create the symlink on installation, to prevent some headaches around the world

The user sent me a patch that worked, but hacking kernel modules is not to be taken lightly, so I wanted to understand what was going on…

Read the documentation!

It’s something most people don’t like, but it actually is a good idea to read the documentation once in a while
In /usr/src/linux/Documentation/scsi/scsi_mid_low_api.txt (if you have the 2.6.37.x kernel installed), I found this interesting comment:

Locks: up to and including 2.6.36, struct Scsi_Host::host_lock
held on entry (with “irqsave”) and is expected to be
held on return. From 2.6.37 onwards, queuecommand is
called without any locks held.

Well, that seems to be the culprit then… So now I headed for the kernel git repository and found this interesting commit:

Move the mid-layer’s ->queuecommand() invocation from being locked
with the host lock to being unlocked to facilitate speeding up the
critical path for drivers who don’t need this lock taken anyway.

The patch below presents a simple SCSI host lock push-down as an
equivalent transformation. No locking or other behavior should change
with this patch. All existing bugs and locking orders are preserved.

Additionally, add one parameter to queuecommand,
struct Scsi_Host *
and remove one parameter from queuecommand,
void (*done)(struct scsi_cmnd *)

Scsi_Host* is a convenient pointer that most host drivers need anyway,
and ‘done’ is redundant to struct scsi_cmnd->scsi_done.

Minimal code disturbance was attempted with this change. Most drivers
needed only two one-line modifications for their host lock push-down.

I checked some of the patches in the kernel tree and indeed they seemed quite simple. This is the patch for the aha1542 driver:

--- a/drivers/scsi/aha1542.c
+++ b/drivers/scsi/aha1542.c
@@ -558,7 +558,7 @@ static void aha1542_intr_handle(struct Scsi_Host *shost)
 };
 }
-static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
+static int aha1542_queuecommand_lck(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 {
 unchar ahacmd = CMD_START_SCSI;
 unchar direction;
@@ -718,6 +718,8 @@ static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 return 0;
 }
+static DEF_SCSI_QCMD(aha1542_queuecommand)
+
 /* Initialize mailboxes */
 static void setup_mailboxes(int bse, struct Scsi_Host *shpnt)
 {

Patching the VHBA module

In the SVN repository for VHBA I found this patch:

--- trunk/vhba-module/vhba.c 2010/08/15 20:11:18 691
+++ trunk/vhba-module/vhba.c 2011/02/27 15:56:27 730
@@ -363,7 +363,7 @@
 spin_unlock_irqrestore(&vhost->cmd_lock, flags);
 }
-static int vhba_queuecommand(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
+static int vhba_queuecommand_lck(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
 {
 struct vhba_device *vdev;
 int retval;
@@ -388,6 +388,12 @@
 return retval;
 }
+#ifdef DEF_SCSI_QCMD
+DEF_SCSI_QCMD(vhba_queuecommand)
+#else
+#define vhba_queuecommand vhba_queuecommand_lck
+#endif
+
 static int vhba_abort(struct scsi_cmnd *cmd)
 {
 struct vhba_device *vdev;

(there’s actually a bit more, but that’s just a cosmetic change…)

The #ifdef / #else / #endif structure was included so that it will work on “older” kernels as well.
It looked similar enough to the official kernel changes, so I included that patch in my SlackBuild script and the VHBA module started working again without crashing my system!

RocketRaid module with similar behavior…

And then yesterday I saw a post on LinuxQuestions about similar problems with the RocketRaid rr232x driver. Since it’s also a “SCSI” driver and it also crashed, I imagined it to have the same cause.

I created a patch based on my little research and posted it in the forum:

--- rr232x-linux-src-v1.10/osm/linux/osm_linux.c 2009-07-15 22:28:28.000000000 -0300
+++ rr232x-linux-src-v1.10_patched/osm/linux/osm_linux.c 2011-03-19 20:27:49.000000000 -0300
@@ -874,7 +874,7 @@
 }
 }
-static int hpt_queuecommand (Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
+static int hpt_queuecommand_lck (Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 {
 struct Scsi_Host *phost = sc_host(SCpnt);
 PVBUS_EXT vbus_ext = get_vbus_ext(phost);
@@ -1408,6 +1408,12 @@
 return 0;
 }
+#ifdef DEF_SCSI_QCMD
+DEF_SCSI_QCMD(hpt_queuecommand)
+#else
+#define hpt_queuecommand hpt_queuecommand_lck
+#endif
+
 static int hpt_reset (Scsi_Cmnd *SCpnt)
 {
 PVBUS_EXT vbus_ext = get_vbus_ext(sc_host(SCpnt));

Today the original poster answered that it worked “like a charm”
This patch can be downloaded from my site.

The system

Recently I upgraded a system that was still running Slackware 13.0. It’s a not-so-new system, but should be good enough to serve as a desktop for some more time: 2.6GHz P4, 1GB of memory, 160GB hard drive. Video, sound, network are all on-board, using a cheap Via chipset.
This box has had some stability problems before, like freezing with several tabs open in Firefox, but I thought it was simply because that browser was getting more and more “obese”

Youtube or not Youtube?

After upgrading it to Slackware 13.1, it showed very “consistent” behavior: All videos from Youtube were without sound or stuttering sound. I checked the usual suspects: flashplayer-plugin, alsaconf, etc., but without success. All I found on the internet about Youtube videos without sound was old information from years ago that did not apply.
I tried to save some videos locally, and found that they played well in mplayer, but also with stuttering sound in gxine. So the problem was not related to Youtube…

Comparing with another system

Next step was comparing the configuration with a similar box, with the same sound chip (at least I thought…). On this second system I had no problems at all with sound, although the configuration is quite similar – it’s just a bit newer and has some better specs (memory, processor, etc.)
But… there was a small difference between the two HDA Intel chips…

This is the one that stutters:

02:01.0 Audio device: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller)
 Subsystem: ASUSTeK Computer Inc. Device 818f
 Flags: bus master, fast devsel, latency 0, IRQ 17
 Memory at fbefc000 (32-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit-
 Capabilities: [70] Express Legacy Endpoint, MSI 00
 Capabilities: [100] Virtual Channel 
 Capabilities: [130] Root Complex Link 
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

and this is the one that works fine:

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
 Subsystem: ASUSTeK Computer Inc. P5KPL-CM Motherboard
 Flags: bus master, fast devsel, latency 0, IRQ 44
 Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
 Capabilities: [100] Virtual Channel 
 Capabilities: [130] Root Complex Link 
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

Google is our friend again

So, back to Google, and after some browsing I found an interesting article about nvidia chips that had the same problem here.

I edited the /etc/modprobe.d/sound.conf file and added this line:

options snd-hda-intel enable_msi=0

And, after a reboot, the system played videos in Youtube and locally without any stuttering

The kernel patch that is suggested in the article is already included in the kernel that comes with Slackware 13.1, but it only checks for the nvidia chip.
If this box continues to work fine, I might patch the source for the HDA Intel driver (hda_intel.c) and compile a custom kernel. If that works fine, I’ll send the patch to the maintainer of this module.

Installation of Slackware 13.1 went smoothly, as always, except for one thing: the maximum resolution with the NVIDIA driver (built with the script from SlackBuilds.org) was 1280×1024. This annoyed me and intrigued me at the same time, as the Debian spin-off worked flawlessly at 1600×900.

In the /var/log/Xorg.0.log (the first place to look when X does not work the way you expect) I noticed the following strange error message:

Failed to allocate primary buffer: out of memory

The /etc/X11/xorg.conf created by the nvidia-settings program was almost the same on both Linux flavors, so that was not the problem.

Then I started to check the differences between the two installations…
I noticed that the Debian spin-off used an older kernel and an older version of the NVIDIA driver, but I never had problems with the newer versions on other systems.

Next step: Google.

I found several reports of the same problem, and the “solution” (more like a work-around) was adding the “nopat” parameter to the kernel.
I checked the configuration of the kernel used by Slackware 13.1 (/boot/config) against the configuration used to build the kernel that came with the Debian spin-off and they were different indeed:

in Slackware it is:

CONFIG_X86_PAT=y

While the other has:

# CONFIG_X86_PAT is not set

I added the “nopat” parameter in /etc/lilo.conf:

...
append=" vt.default_utf8=0 nopat"
...

After running lilo and rebooting, the resolution went to 1600×900 without problems!

Now it’s just a lot of irony that I have to set “nopat” to use Slackware, but I hope he forgives me until I compile my own kernel for this box

On most computers running Linux he’ll show up while the kernel is starting up the main services, once for every processor in your system. This little picture in compiled into the kernel and, if you have the sources on your system (like on almost all Slackware installations), you can find him at /usr/src/linux/drivers/video/logo in his various forms (black & white, color, with several architecture-logos, etc.)
The most well-known version is in the logo_linux_clut224.ppm file:

Who likes to use the latest version of the kernel, will have noticed that as of 2.6.29, Tux has been replaced by… Tuz:

Tuz is a little Tasmanian Devil trying to disguise as a penguin

Linus Torvalds had already announced this chance in his blog and as most understood, this is a temporary change, only in the 2.6.29.x kernels.

But for those who can’t wait and really do not like Tuz, it is possible to compile your own kernel with Tux on your screen again.

First you’ll have to get hold of the original logo_linux_clut224.ppm with the image from Tux. Get it from a system still running the 2.6.28.x kernel or older, or find it on the internet. Save this file in /usr/src/linux/drivers/video/logo/ and then follow these standard steps to compile your kernel:

• # cd /usr/src/linux
• # make mrproper
• Copy the configuration file of your current kernel (usually in /boot) as .config here
• # make menuconfig
• In the configuration menu, choose “General setup” and change the “Local version” to something like “-tux”, so that you can recognize your custom kernel later. Exit the menu saving your change.
• # make (this will take a while, depending on your processing power…)
• # make modules_install
• # cp arch/i386/boot/bzImage /boot/vmlinuz-tux
• # cp System.map /boot/System.map-tux
• # cp .config /boot/config-tux
• If you used an initrd with your normal kernel, you’ll need to create one for this custom kernel as well
• Add your new kernel to your lilo.conf, run lilo and reboot!

If you feel like it you can also experiment with other pictures…