Linux/ACPI 2.4 release status

Linux/ACPI 2.4 release status

[Len Brown]

Folks,
2.4.23 shipped -- and I'd like to thank all of you for helping build the
best stable ACPI kernel yet!

There is a new 2.4.24 BK tree on bkbits and corresponding patch
directory on kernel.org (below).  The latest ACPI patch integrated with
2.4.24 will live there.  At the same time, I'll also export the latest
ACPI patch backported to the 2.4.22 and 2.4.23 BK trees and patch
directories.

The latest patch (below) contains two ACPICA updates, as well as a
handful of other patches.  Please try it out and let me know how it
goes.

Yes, this is a good time to remind me about, or update and re-send
patches that we were not able to handle in time for 2.4.23.

thanks,
-Len
----

bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.24
or
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.24-pre1/acpi-20031203-2.4.24-pre1.diff.gz

This will update the following files:

 arch/i386/kernel/mpparse.c         |    8 -
 arch/i386/kernel/smpboot.c         |    2 
 drivers/acpi/Config.in             |    3 
 drivers/acpi/dispatcher/dsinit.c   |    4 
 drivers/acpi/dispatcher/dsmethod.c |    4 
 drivers/acpi/dispatcher/dsmthdat.c |   45 ++++--
 drivers/acpi/dispatcher/dsopcode.c |   22 +-
 drivers/acpi/dispatcher/dswexec.c  |   22 ++
 drivers/acpi/dispatcher/dswload.c  |    8 -
 drivers/acpi/dispatcher/dswscope.c |    8 -
 drivers/acpi/events/evgpe.c        |   59 +++-----
 drivers/acpi/events/evgpeblk.c     |    5 
 drivers/acpi/events/evmisc.c       |    3 
 drivers/acpi/events/evregion.c     |  134 ++++++++++++------
 drivers/acpi/events/evrgnini.c     |   32 +++-
 drivers/acpi/events/evxfregn.c     |   24 ++-
 drivers/acpi/executer/exdump.c     |   50 +++---
 drivers/acpi/executer/exfldio.c    |  184 ++++++++++++-------------
 drivers/acpi/executer/exmisc.c     |    6 
 drivers/acpi/executer/exmutex.c    |   12 -
 drivers/acpi/executer/exoparg1.c   |    3 
 drivers/acpi/executer/exoparg3.c   |    5 
 drivers/acpi/executer/exprep.c     |    4 
 drivers/acpi/executer/exregion.c   |   10 -
 drivers/acpi/executer/exresolv.c   |    6 
 drivers/acpi/executer/exresop.c    |    4 
 drivers/acpi/executer/exstore.c    |    3 
 drivers/acpi/executer/exsystem.c   |   21 ++
 drivers/acpi/hardware/hwacpi.c     |   13 -
 drivers/acpi/hardware/hwregs.c     |   12 -
 drivers/acpi/hardware/hwsleep.c    |   89 ++++++++----
 drivers/acpi/namespace/nsaccess.c  |    8 -
 drivers/acpi/namespace/nsalloc.c   |    7 
 drivers/acpi/namespace/nsdump.c    |   37 ++---
 drivers/acpi/namespace/nsdumpdv.c  |    2 
 drivers/acpi/namespace/nsinit.c    |   63 +++++---
 drivers/acpi/namespace/nsobject.c  |    7 
 drivers/acpi/namespace/nssearch.c  |    4 
 drivers/acpi/namespace/nsutils.c   |    6 
 drivers/acpi/namespace/nsxfname.c  |    2 
 drivers/acpi/parser/psargs.c       |    4 
 drivers/acpi/parser/psparse.c      |    4 
 drivers/acpi/parser/psxface.c      |   34 +++-
 drivers/acpi/processor.c           |   73 ++++++++-
 drivers/acpi/resources/rscalc.c    |    4 
 drivers/acpi/resources/rscreate.c  |    2 
 drivers/acpi/resources/rsdump.c    |   18 --
 drivers/acpi/resources/rsirq.c     |   38 ++---
 drivers/acpi/resources/rslist.c    |    4 
 drivers/acpi/tables.c              |   30 ++--
 drivers/acpi/tables/tbget.c        |   10 -
 drivers/acpi/tables/tbgetall.c     |    3 
 drivers/acpi/tables/tbrsdt.c       |    3 
 drivers/acpi/tables/tbxface.c      |    2 
 drivers/acpi/tables/tbxfroot.c     |    3 
 drivers/acpi/thermal.c             |    1 
 drivers/acpi/utilities/utalloc.c   |   55 -------
 drivers/acpi/utilities/utdebug.c   |    2 
 drivers/acpi/utilities/utdelete.c  |    4 
 drivers/acpi/utilities/uteval.c    |    4 
 drivers/acpi/utilities/utglobal.c  |   99 +++++++++++++
 drivers/acpi/utilities/utobject.c  |   28 ---
 include/acpi/acconfig.h            |    4 
 include/acpi/acevents.h            |   11 +
 include/acpi/acglobal.h            |    3 
 include/acpi/acmacros.h            |   27 +--
 include/acpi/acobject.h            |   35 ++--
 include/acpi/acutils.h             |    8 +
 68 files changed, 884 insertions(+), 570 deletions(-)

through these ChangeSets:

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1063.46.61)
   [ACPI] Update Linux to ACPICA 20031203 (Bob Moore)
   
   Changed the initialization of Operation Regions during subsystem init
to
   perform two entire walks of the ACPI namespace; The first to
initialize
   the regions themselves, the second to execute the _REG methods.  This
   fixed some interdependencies across _REG methods found on some
machines.
   
   Fixed a problem where a Store(Local0, Local1) could simply update the
   object reference count, and not create a new copy of the object if
the
   Local1 is uninitialized.
   
   Implemented support for the _SST reserved method during sleep
   transitions.
   
   Implemented support to clear the SLP_TYP and SLP_EN bits when waking
up,
   this is apparently required by some machines.
   
   When sleeping, clear the wake status only if SleepState is not S5.
   
   Fixed a problem in AcpiRsExtendedIrqResource() where an incorrect
   pointer arithmetic advanced a string pointer too far.
   
   Fixed a problem in AcpiTbGetTablePtr() where a garbage pointer could
be
   returned if the requested table has not been loaded.
   
   Within the support for IRQ resources, restructured the handling of
the
   active and edge/level bits.
   
   Fixed a few problems in AcpiPsxExecute() where memory could be leaked
   under certain error conditions.
   
   Improved error messages for the cases where the ACPI mode could not
be
   entered.

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1063.46.60)
   [ACPI] update Linux to ACPICA 20031029 (Bob Moore)
   
   Fixed a problem where a level-triggered GPE with an associated _Lxx
   control method was incorrectly cleared twice.
   
   Fixed a problem with the Field support code where an access can occur
   beyond the end-of-region if the field is non-aligned but extends to
the
   very end of the parent region (resulted in an AE_AML_REGION_LIMIT
   exception.)
   
   Fixed a problem with ACPI Fixed Events where an RT Clock handler
would
   not get invoked on an RTC event.  The RTC event bitmasks for the PM1
   registers were not being initialized properly.
   
   Implemented support for executing _STA and _INI methods for Processor
   objects.  Although this is currently not part of the ACPI
specification,
   there is existing ASL code that depends on the init-time execution of
   these methods.
   
   Implemented and deployed a GetDescriptorName function to decode the
   various types of internal descriptors.  Guards against null
descriptors
   during debug output also.
   
   Implemented and deployed a GetNodeName function to extract the
   4-character namespace node name.  This function simplifies the debug
and
   error output, as well as guarding against null pointers during
output.
   
   Implemented and deployed the ACPI_FORMAT_UINT64 helper macro to
simplify
   the debug and error output of 64-bit integers.  This macro replaces
the
   HIDWORD and LODWORD macros for dumping these integers.
   
   Updated the implementation of the Stall() operator to only call
   AcpiOsStall(), and also return an error if the operand is larger than
   255.  This preserves the required behavior of not relinquishing the
   processor, as would happen if AcpiOsSleep() was called for "long
   stalls".
   
   Constructs of the form "Store(LocalX,LocalX)" where LocalX is not
   initialized are now treated as NOOPs.
   
   Cleaned up a handful of warnings during 64-bit generation.
   
   Fixed a reported error where and incorrect GPE number was passed to
the
   GPE dispatch handler.  This value is only used for error output,
   however.  Used this opportunity to clean up and streamline the GPE
   dispatch code.

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1063.46.59)
   [ACPI] revert two fixes in preparation for ACPICA merge

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/10 1.1063.46.58)
   [ACPI] set APIC ACPI SCI OVR default to level/low
     http://bugzilla.kernel.org/show_bug.cgi?id=1351

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/10 1.1063.46.57)
   [ACPI] change hard-coded IO width to programmable width (Shaohua
David Li)
     http://bugzilla.kernel.org/show_bug.cgi?id=1349

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/02 1.1063.46.56)
   [ACPI] add warning to thermal shutdown (Pavel Machek)

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/02 1.1063.46.55)
   [ACPI] handle sparse APIC-IDs in the face of reduced NR_CPUS

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/20 1.1063.46.54)
   [ACPI]  fix xconfig failure (Matt Wilcox)
   http://bugzilla.kernel.org/show_bug.cgi?id=1568
   






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Sérgio Monteiro Basto]

Hi Len


On Fri, 2003-12-12 at 06:15, Len Brown wrote:
> Folks,
> 2.4.23 shipped -- and I'd like to thank all of you for helping build the
> best stable ACPI kernel yet!

yes in my laptop it is very stable too. thanks


> Yes, this is a good time to remind me about, or update and re-send
> patches that we were not able to handle in time for 2.4.23.
> 

have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels.
or does anybody have any implantation of cpufreq for kernel 2.4.23? 

-- 
Sérgio M B




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Karol Kozimor]

Thus wrote Sérgio Monteiro Basto:
> have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels.
> or does anybody have any implantation of cpufreq for kernel 2.4.23? 

Current snapshots of CPUFreq (both for 2.4 and 2.6) can be found here:
http://ftp.linux.org.uk/pub/linux/cpufreq/

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: Linux/ACPI 2.4 release status and cpufreq

[Ow Mun Heng]

> -----Original Message-----
> From: Sérgio Monteiro Basto [mailto:sergiomb-hHo3WeeoaswVhHzd4jOs4w@public.gmane.org]
> Sent: Saturday, December 13, 2003 1:06 AM
> To: Len Brown
> Cc: ACPI Developers
> Subject: Re: [ACPI] Linux/ACPI 2.4 release status and cpufreq
>
> have you any plan? to integrated cpufreq that cames in 
> 2.22-ac4 kernels.
> or does anybody have any implantation of cpufreq for kernel 2.4.23? 

I've made a patch for the 2.4.23 kernel for cpufreq. It's a patch to the
vanilla 2.4.23 kernel from kernel.org. I'm using it right now on my lappy.

if you want it, mail me off-line

OW


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[wwp]

Hi Ow Mun Heng,


On Mon, 15 Dec 2003 09:26:48 +0800 "Ow Mun Heng" <ow.mun.heng-Sjgp3cTcYWE@public.gmane.org> wrote:

> > -----Original Message-----
> > From: Sérgio Monteiro Basto [mailto:sergiomb-hHo3WeeoaswVhHzd4jOs4w@public.gmane.org]
> > Sent: Saturday, December 13, 2003 1:06 AM
> > To: Len Brown
> > Cc: ACPI Developers
> > Subject: Re: [ACPI] Linux/ACPI 2.4 release status and cpufreq
> >
> > have you any plan? to integrated cpufreq that cames in 
> > 2.22-ac4 kernels.
> > or does anybody have any implantation of cpufreq for kernel 2.4.23? 
> 
> I've made a patch for the 2.4.23 kernel for cpufreq. It's a patch to the
> vanilla 2.4.23 kernel from kernel.org. I'm using it right now on my lappy.
> 
> if you want it, mail me off-line

Is cpufreq something equivalent to Intel´s eist (speedstep)?


Regards,

-- 
wwp


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: Linux/ACPI 2.4 release status and cpufreq

[Ow Mun Heng]

> -----Original Message-----
> From: wwp [mailto:subscript-GANU6spQydw@public.gmane.org]
> Sent: Monday, December 15, 2003 4:01 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] Linux/ACPI 2.4 release status and cpufreq

> 
> Is cpufreq something equivalent to Intel´s eist (speedstep)?
> 

Yes.. It's a Open Source implementation of that.. I've not/never tried the
intel version speedstep.. 


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Micha Feigin]

On Mon, Dec 15, 2003 at 09:26:48AM +0800, Ow Mun Heng wrote:
> 
> 
> > -----Original Message-----
> > From: S?rgio Monteiro Basto [mailto:sergiomb-hHo3WeeoaswVhHzd4jOs4w@public.gmane.org]
> > Sent: Saturday, December 13, 2003 1:06 AM
> > To: Len Brown
> > Cc: ACPI Developers
> > Subject: Re: [ACPI] Linux/ACPI 2.4 release status and cpufreq
> >
> > have you any plan? to integrated cpufreq that cames in 
> > 2.22-ac4 kernels.
> > or does anybody have any implantation of cpufreq for kernel 2.4.23? 
> 
> I've made a patch for the 2.4.23 kernel for cpufreq. It's a patch to the
> vanilla 2.4.23 kernel from kernel.org. I'm using it right now on my lappy.
> 
> if you want it, mail me off-line
> 
> OW

The cvs version (iirc mentioned earlier in this thread, otherwise
search the archives) applied cleanly to 2.4.23 last time I checked.

> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Luca Capello]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

on 12/15/03 12:26, Micha Feigin wrote:
| The cvs version (iirc mentioned earlier in this thread, otherwise
| search the archives) applied cleanly to 2.4.23 last time I checked.
well, I just got an error applying the latest 'cpufreq' from
	http://ftp.linux.org.uk/pub/linux/cpufreq/

Here's the error (I used a fresh 2.4.23 with the latest ACPI patch):
| gismo:/usr/src/linux-2.4.23# bunzip2 -c
../kernel/cpufreq-LINUX_2_4-20031215.tar.bz2 | patch -p1
| missing header for unified diff at line 57 of patch
| patching file Documentation/00-INDEX
| patching file Documentation/Configure.help
| patching file Makefile
| patching file arch/i386/boot/setup.S
| patching file arch/i386/config.in
| patching file arch/i386/kernel/Makefile
| patching file arch/i386/kernel/i386_ksyms.c
| patching file arch/i386/kernel/setup.c
| patching file arch/i386/kernel/time.c
| patching file drivers/Makefile
| patching file include/asm-i386/ist.h
| patching file include/asm-i386/msr.h
| patching file include/asm-i386/smp.h
| patching file include/linux/smp.h
| patch unexpectedly ends in middle of line
| gismo:/usr/src/linux-2.4.23#

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE/3Z42VAp7Xm10JmkRAjl6AJ956SUyP5EK5YxIntR9lLdaD3igDQCfYNsw
FH5MhlkTBT/le4358VeqbA4=
=azW0
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[wwp]

Hi Luca Capello,


On Mon, 15 Dec 2003 12:42:47 +0100 Luca Capello <luca-wlebWZzHoyE@public.gmane.org> wrote:

> Hello,
> 
> on 12/15/03 12:26, Micha Feigin wrote:
> | The cvs version (iirc mentioned earlier in this thread, otherwise
> | search the archives) applied cleanly to 2.4.23 last time I checked.
> well, I just got an error applying the latest 'cpufreq' from
> 	http://ftp.linux.org.uk/pub/linux/cpufreq/
> 
> Here's the error (I used a fresh 2.4.23 with the latest ACPI patch):
> | gismo:/usr/src/linux-2.4.23# bunzip2 -c
> ../kernel/cpufreq-LINUX_2_4-20031215.tar.bz2 | patch -p1
> | missing header for unified diff at line 57 of patch
> | patching file Documentation/00-INDEX
> | patching file Documentation/Configure.help
> | patching file Makefile
> | patching file arch/i386/boot/setup.S
> | patching file arch/i386/config.in
> | patching file arch/i386/kernel/Makefile
> | patching file arch/i386/kernel/i386_ksyms.c
> | patching file arch/i386/kernel/setup.c
> | patching file arch/i386/kernel/time.c
> | patching file drivers/Makefile
> | patching file include/asm-i386/ist.h
> | patching file include/asm-i386/msr.h
> | patching file include/asm-i386/smp.h
> | patching file include/linux/smp.h
> | patch unexpectedly ends in middle of line
> | gismo:/usr/src/linux-2.4.23#

Using cpufreq-LINUX_2_4-20031215.tar.bz2, patching manually
w/ `patch -p1 --dry-run < patch` against a 2.4.33+acpi+ieee1394+
other-various-patches:

patching file Documentation/00-INDEX
patching file Documentation/Configure.help
patching file Makefile
patching file arch/i386/boot/setup.S
patching file arch/i386/config.in
patching file arch/i386/kernel/Makefile
patching file arch/i386/kernel/i386_ksyms.c
patching file arch/i386/kernel/setup.c
patching file arch/i386/kernel/time.c
patching file drivers/Makefile
patching file include/asm-i386/ist.h
patching file include/asm-i386/msr.h
patching file include/asm-i386/smp.h
patching file include/linux/smp.h

Seems OK here.


Regards,

-- 
wwp


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Luca Capello]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

on 12/15/03 12:59, wwp wrote:
| Using cpufreq-LINUX_2_4-20031215.tar.bz2, patching manually
| w/ `patch -p1 --dry-run < patch` against a 2.4.33+acpi+ieee1394+
| other-various-patches:
this sounds quite strange, because here:

| gismo:/usr/src/linux-2.4.23# patch -p1 --dry-run <
cpufreq-LINUX_2_4-20031215.tar.bz2
| patch unexpectedly ends in middle of line
| patch: **** Only garbage was found in the patch input.
| gismo:/usr/src/linux-2.4.23#

of the same

| gismo:/usr/src/linux-2.4.23# patch -p1 --dry-run <
cpufreq-LINUX_2_4-20031215.tar
| missing header for unified diff at line 57 of patch
| patching file Documentation/00-INDEX
| patching file Documentation/Configure.help
| patching file Makefile
| patching file arch/i386/boot/setup.S
| patching file arch/i386/config.in
| patching file arch/i386/kernel/Makefile
| patching file arch/i386/kernel/i386_ksyms.c
| patching file arch/i386/kernel/setup.c
| patching file arch/i386/kernel/time.c
| patching file drivers/Makefile
| patching file include/asm-i386/ist.h
| patching file include/asm-i386/msr.h
| patching file include/asm-i386/smp.h
| patching file include/linux/smp.h
| patch unexpectedly ends in middle of line
| gismo:/usr/src/linux-2.4.23#

Anyway, I made some tests:
- - I've always the problem above if I use the command
	bunzip2/gunzip -c [patch].bz2/gz | patch -p1

- - if I bunzip2/gunzip + untar (so 'tar xvf[j|z]') and then I use the
manual patching script present in the 'cpufreq' package, all goes well

As this is the only patch which doesn't work on my system, I think
there's a problem in the patch, but maybe as I'm on Debian unstable,
there could be some bugs on my machine.

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE/3cBGVAp7Xm10JmkRAgqeAJ42124ybVwEjgiXy0VBpYVP7T8ieACffhZZ
hMhWLK57AiBrqz5vLTE/Qfw=
=ta8/
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Karol Kozimor]

Thus wrote Luca Capello:
> As this is the only patch which doesn't work on my system, I think
> there's a problem in the patch, but maybe as I'm on Debian unstable,
> there could be some bugs on my machine.

It's because it's not a patch. It's a bzipped *tar* archive (note .tar.bz2)
as opposed to a bzipped patch (.bz2). Untar it and proceed according to
instructions.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Micha Feigin]

On Mon, Dec 15, 2003 at 12:42:47PM +0100, Luca Capello wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> on 12/15/03 12:26, Micha Feigin wrote:
> | The cvs version (iirc mentioned earlier in this thread, otherwise
> | search the archives) applied cleanly to 2.4.23 last time I checked.
> well, I just got an error applying the latest 'cpufreq' from
> 	http://ftp.linux.org.uk/pub/linux/cpufreq/
> 
> Here's the error (I used a fresh 2.4.23 with the latest ACPI patch):
> | gismo:/usr/src/linux-2.4.23# bunzip2 -c
> ../kernel/cpufreq-LINUX_2_4-20031215.tar.bz2 | patch -p1

If you'll notice the file is a tar.bz2 and not just bz2.
What you need to do is
tar -xjf cpufreq-LINUX_2_4-20031215.tar.bz2
cd cpufreq
./patchin.sh <kernel-dir>
This will patch you're kernel and add links to the cpufreq files.

> | missing header for unified diff at line 57 of patch
> | patching file Documentation/00-INDEX
> | patching file Documentation/Configure.help
> | patching file Makefile
> | patching file arch/i386/boot/setup.S
> | patching file arch/i386/config.in
> | patching file arch/i386/kernel/Makefile
> | patching file arch/i386/kernel/i386_ksyms.c
> | patching file arch/i386/kernel/setup.c
> | patching file arch/i386/kernel/time.c
> | patching file drivers/Makefile
> | patching file include/asm-i386/ist.h
> | patching file include/asm-i386/msr.h
> | patching file include/asm-i386/smp.h
> | patching file include/linux/smp.h
> | patch unexpectedly ends in middle of line
> | gismo:/usr/src/linux-2.4.23#
> 
> Thx, bye,
> Gismo / Luca
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
> 
> iD8DBQE/3Z42VAp7Xm10JmkRAjl6AJ956SUyP5EK5YxIntR9lLdaD3igDQCfYNsw
> FH5MhlkTBT/le4358VeqbA4=
> =azW0
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Micha Feigin]

On Mon, Dec 15, 2003 at 03:08:07PM +0100, Luca Capello wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> on 12/15/03 12:59, wwp wrote:
> | Using cpufreq-LINUX_2_4-20031215.tar.bz2, patching manually
> | w/ `patch -p1 --dry-run < patch` against a 2.4.33+acpi+ieee1394+
> | other-various-patches:
> this sounds quite strange, because here:
> 
> | gismo:/usr/src/linux-2.4.23# patch -p1 --dry-run <
> cpufreq-LINUX_2_4-20031215.tar.bz2
> | patch unexpectedly ends in middle of line
> | patch: **** Only garbage was found in the patch input.
> | gismo:/usr/src/linux-2.4.23#
> 
> of the same
> 
> | gismo:/usr/src/linux-2.4.23# patch -p1 --dry-run <
> cpufreq-LINUX_2_4-20031215.tar
> | missing header for unified diff at line 57 of patch
> | patching file Documentation/00-INDEX
> | patching file Documentation/Configure.help
> | patching file Makefile
> | patching file arch/i386/boot/setup.S
> | patching file arch/i386/config.in
> | patching file arch/i386/kernel/Makefile
> | patching file arch/i386/kernel/i386_ksyms.c
> | patching file arch/i386/kernel/setup.c
> | patching file arch/i386/kernel/time.c
> | patching file drivers/Makefile
> | patching file include/asm-i386/ist.h
> | patching file include/asm-i386/msr.h
> | patching file include/asm-i386/smp.h
> | patching file include/linux/smp.h
> | patch unexpectedly ends in middle of line
> | gismo:/usr/src/linux-2.4.23#
> 
> Anyway, I made some tests:
> - - I've always the problem above if I use the command
> 	bunzip2/gunzip -c [patch].bz2/gz | patch -p1
> 
> - - if I bunzip2/gunzip + untar (so 'tar xvf[j|z]') and then I use the
> manual patching script present in the 'cpufreq' package, all goes well
> 

Thats because if you just bunzip2/gunzip -c [patch].bz2/gz | patch -p1
you get the raw tar file piped into patch and of course patch can't
handle that.
When you untar there is a patch file in the top directory which is the
patch that should be applied and some files that are linked to.

> As this is the only patch which doesn't work on my system, I think
> there's a problem in the patch, but maybe as I'm on Debian unstable,
> there could be some bugs on my machine.
> 

Don't think that its debian unstable since I am using debian unstable
and my system is rock solid (There are the occasional problematic
programs but very rare. Most of the problem is the occasional
dependencies that get update with a delay and require manually resolving
the broken packages on update).
Using the debian kernel with external patches can cause problems though
as there are all sorts of patches added by debian that may collide.
I am using vanilla kernel from www.kernel.org for years now without any
problems.

> Thx, bye,
> Gismo / Luca
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
> 
> iD8DBQE/3cBGVAp7Xm10JmkRAgqeAJ42124ybVwEjgiXy0VBpYVP7T8ieACffhZZ
> hMhWLK57AiBrqz5vLTE/Qfw=
> =ta8/
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Ducrot Bruno]

On Fri, Dec 12, 2003 at 05:06:24PM +0000, Sérgio Monteiro Basto wrote:
> Hi Len
> 
> 
> On Fri, 2003-12-12 at 06:15, Len Brown wrote:
> > Folks,
> > 2.4.23 shipped -- and I'd like to thank all of you for helping build the
> > best stable ACPI kernel yet!
> 
> yes in my laptop it is very stable too. thanks
> 
> 
> > Yes, this is a good time to remind me about, or update and re-send
> > patches that we were not able to handle in time for 2.4.23.
> > 
> 
> have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels.
> or does anybody have any implantation of cpufreq for kernel 2.4.23? 
> 

I don't think it's up to acpi folks to integrate cpufreq.  The 2 works
are definitely different due to the fact that cpufreq claims at
first to be architecture independant (you have to consider arm, sparc,
ppc...).

Of course, an ACPI based cpufreq driver for 2.4 will be fine, and perhaps
an acpi governor based both on input from thermal stuff, load of the system
may be good, who knows.

Note that acpi use cpufreq api in 2.[56].

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status

[Bjorn Helgaas]

On Thursday 11 December 2003 11:15 pm, Len Brown wrote:
> Yes, this is a good time to remind me about, or update and re-send
> patches that we were not able to handle in time for 2.4.23.

Here's one:

This patch against the current 2.4 tree removes a bunch of
ill-advised code I added to get _TRA information from PCI
root bridges.

This was the wrong approach because for one thing, it only
handled one MEM window and one IO window, and root bridges
may have several of each.

This patch can be applied for both 2.4 and 2.5.  ia64 was the
only user of this code, and we no longer need it.  The current
approach is to walk the _CRS in pcibios_scan_root() using
acpi_walk_resources(). 

diff -u -ur 2.4/drivers/acpi/pci_root.c 2.4-patched/drivers/acpi/pci_root.c
--- 2.4/drivers/acpi/pci_root.c	2003-12-15 11:41:51.000000000 -0700
+++ 2.4-patched/drivers/acpi/pci_root.c	2003-12-15 11:41:19.000000000 -0700
@@ -61,8 +61,6 @@
 	acpi_handle		handle;
 	struct acpi_pci_id	id;
 	struct pci_bus		*bus;
-	u64			mem_tra;
-	u64			io_tra;
 };
 
 static LIST_HEAD(acpi_pci_roots);
@@ -114,97 +112,6 @@
 	}
 }
 
-void
-acpi_pci_get_translations (
-	struct acpi_pci_id	*id,
-	u64			*mem_tra,
-	u64			*io_tra)
-{
-	struct list_head	*node = NULL;
-	struct acpi_pci_root	*entry;
-
-	/* TBD: Locking */
-	list_for_each(node, &acpi_pci_roots) {
-		entry = list_entry(node, struct acpi_pci_root, node);
-		if ((id->segment == entry->id.segment)
-			&& (id->bus == entry->id.bus)) {
-			*mem_tra = entry->mem_tra;
-			*io_tra = entry->io_tra;
-			return;
-		}
-	}
-
-	*mem_tra = 0;
-	*io_tra = 0;
-}
-
-
-static u64
-acpi_pci_root_bus_tra (
-       struct acpi_resource	*resource,
-       int			type)
-{
-	struct acpi_resource_address16 *address16;
-	struct acpi_resource_address32 *address32;
-	struct acpi_resource_address64 *address64;
-
-	while (1) {
-		switch (resource->id) {
-		case ACPI_RSTYPE_END_TAG:
-			return 0;
-
-		case ACPI_RSTYPE_ADDRESS16:
-			address16 = (struct acpi_resource_address16 *) &resource->data;
-			if (type == address16->resource_type) {
-				return address16->address_translation_offset;
-			}
-			break;
-
-		case ACPI_RSTYPE_ADDRESS32:
-			address32 = (struct acpi_resource_address32 *) &resource->data;
-			if (type == address32->resource_type) {
-				return address32->address_translation_offset;
-			}
-			break;
-
-		case ACPI_RSTYPE_ADDRESS64:
-			address64 = (struct acpi_resource_address64 *) &resource->data;
-			if (type == address64->resource_type) {
-				return address64->address_translation_offset;
-			}
-			break;
-		}
-		resource = ACPI_PTR_ADD (struct acpi_resource,
-				resource, resource->length);
-	}
-
-	return 0;
-}
-
-
-static int
-acpi_pci_evaluate_crs (
-	struct acpi_pci_root	*root)
-{
-	acpi_status		status;
-	struct acpi_buffer	buffer = {ACPI_ALLOCATE_BUFFER, NULL};
-
-	ACPI_FUNCTION_TRACE("acpi_pci_evaluate_crs");
-
-	status = acpi_get_current_resources (root->handle, &buffer);
-	if (ACPI_FAILURE(status))
-		return_VALUE(-ENODEV);
-
-	root->io_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
-			buffer.pointer, ACPI_IO_RANGE);
-	root->mem_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
-			buffer.pointer, ACPI_MEMORY_RANGE);
-
-	acpi_os_free(buffer.pointer);
-	return_VALUE(0);
-}
-
-
 static int
 acpi_pci_root_add (
 	struct acpi_device	*device)
@@ -289,10 +196,8 @@
 	root->id.function = device->pnp.bus_address & 0xFFFF;
 
 	/*
-	 * Evaluate _CRS to get root bridge resources
 	 * TBD: Need PCI interface for enumeration/configuration of roots.
 	 */
- 	acpi_pci_evaluate_crs(root);
 
  	/* TBD: Locking */
  	list_add_tail(&root->node, &acpi_pci_roots);
diff -u -ur 2.4/include/acpi/acpi_drivers.h 2.4-patched/include/acpi/acpi_drivers.h
--- 2.4/include/acpi/acpi_drivers.h	2003-12-15 11:41:53.000000000 -0700
+++ 2.4-patched/include/acpi/acpi_drivers.h	2003-12-15 11:41:19.000000000 -0700
@@ -162,7 +162,6 @@
 
 int acpi_pci_root_init (void);
 void acpi_pci_root_exit (void);
-void acpi_pci_get_translations (struct acpi_pci_id* id, u64* mem_tra, u64* io_tra);
 
 /* ACPI PCI Interrupt Link (pci_link.c) */
 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status

[Len Brown]

Bjorn.

Is it possible that some ia32 or x86_64 platforms might depend on this
code and miss it because they lack the _CRS walk that ia64 has in
pcibios_scan_root()?


thanks,
-Len

On Mon, 2003-12-15 at 13:46, Bjorn Helgaas wrote:
> On Thursday 11 December 2003 11:15 pm, Len Brown wrote:
> > Yes, this is a good time to remind me about, or update and re-send
> > patches that we were not able to handle in time for 2.4.23.
> 
> Here's one:
> 
> This patch against the current 2.4 tree removes a bunch of
> ill-advised code I added to get _TRA information from PCI
> root bridges.
> 
> This was the wrong approach because for one thing, it only
> handled one MEM window and one IO window, and root bridges
> may have several of each.
> 
> This patch can be applied for both 2.4 and 2.5.  ia64 was the
> only user of this code, and we no longer need it.  The current
> approach is to walk the _CRS in pcibios_scan_root() using
> acpi_walk_resources(). 
> 
> diff -u -ur 2.4/drivers/acpi/pci_root.c 2.4-patched/drivers/acpi/pci_root.c
> --- 2.4/drivers/acpi/pci_root.c	2003-12-15 11:41:51.000000000 -0700
> +++ 2.4-patched/drivers/acpi/pci_root.c	2003-12-15 11:41:19.000000000 -0700
> @@ -61,8 +61,6 @@
>  	acpi_handle		handle;
>  	struct acpi_pci_id	id;
>  	struct pci_bus		*bus;
> -	u64			mem_tra;
> -	u64			io_tra;
>  };
>  
>  static LIST_HEAD(acpi_pci_roots);
> @@ -114,97 +112,6 @@
>  	}
>  }
>  
> -void
> -acpi_pci_get_translations (
> -	struct acpi_pci_id	*id,
> -	u64			*mem_tra,
> -	u64			*io_tra)
> -{
> -	struct list_head	*node = NULL;
> -	struct acpi_pci_root	*entry;
> -
> -	/* TBD: Locking */
> -	list_for_each(node, &acpi_pci_roots) {
> -		entry = list_entry(node, struct acpi_pci_root, node);
> -		if ((id->segment == entry->id.segment)
> -			&& (id->bus == entry->id.bus)) {
> -			*mem_tra = entry->mem_tra;
> -			*io_tra = entry->io_tra;
> -			return;
> -		}
> -	}
> -
> -	*mem_tra = 0;
> -	*io_tra = 0;
> -}
> -
> -
> -static u64
> -acpi_pci_root_bus_tra (
> -       struct acpi_resource	*resource,
> -       int			type)
> -{
> -	struct acpi_resource_address16 *address16;
> -	struct acpi_resource_address32 *address32;
> -	struct acpi_resource_address64 *address64;
> -
> -	while (1) {
> -		switch (resource->id) {
> -		case ACPI_RSTYPE_END_TAG:
> -			return 0;
> -
> -		case ACPI_RSTYPE_ADDRESS16:
> -			address16 = (struct acpi_resource_address16 *) &resource->data;
> -			if (type == address16->resource_type) {
> -				return address16->address_translation_offset;
> -			}
> -			break;
> -
> -		case ACPI_RSTYPE_ADDRESS32:
> -			address32 = (struct acpi_resource_address32 *) &resource->data;
> -			if (type == address32->resource_type) {
> -				return address32->address_translation_offset;
> -			}
> -			break;
> -
> -		case ACPI_RSTYPE_ADDRESS64:
> -			address64 = (struct acpi_resource_address64 *) &resource->data;
> -			if (type == address64->resource_type) {
> -				return address64->address_translation_offset;
> -			}
> -			break;
> -		}
> -		resource = ACPI_PTR_ADD (struct acpi_resource,
> -				resource, resource->length);
> -	}
> -
> -	return 0;
> -}
> -
> -
> -static int
> -acpi_pci_evaluate_crs (
> -	struct acpi_pci_root	*root)
> -{
> -	acpi_status		status;
> -	struct acpi_buffer	buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> -
> -	ACPI_FUNCTION_TRACE("acpi_pci_evaluate_crs");
> -
> -	status = acpi_get_current_resources (root->handle, &buffer);
> -	if (ACPI_FAILURE(status))
> -		return_VALUE(-ENODEV);
> -
> -	root->io_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
> -			buffer.pointer, ACPI_IO_RANGE);
> -	root->mem_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
> -			buffer.pointer, ACPI_MEMORY_RANGE);
> -
> -	acpi_os_free(buffer.pointer);
> -	return_VALUE(0);
> -}
> -
> -
>  static int
>  acpi_pci_root_add (
>  	struct acpi_device	*device)
> @@ -289,10 +196,8 @@
>  	root->id.function = device->pnp.bus_address & 0xFFFF;
>  
>  	/*
> -	 * Evaluate _CRS to get root bridge resources
>  	 * TBD: Need PCI interface for enumeration/configuration of roots.
>  	 */
> - 	acpi_pci_evaluate_crs(root);
>  
>   	/* TBD: Locking */
>   	list_add_tail(&root->node, &acpi_pci_roots);
> diff -u -ur 2.4/include/acpi/acpi_drivers.h 2.4-patched/include/acpi/acpi_drivers.h
> --- 2.4/include/acpi/acpi_drivers.h	2003-12-15 11:41:53.000000000 -0700
> +++ 2.4-patched/include/acpi/acpi_drivers.h	2003-12-15 11:41:19.000000000 -0700
> @@ -162,7 +162,6 @@
>  
>  int acpi_pci_root_init (void);
>  void acpi_pci_root_exit (void);
> -void acpi_pci_get_translations (struct acpi_pci_id* id, u64* mem_tra, u64* io_tra);
>  
>  /* ACPI PCI Interrupt Link (pci_link.c) */
>  
> 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status

[Bjorn Helgaas]

On Monday 15 December 2003 3:50 pm, Len Brown wrote:
> Is it possible that some ia32 or x86_64 platforms might depend on this
> code and miss it because they lack the _CRS walk that ia64 has in
> pcibios_scan_root()?

There are no current users of this code in the standard tree,
according to grep.  And the code is broken in the sense that
it only handles a single MEM and a single IO window, and bridges
often have several MEM windows.

Bjorn



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: Linux/ACPI 2.4 release status and cpufreq

[Ow Mun Heng]

> -----Original Message-----
> From: Luca Capello [mailto:luca-wlebWZzHoyE@public.gmane.org]
> Sent: Monday, December 15, 2003 7:43 PM
> To: ML ACPI-devel
> Subject: Re: [ACPI] Linux/ACPI 2.4 release status and cpufreq
> 
> well, I just got an error applying the latest 'cpufreq' from
> 	http://ftp.linux.org.uk/pub/linux/cpufreq/
> 

Can anyone tell me what's the difference between the 20031215 and the
20031201 release?? (I used the 20031201 patch to patch my 2.4.23 kernel)
There was some errors which was resolved by hand.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

RE: Linux/ACPI 2.4 release status and cpufreq

[Yu, Luming]

>Can anyone tell me what's the difference between the 20031215 and the
>20031201 release?? (I used the 20031201 patch to patch my 2.4.23 kernel)

The difference is :

1c1
< 02 December 2003.  Summary of changes for version 20031202:
---
> 03 December 2003.  Summary of changes for version 20031203: (Includes 20031202)
20a21,24
> Fixed a few problems in AcpiPsxExecute() where memory could be leaked under certain error conditions.
> 
> Improved error messages for the cases where the ACPI mode could not be entered.
> 
32c36,37
< Implemented a fix for the iASL disassembler on 64-bit platforms where a bad index was generated.
---
> Implemented a fix for the iASL disassembler where a bad index was generated.  This was most noticeable on 64-bit platforms
> 

--Luming


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/