How the Linux/ACPI patch flow works
Len Brown <len.brown@...>
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
acpi-devel@...
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 acpi-devel@... 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.brown@... 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
linux-kernel@...
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.brown@...
Thanks,
-Len Brown
Intel Open Source Technology Center

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.

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...

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@...:/proc/acpi# cat alarm
> 2005-12-00 01:03:24
> root@...:/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
sziwan@...

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!

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

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!

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/

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/

Hi, thanks for your reply.
On 12/22/05, Thomas Renninger <trenn@...> 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

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!

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/