NetBSD Problem Report #44366

From kefren@kefren.ngnetworks.ro  Mon Jan 10 11:49:30 2011
Return-Path: <kefren@kefren.ngnetworks.ro>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 84D6663B89A
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 10 Jan 2011 11:49:30 +0000 (UTC)
Message-Id: <20110110114925.1A577283C10A@kefren.ngnetworks.ro>
Date: Mon, 10 Jan 2011 13:49:25 +0200 (EET)
From: mihai.chelaru@ngnetworks.ro
Reply-To: mihai.chelaru@ngnetworks.ro
To: gnats-bugs@gnats.NetBSD.org
Subject: poweroff doesn't work
X-Send-Pr-Version: 3.95

>Number:         44366
>Category:       kern
>Synopsis:       ACPI poweroff doesn't work
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 10 11:50:00 +0000 2011
>Last-Modified:  Fri Jan 14 14:25:03 +0000 2011
>Originator:     Mihai Chelaru
>Release:        NetBSD 5.99.43
>Organization:

>Environment:


System: NetBSD kefren.ngnetworks.ro 5.99.43 NetBSD 5.99.43 (Home) #49: Fri Jan 7 10:09:44 EET 2011 kefren@kefren.ngnetworks.ro:/disk3/work/netbsd-current/src/sys/arch/amd64/compile/obj/Home amd64
Architecture: x86_64
Machine: amd64
>Description:

poweroff doesn't work in -current on some computers. Affected computers
include:

	* Dell Mini 10 (i386) - the screen turns off but fans
	are still working and power led is still on.
	* custom made (amd64) Asus mainboard - see dmesg below -
	in most cases it shuts down the HDDs and it even turns
	off the front panel LEDs (including powerled), but power
	is not cut, fans are still spinning, the video card is still
	working so I can read the "acpi: entering state 5" message.
	This is the strangest one, because twice or thrice it
	completed the shutdown.

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.99.43 (Home) #49: Fri Jan  7 10:09:44 EET 2011
        kefren@kefren.ngnetworks.ro:/disk3/work/netbsd-current/src/sys/arch/amd64/compile/obj/Home
total memory = 4095 MB
avail memory = 3952 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
System manufacturer P5Q-E (System Version)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel 686-class, 2499MHz, id 0x10677
cpu1 at mainbus0 apid 1: Intel 686-class, 2499MHz, id 0x10677
cpu2 at mainbus0 apid 2: Intel 686-class, 2499MHz, id 0x10677
cpu3 at mainbus0 apid 3: Intel 686-class, 2499MHz, id 0x10677
ioapic0 at mainbus0 apid 4: pa 0xfec00000, version 20, 24 pins
acpi0 at mainbus0: Intel ACPICA 20100528
acpi0: X/RSDT: OemId <A_M_I_,OEMRSDT ,04000906>, AslId <MSFT,00000097>
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
acpicpu0 at acpi0 (P001): ACPI CPU
ACPI Warning: Incorrect checksum in table [OEMB] - 0xF7, should be 0xEE (20100528/tbutils-354)
acpicpu1 at acpi0 (P002): ACPI CPU
acpicpu2 at acpi0 (P003): ACPI CPU
acpicpu3 at acpi0 (P004): ACPI CPU
MCH (PNP0C01) at acpi0 not configured
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
FDC (PNP0700) at acpi0 not configured
SIOR (PNP0C02) at acpi0 not configured
RMSC (PNP0C02) at acpi0 not configured
aibs0 at acpi0 (ASOC, ATK0110-16843024): ASUSTeK AI Booster
aibs0: V0: 0x06020000        Vcore Voltage   800 /  1600  0x1
aibs0: V1: 0x06020001         +3.3 Voltage  2970 /  3630  0x1
aibs0: V2: 0x06020002           +5 Voltage  4500 /  5500  0x1
aibs0: V3: 0x06020003          +12 Voltage 10200 / 13800  0x1
aibs0: T0: 0x06030000      CPU Temperature   600 /   950  0x10001
aibs0: T1: 0x06030001       MB Temperature   450 /   950  0x10001
aibs0: F0: 0x06040000        CPU FAN Speed   600 /  7200  0x10001
aibs0: F1: 0x06040001   CHASSIS1 FAN Speed   600 /  7200  0x10001
aibs0: F2: 0x06040002   CHASSIS2 FAN Speed   600 /  7200  0x10001
aibs0: F3: 0x06040003   CHASSIS3 FAN Speed   600 /  7200  0x10001
aibs0: F4: 0x06040004      POWER FAN Speed   600 /  7200  0x10001
hpet0 at acpi0 (HPET, PNP0103): mem 0xfed00000-0xfed003ff
timecounter: Timecounter "hpet0" frequency 14318179 Hz quality 2000
FWH (INT0800) at acpi0 not configured
FWHE (PNP0C02) at acpi0 not configured
UAR1 (PNP0501) at acpi0 not configured
OMSC (PNP0C02) at acpi0 not configured
PCIE (PNP0C02) at acpi0 not configured
RMEM (PNP0C01) at acpi0 not configured
acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button
attimer1: attached to pcppi1
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x2e20 (rev. 0x02)
agp0 at pchb0: can't find internal VGA device config space
ppb0 at pci0 dev 1 function 0: vendor 0x8086 product 0x2e21 (rev. 0x02)
ppb0: unsupported PCI Express version
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
vga0 at pci1 dev 0 function 0: vendor 0x1002 product 0x9598 (rev. 0x00)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
radeondrm0 at vga0: ATI ATI Radeon HD 3600 XT
radeondrm0: Initialized radeon 1.29.0 20080613
hdaudio0 at pci1 dev 0 function 1: HD Audio Controller
hdaudio0: interrupting at ioapic0 pin 17
hdafg0 at hdaudio0: ATI RS600 HDMI
hdafg0: DAC00 2ch: Digital Out [Jack]
hdafg0: 2ch/0ch 48000Hz 16/16
audio0 at hdafg0: half duplex, playback
uhci0 at pci0 dev 26 function 0: vendor 0x8086 product 0x3a37 (rev. 0x00)
uhci0: interrupting at ioapic0 pin 16
usb0 at uhci0: USB revision 1.0
uhci1 at pci0 dev 26 function 1: vendor 0x8086 product 0x3a38 (rev. 0x00)
uhci1: interrupting at ioapic0 pin 21
usb1 at uhci1: USB revision 1.0
uhci2 at pci0 dev 26 function 2: vendor 0x8086 product 0x3a39 (rev. 0x00)
uhci2: interrupting at ioapic0 pin 18
usb2 at uhci2: USB revision 1.0
ehci0 at pci0 dev 26 function 7: vendor 0x8086 product 0x3a3c (rev. 0x00)
ehci0: interrupting at ioapic0 pin 18
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2
usb3 at ehci0: USB revision 2.0
hdaudio1 at pci0 dev 27 function 0: HD Audio Controller
hdaudio1: interrupting at ioapic0 pin 22
hdafg1 at hdaudio1: ADI AD1989B
hdafg1: DAC00 8ch: Speaker [Jack]
hdafg1: ADC01 2ch: CD [Built-In], Line In [Jack], Mic In [Jack]
hdafg1: DAC02 2ch: HP Out [Jack]
hdafg1: DAC03 2ch: SPDIF Out [Jack]
hdafg1: DAC04 2ch: Digital Out [Jack]
hdafg1: 8ch/2ch 8000Hz 11025Hz 16000Hz 22050Hz 32000Hz 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz 16/16 20/32 24/32
audio1 at hdafg1: full duplex, playback, capture, independent
ppb1 at pci0 dev 28 function 0: vendor 0x8086 product 0x3a40 (rev. 0x00)
pci2 at ppb1 bus 4
pci2: memory space enabled, rd/line, wr/inv ok
ppb2 at pci0 dev 28 function 4: vendor 0x8086 product 0x3a48 (rev. 0x00)
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
ahcisata0 at pci3 dev 0 function 0: vendor 0x11ab product 0x6121
ahcisata0: interrupting at ioapic0 pin 16
ahcisata0: 64-bit DMA
ahcisata0: AHCI revision 1.0, 3 ports, 32 command slots, features 0xca226000
atabus0 at ahcisata0 channel 0
atabus1 at ahcisata0 channel 1
atabus2 at ahcisata0 channel 2
ppb3 at pci0 dev 28 function 5: vendor 0x8086 product 0x3a4a (rev. 0x00)
pci4 at ppb3 bus 2
pci4: i/o space, memory space enabled, rd/line, wr/inv ok
mskc0 at pci4 dev 0 function 0, Yukon-2 EC Ultra rev. B0 (0x3): ioapic0 pin 17
msk0 at mskc0 port A: Ethernet address 00:22:15:80:9f:02
makphy0 at msk0 phy 0: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
uhci3 at pci0 dev 29 function 0: vendor 0x8086 product 0x3a34 (rev. 0x00)
uhci3: interrupting at ioapic0 pin 23
usb4 at uhci3: USB revision 1.0
uhci4 at pci0 dev 29 function 1: vendor 0x8086 product 0x3a35 (rev. 0x00)
uhci4: interrupting at ioapic0 pin 19
usb5 at uhci4: USB revision 1.0
uhci5 at pci0 dev 29 function 2: vendor 0x8086 product 0x3a36 (rev. 0x00)
uhci5: interrupting at ioapic0 pin 18
usb6 at uhci5: USB revision 1.0
ehci1 at pci0 dev 29 function 7: vendor 0x8086 product 0x3a3a (rev. 0x00)
ehci1: interrupting at ioapic0 pin 23
ehci1: EHCI version 1.0
ehci1: companion controllers, 2 ports each: uhci3 uhci4 uhci5
usb7 at ehci1: USB revision 2.0
ppb4 at pci0 dev 30 function 0: vendor 0x8086 product 0x244e (rev. 0x90)
pci5 at ppb4 bus 5
pci5: i/o space, memory space enabled
clcs0 at pci5 dev 0 function 0: vendor 0x1013 product 0x6003 (rev. 0x01)
clcs0: interrupting at ioapic0 pin 16
clcs0: ac97: Crystal CS4294 codec; headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D
audio2 at clcs0: full duplex, playback, capture, independent
midi1 at clcs0: CS4280 MIDI UART
skc0 at pci5 dev 2 function 0: ioapic0 pin 18
skc0: interrupt moderation is 0 us
skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9)
sk0 at skc0 port A: Ethernet address 00:22:15:80:ac:e8
makphy1 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x3a16 (rev. 0x00)
piixide0 at pci0 dev 31 function 2: Intel 82801JI Serial ATA Controller (ICH10) (rev. 0x00)
piixide0: bus-master DMA support present
piixide0: primary channel configured to native-PCI mode
piixide0: using ioapic0 pin 19 for native-PCI interrupt
atabus3 at piixide0 channel 0
piixide0: secondary channel configured to native-PCI mode
atabus4 at piixide0 channel 1
ichsmb0 at pci0 dev 31 function 3: vendor 0x8086 product 0x3a30 (rev. 0x00)
ichsmb0: interrupting at ioapic0 pin 18
iic0 at ichsmb0: I2C bus
spdmem0 at iic0 addr 0x52
spdmem0: DDR2 SDRAM, no parity or ECC, 2GB, 800MHz (PC2-6400)
spdmem0: 14 rows, 10 cols, 2 ranks, 8 banks/chip, 2.50ns cycle time
spdmem0: tAA-tRCD-tRP-tRAS: 5-5-5-18
spdmem0: voltage SSTL 1.8V, refresh time 7.8us (self-refreshing)
piixide1 at pci0 dev 31 function 5: Intel 82801JI Serial ATA Controller (ICH10) (rev. 0x00)
piixide1: bus-master DMA support present
piixide1: primary channel wired to native-PCI mode
piixide1: using ioapic0 pin 19 for native-PCI interrupt
atabus5 at piixide1 channel 0
piixide1: secondary channel wired to native-PCI mode
atabus6 at piixide1 channel 1
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
uhub0 at usb0: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub1 at usb1: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub2 at usb2: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhub3 at usb3: vendor 0x8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
uhub4 at usb4: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub4: 2 ports with 2 removable, self powered
uhub5 at usb5: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub5: 2 ports with 2 removable, self powered
uhub6 at usb6: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub6: 2 ports with 2 removable, self powered
IPsec: Initialized Security Association Processing.
uhub7 at usb7: vendor 0x8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub7: 6 ports with 6 removable, self powered
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
wd0 at atabus3 drive 0: <ST3320620AS>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd1 at atabus3 drive 1: <WDC WD5000AAJS-00YFA0>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd1(piixide0:0:1): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd2 at atabus4 drive 1: <WDC WD1001FALS-00J7B0>
wd2: drive supports 16-sector PIO transfers, LBA48 addressing
wd2: 931 GB, 1938021 cyl, 16 head, 63 sec, 512 bytes/sect x 1953525168 sectors
wd2: 32-bit data port
wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd2(piixide0:1:1): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
Kernelized RAIDframe activated
pad0: outputs: 44100Hz, 16-bit, stereo
audio3 at pad0: half duplex, playback, capture
boot device: wd2
root on wd2e dumps on wd1b
root file system type: ffs
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Logitech USB Receiver, rev 2.00/5.00, addr 2, iclass 3/1
ums0 at uhidev0: 16 buttons, W and Z dirs
wsmouse0 at ums0 mux 0
uhidev1 at uhub0 port 1 configuration 1 interface 1
uhidev1: Logitech USB Receiver, rev 2.00/5.00, addr 2, iclass 3/0
uhidev1: 17 report ids
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid2 at uhidev1 reportid 17: input=19, output=19, feature=0
uhidev2 at uhub1 port 1 configuration 1 interface 0
uhidev2: Logitech Logitech Illuminated Keyboard, rev 2.00/55.00, addr 2, iclass 3/1
ukbd0 at uhidev2
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev3 at uhub1 port 1 configuration 1 interface 1
uhidev3: Logitech Logitech Illuminated Keyboard, rev 2.00/55.00, addr 2, iclass 3/0
uhidev3: 16 report ids
uhid3 at uhidev3 reportid 3: input=7, output=0, feature=0
uhid4 at uhidev3 reportid 16: input=6, output=6, feature=0
skc0: interrupt moderation is 1000 us
uhub4: device problem, disabling port 2
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
wsdisplay0: screen 5 added (80x25, vt100 emulation)
wsdisplay0: screen 6 added (80x25, vt100 emulation)
wsdisplay0: screen 7 added (80x25, vt100 emulation)
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV635 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
wd2: 931 GB, 1938021 cyl, 16 head, 63 sec, 512 bytes/sect x 1953525168 sectors
wd2: 32-bit data port
wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd2(piixide0:1:1): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
Kernelized RAIDframe activated
pad0: outputs: 44100Hz, 16-bit, stereo
audio3 at pad0: half duplex, playback, capture
boot device: wd2
root on wd2e dumps on wd1b
root file system type: ffs
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Logitech USB Receiver, rev 2.00/5.00, addr 2, iclass 3/1
ums0 at uhidev0: 16 buttons, W and Z dirs
wsmouse0 at ums0 mux 0
uhidev1 at uhub0 port 1 configuration 1 interface 1
uhidev1: Logitech USB Receiver, rev 2.00/5.00, addr 2, iclass 3/0
uhidev1: 17 report ids
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid2 at uhidev1 reportid 17: input=19, output=19, feature=0
uhidev2 at uhub1 port 1 configuration 1 interface 0
uhidev2: Logitech Logitech Illuminated Keyboard, rev 2.00/55.00, addr 2, iclass 3/1
ukbd0 at uhidev2
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev3 at uhub1 port 1 configuration 1 interface 1
uhidev3: Logitech Logitech Illuminated Keyboard, rev 2.00/55.00, addr 2, iclass 3/0
uhidev3: 16 report ids
uhid3 at uhidev3 reportid 3: input=7, output=0, feature=0
uhid4 at uhidev3 reportid 16: input=6, output=6, feature=0
skc0: interrupt moderation is 1000 us
uhub4: device problem, disabling port 2
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
wsdisplay0: screen 5 added (80x25, vt100 emulation)
wsdisplay0: screen 6 added (80x25, vt100 emulation)
wsdisplay0: screen 7 added (80x25, vt100 emulation)
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV635 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
radeondrm0: interrupting at ioapic0 pin 16


>How-To-Repeat:

>Fix:


>Audit-Trail:
From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Mon, 10 Jan 2011 12:52:55 +0100

 On Mon, Jan 10, 2011 at 11:50:00AM +0000, mihai.chelaru@ngnetworks.ro wrote:
 > poweroff doesn't work in -current on some computers. Affected computers
 > include:

 I'm seeing this as well, dmesg available on request.
  Thomas

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Mon, 10 Jan 2011 19:20:55 +0200

 On Mon, Jan 10, 2011 at 11:50:00AM +0000, mihai.chelaru@ngnetworks.ro wrote:
 > poweroff doesn't work in -current on some computers. Affected computers
 > include:
 > 
 > 	* Dell Mini 10 (i386) - the screen turns off but fans
 > 	are still working and power led is still on.
 > 	* custom made (amd64) Asus mainboard - see dmesg below -
 > 	in most cases it shuts down the HDDs and it even turns
 > 	off the front panel LEDs (including powerled), but power
 > 	is not cut, fans are still spinning, the video card is still
 > 	working so I can read the "acpi: entering state 5" message.
 > 	This is the strangest one, because twice or thrice it
 > 	completed the shutdown.

 Might be a longshot, but can you try the following tiny patch?

 - Jukka.

 Index: acpi.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/acpi/acpi.c,v
 retrieving revision 1.229
 diff -u -p -r1.229 acpi.c
 --- acpi.c	6 Jan 2011 07:05:00 -0000	1.229
 +++ acpi.c	10 Jan 2011 17:16:53 -0000
 @@ -1376,6 +1376,8 @@ acpi_enter_sleep_state(int state)
  			break;
  		}

 +		(void)AcpiDisableAllGpes();
 +
  		DELAY(1000000);

  		sc->sc_sleepstate = state;

From: Mihai Chelaru <mihai.chelaru@NGNetworks.ro>
To: gnats-bugs@NetBSD.org
Cc: Jukka Ruohonen <jruohonen@iki.fi>, kern-bug-people@netbsd.org, 
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/44366: poweroff doesn't work
Date: Mon, 10 Jan 2011 22:07:18 +0200

 On 01/10/11 19:25, Jukka Ruohonen wrote:
 >  Might be a longshot, but can you try the following tiny patch?
 >  
 >  - Jukka.
 >  
 >  Index: acpi.c
 >  ===================================================================
 >  RCS file: /cvsroot/src/sys/dev/acpi/acpi.c,v
 >  retrieving revision 1.229
 >  diff -u -p -r1.229 acpi.c
 >  --- acpi.c	6 Jan 2011 07:05:00 -0000	1.229
 >  +++ acpi.c	10 Jan 2011 17:16:53 -0000
 >  @@ -1376,6 +1376,8 @@ acpi_enter_sleep_state(int state)
 >   			break;
 >   		}
 >   
 >  +		(void)AcpiDisableAllGpes();
 >  +
 >   		DELAY(1000000);
 >   
 >   		sc->sc_sleepstate = state;
 >  

 Tested on both reported machines, but there is no change, sorry.

 -- 
 Mihai

From: Mark Davies <mark@ecs.vuw.ac.nz>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Tue, 11 Jan 2011 09:51:34 +1300

 On Tuesday 11 January 2011 00:50:00 you wrote:
 > 	* custom made (amd64) Asus mainboard - see dmesg below -
 > 	in most cases it shuts down the HDDs and it even turns
 > 	off the front panel LEDs (including powerled), but power
 > 	is not cut, fans are still spinning, the video card is still
 > 	working so I can read the "acpi: entering state 5" message.
 > 	This is the strangest one, because twice or thrice it
 > 	completed the shutdown.

 I get this as well on Dell Optiplex 745's, 755's and 760's but not 
 Latitiude E6400's (all 2 cpu machines).  The optipex's complete the 
 shutdown approx 50% of the time.

 cheers
 mark

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Mon, 10 Jan 2011 21:16:51 +0000

 On Mon, Jan 10, 2011 at 08:55:02PM +0000, Mark Davies wrote:
 >  
 >  I get this as well on Dell Optiplex 745's, 755's and 760's but not 
 >  Latitiude E6400's (all 2 cpu machines).  The optipex's complete the 
 >  shutdown approx 50% of the time.

 Do we still have the problem of trying to run the ACPI power off
 on the non-boot cpu?

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Tue, 11 Jan 2011 20:27:56 +0200

 On Mon, Jan 10, 2011 at 09:15:04PM +0000, David Laight wrote:
 >  Do we still have the problem of trying to run the ACPI power off
 >  on the non-boot cpu?

 Can any of you with the problem try revision 1.79 of sys/arch/x86/x86/cpu.c?

 - Jukka.

From: Mihai Chelaru <mihai.chelaru@ngnetworks.ro>
To: gnats-bugs@NetBSD.org
Cc: Jukka Ruohonen <jruohonen@iki.fi>, kern-bug-people@netbsd.org, 
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/44366: poweroff doesn't work
Date: Tue, 11 Jan 2011 21:49:00 +0200

 On 01/11/11 20:30, Jukka Ruohonen wrote:
 >  
 >  Can any of you with the problem try revision 1.79 of sys/arch/x86/x86/cpu.c?
 >  
 >  - Jukka.
 >  
 Same behaviour.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: mihai.chelaru@ngnetworks.ro
Subject: Re: kern/44366: poweroff doesn't work
Date: Tue, 11 Jan 2011 22:30:37 +0200

 On Tue, Jan 11, 2011 at 07:50:05PM +0000, Mihai Chelaru wrote:
 >  Same behaviour.

 Okay, can you please try the next attached patch?

 (The acpi_enter_sleep_state() function must be called with interrupts enabled.)

 - Jukka.

 Index: sys/arch/i386/i386/machdep.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/i386/i386/machdep.c,v
 retrieving revision 1.698
 diff -u -p -r1.698 machdep.c
 --- sys/arch/i386/i386/machdep.c	12 Nov 2010 13:18:57 -0000	1.698
 +++ sys/arch/i386/i386/machdep.c	11 Jan 2011 20:27:41 -0000
 @@ -864,6 +864,7 @@ cpu_reboot(int howto, char *bootstr)
  {
  	static bool syncdone = false;
  	struct lwp *l;
 +	int s;

  	l = (curlwp == NULL) ? &lwp0 : curlwp;

 @@ -908,7 +909,7 @@ cpu_reboot(int howto, char *bootstr)

  	pmf_system_shutdown(boothowto);

 -	splhigh();
 +	s = splhigh();
  haltsys:

  	if ((howto & RB_POWERDOWN) == RB_POWERDOWN) {
 @@ -923,6 +924,7 @@ haltsys:
  		}
  #endif
  #if NACPICA > 0
 +		splx(s);
  		acpi_enter_sleep_state(ACPI_STATE_S5);
  #endif
  #if NAPMBIOS > 0 && !defined(APM_NO_POWEROFF)
 Index: sys/arch/amd64/amd64/machdep.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/amd64/amd64/machdep.c,v
 retrieving revision 1.157
 diff -u -p -r1.157 machdep.c
 --- sys/arch/amd64/amd64/machdep.c	15 Nov 2010 06:12:28 -0000	1.157
 +++ sys/arch/amd64/amd64/machdep.c	11 Jan 2011 20:27:41 -0000
 @@ -669,6 +669,7 @@ struct pcb dumppcb;
  void
  cpu_reboot(int howto, char *bootstr)
  {
 +	int s;

  	if (cold) {
  		howto |= RB_HALT;
 @@ -687,7 +688,7 @@ cpu_reboot(int howto, char *bootstr)
  	}

  	/* Disable interrupts. */
 -	splhigh();
 +	s = splhigh();

  	/* Do a dump if requested. */
  	if ((howto & (RB_DUMP | RB_HALT)) == RB_DUMP)
 @@ -701,6 +702,7 @@ haltsys:
          if ((howto & RB_POWERDOWN) == RB_POWERDOWN) {
  #ifndef XEN
  #if NACPICA > 0
 +		splx(s);
  		acpi_enter_sleep_state(ACPI_STATE_S5);
  #endif
  #else /* XEN */

From: Mihai Chelaru <mihai.chelaru@ngnetworks.ro>
To: gnats-bugs@NetBSD.org
Cc: Jukka Ruohonen <jruohonen@iki.fi>, kern-bug-people@netbsd.org, 
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/44366: poweroff doesn't work
Date: Tue, 11 Jan 2011 22:52:05 +0200

 On 01/11/11 22:35, Jukka Ruohonen wrote:
 >  
 >  Okay, can you please try the next attached patch?
 >  
 >  (The acpi_enter_sleep_state() function must be called with interrupts enabled.)
 >  
 >  - Jukka.

 It still doesn't work.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: mihai.chelaru@ngnetworks.ro
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 10:35:12 +0200

 On Tue, Jan 11, 2011 at 08:55:02PM +0000, Mihai Chelaru wrote:
 >  It still doesn't work.

 Can you try yet another patch?

 This may again be a long-shot, but I am running out of ideas...

 - Jukka.

 Index: acpi.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/acpi/acpi.c,v
 retrieving revision 1.233
 diff -u -p -r1.233 acpi.c
 --- acpi.c	13 Jan 2011 05:58:05 -0000	1.233
 +++ acpi.c	13 Jan 2011 08:31:51 -0000
 @@ -123,6 +123,8 @@ __KERNEL_RCSID(0, "$NetBSD: acpi.c,v 1.2
  #include <dev/acpi/acpi_timer.h>
  #include <dev/acpi/acpi_wakedev.h>

 +#include <dev/ic/i8042reg.h>	/* XXX: DEBUG. */
 +
  #define _COMPONENT	ACPI_BUS_COMPONENT
  ACPI_MODULE_NAME	("acpi")

 @@ -1388,6 +1390,7 @@ acpi_enter_sleep_state(int state)

  		sc->sc_sleepstate = state;
  		acpi_md_OsDisableInterrupt();
 +		lapic_disable();

  		(void)AcpiEnterSleepState(ACPI_STATE_S5);

 Index: lapic.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/x86/x86/lapic.c,v
 retrieving revision 1.44
 diff -u -p -r1.44 lapic.c
 --- lapic.c	21 Nov 2009 03:11:01 -0000	1.44
 +++ lapic.c	13 Jan 2011 08:32:06 -0000
 @@ -77,6 +77,8 @@ static void lapic_hwmask(struct pic *, i
  static void lapic_hwunmask(struct pic *, int);
  static void lapic_setup(struct pic *, struct cpu_info *, int, int, int);

 +static bool lapic_msr = false;
 +
  struct pic local_pic = {
  	.pic_name = "lapic",
  	.pic_type = PIC_LAPIC,
 @@ -108,6 +110,7 @@ lapic_map(paddr_t lapic_base)
  		}
  		wrmsr(LAPIC_MSR, lapic_base | LAPIC_MSR_ENABLE);
  		lapic_base &= LAPIC_MSR_ADDR;
 +		lapic_msr = true;
  	}

  	x86_disable_intr();
 @@ -134,9 +137,6 @@ lapic_map(paddr_t lapic_base)
  	x86_enable_intr();
  }

 -/*
 - * enable local apic
 - */
  void
  lapic_enable(void)
  {
 @@ -144,8 +144,33 @@ lapic_enable(void)
  }

  void
 +lapic_disable(void)
 +{
 +	uint64_t msr;
 +	uint32_t val;
 +
 +	val = i82489_readreg(LAPIC_SVR);
 +
 +	if ((val & LAPIC_SVR_ENABLE) != 0) {
 +		val &= ~LAPIC_SVR_ENABLE;
 +		i82489_writereg(LAPIC_SVR, val);
 +	}
 +
 +	if (lapic_msr != true)
 +		return;
 +
 +	msr = rdmsr(LAPIC_MSR);
 +
 +	if ((msr & LAPIC_MSR_ENABLE) != 0) {
 +		msr &= ~LAPIC_MSR_ENABLE;
 +		wrmsr(LAPIC_MSR, msr);
 +	}
 +}
 +
 +void
  lapic_suspend(void)
  {
 +	/* XXX. */
  }

  void
 Index: i82489var.h
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/x86/include/i82489var.h,v
 retrieving revision 1.12
 diff -u -p -r1.12 i82489var.h
 --- i82489var.h	28 Apr 2008 20:23:40 -0000	1.12
 +++ i82489var.h	13 Jan 2011 08:32:28 -0000
 @@ -112,6 +112,7 @@ struct cpu_info;
  extern void lapic_boot_init(paddr_t);
  extern void lapic_set_lvt(void);
  extern void lapic_enable(void);
 +extern void lapic_disable(void);
  extern void lapic_suspend(void);
  extern void lapic_resume(void);
  extern void lapic_calibrate_timer(struct cpu_info *ci);

From: Mihai Chelaru <mihai.chelaru@ngnetworks.ro>
To: gnats-bugs@NetBSD.org
Cc: Jukka Ruohonen <jruohonen@iki.fi>, kern-bug-people@netbsd.org, 
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 15:06:38 +0200

 On 01/13/11 10:40, Jukka Ruohonen wrote:
 >  Can you try yet another patch?
 >  
 >  This may again be a long-shot, but I am running out of ideas...
 >  
 >  - Jukka.
 >  

 It still doesn't work, sorry. Moreover, I just tested 5.0/i386
 and 5.1 GENERIC kernels and both completes power off.

 -- 
 Mihai

From: Mihai Chelaru <mihai.chelaru@ngnetworks.ro>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 15:11:12 +0200

 On 01/13/11 15:10, Mihai Chelaru wrote:
 >  It still doesn't work, sorry. Moreover, I just tested 5.0/i386
 >  and 5.1 GENERIC kernels and both completes power off.

 Just a clarification: I tested this on Dell Mini 9 (910).

 -- 
 Mihai

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: mihai.chelaru@ngnetworks.ro
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 15:30:59 +0200

 On Thu, Jan 13, 2011 at 01:10:07PM +0000, Mihai Chelaru wrote:
 >  It still doesn't work, sorry. Moreover, I just tested 5.0/i386
 >  and 5.1 GENERIC kernels and both completes power off.

 Nothing in the acpi(4) stack has really changed in this area. (Although 
 ACPICA has been updated three times.) I think this is something in the
 changes done to i386/amd64 'machdep.c' and cpu_reboot() therein. The
 versions in 5.X and HEAD look quite different.

 - Jukka.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: mihai.chelaru@ngnetworks.ro
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 17:20:51 +0200

 On Thu, Jan 13, 2011 at 01:10:07PM +0000, Mihai Chelaru wrote:
 >  It still doesn't work, sorry. Moreover, I just tested 5.0/i386
 >  and 5.1 GENERIC kernels and both completes power off.

 Thanks to Jared D. McNeill, the bug was located. This regression was caused
 by adding detach-routines to acpi(4) followed by the commit to i386/amd64
 machdep.c:

 revision 1.669
 date: 2009/06/26 23:40:27;  author: dyoung;  state: Exp;  lines: +52 -27
 During a normal shutdown, gracefully tear down arbitrary stacks of
 filesystems and (pseudo-)devices, according to the algorithm at A3
 and A4, below.

 Proposed and discussed at
 <http://mail-index.netbsd.org/tech-kern/2009/04/20/msg004864.html>.  No
 objections.

 ...

 In particular, cpu_reboot() now runs config_detach_all(), while acpi(4) can
 not obviously be detached as it is responsible for the hardware powerdown. 
 It was also disucssed that removing the dopowerhooks() could be unsafe (even
 on x86).

 At the moment it is unclear how this should be resolved.

 - Jukka.

From: David Young <dyoung@pobox.com>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, mihai.chelaru@ngnetworks.ro
Subject: Re: kern/44366: poweroff doesn't work
Date: Thu, 13 Jan 2011 12:07:18 -0600

 On Thu, Jan 13, 2011 at 03:25:04PM +0000, Jukka Ruohonen wrote:
 > The following reply was made to PR kern/44366; it has been noted by GNATS.
 > 
 > From: Jukka Ruohonen <jruohonen@iki.fi>
 > To: gnats-bugs@NetBSD.org
 > Cc: mihai.chelaru@ngnetworks.ro
 > Subject: Re: kern/44366: poweroff doesn't work
 > Date: Thu, 13 Jan 2011 17:20:51 +0200
 > 
 >  On Thu, Jan 13, 2011 at 01:10:07PM +0000, Mihai Chelaru wrote:
 >  >  It still doesn't work, sorry. Moreover, I just tested 5.0/i386
 >  >  and 5.1 GENERIC kernels and both completes power off.
 >  
 >  Thanks to Jared D. McNeill, the bug was located. This regression was caused
 >  by adding detach-routines to acpi(4) followed by the commit to i386/amd64
 >  machdep.c:
 >  
 >  revision 1.669
 >  date: 2009/06/26 23:40:27;  author: dyoung;  state: Exp;  lines: +52 -27
 >  During a normal shutdown, gracefully tear down arbitrary stacks of
 >  filesystems and (pseudo-)devices, according to the algorithm at A3
 >  and A4, below.
 >  
 >  Proposed and discussed at
 >  <http://mail-index.netbsd.org/tech-kern/2009/04/20/msg004864.html>.  No
 >  objections.
 >  
 >  ...
 >  
 >  In particular, cpu_reboot() now runs config_detach_all(), while acpi(4) can
 >  not obviously be detached as it is responsible for the hardware powerdown. 
 >  It was also disucssed that removing the dopowerhooks() could be unsafe (even
 >  on x86).
 >  
 >  At the moment it is unclear how this should be resolved.

 Two corrections to the above:

 acpi(4) is not flagged as detachable at shutdown, so I don't think that
 the kernel actually detaches it.  The kernel should print a message for
 each device that it detaches during shutdown.

 I think that you meant shutdownhooks, not powerhooks.  You should
 be able to rule that out quickly, because few drivers establish
 shutdownhooks any longer:

 find sys/dev/ sys/arch/{i386,amd64,x86} -type f | xargs grep -l shutdownhook_est
 sys/dev/bi/if_ni.c
 sys/dev/eisa/if_fea.c
 sys/dev/i2o/iop.c
 sys/dev/ic/aac.c
 sys/dev/ic/awi.c
 sys/dev/ic/cac.c
 sys/dev/ic/ciss.c
 sys/dev/ic/dpt.c
 sys/dev/ic/mlx.c
 sys/dev/ic/mtd803.c
 sys/dev/ic/tropic.c
 sys/dev/isa/if_lc_isa.c
 sys/dev/isa/if_ntwoc_isa.c
 sys/dev/marvell/gtmpsc.c
 sys/dev/mvme/clock_pcctwo.c
 sys/dev/pci/amr.c
 sys/dev/pci/if_de.c
 sys/dev/pci/if_fpa.c
 sys/dev/pci/if_lmc.c
 sys/dev/pci/if_ntwoc_pci.c
 sys/dev/pci/mly.c
 sys/dev/pci/twa.c
 sys/dev/qbus/if_de.c
 sys/dev/sysmon/sysmon_wdog.c
 sys/dev/tc/if_fta.c
 sys/arch/i386/tags
 sys/arch/amd64/tags

 If an incomplete or broken detachment routine causes the trouble, you
 can narrow in on the problem driver by removing DVF_DETACH_SHUTDOWN
 flags from CFATTACH_DECL3_NEW() calls affecting drivers for your
 hardware, and adding them back again one by one.

 Dave

 -- 
 David Young             OJC Technologies
 dyoung@ojctech.com      Urbana, IL * (217) 278-3933

From: Mark Davies <mark@ecs.vuw.ac.nz>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Fri, 14 Jan 2011 15:57:23 +1300

 On Fri, 14 Jan 2011, David Young wrote:

 >  >  On Thu, Jan 13, 2011 at 01:10:07PM +0000, Mihai Chelaru wrote:
 >  >  >  It still doesn't work, sorry. Moreover, I just tested
 >  >  > 5.0/i386 and 5.1 GENERIC kernels and both completes power
 >  >  > off.

 Note that for me the problem exists with 5.1 (and earlier 5.x) as well 
 as current.

 >  I think that you meant shutdownhooks, not powerhooks.  You should
 >  be able to rule that out quickly, because few drivers establish
 >  shutdownhooks any longer:

   [...]

 >  If an incomplete or broken detachment routine causes the trouble,
 > you can narrow in on the problem driver by removing
 > DVF_DETACH_SHUTDOWN flags from CFATTACH_DECL3_NEW() calls affecting
 > drivers for your hardware, and adding them back again one by one.

 If it helps to try and track down a particular driver that might be 
 causing the problem I've put dmesg outputs for optiplex760 and 755 
 (that have the problem) and latitude e6400 (that doesn't) at
 http://homepages.ecs.vuw.ac.nz/~mark/dmesg.
 {optiplex760,optiplex755,latitudee6400}

 cheers
 mark

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44366: poweroff doesn't work
Date: Fri, 14 Jan 2011 16:21:47 +0200

 On Thu, Jan 13, 2011 at 06:10:05PM +0000, David Young wrote:
 >  acpi(4) is not flagged as detachable at shutdown, so I don't think that
 >  the kernel actually detaches it.  The kernel should print a message for
 >  each device that it detaches during shutdown.

 The analysis is however correct about the basic premise: the newly
 added call to config_detach_all() in cpu_reboot() causes the regression.

 (For the archives.)

 - Jukka.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.