You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(200) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(162) |
Feb
(338) |
Mar
(493) |
Apr
(706) |
May
(729) |
Jun
(316) |
Jul
(435) |
Aug
(325) |
Sep
(355) |
Oct
(314) |
Nov
(336) |
Dec
(330) |
2003 |
Jan
(320) |
Feb
(387) |
Mar
(362) |
Apr
(216) |
May
(391) |
Jun
(292) |
Jul
(369) |
Aug
(334) |
Sep
(429) |
Oct
(339) |
Nov
(340) |
Dec
(344) |
2004 |
Jan
(641) |
Feb
(611) |
Mar
(603) |
Apr
(308) |
May
(321) |
Jun
(355) |
Jul
(291) |
Aug
(508) |
Sep
(482) |
Oct
(490) |
Nov
(574) |
Dec
(408) |
2005 |
Jan
(568) |
Feb
(500) |
Mar
(485) |
Apr
(357) |
May
(219) |
Jun
(370) |
Jul
(336) |
Aug
(300) |
Sep
(388) |
Oct
(257) |
Nov
(298) |
Dec
(313) |
2006 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Karl H. B. <kar...@gm...> - 2005-12-21 08:39:32
|
Hi Shaohua, tried 2.6.15rc6 with patch found in: http://bugzilla.kernel.org/show_bug.cgi?id=3D5165 This fixes the slow bootup problem and allows me to remove the idle=3Dhal= t option. However, the suspend/resume results are sadly the same. Karl. |
From: Jaco K. <ja...@cs...> - 2005-12-21 06:44:07
|
Hello all, I'm having some trouble with suspend/resume on my Toshiba Satellite P10 and was wondering whether anybody would be able to assist. The omnibook module makes some functionality (like the multimedia keys, temperature readings, LCD and FAN adjustments) available. It however does not help with suspend/resume at all. It seems like the notebook only supports standby and suspend to ram. It seems to come out of standby almost immediately and never come out of suspend to ram. Running hibernate-ram -n works fine, but when running it without -n it actually suspends to RAM, hdd spins down, network goes down, CPU fans stop and the power led turns red (instead of the normal blue - this is in accordance with what I've seen with Windows). When it's time again to resume however, it just does nothing and I need to power-cycle the machine to get it usable again. I've proceeded to make a copy of /proc/acpi/dsdt into ~/dsdt.dat and decompiled that using iasl. Upon recompiling (without making modifications) this rendered 17 errors and 3 warnings. One of the warnings being about _WAK not returning a value - which I've changed to always return a packet containing two zeroes (not a fix but rather a workaround). There were also some access errors where changing AnyAcc to ByteAcc solved 3 of the errors. I unfortunately have no idea how to solve the other errors, most of which are 'Error 1094 - Missing ResourceSource string (required)'. I've read somewhere that these strings are in fact optional. Is this a bug in the iasl compiler? An example of such a block: DWordMemory (ResourceProducer, SubDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Address Space Granularity 0x000A0000, // Address Range Minimum 0x000BFFFF, // Address Range Maximum 0x00000000, // Address Translation Offset 0x00020000, 0x00,, , AddressRangeMemory, TypeStatic) This is inside a block ' Name (RSRC, ResourceTemplate () { ... many of the above blocks here }) I suspect this is resource specifications, in this particular case, the VGA BIOS video memory used by vesa if I'm not mistaken. The other error that I receive is 'Error 1013 - Method local variable is not initialized (Local1)'. In this case I guess I can just initialize it to 0 and get it over with? There are also two warnings 'Warning 2019 - Not all control paths return a value' for methods SLLB and PBGU. Looking at these methods they indeed look dodgy. The SLLB function looks like: Method (SLLB, 1, NotSerialized) { Store (Arg0, Local0) And (Local0, 0xFF, Local0) If (LLess (Arg0, 0x0100)) { Return (Z00B) } Else { Store (Local0, Z00B) } } This means that when SLLB gets called with an argument less that 0x0100 then a value will be returned, but if not we store the value passed in the argument anded with 0xFF. For optimization - shouldn't this calculation be moved into the Else part, also, should both cases return Z00B, in which case the If can be rewritten to a > 0xFF and both Stores and the And inside that with the Return after the If. The second case is less clear: Method (PBGU, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (BGU1) } If (LEqual (Arg0, 0x01)) { Return (Z00C) } If (LEqual (Arg0, 0x02)) { Store (0x00, ZOOC) Return (Z00C) } } This case is less clear. If we can assume that values will always be in the range [0-2] then it's possible to simply remove the last If statement and just put it's contents there. Any and all advice appreciated. I could not locate these methods in the ACPI spec so I'm suspecting that they are being used internally and does not form part of the ACPI spec. Thank, -- Jaco Kroon Support Engineer CSS TIRISANO Computer Systems (Pty) Ltd Tel: +27 12 621 3171 Fax: +27 12 661 4984 Cell: +27 84 515 8255 Notice: This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender by email or by phone to the listed number. Any unauthorised use, alteration or dissemination is prohibited. CSS Tirisano (Pty) Ltd accepts no liability for any direct, indirect or consequential loss or damages, arising from the contents of this message. |
From: Brown, L. <len...@in...> - 2005-12-21 03:52:22
|
applied to acpi-test thanks, -Len=20 |
From: Dirk M. <dmu...@su...> - 2005-12-21 03:46:56
|
Hi, it seems to me the return values of cpu_has_cpufreq in processor_thermal.c are reversed. all callers check for if(!cpu_has_cpufreq()) return -ENODEV, which indicates that it expects a return value of 0 for error, and nonzero for success. However the current implementation gets that reversed. the patch below fixes it. Spotted by Thomas Renninger, and fixes the ACPI thermal code never actually speedstepping the CPU when it overheats. Signed-off-by: Thomas Renninger <tr...@su...> Signed-off-by: Dirk Mueller <dmu...@su...> --- processor_thermal.c.orig 2005-12-21 00:18:06.000000000 +0100 +++ processor_thermal.c 2005-12-21 00:18:23.000000000 +0100 @@ -102,8 +102,8 @@ static int cpu_has_cpufreq(unsigned int { struct cpufreq_policy policy; if (!acpi_thermal_cpufreq_is_init || cpufreq_get_policy(&policy, cpu)) - return -ENODEV; - return 0; + return 0; + return 1; } static int acpi_thermal_cpufreq_increase(unsigned int cpu) |
From: Brown, L. <len...@in...> - 2005-12-21 03:29:10
|
Applied. (note that x86_64 includes CONFIG_X86, so this changes IA64 only) thanks, -Len >-----Original Message----- >From: Kenji Kaneshige [mailto:kan...@jp...] >Sent: Tuesday, December 20, 2005 10:24 PM >To: Brown, Len; Andrew Morton; acp...@li... >Subject: [PATCH][RESEND] ACPI EC driver on IA64 > >Hi, > >This is the resend of the patch I posted before at > > http://sourceforge.net/mailarchive/message.php?msg_id=14090410 > >Please apply. > >Thanks, >Kenji Kaneshige > > >This patch removes "depends on X86" from config ACPI_EC. With this >patch, ACPI EC driver will be built also on x86_64 and ia64. > >Signed-off-by: Kenji Kaneshige <kan...@jp...> > > drivers/acpi/Kconfig | 1 - > 1 files changed, 1 deletion(-) > >Index: linux-2.6.15-rc6/drivers/acpi/Kconfig >=================================================================== >--- linux-2.6.15-rc6.orig/drivers/acpi/Kconfig >+++ linux-2.6.15-rc6/drivers/acpi/Kconfig >@@ -269,7 +269,6 @@ config ACPI_DEBUG > > config ACPI_EC > bool >- depends on X86 > default y > help > This driver is required on some systems for the >proper operation of > |
From: Kenji K. <kan...@jp...> - 2005-12-21 03:25:18
|
Hi, This is the resend of the patch I posted before at http://sourceforge.net/mailarchive/message.php?msg_id=14090410 Please apply. Thanks, Kenji Kaneshige This patch removes "depends on X86" from config ACPI_EC. With this patch, ACPI EC driver will be built also on x86_64 and ia64. Signed-off-by: Kenji Kaneshige <kan...@jp...> drivers/acpi/Kconfig | 1 - 1 files changed, 1 deletion(-) Index: linux-2.6.15-rc6/drivers/acpi/Kconfig =================================================================== --- linux-2.6.15-rc6.orig/drivers/acpi/Kconfig +++ linux-2.6.15-rc6/drivers/acpi/Kconfig @@ -269,7 +269,6 @@ config ACPI_DEBUG config ACPI_EC bool - depends on X86 default y help This driver is required on some systems for the proper operation of |
From: Randy.Dunlap <rd...@xe...> - 2005-12-21 03:18:06
|
From: Randy Dunlap <ran...@li...> Convert the callers of local acpi_path_name() functions to use the exported version of it. Signed-off-by: Randy Dunlap <ran...@li...> --- drivers/pci/hotplug/pciehprm_acpi.c | 63 ++++++++++++++++++++---------------- drivers/pci/hotplug/shpchprm_acpi.c | 49 ++++++++++++++-------------- 2 files changed, 60 insertions(+), 52 deletions(-) --- linux-2615-rc6-acpi.orig/drivers/pci/hotplug/pciehprm_acpi.c +++ linux-2615-rc6-acpi/drivers/pci/hotplug/pciehprm_acpi.c @@ -38,21 +38,6 @@ #define METHOD_NAME__HPP "_HPP" #define METHOD_NAME_OSHP "OSHP" -static u8 * acpi_path_name( acpi_handle handle) -{ - acpi_status status; - static u8 path_name[ACPI_PATHNAME_MAX]; - struct acpi_buffer ret_buf = { ACPI_PATHNAME_MAX, path_name }; - - memset(path_name, 0, sizeof (path_name)); - status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); - - if (ACPI_FAILURE(status)) - return NULL; - else - return path_name; -} - static acpi_status acpi_run_hpp(acpi_handle handle, struct hotplug_params *hpp) { @@ -60,8 +45,14 @@ acpi_run_hpp(acpi_handle handle, struct u8 nui[4]; struct acpi_buffer ret_buf = { 0, NULL}; union acpi_object *ext_obj, *package; - u8 *path_name = acpi_path_name(handle); int i, len = 0; + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname; + + if (acpi_path_name(handle, &namebuf)) + pathname = NULL; + else + pathname = namebuf.pointer; /* get _hpp */ status = acpi_evaluate_object(handle, METHOD_NAME__HPP, NULL, &ret_buf); @@ -70,7 +61,8 @@ acpi_run_hpp(acpi_handle handle, struct ret_buf.pointer = kmalloc (ret_buf.length, GFP_KERNEL); if (!ret_buf.pointer) { err ("%s:%s alloc for _HPP fail\n", __FUNCTION__, - path_name); + pathname); + acpi_os_free(namebuf.pointer); return AE_NO_MEMORY; } status = acpi_evaluate_object(handle, METHOD_NAME__HPP, @@ -80,7 +72,8 @@ acpi_run_hpp(acpi_handle handle, struct default: if (ACPI_FAILURE(status)) { dbg("%s:%s _HPP fail=0x%x\n", __FUNCTION__, - path_name, status); + pathname, status); + acpi_os_free(namebuf.pointer); return status; } } @@ -88,7 +81,7 @@ acpi_run_hpp(acpi_handle handle, struct ext_obj = (union acpi_object *) ret_buf.pointer; if (ext_obj->type != ACPI_TYPE_PACKAGE) { err ("%s:%s _HPP obj not a package\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -103,7 +96,7 @@ acpi_run_hpp(acpi_handle handle, struct break; default: err ("%s:%s _HPP obj type incorrect\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -120,23 +113,31 @@ acpi_run_hpp(acpi_handle handle, struct dbg(" _HPP: enable PERR =0x%x\n", hpp->enable_perr); free_and_return: - kfree(ret_buf.pointer); + acpi_os_free(ret_buf.pointer); + acpi_os_free(namebuf.pointer); return status; } static acpi_status acpi_run_oshp(acpi_handle handle) { acpi_status status; - u8 *path_name = acpi_path_name(handle); + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname; + + if (acpi_path_name(handle, &namebuf)) + pathname = NULL; + else + pathname = namebuf.pointer; /* run OSHP */ status = acpi_evaluate_object(handle, METHOD_NAME_OSHP, NULL, NULL); if (ACPI_FAILURE(status)) { - dbg("%s:%s OSHP fails=0x%x\n", __FUNCTION__, path_name, + dbg("%s:%s OSHP fails=0x%x\n", __FUNCTION__, pathname, status); } else { - dbg("%s:%s OSHP passes\n", __FUNCTION__, path_name); + dbg("%s:%s OSHP passes\n", __FUNCTION__, pathname); } + acpi_os_free(namebuf.pointer); return status; } @@ -174,7 +175,10 @@ int pciehp_get_hp_hw_control_from_firmwa acpi_status status; acpi_handle chandle, handle = DEVICE_ACPI_HANDLE(&(dev->dev)); struct pci_dev *pdev = dev; - u8 *path_name; + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + acpi_status namests; + char *pathname; + /* * Per PCI firmware specification, we should run the ACPI _OSC * method to get control of hotplug hardware before using it. @@ -204,17 +208,20 @@ int pciehp_get_hp_hw_control_from_firmwa } while (handle) { - path_name = acpi_path_name(handle); - dbg("Trying to get hotplug control for %s \n", path_name); + namests = acpi_path_name(handle, &namebuf); + pathname = namests ? NULL : namebuf.pointer; + dbg("Trying to get hotplug control for %s\n", pathname); status = pci_osc_control_set(handle, OSC_PCI_EXPRESS_NATIVE_HP_CONTROL); if (status == AE_NOT_FOUND) status = acpi_run_oshp(handle); if (ACPI_SUCCESS(status)) { dbg("Gained control for hotplug HW for pci %s (%s)\n", - pci_name(dev), path_name); + pci_name(dev), pathname); + acpi_os_free(namebuf.pointer); return 0; } + acpi_os_free(namebuf.pointer); if (is_root_bridge(handle)) break; chandle = handle; --- linux-2615-rc6-acpi.orig/drivers/pci/hotplug/shpchprm_acpi.c +++ linux-2615-rc6-acpi/drivers/pci/hotplug/shpchprm_acpi.c @@ -37,21 +37,6 @@ #define METHOD_NAME__HPP "_HPP" #define METHOD_NAME_OSHP "OSHP" -static u8 * acpi_path_name( acpi_handle handle) -{ - acpi_status status; - static u8 path_name[ACPI_PATHNAME_MAX]; - struct acpi_buffer ret_buf = { ACPI_PATHNAME_MAX, path_name }; - - memset(path_name, 0, sizeof (path_name)); - status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); - - if (ACPI_FAILURE(status)) - return NULL; - else - return path_name; -} - static acpi_status acpi_run_hpp(acpi_handle handle, struct hotplug_params *hpp) { @@ -59,8 +44,14 @@ acpi_run_hpp(acpi_handle handle, struct u8 nui[4]; struct acpi_buffer ret_buf = { 0, NULL}; union acpi_object *ext_obj, *package; - u8 *path_name = acpi_path_name(handle); int i, len = 0; + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname; + + if (acpi_path_name(handle, &namebuf)) + pathname = NULL; + else + pathname = namebuf.pointer; /* get _hpp */ status = acpi_evaluate_object(handle, METHOD_NAME__HPP, NULL, &ret_buf); @@ -69,7 +60,8 @@ acpi_run_hpp(acpi_handle handle, struct ret_buf.pointer = kmalloc (ret_buf.length, GFP_KERNEL); if (!ret_buf.pointer) { err ("%s:%s alloc for _HPP fail\n", __FUNCTION__, - path_name); + pathname); + acpi_os_free(namebuf.pointer); return AE_NO_MEMORY; } status = acpi_evaluate_object(handle, METHOD_NAME__HPP, @@ -79,7 +71,8 @@ acpi_run_hpp(acpi_handle handle, struct default: if (ACPI_FAILURE(status)) { dbg("%s:%s _HPP fail=0x%x\n", __FUNCTION__, - path_name, status); + pathname, status); + acpi_os_free(namebuf.pointer); return status; } } @@ -87,7 +80,7 @@ acpi_run_hpp(acpi_handle handle, struct ext_obj = (union acpi_object *) ret_buf.pointer; if (ext_obj->type != ACPI_TYPE_PACKAGE) { err ("%s:%s _HPP obj not a package\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -102,7 +95,7 @@ acpi_run_hpp(acpi_handle handle, struct break; default: err ("%s:%s _HPP obj type incorrect\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -119,23 +112,31 @@ acpi_run_hpp(acpi_handle handle, struct dbg(" _HPP: enable PERR =0x%x\n", hpp->enable_perr); free_and_return: - kfree(ret_buf.pointer); + acpi_os_free(ret_buf.pointer); + acpi_os_free(namebuf.pointer); return status; } static void acpi_run_oshp(acpi_handle handle) { acpi_status status; - u8 *path_name = acpi_path_name(handle); + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname; + + if (acpi_path_name(handle, &namebuf)) + pathname = NULL; + else + pathname = namebuf.pointer; /* run OSHP */ status = acpi_evaluate_object(handle, METHOD_NAME_OSHP, NULL, NULL); if (ACPI_FAILURE(status)) { - err("%s:%s OSHP fails=0x%x\n", __FUNCTION__, path_name, + err("%s:%s OSHP fails=0x%x\n", __FUNCTION__, pathname, status); } else { - dbg("%s:%s OSHP passes\n", __FUNCTION__, path_name); + dbg("%s:%s OSHP passes\n", __FUNCTION__, pathname); } + acpi_os_free(namebuf.pointer); } int shpchprm_get_physical_slot_number(struct controller *ctrl, u32 *sun, u8 busnum, u8 devnum) --- |
From: Randy.Dunlap <rd...@xe...> - 2005-12-21 03:18:01
|
From: Randy Dunlap <ran...@li...> Make acpi_path_name() usable by everyone. I need this for adding SATA suspend/resume ACPI support. Signed-off-by: Randy Dunlap <ran...@li...> --- drivers/acpi/osl.c | 21 +++++++++++++++++++++ include/acpi/acpiosxf.h | 2 ++ 2 files changed, 23 insertions(+) --- linux-2615-rc6-acpi.orig/drivers/acpi/osl.c +++ linux-2615-rc6-acpi/drivers/acpi/osl.c @@ -1078,6 +1078,27 @@ void acpi_os_release_lock(acpi_handle ha spin_unlock_irqrestore((spinlock_t *) handle, flags); } +/** + * acpi_path_name - get ACPI path_name for the given handle + * @handle: ACPI object handle to look up name of + * @namebuf: acpi_buffer with input flags and output name + * + * Caller can allocate & free the output name buffer or can set + * namebuf.length to ACPI_ALLOCATE_BUFFER to have ACPI-CA allocate + * the buffer but caller is still responsible for freeing it. + * + * Returns: status of acpi_get_name() + */ +acpi_status acpi_path_name(acpi_handle handle, struct acpi_buffer *namebuf) +{ + acpi_status status; + + status = acpi_get_name(handle, ACPI_FULL_PATHNAME, namebuf); + + return_ACPI_STATUS(status); +} +EXPORT_SYMBOL_GPL(acpi_path_name); + #ifndef ACPI_USE_LOCAL_CACHE /******************************************************************************* --- linux-2615-rc6-acpi.orig/include/acpi/acpiosxf.h +++ linux-2615-rc6-acpi/include/acpi/acpiosxf.h @@ -112,6 +112,8 @@ unsigned long acpi_os_acquire_lock(acpi_ void acpi_os_release_lock(acpi_handle handle, unsigned long flags); +acpi_status acpi_path_name(acpi_handle handle, struct acpi_buffer *namebuf); + /* * Memory allocation and mapping */ --- |
From: <in...@dd...> - 2005-12-20 19:34:48
|
$B:#2s!"@?$K>!<j$J$4O"Mm$r$5$;$FD:$-$^$7$F?=$7Lu$"$j$^$;$s!#(B $B"(%$%Y%s%H!ZL)2q![$N6aF|3+:E7hDj$N$4Js9p5Z$S!"(B $B$=$l$KH<$$$^$7$F!"CK@-MM!&=w@-MM$N8BDjOH$,ITB-$7$F$$$k$?$a(B $B5^Jg0MMj$N$*CN$i$;$G8f:B$$$^$9!#(B $B"(%$%Y%s%H$O4{$K!"M=Dj8BDj?M?t$K$F3FCO0h3+:EM=Dj2q>l$r(B $B%T%C%/%"%C%W!TCK@-(B13$BL>MM!&=w@-(B8$BL>MM!U$N?M?tITB-$H$$$&8=>u(B $B$K$"$j$^$9!#!!Cm(B)$B3FCO0hITB-?M?t$O0[$J$j$^$9!*(B $B$D$-$^$7$F$O!"5.J}MM$K:#2s$N$40FFbFbMF$K$4F10UD:$1$kMM$G$"(B $B$l$P!ZL)2q![$K$4;22C$rD:$-$?$/!"%$%Y%s%H3+:E9pCN$H$$$&7A$G$N(B $B$4O"Mm$H$5$;$FD:$$$F$*$j$^$9!#(B $B"!$4;?F1$44uK>$O$3$A$i"-(B http://www.f-day1.net/?sex $B!ZL)2q![$N%W%m%0%i%`$O0J2<$NMM$K$J$j$^$9!#(B $B!|FH?H=w@-(B20$BBeA0H>!A(B35$B:MKx$N=w@-MMJ}$H$N8D<<$*?);v2q(B $B!JCK@-MM(B3$BL>!?=w@-MM(B4$BL>!K(B $B!|$*?);v8e(B30$BJ,4V$N%U%j!<%?%$%`@)(B $B!|CK=w(B1$BBP(B1$B$N%+%C%W%k$K@.$i$l$^$7$FJL<<$X0\F0(B $B!!:#8eMM!9$J$*LsB+$r$*<h<!$.2<$5$$!#(B $B"($3$N:]CK=w%+%C%W%k$K@.$j$=$S$l$k;v$O7h$7$FL5$$MM<jG[$r$5(B $B$;$FD:$-$^$9(B $B!|$*Aj<j=w@-MM$h$j!"#S#E#X$*Aj<j$H$7$F7@Ls@.N)$N:]$O5.J}MM(B $B!!$X$N<UNi6b$rL5>r7o$K$F$*<u$1<h$j2DG=$H$J$C$F$*$j$^$9!#(B $B!!(B $B"(5.J}MM$X$N<UNi6b$O!"=w@-MM$,5.J}MM$X46<U$N5$;}$A$GD>@\5.J}(B $BMM$X$*EO$7$9$k$N$G5.J}MM$,A43[<u$1<h$l$^$9!#(B $B:#2s>/?t?M?t8BDj$N$41~Jg$K$J$C$F$$$^$9$N$GDj0w?t$r%*!<%P!<$5(B $B$l$^$9$H$4;?F1$7$F$$$?$@$1$^$7$F$b!ZL)2q![$K$4;22CD:$1$J$$>l(B $B9g$b8f:B$$$^$9$N$GM=$a$4N;>5$/$@$5$$$^$9MM$*4j$$$$$?$7$^$9!#(B $B$=$N:]$O!ZL)2q![$HF1MM$J%$%Y%s%H$K!Z:GM%@h![$G$4;22C2DG=$J(B $B<jB3$-$r<h$i$;$F$$$?$@$-$^$9!#(B http://www.f-day1.net/?sex -------------------------------------------- $BG[?.5qH]$r4uK>$NJ}$O$3$A$i$^$G$*4j$$$7$^$9!#(B $B!!(Bs...@f-... |
From: MAILER D. <> - 2005-12-20 16:54:53
|
QUxBUk1BIERFIEVTVEUgTk9NQlJFIERFIEFSQ0hJVk8NCg0KWW91ciBtZXNz YWdlIHRvOiBtZGVscmlvQHVkZW0uZWR1Lm14DQpGdWUgYmxvcXVlYWRvIHBv ciBlbCBzZXJ2aWRvciBkZSBzcGFtLiBFbCBtYWlsIHF1ZSB1c3RlZCBlbnZp byBjb24gbG8gc2lndWllbnRlIE5PIFNFIEEgRU5UUkVHQURPOg0KDQpTdWJq ZWN0OiBSZTogRGVsaXZlcnkgU2VydmVyDQoNCkFuIGF0dGFjaG1lbnQgaW4g dGhhdCBtYWlsIHdhcyBvZiBhIGZpbGUgdHlwZSB0aGF0IHRoZSBTcGFtIEZp cmV3YWxsIGlzIHNldCB0byBibG9jay4NCg0KDQoK |
From: Yu, L. <lum...@in...> - 2005-12-20 07:27:50
|
I just replace spin_lock_irq_xx with mutex for poll code path of ec = driver. It is at http://bugzilla.kernel.org/show_bug.cgi?id=3D5764 . For issues observerd on Smart Battery driver with ec_intr=3D1 (aka = "ec_burst=3D1") , we need to follow up. =20 Please try to kill acpi daemon to see if your problem get resolved? Thanks, Luming >-----Original Message----- >From: acp...@li...=20 >[mailto:acp...@li...] On Behalf Of=20 >Lebedev, Vladimir P >Sent: 2005=C4=EA11=D4=C216=C8=D5 1:39 >To: Rich Townsend; acp...@li... >Cc: Brown, Len; Starikovskiy, Alexey Y >Subject: RE: [ACPI] New Smart Battery release (incl. updated=20 >embedded controller patches) > >Hi Rich, > >I am attaching patch for kernel 2.6.14 with SBS drivers based=20 >on drivers >which were written by you and Bruno Ducrot. > >Also this patch contains your latest updates of embedded controller >(ec.c file) > >Differences to your version include some cleanup, handling of battery >removal/insertion, and non-conflicting operation with ACPI battery and >ac modules.=20 > >All work pretty good on Acer TravelMate 2303LCi. > >If you are interested, apply the patch, set ACPI_SBS configuration >variable (Smart Battery System - bottom of menu) to 'y' or 'm'(modprobe >acpi_sbs will be required in case 'm'), etc. Module acpi_sbs depends on >ACPI_AC, ACPI_BATTERY and I2C. > >Vladimir. > > > >=20 > >=20 > >=20 > >=20 > > >-----Original Message----- >From: acp...@li... >[mailto:acp...@li...] On Behalf Of Rich >Townsend >Sent: Sunday, November 13, 2005 7:14 AM >To: acp...@li... >Subject: [ACPI] New Smart Battery release (incl. updated embedded >controller patches) > > >I'm pleased to announce that, after quite a long period of inactivity, >I've=20 >finally managed to grab enough spare time from the real world to bring >the=20 >SBS-CM (Smart Battery System/Control Method) project up to date. > >Those relying on this project to check their battery status (primarily >on Acer=20 >laptops) can now grab the sbs-cm-20051112 release of SBS-CM from the >Sourceforge=20 >download page: > >https://sourceforge.net/project/showfiles.php?group_id=3D129330 > >In this new release, I haven't made any changes to the DSDT stuff. >However, I've=20 >included new patches for replacing the spinlock mutexing in=20 >the embedded > >controller (EC) driver with semaphore mutexing. In addition to the >kernel 2.6.10=20 >and 2.6.11 patches included in previous releases, I now provide patches >for=20 >2.6.12. 2.6.13 and 2.6.14 kernels. I intend to offer a 2.6.15=20 >patch once >this=20 >kernel version becomes the current version. > >Why are these patches still necessary? Yuming Lu has done some great >work=20 >getting EC burst mode working under Linux; I believe all kernels since >2.6.13=20 >contain the burst mode code by default. Unfortunately, however, burst >mode does=20 >not fix the problems that the spinlock patches were designed to fix. > >To be specific: I have fixed my kernel (2.6.13) with Yuming's most >recent patch=20 >that prevents the boot process from stalling when the EC driver is >loaded.=20 >Booting with burst mode enabled (boot parameter ec_burst=3D1) gets into >immediate=20 >trouble if I have the thermal zone ACPI driver loaded, since=20 >my computer >thinks=20 >the cpu is at 250C. This is indicative that the EC is not working >properly. > >Then, after disabling the thermal zone stuff, my computer boots up OK >but still=20 >shows all the symptoms of lost interrupts. Furthermore, after=20 >10 minutes >of=20 >uptime, I notice that the kacpid task has expended nearly 3 seconds of >CPU time.=20 >This expenditure is wholly due to the EC access, and indicates that for >3=20 >seconds out of 10 minutes, the EC burst code is not interruptible -- >hence the=20 >lost interrupts. > >While I will certainly agree that my own patches are not nearly as >elegant as=20 >the burst mode solution, I must point out that they do not lead to any >lost=20 >interrupts at all -- I don't lose any keypresses, and the kacpid task >doesn't=20 >use up any CPU time. > >I would really appreciate it if those involved in maintaining the EC >code ---=20 >both Yuming and perhaps Len Brown --- could get in touch with me and >help sort=20 >out a way to get EC burst mode working without lost interrupts. When >that's=20 >done, I'll feel much more comfortable about focusing on porting my SBS >stuff to=20 >the HAL, which is where it belongs. > >Best wishes, > >Rich T > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. >Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >Acpi-devel mailing list >Acp...@li... >https://lists.sourceforge.net/lists/listinfo/acpi-devel > |
From: Li, S. <sha...@in...> - 2005-12-20 02:57:14
|
Hi, > >I do have hotplug_cpu configured into my kernel and disabling/enabling >CPUs works just as well in the situation where I did my suspend, s. >below. > >Could it be the setting idle=3Dhalt is causing problems? I need that = (or >max_cstate=3D1 to keep my CPU up to speed) Might be an issue fixed in latest kernel. Please try. Thanks, Shaohua |
From: Randy D. <ran...@li...> - 2005-12-19 21:53:16
|
During a suspend, a user sees: Stopping tasks: ==========| acpi_bus-0201 [57] bus_set_power : Device is not power manageable PM: Entering mem sleep When a user sees this, is there anything that s/he should do? Does this prevent or hinder or harm suspend/resume capabilities? The line number and thread_id are unclear IMO. What thread_id is this? Is there some way that we can get some kind of device info into this message? Thanks, --- ~Randy |
From: Randy D. <ran...@li...> - 2005-12-19 21:19:24
|
On Mon, 19 Dec 2005 14:19:25 -0800 Patrick Mochel <mo...@li...> wrote: > On Mon, Dec 19, 2005 at 11:54:35AM -0800, Randy Dunlap wrote: > > From: Randy Dunlap <ran...@li...> > > > > Make acpi_path_name() usable by everyone. > > I need this for adding SATA suspend/resume ACPI support. > > I liked the first one better, and I think it was more appropriate, > given its users: > > It's a function that is used by code outside of drivers/acpi/, so it > seems that it should use semantics that are common to the rest of the > kernel, and not expose/require any internal data structures than what is > necessary (like struct acpi_buffer). > > It seems like that is the point of the ACPI OSL - to provide functions > that are stylistically and semantically familiar to the rest OS for > which to interface with the ACPICA. In the case of Linux and this > function, that would be more like providing an interface that you did > before - returning a char * that the caller has to free. > > Note that Kristen made an argument that it's a burden on the caller, > and a source for memory leak bugs. That's a valid concern, but there > are many examples of similar interfaces (think strdup(3) or kstrdup()), > and the effects can be mitigated by proper documentation. For the > kernel, one could potentially integrate a check for that type of bad > programming into sparse.. Besides, making the caller understand > enough of the semantics of the ACPICA to initialize and tear down > the acpi_buffer is arguably a much larger burden than knowing you > have to free the string returned.. Thanks for enumerating. These are all things that I considered in making the first patch and most of the reasons that I chose to make that patch as my first choice. I still consider it to be the more appropriate patch than the second version. --- ~Randy |
From: Patrick M. <mo...@li...> - 2005-12-19 21:17:13
|
On Mon, Dec 19, 2005 at 11:54:35AM -0800, Randy Dunlap wrote: > From: Randy Dunlap <ran...@li...> > > Make acpi_path_name() usable by everyone. > I need this for adding SATA suspend/resume ACPI support. I liked the first one better, and I think it was more appropriate, given its users: It's a function that is used by code outside of drivers/acpi/, so it seems that it should use semantics that are common to the rest of the kernel, and not expose/require any internal data structures than what is necessary (like struct acpi_buffer). It seems like that is the point of the ACPI OSL - to provide functions that are stylistically and semantically familiar to the rest OS for which to interface with the ACPICA. In the case of Linux and this function, that would be more like providing an interface that you did before - returning a char * that the caller has to free. Note that Kristen made an argument that it's a burden on the caller, and a source for memory leak bugs. That's a valid concern, but there are many examples of similar interfaces (think strdup(3) or kstrdup()), and the effects can be mitigated by proper documentation. For the kernel, one could potentially integrate a check for that type of bad programming into sparse.. Besides, making the caller understand enough of the semantics of the ACPICA to initialize and tear down the acpi_buffer is arguably a much larger burden than knowing you have to free the string returned.. Thanks, Patrick |
From: Karl H. B. <kar...@gm...> - 2005-12-19 20:52:36
|
Oops, sorry about that ... evolution was playing tricks on me ... Karl. |
From: Kristen A. <kri...@in...> - 2005-12-19 20:42:48
|
On Mon, 2005-12-19 at 11:54 -0800, Randy Dunlap wrote: > From: Randy Dunlap <ran...@li...> > > Make acpi_path_name() usable by everyone. > I need this for adding SATA suspend/resume ACPI support. > > Signed-off-by: Randy Dunlap <ran...@li...> > --- > drivers/acpi/osl.c | 21 +++++++++++++++++++++ > include/acpi/acpiosxf.h | 2 ++ > 2 files changed, 23 insertions(+) > > --- linux-2615-rc6-acpi.orig/drivers/acpi/osl.c > +++ linux-2615-rc6-acpi/drivers/acpi/osl.c > @@ -1078,6 +1078,27 @@ void acpi_os_release_lock(acpi_handle ha > spin_unlock_irqrestore((spinlock_t *) handle, flags); > } > > +/** > + * acpi_path_name - get ACPI path_name for the given handle > + * @handle: ACPI object handle to look up name of > + * @namebuf: acpi_buffer with input flags and output name > + * > + * Caller can allocate & free the output name buffer or can set > + * namebuf.length to ACPI_ALLOCATE_BUFFER to have ACPI-CA allocate > + * the buffer but caller is still responsible for freeing it. > + * > + * Returns: status of acpi_get_name() > + */ > +acpi_status acpi_path_name(acpi_handle handle, struct acpi_buffer *namebuf) > +{ > + acpi_status status; > + > + status = acpi_get_name(handle, ACPI_FULL_PATHNAME, namebuf); > + > + return_ACPI_STATUS(status); > +} > +EXPORT_SYMBOL(acpi_path_name); > + Shouldn't this be EXPORT_SYMBOL_GPL instead? Kristen |
From: Karl H. B. <kar...@gm...> - 2005-12-19 20:35:09
|
Hi Christoph, Shaohua, I do have hotplug_cpu enabled and disabling/enabling cpus works in the same situation as the suspend after which the resume does not. Could my setting of idle=halt be a problem? I need it to work around a boot up problem. Thanks, Karl. |
From: Karl H. B. <kar...@gm...> - 2005-12-19 20:19:16
|
Hi Christoph, Shaohua, I do have hotplug_cpu configured into my kernel and disabling/enabling CPUs works just as well in the situation where I did my suspend, s. below. Could it be the setting idle=halt is causing problems? I need that (or max_cstate=1 to keep my CPU up to speed) ... otherwise I get boottimes of an hour) found a patch that didn't help me, so I sticked to the boot param. Haven't gotten round to testing without the param because it would take a matter of hours to boot and suspend :S Probable cause here? Thanks, Karl. |
From: Karl H. B. <kar...@gm...> - 2005-12-19 19:56:30
|
Am Freitag, den 16.12.2005, 10:12 +0800 schrieb Li, Shaohua: > [...] I think it's yes. > Could you please try the CPU offline and online in the system? > just do > offline: > echo 0 > /sys/devices/system/cpu/cpu1/online > online: > echo 1 > /sys/devices/system/cpu/cpu1/online > please check if the CPU1 is correctly online after that. > > Thanks, > Shaohua > Sure, Script wurde gestartet: Fr 16 Dez 2005 11:57:11 CE root@ubuntu:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping : 9 cpu MHz : 3057.209 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 6119.86 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping : 9 cpu MHz : 3057.209 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 6113.80 root@ubuntu:~# echo 0 > /sys/devices/system/cpu/cpu1/online root@ubuntu:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping : 9 cpu MHz : 3057.209 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 6119.86 root@ubuntu:~# echo 1 > /sys/devices/system/cpu/cpu1/online root@ubuntu:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping : 9 cpu MHz : 3057.209 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 6119.86 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping : 9 cpu MHz : 3057.209 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 6113.86 Seems to work, will try once more in single-user mode with all services stopped and modules unloaded like when I suspended and keep you posted. Karl. |
From: Randy D. <ran...@li...> - 2005-12-19 19:54:23
|
From: Randy Dunlap <ran...@li...> Convert the callers of local acpi_path_name() functions to use the exported version of it. Signed-off-by: Randy Dunlap <ran...@li...> --- drivers/pci/hotplug/pciehprm_acpi.c | 56 ++++++++++++++++++------------------ drivers/pci/hotplug/shpchprm_acpi.c | 43 ++++++++++++--------------- 2 files changed, 47 insertions(+), 52 deletions(-) --- linux-2615-rc6-acpi.orig/drivers/pci/hotplug/pciehprm_acpi.c +++ linux-2615-rc6-acpi/drivers/pci/hotplug/pciehprm_acpi.c @@ -38,21 +38,6 @@ #define METHOD_NAME__HPP "_HPP" #define METHOD_NAME_OSHP "OSHP" -static u8 * acpi_path_name( acpi_handle handle) -{ - acpi_status status; - static u8 path_name[ACPI_PATHNAME_MAX]; - struct acpi_buffer ret_buf = { ACPI_PATHNAME_MAX, path_name }; - - memset(path_name, 0, sizeof (path_name)); - status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); - - if (ACPI_FAILURE(status)) - return NULL; - else - return path_name; -} - static acpi_status acpi_run_hpp(acpi_handle handle, struct hotplug_params *hpp) { @@ -60,8 +45,11 @@ acpi_run_hpp(acpi_handle handle, struct u8 nui[4]; struct acpi_buffer ret_buf = { 0, NULL}; union acpi_object *ext_obj, *package; - u8 *path_name = acpi_path_name(handle); int i, len = 0; + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname = namebuf.pointer; + + acpi_path_name(handle, &namebuf); /* get _hpp */ status = acpi_evaluate_object(handle, METHOD_NAME__HPP, NULL, &ret_buf); @@ -70,7 +58,8 @@ acpi_run_hpp(acpi_handle handle, struct ret_buf.pointer = kmalloc (ret_buf.length, GFP_KERNEL); if (!ret_buf.pointer) { err ("%s:%s alloc for _HPP fail\n", __FUNCTION__, - path_name); + pathname); + acpi_os_free(namebuf.pointer); return AE_NO_MEMORY; } status = acpi_evaluate_object(handle, METHOD_NAME__HPP, @@ -80,7 +69,8 @@ acpi_run_hpp(acpi_handle handle, struct default: if (ACPI_FAILURE(status)) { dbg("%s:%s _HPP fail=0x%x\n", __FUNCTION__, - path_name, status); + pathname, status); + acpi_os_free(namebuf.pointer); return status; } } @@ -88,7 +78,7 @@ acpi_run_hpp(acpi_handle handle, struct ext_obj = (union acpi_object *) ret_buf.pointer; if (ext_obj->type != ACPI_TYPE_PACKAGE) { err ("%s:%s _HPP obj not a package\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -103,7 +93,7 @@ acpi_run_hpp(acpi_handle handle, struct break; default: err ("%s:%s _HPP obj type incorrect\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -120,23 +110,28 @@ acpi_run_hpp(acpi_handle handle, struct dbg(" _HPP: enable PERR =0x%x\n", hpp->enable_perr); free_and_return: - kfree(ret_buf.pointer); + acpi_os_free(ret_buf.pointer); + acpi_os_free(namebuf.pointer); return status; } static acpi_status acpi_run_oshp(acpi_handle handle) { acpi_status status; - u8 *path_name = acpi_path_name(handle); + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname = namebuf.pointer; + + acpi_path_name(handle, &namebuf); /* run OSHP */ status = acpi_evaluate_object(handle, METHOD_NAME_OSHP, NULL, NULL); if (ACPI_FAILURE(status)) { - dbg("%s:%s OSHP fails=0x%x\n", __FUNCTION__, path_name, + dbg("%s:%s OSHP fails=0x%x\n", __FUNCTION__, pathname, status); } else { - dbg("%s:%s OSHP passes\n", __FUNCTION__, path_name); + dbg("%s:%s OSHP passes\n", __FUNCTION__, pathname); } + acpi_os_free(namebuf.pointer); return status; } @@ -174,7 +169,10 @@ int pciehp_get_hp_hw_control_from_firmwa acpi_status status; acpi_handle chandle, handle = DEVICE_ACPI_HANDLE(&(dev->dev)); struct pci_dev *pdev = dev; - u8 *path_name; + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + acpi_status namests; + char *pathname = namebuf.pointer; + /* * Per PCI firmware specification, we should run the ACPI _OSC * method to get control of hotplug hardware before using it. @@ -204,17 +202,19 @@ int pciehp_get_hp_hw_control_from_firmwa } while (handle) { - path_name = acpi_path_name(handle); - dbg("Trying to get hotplug control for %s \n", path_name); + namests = acpi_path_name(handle, &namebuf); + dbg("Trying to get hotplug control for %s\n", pathname); status = pci_osc_control_set(handle, OSC_PCI_EXPRESS_NATIVE_HP_CONTROL); if (status == AE_NOT_FOUND) status = acpi_run_oshp(handle); if (ACPI_SUCCESS(status)) { dbg("Gained control for hotplug HW for pci %s (%s)\n", - pci_name(dev), path_name); + pci_name(dev), pathname); + acpi_os_free(namebuf.pointer); return 0; } + acpi_os_free(namebuf.pointer); if (is_root_bridge(handle)) break; chandle = handle; --- linux-2615-rc6-acpi.orig/drivers/pci/hotplug/shpchprm_acpi.c +++ linux-2615-rc6-acpi/drivers/pci/hotplug/shpchprm_acpi.c @@ -37,21 +37,6 @@ #define METHOD_NAME__HPP "_HPP" #define METHOD_NAME_OSHP "OSHP" -static u8 * acpi_path_name( acpi_handle handle) -{ - acpi_status status; - static u8 path_name[ACPI_PATHNAME_MAX]; - struct acpi_buffer ret_buf = { ACPI_PATHNAME_MAX, path_name }; - - memset(path_name, 0, sizeof (path_name)); - status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); - - if (ACPI_FAILURE(status)) - return NULL; - else - return path_name; -} - static acpi_status acpi_run_hpp(acpi_handle handle, struct hotplug_params *hpp) { @@ -59,8 +44,11 @@ acpi_run_hpp(acpi_handle handle, struct u8 nui[4]; struct acpi_buffer ret_buf = { 0, NULL}; union acpi_object *ext_obj, *package; - u8 *path_name = acpi_path_name(handle); int i, len = 0; + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname = namebuf.pointer; + + acpi_path_name(handle, &namebuf); /* get _hpp */ status = acpi_evaluate_object(handle, METHOD_NAME__HPP, NULL, &ret_buf); @@ -69,7 +57,8 @@ acpi_run_hpp(acpi_handle handle, struct ret_buf.pointer = kmalloc (ret_buf.length, GFP_KERNEL); if (!ret_buf.pointer) { err ("%s:%s alloc for _HPP fail\n", __FUNCTION__, - path_name); + pathname); + acpi_os_free(namebuf.pointer); return AE_NO_MEMORY; } status = acpi_evaluate_object(handle, METHOD_NAME__HPP, @@ -79,7 +68,8 @@ acpi_run_hpp(acpi_handle handle, struct default: if (ACPI_FAILURE(status)) { dbg("%s:%s _HPP fail=0x%x\n", __FUNCTION__, - path_name, status); + pathname, status); + acpi_os_free(namebuf.pointer); return status; } } @@ -87,7 +77,7 @@ acpi_run_hpp(acpi_handle handle, struct ext_obj = (union acpi_object *) ret_buf.pointer; if (ext_obj->type != ACPI_TYPE_PACKAGE) { err ("%s:%s _HPP obj not a package\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -102,7 +92,7 @@ acpi_run_hpp(acpi_handle handle, struct break; default: err ("%s:%s _HPP obj type incorrect\n", __FUNCTION__, - path_name); + pathname); status = AE_ERROR; goto free_and_return; } @@ -119,23 +109,28 @@ acpi_run_hpp(acpi_handle handle, struct dbg(" _HPP: enable PERR =0x%x\n", hpp->enable_perr); free_and_return: - kfree(ret_buf.pointer); + acpi_os_free(ret_buf.pointer); + acpi_os_free(namebuf.pointer); return status; } static void acpi_run_oshp(acpi_handle handle) { acpi_status status; - u8 *path_name = acpi_path_name(handle); + struct acpi_buffer namebuf = {ACPI_ALLOCATE_BUFFER, NULL}; + char *pathname = namebuf.pointer; + + acpi_path_name(handle, &namebuf); /* run OSHP */ status = acpi_evaluate_object(handle, METHOD_NAME_OSHP, NULL, NULL); if (ACPI_FAILURE(status)) { - err("%s:%s OSHP fails=0x%x\n", __FUNCTION__, path_name, + err("%s:%s OSHP fails=0x%x\n", __FUNCTION__, pathname, status); } else { - dbg("%s:%s OSHP passes\n", __FUNCTION__, path_name); + dbg("%s:%s OSHP passes\n", __FUNCTION__, pathname); } + acpi_os_free(namebuf.pointer); } int shpchprm_get_physical_slot_number(struct controller *ctrl, u32 *sun, u8 busnum, u8 devnum) --- |
From: Randy D. <ran...@li...> - 2005-12-19 19:54:19
|
From: Randy Dunlap <ran...@li...> Make acpi_path_name() usable by everyone. I need this for adding SATA suspend/resume ACPI support. Signed-off-by: Randy Dunlap <ran...@li...> --- drivers/acpi/osl.c | 21 +++++++++++++++++++++ include/acpi/acpiosxf.h | 2 ++ 2 files changed, 23 insertions(+) --- linux-2615-rc6-acpi.orig/drivers/acpi/osl.c +++ linux-2615-rc6-acpi/drivers/acpi/osl.c @@ -1078,6 +1078,27 @@ void acpi_os_release_lock(acpi_handle ha spin_unlock_irqrestore((spinlock_t *) handle, flags); } +/** + * acpi_path_name - get ACPI path_name for the given handle + * @handle: ACPI object handle to look up name of + * @namebuf: acpi_buffer with input flags and output name + * + * Caller can allocate & free the output name buffer or can set + * namebuf.length to ACPI_ALLOCATE_BUFFER to have ACPI-CA allocate + * the buffer but caller is still responsible for freeing it. + * + * Returns: status of acpi_get_name() + */ +acpi_status acpi_path_name(acpi_handle handle, struct acpi_buffer *namebuf) +{ + acpi_status status; + + status = acpi_get_name(handle, ACPI_FULL_PATHNAME, namebuf); + + return_ACPI_STATUS(status); +} +EXPORT_SYMBOL(acpi_path_name); + #ifndef ACPI_USE_LOCAL_CACHE /******************************************************************************* --- linux-2615-rc6-acpi.orig/include/acpi/acpiosxf.h +++ linux-2615-rc6-acpi/include/acpi/acpiosxf.h @@ -112,6 +112,8 @@ unsigned long acpi_os_acquire_lock(acpi_ void acpi_os_release_lock(acpi_handle handle, unsigned long flags); +acpi_status acpi_path_name(acpi_handle handle, struct acpi_buffer *namebuf); + /* * Memory allocation and mapping */ --- |
From: Frittella L. <lau...@re...> - 2005-12-19 16:24:31
|
Hi all, I'm trying to fix my DSDT table on my DELL Latitude D510, using "Linux ACPI Howto" I've fixed some warnings... but how can I fix these? dsdt.dsl 2330: Method (_S0D, 0, NotSerialized) Warning 2096 - Unknown reserved name ^ (_S0D) dsdt.dsl 2396: Method (_S0D, 0, NotSerialized) Warning 2096 - Unknown reserved name ^ (_S0D) dsdt.dsl 2461: Method (_S0D, 0, NotSerialized) Warning 2096 - Unknown reserved name ^ (_S0D) dsdt.dsl 2526: Method (_S0D, 0, NotSerialized) Warning 2096 - Unknown reserved name ^ (_S0D) dsdt.dsl 2591: Method (_S0D, 0, NotSerialized) Warning 2096 - Unknown reserved name ^ (_S0D) dsdt.dsl 3807: Return (Package (0x00) {}) Remark 3069 - Effective AML package length is zero ^ For the first 5 warnings the Method is the same: Method (_S0D, 0, NotSerialized) { Store (SMI (0x85, 0x00), Local0) And (Local0, 0x01, Local0) If (LEqual (Local0, 0x00)) { Return (0x03) } Else { Return (0x00) } } For the last warning the part of interest is: Device (VID2) { Name (_ADR, 0x00020001) Method (_DOS, 1, NotSerialized) { } Method (_DOD, 0, NotSerialized) { Return (Package (0x00) {}) } } Thanks in advance, Frittella Laurento |
From: Dominik B. <li...@do...> - 2005-12-19 00:11:02
|
A few improvements and bugfixes to the ACPI C-States management based on what's already in your dyn-tick patchset: - last_sleep needs to be per-CPU - cx->time for C1-type sleep is meaningless, remove support for it. - Add a fast-path demotion: if dynticks are enabled, we can relax a bit and use a more responsive sleep type if we're going to sleep only for a short period of time (<1 tick), as long as we get back to deep sleep soon (quick_promotion). Signed-off-by: Dominik Brodowski <li...@do...> Index: working-tree/drivers/acpi/processor_idle.c =================================================================== --- working-tree.orig/drivers/acpi/processor_idle.c +++ working-tree/drivers/acpi/processor_idle.c @@ -180,7 +180,6 @@ static void acpi_safe_halt(void) } static atomic_t c3_cpu_count; -static int last_sleep = 0; static void acpi_processor_idle(void) { @@ -277,28 +276,55 @@ static void acpi_processor_idle(void) next_state = cx->demotion.state; if (dyn_tick_enabled()) dyn_early_reprogram(BM_JIFFIES); - last_sleep = 0; /* do not promote in fast-path */ + /* do not promote in fast-path */ + pr->power.last_sleep = 0; goto end; } } /* - * Fast-path promotion: if we slept for more than 2 jiffies the last - * time, and we're intended to sleep for more than 2 jiffies now, - * promote. Note that the processor won't enter a low-power state - * during this call (to this funciton) but should upon the next. + * Some special policy tweaks for dynamic ticks */ if (dyn_tick_enabled()) { + /* + * Fast-path promotion: if we slept for more than 2 jiffies the + * last time, and we're intended to sleep for more than 2 + * jiffies now, promote. Note that the processor won't enter a + * low-power state during this call (to this funciton) but + * should upon the next. + */ if (cx->promotion.state && cx->promotion.count && - (last_sleep > BM_JIFFIES) && + (dyn_tick->next_tick > jiffies) && + ((pr->power.last_sleep > + (BM_JIFFIES * cx->promotion.threshold.ticks)) || + (pr->power.quick_promotion == 1)) && (dyn_tick->skip > BM_JIFFIES)) { local_irq_enable(); next_state = cx->promotion.state; goto end; } + + + /* + * Fast-path demotion: if we're going to sleep for only one + * jiffy, and we'd enter C3-type sleep, and the wakeup latency + * is high, don't use C3-type sleep but (temporarily) C2. + */ + if (cx->demotion.state && cx->demotion.threshold.bm && + (dyn_tick->next_tick < (jiffies + 1)) + && (cx->latency > 150)) { + local_irq_enable(); + next_state = cx->demotion.state; + + /* don't do a fast-path promotion next time... */ + pr->power.last_sleep = 0; + /* ... but thereafter. */ + pr->power.quick_promotion = 2; + goto end; + } } - last_sleep = 0; + pr->power.last_sleep = 0; #ifdef CONFIG_HOTPLUG_CPU /* @@ -411,19 +437,18 @@ static void acpi_processor_idle(void) if (cx->type != ACPI_STATE_C1) { if (sleep_ticks > 0) cx->time += sleep_ticks; - } else { - /* for C1, where we don't know the exact value, assume 0.5 of - * a jiffy */ - cx->time += (PM_TIMER_FREQUENCY / (2 * HZ)); } - last_sleep = sleep_ticks / (PM_TIMER_FREQUENCY / HZ); + pr->power.last_sleep = sleep_ticks / (PM_TIMER_FREQUENCY / HZ); if (pr->flags.bm_check) - pr->power.bm_check_timestamp += last_sleep; + pr->power.bm_check_timestamp += pr->power.last_sleep; next_state = pr->power.state; + if (pr->power.quick_promotion) + pr->power.quick_promotion--; + /* * Promotion? * ---------- Index: working-tree/include/acpi/processor.h =================================================================== --- working-tree.orig/include/acpi/processor.h +++ working-tree/include/acpi/processor.h @@ -61,6 +61,8 @@ struct acpi_processor_power { unsigned long bm_check_timestamp; u32 default_state; u32 bm_activity; + u16 last_sleep; + u16 quick_promotion; int count; struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER]; |
From: Nhung L. <nhu...@ki...> - 2005-12-18 22:01:56
|
=20 http://www.desirire.com =20 C S X V A V M P L i o a A m i e r e A m n L b A r o v L a a i i G i p i i =20 x U e R d e t S =20 =20 M n A i c r =20 =20 =20 =20 =20 =20 a i a =20 =20 =20 =20 =20 =20 =20 a =20 $9 $7 $1 $8 $6 $6 $9 $6 $9 9.95 5.95 23.45 5.45 8.00 9.95 9.95 4.95 9.95 =20 =20 =20 Charles Casset in Washington. Three minutes later the man emerged from the building and walked out on the short narrow pavement. What are you dressed like that for? he asked the messenger who stood by the large automobile, covering the insignia on the rear door. Im the Catholic chaplain, my son. Our military chargC) daffaires would like a word with you. He opened the door. Ill do many things for you people, laughed the driver as he bent down to look inside the limousine, but being drafted into your army isnt one of them. ... Yes, sir, what can I do for you? Where did you take our people? asked the shadowed figure in the backseat, his features in darkness. What people? said the Algerian, sudden concern in his voice. The two you picked up at the airport several hours ago. The cripple |