ASUS M6800N: battery0 not present

DISCUSSION Luca Capello 3 participants 10 messages Feb 17, 2004 – Mar 20, 2004 5 messages not in the archive ACPI

lore

Share & tools

lore

Luca Capello

author

2004-02-17 17:28 UTC #0 lore raw

-----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 <[email protected]>
To: [email protected]
CC: Ben B. <[email protected]>
References: <[email protected]>

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

Quoted 4 lines

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.

Quoted 1 line

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):

Quoted 1 line

gismo:/usr/src/linux-2.6.2# patch -p1 <

../kernel/v2.6/03_acpi-dsdt-initrd-patch-v0.4-2.6.1.diff

Quoted 6 lines

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:

Quoted 1 line

gismo:/usr/src/kernel/dsdt/iasl-linux-20030918# ./iasl

messerschmidt_asus_m6800n_dsdt_test.dsl

Quoted 7 lines

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)

Quoted 2 lines

ASL Input: messerschmidt_asus_m6800n_dsdt_test.dsl - 5580 lines,

181689 bytes, 2576 keywords

Quoted 1 line

AML Output: DSDT.aml - 22419 bytes 772 named objects 1804 executable

opcodes

Quoted 3 lines

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:

Quoted 4 lines

	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:

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Linux version 2.6.2-acpi-dsdt-initrd

([email protected]) (gcc version 3.3.3 20040214 (prerelease) (Debian)) #1 Mon

Feb 16 16:36:47 CET 2004

Quoted 2 lines

Feb 16 16:42:40 localhost kernel: BIOS-provided physical RAM map:
Feb 16 16:42:40 localhost kernel:  BIOS-e820: 0000000000000000 -

000000000009fc00 (usable)

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  BIOS-e820: 000000000009fc00 -

00000000000a0000 (reserved)

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  BIOS-e820: 00000000000e0000 -

0000000000100000 (reserved)

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  BIOS-e820: 0000000000100000 -

000000001ff40000 (usable)

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  BIOS-e820: 000000001ff40000 -

000000001ff50000 (ACPI data)

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  BIOS-e820: 000000001ff50000 -

0000000020000000 (ACPI NVS)

Quoted 4 lines

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

Quoted 3 lines

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI: RSDT (v001 A M I  OEMRSDT

0x02000406 MSFT 0x00000097) @ 0x1ff40000

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI: FADT (v001 A M I  OEMFACP

0x02000406 MSFT 0x00000097) @ 0x1ff40200

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI: OEMB (v001 A M I  OEMBIOS

0x02000406 MSFT 0x00000097) @ 0x1ff50040

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI: DSDT (v001  1ABSP 1ABSP001

0x00000001 MSFT 0x0100000d) @ 0x00000000

Quoted 2 lines

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

Quoted 3 lines

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)

Quoted 4 lines

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)

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Checking if this processor honours

the WP bit even in supervisor mode... Ok.

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Calibrating delay loop... 3162.11

BogoMIPS

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Dentry cache hash table entries:

65536 (order: 6, 262144 bytes)

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Inode-cache hash table entries:

32768 (order: 5, 131072 bytes)

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Mount-cache hash table entries: 512

(order: 0, 4096 bytes)

Quoted 1 line

Feb 16 16:42:40 localhost kernel: checking if image is initramfs...it

isn't (ungzip failed); looks like an initrd

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI: Looking for DSDT in initrd ...

found customized DSDT with 22420 bytes!

Quoted 2 lines

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel: CPU:     After vendor identify,

caps: a7e9fbbf 00000000 00000000 00000000

Quoted 3 lines

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Intel machine check architecture

supported.

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Intel machine check reporting

enabled on CPU#0.

Quoted 1 line

Feb 16 16:42:40 localhost kernel: CPU: Intel(R) Pentium(R) M processor

1600MHz stepping 05

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Enabling fast FPU save and

restore... done.

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Enabling unmasked SIMD FPU exception

support... done.

Quoted 4 lines

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ESR value after enabling vector:

00000000

Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 5 lines

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  tbxface-0117 [03] acpi_load_tables

: ACPI Tables successfully acquired

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Parsing all Control

Methods:.............................................................................................................................................................................................................................................................................

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Table [DSDT](id F004) - 967 Objects

with 58 Devices 269 Methods 29 Regions

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI Namespace successfully loaded

at root c04bf1dc

Quoted 2 lines

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

Quoted 1 line

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Completing

Region/Field/Buffer/Package initialization:.................................................................................................................................

Quoted 1 line

Feb 16 16:42:40 localhost kernel: Initialized 28/29 Regions 34/35

Fields 39/39 Buffers 28/28 Packages (975 nodes)

Quoted 1 line

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

Quoted 1 line

Feb 16 16:42:40 localhost kernel: search_node c155a528 start_node

c155a528 return_node 00000000

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method

execution failed [\_SB_.ECAV] (Node c155a528), AE_NOT_FOUND

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method

execution failed [\_SB_.ACS_] (Node c155a4a8), AE_NOT_FOUND

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method

execution failed [\_SB_.AC__._INI] (Node c1559728), AE_NOT_FOUND

Quoted 1 line

Feb 16 16:42:40 localhost kernel: .  psargs-0352: *** Error: Looking

up [ECFL] in namespace, AE_NOT_FOUND

Quoted 1 line

Feb 16 16:42:40 localhost kernel: search_node c155a528 start_node

c155a528 return_node 00000000

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method

execution failed [\_SB_.ECAV] (Node c155a528), AE_NOT_FOUND

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method

execution failed [\_SB_.BATS] (Node c155a428), AE_NOT_FOUND

Quoted 1 line

Feb 16 16:42:40 localhost kernel:  psparse-1120: *** Error: Method

execution failed [\_SB_.BAT0._STA] (Node c1558e28), AE_NOT_FOUND

Quoted 2 lines

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:

Quoted 1 line

Feb 16 16:42:40 localhost kernel: ACPI: Looking for DSDT in initrd ...

found customized DSDT with 22420 bytes!
<cut>

Quoted 3 lines

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

Quoted 1 line

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jan Philipp Giel

2004-02-17 20:43 UTC #2 lore raw

Am Tuesday 17 February 2004 18:28 schrieb Luca Capello:

Quoted 6 lines

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).
Quoted 2 lines
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.

Hi!
I think Andre meant that the battery things are visible in acpi but they show the battery as absent - so they do not really work.
There is a BIOS Update available for the M6800N. It was mailed to someone who had problems with some ACPIEC Message while running Windows (ASUSProbe). The DSDT (see attachment) has changed with the BIOS Update. Maybe this helps someone to fix the DSDT.

Find the BIOS update here:
http://benbuchwald.de/images/bios.zip

Hope this was not too off-topic...

Regards
Philipp

A message that is not in the archive (sent off-list or not yet received): 200402172143.27818.gielj-TFexGAE6Ty5xRhk+k0m/[email protected]

Luca Capello

author

2004-02-18 10:55 UTC #4 lore raw

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

Hello,

Quoted 1 line · Jan Philipp Giel

I think Andre meant that the battery things are visible in acpi but

they show

Quoted 1 line

the battery as absent - so they do not really work.

yes, I know this, but anyway it's better than normal situation ;-)

Quoted 1 line

There is a BIOS Update available for the M6800N. It was mailed to

someone who

Quoted 2 lines

had problems with some ACPIEC Message while running Windows (ASUSProbe). The DSDT (see attachment) has changed with the BIOS Update. Maybe this

helps

Quoted 1 line

someone to fix the DSDT.

Yes, when I searched for info about GNU/Linux on ASUS M6800N I found your page and I already upgrade my BIOS to the latest available 0205A.

Now, the strange things:
- - I suppose the DSDT you attached comes from the new BIOS, am I right? Because in this case, the DSDT I got from my new BIOS (I attacched) is different from your when I disassemble them with 'iasl-20030918'. In which way have you caught your DSDT? I did:
cat /proc/acpi/dsdt > [file]

- - in the 2 cases, the new DSDT has just 5 errors and not >200 as the old one. ASAP I'll try to correct it to see what changes

Thx, bye,
Gismo / Luca

PS to Andre: I still don't know if you're subscribed to the list... -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFAM0SbVAp7Xm10JmkRAvZVAJ9UJ9anpV4cUHBrAOU/NGK5/uYU9ACfdUGA CKvbbc6sxnEru6t46sasXnQ=
=4Qzl
-----END PGP SIGNATURE-----

Andre Messerschmidt

2004-02-18 07:52 UTC #5 lore raw

In reply to a message not in the archive

Am Dienstag, 17. Februar 2004 18:28 schrieb Luca Capello:

Hi Luca,

I don't have any errors if I use my DSDT. See the attached output from dmesg for how it looks here with a 2.4.21.
I reckon that you are right with your assumption that the new DSDT table is not used, but I don't know why, since I have no insights in ACPI.

regards
Andre

----- from dmesg --------------------------
...
Looking for DSDT in initrd ... found (at offset 452594)!
ACPI-0292: *** Info: Table [DSDT] replaced by host OS
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S3 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 00:1f.1
Transparent bridge - Intel Corp. 82801BAM/CAM/DBM PCI Bridge
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC0] (gpe 28)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: Power Resource [GFAN] (off)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 4 00:00:1f[B] -> IRQ 4 Mode 1 Trigger 1
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9 00:00:1f[A] -> IRQ 9 Mode 1 Trigger 1
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 00:00:01[A] -> IRQ 11 Mode 1 Trigger 1
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10 00:00:1d[D] -> IRQ 10 Mode 1 Trigger 1
PIC: IRQ (11) already programmed
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5 00:00:1d[B] -> IRQ 5 Mode 1 Trigger 1
PIC: IRQ (9) already programmed
PIC: IRQ (4) already programmed
PIC: IRQ (11) already programmed
PIC: IRQ (9) already programmed
PIC: IRQ (4) already programmed
PIC: IRQ (4) already programmed
PIC: IRQ (5) already programmed
PIC: IRQ (11) already programmed
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
...
ACPI: AC Adapter [AC] (on-line)
Asus Laptop ACPI Extras version 0.24a
M6N model detected, unsupported, trying default values, contact the
developers
Notify Handler installed successfully
Error changing brightness
Error changing brightness
ACPI: Battery Slot [BAT0] (battery absent)
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Fan [FN00] (on)
ACPI: Processor [CPU1] (supports C1)
ACPI: Thermal Zone [THRM] (21 C)
-----------------------------------------------

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

A message that is not in the archive (sent off-list or not yet received): [email protected]

Luca Capello

author

2004-02-18 11:11 UTC #7 lore raw

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

Hello,

Quoted 1 line · Andre Messerschmidt

I don't have any errors if I use my DSDT. See the attached output from

dmesg

Quoted 1 line

for how it looks here with a 2.4.21.

yes, I saw, and this is the same I'd like to have. Anyway, I forgot to advise that I upgraded to the new BIOS (0205A.001) and so maybe this is a problem or cause something strange. I even tried a kernel-2.4.21 + ACPI-20030619 + 'ACPI DSDT in initrd', but nothing changed, so maybe the problem in my case is different.

Just to avoid mistackes: can you attach you customized compiled DSDT? I'll give it a try and report the results.

Quoted 1 line

I reckon that you are right with your assumption that the new DSDT

table is

Quoted 1 line

not used, but I don't know why, since I have no insights in ACPI.

Another strange thing is this one: as I reported in my first post, the DSDT I've in /proc/acpi/dsdt if I boot with your customized compiled DSDT and you customized DSDT are different. I mean:
- - ./iasl -c [your DSDT].dsl
- - cp DSDT.aml /boot/
- - reboot
- - cat /proc/acpi/dsdt > 2.6.2-initrd.dat
- - ./iasl -d 2.6.2-initrd.dat
- - diff [your DSDT].dsl 2.6.2-initrd.dsl > andre_luca.diff (attached)

As I wrote in the last post, I'll try to correct the new DSDT from BIOS 0205A.001: it has just 5 errors, so maybe there're good improvements. Anyway, as above, I'd like to try your DSDT in .aml format, compiled by you, if you could attach it.

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFAM0hzVAp7Xm10JmkRAhVmAJ9X+R49FMnhQtMFDXmc9f2K3Izw4wCeLpNl c9gw1mApcLxO+0y80ik4BlU=
=ZH3O
-----END PGP SIGNATURE-----

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andre Messerschmidt

2004-02-18 18:31 UTC #9 lore raw

Am Mittwoch, 18. Februar 2004 12:11 schrieb Luca Capello:

Quoted 2 lines

Just to avoid mistackes: can you attach you customized compiled DSDT? I'll give it a try and report the results.

See attachment.

Quoted 4 lines

As I wrote in the last post, I'll try to correct the new DSDT from BIOS 0205A.001: it has just 5 errors, so maybe there're good improvements. Anyway, as above, I'd like to try your DSDT in .aml format, compiled by you, if you could attach it.

I tried your table with my original BIOS, but then I get errors during startup, which is not really suprising since it is another BIOS. Here is the boot.msg part:

<4> ACPI-0292: *** Info: Table [DSDT] replaced by host OS
<3>schedule_task(): keventd has not started <3>schedule_task(): keventd has not started <3>schedule_task(): keventd has not started <3>schedule_task(): keventd has not started
<4> ACPI-0398: *** Error: acpi_ev_gpe_dispatch: No handler or method for
GPE[1C], d
isabling event
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKA._STA] (Node
dfeaa620)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKA._STA] (Node
dfeaa620)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKB._STA] (Node
dfeaa720)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKB._STA] (Node
dfeaa720)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKC._STA] (Node
dfeaa820)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKC._STA] (Node
dfeaa820)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKD._STA] (Node
dfeaa920)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKD._STA] (Node
dfeaa920)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKE._STA] (Node
dfeaaa20)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKE._STA] (Node
dfeaaa20)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKF._STA] (Node
dfeaab20)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKF._STA] (Node
dfeaab20)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKG._STA] (Node
dfeaac20)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKG._STA] (Node
dfeaac20)
, AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKH._STA] (Node
dfeaad20)
, AE_AML_REGION_LIMIT
<4> ACPI-0098: *** Error: Method execution failed [\_SB_.LNKH._STA] (Node
dfeaad20)
, AE_AML_REGION_LIMIT
<6>ACPI: Interpreter enabled
<6>ACPI: Using PIC for interrupt routing
<6>ACPI: System [ACPI] (supports S0 S1 S3 S4 S5)
<6>ACPI: PCI Root Bridge [PCI0] (00:00)
<4>PCI: Probing PCI hardware (bus 00)
<6>PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 <4>Transparent bridge - Intel Corp. 82801BAM/CAM/DBM PCI Bridge <7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] <6>ACPI: Embedded Controller [EC0] (gpe 28)
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT] <7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKA._STA] (Node
dfeaa620), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKB._STA] (Node
dfeaa720), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKC._STA] (Node
dfeaa820), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKD._STA] (Node
dfeaa920), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKE._STA] (Node
dfeaaa20), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKF._STA] (Node
dfeaab20), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKG._STA] (Node
dfeaac20), AE_AML_REGION_LIMIT
<4> ACPI-1121: *** Error: Method execution failed [\_SB_.LNKH._STA] (Node
dfeaad20), AE_AML_REGION_LIMIT
<6>ACPI: Power Resource [GFAN] (off)
<6>PCI: Probing PCI hardware
<4>PCI: No IRQ known for interrupt pin A of device 00:1d.0 <4>PCI: No IRQ known for interrupt pin B of device 00:1d.1 <4>PCI: No IRQ known for interrupt pin C of device 00:1d.2 <4>PCI: No IRQ known for interrupt pin D of device 00:1d.7 <4>PCI: No IRQ known for interrupt pin A of device 00:1f.1 <4>PCI: No IRQ known for interrupt pin B of device 00:1f.3 <4>PCI: No IRQ known for interrupt pin B of device 00:1f.5 <4>PCI: No IRQ known for interrupt pin B of device 00:1f.6 <4>PCI: No IRQ known for interrupt pin A of device 01:00.0 <4>PCI: No IRQ known for interrupt pin A of device 02:00.0 <4>PCI: No IRQ known for interrupt pin A of device 02:01.0 <4>PCI: No IRQ known for interrupt pin B of device 02:01.1 - using IRQ 255 <4>PCI: No IRQ known for interrupt pin C of device 02:01.2 <4>PCI: No IRQ known for interrupt pin A of device 02:02.0 <6>PCI: Using ACPI for IRQ routing
<6>PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'

regards
Andre

Luca Capello

author

2004-02-18 17:13 UTC #10 lore raw

In reply to a message not in the archive

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

Hello,

Quoted 10 lines · Luca Capello

Now, the real problem is in these lines:
Quoted 1 line
Quoted 1 line
Feb 16 16:42:40 localhost kernel: ACPI: Looking for DSDT in initrd ...
found customized DSDT with 22420 bytes!
<cut>
Quoted 5 lines
Quoted 3 lines
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
Quoted 1 line
Feb 16 16:42:40 localhost kernel:  tbxface-0117 [03] acpi_load_tables

Quoted 7 lines

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

sorry, but reading 'drivers/acpi/table/tbget.c' let me know that the message above is the correct one: the DSDT in the BIOS is replaced with the new one, which in my case is taken via the initrd patch. If this is not true, please someone could correct me?

So, now the problem is that I can't use Andre's DSDT, I mean, I can use it, but with no changes. I suppose this is due to the more recent BIOS I use, am I right?

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFAM51IVAp7Xm10JmkRAqNrAKCKjEMzjIy7jH53cLeeViaLs2jZ/gCfdahm sxaaG90KNyn+RFfE34FoUGg=
=Xsog
-----END PGP SIGNATURE-----

Luca Capello

author

2004-03-04 14:12 UTC #11 lore raw

In reply to a message not in the archive

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

Hello,

I found on Jan Philipp Giel report

	http://fsai.fh-trier.de/~gielj/M6800N/

a new DSDT which solve the battery problem with the new BIOS 0205A. This new DSDT was hacked by Ycarus, here the first lines from the .dsl version:
=====
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20030918
*
* Disassembly of dsdt.dat, Tue Mar 2 23:05:23 2004
*
* Modified version of DSDT from Asus M6800N bios version 0205A
* This version now report battery state under Linux.
* Bug : Ac_adapter state is always off-line
* Modified version by Ycarus (Yannick Chabanois)
* chabanois(at)ifrance.com
*
*/
=====

I just tried it on 2.6.3 + ACPI 20040220 + ACPI DSDT in initrd 2.6.1 and now the battery0 is read correctly:
=====

[email protected]:~$ dmesg | grep battery
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Battery Slot [BAT1] (battery absent)
[email protected]:~$ cat /proc/acpi/battery/BAT0/alarm
alarm:                   unsupported
[email protected]:~$ cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         4300 mAh
last full capacity:      4300 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 130 mAh
design capacity low:     21 mAh
capacity granularity 1:  52 mAh
capacity granularity 2:  2418 mAh
model number:            M6N
serial number:           00001
battery type:            LIon
OEM info:                ASUSTek
[email protected]:~$ cat /proc/acpi/battery/BAT0/state [if on AC mode]
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            unknown
remaining capacity:      4456 mAh
present voltage:         16649 mV
[email protected]:~$ cat /proc/acpi/battery/BAT0/state [if on battery mode]
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1320 mA
remaining capacity:      4455 mAh
present voltage:         16406 mV
[email protected]:~$
=====

IMHO someone should send this hacked DSDT to ASUS in order to have a new BIOS version which doesn't need an hacked DSDT, am I right? Could this be useful?

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFARzlZVAp7Xm10JmkRAqyEAJ9G4G3Yv83nHaGoqmTSa9RQW0t+uACgjexW oIriGQXghKzcdpHEAfDgxGk=
=0n5Z
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Jan Philipp Giel

2004-03-04 14:39 UTC #12 lore raw

Hi!

Quoted 3 lines

Hallo Herr Giel,
Wir bieten keinen Support für Linux an.
Bitte schauen sie in die bekannten Linux Foren ob es dort eine Lösung für

gibt.

In English this would be something like:

Quoted 3 lines

Hello Mr. Giel
We do not support Linux.
Please search the appropriate linux forums for a possible solution.

This is the answer that I got when I asked them to provide a fixed DSDT. So I don't think they will fix it even if we mail the fixed version to them.

The corrected DSDT still lacks some funtionality, e.g. it is not properly handled when the AC Adaptor is connected - KLaptop still shows "running on batteries", 0:00 left but the battery status is increasing.

So before mailing to Asus we should wait until everything is working IMO.

Regards
Philipp

----- Original Message -----
From: "Luca Capello" <[email protected]>
To: "ML ACPI-devel" <[email protected]>
Cc: "Yannick Chabanois" <[email protected]>
Sent: Thursday, March 04, 2004 3:12 PM
Subject: Re: [ACPI] ASUS M6800N: battery0 not present

Quoted 8 lines

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I found on Jan Philipp Giel report
http://fsai.fh-trier.de/~gielj/M6800N/
a new DSDT which solve the battery problem with the new BIOS 0205A. This

new

Quoted 17 lines

DSDT was hacked by Ycarus, here the first lines from the .dsl version:
=====
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20030918
*
* Disassembly of dsdt.dat, Tue Mar 2 23:05:23 2004
*
* Modified version of DSDT from Asus M6800N bios version 0205A
* This version now report battery state under Linux.
* Bug : Ac_adapter state is always off-line
* Modified version by Ycarus (Yannick Chabanois)
* chabanois(at)ifrance.com
*
*/
=====

Quoted 1 line

I just tried it on 2.6.3 + ACPI 20040220 + ACPI DSDT in initrd 2.6.1 and

now the

Quoted 38 lines

battery0 is read correctly:
=====

[email protected]:~$ dmesg | grep battery
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Battery Slot [BAT1] (battery absent)
[email protected]:~$ cat /proc/acpi/battery/BAT0/alarm
alarm:                   unsupported
[email protected]:~$ cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         4300 mAh
last full capacity:      4300 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 130 mAh
design capacity low:     21 mAh
capacity granularity 1:  52 mAh
capacity granularity 2:  2418 mAh
model number:            M6N
serial number:           00001
battery type:            LIon
OEM info:                ASUSTek
[email protected]:~$ cat /proc/acpi/battery/BAT0/state [if on AC mode]
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            unknown
remaining capacity:      4456 mAh
present voltage:         16649 mV
[email protected]:~$ cat /proc/acpi/battery/BAT0/state [if on battery mode]
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1320 mA
remaining capacity:      4455 mAh
present voltage:         16406 mV
[email protected]:~$
=====

Quoted 1 line

IMHO someone should send this hacked DSDT to ASUS in order to have a new

BIOS

Quoted 1 line

version which doesn't need an hacked DSDT, am I right? Could this be

useful?

Quoted 13 lines

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFARzlZVAp7Xm10JmkRAqyEAJ9G4G3Yv83nHaGoqmTSa9RQW0t+uACgjexW oIriGQXghKzcdpHEAfDgxGk=
=0n5Z
-----END PGP SIGNATURE-----

Quoted 11 lines

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Acpi-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

A message that is not in the archive (sent off-list or not yet received): 002401c401f6$8cfcd920$3a392886-NmZw/[email protected]

Luca Capello

author

2004-03-20 11:05 UTC #14 lore raw

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

Hello,

Quoted 3 lines · Jan Philipp Giel

The corrected DSDT still lacks some funtionality, e.g. it is not properly handled when the AC Adaptor is connected - KLaptop still shows "running on batteries", 0:00 left but the battery status is increasing.

latest DSDT from Andre Messerschmidt

	http://www.isis.de/members/~messersch/asus-m6800n.html
solved the AC status: now it's recognized correctly and 'GNOME Battery Applet'
shows correctly if I'm AC or battery and when I plug in/out the AC adapter.
=====
gismo:/home/luca# dmesg | grep ACPI
Asus Laptop ACPI Extras version 0.27
ACPI: AC Adapter [AC] (on-line)
ACPI: Processor [CPU1] (supports C1)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Thermal Zone [THRM] (58 C)
gismo:/home/luca#
=====

Quoted 1 line

So before mailing to Asus we should wait until everything is working IMO.

You're right, here the situation for ACPI support on my M6842NWH:
- - battery > works with Andre's DSDT
- - AC > works with Andre's DSDT
- - thermal > works
- - processor > still 'invalid PBLK length (7)' message, only C1 with original or Andre's DSDT, C1 & C2 with Bruno Ducrot's _CST patches
- - buttons > works
- - hotkeys > works with 'acpi4asus' 0.27+CVS
- - fan > module loaded, but no entries in /proc/acpi/fan/, anyway the fan starts automatically when required
- - with APIC I can't clearly shutdown

    http://sourceforge.net/mailarchive/forum.php?thread_id=3854100&forum_id=6102

- - 'os_wait_semaphore' problem still unsolved
- - I haven't tried yet sleep states

BTW, I upgraded to BIOS 0206A from http://fsai.fh-trier.de/~gielj/M6800N/

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFAXCVhVAp7Xm10JmkRAgdrAJ4w3WBCKkLlkK6P/Y6bU8nvzRIyGgCfZlOK X7cgRtyM56y/S1vNBL7nVQM=
=HJps
-----END PGP SIGNATURE-----