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: <cma...@cm...> - 2005-12-18 18:53:11
|
Your mail to 'CMake' with the subject hello will be discarded. The reason it is being discarded is: Post by non-member to a members-only list The mailing lists at Kitware all require membership on the list to post. This is to avoid SPAM. If you are not a member on the list, and you post to the list, your message will be discarded. Do not take it personally, we just do not have enough time to approve every email posted to the list. If you have more than one email account, you can subscribe them all to the list, then set all but one of them to nomail from the mailman web GUI. Also, some mailers tend to add a few extra characters to your return address, if you think you have subscribed, but it is still not accepting your email, try sending yourself an email, and then reply to it. Look at the address that you are replying to, and make sure that is the EXACT same address that you subscribed to on the list. You can join the list here: http://public.kitware.com/mailman/listinfo/CMake If the message is too large, it will also be discarded, try putting the large file on a web server and using a link in your message. Bugs can be reported here: http://public.kitware.com/Bug/ |
From: Steven R. <ro...@go...> - 2005-12-18 15:27:08
|
On Tue, 29 Nov 2005, Pavel Machek wrote: > Hi! > > > Description: > > > > This patch creates a directory in /sys/kernel called idle. This > > directory contains two files: idle_ctrl and idle_methods. Reading > > idle_ctrl will show the function that is currently being used for idle, > > and idle_methods shows the available methods for the user to send write > > into idle_ctrl to change which function to use for idle. > > Pretty ugly interface, I'd say... is listing function really neccessary? > What interface would you prefer? And the listing was a feature request made by Ingo. But this is pretty much moot, since the patch is not going any further than the RT patch. And even then, it probably is only temporary, if it is even still in there (I haven't checked). --Steve |
From: Olaf C. <oo...@gm...> - 2005-12-18 15:12:14
|
On 12/9/05, Karasyov, Konstantin A <kon...@in...> wrote: > Hi, > > It looks like your trip points are getting reset on thermal > notifications. > Your DSDT implements hysteresis for passive and active cooling (i.e. > when the temperature raises above the trip point, the trip point value > is decreased to avoid too frequent trip point crossing), so hardware > sends the notification to the system to update the trip points, when the > trip point is being crossed. > > So, it's not a bug, it is a firmware implementation, but your DSDT could > be slightly modified to set higher trip points values: I've started looking into the DSDT to fix various methods, so far just tried to figure out what all methods do. In the mean time I upgraded to kernel 2.6.15-rc4 and most problems disappeared. Still using the original DSDT. During heavy usage cpu temperature rises to 76-78, and never reaches 80. Yesterday I upgraded to kernel 2.6.15-rc5, and during compilation of ndiswrapper, while browsing the internet, it shutdown. If I compile ndiswrapper and don't do anything else, the cpu temp touches 80 briefly, but does not shutdown. Under -rc4 this does not happen. -Olaf |
From: Pavel M. <pa...@uc...> - 2005-12-18 14:24:24
|
Hi! > Description: > > This patch creates a directory in /sys/kernel called idle. This > directory contains two files: idle_ctrl and idle_methods. Reading > idle_ctrl will show the function that is currently being used for idle, > and idle_methods shows the available methods for the user to send write > into idle_ctrl to change which function to use for idle. Pretty ugly interface, I'd say... is listing function really neccessary? Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms |
From: Annika <blu...@ya...> - 2005-12-17 22:18:58
|
SGVsbG8sCgpEbyB5b3Ugd2FudCB0byBsZWFybiBob3cgdG8gc3RhcnQgeW91ciBvd24gZW1waXJl IG9mIHByb2ZpdGFibGUgCiJOaWNoZSBQYXkgUGVyIENsaWNrIFNlYXJjaCBFbmdpbmVzIiBUaGF0 IFBheSBZb3UgRXZlcnkgTW9udGggTGlrZSBDbG9ja3dvcmsgPwoKR28gdG8gdGhpcyBzaXRlIGh0 dHA6Ly9uZXRiaXp6Lml3YXJwLmNvbSBhbmQgY2xpY2sgdGhlIHNwb25zb3JlZCBsaW5rcy4KClNl ZSB5b3UhCgpBbm5pa2EK |
From: Stefan S. <se...@gm...> - 2005-12-17 06:16:27
|
On Mon, Dec 12, 2005 at 04:20:08PM +0100, Pavel Machek wrote: > Hi! > > > when I try setting the alarm to wake up my pc I get the following > > result: > > [root@mithrandir acpi]# cat alarm > > 2005-12-00 17:18:19 > > [root@mithrandir acpi]# > > BTW, nothing happens at the echo'd date/time. Could someone please > > give me a clue where to start looking? I'm running fedora core 4, my > > mobo is an ASUS P5S800-VM, the documentation on the motherboard states > > that ACPI is supported. There is an option to turn acpi 2.0 on, but no > > difference... > > alarm never worked properly, IIRC. i have seen a thinkpad wake up from S3 at the specified alarm time. So it works somehow. Although i was never able to figure out if it was woken up manually or by the alarm. -- Stefan Seyfried |
From: Christoph G. <li...@ch...> - 2005-12-17 00:46:39
|
Hi, i just bought a new Acer Aspire notebook and after installing Gentoo (Vanilla-Kernel 2.6.14.3) I unfortunately noticed that there is nearly no ACPI support (just ac_adapter and buttons afaIk). That's not really sad but I need at least the battery state if I'm away. A "cat" on /proc/acpi/battery/BAT1/state shows me present: yes ERROR: Unable to read battery status /proc/acpi/battery/BAT1/info shows the right information about capacity, model, vendor etc. Are there any common/known issues about ACPI on Acer notebooks? If you need more info, let me know. Thanks in advance. Christoph |
From: Christoph G. <li...@ch...> - 2005-12-17 00:29:42
|
Hi, On 12/16/2005 09:17 PM, Karl H. Beckers wrote: >> Am Freitag, den 16.12.2005, 10:12 +0800 schrieb Li, Shaohua: >> 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. I don't know if it solves your problem, but i had to activate "Support for hot-pluggable CPUs (Experimental)" (CONFIG_HOTPLUG_CPU=y) in kernel to get suspend to disk working with my Pentium 4 HT. Maybe it helps. Christoph |
From: Moore, R. <rob...@in...> - 2005-12-16 21:07:36
|
That is correct, all ACPICA interfaces that require a buffer parameter allow the buffer object to be pre-initialized with a buffer allocated by the caller or allow ACPICA to allocate the buffer. Bob > -----Original Message----- > From: Rolf Eike Beer [mailto:ei...@sf...] > Sent: Friday, December 16, 2005 1:04 PM > To: Accardi, Kristen C > Cc: Randy.Dunlap; Brown, Len; ran...@li...; acpi- > de...@li...; pci...@li...; > gr...@su...; Moore, Robert > Subject: Re: [PATCH 1/2] make acpi_path_name() global >=20 > > On Thu, 2005-12-15 at 21:27 -0800, Randy.Dunlap wrote: > >> On Thu, 15 Dec 2005 23:56:47 -0500 Brown, Len wrote: > > > > <snip> > >> > an example of this is acpi_get_name(), which as declared > >> > isn't supposed to be available outside the core. > >> > All the uses of it to print ACPI namespace tokens in /proc > >> > are totally bogus and should be deleted. The other use > >> > of it is to print out debug strings -- stuff the OS > >> > doesn't really need to "know" and maybe something the > >> > core should do for it. That leaves the hotplug use, > >> > which I don't understand. What does SATA need > >> > with the actual path names? > >> > >> SATA uses the name string for (a) debugging, as you have > >> mentioned, and (b) for comparing complete device strings > >> to match/find a SATA _ADR under a device (in a device's > >> scope). I can do without (a) as well as the rest of the > >> kernel can, of course. I don't know how to find and match > >> SATA devices (part b) without it, so this is an opportunity > >> for you to educate me. :) > >> > >> > > We use this in pciehp and shpchp as well for the same reason. One thing > > I don't love about these patches is the need now to worry about freeing > > memory after you make these calls. To me that seems like asking for > > memory leaks in error paths at some point down the road when someone > > less careful than Randy adds some code in. If there were some way to > > return a pointer to a static string, I'd prefer that solution, but I > > can't figure out from looking at the acpi code if that is possible. If > > there's some better way to perform this compare, I'd like to hear it > > too. >=20 > Don't do the allocation in the function but pass a buffer and it's length > to it. The caller can do dynamic allocation if needed or use a buffer on > stack if not. This also makes error handling easier as ENOMEM can't happen > in acpi_path_name() anymore. >=20 > Eike |
From: Rolf E. B. <ei...@sf...> - 2005-12-16 21:03:44
|
> On Thu, 2005-12-15 at 21:27 -0800, Randy.Dunlap wrote: >> On Thu, 15 Dec 2005 23:56:47 -0500 Brown, Len wrote: > > <snip> >> > an example of this is acpi_get_name(), which as declared >> > isn't supposed to be available outside the core. >> > All the uses of it to print ACPI namespace tokens in /proc >> > are totally bogus and should be deleted. The other use >> > of it is to print out debug strings -- stuff the OS >> > doesn't really need to "know" and maybe something the >> > core should do for it. That leaves the hotplug use, >> > which I don't understand. What does SATA need >> > with the actual path names? >> >> SATA uses the name string for (a) debugging, as you have >> mentioned, and (b) for comparing complete device strings >> to match/find a SATA _ADR under a device (in a device's >> scope). I can do without (a) as well as the rest of the >> kernel can, of course. I don't know how to find and match >> SATA devices (part b) without it, so this is an opportunity >> for you to educate me. :) >> >> > We use this in pciehp and shpchp as well for the same reason. One thing > I don't love about these patches is the need now to worry about freeing > memory after you make these calls. To me that seems like asking for > memory leaks in error paths at some point down the road when someone > less careful than Randy adds some code in. If there were some way to > return a pointer to a static string, I'd prefer that solution, but I > can't figure out from looking at the acpi code if that is possible. If > there's some better way to perform this compare, I'd like to hear it > too. Don't do the allocation in the function but pass a buffer and it's length to it. The caller can do dynamic allocation if needed or use a buffer on stack if not. This also makes error handling easier as ENOMEM can't happen in acpi_path_name() anymore. Eike |
From: Karl H. B. <kar...@gm...> - 2005-12-16 20:16:23
|
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: Moore, R. <rob...@in...> - 2005-12-16 20:11:52
|
AcpiGetName is in fact an external interface to ACPICA, and is declared in acpixf.h. The three headers that are intended to be "public" are as follows: Acpiosxf.h - Interfaces to be implemented by the OS interface layer (OSL). Acpixf.h - Interfaces to ACPICA, to be used by drivers, etc. Actypes.h - Types and structs required to use the public interfaces. The naming convention for ACPICA is that all "non-public" interfaces contain the prefix "Acpi??" where ?? is the short abbreviation for the component (Ut =3D Utilities, Dm =3D Disassembler, etc.) Anything without = the ?? abbreviation is a public interface. Rather than use another abbreviation, we decided to just drop it for the public interfaces to keep things short and descriptive. To clarify things for the world, I would have no problem with renaming the existing "acpi.h" to something else that indicates it is internal only, and then renaming actypes.h to acpi.h (or acpica.h) and pulling in both acpiosxf.h and acpixf.h within it. This way, we could export acpi.h (or acpica.h) to the world as the external header for ACPICA. Bob > -----Original Message----- > From: Rajesh Shah [mailto:raj...@in...] > Sent: Friday, December 16, 2005 10:39 AM > To: Brown, Len > Cc: Randy Dunlap; acp...@li...; pcihpd- > di...@li...; Accardi, Kristen C; gr...@su...; Moore, > Robert > Subject: Re: [ACPI] RE: [PATCH 1/2] make acpi_path_name() global >=20 > On Thu, Dec 15, 2005 at 11:56:47PM -0500, Brown, Len wrote: > > > > an example of this is acpi_get_name(), which as declared > > isn't supposed to be available outside the core. > > All the uses of it to print ACPI namespace tokens in /proc > > are totally bogus and should be deleted. The other use > > of it is to print out debug strings -- stuff the OS > > doesn't really need to "know" and maybe something the > > core should do for it. That leaves the hotplug use, > > which I don't understand. What does SATA need >=20 > Hotplug drivers use it to print where we found good, bad or missing > ACPI methods like _HPP, OSHP, _OSC that we need to work properly. > This is very useful as a debug aid, since ACPI namespace problems > have always been the number one reason why the hotplug drivers > fail to work. >=20 > thanks, > Rajesh |
From: Rajesh S. <raj...@in...> - 2005-12-16 18:39:09
|
On Thu, Dec 15, 2005 at 11:56:47PM -0500, Brown, Len wrote: > > an example of this is acpi_get_name(), which as declared > isn't supposed to be available outside the core. > All the uses of it to print ACPI namespace tokens in /proc > are totally bogus and should be deleted. The other use > of it is to print out debug strings -- stuff the OS > doesn't really need to "know" and maybe something the > core should do for it. That leaves the hotplug use, > which I don't understand. What does SATA need Hotplug drivers use it to print where we found good, bad or missing ACPI methods like _HPP, OSHP, _OSC that we need to work properly. This is very useful as a debug aid, since ACPI namespace problems have always been the number one reason why the hotplug drivers fail to work. thanks, Rajesh |
From: Kristen A. <kri...@in...> - 2005-12-16 18:37:58
|
On Thu, 2005-12-15 at 21:27 -0800, Randy.Dunlap wrote: > On Thu, 15 Dec 2005 23:56:47 -0500 Brown, Len wrote: <snip> > > an example of this is acpi_get_name(), which as declared > > isn't supposed to be available outside the core. > > All the uses of it to print ACPI namespace tokens in /proc > > are totally bogus and should be deleted. The other use > > of it is to print out debug strings -- stuff the OS > > doesn't really need to "know" and maybe something the > > core should do for it. That leaves the hotplug use, > > which I don't understand. What does SATA need > > with the actual path names? > > SATA uses the name string for (a) debugging, as you have > mentioned, and (b) for comparing complete device strings > to match/find a SATA _ADR under a device (in a device's > scope). I can do without (a) as well as the rest of the > kernel can, of course. I don't know how to find and match > SATA devices (part b) without it, so this is an opportunity > for you to educate me. :) > > We use this in pciehp and shpchp as well for the same reason. One thing I don't love about these patches is the need now to worry about freeing memory after you make these calls. To me that seems like asking for memory leaks in error paths at some point down the road when someone less careful than Randy adds some code in. If there were some way to return a pointer to a static string, I'd prefer that solution, but I can't figure out from looking at the acpi code if that is possible. If there's some better way to perform this compare, I'd like to hear it too. Kristen |
From: <wk...@29...> - 2005-12-16 11:35:34
|
过年了,请新老客户记得查验机票。http://www.travelsky.com/ 深圳始发机票价格: 始发站 终点站 原价 优惠价 始发站 终点站 原价 优惠价 深圳 北京 1750 700 深圳 厦门 790 470 深圳 天津 1850 740 深圳 福州 990 250 深圳 上海 1400 490 深圳 桂林 660 330 深圳 南京 1380 550 深圳 贵阳 940 380 深圳 杭州 1260 440 深圳 温州 960 580 深圳 成都 1410 560 深圳 三亚 890 450 深圳 重庆 1280 510 深圳 海口 690 280 深圳 无锡 1310 920 深圳 长沙 730 440 深圳 济南 1750 680 深圳 南昌 850 400 深圳 青岛 1830 730 深圳 南宁 890 450 深圳 西安 1630 570 深圳 宜昌 990 690 深圳 大连 2040 820 深圳 武汉 980 440 深圳 银川 1890 850 深圳 晋江 930 650 深圳 太原 1550 780 深圳 合肥 1190 600 深圳 昆明 1240 500 深圳 郑州 1410 630 深圳 宁波 1160 930 深圳 沈阳 2280 1140 深圳 长春 2490 1490 深圳 石家庄 1510 980 深圳 哈尔滨 2460 1230 深圳 乌鲁木齐 2840 1140 注:近期价格有变,请大家以当日电话为准! 热线电话:0755-25580444 传真:0755-25594137 订票可以送深圳华联出发330往返大巴票。数量有限送完为止 服务宗旨: 万俊航空服务有限公司是一家航空公司指定的代理公司,代理全 国各地的机票业务.一直以来,我们以专业快速和诚实守信的优质规 范的服务为你们效劳。无论单程还是往返,散客或是组团,国内或者 国际机票,我们都可以做到最优惠价格给您,使您满意有限航程,无 限真诚,您不打电话来是您的错.您打电话来没订票,是我们的错。 热线电话: 0755-21198789 传 真: 0755-25594137 Q Q 订票: 253482953 MSN 订票: abc...@ho... E___mail: 255...@16... 地 址: 深圳罗湖区国际信托大厦首层 |
From: Randy.Dunlap <rd...@xe...> - 2005-12-16 05:27:09
|
On Thu, 15 Dec 2005 23:56:47 -0500 Brown, Len wrote: > I think that some of our code partitioning is screwed up > and this continues and extends that tradition:-) I won't deny or argue with you there. > acpiosxf.h is supposed to declare ACPICA core things that > the OS needs to see. osl.c is supposed to glue and > wrap the appropriate core and Linux functions together. > > The big problem we have here is that every acpi sub-system > header is sucked into a consolidated header and so every > internal function is available to the entire kernel. > > an example of this is acpi_get_name(), which as declared > isn't supposed to be available outside the core. > All the uses of it to print ACPI namespace tokens in /proc > are totally bogus and should be deleted. The other use > of it is to print out debug strings -- stuff the OS > doesn't really need to "know" and maybe something the > core should do for it. That leaves the hotplug use, > which I don't understand. What does SATA need > with the actual path names? SATA uses the name string for (a) debugging, as you have mentioned, and (b) for comparing complete device strings to match/find a SATA _ADR under a device (in a device's scope). I can do without (a) as well as the rest of the kernel can, of course. I don't know how to find and match SATA devices (part b) without it, so this is an opportunity for you to educate me. :) > thanks, > -Len > > >-----Original Message----- > >From: Randy Dunlap [mailto:ran...@li...] > >Sent: Thursday, December 15, 2005 8:20 PM > >To: acp...@li...; > >pci...@li... > >Cc: Accardi, Kristen C; Brown, Len; gr...@su... > >Subject: [PATCH 1/2] make acpi_path_name() global > > > >From: Randy Dunlap <ran...@li...> > > > >Make acpi_path_name() usable by everyone. > >I need this for adding SATA suspend/resume ACPI support. > > > >Note: > >This function is now a memory allocator and callers should kfree() > >the memory when done with it. It doesn't seem safe to me to leave > >it as returning a pointer to a static buffer (as it was in multiple > >cloned copies) as we add callers to it. > > > > > >Signed-off-by: Randy Dunlap <ran...@li...> > >--- > > drivers/acpi/osl.c | 29 +++++++++++++++++++++++++++++ > > include/acpi/acpiosxf.h | 2 ++ > > 2 files changed, 31 insertions(+) > > > >--- linux-2615-rc5g5.orig/drivers/acpi/osl.c > >+++ linux-2615-rc5g5/drivers/acpi/osl.c > >@@ -1078,6 +1078,35 @@ 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 > >+ * > >+ * Allocates memory if successul. Caller must free the memory. > >+ * > >+ * Returns: pointer to path_name if successful, NULL if not. > >+ */ > >+u8 *acpi_path_name(acpi_handle handle) > >+{ > >+ acpi_status status; > >+ static u8 *path_name; > >+ struct acpi_buffer ret_buf = {ACPI_PATHNAME_MAX, > >path_name}; > >+ > >+ path_name = kzalloc(ACPI_PATHNAME_MAX, GFP_KERNEL); > >+ if (!path_name) > >+ return NULL; > >+ > >+ status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); > >+ > >+ if (ACPI_FAILURE(status)) { > >+ acpi_os_free(path_name); > >+ return NULL; > >+ } > >+ > >+ return path_name; > >+} > >+EXPORT_SYMBOL(acpi_path_name); > >+ > > #ifndef ACPI_USE_LOCAL_CACHE > > > > > >/************************************************************** > >***************** > >--- linux-2615-rc5g5.orig/include/acpi/acpiosxf.h > >+++ linux-2615-rc5g5/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); > > > >+u8 *acpi_path_name(acpi_handle handle); > >+ > > /* > > * Memory allocation and mapping > > */ --- ~Randy |
From: Brown, L. <len...@in...> - 2005-12-16 04:57:00
|
I think that some of our code partitioning is screwed up and this continues and extends that tradition:-) acpiosxf.h is supposed to declare ACPICA core things that the OS needs to see. osl.c is supposed to glue and wrap the appropriate core and Linux functions together. The big problem we have here is that every acpi sub-system header is sucked into a consolidated header and so every internal function is available to the entire kernel. an example of this is acpi_get_name(), which as declared isn't supposed to be available outside the core. All the uses of it to print ACPI namespace tokens in /proc are totally bogus and should be deleted. The other use of it is to print out debug strings -- stuff the OS doesn't really need to "know" and maybe something the core should do for it. That leaves the hotplug use, which I don't understand. What does SATA need with the actual path names? thanks, -Len >-----Original Message----- >From: Randy Dunlap [mailto:ran...@li...]=20 >Sent: Thursday, December 15, 2005 8:20 PM >To: acp...@li...;=20 >pci...@li... >Cc: Accardi, Kristen C; Brown, Len; gr...@su... >Subject: [PATCH 1/2] make acpi_path_name() global > >From: Randy Dunlap <ran...@li...> > >Make acpi_path_name() usable by everyone. >I need this for adding SATA suspend/resume ACPI support. > >Note: >This function is now a memory allocator and callers should kfree() >the memory when done with it. It doesn't seem safe to me to leave >it as returning a pointer to a static buffer (as it was in multiple >cloned copies) as we add callers to it. > > >Signed-off-by: Randy Dunlap <ran...@li...> >--- > drivers/acpi/osl.c | 29 +++++++++++++++++++++++++++++ > include/acpi/acpiosxf.h | 2 ++ > 2 files changed, 31 insertions(+) > >--- linux-2615-rc5g5.orig/drivers/acpi/osl.c >+++ linux-2615-rc5g5/drivers/acpi/osl.c >@@ -1078,6 +1078,35 @@ void acpi_os_release_lock(acpi_handle ha > spin_unlock_irqrestore((spinlock_t *) handle, flags); > } >=20 >+/** >+ * acpi_path_name - get ACPI path_name for the given handle >+ * @handle: ACPI object handle to look up name of >+ * >+ * Allocates memory if successul. Caller must free the memory. >+ * >+ * Returns: pointer to path_name if successful, NULL if not. >+ */ >+u8 *acpi_path_name(acpi_handle handle) >+{ >+ acpi_status status; >+ static u8 *path_name; >+ struct acpi_buffer ret_buf =3D {ACPI_PATHNAME_MAX,=20 >path_name}; >+ >+ path_name =3D kzalloc(ACPI_PATHNAME_MAX, GFP_KERNEL); >+ if (!path_name) >+ return NULL; >+ >+ status =3D acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); >+ >+ if (ACPI_FAILURE(status)) { >+ acpi_os_free(path_name); >+ return NULL; >+ } >+ >+ return path_name; >+} >+EXPORT_SYMBOL(acpi_path_name); >+ > #ifndef ACPI_USE_LOCAL_CACHE >=20 >=20 >/************************************************************** >***************** >--- linux-2615-rc5g5.orig/include/acpi/acpiosxf.h >+++ linux-2615-rc5g5/include/acpi/acpiosxf.h >@@ -112,6 +112,8 @@ unsigned long acpi_os_acquire_lock(acpi_ >=20 > void acpi_os_release_lock(acpi_handle handle, unsigned long flags); >=20 >+u8 *acpi_path_name(acpi_handle handle); >+ > /* > * Memory allocation and mapping > */ > > >--- > |
From: Li, S. <sha...@in...> - 2005-12-16 02:13:02
|
Hi, > >am a little stuck with suspend/resume on my ubuntu breezy system with a >vanilla 2.6.14.3 kernel built according to >http://www.columbia.edu/~ariel/acpi/acpi_howto.html > >Can't get it to suspend cleanly in normal runlevels, but when I boot to >single user mode without vesafb, fbcon etc. and if I stop next to >everything (NetworkManager, pcmcia, alsa etc.) and then unload all sorts >of modules I can get the system to suspend ... though it seems to hang >with a line "Shutdown: hda" till I hit Enter. > >Now, when I resume, I get: > >Thawing cpus ... >Booting processor 1/1 eip 3000 >Initializing CPU#1 >Stuck ?? >Inquiring remote API #1... >... APIC #1 ID: failed >... APIC #1 VERSION: failed >... APIC #1 SPIV: failed >Error taking cpu 1 up: -22 >Kernel panic - not synching: Not enough cpus > >While I tend to agree that I could use some more CPUs I don't panic about >it ;) > >Anyway, from what I see on this list the code that actually gives this >output seems to be in some of the required patches mentioned here. Is it >safe to assume that 2.6.14.3 includes the patches needed for >suspend/resume on a P4 with SMP/HT/PREEMPT in the kernel? 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 |
From: Li, S. <sha...@in...> - 2005-12-16 01:58:46
|
Hi, > >> >> when I try setting the alarm to wake up my pc I get the following >> >> result: >> >> [root@mithrandir acpi]# pwd >> >> /proc/acpi >> >> [root@mithrandir acpi]# cat alarm >> >> 2005-12-00 00:00:00 >> >> [root@mithrandir acpi]# echo 2005-12-15 17:18:19 > alarm >> >> [root@mithrandir acpi]# cat alarm >> >> 2005-12-00 17:18:19 >> >> [root@mithrandir acpi]# >> >> BTW, nothing happens at the echo'd date/time. Could someone please >> >> give me a clue where to start looking? I'm running fedora core 4, >> my >> >> mobo is an ASUS P5S800-VM, the documentation on the motherboard >> states >> >> that ACPI is supported. There is an option to turn acpi 2.0 on, >> but no >> >> difference... >> > >> >alarm never worked properly, IIRC. > >> It works well on different systems here :). > >Okay, so the problem is in me. Could we get some documentation? It >would be useful to know what to expect, and it should probably end up >in Documentation/ somewhere. Yup. Alarm is expected to wakeup the system from S3 sleep at a given time. Setting day, month and century is optional and depends on BIOS per ACPI spec. S4 alarm is also optional but maybe doesn't work on Linux (never tried). Thanks, Shaohua |
From: Randy D. <ran...@li...> - 2005-12-16 01:16:47
|
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 | 21 ++++++--------------- drivers/pci/hotplug/shpchprm_acpi.c | 19 ++++--------------- 2 files changed, 10 insertions(+), 30 deletions(-) --- linux-2615-rc5g5.orig/drivers/pci/hotplug/pciehprm_acpi.c +++ linux-2615-rc5g5/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) { @@ -71,6 +56,7 @@ acpi_run_hpp(acpi_handle handle, struct if (!ret_buf.pointer) { err ("%s:%s alloc for _HPP fail\n", __FUNCTION__, path_name); + kfree(path_name); return AE_NO_MEMORY; } status = acpi_evaluate_object(handle, METHOD_NAME__HPP, @@ -81,6 +67,7 @@ acpi_run_hpp(acpi_handle handle, struct if (ACPI_FAILURE(status)) { dbg("%s:%s _HPP fail=0x%x\n", __FUNCTION__, path_name, status); + kfree(path_name); return status; } } @@ -121,6 +108,7 @@ acpi_run_hpp(acpi_handle handle, struct free_and_return: kfree(ret_buf.pointer); + kfree(path_name); return status; } @@ -137,6 +125,7 @@ static acpi_status acpi_run_oshp(acpi_ha } else { dbg("%s:%s OSHP passes\n", __FUNCTION__, path_name); } + kfree(path_name); return status; } @@ -213,8 +202,10 @@ int pciehp_get_hp_hw_control_from_firmwa if (ACPI_SUCCESS(status)) { dbg("Gained control for hotplug HW for pci %s (%s)\n", pci_name(dev), path_name); + kfree(path_name); return 0; } + kfree(path_name); if (is_root_bridge(handle)) break; chandle = handle; --- linux-2615-rc5g5.orig/drivers/pci/hotplug/shpchprm_acpi.c +++ linux-2615-rc5g5/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) { @@ -70,6 +55,7 @@ acpi_run_hpp(acpi_handle handle, struct if (!ret_buf.pointer) { err ("%s:%s alloc for _HPP fail\n", __FUNCTION__, path_name); + kfree(path_name); return AE_NO_MEMORY; } status = acpi_evaluate_object(handle, METHOD_NAME__HPP, @@ -80,6 +66,7 @@ acpi_run_hpp(acpi_handle handle, struct if (ACPI_FAILURE(status)) { dbg("%s:%s _HPP fail=0x%x\n", __FUNCTION__, path_name, status); + kfree(path_name); return status; } } @@ -120,6 +107,7 @@ acpi_run_hpp(acpi_handle handle, struct free_and_return: kfree(ret_buf.pointer); + kfree(path_name); return status; } @@ -136,6 +124,7 @@ static void acpi_run_oshp(acpi_handle ha } else { dbg("%s:%s OSHP passes\n", __FUNCTION__, path_name); } + kfree(path_name); } int shpchprm_get_physical_slot_number(struct controller *ctrl, u32 *sun, u8 busnum, u8 devnum) --- |
From: Randy D. <ran...@li...> - 2005-12-16 01:16:43
|
From: Randy Dunlap <ran...@li...> Make acpi_path_name() usable by everyone. I need this for adding SATA suspend/resume ACPI support. Note: This function is now a memory allocator and callers should kfree() the memory when done with it. It doesn't seem safe to me to leave it as returning a pointer to a static buffer (as it was in multiple cloned copies) as we add callers to it. Signed-off-by: Randy Dunlap <ran...@li...> --- drivers/acpi/osl.c | 29 +++++++++++++++++++++++++++++ include/acpi/acpiosxf.h | 2 ++ 2 files changed, 31 insertions(+) --- linux-2615-rc5g5.orig/drivers/acpi/osl.c +++ linux-2615-rc5g5/drivers/acpi/osl.c @@ -1078,6 +1078,35 @@ 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 + * + * Allocates memory if successul. Caller must free the memory. + * + * Returns: pointer to path_name if successful, NULL if not. + */ +u8 *acpi_path_name(acpi_handle handle) +{ + acpi_status status; + static u8 *path_name; + struct acpi_buffer ret_buf = {ACPI_PATHNAME_MAX, path_name}; + + path_name = kzalloc(ACPI_PATHNAME_MAX, GFP_KERNEL); + if (!path_name) + return NULL; + + status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); + + if (ACPI_FAILURE(status)) { + acpi_os_free(path_name); + return NULL; + } + + return path_name; +} +EXPORT_SYMBOL(acpi_path_name); + #ifndef ACPI_USE_LOCAL_CACHE /******************************************************************************* --- linux-2615-rc5g5.orig/include/acpi/acpiosxf.h +++ linux-2615-rc5g5/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); +u8 *acpi_path_name(acpi_handle handle); + /* * Memory allocation and mapping */ --- |
From: Borislav P. <bbp...@ya...> - 2005-12-15 19:18:04
|
This removes the default (y|m) ACPI settings for laptops in order to speed up automated kbuilds without compiling unneeded stuff - I'm pretty certain the majority of machines running lnx are not laptops after all :) Signed-off-by: Borislav Petkov <pe...@un...> --- current/drivers/acpi/Kconfig.orig 2005-12-15 20:03:59.000000000 +0100 +++ current/drivers/acpi/Kconfig 2005-12-15 20:04:31.000000000 +0100 @@ -168,7 +168,6 @@ config ACPI_NUMA config ACPI_ASUS tristate "ASUS/Medion Laptop Extras" depends on X86 - default y ---help--- This driver provides support for extra features of ACPI-compatible ASUS laptops. As some of Medion laptops are made by ASUS, it may also @@ -209,7 +208,6 @@ config ACPI_IBM config ACPI_TOSHIBA tristate "Toshiba Laptop Extras" depends on X86 - default y ---help--- This driver adds support for access to certain system settings on "legacy free" Toshiba laptops. These laptops can be recognized by @@ -236,7 +234,6 @@ config ACPI_TOSHIBA config ACPI_SONY tristate "Sony Laptop Extras" depends on X86 && ACPI - default m ---help--- This mini-driver drives the ACPI SNC device present in the ACPI BIOS of the Sony Vaio laptops. ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de |
From: Karl H. B. <kar...@gm...> - 2005-12-15 17:11:09
|
Hi all, am a little stuck with suspend/resume on my ubuntu breezy system with a vanilla 2.6.14.3 kernel built according to http://www.columbia.edu/~ariel/acpi/acpi_howto.html Can't get it to suspend cleanly in normal runlevels, but when I boot to single user mode without vesafb, fbcon etc. and if I stop next to everything (NetworkManager, pcmcia, alsa etc.) and then unload all sorts of modules I can get the system to suspend ... though it seems to hang with a line "Shutdown: hda" till I hit Enter. Now, when I resume, I get: Thawing cpus ... Booting processor 1/1 eip 3000 Initializing CPU#1 Stuck ?? Inquiring remote API #1... ... APIC #1 ID: failed ... APIC #1 VERSION: failed ... APIC #1 SPIV: failed Error taking cpu 1 up: -22 Kernel panic - not synching: Not enough cpus While I tend to agree that I could use some more CPUs I don't panic about it ;) Anyway, from what I see on this list the code that actually gives this output seems to be in some of the required patches mentioned here. Is it safe to assume that 2.6.14.3 includes the patches needed for suspend/resume on a P4 with SMP/HT/PREEMPT in the kernel? TIA, Karl. |
From: Pavel M. <pa...@su...> - 2005-12-15 16:24:11
|
Hi! > >> when I try setting the alarm to wake up my pc I get the following > >> result: > >> [root@mithrandir acpi]# pwd > >> /proc/acpi > >> [root@mithrandir acpi]# cat alarm > >> 2005-12-00 00:00:00 > >> [root@mithrandir acpi]# echo 2005-12-15 17:18:19 > alarm > >> [root@mithrandir acpi]# cat alarm > >> 2005-12-00 17:18:19 > >> [root@mithrandir acpi]# > >> BTW, nothing happens at the echo'd date/time. Could someone please > >> give me a clue where to start looking? I'm running fedora core 4, > my > >> mobo is an ASUS P5S800-VM, the documentation on the motherboard > states > >> that ACPI is supported. There is an option to turn acpi 2.0 on, > but no > >> difference... > > > >alarm never worked properly, IIRC. > It works well on different systems here :). Okay, so the problem is in me. Could we get some documentation? It would be useful to know what to expect, and it should probably end up in Documentation/ somewhere. Pavel -- Thanks, Sharp! |
From: Roman I K. <ri...@os...> - 2005-12-15 11:24:36
|
15 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2005 10:40 | Andrew Morton: > - Roman I Khimov <ri...@os...>: "Something went wrong with ACPI, my > fan is blowing constantly." Just built 2.6.15-rc5-mm3, C2 state is back and everything is fine! Thanks. rik@pu-erh:~> cat /proc/acpi/processor/CPU0/power active state: C2 max_cstate: C8 bus master activity: 00000000 states: C1: type[C1] promotion[C2] demotion[--] latency[000] u= sage[00057690] *C2: type[C2] promotion[--] demotion[C1] latency[090] u= sage[00251887] =2D-=20 Roman ,---------------------------. ,--------------------------. / http://www.3os.ru/ V http://www.osrc.info/ \ .o. \ mailto: ri...@3o... ^ mailto: ri...@os... / ..o `---------------------------' `--------------------------' ooo gpg --recv-keys 0xE5E055C3 --keyserver hkp://subkeys.pgp.net |