public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* halt does not shut the system down
@ 2007-10-08 16:19 John Sigler
  2007-10-09  8:06 ` John Sigler
  2007-10-10  9:11 ` John Sigler
  0 siblings, 2 replies; 20+ messages in thread
From: John Sigler @ 2007-10-08 16:19 UTC (permalink / raw)
  To: linux-kernel; +Cc: robert.moore, len.brown

[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

Hello,

When I run 'halt' the kernel prints:

Halting.
Shutdown: hdc
ACPI: PCI interrupt for device 0000:01:05.0 disabled
ACPI: PCI interrupt for device 0000:01:04.0 disabled
ACPI: PCI interrupt for device 0000:01:03.0 disabled
ACPI: PCI interrupt for device 0000:01:02.0 disabled
Power down.
acpi_power_off called

But the system does not shut down. (The fans keep spinning, the LEDs 
keep shining, the LCD keeps displaying.) Basically, the motherboard is 
still providing power to every component, as if the power supply had 
refused to stop.

Kernel is 2.6.22.1-rt9

I followed the instructions given here:
http://bugzilla.kernel.org/show_bug.cgi?id=6431

# cat /sys/module/acpi/parameters/debug_layer
Description                     Hex        SET
ACPI_UTILITIES                  0x00000001 [*]
ACPI_HARDWARE                   0x00000002 [*]
ACPI_EVENTS                     0x00000004 [*]
ACPI_TABLES                     0x00000008 [*]
ACPI_NAMESPACE                  0x00000010 [*]
ACPI_PARSER                     0x00000020 [*]
ACPI_DISPATCHER                 0x00000040 [*]
ACPI_EXECUTER                   0x00000080 [*]
ACPI_RESOURCES                  0x00000100 [*]
ACPI_CA_DEBUGGER                0x00000200 [*]
ACPI_OS_SERVICES                0x00000400 [*]
ACPI_CA_DISASSEMBLER            0x00000800 [*]
ACPI_COMPILER                   0x00001000 [*]
ACPI_TOOLS                      0x00002000 [*]
ACPI_ALL_DRIVERS                0xFFFF0000 [*]
--
debug_layer = 0xFFFF3FFF ( * = enabled)

# cat /sys/module/acpi/parameters/debug_level
Description                     Hex        SET
ACPI_LV_ERROR                   0x00000001 [*]
ACPI_LV_WARN                    0x00000002 [*]
ACPI_LV_INIT                    0x00000004 [*]
ACPI_LV_DEBUG_OBJECT            0x00000008 [*]
ACPI_LV_INFO                    0x00000010 [*]
ACPI_LV_INIT_NAMES              0x00000020 [*]
ACPI_LV_PARSE                   0x00000040 [*]
ACPI_LV_LOAD                    0x00000080 [*]
ACPI_LV_DISPATCH                0x00000100 [*]
ACPI_LV_EXEC                    0x00000200 [*]
ACPI_LV_NAMES                   0x00000400 [*]
ACPI_LV_OPREGION                0x00000800 [*]
ACPI_LV_BFIELD                  0x00001000 [*]
ACPI_LV_TABLES                  0x00002000 [*]
ACPI_LV_VALUES                  0x00004000 [*]
ACPI_LV_OBJECTS                 0x00008000 [*]
ACPI_LV_RESOURCES               0x00010000 [*]
ACPI_LV_USER_REQUESTS           0x00020000 [*]
ACPI_LV_PACKAGE                 0x00040000 [*]
ACPI_LV_ALLOCATIONS             0x00100000 [*]
ACPI_LV_FUNCTIONS               0x00200000 [*]
ACPI_LV_OPTIMIZATIONS           0x00400000 [*]
ACPI_LV_MUTEX                   0x01000000 [*]
ACPI_LV_THREADS                 0x02000000 [*]
ACPI_LV_IO                      0x04000000 [*]
ACPI_LV_INTERRUPTS              0x08000000 [*]
ACPI_LV_AML_DISASSEMBLE         0x10000000 [*]
ACPI_LV_VERBOSE_INFO            0x20000000 [*]
ACPI_LV_FULL_TABLES             0x40000000 [*]
ACPI_LV_EVENTS                  0x80000000 [*]
--
debug_level = 0xFFFFFFFF (* = enabled)

I've attached my .config and the output of the following commands:
dmesg, lspci, acpidump, halt

Do you have any idea what the problem is?

Regards.

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 12606 bytes --]

Linux version 2.6.22.1-rt9 (root@venus) (gcc version 3.4.6) #2 PREEMPT RT Mon Oct 8 17:27:02 CEST 2007
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fef0000 (usable)
 BIOS-e820: 000000000fef0000 - 000000000fef3000 (ACPI NVS)
 BIOS-e820: 000000000fef3000 - 000000000ff00000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
254MB LOWMEM available.
found SMP MP-table at 000f4fa0
Entering add_active_range(0, 0, 65264) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    65264
early_node_map[1] active PFN ranges
    0:        0 ->    65264
On node 0 totalpages: 65264
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 477 pages used for memmap
  Normal zone: 60691 pages, LIFO batch:15
DMI 2.2 present.
ACPI: RSDP 000F6850, 0014 (r0 IntelR)
ACPI: RSDT 0FEF3000, 002C (r1 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 0FEF3040, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 0FEF30C0, 39B3 (r1 INTELR AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 0FEF0000, 0040
ACPI: APIC 0FEF6A80, 0068 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 10000000 (gap: 0ff00000:eed00000)
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists.  Total pages: 64755
Kernel command line: ro root=/dev/hdc1 console=ttyS0,57600n8 console=tty0 panic=3 apic=debug acpi_pm_good
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
WARNING: experimental RCU implementation.
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 2400.000 MHz processor.
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255916k/261056k available (1513k kernel code, 4644k reserved, 560k data, 148k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xd0800000 - 0xfffb5000   ( 759 MB)
    lowmem  : 0xc0000000 - 0xcfef0000   ( 254 MB)
      .init : 0xc030a000 - 0xc032f000   ( 148 kB)
      .data : 0xc027a641 - 0xc030692c   ( 560 kB)
      .text : 0xc0100000 - 0xc027a641   (1513 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 4802.77 BogoMIPS (lpj=24013893)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 09
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
Parsing all Control Methods:
Table [DSDT](id 0001) - 483 Objects with 44 Devices 132 Methods 29 Regions
 tbxface-0587 [02] tb_load_namespace     : ACPI Tables successfully acquired
evxfevnt-0091 [02] enable                : Transition to ACPI mode successful
Getting VERSION: 50014
Getting VERSION: 50014
Getting ID: 0
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#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 apic1=0 pin1=2 apic2=-1 pin2=-1
Using local APIC timer interrupts.
calibrating APIC timer ...
... lapic delta = 833376
... PM timer delta = 357961
... PM timer result ok
..... delta 833376
..... mult: 35793226
..... calibration result: 1333401
..... CPU clock speed is 2400.1280 MHz.
..... host bus clock speed is 133.3401 MHz.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb3e0, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
evgpeblk-0952 [04] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 6 Wake, Enabled 1 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:...................................................................
Initialized 29/29 Regions 9/9 Fields 19/19 Buffers 10/13 Packages (492 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:..
Executed 2 _INI methods requiring 1 _STA executions (examined 49 objects)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0480-04bf claimed by ICH4 GPIO
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 *9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
IOAPIC[0]: Set PCI routing entry (2-8 -> 0x69 -> IRQ 8 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-13 -> 0x91 -> IRQ 13 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-6 -> 0x59 -> IRQ 6 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-4 -> 0x49 -> IRQ 4 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-3 -> 0x41 -> IRQ 3 Mode:0 Active:0)
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
number of MP IRQ sources: 15.
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 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  1    0    0   0   0    1    1    41
 04 001 01  1    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  1    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  1    0    0   0   0    1    1    69
 09 001 01  0    1    0   0   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  1    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
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
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
pnp: 00:09: ioport range 0x400-0x4bf could not be reserved
pnp: 00:0b: iomem range 0xcb000-0xcbfff has been reserved
pnp: 00:0b: iomem range 0xf0000-0xf7fff could not be reserved
pnp: 00:0b: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0b: iomem range 0xfc000-0xfffff could not be reserved
PCI: Bridge: 0000:00:1e.0
  IO window: c000-cfff
  MEM window: ec000000-edffffff
  PREFETCH window: 10000000-100fffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 6, 294912 bytes)
TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
io scheduler noop registered (default)
Boot video device is 0000:00:02.0
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:01:02.0: e1000_probe: (PCI:33MHz:32-bit) 00:0b:ab:14:32:31
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 17 (level, low) -> IRQ 17
e1000: 0000:01:03.0: e1000_probe: (PCI:33MHz:32-bit) 00:0b:ab:14:32:32
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb9 -> IRQ 18 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:01:04.0[A] -> GSI 18 (level, low) -> IRQ 18
e1000: 0000:01:04.0: e1000_probe: (PCI:33MHz:32-bit) 00:0b:ab:14:32:33
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:01:05.0[A] -> GSI 19 (level, low) -> IRQ 19
e1000: 0000:01:05.0: e1000_probe: (PCI:33MHz:32-bit) 00:0b:ab:14:32:34
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
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
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
Probing IDE interface ide1...
hdc: PQI IDE DiskOnModule, ATA DISK drive
hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdc: set_drive_speed_status: error=0x04 { DriveStatusError }
ide1 at 0x170-0x177,0x376 on irq 15
hdc: max request size: 128KiB
hdc: 256000 sectors (131 MB) w/1KiB Cache, CHS=500/16/32
 hdc: hdc1 hdc2 hdc3 hdc4
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
Using IPI Shortcut mode
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 148k freed
e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

[-- Attachment #3: lspci.txt --]
[-- Type: text/plain, Size: 8348 bytes --]

00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 03)
	Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [e4] Vendor Specific Information

00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03) (prog-if 00 [VGA])
	Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 7
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at ee000000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR+
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: ec000000-edffffff
	Prefetchable memory behind bridge: 10000000-100fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
	Subsystem: Intel Corporation Unknown device 24c2
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at 01f0 [size=8]
	Region 1: I/O ports at 03f4 [size=1]
	Region 2: I/O ports at 0170 [size=8]
	Region 3: I/O ports at 0374 [size=1]
	Region 4: I/O ports at f000 [size=16]
	Region 5: Memory at 10100000 (32-bit, non-prefetchable) [size=1K]

00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
	Subsystem: Intel Corporation Unknown device 24c2
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin B routed to IRQ 5
	Region 4: I/O ports at 0500 [size=32]

01:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
	Subsystem: Intel Corporation PRO/1000 MT Network Connection
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (63750ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at ed000000 (64-bit, non-prefetchable) [size=128K]
	Region 2: Memory at ed080000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at c000 [size=64]
	[virtual] Expansion ROM at 10000000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] PCI-X non-bridge device
		Command: DPERE- ERO+ RBC=512 OST=1
		Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000

01:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
	Subsystem: Intel Corporation PRO/1000 MT Network Connection
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (63750ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at ed020000 (64-bit, non-prefetchable) [size=128K]
	Region 2: Memory at ed0a0000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at c400 [size=64]
	[virtual] Expansion ROM at 10010000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] PCI-X non-bridge device
		Command: DPERE- ERO+ RBC=512 OST=1
		Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000

01:04.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
	Subsystem: Intel Corporation PRO/1000 MT Network Connection
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (63750ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at ed040000 (64-bit, non-prefetchable) [size=128K]
	Region 2: Memory at ed090000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at c800 [size=64]
	[virtual] Expansion ROM at 10020000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] PCI-X non-bridge device
		Command: DPERE- ERO+ RBC=512 OST=1
		Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000

01:05.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
	Subsystem: Intel Corporation PRO/1000 MT Network Connection
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (63750ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 19
	Region 0: Memory at ed060000 (64-bit, non-prefetchable) [size=128K]
	Region 2: Memory at ed0b0000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at cc00 [size=64]
	[virtual] Expansion ROM at 10030000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] PCI-X non-bridge device
		Command: DPERE- ERO+ RBC=512 OST=1
		Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000

01:0f.0 Multimedia video controller: DekTec Digital Video B.V. DTA-105
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 11750ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at ed0c0000 (32-bit, non-prefetchable) [size=2K]


[-- Attachment #4: acpidump.txt.bz2 --]
[-- Type: application/octet-stream, Size: 16647 bytes --]

[-- Attachment #5: halt.txt.bz2 --]
[-- Type: application/octet-stream, Size: 14300 bytes --]

[-- Attachment #6: config-2.6.22.1-rt9.bz2 --]
[-- Type: application/octet-stream, Size: 4599 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-08 16:19 halt does not shut the system down John Sigler
@ 2007-10-09  8:06 ` John Sigler
  2007-10-09 20:04   ` Remy Bohmer
  2007-10-10  9:11 ` John Sigler
  1 sibling, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-09  8:06 UTC (permalink / raw)
  To: linux-kernel, linux-acpi; +Cc: robert.moore, len.brown

John Sigler wrote:

> When I run 'halt' the kernel prints:
> 
> Halting.
> Shutdown: hdc
> ACPI: PCI interrupt for device 0000:01:05.0 disabled
> ACPI: PCI interrupt for device 0000:01:04.0 disabled
> ACPI: PCI interrupt for device 0000:01:03.0 disabled
> ACPI: PCI interrupt for device 0000:01:02.0 disabled
> Power down.
> acpi_power_off called
> 
> But the system does not shut down. (The fans keep spinning, the LEDs 
> keep shining, the LCD keeps displaying.) Basically, the motherboard is 
> still providing power to every component, as if the power supply had 
> refused to stop.

If I disable the 4 integrated NICs in the BIOS, then the kernel prints:

Halting.
Shutdown: hdc
Power down.
acpi_power_off called
  hwsleep-0322 [01] enter_sleep_state     : Entering sleep state [S5]

But the system does not power down.

> Kernel is 2.6.22.1-rt9
> 
> I followed the instructions given here:
> http://bugzilla.kernel.org/show_bug.cgi?id=6431
> 
> # cat /sys/module/acpi/parameters/debug_layer
> Description                     Hex        SET
> ACPI_UTILITIES                  0x00000001 [*]
> ACPI_HARDWARE                   0x00000002 [*]
> ACPI_EVENTS                     0x00000004 [*]
> ACPI_TABLES                     0x00000008 [*]
> ACPI_NAMESPACE                  0x00000010 [*]
> ACPI_PARSER                     0x00000020 [*]
> ACPI_DISPATCHER                 0x00000040 [*]
> ACPI_EXECUTER                   0x00000080 [*]
> ACPI_RESOURCES                  0x00000100 [*]
> ACPI_CA_DEBUGGER                0x00000200 [*]
> ACPI_OS_SERVICES                0x00000400 [*]
> ACPI_CA_DISASSEMBLER            0x00000800 [*]
> ACPI_COMPILER                   0x00001000 [*]
> ACPI_TOOLS                      0x00002000 [*]
> ACPI_ALL_DRIVERS                0xFFFF0000 [*]
> -- 
> debug_layer = 0xFFFF3FFF ( * = enabled)
> 
> # cat /sys/module/acpi/parameters/debug_level
> Description                     Hex        SET
> ACPI_LV_ERROR                   0x00000001 [*]
> ACPI_LV_WARN                    0x00000002 [*]
> ACPI_LV_INIT                    0x00000004 [*]
> ACPI_LV_DEBUG_OBJECT            0x00000008 [*]
> ACPI_LV_INFO                    0x00000010 [*]
> ACPI_LV_INIT_NAMES              0x00000020 [*]
> ACPI_LV_PARSE                   0x00000040 [*]
> ACPI_LV_LOAD                    0x00000080 [*]
> ACPI_LV_DISPATCH                0x00000100 [*]
> ACPI_LV_EXEC                    0x00000200 [*]
> ACPI_LV_NAMES                   0x00000400 [*]
> ACPI_LV_OPREGION                0x00000800 [*]
> ACPI_LV_BFIELD                  0x00001000 [*]
> ACPI_LV_TABLES                  0x00002000 [*]
> ACPI_LV_VALUES                  0x00004000 [*]
> ACPI_LV_OBJECTS                 0x00008000 [*]
> ACPI_LV_RESOURCES               0x00010000 [*]
> ACPI_LV_USER_REQUESTS           0x00020000 [*]
> ACPI_LV_PACKAGE                 0x00040000 [*]
> ACPI_LV_ALLOCATIONS             0x00100000 [*]
> ACPI_LV_FUNCTIONS               0x00200000 [*]
> ACPI_LV_OPTIMIZATIONS           0x00400000 [*]
> ACPI_LV_MUTEX                   0x01000000 [*]
> ACPI_LV_THREADS                 0x02000000 [*]
> ACPI_LV_IO                      0x04000000 [*]
> ACPI_LV_INTERRUPTS              0x08000000 [*]
> ACPI_LV_AML_DISASSEMBLE         0x10000000 [*]
> ACPI_LV_VERBOSE_INFO            0x20000000 [*]
> ACPI_LV_FULL_TABLES             0x40000000 [*]
> ACPI_LV_EVENTS                  0x80000000 [*]
> -- 
> debug_level = 0xFFFFFFFF (* = enabled)
> 
> I've attached my .config and the output of the following commands:
> dmesg, lspci, acpidump, halt
> 
> Do you have any idea what the problem is?


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-09  8:06 ` John Sigler
@ 2007-10-09 20:04   ` Remy Bohmer
  2007-10-10  9:56     ` John Sigler
  0 siblings, 1 reply; 20+ messages in thread
From: Remy Bohmer @ 2007-10-09 20:04 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-kernel, linux-acpi, robert.moore, len.brown

Hello John,

> John Sigler wrote:
> > When I run 'halt' the kernel prints:
> > Halting.
> > Shutdown: hdc
> > ACPI: PCI interrupt for device 0000:01:05.0 disabled
> > ACPI: PCI interrupt for device 0000:01:04.0 disabled
> > ACPI: PCI interrupt for device 0000:01:03.0 disabled
> > ACPI: PCI interrupt for device 0000:01:02.0 disabled
> > Power down.
> > acpi_power_off called
> >
> > But the system does not shut down. (The fans keep spinning, the LEDs

I have seen this behavior earlier on a system with the SMI interrupt
disabled. I do not know if this the case here, it is just a hint.
By the way, some distros bring the CPU in a halted state on a 'halt'
command, instead of powering off (actually very logical). For real
powering off these distros require the obvious 'poweroff' command.

Some long shots, maybe it helps...

Kind Regards,

Remy

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-08 16:19 halt does not shut the system down John Sigler
  2007-10-09  8:06 ` John Sigler
@ 2007-10-10  9:11 ` John Sigler
  2007-10-12  9:58   ` John Sigler
  1 sibling, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-10  9:11 UTC (permalink / raw)
  To: linux-kernel, linux-acpi; +Cc: robert.moore, len.brown

(The original message seems to have been ignored by the mailing list 
robot, probably because the attachments made it too large. Re-send with 
links instead of attaching the documents to the message.)

John Sigler wrote:

> When I run 'halt' the kernel prints:
> 
> Halting.
> Shutdown: hdc
> ACPI: PCI interrupt for device 0000:01:05.0 disabled
> ACPI: PCI interrupt for device 0000:01:04.0 disabled
> ACPI: PCI interrupt for device 0000:01:03.0 disabled
> ACPI: PCI interrupt for device 0000:01:02.0 disabled
> Power down.
> acpi_power_off called
> 
> But the system does not shut down. (The fans keep spinning, the LEDs 
> keep shining, the LCD keeps displaying.) Basically, the motherboard is 
> still providing power to every component, as if the power supply had 
> refused to stop.
> 
> Kernel is 2.6.22.1-rt9
> 
> I followed the instructions given here:
> http://bugzilla.kernel.org/show_bug.cgi?id=6431
> 
> # cat /sys/module/acpi/parameters/debug_layer
> Description                     Hex        SET
> ACPI_UTILITIES                  0x00000001 [*]
> ACPI_HARDWARE                   0x00000002 [*]
> ACPI_EVENTS                     0x00000004 [*]
> ACPI_TABLES                     0x00000008 [*]
> ACPI_NAMESPACE                  0x00000010 [*]
> ACPI_PARSER                     0x00000020 [*]
> ACPI_DISPATCHER                 0x00000040 [*]
> ACPI_EXECUTER                   0x00000080 [*]
> ACPI_RESOURCES                  0x00000100 [*]
> ACPI_CA_DEBUGGER                0x00000200 [*]
> ACPI_OS_SERVICES                0x00000400 [*]
> ACPI_CA_DISASSEMBLER            0x00000800 [*]
> ACPI_COMPILER                   0x00001000 [*]
> ACPI_TOOLS                      0x00002000 [*]
> ACPI_ALL_DRIVERS                0xFFFF0000 [*]
> -- 
> debug_layer = 0xFFFF3FFF ( * = enabled)
> 
> # cat /sys/module/acpi/parameters/debug_level
> Description                     Hex        SET
> ACPI_LV_ERROR                   0x00000001 [*]
> ACPI_LV_WARN                    0x00000002 [*]
> ACPI_LV_INIT                    0x00000004 [*]
> ACPI_LV_DEBUG_OBJECT            0x00000008 [*]
> ACPI_LV_INFO                    0x00000010 [*]
> ACPI_LV_INIT_NAMES              0x00000020 [*]
> ACPI_LV_PARSE                   0x00000040 [*]
> ACPI_LV_LOAD                    0x00000080 [*]
> ACPI_LV_DISPATCH                0x00000100 [*]
> ACPI_LV_EXEC                    0x00000200 [*]
> ACPI_LV_NAMES                   0x00000400 [*]
> ACPI_LV_OPREGION                0x00000800 [*]
> ACPI_LV_BFIELD                  0x00001000 [*]
> ACPI_LV_TABLES                  0x00002000 [*]
> ACPI_LV_VALUES                  0x00004000 [*]
> ACPI_LV_OBJECTS                 0x00008000 [*]
> ACPI_LV_RESOURCES               0x00010000 [*]
> ACPI_LV_USER_REQUESTS           0x00020000 [*]
> ACPI_LV_PACKAGE                 0x00040000 [*]
> ACPI_LV_ALLOCATIONS             0x00100000 [*]
> ACPI_LV_FUNCTIONS               0x00200000 [*]
> ACPI_LV_OPTIMIZATIONS           0x00400000 [*]
> ACPI_LV_MUTEX                   0x01000000 [*]
> ACPI_LV_THREADS                 0x02000000 [*]
> ACPI_LV_IO                      0x04000000 [*]
> ACPI_LV_INTERRUPTS              0x08000000 [*]
> ACPI_LV_AML_DISASSEMBLE         0x10000000 [*]
> ACPI_LV_VERBOSE_INFO            0x20000000 [*]
> ACPI_LV_FULL_TABLES             0x40000000 [*]
> ACPI_LV_EVENTS                  0x80000000 [*]
> -- 
> debug_level = 0xFFFFFFFF (* = enabled)

http://linux.kernel.free.fr/halt/config-2.6.22.1-rt9
http://linux.kernel.free.fr/halt/acpidump.txt
http://linux.kernel.free.fr/halt/dmesg.txt
http://linux.kernel.free.fr/halt/halt.txt
http://linux.kernel.free.fr/halt/lspci.txt

Do you know what could be the problem?
(Meanwhile, I will investigate Remy Bohmer's suggestion.)

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-09 20:04   ` Remy Bohmer
@ 2007-10-10  9:56     ` John Sigler
  2007-10-12 19:29       ` Remy Bohmer
  0 siblings, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-10  9:56 UTC (permalink / raw)
  To: Remy Bohmer; +Cc: linux-kernel, linux-acpi, robert.moore, len.brown

Hello Remy,

Remy Bohmer wrote:

> John Sigler wrote:
> 
>> When I run 'halt' the kernel prints:
>> Halting.
>> Shutdown: hdc
>> ACPI: PCI interrupt for device 0000:01:05.0 disabled
>> ACPI: PCI interrupt for device 0000:01:04.0 disabled
>> ACPI: PCI interrupt for device 0000:01:03.0 disabled
>> ACPI: PCI interrupt for device 0000:01:02.0 disabled
>> Power down.
>> acpi_power_off called
>>
>> But the system does not shut down. (The fans keep spinning, the LEDs
> 
> I have seen this behavior earlier on a system with the SMI interrupt
> disabled. I do not know if this the case here, it is just a hint.

Thanks for the suggestion. I didn't see anything related to SMM in the 
BIOS menus. However, the system has real-time constraints. Thus, I'd 
turn SMM off if I knew how :-)

    Phoenix - AwardBIOS v6.00PG, An Energy Star Ally
    Copyright (C) 1984-2003, Phoenix Technologies, LTD
*** NAMB-3140 BIOS V1.20 ***
03/27/2006-i845GV-W83627-6A69VAKHC-00

> By the way, some distros bring the CPU in a halted state on a 'halt'
> command, instead of powering off (actually very logical). For real
> powering off these distros require the obvious 'poweroff' command.

Good suggestion. I'm using sysvinit-2.86
http://freshmeat.net/projects/sysvinit/

AFAIU, poweroff is equivalent to halt -p

halt (no option) calls reboot(RB_HALT);
poweroff or halt -p calls reboot(RB_POWER_OFF);
man 2 reboot

Alas, when I run 'poweroff' the kernel prints the same information:

Halting.
Shutdown: hdc
ACPI: PCI interrupt for device 0000:01:05.0 disabled
ACPI: PCI interrupt for device 0000:01:04.0 disabled
ACPI: PCI interrupt for device 0000:01:03.0 disabled
ACPI: PCI interrupt for device 0000:01:02.0 disabled
Power down.
acpi_power_off called

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-10  9:11 ` John Sigler
@ 2007-10-12  9:58   ` John Sigler
  2007-10-12 10:41     ` Alexey Starikovskiy
  0 siblings, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-12  9:58 UTC (permalink / raw)
  To: linux-acpi; +Cc: linux-kernel, robert.moore, len.brown

John Sigler wrote:

> When I run 'halt' the kernel prints:
>
> Halting.
> Shutdown: hdc
> ACPI: PCI interrupt for device 0000:01:05.0 disabled
> ACPI: PCI interrupt for device 0000:01:04.0 disabled
> ACPI: PCI interrupt for device 0000:01:03.0 disabled
> ACPI: PCI interrupt for device 0000:01:02.0 disabled
> Power down.
> acpi_power_off called
>
> But the system does not shut down. (The fans keep spinning, the LEDs 
> keep shining, the LCD keeps displaying.) Basically, the motherboard is 
> still providing power to every component, as if the power supply had 
> refused to stop.
>
> http://linux.kernel.free.fr/halt/config-2.6.22.1-rt9
> http://linux.kernel.free.fr/halt/acpidump.txt
> http://linux.kernel.free.fr/halt/dmesg.txt
> http://linux.kernel.free.fr/halt/halt.txt
> http://linux.kernel.free.fr/halt/lspci.txt

Is there something else I can provide that might help in identifying
the problem?

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-12  9:58   ` John Sigler
@ 2007-10-12 10:41     ` Alexey Starikovskiy
  2007-10-12 13:11       ` John Sigler
  0 siblings, 1 reply; 20+ messages in thread
From: Alexey Starikovskiy @ 2007-10-12 10:41 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

Could you please open bug at bugzilla.kernel.org and put all these files there?

Thanks,
Alex.

John Sigler wrote:
> John Sigler wrote:
> 
>> When I run 'halt' the kernel prints:
>>
>> Halting.
>> Shutdown: hdc
>> ACPI: PCI interrupt for device 0000:01:05.0 disabled
>> ACPI: PCI interrupt for device 0000:01:04.0 disabled
>> ACPI: PCI interrupt for device 0000:01:03.0 disabled
>> ACPI: PCI interrupt for device 0000:01:02.0 disabled
>> Power down.
>> acpi_power_off called
>>
>> But the system does not shut down. (The fans keep spinning, the LEDs 
>> keep shining, the LCD keeps displaying.) Basically, the motherboard is 
>> still providing power to every component, as if the power supply had 
>> refused to stop.
>>
>> http://linux.kernel.free.fr/halt/config-2.6.22.1-rt9
>> http://linux.kernel.free.fr/halt/acpidump.txt
>> http://linux.kernel.free.fr/halt/dmesg.txt
>> http://linux.kernel.free.fr/halt/halt.txt
>> http://linux.kernel.free.fr/halt/lspci.txt
> 
> Is there something else I can provide that might help in identifying
> the problem?
> 
> Regards.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-12 10:41     ` Alexey Starikovskiy
@ 2007-10-12 13:11       ` John Sigler
  2007-10-15 10:36         ` John Sigler
  0 siblings, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-12 13:11 UTC (permalink / raw)
  To: Alexey Starikovskiy; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

Alexey Starikovskiy wrote:

> Could you please open bug at bugzilla.kernel.org and put all these
> files there?

http://bugzilla.kernel.org/show_bug.cgi?id=9148

(In my browser, halt output is incorrectly displayed in UTF-8.)

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-10  9:56     ` John Sigler
@ 2007-10-12 19:29       ` Remy Bohmer
  0 siblings, 0 replies; 20+ messages in thread
From: Remy Bohmer @ 2007-10-12 19:29 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-kernel, linux-acpi, robert.moore, len.brown

Hello John,

> Thanks for the suggestion. I didn't see anything related to SMM in the
> BIOS menus. However, the system has real-time constraints. Thus, I'd
> turn SMM off if I knew how :-)

Here you can find a driver that can disable and enable the SMI
interrupt in the chipset. It supports up to the ICH5 chipsets, but by
adding the proper device/vendor IDs you can also make it support newer
chipsets.
http://www.bohmer.net/smi.tar.bz2

> AFAIU, poweroff is equivalent to halt -p

You are right.

Kind Regards,

Remy

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-12 13:11       ` John Sigler
@ 2007-10-15 10:36         ` John Sigler
  2007-10-15 11:11           ` Alexey Starikovskiy
  2007-10-16 10:51           ` John Sigler
  0 siblings, 2 replies; 20+ messages in thread
From: John Sigler @ 2007-10-15 10:36 UTC (permalink / raw)
  To: linux-acpi; +Cc: linux-kernel, robert.moore, len.brown

John Sigler wrote:

> Alexey Starikovskiy wrote:
> 
>> Could you please open bug at bugzilla.kernel.org and put all these
>> files there?
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=9148

Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to 
hang my system in acpi_os_write_port(). What can I do about that?

Is it a BIOS issue? a kernel issue? a hardware issue?

(All my results are attached to the bug report.)

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-15 10:36         ` John Sigler
@ 2007-10-15 11:11           ` Alexey Starikovskiy
  2007-10-15 13:29             ` John Sigler
  2007-10-16 10:51           ` John Sigler
  1 sibling, 1 reply; 20+ messages in thread
From: Alexey Starikovskiy @ 2007-10-15 11:11 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

John Sigler wrote:
> John Sigler wrote:
> 
>> Alexey Starikovskiy wrote:
>>
>>> Could you please open bug at bugzilla.kernel.org and put all these
>>> files there?
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=9148
> 
> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
> hang my system in acpi_os_write_port(). What can I do about that?
That is supposed to turn your machine off. At least we now know that ACPI 
did try to turn it off.
You could also try different kernel or defconfig.
> 
> Is it a BIOS issue? a kernel issue? a hardware issue?
I think _other_ OS could turn your machine off just fine, so the issue is not HW, not BIOS.
Probably, first thing to try is 2.6.23.1 as it was just released and has some changes in
power management section...

Regards,
Alex.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-15 11:11           ` Alexey Starikovskiy
@ 2007-10-15 13:29             ` John Sigler
  2007-10-15 14:03               ` Alexey Starikovskiy
  0 siblings, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-15 13:29 UTC (permalink / raw)
  To: Alexey Starikovskiy; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

Alexey Starikovskiy wrote:

> John Sigler wrote:
> 
>> Alexey Starikovskiy wrote:
>> 
>>> Could you please open bug at bugzilla.kernel.org and put all
>>> these files there?
>> 
>> http://bugzilla.kernel.org/show_bug.cgi?id=9148
>> 
>> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears
>> to hang my system in acpi_os_write_port(). What can I do about that?
> 
> That is supposed to turn your machine off. At least we now know that
> ACPI did try to turn it off. You could also try different kernel or
> defconfig.

What's defconfig? .config? Which option(s) might have an impact?

>> Is it a BIOS issue? a kernel issue? a hardware issue?
> 
> I think _other_ OS could turn your machine off just fine, so the
> issue is not HW, not BIOS. Probably, first thing to try is 2.6.23.1
> as it was just released and has some changes in power management
> section...

I have the same problem in 2.6.23.1 (cf. my bug report in the database)

I'll ask the manufacturer whether they could get poweroff to work.

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-15 13:29             ` John Sigler
@ 2007-10-15 14:03               ` Alexey Starikovskiy
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Starikovskiy @ 2007-10-15 14:03 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

John Sigler wrote:
> Alexey Starikovskiy wrote:
> 
>> John Sigler wrote:
>>
>>> Alexey Starikovskiy wrote:
>>>
>>>> Could you please open bug at bugzilla.kernel.org and put all
>>>> these files there?
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=9148
>>>
>>> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears
>>> to hang my system in acpi_os_write_port(). What can I do about that?
>>
>> That is supposed to turn your machine off. At least we now know that
>> ACPI did try to turn it off. You could also try different kernel or
>> defconfig.
> 
> What's defconfig? .config? Which option(s) might have an impact?

This is an option to make. It creates .config file with some default settings,
appropriate to most computers.

>>> Is it a BIOS issue? a kernel issue? a hardware issue?
>>
>> I think _other_ OS could turn your machine off just fine, so the
>> issue is not HW, not BIOS. Probably, first thing to try is 2.6.23.1
>> as it was just released and has some changes in power management
>> section...
> 
> I have the same problem in 2.6.23.1 (cf. my bug report in the database)
> 
> I'll ask the manufacturer whether they could get poweroff to work.
> 
> Regards.
> 


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-15 10:36         ` John Sigler
  2007-10-15 11:11           ` Alexey Starikovskiy
@ 2007-10-16 10:51           ` John Sigler
  2007-10-16 12:37             ` linux-os (Dick Johnson)
  1 sibling, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-16 10:51 UTC (permalink / raw)
  To: linux-acpi; +Cc: linux-kernel, robert.moore, len.brown

John Sigler wrote:

> Alexey Starikovskiy wrote:
>
>> Could you please open bug at bugzilla.kernel.org and put all these
>> files there?
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9148
> 
> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
> hang my system in acpi_os_write_port(). What can I do about that?

Another observation: if I connect a screen to the system's VGA port, 
when I call 'poweroff' the screen goes into power saving mode. This 
seems to indicate that the integrated video card is properly shut down.

So the fans keep spinning, the LEDs keep shining, the LCD keeps 
displaying, but the video card is shut down?

Might this help pinpoint the problem?

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-16 10:51           ` John Sigler
@ 2007-10-16 12:37             ` linux-os (Dick Johnson)
  2007-10-16 13:08               ` John Sigler
  0 siblings, 1 reply; 20+ messages in thread
From: linux-os (Dick Johnson) @ 2007-10-16 12:37 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown


On Tue, 16 Oct 2007, John Sigler wrote:

> John Sigler wrote:
>
>> Alexey Starikovskiy wrote:
>>
>>> Could you please open bug at bugzilla.kernel.org and put all these
>>> files there?
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=9148
>>
>> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
>> hang my system in acpi_os_write_port(). What can I do about that?
>
> Another observation: if I connect a screen to the system's VGA port,
> when I call 'poweroff' the screen goes into power saving mode. This
> seems to indicate that the integrated video card is properly shut down.
>
> So the fans keep spinning, the LEDs keep shining, the LCD keeps
> displaying, but the video card is shut down?
>
> Might this help pinpoint the problem?
>
> Regards.
> -

Check the BIOS to see if the "Power Button" is configured to
shut the system down. Some BIOS configure APM to do what
the power button does!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-16 12:37             ` linux-os (Dick Johnson)
@ 2007-10-16 13:08               ` John Sigler
  2007-10-16 17:06                 ` Alexey Starikovskiy
  0 siblings, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-16 13:08 UTC (permalink / raw)
  To: Dick Johnson; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

Dick Johnson wrote:

> John Sigler wrote:
> 
>> http://bugzilla.kernel.org/show_bug.cgi?id=9148
>>
>> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
>> hang my system in acpi_os_write_port(). What can I do about that?
>>
>> Another observation: if I connect a screen to the system's VGA port,
>> when I call 'poweroff' the screen goes into power saving mode. This
>> seems to indicate that the integrated video card is properly shut down.
>>
>> So the fans keep spinning, the LEDs keep shining, the LCD keeps
>> displaying, but the video card is shut down?
>>
>> Might this help pinpoint the problem?
> 
> Check the BIOS to see if the "Power Button" is configured to
> shut the system down. Some BIOS configure APM to do what
> the power button does!

Here is the relevant BIOS menu.

         Phoenix - AwardBIOS CMOS Setup Utility
                 Power Management Setup
+=====================================================+
|    ACPI Function             [Enabled]              |
|    MODEM Use IRQ             [NA]                   |
|    Soft-Off by PWR-BTTN      [Instant-Off]          |
|    CPU THRM-Throttling       [50.0%]                |
|    Resume by Alarm           [Disabled]             |
|  x  Date(of Month) Alarm       0                    |
|  x  Time(hh:mm:ss) Alarm       0 :  0 :  0          |
|                                                     |
|    ** Reload Global Timer Events **                 |
|    Primary IDE 0             [Disabled]             |
|    Primary IDE 1             [Disabled]             |
|    Secondary IDE 0           [Disabled]             |
|    Secondary IDE 1           [Disabled]             |
|    FDD,COM,LPT Port          [Disabled]             |
|    PCI PIRQ[A-D]#            [Disabled]             |
|                                                     |
+=====================================================+

          +===================================+
          | Soft-Off by PWR-BTTN              |
          |-----------------------------------|
          | Instant-Off  ..... [v]            |
          | Delay 4 Sec. ..... [ ]            |
          |                                   |
          |-----------------------------------|
          |  ^V:Move ENTER:Accept ESC:Abort   |
          +===================================+

'Instant-Off' is the appropriate setting, right?

In a different menu, there are two other (relevant?) options:

     PWRON After PWR-Fail      [On]
     Watch Dog Timer Select    [Disabled]

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-16 13:08               ` John Sigler
@ 2007-10-16 17:06                 ` Alexey Starikovskiy
  2007-10-17  8:09                   ` John Sigler
  0 siblings, 1 reply; 20+ messages in thread
From: Alexey Starikovskiy @ 2007-10-16 17:06 UTC (permalink / raw)
  To: John Sigler
  Cc: Dick Johnson, linux-acpi, linux-kernel, robert.moore, len.brown

John Sigler wrote:

>          +===================================+
>          | Soft-Off by PWR-BTTN              |
>          |-----------------------------------|
>          | Instant-Off  ..... [v]            |
>          | Delay 4 Sec. ..... [ ]            |
>          |                                   |
>          |-----------------------------------|
>          |  ^V:Move ENTER:Accept ESC:Abort   |
>          +===================================+
> 
> 'Instant-Off' is the appropriate setting, right?
Actually, default should be 4 sec delay. OS should have 
a chance to shut down the system...


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-16 17:06                 ` Alexey Starikovskiy
@ 2007-10-17  8:09                   ` John Sigler
  2007-10-17  8:11                     ` Alexey Starikovskiy
  0 siblings, 1 reply; 20+ messages in thread
From: John Sigler @ 2007-10-17  8:09 UTC (permalink / raw)
  To: Alexey Starikovskiy; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

Alexey Starikovskiy wrote:

> John Sigler wrote:
> 
>>          +===================================+
>>          | Soft-Off by PWR-BTTN              |
>>          |-----------------------------------|
>>          | Instant-Off  ..... [v]            |
>>          | Delay 4 Sec. ..... [ ]            |
>>          |                                   |
>>          |-----------------------------------|
>>          |  ^V:Move ENTER:Accept ESC:Abort   |
>>          +===================================+
>>
>> 'Instant-Off' is the appropriate setting, right?
>
> Actually, default should be 4 sec delay. OS should have 
> a chance to shut down the system...

I don't see why this setting would have an impact on the outcome
of the 'halt' and 'poweroff' commands.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-17  8:09                   ` John Sigler
@ 2007-10-17  8:11                     ` Alexey Starikovskiy
  2007-10-17  9:59                       ` John Sigler
  0 siblings, 1 reply; 20+ messages in thread
From: Alexey Starikovskiy @ 2007-10-17  8:11 UTC (permalink / raw)
  To: John Sigler; +Cc: linux-acpi, linux-kernel, robert.moore, len.brown

John Sigler wrote:
> Alexey Starikovskiy wrote:
> 
>> John Sigler wrote:
>>
>>>          +===================================+
>>>          | Soft-Off by PWR-BTTN              |
>>>          |-----------------------------------|
>>>          | Instant-Off  ..... [v]            |
>>>          | Delay 4 Sec. ..... [ ]            |
>>>          |                                   |
>>>          |-----------------------------------|
>>>          |  ^V:Move ENTER:Accept ESC:Abort   |
>>>          +===================================+
>>>
>>> 'Instant-Off' is the appropriate setting, right?
>>
>> Actually, default should be 4 sec delay. OS should have a chance to
>> shut down the system...
> 
> I don't see why this setting would have an impact on the outcome
> of the 'halt' and 'poweroff' commands.
> 
Well, it is not possible to tell, what BIOS writer have connected to this flag...


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: halt does not shut the system down
  2007-10-17  8:11                     ` Alexey Starikovskiy
@ 2007-10-17  9:59                       ` John Sigler
  0 siblings, 0 replies; 20+ messages in thread
From: John Sigler @ 2007-10-17  9:59 UTC (permalink / raw)
  To: Alexey Starikovskiy, len.brown; +Cc: linux-acpi, linux-kernel, robert.moore

Alexey Starikovskiy wrote:

> John Sigler wrote:
> 
>> Alexey Starikovskiy wrote:
>>
>>> John Sigler wrote:
>>>
>>>>          +===================================+
>>>>          | Soft-Off by PWR-BTTN              |
>>>>          |-----------------------------------|
>>>>          | Instant-Off  ..... [v]            |
>>>>          | Delay 4 Sec. ..... [ ]            |
>>>>          |                                   |
>>>>          |-----------------------------------|
>>>>          |  ^V:Move ENTER:Accept ESC:Abort   |
>>>>          +===================================+
>>>>
>>>> 'Instant-Off' is the appropriate setting, right?
>>>
>>> Actually, default should be 4 sec delay. OS should have a chance to
>>> shut down the system...
>>
>> I don't see why this setting would have an impact on the outcome
>> of the 'halt' and 'poweroff' commands.
>>
> Well, it is not possible to tell, what BIOS writer have connected to this flag...

(It sucks to be stuck with a closed proprietary BIOS.)

I tested the other setting, and it didn't change anything.
The system remains powered on after executing poweroff.

Len: the system is 100% Intel (Intel CPU, Intel north bridge, Intel 
south bridge, Intel integrated network controllers). Have Intel 
engineers run into the same problem on a similar platform?

http://bugzilla.kernel.org/show_bug.cgi?id=9148

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2007-10-17  9:59 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-08 16:19 halt does not shut the system down John Sigler
2007-10-09  8:06 ` John Sigler
2007-10-09 20:04   ` Remy Bohmer
2007-10-10  9:56     ` John Sigler
2007-10-12 19:29       ` Remy Bohmer
2007-10-10  9:11 ` John Sigler
2007-10-12  9:58   ` John Sigler
2007-10-12 10:41     ` Alexey Starikovskiy
2007-10-12 13:11       ` John Sigler
2007-10-15 10:36         ` John Sigler
2007-10-15 11:11           ` Alexey Starikovskiy
2007-10-15 13:29             ` John Sigler
2007-10-15 14:03               ` Alexey Starikovskiy
2007-10-16 10:51           ` John Sigler
2007-10-16 12:37             ` linux-os (Dick Johnson)
2007-10-16 13:08               ` John Sigler
2007-10-16 17:06                 ` Alexey Starikovskiy
2007-10-17  8:09                   ` John Sigler
2007-10-17  8:11                     ` Alexey Starikovskiy
2007-10-17  9:59                       ` John Sigler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox