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.

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...