All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.