linux kernel

2.6.25 - the next big problem on my todo list

Alexander Griesser — 2008-04-17T14:33:39+02:00

Today I downloaded 2.6.25 and installed it on my desktop system for testing purposes. Nearly _ALL_ third party kernel modules fail to build, including the Matrox Parhelia driver (mtx.ko), some VMware modules, etc.
The only module that works out of the box is Cisco's cisco_ipsec.ko (surprise, surprise...).

With 2.6.25, some symbols got unexported because they're unused inside the kernel, like "init_mm" and "cpu_callout_map".
cpu_callout_map may be fixed easily in mtx.ko, init_mm fixes seem to be much more difficult.
For the time being, I now run a somewhat crippled version of mtx.ko on my system (no hardware acceleration), but I at least got it to load by now, so expect any usable results for all main third-party modules in the next few days.

Why do I always have to edit kernel sourcecode?

Alexander Griesser — 2006-12-12T01:34:15+02:00

My graphics card driver doesn't work at it should, Cisco's VPN Client isn't uptodate, VMware Server and Workstation's kernel modules need updates on a regularly basis to compile with the newest linux kernel sources and today I tried to mount a squashfs volume on my system just to find out, that I didn't have squashfs support compiled into my kernel.

Well, no problem with that, gonna have to download, compile and use it, right?

Nope. I once again had to look into the Changelog from 2.6.18 to 2.6.19 because "inode.i_blksize" has been removed. Well, not a really big deal after all, needed to delete three lines of code in the now squashfs'ed kernel (doesn't seem to matter after all, inode.i_blksize didn't have any effect obviously).

But, you guys out there developing software, drivers, etc. for Linux: why can't you be up-to-date?? 2.6.19 isn't out for just about three minutes, it has been officially release two weeks ago! I don't want to download outdated or incompatible software for current kernel releases!

Maybe, at the moment I'm too frustrated about that all, but I simply wanted to modify a file inside of this squashfs for a customer and estimated the amount of work needed to an hour - well, now (including recompiling the kernel and getting it to compile with 2.6.19) it has been more than one hour and I doubt that my customer is willing to pay for the extra-time...

Update: also the return value of "kmem_cache_destroy" has changed. Now it really seems to compile, but who knows...

Update in the framebuffer logo section

Alexander Griesser — 2006-04-03T15:25:16+02:00

Today I had some time and installed the new shiny 2.6.16.1 on my notebook and while I was experimenting with my kernel configuration options I stumbled accross the framebuffer logo configuration. I remembered, that I once wrote a small patch to hack my logo in there and tried to apply, but of course, it didn't work anymore (it was designed for 2.6.0-test9 or something else very old...).

So, now there's an update available that should work with all recent kernel versions and the link below the banner of this site has also been updated.
This diff is intended to give you an impression about how to inject your own image into the boot process, but you may also use mine if you want ;)

Downloads:

tuxx-home.at-fblogo.diff (for recent 2.6.x kernel versions)

Getting Smart Battery System (SBS) on an Acer Travelmate 4000 Series Laptop to work with Linux

Alexander Griesser — 2005-03-04T08:50:23+02:00

Yesterday I found an interesting sourceforge-project (sbs-linux [EN]) that deals with supporting the Smart Battery System (SBS) found in some laptops.
As I have some Acer Travelmate 4001LCi laptops at work as platform for my thinclient installation, I always wanted to know the state of my battery. All other laptops work fine with my xbattbar modification, but this model doesn't.

To keep it short: It works now.
Here are the steps one needs to go to get this working:

Download the latest sbs-cm tgz-archive from http://sourceforge.net/projects/sbs-linux
Download the Intel iasl compiler from http://developer.intel.com/technology/iapc/acpi/downloads.htm
To compile this compiler you need "bison" and "flex" installed (Note for Debian users: you need the "flex-old" package instead of "flex", otherwise the compilation doesn't succeed).
```
vi-dsdt:~# tar xfz acpica-unix-20050211.tar.gz
vi-dsdt:~# cd acpica-unix-20050211/compiler
vi-dsdt:~/acpica-unix-20050211/compiler# make
```
If everything is fine, you should have a binary file called "iasl" in this directory. Copy it anywhere to your $PATH or remind where it's located.
Extract the current DSDT from your running kernel
```
vi-dsdt:~# cp /proc/acpi/dsdt dsdt.dat
```

Decompile dsdt.dat with iasl

vi-dsdt:~# iasl -d dsdt.dat

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20050211 [Mar  3 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0

Loading Acpi table from file dsdt.dat
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
...........................................................................
...........................................................................
...........................................................................
...........................................................................
Parsing completed
Disassembly completed, written to "dsdt.dsl"
vi-dsdt:~#

Now you should get a file called "dsdt.dsl" in your CWD.

Patch dsdt.dsl with the patches from sbs-cm (verify, that all .asl files and the diff file of your choice is in the same directory as dsdt.dsl)

vi-dsdt:~# ls
Acer4xxx-DSDT.aml        dsdt.dat  iasl           sbs-cm-2b.asl  tc
acer-tm4xxx-sbs-cm.diff  dsdt.dsl  sbs-cm-1b.asl  smbus-cm.asl
vi-dsdt:~# patch

Compile the modified dsdt.dsl with iasl

vi-dsdt:~# iasl dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20050211 [Mar  3 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0

dsdt.dsl   245:     Method (_WAK, 1, NotSerialized)
Warning  2026 -                ^ Reserved method must return a value (_WAK)

dsdt.dsl  4404:                         Method (_STA, 0, NotSerialized)
Warning  2019 -                                    ^ Not all control paths return a value (_STA)

dsdt.dsl  4404:                         Method (_STA, 0, NotSerialized)
Warning  2026 -                                    ^ Reserved method must return a value (_STA)

smbus-cm.asl    84:         Method (_SBI, 0, NotSerialized)
Warning  2033 -  Unknown reserved name ^  (_SBI)

smbus-cm.asl   144:         Method (_SBR, 3, NotSerialized)
Warning  2033 -  Unknown reserved name ^  (_SBR)

smbus-cm.asl   234:         Method (_SBW, 5, NotSerialized)
Warning  2033 -  Unknown reserved name ^  (_SBW)

smbus-cm.asl   311:         Method (_SBA, 0, NotSerialized)
Warning  2033 -  Unknown reserved name ^  (_SBA)

ASL Input:  dsdt.dsl - 4939 lines, 232406 bytes, 2907 keywords
AML Output: DSDT.aml - 24793 bytes 707 named objects 2200 executable opcodes

Compilation complete. 0 Errors, 7 Warnings, 0 Remarks, 779 Optimizations
vi-dsdt:~#

As you can see, there are several warnings which means, that the patch provided by sbs-cm is not fully applicable to the DSDT of this laptop. So I corrected some of these warnings by hand for my DSDT. If your warnings are similar to mine, you may use my acer-tm4001LCi-sbs-cm.diff instead of the acer-tm4xxx-sbs-cm.diff provided by the sbs-cm package.
With this patch, all warnings (except for the 2033 warnings) are cleaned. If you have any idea of how to get rid of the last four messages, please send me an e-mail.

After completion you should have a "DSDT.aml" file in your CWD. Now you have to add this DSDT to your kernel by either compiling it into your kernel or by using an initrd. I decided the initrd-method, because I already have an initrd for bootsplash and so I only had to append the modified DSDT to my initrd.
```
vi-dsdt:~# echo -n "INITRDDSDT123DSDT123" >>/boot/initrd.splash
vi-dsdt:~# cat DSDT.aml >>/boot/initrd.splash
vi-dsdt:~#
```
The "-n" is mandatory in this place, unlike mentioned in other documentations! If you omit the "-n" your DSDT will not be found at boot-time.
Adding DSDT in intrd support to your kernel
Apply the apropriate patch from http://gaugusch.at/kernel.shtml to your kernel source and enable the new option CONFIG_ACPI_CUSTOM_DSDT_INITRD at the ACPI options. (local copy of the patch for 2.6.9 to 2.6.11). As mentioned on another webresource, you should also apply acpi-ec-nospinlock-2.6.10.diff to prevent your kernel from going crazy when polling ACPI battery state every few seconds.
Recompile your kernel, install it and reboot.

If everything worked fine, you should get a message like this one in your dmesg log:

vi-dsdt:~# dmesg | grep Looking
ACPI: Looking for DSDT in initrd... found (at offset 0x32f14).
vi-dsdt:~#

Additional Links with detailed information about this topic:

Getting bootsplash to work with the intel 815 framebuffer (i810fb)

Alexander Griesser — 2005-02-23T13:09:46+02:00

This was again one of those tasks, you don't want to have assigned to you. I had to install my thinclient-installation on a messy old Compaq Deskpro EN with an Intel 815 Chipset. As my thinclient-installation uses bootsplash [EN] to show nice graphics while booting, I booted this machine after restoring the tc-image on it and waited for the bootsplash to no avail.
The reason, why bootsplash didn't show up was on the one hand the missing framebuffer support and on the other hand, the missing framebuffer support (no, that's semantically correct!).

My kernel lacked support for the i810fb (CONFIG_FB_I810=y, CONFIG_FB_I810_GTF=y) and bootsplash still lacks support for any other framebuffer driver than the vesafb. So you have to patch the bootsplash-code of your bootsplash-enabled kernel.

You also have to edit your bootloaders configuration file so your newly compiled kernel will get the right parameters for the i810fb driver. I'd recommend reserving about 8MiB of system memory for the i810fb device, otherwise you may run into errors when switching bootsplash images (2MiB is far to less, 4MiB is on the limit (3,8MiB needed by my bootsplash images)). The append-line for LILO could look like this (1024x768, 16bit, 8MiB RAM):

append="video=i810fb:vram:8,xres:1024,yres:768,bpp:16,hsync1:30,hsync2:55,vsync1:50,vsync2:60"

I had to use 16 bits of color depth because with 8bpp bootsplash doesn't work with i810fb and the upper limit of 60Hz for vsync2 was necessary because of my TFT screen (so if you use a CRT you may increase this value to whatever your monitor is capable of). Don't forget to remove the "vga=791" option in bootloader's configuration file because with the video= parameter, this parameter is obsolete and causes user interaction at boot time because of an invalid VGA-mode passed to your kernel.

Speedstepping Patch for Pentium M 715 (Dothan)

Alexander Griesser — 2005-01-07T23:06:34+02:00

Today I found out, that my newest toy@work (an Acer Travelmate 4001LCi) is the biggest pile of crap I ever had to work with. But at the end I'll be the winner, I promise. Like all notebooks from Acer, they don't adhere to standards. That starts with their software radio kill switches and ends up in crippled BIOS implementations. Getting Linux to work on such a notebook - even as thinclient, as I have to - is bugging me...

Never think of buying this model if you want to setup Linux on it.

The ACPI implementation is broken - ac_adapter and battery directories in /proc are empty
You _HAVE TO_ make the first boot partition active otherwise you can't boot from it
You are only allowed to boot from hda1
and many other things...

Never think of buying this model if you use 10 fingers while typing.

The keyboard is curved which drives me crazy everytime anew
There are seperate keys for the dollar and euro currencies that are - you guessed it, did you? - located exactly next to the ctrl-key and because of its groovy curvy shape you hit this useless key more often than anything else
Did I mention the curvy shape?

Of course, one can get used to that but do _I_ have to? No, I don't. Fortunately this notebooks are for my users out there, not for me...

I want to post one link here, because I did google for it quite a while: The patch for getting speedstep functionality on the Dothan CPU of this notebook. Here it is. Now it's 23:04 and I'm still at work struggling with this notebook... And with ZenWorks Imaging too, but that's another story.

Woozy Numbat on my notebook, part 1

Alexander Griesser — 2005-01-06T00:26:38+02:00

I ran into a problem while trying to upgrade to Linux 2.6.10 on my notebook (ASUS M2400N). ALSA didn't find any soundcards during boot, although it should (2.6.9 did).

0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)

After searching through the kernel source and trying various other things, including building the driver as module, loading with special parameters, forced loading, many ugly hacks...
Needless to say, none of my approaches lead to a working soundcard. After a while I recognized that with 2.6.10, my parport device got an IRQ assigned to it, IRQ 7. My soundcard also wants to occupy this IRQ but that shouldn't be the problem, I thought, because in times, where we have IRQ sharing and request_irq's SA_SHIRQ parameter, two devices per IRQ could easily be done.
Anyhow, I rebooted to view the IRQ-table in 2.6.9 but I didn't see the parport device listed there. This was the time, when I knew, that I know absolutely not enough about the parport implementation in the linux kernel. After reading the parport documentation, everything was much clearer to me.
parport doesn't need an interrupt, to work properly. 2.6.10 was the first kernel, that assigned one to it - maybe because of the new PNP ACPI feature?
Appending one additional parameter to the kernel's cmdline solved the problem by restoring the old behaviour: not assigning an interrupt to the parport driver.

LILO: 2.6.10 parport=0x378,-1

The -1 means, that no IRQ should be assigned to the parport driver. Now everything is fine:

           CPU0
  0:    3864839          XT-PIC  timer
  1:      11674          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  4:          1          XT-PIC  ehci_hcd
  5:     120838          XT-PIC  yenta, uhci_hcd, uhci_hcd, uhci_hcd, eth0, eth1
  7:          0          XT-PIC  snd-intel8x0
  9:       7641          XT-PIC  acpi
 12:      95168          XT-PIC  i8042
 14:      24773          XT-PIC  ide0
 15:         13          XT-PIC  ide1
NMI:          0
ERR:          0

There are also other issues with 2.6.10 on my system, but that's another story, maybe in another entry...

QLA2300 FC HBA Driver and Linux Kernel 2.6.9

Alexander Griesser — 2004-12-22T11:44:14+02:00

Yesterday, I tried to upgrade one of my servers from Linux Kernel 2.4.26 to Kernel 2.6.9. The server has two Qlogic QLA2310F FC HBA PCI adapters [EN] plugged in that are connected to two EMC CLARiiON CX600 [EN] SANs.
One has two opportunities to manage the appropriated LUNs:

Establish a software raid to mirror the duplicated LUNs manually
Let the FC HBAs manage failover situations and MPIO (multipath I/O)

Of course, using the second way is much more beautiful but that requires specific driver support for MPIO. With 2.4.26, there's no Qlogic FC support at all shipped with the kernel. So I had to use the qlogic driver that is certified for use with EMC SANs. 2.6.9 has qlogic support builtin, but since 2.6.1, the MPIO and Failover support was silently removed and also other changes have been made to this driver, concerning timeouts etc.

Rebooting the machine lead up to having no disks at all. Building the qla2xxx driver as kernel module resolved that problem if you're willing to load the module two times. With the new driver, it takes longer to set up the FC loop and therefore the initalization of the HBAs fail. Reloading the driver fixes the problem. But then I ran into the next problem. The FC Adapters showed me all LUNs associated to my WWNs instead of displaying only half the devices (you know, MPIO). So I googled quite a while to find out, that the MPIO support has been removed. On the Qlogic website I mentioned above are also not supported drivers available for download, e.g. from IBM, Hitachi, EMC,... I gave the IBM driver a try (v8.00.00 [TGZ]), because it has support for driver-side MPIO. Extracting the tar.gz-ball and replacing the qla2xxx Directory in my kernel source tree ended up in many compiler-errors. Naivley as I am, I tried to fix the errors with the help of $MY_FAVOURITE_VIM^H^H^HEDITOR. That seemed to work, but then other compiler- errors showed up and so I stopped coding due to lack of time.

So what to do now? Numerous of incomplete non-working drivers on my hard disk and also numerous of users who wanted to continue working...
Being in total forlornness, I ftp'ed to download.qlogic.com and tried a recursive file search (ls */*qla2xxx*) that finally saved my day (or night, whatever...). In a directory not accessible from the webpage I found the 8.00.01 version [TGZ] of the driver which worked flawlessly, even with MPIO.

tuxx@vi-edv003:~$ ftp download.qlogic.com
[...]
ftp> cd drivers
250 CWD command successful.
ftp> ls */*qla2xxx*
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
-rwxrwxrwx   1 webmaster cod       1016041 Nov 11 23:51 24092/qla2xxx-v8.00.00-dist.tgz
-rwxrwxrwx   1 webmaster cod       1016041 Nov 12 22:30 24132/qla2xxx-v8.00.00-dist.tgz
-rwxrwxrwx   1 webmaster cod       1016041 Dec 13 22:19 24911/qla2xxx-v8.00.00-dist.tgz
-rwxrwxrwx   1 webmaster cod       1057279 Dec 14 19:23 24998/qla2xxx-v8.00.01-dist.tgz
-rwxrwxrwx   1 webmaster cod       1057279 Dec 14 19:28 25000/qla2xxx-v8.00.01-dist.tgz
226 Transfer complete.
ftp>

If for any reason this driver will be removed from their site and you - the reader - are not able to find it anymore, I'll keep it in cool place