ACPI patches updated (20030228)

ACPI patches updated (20030228)

[Grover, Andrew]

Hi all,

The ACPI patches against 2.4 and 2.5 have been updated and are now
available from http://sf.net/project/acpi . The non-Linux-specific
releases should be available from
http://developer.intel.com/technology/iapc/acpi/downloads.htm hopefully
by tonight but possibly as late as Monday evening.

This includes a LOT of fixes for longstanding bugs. If you have had
issues in the past with long delays or oopses on reads from the battery
interface, hangs on boot, or excessive ACPI interrupts causing system
slowness, please try this patch.

The incorrect "mem=" additions are still in these patches, sorry. I will
remove them in the next update.

Regards -- Andy

---------------------------------------
28 February 2003.  Summary of changes for version 20030228.

1) Linux

S3 fixes (Ole Rohne)

Update ACPI PHP driver with to use new acpi_walk_resource API
(Bjorn Helgaas)

(2.5) Add S4BIOS support (Pavel Machek)

Map in entire table before performing checksum (John Stultz)

Expand the mem= cmdline to allow the specification of reserved
and ACPI DATA blocks (Pavel Machek)

Never use ACPI on VISWS

Fix derive_pci_id (Ducrot Bruno, Alvaro Lopez)

Revert a change that allowed P_BLK lengths to be 4 or 5. This is
causing us to think that some systems support C2 when they really
don't.

Do not count processor objects for non-present CPUs (Thanks to
Dominik Brodowski)

2) ACPI CA Core Subsystem:

The GPE handling and dispatch code has been completely overhauled
in preparation for support of GPE Block Devices (ID ACPI0006).
This affects internal data structures and code only; there should
be no differences visible externally.  One new file has been
added, evgpeblk.c

The FADT fields GPE0_BLK_LEN and GPE1_BLK_LEN are now the only
fields that are used to determine the GPE block lengths.  The
REGISTER_BIT_WIDTH field of the X_GPEx_BLK extended address
structures are ignored.  This is per the ACPI specification but
it isn't very clear.  The full 256 Block 0/1 GPEs are now
supported (the use of REGISTER_BIT_WIDTH limited the number of
GPEs to 128).

In the SCI interrupt handler, removed the read of the PM1_CONTROL
register to look at the SCI_EN bit.  On some machines, this read
causes an SMI event and greatly slows down SCI events.  (This may
in fact be the cause of slow battery status response on some
systems.)

Fixed a problem where a store of a NULL string to a package
object could cause the premature deletion of the object.  This
was seen during execution of the battery _BIF method on some
systems, resulting in no battery data being returned.

Added AcpiWalkResources interface to simplify parsing of resource
lists.


-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

Re: ACPI patches updated (20030228)

[Markus Gaugusch]

On Feb 28, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> This includes a LOT of fixes for longstanding bugs. If you have had
> issues in the past with long delays or oopses on reads from the battery
> [...] please try this patch.
I didn't have oopses, but reading the battery on my Sony Vaio FX405 took
0.1 secs kernel time. Unfortunately it is still the same :(
This is 2.4.21pre4 with 20030228 patch.

Anyway, thanks for your effort!

Markus


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ACPI patches updated (20030228)

[Nils Faerber]

On Fri, 28 Feb 2003 12:53:33 -0800
"Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Hi all,
Hi Andrew!

> The ACPI patches against 2.4 and 2.5 have been updated and are now
> available from http://sf.net/project/acpi . The non-Linux-specific
> releases should be available from
> http://developer.intel.com/technology/iapc/acpi/downloads.htm
> hopefully by tonight but possibly as late as Monday evening.
> 
> This includes a LOT of fixes for longstanding bugs. If you have had
> issues in the past with long delays or oopses on reads from the
> battery interface, hangs on boot, or excessive ACPI interrupts causing
> system slowness, please try this patch.

And so I did and am sorry to report that I still see high CPU usage and
delays when trying to read my battery status; machine is Asus L3800C.

> Regards -- Andy
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Ole Rohne]

In my quest to make S3 working on this platform, I've found the
underlying reason why the display is black after a S3: the vga adapter
(ATI Radeon M6 LY) looses its pci configuration and comes back with io
and memory disabled, and BASE_ADDRESS_n, LATENCY_TIMER,
CACHE_LINE_SIZE, and INTERRUPT_LINE containing garbage. At first I
felt let down by the BIOS, but on reading the ACPI spec it seems that
it is up to the OS to enumerate and configure devices on "known" buses.

So far I've tried calling pci_save_state/pci_restore_state from within
the radeonfb pci driver suspend/resume routines. Unfortunately, that
causes the machine to hang, probably just after PCI_COMMAND has been
updated. Alternatively, I've tried rewriting the PCI configuration
from userspace (setpci), which doesn't always hang but now the thing
claims there is nothing connected when I eg reload radeonfb.

Questions:
Is it really the job of the OS to configure PCI devices after a S3 sleep?

What is the reason for the hanging when I try to restore PCI config?

Is it possible that PCI "enumeration" and configuration needs to be
done early, like in real mode or before irqs are enabled?

	Appreciating your suggestions,
        Ole


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Patrick Mochel]

On 4 Mar 2003, Ole Rohne wrote:

> In my quest to make S3 working on this platform, I've found the
> underlying reason why the display is black after a S3: the vga adapter
> (ATI Radeon M6 LY) looses its pci configuration and comes back with io
> and memory disabled, and BASE_ADDRESS_n, LATENCY_TIMER,
> CACHE_LINE_SIZE, and INTERRUPT_LINE containing garbage. At first I
> felt let down by the BIOS, but on reading the ACPI spec it seems that
> it is up to the OS to enumerate and configure devices on "known" buses.
> 
> So far I've tried calling pci_save_state/pci_restore_state from within
> the radeonfb pci driver suspend/resume routines. Unfortunately, that
> causes the machine to hang, probably just after PCI_COMMAND has been
> updated. Alternatively, I've tried rewriting the PCI configuration
> from userspace (setpci), which doesn't always hang but now the thing
> claims there is nothing connected when I eg reload radeonfb.
> 
> Questions:
> Is it really the job of the OS to configure PCI devices after a S3 sleep?

Yes. That's what the suspend()/resume() callbacks are for in the drivers. 

> What is the reason for the hanging when I try to restore PCI config?

I'm not sure. You're definitely writing on something that you shouldn't. 
What are you passing to pci_{save,restore}_state()? Are you giving it a 
buffer or not? 

> Is it possible that PCI "enumeration" and configuration needs to be
> done early, like in real mode or before irqs are enabled?

No. There's no need to do it that early. We should be able to handle most 
(read: sane) devices with interrupts enabled. If there are devices that 
need to be quieted with interrupts off, their resume() methods should do 
so during the first pass (RESUME_POWER_ON).

	-pat



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Ducrot Bruno]

On Tue, Mar 04, 2003 at 02:26:55PM -0600, Patrick Mochel wrote:
> 
> On 4 Mar 2003, Ole Rohne wrote:
> 
> > In my quest to make S3 working on this platform, I've found the
> > underlying reason why the display is black after a S3: the vga adapter
> > (ATI Radeon M6 LY) looses its pci configuration and comes back with io
> > and memory disabled, and BASE_ADDRESS_n, LATENCY_TIMER,
> > CACHE_LINE_SIZE, and INTERRUPT_LINE containing garbage. At first I
> > felt let down by the BIOS, but on reading the ACPI spec it seems that
> > it is up to the OS to enumerate and configure devices on "known" buses.
> > 
> > So far I've tried calling pci_save_state/pci_restore_state from within
> > the radeonfb pci driver suspend/resume routines. Unfortunately, that
> > causes the machine to hang, probably just after PCI_COMMAND has been
> > updated. Alternatively, I've tried rewriting the PCI configuration
> > from userspace (setpci), which doesn't always hang but now the thing
> > claims there is nothing connected when I eg reload radeonfb.
> > 
> > Questions:
> > Is it really the job of the OS to configure PCI devices after a S3 sleep?
> 
> Yes. That's what the suspend()/resume() callbacks are for in the drivers. 
> 
> > What is the reason for the hanging when I try to restore PCI config?
> 
> I'm not sure. You're definitely writing on something that you shouldn't. 
> What are you passing to pci_{save,restore}_state()? Are you giving it a 
> buffer or not? 
> 
> > Is it possible that PCI "enumeration" and configuration needs to be
> > done early, like in real mode or before irqs are enabled?
> 
> No. There's no need to do it that early. We should be able to handle most 
> (read: sane) devices with interrupts enabled. If there are devices that 
> need to be quieted with interrupts off, their resume() methods should do 
> so during the first pass (RESUME_POWER_ON).
> 

There are more things to do when you want to save/restore video devices,
as for example saving the framebuffer.  There are some code already
present in some fb drivers, but for openfirmware use.  Perhaps we
should as well enable them in general.

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Patrick Mochel]

> There are more things to do when you want to save/restore video devices,
> as for example saving the framebuffer.  There are some code already
> present in some fb drivers, but for openfirmware use.  Perhaps we
> should as well enable them in general.

Defintely. However, what I was more concerned with was the fact that there
is a definite hang when writing PCI config space. Getting around that will
enable progess in saving/restoring the rest of the state..

	-pat



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Ducrot Bruno]

On Wed, Mar 05, 2003 at 11:22:24AM -0600, Patrick Mochel wrote:
> 
> > There are more things to do when you want to save/restore video devices,
> > as for example saving the framebuffer.  There are some code already
> > present in some fb drivers, but for openfirmware use.  Perhaps we
> > should as well enable them in general.
> 
> Defintely. However, what I was more concerned with was the fact that there
> is a definite hang when writing PCI config space. Getting around that will
> enable progess in saving/restoring the rest of the state..
> 

Correct.  Perhaps then the bridge between the host and the video device
is not well restored (imo this card is AGP)?

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Ole Rohne]

Patrick Mochel <mochel-3NddpPZAyC0@public.gmane.org> writes:

> Defintely. However, what I was more concerned with was the fact that there
> is a definite hang when writing PCI config space. Getting around that will
> enable progess in saving/restoring the rest of the state..

I've added pci_driver->power_on in and call it during RESUME_POWER_ON
from pci_device_resume. Now I can write PCI config in
radeonfb_power_on without hanging... I'd be able to provide a patch
shortly, unless I'm told this is not the way to do it.

Ole




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Patrick Mochel]

On 6 Mar 2003, Ole Rohne wrote:

> Patrick Mochel <mochel-3NddpPZAyC0@public.gmane.org> writes:
> 
> > Defintely. However, what I was more concerned with was the fact that there
> > is a definite hang when writing PCI config space. Getting around that will
> > enable progess in saving/restoring the rest of the state..
> 
> I've added pci_driver->power_on in and call it during RESUME_POWER_ON
> from pci_device_resume. Now I can write PCI config in
> radeonfb_power_on without hanging... I'd be able to provide a patch
> shortly, unless I'm told this is not the way to do it.

That's great. Do you actually get video back when you do that? 

	-pat



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Fujitsu P2120 S3 resume - no video, lost PCI config, suggestions?

[Ole Rohne]

Patrick Mochel <mochel-3NddpPZAyC0@public.gmane.org> writes:

> That's great. Do you actually get video back when you do that? 

Unfortunately not... 

The Radeon chip apparently needs some intricate initialization
sequence after its power has been removed. Any attempts at fudging it
(based on the stale PowerMac PM code in radeonfb.c) generally results
in hangs on resume.

Bummer!

Ole


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: ACPI patches updated (20030228)

[Takayoshi Kochi]

[-- Attachment #1: Type: Text/Plain, Size: 606 bytes --]

Hi Andy,

> 2) ACPI CA Core Subsystem:
> 
> The GPE handling and dispatch code has been completely overhauled
> in preparation for support of GPE Block Devices (ID ACPI0006).
> This affects internal data structures and code only; there should
> be no differences visible externally.  One new file has been
> added, evgpeblk.c

I found a bug in evgpeblk.c.  If an ACPI hardware has non-zero
based GPE block, sometimes it's ignored.  This patch fixes the
problem.

Also, ACPI_MODULE_NAME should be evgpeblk, not evgpe :)

Thanks,
---
Takayoshi Kochi <kochi-PTg2hmCz6mgYz5ZhgtY7qeqrae++aQT8@public.gmane.org>

[-- Attachment #2: evgpeblk.diff --]
[-- Type: Text/Plain, Size: 770 bytes --]

--- 2421-pre4-acpi/drivers/acpi/events/evgpeblk.c.orig	Wed Mar  5 17:00:15 2003
+++ 2421-pre4-acpi/drivers/acpi/events/evgpeblk.c	Wed Mar  5 17:01:30 2003
@@ -46,7 +46,7 @@
 #include <acpi/acnamesp.h>
 
 #define _COMPONENT          ACPI_EVENTS
-	 ACPI_MODULE_NAME    ("evgpe")
+	 ACPI_MODULE_NAME    ("evgpeblk")
 
 
 /*******************************************************************************
@@ -131,7 +131,7 @@
 	/* Ensure that we have a valid GPE number for this GPE block */
 
 	if ((gpe_number < gpe_block->block_base_number) ||
-		(gpe_number >= (gpe_block->register_count * 8))) {
+		(gpe_number - gpe_block->block_base_number >= (gpe_block->register_count * 8))) {
 		/* Not valid, all we can do here is ignore it */
 
 		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,

RE: ACPI patches updated (20030228)

[Grover, Andrew]

> From: Markus Gaugusch [mailto:markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org] 
> On Feb 28, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> > This includes a LOT of fixes for longstanding bugs. If you have had
> > issues in the past with long delays or oopses on reads from 
> the battery
> > [...] please try this patch.
> I didn't have oopses, but reading the battery on my Sony Vaio 
> FX405 took
> 0.1 secs kernel time. Unfortunately it is still the same :(
> This is 2.4.21pre4 with 20030228 patch.
> 
> Anyway, thanks for your effort!

Is 0.1 sec at all better than it was before?

What does your machine's _BST look like? I wonder if it is calling
Stall() or something.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: ACPI patches updated (20030228)

[Grover, Andrew]

> From: Nils Faerber [mailto:nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org] 
> > This includes a LOT of fixes for longstanding bugs. If you have had
> > issues in the past with long delays or oopses on reads from the
> > battery interface, hangs on boot, or excessive ACPI 
> interrupts causing
> > system slowness, please try this patch.
> 
> And so I did and am sorry to report that I still see high CPU 
> usage and
> delays when trying to read my battery status; machine is Asus L3800C.

What does the ASL for your system's BAT._BST method look like? Something
in there must be causing the problem (obviously) so let's figure out
what.

Thanks -- Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: ACPI patches updated (20030228)

[Karol Kozimor]

Thus wrote Grover, Andrew:
> > From: Nils Faerber [mailto:nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org] 
> > > This includes a LOT of fixes for longstanding bugs. If you have had
> > > issues in the past with long delays or oopses on reads from the
> > > battery interface, hangs on boot, or excessive ACPI 
> > interrupts causing
> > > system slowness, please try this patch.
> > And so I did and am sorry to report that I still see high CPU 
> > usage and
> > delays when trying to read my battery status; machine is Asus L3800C.

[the original mail did not make it to the list, I suppose]

I also have an Asus L3800C, however I neither experience delays, nor CPU
usage when reading battery status. What version of BIOS do you have?
Version 118 should be OK, at least it is with me.
Best regards,

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


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

RE: ACPI patches updated (20030228)

[Grover, Andrew]

> From: Takayoshi Kochi [mailto:kochi-PTg2hmCz6mgYz5ZhgtY7qeqrae++aQT8@public.gmane.org] 
> I found a bug in evgpeblk.c.  If an ACPI hardware has non-zero
> based GPE block, sometimes it's ignored.  This patch fixes the
> problem.
> 
> Also, ACPI_MODULE_NAME should be evgpeblk, not evgpe :)

We found this problem yesterday and were debating whether or not to put
out an interim patch or wait until the next regular release. It is a
fairly significant bug.

Since you've already posted a patch I think we will wait and just point
to your patch as the correct fix for now.

Thanks -- Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: ACPI patches updated (20030228)

[Takayoshi Kochi]

From: "Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

> > I found a bug in evgpeblk.c.  If an ACPI hardware has non-zero
> > based GPE block, sometimes it's ignored.  This patch fixes the
> > problem.
> 
> We found this problem yesterday and were debating whether or not to put
> out an interim patch or wait until the next regular release. It is a
> fairly significant bug.
> 
> Since you've already posted a patch I think we will wait and just point
> to your patch as the correct fix for now.

For 2.5, how about sending the small patch to Linus?

Thanks,
---
Takayoshi Kochi <kochi-PTg2hmCz6mgYz5ZhgtY7qeqrae++aQT8@public.gmane.org>


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com