Re: [patch 11/14] ACPI: change GFP_ATOMIC to GFP_KERNEL for non-atomic allocation
On Wed, 16 Aug 2006, Len Brown wrote:
acpi_pci_link_set() allocates with GFP_ATOMIC. On resume from suspend,
this is called with interrupts off, otherwise GFP_KERNEL is safe.
So you are suggesting this?
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 7f3e7e7..d53bd98 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -307,7 +307,7 @@ static int acpi_pci_link_set(struct acpi
if (!link || !irq)
return -EINVAL;
- resource = kmalloc(sizeof(*resource) + 1, GFP_ATOMIC);
+ resource = kmalloc(sizeof(*resource) + 1, irqs_disabled() ? GFP_ATOMIC:
GFP_KERNEL);
if (!resource)
return -ENOMEM;
Yes, exactly.
acpi_pci_link_resume - acpi_pci_link_set - acpi_set_current_resources -
acpi_rs_set_srs_method_data - acpi_ut_create_internal_object_dbg -
acpi_ut_allocate_object_desc_dbg - acpi_os_acquire_object -
kmem_cache_alloc(GFP_KERNEL) flag.
I don't understand this comment.
acpi_os_acquire_object is implemented in aclinux.h:
static inline void *acpi_os_acquire_object(acpi_cache_t * cache) {
return kmem_cache_zalloc(cache, irqs_disabled() ? GFP_ATOMIC :
GFP_KERNEL);
}
This happened in some -rc of 2.6.18 (can be seen at
http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Ftesting%2Fpatch-2.6.18-rc4.bz2;z=2727)
- the acpi_os_acquire_object() was renamed to acpi_os_validate_interface()
... which allocates solely with GFP_KERNEL, but this may be OK, I haven't
checked.
Anyway ...
Unfortunately, looking at the refactorized ACPI code in
2.6.18-rc4, there are still issues with sleeping functions called with
disabled interrupts (during resume), in ACPI code.
Two random examples:
- when acpi_pci_link_set() is called during resume (local irqs off), the
following callchain happens, which is bad: acpi_pci_link_resume -
acpi_pci_link_set - acpi_set_current_resources -
acpi_rs_set_srs_method_data - acpi_ns_evaluate - acpi_ns_get_node ..
here the mutex is acquired. Not good.
- device_power_up - sysdev_resume - __sysdev_resume - cpufreq_resume -
blocking_notifier_call_chain - down on semaphore. Not good.
Is there any general idea for solution?
Thanks,
--
JiKos.
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Button implementation question
Hi !
I don't have much knowlegde about ACPI :-(
What I have is a device called FuturePad PC which has some four
keys at the bottom and one double key at the side. It also has a
button on the left side to switch it off, which works fine with
Linux' ACPI, acpid and /etc/acpi/events/powerbt
When I run Linux 2.6.16 (the Debian variety), and
press one of the keys, I get this error output:
ACPI Error (evregion-0303): No handler for Region [ASI2] (bebb42a4)
[user_defined_region] [20060127]
ACPI Error (exfldio-0279): Region user_defined_region(81) has no handler
[20060127]
ACPI Exception (dswexec-0458): AE_NOT_EXIST, While resolving operands for
[AE_NOT_CONFIGURED] [20060127]
ACPI Error (psparse-0517): Method parse/execution failed [\_GPE._L2A] (Node
bebaffe0), AE_NOT_EXIST
ACPI Exception (evgpe-0553): AE_NOT_EXIST, While evaluating method [_L2A] for
GPE[ 0] [20060127]
Now I googled for region 81 and ASI2 and have some questions:
a) there is a driver for some Atlas Wallmount Touchscreen device from
Jaya Kumar which claims to implement something for region 81 (whatever that
is). I took the code from
http://marc.theaimsgroup.com/?l=linux-acpim=115391161115058w=2,
compiled that and loaded it as a module. That worked so far. But it didn't
change anything, I still get those errors.
Is there any documented way on how to implement kernel support for
arbitrary ACPI buttons?
b) I used iaml to dissemble my dsdt. There I found a section like this:
Scope (\_SB)
{
Device (ASIM)
{
Name (_HID, ASIM)
Name (_GPE, 0x00)
Name (_UID, 0x00)
OperationRegion (ASI2, 0x81, 0x00, 0x0001)
Field (ASI2, AnyAcc, Lock, Preserve)
{
BNE1, 8,
BNE2, 8,
BNE3, 8,
BNE4, 8,
BNEU, 8,
BNED, 8,
BNEL, 8,
BNER, 8,
BNEE, 8,
BNES, 8,
BNEC, 8,
BNRB, 8,
BNRC, 8,
BNRD, 8,
BNRE, 8,
BNRF, 8,
BNS1, 8,
BNS2, 8,
BNS3, 8,
BNS4, 8,
BNSU, 8,
BNSD, 8,
BNSL, 8,
BNSR, 8,
BNSE, 8,
BNSS, 8,
BNSC, 8,
BSRB, 8,
BSRC, 8,
BSRD, 8,
BSRE, 8,
BSRF, 8,
BNT1, 8,
BNT2, 8,
BNT3, 8,
BNT4, 8,
BNTU, 8,
BNTD, 8,
BNTL, 8,
BNTR, 8,
BNTE, 8,
BNTS, 8,
BNTC, 8,
BRIT, 8,
BTRC, 8,
BTRD, 8,
}
Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}
}
}
Here I see both 'ASI2' and 0x81. In what relation is this code to any
possible kernel module that I could write?
c) one error messages referred to some AE_NOT_EXIST, While evaluating
method [_L2A] (hey, the While should be while!). Whatever an AE is.
Anyway, I found a method named _L2A in my dsdt.dsl:
Method (_L2A, 0, NotSerialized)
{
Store (0x2A, DEBP)
If (LEqual (\_SB.ASIM.BNS3, 0x00))
{
If (\_SB.PCI0.PM.EGS2)
{
Store (0x00, \_SB.ASIM.BNSU)
}
Else
{
Store (0x01, \_SB.ASIM.BNEU)
Store (0x01, \_SB.ASIM.BNSU)
}
}
Else
{
If (LEqual (\_SB.PCI0.PM.EGS2, 0x00))
{
BRTU ()
STBS ()
}
}
}
Anything erraneous with that?
d) When I recompile my dsdt.dsl file, I get 3 errors and a bunch of
warnings (but not in the area of the above posted ASI2 stuff. Also,
the ACPI output in dmesg don't look erraneous to me. Shoud I still
seek help in this list to fix the DSDT?
ACPI: RSDP (v000 PTLTD ) @ 0x000f7000
ACPI: RSDT (v001 PTLTDRSDT 0x06040005 LTP 0x) @ 0x0eff9583
ACPI: FADT (v001 TMETA PDB.ALI 0x06040005 PTL 0x000f4240) @ 0x0effee77
ACPI: SSDT (v001 PTLTD ACPIPST1 0x06040005 LTP 0x0001) @ 0x0effeeeb
ACPI: DSDT (v001 TM PDBALI35 0x06040005 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x8008
...
ACPI: setting ELCR to 0200 (from 8ca0)
...
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative [20060127]
ACPI Error (nsxfeval-0242): Handle is
Re: [PATCH,RFC]: acpi,backlight: MSI S270 - driver, second try
On Thu, 17.08.06 15:21, Pavel Machek ([EMAIL PROTECTED]) wrote:
This patch applies to 2.6.17 and requires the ACPI ec_transaction()
patch I posted earlier:
http://marc.theaimsgroup.com/?l=linux-acpim=115517193511970w=2
Please comment and/or apply!
Looks ok to me...
Thanks!
+static int auto_brightness;
+module_param(auto_brightness, int, 0);
+MODULE_PARM_DESC(auto_brightness, Enable automatic brightness control (0:
disabled; 1: enabled; 2: don't touch));
+
+/*** Hardware access ***/
+
+static const uint8_t lcd_table[MSI_LCD_LEVEL_MAX] = {
+0x00, 0x1f, 0x3e, 0x5d, 0x7c, 0x9b, 0xba, 0xd9, 0xf8
+};
Can we get 0xf8 levels and simplify code while we are at it?
Unfortunately not. The hardware only supports 9 levels of
brightness.
However, I guess I could multiply the brightness level with 31 instead
of using the translation table above.
I will fix that.
+if ((result = ec_transaction(MSI_EC_COMMAND_LCD_LEVEL, wdata, 1,
rdata, 1)) 0)
+return result;
Please split this into two lines.
result = ...;
if (result.)
Will do.
+static DEVICE_ATTR(bluetooth, 0444, show_bluetooth, NULL);
+static DEVICE_ATTR(wlan, 0444, show_wlan, NULL);
So bluetooth and wlan basically mirror physical switch state? Should
we make these switches available through input subsystem one day?
Yes. Actually I've already been discussing with Ivo how to extend the
rfkill API to tell userspace whether an rfkill device is actually for
Bluetooth, for wlan, for uwb and so on. I will update my S270 code as
soon as rfkill enters the kernel to support this new API properly. The
driver will then register two rfkill devices, one for Bluetooth and
one for WLAN.
Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] ACPI: Correctly recover from a failed S3 attempt
Hi! We have a poorly behaving BIOS that simply returns from its suspend procedure, rather then jumping to the restart routine indicated by the FACS. This appears to Linux as a failed S3 attempt. This would normally succeed, but the sysenter msrs are not restored and the restart fails. It is not clear if this is the only omission, but if the sysenter msrs are manually entered in the debugger, the OS resumes. The attached patch would invoke the register restore function on failure. This has absolutely no effect on correct systems, and, does the right thing for failed or stupid BIOSes, at least as far as I am concerned. Can we get fixed bios, too? What machines are affected? --- a/arch/i386/kernel/acpi/wakeup.S +++ b/arch/i386/kernel/acpi/wakeup.S @@ -292,7 +292,10 @@ ENTRY(do_suspend_lowlevel) pushl $3 callacpi_enter_sleep_state addl$4, %esp - ret + +#In case of S3 failure, we'll emerge here. Jump +#to ret_point to recover + jmp ret_point .p2align 4,,7 %esp manipulation is now unneccessary? Can we somehow propagate the error condition? Why jmp when ret_point is next instruction? ret_point: callrestore_registers -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
DSDT/ASL compiler error
Wondering if any ASL experts can help me here. I'm trying to recompile
the DSDT on my HP NC6400 laptop, to hopefully get some better acpi
functionality, and I'm seeing the following error:
$ iasl -tc dsdt.dsl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060608 [Jun 29 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a
dsdt.dsl 3275: And (Local1, 0x)
Warning 1104 -Result is not used, operator has no effect ^
dsdt.dsl 4672: Method (_DSM, 4, NotSerialized)
Warning 1086 -^ Not all control paths return a
value (_DSM)
dsdt.dsl 4672: Method (_DSM, 4, NotSerialized)
Warning 1079 -^ Reserved method must return a
value (_DSM)
dsdt.dsl 12767: CreateByteField (C1D3,
\_SB.C002.C003._X0F._LEN, C08F)
Error4062 - Object does not exist ^
(\_SB.C002.C003._X0F._LEN)
ASL Input: dsdt.dsl - 13280 lines, 478523 bytes, 6207 keywords
Compilation complete. 1 Errors, 3 Warnings, 0 Remarks, 2052 Optimizations
The relevent section around line 12767 is this:
Device (\_SB.C002.C003.C334)
{
Name (_HID, EisaId (PNP0C02))
Name (_UID, 0x02)
Name (\_SB.C002.C003.C1D3, ResourceTemplate ()
{
IO (Decode16,
0x0010, // Range Minimum
0x0010, // Range Maximum
0x01, // Alignment
0x10, // Length
)
[... skipping some defs ..]
IO (Decode16,
0x00A4, // Range Minimum
0x00A4, // Range Maximum
0x01, // Alignment
0x1A, // Length
)
IO (Decode16,
0x0500, // Range Minimum
0x0500, // Range Maximum
0x01, // Alignment
0x80, // Length
_X0F)
IO (Decode16,
0x0800, // Range Minimum
0x0800, // Range Maximum
0x01, // Alignment
0x10, // Length
)
Memory32Fixed (ReadOnly,
0xFFB0, // Address Base
0x0010, // Address Length
)
Memory32Fixed (ReadOnly,
0xFFF0, // Address Base
0x0010, // Address Length
)
})
Method (_CRS, 0, NotSerialized)
{
If (LEqual (\_SB.C002.C003.C1FC._STA (), 0x0F))
{
CreateByteField (C1D3, \_SB.C002.C003.C1D3._X0F._LEN,
C08F)
Store (0x60, C08F)
}
Return (^^C1AD.C1D2 ())
}
}
What suggestions does anyone have on fixing this?
Thanks,
BB
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
