Bug 6208

Created attachment 7555 [details]
lspci

lspci

Created attachment 7556 [details]
lsusb

with mouse plugged-in

Created attachment 7557 [details]
dmesg

try boot option: nolapic

with nolapic boot stops on:
utxface-0149 [02] enable_subsystem [Init] Going into ACPI mode.

Did you try Windows? Or is there any useful BIOS option?
IIRC, before ACPI mode, Linux doesn't touch any USB/PCI staffes.

Yes i have corectly working Windows. BIOS does not have any options for usb
manipulations. My linux  is stoping in ACPI mode. Last seen message is "Going
into ACPI mode". I do not know eny technical stuff about ACPI but i do know that
in my case it is stoping at  "case ACPI_SYS_MODE_ACPI:" in hwacpi.c. I know it
becouse i made some simple code modyfications and i used boot option
acpi_dbg_level=0xffffffff. If ther is eny way to display more specific
informations about what is happening in my case plese tell me i will do it and i
will report the results. Bios shows information: ACPI 1.0 enabled...

hi Squade,

I and three other people encountered on http://forum.hardware.fr/ have the same
problem on the Asus A6KM-Q007H laptop.

Moreover, the sound does not work. This problem is very unpleasant !

We have tried to correct the buggy dsdt (i suppose you're the same Squade who've
submitted it's dsdt on acpi.sourceforge.net/), with success with the iasl
compiler, but with no more results on the sound and the mouse.

What can we do to help the kernel's developpers ?

Hello Niko380.

I know that if you remove all that "zero"s from _PSS section it can correct this
one error but linux can handle that error in dsdt. This three warnings ... one
of them is stupid because there are two "return" one after one and it sems it
returns same value ... about other two warnigs i do not know what alternative
states are posible and i can't fix it in corect way... because ther have to be
some returned values... or not ... i don't know. Personaly i think that problem
whit mouse is comming form bios because it detects is and PROBABLY then bios
makes some changes that are not corect with ACPI specyfications ... Test: turn
off notebook, plug-out   usb mouse, turn notebook on, wait while lilo shows
menu, plug-in usb mouse, start linux ..... and every thing works fine, but when
mouse is plugged-in all the time ... linux doesn't boot

You've described exactly the way i boot my notebook : I plug in my mouse while
linux is already booting, not before the lilo prompt level...

What about the sound on your laptop ? Is it working fine ?
And what is your notebook reference ? Is it A6KM-Q007H ? 
Some people who've bought this notebook before December don't seems to have any
problem. The problems arrived later, strange isn't it ? 

My notebook is A6KM-Q017. 
About "december" what versione of BIOS they have?
I don't have working sound and i also notice that under windows 7012/7018
oryginal drivers does not work too.

If your sound don't work anymore, don't you think it would be better to notice 
that problem in this Kernel Bug, or in an other one ?

My impression is that this problem and the mouse one are probably linked, maybe 
a bad integration of the chipset SIS ???

It is interressant to notice that the Bios version on the fully working Asus 
A6Km-Q007H is the 202 one. 
It is the case of the person on this site : (in french sorry) 
http://multipotes.free.fr/article.php3?id_article=154

His notebook presents some light differences with mine (Network Controller and 
Cardbus Bridge, see the lspci ...) and the bios version.

Maybe a downgrade of the bios should be an issue, but I will try this solution 
when all the others would have been watched.

I have the same problem with my A6Km, and in fact got so annoyed by it that I
e-mailed ASUS technical support. I'll let you know if they answer. :)

And if it's any use, I did some testing today and found out that even FreeBSD
(tested 6.1 beta) has this USB mouse lock up problem too. Pretty much the same
thing happens - ACPI system initializes and hangs on acpi0: [MPSAFE].

I also did a bit hacking on the DSDT and fixed the three warnings and one error
as best as I could. This fixed the CPU frequency scaling problem (powernow-k8
module) that I was having on Ubuntu Dapper. You can download the DSDT from
acpi.sourceforge.net, but sadly it doesn't fix the mouse problem.

Antti, 
What about the sound problem ? Does it works fully ?
What is your notebook reference ?

Niko380,

Sound is working fine and the controller is recognized as Silicon Integrated
Systems [SiS] Sound Controller (rev a0). It seems the model reference numbers
vary from country to country. My Finnish version of this notebook is labeled as
A6Q00KM  / A6Q49KMUH - with 100 gig hard drive and no bluetooth.

No word from ASUS yet, but I'm still hopefull.

Ok, I did the BIOS downgrade thing from 0208AS to 0202AS and the mouse bug is
gone! Winflash won't let you flash the older revision, but the utility in BIOS
does. Give it a shot - it just might work.

And I also got an answer from ASUS. They said that the BIOS isn't adapted to
fully support Linux and that they're mainly focused to suiting the notebooks to
fit Windows XP. Bah, just so typical... makes me wonder why they even have a
Linux as an OS choice on the technical support form.

Thank you Antti, 
I've done the downgrade of the bios following your recomandations and it's true
that solves the mouse problem !
Unfortunately, the sound is still posing problem ...
I don't know what to do for this ...

ASUS has released a new BIOS version (209AS) for the A6Km. Don't bother
upgrading - at least on my notebook the mouse bug is still there. Also the ACPI
DSDT has the same errors / warnings as version 0208AS. Here's the changelog:

1. Change VBIOS from N03304.007 to N03304.011 tofix the S-video problem.
2. Fix that if there is any USB device connected to the System (Win2K),system
will hang at win2K issue

Well, judging by that second note at least they know about the USB problems.

Modify 

file: /usr/src/linux/drivers/acpi/executer/exregion.c
function: acpi_ex_pci_config_space_handler

acpi_status
acpi_ex_pci_config_space_handler(u32 function,
                                 acpi_physical_address address,
                                 u32 bit_width,
                                 acpi_integer * value,
                                 void *handler_context, void *region_context)
{
        acpi_status status = AE_OK;
        struct acpi_pci_id *pci_id;
        u16 pci_register;

        ACPI_FUNCTION_TRACE("ex_pci_config_space_handler");

        /*
         *  The arguments to acpi_os(Read|Write)pci_configuration are:
         *
         *  pci_segment is the PCI bus segment range 0-31
         *  pci_bus     is the PCI bus number range 0-255
         *  pci_device  is the PCI device number range 0-31
         *  pci_function is the PCI device function number
         *  pci_register is the Config space register range 0-255 bytes
         *
         *  Value - input value for write, output address for read
         *
         */
        pci_id = (struct acpi_pci_id *)region_context;
        pci_register = (u16) (u32) address;

        ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                          "pci_config %d (%d) Seg(%04x) Bus(%04x) Dev(%04x)
Func(%04x) Reg(%04x)\n",
                          function, bit_width, pci_id->segment, pci_id->bus,
                          pci_id->device, pci_id->function, pci_register));

        if ( pci_id->bus != 0 && pci_id->device != 3 ) { // ASUS A6Km usb lockup
        
                switch (function) {
                case ACPI_READ:

                        *value = 0;
                        status = acpi_os_read_pci_configuration(pci_id,
pci_register,
                                                                value, bit_width);
                        break;

                case ACPI_WRITE:

                        status = acpi_os_write_pci_configuration(pci_id,
pci_register,
                                                                 *value, bit_width);
                        break;

                default:

                        status = AE_BAD_PARAMETER;
                        break;
                }
        }

        return_ACPI_STATUS(status);
}

If enybody knows how to check if this function is dealing with this notebook
pleas write it. I think that this functions makes some initialization in pci
area and if it is bus 0 device 3 it can skip it because asus a6km makes it. 
This is kernel 2.6.17-rc3 modyfication.

Created attachment 8006 [details]
SiS Sound Controller on a6km bugfix.

regarding sound, i've had to modifiy the alsa driver in the kernel to make it
work. there's a bug report on the alsa bugtracker, but you'll need an account:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1898 (registration
required).

i'll repost the patch here.

i also have a problem with ACPI. it's quite annyoing and very strange, as i
sometimes could boot my system successfully with the latest bios, but then it
wouldn't work again for some time, until it worked again the other day. the
kernel is looking for a custom dsdt.aml and can't find any, because i didn't
pro vide it! it's still looking for it in the initramfs. 

i've not yet found a substitute dsdt for the 209 bios on acpi.sf.net, but i
hope someone will provide one soon, because i'm not able to decompile my bios
with the iasl and just in case it ever worked, i'd have no idea what to change,
to make it work.

BIG thanks. Now my ASUS A6Km works perfectly fine. No usb mouse problem at boot
time with oryginal bios 209as and oryginal dsdt. Alas snd-intel8x0 works to with
exterlnal amplifier, headphones and ... buid in speakers works too :] 

last modification was incorrect becouse when i put 'noapic' in boot options
usbhid  didn't work. Finaly with this modyfication my linux-2.6.17-rc3-git-5 has
no problems with usb mouse and booting.

file: /usr/src/linux/drivers/acpi/executer/exregion.c
function: acpi_ex_pci_config_space_handler

acpi_status
acpi_ex_pci_config_space_handler(u32 function,
                                 acpi_physical_address address,
                                 u32 bit_width,
                                 acpi_integer * value,
                                 void *handler_context, void *region_context)
{
        acpi_status status = AE_OK;
        struct acpi_pci_id *pci_id;
        u16 pci_register;

        ACPI_FUNCTION_TRACE("ex_pci_config_space_handler");

        /*
         *  The arguments to acpi_os(Read|Write)pci_configuration are:
         *
         *  pci_segment is the PCI bus segment range 0-31
         *  pci_bus     is the PCI bus number range 0-255
         *  pci_device  is the PCI device number range 0-31
         *  pci_function is the PCI device function number
         *  pci_register is the Config space register range 0-255 bytes
         *
         *  Value - input value for write, output address for read
         *
         */
        pci_id = (struct acpi_pci_id *)region_context;
        pci_register = (u16) (u32) address;


        ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                          "pci_config %d (%d) Seg(%04x) Bus(%04x) Dev(%04x)
Func(%04x) Reg(%04x)\n",
                          function, bit_width, pci_id->segment, pci_id->bus,
                          pci_id->device, pci_id->function, pci_register));

        if ( pci_id->bus == 0x0000 && pci_id->device == 0x0003 &&
pci_id->function != 0x0001 ) {
                ACPI_DEBUG_PRINT((ACPI_DB_INFO, "SKIP!\n" ));
        }
        else
        {
                switch (function) {
                case ACPI_READ:

                        *value = 0;
                        status = acpi_os_read_pci_configuration(pci_id,
pci_register,
                                                                value, bit_width);
                        break;

                case ACPI_WRITE:

                        status = acpi_os_write_pci_configuration(pci_id,
pci_register,
                                                                 *value, bit_width);
                        break;

                default:

                        status = AE_BAD_PARAMETER;
                        break;
                }
        }
        
        return_ACPI_STATUS(status);
}

This function can work fine olny when pci_id->function is set to 1. Why is that?  

Created attachment 8200 [details]
fixed DSDT for 210as bios - no usb mouse bug.

Can enybody check this dsdt. On my linux it solve this bug without kernel
patch.

Created attachment 8202 [details]
DSDT (210AS) with fixed any usb devices problems at boot time.

squade: your fixed 210AS doesn't work for me (I downloaded it from acpi.sf.net 
site), the kernel crashes before long, when booting.

This notebook is quite a pain in the ass, some people with similar models 
(maybe the same?) get sound working with some kernel versions or patches 
provided by ALSA people, but mine doesn't even repeating the steps that they 
made and using the same versions and patches: I never got USB-mouse-on-init and 
sound to work, even if I tested half a dozen kernel versions (both from Debian 
and vanilla), applied patches, used new 1.0.12-rc1 ALSA code, several BIOS 
versions provided by ASUS, DSDTs from other people, trying to fix the DSDT 
problems myself... and no way, I can't get it to work.

My model is A6KM-Q0012H, with 1GB of DDR and AMD64, no bluetooth. I think that 
some of the people who got rid of these problems had slightly different 
configurations. I'm trying now to get technical "support" (as other person 
says, they refuse to help you with anything but WindowsXP) to provide the old 
202AS BIOS version again from their webpages, because I don't know what else I 
could do now...

The sad part is that I already knew of these problems (I investigated a bit 
before buying it, and stumbled upon this bug report, among others), but since 
people seemed to get it to work, I thought that the problem was already being 
fixed in recent versions, so I decided to buy it anyway. So this is a warning 
for people who might be seeing this and are thinking about buying this 
notebook, or very similar models. It's a pity, because it's a nice piece of 
hardware...

Pleas compile your kernel with full acpi debug support then boot with
acpi_dbg_level=0x1f and send me as much as posible informations about functions
and .c files ( and lines ) at which your kernel stops ( with usb mouse plugged
). About DSDT: i just removed USB1 function from _INIT in USB,USB2 and USB3
devices. 

You can try to remove all _INI methods form USB, USB2 and USB3 in DSDT.

I edited the DSDT removing those _INI method and it's working now, thanks a 
lot :)  Those methods are apparently [1] making comparisons only, not executing 
anything; and as you say there are only 3 instead of 4, so apparently one USB 
is missing... maybe if the mouse is attached to that one, the computer would 
boot fine?

I didn't try your patch of acpi_ex_pci_config_space_handle that you list in one 
comment, so I don't know if the patch would work for me as is; but before 
fixing my DSDT, the kernel also stopped while initializating the devices, 
exactly in the same function. The problem to produce a patch out of this, IMO, 
is that you would have to find a way to identify exactly that system to know 
whether to skip the initialization of that device or not, and since people 
seems to have problems with these series of notebooks depending on concrete 
models or configurations, probably it's difficult to get it right. And anyway, 
I think that applying those kind of hacks to the kernel is not the cleanest 
solution (although maybe it's the norm, I've never put much attention to the 
internals of the kernel).

Anyway, maybe we should make a web page explaining this? There are a few guides 
out there, but often in non-english languages and a bit outdated, and not 
explaining some of these new discoveries. My complaints to the "support" staff 
for the buggy BIOS don't seem to make them react at all...

[1] It's the first time that I see that language, so my opinions about this are 
no more than guesses.

No there is 4 usb ( EUSB, USB, USB2, USB3 ) EUSB is for usb2.0 . This problem
depends on acpi pci configuration. USB, USB2 and SUB3 has the same space in
memory for configuration. Linux kernel initializes one by one every usb entry in
DSDT but in fact it initializes three times the same device. In _INI method
there is USB1 function which makes OR and AND operations in config space and
after this configuration fails... About sound: remembar that you have to unmute
"extarnal..." in alsamixer and patch included in this bug should work. 

So do you have any suggestion about what to do now?  Do you want me to test 
some kernel patch, or the DSDT fix should be enough?

PS: that was the fix for the sound, yep.  I was reading some ALSA docs about 
enabling external amplifier for Dell Inspiron 8600 or so, and worked -- other 
fixes such as enabling Surround or echoing magic numbers to registers (gathered 
from bug reports about the same laptop model) weren't working for me.

 I have notebook Asus A6Kt with latest BIOS version 206AS (a6kt206as). I'm using
kernel linux-2.6.17-rc4 with the same symptoms as in the description. Is the
mentioned patch (#22) eliminate the problem or is there any other settings?

Hey. I can confirm that this bug still exists. My setup:

Distribution: Ubuntu Gutsy Beta (7.10)
Hardware Environment: Asus A6KM-Q025H Notebook
Software Environment: i386 (?)
BIOS version: 300 (Latest from Asus.com, bug confirmed with previous version 210 as well)

If i can do anything to help fixing this, just ask.

Ask asus to fix their stupid BIOS, it's really DESIGNED FOR WINDOWS. See below ASL code, if running OS isn't windows, they will call USB1(), I guess this method will disable USB.

Scope (\_SB.PCI0.USB)
    {
        Method (_INI, 0, NotSerialized)
        {
            /*If (LNot (LEqual (OSFG, 0x08)))
            {
                USB1 ()
            }*/
        }
    }

Name (OSFG, 0x00)
        Name (OS9X, 0x01)
        Name (OS98, 0x02)
        Name (OSME, 0x04)
        Name (OS2K, 0x08)
        Name (OSXP, 0x10)
        Method (MSOS, 0, NotSerialized)
        {
            If (CondRefOf (\_OSI, Local0))
            {
                Store (OSXP, OSFG)
            }
            Else
            {
                If (MCTH (\_OS, "Microsoft Windows"))
                {
                    Store (OS98, OSFG)
                }
                Else
                {
                    If (MCTH (\_OS, "Microsoft WindowsME: Millennium Edition"))
                    {
                        Store (OSME, OSFG)
                    }
                    Else
                    {
                        If (MCTH (\_OS, "Microsoft Windows NT"))
                        {
                            Store (OS2K, OSFG)
                        }
                        Else
                        {
                            Store (OSXP, OSFG)
                        }
                    }
                }
            }

            Return (OSFG)
        }

Hey.

That looks quite interesting, but I'm not entirely sure that is meant as a "Designed for Windows" thing.

Looking at:
                        If (MCTH (\_OS, "Microsoft Windows NT"))
                        {
                            Store (OS2K, OSFG)
                        }

and then:
Name (OS2K, 0x08)

and then:
            /*If (LNot (LEqual (OSFG, 0x08)))
            {
                USB1 ()
            }*/

... it seems like any OS BUT Win2k will trigger USB1(). So Win98 and WinXP will also trigger it, right?

This seems to be related to the following part of the BIOS changelog:
"BIOS Ver.209as
1.Change VBIOS from N03304.007 to N03304.011 tofix the S-video problem.
2.Fix that if there is any USB device connected to the System (Win2K),system will hang at win2K issue"

(http://support.asus.com/download/download.aspx?SLanguage=en-us - Select Notebook, A6000 and A6Km. Then expand the BIOS tree.)

Yes, the default Linux os name is "Microsoft Windows NT".
Please try kernel parameter acpi_os_name="Microsoft Windows" without fixing the dsdt.

Ah, i see. How come it not be "Linux" or "Ubuntu" or something?

I'm new to this stuff. Where exactly do i put that kernel parameter? I tried adding it to the "kernel" line in GRUB, but that changed nothing.

By the way, if i try a "recovery mode boot", the system freezes just after these 2 log messages:

"Setting up standard PCI resources"
"ACPI: EC: GPE=0x19, ports=0x66, 0x62"

Hi, sorry for the delay,

>I tried adding it to the "kernel" line in GRUB, but that changed nothing.
You're right, :). Please try acpi_osi=

Hey.

No problem. Unfortunately, I am not in posession of this laptop anymore. I recently sent it in for repair and expect to get a refund for the laptop (because i already had it repaired twice, so i demanded a refund actually).

Perhaps someone else from this thread can give it a try? I will try this if i get the laptop back, but i doubt i will.

Anyway, we root caused the problem and the test is just used to verify it's a BIOS problem that "Designed for Windows"...
I'll close this bug and mark it as INVALID. Please reopen it if you still have some questions.

If that fix was necessary to support Windows NT, and only affects the OS when it reports itself as "Windows NT", then this isn't really their fault, is it?

I cannot see how it can be ASUS's fault that Ubuntu/Linux reports itself as "Windows NT", when in fact, it is not. That is our fault then. This bug still exists nevertheless, and is not "invalid" at all.

Question is then if Ubuntu/Linux should change to report "Linux" (or something) instead, but i assume that there is a reason we call ourselves "Windows NT"?

In the end though, we still need to solve this problem... Don't we? Perhaps include a check in the installer that checks for this model/BIOS (if that is possible?) and set the name to something else?

(So yea, i propose that this bug is reopened... I do not have access to do that though)

Sorry that comments #35 is wrong.

If (LNot (LEqual (OSFG, 0x08)))
            {
                USB1 ()
            }
This means any OS BUT Windows NT will trigger USB1(). 
And by reading the MSOS method, 
            If (CondRefOf (\_OSI, Local0))
            {
                Store (OSXP, OSFG)
            }
Linux has the _OSI method so we can find that OSFG is set to OSXP.
This can explain why excluding the USB1() function call can solve the problem.

Boot parameter "acpi_osi=" can prevent Linux from creating _OSI method
and then OSFG will be set to OS2K instead, and this should workaround the issue for Linux.

>only affects the OS when it reports itself as "Windows NT",
>then this isn't really their fault, is it?
Problem is that few BIOS is tested under Linux before they are released.
BIOS queries the _OSI/_OS method and execute different code path when needed, but none of them is for Linux..., Linux must pretends itself to be some windows os in order to work... 
But this depends on the BIOS, that's what the kernel parameter acpi_osi and acpi_os_name are designed for.
So do you think it's a Linux bug? :)

Ah, i see.

Is there any work being done in trying to create a new standard allowing for Linux support from the BIOS that wants to, but otherwise allow Linux to "fall back" to pretending to be Windows?

Like, have Linux create a "variable" called _OS_LINUX or something. Then if BIOS supports Linux, it checks that variable first, and we got Linux support. A BIOS without Linux support would then check _OS/_OSI, and Linux will report Windows? Just a thought...

Anyway, back to the problem. Is it possible to fix this by letting Linux check for this laptop, and report itself differently automatically? Or is it possible to fix the "conflict" itself? (It works in XP, why not Linux calling itself XP? What is it that Linux does/does not that causes this problem, and can that be fixed?). So yea, kind of a Linux bug, although i do see it can be hard if the BIOS only supports Windows by default.

But thanks for the info! :).

(In reply to comment #37)
> Hi, sorry for the delay,
> 
> >I tried adding it to the "kernel" line in GRUB, but that changed nothing.
> You're right, :). Please try acpi_osi=
> 

I managed to get a hold of the laptop for a limited time. I just tried adding "acpi_osi=" to the kernel line, and i can confirm that the boot no longer freezes because of connected USB devices! :)

So what do we do now?

(In reply to comment #40)
> In the end though, we still need to solve this problem... Don't we? Perhaps
> include a check in the installer that checks for this model/BIOS (if that is
> possible?) and set the name to something else?

Anyone...?

Do we really just want to drop support for this model (and possibly others from ASUS as well)?

Well, I think I can cook up a dmicheck patch to help this laptop to work in Linux, but it's hard to say if the patch can be merged or not. :(
First, please try the latest BIOS and see if this is fixed.
If no, please attach the dmidecode.

Created attachment 15655 [details]
dmidecode of A6Km from Ubuntu 8.04 B1

I am already running the latest version of the BIOS available (version 300).

I have attached the output of "sudo dmidecode" on Ubuntu 8.04 B1 @ the Asus A6Km booted with "acpi_osi=".

Created attachment 15664 [details]
patch: disable osi for asus a6km

Please apply this patch and boot _without_ "acpi_osi=".

Following the guide at http://howtoforge.com/kernel_compilation_ubuntu - I get the following error while compiling:

...
 CC      drivers/acpi/blacklist.o
drivers/acpi/blacklist.c: In function ‘dmi_disable_osi’:
drivers/acpi/blacklist.c:195: error: implicit declaration of function ‘acpi_osi_setup’
make[3]: *** [drivers/acpi/blacklist.o] Error 1
make[2]: *** [drivers/acpi] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/linux-source-2.6.24'
make: *** [debian/stamp-build-kernel] Error 2

:(

Please try with the latest kernel release, say 2.6.26-rc8. :)

I can't find any 2.6.26 kernels. The latest i could find was patch-2.6.25-rc8 at http://www.eu.kernel.org/pub/linux/kernel/v2.6/testing/

If that is the one you are referring to, could you tell me which kernel I need to apply the patch to?

oops. sorry, I mean 2.6.25-rc8. :)

hey guys i have an asus a6km, i've red all the discussion
and i think we HAVE to fix this one (a downgrade is a
"Windows" solution).

So i'll soon that patch

I tried applying patch-2.6.25-rc8 to linux-source-2.6.24 without luck. First file to patch (.gitignore) was not found. Even if i strip out that file from the patch, i get loads of Hunk errors.

What kernel am i supposed to apply rc8 to? According to http://kernel.org/patchtypes/pre.html 2.6.24 should be the right one.

(In reply to comment #54)
> I tried applying patch-2.6.25-rc8 to linux-source-2.6.24 without luck.
that's weird. it should work.
are you sure it's a clean 2.6.24? there maybe some conflicts if you have applied other patches.

please download the 2.6.24 source code at http://www.kernel.org/pub/linux/kernel/v2.6/
then
cd linux-2.6.24
run "patch -p1 --dry-run < patch-2.6.25-rc8" to see if there are any conflicts.
if no, run "patch -p1 < patch-2.6.25-rc8"
patch -p1 < the patch in comment #48

I ended up removing all kernel source and header packages via Synaptic and manually wiping the rest from /usr/src/ and starting all over. Surely enough, that helped.

Both patches apply without errors now! By following the guide, I was able to compile the kernel successfully with the same configuration as my current kernel (config-2.6.24-16-generic). I made sure that the new kernel line in GRUB's menu.lst did not contain the "acpi_osi=" argument.

... and it works! Ubuntu now boots with an USB mouse attached without problems :). Good job.

I did, however, notice a new error just after the "loading linux kernel" message (just after selecting the kernel in GRUB, and just before the graphical booting progress bar). It said something like "BIOS bug: MCFG area at ..... not E820-reserved". Should I worry?

i think that the patch is not a solution
but a debug test...so i preceed Zhang Rui
and ask the dmidecode :)

(In reply to comment #56)
> ... and it works! Ubuntu now boots with an USB mouse attached
> without problems :). Good job.
good news. :)

> I did, however, notice a new error just after the "loading linux kernel"
> message (just after selecting the kernel in GRUB, and just before the
> graphical
> booting progress bar). It said something like "BIOS bug: MCFG area at .....
> not
> E820-reserved". Should I worry?
no, that's just a warning message, you can ignore it.

Paweł, Alexander, niko380, Annti, mafm, tiber and Kapitan,
could you please send the dmidecode of your laptop please?

Created attachment 15745 [details]
dmi for a6km q017

Created attachment 15747 [details]
A6KM-Q024H

Kapitan A6KM-Q024H

Created attachment 15748 [details]
dmi for Asus A6Kt

dmi for Asus A6Kt

Created attachment 15760 [details]
dmidecode output for Asus A6KM-Q0012H

dmidecode output for Asus A6KM-Q0012H

any news?

Ditto that. Is there anything else I can do?

Created attachment 16136 [details]
patch: disable osi for A6KM A6KT

This patch should work for all the laptops here.
Please give it a try. :)

Is the kernel to patch the last experimental?

AKA:

2.6.25 + 2.6.26-rc2?

yes