Bug 1752 - no ACPI GPE events unless "irqpoll" - Dell Inspiron 5150
Summary: no ACPI GPE events unless "irqpoll" - Dell Inspiron 5150
Status: CLOSED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Len Brown
URL:
Keywords:
: 2251 7019 11857 vaio (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-27 00:20 UTC by Michael McCaskill
Modified: 2011-07-30 04:55 UTC (History)
24 users (show)

See Also:
Kernel Version: 2.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
A01 Bios (782.03 KB, application/x-bzip2)
2004-04-16 15:50 UTC, Robert Paskowitz
Details
Dell Inspiron 5150 dsdt (3.78 KB, application/octet-stream)
2004-05-26 00:40 UTC, Ivo Bitter
Details
Laptop configuration information (52.54 KB, application/octet-stream)
2004-08-02 18:45 UTC, Jason Bouzane
Details
dmesg from my 2.6.10-rc2 kernel (15.04 KB, text/plain)
2004-12-03 03:54 UTC, Jakob Schi
Details
dmesg from my 2.6.10-rc2 kernel (15.04 KB, text/plain)
2004-12-03 03:55 UTC, Jakob Schi
Details
Output from acpidmp on a 2.6.10-rc2 kernel (42.71 KB, text/plain)
2004-12-07 04:54 UTC, Jakob Schi
Details
My .config file (28.13 KB, text/plain)
2005-06-10 11:39 UTC, Jakob Schi
Details
dmesg wiith acpi_dbg_layer=4 acpi_dbg_level=0xFFFFFFFF (48.09 KB, text/plain)
2006-10-10 22:17 UTC, Len Brown
Details
try the debug patch (1.17 KB, patch)
2008-03-17 23:53 UTC, ykzhao
Details | Diff
dmesg after patch comment #110 (24.34 KB, text/plain)
2008-07-19 23:21 UTC, alwin
Details
lspci -vxxx after patch comment #110 (20.68 KB, text/plain)
2008-07-19 23:31 UTC, alwin
Details
try the debug patch to see whether the problem still exists (1000 bytes, patch)
2008-07-21 19:45 UTC, ykzhao
Details | Diff
dmesg after patch comment #110 and comment #117 (24.62 KB, text/plain)
2008-07-22 11:56 UTC, alwin
Details
lspci -vxxx after patch comment #110 and comment #117 (20.68 KB, text/plain)
2008-07-22 11:57 UTC, alwin
Details
metalog after patch comment #110 and comment #117 (75.74 KB, text/plain)
2008-07-22 12:12 UTC, alwin
Details
try the debug patch to confirm whether the problem still exists (1.08 KB, patch)
2008-08-25 23:30 UTC, ykzhao
Details | Diff
try the updated debug patch (1.07 KB, patch)
2008-08-26 17:45 UTC, ykzhao
Details | Diff
dmesg after patch comment #125 (26.70 KB, text/plain)
2008-08-27 12:29 UTC, alwin
Details
lspci -vxxx after patch comment #125 (20.39 KB, text/plain)
2008-08-27 12:31 UTC, alwin
Details
metalog after patch comment #125 (37.01 KB, text/plain)
2008-08-27 12:46 UTC, alwin
Details
call the _WAK object after ACPI full initialization (933 bytes, patch)
2009-03-04 17:52 UTC, ykzhao
Details | Diff
lspci -vxxx after comment #130 and comment #131 (124.41 KB, text/plain)
2009-03-14 07:43 UTC, alwin
Details
metalog after comment #130 and comment #131 (17.01 KB, text/plain)
2009-03-14 07:48 UTC, alwin
Details

Description Michael McCaskill 2003-12-27 00:20:33 UTC
Distribution: Gentoo
Hardware Environment: Dell Inspiron 5150
Software Environment: 2.6 kernel with ACPI builtin but tried modules
Problem Description: Button and lid events do not work at all. The event is not 
getting transmitted. Using acpid does nothing. Works correctly in 2.4 series.

Steps to reproduce:
Comment 1 Luming Yu 2004-01-06 21:58:03 UTC
At first, you need post full dmesg.
Comment 2 James Kyle 2004-01-07 16:13:18 UTC
I'm not the original poster, but have the same problem. Here is my dmesg:

Linux version 2.6.0-mm1 (root@laptop) (gcc version 3.2.3 20030422 (Gentoo Linux
1.4 3.2.3-r3, propolice)) #1 Fri Jan 2 16:02:08 CST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000017fcf800 (usable)
 BIOS-e820: 0000000017fcf800 - 0000000018000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec20000 (reserved)
 BIOS-e820: 00000000feda0000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
383MB LOWMEM available.
On node 0 totalpages: 98255
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 94159 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 DELL                                      ) @ 0x000fdea0
ACPI: RSDT (v001 DELL    CPi R   0x27d30c0a ASL  0x00000061) @ 0x17ff0000
ACPI: FADT (v001 DELL    CPi R   0x27d30c0a ASL  0x00000061) @ 0x17ff0400
ACPI: MADT (v001 DELL    CPi R   0x27d30c0a ASL  0x00000047) @ 0x17ff0c00
ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000
Building zonelist for node : 0
Kernel command line: root=/dev/hdc2 idebus=66 vga=0x31A video=vesa:ywrap,mtrr
noresume
ide_setup: idebus=66
current: c0437a60
current->thread_info: c04c4000
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 3056.959 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Memory: 384036k/393020k available (2778k kernel code, 8232k reserved, 1076k
data, 248k init, 0k highmem)
zapping low mappings.
Calibrating delay loop... 6045.69 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU:     After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU:     After vendor identify, caps: bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU:     After all inits, caps: bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU: Intel Mobile Intel(R) Pentium(R) 4     CPU 3.06GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfcf1e, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031203
 tbxface-0117 [03] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control
Methods:..........................................................................................................................................
Table [DSDT](id F004) - 351 Objects with 58 Devices 138 Methods 5 Regions
ACPI Namespace successfully loaded at root c051ce7c
ACPI: IRQ9 SCI: Edge set to Level Trigger.
evxfevnt-0093 [04] acpi_enable           : Transition to ACPI mode successful
evgpeblk-0747 [06] ev_create_gpe_block   : GPE 00 to 31 [_GPE] 4 regs at
0000000000001028 on int 9
Completing Region/Field/Buffer/Package
initialization:.............................................................
Initialized 5/5 Regions 8/8 Fields 21/21 Buffers 27/27 Packages (359 nodes)
Executing all Device _STA and_INI
methods:............................................................
60 Devices found containing: 60 _STA, 3 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7)
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fe2d0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xe2f4, dseg 0x40
pnp: 00:01: ioport range 0x1000-0x105f has been reserved
pnp: 00:01: ioport range 0x1060-0x107f has been reserved
pnp: 00:01: ioport range 0x1080-0x10bf has been reserved
pnp: 00:01: ioport range 0x10c0-0x10ff has been reserved
pnp: 00:01: ioport range 0xf400-0xf4fe has been reserved
PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver
i8k: unable to get SMM Dell signature
i8k: unable to get SMM BIOS version
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
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 11
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
vesafb: framebuffer at 0xd0000000, mapped to 0xd8806000, size 16384k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:e280
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
Machine check exception polling timer started.
cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
ikconfig 0.7 with /proc/config*
devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
udf: registering filesystem
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: AC Adapter [AC] (off-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Processor [CPU0] (supports C1 C2 C3, 8 throttling states)
ACPI: Thermal Zone [THM] (25 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Console: switching to colour frame buffer device 160x64
pty: 256 Unix98 ptys configured
request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
hw_random: cannot enable RNG, aborting
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 855GM Chipset.
agpgart: Maximum main memory to use for agp memory: 321M
agpgart: AGP aperture is 128M @ 0xe0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
Using anticipatory io scheduler
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
b44.c:v0.92 (Nov 4, 2003)
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0d:56:36:87:7e
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 66MHz system bus speed for PIO modes
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio
hda: _NEC DVD+RW ND-5100A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: FUJITSU MHT2060AT PL, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: max request size: 128KiB
hdc: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)
 /dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4 < p5 p6 >
end_request: I/O error, dev hda, sector 0
cdrom: : unknown mrw mode page
hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ohci1394: $Rev: 1045 $ Ben Collins <bcollins@debian.org>
ohci1394_0: OHCI-1394 1.1 (PCI): IRQ=[11]  MMIO=[faffd800-faffdfff]  Max
Packet=[2048]
Console: switching to colour frame buffer device 160x64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 11, pci mem d9843c00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
uhci_hcd 0000:00:1d.0: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 11, io base 0000bf80
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 11, io base 0000bf40
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: UHCI Host Controller
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[4a4fc0001ddf3c61]
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 11, io base 0000bf20
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
drivers/usb/core/usb.c: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
i8042.c: Warning: Keylock active.
serio: i8042 AUX port at 0x60,0x64 irq 12
Synaptics Touchpad, model: 1
 Firmware: 5.9
 Sensor: 37
 new absolute packet format
 Touchpad has extended capability bits
 -> multifinger detection
 -> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
EISA: Probing bus 0 at eisa0
Advanced Linux Sound Architecture Driver Version 0.9.7 (Thu Sep 25 19:16:36 2003
UTC).
request_module: failed /sbin/modprobe -- snd-card-0. error = -16
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49442 usecs
intel8x0: clocking to 48000
ALSA device list:
  #0: Intel 82801DB-ICH4 at 0xf4fff800, irq 11
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
cpufreq: No CPUs supporting ACPI performance management found.
BIOS EDD facility v0.10 2003-Oct-11, 1 devices found
Please report your BIOS at http://domsch.com/linux/edd30/results.html
Resume Machine: disabled
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S3 S4 S4bios S5)
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 248k freed
Unable to find swap-space signature
EXT3 FS on hdc2, internal journal
pcmcia_core: no version for "struct_module" found: kernel tainted.
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
Yenta: CardBus bridge found at 0000:02:02.0 [12a3:ab01]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta: ISA IRQ mask 0x0000, PCI irq 11
Socket status: 30000010
PCI: Enabling device 0000:02:04.0 (0000 -> 0002)
Yenta: CardBus bridge found at 0000:02:04.0 [1028:015f]
Yenta: ISA IRQ mask 0x04f8, PCI irq 11
Socket status: 30000006
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
orinoco_cs.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdc5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdc6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Unable to find swap-space signature
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: excluding 0x800-0x807
cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
eth1: Station identity 001f:0001:0008:000a
eth1: Looks like a Lucent/Agere firmware version 8.10
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:02:2D:6E:02:E0
eth1: Station name "HERMES I"
eth1: ready
eth1: index 0x01: Vcc 3.3, irq 11, io 0x0100-0x013f
b44: eth0: Link is down.
b44: eth0: Link is up at 10 Mbps, half duplex.
b44: eth0: Flow control is off for TX and off for RX.
nvidia: no version magic, tainting kernel.
nvidia: module license 'NVIDIA' taints kernel.
0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module  1.0-5328  Wed Dec 17
13:54:51 PST 2003
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
no device found
no device found
no device found
no device found
b44: eth0: Link is down.
b44: eth0: Link is up at 10 Mbps, half duplex.
b44: eth0: Flow control is off for TX and off for RX.
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Comment 3 Michael McCaskill 2004-01-07 20:16:23 UTC
I am the originator. Here is my dmesg:
IC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, IRQ 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 BALANCE SET
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Building zonelist for node : 0
Kernel command line: root=/dev/hdc4 video=vesa:ywrap,mtrr vga=795
current: c042f1a0
current->thread_info: c04bc000
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 3057.144 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Memory: 513652k/524092k available (2774k kernel code, 9696k reserved, 1044k
data, 184k init, 0k highmem)
Calibrating delay loop... 6045.69 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU:     After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU:     After vendor identify, caps: bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU:     After all inits, caps: bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel Mobile Intel(R) Pentium(R) 4     CPU 3.06GHz stepping 09
per-CPU timeslice cutoff: 1462.68 usecs.
task migration cache decay timeout: 2 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 3000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 6094.84 BogoMIPS
CPU:     After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU:     After vendor identify, caps: bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU:     After all inits, caps: bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU#1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#1: Thermal monitoring enabled
CPU1: Intel Mobile Intel(R) Pentium(R) 4     CPU 3.06GHz stepping 09
Total of 2 processors activated (12140.54 BogoMIPS).
cpu_sibling_map[0] = 1
cpu_sibling_map[1] = 0
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not
connected.
..TIMER: vector=0x31 pin1=2 pin2=0
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 3056.0012 MHz.
..... host bus clock speed is 132.0869 MHz.
checking TSC synchronization across 2 CPUs: 
BIOS BUG: CPU#0 improperly initialized, has -5120 usecs TSC skew! FIXED.
BIOS BUG: CPU#1 improperly initialized, has 5120 usecs TSC skew! FIXED.
Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 8
zapping low mappings.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfcf1e, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031203
 tbxface-0117 [03] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control
Methods:.........................................................................................................................................
Table [DSDT](id F004) - 354 Objects with 58 Devices 137 Methods 7 Regions
ACPI Namespace successfully loaded at root c0508c7c
IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:1 Active:0)
evxfevnt-0093 [04] acpi_enable           : Transition to ACPI mode successful
evgpeblk-0747 [06] ev_create_gpe_block   : GPE 00 to 31 [_GPE] 4 regs at
0000000000001028 on int 9
Completing Region/Field/Buffer/Package
initialization:.............................................................
Initialized 7/7 Regions 8/8 Fields 21/21 Buffers 25/25 Packages (362 nodes)
Executing all Device _STA and_INI
methods:.............................................................
61 Devices found containing: 61 _STA, 3 _INI methods
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7)
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fe2d0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xe2f4, dseg 0x40
pnp: 00:01: ioport range 0x1000-0x105f has been reserved
pnp: 00:01: ioport range 0x1060-0x107f has been reserved
pnp: 00:01: ioport range 0x1080-0x10bf has been reserved
pnp: 00:01: ioport range 0x10c0-0x10ff has been reserved
pnp: 00:01: ioport range 0xf400-0xf4fe has been reserved
PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver
SCSI subsystem initialized
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1)
00:00:1f[A] -> 2-16 -> IRQ 16
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1)
00:00:1f[B] -> 2-17 -> IRQ 17
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb9 -> IRQ 18 Mode:1 Active:1)
00:00:1f[C] -> 2-18 -> IRQ 18
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19 Mode:1 Active:1)
00:00:1f[D] -> 2-19 -> IRQ 19
Pin 2-16 already programmed
Pin 2-19 already programmed
Pin 2-18 already programmed
IOAPIC[0]: Set PCI routing entry (2-23 -> 0xc9 -> IRQ 23 Mode:1 Active:1)
00:00:1d[D] -> 2-23 -> IRQ 23
Pin 2-16 already programmed
Pin 2-17 already programmed
IOAPIC[0]: Set PCI routing entry (2-20 -> 0xd1 -> IRQ 20 Mode:1 Active:1)
00:01:00[A] -> 2-20 -> IRQ 20
Pin 2-16 already programmed
Pin 2-16 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-17 already programmed
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00178020
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0020
.... register #02: 00000000
.......     : arbitration: 00
.... register #03: 00000001
.......     : Boot DT    : 1
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 0FF 0F  0    0    0   0   0    1    1    39
 02 0FF 0F  0    0    0   0   0    1    1    31
 03 0FF 0F  0    0    0   0   0    1    1    41
 04 0FF 0F  0    0    0   0   0    1    1    49
 05 0FF 0F  0    0    0   0   0    1    1    51
 06 0FF 0F  0    0    0   0   0    1    1    59
 07 0FF 0F  0    0    0   0   0    1    1    61
 08 0FF 0F  0    0    0   0   0    1    1    69
 09 003 03  0    1    0   0   0    1    1    71
 0a 0FF 0F  0    0    0   0   0    1    1    79
 0b 0FF 0F  0    0    0   0   0    1    1    81
 0c 0FF 0F  0    0    0   0   0    1    1    89
 0d 0FF 0F  0    0    0   0   0    1    1    91
 0e 0FF 0F  0    0    0   0   0    1    1    99
 0f 0FF 0F  0    0    0   0   0    1    1    A1
 10 003 03  1    1    0   1   0    1    1    A9
 11 003 03  1    1    0   1   0    1    1    B1
 12 003 03  1    1    0   1   0    1    1    B9
 13 003 03  1    1    0   1   0    1    1    C1
 14 003 03  1    1    0   1   0    1    1    D1
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 003 03  1    1    0   1   0    1    1    C9
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9-> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ23 -> 0:23
.................................... done.
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
vesafb: framebuffer at 0xd0000000, mapped to 0xe080a000, size 16384k
vesafb: mode is 1280x1024x32, linelength=5120, pages=0
vesafb: protected mode interface info at c000:e280
vesafb: scrolling: redraw
vesafb: directcolor: size=8:8:8:8, shift=24:16:8:0
fb0: VESA VGA frame buffer device
Machine check exception polling timer started.
cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
Starting balanced_irq
devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
NTFS driver 2.1.5 [Flags: R/O].
udf: registering filesystem
ACPI: AC Adapter [AC] (off-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Processor [CPU0] (supports C1, 8 throttling states)
ACPI: Processor [CPU1] (supports C1, 8 throttling states)
ACPI: Thermal Zone [THM] (31 C)
Console: switching to colour frame buffer device 160x64
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 855GM Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 128M @ 0xe0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
pktcdvd: v0.0.3a 07/04/2003 Jens Axboe (axboe@suse.de)
b44.c:v0.92 (Nov 4, 2003)
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0d:56:ac:5a:f9
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)
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio
hda: QSI CD-RW/DVD-ROM SBW-242, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: HTS726060M9AT00, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: max request size: 1024KiB
hdc: 117210240 sectors (60011 MB) w/7877KiB Cache, CHS=16383/255/63, UDMA(100)
 /dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4
cdrom: : unknown mrw mode page
hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ohci1394: $Rev: 1087 $ Ben Collins <bcollins@debian.org>
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16]  MMIO=[faffd800-faffdfff]  Max
Packet=[2048]
Console: switching to colour frame buffer device 160x64
PCI: Enabling device 0000:02:04.0 (0000 -> 0002)
Yenta: CardBus bridge found at 0000:02:04.0 [1028:015f]
Yenta: ISA IRQ mask 0x0cf8, PCI irq 16
Socket status: 30000006
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 23, pci mem e183ac00
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[334fc0000bb76861]
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
uhci_hcd 0000:00:1d.0: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 16, io base 0000bf80
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 19, io base 0000bf40
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 18, io base 0000bf20
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
drivers/usb/core/usb.c: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
i8042.c: Warning: Keylock active.
serio: i8042 AUX port at 0x60,0x64 irq 12
Synaptics Touchpad, model: 1
 Firmware: 5.9
 Sensor: 37
 new absolute packet format
 Touchpad has extended capability bits
 -> multifinger detection
 -> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
Advanced Linux Sound Architecture Driver Version 1.0.1 (Tue Dec 30 10:04:14 2003
UTC).
request_module: failed /sbin/modprobe -- snd-card-0. error = -16
PCI: Setting latency timer of device 0000:00:1f.5 to 64
input: AT Translated Set 2 keyboard on isa0060/serio0
MC'97 1 converters and GPIO not ready (0xff00)
intel8x0_measure_ac97_clock: measured 49441 usecs
intel8x0: clocking to 48000
ALSA device list:
  #0: Intel 82801DB-ICH4 at 0xf4fff800, irq 17
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S1 S3 S4 S4bios S5)
found reiserfs format "3.6" with standard journal
Reiserfs journal params: device hdc4, size 8192, journal first block 18, max
trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (hdc4) for (hdc4)
Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 184k freed
nvidia: no version magic, tainting kernel.
nvidia: module license 'NVIDIA' taints kernel.
0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module  1.0-5328  Wed Dec 17
13:54:51 PST 2003
b44: eth0: Link is down.
Comment 4 James Kyle 2004-01-13 12:56:06 UTC
Please let me know if you need anything else to work on this and I will post it.
Also let me know if there is anything I can do in general to help.
Comment 5 Michael McCaskill 2004-01-13 13:16:15 UTC
I thinks I have traced the problem to a broken DSDT. I am trying to fix it and 
I will let you know of my results. Thanks so much for all your help.
Comment 6 James Kyle 2004-02-01 09:33:13 UTC
I decompiled my DSDT and than fixed the only error (had to do with a WAK_ call).
However I'm also getting a 2033 warning with S0D. When I looked at the code it
seemed to reference usb devices. I couldn't find a fix to this particular
warning and I still have no events with LID and PWBTN though dmesg reports them
as detected.


Any progress?
Comment 7 Luming Yu 2004-02-10 17:20:03 UTC
Firstly, could you please confirm that 2.4 kernel works well with Power 
button, Sleep button and Lid switch but 2.6 not. I'm rather unsure.

Secondly, could you post the buggy ASL code that you are working on.

Ps. Don't directly post huge dmesg or .config on comments column. It should be
in the attachment column.
Comment 8 Robert Paskowitz 2004-02-26 21:50:07 UTC
I can confirm that the buttons and switches worked with 2.4 series kernels and 
not 2.6, up to and including 2.6.3. 
Comment 9 Gregor von Stangen 2004-03-01 01:01:06 UTC
I for myself CANNOT confirm that the buttons and switches were running in 2.4
series kernels. I'm very curious, how Robert made it run. What BIOS and kernel
version did you use ?
Comment 10 horton wood 2004-03-08 20:42:28 UTC
I am currently experiencing this bug on my new dell 5100. The last comment with
the usb references seems to confirm it for me. I can get my lid and button
events to only occur in this situation. I close my lid, It doesn't turn off, if
I then plug a usb device in my lid closing event shows up and my display turns
off.(Which is really annoying I might add) I have built a ton of kernels testing
it, but only used 2.6.3 and 2.6.4-rc1. 
I changed tons of options in my kernel, disabled devices, moved static things
around to modules, passed arguments at boot and still can replicate this exact
same problem every time. I also have 4 dell 5100 laptops 2 of which run gentoo
with 2.6.3+ kernels and have this same problem. I believe the bios version they
shipped them with is A28.
Comment 11 Shaohua 2004-03-14 22:52:12 UTC
*** Bug 2251 has been marked as a duplicate of this bug. ***
Comment 12 Jason Bouzane 2004-03-14 23:04:16 UTC
Bug 2251 has been marked as a duplicate of this one. That is because it has the 
same cause, but a different effect: the battery still appears to be present 
when you remove it. I checked and if I unplug a USB device and plug it in again 
after I remove the battery, I get acpi interrupts (I usually don't get any; the 
count is at 0), and the battery does show as being removed. 
Comment 13 Shaohua 2004-03-14 23:24:08 UTC
this is funny. did the power button work after unplug/plug USB device? please 
add the /proc/interrupts after that.
Comment 14 Jason Bouzane 2004-03-14 23:31:20 UTC
OK, this is weird. If I unplug/plug in my USB mouse without touching the power 
button/battery/etc. then the acpi interrupt counter doesn't change. If I press 
the power button, then unplug and plug in the USB mouse, then the acpi 
interrupt counter goes up. Note that unplugging doesn't change it. Only 
plugging back in again will cause it to change. 
Comment 15 Jason Bouzane 2004-03-14 23:36:57 UTC
Actually, that's not quite right, upon further investigation. It seems to 
change the acpi interrupt counter only if I wait longer than about half a 
second before plugging it in again. If I pull it out and put it in again as 
fast as I can, the counter doesn't change. 
Comment 16 Jason Bouzane 2004-03-14 23:41:36 UTC
And, just in case this is useful, here is the diff before and after 
unplugging/plugging in the mouse: 
 
<   9:      60554   IO-APIC-level  acpi 
--- 
>   9:      64898   IO-APIC-level  acpi 
 
Comment 17 Shaohua 2004-03-14 23:55:17 UTC
<   9:      60554   IO-APIC-level  acpi 
--- 
>   9:      64898   IO-APIC-level  acpi 
so many interrupt. please apply the patch in Bug 2200, any difference?
Comment 18 Jason Bouzane 2004-03-15 00:06:17 UTC
No better: 
 
<   9:      13066   IO-APIC-level  acpi 
--- 
>   9:      16131   IO-APIC-level  acpi 
 
Comment 19 horton wood 2004-03-15 07:17:54 UTC
Tested the patch on ck-sources 2.6.4-ck1 and still am only able to get events to
occur if I plug a usb device in.
In other words the patch doesn't fix it.
Comment 20 Robert Paskowitz 2004-03-15 08:44:30 UTC
With the original buggy BIOS, back when there was no way to hit the 3,06ghz 
mark, ACPI worked relatively well. The LCD went off at the bios level, and 
sleep mode 1 worked, (I didn't test 3 or 4, because this was back in Auguest, 
pre-2.6). After the upgrade to I believe the Pheonix bios, stuff started to go 
wrong. 
 
I do recall getting events with a 2.4 kernel, after the large upgrade, but I 
am afraid it was so long ago, I can't remember the specific configuration. 
 
On another note, following stuff here, I do now notice that after doing stuff 
that should trigger events, unplugging a USB device and putting it back in has 
them show up in a flood. 
 
Back at the beginning of February, James Kyle commented on decompiling the 
dsdt, and having the remaining issues that refered to USB stuff. That seems 
like a pretty good lead, and while I have looked at the dsdt briefly, it's a 
bit over my head. Perhaps someone else here might take a look? 
Comment 21 Daniel Block 2004-03-15 23:22:46 UTC
Here is what I can tell you I have personally got working from my experiences.
First Robert was correct that the older bios versions like A02 (I think) did
work with ACPI, but unfurtunatly they did not work with cpu throttling. 

Now I have also gotten 2.4.22 to work with Redhat 9 only. Meaning if I try 2.6
kernels it didn't work and if I tried the same config on another distro like
Slackware, it did not work as well. This I find to be very wierd. I may be
missing something but that is what I have experienced. I have tried just about
everything to get the ACPI buttons to work with Slackware, but I can't get it to
work. Since the DSDT is a bit over my head, I have basically given up until
someone else can get it to work. I hope this adds something useful.

Dan Block
Comment 22 Shaohua 2004-03-16 00:31:24 UTC
So please attach the the acpidmp from the older BIOS and the newer one. Let's 
have a look at the difference.
Comment 23 Robert Paskowitz 2004-03-16 06:05:11 UTC
It'll be tough to get that dump, all the new models ship with the newer bios, 
and I don't know of anyone that has not made this upgrade. Furthermore, once 
the 'major' upgrade is done, you cannot easily revert, even if dell were to 
release it. On the site, no file for the A03 is available.
Comment 24 Jason Bouzane 2004-03-16 08:43:12 UTC
This is starting to seem like the type of bug that can't be fixed without 
access to the hardware... Maybe I'll take a look at it this summer when I have 
more time and see if I can come up with a kernel patch to fix it. 
 
FYI: after playing with it some more, that patch seems to have made a 
difference. Now, with that patch applied, I don't get any ACPI interrupts 
regardless of what I do with the USB device. I'm not sure what changed... Maybe 
it just needed a full power off. 
Comment 25 Robert Paskowitz 2004-03-18 05:38:48 UTC
Who would like to be the first to give the 2 new flashes a test? A32 says it 
fixes:  
1. Update new Nvidia video BIOS. 
2. Fixed the system fails to complete post with targus apr in the top usb 
port. 
 
And A33: 
1. Support Simplo(SDI cell) & Sanyo battery on Inspiron 5150. 
 
Of course, who know what really goes in....Also, on a sort-of off topic 
question, do you any of have a way to flash without booting windows? (Please 
respond privately not to the bug) 
Comment 26 horton wood 2004-03-22 20:25:33 UTC
I have just installed linux-2.6.5-rc2-mm1 on my Inspiron 5100 and I can now
close my lid and my display shuts off. I am stoked I did it like 50 times in a
row just cause I was so happy.

Thanks kernel folks.
Comment 27 Robert Paskowitz 2004-03-22 22:07:49 UTC
On Dell 5150, with bios A24, tried the 2.6.5-rc1-mm1 kernel, and report that 
the LCD stays on when lid is shut, as well, no event is captured 
in /proc/acpi/event. 
Comment 28 Robert Paskowitz 2004-03-22 22:41:08 UTC
Sorry about the useless comment above, I only realized after posting that it 
was for -rc2, and not -rc1. On that note, I compiled -rc2, and got an odd 
lockup on boot after mounting devfs on /dev. Not a kernel panic, numlock et al 
still worked, but it was frozen pretty solid besides that. I presume there is 
another underlying issue for that, so I cannot confirm whether or not this 
kernel will shut off the LCD. 
Comment 29 Jason Bouzane 2004-03-22 23:31:43 UTC
I was about to post the same thing. I am seeing lockups with the 2.6.5rc2-mm1 
kernel on boot as well. It's not a panic but it is frozen solid. I can't get 
much information, but here's what I do know: 
 
The kernel usually freezes immediately AFTER executing the stuff in initrd. If 
I remove initrd, the kernel usually freezes just before it announces that it 
freed x amount of unused memory and starts Init 2.85. 
 
However, this isn't set in stone. Twice, I was able to get the kernel to finish 
rc.sysinit, but it hasn't managed to get into runlevel five at all. It froze 
just as it said it was entering it. 
 
Note that I didn't so much as lay my hands on the keyboard so it's nothing I'm 
doing that's causing it to lock up in different places. 
Comment 30 Jason Bouzane 2004-03-22 23:32:37 UTC
Oh, I should also add that I'm using a 5150 with the A29 BIOS. 
Comment 31 Jason Bouzane 2004-03-22 23:49:39 UTC
Just upgraded to A33 and it booted to a login prompt before freezing. I'm 
guessing it was a fluke. 
Comment 32 horton wood 2004-03-23 07:53:24 UTC
Ok, sorry for my sparse post lastnight. I am back to help confirm that acpi
events are now working in 2.6.5-rc2-mm1 on my dell Inspirion 5100. First of all
I use udev in my kernel and no longer use devfsd. The only additional patch I
added to my kernel was bootsplash. After I boot up and login via X and close my
lid I still see the problem I was originally having with no acpi events. If I
then go and plug a usb device in and close my lid the acpi events work.
Previously I would only get one event through and I would have to then unplug
and replug my usb mouse back in to trigger the next lid open event. Now tho I
have found that after the initial usb device is plugged in, acpi events continue
to work without having to replug the usb device in. Meaning you gotta do it once
and then it works every time after that on it's own. I will include my kernel
.config and my /etc/acpi and any additional shell scripts I use.
http://dev.gentoo.org/~horton/linux-2.6.5-rc2-mm1.config
http://dev.gentoo.org/~horton/acpi.tgz

Mine is working even tho it is a little buggy on the startup.
Comment 33 Jason Bouzane 2004-03-24 23:40:02 UTC
I tried that config file as well as a couple of variations on it and I still 
can't get this machine to boot. However, I am not using udevfs; I'm using 
devfs. Does anyone know if this is a Bad Thing with this kernel? Or should it 
still work? Starting with devfs=nomount doesn't seem to help either, and, in 
fact, I've seen freezes before the devfs service even starts, so I'm skeptical 
that devfs is causing this. 
 
Sorry that I haven't had a chance to actually track down what's going on, but 
this is definitely not a good time for me to be debugging this problem. 
Comment 34 Andrew Beard 2004-03-29 13:39:51 UTC
I finally got 2.6.5-rc2-mm5 working (^%*$*#% devfs bug and 4K stacks) on my
Inspiron 5150 (A33).  Still no love with the acpi events for lid closing.
Comment 35 Luming Yu 2004-04-01 01:26:04 UTC
Could you send me /proc/acpi/dsdt ?  --Luming 
Comment 36 Robert Paskowitz 2004-04-16 15:50:08 UTC
Created attachment 2609 [details]
A01 Bios

This is a bzip2 of an iso direct from dell that contains the i5150 A01 bios
flash. (Recently received with a replacement lcd for some unknown reason). I
don't have time myself right now, but perhaps if someone got this on their
computer, the DSDT might be something useful/revealing as this is before the
move away from the pure phoenix bios.
Comment 37 Luming Yu 2004-05-17 23:54:33 UTC
There will have Wakeup/runtime GPE related codes changes released in the recent
days. Maybe you can help with testing if it can help this cases.

Thanks,
Luming
Comment 38 Jason Bouzane 2004-05-20 18:17:01 UTC
Could you give a little more information about what these changes are and how 
we should test them?
Comment 39 Luming Yu 2004-05-26 00:01:57 UTC
To comment #36, I don't want the BIOS image, because it is useless to me.
What I want is /proc/acpi/dsdt.
--Luming
Comment 40 Ivo Bitter 2004-05-26 00:40:20 UTC
Created attachment 2976 [details]
Dell Inspiron 5150 dsdt

Dell Inspiron 5150 dsdt (my bios version is A33)
Comment 41 Jason Bouzane 2004-05-26 18:55:37 UTC
I've been doing some perfunctory debugging of this problem over the last few 
days and so far have been totally unsuccessful in figuring out what's going 
on. Could anyone more knowledgeable about this provide any tips on what to 
look at or test when I'm debugging? Thanks. 
Comment 42 Ivo Bitter 2004-06-25 15:35:06 UTC
I just upgraded to 2.6.7-mm2, and the situation seems to have worsened. even
with the usb (un)plugging described in comments #12 to #19 i get no ACPI
interrupts at all, the counter stays firmly at 0.
Comment 43 Len Brown 2004-06-29 00:09:30 UTC
I should be able to get access to a Dell 5150 next week. 
Comment 44 Len Brown 2004-07-08 12:12:09 UTC
rats, what i thought was a 5150 turns out to be a 5100, 
and it has no MADT, and no IOAPIC. 
Comment 45 Len Brown 2004-07-22 10:47:35 UTC
I ran linux-acpi-test-2.6.7 on a dell 5150 yesterday.
with the SMP kernel, it came up in IOAPIC mode
even though the nolapic dmi_scan entry fired.

System was able to suspend to S3 and resume with LID
events, but the NVIDIA graphics console came up off.
Comment 46 Michael McCaskill 2004-07-22 19:32:19 UTC
Awesome. I will try adding it on my 5150 SMP. As it turns out I am running 
2.6.7 currently. By any chance did you get any power button events?
Comment 47 Len Brown 2004-07-24 07:59:22 UTC
yes, power button events (CM) worked fine.
BIOS version was A31
Comment 48 Jason Bouzane 2004-07-24 10:59:34 UTC
I just tried this configuration, except UP, and wasn't able to get it to work. 
No ACPI events are firing (power button, lid, etc), and the laptop refuses to 
sleep, claiming that the EHCI controller is failing to suspend. The error on 
sleep is: 
 
Could not suspend device 0000:00:1d.7: error -5 
 
The laptop then resumes to its previous state before the sleep request. This 
behaviour is identical to an unpatched 2.6.7 kernel. 
 
If I build the kernel with EHCI support as a module, I can suspend assuming 
the EHCI module is not loaded. 
 
Also, the acpi patch did not apply cleanly to the 2.6.7 kernel. One hunk was 
rejected because that hunk had already been applied to Linus' tree. 
 
Currently, I'm running BIOS A33. 
Comment 49 Shreyas Ananthan 2004-07-25 22:11:17 UTC
I have the same problem as #48. My bios is A33. I compiled 2.6.7 with the acpi
patches. I do not have apic enabled because there was some interrupt problem
(for the hard drive) when I enabled apic. The power and lid events aren't firing
with  the present setting. Also I haven't been able to get those acpi events
with kernel 2.4.26 and A33 bios either. has anyone had success with 2.4.26
kernel with A33 bios?  
Comment 50 Jason Bouzane 2004-07-26 08:44:07 UTC
To get apic to work, try passing "lapic" to the kernel. The problem is the dmi
scan incorrectly blacklists the bios but disables only the lapic, not the
ioapic. Forcing the lapic on as well fixes the problem.

The wakeup events do fire for me. When I put the laptop to sleep, the power and
lid events will wake it up. However, still no interrupts are firing for ACPI.
Dmesg, /proc/interrupts, DSDT, etc. are forthcoming after I play around with
this a little more. So far, I've tried several things with little success, such
as running in PIC mode, forcing the interrupt to be edge triggered (even going
so far as to modify the code so the IO write that sets it is called regardless
of whether the controller is already in the correct state), writing the PIC mode
edge value when coming up in APIC mode, and commenting out the code to disable
gpes. So far, I haven't been able to get any sense out of it.

One interesting thing I have noticed is that I get around 800-900 interrupts on
IRQ 12 (the IRQ for the touchpad) whenever I close the lid, although I get no
interrupts there when I do anything else that would cause an ACPI interrupt,
such as pressing the power or suspend buttons or removing the battery. I'm
relatively certain that there is nothing making contact with the touchpad when I
close the lid.
Comment 51 Jason Bouzane 2004-08-02 18:45:45 UTC
Created attachment 3459 [details]
Laptop configuration information

As promised, here is all the information for my configuration. I tried 
"downgrading" to A31 and "upgrading" to A35, but no luck. I've attached dmesg, 
dsdt, config, /proc/interrupts, and /proc/modules. Also, I included lspci -vvv,

but that was from a later boot without the ACPI patch, and the binary nVidia 
kernel module loaded.
Comment 52 Len Brown 2004-11-14 20:31:20 UTC
fixed in linux-2.6.9? 
Comment 53 Robert Paskowitz 2004-11-14 21:42:52 UTC
My 5150 has been replaced by dell, and I now have a 5160. It's quite identical, 
except I now have an HT processor. 
 
Using 2.6.9-ac8, events still do not function. Not sure how relevent this is 
due to different model, but as far as I can tell the machines are nearly 
identical. 
Comment 54 Len Brown 2004-11-15 23:08:11 UTC
please attach (do not paste) the full dmesg and the acpidmp output, and paste the /proc/interrupts  
for the 5160 running 2.6.9.  TIA -Len 
Comment 55 Jakob Schi 2004-11-25 01:22:52 UTC
I just tested this on my Inspiron 5150, using the 2.6.10-rc2 kernel.  No acpi
events.  I run the latest (A37) bios, but I had the same problem with the
original A26 bios one or two kernel versions ago.

Has anybody contacted Dell concerning this?  Although they do not officially
support Linux, their linux support is better than most, and they have linux
support pages at linux.dell.com

/Jakob
Comment 56 Jakob Schi 2004-12-03 03:54:19 UTC
Created attachment 4205 [details]
dmesg from my 2.6.10-rc2 kernel

Although comment #54 was not addresses to me, I also have an interest in seing
this fixed. :-)

I have attached the output from dmesg.	I do not have an acpidmp program, and
cannot find it, but if somebody points me to it I will be pleased to run it. 
/proc/interrupts is pasted below.

/Jakob

	   CPU0
  0:	 228503 	 XT-PIC  timer
  1:	    394 	 XT-PIC  i8042
  2:	      0 	 XT-PIC  cascade
  7:	   1406 	 XT-PIC  Intel 82801DB-ICH4, eth0
  8:	      2 	 XT-PIC  rtc
  9:	      0 	 XT-PIC  acpi
 11:	  15779 	 XT-PIC  yenta, ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd,
nvidia
 12:	     77 	 XT-PIC  i8042
 14:	     12 	 XT-PIC  ide0
 15:	  10695 	 XT-PIC  ide1
NMI:	      0
ERR:	      0
Comment 57 Jakob Schi 2004-12-03 03:55:47 UTC
Created attachment 4206 [details]
dmesg from my 2.6.10-rc2 kernel

Although comment #54 was not addresses to me, I also have an interest in seing
this fixed. :-)

I have attached the output from dmesg.	I do not have an acpidmp program, and
cannot find it, but if somebody points me to it I will be pleased to run it. 
/proc/interrupts is pasted below.

/Jakob

	   CPU0
  0:	 228503 	 XT-PIC  timer
  1:	    394 	 XT-PIC  i8042
  2:	      0 	 XT-PIC  cascade
  7:	   1406 	 XT-PIC  Intel 82801DB-ICH4, eth0
  8:	      2 	 XT-PIC  rtc
  9:	      0 	 XT-PIC  acpi
 11:	  15779 	 XT-PIC  yenta, ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd,
nvidia
 12:	     77 	 XT-PIC  i8042
 14:	     12 	 XT-PIC  ide0
 15:	  10695 	 XT-PIC  ide1
NMI:	      0
ERR:	      0
Comment 58 Len Brown 2004-12-05 21:53:28 UTC
acpidmp is in /usr/sbin, or in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
Comment 59 Jakob Schi 2004-12-07 04:54:59 UTC
Created attachment 4244 [details]
Output from acpidmp on a 2.6.10-rc2 kernel

Thanks for pointing me to acpidmp.  I attach the output here - hopefully only
once this time :-)

/Jakob
Comment 60 Jason Bouzane 2004-12-30 01:50:36 UTC
I can confirm that this is still broken in 2.6.9 and 2.6.10. I'm not using the
ACPI patch, though. Is there any point to me trying that? Or the latest -mm patch?

Should I be using ACPI PnP? I have it enabled on 2.6.10 and it seems to be
working fine, and doesn't seem to have affected this problem at all.

I've said this before, but there's no harm in asking again. Does anyone have any
tips on what to look for? I don't mind debugging kernel code and experimenting,
but the ACPI spec is huge and frankly, I don't know where to start with this
problem. Any pointers at all would be very helpful, no matter how small. E.g.
what are common causes of this problem? What pieces of code may be suspect? Is
there anything I should try, in particular?

Thanks
Comment 61 Shaohua 2004-12-30 18:08:44 UTC
Just power button can't generate interrupt or sleep button and Lid switch 
also? Could boot option 'osi=' help?
Comment 62 Jason Bouzane 2004-12-30 20:10:03 UTC
Nothing I do will generate an ACPI interrupt, including the power button, the
sleep button, or adding or removing the battery.

Even adding and removing USB devices will no longer generate ACPI interrupts.
The interrupt is configured, apparently, but it simply isn't firing.

Adding acpi_osi= on boot doesn't seem to make any difference.

Here's a copy of my /proc/interrupts file:

           CPU0
  0:     606281    IO-APIC-edge  timer
  1:        557    IO-APIC-edge  i8042
  8:          2    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:       4535    IO-APIC-edge  i8042
 14:         22    IO-APIC-edge  ide0
 15:       9765    IO-APIC-edge  ide1
169:        608   IO-APIC-level  Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, eth0
177:          0   IO-APIC-level  eth1, uhci_hcd
185:          3   IO-APIC-level  ohci1394, uhci_hcd
193:          2   IO-APIC-level  ehci_hcd
201:      11616   IO-APIC-level  uhci_hcd
209:      27483   IO-APIC-level  nvidia
NMI:          0
LOC:     601699
ERR:          0
MIS:          0
Comment 63 Len Brown 2005-01-03 21:34:31 UTC
do all the failing machines have nvidia?
(dell makes these boxes with either nvidia or ati)
same failure if nvidia is not loaded?
Comment 64 Joshua Shoemaker 2005-01-03 21:41:16 UTC
I have a 5100 with ATI and a 5160 with nvidia and both do the same thing.
Comment 65 Jason Bouzane 2005-01-03 23:02:12 UTC
I have an nvidia card, but it also fails without the nvidia module loaded. I
always test that configuration just in case the binary driver is causing
problems, but so far, the behaviour has always been identical, except that
wakeup actually works properly with the nvidia module loaded (well, most of the
time, and only as of 2.6.10).
Comment 66 Len Brown 2005-01-30 23:10:48 UTC
I reproduced the unresponsive button/lid issue with a Dell inspiron 5150 w/ BIOS A38 and 
Linux-2.6.11-rc2 
Comment 67 Matt Weinecke 2005-03-24 17:44:08 UTC
I had this problem with a Dell 5100 and kernel 2.6.11 and the latest Dell BIOS
(A38 I think) - the problem was fixed for me when once I passed acpi_irq_balance
as a kernel boot parm.

HTH,
Matt
Comment 68 Jakob Schi 2005-04-19 12:20:11 UTC
I can confirm that passing the acpi_irq_balance fixes the problem on an Inspiron
5150, provided you use the latest BIOS (A38).  It did not work with the A37 BIOS.

/Jakob
Comment 69 Michael McCaskill 2005-04-19 15:10:07 UTC
Didn't work for me. What version kernel are you using? I've got 2.6.11.7.
Comment 70 Jakob Schi 2005-04-20 00:44:58 UTC
I use gentoo-sources-2.6.11-r5, which is essentially 2.6.11.6 with a few
patches, I doubt that any of them is ACPI related (it is more stuff like
speakup).  I could try with a plain kernel, but not today.

Perhaps more relevant: I also pass the acpi=on parameter to the kernel.  I am
not sure I need it.  It may be necessary.

Also, I have not tested all possible acpi events.  I have acpid running, it logs
but does nothing else (yet).  With BIOS A38 I see events when I close or open
the lid, and when I press Fn-suspend.  I did not see that with BIOS A37.

Comment 71 Jakob Schi 2005-04-20 04:02:55 UTC
I can now confirm that is also works with a standard 2.6.11.7 kernel with the
command line options root=/dev/hdc3 acpi_irq_balance quiet

However, the ONLY Fn key generating ACPI events is Fn-Suspend.  I also get lid
events and events when I connect/disconnect AC.

My kernel configuration has the following ACPI settings:

>grep -i acpi /usr/src/linux-2.6.11.7/.config
# Power management options (ACPI, APM)
# ACPI (Advanced Configuration and Power Interface) Support
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_PNPACPI=y
# CONFIG_SERIAL_8250_ACPI is not set


I have built the Dell Laptop extensions as a module, but it does not work well.
 If forced to load with the force=1 module option, it gives access to fan
information, but no extra Fn keys.

/Jakob
Comment 72 Brian Sedlacek 2005-04-21 06:35:56 UTC
What version of the BIOS do you have?  I'm running into the same problem with
A32 and 2.6.11.7.  I've tried your suggested changes and it still doesn't work.
Comment 73 Jakob Schi 2005-04-21 07:20:08 UTC
You need to upgrade your BIOS to A38.  It will not work with older versions.   
(This is for the Inspiron 5150, BIOS version numbers vary between models.  If  
the newest BIOS for your model does not work, then you can only hope that the  
next version will ... )  
  
Comment 74 squishypickle 2005-06-02 20:53:10 UTC
I've tried nearly everything the above comments have suggested to no avail. I
have an inspiron 5150 with the A38 bios. I've tried 2.6.11-morph10 sources with
and without the acpi update, the 2.6.11-gentoo-r9 sources, passing
acpi_irq_balance to the kernel, and plugging in usb devices. Still nothing
happens, assuming acpi_listen is what informs you of acpi interrupts (?).
Comment 75 Xavier Droubay 2005-06-09 12:41:15 UTC
Hello, 

I've just tried A38 and 2.6.11.7 kernel, installed from Redhat9. 
and I still have no events. I use acpid on startup.

However, as I mentionned it in the acpi-devel list, 
I use patches, so may be I have too many paches applied on 
kernel 2.6.11.7. I have patched kernel 3 times with, 
in the following order, an nvidia patch 
(linux-2.6.11.7-nvidia_6111-6629_compat2.diff), 
the acpi patch acpi-20050408-2.6.11.diff.bz2, 
and the suspend2 patch software-suspend-2.1.8-for-2.6.11.tar.bz2.

I use an usbmouse and tried to plug unplug the mouse. 
Nothing happened. 


Can those who have a working /proc/acpi/event, with A38 bios
and 2.6.11.7 kernel can  Too many paches applied on kernel 2.6.11.7. I have 
patched kernel 3 times with, in the following order,
an nvidia patch (linux-2.6.11.7-nvidia_6111-
6629_compat2.diff), the acpi patch acpi-20050408-2.6.11.
diff.bz2, and the suspend2 patch software-suspend-2.1.8-
for-2.6.11.tar.bz2.

Can you, who have a working /proc/acpi/event, with A38 bios
and 2.6.11.7 kernel
1) send you .config eventually: use of SMP (hiperthreading), 
software suspend additional patches.
2) tell if you use some particular patches: 
which patch for acpi, or others ...
3) inform about your graphic card : an Nvidia or ATI ? If it is 
an nvidia, which version of driver do you use? 
4) tell whether you patched the DSDT. 
5) Also, can you tell what distro you use ? 

I don't know how to solve this problem, as mentionned by the guy from last post. 


Thanks in advance, Xavier
Comment 76 Jakob Schi 2005-06-10 00:46:44 UTC
I have tried with an unpatched kernel (2.6.11.7, I think), but currently I am
using the 2.6.11-gentoo-r8 kernel (I use Gentoo Linux).  It works with both
kernels (I see events with acpid when I open or close the lid).  I do not have a
hyperthreading CPU, so I have not build an SMP kernel - maybe that makes a
difference.  

Xavier: You may want to try without at least the acpi patch (what is it supposed
to do?).   I have an nVidia card, but do not use any nvidia patch (I load
nVidia's closed-source kernel module during boot, version 1.0.7664 I think, but
I am not on that machine now).  I did not patch the DSDT, I would not know how
to do that.

If you try building without the acpi patch, and without SMP, please post here if
it works.

/Jakob
Comment 77 Jason Bouzane 2005-06-10 09:32:51 UTC
I cannot get it to work, either.

I am using a vanilla 2.6.11.10 kernel with the binary-only NVIDIA driver. It is
a uniprocessor kernel, and I do not have a hyperthreaded CPU. Throughout the
entire time the system is up, I see exactly one ACPI interrupt (on boot) and I
never get another, nor does /proc/acpi/events work (obviously).

I am using the A38 BIOS. Could someone with a working setup post the entire
config file and boot parameters? I've compared my ACPI setup to that of working
kernels and there are no differences, so it must be something else.
Comment 78 Jakob Schi 2005-06-10 11:39:48 UTC
Created attachment 5146 [details]
My .config file

Here are the config file and the boot parameters of my running kernel.

From my GRUB configuration file:
title=Gentoo Linux (2.6.11-gentoo-r9 kernel)
root (hd0,2)
kernel (hd0,2)/boot/vmlinuz-2.6.11-gentoo-r9 root=/dev/hdc3 acpi_irq_balance
quiet

On this kernel I can see ACPI events when running acpid.
Comment 79 Jeff Davidson 2005-06-10 12:50:34 UTC
In response to #78:

I took your kernel config and adapted it to my 5100, and with the
acpi_irq_balance option alone the event interface still didn't work.  However,
after adding "pci=routeirq" to the list (just on a wild hunch at that point),
they worked on this laptop.  I also added "lapic", but that seemed not to be
what did it.
Comment 80 Jakob Schi 2005-06-17 00:56:43 UTC
I can add another weird observation: it only works if X is running, and the
current virtual terminal is the one where X runs!  If I switch to another
virtual terminal, the acpi event waits until I switch back to X.  It does not
matter if I compile the kernel with or without framebuffer.

I am using the nvidia kernel module version 1.0.7664.

/Jakob

Comment 81 Jason Bouzane 2005-06-17 22:09:12 UTC
I finally got time to try that config file and no luck. I still get exactly one
ACPI interrupt per boot cycle. I did have to make some minor changes, though,
such as including ReiserFS and passing devfs=nomount to make the kernel boot,
and the laptop came up in PIC mode, even when passing the "lapic" parameter. I
didn't look too closely at the config file to see what was causing this, though.
Comment 82 Len Brown 2006-01-28 01:39:54 UTC
Anybody have ACPI events on a Dell 5100 or 5150 working?

If I boot the kernel with "noapic" "acpi_balance_irq" "acpi_irq_isa=10,11"
then USB is forced to share IRQ9 with ACPI.  Under these conditions
if I have USB interrupt activity (say, wiggling the USB mouse),
then I am able to get ACPI events (/etc/init.d/acpid stop;
cat /proc/acpi/event) including power button, sleep button (Fn + ESC)
AC/DC switch and battery status.

This shows that the ACPI devices are indeed provoking events,
and that the kernel is indeed ready to handle them --
and that the missing link is the SCI interrupt itself.

Looking in the ICH4 PCI config space, in the LPC bridge
(DID 0x24cc) at offset 0x44, ACPI_CNTL = 0x10 -- the 1
means ACPI is enabled, and the bottom three bits 0 means
that the SCI is programmed for IRQ9 where the kernel
expects it to be.

5150 BIOS A38, linux-2.6.16-rc1
Comment 83 Craig Duquette 2006-01-28 11:42:47 UTC
Comment 78 and comment 79 didn't fix the issue for me. I used to be using 
Gentoo and adding acpi_irq_balance did fix the issues for me, but for some 
reason it is no longer working in Ubuntu. This is on the Inspiron 5150. Has 
anyone recently got the /proc/acpi/events to generate events? 
Comment 84 Len Brown 2006-01-28 14:18:13 UTC
I expect that acpi_irq_balance (in PIC mode) may have sometimes
helped because of the case in comment #82 -- for if acpi is
sharing interrupts with another device, then its handler
will get invoked whenever that other device causes an interrupt
-- in that case, USB.

I've found that booting 2.6.16-rc1 simply with "irqpoll"
is a sufficient workaround to make acpi events work
on the 5150.

IRQ9 in /proc/interrupts will not increment, but if you
cat /proc/acpi/event (or run acpid:-) then all the appropriate
acpi events seem to come through.
Comment 85 Jason Bouzane 2006-01-28 17:34:36 UTC
> Anybody have ACPI events on a Dell 5100 or 5150 working?

Not that I know of. I never have.

> This shows that the ACPI devices are indeed provoking events,
> and that the kernel is indeed ready to handle them --
> and that the missing link is the SCI interrupt itself.

Yeah, I came to the same conclusion, but I have no idea why the SCI interrupt
isn't actually firing.

> Looking in the ICH4 PCI config space, in the LPC bridge
> (DID 0x24cc) at offset 0x44, ACPI_CNTL = 0x10 -- the 1
> means ACPI is enabled, and the bottom three bits 0 means
> that the SCI is programmed for IRQ9 where the kernel
> expects it to be.

Do you think that playing with these bits might help? E.g. reassigning the IRQ
to something else, and then setting it back to 9 again? Or is there some simple
way to tell the kernel to force the ACPI IRQ to some other line (though I think
that Windows also uses IRQ 9)?

Furthermore, is there any drawback to using irqpoll? I'll test that out the next
chance I get and let you know if it helps on my end.
Comment 86 Len Brown 2006-01-28 19:23:24 UTC
Re: cmdline "irqpoll" workaround
Yes, the disadvantage is that it will suck up some CPU
because upon detecting a mis-routed irq, it will poll
all the shared interrupt handlers in the system.

also, "irqpoll" appears to work for me only in "noapic" PIC mode --
though i'm not sure why that behaves differently from IOAPIC mode.

Re: IRQ 9
I booted a Windows 2000 drive on the 5150 and ACPI
came up on IRQ9 and the button worked as expected.
Since here the OS pre-dates the hardware, this means
it is unlikely that XP ships with some special workaround
that fixes some quirk on this box.  If Win2K can figure
it out, surely Linux can too...

So it appears that on Linux the ACPI interrupt isn't coming
out on IRQ9, but perhaps is going elswhere.  Need to find out
where and why...
Comment 87 Len Brown 2006-01-28 21:48:31 UTC
Re: cmdline "irqpoll"
I take back what i wrote about it not helping in IOAPIC mode --
it works just as well in IOAPIC mode as in PIC mode.

However, in both cases, "irqpoll" is working because
acpi_irq() is being polled from the IRQ0 handler.

So this is not a case of the ACPI handler registering
on IRQ9 while the ACPI hardware provokes an interrupt
on a different IRQ.

Further, in both PIC and IOAPIC mode, there is always
exactly one REAL interrupt on IRQ9 shown in /proc/interrupts.

So this looks less like IRQ mis-routing than it looks
like IRQ9 getting stuck masked after its first invocation.

Curious, of course, that this seems specific to the i5150 --
unclear at this point what is unique about this platform.
Comment 88 Len Brown 2006-01-28 23:55:59 UTC
IOAPIC bits look normal.  sticking a print_IO_APIC() in acpi_irq()
for the IRQ_HANDLED case, the 1st invocation looks like this:

NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 09 001 01  0    1    1   0   0    1    1    71

Unmasked, level trigger, IIR says the interrupt is accepted
but EOI has not yet cleared it, Polarity is high -- per
the interrupt source override, Status is idle.

When later invoked by irqpoll, we see this:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 09 001 01  0    1    0   0   0    1    1    71

everything is the same, except IIR shows there simply isn't
an interrupt in progress.
Comment 89 Len Brown 2006-01-29 00:15:48 UTC
PIC-mode bits look normal too.
Same exercise: print_PIC()
from acpi_irq() when it finds work to do.

The 1st one is presumably a real interrupt:

printing PIC contents
... PIC  IMR: 2678
... PIC  IRR: 0000
... PIC  ISR: 0000
... PIC ELCR: 0a80

The 6 in IMR 2678 means bit 9 1, so IRQ9 is masked = DISABLED --
which makes sense since we're printing this from its handler...
ELCR a80 has bit 9 is set meaning IRQ9 is LEVEL sensitive,
just like IRQ 7 and 11 -- as expected.

Later when invoked via irqpoll...
printing PIC contents
... PIC  IMR: 2479
... PIC  IRR: 0000
... PIC  ISR: 0000
... PIC ELCR: 0a80

The 4 in IMR means that bit 9 is now CLEAR,
which means that IRQ9 is indeed UNMASKED and ready for action --

So in both the PIC and IOAPIC cases, the interrupt controller
sits ready for the SCI, but the input pin is not being driven
again after its first invocation.
Comment 90 Len Brown 2006-01-29 00:36:18 UTC
Can anybody confirm that an i5150 running an
ACPI enabled 2.4 kernel works WRT ACPI events
like power button?

I tried a 2.4.30 kernel which didn't undestand
my 2.6 file system enough to get past fsck, but
my test of the power button at that point did not
yield an interrupt, suggesting that linux-2.4
shares this issue with linux-2.6.
Comment 91 Jason Bouzane 2006-01-29 01:15:42 UTC
Re: The IOAPIC thing:
Yes, I am using my laptop now with the IOAPIC enabled and irqpoll is working fine.

Re: The 2.4 kernel:
It's been so long since I've run a 2.4 kernel that I honestly don't remember
much, but I can say that I've never had this work on a 2.4 kernel. I think other
successes on 2.4 were probably related to IRQ sharing as you've already
described, or were with earlier BIOS revisions.

I can try a 2.4 kernel in a couple of days, but I really don't expect it to help
much.
Comment 92 Shaohua 2006-02-27 18:55:36 UTC
Re comment #82:
It's quite possible sci interrupt isn't level triggered. could anybody try 
boot option: acpi_sci=edge? please do it in pic mode.
Comment 93 D Bera 2006-07-06 13:38:21 UTC
Just for information, this bug is present in inspiron 1100 also (with A32 bios).
I  remember having used the power buttons and lid-close events in 2.4 series but
with 2.6 it never worked. I have tried various acpi/irq boot params to no
effect. If there is any suggetion, I can try them and report.
Comment 94 Len Brown 2006-08-30 20:38:53 UTC
*** Bug 7019 has been marked as a duplicate of this bug. ***
Comment 95 Len Brown 2006-10-10 16:19:32 UTC
Re: comment #92
No, "noapic" "acpi_irq=edge" doesn't help.
Still just a single interrupt registered on IRQ9.
Comment 96 Len Brown 2006-10-10 21:28:07 UTC
booting with acpi_dbg_level=0xffffffff acpi_dbg_layer=4   
   
Using IPI No-Shortcut mode   
evxfevnt-0216 [DFF94A70] [01] set_gpe_type          : ----Entry   
   evgpe-0072 [DFF94A70] [02] ev_set_gpe_type       : ----Entry   
   evgpe-0247 [DFF94A70] [03] ev_disable_gpe        : ----Entry   
Time: tsc clocksource has been installed.   
   evgpe-0250 [DFF94A70] [03] ev_disable_gpe        : ----Exit- AE_OK   
   evgpe-0094 [DFF94A70] [02] ev_set_gpe_type       : ----Exit- AE_OK   
evxfevnt-0235 [DFF94A70] [01] set_gpe_type          : ----Exit- AE_OK   
evxfevnt-0259 [DFF94A70] [01] enable_gpe            : ----Entry   
   evgpe-0181 [DFF94A70] [02] ev_enable_gpe         : ----Entry   
Time: acpi_pm clocksource has been installed.   
   evgpe-0118 [DFF94A70] [03] ev_update_gpe_enable_m: ----Entry   
   evgpe-0158 [DFF94A70] [03] ev_update_gpe_enable_m: ----Exit- AE_OK   
   evgpe-0228 [DFF94A70] [02] ev_enable_gpe         : ----Exit- AE_OK   
evxfevnt-0286 [DFF94A70] [01] enable_gpe            : ----Exit- AE_OK   
evxfevnt-0216 [DFF94A70] [01] set_gpe_type          : ----Entry   
evxfevnt-0227 [DFF94A70] [01] set_gpe_type          : ----Exit- AE_OK   
evxfevnt-0259 [DFF94A70] [01] enable_gpe            : ----Entry   
   evgpe-0181 [DFF94A70] [02] ev_enable_gpe         : ----Entry   
   evgpe-0118 [DFF94A70] [03] ev_update_gpe_enable_m: ----Entry   
   evgpe-0158 [DFF94A70] [03] ev_update_gpe_enable_m: ----Exit- AE_OK   
   evgpe-0228 [DFF94A70] [02] ev_enable_gpe         : ----Exit- AE_OK   
evxfevnt-0286 [DFF94A70] [01] enable_gpe            : ----Exit- AE_OK   
ACPI: (supports S0 S1 S3 S4 S5)   
 evxface-0116 [DFF94A70] [01] install_fixed_event_ha: ----Entry   
evxfevnt-0410 [DFF94A70] [02] clear_event           : ----Entry   
evxfevnt-0426 [DFF94A70] [02] clear_event           : ----Exit- AE_OK   
evxfevnt-0158 [DFF94A70] [02] enable_event          : ----Entry   
evxfevnt-0193 [DFF94A70] [02] enable_event          : ----Exit- AE_OK   
 evxface-0155 [DFF94A70] [01] install_fixed_event_ha: Enabled fixed event 4,   
Handler=c025dd96   
 evxface-0160 [DFF94A70] [01] install_fixed_event_ha: ----Exit- AE_OK   
   
...   
Freeing unused kernel memory: 228k freed   
device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised:   
dm-devel@redhat.com   
   
   
**** Context Switch from TID DFF94A70 to TID C05F31E0 ****   
   
   evsci-0072 [C05F31E0] [01] ev_sci_xrupt_handler  : ----Entry   
 evevent-0257 [C05F31E0] [01] ev_fixed_event_detect : Fixed Event Block: Enable   
00000420 Status 00000411   
evxfevnt-0410 [C05F31E0] [02] clear_event           : ----Entry   
evxfevnt-0426 [C05F31E0] [02] clear_event           : ----Exit- AE_OK   
evxfevnt-0357 [C05F31E0] [02] disable_event         : ----Entry   
evxfevnt-0390 [C05F31E0] [02] disable_event         : ----Exit- AE_OK   
   evgpe-0443 [C05F31E0] [01] ev_gpe_detect         : Read GPE Register at   
GPE0: Status=00, Enable=00   
   evgpe-0443 [C05F31E0] [01] ev_gpe_detect         : Read GPE Register at   
GPE8: Status=00, Enable=01   
   evgpe-0443 [C05F31E0] [01] ev_gpe_detect         : Read GPE Register at   
GPE10: Status=FF, Enable=00   
   evgpe-0443 [C05F31E0] [01] ev_gpe_detect         : Read GPE Register at   
GPE18: Status=00, Enable=11   
   evsci-0091 [C05F31E0] [01] ev_sci_xrupt_handler  : ----Exit-   
0000000000000001   
   
The FADT says:   
PM1a_EVT_BLK:     0x00001000   
PM1b_EVT_BLK:     0x00000000   
PM1a_CNT_BLK:     0x00001004   
PM1b_CNT_BLK:     0x00000000   
PM2_CNT_BLK:      0x00001020   
PM_TMR_BLK:       0x00001008   
GPE0_BLK:         0x00001028   
GPE1_BLK:         0x00000000   
PM1_EVT_LEN:      4   
PM1_CNT_LEN:      2   
PM2_CNT_LEN:      1   
PM_TM_LEN:        4   
GPE0_BLK_LEN:     8   
GPE1_BLK_LEN:     0   
GPE1_BASE:        0   
   
i5150:~ # inw 0x1004   
0x1401 
the PM1_CNT register: 
bit 0 = 1: SCI_EN is enabled, so the ICH4 should be sending the events 
           to the SCI (rather than to the SMI) 
bit 10,12 = 1: SLP_TYPE = 5 
 
i5150:~ # inw 0x1000 
0x0411 
 
PM1_STS register: 
bit 0 = 1: TMR_STS 
bit 4 = 1: BM_STS 
bit 10 = 1: RTC_STS 
 
i5150:~ # inw 0x1002 
0x0020 
 
PM1_EN register: 
bit 5 = 1: GBL_EN 
 
Given that there is a  TMR_STS pending, but not enbaled, I enabled it: 
  i5150:~ # outw 0x1002 0x51 
and I got an SCI: 
 
i5150:~ # grep acpi /proc/interrupts 
  9:          2   IO-APIC-fasteoi  acpi 
 
# dmesg | tail -1 
ACPI Error (evevent-0314): No installed handler for fixed event [00000000] 
[20060707] 
 
Repeating the write resulted in a 3rd SCI. 
 
This shows that the SCI interrupt is actually working, 
and the problem is not interrupt routing, but in the 
enabling of the low-level ACPI events. 
 
Comment 97 Len Brown 2006-10-10 22:13:14 UTC
_PRW shows that the LID and power button are both on GPE #8, 
at least for wakeup: 
  
        Device (LID)  
        {  
            Name (_HID, EisaId ("PNP0C0D"))  
            Method (_LID, 0, NotSerialized)  
            {  
                Store (SMI (0x84, 0x00), Local0)  
                Return (Local0)  
            }  
  
            Name (_PRW, Package (0x02)  
            {  
                0x08,  
                0x03  
            })  
            Method (_PSW, 1, NotSerialized)  
            {  
                PSW (Arg0, 0x02)  
            }  
        }  
  
        Device (PBTN)  
        {  
            Name (_HID, EisaId ("PNP0C0C"))  
            Name (_PRW, Package (0x02)  
            {  
                0x08,  
                0x04  
            })  
            Method (_PSW, 1, NotSerialized)  
            {  
                PSW (Arg0, 0x01)  
            }  
        }  
  
        Device (SBTN)  
        {  
            Name (_HID, EisaId ("PNP0C0E"))  
        }  
From the FADT, GPE0_STS 
i5150:~ # inl 0x1028 
0x00FF0000 
 
bit8 is clear, so the HW does not indicate that the 
power button has been pressed. 
 
From the FADT, GPE0_EN 
i5150:~ # inl 0x102C 
0x11000100 
 
bit8 is 1, so the power button GPE is enabled. 
 
Upon a button press, GPE28 (0x1C) STS gets set, rather than GPE 8. 
 
i5150:~ # inl 0x1028 
0x10FF0000 
i5150:~ # inl 0x102C 
0x11000100 
 
Looking at the AML handler for for 28 _L1C(), it appears 
to be a general purpose event handler which uses SMI commands 
to determine the source of the event and then kicks off the 
appropriate notify() on the corresponding device. 
 
However, even though the status and the enable bits for that 
handler are set above, the SCI did not get invoked and the 
dispatch handler did not run. 
 
Comment 98 Len Brown 2006-10-10 22:17:08 UTC
Created attachment 9203 [details]
dmesg  wiith acpi_dbg_layer=4 acpi_dbg_level=0xFFFFFFFF
Comment 99 Len Brown 2006-10-10 22:41:20 UTC
Was able to use the fixed event method above to  
provoke an SCI, which discarded the bogus fixed event,  
but picked up a pending battery insertion GPE event:  
  
i5150:~ # inl 0x1028  
0x00FF0000  
  
<insert battery here>  
  
i5150:~ # inl 0x102C  
0x11000100  
i5150:~ # inl 0x1028  
0x10FF0000  
  
i5150:~ # inw 0x1000  
0x0411  
i5150:~ # inw 0x1002  
  
enable fixed event 0:  
0x0020  
i5150:~ # outw 0x1002 0x1  
  
ACPI Error (evevent-0314): No installed handler for fixed event [00000000]  
[20060707]  
   evgpe-0443 [DA56B030] [01] ev_gpe_detect         : Read GPE Register at  
GPE0: Status=00, Enable=00  
   evgpe-0443 [DA56B030] [01] ev_gpe_detect         : Read GPE Register at  
GPE8: Status=00, Enable=01  
   evgpe-0443 [DA56B030] [01] ev_gpe_detect         : Read GPE Register at  
GPE10: Status=FF, Enable=00  
   evgpe-0443 [DA56B030] [01] ev_gpe_detect         : Read GPE Register at  
GPE18: Status=10, Enable=11  
   evgpe-0619 [DA56B030] [02] ev_gpe_dispatch       : ----Entry  
   evgpe-0247 [DA56B030] [03] ev_disable_gpe        : ----Entry  
   evgpe-0118 [DA56B030] [04] ev_update_gpe_enable_m: ----Entry  
   evgpe-0132 [DA56B030] [04] ev_update_gpe_enable_m: ----Exit- AE_OK  
   evgpe-0285 [DA56B030] [03] ev_disable_gpe        : ----Exit- AE_OK  
   evgpe-0727 [DA56B030] [02] ev_gpe_dispatch       : ----Exit-  
0000000000000001  
   evsci-0091 [DA56B030] [01] ev_sci_xrupt_handler  : ----Exit-  
0000000000000001  
  
**** Context Switch from TID DA56B030 to TID C148A030 ****  
  
   evgpe-0512 [C148A030] [01] ev_asynch_execute_gpe_: ----Entry  
   evgpe-0181 [C148A030] [02] ev_enable_gpe         : ----Entry  
   evgpe-0118 [C148A030] [03] ev_update_gpe_enable_m: ----Entry  
   evgpe-0158 [C148A030] [03] ev_update_gpe_enable_m: ----Exit- AE_OK  
   evgpe-0228 [C148A030] [02] ev_enable_gpe         : ----Exit- AE_OK  
  evmisc-0139 [C148A030] [08] ev_queue_notify_reques: Dispatching Notify(81) on  
node c1476ee4  
  evmisc-0147 [C148A030] [08] ev_queue_notify_reques: Notify value: 0x81  
**Device Specific**  
  evmisc-0139 [C148A030] [08] ev_queue_notify_reques: Dispatching Notify(80) on  
node c1476ee4  
  evmisc-0147 [C148A030] [08] ev_queue_notify_reques: Notify value: 0x80  
**Device Specific**  
   evgpe-0595 [C148A030] [01] ev_asynch_execute_gpe_: ----Exit-  
  
So this failure seems specific to GPEs. 
Fixed events and the SCI itself are actually working -- 
but that is somewhat academic, as the useful events on this 
machine are all GPEs. 
 
  
  
Comment 100 Len Brown 2006-10-11 00:20:02 UTC
i5150:~ # lspci -s 00:1f.0 -xxx 
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge 
(rev 01) 
00: 86 80 cc 24 0f 01 80 02 01 00 01 06 00 00 80 00 
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
40: 01 10 00 00 10 00 00 00 00 00 00 00 00 00 00 00 
50: 00 00 00 00 00 00 00 00 81 10 00 00 10 00 00 00 
60: 8b 8b 8b 8b 91 00 00 00 8b 80 80 8b 00 00 00 00 
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
90: ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
a0: 28 03 02 00 02 00 00 00 12 00 00 00 00 00 08 00 
b0: 00 00 00 00 00 00 00 00 00 00 01 08 00 00 00 00 
c0: b0 00 00 00 60 00 e0 10 00 00 00 08 74 f0 00 00 
d0: 87 21 20 00 02 cf 00 00 04 00 00 00 00 00 00 00 
e0: 00 00 00 c0 01 09 00 3f 00 00 00 00 e1 00 00 00 
f0: 00 00 09 00 00 00 00 00 60 0f 03 00 00 00 80 00 
 
ICH4M GPI_ROUT Register is at offset b8, 
which has 2 bits for each GPI: 
00: no effect 
01: SMI 
10: SCI 
11: Reserved 
 
so... 
b8: 00 
b9: 00 
ba: 01 = SMI for GPI #8, corresponding to GPE 14 (0xE) 
bb: 08 = SCI for GPI #13, corresponding to GPE 29 (0x1D) 
 
But the GPE we care about is #28, and it set to 00 -- no effect. 
So lets enable #28 that as an SCI: 
i5150:~ # setpci -s 00:1f.0 bb.b=0a 
giving us this: 
b0: 00 00 00 00 00 00 00 00 00 00 01 0a 00 00 00 00 
 
and then ACPI GPE SCI's work: 
i5150:~ # /etc/init.d/acpid stop 
Shutting down acpid                                                   done 
i5150:~ # cat /proc/acpi/event 
button/power PBTN 00000080 00000006 
button/sleep SBTN 00000080 00000005 
ac_adapter AC 00000080 00000000 
battery BAT0 00000080 00000001 
ac_adapter AC 00000080 00000001 
battery BAT0 00000080 00000001 
 
So the question is why the ICH4M GPI_ROUT register 
is programmed incorrectly. 
 
There are a couple of possibilities: 
1. Dell BIOS bug 
   But then why does Windows work properly? 
   Maybe Windows has an ICH4 driver 
   or a system specific workaround? 
2. Linux scribbled on the ICH4 config space 
   But there doesn't seem to be and ICH4 driver, 
   so it would have to be some other code... 
3. Linux provoked the Dell BIOS AML to do the wrong thing. 
   Possible, but this is why we identify ourselves as 
   compatible with Windows.  Maybe in this case it didn't work -- 
   but a quick scan of the DSDT doesn't show scribbling on 
   this register from AML. 
 
Comment 101 Patrik Pettersson 2006-10-11 00:21:53 UTC
Hi,

I found the following documentation about GPE Routing for Windows at Microsoft.

http://www.microsoft.com/whdc/system/pnppwr/powermgmt/GPE_routing.mspx

Patrik
Comment 102 Len Brown 2006-10-11 01:57:35 UTC
Confirmed that 2.4 behaves the same as 2.6.

Installed SuSE Linux 8.2 on the i5150.
It runs Linux-2.4.20-4GB in ACPI mode
and uses XT-PIC mode for interrupts.
Manual modprobe button is necessary,
but no ACPI events worked out of the box.

lspci showed the same as 2.6 for the ICH4 config space,
and the same setpci command as above made ACPI events work.
Comment 103 Patrik Pettersson 2007-06-19 01:47:36 UTC
I can confirm that the solution described in comment #100 above works on a Dell Inspiron 5160.

So, currently a usable work-around for this issue on a Dell Inspiron 5160 is to make sure that the command "setpci -s 00:1f.0 bb.b=0a" is executed both on initial system startup as well as after a standby/hibernate resume.

On my current system (Ubuntu 7.04) I use /etc/rc.local for initial startup and a new file called /etc/acpi/resume.d/95-fix-dell-powerbtn.sh for resume.

Patrik
Comment 104 Ole Christian Tvedt 2007-07-03 17:28:00 UTC
And I can confirm that the solution in comment #100 also works on a Dell Inspiron 5100.

The bridge in the 5100 is an ICH4-L, but I checked the specs, and the GPI_ROUT is at the same address.

I also have a button next to the power button whith an "i" on it that doesn't work, and a cd-eject button (Fn-F10). Is that in any way related, or aren't they supposed to generate events?

@Len Brown: Thank you, I've learned a lot from this.
Comment 105 D Bera 2007-07-03 20:22:39 UTC
On my Inspiron 1100, my 'i' button works (the eject button probably worked before, I dont use it anymore so its not mapped to anything). The 'i' button sends some keycode and I used xev to map it to open some application.
Comment 106 D Bera 2007-07-08 12:09:34 UTC
Confirming that the setpci hack from comment #100 works for inspiron 1100 too.
Comment 107 Natalie Protasevich 2008-03-03 16:43:20 UTC
Is this sufficient resolution for the problem? Len, is it ok if we close the bug?
Thanks.
Comment 108 Zhang Rui 2008-03-17 01:42:45 UTC
Hi, all,
please make sure you don't have this problem with the latest kernel and the lastest BIOS. As there is no reponse more than half a year.
I'll close this bug if there is not any feedback. :)
Comment 109 D Bera 2008-03-17 08:36:00 UTC
Problem exists in 2.6.24 (its a mandriva kernel and not a vanilla one but I doubt the problem is fixed in the vanilla kernel). Also confirmed that the setpci hack fixes the problem. (And BIOS is also latest).
Comment 110 ykzhao 2008-03-17 23:53:17 UTC
Created attachment 15320 [details]
try the debug patch

Will you please try the debug patch and see whether the bug can be fixed?
Thanks.
Comment 111 ykzhao 2008-03-17 23:57:58 UTC
Hi, All
   What Len said in comment #100 is right. GPE routing is incorrect and GPI_ROUT register in 1f.0 pci device is also incorrect. 
   
   From the AML handler it seems that there are the following definitions:
    Device (LID)  
        {  
            Name (_PRW, Package (0x02)  
            {  
                0x08,  
                0x03  
            })  
            Method (_PSW, 1, NotSerialized)  
            {  
                PSW (Arg0, 0x02)  
            }  
        }  
        Device (PBTN)  
        {  
            Name (_PRW, Package (0x02)  
            {  
                0x08,  
                0x04  
            })  
            Method (_PSW, 1, NotSerialized)  
            {  
                PSW (Arg0, 0x01)  
            }  
        }  
    Will you please try the debug patch in comment #110 and see whether the bug still exists?
    In the debug patch the _PSW object is called for the Power button and LID button to enable the ability to wake the sleeping system or trigger interrupt.
    
    Please boot the system with the option of "acpi.debug_layer=0x090004 acpi.debug_level=0x1f" and attach the output of dmesg, lspci -vxxx.
    Thanks.
    
Comment 112 D Bera 2008-03-18 05:40:11 UTC
(In reply to comment #110)
> Created an attachment (id=15320) [details]
> try the debug patch
> 
> Will you please try the debug patch and see whether the bug can be fixed?

I dont have any scope of building a kernel myself; if someone else can try it, my lots of thanks to him/her/them. Sorry :(
Comment 113 Craig Duquette 2008-03-18 16:14:23 UTC
I'm also not able to test this issue, as my computer with this bug no longer works.
Comment 114 Roland Kletzing 2008-04-30 12:32:42 UTC
anybody there who can try the debug-patch to bring this long story to an happy end?
Comment 115 alwin 2008-07-19 23:21:30 UTC
Created attachment 16902 [details]
dmesg after patch comment #110
Comment 116 alwin 2008-07-19 23:31:53 UTC
Created attachment 16903 [details]
lspci -vxxx after patch comment #110

patched/recompiled/rebooted using vanilla-sources-2.6.25.9 (and gentoo-sources-2.6.25-r6), but can't get events, unless i do "setpci -s 00:1f.0 bb.b=0a" from comment #100.
Comment 117 ykzhao 2008-07-21 19:45:10 UTC
Created attachment 16930 [details]
try the debug patch to see whether the problem still exists

Will you please try the attached patch to see whether the system can work well?
 In the debug patch the _PSW object will be evaluated to enable the wakeup functionality of run-wake device. For example: Power Button/SLeep Button/LID device.
Of course the patch in comment #110 is also required.

Thanks.
Comment 118 alwin 2008-07-22 11:56:03 UTC
Created attachment 16940 [details]
dmesg after patch comment #110 and comment #117
Comment 119 alwin 2008-07-22 11:57:31 UTC
Created attachment 16941 [details]
lspci -vxxx after patch comment #110 and comment #117
Comment 120 alwin 2008-07-22 12:12:32 UTC
Created attachment 16942 [details]
metalog after patch comment #110 and comment #117

ykzhao, thank you for working on this bug. no events yet. typing "setpci -s 00:1f.0 bb.b=0a" causes an immediate shutdown, because i pressed Fn-Suspend (not setup yet), pressed the power button, and moved the power cord out/in. no problem, only mentioning this, to clear up the logs. :-)
Comment 121 ykzhao 2008-07-22 19:38:27 UTC
Hi, Alwin
   thanks for the test.
   The patch in comment #117 still can't make your laptop work well. The GPI routing in 1f.0 PCI config space still can't be changed after the _PSW object is called for the PWRB/LID device to enable the wake functionality of LID & PWRB device.
Comment 122 alwin 2008-07-23 13:02:24 UTC
(In reply to comment #121)
> Hi, Alwin
>    thanks for the test.
>    The patch in comment #117 still can't make your laptop work well. The GPI
> routing in 1f.0 PCI config space still can't be changed after the _PSW object
> is called for the PWRB/LID device to enable the wake functionality of LID &
> PWRB device.
> 

correct. i'm not an expert on this though. i tried to get events using the patched kernel, by pressing the buttons etc., but nothing happened. the key commands were remembered somewhere, and executed as soon as i typed in "setpci -s 00:1f.0 bb.b=0a" later (that's the shutdown in the logs). i checked the files, if patching was done correctly, and the kernel replaced with the new one...
Comment 123 ykzhao 2008-08-25 23:30:57 UTC
Created attachment 17453 [details]
try the debug patch to confirm whether the problem still exists

Hi, Alwin
   Will you please try the attached patch on the latest kernel(2.6.27-rc3/4) to see whether the system can work well?
  In the debug patch the _PSW object will be evaluated to enable the wakeup
functionality of run-wake device. For example: Power Button/SLeep Button/LID
device.
   
   I am sorry for that I attach an incorrect debug patch in comment #117.
Thanks.
Comment 124 alwin 2008-08-26 13:15:02 UTC
(In reply to comment #123)
> Created an attachment (id=17453) [details]
> try the debug patch to confirm whether the problem still exists
(...)

Hi ykzhao,
Thanks for the new patch! The patched kernel doesn't compile yet, unfortunately... using versions 2.6.27-rc3 or 4. Here's a part of the output from make:

inspiron5150 linux # make && make modules_install && REL=`ls -l /usr/src/linux | sed -e 's:.*linux-\(.*\):\1:'` && cp -b arch/i386/boot/bzImage /boot/kernel-$REL && cp -b .config /boot/config-$REL; rm -f /boot/kernel; ln -s kernel-$REL /boot/kernel
(...)
  CC      drivers/acpi/sleep/wakeup.o
drivers/acpi/sleep/wakeup.c: In function 'acpi_wakeup_device_init':
drivers/acpi/sleep/wakeup.c:186: warning: ISO C90 forbids mixed declarations and code
drivers/acpi/sleep/wakeup.c:186: error: expected declaration or statement at end of input
make[3]: *** [drivers/acpi/sleep/wakeup.o] Error 1
make[2]: *** [drivers/acpi/sleep] Error 2
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2
Comment 125 ykzhao 2008-08-26 17:45:26 UTC
Created attachment 17468 [details]
try the updated debug patch

Sorry that I attached the incorrect debug patch. 
Will you please try the updated patch?
Thanks.
Comment 126 alwin 2008-08-27 12:29:17 UTC
Created attachment 17485 [details]
dmesg after patch comment #125
Comment 127 alwin 2008-08-27 12:31:03 UTC
Created attachment 17486 [details]
lspci -vxxx after patch comment #125
Comment 128 alwin 2008-08-27 12:46:51 UTC
Created attachment 17487 [details]
metalog after patch comment #125

Thank you for the new patch! I tested a patched 2.6.27-rc4 kernel, in the same way as last time. The results are also the same as described in comment #122 . Still, it doesn't produce events. ;-(
Comment 129 ykzhao 2008-08-27 18:20:42 UTC
Hi, Alwin
    Thanks for the test.
    It seems that the system still can't work as what we expected after applying the patch in comment #125. And the GPI_ROUTING register in pci 0000:00:1f.0 can't be changed by the patch. 
    It is an obvious BIOS bug. 
    
    Thanks.
Comment 130 ykzhao 2009-03-04 17:38:21 UTC
Hi, alwin
    Will you please do the following test on your box?
    a. setpci -s 00:1f.0 bb.b=0a  and assure that ACPI event is reported correctly
    b. put the box into hibernate state.(echo disk > /sys/power/state)
    c. resume the box and see whether the ACPI event is reported correctly. Of course please attach the output of lspci -vxxx.
    
    Thanks.
Comment 131 ykzhao 2009-03-04 17:52:37 UTC
Created attachment 20432 [details]
call the _WAK object after ACPI full initialization

Hi, Alwin
    Will you please try the debug patch on the latest kernel and see whether the ACPI event can be reported correctly?
    After the box is booted, please attach the output of lspci -vxxx.
    Thanks.
Comment 132 alwin 2009-03-09 14:00:17 UTC
Hi ykzhao,
Thanks for the new patch! I will try asap...
Comment 133 alwin 2009-03-14 07:43:15 UTC
Created attachment 20519 [details]
lspci -vxxx after comment #130 and comment #131
Comment 134 alwin 2009-03-14 07:48:36 UTC
Created attachment 20520 [details]
metalog after comment #130 and comment #131

Back again, and I did the following after comment #130 and #131

01. Compiled a new kernel (vanilla-sources-2.6.29_rc8 *WITHOUT* patch), and rebooted
02. Followed http://www.gentoo.org/doc/en/power-management-guide.xml#doc_chap7 to quickly setup Sleep (S3) and Hibernate (S4) swsusp
03. Did lspci -vxxx (attachment lspci.out snip1)
04. Tried Fn-Suspend, button on/off, lid close/open: no events are reported/working
05. Typed setpci -s 00:1f.0 bb.b=0a and nothing more. Now, the three delayed events from step 04 are executed immediately, and reported in the logs. Because I didn't hooked up a script on the Fn-Suspend key press (button/sleep SBTN 00000080 00000001), it does nothing usefull at the moment, it shows up in the logs only. Lid switch activates the laptop-mode script that turns the display off and back on. The button-on/off key press activates a script executing /sbin/init 0, so the laptop shuts down.
06. Booting the laptop again
07. Typed setpci -s 00:1f.0 bb.b=0a so events are working again
08. Did lspci -vxxx (attachment lspci.out snip2)
09. Typed echo disk > /sys/power/state, the laptop enters the hibernate state correctly
10. I press the on/off button, bootloader grub kicks off the system, the S4 system image is restored instead of a normal boot.
11. Did lspci -vxxx (attachment lspci.out snip3)
12. The laptop seems to work fine, but events from Fn-Suspend, button on/off, lid close/open don't work anymore, like before hibernation
13. The logs however show a received event "ac_adapter AC 00000080 00000001"_, that's got something to do with leaving the S4 hibernate state. --> Attachment metalog snip1

=== Doing the same with the pached kernel ===
15. Recompiled the kernel (vanilla-sources-2.6.29_rc8 *WITH* the patch from comment #131 ), and rebooted
16. Did lspci -vxxx (attachment lspci.out snip4)
17. Tried Fn-Suspend, lid close/open: no events are reported/working
18. Typed setpci -s 00:1f.0 bb.b=0a and nothing more. Now, the two delayed events from step 17 are executed immediately and reported in the logs. Because i didn't hooked up a script on the Fn-Suspend key press (button/sleep SBTN 00000080 00000001), it does nothing usefull at the moment, it shows up in the logs only. Lid switch activates the laptop-mode script that turns the display off and back on.
19. Did lspci -vxxx (attachment lspci.out snip5)
20. Typed echo disk > /sys/power/state, the laptop enters the hibernate state correctly
21. I press the on/off button, bootloader grub kicks off the system, the S4 system image is restored instead of a normal boot.
22. Did lspci -vxxx (attachment lspci.out snip6)
23. The laptop seems to work fine, but events from Fn-Suspend, button on/off, lid close/open don't work anymore, like before last hibernation
24. The logs however show a received event "ac_adapter AC 00000080 00000001"_, that's got something to do with leaving the S4 hibernate state. --> Attachment metalog snip2

After using the debug patch, events are still not reported unless setpci -s 00:1f.0 bb.b=0a is entered before and after the hibernate state.
Comment 135 ykzhao 2009-03-17 18:43:23 UTC
Hi, Alwin
    Thanks for the detailed test.
    From the test it seems that the problem still exists even when the _WAK object is explicitly executed in course of ACPI initialization. And after the cycle of hibernate/resume it still can't work unless the command of setpci is executed.
    
    Thanks for the test again.
Comment 136 ykzhao 2009-03-23 02:28:06 UTC
*** Bug 11857 has been marked as a duplicate of this bug. ***
Comment 137 Zhang Rui 2009-07-06 03:08:44 UTC
*** Bug 13607 has been marked as a duplicate of this bug. ***
Comment 138 Zhang Rui 2010-02-21 06:06:54 UTC
Len,
why do we still leave this bug open? this seems to be a firmware problem on some old laptops, and there is nothing we can do in Linux/kernel.
why not close it?

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