kacpi_notify?

kacpi_notify?

[Linus Torvalds]

Hmm.

What's up with this?

 2341 ?        D<     0:00 [kacpid_notify]
 2342 ?        D<     0:00 [kacpid_notify]
 2343 ?        D<     0:00 [kacpid_notify]
 2344 ?        D<     0:00 [kacpid_notify]
 2345 ?        D<     0:00 [kacpid_notify]
 2346 ?        D<     0:00 [kacpid_notify]
 2347 ?        D<     0:00 [kacpid_notify]
 ...

(apparently about 300 of those processes, at which point the machine just 
hangs, because even root cannot start any new processes, and I couldn't 
actually get to debug this at all).

What would it be waiting on, and why?

This machine doesn't have any module support (at all), and I haven't 
booted a new kernel on it in quite a while, so this isn't necessarily new 
behaviour, but the last kernel I tried (which did _not_ have this problem, 
obviously) was in April (commit 6e5882cfa24e1456702e463f6920fc0ca3c3d2b8, 
to be exact).

Now, that's 6000+ commits ago, so I'd rather not even bisect this, if 
somebody can come up with a more obvious explanation of why kacpid_notify 
would be started over and over and over again, only to always get stuck..

		Linus

Re: kacpi_notify?

[Linus Torvalds]

On Wed, 12 Jul 2006, Linus Torvalds wrote:
> 
> (apparently about 300 of those processes, at which point the machine just 
> hangs, because even root cannot start any new processes, and I couldn't 
> actually get to debug this at all).

With ACPI debugging, I notice that it finally dies due to ACPI Error 
AE_NO_MEMORY. Which I guess is just due to thousands of kacpi_notify 
processes, and tons of allocations.

With ctrl+scrolllock, I finally got something. The traceback for the 
D-state (millions and millions of them) is

	__down_failed
	acpi_ut_acquire_mutex
	acpi_ex_enter_interpreter
	acpi_ns_evaluate
	acpi_evaluate_object
	acpi_evaluate_integer
	acpi_os_execute_thread
	acpi_thermal_get_temperature
	acpi_thermal_check
	..

and 'kacpid' seems to be stuck using all CPU time, with the thing doing 
something like:

	EIP is at delay_tsc+0xb/0x13
	 EFLAGS: 00000283    Not tainted  (2.6.18-rc1-g155dbfd8 #24)
	EAX: 4aa48900 EBX: 00026be1 ECX: 4aa40b7e EDX: 0000001a
	ESI: 00000000 EDI: c039300d EBP: c0390df3 DS: 007b ES: 007b
	CR0: 8005003b CR2: 080516f0 CR3: 362dc000 CR4: 000006d0
	 [<c01c94c0>] __delay+0x6/0x7
	 [<c01f23ef>] acpi_os_stall+0x1d/0x29
	 [<c0201f11>] acpi_ex_system_do_stall+0x37/0x3b
	 [<c0200fca>] acpi_ex_opcode_1A_0T_0R+0x85/0xc8
	 [<c01f5308>] acpi_ds_exec_end_op+0x133/0x553
	 [<c020d0f3>] acpi_ps_parse_loop+0x777/0xbe0
	 [<c020c488>] acpi_ps_parse_aml+0xd8/0x2d5
	 [<c020dbbe>] acpi_ps_execute_pass+0xa9/0xd2
	 [<c020dd6a>] acpi_ps_execute_method+0x153/0x231
	 [<c02095e1>] acpi_ns_evaluate+0x179/0x24c
	 [<c01fc12e>] acpi_ev_asynch_execute_gpe_method+0xeb/0x159
	 [<c01f2083>] acpi_os_execute_deferred+0x19/0x21
	 [<c01226a0>] run_workqueue+0x68/0x95
	 [<c01f206a>] acpi_os_execute_deferred+0x0/0x21
	 [<c0122b2e>] worker_thread+0xf9/0x12b
	 [<c03570bf>] schedule+0x469/0x4cc
	 [<c0113bfb>] default_wake_function+0x0/0xc
	 [<c0122a35>] worker_thread+0x0/0x12b
	 [<c01249bb>] kthread+0xad/0xd8
	 [<c012490e>] kthread+0x0/0xd8
	 [<c0101005>] kernel_thread_helper+0x5/0xb

which I assume is the thing that holds the AML semaphore, and isn't 
releasing it.

Is there any sane debugging info I can send people?

		Linus

RE: kacpi_notify?

[Brown, Len]

 
>With ctrl+scrolllock, I finally got something. The traceback for the 
>D-state (millions and millions of them) is
>
>	__down_failed
>	acpi_ut_acquire_mutex
>	acpi_ex_enter_interpreter
>	acpi_ns_evaluate
>	acpi_evaluate_object
>	acpi_evaluate_integer
>	acpi_os_execute_thread
>	acpi_thermal_get_temperature
>	acpi_thermal_check
>	..
>
>and 'kacpid' seems to be stuck using all CPU time, with the 
>thing doing 
>something like:
>
>	EIP is at delay_tsc+0xb/0x13
>	 EFLAGS: 00000283    Not tainted  (2.6.18-rc1-g155dbfd8 #24)
>	EAX: 4aa48900 EBX: 00026be1 ECX: 4aa40b7e EDX: 0000001a
>	ESI: 00000000 EDI: c039300d EBP: c0390df3 DS: 007b ES: 007b
>	CR0: 8005003b CR2: 080516f0 CR3: 362dc000 CR4: 000006d0
>	 [<c01c94c0>] __delay+0x6/0x7
>	 [<c01f23ef>] acpi_os_stall+0x1d/0x29
>	 [<c0201f11>] acpi_ex_system_do_stall+0x37/0x3b
>	 [<c0200fca>] acpi_ex_opcode_1A_0T_0R+0x85/0xc8
>	 [<c01f5308>] acpi_ds_exec_end_op+0x133/0x553
>	 [<c020d0f3>] acpi_ps_parse_loop+0x777/0xbe0
>	 [<c020c488>] acpi_ps_parse_aml+0xd8/0x2d5
>	 [<c020dbbe>] acpi_ps_execute_pass+0xa9/0xd2
>	 [<c020dd6a>] acpi_ps_execute_method+0x153/0x231
>	 [<c02095e1>] acpi_ns_evaluate+0x179/0x24c
>	 [<c01fc12e>] acpi_ev_asynch_execute_gpe_method+0xeb/0x159
>	 [<c01f2083>] acpi_os_execute_deferred+0x19/0x21
>	 [<c01226a0>] run_workqueue+0x68/0x95
>	 [<c01f206a>] acpi_os_execute_deferred+0x0/0x21
>	 [<c0122b2e>] worker_thread+0xf9/0x12b
>	 [<c03570bf>] schedule+0x469/0x4cc
>	 [<c0113bfb>] default_wake_function+0x0/0xc
>	 [<c0122a35>] worker_thread+0x0/0x12b
>	 [<c01249bb>] kthread+0xad/0xd8
>	 [<c012490e>] kthread+0x0/0xd8
>	 [<c0101005>] kernel_thread_helper+0x5/0xb
>
>which I assume is the thing that holds the AML semaphore, and isn't 
>releasing it.
>
>Is there any sane debugging info I can send people?

I think you just did:-)

The os_stall part is due to interpreting AML.  If you can get the
output from acpidump, that would help us see what it is doing.
I ask most people to attach it to a new bugzilla entry,
but I don't know that you have an account:-)

Anyway, if you don't have it already, acpidump is in the latest pmtools
here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

dmesg with CONFIG_ACPI_DEBUG might be interesting too.

thanks,
-Len

RE: kacpi_notify?

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 318 bytes --]



On Wed, 12 Jul 2006, Linus Torvalds wrote:
> 
> I saw nothing even remotely interesting there when I had ACPI_DEBUG on, 
> but if you really want it, I can send it..

Attached. There's no verbose debugging on (just CONFIG_ACPI_DEBUG=y), if 
you want me to enable more messages, tell me what/how you want it.

		Linus

[-- Attachment #2: Type: TEXT/PLAIN, Size: 17038 bytes --]

Linux version 2.6.18-rc1-g155dbfd8 (torvalds@evo.osdl.org) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #24 Wed Jul 12 13:07:29 PDT 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffd0000 (usable)
 BIOS-e820: 000000003ffd0000 - 000000003fff0c00 (reserved)
 BIOS-e820: 000000003fff0c00 - 000000003fffc000 (ACPI NVS)
 BIOS-e820: 000000003fffc000 - 0000000040000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
DMI 2.3 present.
ACPI: PM-Timer IO Port: 0x1008
Allocating PCI resources starting at 50000000 (gap: 40000000:c0000000)
Detected 1598.707 MHz processor.
Built 1 zonelists.  Total pages: 262096
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Local APIC disabled by BIOS -- you can enable it with "lapic"
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1033100k/1048384k available (2404k kernel code, 14516k reserved, 894k data, 188k init, 130880k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3199.33 BogoMIPS (lpj=6398667)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 1024K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) M processor 1600MHz stepping 05
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
 tbxface-0107 [01] load_tables           : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0006) - 843 Objects with 76 Devices 283 Methods 26 Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 9 Objects with 0 Devices 4 Methods 0 Regions
ACPI Namespace successfully loaded at root c04aadf0
ACPI: setting ELCR to 0200 (from 0c00)
evxfevnt-0089 [02] enable                : Transition to ACPI mode successful
checking if image is initramfs... it is
Freeing initrd memory: 1643k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf031f, last bus=4
Setting up standard PCI resources
evgpeblk-0951 [04] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 8 Wake, Enabled 5 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:...........................................................................................................
Initialized 25/26 Regions 0/0 Fields 27/27 Buffers 55/64 Packages (861 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:........
Executed 8 _INI methods requiring 2 _STA executions (examined 82 objects)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [C046] (0000:00)
ACPI: Assume root bridge [\_SB_.C046] bus is 0
PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 1100-113f claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Bus #04 (-#07) is hidden behind transparent bridge #02 (-#04) (try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: Power Resource [C174] (on)
ACPI: Power Resource [C18B] (on)
ACPI: Power Resource [C192] (on)
ACPI: Power Resource [C19C] (on)
ACPI: PCI Interrupt Link [C0C3] (IRQs *10 11)
ACPI: PCI Interrupt Link [C0C4] (IRQs 10 *11)
ACPI: PCI Interrupt Link [C0C5] (IRQs *10 11)
ACPI: PCI Interrupt Link [C0C6] (IRQs *10 11)
ACPI: PCI Interrupt Link [C0C7] (IRQs 10 *11)
ACPI: PCI Interrupt Link [C0C8] (IRQs 10 11) *0, disabled.
ACPI: PCI Interrupt Link [C0C9] (IRQs *10 11)
ACPI: PCI Interrupt Link [C0CA] (IRQs *10 11)
ACPI: Power Resource [C209] (off)
ACPI: Power Resource [C20A] (off)
ACPI: Power Resource [C20B] (off)
ACPI: Power Resource [C20C] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 14 devices
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:0c: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:0c: ioport range 0x1000-0x107f could not be reserved
pnp: 00:0c: ioport range 0x1100-0x113f has been reserved
pnp: 00:0c: ioport range 0x1200-0x121f has been reserved
PCI: Bridge: 0000:00:01.0
  IO window: 2000-2fff
  MEM window: 90200000-902fffff
  PREFETCH window: 98000000-9fffffff
PCI: Bus 3, cardbus bridge: 0000:02:06.0
  IO window: 00004000-000040ff
  IO window: 00004400-000044ff
  PREFETCH window: 50000000-51ffffff
  MEM window: 56000000-57ffffff
PCI: Bus 4, cardbus bridge: 0000:02:06.1
  IO window: 00004800-000048ff
  IO window: 00004c00-00004cff
  PREFETCH window: 52000000-53ffffff
  MEM window: 58000000-59ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 4000-4fff
  MEM window: 90000000-901fffff
  PREFETCH window: 50000000-54ffffff
ACPI: PCI Interrupt Link [C0C9] enabled at IRQ 10
ACPI: PCI Interrupt 0000:02:06.0[A] -> Link [C0C9] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI Interrupt 0000:02:06.1[A] -> Link [C0C9] -> GSI 10 (level, low) -> IRQ 10
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1152735214.704:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
SELinux:  Registering netfilter hooks
Jul 12 13:14:03 evo rpc.statd[1612]: Version 1.0.8-rc2 Starting
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: PCI Interrupt Link [C0C3] enabled at IRQ 10
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=260.00 Mhz, System=183.00 MHz
radeonfb: PLL min 20000 max 35000
radeonfb: Monitor 1 type LCD found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: panel ID string: HTC                     
radeonfb: detected LVDS panel size from BIOS: 1400x1050
radeondb: BIOS provided dividers will be used
radeonfb: Dynamic Clock Power Management enabled
Console: switching to colour frame buffer device 175x65
radeonfb (0000:01:00.0): ATI Radeon LW 
ACPI: AC Adapter [C1B5] (on-line)
ACPI: Battery Slot [C1B3] (battery present)
ACPI: Battery Slot [C1B4] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1B6]
ACPI: Lid Switch [C1B7]
ACPI: Transitioning device [C20D] to D3
ACPI: Transitioning device [C20D] to D3
ACPI: Fan [C20D] (off)
ACPI: Transitioning device [C20E] to D3
ACPI: Transitioning device [C20E] to D3
ACPI: Fan [C20E] (off)
ACPI: Transitioning device [C20F] to D3
ACPI: Transitioning device [C20F] to D3
ACPI: Fan [C20F] (off)
ACPI: Transitioning device [C210] to D3
ACPI: Transitioning device [C210] to D3
ACPI: Fan [C210] (off)
ACPI: Video Device [C0D1] (multi-head: yes  rom: no  post: no)
Using specific hotkey driver
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [TZ1] (51 C)
ACPI: Thermal Zone [TZ2] (48 C)
ACPI: Thermal Zone [TZ3] (45 C)
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855PM Chipset.
agpgart: AGP aperture is 256M @ 0xb0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A
00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt Link [C0C4] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [C0C4] -> GSI 11 (level, low) -> IRQ 11
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
tg3.c:v3.62 (June 30, 2006)
ACPI: PCI Interrupt Link [C0C7] enabled at IRQ 11
ACPI: PCI Interrupt 0000:02:0e.0[A] -> Link [C0C7] -> GSI 11 (level, low) -> IRQ 11
eth0: Tigon3 [partno(BCM5705mA1) rev 3001 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:08:02:d5:e2:6f
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
eth0: dma_rwctrl[763f0000] dma_mask[64-bit]
Loaded prism54 driver, version 1.2
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [C0C5] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10
ICH4: chipset revision 3
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x3c20-0x3c27, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x3c28-0x3c2f, BIOS settings: hdc:pio, hdd:pio
hda: HTS726060M9AT00, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 512KiB
hda: 117210240 sectors (60011 MB) w/7877KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2
ide-floppy driver 0.99.newide
Yenta: CardBus bridge found at 0000:02:06.0 [0e11:0058]
Yenta O2: res at 0x94/0xD4: ea/00
Yenta O2: enabling read prefetch/write burst
Yenta: ISA IRQ mask 0x00b8, PCI irq 10
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x4000 - 0x4fff
pcmcia: parent PCI bridge Memory window: 0x90000000 - 0x901fffff
pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x54ffffff
Yenta: CardBus bridge found at 0000:02:06.1 [0e11:0058]
Yenta: ISA IRQ mask 0x00b8, PCI irq 10
Socket status: 30000006
Yenta: Raising subordinate bus# of parent bus (#02) from #04 to #07
pcmcia: parent PCI bridge I/O window: 0x4000 - 0x4fff
pcmcia: parent PCI bridge Memory window: 0x90000000 - 0x901fffff
pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x54ffffff
usbmon: debugfs is not available
ACPI: PCI Interrupt Link [C0CA] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [C0CA] -> GSI 10 (level, low) -> IRQ 10
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: irq 10, io mem 0xa0000000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 10, io base 0x000038c0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [C0C6] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [C0C6] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 10, io base 0x000038e0
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 10, io base 0x00003c00
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: PS/2 Controller [PNP0303:C199,PNP0f13:C19A] at 0x60,0x64 irq 1,12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
EDAC MC: Ver: 2.0.1 Jul 12 2006
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [C0C4] -> GSI 11 (level, low) -> IRQ 11
input: AT Translated Set 2 keyboard as /class/input/input0
Synaptics Touchpad, model: 1, fw: 5.9, id: 0x9b6eb1, caps: 0x884793/0x0
serio: Synaptics pass-through port at isa0060/serio4/input0
input: SynPS/2 Synaptics TouchPad as /class/input/input1
intel8x0_measure_ac97_clock: measured 56004 usecs
intel8x0: clocking to 48000
ALSA device list:
  #0: Intel 82801DB-ICH4 with AD1981B at 0xa0100000, irq 11
oprofile: using timer interrupt.
ip_conntrack version 2.4 (8190 buckets, 65520 max) - 204 bytes per conntrack
ip_tables: (C) 2000-2006 Netfilter Core Team
arp_tables: (C) 2002 David S. Miller
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
acpi_processor-0742 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination
acpi_processor-0742 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination
Using IPI Shortcut mode
ACPI: (supports S0 S3 S4 S5)
Freeing unused kernel memory: 188k freed
Time: tsc clocksource has been installed.
Time: acpi_pm clocksource has been installed.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1152735222.664:2): selinux=0 auid=4294967295
input: PS/2 Generic Mouse as /class/input/input2
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on dm-0, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 2031608k swap on /dev/VolGroup00/LogVol01.  Priority:-1 extents:1 across:2031608k
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
audit(1152735242.848:3): audit_pid=1553 old=0 by auid=4294967295

Pid: 9, comm:               kacpid
EIP: 0060:[<c01c948f>] CPU: 0
EIP is at delay_tsc+0xb/0x13
 EFLAGS: 00000283    Not tainted  (2.6.18-rc1-g155dbfd8 #24)
EAX: 4aa48900 EBX: 00026be1 ECX: 4aa40b7e EDX: 0000001a
ESI: 00000000 EDI: c039300d EBP: c0390df3 DS: 007b ES: 007b
CR0: 8005003b CR2: 080516f0 CR3: 362dc000 CR4: 000006d0
 [<c01c94c0>] __delay+0x6/0x7
 [<c01f23ef>] acpi_os_stall+0x1d/0x29
 [<c0201f11>] acpi_ex_system_do_stall+0x37/0x3b
 [<c0200fca>] acpi_ex_opcode_1A_0T_0R+0x85/0xc8
 [<c01f5308>] acpi_ds_exec_end_op+0x133/0x553
 [<c020d0f3>] acpi_ps_parse_loop+0x777/0xbe0
 [<c020c488>] acpi_ps_parse_aml+0xd8/0x2d5
 [<c020dbbe>] acpi_ps_execute_pass+0xa9/0xd2
 [<c020dd6a>] acpi_ps_execute_method+0x153/0x231
 [<c02095e1>] acpi_ns_evaluate+0x179/0x24c
 [<c01fc12e>] acpi_ev_asynch_execute_gpe_method+0xeb/0x159
 [<c01f2083>] acpi_os_execute_deferred+0x19/0x21
 [<c01226a0>] run_workqueue+0x68/0x95
 [<c01f206a>] acpi_os_execute_deferred+0x0/0x21
 [<c0122b2e>] worker_thread+0xf9/0x12b
 [<c03570bf>] schedule+0x469/0x4cc
 [<c0113bfb>] default_wake_function+0x0/0xc
 [<c0122a35>] worker_thread+0x0/0x12b
 [<c01249bb>] kthread+0xad/0xd8
 [<c012490e>] kthread+0x0/0xd8
 [<c0101005>] kernel_thread_helper+0x5/0xb

RE: kacpi_notify?

[Brown, Len]

Linus,
Does /proc/interrupts show that the acpi interrupt is ticking along
at the same rate as the kacpid_notify build-up?

If you run with  CONFIG_ACPI_THERMAL=n or otherwise nuke
the thermal module, does the interrupt and the kacpid_notify symptom go
away?

thanks,
-Len

RE: kacpi_notify?

[Linus Torvalds]

On Wed, 12 Jul 2006, Brown, Len wrote:
>
> Does /proc/interrupts show that the acpi interrupt is ticking along
> at the same rate as the kacpid_notify build-up?

It's really hard to tell.

The machine starts out fine, with no kacpid_notify buildup AT ALL.

Then, at some point, something changes. I dunno what, but I'm guessing the 
temperature goes up, and it gets a temp event and wants to turn on the 
fan.

And when that happens, things go to hell very quickly, and the whole 
machine becomes undebuggable quite soon. And it's really hard to hit the 
window between "uhhuh, bad things are starting to happen" and the "oops, 
the machine is now totally deal, only the magic scrolllock keys work any 
more".

So I can give you info about what the machine dos _before_ things go bad, 
and I can give limited register info about what happens when the machine 
is totally hosed, but I've only been able to get very lucky a few times 
(usually it's a "ps ax" that I had running to try to trigger it, and it 
locks up in the _middle_ of the "ps", showing tens of the kacpid_notify 
things - there are probably thousands, but the "ps ax" takes long enough 
that the machine runs out of memory before it even finishes.

> If you run with  CONFIG_ACPI_THERMAL=n or otherwise nuke
> the thermal module, does the interrupt and the kacpid_notify symptom go
> away?

I'll try that. Right now I've started a "git bisect" run, since it seemed 
to be the easiest way to get _some_ information about the problem, without 
having to know much else about it.

The problem, of course, is that there are those 6000 commits (fine, that's 
about 13 kernels to be tested), but more importantly that I'm not 100% 
sure how repeatable it all is (see above - it's not like it locks up 
immediately on boot, there seems to be something that triggers it, usually 
while doing a kernel compile or a big grep), and if I ever get that answer 
wrong, I'll be doing it all in vain.

		Linus

RE: kacpi_notify?

[Linus Torvalds]

On Wed, 12 Jul 2006, Linus Torvalds wrote:
> 
> I'll try that. Right now I've started a "git bisect" run, since it seemed 
> to be the easiest way to get _some_ information about the problem, without 
> having to know much else about it.

Current result: it _looks_ like it was brought in by when I did the ACPI 
merge on June 23 (commit 37224470c8c6d90a4062e76a08d4dc1fcf91fc89).

I've got a hundred-odd commits to go, but the next bisection test happens 
to be the parent of my merge (your "merge linus into release branch" 
merge: ae6c859b7dcd708efadf1c76279c33db213e3506), so if I'm right, I'd 
expect that to be a bad tree.

		Linus

RE: kacpi_notify?

[Linus Torvalds]

On Wed, 12 Jul 2006, Linus Torvalds wrote:
> 
> I've got a hundred-odd commits to go, but the next bisection test happens 
> to be the parent of my merge (your "merge linus into release branch" 
> merge: ae6c859b7dcd708efadf1c76279c33db213e3506), so if I'm right, I'd 
> expect that to be a bad tree.

Yup.

And yes, the problem seems to co-incide with getting about 300 acpi 
interrupts per second. After about 9500 interrupts (each of which seems to 
create one of these things), the machine is basically dead.

Ten thousand kacpid_notify threads is too much. Regardless of what brought 
on this bug, I think there's something wrong in anything that keeps on 
notifying things without keeping track of how many outstanding 
notifications it already has.

		Linus

RE: kacpi_notify?

[Brown, Len]

Likely related to bugzilla-5534

-Len 

RE: kacpi_notify?

[Brown, Len]

>Likely related to bugzilla-5534

b8d35192c55fb055792ff0641408eaaec7c88988

RE: kacpi_notify?

[Linus Torvalds]

On Wed, 12 Jul 2006, Brown, Len wrote:
>
> >Likely related to bugzilla-5534
> 
> b8d35192c55fb055792ff0641408eaaec7c88988

Well, that one certainly looks likely.

Any reason to not just revert it? The fundamental problems that it 
introduces are obviously much worse than the fix.

		Linus 

RE: kacpi_notify?

[Brown, Len]

>On Wed, 12 Jul 2006, Brown, Len wrote:
>>
>> >Likely related to bugzilla-5534
>> 
>> b8d35192c55fb055792ff0641408eaaec7c88988
>
>Well, that one certainly looks likely.
>
>Any reason to not just revert it? The fundamental problems that it 
>introduces are obviously much worse than the fix.

If reverting it fixes your EVO, then certainly this is what to do right
now.
However, as the saga in 5534 will testify, this will make other systems
unhappy,
so we'll have to come back quickly with an improved patch for 5534.

-Len

RE: kacpi_notify?

[Brown, Len]

>>On Wed, 12 Jul 2006, Brown, Len wrote:
>>>
>>> >Likely related to bugzilla-5534
>>> 
>>> b8d35192c55fb055792ff0641408eaaec7c88988
>>
>>Well, that one certainly looks likely.
>>
>>Any reason to not just revert it? The fundamental problems that it 
>>introduces are obviously much worse than the fix.
>
>If reverting it fixes your EVO, then certainly this is what to 
>do right now.  However, as the saga in 5534 will testify, this will
make 
>other systems unhappy, so we'll have to come back quickly with an
improved patch for 5534.

Ugh, ACPICA starts depending on on acpi_os_execute() at that time,
so a simple revert will break the build -- needs to be tweaked.

I can do it, but I've got to grab something to eat now...

-Len

RE: kacpi_notify?

[Linus Torvalds]

On Wed, 12 Jul 2006, Brown, Len wrote:
> 
> Ugh, ACPICA starts depending on on acpi_os_execute() at that time,
> so a simple revert will break the build -- needs to be tweaked.

Yeah, I just noticed.

Those "ACPICA" commits are crap. Crap, crap, crap. They do more than one 
thing, and are clearly just patches applied from a system that probably 
does have finer-grained granularity of tracking the changes.

Here's a suggested revert. This boots, and seems to have the problem 
fixed. At least I can now recompile the kernel on that machine again, 
without the machine crashing.

		Linus

----
Revert "ACPI: execute Notify() handlers on new thread"

This reverts commit b8d35192c55fb055792ff0641408eaaec7c88988 (and parts
of commit 958dd242b691f64ab4632b4903dbb1e16fee8269: "ACPI: ACPICA
20060512", which were intertwined, along with some Smart Battery logic
that had already started using the broken routines).

The thread execution doesn't actually solve the bug it set out to solve
(see

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

for more details) because the new events can get caught behind the AML
semaphore or other serialization.  And when that happens, the notify
threads keep on pilin gup until the system dies.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>


diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index e5d7963..bdf3e12 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -759,7 +759,8 @@ static u32 acpi_ec_gpe_poll_handler(void
 
 	acpi_disable_gpe(NULL, ec->common.gpe_bit, ACPI_ISR);
 
-	status = acpi_os_execute(OSL_EC_POLL_HANDLER, acpi_ec_gpe_query, ec);
+	status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
+					     acpi_ec_gpe_query, ec);
 
 	if (status == AE_OK)
 		return ACPI_INTERRUPT_HANDLED;
@@ -797,7 +798,7 @@ static u32 acpi_ec_gpe_intr_handler(void
 
 	if (value & ACPI_EC_FLAG_SCI) {
 		atomic_add(1, &ec->intr.pending_gpe);
-		status = acpi_os_execute(OSL_EC_BURST_HANDLER,
+		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
 						     acpi_ec_gpe_query, ec);
 		return status == AE_OK ?
 		    ACPI_INTERRUPT_HANDLED : ACPI_INTERRUPT_NOT_HANDLED;
diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
index c76c058..aad17dd 100644
--- a/drivers/acpi/events/evgpe.c
+++ b/drivers/acpi/events/evgpe.c
@@ -495,8 +495,8 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
  * RETURN:      None
  *
  * DESCRIPTION: Perform the actual execution of a GPE control method. This
- *              function is called from an invocation of acpi_os_execute and
- *              therefore does NOT execute at interrupt level - so that
+ *              function is called from an invocation of acpi_os_queue_for_execution
+ *              (and therefore does NOT execute at interrupt level) so that
  *              the control method itself is not executed in the context of
  *              an interrupt handler.
  *
@@ -692,9 +692,9 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_eve
 		 * Execute the method associated with the GPE
 		 * NOTE: Level-triggered GPEs are cleared after the method completes.
 		 */
-		status = acpi_os_execute(OSL_GPE_HANDLER,
-					 acpi_ev_asynch_execute_gpe_method,
-					 gpe_event_info);
+		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
+						     acpi_ev_asynch_execute_gpe_method,
+						     gpe_event_info);
 		if (ACPI_FAILURE(status)) {
 			ACPI_EXCEPTION((AE_INFO, status,
 					"Unable to queue handler for GPE[%2X] - event disabled",
diff --git a/drivers/acpi/events/evmisc.c b/drivers/acpi/events/evmisc.c
index 6eef4ef..625dd3b 100644
--- a/drivers/acpi/events/evmisc.c
+++ b/drivers/acpi/events/evmisc.c
@@ -192,9 +192,9 @@ acpi_ev_queue_notify_request(struct acpi
 		notify_info->notify.value = (u16) notify_value;
 		notify_info->notify.handler_obj = handler_obj;
 
-		status =
-		    acpi_os_execute(OSL_NOTIFY_HANDLER, acpi_ev_notify_dispatch,
-				    notify_info);
+		status = acpi_os_queue_for_execution(OSD_PRIORITY_HIGH,
+						     acpi_ev_notify_dispatch,
+						     notify_info);
 		if (ACPI_FAILURE(status)) {
 			acpi_ut_delete_generic_state(notify_info);
 		}
@@ -347,9 +347,9 @@ static u32 acpi_ev_global_lock_handler(v
 
 		/* Run the Global Lock thread which will signal all waiting threads */
 
-		status =
-		    acpi_os_execute(OSL_GLOBAL_LOCK_HANDLER,
-				    acpi_ev_global_lock_thread, context);
+		status = acpi_os_queue_for_execution(OSD_PRIORITY_HIGH,
+						     acpi_ev_global_lock_thread,
+						     context);
 		if (ACPI_FAILURE(status)) {
 			ACPI_EXCEPTION((AE_INFO, status,
 					"Could not queue Global Lock thread"));
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 47dfde9..8eb3ab6 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -36,7 +36,6 @@ #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/workqueue.h>
 #include <linux/nmi.h>
-#include <linux/kthread.h>
 #include <acpi/acpi.h>
 #include <asm/io.h>
 #include <acpi/acpi_bus.h>
@@ -583,41 +582,23 @@ static void acpi_os_execute_deferred(voi
 	return;
 }
 
-static int acpi_os_execute_thread(void *context)
-{
-	struct acpi_os_dpc *dpc = (struct acpi_os_dpc *)context;
-	if (dpc) {
-		dpc->function(dpc->context);
-		kfree(dpc);
-	}
-	do_exit(0);
-}
-
-/*******************************************************************************
- *
- * FUNCTION:    acpi_os_execute
- *
- * PARAMETERS:  Type               - Type of the callback
- *              Function           - Function to be executed
- *              Context            - Function parameters
- *
- * RETURN:      Status
- *
- * DESCRIPTION: Depending on type, either queues function for deferred execution or
- *              immediately executes function on a separate thread.
- *
- ******************************************************************************/
-
-acpi_status acpi_os_execute(acpi_execute_type type,
+acpi_status
+acpi_os_queue_for_execution(u32 priority,
 			    acpi_osd_exec_callback function, void *context)
 {
 	acpi_status status = AE_OK;
 	struct acpi_os_dpc *dpc;
 	struct work_struct *task;
-	struct task_struct *p;
+
+	ACPI_FUNCTION_TRACE("os_queue_for_execution");
+
+	ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+			  "Scheduling function [%p(%p)] for deferred execution.\n",
+			  function, context));
 
 	if (!function)
-		return AE_BAD_PARAMETER;
+		return_ACPI_STATUS(AE_BAD_PARAMETER);
+
 	/*
 	 * Allocate/initialize DPC structure.  Note that this memory will be
 	 * freed by the callee.  The kernel handles the tq_struct list  in a
@@ -628,37 +609,30 @@ acpi_status acpi_os_execute(acpi_execute
 	 * We can save time and code by allocating the DPC and tq_structs
 	 * from the same memory.
 	 */
-	if (type == OSL_NOTIFY_HANDLER) {
-		dpc = kmalloc(sizeof(struct acpi_os_dpc), GFP_KERNEL);
-	} else {
-		dpc = kmalloc(sizeof(struct acpi_os_dpc) +
-				sizeof(struct work_struct), GFP_ATOMIC);
-	}
+
+	dpc =
+	    kmalloc(sizeof(struct acpi_os_dpc) + sizeof(struct work_struct),
+		    GFP_ATOMIC);
 	if (!dpc)
-		return AE_NO_MEMORY;
+		return_ACPI_STATUS(AE_NO_MEMORY);
+
 	dpc->function = function;
 	dpc->context = context;
 
-	if (type == OSL_NOTIFY_HANDLER) {
-		p = kthread_create(acpi_os_execute_thread, dpc, "kacpid_notify");
-		if (!IS_ERR(p)) {
-			wake_up_process(p);
-		} else {
-			status = AE_NO_MEMORY;
-			kfree(dpc);
-		}
-	} else {
-		task = (void *)(dpc + 1);
-		INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
-		if (!queue_work(kacpid_wq, task)) {
-			status = AE_ERROR;
-			kfree(dpc);
-		}
+	task = (void *)(dpc + 1);
+	INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
+
+	if (!queue_work(kacpid_wq, task)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+				  "Call to queue_work() failed.\n"));
+		kfree(dpc);
+		status = AE_ERROR;
 	}
-	return status;
+
+	return_ACPI_STATUS(status);
 }
 
-EXPORT_SYMBOL(acpi_os_execute);
+EXPORT_SYMBOL(acpi_os_queue_for_execution);
 
 void acpi_os_wait_events_complete(void *context)
 {
diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
index db7b350..87d7800 100644
--- a/drivers/acpi/sbs.c
+++ b/drivers/acpi/sbs.c
@@ -1366,7 +1366,7 @@ static void acpi_ac_remove(struct acpi_s
 
 static void acpi_sbs_update_queue_run(unsigned long data)
 {
-	acpi_os_execute(OSL_GPE_HANDLER, acpi_sbs_update_queue, (void *)data);
+	acpi_os_queue_for_execution(OSD_PRIORITY_GPE, acpi_sbs_update_queue, (void *)data);
 }
 
 static int acpi_sbs_update_run(struct acpi_sbs *sbs, int data_type)
@@ -1658,11 +1658,11 @@ static int acpi_sbs_add(struct acpi_devi
 
 	init_timer(&sbs->update_timer);
 	if (update_mode == QUEUE_UPDATE_MODE) {
-		status = acpi_os_execute(OSL_GPE_HANDLER,
+		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
 					 acpi_sbs_update_queue, (void *)sbs);
 		if (status != AE_OK) {
 			ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
-					  "acpi_os_execute() failed\n"));
+					  "acpi_os_queue_for_execution() failed\n"));
 		}
 	}
 	sbs->update_time = update_time;
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 5753d06..e16e69a 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -657,7 +657,8 @@ static void acpi_thermal_run(unsigned lo
 {
 	struct acpi_thermal *tz = (struct acpi_thermal *)data;
 	if (!tz->zombie)
-		acpi_os_execute(OSL_GPE_HANDLER, acpi_thermal_check, (void *)data);
+		acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
+					    acpi_thermal_check, (void *)data);
 }
 
 static void acpi_thermal_check(void *data)
diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
index 0cd63bc..8040084 100644
--- a/include/acpi/acpiosxf.h
+++ b/include/acpi/acpiosxf.h
@@ -50,16 +50,12 @@ #define __ACPIOSXF_H__
 #include "platform/acenv.h"
 #include "actypes.h"
 
-/* Types for acpi_os_execute */
+/* Priorities for acpi_os_queue_for_execution */
 
-typedef enum {
-	OSL_GLOBAL_LOCK_HANDLER,
-	OSL_NOTIFY_HANDLER,
-	OSL_GPE_HANDLER,
-	OSL_DEBUGGER_THREAD,
-	OSL_EC_POLL_HANDLER,
-	OSL_EC_BURST_HANDLER
-} acpi_execute_type;
+#define OSD_PRIORITY_GPE            1
+#define OSD_PRIORITY_HIGH           2
+#define OSD_PRIORITY_MED            3
+#define OSD_PRIORITY_LO             4
 
 #define ACPI_NO_UNIT_LIMIT          ((u32) -1)
 #define ACPI_MUTEX_SEM              1
@@ -188,8 +184,8 @@ acpi_os_remove_interrupt_handler(u32 gsi
 acpi_thread_id acpi_os_get_thread_id(void);
 
 acpi_status
-acpi_os_execute(acpi_execute_type type,
-		acpi_osd_exec_callback function, void *context);
+acpi_os_queue_for_execution(u32 priority,
+			    acpi_osd_exec_callback function, void *context);
 
 void acpi_os_wait_events_complete(void *context);
 

RE: kacpi_notify?

[Len Brown]

>Here's a suggested revert.

Please try this smaller revert to just osl.c.
(it builds and boots for me)

It reverts acpi_os_queue_for_execution() to exactly
as it was in 2.6.17, except it changes the name to
acpi_os_execute() to match ACPICA 20060512.

(yes, it is okay we ignore the 1st parameter,
 it wasn't used until the 5534 fix we are reverting)

thanks,
-Len

Signed-off-by: Len Brown <len.brown@intel.com>

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
diff --git a/drivers/acpi/events/evmisc.c b/drivers/acpi/events/evmisc.c
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 47dfde9..b7d1514 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -36,7 +36,6 @@ #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/workqueue.h>
 #include <linux/nmi.h>
-#include <linux/kthread.h>
 #include <acpi/acpi.h>
 #include <asm/io.h>
 #include <acpi/acpi_bus.h>
@@ -583,16 +582,6 @@ static void acpi_os_execute_deferred(voi
 	return;
 }
 
-static int acpi_os_execute_thread(void *context)
-{
-	struct acpi_os_dpc *dpc = (struct acpi_os_dpc *)context;
-	if (dpc) {
-		dpc->function(dpc->context);
-		kfree(dpc);
-	}
-	do_exit(0);
-}
-
 /*******************************************************************************
  *
  * FUNCTION:    acpi_os_execute
@@ -614,10 +603,16 @@ acpi_status acpi_os_execute(acpi_execute
 	acpi_status status = AE_OK;
 	struct acpi_os_dpc *dpc;
 	struct work_struct *task;
-	struct task_struct *p;
+
+	ACPI_FUNCTION_TRACE("os_queue_for_execution");
+
+	ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+			  "Scheduling function [%p(%p)] for deferred execution.\n",
+			  function, context));
 
 	if (!function)
-		return AE_BAD_PARAMETER;
+		return_ACPI_STATUS(AE_BAD_PARAMETER);
+
 	/*
 	 * Allocate/initialize DPC structure.  Note that this memory will be
 	 * freed by the callee.  The kernel handles the tq_struct list  in a
@@ -628,34 +623,27 @@ acpi_status acpi_os_execute(acpi_execute
 	 * We can save time and code by allocating the DPC and tq_structs
 	 * from the same memory.
 	 */
-	if (type == OSL_NOTIFY_HANDLER) {
-		dpc = kmalloc(sizeof(struct acpi_os_dpc), GFP_KERNEL);
-	} else {
-		dpc = kmalloc(sizeof(struct acpi_os_dpc) +
-				sizeof(struct work_struct), GFP_ATOMIC);
-	}
+
+	dpc =
+	    kmalloc(sizeof(struct acpi_os_dpc) + sizeof(struct work_struct),
+		    GFP_ATOMIC);
 	if (!dpc)
-		return AE_NO_MEMORY;
+		return_ACPI_STATUS(AE_NO_MEMORY);
+
 	dpc->function = function;
 	dpc->context = context;
 
-	if (type == OSL_NOTIFY_HANDLER) {
-		p = kthread_create(acpi_os_execute_thread, dpc, "kacpid_notify");
-		if (!IS_ERR(p)) {
-			wake_up_process(p);
-		} else {
-			status = AE_NO_MEMORY;
-			kfree(dpc);
-		}
-	} else {
-		task = (void *)(dpc + 1);
-		INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
-		if (!queue_work(kacpid_wq, task)) {
-			status = AE_ERROR;
-			kfree(dpc);
-		}
+	task = (void *)(dpc + 1);
+	INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
+
+	if (!queue_work(kacpid_wq, task)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+				  "Call to queue_work() failed.\n"));
+		kfree(dpc);
+		status = AE_ERROR;
 	}
-	return status;
+
+	return_ACPI_STATUS(status);
 }
 
 EXPORT_SYMBOL(acpi_os_execute);

RE: kacpi_notify?

[Starikovskiy, Alexey Y]

Linus,

I'm terribly sorry that my patch broke on your machine.
May I ask you to send me or attach to #5534 output of acpidump from this
machine?
Do you think that the whole idea is crap, or if I limit number of
possible spawned threads and forsibly put current thread to sleep (which
will release ACPICA executer mutex), as it happens in DSDT of nx6125 it
will be possible to use it?

Thanks in advance, and once again my apology.
Alex.

>-----Original Message-----
>From: Linus Torvalds [mailto:torvalds@osdl.org] 
>Sent: Thursday, July 13, 2006 4:15 AM
>To: Brown, Len
>Cc: Andrew Morton; linux-acpi@vger.kernel.org; Moore, Robert; 
>Starikovskiy, Alexey Y
>Subject: RE: kacpi_notify?
>
>
>
>On Wed, 12 Jul 2006, Brown, Len wrote:
>> 
>> Ugh, ACPICA starts depending on on acpi_os_execute() at that time,
>> so a simple revert will break the build -- needs to be tweaked.
>
>Yeah, I just noticed.
>
>Those "ACPICA" commits are crap. Crap, crap, crap. They do 
>more than one 
>thing, and are clearly just patches applied from a system that 
>probably 
>does have finer-grained granularity of tracking the changes.
>
>Here's a suggested revert. This boots, and seems to have the problem 
>fixed. At least I can now recompile the kernel on that machine again, 
>without the machine crashing.
>
>		Linus
>
>----
>Revert "ACPI: execute Notify() handlers on new thread"
>
>This reverts commit b8d35192c55fb055792ff0641408eaaec7c88988 (and parts
>of commit 958dd242b691f64ab4632b4903dbb1e16fee8269: "ACPI: ACPICA
>20060512", which were intertwined, along with some Smart Battery logic
>that had already started using the broken routines).
>
>The thread execution doesn't actually solve the bug it set out to solve
>(see
>
>	http://bugzilla.kernel.org/show_bug.cgi?id=5534
>
>for more details) because the new events can get caught behind the AML
>semaphore or other serialization.  And when that happens, the notify
>threads keep on pilin gup until the system dies.
>
>Signed-off-by: Linus Torvalds <torvalds@osdl.org>
>
>
>diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>index e5d7963..bdf3e12 100644
>--- a/drivers/acpi/ec.c
>+++ b/drivers/acpi/ec.c
>@@ -759,7 +759,8 @@ static u32 acpi_ec_gpe_poll_handler(void
> 
> 	acpi_disable_gpe(NULL, ec->common.gpe_bit, ACPI_ISR);
> 
>-	status = acpi_os_execute(OSL_EC_POLL_HANDLER, 
>acpi_ec_gpe_query, ec);
>+	status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
>+					     acpi_ec_gpe_query, ec);
> 
> 	if (status == AE_OK)
> 		return ACPI_INTERRUPT_HANDLED;
>@@ -797,7 +798,7 @@ static u32 acpi_ec_gpe_intr_handler(void
> 
> 	if (value & ACPI_EC_FLAG_SCI) {
> 		atomic_add(1, &ec->intr.pending_gpe);
>-		status = acpi_os_execute(OSL_EC_BURST_HANDLER,
>+		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
> 						     
>acpi_ec_gpe_query, ec);
> 		return status == AE_OK ?
> 		    ACPI_INTERRUPT_HANDLED : ACPI_INTERRUPT_NOT_HANDLED;
>diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
>index c76c058..aad17dd 100644
>--- a/drivers/acpi/events/evgpe.c
>+++ b/drivers/acpi/events/evgpe.c
>@@ -495,8 +495,8 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_x
>  * RETURN:      None
>  *
>  * DESCRIPTION: Perform the actual execution of a GPE control 
>method. This
>- *              function is called from an invocation of 
>acpi_os_execute and
>- *              therefore does NOT execute at interrupt level 
>- so that
>+ *              function is called from an invocation of 
>acpi_os_queue_for_execution
>+ *              (and therefore does NOT execute at interrupt 
>level) so that
>  *              the control method itself is not executed in 
>the context of
>  *              an interrupt handler.
>  *
>@@ -692,9 +692,9 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_eve
> 		 * Execute the method associated with the GPE
> 		 * NOTE: Level-triggered GPEs are cleared after 
>the method completes.
> 		 */
>-		status = acpi_os_execute(OSL_GPE_HANDLER,
>-					 
>acpi_ev_asynch_execute_gpe_method,
>-					 gpe_event_info);
>+		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
>+						     
>acpi_ev_asynch_execute_gpe_method,
>+						     gpe_event_info);
> 		if (ACPI_FAILURE(status)) {
> 			ACPI_EXCEPTION((AE_INFO, status,
> 					"Unable to queue 
>handler for GPE[%2X] - event disabled",
>diff --git a/drivers/acpi/events/evmisc.c 
>b/drivers/acpi/events/evmisc.c
>index 6eef4ef..625dd3b 100644
>--- a/drivers/acpi/events/evmisc.c
>+++ b/drivers/acpi/events/evmisc.c
>@@ -192,9 +192,9 @@ acpi_ev_queue_notify_request(struct acpi
> 		notify_info->notify.value = (u16) notify_value;
> 		notify_info->notify.handler_obj = handler_obj;
> 
>-		status =
>-		    acpi_os_execute(OSL_NOTIFY_HANDLER, 
>acpi_ev_notify_dispatch,
>-				    notify_info);
>+		status = acpi_os_queue_for_execution(OSD_PRIORITY_HIGH,
>+						     
>acpi_ev_notify_dispatch,
>+						     notify_info);
> 		if (ACPI_FAILURE(status)) {
> 			acpi_ut_delete_generic_state(notify_info);
> 		}
>@@ -347,9 +347,9 @@ static u32 acpi_ev_global_lock_handler(v
> 
> 		/* Run the Global Lock thread which will signal 
>all waiting threads */
> 
>-		status =
>-		    acpi_os_execute(OSL_GLOBAL_LOCK_HANDLER,
>-				    acpi_ev_global_lock_thread, 
>context);
>+		status = acpi_os_queue_for_execution(OSD_PRIORITY_HIGH,
>+						     
>acpi_ev_global_lock_thread,
>+						     context);
> 		if (ACPI_FAILURE(status)) {
> 			ACPI_EXCEPTION((AE_INFO, status,
> 					"Could not queue Global 
>Lock thread"));
>diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>index 47dfde9..8eb3ab6 100644
>--- a/drivers/acpi/osl.c
>+++ b/drivers/acpi/osl.c
>@@ -36,7 +36,6 @@ #include <linux/kmod.h>
> #include <linux/delay.h>
> #include <linux/workqueue.h>
> #include <linux/nmi.h>
>-#include <linux/kthread.h>
> #include <acpi/acpi.h>
> #include <asm/io.h>
> #include <acpi/acpi_bus.h>
>@@ -583,41 +582,23 @@ static void acpi_os_execute_deferred(voi
> 	return;
> }
> 
>-static int acpi_os_execute_thread(void *context)
>-{
>-	struct acpi_os_dpc *dpc = (struct acpi_os_dpc *)context;
>-	if (dpc) {
>-		dpc->function(dpc->context);
>-		kfree(dpc);
>-	}
>-	do_exit(0);
>-}
>-
>-/*************************************************************
>******************
>- *
>- * FUNCTION:    acpi_os_execute
>- *
>- * PARAMETERS:  Type               - Type of the callback
>- *              Function           - Function to be executed
>- *              Context            - Function parameters
>- *
>- * RETURN:      Status
>- *
>- * DESCRIPTION: Depending on type, either queues function for 
>deferred execution or
>- *              immediately executes function on a separate thread.
>- *
>- 
>***************************************************************
>***************/
>-
>-acpi_status acpi_os_execute(acpi_execute_type type,
>+acpi_status
>+acpi_os_queue_for_execution(u32 priority,
> 			    acpi_osd_exec_callback function, 
>void *context)
> {
> 	acpi_status status = AE_OK;
> 	struct acpi_os_dpc *dpc;
> 	struct work_struct *task;
>-	struct task_struct *p;
>+
>+	ACPI_FUNCTION_TRACE("os_queue_for_execution");
>+
>+	ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
>+			  "Scheduling function [%p(%p)] for 
>deferred execution.\n",
>+			  function, context));
> 
> 	if (!function)
>-		return AE_BAD_PARAMETER;
>+		return_ACPI_STATUS(AE_BAD_PARAMETER);
>+
> 	/*
> 	 * Allocate/initialize DPC structure.  Note that this 
>memory will be
> 	 * freed by the callee.  The kernel handles the 
>tq_struct list  in a
>@@ -628,37 +609,30 @@ acpi_status acpi_os_execute(acpi_execute
> 	 * We can save time and code by allocating the DPC and 
>tq_structs
> 	 * from the same memory.
> 	 */
>-	if (type == OSL_NOTIFY_HANDLER) {
>-		dpc = kmalloc(sizeof(struct acpi_os_dpc), GFP_KERNEL);
>-	} else {
>-		dpc = kmalloc(sizeof(struct acpi_os_dpc) +
>-				sizeof(struct work_struct), GFP_ATOMIC);
>-	}
>+
>+	dpc =
>+	    kmalloc(sizeof(struct acpi_os_dpc) + sizeof(struct 
>work_struct),
>+		    GFP_ATOMIC);
> 	if (!dpc)
>-		return AE_NO_MEMORY;
>+		return_ACPI_STATUS(AE_NO_MEMORY);
>+
> 	dpc->function = function;
> 	dpc->context = context;
> 
>-	if (type == OSL_NOTIFY_HANDLER) {
>-		p = kthread_create(acpi_os_execute_thread, dpc, 
>"kacpid_notify");
>-		if (!IS_ERR(p)) {
>-			wake_up_process(p);
>-		} else {
>-			status = AE_NO_MEMORY;
>-			kfree(dpc);
>-		}
>-	} else {
>-		task = (void *)(dpc + 1);
>-		INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
>-		if (!queue_work(kacpid_wq, task)) {
>-			status = AE_ERROR;
>-			kfree(dpc);
>-		}
>+	task = (void *)(dpc + 1);
>+	INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
>+
>+	if (!queue_work(kacpid_wq, task)) {
>+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
>+				  "Call to queue_work() failed.\n"));
>+		kfree(dpc);
>+		status = AE_ERROR;
> 	}
>-	return status;
>+
>+	return_ACPI_STATUS(status);
> }
> 
>-EXPORT_SYMBOL(acpi_os_execute);
>+EXPORT_SYMBOL(acpi_os_queue_for_execution);
> 
> void acpi_os_wait_events_complete(void *context)
> {
>diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
>index db7b350..87d7800 100644
>--- a/drivers/acpi/sbs.c
>+++ b/drivers/acpi/sbs.c
>@@ -1366,7 +1366,7 @@ static void acpi_ac_remove(struct acpi_s
> 
> static void acpi_sbs_update_queue_run(unsigned long data)
> {
>-	acpi_os_execute(OSL_GPE_HANDLER, acpi_sbs_update_queue, 
>(void *)data);
>+	acpi_os_queue_for_execution(OSD_PRIORITY_GPE, 
>acpi_sbs_update_queue, (void *)data);
> }
> 
> static int acpi_sbs_update_run(struct acpi_sbs *sbs, int data_type)
>@@ -1658,11 +1658,11 @@ static int acpi_sbs_add(struct acpi_devi
> 
> 	init_timer(&sbs->update_timer);
> 	if (update_mode == QUEUE_UPDATE_MODE) {
>-		status = acpi_os_execute(OSL_GPE_HANDLER,
>+		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
> 					 acpi_sbs_update_queue, 
>(void *)sbs);
> 		if (status != AE_OK) {
> 			ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
>-					  "acpi_os_execute() 
>failed\n"));
>+					  
>"acpi_os_queue_for_execution() failed\n"));
> 		}
> 	}
> 	sbs->update_time = update_time;
>diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
>index 5753d06..e16e69a 100644
>--- a/drivers/acpi/thermal.c
>+++ b/drivers/acpi/thermal.c
>@@ -657,7 +657,8 @@ static void acpi_thermal_run(unsigned lo
> {
> 	struct acpi_thermal *tz = (struct acpi_thermal *)data;
> 	if (!tz->zombie)
>-		acpi_os_execute(OSL_GPE_HANDLER, 
>acpi_thermal_check, (void *)data);
>+		acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
>+					    acpi_thermal_check, 
>(void *)data);
> }
> 
> static void acpi_thermal_check(void *data)
>diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
>index 0cd63bc..8040084 100644
>--- a/include/acpi/acpiosxf.h
>+++ b/include/acpi/acpiosxf.h
>@@ -50,16 +50,12 @@ #define __ACPIOSXF_H__
> #include "platform/acenv.h"
> #include "actypes.h"
> 
>-/* Types for acpi_os_execute */
>+/* Priorities for acpi_os_queue_for_execution */
> 
>-typedef enum {
>-	OSL_GLOBAL_LOCK_HANDLER,
>-	OSL_NOTIFY_HANDLER,
>-	OSL_GPE_HANDLER,
>-	OSL_DEBUGGER_THREAD,
>-	OSL_EC_POLL_HANDLER,
>-	OSL_EC_BURST_HANDLER
>-} acpi_execute_type;
>+#define OSD_PRIORITY_GPE            1
>+#define OSD_PRIORITY_HIGH           2
>+#define OSD_PRIORITY_MED            3
>+#define OSD_PRIORITY_LO             4
> 
> #define ACPI_NO_UNIT_LIMIT          ((u32) -1)
> #define ACPI_MUTEX_SEM              1
>@@ -188,8 +184,8 @@ acpi_os_remove_interrupt_handler(u32 gsi
> acpi_thread_id acpi_os_get_thread_id(void);
> 
> acpi_status
>-acpi_os_execute(acpi_execute_type type,
>-		acpi_osd_exec_callback function, void *context);
>+acpi_os_queue_for_execution(u32 priority,
>+			    acpi_osd_exec_callback function, 
>void *context);
> 
> void acpi_os_wait_events_complete(void *context);
> 
>

RE: kacpi_notify?

[Linus Torvalds]

On Thu, 13 Jul 2006, Starikovskiy, Alexey Y wrote:
> 
> I'm terribly sorry that my patch broke on your machine.
> May I ask you to send me or attach to #5534 output of acpidump from this
> machine?

I'll send it in another email, since I already generated it for Len ;)

> Do you think that the whole idea is crap, or if I limit number of
> possible spawned threads and forsibly put current thread to sleep (which
> will release ACPICA executer mutex), as it happens in DSDT of nx6125 it
> will be possible to use it?

I don't think the _idea_ is crap per se, but it would at a minimum need a 
thread limit. But I think it's the wrong approach: especially if you put 
the current thread to sleep, you really don't want another thread at all, 
you are really just working around a problem that is totally internal to 
acpi (and the AML interpreter in particular).

So I think the problem really lies elsewhere, and that the whole thread 
approach was trying to paper over it. And having a limited set of threads 
is probably potentially _worse_ then what we have now.

Is there no way to have the AML interpreter have some state, and just push 
that current interrupted state back onto the "event queue", and just start 
executing the new one instead? That sounds like it should fix the _real_ 
problem - a kind of "mini-scheduler" for ACPI events?

		Linus

RE: kacpi_notify?

[Starikovskiy, Alexey Y]

>I don't think the _idea_ is crap per se, but it would at a 
>minimum need a 
>thread limit. But I think it's the wrong approach: especially 
>if you put 
>the current thread to sleep, you really don't want another 
>thread at all, 
>you are really just working around a problem that is totally 
>internal to 
>acpi (and the AML interpreter in particular).

Agree, this was meant as a temporary fix while we make 
interpreter to be able to preempt, as you suggesting later.

>
>So I think the problem really lies elsewhere, and that the 
>whole thread 
>approach was trying to paper over it. And having a limited set 
>of threads 
>is probably potentially _worse_ then what we have now.

Right now we have overheating NX and NC series of notebooks 
from HP with AMD processors (somehow Intel DSDTs do not 
use Notify from infinite While loop), plus several "kacpid uses 
100% of cpu" caused by Notify() events, which were scheduled to 
rush through the queue if the bloker exits. 

>
>Is there no way to have the AML interpreter have some state, 
>and just push 
>that current interrupted state back onto the "event queue", 
>and just start executing the new one instead?

This interpreter cannot do such tricks and if we choose to 
executer Notify() immidiately on the same stack we risk to overflow
it...

> That sounds like it should fix the _real_ 
>problem - a kind of "mini-scheduler" for ACPI events?

Yes, that will be a perfect solution, but it will require whole
interpreter rewrite, 
so will take time.

>
>		Linus
>

Thanks,
	Alex.