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: Len B. <len...@in...> - 2006-01-17 05:17:16
|
Please note that acp...@li... is defunct. It will carry no new messages (except reminders like this:-) The new list is lin...@vg... To subscribe, go here: http://vger.kernel.org/vger-lists.html#linux-acpi thanks, -Len Brown, Intel Open Source Technology Center E-mail lists related to Linux ACPI and Power Management (1/16/2005) lin...@vg... Description: Linux/ACPI Development, Discussion, Support Subscribe: mailto:maj...@vg...?body=subscribe linux-acpi http://vger.kernel.org/vger-lists.html#linux-acpi Note that your "From:" address must match your subscription address, or you will not be able to subscribe. Archives for linux-acpi (started Jan 2006) http://marc.theaimsgroup.com/?l=linux-acpi&r=1&w=2 http://dir.gmane.org/gmane.linux.acpi.devel http://www.mail-archive.com/lin...@vg.../ Archives for acp...@li... (discontinued Jan 2006): http://sourceforge.net/mailarchive/forum.php?forum=acpi-devel http://marc.theaimsgroup.com/?l=acpi4linux http://news.gmane.org/gmane.linux.acpi.devel Archives for acp...@li... (discontinued Feb 2004) http://sourceforge.net/mailarchive/forum.php?forum=acpi-support int...@li... Description: Intel-only sub-set of above - used to ping Intel team directly. acp...@li... Description: Used only for cc: on public Linux/ACPI bug reports Subscribe if you want to see bugzilla updates in real-time. Do not post to this list Archives: http://sourceforge.net/mailarchive/forum.php?forum=acpi-bugzilla http://www.mail-archive.com/acpi-bugzilla%40lists.sourceforge.net/ Subscribe: mailto:acp...@li...?subject=subscribe http://lists.sourceforge.net/lists/listinfo/acpi-bugzilla lin...@li... Description: General discussion about power management issues under Linux Subscribe: https://lists.osdl.org/mailman/listinfo/linux-pm Archives: http://lists.osdl.org/pipermail/linux-pm/ lin...@li... Description: General discussion about power management issues under Linux Subscribe: http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Archives: http://sourceforge.net/mailarchive/forum.php?forum=linux-pm-devel Comment: seems to have the same charter as the more heavily used OSDL list above. |
From: Len B. <len...@in...> - 2006-01-09 08:22:55
|
Please note that acp...@li... is defunct. The new list to use for Linux/ACPI topics is lin...@vg... If you'd like to participate in Linux/ACPI development and support discussions, you can subscribe here: http://vger.kernel.org/vger-lists.html#linux-acpi Or read the archives here: http://dir.gmane.org/gmane.linux.acpi.devel http://www.mail-archive.com/linux-acpi%40vger.kernel.org/ http://marc.theaimsgroup.com/?l=linux-acpi&r=1&w=2 thanks, -Len |
From: Len B. <le...@he...> - 2006-01-05 05:12:29
|
Everybody, Sourceforge reliability is (way) down (again), and spam is up. In contrast, LKML and linux-ia64 on vger.kernel.org run quite well. The folks at vger.kernel.org have graciously agreed to host our list for us. Given the current sourceforge instability, I'd like to transition immediately. There will be no more messages to acp...@li... (except reminders like this:-) Please subscribe to lin...@vg... per the notes below. thanks, -Len Brown, Intel Open Source Technology Center E-mail lists related to Linux ACPI and Power Management (1/4/2006) lin...@vg... Description: Linux/ACPI Development, Discussion, Support Subscribe: mailto:maj...@vg...?body=subscribe linux-acpi http://vger.kernel.org/vger-lists.html#linux-acpi Note that no human approves subscriptions -- if you can't get your FROM: header to agree with your address then you can't subscribe. Archives for lin...@vg... http://marc.theaimsgroup.com/?l=linux-acpi&r=1&w=2 (requested) http://news.gmane.org/gmane.linux.acpi.devel (includes old sourceforge archive too) http://www.mail-archive.com (requested, but not yet operational as of 1/4/06) Archives for acp...@li... (discontinued Jan 2006): http://sourceforge.net/mailarchive/forum.php?forum=acpi-devel http://marc.theaimsgroup.com/?l=acpi4linux http://news.gmane.org/gmane.linux.acpi.devel Archives for acp...@li... (discontinued Feb 2004) http://sourceforge.net/mailarchive/forum.php?forum=acpi-support lin...@in... Description: Includes Len Brown and the other Intel folks who work with Linux/ACPI. Use this list to bug Intel directly about Linux/ACPI. This is used by some distros to cc: Intel on bugzilla entries when acp...@li... would not work. (note that lin...@in... is subscribed to lin...@vg..., so there is no need to cross post) acp...@li... Description: Used only for cc: on public Linux/ACPI bug reports Subscribe if you want to see bugzilla updates in real-time. Do not post to this list Archives: http://sourceforge.net/mailarchive/forum.php?forum=acpi-bugzilla http://www.mail-archive.com/acpi-bugzilla%40lists.sourceforge.net/ Subscribe: mailto:acp...@li...?subject=subscribe http://lists.sourceforge.net/lists/listinfo/acpi-bugzilla lin...@li... Description: General discussion about power management issues under Linux Subscribe: https://lists.osdl.org/mailman/listinfo/linux-pm Archives: http://lists.osdl.org/pipermail/linux-pm/ lin...@li... Description: General discussion about power management issues under Linux Subscribe: http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Archives: http://sourceforge.net/mailarchive/forum.php?forum=linux-pm-devel Comment: seems to have the same charter as the more heavily used OSDL list above. |
From: Len B. <le...@he...> - 2005-12-30 08:15:19
|
Everybody, Sourceforge reliability is (way) down (again), and spam is up. In contrast, LKML and linux-ia64 on vger.kernel.org run quite well. The folks at vger.kernel.org have graciously agreed to host our list for us. Given the current sourceforge instability, I'd like to transition immediately. Please subscribe to lin...@vg... per the notes below. thanks, -Len Brown Intel Open Source Technology Center E-mail lists related to Linux ACPI and Power Management (12/29/2005) lin...@vg... Description: Linux/ACPI Development, Discussion, Support Subscribe: mailto:maj...@vg...?body=subscribe linux-acpi http://vger.kernel.org/vger-lists.html#linux-acpi Archives for linux-acpi (started Jan 2006) http://marc.theaimsgroup.com/?l=linux-acpi&r=1&w=2 (requested) http://gmane.org/ (requested, but not yet operational as of 12/29) http://www.mail-archive.com (requested, but not yet operational as of 12/29) Archives for acp...@li... (discontinued Jan 2006): http://sourceforge.net/mailarchive/forum.php?forum=acpi-devel http://marc.theaimsgroup.com/?l=acpi4linux http://news.gmane.org/gmane.linux.acpi.devel Archives for acp...@li... (discontinued Feb 2004) http://sourceforge.net/mailarchive/forum.php?forum=acpi-support lin...@in... Description: Len Brown and the other Intel folks who work with Linux/ACPI. Use this list to bug Intel directly about Linux/ACPI. This is used by some distros to cc: Intel on bugzilla entries when acp...@li... would not work. (note that these folks are also on the list above, no need to cross post) acp...@li... Description: Used only for cc: on public Linux/ACPI bug reports Subscribe if you want to see bugzilla updates in real-time. Do not post to this list Archives: http://sourceforge.net/mailarchive/forum.php?forum=acpi-bugzilla Subscribe: mailto:acp...@li...?subject=subscribe http://lists.sourceforge.net/lists/listinfo/acpi-bugzilla lin...@li... Description: General discussion about power management issues under Linux Subscribe: https://lists.osdl.org/mailman/listinfo/linux-pm Archives: http://lists.osdl.org/pipermail/linux-pm/ lin...@li... Description: General discussion about power management issues under Linux Subscribe: http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Archives: http://sourceforge.net/mailarchive/forum.php?forum=linux-pm-devel Comment: seems to have the same charter as the more heavily used OSDL list above. |
From: Len B. <le...@he...> - 2005-12-30 04:02:27
|
How the Linux/ACPI patch flow works Len Brown <len...@in...> Dec 10, 2005 The latest version of this file lives here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/README.ACPI This file describes how the Linux/ACPI patch flow works, and where you can get Linux/ACPI kernel paches: 1. mailing lists 2. bugzilla 3. the Linux/ACPI git tree 4. plain patches on kernel.org Mailing Lists ------------- Issues with Linux/ACPI should be discussed on acp...@li.... Note that acpi-devel has an 80KB message size limit, which reminds people that big debug logs are best filed in bugzilla... Bugzilla -------- The Linux/ACPI community makes active use of bugzilla. http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI While discussion-oriented issues are best dealt with on the list. Specific issues which require lots of backing data, such as debug logs for specific failing machines are best dealt with in bugzilla. Many issues can use both simultaneously -- getting attention to the issue on the list and storing the backing data in bugzilla. Patch Flow ---------- Len Brown (the author) is the maintainer for the Linux Kernel ACPI sub-system. He's responsible for the "smooth" flow of patches from the community to Andrew's mm testing tree and to Linus's kernel - quotes intentional:-) Proposed patches to the Linux/ACPI kernel sub-system should be e-mailed to acp...@li... for review, comment, and testing by the community. It is important to describe your expectations of the patch in the e-mail. If it is an experiment, or a debug patch, please say so. If you think it is well tested, broadly reviewed and ready to integrate into the upstream kernel, say that using the words "please apply", adding len...@in... the "to: list" to make sure he sees your request. Note that Len is okay with patches in e-mail attachments as well as in plain text. If the patch touches code outside the ACPI sub-system, then the same message should be cross-posted to lin...@vg.... Len also takes patches directly from bugzilla entries. Indeed, he usually gives priority to bugzilla fixes because bugzilla does such a good job remembering the details of the issue, and the people involved have taken the trouble to carefully enter the data in bugzilla. Len also incorporates updates from ACPICA, the "ACPI Component Architecture" -- the core interpreter that Intel develops for the benefit of all ACPI operating systems. (okay, all but Windows -- MS uses their own interpreter) Intel publishes ACPICA under a dual source license so that FreeBSD etc. can use it w/o GPL tainting. Linux gets huge benefits from sharing this core, and so preventing divergence between Linux and the shared ACPICA code is why Len hates to accept GPL patches to some files. Note that the ACPICA files are the ones in the sub-directories drivers/acpi/* plus a bunch of include/acpi/ headers. All the other kernel files in drivers/acpi/* and elsewhere are straight GPL -- as indicated in their header comments. git --- Len follows Tony Luck's method of using GIT branches, documented in git/Documentation/howto/using-topic-branches.txt The latest patches intended for Linus are here: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release The latest patches intended for community testing are here: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test This test branch is always a proper super-set of the release branch above. Note that Andrew Morton routinely pulls this test branch into the mm tree as git-acpi.patch. git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git acpica Is a topic-specific branch containing the latest ACPICA interpreter. It will get pulled into the test branch above when ready. There may be other topic-specific branches from time to time. Fetching code via git is the easiest way to stay up to date, so get git and get going: git pull git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test Git startup instructions: http://linux.yyz.us/git-howto.html patches ------- ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release includes patches from the Linux/ACPI git release branch. Len publishes these when he sends a pull request to Linus. If Linus doesn't pull for a while, this patch tells you what is in the queue. As soon as Linus pulls, however, this patch becomes a duplicate of what is in Linu's tree and will thus no longer apply. The patches are named like so: acpi-release-20050902-2.6.15-rc5.diff.gz was created on the "release" branch, some time after 2.6.15-rc5, and includes ACPICA up through 20050902. ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test includes patches from the Linux/ACPI test branch, as well as other topic branches such as acpica: acpi-test-20050916-2.6.15-rc5.diff.gz acpi-acpica-20051202-2.6.15-rc5.diff.gz Len rarely public individual test patches here, since they can now be pulled from the GUI using gitweb: http://www.kernel.org/git/?p=linux/kernel/git/lenb/linux-acpi-2.6.git patch signing ------------- files on ftp.kernel.org compressed and signed per http://www.kernel.org/signature.html If you'd like to verify the signature, import key by: gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E verify integrity by: gpg --verify <sigfile> <signed-file> you can skip <signed-file> if it is in the same directory as <sigfile>. applying patches ---------------- Both Test and Release patches have a header at the top of the patch including the commit comments to describe what is included in the patch. Note you can test if a patch will apply cleanly before you apply it for real: $ cd my-src/linux/ To test $ patch --dry-run -Np1 < acpi.patch For real: $ patch -Np1 < acpi.patch --- Questsion, comments, suggestions to len...@in... Thanks, -Len Brown Intel Open Source Technology Center |
From: Jaco K. <ja...@kr...> - 2005-12-29 12:37:00
|
Right, I've tired of this piece of crap. I've been staring at the dsdt for hours now, made a large number of mods, did some weird debugging and I'm still stuck. This is what I can figure out so far, if _OSI is disabled, and os_name is set to "Microsoft Windows NT" you get events upon both opening and closin= g the lid. Anything else and you only get events upon close. I'm not sure as to the exact functioning of the hardware but it seems it acts different for different versions of Windows as it's writing out a single byte to memory (with a single bit set) (0x04 for NT, always one of the lower-order 4-bits for non _OSI and one of the upper bits for _OSI, 0 in case where it can't find a match for anything - Linux). Right, now there is an event handler in \_GPE, _L07 which gets called every time the lid closes (as well as when the lid opens for MS Win NT).=20 For MS Win NT the function flips a bit called LPOL (Lid Polarity?) and fo= r everything else it calls a function PHSS which writes the passed value ot= u to memory after locking a Mutex and first, and sends a fixed value before and after sending the argument - I suspect this merely makes the BIOS bee= p the pcspkr or something as I only get beeps on close when I'm not using Win NT), and then inverts the LIDS bit. Now the weird thing, I would have thought that the output of the LIDS bit is purely dependand on the hardware (ie, some switch that is connected to the LID that determines whether the value is 0 or 1). Flipping the LPOL bit seems to allow me to get open events as well. In neither case does the LIDS bit seem to function, it's _always_ 0 when read from the LID._LID function and it seems to be always one in the \_GPE._L07 handler. Both the LPOL and LIDS bits is accessed via the same IndexField. I still wonder whether sleeping between sending the index value and reading the data value might help? My counter argument to this is that the LPOL bit seems to always be valid. This will have to be done in the executer (kernel) though - or is this already done (I can't make head or tail of the executer/ code). The alignment of the LIDS and LPOL bits within their individual bytes is identical though and access it ByteAcc. Since the LPOL bit seems to reflect the correct state with regards to open/close (albeit inverted) I reckon it's possible to hack the DSDT to read the LPOL in _LID instead of LIDS, invert it and return that instead.= =20 Whilst this would most probably work I don't think it's the right thing t= o do. What other options are available? Thanks for any and all help. Jaco PS: My DSDT is available at http://www.kroon.co.za/downloads/toshiba_p10-792/ --=20 There are 10 kinds of people in the world, those who understand binary, and those who don't. --=20 There are 10 kinds of people in the world, those who understand binary, and those who don't. |
From: Karol K. <sz...@he...> - 2005-12-28 22:59:01
|
Thus wrote Li, Shaohua: > S4 alarm is also optional but maybe doesn't work on Linux (never tried). Works here, with a proper S4 (so it's possible, though still hardware dependent). Best regards, -- Karol 'sziwan' Kozimor sz...@he... |
From: Lewis Q. <cla...@be...> - 2005-12-28 21:59:18
|
Today's stock notification is for RYNL. While reviewing a number of up and coming companies we came across this low entry investment stock that surprised with the stability and foundations for growth. Company: Reynaldo's Mexican Food Inc. Symbol: RYNL Date: Dec 29 2005 Last price: $0.11 Short Term Target: $0.5 Reynaldo's Mexican Food Inc. (RYNL OTC:BB) has been in business for over 20 years supplying a wide variety of Mexican Foods. In their humble beginnings they began supplying prepared foods to industrial catering companies but in time expanded not only their list of products but their clientele. RYNL now supplies Mexican Cuisine from its multiple factories to Mexico and over 14 different states. They also distrinute through some of United states largest corporations, just go to their website to see a list of their business partners. Members, this is one solid company that has already show huge potential by their ability to expand and make all the right connections. Don't over look this solid stock. Add this one to your investment portfolio. You wont regret it. What Ever You Do... We give this to you again as a gift. This company is doing incredible things. They have cash and have made great strategic aquisitions. The current price is $0.11. Word on the street is this stock could take off at any moment. This company has dropped big news in the past, who's to say they dont have another big one brewing. WE SEE BIG THINGS HAPPENING. WATCH RYNL TRADE ON THURSDAY... |
From: Karol K. <sz...@he...> - 2005-12-28 18:24:48
|
Thus wrote Pavel Machek: [...] Last time I checked (2.6.15-rc[45]) it worked fine -- I use it routinely for S3 stress-testing (speaking of which, my machine has just failed to resume after some 20 days of uptime and > 150 S3 cycles). > Here are my attempts: [Commands were typed one-after-another where it > makes sense, and I left machine suspended for long enough -- timer > should have expired] > > root@amd:/proc/acpi# cat alarm > 2005-12-00 01:03:24 > root@amd:/proc/acpi# echo '0-0-0 22:35:00' > alarm You got it mixed up. It's either "2005-12-28 19:50:00" for absolute or "+0000-00-00 00:01:00" for relative. RTC IRQ counter is incremented whenever the timer triggers, regardless of whether the system is up or down (my system, at least). HTH, best regards, -- Karol 'sziwan' Kozimor sz...@he... |
From: Pavel M. <pa...@uc...> - 2005-12-27 16:14:43
|
On =DAt 27-12-05 16:33:30, Dominik Brodowski wrote: > Hi, >=20 > On Tue, Dec 27, 2005 at 03:22:38PM +0100, Pavel Machek wrote: > > So... I guess I found out what is going on. > >=20 > > When power is unplugged, X32 adds C4 state. When power is plugged, X3= 2 > > removes C4 state (behaviour Ted seen). When I load ipw2200, this > > behaviour stops, and I see everything up-to C4. Strange. I remember > > ipw had some problems with C3 and C4, perhaps this is related? >=20 > Nothing strange at all. The C-States are exported by the BIOS to the OS > using the _CST method/object/whatever. This can change on runtime. When= the > BIOS recognizes it is on battery power, the _CST contains the C4 state,= if > it is on AC power, the _CST doesn't contain it. The ACPI code follows w= hat > it is told by the BIOS, for it has no chance to know about this additio= nal > C-State if on AC power, and it wouldn't be wise to second-guess the BIO= S. >=20 > Ipw does limit the max_cstate setting dynamically if it recognizes prob= lems; > however I haven't seen _any_ such things lately on my own system. Might= be > related to dyntick being _enabled_, though ;-) This was without dynticks... But why C4 availability no longer changes (between AC and battery power) with ipw2200 loaded? I'd understand higher C states being unavailable... Pavel --=20 Thanks, Sharp! |
From: Dominik B. <li...@do...> - 2005-12-27 15:33:44
|
Hi, On Tue, Dec 27, 2005 at 03:22:38PM +0100, Pavel Machek wrote: > So... I guess I found out what is going on. > > When power is unplugged, X32 adds C4 state. When power is plugged, X32 > removes C4 state (behaviour Ted seen). When I load ipw2200, this > behaviour stops, and I see everything up-to C4. Strange. I remember > ipw had some problems with C3 and C4, perhaps this is related? Nothing strange at all. The C-States are exported by the BIOS to the OS using the _CST method/object/whatever. This can change on runtime. When the BIOS recognizes it is on battery power, the _CST contains the C4 state, if it is on AC power, the _CST doesn't contain it. The ACPI code follows what it is told by the BIOS, for it has no chance to know about this additional C-State if on AC power, and it wouldn't be wise to second-guess the BIOS. Ipw does limit the max_cstate setting dynamically if it recognizes problems; however I haven't seen _any_ such things lately on my own system. Might be related to dyntick being _enabled_, though ;-) Dominik |
From: Pavel M. <pa...@uc...> - 2005-12-27 14:23:22
|
On =DAt 27-12-05 15:03:25, Pavel Machek wrote: > On =DAt 27-12-05 00:27:12, Pavel Machek wrote: > > On Po 26-12-05 17:52:48, Theodore Ts'o wrote: > > > On Mon, Dec 26, 2005 at 09:38:06PM +0100, Pavel Machek wrote: > > > > Stupid IBM. I've seen it appearing/disappearing, but did not work= out > > > > when. > > > >=20 > > > > No-C4-on-AC is bad -- if you just disconnect AC and walk away, yo= u are > > > > running without benefits of C4. Bad. Changing benchmarks dependin= g on > > > > you booting on AC or battery also look nasty. > > >=20 > > > The moment you disconnect AC, it C4 automagically appears. When yo= u > > > reconnect to the AC mains, the C4 state disappears again, at least > > > from the listing displayed by /proc/acpi/processor/CPU0/power. So = the > > > first issue you brought up isn't a problem. > >=20 > > It does not seem to work like that here. I'm not sure what the exact > > rules are, but I know that I sometimes have C4 and sometimes not. I > > have C4 now, and it is used, even when I'm on AC power. Thinkpad > > X32. >=20 > Well, today it _does_ behave like Theodore described (slightly > different kernel, and I'm using power supply, not docking > station). Strange. So... I guess I found out what is going on. When power is unplugged, X32 adds C4 state. When power is plugged, X32 removes C4 state (behaviour Ted seen). When I load ipw2200, this behaviour stops, and I see everything up-to C4. Strange. I remember ipw had some problems with C3 and C4, perhaps this is related? Pavel --=20 Thanks, Sharp! |
From: Randy.Dunlap <rd...@xe...> - 2005-12-27 03:45:16
|
Hi-- You can drop this patch. With the changes wanted by everyone (except for Pat Mochel), this just makes acpi_path_name() be a synonym for acpi_get_name(), so I'll just use acpi_get_name() directly. On Wed, 21 Dec 2005 12:05:00 -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. > > v4: Fix enter/exit trace error noted by Matthew Wilcox. > v3: use EXPORT_SYMBOL_GPL for acpi_path_name. > v2: use ACPI-CA calling convention for name buffer. --- ~Randy |
From: Pavel M. <pa...@uc...> - 2005-12-26 20:43:37
|
Hi! I wanted to write some documentation about /proc/acpi/alarm, but failed to make it work. I was putting machine to suspend-to-ram and enabled everything in /proc/acpi/wakeup, still it would not do anything. I even went to bios (thinkpad x32), set "RTC alarm" to enabled and set time there. Nothing interesting happened. /proc/acpi/alarm could not see most of my changes done in BIOS, it only cleared century or something like that. I checked that RTC readout in BIOS shows same thing as system timer. Here are my attempts: [Commands were typed one-after-another where it makes sense, and I left machine suspended for long enough -- timer should have expired] root@amd:/proc/acpi# cat alarm 2005-12-00 01:03:24 root@amd:/proc/acpi# echo '0-0-0 22:35:00' > alarm root@amd:/proc/acpi# cat alarm 0005-12-00 22:35:00 root@amd:/proc/acpi# s2ram Freezing cpus ... Stopping tasks: ====================================| ACPI: PCI interrupt for device 0000:02:01.0 disabled ACPI: PCI interrupt for device 0000:02:00.1 disabled ACPI: PCI interrupt for device 0000:02:00.0 disabled radeonfb (0000:01:00.0): suspending to state: 2... radeonfb (0000:01:00.0): resuming from state: 2...to 64er 10 Dec 2004 Restarting tasks... done Thawing cpus ... root@amd:/proc/acpi# date Sun Dec 25 22:36:46 CET 2005 root@amd:/proc/acpi# cat alarm 0005-12-00 22:35:00 root@amd:/proc/acpi# root@amd:/proc/acpi# cat alarm 0005-12-00 22:35:00 root@amd:/proc/acpi# echo '*-*-* 22:40:00' > alarm root@amd:/proc/acpi# cat alarm 0005-12-00 22:35:00 root@amd:/proc/acpi# echo '2005-12-25 22:40:00' > alarm root@amd:/proc/acpi# cat alarm 2005-12-25 22:40:00 root@amd:/proc/acpi# date Sun Dec 25 22:37:53 CET 2005 root@amd:/proc/acpi# s2ram Freezing cpus ... Stopping tasks: =====================================| ACPI: PCI interrupt for device 0000:02:01.0 disabled ACPI: PCI interrupt for device 0000:02:00.1 disabled ACPI: PCI interrupt for device 0000:02:00.0 disabled radeonfb (0000:01:00.0): suspending to state: 2... radeonfb (0000:01:00.0): resuming from state: 2...to 64er 10 Dec 2004 Restarting tasks... done Thawing cpus ... root@amd:/proc/acpi# date Sun Dec 25 22:41:14 CET 2005 root@amd:/proc/acpi# ...so... what am I doing wrong? Is thinkpad x32 machine where it does not work? Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-25 20:32:47
|
Pavel Machek wrote: >>Now, initially when I switch back to X I get the correct image on the >>bottom third of the screen with the top two thirds seemingly corrupted. >> This is pretty normal and is identical to what I normally see when >>switching between consoles and X. This lasts for about half a second >>before it freezes up and causes a hard-lock. Normally the screen just >>resets itself at the time it now locks up. > > > I'm sorry, there's no way we can help you with fglrx. I'm glad at > least s-t-disk works. Was the ati-agp module in the kernel. Adding some suspend/resume support for that module fixes all and I can now happily suspend-to-ram and successfully resume. I've mailed a patch to the agpgart maintainer and cc'ed the lkml. For refference purposes the patch (based on http://unixhead.org/docs/thinkpad/ati-agp/ati-agp.diff) is as follows, and I'll also make it available on my website: --- linux-2.6.15-rc6/drivers/char/agp/ati-agp.c.orig 2005-12-25 22:21:32.000000000 +0200 +++ linux-2.6.15-rc6/drivers/char/agp/ati-agp.c 2005-12-25 22:23:33.000000000 +0200 @@ -243,6 +243,15 @@ return 0; } +static int ati_resume(struct pci_dev *dev) +{ + return ati_configure(); +} + +static int ati_suspend(struct pci_dev *dev, pm_message_t state) +{ + return 0; +} /* *Since we don't need contigious memory we just try @@ -525,6 +534,8 @@ .id_table = agp_ati_pci_table, .probe = agp_ati_probe, .remove = agp_ati_remove, + .resume = ati_resume, + .suspend = ati_suspend, }; static int __init agp_ati_init(void) -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Jaco K. <ja...@kr...> - 2005-12-25 16:16:45
|
Pavel Machek wrote: > Hi! > [--snip--] > I'm sorry, there's no way we can help you with fglrx. I'm glad at > least s-t-disk works. > Pavel LOL - was just posting back as a follow up so that you all know how it turned out. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Olaf C. <oo...@gm...> - 2005-12-25 16:02:45
|
Hi, thanks for your reply. On 12/22/05, Thomas Renninger <tr...@su...> wrote: > What you see is probably a bug that slipped in 2.6.15-rc5: > It totally disables the use of cpufreq for passive cooling. > I already pointed Len to it and as this is really sever I am sure it > will be added before 2.6.15 is out if possible. > Also see Dirk Mueller's mail (12/21/2005): > Subject: make cpu_has_cpufreq() work > or the bug: > http://bugzilla.kernel.org/show_bug.cgi?id=3D3410 My processor does not support speedstep for frequency scaling, it only supports throttling. The bug you pointed to does not seem to be entirely cpufreq specific, so maybe it is relevant. Am not sure. How can I diagnose the problem? I can put the system under load by compiling something, but how can I best monitor acpi? Cheers and a merry xmas, -Olaf |
From: Pavel M. <pa...@su...> - 2005-12-25 08:48:01
|
Hi! > New weird error. This may also be harmless though. Just first a few > notes, I'm back onto 2.6.14.3 kernel (fglrx doesn't work with 2.6.15-rc? > - it just crashes the whole system), and I really need that. > > With fglrx I can suspend to disk and resume. However, I can't > suspend-to-ram. Well, suspend works and it comes back up fine but as > soon as I switch back to X it hard-crashes the machine. Now, I'm > currently between resume and switching to X, and the last few lines from > dmesg looks as follows: > > Restarting tasks... done > ACPI-0284: *** Error: Region EmbeddedController(3) has no handler > ACPI-0508: *** Error: Method execution failed [\_SB_.EPWR.PCLK] > (Node c14d3200), AE_NOT_EXIST > ACPI-0508: *** Error: Method execution failed > [\_SB_.CPI0.LPC0.EC0_._Q1E] (Node c14ceee0), AE_NOT_EXIST ...something wrong with embedded controller... here fixed DSDT *might* help. > Now I have a very weird feeling down in my gut that I did not see this > before and it's probably due to the fglrx module in my kernel. And > interrupt 11, btw, is for the screen (it gets shown now in > /proc/interrupts after I restored most of my kernel). > > Now, initially when I switch back to X I get the correct image on the > bottom third of the screen with the top two thirds seemingly corrupted. > This is pretty normal and is identical to what I normally see when > switching between consoles and X. This lasts for about half a second > before it freezes up and causes a hard-lock. Normally the screen just > resets itself at the time it now locks up. I'm sorry, there's no way we can help you with fglrx. I'm glad at least s-t-disk works. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-25 08:24:49
|
Pavel Machek wrote: > On So 24-12-05 15:14:16, Jaco Kroon wrote: >>Pavel Machek wrote: >>>>Now, with APIC, but no IO-APIC there is a bug notice during resume. >>>>Going to type it over (from dmesg): >>>> >>>>Back to C! >>>>Debug: sleeping function called from invalid context at mm/slab.c:2472 >>>>in_atomic():0, irqs_disabled():1 >>>>__might_sleep+0x9e/0xa6 >>>>acpi_os_allocate+0x15/0x26 >>>>kmem_cache_alloc+0x95/0xad >>>>acpi_ut_callocate+0x37/0x79 >>> >>>I know, it is scary, but it is also known and harmless. You can ignore >>>this one. >> >>Now _that_ made me raise an eyebrow. Even more than the fact that my >>DSDT insists on checking for the version of Microsoft Windows I'm >>running! > > See archives. Len even had a fix at some point, but it was too ugly > IIRC. > Oh ok. No problem then. New weird error. This may also be harmless though. Just first a few notes, I'm back onto 2.6.14.3 kernel (fglrx doesn't work with 2.6.15-rc? - it just crashes the whole system), and I really need that. With fglrx I can suspend to disk and resume. However, I can't suspend-to-ram. Well, suspend works and it comes back up fine but as soon as I switch back to X it hard-crashes the machine. Now, I'm currently between resume and switching to X, and the last few lines from dmesg looks as follows: Restarting tasks... done ACPI-0284: *** Error: Region EmbeddedController(3) has no handler ACPI-0508: *** Error: Method execution failed [\_SB_.EPWR.PCLK] (Node c14d3200), AE_NOT_EXIST ACPI-0508: *** Error: Method execution failed [\_SB_.CPI0.LPC0.EC0_._Q1E] (Node c14ceee0), AE_NOT_EXIST Now I have a very weird feeling down in my gut that I did not see this before and it's probably due to the fglrx module in my kernel. And interrupt 11, btw, is for the screen (it gets shown now in /proc/interrupts after I restored most of my kernel). Now, initially when I switch back to X I get the correct image on the bottom third of the screen with the top two thirds seemingly corrupted. This is pretty normal and is identical to what I normally see when switching between consoles and X. This lasts for about half a second before it freezes up and causes a hard-lock. Normally the screen just resets itself at the time it now locks up. Anyhow, not too serious, overall I'm pretty happy with the progress made during this week. suspend-to-disk == much better than no suspend at all (at least now I can stop my notebook halfway through some busy task to shut it down, transport it and resume elsewhere). Then again, I'll play around with the kernel options for fglrx and see whether they don't perhaps make a difference. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-24 13:58:25
|
On So 24-12-05 15:14:16, Jaco Kroon wrote: > Pavel Machek wrote: > > >>Now, with APIC, but no IO-APIC there is a bug notice during resume. > >>Going to type it over (from dmesg): > >> > >>Back to C! > >>Debug: sleeping function called from invalid context at mm/slab.c:2472 > >>in_atomic():0, irqs_disabled():1 > >> __might_sleep+0x9e/0xa6 > >> acpi_os_allocate+0x15/0x26 > >> kmem_cache_alloc+0x95/0xad > >> acpi_ut_callocate+0x37/0x79 > > > > I know, it is scary, but it is also known and harmless. You can ignore > > this one. > > Now _that_ made me raise an eyebrow. Even more than the fact that my > DSDT insists on checking for the version of Microsoft Windows I'm > running! See archives. Len even had a fix at some point, but it was too ugly IIRC. > Not right now. The festive season awaits (yay ...). So in that spirit, > Merry Christmas and a Happy New Year! Merry Christmas! > > Oh and thanks for video.txt diff, applied. > > Shees. That is my second accepted patch in a week. Also my first two > accepted patches. LOL. Hopefully there will be more to come. Now I :-). Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-24 13:12:42
|
Pavel Machek wrote: >>Now, with APIC, but no IO-APIC there is a bug notice during resume. >>Going to type it over (from dmesg): >> >>Back to C! >>Debug: sleeping function called from invalid context at mm/slab.c:2472 >>in_atomic():0, irqs_disabled():1 >> __might_sleep+0x9e/0xa6 >> acpi_os_allocate+0x15/0x26 >> kmem_cache_alloc+0x95/0xad >> acpi_ut_callocate+0x37/0x79 > > I know, it is scary, but it is also known and harmless. You can ignore > this one. Now _that_ made me raise an eyebrow. Even more than the fact that my DSDT insists on checking for the version of Microsoft Windows I'm running! >>ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, >>low) -> IRQ 11 >>ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, >>low) -> IRQ 11 >>Restarting tasks... done >> >>Both cases looks identical. /proc/interrupts doesn't list 11 as an >>interrupt ?!? > > Talk to acpi people about that. Well, acpi-devel is on the CC list. Hopefully somebody will read. [--snip--] >>Anyhow, suspended twice to ram now in succession, make cleaned and >>rebuilt the kernel, installed it, and the only thing that even suggests >>there is a glitch is that trace. >> >>Looks like I need APIC on and IO-APIC off. Any explanations very >>welcome: and don't tell me the IO-APIC is buggy - I've been running >>with both those options on for as long as I've had this notebook now. > > I do not know enough explanations, feel free to investigate. Not right now. The festive season awaits (yay ...). So in that spirit, Merry Christmas and a Happy New Year! > Anyway so both suspend-to-ram and suspend-to-disk now works for you, > right? No need to press keys to make it write image on disk? How did you know about the key? Yes, it now correctly goes away and comes back up. Guess I'm going to get rid of hibernate though and use my own custom scripts though. > Oh and thanks for video.txt diff, applied. Shees. That is my second accepted patch in a week. Also my first two accepted patches. LOL. Hopefully there will be more to come. Now I need to get my notebook back to a "user-friendly" state. Thanks for all the help and all the patience from everyone. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-24 12:49:37
|
Hi! > I presume you're looking for ide0 and ide1 interrupts, yes, after > suspending to ram twice the command showed that interrupt 14 (ide0) > increased from 994 to 1011 and for 15 (ide1) it stayed at 24. My hdd is > on hda so that'll be on ide0, dvd-rw is on hdc or ide1. > > The interrupt counts for cascade (irq 2), rtc (irq 8) and acpi (irq 9) > stayed constant though, at 0, 2 and 4 respectively. > > No NMI or ERR conditions were ever signaled. > > Now, with APIC, but no IO-APIC there is a bug notice during resume. > Going to type it over (from dmesg): > > Back to C! > Debug: sleeping function called from invalid context at mm/slab.c:2472 > in_atomic():0, irqs_disabled():1 > __might_sleep+0x9e/0xa6 > acpi_os_allocate+0x15/0x26 > kmem_cache_alloc+0x95/0xad > acpi_ut_callocate+0x37/0x79 I know, it is scary, but it is also known and harmless. You can ignore this one. > ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, > low) -> IRQ 11 > ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, > low) -> IRQ 11 > Restarting tasks... done > > Both cases looks identical. /proc/interrupts doesn't list 11 as an > interrupt ?!? Talk to acpi people about that. > Also, this time round the auto-repeat on the keys is working again after > resume. In fact, everything seems to be working. Just that debug > stacktrace that bothers me. Oh, and my console blanking time also seems > to get lost but I can fix that with the help of echo and /dev/tty*. Good. > Anyhow, suspended twice to ram now in succession, make cleaned and > rebuilt the kernel, installed it, and the only thing that even suggests > there is a glitch is that trace. > > Looks like I need APIC on and IO-APIC off. Any explanations very > welcome: and don't tell me the IO-APIC is buggy - I've been running > with both those options on for as long as I've had this notebook now. I do not know enough explanations, feel free to investigate. Anyway so both suspend-to-ram and suspend-to-disk now works for you, right? No need to press keys to make it write image on disk? Oh and thanks for video.txt diff, applied. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-24 12:43:55
|
Pavel Machek wrote: > Hi! > > >>Damn. I just thought I solved it. I disabled the APIC and tried again. >> This time round I managed to re-enable APIC in the kernel source >>(without IO-APIC) and _recompile_ it entirely. Only upon issueing "make >>install modules_install" did it pop. >> >>Sequence was something like: >> >>echo mem > /sys/power/state >>cd /usr/src/linux >>make menuconfig >>make menuconfig >>echo mem > /sys/power/state >>make menuconfig >>--> re-enable APIC but not IO-APIC >>make >>make install modules_install >>->> pop. When copying the image from the source directory to /boot. >> >>This is beginning to sound more and more like some obscure >>race-condition if you ask me. > > > I would be surprised if that was the case. Are you sure it is not just > "disk does not work after resume", and depending of stuff in cache, it > fails at random places? Yes. If the first thing I do after boot is "echo mem > /sys/power/state", then how can tools like dmesg, make, gcc, cat and even ls be in the cache? -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Jaco K. <ja...@kr...> - 2005-12-24 12:41:46
|
Pavel Machek wrote: > Hi! > > >>>>>Okay, what *other* patches do you have installed? What kernel are you >>>>>running? 2.6.15-rc6? >>>> >>>>I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can >>>>always get the VI patch to rc6). Was intending to run the acpi_include >>>>patch, but since that is a standard option in 2.6.14.x I never actually >>>>pulled in that patch, so no other patches and I've backed out suspend2 >>>>now. Will also give 15rc6 a go in the morning. >>> >>>rc5 should be good enough. >> >>Same problem. SysRq+T reveals that the newly spawned process is getting >>stuck in: >> >>ide_do_request+0x18a/0x3c5 >>io_schedule+0xe/0x16 >>sync_page+0x3e/0x4b >>__wait_on_bit_lock+0x41/0x61 >>sync_page+0x0/0x4b >>__lock_page+0x9d/0xb1 >>wake_bit_function+0x0/0x55 >>wake_bit_function+0x0/0x55 >>do_generic_mapping_read+0x335/0x7fd >>__generic_file_aio_read+0x19d/0x203 >>file_read_actor+0x0/0xfa >>generic_file_read+0xba/0xd8 >>autoremove_wake_function+0x0/0x57 >>vfs_read+0x1a5/0x1aa >>kernel_read+0x50/0x5f >>prepare_binprm+0xd8/0x103 >>do_execve+0xfe/0x203 >>sys_execve+0x3c/0x6f >>sysenter_past_esp+0x54/0x75 >> >>Second run round the first command I issued worked fine, as did cd to >>/usr/src/linux, but running make menuconfig failed. This time the stack >>trace was considerably longer (I'm not going to type that over). The >>top two calls are the same, but it comes in from sync_buffer, >>__wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, >>wake_bit_function, wakebit_function, and so forth. A quick scan of the >>VI between rc5 and rc6 doesn't reveal any changes that could possibly >>affect this (I'm going to patch to rc6 in any case). >> >>Could it be a bug in reiserfs? I have run a fsck but no errors were >>found, so I presume the fs is still in tact. > > Seife is right, this looks like an ide problem. And the fact that > autorepeat does not work for you may mean something bad with > interrupts. Can you try "noapic"? See my other mail. >>>>Will do if I get it working. more-or-less is simply not good enough (or >>>>should I just make a note there?). >>> >>>It is good enough for video.txt. It describes how to get _video_ >>>working, and video works just ok for you. >> >>You should have received the patch. > > I don't see it here. Can you just attach it to this discussion? It > should be small enough... http://sourceforge.net/mailarchive/forum.php?thread_id=9313913&forum_id=6102 -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Jaco K. <ja...@kr...> - 2005-12-24 12:33:36
|
Pavel Machek wrote: > Hi! > > >>>I have a Vaio which has the same ide problem (at least I think so): >>>after resume, all processes wishing to access the disk hang, >>>dmesg shows lots of "hda: lost interrupt" messages. >>>However, doing a "hdparm -w /dev/hda" after resume makes everything >>>work again. >>> >> >>>From the man page: >> >> -w Perform a device reset (DANGEROUS). Do NOT use this >>option. It >> exists for unlikely situations where a reboot might >>otherwise be >> required to get a confused drive back into a useable state. >> >>Ok. I don't have really important data on the notebook atm (all backed >>up for obvious reasons). So I gave this a try. It causes the kernel to >>crash entirely. No more SysRq. No OOPS. Nothing. It outputs a single >>string namely "/dev/hda:" and then dies. > > > Try verifying that your interrupts work after resume. (I assume we are > still talking suspend-to-RAM here, and that you got suspend-to-disk to > more or less work?) Do cat /proc/interrupts; sleep 10; cat > /proc/interrupts both before and after suspend. I presume you're looking for ide0 and ide1 interrupts, yes, after suspending to ram twice the command showed that interrupt 14 (ide0) increased from 994 to 1011 and for 15 (ide1) it stayed at 24. My hdd is on hda so that'll be on ide0, dvd-rw is on hdc or ide1. The interrupt counts for cascade (irq 2), rtc (irq 8) and acpi (irq 9) stayed constant though, at 0, 2 and 4 respectively. No NMI or ERR conditions were ever signaled. Now, with APIC, but no IO-APIC there is a bug notice during resume. Going to type it over (from dmesg): Back to C! Debug: sleeping function called from invalid context at mm/slab.c:2472 in_atomic():0, irqs_disabled():1 __might_sleep+0x9e/0xa6 acpi_os_allocate+0x15/0x26 kmem_cache_alloc+0x95/0xad acpi_ut_callocate+0x37/0x79 acpi_os_acquire_object+0xf/0x3c acpi_ut_allocate_object_desc_dbg+0xc/0x49 acpi_ut_create_internal_object_dbg+0x18/0x6d acpi_rs_set_srs_method_data+0x41/0xc kmem_cache_alloc+0x6d/0xad acpi_pci_link_set+0x4c/0x1ad acpi_pci_link_set+0x126/0x1ad acpi_pci_link_resume+0x22/0x28 irqrouters_resume+0x25/0x38 __sysdev_resume+0x3d/0x71 sysdev_resume+0x38/0x5e device_power_up+0x5/0xa suspend_enter+0x36/0x54 enter_state+0x49/0x8a state_store+0x9a/0xad subsys_attr_store+0x37/0x40 flush_write_buffer+0x3e/0x4a sysfs_write_file+0x6b/0x92 vfs_write+0x1a5/0x1aa sys_write+0x51/0x80 sysenter_past_esp+0x54/0x75 ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11 Restarting tasks... done Both cases looks identical. /proc/interrupts doesn't list 11 as an interrupt ?!? Also, this time round the auto-repeat on the keys is working again after resume. In fact, everything seems to be working. Just that debug stacktrace that bothers me. Oh, and my console blanking time also seems to get lost but I can fix that with the help of echo and /dev/tty*. Anyhow, suspended twice to ram now in succession, make cleaned and rebuilt the kernel, installed it, and the only thing that even suggests there is a glitch is that trace. Looks like I need APIC on and IO-APIC off. Any explanations very welcome: and don't tell me the IO-APIC is buggy - I've been running with both those options on for as long as I've had this notebook now. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |