Bug 5809 - Status/state for LID is _close_ while the lid is open - Samsung X20 1730
Summary: Status/state for LID is _close_ while the lid is open - Samsung X20 1730
Status: REJECTED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Steffen Pankratz
URL:
Keywords:
: 9666 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-01-02 03:08 UTC by Michael Braun
Modified: 2008-05-08 13:42 UTC (History)
5 users (show)

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


Attachments
acpi dump (116.94 KB, text/plain)
2006-08-14 04:08 UTC, Michael Braun
Details
acpidump output (128.58 KB, text/plain)
2007-12-04 11:55 UTC, Steffen Pankratz
Details
dmesg output (15.09 KB, text/plain)
2007-12-04 11:56 UTC, Steffen Pankratz
Details
dmesg.output_complete (18.25 KB, application/octet-stream)
2007-12-31 17:58 UTC, Steffen Pankratz
Details
dmesg.output (18.06 KB, application/octet-stream)
2008-01-01 12:00 UTC, Steffen Pankratz
Details
dmesg_after (19.67 KB, application/octet-stream)
2008-01-23 14:39 UTC, Steffen Pankratz
Details
interrupts_before (840 bytes, application/octet-stream)
2008-01-23 14:39 UTC, Steffen Pankratz
Details
interrupts_after (840 bytes, application/octet-stream)
2008-01-23 14:40 UTC, Steffen Pankratz
Details
lspci_-vvxxx (33.34 KB, application/octet-stream)
2008-01-24 07:54 UTC, Steffen Pankratz
Details
acpi_event test2 (68 bytes, application/octet-stream)
2008-01-24 07:54 UTC, Steffen Pankratz
Details
dmesg_before test2 (19.67 KB, application/octet-stream)
2008-01-24 07:55 UTC, Steffen Pankratz
Details
dmesg_after test2 (23.59 KB, application/octet-stream)
2008-01-24 07:55 UTC, Steffen Pankratz
Details
interrupts_before test2 (840 bytes, application/octet-stream)
2008-01-24 07:55 UTC, Steffen Pankratz
Details
interrupts_after test2 (840 bytes, application/octet-stream)
2008-01-24 07:56 UTC, Steffen Pankratz
Details
patch: disable ec gpe in gpe handler (781 bytes, patch)
2008-02-27 17:29 UTC, Zhang Rui
Details | Diff
try the debug patch (506 bytes, patch)
2008-05-04 02:29 UTC, ykzhao
Details | Diff
dmesg output with new patch (26.55 KB, application/octet-stream)
2008-05-04 10:31 UTC, Steffen Pankratz
Details
try the custom DSDT (229.40 KB, patch)
2008-05-04 18:28 UTC, ykzhao
Details | Diff
dmesg_with_custom_dsdt (21.60 KB, application/octet-stream)
2008-05-05 09:45 UTC, Steffen Pankratz
Details
the custom DSDT (227.95 KB, patch)
2008-05-07 22:23 UTC, ykzhao
Details | Diff

Description Michael Braun 2006-01-02 03:08:35 UTC
Most recent kernel where this bug did not occur: n/a

Distribution: Mandriva 2006 (+cooker)

Hardware Environment: Notebook - Samsung X20 1730
(http://www.samsungcomputer.com/product/spec_x20.htm?SMSESSION=NO)

Software Environment: 2.6.15-rc7

Problem Description:
I get a wrong ACPI event state for my lid of my laptop (Samsung X20 1730 II).
When its open I get "closed" state.

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

cat /proc/acpi/button/lid/LID0/info
type:                    Lid Switch

After some tests, I get the state to "open" after I've closed the lid for about
10 seconds. When I open it under 10 seconds its still closed.

I think it is no hardware problem, because under WinXP the lid function works as
it should.

I hope someone can help me to solve this problem. If you need more information
please let me know.

/proc/version
*******************
Linux version 2.6.15-rc7.4mdk (lcapitulino@n1.mandriva.com) (gcc version 4.0.2
(4.0.2
-1mdk for Mandriva Linux release 2006.1)) #1 Wed Dec 28 18:57:53 CET 2005

/proc/cpuinfo
*****************************
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.73GHz
stepping        : 8
cpu MHz         : 798.171
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips        : 1597.95


DMESG
*****
Linux version 2.6.15-rc7.4mdk (lcapitulino@n1.mandriva.com) (gcc version 4.0.2
(4.0.2-1mdk for Mandriva Linux release 2006.1)) #1 Wed Dec 28 18:57:53 CET 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d0000 - 00000000000d4000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fea0000 (usable)
 BIOS-e820: 000000003fea0000 - 000000003feb1000 (ACPI data)
 BIOS-e820: 000000003feb1000 - 000000003ff00000 (ACPI NVS)
BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0006000 (reserved)
 BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
 BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
 BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
126MB HIGHMEM available.
896MB LOWMEM available.
NX (Execute Disable) protection: active
On node 0 totalpages: 261792
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 32416 pages, LIFO batch:7
DMI present.
ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f7730
ACPI: RSDT (v001 PTLTD  Ohlone00 0x06040000  LTP 0x00000000) @ 0x3feaa995
ACPI: FADT (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3feb0e96
ACPI: MADT (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3feb0f0a
ACPI: HPET (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3feb0f64
ACPI: MCFG (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3feb0f9c
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x3feb0fd8
ACPI: SSDT (v001 SataRe SataAhci 0x00001000 INTL 0x20030224) @ 0x3feab18b
ACPI: SSDT (v001  PmRef  Cpu0Ist 0x00003000 INTL 0x20030224) @ 0x3feaac60
ACPI: SSDT (v001  PmRef  Cpu0Cst 0x00003001 INTL 0x20030224) @ 0x3feaaaa6
ACPI: SSDT (v001  PmRef    CpuPm 0x00003000 INTL 0x20030224) @ 0x3feaa9dd
ACPI: DSDT (v001 INTEL  ALVISO   0x06040000 INTL 0x20030224) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:13 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Built 1 zonelists
Kernel command line: auto BOOT_IMAGE=2.6.15-rc7.4 root=305 resume=/dev/hda6
splash=si
lent
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034064k/1047168k available (2041k kernel code, 12496k reserved, 610k
data, 2
16k init, 129664k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
hpet0: at MMIO 0xfed00000 (virtual 0xf8800000), IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
Using HPET for base-timer
Using HPET for gettimeofday
Detected 1729.040 MHz processor.
Using hpet for high-res timesource
Calibrating delay using timer specific routine.. 3461.56 BogoMIPS (lpj=6923122)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 00100000 00000000 00000000 00000180
00000
000 00000000
CPU: After vendor identify, caps: afe9fbff 00100000 00000000 00000000 00000180
000000
00 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 00100000 00000000 00000040 00000180
00000000 000
00000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) M processor 1.73GHz stepping 08
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like
an initrd
Freeing initrd memory: 188k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd92e, last bus=6
PCI: Using MMCONFIG
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:01:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEGP._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs *10)
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
ACPI: PCI Interrupt Link [LNKD] (IRQs *5)
ACPI: PCI Interrupt Link [LNKE] (IRQs *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs *5)
ACPI: PCI Interrupt Link [LNKH] (IRQs *5)
ACPI: Embedded Controller [H_EC] (gpe 23)
ACPI: Power Resource [CFAN] (on)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 11 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:01.0
  IO window: 3000-3fff
  MEM window: c0100000-c01fffff
  PREFETCH window: d0000000-d7ffffff
PCI: Bridge: 0000:00:1c.0
  IO window: 4000-4fff
  MEM window: c4000000-c7ffffff
  PREFETCH window: d8000000-dbffffff
PCI: Bus 7, cardbus bridge: 0000:06:09.0
  IO window: 00005000-000050ff
  IO window: 00005400-000054ff
  PREFETCH window: 50000000-51ffffff
  MEM window: 52000000-53ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 5000-5fff
  MEM window: c8000000-c80fffff
  PREFETCH window: 50000000-51ffffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt 0000:06:09.0[A] -> GSI 16 (level, low) -> IRQ 16
Simple Boot Flag at 0x36 set to 0x1
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1136203606.484:1): initialized
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie03]
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
Allocate Port Service[pcie03]
vesafb: framebuffer at 0xd0000000, mapped to 0xf8880000, using 1875k, total 131072k
vesafb: mode is 800x600x16, linelength=1600, pages=135
vesafb: protected mode interface info at c000:5b3b
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
hpet_resources: 0xfed00000 is busy
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
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
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ACPI: PCI Interrupt 0000:00:1e.3[B] -> GSI 20 (level, low) -> IRQ 18
ACPI: PCI interrupt for device 0000:00:1e.3 disabled
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 19
ICH6: chipset revision 3
ICH6: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x18c0-0x18c7, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: HTS421210H9AT00, ATA DISK drive
hdb: TSSTcorpCD/DVDW TS-L632B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: Host Protected Area detected.
        current capacity is 194560369 sectors (99614 MB)
        native  capacity is 195371568 sectors (100030 MB)
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: 0x37
hda: 194560369 sectors (99614 MB) w/7528KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 >
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI wakeup devices:
PWRB RP01 LANC MODM
ACPI: (supports S0 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 136KiB [1 disk] into ram disk... |^H/^H-^H\^H|^H/^H-^H\^H|^Hdone.
VFS: Mounted root (cramfs filesystem) readonly.
input: AT Translated Set 2 keyboard as /class/input/input0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 216k freed
Synaptics Touchpad, model: 1, fw: 6.1, id: 0x2580b1, caps: 0xa04713/0x200000
input: SynPS/2 Synaptics TouchPad as /class/input/input1
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 20
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 1
uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001800
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 21
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 2
uhci_hcd 0000:00:1d.1: irq 21, 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.2[C] -> GSI 18 (level, low) -> IRQ 19
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 3
uhci_hcd 0000:00:1d.2: irq 19, 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.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.3: irq 16, io base 0x00001860
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 2-1: new low speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 20
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 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: irq 20, io mem 0xc0000000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb 2-1: can't set config #1, error -71
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
ts: Compaq touchscreen protocol output
usb 2-1: new low speed USB device using uhci_hcd and address 4
usbcore: registered new driver hiddev
input: Microsoft Microsoft USB Wireless Mouse as /class/input/input2
input: USB HID v1.11 Mouse [Microsoft Microsoft USB Wireless Mouse] on
usb-0000:00:1d.1-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new driver usbmouse
drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
EXT3 FS on hda5, internal journal
Adding 1630556k swap on /dev/hda6.  Priority:-1 extents:1 across:1630556k
input: PC Speaker as /class/input/input3
Non-volatile memory driver v1.2
hw_random hardware driver 1.0.0 loaded
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 915GM Chipset.
agpgart: AGP aperture is 256M @ 0x0
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
NTFS driver 2.1.25 [Flags: R/O MODULE].
NTFS volume version 3.1.
loop: loaded (max 8 devices)
hdb: ATAPI 24X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8181 buckets, 65448 max) - 232 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
Removing netfilter NETLINK layer.
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Power Button (CM) [PWRB]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Fan [FAN1] (on)
Using specific hotkey driver
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU0] (supports 2 throttling states)
ACPI: Thermal Zone [THRM] (63 C)
ACPI: Video Device [ATIM] (multi-head: yes  rom: no  post: no)
ACPI: PCI Interrupt 0000:06:09.0[A] -> GSI 16 (level, low) -> IRQ 16
Yenta: CardBus bridge found at 0000:06:09.0 [144d:c018]
Yenta: ISA IRQ mask 0x04b8, PCI irq 16
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x5000 - 0x5fff
cs: IO port probe 0x5000-0x5fff: clean.
pcmcia: parent PCI bridge Memory window: 0xc8000000 - 0xc80fffff
pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x51ffffff
pcmcia: Detected deprecated PCMCIA ioctl usage.
pcmcia: This interface will soon be removed from the kernel; please expect
breakage unless you upgrade to new tools.
pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for
details.
cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff
cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7
cs: IO port probe 0xa00-0xaff: clean.
floppy0: no floppy controllers found
floppy0: no floppy controllers found
CAPI Subsystem Rev 1.1.2.8
capifs: Rev 1.1.2.3
capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
NET: Registered protocol family 17
tg3.c:v3.46 (Dec 19, 2005)
ACPI: PCI Interrupt 0000:06:05.0[A] -> GSI 22 (level, low) -> IRQ 22
eth0: Tigon3 [partno(BCM95788A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit)
10/100/1000BaseT Ethernet 00:13:77:02:d6:0c
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[0] TSOcap[1]
eth0: dma_rwctrl[763f0000]
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: 802.11 data/management/control stack, git-1.1.7
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
ipw2200: Copyright(c) 2003-2005 Intel Corporation
ACPI: PCI Interrupt 0000:06:07.0[A] -> GSI 20 (level, low) -> IRQ 18
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ip_tables: (C) 2000-2002 Netfilter core team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8181 buckets, 65448 max) - 232 bytes per conntrack
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. 
http://snowman.net/projects/ipt_recent/
ieee80211_crypt: registered algorithm 'TKIP'
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6 over IPv4 tunneling driver
ACPI: PCI Interrupt 0000:00:1e.2[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1e.2 to 64
intel8x0_measure_ac97_clock: measured 55501 usecs
intel8x0: clocking to 48000
Bluetooth: Core ver 2.8
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.6
eth2: no IPv6 routers present
Comment 1 Len Brown 2006-08-10 01:08:40 UTC
1. When you boot the system with the lid open, what does state say?

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?

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

does it work properly from there forward?
Comment 2 Michael Braun 2006-08-10 03:54:22 UTC
Hi,

thanks for your answer. I'll try to answer your questions...

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?
*******************************************************************
The state is still closed when the LID is closed.

# sleep 5 && cat /proc/acpi/button/lid/LID0/state
state:      closed

3. when you release or open the lid, what does state say?
*******************************************************************
When I wait up to 20 seconds with a closed LID and open it afterwards, the
status changed to open, after opening the lid.

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

does it work properly from there forward?
*****************************************
Not really. The state remains up to 10 seconds in state "open" and changed then
to "closed" (lid is closed). But no suspend activity happens after the change to
"close". But when I open the lid the system powers down for suspending. So it
looks like that the system did not see the status change until I've opened the
lid. Why does the status changed so late after I've closed the lid?

# sleep 5 && cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state
state:      open
state:      open
state:      closed
state:      closed
state:      closed
state:      closed


If you need further information please contact me.

Regards,
Michael
Comment 3 Zhang Rui 2006-08-14 02:27:18 UTC
>1. When you boot the system with the lid open, what does state say?
>*******************************************************************
># cat /proc/acpi/button/lid/LID0/state
>state:      closed
Does the state change to open after a longer time, or just keep closed ? 
e.g,20 seconds .

>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?
>*******************************************************************
>The state is still closed when the LID is closed.
>
># sleep 5 && cat /proc/acpi/button/lid/LID0/state
>state:      closed
The same question.:)

And please attach your acpidump:).
Comment 4 Michael Braun 2006-08-14 04:07:24 UTC
When the system is up and I do not close the LID, the status just keep "closed".
When I close the LID the 1st time, I get the following result: 

[mb@neo ~]$ cat /proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat
/proc/acpi/button/lid/LID0/state && sleep 5 && cat /proc/acpi/button/lid/LID0/state
state:      closed
state:      closed
state:      closed
state:      closed
state:      closed
state:      closed
state:      closed

When I open the LID, the system tries to get into suspend, because as you can
see after I've opened the LID, the status has changed to "open".

[mb@neo ~]$ cat /proc/acpi/button/lid/LID0/state
state:      open

After this, the state will be still "open" when the LID is open. When I close
the LID, the status changes after a few seconds to closed as I've writen in my
last posting.

I'll attach my acpidump.
Comment 5 Michael Braun 2006-08-14 04:08:50 UTC
Created attachment 8780 [details]
acpi dump
Comment 6 Len Brown 2006-08-16 18:15:41 UTC
lets not get user-space acpid and suspend mixed up
in the state of the lid.

Try this:

# /etc/init.s/acpid stop
# cat /proc/acpi/event

And report if you see the LID events come out of this file
when they actually happen, or with a delay like you are seeing
with the state file.  Also, the line for acpi in /proc/acpi/events
should increment at the same time as each lid event.

Comment 7 Michael Braun 2006-08-17 00:03:03 UTC
Here comes my results. If I close the LID and reopen it after 3 seconds, no
event is written. But when I wait 20 seconds I get the foloowing:

-----------8<---------
# /etc/init.d/acpid stop
Stoppen des acpi D
Comment 8 Shaohua 2006-08-17 00:19:26 UTC
re:
Here comes my results. If I close the LID and reopen it after 3 seconds, no
event is written. But when I wait 20 seconds I get the foloowing:

with the same process, can you check if /proc/interrupt has acpi interrupt 
increment? I'd like to know if the event is delayed as some software issues
Comment 9 Michael Braun 2006-08-17 00:37:11 UTC
I hope I understood you correct.

My result with open LID:

# cat /proc/interrupts
           CPU0
  0:    1666601    IO-APIC-edge  timer
  1:       8074    IO-APIC-edge  i8042
  8:          3    IO-APIC-edge  rtc
  9:      39535   IO-APIC-level  acpi
 12:    1014050    IO-APIC-edge  i8042
 14:     166984    IO-APIC-edge  ide0
 16:          0   IO-APIC-level  yenta, uhci_hcd:usb4
 17:      31710   IO-APIC-level  Intel ICH6, ohci1394
 18:     220265   IO-APIC-level  ipw2200
 19:          0   IO-APIC-level  sdhci:slot0, uhci_hcd:usb3
 20:          0   IO-APIC-level  ehci_hcd:usb5, uhci_hcd:usb1
 21:          0   IO-APIC-level  uhci_hcd:usb2
 22:      66368   IO-APIC-level  eth0
NMI:          0
LOC:    1666553
ERR:          0
MIS:          0

With closed LID (after 20 seconds):
# sleep 20 && cat /proc/interrupts
           CPU0
  0:    1674264    IO-APIC-edge  timer
  1:       8160    IO-APIC-edge  i8042
  8:          3    IO-APIC-edge  rtc
  9:      39681   IO-APIC-level  acpi
 12:    1014050    IO-APIC-edge  i8042
 14:     167266    IO-APIC-edge  ide0
 16:          0   IO-APIC-level  yenta, uhci_hcd:usb4
 17:      31710   IO-APIC-level  Intel ICH6, ohci1394
 18:     220592   IO-APIC-level  ipw2200
 19:          0   IO-APIC-level  sdhci:slot0, uhci_hcd:usb3
 20:          0   IO-APIC-level  ehci_hcd:usb5, uhci_hcd:usb1
 21:          0   IO-APIC-level  uhci_hcd:usb2
 22:      66674   IO-APIC-level  eth0
NMI:          0
LOC:    1674216
ERR:          0
MIS:          0
Comment 10 Shaohua 2006-08-17 00:40:14 UTC
Ha, I mean 'If I close the LID and reopen it after 3 seconds,'. See if there 
is interrupt increment.
Comment 11 Thomas Renninger 2006-08-18 02:48:18 UTC
Isn't:
  9:      39681   IO-APIC-level  acpi
this a too high value for ACPI interrupts?
possibly noapic or pci=noacpi might workaround the problem?
Comment 12 Michael Braun 2006-08-18 03:46:04 UTC
to comment #10

After a fresh reboot
********************
[root@neo ~]# cat /proc/interrupts
           CPU0
  0:    1251719    IO-APIC-edge  timer
  1:       1741    IO-APIC-edge  i8042
  8:          3    IO-APIC-edge  rtc
  9:      41364   IO-APIC-level  acpi
 12:     422365    IO-APIC-edge  i8042
 14:      79963    IO-APIC-edge  ide0
 16:          0   IO-APIC-level  uhci_hcd:usb4, yenta
 17:      11518   IO-APIC-level  ohci1394, Intel ICH6
 18:      66706   IO-APIC-level  ipw2200
 19:          0   IO-APIC-level  uhci_hcd:usb3, sdhci:slot0
 20:          0   IO-APIC-level  uhci_hcd:usb1, ehci_hcd:usb5
 21:          0   IO-APIC-level  uhci_hcd:usb2
 22:      49825   IO-APIC-level  eth0
NMI:          0
LOC:    1251678
ERR:          0
MIS:          0
[root@neo ~]# /etc/init.d/acpid stop
Stoppen des acpi D
Comment 13 Michael Braun 2006-08-18 03:48:10 UTC
to comment #11

I've tried both "noapic" and "pci=noacpi" but both does not solve the problem.
Comment 14 Zhang Rui 2006-08-22 01:27:53 UTC
please have a try with a boot option ec_intr=polling :)
Comment 15 Michael Braun 2006-08-22 04:08:54 UTC
Thanks for this tip, but also "ec_intr=polling" does not change anything on the
status.
Comment 16 Thomas Renninger 2006-08-22 04:40:22 UTC
It seems you have some kind of interrupt storm on the acpi interrupt.
Just an idea (I've never saw this and never used this one), but this boot
parameter sounds as it may help on your system:
(from Documentation/kernel-parameters.txt):
       acpi_sci=       [HW,ACPI] ACPI System Control Interrupt trigger mode
                        Format: { level | edge | high | low }
Comment 17 Michael Braun 2006-08-22 07:32:15 UTC
I've tried every option for "acpi_sci=" but with no success. Its still the same
beahvior.
Comment 18 Len Brown 2006-08-23 19:03:10 UTC
Looks like the ACPI SCI is actually working properly,
and the problem with the huge storm of interrupts might
be due to the underlying GPE's screaming.
Comment 19 Len Brown 2006-08-23 19:07:41 UTC
There are quite possibly two independent problems on this box.
the interrupt storm on the acpi SCI interrupt,
and the lid state issue.

in the responses above about the following parameters
noapic
acpi_sci=level acpi_sci=high
acpi_sci=level acpi_sci=low
acpi_sci=edge acpi_sci=high
acpi_sci=edge acpi_sci=low

while they did not have an effect on the lid problem, did
any of them have any effect on the storm of acpi interrupts?

Comment 20 Len Brown 2006-08-23 19:56:53 UTC
Re: comment #15
try "ec_intr=0" -- i believe the syntax you used above was a no-op.
You can confirm it worked by looking for a change in dmesg:
> EC polling mode.
(if you use ec_intr=1, it should print "EC interrupt mode", which
 is the default)

Re: the delay
I suspect that the interrupt storm is getting in the
way of processing the lid event in a timely manner.
Unclear why _LID doesn't immediately return the proper
value, unless a delayed event is necessary to update that too.

Re: suspend
There is only 1 type of event for the lid -- 0x80 means the lid _changed_.
acpid gets this event via /proc/acpi/event,
goes off and looks at /proc/acpi/.../lid and it says "closed",
then it will interpret that as a lid close event and suspend.

So if there is a delay between the event and the lid status,
you'll see this kind of symptom.  For the time being, disable
acpid -- or at least its lid handler.

Comment 21 Len Brown 2006-08-23 20:36:50 UTC
Looking at the DSDT: 
        Device (LID0) 
        { 
            Name (_HID, EisaId ("PNP0C0D")) 
            Method (_LID, 0, NotSerialized) 
            { 
                Return (LIDS) 
            } 
        } 
 
                    OperationRegion (ECR, EmbeddedControl, Zero, 0xFF) 
                    Field (ECR, ByteAcc, Lock, Preserve) 
                    { 
                                Offset (0x18), 
                        SPTR,   8, 
                        SSTS,   8, 
                        SADR,   8, 
                        SCMD,   8, 
                        SBFR,   256, 
                        SCNT,   8, 
                                Offset (0x80), 
                        B1EX,   1, 
                            ,   1, 
                        ACEX,   1, 
                                Offset (0x81), 
                        SWBE,   1, 
                        DCBE,   1, 
                                Offset (0x82), 
                        WLST,   1, 
                                Offset (0x83), 
                        LIDS,   1, 
                                Offset (0x84), 
 
... 
                    Method (_Q5E, 0, NotSerialized) 
                    { 
                        Store (LIDS, \LIDS) 
                        Notify (LID0, 0x80) 
                    } 
 
                    Method (_Q5F, 0, NotSerialized) 
                    { 
                        Store (LIDS, \LIDS) 
                        Notify (LID0, 0x80) 
                    } 
 
So the EC handlers _Q5E and _Q5F read the EC LIDS 
and apparently copy it to a global \LIDS that the _LID 
method simply returns that as its status. 
 
ec_intr=0 remains the key knob to turn. 
 
 
 
Comment 22 Adrian Bunk 2006-10-24 19:41:17 UTC
Please reopen this bug if:
- it is still present in kernel 2.6.18 and
- you can provide the requested data.
Comment 23 Robert 2006-12-21 16:20:53 UTC
I have he same problem as described with kernel 2.6.18.2-34 (openSuSE 10.2).

Comment 24 Zhang Rui 2006-12-24 23:30:55 UTC
Hi Robert
please try 2.6.19 and attach the dmesg and acpidump at the same time.
Comment 25 Adrian Bunk 2007-02-24 09:13:13 UTC
Please reopen this bug if:
- it is still present with kernel 2.6.20 and
- you canprovide the requested information.
Comment 26 Steffen Pankratz 2007-12-04 11:55:57 UTC
Created attachment 13848 [details]
acpidump output
Comment 27 Steffen Pankratz 2007-12-04 11:56:25 UTC
Created attachment 13849 [details]
dmesg output
Comment 28 Steffen Pankratz 2007-12-04 12:00:47 UTC
I have the same problem and it seems it's not fixed yet.

Hardware:
Samsung M50 

Tested with:
2.6.23.9 and 2.6.24-rc4

See attachments for acpidump and dmesg output.
Comment 29 Len Brown 2007-12-31 11:38:48 UTC
*** Bug 9666 has been marked as a duplicate of this bug. ***
Comment 30 Len Brown 2007-12-31 11:52:58 UTC
The acpidump for Steffen's Samsung M50-2130 in bug #9666
shows the same EC mechanism for updating _LID:

               Device (H_EC)
                {
                    Name (_HID, EisaId ("PNP0C09"))
...
                    OperationRegion (ECR, EmbeddedControl, Zero, 0xFF)
                    Field (ECR, ByteAcc, Lock, Preserve)
                    {
                                Offset (0x18),
                        SPTR,   8,
                        SSTS,   8,
                        SADR,   8,
                        SCMD,   8,
                        SBFR,   256,
                        SCNT,   8,
                                Offset (0x80),
                        B1EX,   1,
                            ,   1,
                        ACEX,   1,
                                Offset (0x81),
                        SWBE,   1,
                        DCBE,   1,
                                Offset (0x82),
                        WLST,   1,
                                Offset (0x83),
                        LIDS,   1,
                                Offset (0x84),
...
                    Method (_Q5E, 0, NotSerialized)
                    {
                        Store (LIDS, \LIDS)
                        Notify (LID0, 0x80)
                    }

                    Method (_Q5F, 0, NotSerialized)
                    {
                        Store (LIDS, \LIDS)
                        Notify (LID0, 0x80)
                    }
Comment 31 Len Brown 2007-12-31 11:57:51 UTC
Steffen,
>  9:       2758    XT-PIC-XT        acpi

Looks like you see a lot of ACPI interrupts also.
While perhaps not directly related tot the problem at hand,
you are running in PIC mode -- does your kernel have IOAPIC
support enabled?  Also, to get the full dmesg back to the
beginning, you need to do something like "dmesg -s64000"
Comment 32 Len Brown 2007-12-31 12:00:07 UTC
re: lots of ACPI interrupts
It would be best to execute the tests on the lid
in single-user mode.  That will get various user-space
utilities that poke /proc/acpi files and cause events
out of the picture so we can focus on just the lid
and the events it causes.
Comment 33 Steffen Pankratz 2007-12-31 17:58:48 UTC
Created attachment 14243 [details]
dmesg.output_complete
Comment 34 Steffen Pankratz 2007-12-31 18:00:22 UTC
grep APIC .config
CONFIG_X86_GOOD_APIC=y
# CONFIG_X86_UP_APIC is not set

Not sure if it's the same you asked for?

I attached new and complete dmesg output 'dmesg.output_complete'.
Comment 35 Len Brown 2008-01-01 10:03:49 UTC
> # CONFIG_X86_UP_APIC is not set

Yes, you want to enable that, as your system has an IOAPIC:

ACPI: APIC 7FEAFF0A, 005A (r1 INTEL  ALVISO    6040000 LOHR       5F)

(While IOAPIC mode is the proper way to run this hardware,
 I don't expect it to have an effect on the problem at hand.)

So please boot up into single user mode and...

grep acpi /proc/interrupts
cat /proc/acpi/event &

# press the power button to see an event come out
# you can also use the sleep button, if you have one,
# or plug/unplug the AC/DC adapter

grep acpi /proc/interrupts

# and now try the lid button to see it provokes events
# and if the LCD backlight comes back even after you wait,
# then type "reboot" to the blank screen...
Comment 36 Steffen Pankratz 2008-01-01 12:00:44 UTC
Created attachment 14247 [details]
dmesg.output
Comment 37 Steffen Pankratz 2008-01-01 12:06:21 UTC
New kernel now running with:

CONFIG_X86_GOOD_APIC=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

and new dmesg output is also attached.

here is the output you wanted:

  9:        146   IO-APIC-fasteoi   acpi
button/power PWRF 00000080 00000001
  9:        147   IO-APIC-fasteoi   acpi
state:      closed
button/lid LID0 00000080 00000001
button/lid LID0 00000080 00000002
state:      open
  9:        155   IO-APIC-fasteoi   acpi

For the lid part:
initial state is closed then I really closed the lid for about 15 seconds and opened it afterwards.
Comment 38 Len Brown 2008-01-04 22:12:03 UTC
can you add some timing detail to that?
ie. does the button/lid even happen immediately
upon hitting the lid switch?  (i expect yes).
And it looks like the state file catches up
with reality -- how long does it take
to switch between incorrect to correct?
Comment 39 Steffen Pankratz 2008-01-05 04:24:41 UTC
 9:        147   IO-APIC-fasteoi   acpi
state:      closed

# 2 lines above show the inital state, lid is closed and count is 147

button/power PWRF 00000080 00000002 Sat Jan 5 13:08:25 CET 2008
  9:        148   IO-APIC-fasteoi   acpi
state:      closed

# after pressing the power button, lid state is still closed and count was incremented

Sat Jan  5 13:09:06 CET 2008

# circa the time I closed the lid

button/lid LID0 00000080 00000001 Sat Jan 5 13:09:18 CET 2008
  9:        152   IO-APIC-fasteoi   acpi
state:      closed

# so it took about 12 seconds till the event occurred 

button/lid LID0 00000080 00000002 Sat Jan 5 13:09:44 CET 2008
  9:        156   IO-APIC-fasteoi   acpi
state:      open

# the lid is now open but it's hard to say if the event occurred while opening the lid because there is no button I could press, I really have to close the lid

I hope this helps you further
Comment 40 Steffen Pankratz 2008-01-06 04:32:07 UTC
I added some audio output to my script (echo -e "\a") :)

When opening the lid again the event is dispatched immediately.

So the main problems are:

1. Initial state of the lid is always 'closed'
2. It takes arround 12 seconds to recognise the lid was closed.
Comment 41 ykzhao 2008-01-23 01:24:24 UTC
Hi, Steffen
   Will you please try the latest kernel(2.6.24-rc8) and do the following test ? It is noted that the acpi debug function should be enabled in kernel configuration.
   a. use the command of "lsof /proc/acpi/event" to get the PID who is using /proc/acpi/event. Kill -9 PID
   b. cat /proc/interrupts > interrupts_before and dmesg > dmesg_before
   c. echo 0x04 > /sys/module/acpi/parameters/debug_layer and echo 0x08000010 > /sys/module/acpi/parameters/debug_level
   d. cat /proc/acpi/event > acpi_event
   e. close LID and reopen it. Then cat /proc/interrupts > interrupts_after and dmesg > dmesg_after

   After the test , will you please attach the above test?
Thanks.
Comment 42 Steffen Pankratz 2008-01-23 14:38:43 UTC
Here we go:

acpi_event is totally empty and dmesg_before and dmesg_after are identical afterwards.

Maybe I did something wrong?

Debugging is enabled:
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
Comment 43 Steffen Pankratz 2008-01-23 14:39:26 UTC
Created attachment 14549 [details]
dmesg_after
Comment 44 Steffen Pankratz 2008-01-23 14:39:49 UTC
Created attachment 14550 [details]
interrupts_before
Comment 45 Steffen Pankratz 2008-01-23 14:40:14 UTC
Created attachment 14551 [details]
interrupts_after
Comment 46 ykzhao 2008-01-23 16:55:40 UTC
Hi, Steffen
   Thanks for the info and what you have done is right.
   From the comment #44 and #45 it seems that no acpi interrupt happens when lid is closed and opened. It is very strange. In theory acpi interrupt should be triggered. 
   Will you please attach the output of "lspci -vvxxx"? 
   Thanks.
Comment 47 Steffen Pankratz 2008-01-24 07:54:09 UTC
This is right there was no acpi event when i opened and closed the lid.
I have done the tests again but this time I waited arround 12 seconds (see Comment  #40) before opening the lid and now I got some events.

I will attach the new files and the lspci output.
Comment 48 Steffen Pankratz 2008-01-24 07:54:38 UTC
Created attachment 14558 [details]
lspci_-vvxxx
Comment 49 Steffen Pankratz 2008-01-24 07:54:56 UTC
Created attachment 14559 [details]
acpi_event test2
Comment 50 Steffen Pankratz 2008-01-24 07:55:12 UTC
Created attachment 14560 [details]
dmesg_before test2
Comment 51 Steffen Pankratz 2008-01-24 07:55:29 UTC
Created attachment 14561 [details]
dmesg_after test2
Comment 52 Steffen Pankratz 2008-01-24 07:55:46 UTC
Created attachment 14562 [details]
interrupts_before test2
Comment 53 Steffen Pankratz 2008-01-24 07:56:14 UTC
Created attachment 14563 [details]
interrupts_after test2
Comment 54 ykzhao 2008-02-04 00:58:36 UTC
Thanks for the info.

What Steffen said in comment #40 is very right. The remaing two problems are
>1. Initial state of the lid is always 'closed'
>2. It takes arround 12 seconds to recognise the lid was closed.

For the problem 1: It is caused by the following:
     Method (_LID, 0, NotSerialized)
            {
                Return (LIDS)  // LIDS is declared in the ACPI_NVS memory and initial value is zero.
            }
      Method (_Q5E, 0, NotSerialized) //Only when the EC triggers acpi interrupt and Q5E/Q5F method is executed , the state of the LID will be update.
              {
               Store (LIDS, \LIDS)
               Notify (LID0, 0x80)
              }

For the problem 2: From the log in comment #44 and #45 there is no ACPI interrupt when LID is closed and opened  in case of no waiting 12 seconds. 
But after waiting about 12 seconds, there is EC interrupt and the state of the lid can be update when LID is closed/opened. 

    Maybe this issue is related to EC hardware. 

    Thanks.
   
                
Comment 55 Steffen Pankratz 2008-02-23 06:28:12 UTC
What's next?
Can I do anything else, helping you to fix this problem?
Comment 56 ykzhao 2008-02-26 00:28:22 UTC
The problem is related with BIOS. Can you upgrade BIOS first and see whether the problem still exists?
Comment 57 Steffen Pankratz 2008-02-26 09:08:28 UTC
There is no BIOS update available :(

See:
http://www.samsungpc.com/products/m50/m50_bios.htm

Why does it work in Windows then?
Comment 58 Zhang Rui 2008-02-27 17:29:18 UTC
Created attachment 15039 [details]
patch: disable ec gpe in gpe handler

Please try the latest kernel with this patch applied. :)
Comment 59 Steffen Pankratz 2008-02-28 11:58:54 UTC
I patched Linux 2.6.24.3, which is the latest stable kernel at the moment.

Here are my observations:

- initial lid state is still closed
- power-button still produces acpi events
- closing the lid does not generate events anymore, even if waiting for more than 12 seconds nothing happend
Comment 60 Steffen Pankratz 2008-02-28 14:18:55 UTC
With your patch the "Fn" key combinations stopped working and unplugging my notebook from ac doesn't lower the display brightness anymore too.
Comment 61 Zhang Rui 2008-03-17 02:02:42 UTC
Please obsolete the patch in #58.
Comment 62 Steffen Pankratz 2008-04-07 09:10:33 UTC
Anything else I can do, to help you to fix this problem?
Comment 63 ykzhao 2008-05-04 02:29:39 UTC
Created attachment 16020 [details]
try the debug patch

Will you please try the debug on the latest kernel and do the following test?
   a. use the command of "lsof /proc/acpi/event" to get the PID who is using
/proc/acpi/event. Kill -9 PID
   b. echo 0x04 > /sys/module/acpi/parameters/debug_layer and echo 0x08000010 >
/sys/module/acpi/parameters/debug_level && echo 1 > /sys/module/printk/parameters/time
   c. close LID (waiting for 10 seconds) and reopen it .

   After the test, please attach the output of dmesg.
   It is noted that the acpi debug function should be enabled in kernel
configuration.
   Thanks.
Comment 64 Steffen Pankratz 2008-05-04 10:30:48 UTC
I had to wait at least for 12 seconds before seeing something in dmesg.
Comment 65 Steffen Pankratz 2008-05-04 10:31:49 UTC
Created attachment 16024 [details]
dmesg output with new patch
Comment 66 ykzhao 2008-05-04 18:23:07 UTC
Thanks for so quick response.
From the log in comment #65 the LID event can be received after the LID is closed and reopened.
>[   49.984539] ACPI: EC: Evaluate _Q5e object 
>[   52.186157] ACPI: EC: Evaluate _Q5f object
And the above two objects will send notification event(0x80) to LID device.
   >                     Store (LIDS, \LIDS)
    >                    Notify (LID0, 0x80)

Will you please confirm whether the windows enter the standby mode immediately after closing the lid? 

> the initial state of the LID is closed.
  IMO the windows doesn't care the initiail state of the LID. Only when the LID is closed will windows receive the LID event and enter the standby mode. And when the LID is reopened, the windows will be waked from the sleeping state.

  Thanks.
Comment 67 ykzhao 2008-05-04 18:28:43 UTC
Created attachment 16026 [details]
try the custom DSDT

Will you please try the custom DSDT and see whether the initial state of the lid is correct?
In the custom DSDT the state of LID is stored to the global variable of LIDS in the course of EC initialization.
> Store(LIDS, \LIDS)

How to use the custom DSDT can be found in the following website:
http://www.lesswatts.org/projects/acpi/faq.php
Comment 68 Steffen Pankratz 2008-05-05 09:44:11 UTC
I'm not sure what do you mean by "the windows"? Do you mean Microsoft Windows?
I have no MS Windows on this notebook but I can ask my sister, she has the same, if it's this what you are asking for.

I tried the custom dsdt:
I compiled the attachment with iasl and configured the kernel and so one,
I had the following problems booting the new kernel:

I couldn't boot because the laptop was shut down:
May  5 18:04:43 hermes kernel: Critical temperature reached (77 C), shutting down.
May  5 18:13:07 hermes kernel: Critical temperature reached (53 C), shutting down.
May  5 18:18:22 hermes kernel: Critical temperature reached (76 C), shutting down.
May  5 18:22:09 hermes kernel: Critical temperature reached (69 C), shutting down.

This never happened before.

Linux console was nearly unusable, hard to describe.

Nvidia driver (blob) could not be loaded anymore
May  5 18:13:17 hermes kernel: NVRM: RmInitAdapter failed! (0x12:0x2b:1550)
May  5 18:13:17 hermes kernel: NVRM: rm_init_adapter(0) failed

I saw some irg problems which also never happened before:

May  5 18:22:09 hermes kernel: irq 16: nobody cared (try booting with the "irqpoll" option)
May  5 18:22:09 hermes kernel: Pid: 1944, comm: S30checkfs Tainted: P       A 2.6.25.1 #3
May  5 18:22:09 hermes kernel:  [__report_bad_irq+0x24/0x90] __report_bad_irq+0x24/0x90
May  5 18:22:09 hermes kernel:  [note_interrupt+0x2c8/0x300] note_interrupt+0x2c8/0x300
May  5 18:22:09 hermes kernel:  [handle_IRQ_event+0x25/0x60] handle_IRQ_event+0x25/0x60
May  5 18:22:09 hermes kernel:  [handle_fasteoi_irq+0xbb/0x100] handle_fasteoi_irq+0xbb/0x100
May  5 18:22:09 hermes kernel:  [do_IRQ+0x45/0x80] do_IRQ+0x45/0x80
May  5 18:22:09 hermes kernel:  [sys_rt_sigprocmask+0x83/0x100] sys_rt_sigprocmask+0x83/0x100
May  5 18:22:09 hermes kernel:  [common_interrupt+0x23/0x28] common_interrupt+0x23/0x28
May  5 18:22:09 hermes kernel:  =======================
May  5 18:22:09 hermes kernel: handlers:
May  5 18:22:09 hermes kernel: [<f8929f20>] (usb_hcd_irq+0x0/0x60 [usbcore])
May  5 18:22:09 hermes kernel: Disabling IRQ #16

I will attach the dmesg output but one good think happened, the lid state was right :)
Comment 69 Steffen Pankratz 2008-05-05 09:45:44 UTC
Created attachment 16029 [details]
dmesg_with_custom_dsdt
Comment 70 ykzhao 2008-05-05 20:10:59 UTC
Hi, 
   Thanks for the test.
   It seems that the LID initial state is right after the custom DSDT is used. But it brings some new problems.
   Will you please confirm whether the problems in comment #68 exists if not using the custom DSDT?

   Maybe what I said in comment #66 is not very clear. 
a. About the initial state of the LID even when the LID is open
   Maybe the microsoft windows doesn't care the initial state of the LID. It only cares whether the LID button is pressed and the LID event is received. When it receivces the LID event that the LID is pressed, it will enter the standby mode. 
   In fact the problem is caused by the broken bios. If the state of LID is stored to the global variable of LIDS in the course of EC initialization, we can get the correct state of the LID using /proc/acpi/button/lid/LID0/state.

b. takes 12 seconds to receive the LID event when the LID is pressed.
   From the log in comment #65 the LID event can be received when LID is pressed. But it need wait for 12 seconds to recognize the state of the LID.
   We had better confirm whether the windows enter the standby mode immedidately after the LID is pressed. If no, I think that it is related with BIOS.
   
   Please test it on your sister's laptop.
   Thanks.

   
Comment 71 Steffen Pankratz 2008-05-06 09:40:02 UTC
Just to make sure, maybe you mixed something up, did you use my acpi dump to create the custom DSDT, there are two attached to this bug report?

All problems I described in #c86 only occur if I boot the kernel which was patched with the custom DSDT.

I called my sister and she had to perform some tests with her notebook :)
It's the same on MS Windows, after closing the lid it takes about 12 seconds before the notebook starts to enter suspend mode.
Maybe this delay is a feature?
Comment 72 ykzhao 2008-05-06 18:57:38 UTC
Hi, Steffen
    Thanks for the test. 
    Sorry for my fault. I mixed the acpidump file on your laptop with another. But anyway it points the root cause that the initial state of the LID is closed when using the interface of /proc/acpi/button/LID0/state. It is caused by the following:
   > Method (_LID, 0, NotSerialized)
            {
    >            Return (LIDS)  // LIDS is declared in the ACPI_NVS memory and
initial value is zero.
     >       } 
  When the LID button is pressed, the _Q5E/_Q5F object will be executed and the state of the LID can be updated correctly.
   >                     Store (LIDS, \LIDS)
   >                    Notify (LID0, 0x80)

  And if the LID state is stored to the global variable \LIDS in the custom DSDT, we will get the correct LID state using /proc/acpi/button/LID0/state.
   >  Method (_REG, 2, NotSerialized)            {
 >                       If (LAnd (LEqual (Arg0, 0x03), LEqual (Arg1, One)))
  >                      {
>                                Store(LIDS, \LIDS)

b. takes 12 seconds to receive the LID event when the LID is pressed 
   According to the test on Windows it seems that it also takes about 12 seconds before the notebook starts to enter suspend mode after closing the LID. IMO this is related with the BIOS. Maybe the delay is a feature of this laptop. 

   Since the two above issuse are caused by BIOS and can't be fixed in Linux ACPI, IMO this bug can be closed. 

   Thanks.
   
   
   
   
Comment 73 Steffen Pankratz 2008-05-07 09:00:05 UTC
Thank you very much for your help Yakui, but could you do me a last favour and fix
the DSDT for me, as I have now knowledge of this stuff.

This can be closed then, thanks.
Comment 74 ykzhao 2008-05-07 22:23:13 UTC
Created attachment 16062 [details]
the custom DSDT

Hi, Steffen
    The attached is the custom DSDT based on your ACPIDUMP.
    The lid state is stored to the global \LIDS variable in the course of EC initialization. 
  >  Method (_REG, 2, NotSerialized)                {
>                        If (LAnd (LEqual (Arg0, 0x03), LEqual (Arg1, One)))
                        {
 >                               Store(LIDS, \LIDS)
  >                          Store (One, ECON)
   >                         Store (ACEX, PWRS)

   And thanks for your help.
Comment 75 Steffen Pankratz 2008-05-08 13:42:50 UTC
Thank you very much Yakui, everything is still working fine with the patched DSDT and the lid state is also correct.

I will close this bug report now.

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