Bug 5904 - wrong state of laptop lid on startup
wrong state of laptop lid on startup
Status: REJECTED INSUFFICIENT_DATA
Product: ACPI
Classification: Unclassified
Component: Other
i386 Linux
: P2 normal
Assigned To: Zhang Rui
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-16 08:14 UTC by Fabian Zeindl
Modified: 2006-12-02 01:31 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.15
Tree: Mainline
Regression: ---


Attachments
acpidump (94.73 KB, text/plain)
2006-08-22 01:54 UTC, Fabian Zeindl
Details
get LID state earlier (902 bytes, patch)
2006-08-22 19:55 UTC, Zhang Rui
Details | Diff
Dmesg output with patch (14.94 KB, text/plain)
2006-08-26 01:13 UTC, Fabian Zeindl
Details
new dsdt (180.15 KB, application/octet-stream)
2006-08-30 22:11 UTC, Zhang Rui
Details

Description Fabian Zeindl 2006-01-16 08:14:31 UTC
Distribution: Gentoo Linux
Hardware Environment: Acer Travelmate 243LC
Problem Description:

Hi

 When my laptop is started and my laptop lid is open,
/proc/acpi/button/lid/LID/state says "closed". When I close it once and
open it again once the value is set correctly. This is very annoying
cause my screensaver always invokes on startup.


Linux version 2.6.15-suspend2 (root@obsidian) (gcc version 3.4.4 (Gentoo
3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #2 PREEMPT Sat Jan 14 23:12:45 C
ET 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
 BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000eee0000 (usable)
 BIOS-e820: 000000000eee0000 - 000000000eeeb000 (ACPI data)
 BIOS-e820: 000000000eeeb000 - 000000000ef00000 (ACPI NVS)
 BIOS-e820: 000000000ef00000 - 0000000010000000 (reserved)
 BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved)
 BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved)
238MB LOWMEM available.
found SMP MP-table at 000f63f0
On node 0 totalpages: 61152
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 57056 pages, LIFO batch:15
  HighMem zone: 0 pages, LIFO batch:0
DMI present.
ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f6420
ACPI: RSDT (v001 PTLTD  Montara  0x06040000  LTP 0x00000000) @ 0x0eee5e05
ACPI: FADT (v001 Acer   Yuhina   0x06040000 PTL  0x00000001) @ 0x0eeeaed2
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x0eeeafd8
ACPI: DSDT (v001   ANNI   Yuhina 0x06040000 MSFT 0x0100000e) @ 0x00000000
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
SMP mptable: bad signature [0x0]!
BIOS bug, MP table errors detected!...
... disabling SMP support. (tell your hw vendor)
Allocating PCI resources starting at 20000000 (gap: 10000000:eec10000)
Built 1 zonelists
Kernel command line: root=/dev/hda3 resume2=/dev/hda2 init=/sbin/initng lapic
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to ffffd000 (fee00000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 2498.310 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 238724k/244608k available (2212k kernel code, 5452k reserved, 740k data,
148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5002.83 BogoMIPS (lpj=10005677)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400
00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400
00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 128K
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
mtrr: v2.0 (20020519)
CPU: Intel(R) Celeron(R) CPU 2.50GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
    ACPI-0284: *** Info: Table [DSDT] replaced by host OS
ACPI: setting ELCR to 0200 (from 0c30)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd6b4, last bus=2
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:02.0
PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 10 11) *5
ACPI: PCI Interrupt Link [LNKB] (IRQs *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs *10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs *10 11)
ACPI: PCI Interrupt Link [LNKG] (IRQs *10 11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 10 11) *4
ACPI: Embedded Controller [EC] (gpe 28)
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bus 3, cardbus bridge: 0000:02:04.0
  IO window: 00003400-000034ff
  IO window: 00003800-000038ff
  PREFETCH window: 20000000-21ffffff
  MEM window: 26000000-27ffffff
PCI: Bus 7, cardbus bridge: 0000:02:04.1
  IO window: 00003c00-00003cff
  IO window: 00001400-000014ff
  PREFETCH window: 22000000-23ffffff
  MEM window: 28000000-29ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 3000-3fff
  MEM window: e0200000-e02fffff
  PREFETCH window: 20000000-24ffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNKF] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 10
ACPI: PCI Interrupt 0000:02:04.1[B] -> Link [LNKG] -> GSI 10 (level, low) -> IRQ 10
Simple Boot Flag at 0x3c set to 0x1
Machine check exception polling timer started.
SGI XFS with no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
vesafb: Intel Corporation, Intel(r)852MG/852MGE/855MG/855MGE Graphics
Controller, Hardware Version 0.0 (OEM: Intel(r)852MG/852MGE/855MG/855MGE
 Graphics Chip Accelerated VGA BIOS)
vesafb: VBE version: 3.0
vesafb: VBIOS/hardware doesn't support DDC transfers
vesafb: no monitor limits have been set
vesafb: scrolling: redraw
Console: switching to colour frame buffer device 128x48
vesafb: framebuffer at 0xe8000000, mapped to 0xcf880000, using 6144k, total 16192k
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLP2]
ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)
Using specific hotkey driver
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRS] (58 C)
ACPI: Thermal Zone [THRC] (52 C)
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Detected 16252K stolen memory.
agpgart: AGP aperture is 128M @ 0xe8000000
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[drm] Initialized i915 1.1.0 20040405 on minor 0:
[drm] Initialized i915 1.1.0 20040405 on minor 1:
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM
chipsets
intelfb: Version 0.9.2
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
intelfb: Cannot reserve FB region.
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:02:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
eth0: RealTek RTL8139 at 0xcf80a000, 00:0a:e4:4a:d9:20, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8101'
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
ICH4: chipset revision 3
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1818-0x181f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
input: AT Translated Set 2 keyboard as /class/input/input0
hda: HITACHI_DK23FA-30, ATA DISK drive
Synaptics Touchpad, model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000
input: SynPS/2 Synaptics TouchPad as /class/input/input1
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: QSI CD-RW/DVD-ROM SBW-242, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 58605120 sectors (30005 MB) w/2048KiB Cache, CHS=58140/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNKF] -> GSI 10 (level, low) -> IRQ 10
Yenta: CardBus bridge found at 0000:02:04.0 [1025:0039]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:04.0, mfunc 0x00921b22, devctl 0x64
Yenta: ISA IRQ mask 0x00b8, PCI irq 10
Socket status: 30000020
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe02fffff
pcmcia: parent PCI bridge Memory window: 0x20000000 - 0x24ffffff
ACPI: PCI Interrupt 0000:02:04.1[B] -> Link [LNKG] -> GSI 10 (level, low) -> IRQ 10
Yenta: CardBus bridge found at 0000:02:04.1 [1025:0039]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:04.1, mfunc 0x00921b22, devctl 0x64
Yenta: ISA IRQ mask 0x00b8, PCI irq 10
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe02fffff
pcmcia: parent PCI bridge Memory window: 0x20000000 - 0x24ffffff
usbmon: debugfs is not available
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 11, io mem 0xe0100000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 11, io base 0x00001820
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001840
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 10, io base 0x00001860
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
pccard: CardBus card inserted into slot 0
usb 2-2: new low speed USB device using uhci_hcd and address 2
input: Darfon USB Mouse as /class/input/input2
input: USB HID v1.10 Mouse [Darfon USB Mouse] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21
2005 UTC).
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 55333 usecs
intel8x0: clocking to 48000
ALSA device list:
  #0: Intel 82801DB-ICH4 with CS4299 at 0xe0100c00, irq 10
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
Using IPI Shortcut mode
Suspend2 Core.
Suspend2 Compression Driver loading.
Suspend2 Encryption Driver loading.
Suspend2 Swap Writer loading.
ACPI wakeup devices:
 LID LANC MODM
ACPI: (supports S0 S3 S4 S5)
Suspend2 2.2-rc16: Swapwriter: Signature found.
Suspend2 2.2-rc16: Suspending enabled.
swapper(1): READ block 0 size 4096 on hda2
XFS mounting filesystem hda3
Ending clean XFS mount for filesystem: hda3
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 148k freed
IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
microcode: CPU0 updated from revision 0x17 to 0x2e, date = 08112004
Adding 500464k swap on /dev/hda2.  Priority:-1 extents:1 across:500464k
Comment 1 Luming Yu 2006-02-07 01:11:53 UTC
>Checking 'hlt' instruction... OK.
>    ACPI-0284: *** Info: Table [DSDT] replaced by host OS

Please re-test without overriding DSDT.
Comment 2 Fabian Zeindl 2006-02-08 07:44:03 UTC
I've tested it without overriding. Same result...
Comment 3 Len Brown 2006-08-10 00:41:20 UTC
Please verify that this is still a problem with a recent kernel,
such as 2.6.17.stable or 2.6.18-rc
Comment 4 Fabian Zeindl 2006-08-17 01:38:10 UTC
Hi,

I run 2.6.17.7 and still have this problem on my laptop.
Comment 5 Zhang Rui 2006-08-17 23:04:20 UTC
please have a look at bug 5809 shown in 
http://bugzilla.kernel.org/show_bug.cgi?id=5809, and make sure whether you've 
got the same problem.:)
If not, please make the test that Len Brown asked in #1, that will be 
helpful.:)
Comment 6 Fabian Zeindl 2006-08-18 04:49:13 UTC
I did the test:

1. When you boot the system with the lid open, what does state say?

# cat /proc/acpi/button/lid/LID0/state
state:      closed

2. When you then press the lid button down (or actually close the lid
and check the state from a serial console or network connection)
what does state say?

# cat /proc/acpi/button/lid/LID0/state
state:      closed

3. when you release or open the lid, what does state say?

# cat /proc/acpi/button/lid/LID0/state
state:      open



I dont't think I have the same problem, because after I closed the lid once
everything is working perfectly fine. I don't have problems like I have to wait
20 seconds to change the status or things like that.
Comment 7 Zhang Rui 2006-08-21 21:35:13 UTC
Please attach your acpidump output.:)
Comment 8 Fabian Zeindl 2006-08-22 01:54:01 UTC
Created attachment 8847 [details]
acpidump
Comment 9 Zhang Rui 2006-08-22 19:55:13 UTC
Created attachment 8850 [details]
get LID state earlier

Maybe OS gets a wrong LID state by evaluate "_LID" method. So i try to get the
LID state at an earlier time. if the state still shows "closed". i think this
is probably caused by a bios bug. Please try this patch and attach dmesg
again:)
Comment 10 Len Brown 2006-08-23 19:36:54 UTC
Rui,
Looking at the DSDT...
       Device (LID)
        {
            Name (_HID, EisaId ("PNP0C0D"))
            Method (_LID, 0, NotSerialized)
            {
                If (LIDS)
                {
                    Return (0x01)
                }
                Else
                {
                    Return (0x00)
                }
            }

            Name (_PRW, Package (0x02)
            {
                0x18, 
                0x03
            })
        }

and LIDS is defined here:

    OperationRegion (MNVS, SystemMemory, 0x0EEEBF09, 0x40)
    Field (MNVS, AnyAcc, Lock, Preserve)
    {
        OSYS,   16, 
        SMIF,   8, 
        PRM0,   8, 
        PRM1,   8, 
        SCIF,   8, 
        PRM2,   8, 
        PRM3,   8, 
        LCKF,   8, 
        PRM4,   8, 
        PRM5,   8, 
        DBGS,   8, 
        DCKS,   4, 
        CDCK,   4, 
        FPEN,   8, 
        FPST,   8, 
        LIDS,   8, 
        PWRS,   8, 

and LIDS is accessed here:

                    Method (_Q2E, 0, NotSerialized)
                    {
                        Store (0x2E, P80H)
                        If (LEqual (\_SB.PCI0.LPCB.EC.P54, 0x00))
                        {
                            Store (0x98, \_SB.PCI0.LPCB.EC.P54S)
                            Store (0x00, LIDS)
                        }
                        Else
                        {
                            Store (0x88, \_SB.PCI0.LPCB.EC.P54S)
                            Store (0x01, LIDS)
                        }

                        Notify (\_SB.LID, 0x80)
                    }

Which is an Embedded Controller event handler.

and P54 is defined here:


                    OperationRegion (ERAM, EmbeddedControl, 0x00, 0x7F)
                    Field (ERAM, AnyAcc, Lock, Preserve)
                    {
                                Offset (0x01), 
                        SCIC,   8, 
                                Offset (0x04), 
                        CMCD,   8, 
                        DAT1,   8, 
                        DAT2,   8, 
                        DAT3,   8, 
                                Offset (0x18), 
                        SMPR,   8, 
                        SMST,   8, 
                        SMAD,   8, 
                        SMCM,   8, 
                        SMD0,   264, 
                        SMAA,   8, 
                                Offset (0x43), 
                        P50,    1, 
                            ,   2, 
                        P43,    1, 
                        P54,    1, 

If you can access the valuyes of P54 and LIDS before
any lid events are triggered, then that will tell us
if the values are correct in the hardware and perhaps an 
EC event was necessary to update LIDS and notify the OS.
(and maybe Linux has a bug where that even was dropped
and the EC handler was not invoked?)

or if the values are incorrect in P54 and LIDS until there is
an actual LID change, then this hardware and BIOS simply
work that way and Linux will not be able to fix this bug.

Fabian,
It would be interesting if you can boot the laptop with
the lid closed, log in over the network and observe the
lid status then.  presumably it will say closed, as that
is apparently the inital value no matter what.

Then on 1st open the lid state should immediately switch
to open, because this ec event handler should run for
the first time (and you should see an increment under
acpi in /proc/interrupts) and update the value to be open.
If that doesn't work, then I'm off track here and the
issue is elsewhere.
Comment 11 Zhang Rui 2006-08-23 20:12:52 UTC
i really have the same doubt that whether LIDS/P54S is 
initialized the right value when the laptop boots. 
i suppose that adding an method (maybe the _INI) for 
LID0 device which will set LIDS to 1 may help this laptop 
boots correctly with the LID open. Any other places to 
set LIDS to 1 will also works.
but i don't know whether this can be realized or not. 
Maybe i am on the wrong way from the beginning ...
Comment 12 Len Brown 2006-08-23 22:27:50 UTC
Rui, 
You can find the values of these locations at boot in two ways. 
 
1. find the chip-set spec for the hardware, determine the 
   addresses to read/write, and use inl(1) etc. 
or 
2. modify the DSDT with move(variable, Debug) lines 
   that are invoked at some boot time place before 
   the event in question.  build the DSDT into the kernel 
   and build with CONFIG_ACPI_DEBUG so that the messages 
   come out in the console log. 
 
Comment 13 Fabian Zeindl 2006-08-26 01:13:16 UTC
1.
When I try the patch it still says "closed" after bootup. I attached dmesg.

2.
When I try to boot the laptop with LID closed (by touching the sensor) it
immediatly powers off again. When I reboot with LID closed it's the same. it
powers off.
When I wait until the grub menu comes I can close it and it will be boot. I
logged in over network and lid state says "closed". 
Comment 14 Fabian Zeindl 2006-08-26 01:13:53 UTC
Created attachment 8880 [details]
Dmesg output with patch
Comment 15 Fabian Zeindl 2006-08-26 01:15:35 UTC
P.S.: I tried booting and logging in over network with the old kernel again
_without_ the patch.
Comment 16 Len Brown 2006-08-26 18:57:41 UTC
> I logged in over network and lid state says "closed". 
 
And when you opened it for the first time, did it correctly 
switch to "open", and increment the acpi line in /proc/acpi/interrupts? 
 
 
Comment 17 Fabian Zeindl 2006-08-28 00:55:57 UTC
Yes, it switched to open.

I don't have /proc/acpi/interrupt.
Comment 18 Zhang Rui 2006-08-28 01:51:14 UTC
>Yes, it switched to open.
Everything goes well when boot with the Lid closed.
This proves that Linux does not drop any events.
It seems that the values remains 0 in LIDS no matter
the Lid is open or closed until there is an actual 
LID change. This "0" value is meaningless because
no one touches it since the system boots.But OS treats 
this as the signature of "closed" Lid state.
This is rather a BIOS bug that Linux can't fix.
 
>I don't have /proc/acpi/interrupts.
cat /proc/interrupts
check if there is an acpi interrupt increment
when you open the Lid for the first time.

Comment 19 Fabian Zeindl 2006-08-28 02:14:48 UTC
No, it doesn't increment, it stays on 186 or something like this. I've to close
the LID another time, then it begins to increment.
Comment 20 Zhang Rui 2006-08-28 03:53:02 UTC
So do you mean that when open the lid for the first time, 
State turns to "open" immediately but none acpi interrupt occurs.
That's weird.:(
How about this one:
# /etc/init.s/acpid stop
# cat /proc/acpi/event
Would you please try this test and tell me the result? :)
And if you can boot your laptop with Lid open and do the same 
two tests again, that will be great.:)
Comment 21 Fabian Zeindl 2006-08-28 04:30:34 UTC
I did the test again, and when I boot with lid closed it says closed and when I
open it it says closed and I have to close and open it another time for correct
value.

sorry, I think I did something wrong before. Do you need the new tests too?
Comment 22 Zhang Rui 2006-08-28 18:22:58 UTC
OK. Sounds interesting.
Let's repeat the tests again,and during the first step,
i want you to give me the following information.
Lid state, acpi interrupts(proc/interrupts).
Boots with the lid open and lid closed,  make a record
every time you open/close your Lid until everything is OK.:)
Comment 23 Fabian Zeindl 2006-08-29 03:15:25 UTC
OK:

=== Boot with LID open ===

interrupts:
  9:        149          XT-PIC  acpi
state:
  state:      closed

==> LID CLOSE
interrupts:
  9:        156          XT-PIC  acpi
state:
  state:      closed

==> LID OPEN
interrupts:
  9:        198          XT-PIC  acpi
state:
  state:      open

=== Boot with LID close ===
interrupts:
  9:        183          XT-PIC  acpi
state:
  state:      closed

===> LID OPEN
interrupts:
  9:        218          XT-PIC  acpi
state:
  state:      closed

===> LID CLOSE
interrupts:
  9:        225          XT-PIC  acpi
state:
  state:      closed

===> LID OPEN
interrupts:
  9:        267          XT-PIC  acpi
state:
  state:      open


I hope this helps. Is the one interrupts-line OK?
Comment 24 Fabian Zeindl 2006-08-29 03:16:49 UTC
Is there a reason why interrupts increment now everytime? I'm on ac power so I
don't think it's a "power interrupt" (if such things exist).
What can that be?
Comment 25 Zhang Rui 2006-08-29 18:56:28 UTC
There is really an abnormal interrupt increment that brings me some difficulty
to make sure whether there is an interrupt occurs when you open/close the Lid.
This time let's try this way.
Do the following soon after OS is started.
# /etc/init.s/acpid stop
# cat /proc/acpi/event
open/close the lid for several times and record what is print out each time.
Comment 26 Zhang Rui 2006-08-30 02:23:22 UTC
And /proc/interrupts as well:)
Comment 27 Zhang Rui 2006-08-30 22:11:23 UTC
Created attachment 8914 [details]
new dsdt

override your dsdt with this one.
cat your Lid state before any Lid open/close operations.
then open/close it until everything is OK.
attach the dmesg output.:)
Comment 28 Zhang Rui 2006-08-30 22:15:39 UTC
set   CONFIG_ACPI_CUSTOM_DSDT=y   and
  CONFIG_ACPI_CUSTOM_DSDT_FILE="/.../dsdt.hex" (the
   full pathname of the new dsdt file here). 
Make and install, and your new DSDT table will
   be  used  in place of the old one.
Comment 29 Fabian Zeindl 2006-09-04 06:42:58 UTC
I tried the new dsdt, this doesn't change anything.

boot with lid open:
interrupts:615 lid:closed
->close
interrupts:661 lid:closed
->open
interrups:672 lid:open

boot with lid closed:
interrupts:186 lid:closed
->open
interrupts:223 lid:closed
->closed
interrups:264 lid:closed
->open
interrups:297 lid:open

i remove acpid of the startup scripts for all this.

I noticed that doing
cat /proc/acpi/button/lid/LID0/state
increases the interrupt line too.

greetings

PS: can't we just close this bug to won't fix or something?
I'm spending far more time debugging that it annoys me.
Comment 30 Zhang Rui 2006-09-04 18:10:48 UTC
I think you should attatch the _dmesg_ output with the new dsdt. :)
Debug information in the dmesg will tell us if the values are correct in the 
hardware. This can really help us find the key reason of this bug.

Sorry to bother you too much. But we are getting closer to the right way step 
by step. It will be very kind of you to try it again. Thanks.
Comment 31 Adrian Bunk 2006-12-02 01:31:29 UTC
Please reopen this bug if:
- it is still present in kernel 2.6.19 and
- you can provide the requested information.

Note You need to log in before you can comment on or make changes to this bug.