Created attachment 116045 [details]
/var/log/dmesg

Created attachment 116046 [details]
Output from lspci

[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.

Finally able to test: The problem is still there with the 2.6.12-1.1398_FC4 kernel.

I have the same problem with a TravelMate Acer 4601WLMI

I make a test with normal kernel 2.6.12-1.1398_FC4 and the new 2.6.12.5, and in
both cases i have not had some result.

The computer comes sold with windows xp, and into the three hardware i see that
the cpu have a "local acpi uniprocessor support"

I compile the kernel with and without this option and i bootstrap without any
problem, also when i compile the 
<< IO-APIC support on uniprocessors  >>
 
Processor type and features  --->  
[*] Local APIC support on uniprocessors    
[*]   IO-APIC support on uniprocessors 

the system dont start, freeze after grub selection.

The system seems to work perfectly even if the tools of the kde they do not find
the battery

I think that the problem are in the state of the battery, because the system
dont read the status

If i cat the file :

/proc/acpi/battery/BAT1/info i see :

present:                 yes
design capacity:         4400 mAh
last full capacity:      4400 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 300 mAh
design capacity low:     132 mAh
capacity granularity 1:  32 mAh
capacity granularity 2:  32 mAh
model number:            ZL01
serial number:           208
battery type:            LION
OEM info:                SANYO

but if i try to read the state with the file :

/proc/acpi/battery/BAT1/state 

i have this error :

present:                 yes
ERROR: Unable to read battery status

Howerwhere

i add the .config file of the kernel

the dmesg and messages log with the 2 bootstrap (with the Local APIC support on
uniprocessors and without)

file :

dmesg and messages are with the kernel without the Local APIC support
dmesg_lasu and messages_lasu are with the kernel with the Local APIC support

bye

Thank You



ps2 My error :

Aug 24 16:46:58 gdrbook kernel:     ACPI-0352: *** Error: Looking up [Z00C] in
namespace, AE_NOT_FOUND
Aug 24 16:46:58 gdrbook kernel: search_node c14781e0 start_node c14781e0
return_node 00000000
Aug 24 16:46:58 gdrbook kernel:     ACPI-1138: *** Error: Method execution
failed [\_SB_.BAT1._BST] (Node c1478fc0), AE_NOT_FOUND



(In reply to comment #4)
> Finally able to test: The problem is still there with the 2.6.12-1.1398_FC4
kernel.

Created attachment 118062 [details]
dmesg without without the Local APIC support

Created attachment 118064 [details]
dmesg with the Local APIC support

Created attachment 118065 [details]
messages without the Local APIC support

Created attachment 118066 [details]
messages with the Local APIC support

Created attachment 118067 [details]
kernel configuration

Hi everybody

I have localized the nature of the problem

The problem resides in the control acpi of the management of the batteries,
exactly in the management of the DSDT.

From  http://acpi.sourceforge.net/dsdt/index.php

DSDT is an acronym for Differentiated System Description Table. This table
contains the Differentiated Definition Block, which supplies the information and
configuration information about the base system. It is always inserted into the
ACPI Namespace by the OS at boot time. Unfortunately, many hardware vendors and
OEMs are not capable of supplying fully functional tables (not even the members
of the ACPI SIG).

In various cases the dsdt they are realized using a compiler microsoft, which
during the compilation it allows one various management of the bug.

The problem is resolved inserting one corrected dsdt in the system (passed from
the initrd or kernel)

There are two possibility, that is by means of the download of a dsdt corrected
from repository placed on http://acpi.sourceforge.net/dsdt/index.php, or
realizing a new total dsdt

In order to construct one correct dsdt, while verified with that compiler has
been realized yours 

dmesg |grep DSDT

if is :

ACPI: DSDT (v001 INTEL  ALVISO   0x06040000 MSFT 0x0100000e) @ 0x00000000

is a microsoft compiler (MSFT)

In any case

download the intel ASL Compiler from :

http://www.intel.com/technology/IAPC/acpi/downloads.htm

decompress source file and  

cd cacpica-unix-20050902
cd compiler
./config
make


realized an image of yours dsdt

cat /proc/acpi/dsdt > DSDT

decompile this file 

./iasl -d DSDT

you have now another file ---- >  DSDT.dsl

recompile with 

./iasl -tc DSDT.dsl

Probably there will be various errors that go corrected

I attach my log for examples

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20050902 [Sep 10 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0

DSDT.dsl   451:                     Store (\PPMF, CFGD)
Error    1061 -                Object does not exist ^  (CFGD)

DSDT.dsl   470:                     And (CFGD, 0xFFFFFF3F, CFGD)
Error    1061 -       Object does not exist ^  (CFGD)

DSDT.dsl   470:                     And (CFGD, 0xFFFFFF3F, CFGD)
Error    1061 -                         Object does not exist ^  (CFGD)

DSDT.dsl   583:             If (LEqual (And (PDC0, 0x0A), 0x0A))
Error    1061 -           Object does not exist ^  (PDC0)

DSDT.dsl   588:             If (LEqual (And (PDC1, 0x0A), 0x0A))
Error    1065 -                                 ^ Object not accessible from
this scope (PDC1)

DSDT.dsl  1917:                     Method (DRUL, 1, NotSerialized)
Warning  2085 -                                ^ Not all control paths return a
value (DRUL)

DSDT.dsl  2564:                         Method (_DCK, 1, NotSerialized)
Warning  2085 -                                    ^ Not all control paths
return a value (_DCK)

DSDT.dsl  2564:                         Method (_DCK, 1, NotSerialized)
Warning  2078 -                                    ^ Reserved method must return
a value (_DCK)

DSDT.dsl  2616:                         Store (CFGD, \PPMF)
Error    1061 -             Object does not exist ^  (CFGD)

DSDT.dsl  2620:                             And (CFGD, 0xFFFFFF3F, CFGD)
Error    1061 -               Object does not exist ^  (CFGD)

DSDT.dsl  2620:                             And (CFGD, 0xFFFFFF3F, CFGD)
Error    1061 -                                 Object does not exist ^  (CFGD)

DSDT.dsl  2629:                             Store (\PPMF, CFGD)
Error    1061 -                        Object does not exist ^  (CFGD)

DSDT.dsl  6362:                 Z00C,
Error    1061 -                    ^ Object does not exist (Z00C)

DSDT.dsl  6363:                 Z00C,
Error    1061 -                    ^ Object does not exist (Z00C)

DSDT.dsl  6619:                 Z00C,
Error    1061 -                    ^ Object does not exist (Z00C)

DSDT.dsl  6620:                 Z00C,
Error    1061 -                    ^ Object does not exist (Z00C)

ASL Input:  DSDT.dsl - 6939 lines, 243895 bytes, 3200 keywords
Compilation complete. 13 Errors, 3 Warnings, 0 Remarks, 1121 Optimizations


There are various howto in internet for the management of the problems :

http://www.cpqlinux.com/acpi-howto.html
http://forums.gentoo.org/viewtopic.php?t=122145

Once obtained a file compilated without errors or warning, is necessary to
prepare the kernel for a patch and a new compile 

Is necessary to prepare the kernel to use external dsdt, by one (or more) patchs

Download the patchs for your  kernel version, we insert the dsdt into the initrd

http://gaugusch.at/kernel.shtml

io ho use 
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch
for the 2.6.12.5 version

if you use a splash boot (like grub), beyond the previous one download this 

http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch

recompile the kernel, and modify the boot loader (grub or lilo)

Modify the initrd with :

echo -n "INITRDDSDT123DSDT123" >> /boot/initrd # magic signature

cat DSDT.aml >> /boot/initrd


reboot the system

Now i have a full system functionally, without any error and the perfect
management of the battery. ( i make a test with kde, and i make the cat of the
file /proc/acpi/battery/BAT1/state 


with external AC
[root@gdrbook ~]# cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          charging
present rate:            63407 mA
remaining capacity:      3093 mAh
present voltage:         2 mV


without external AC
[root@gdrbook ~]# cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1471 mA
remaining capacity:      3106 mAh
present voltage:         1 mV

I dont insert into this solution all operations that i made, but if is necessary
i write another memo.

Bye

Giancarlo del Rossi

Reference :

http://acpi.sourceforge.net/dsdt/index.php
http://www.cpqlinux.com/acpi-howto.html
http://forums.gentoo.org/viewtopic.php?t=122145
http://gaugusch.at/kernel.shtml






 

Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.

The problem is still present on my laptop under kernel-2.6.13-1.1526_FC4.i686

I believe that the best solution would be to add a patch allowing for the
loading of a debugged DSDT from initrd, as proposed earlier for this bug.

2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

The kernel still complains every 30 seconds at 2.6.14-1.1637_FC4 too.

This is really a BIOS bug; however, since many vendors (particularly Acer) seem
incapable of supplying a correct DSDT with their BIOS I'd like to propose this
bug be made into an RFE to add the acpi-dsdt-initrd patch mentioned above (from
http://gaugusch.at/kernel.shtml) to the Fedora kernel in order to support
loading a DSDT from the initramfs.  Several other distributions including SuSE
and Ubuntu already include this functionality.

Of course mkinitrd will also have to be extended to support adding a DSDT to the
image, but the kernel patch is the urgent part as the userspace stuff is easier
to hack.

Here's a useful HOWTO that requires no kernel patching, only a rebuild of the
kernel src.rpm: http://www.aalbiol.upv.es/ACER.html
Basically it requires a slight modification of the default config file(s):
* Edit config and change
CONFIG_STANDALONE=n
CONFIG_PREVENT_FIRMWARE_BUILD=n
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="/lib/firmware/DSDT.hex"
That's it. I've tested it and it works like charm.
I wonder why this functionality isn't enabled in Fedora kernels. If it were,
placing a new DSDT in /lib/firmware would be all you'd need to do to fix this.

If this is already in the kernel sources it is hard to understand why this
feature can not be enabled. It is clearly useful for at least some people and
will not harm those not using this facility.

it's not in the kernel sources, and the upstream maintainer has no intention of
including it.  For the same reason, it won't appear in the Fedora kernel.

What isn't? All we need to do is change some CONFIG_*'s. If you want patching,
an alternative solution is to load the DSDT from initrd (requires patch to
kernel and mkinitrd): http://people.redhat.com/linville/kernels/dsdt/

We've fixed the "invald name in a package" for ACPICA 20051216:


Implemented optional support to allow unresolved names within ASL Package 
objects. A null object is inserted in the package when a named reference 
cannot be located in the current namespace. Enabled via the interpreter slack 
flag, this should eliminate AE_NOT_FOUND exceptions seen on machines that 
contain such code.

Dominik, that config option puts your DSDT into the kernel at compile time.  You
need to recompile after putting the DSDT file in /lib/firmware and you end up
with a kernel which only runs on that specific machine - this is clearly not
something which Red Hat can include in their kernel.  As it happens, the patch
which I mentioned in comment 16 is pretty simple to apply (two lines added to
the spec file and one line added to the config file) and it's already in use by
several other major distributions.

Dave, if you are fed up of explaining why this patch isn't going to be included
then that should tell you how widespread the desire for its inclusion is.  I can
sort of see your point, but you are basically telling all Acer laptop owners
(and several other brands) that they can't run Fedora on their laptops if they
don't know how to patch the kernel (or don't want to do so every time an errata
comes out).

If it's not going in then this bug might as well get closed WONTFIX (or UPSTREAM
as bug 169014 was).

please read comment 21.

The acpi developers implemented a workaround in the parser.  (And I'll include
that fix in the next update).

Every time that "I need to patch my DSDT" has come up, it's been a case where
the parser needed fixing.

Regardless of if the DSDT has errors, the fact that it works under other OS's is
a good sign that something is amiss.  If other interpretors can make sense of
the garbage people put in DSDTs, there's no reason the Linux one can't be
equally flexable.

I'm not fed up of explaining why we won't include it. I'm fed up of people who
refuse to understand why it's the wrong answer.  The fact that 'other distros do
it' is utterly irrelevant. If they want to put themselves in a position where
they get to debug crap dsdt's created by users who don't know what they're
doing, more power to them, but that's not something I have time for in Fedora.

Ian, thanks for the clue, I somehow missed it. Dave, sorry for biting your head
off. If you say it'll be fixed in next release, then I'm quite content. Thanks.

Re: DSDT patch
Dave has it right.  Linux distros should not support
systems that are running modified vendor firmware.
If a developer needs to run modified firmware, then
they can build a kernel to do so, and by definition
it is not supported.  This is a feature.
I can't explain SuSE's reasoning for shipping
the initrd patch -- I consider it a SuSE bug.

Re: trying out the fix for this issue
ACPICA 20051216 is included in the latest ACPI patch.
You can run it in the latest -mm patch or patch 2.6.15 directly with this:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.15/

This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

This problem is still present in 2.6.15-1.1830_FC4

[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.

This particular problem is fixed in FC5, at least all the noise has gone on my
laptop.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Per, thanks for testing.  
Marking this bugzilla resolved according to comment #29.