Bug 1752
|
Description
Michael McCaskill
2003-12-27 00:20:33 UTC
At first, you need post full dmesg. 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). 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. 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. 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. 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? 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. 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. 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 ? 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. *** Bug 2251 has been marked as a duplicate of this bug. *** 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. this is funny. did the power button work after unplug/plug USB device? please add the /proc/interrupts after that. 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. 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. 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
< 9: 60554 IO-APIC-level acpi --- > 9: 64898 IO-APIC-level acpi so many interrupt. please apply the patch in Bug 2200, any difference? No better:
< 9: 13066 IO-APIC-level acpi
---
> 9: 16131 IO-APIC-level acpi
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. 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? 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 So please attach the the acpidmp from the older BIOS and the newer one. Let's have a look at the difference. 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. 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. 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) 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. 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. 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. 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. Oh, I should also add that I'm using a 5150 with the A29 BIOS. Just upgraded to A33 and it booted to a login prompt before freezing. I'm guessing it was a fluke. 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. 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. 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. Could you send me /proc/acpi/dsdt ? --Luming 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.
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 Could you give a little more information about what these changes are and how we should test them? To comment #36, I don't want the BIOS image, because it is useless to me. What I want is /proc/acpi/dsdt. --Luming Created attachment 2976 [details]
Dell Inspiron 5150 dsdt
Dell Inspiron 5150 dsdt (my bios version is A33)
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. 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. I should be able to get access to a Dell 5150 next week. rats, what i thought was a 5150 turns out to be a 5100, and it has no MADT, and no IOAPIC. 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. 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? yes, power button events (CM) worked fine. BIOS version was A31 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. 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? 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. 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.
fixed in linux-2.6.9? 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. 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 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 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 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 acpidmp is in /usr/sbin, or in pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ 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
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 Just power button can't generate interrupt or sleep button and Lid switch also? Could boot option 'osi=' help? 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
do all the failing machines have nvidia? (dell makes these boxes with either nvidia or ati) same failure if nvidia is not loaded? I have a 5100 with ATI and a 5160 with nvidia and both do the same thing. 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). I reproduced the unresponsive button/lid issue with a Dell inspiron 5150 w/ BIOS A38 and Linux-2.6.11-rc2 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 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 Didn't work for me. What version kernel are you using? I've got 2.6.11.7. 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. 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
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. 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 ... ) 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 (?). 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 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 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. 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.
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. 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 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. 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 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? 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. > 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. 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... 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. 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. 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. 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. 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. 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. 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. *** Bug 7019 has been marked as a duplicate of this bug. *** Re: comment #92 No, "noapic" "acpi_irq=edge" doesn't help. Still just a single interrupt registered on IRQ9. 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. _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.
Created attachment 9203 [details]
dmesg wiith acpi_dbg_layer=4 acpi_dbg_level=0xFFFFFFFF
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. 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. 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 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. 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 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. 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. Confirming that the setpci hack from comment #100 works for inspiron 1100 too. Is this sufficient resolution for the problem? Len, is it ok if we close the bug? Thanks. 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. :) 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). Created attachment 15320 [details]
try the debug patch
Will you please try the debug patch and see whether the bug can be fixed?
Thanks.
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. (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 :( I'm also not able to test this issue, as my computer with this bug no longer works. anybody there who can try the debug-patch to bring this long story to an happy end? Created attachment 16902 [details] dmesg after patch comment #110 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. 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. Created attachment 16940 [details] dmesg after patch comment #110 and comment #117 Created attachment 16941 [details] lspci -vxxx after patch comment #110 and comment #117 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. :-) 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. (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... 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. (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 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.
Created attachment 17485 [details] dmesg after patch comment #125 Created attachment 17486 [details] lspci -vxxx after patch comment #125 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. ;-( 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.
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.
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.
Hi ykzhao, Thanks for the new patch! I will try asap... Created attachment 20519 [details] lspci -vxxx after comment #130 and comment #131 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. 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.
*** Bug 11857 has been marked as a duplicate of this bug. *** *** Bug 13607 has been marked as a duplicate of this bug. *** 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? |