Created attachment 929 [details]
ACPI tables for IBM ThinkPad G40 .tar.gz format

I can confirm this on both 2.4.23-pre4 and 2.6.0-test5 on my G40 laptop with the
latest IBM BIOS - 1TET79WW (1.04) and ACPI patches (acpi-20030916).

The problem has also been reported in the following thread:
http://sourceforge.net/mailarchive/forum.php?thread_id=3175124&forum_id=7803

The error is in acpi_ec_ecdt_probe of ec.c. there are 3 functions called in 
acpi_ec_ecdt_probe. can you find which one is error? Thanks a lot.

Well, i didn't use C language for years, but after some time I was able to add 
a log message into ec.c, function acpi_ec_ecdt_probe:

status = acpi_get_handle(NULL, ecdt_ptr->ec_id, &ec_ecdt->handle);
if (ACPI_FAILURE(status)) {
  printk(KERN_INFO PREFIX "Error in acpi_get_handle with status: %d\n", status);
  goto error;
}

And after reboot, there's a message in dmesg:

ACPI: Found ECDT
ACPI: Error in acpi_get_handle with status: 4097
ACPI: Could not use ECDT

But i wasn't able to find what status = 4097 means.

4097 means bad parameter, so this means 'ecdt_ptr->ec_id' is bad. But 
according to ECDT, this one is correct. It's strange. can you print 'ecdt_ptr-
>ec_id'? Thanks a lot.

Here it is:

ecdt_ptr->ec_id: -268378168

sorry, I didn't explain clearly. though it's named ec_id, it's a string in 
fact. it would be better to print it as a string. But through the number you 
gave, I find the ec_id seems to be error.

please try replace 
>status = acpi_get_handle(NULL, ecdt_ptr->ec_id, &ec_ecdt->handle);
with
>status = acpi_get_handle(NULL, "\\_SB_.PCI0.LPC_.EC__", &ec_ecdt->handle);

Created attachment 942 [details]
dmesg output

Sorry, it's my mistake i didn't check the ec_id type. So here it is
a corrected logs:

ACPI: Found ECDT
ACPI: Before calling acpi_get_handle() ecdt_ptr->ec_id=\_SB.PCI0.LPC.ECBOOT(
ACPI: Error in acpi_get_handle with status: 4097
ACPI: After calling acpi_get_handle() ecdt_ptr->ec_id=\_SB.PCI0.LPC.ECBOOT(
ACPI: Could not use ECDT

Then i've changed the acpi_get_handle call to the one you suggested and ACPI
is functional! I have attached dmesg file. Is there any chance to correct
this 'hack' with inserting correct string into ec_id and replace it with
more common code?

Thanks

Some strange error have started to appear in dmesg output after the 'string 
hack' and successful ACPI status:

evregion-0345: *** Error: Handler for [EmbeddedControl] returned AE_TIME
 dswexec-0422 [4993] ds_exec_end_op        : [Store]: Could not resolve
operands, AE_TIME
 psparse-1121: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.SMRD]
(Node c18fbde8), AE_TIME
 psparse-1121: *** Error: Method execution failed
[\_SB_.PCI0.LPC_.EC__.BAT1.UPBI] (Node c18f8d68), AE_TIME
 psparse-1121: *** Error: Method execution failed
[\_SB_.PCI0.LPC_.EC__.BAT1._BIF] (Node c18f8c68), AE_TIME
acpi_battery-0134 [4985] acpi_battery_get_info : Error evaluating _BIF

But my GNOME applet for battery status is functional and shows correct values
(compared to WinXP after reboot).

please refer Bug 1038.

Well, I've applied the battery patch from 
http://erkki.tty0.org/thinkpad/kernel/acpi-thinkpad-battery-patch, but it didn't
help. There are still a lot of errors in dmesg:

evregion-0345: *** Error: Handler for [EmbeddedControl] returned AE_TIME
 dswexec-0422 [40661] ds_exec_end_op        : [Store]: Could not resolve
operands, AE_TIME
 psparse-1121: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.SMRD]
(Node c18fbde8), AE_TIME
 psparse-1121: *** Error: Method execution failed
[\_SB_.PCI0.LPC_.EC__.BAT1.UPBI] (Node c18f8d68), AE_TIME
 psparse-1121: *** Error: Method execution failed
[\_SB_.PCI0.LPC_.EC__.BAT1._BIF] (Node c18f8c68), AE_TIME
acpi_battery-0134 [40653] acpi_battery_get_info : Error evaluating _BIF

I have also tried to apply 
http://erkki.tty0.org/thinkpad/kernel/acpi-thinkpad-ec-patch, but it seems, this
one is already included in ACPI-20030916 patch.

I find below ASL code in your DSDT:
>OperationRegion (ERAM, EmbeddedControl, 0x00, 0xFF)
>Field (ERAM, ByteAcc, NoLock, Preserve)
>{
>...
> Offset (0x18),
>SMPR,   8,
>SMST,   8,
>SMAD,   8,
>SMCM,   8,
>SMD0,   264,
>SMAA,   8,
>BATD,   16,
>ACFL,   1,
Offset (0x42),
>...
> NHSE,   88,
> LIEN,   1,
> Offset (0xE4),
> NHNA,   88
>}
>Method (SMRD, 4, NotSerialized)
>{
>...
> If (LEqual (Arg0, 0x0B))
> {
>     Store (SMD0, Arg3)
>  }
>...
>}
SMD0's length is 33(264/8) bytes. So strange! I think it's the reason to fail 
of 'Store (SMD0, Arg3)'. Try change 'ACPI_EC_UDELAY_COUNT' of ec.c to a larger 
number (such as 5000). what did it happen?

Created attachment 960 [details]
dmesg output

Well, setting ACPI_EC_UDELAY_COUNT to 5000 didn't help, errors are still
logged in dmesg.

Well, it seems, that AE_TIME errors in dmesg output were generated because of
inoptimal access to ACPI battery status from GNOME 2.2 battstat-applet. I've
patched this applet with patch from http://www.its.caltech.edu/~dmoore/battstat/
and AE_TIME errors disappeared.

Anyway, thanks for help.

I've patched ACPI20031002 on 2.4.22 kernel and ACPI works even without
ECDT table (I didn't use a hack with "\\_SB_.PCI0.LPC_.EC__" string). There is
a warning message in dmesg but all ACPI modules load and they appear to run
fine. Here are interesting parts of dmesg output:

IBM machine detected. Enabling interrupts during APM calls.
ACPI: RSDP (v002 IBM                                       ) @ 0x000f7330
ACPI: XSDT (v001 IBM    TP-1T    0x00001050  LTP 0x00000000) @ 0x2f6f2447
ACPI: FADT (v002 IBM    TP-1T    0x00001050 IBM  0x00000001) @ 0x2f6f248b
ACPI: SSDT (v001 IBM    TP-1T    0x00001050 MSFT 0x0100000d) @ 0x2f6f253f
ACPI: ECDT (v001 IBM    TP-1T    0x00001050 IBM  0x00000001) @ 0x2f6f7f87
ACPI: BOOT (v001 IBM    TP-1T    0x00001050  LTP 0x00000001) @ 0x2f6f7fd8
ACPI: DSDT (v001 IBM    TP-1T    0x00001050 MSFT 0x0100000d) @ 0x00000000
Kernel command line: BOOT_IMAGE=Linux ro root=302 devfs=mount hdc=ide-scsi
No local APIC present or hardware disabled
Initializing CPU#0
Detected 2788.724 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 5570.56 BogoMIPS
Memory: 761828k/777152k available (1267k kernel code, 14872k reserved, 498k
data, 112k init, 0k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: bfebf9ff 00000000 00000000 00000000
CPU:             Common caps: bfebf9ff 00000000 00000000 00000000
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20031002
PCI: PCI BIOS revision 2.10 entry at 0xfd966, last bus=5
PCI: Using configuration type 1
 tbxface-0117 [03] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control
Methods:.........................................................................................................................................................................................................................
Table [DSDT](id F005) - 799 Objects with 47 Devices 217 Methods 16 Regions
Parsing all Control Methods:.
Table [SSDT](id F003) - 1 Objects with 0 Devices 1 Methods 0 Regions
ACPI Namespace successfully loaded at root c02f273c
ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd
evxfevnt-0093 [04] acpi_enable           : Transition to ACPI mode successful
evgpeblk-0748 [06] ev_create_gpe_block   : GPE 00 to 31 [_GPE] 4 regs at
0000000000001028 on int 9
ACPI: Found ECDT
ACPI: Could not use ECDT
Completing Region/Field/Buffer/Package
initialization:................................................................................................................................................
Initialized 16/16 Regions 61/61 Fields 47/47 Buffers 20/20 Packages (808 nodes)
Executing all Device _STA and_INI
methods:................................................
48 Devices found containing: 48 _STA, 3 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S3 S4 S5)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
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 PCI Bridge
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC] (gpe 29)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
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)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Processor [CPU0] (supports C1 C2, 4 throttling states)
ACPI: Thermal Zone [THRM] (52 C)

*** Bug 1326 has been marked as a duplicate of this bug. ***

yes, no ECDT didn't impact ACPI. Now ACPI can tolerant it.

Seems like your system works.