public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Luca Capello <luca-wlebWZzHoyE@public.gmane.org>
To: ML ACPI-devel
	<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Cc: Andre Messerschmidt
	<a.messerschmidt-hi6Y0CQ0nG0@public.gmane.org>,
	Markus Gaugusch <dsdt-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org>
Subject: ASUS M6800N: battery0 not present
Date: Tue, 17 Feb 2004 18:28:36 +0100	[thread overview]
Message-ID: <40324F44.60006@pca.it> (raw)

[-- Attachment #1: Type: text/plain, Size: 13186 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I included a mail from the 'acpi4asus-user' mailing-list, as the problem
is already know and Andre Messerschmidt found a solution (at least to
see the battery IIRC).

- -------- Start Original Message --------
Subject: Re: [Acpi4asus-user] ASUS M6000N - Battery0 not present
Date: Thu, 5 Feb 2004 13:37:01 +0100
From: Andre Messerschmidt <a.messerschmidt-hi6Y0CQ0nG0@public.gmane.org>
To: acpi4asus-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
CC: Ben B. <ben.forum-cmBhpYW9OiY@public.gmane.org>
References: <40221902.6040606-cmBhpYW9OiY@public.gmane.org>

Am Donnerstag, 5. Februar 2004 11:20 schrieb Ben B.:
Hi.

> But I've a big problem to use my laptop without AC-adaptator.
> In fact, the battery0 (physically present) is not show in /proc (or
> elsewhere) just the battery1 (no physically present) is show with "no
> present" tag (it's right).
I had the same problem on my M6800N. After changing the DSDT table I now
have
BAT0 and BAT1 but both are always absent, no matter what I do.
You can download my DSDT table from here
http://www.isis.de/members/~messersch/asus-m6800n.html
Maybe it helps.

> Please can you tell me if it's a bug of ACPI or other think ?
I am not sure if this is a problem of the DSDT table or a bug in ACPI
itself.

best regards
Andre
- -------- End Original Message --------

As I wanted to use Andre's DSDT, I patched my 2.6.2 kernel with the
'ACPI DSDT in initrd' patch from http://gaugusch.at/kernel.shtml. The
latest patch available is against 2.6.1 and it applies with an hunk over
kernel 2.6.2 + ACPI 20040211 (no matter if I patch with the latest ACPI
before or after the 'ACPI DSDT in initrd' patch):
> gismo:/usr/src/linux-2.6.2# patch -p1 <
../kernel/v2.6/03_acpi-dsdt-initrd-patch-v0.4-2.6.1.diff
> patching file drivers/acpi/Kconfig
> patching file drivers/acpi/osl.c
> patching file drivers/acpi/tables/tbget.c
> Hunk #2 succeeded at 287 (offset -1 lines).
> patching file include/linux/initrd.h
> patching file init/initramfs.c

Then, I compiled Andre's DSDT with the latest 'iasl' from Intel:
> gismo:/usr/src/kernel/dsdt/iasl-linux-20030918# ./iasl
messerschmidt_asus_m6800n_dsdt_test.dsl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler / AML Disassembler version 20030918 [Sep 18 2003]
> Copyright (C) 2000 - 2003 Intel Corporation
> Supports ACPI Specification Revision 2.0b
>
> messerschmidt_asus_m6800n_dsdt_test.dsl  3180:                 Scope
(\_SB.PCI0)Warning  2031 -
Internal compiler error ^  (Not using optimized name - did not find node)
>
> ASL Input:  messerschmidt_asus_m6800n_dsdt_test.dsl - 5580 lines,
181689 bytes, 2576 keywords
> AML Output: DSDT.aml - 22419 bytes 772 named objects 1804 executable
opcodes
>
> Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 740 Optimizations
> gismo:/usr/src/kernel/dsdt/iasl-linux-20030918#

I compiled kernel 2.6.2 with the 'ACPI DSDT in initrd' patch and I
prepared my LiLo tu use it: as I don't use any initrd, I copied Andre's
compiled DSDT in /boot/ and I added these lines to /etc/lilo.conf:
> 	image=/boot/vmlinuz-2.6.2-acpi-dsdt-initrd
> 	        label=262-dsdt
> 	        read-only
> 	        initrd=/boot/dsdt-m6842nwh_20040216.01.aml

At reboot, anyway, I can't see any line 'Looking for DSDT in intird',
but, strange, if now I grab my DSDT, this is Andre's one, not mine (as
if the DSDT was read from initrd). On the contrary, battery0 is still no
present (I attached my kern.log_20040217).

On the other hand, as from the syslog_20040216 I attached, during
various tests I made yesterday, just one time I could see the famous
'Looking for DSDT in initrd' in 'syslog', so IMHO now every boot the
kernel takes my customized DSDT. In fact, the latest kern.log_20040217
lacks some line which are present in syslog_20040216:
> Feb 16 16:42:40 localhost kernel: Linux version 2.6.2-acpi-dsdt-initrd
(root-HSB4nKSusd8@public.gmane.org) (gcc version 3.3.3 20040214 (prerelease) (Debian)) #1 Mon
Feb 16 16:36:47 CET 2004
> Feb 16 16:42:40 localhost kernel: BIOS-provided physical RAM map:
> Feb 16 16:42:40 localhost kernel:  BIOS-e820: 0000000000000000 -
000000000009fc00 (usable)
> Feb 16 16:42:40 localhost kernel:  BIOS-e820: 000000000009fc00 -
00000000000a0000 (reserved)
> Feb 16 16:42:40 localhost kernel:  BIOS-e820: 00000000000e0000 -
0000000000100000 (reserved)
> Feb 16 16:42:40 localhost kernel:  BIOS-e820: 0000000000100000 -
000000001ff40000 (usable)
> Feb 16 16:42:40 localhost kernel:  BIOS-e820: 000000001ff40000 -
000000001ff50000 (ACPI data)
> Feb 16 16:42:40 localhost kernel:  BIOS-e820: 000000001ff50000 -
0000000020000000 (ACPI NVS)
> Feb 16 16:42:40 localhost kernel: 511MB LOWMEM available.
> Feb 16 16:42:40 localhost kernel: On node 0 totalpages: 130880
> Feb 16 16:42:40 localhost kernel:   DMA zone: 4096 pages, LIFO batch:1
> Feb 16 16:42:40 localhost kernel:   Normal zone: 126784 pages, LIFO
batch:16
> Feb 16 16:42:40 localhost kernel:   HighMem zone: 0 pages, LIFO batch:1
> Feb 16 16:42:40 localhost kernel: DMI 2.3 present.
> Feb 16 16:42:40 localhost kernel: ACPI: RSDP (v000 ACPIAM
                       ) @ 0x000f5db0
> Feb 16 16:42:40 localhost kernel: ACPI: RSDT (v001 A M I  OEMRSDT
0x02000406 MSFT 0x00000097) @ 0x1ff40000
> Feb 16 16:42:40 localhost kernel: ACPI: FADT (v001 A M I  OEMFACP
0x02000406 MSFT 0x00000097) @ 0x1ff40200
> Feb 16 16:42:40 localhost kernel: ACPI: OEMB (v001 A M I  OEMBIOS
0x02000406 MSFT 0x00000097) @ 0x1ff50040
> Feb 16 16:42:40 localhost kernel: ACPI: DSDT (v001  1ABSP 1ABSP001
0x00000001 MSFT 0x0100000d) @ 0x00000000
> Feb 16 16:42:40 localhost kernel: Building zonelist for node : 0
> Feb 16 16:42:40 localhost kernel: Kernel command line:
BOOT_IMAGE=262-dsdt ro root=303
> Feb 16 16:42:40 localhost kernel: Found and enabled local APIC!
> Feb 16 16:42:40 localhost kernel: Initializing CPU#0
> Feb 16 16:42:40 localhost kernel: PID hash table entries: 2048 (order
11: 16384 bytes)
> Feb 16 16:42:40 localhost kernel: Detected 1601.014 MHz processor.
> Feb 16 16:42:40 localhost kernel: Using tsc for high-res timesource
> Feb 16 16:42:40 localhost kernel: Console: colour dummy device 80x25
> Feb 16 16:42:40 localhost kernel: Memory: 513580k/523520k available
(2461k kernel code, 9184k reserved, 1061k data, 164k init, 0k highmem)
> Feb 16 16:42:40 localhost kernel: Checking if this processor honours
the WP bit even in supervisor mode... Ok.
> Feb 16 16:42:40 localhost kernel: Calibrating delay loop... 3162.11
BogoMIPS
> Feb 16 16:42:40 localhost kernel: Dentry cache hash table entries:
65536 (order: 6, 262144 bytes)
> Feb 16 16:42:40 localhost kernel: Inode-cache hash table entries:
32768 (order: 5, 131072 bytes)
> Feb 16 16:42:40 localhost kernel: Mount-cache hash table entries: 512
(order: 0, 4096 bytes)
> Feb 16 16:42:40 localhost kernel: checking if image is initramfs...it
isn't (ungzip failed); looks like an initrd
> Feb 16 16:42:40 localhost kernel: ACPI: Looking for DSDT in initrd ...
found customized DSDT with 22420 bytes!
> Feb 16 16:42:40 localhost kernel: Freeing initrd memory: 21k freed
> Feb 16 16:42:40 localhost kernel: CPU:     After generic identify,
caps: a7e9fbbf 00000000 00000000 00000000
> Feb 16 16:42:40 localhost kernel: CPU:     After vendor identify,
caps: a7e9fbbf 00000000 00000000 00000000
> Feb 16 16:42:40 localhost kernel: CPU: L1 I cache: 32K, L1 D cache: 32K
> Feb 16 16:42:40 localhost kernel: CPU: L2 cache: 1024K
> Feb 16 16:42:40 localhost kernel: CPU:     After all inits, caps:
a7e9fbbf 00000000 00000000 00000040
> Feb 16 16:42:40 localhost kernel: Intel machine check architecture
supported.
> Feb 16 16:42:40 localhost kernel: Intel machine check reporting
enabled on CPU#0.
> Feb 16 16:42:40 localhost kernel: CPU: Intel(R) Pentium(R) M processor
1600MHz stepping 05
> Feb 16 16:42:40 localhost kernel: Enabling fast FPU save and
restore... done.
> Feb 16 16:42:40 localhost kernel: Enabling unmasked SIMD FPU exception
support... done.
> Feb 16 16:42:40 localhost kernel: Checking 'hlt' instruction... OK.
> Feb 16 16:42:40 localhost kernel: POSIX conformance testing by UNIFIX
> Feb 16 16:42:40 localhost kernel: enabled ExtINT on CPU#0
> Feb 16 16:42:40 localhost kernel: ESR value before enabling vector:
00000000
> Feb 16 16:42:40 localhost kernel: ESR value after enabling vector:
00000000
> Feb 16 16:42:40 localhost kernel: Using local APIC timer interrupts.
> Feb 16 16:42:40 localhost kernel: calibrating APIC timer ...
> Feb 16 16:42:40 localhost kernel: ..... CPU clock speed is 1599.0846 MHz.
> Feb 16 16:42:40 localhost kernel: ..... host bus clock speed is
99.0990 MHz.
> Feb 16 16:42:40 localhost kernel: NET: Registered protocol family 16
> Feb 16 16:42:40 localhost kernel: PCI: PCI BIOS revision 2.10 entry at
0xf0031, last bus=2
> Feb 16 16:42:40 localhost kernel: PCI: Using configuration type 1
> Feb 16 16:42:40 localhost kernel: mtrr: v2.0 (20020519)
> Feb 16 16:42:40 localhost kernel: ACPI: Subsystem revision 20040211
> Feb 16 16:42:40 localhost kernel: ACPI: Using customized DSDT
> Feb 16 16:42:40 localhost kernel:    tbget-0299: *** Info: Table
[DSDT] replaced by host OS
> Feb 16 16:42:40 localhost kernel:  tbxface-0117 [03] acpi_load_tables
     : ACPI Tables successfully acquired
> Feb 16 16:42:40 localhost kernel: Parsing all Control
Methods:.............................................................................................................................................................................................................................................................................
> Feb 16 16:42:40 localhost kernel: Table [DSDT](id F004) - 967 Objects
with 58 Devices 269 Methods 29 Regions
> Feb 16 16:42:40 localhost kernel: ACPI Namespace successfully loaded
at root c04bf1dc
> Feb 16 16:42:40 localhost kernel: ACPI: IRQ9 SCI: Level Trigger.
> Feb 16 16:42:40 localhost kernel: evxfevnt-0093 [04] acpi_enable
     : Transition to ACPI mode successful
> Feb 16 16:42:40 localhost kernel: evgpeblk-0747 [06]
ev_create_gpe_block   : GPE 00 to 31 [_GPE] 4 regs at 0000000000000428
on int 9
> Feb 16 16:42:40 localhost kernel: Completing
Region/Field/Buffer/Package
initialization:.................................................................................................................................
> Feb 16 16:42:40 localhost kernel: Initialized 28/29 Regions 34/35
Fields 39/39 Buffers 28/28 Packages (975 nodes)
> Feb 16 16:42:40 localhost kernel: Executing all Device _STA and_INI
methods:..............................................  psargs-0352: ***
Error: Looking up [ECFL] in namespace, AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel: search_node c155a528 start_node
c155a528 return_node 00000000
> Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method
execution failed [\_SB_.ECAV] (Node c155a528), AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method
execution failed [\_SB_.ACS_] (Node c155a4a8), AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method
execution failed [\_SB_.AC__._INI] (Node c1559728), AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel: .  psargs-0352: *** Error: Looking
up [ECFL] in namespace, AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel: search_node c155a528 start_node
c155a528 return_node 00000000
> Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method
execution failed [\_SB_.ECAV] (Node c155a528), AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method
execution failed [\_SB_.BATS] (Node c155a428), AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method
execution failed [\_SB_.BAT0._STA] (Node c1558e28), AE_NOT_FOUND
> Feb 16 16:42:40 localhost kernel: .............
> Feb 16 16:42:40 localhost kernel: 60 Devices found containing: 60
_STA, 3 _INI methods

Now, the real problem is in these lines:
> Feb 16 16:42:40 localhost kernel: ACPI: Looking for DSDT in initrd ...
found customized DSDT with 22420 bytes!
<cut>
> Feb 16 16:42:40 localhost kernel: ACPI: Subsystem revision 20040211
> Feb 16 16:42:40 localhost kernel: ACPI: Using customized DSDT
> Feb 16 16:42:40 localhost kernel:    tbget-0299: *** Info: Table
[DSDT] replaced by host OS
> Feb 16 16:42:40 localhost kernel:  tbxface-0117 [03] acpi_load_tables
     : ACPI Tables successfully acquired

/et-voilà/: the kernel reads my customized DSDT, but after it doesn't
used it (the 'replaced by host OS' message), so I've the corrected DSDT
in /proc/acpi/dsdt, but not used. Am I right? In fact, I get all the
errors I've with the original DSDT (which I'd like to correct, but after
having booted with the new DSDT).

Any ideas?

Thx, bye,
Gismo / Luca

PS to Andre Messerschmidt: I don't know if you're subscribed to
'acpi-devel', so I cc you.

PPS to Markus Gaugusch: I think your patch (version for 2.6.1 vanilla)
is applicable even on 2.6.2, while there's just an hunk.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFAMk9DVAp7Xm10JmkRAqP0AKCMGpV3Rn0/DjaSIdg/IHRJ+SO1PwCgiCqZ
rSdPF7HnT0mZ7pRQULsUym0=
=ItC9
-----END PGP SIGNATURE-----

[-- Attachment #2: syslog-2.6.2-acpi-dsdt-initrd.20040216.gz --]
[-- Type: application/x-gzip, Size: 7198 bytes --]

[-- Attachment #3: kern.log-2.6.2-acpi-dsdt-initrd.20040217.gz --]
[-- Type: application/x-gzip, Size: 6193 bytes --]

             reply	other threads:[~2004-02-17 17:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-17 17:28 Luca Capello [this message]
     [not found] ` <40324F44.60006-wlebWZzHoyE@public.gmane.org>
2004-02-17 20:43   ` ASUS M6800N: battery0 not present Jan Philipp Giel
     [not found]     ` <200402172143.27818.gielj-TFexGAE6Ty5xRhk+k0m/rQ@public.gmane.org>
2004-02-18 10:55       ` Luca Capello
2004-02-18  7:52   ` Andre Messerschmidt
     [not found]     ` <200402180852.16189.a.messerschmidt-hi6Y0CQ0nG0@public.gmane.org>
2004-02-18 11:11       ` Luca Capello
     [not found]         ` <40334874.6000109-wlebWZzHoyE@public.gmane.org>
2004-02-18 18:31           ` Andre Messerschmidt
2004-02-18 17:13   ` Luca Capello
2004-03-04 14:12   ` Luca Capello
2004-03-04 14:39     ` Jan Philipp Giel
     [not found]       ` <002401c401f6$8cfcd920$3a392886-NmZw/y+ms+s@public.gmane.org>
2004-03-20 11:05         ` Luca Capello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40324F44.60006@pca.it \
    --to=luca-wlebwzzhoye@public.gmane.org \
    --cc=a.messerschmidt-hi6Y0CQ0nG0@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=dsdt-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox