[PATCH] ACPI: ibm-acpi: improve backlight power handling

[PATCH] ACPI: ibm-acpi: improve backlight power handling

[Henrique de Moraes Holschuh]

Improve the backlight code to emulate as much as possible the power
management events, as we are unable to really power on or power off the
backlight.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
---

 Len, I have added this to the for-upstream/acpi-test branch
 of git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
 for when you pull it.

 drivers/acpi/ibm_acpi.c |    5 ++++-
 drivers/acpi/ibm_acpi.h |    1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index dd36be0..6573d01 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1664,7 +1664,10 @@ static void brightness_exit(void)
 
 static int brightness_update_status(struct backlight_device *bd)
 {
-	return brightness_set(bd->props.brightness);
+	return brightness_set(
+		(bd->props.fb_blank == FB_BLANK_UNBLANK &&
+		 bd->props.power == FB_BLANK_UNBLANK) ?
+				bd->props.brightness : 0);
 }
 
 static int brightness_get(struct backlight_device *bd)
diff --git a/drivers/acpi/ibm_acpi.h b/drivers/acpi/ibm_acpi.h
index 4d0387a..b63c014 100644
--- a/drivers/acpi/ibm_acpi.h
+++ b/drivers/acpi/ibm_acpi.h
@@ -32,6 +32,7 @@
 
 #include <linux/proc_fs.h>
 #include <linux/backlight.h>
+#include <linux/fb.h>
 #include <asm/uaccess.h>
 
 #include <linux/dmi.h>
-- 
1.5.0.1

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[2/6] 2.6.21-rc2: known regressions

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
             http://lkml.org/lkml/2007/2/28/348
Submitter  : Jens Axboe <jens.axboe@oracle.com>
             Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : beeps get longer after suspend
References : http://lkml.org/lkml/2007/2/26/276
Submitter  : Pavel Machek <pavel@ucw.cz>
Status     : unknown


Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Status     : unknown


Subject    : ThinkPad Z60m: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
             http://lkml.org/lkml/2007/2/28/172
Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
             commit 0a6139027f3986162233adc17285151e78b39cac
Handled-By : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
Status     : problem is being debugged


Subject    : AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
             http://lkml.org/lkml/2007/2/27/263
Submitter  : Thomas Meyer <thomas.mey@web.de>
             Meelis Roos <mroos@linux.ee>
Handled-By : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Status     : patch available


Subject    : Asus M6Ne notebook: ACPI: First battery is not detected
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
Status     : unknown


Subject    : AT keyboard only works with pci=noacpi
References : http://lkml.org/lkml/2007/3/3/68
Submitter  : Ash Milsted <thatistosayiseenem@gawab.com>
Status     : unknown

[3/6] 2.6.21-rc2: known regressions

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Status     : unknown


Subject    : kernels fail to boot with drives on ATIIXP controller
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
Handled-By : Tejun Heo <htejun@gmail.com>
Status     : problem is being discussed


Subject    : SATA_ACPI errors during kernel boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
             http://bugzilla.kernel.org/show_bug.cgi?id=8046
             http://bugzilla.kernel.org/show_bug.cgi?id=8095
             http://lkml.org/lkml/2007/2/22/159
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
             Lukas Hejtmanek <xhejtman@fi.muni.cz>
             Meelis Roos <mroos@linux.ee>
             Olivier Mondoloni <darkcore71@yahoo.fr>
Handled-By : Thomas Renninger <trenn@suse.de>
             Tejun Heo <htejun@gmail.com>
             Robert Moore <robert.moore@intel.com>
Status     : problem is being debugged

[4/6] 2.6.21-rc2: known regressions

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : Asus A8N-VM motherboard:
             framebuffer/console boot failure boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter  : Andrew Nelless <andrew@nelless.net>
Caused-By  : Len Brown <len.brown@intel.com>
             commit 7f8f97c3cc75d5783d0b45cf323dedf17684be19
Handled-By : Antonino A. Daplas <adaplas@gmail.com>
Status     : problem is being debugged


Subject    : LCD is dimmed  (ibm-acpi related)
References : http://lkml.org/lkml/2007/2/25/206
Submitter  : Jiri Kosina <jikos@jikos.cz>
Caused-By  : Richard Purdie <rpurdie@rpsys.net>
             commit 994efacdf9a087b52f71e620b58dfa526b0cf928
Handled-By : Jiri Kosina <jikos@jikos.cz>
             Richard Purdie <rpurdie@rpsys.net>
             Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Status     : patches are being discussed


Subject    : no backlight on radeon
References : http://lkml.org/lkml/2007/2/19/1
Submitter  : Yaroslav Halchenko <kernel@onerussian.com>
             Alex Romosan <romosan@sycorax.lbl.gov>
             David Miller <davem@davemloft.net>
Caused-By  : James Simmons <jsimmons@infradead.org>
             commit e0e34ef7f02915cfe50e501e9f32c24217177a96
Handled-By : Richard Purdie <rpurdie@rpsys.net>
             James Simmons <jsimmons@infradead.org>
             Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Status     : problem is being discussed


Subject    : nvidiafb broken
References : http://lkml.org/lkml/2007/2/24/36
Submitter  : Andreas Schwab <schwab@suse.de>
Caused-By  : Richard Purdie <rpurdie@rpsys.net>
             commit 599a52d12629394236d785615808845823875868
Handled-By : Richard Purdie <rpurdie@rpsys.net>
Patch      : http://lkml.org/lkml/2007/2/26/43
Status     : patch available

Re: [3/6] 2.6.21-rc2: known regressions

[Michal Jaegermann]

On Mon, Mar 05, 2007 at 02:50:36AM +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
> that are not yet fixed in Linus' tree.
....
> Subject    : kernels fail to boot with drives on ATIIXP controller
> References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
> Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
> Status     : unknown

Alan added comment to my posting that my problems are caused by
messed up IRQ routing on that box I tried.  Indeed, I can boot
kernel 2.6.20-1.2962.fc7, which really is 2.6.21-rc2, provided
I will use 'acpi=off irqpoll'.  Anything else and a boot silently
dies if 'acpi=off' is skipped or is not finding disk if 'irqpoll'
is missing.

Somehow 2.6.19 is booting on the same hardware without "valliant
efforts"; OTOH 'ahci' driver was not used there.

    Michal

Re: [4/6] 2.6.21-rc2: known regressions

[Antonino A. Daplas]

On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
> that are not yet fixed in Linus' tree.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : Asus A8N-VM motherboard:
>              framebuffer/console boot failure boot failure (ACPI related)
> References : http://lkml.org/lkml/2007/2/23/132
> Submitter  : Andrew Nelless <andrew@nelless.net>
> Caused-By  : Len Brown <len.brown@intel.com>
>              commit 7f8f97c3cc75d5783d0b45cf323dedf17684be19
> Handled-By : Antonino A. Daplas <adaplas@gmail.com>
> Status     : problem is being debugged
> 

This is not a framebuffer nor console problem.

I think Andrew Nelless confirmed that the cause is from the above
commit. How to fix it, I don't know.  Perhaps the
acpi_skip_timer_override boot option has to be used.

Tony

Re: [4/6] 2.6.21-rc2: known regressions

[Richard Purdie]

On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote:
> Subject    : LCD is dimmed  (ibm-acpi related)
> References : http://lkml.org/lkml/2007/2/25/206
> Submitter  : Jiri Kosina <jikos@jikos.cz>
> Caused-By  : Richard Purdie <rpurdie@rpsys.net>
>              commit 994efacdf9a087b52f71e620b58dfa526b0cf928
> Handled-By : Jiri Kosina <jikos@jikos.cz>
>              Richard Purdie <rpurdie@rpsys.net>
>              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Status     : patches are being discussed

The confirmed fix is in the ACPI test branch for this.

> Subject    : no backlight on radeon
> References : http://lkml.org/lkml/2007/2/19/1
> Submitter  : Yaroslav Halchenko <kernel@onerussian.com>
>              Alex Romosan <romosan@sycorax.lbl.gov>
>              David Miller <davem@davemloft.net>
> Caused-By  : James Simmons <jsimmons@infradead.org>
>              commit e0e34ef7f02915cfe50e501e9f32c24217177a96
> Handled-By : Richard Purdie <rpurdie@rpsys.net>
>              James Simmons <jsimmons@infradead.org>
>              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Status     : problem is being discussed
> 
> 
> Subject    : nvidiafb broken
> References : http://lkml.org/lkml/2007/2/24/36
> Submitter  : Andreas Schwab <schwab@suse.de>
> Caused-By  : Richard Purdie <rpurdie@rpsys.net>
>              commit 599a52d12629394236d785615808845823875868
> Handled-By : Richard Purdie <rpurdie@rpsys.net>
> Patch      : http://lkml.org/lkml/2007/2/26/43
> Status     : patch available

The confirmed fixes for both of these are in the backlight tree. I was
waiting for any further feedback on the first issue above but will send
them to Linus now.

Cheers,

Richard

Re: [3/6] 2.6.21-rc2: known regressions

[Alan Cox]

> Subject    : libata: PATA UDMA/100 configured as UDMA/33
> References : http://lkml.org/lkml/2007/2/20/294
>              http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
> Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
> Handled-By : Tejun Heo <htejun@gmail.com>
> Status     : problem is being discussed

Patch went to Jeff, hopefully it is now fixed. Bigger rework is heading
into -mm but not appropriate or neccessary for 2.6.21

Re: [2/6] 2.6.21-rc2: known regressions

[Jeff Garzik]

Adrian Bunk wrote:
> Subject    : AT keyboard only works with pci=noacpi
> References : http://lkml.org/lkml/2007/3/3/68
> Submitter  : Ash Milsted <thatistosayiseenem@gawab.com>
> Status     : unknown


sounds like a BIOS bug, even though it appears to be a regression?

Re: [3/6] 2.6.21-rc2: known regressions

[Jeff Garzik]

Adrian Bunk wrote:
> Subject    : NCQ problem with ahci and Hitachi drive
> References : http://lkml.org/lkml/2007/3/4/178
> Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
> Status     : unknown

according to the last message in that thread, it sounds like ACPI and 
interrupt problems


> Subject    : SATA_ACPI errors during kernel boot
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
>              http://bugzilla.kernel.org/show_bug.cgi?id=8046
>              http://bugzilla.kernel.org/show_bug.cgi?id=8095
>              http://lkml.org/lkml/2007/2/22/159
> Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
>              Lukas Hejtmanek <xhejtman@fi.muni.cz>
>              Meelis Roos <mroos@linux.ee>
>              Olivier Mondoloni <darkcore71@yahoo.fr>
> Handled-By : Thomas Renninger <trenn@suse.de>
>              Tejun Heo <htejun@gmail.com>
>              Robert Moore <robert.moore@intel.com>
> Status     : problem is being debugged

Note that there WILL be an increase in ACPI diagnostic output.  The key 
difference is whether the users are seeing scary printks, or whether the 
boot is actually breaking.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2/6] 2.6.21-rc2: known regressions

[Linus Torvalds]

On Wed, 7 Mar 2007, Jeff Garzik wrote:
>
> Adrian Bunk wrote:
> > Subject    : AT keyboard only works with pci=noacpi
> > References : http://lkml.org/lkml/2007/3/3/68
> > Submitter  : Ash Milsted <thatistosayiseenem@gawab.com>
> > Status     : unknown
> 
> sounds like a BIOS bug, even though it appears to be a regression?

So?

BIOS bugs are not bugs we can fix, they are things we have to work around. 
They are like hardware bugs in a network chip: a "driver" that doesn't 
work around a BIOS bug is simply a *buggy* driver, exactly the same way a 
network driver has to work around errata in the hardware.

So it doesn't really matter if something is a BIOS bug or not. It's not 
reasonable to expect people to upgrade their BIOS'es - even if such an 
upgrade were to exist (which is fairly rare in itself). 

If it used to work, that just makes it (a) doubly important to try to fix 
it, since regressions are BAD BAD BAD and (b) a fair amount *easier* to 
fix, since we can hopefully get an idea of what broke it.

Ash, can you try to use "git bisect" to figure where it started? But 
perhaps just try -rc3 first to see if it's been fixed?

The working setups (whether with irqfixup or with pci=noacpi seem to both 
have a nice

	input: AT Translated Set 2 keyboard as /class/input/inputX

but the nonworking one does not. But even the nonworking one actually 
*found* the controller:

	PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
	PNP: PS/2 controller doesn't have AUX irq; using default 12
	serio: i8042 KBD port at 0x60,0x64 irq 1
	serio: i8042 AUX port at 0x60,0x64 irq 12
	mice: PS/2 mouse device common for all mice

which probably means that the "atkbd_probe()" function fails (probably 
because it never gets a reply, which in turn is probably because the 
interrupt routing is broken).

If you use "atkbd.reset=1" on the kernel command line, you would probably 
get a message like "keyboard reset failed"..

Now, the most likely cause is obviously just the ACPI changes that mess up 
irq routing somehow, but it would be important to figure out *what* makes 
it happen, which is why "git bisect" would be wonderful to try.

So Ash, if you get the git tree, just start with

	git bisect start
	git bisect good v2.6.20
	git bisect bad v2.6.21-rc1

and off you go.. git isn't really that hard to use any more.

		Linus

[GIT PULL] ibm-acpi 2.6.21-rc3 regression fixes

[Henrique de Moraes Holschuh]

On Mon, 05 Mar 2007, Richard Purdie wrote:
> On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote:
> > Subject    : LCD is dimmed  (ibm-acpi related)
> > References : http://lkml.org/lkml/2007/2/25/206
> > Submitter  : Jiri Kosina <jikos@jikos.cz>
> > Caused-By  : Richard Purdie <rpurdie@rpsys.net>
> >              commit 994efacdf9a087b52f71e620b58dfa526b0cf928
> > Handled-By : Jiri Kosina <jikos@jikos.cz>
> >              Richard Purdie <rpurdie@rpsys.net>
> >              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> > Status     : patches are being discussed
> 
> The confirmed fix is in the ACPI test branch for this.

Len, since this is being tracked as a regression, please pull from
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch acpi-release

to receive the following patches:
      ACPI: ibm-acpi: fix initial status of backlight device
      ACPI: ibm-acpi: improve backlight power handling

against v2.6.21-rc3.

They are obvious bug-fixes, and address the above regression plus a related
problem in ibm-acpi backlight handling.

If we get these two patches into mainline, I will proceed to rediff the
pending 2.6.22 ibm-acpi stuff for acpi-test, so that you don't have any
extra work when the time comes to merge the ibm-acpi queue into acpi-test.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[PATCH] ACPI: ibm-acpi: fix initial status of backlight device

[Henrique de Moraes Holschuh]

The brightness class core does not update the initial status of the
device's brightness at register time.  Do it by ourselves.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
---
 drivers/acpi/ibm_acpi.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 4cc534e..7c1b418 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1711,6 +1711,12 @@ static struct backlight_ops ibm_backlight_data = {
 
 static int brightness_init(void)
 {
+	int b;
+
+	b = brightness_get(NULL);
+	if (b < 0)
+		return b;
+
 	ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
 							 &ibm_backlight_data);
 	if (IS_ERR(ibm_backlight_device)) {
@@ -1718,7 +1724,9 @@ static int brightness_init(void)
 		return PTR_ERR(ibm_backlight_device);
 	}
 
-        ibm_backlight_device->props.max_brightness = 7;
+	ibm_backlight_device->props.max_brightness = 7;
+	ibm_backlight_device->props.brightness = b;
+	backlight_update_status(ibm_backlight_device);
 
 	return 0;
 }
-- 
1.5.0.3

[PATCH] ACPI: ibm-acpi: improve backlight power handling

[Henrique de Moraes Holschuh]

Improve the backlight code to emulate as much as possible the power
management events, as we are unable to really power on or power off the
backlight.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Richard Purdie <rpurdie@rpsys.net>
---
 drivers/acpi/ibm_acpi.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 7c1b418..63d7a85 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -86,6 +86,7 @@
 
 #include <linux/proc_fs.h>
 #include <linux/backlight.h>
+#include <linux/fb.h>
 #include <asm/uaccess.h>
 
 #include <linux/dmi.h>
@@ -1701,7 +1702,10 @@ static int brightness_write(char *buf)
 
 static int brightness_update_status(struct backlight_device *bd)
 {
-	return brightness_set(bd->props.brightness);
+	return brightness_set(
+		(bd->props.fb_blank == FB_BLANK_UNBLANK &&
+		 bd->props.power == FB_BLANK_UNBLANK) ?
+				bd->props.brightness : 0);
 }
 
 static struct backlight_ops ibm_backlight_data = {
-- 
1.5.0.3

Re: [2/6] 2.6.21-rc2: known regressions

[Ash Milsted]

On Wed, 07 Mar 2007 06:09:06 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> Adrian Bunk wrote:
> > Subject    : AT keyboard only works with pci=noacpi
> > References : http://lkml.org/lkml/2007/3/3/68
> > Submitter  : Ash Milsted <thatistosayiseenem@gawab.com>
> > Status     : unknown
> 
> 
> sounds like a BIOS bug, even though it appears to be a regression?
> 

Resolved here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=117332735404395&w=2

Was a bug in the i8042 driver it seems.

Ash

Re: [2/6] 2.6.21-rc2: known regressions

[Michael S. Tsirkin]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

> Quoting Adrian Bunk <bunk@stusta.de>:
> Subject: [2/6] 2.6.21-rc2: known regressions
> 
> Subject    : ThinkPad T60: no screen after suspend to RAM
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Status     : unknown

Here's the status with -rc3: better, but still does not work as well as 2.6.20.

1. Switching to console VT, and running s2ram, I am able to resume to console
   (I have not tested with echo mem > /sys/power/state yet, both work OK
    with 2.6.20)
   This seems to take about as long as with 2.6.20.
   During this time, I see some messages on console (see attached log)

2. First disk access after resume takes a couple of minutes
   (seemed instant with 2.6.20) during this time no new messages show on console

3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows
   after waiting for some 10 min, I rebooted.
   no new messages showed up in /var/log/messages

log attached
   
-- 
MST


[-- Attachment #2: newlog --]
[-- Type: text/plain, Size: 20275 bytes --]

Mar  8 08:47:20 localhost kernel: Inspecting /boot/System.map-2.6.21-rc3-work
Mar  8 08:47:20 localhost kernel: Loaded 31265 symbols from /boot/System.map-2.6.21-rc3-work.
Mar  8 08:47:20 localhost kernel: Symbols match kernel version 2.6.21.
Mar  8 08:47:20 localhost kernel: No module symbols loaded - kernel modules not enabled. 
Mar  8 08:47:20 localhost kernel: 1
Mar  8 08:47:20 localhost kernel: [   15.317823] ata2: SATA link down (SStatus 0 SControl 0)
Mar  8 08:47:20 localhost kernel: [   15.317897] scsi2 : ahci
Mar  8 08:47:20 localhost kernel: [   15.379836] ata3: SATA link down (SStatus 0 SControl 0)
Mar  8 08:47:20 localhost kernel: [   15.379909] scsi3 : ahci
Mar  8 08:47:20 localhost kernel: [   15.441854] ata4: SATA link down (SStatus 0 SControl 0)
Mar  8 08:47:20 localhost kernel: [   15.441999] scsi 0:0:0:0: Direct-Access     ATA      HTS541080G9SA00  MB4I PQ: 0 ANSI: 5
Mar  8 08:47:20 localhost kernel: [   15.442216] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Mar  8 08:47:20 localhost kernel: [   15.442292] sda: Write Protect is off
Mar  8 08:47:20 localhost kernel: [   15.443138] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  8 08:47:20 localhost kernel: [   15.443256] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Mar  8 08:47:20 localhost kernel: [   15.443330] sda: Write Protect is off
Mar  8 08:47:20 localhost kernel: [   15.443406] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  8 08:47:20 localhost kernel: [   15.443490]  sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
Mar  8 08:47:20 localhost kernel: [   15.845145] sd 0:0:0:0: Attached scsi disk sda
Mar  8 08:47:20 localhost kernel: [   15.845290] sd 0:0:0:0: Attached scsi generic sg0 type 0
Mar  8 08:47:20 localhost kernel: [   15.845797] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 21
Mar  8 08:47:20 localhost kernel: [   15.845946] ehci_hcd 0000:00:1d.7: EHCI Host Controller
Mar  8 08:47:20 localhost kernel: [   15.846106] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
Mar  8 08:47:20 localhost kernel: [   15.846229] ehci_hcd 0000:00:1d.7: debug port 1
Mar  8 08:47:20 localhost kernel: [   15.846315] ehci_hcd 0000:00:1d.7: irq 21, io mem 0xee444000
Mar  8 08:47:20 localhost kernel: [   15.850269] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Mar  8 08:47:20 localhost kernel: [   15.850508] usb usb1: configuration #1 chosen from 1 choice
Mar  8 08:47:20 localhost kernel: [   15.850630] hub 1-0:1.0: USB hub found
Mar  8 08:47:20 localhost kernel: [   15.850697] hub 1-0:1.0: 8 ports detected
Mar  8 08:47:20 localhost kernel: [   15.862005] USB Universal Host Controller Interface driver v3.0
Mar  8 08:47:20 localhost kernel: [   15.862135] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:47:20 localhost kernel: [   15.862268] uhci_hcd 0000:00:1d.0: UHCI Host Controller
Mar  8 08:47:20 localhost kernel: [   15.862381] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
Mar  8 08:47:20 localhost kernel: [   15.862484] uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001820
Mar  8 08:47:20 localhost kernel: [   15.862702] usb usb2: configuration #1 chosen from 1 choice
Mar  8 08:47:20 localhost kernel: [   15.862821] hub 2-0:1.0: USB hub found
Mar  8 08:47:20 localhost kernel: [   15.862887] hub 2-0:1.0: 2 ports detected
Mar  8 08:47:20 localhost kernel: [   15.892543] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 22
Mar  8 08:47:20 localhost kernel: [   15.892676] uhci_hcd 0000:00:1d.1: UHCI Host Controller
Mar  8 08:47:20 localhost kernel: [   15.892789] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
Mar  8 08:47:20 localhost kernel: [   15.892894] uhci_hcd 0000:00:1d.1: irq 22, io base 0x00001840
Mar  8 08:47:20 localhost kernel: [   15.893113] usb usb3: configuration #1 chosen from 1 choice
Mar  8 08:47:20 localhost kernel: [   15.893229] hub 3-0:1.0: USB hub found
Mar  8 08:47:20 localhost kernel: [   15.893296] hub 3-0:1.0: 2 ports detected
Mar  8 08:47:20 localhost kernel: [   15.933182] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 23
Mar  8 08:47:20 localhost kernel: [   15.933314] uhci_hcd 0000:00:1d.2: UHCI Host Controller
Mar  8 08:47:20 localhost kernel: [   15.933427] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
Mar  8 08:47:20 localhost kernel: [   15.933577] uhci_hcd 0000:00:1d.2: irq 23, io base 0x00001860
Mar  8 08:47:20 localhost kernel: [   15.933797] usb usb4: configuration #1 chosen from 1 choice
Mar  8 08:47:20 localhost kernel: [   15.933915] hub 4-0:1.0: USB hub found
Mar  8 08:47:20 localhost kernel: [   15.933981] hub 4-0:1.0: 2 ports detected
Mar  8 08:47:20 localhost kernel: [   15.976494] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 21
Mar  8 08:47:20 localhost kernel: [   15.976627] uhci_hcd 0000:00:1d.3: UHCI Host Controller
Mar  8 08:47:20 localhost kernel: [   15.976740] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
Mar  8 08:47:20 localhost kernel: [   15.976843] uhci_hcd 0000:00:1d.3: irq 21, io base 0x00001880
Mar  8 08:47:20 localhost kernel: [   15.977060] usb usb5: configuration #1 chosen from 1 choice
Mar  8 08:47:20 localhost kernel: [   15.977196] hub 5-0:1.0: USB hub found
Mar  8 08:47:20 localhost kernel: [   15.977263] hub 5-0:1.0: 2 ports detected
Mar  8 08:47:20 localhost kernel: [   16.040824] Initializing USB Mass Storage driver...
Mar  8 08:47:20 localhost kernel: [   16.157808] usb 5-2: new full speed USB device using uhci_hcd and address 2
Mar  8 08:47:20 localhost kernel: [   16.221329] usb 5-2: configuration #1 chosen from 1 choice
Mar  8 08:47:20 localhost kernel: [   16.224625] usbcore: registered new interface driver usb-storage
Mar  8 08:47:20 localhost kernel: [   16.224692] USB Mass Storage support registered.
Mar  8 08:47:20 localhost kernel: [   16.224886] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
Mar  8 08:47:20 localhost kernel: [   16.233142] serio: i8042 KBD port at 0x60,0x64 irq 1
Mar  8 08:47:20 localhost kernel: [   16.233211] serio: i8042 AUX port at 0x60,0x64 irq 12
Mar  8 08:47:20 localhost kernel: [   16.233366] mice: PS/2 mouse device common for all mice
Mar  8 08:47:20 localhost kernel: [   16.233716] Advanced Linux Sound Architecture Driver Version 1.0.14rc3 (Tue Mar 06 13:10:00 2007 UTC).
Mar  8 08:47:20 localhost kernel: [   16.234221] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22
Mar  8 08:47:20 localhost kernel: [   16.236937] input: AT Translated Set 2 keyboard as /class/input/input3
Mar  8 08:47:20 localhost kernel: [   16.444361] ALSA device list:
Mar  8 08:47:20 localhost kernel: [   16.444428]   #0: HDA Intel at 0xee240000 irq 22
Mar  8 08:47:20 localhost kernel: [   16.444525] nf_conntrack version 0.5.0 (7168 buckets, 57344 max)
Mar  8 08:47:20 localhost kernel: [   16.444736] ip_tables: (C) 2000-2006 Netfilter Core Team
Mar  8 08:47:20 localhost kernel: [   16.444809] TCP cubic registered
Mar  8 08:47:20 localhost kernel: [   16.444887] NET: Registered protocol family 1
Mar  8 08:47:20 localhost kernel: [   16.444953] NET: Registered protocol family 17
Mar  8 08:47:20 localhost kernel: [   16.445019] ieee80211: 802.11 data/management/control stack, git-1.1.13
Mar  8 08:47:20 localhost kernel: [   16.445087] ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
Mar  8 08:47:20 localhost kernel: [   16.445185] Starting balanced_irq
Mar  8 08:47:20 localhost kernel: [   16.445254] Using IPI No-Shortcut mode
Mar  8 08:47:20 localhost kernel: [   16.472663] kjournald starting.  Commit interval 5 seconds
Mar  8 08:47:20 localhost kernel: [   16.472735] EXT3-fs: mounted filesystem with ordered data mode.
Mar  8 08:47:20 localhost kernel: [   16.472864] VFS: Mounted root (ext3 filesystem) readonly.
Mar  8 08:47:20 localhost kernel: [   16.473029] Freeing unused kernel memory: 184k freed
Mar  8 08:47:20 localhost kernel: [   16.473122] Write protecting the kernel read-only data: 902k
Mar  8 08:47:20 localhost kernel: [   24.658491] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Mar  8 08:47:20 localhost kernel: [   24.658576] Copyright (c) 1999-2006 Intel Corporation.
Mar  8 08:47:20 localhost kernel: [   24.658761] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:47:20 localhost kernel: [   24.733801] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:54:6c:47
Mar  8 08:47:20 localhost kernel: [   24.815441] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Mar  8 08:47:20 localhost kernel: [   25.282292] Adding 1951824k swap on /dev/sda6.  Priority:-1 extents:1 across:1951824k
Mar  8 08:47:20 localhost kernel: [   25.343370] EXT3 FS on sda3, internal journal
Mar  8 08:47:20 localhost kernel: [   25.697608] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x81a0b1, caps: 0xa04793/0x300000
Mar  8 08:47:20 localhost kernel: [   25.697710] serio: Synaptics pass-through port at isa0060/serio1/input0
Mar  8 08:47:20 localhost kernel: [   25.742946] input: SynPS/2 Synaptics TouchPad as /class/input/input4
Mar  8 08:47:20 localhost kernel: [   30.419349] NTFS volume version 3.1.
Mar  8 08:47:20 localhost kernel: [   31.156204] IBM TrackPoint firmware: 0x0e, buttons: 3/3
Mar  8 08:47:20 localhost kernel: [   31.426442] input: TPPS/2 IBM TrackPoint as /class/input/input5
Mar  8 08:47:22 localhost hpiod: 0.9.7 accepting connections at 50899... 
Mar  8 08:47:26 localhost kernel: [   39.389386] [drm] Initialized i915 1.6.0 20060119 on minor 0
Mar  8 08:48:07 localhost kernel: <1] pcieport-driver 0000:00:1c.3: LATE suspend
Mar  8 08:48:07 localhost kernel: [    2.183443] Intel machine check architecture supported.
Mar  8 08:48:07 localhost kernel: [    2.183451] Intel machine check reporting enabled on CPU#0.
Mar  8 08:48:07 localhost kernel: [    2.183982] Enabling non-boot CPUs ...
Mar  8 08:48:07 localhost kernel: [    2.321035] SMP alternatives: switching to SMP code
Mar  8 08:48:07 localhost kernel: [    2.321241] Booting processor 1/1 eip 3000
Mar  8 08:48:07 localhost kernel: [    2.332199] Initializing CPU#1
Mar  8 08:48:07 localhost kernel: [    3.143727] Calibrating delay using timer specific routine.. 20089.15 BogoMIPS (lpj=100445793)
Mar  8 08:48:07 localhost kernel: [    3.143746] monitor/mwait feature present.
Mar  8 08:48:07 localhost kernel: [    3.143751] CPU: L1 I cache: 32K, L1 D cache: 32K
Mar  8 08:48:07 localhost kernel: [    3.143755] CPU: L2 cache: 2048K
Mar  8 08:48:07 localhost kernel: [    3.143759] CPU: Physical Processor ID: 0
Mar  8 08:48:07 localhost kernel: [    3.143761] CPU: Processor Core ID: 1
Mar  8 08:48:07 localhost kernel: [    3.143774] Intel machine check architecture supported.
Mar  8 08:48:07 localhost kernel: [    3.143783] Intel machine check reporting enabled on CPU#1.
Mar  8 08:48:07 localhost kernel: [    3.144104] CPU1: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
Mar  8 08:48:07 localhost kernel: [    3.144892] speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is deprecated.
Mar  8 08:48:07 localhost kernel: [    3.144896]  Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead.
Mar  8 08:48:07 localhost kernel: [    3.144936] CPU1 is up
Mar  8 08:48:07 localhost kernel: [    3.440273] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:07 localhost kernel: [    3.527272] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22
Mar  8 08:48:07 localhost kernel: [    3.912917] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:07 localhost kernel: [    3.912966] usb usb2: root hub lost power or was reset
Mar  8 08:48:07 localhost kernel: [    3.912988] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 22
Mar  8 08:48:07 localhost kernel: [    3.913036] usb usb3: root hub lost power or was reset
Mar  8 08:48:07 localhost kernel: [    3.913055] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 23
Mar  8 08:48:07 localhost kernel: [    3.913102] usb usb4: root hub lost power or was reset
Mar  8 08:48:07 localhost kernel: [    3.913120] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 21
Mar  8 08:48:07 localhost kernel: [    3.913168] usb usb5: root hub lost power or was reset
Mar  8 08:48:07 localhost kernel: [    3.914015] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 21
Mar  8 08:48:07 localhost kernel: [    3.914205] ACPI: PCI Interrupt 0000:00:1f.1[C] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:07 localhost kernel: [    3.914407] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:07 localhost kernel: [    3.922880] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:07 localhost kernel: [    3.928614] ACPI: PCI Interrupt 0000:15:00.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:07 localhost kernel: [    3.928638] pnp: Device 00:08 does not support activation.
Mar  8 08:48:07 localhost kernel: [    3.928641] pnp: Device 00:09 does not support activation.
Mar  8 08:48:07 localhost kernel: [    4.209165] ata2: SATA link down (SStatus 0 SControl 0)
Mar  8 08:48:07 localhost kernel: [    4.209179] ata3: SATA link down (SStatus 0 SControl 0)
Mar  8 08:48:07 localhost kernel: [    4.209191] ata4: SATA link down (SStatus 0 SControl 0)
Mar  8 08:48:07 localhost kernel: [    4.849894] atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0).
Mar  8 08:48:07 localhost kernel: [    4.849896] atkbd.c: Use 'setkeycodes e060 <keycode>' to make it known.
Mar  8 08:48:07 localhost kernel: [    4.850297] atkbd.c: Unknown key pressed (translated set 2, code 0x63 on isa0060/serio0).
Mar  8 08:48:07 localhost kernel: [    4.850300] atkbd.c: Use 'setkeycodes 63 <keycode>' to make it known.
Mar  8 08:48:07 localhost kernel: [    5.826771] Restarting tasks ... <6>usb 5-2: USB disconnect, address 2
Mar  8 08:48:07 localhost kernel: [    5.839206] done.
Mar  8 08:48:07 localhost kernel: [    6.702776] ata1: waiting for device to spin up (7 secs)
Mar  8 08:48:07 localhost kernel: [    6.775788] usb 5-2: new full speed USB device using uhci_hcd and address 3
Mar  8 08:48:07 localhost kernel: [    6.866806] usb 5-2: configuration #1 chosen from 1 choice
Mar  8 08:48:07 localhost kernel: [   11.334773] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Mar  8 08:48:07 localhost kernel: [   11.673734] ata1.00: configured for UDMA/100
Mar  8 08:48:07 localhost kernel: [   11.696311] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Mar  8 08:48:07 localhost kernel: [   11.697691] sda: Write Protect is off
Mar  8 08:48:07 localhost kernel: [   11.708467] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  8 08:48:16 localhost kernel: <>[   19.841599] button button_power:00: suspend
Mar  8 08:48:16 localhost kernel: [   19.841607] Disabling non-boot CPUs ...
Mar  8 08:48:16 localhost kernel: [   19.847811] Breaking affinity for irq 12
Mar  8 08:48:16 localhost kernel: [   20.444974] CPU 1 is now offline
Mar  8 08:48:16 localhost kernel: [   20.444980] SMP alternatives: switching to UP code
Mar  8 08:48:16 localhost kernel: [   20.445823] CPU1 is down
Mar  8 08:48:16 localhost kernel: [    2.423903] Intel machine check architecture supported.
Mar  8 08:48:16 localhost kernel: [    2.423911] Intel machine check reporting enabled on CPU#0.
Mar  8 08:48:16 localhost kernel: [    2.424444] Enabling non-boot CPUs ...
Mar  8 08:48:16 localhost kernel: [    2.534642] SMP alternatives: switching to SMP code
Mar  8 08:48:16 localhost kernel: [    2.534847] Booting processor 1/1 eip 3000
Mar  8 08:48:16 localhost kernel: [    2.545805] Initializing CPU#1
Mar  8 08:48:16 localhost kernel: [    3.357337] Calibrating delay using timer specific routine.. 20089.13 BogoMIPS (lpj=100445659)
Mar  8 08:48:16 localhost kernel: [    3.357357] monitor/mwait feature present.
Mar  8 08:48:16 localhost kernel: [    3.357362] CPU: L1 I cache: 32K, L1 D cache: 32K
Mar  8 08:48:16 localhost kernel: [    3.357365] CPU: L2 cache: 2048K
Mar  8 08:48:16 localhost kernel: [    3.357369] CPU: Physical Processor ID: 0
Mar  8 08:48:16 localhost kernel: [    3.357372] CPU: Processor Core ID: 1
Mar  8 08:48:16 localhost kernel: [    3.357384] Intel machine check architecture supported.
Mar  8 08:48:16 localhost kernel: [    3.357394] Intel machine check reporting enabled on CPU#1.
Mar  8 08:48:16 localhost kernel: [    3.357711] CPU1: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
Mar  8 08:48:16 localhost kernel: [    3.358503] speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is deprecated.
Mar  8 08:48:16 localhost kernel: [    3.358507]  Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead.
Mar  8 08:48:16 localhost kernel: [    3.358548] CPU1 is up
Mar  8 08:48:16 localhost kernel: [    3.653795] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:16 localhost kernel: [    3.740900] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22
Mar  8 08:48:16 localhost kernel: [    4.126569] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:16 localhost kernel: [    4.126619] usb usb2: root hub lost power or was reset
Mar  8 08:48:16 localhost kernel: [    4.126639] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 22
Mar  8 08:48:16 localhost kernel: [    4.126686] usb usb3: root hub lost power or was reset
Mar  8 08:48:16 localhost kernel: [    4.126705] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 23
Mar  8 08:48:16 localhost kernel: [    4.126752] usb usb4: root hub lost power or was reset
Mar  8 08:48:16 localhost kernel: [    4.126772] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 21
Mar  8 08:48:16 localhost kernel: [    4.126819] usb usb5: root hub lost power or was reset
Mar  8 08:48:16 localhost kernel: [    4.127659] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 21
Mar  8 08:48:16 localhost kernel: [    4.127848] ACPI: PCI Interrupt 0000:00:1f.1[C] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:16 localhost kernel: [    4.128049] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:16 localhost kernel: [    4.136510] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:16 localhost kernel: [    4.142247] ACPI: PCI Interrupt 0000:15:00.0[A] -> GSI 16 (level, low) -> IRQ 20
Mar  8 08:48:16 localhost kernel: [    4.142271] pnp: Device 00:08 does not support activation.
Mar  8 08:48:16 localhost kernel: [    4.142274] pnp: Device 00:09 does not support activation.
Mar  8 08:48:16 localhost kernel: [    4.421975] ata2: SATA link down (SStatus 0 SControl 0)
Mar  8 08:48:16 localhost kernel: [    4.421989] ata3: SATA link down (SStatus 0 SControl 0)
Mar  8 08:48:16 localhost kernel: [    4.422001] ata4: SATA link down (SStatus 0 SControl 0)
Mar  8 08:48:16 localhost kernel: [    5.971047] Restarting tasks ... done.
Mar  8 08:48:16 localhost kernel: [    6.012513] usb 5-2: USB disconnect, address 3
Mar  8 08:48:16 localhost kernel: [    6.891677] ata1: waiting for device to spin up (7 secs)
Mar  8 08:48:16 localhost kernel: [    6.958587] usb 5-2: new full speed USB device using uhci_hcd and address 4
Mar  8 08:48:16 localhost kernel: [    7.049506] usb 5-2: configuration #1 chosen from 1 choice
Mar  8 08:48:16 localhost kernel: [   11.547844] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Mar  8 08:48:16 localhost kernel: [   11.885459] ata1.00: configured for UDMA/100
Mar  8 08:48:16 localhost kernel: [   11.913910] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Mar  8 08:48:16 localhost kernel: [   11.914575] sda: Write Protect is off
Mar  8 08:48:16 localhost kernel: [   11.914868] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  8 08:48:16 localhost shutdown[4092]: shutting down for system halt

Re: [2/6] 2.6.21-rc2: known regressions

[Jeff Chua]

On 3/8/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> > Quoting Adrian Bunk <bunk@stusta.de>:
> > Subject: [2/6] 2.6.21-rc2: known regressions
> >
> > Subject    : ThinkPad T60: no screen after suspend to RAM
> > References : http://lkml.org/lkml/2007/2/22/391
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > Status     : unknown
>
> Here's the status with -rc3: better, but still does not work as well as 2.6.20.

> 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows
>    after waiting for some 10 min, I rebooted.
>    no new messages showed up in /var/log/messages

In my case, I can "suspend" and "resume", but seems the clock died
after resume. "date" always returns the same time! I had to disable
CONFIG_NO_HZ and CONFIG_SYSFS_DEPRECATED in order to suspend.

Try to execute "date" and see if it changes after resume.

Thanks,
Jeff.

Re: [2/6] 2.6.21-rc2: known regressions

[Linus Torvalds]

[ Eric, Ingo, can you double-check the timer initialization after resume? 
  We appear to have several reports of date not advancing, and while this 
  could be some SATA issue, it could easily be a timer tick issue too ]

On Thu, 8 Mar 2007, Michael S. Tsirkin wrote:
> 
> Here's the status with -rc3: better, but still does not work as well as 2.6.20.

Ok. I think we mostly solved the irq-related stuff, but you might want to 
check whether you have CONFIG_NOHZ on or off and whether that makes a 
difference.

> 2. First disk access after resume takes a couple of minutes
>    (seemed instant with 2.6.20) during this time no new messages show on console

Yeah, there is some problem with SATA resume. It would be beautiful if the 
people who actually see this could narrow it down with bisection. "It 
works for me" is clearly the case for many people, but not all.

But before blaming SATA, check if you have NO_HZ enabled and whether 
disabling that makes it work ok. If timeouts don't work right (or are 
*extremely* slow) things that should be instant won't be.

> 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows
>    after waiting for some 10 min, I rebooted.
>    no new messages showed up in /var/log/messages

I think this is likely just more of the disk being buggered, but it could 
again be related to NO_HZ (people report time not advancing, and that 
would make any X timeout taking forever, and you'd see exactly your 
behaviour).

		Linus

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows
> >    after waiting for some 10 min, I rebooted. no new messages showed 
> >    up in /var/log/messages
> 
> I think this is likely just more of the disk being buggered, but it 
> could again be related to NO_HZ (people report time not advancing, and 
> that would make any X timeout taking forever, and you'd see exactly 
> your behaviour).

Michael - does your 'date' output advance after resume? If not then i'd 
say it's a NO_HZ related problem. If yes then i'd guess it's the SATA 
problem.

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> Michael - does your 'date' output advance after resume? If not then 
> i'd say it's a NO_HZ related problem. [...]

in that case please do this on such a 'frozen date' system:

	echo q > /proc/sysrq-trigger

and then send us the hw-timers info.

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > 2. First disk access after resume takes a couple of minutes
> >    (seemed instant with 2.6.20) during this time no new messages 
> >    show on console
> 
> Yeah, there is some problem with SATA resume. It would be beautiful if 
> the people who actually see this could narrow it down with bisection. 
> "It works for me" is clearly the case for many people, but not all.

Thomas found a new twist to this today: applying the patch below (which 
turns on ATA_DEBUG) made the SATA problem go away on his laptop. 
Michael, could you try this patch, does it change the behavior of your 
laptop in any way?

	Ingo

---
 include/linux/libata.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/include/linux/libata.h
===================================================================
--- linux.orig/include/linux/libata.h
+++ linux/include/linux/libata.h
@@ -51,7 +51,7 @@
  * compile-time options: to be removed as soon as all the drivers are
  * converted to the new debugging mechanism
  */
-#undef ATA_DEBUG		/* debugging output */
+#define ATA_DEBUG 1		/* debugging output */
 #undef ATA_VERBOSE_DEBUG	/* yet more debugging output */
 #undef ATA_IRQ_TRAP		/* define to ack screaming irqs */
 #undef ATA_NDEBUG		/* define to disable quick runtime checks */

Re: [2/6] 2.6.21-rc2: known regressions

[Michael S. Tsirkin]

> Quoting Linus Torvalds <torvalds@linux-foundation.org>:
> > 
> > Here's the status with -rc3: better, but still does not work as well as 2.6.20.
> 
> Ok. I think we mostly solved the irq-related stuff, but you might want to 
> check whether you have CONFIG_NOHZ on or off and whether that makes a 
> difference.

This testing was done without NO_HZ.

-- 
MST

Re: [2/6] 2.6.21-rc2: known regressions

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: [2/6] 2.6.21-rc2: known regressions
> 
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows
> > >    after waiting for some 10 min, I rebooted. no new messages showed 
> > >    up in /var/log/messages
> > 
> > I think this is likely just more of the disk being buggered, but it 
> > could again be related to NO_HZ (people report time not advancing, and 
> > that would make any X timeout taking forever, and you'd see exactly 
> > your behaviour).
> 
> Michael - does your 'date' output advance after resume? If not then i'd 
> say it's a NO_HZ related problem. If yes then i'd guess it's the SATA 
> problem.

I'll test, but I have NO_HZ off for now.

-- 
MST

Re: [2/6] 2.6.21-rc2: known regressions

[Michael S. Tsirkin]

> > 2. First disk access after resume takes a couple of minutes
> >    (seemed instant with 2.6.20) during this time no new messages show on console
> 
> Yeah, there is some problem with SATA resume. It would be beautiful if the 
> people who actually see this could narrow it down with bisection. "It 
> works for me" is clearly the case for many people, but not all.

Problem is, there seem to be multiple problems some of which got
fixed between rc2 and rc3.
With rc2 I didn't get as far as getting to console.

-- 
MST

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > Michael - does your 'date' output advance after resume? If not then 
> > i'd say it's a NO_HZ related problem. If yes then i'd guess it's the 
> > SATA problem.
> 
> I'll test, but I have NO_HZ off for now.

there can still be effects of it (the regression we fixed in -rc3 was 
such an effect too), so please test it.

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> Thomas found a new twist to this today: applying the patch below 
> (which turns on ATA_DEBUG) made the SATA problem go away on his 
> laptop. Michael, could you try this patch, does it change the behavior 
> of your laptop in any way?

Here's another suspend/resume artifact: one of my boxes wouldnt resume, 
it hangs at:

[    1.456633] pci 0000:00:18.2: resuming
[    1.456641] pci 0000:00:18.3: resuming
[    1.456648] 8139too 0000:05:07.0: resuming
[    1.456667] radeonfb 0000:01:00.0: resuming

the box is pingable but otherwise no console and it's hung as well. [I 
got the log above via netconsole]

disabling the following radeonfb options in the .config made resume work 
again:

 CONFIG_FB_RADEON=y
 CONFIG_FB_RADEON_I2C=y
 CONFIG_FB_RADEON_BACKLIGHT=y

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> Here's another suspend/resume artifact: one of my boxes wouldnt 
> resume, it hangs at:
> 
> [    1.456633] pci 0000:00:18.2: resuming
> [    1.456641] pci 0000:00:18.3: resuming
> [    1.456648] 8139too 0000:05:07.0: resuming
> [    1.456667] radeonfb 0000:01:00.0: resuming
> 
> the box is pingable but otherwise no console and it's hung as well. [I 
> got the log above via netconsole]

unfortunately there's no way to get any backtrace out of the system at 
this point - the timer interrupts are not active yet here, so i cannot 
use the softlockup_tick patch to sample the lockup. Since it's pingable 
i'll try to hack a dump_stack() into icmp_reply() ;-)

	Ingo

Re: [4/6] 2.6.21-rc2: known regressions

[Len Brown]

On Monday 05 March 2007 05:35, Antonino A. Daplas wrote:
> On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : Asus A8N-VM motherboard:
> >              framebuffer/console boot failure boot failure (ACPI related)
> > References : http://lkml.org/lkml/2007/2/23/132
> > Submitter  : Andrew Nelless <andrew@nelless.net>
> > Caused-By  : Len Brown <len.brown@intel.com>
> >              commit 7f8f97c3cc75d5783d0b45cf323dedf17684be19
> > Handled-By : Antonino A. Daplas <adaplas@gmail.com>
> > Status     : problem is being debugged
> > 
> 
> This is not a framebuffer nor console problem.
> 
> I think Andrew Nelless confirmed that the cause is from the above
> commit. How to fix it, I don't know.  Perhaps the
> acpi_skip_timer_override boot option has to be used.

Looks like I got fooled by the negative logic for the nvidia_bugs().
Please test this patch -- it should fix it,
as well as simplify the code a bit.

thanks,
-Len


Subject: ACPI: repair nvidia early quirk breakage on x86_64

x86_64 nvidia_bugs() broke when we bailed out on not finding the HPET.
However, the quirk works by checking for _not_ finding the HPET...

Delete the nvidia_hpet_detected flag and simply test for
not finding the HPET, which is simple to do now that
acpi_table_parse returns 1 on failure.

Signed-off-by: Len Brown <len.brown@intel.com>
---
 i386/kernel/acpi/earlyquirk.c |    7 +------
 x86_64/kernel/early-quirks.c  |    9 +--------
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/i386/kernel/acpi/earlyquirk.c b/arch/i386/kernel/acpi/earlyquirk.c
index bf86f76..7fdba8a 100644
--- a/arch/i386/kernel/acpi/earlyquirk.c
+++ b/arch/i386/kernel/acpi/earlyquirk.c
@@ -14,11 +14,8 @@
 
 #ifdef CONFIG_ACPI
 
-static int nvidia_hpet_detected __initdata;
-
 static int __init nvidia_hpet_check(struct acpi_table_header *header)
 {
-	nvidia_hpet_detected = 1;
 	return 0;
 }
 #endif
@@ -29,9 +26,7 @@ static int __init check_bridge(int vendor, int device)
 	/* According to Nvidia all timer overrides are bogus unless HPET
 	   is enabled. */
 	if (!acpi_use_timer_override && vendor == PCI_VENDOR_ID_NVIDIA) {
-		nvidia_hpet_detected = 0;
-		acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check);
-		if (nvidia_hpet_detected == 0) {
+		if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check) {
 			acpi_skip_timer_override = 1;
 			  printk(KERN_INFO "Nvidia board "
                        "detected. Ignoring ACPI "
diff --git a/arch/x86_64/kernel/early-quirks.c b/arch/x86_64/kernel/early-quirks.c
index 8047ea8..dec587b 100644
--- a/arch/x86_64/kernel/early-quirks.c
+++ b/arch/x86_64/kernel/early-quirks.c
@@ -30,11 +30,8 @@ static void via_bugs(void)
 
 #ifdef CONFIG_ACPI
 
-static int nvidia_hpet_detected __initdata;
-
 static int __init nvidia_hpet_check(struct acpi_table_header *header)
 {
-	nvidia_hpet_detected = 1;
 	return 0;
 }
 #endif
@@ -52,11 +49,7 @@ static void nvidia_bugs(void)
 	if (acpi_use_timer_override)
 		return;
 
-	nvidia_hpet_detected = 0;
-	if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check))
-		return;
-
-	if (nvidia_hpet_detected == 0) {
+	if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
 		acpi_skip_timer_override = 1;
 		printk(KERN_INFO "Nvidia board "
 		       "detected. Ignoring ACPI "

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > Here's another suspend/resume artifact: one of my boxes wouldnt 
> > resume, it hangs at:
> > 
> > [    1.456633] pci 0000:00:18.2: resuming
> > [    1.456641] pci 0000:00:18.3: resuming
> > [    1.456648] 8139too 0000:05:07.0: resuming
> > [    1.456667] radeonfb 0000:01:00.0: resuming
> > 
> > the box is pingable but otherwise no console and it's hung as well. [I 
> > got the log above via netconsole]
> 
> unfortunately there's no way to get any backtrace out of the system at 
> this point - the timer interrupts are not active yet here, so i cannot 
> use the softlockup_tick patch to sample the lockup. Since it's 
> pingable i'll try to hack a dump_stack() into icmp_reply() ;-)

didnt succeed at that - no netconsole output during the hang. But the 
RADEON_FB .config options definitely make the difference. The video card 
in question is:

01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Linus Torvalds]

On Fri, 9 Mar 2007, Ingo Molnar wrote:
> 
> disabling the following radeonfb options in the .config made resume work 
> again:

In general, don't even *try* to use radeonfb for suspend/resume.

I don't think it has ever worked, except on some very rare laptops 
(largely PPC Macs) where people had enough information to set up the 
PLL's.

I don't think the other framebuffer drivers are much better.

You're better off using the VGA console, and lettign X re-initialize the 
graphics device. That generally at least has a reasonably good chance of 
working.

Re-initializing graphics modes really is very hard. You can try with the 
BIOS video hack (I forget the kernel command line to turn it on), but we 
really do end up depending on X doing it better.

Some day we may have modesetting support in the kernel for some graphics 
hw, right now it's pretty damn spotty.

		Linus

Re: [PATCH] ACPI: ibm-acpi: fix initial status of backlight device

[Len Brown]

we checked this in already back on 2/22
it is on the ibm branch that i'll included in the next 2.6.21 pull request.

thanks,
-Len

On Thursday 08 March 2007 03:28, Henrique de Moraes Holschuh wrote:
> The brightness class core does not update the initial status of the
> device's brightness at register time.  Do it by ourselves.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Acked-by: Richard Purdie <rpurdie@rpsys.net>
> ---
>  drivers/acpi/ibm_acpi.c |   10 +++++++++-
>  1 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
> index 4cc534e..7c1b418 100644
> --- a/drivers/acpi/ibm_acpi.c
> +++ b/drivers/acpi/ibm_acpi.c
> @@ -1711,6 +1711,12 @@ static struct backlight_ops ibm_backlight_data = {
>  
>  static int brightness_init(void)
>  {
> +	int b;
> +
> +	b = brightness_get(NULL);
> +	if (b < 0)
> +		return b;
> +
>  	ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
>  							 &ibm_backlight_data);
>  	if (IS_ERR(ibm_backlight_device)) {
> @@ -1718,7 +1724,9 @@ static int brightness_init(void)
>  		return PTR_ERR(ibm_backlight_device);
>  	}
>  
> -        ibm_backlight_device->props.max_brightness = 7;
> +	ibm_backlight_device->props.max_brightness = 7;
> +	ibm_backlight_device->props.brightness = b;
> +	backlight_update_status(ibm_backlight_device);
>  
>  	return 0;
>  }

Re: [PATCH] ACPI: ibm-acpi: improve backlight power handling

[Len Brown]

Applied.

thanks,
-Len

On Thursday 08 March 2007 03:28, Henrique de Moraes Holschuh wrote:
> Improve the backlight code to emulate as much as possible the power
> management events, as we are unable to really power on or power off the
> backlight.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Acked-by: Richard Purdie <rpurdie@rpsys.net>
> ---
>  drivers/acpi/ibm_acpi.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
> index 7c1b418..63d7a85 100644
> --- a/drivers/acpi/ibm_acpi.c
> +++ b/drivers/acpi/ibm_acpi.c
> @@ -86,6 +86,7 @@
>  
>  #include <linux/proc_fs.h>
>  #include <linux/backlight.h>
> +#include <linux/fb.h>
>  #include <asm/uaccess.h>
>  
>  #include <linux/dmi.h>
> @@ -1701,7 +1702,10 @@ static int brightness_write(char *buf)
>  
>  static int brightness_update_status(struct backlight_device *bd)
>  {
> -	return brightness_set(bd->props.brightness);
> +	return brightness_set(
> +		(bd->props.fb_blank == FB_BLANK_UNBLANK &&
> +		 bd->props.power == FB_BLANK_UNBLANK) ?
> +				bd->props.brightness : 0);
>  }
>  
>  static struct backlight_ops ibm_backlight_data = {

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > disabling the following radeonfb options in the .config made resume 
> > work again:
> 
> In general, don't even *try* to use radeonfb for suspend/resume.
> 
> I don't think it has ever worked, except on some very rare laptops 
> (largely PPC Macs) where people had enough information to set up the 
> PLL's.
> 
> I don't think the other framebuffer drivers are much better.
> 
> You're better off using the VGA console, and lettign X re-initialize 
> the graphics device. That generally at least has a reasonably good 
> chance of working.
> 
> Re-initializing graphics modes really is very hard. You can try with 
> the BIOS video hack (I forget the kernel command line to turn it on), 
> but we really do end up depending on X doing it better.

it's the s3_sleep boot option and /proc/sys/kernel/acpi_video_mode, but 
that didnt make a difference.

> Some day we may have modesetting support in the kernel for some 
> graphics hw, right now it's pretty damn spotty.

having no video is what i'd have expected - but getting a /hang/ is not 
what i'd have expected.

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Pavel Machek]

Hi!

> > disabling the following radeonfb options in the .config made resume work 
> > again:
> 
> In general, don't even *try* to use radeonfb for suspend/resume.
> 
> I don't think it has ever worked, except on some very rare laptops 
> (largely PPC Macs) where people had enough information to set up the 
> PLL's.

It worked ok on thinkpad x32. BIOS did the setup in resume case (with
acpi_sleep=..., anyway), and radeonfb could pick the card up from there.

> I don't think the other framebuffer drivers are much better.
> 
> You're better off using the VGA console, and lettign X re-initialize the 
> graphics device. That generally at least has a reasonably good chance of 
> working.

suspend.sf.net, s2ram there has a long list of tricks. If you invent
new one, please add it there.

> Re-initializing graphics modes really is very hard. You can try with the 
> BIOS video hack (I forget the kernel command line to turn it on), but we 
> really do end up depending on X doing it better.

...or you can try vbetool; it is similar hack to acpi_sleep=... , but
it works for more people.

> Some day we may have modesetting support in the kernel for some graphics 
> hw, right now it's pretty damn spotty.

Yep, that's the way to go.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [2/6] 2.6.21-rc2: known regressions

[Johannes Stezenbach]

On Thu, Mar 08, 2007, Linus Torvalds wrote:
> On Fri, 9 Mar 2007, Ingo Molnar wrote:
> > 
> > disabling the following radeonfb options in the .config made resume work 
> > again:
> 
> In general, don't even *try* to use radeonfb for suspend/resume.
> 
> I don't think it has ever worked, except on some very rare laptops 
> (largely PPC Macs) where people had enough information to set up the 
> PLL's.
> 
> I don't think the other framebuffer drivers are much better.
> 
> You're better off using the VGA console, and lettign X re-initialize the 
> graphics device. That generally at least has a reasonably good chance of 
> working.
> 
> Re-initializing graphics modes really is very hard. You can try with the 
> BIOS video hack (I forget the kernel command line to turn it on), but we 
> really do end up depending on X doing it better.

acpi_sleep=s3_bios has always worked for me on my ThinkPad T42p.

Even if one doesn't use the fb console at all, radeonfb apparently
is still required on some ThinkPad models to work around BIOS bugs:

http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off


Johannes

Re: [2/6] 2.6.21-rc2: known regressions

[Linus Torvalds]

On Fri, 9 Mar 2007, Ingo Molnar wrote:
> > Some day we may have modesetting support in the kernel for some 
> > graphics hw, right now it's pretty damn spotty.
> 
> having no video is what i'd have expected - but getting a /hang/ is not 
> what i'd have expected.

I debugged a case exactly like this (with the TRACE_RESUME() thing) back 
last November on my laptop.

The problem is that radeonfb actually *tries* to re-initialize the 
graphics chips, but because it doesn't know all the details, it does it 
wrong, and hangs the whole chip.

I forget exactly where it happened, and it might well be different for 
you. But this is exactly what TRACE_RESUME can be used to pinpoint if you 
want to try to debug it. 

			Linus

Re: [2/6] 2.6.21-rc2: known regressions

[Pavel Machek]

Hi!

> > You're better off using the VGA console, and lettign X re-initialize the 
> > graphics device. That generally at least has a reasonably good chance of 
> > working.
> > 
> > Re-initializing graphics modes really is very hard. You can try with the 
> > BIOS video hack (I forget the kernel command line to turn it on), but we 
> > really do end up depending on X doing it better.
> 
> acpi_sleep=s3_bios has always worked for me on my ThinkPad T42p.
> 
> Even if one doesn't use the fb console at all, radeonfb apparently
> is still required on some ThinkPad models to work around BIOS bugs:
> 
> http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off


s2ram should be able to work around this, it has parts from
radeontool. (suspend.sf.net).


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [3/6] 2.6.21-rc2: known regressions

[Mathieu Bérard]

Jeff Garzik a écrit :
> Adrian Bunk wrote:
>> Subject    : NCQ problem with ahci and Hitachi drive
>> References : http://lkml.org/lkml/2007/3/4/178
>> Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
>> Status     : unknown
>
> according to the last message in that thread, it sounds like ACPI and
> interrupt problems
>
Hi,
after more testing with a 2.6.21-rc3, it appears that after several ata
errors the boot process
somehow continued as normal, after a "NCQ disabled due to excessive
errors" message.
"pci=noacpi" or "noacpi" parameters workarounds the problem "irqpoll"
does nothing.

lspci:
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI
Express Root Port (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation
82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
AC'97 Modem Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface
Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc M24 [Radeon
Mobility X600]
06:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
06:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG
Network Connection (rev 05)
06:04.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
06:04.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394
Host Controller
06:04.3 Mass storage controller: Texas Instruments PCIxx21 Integrated
FlashMedia Controller
06:04.4 Generic system peripheral [0805]: Texas Instruments
PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller


/proc/interrupts:
        CPU0      
  0:       3242   IO-APIC-edge      timer
  1:        863   IO-APIC-edge      i8042
  8:          3   IO-APIC-edge      rtc
  9:          1   IO-APIC-fasteoi   acpi
 12:        116   IO-APIC-edge      i8042
 14:        128   IO-APIC-edge      libata
 15:          0   IO-APIC-edge      libata
 16:          1   IO-APIC-fasteoi   uhci_hcd:usb4, yenta
 17:          0   IO-APIC-fasteoi   tifm_7xx1, Intel ICH6
 18:        249   IO-APIC-fasteoi   eth0
 19:       2712   IO-APIC-fasteoi   libata, uhci_hcd:usb2, sdhci:slot0,
sdhci:slot1, sdhci:slot2
 20:         47   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 21:          3   IO-APIC-fasteoi   uhci_hcd:usb3, ohci1394
 22:          1   IO-APIC-fasteoi   ipw2200
NMI:          0
LOC:      15767
ERR:          0
MIS:          0


/proc/interrupts with pci=noacpi:
    CPU0      
  0:       2886    XT-PIC-XT        timer
  1:         79    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  8:          3    XT-PIC-XT        rtc
  9:          1    XT-PIC-XT        acpi
 10:          1    XT-PIC-XT        uhci_hcd:usb4, tifm_7xx1, yenta,
sdhci:slot0, sdhci:slot1, sdhci:slot2, Intel ICH6
 11:       3415    XT-PIC-XT        eth0, libata, uhci_hcd:usb1,
uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb5, ohci1394, ipw2200
 12:        116    XT-PIC-XT        i8042
 14:        129    XT-PIC-XT        libata
 15:          0    XT-PIC-XT        libata
NMI:          0
LOC:       6594
ERR:          0
MIS:          0

Full 2.6.21-rc3 boot log:
[    0.000000] Linux version 2.6.21-rc3 (root@manwe) (gcc version 4.1.2
(Ubuntu 4.1.2-0ubuntu4)) #1 PREEMPT Fri Mar 9 01:54:11 CET 2007
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] sanitize start
[    0.000000] sanitize end
[    0.000000] copy_e820_map() start: 0000000000000000 size:
000000000009f800 end: 000000000009f800 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 000000000009f800 size:
0000000000000800 end: 00000000000a0000 type: 2
[    0.000000] copy_e820_map() start: 00000000000d2000 size:
0000000000002000 end: 00000000000d4000 type: 2
[    0.000000] copy_e820_map() start: 00000000000dc000 size:
0000000000024000 end: 0000000000100000 type: 2
[    0.000000] copy_e820_map() start: 0000000000100000 size:
000000003fde0000 end: 000000003fee0000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 000000003fee0000 size:
000000000000a000 end: 000000003feea000 type: 3
[    0.000000] copy_e820_map() start: 000000003feea000 size:
0000000000016000 end: 000000003ff00000 type: 4
[    0.000000] copy_e820_map() start: 000000003ff00000 size:
0000000000100000 end: 0000000040000000 type: 2
[    0.000000] copy_e820_map() start: 00000000e0000000 size:
0000000010006000 end: 00000000f0006000 type: 2
[    0.000000] copy_e820_map() start: 00000000f0008000 size:
0000000000004000 end: 00000000f000c000 type: 2
[    0.000000] copy_e820_map() start: 00000000fed20000 size:
0000000000070000 end: 00000000fed90000 type: 2
[    0.000000] copy_e820_map() start: 00000000ff000000 size:
0000000001000000 end: 0000000100000000 type: 2
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
[    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
[    0.000000]  BIOS-e820: 000000003fee0000 - 000000003feea000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003feea000 - 000000003ff00000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0006000 (reserved)
[    0.000000]  BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[    0.000000] 126MB HIGHMEM available.
[    0.000000] 896MB LOWMEM available.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->   229376
[    0.000000]   HighMem    229376 ->   261856
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->   261856
[    0.000000] DMI present.
[    0.000000] ACPI: RSDP 000F6980, 0014 (r0 TOSCPL)
[    0.000000] ACPI: RSDT 3FEE276F, 0044 (r1 TOSCPL   RSDT    6040000 
LTP        0)
[    0.000000] ACPI: APIC 3FEE9E88, 0068 (r1 INTEL  ALVISO    6040000
LOHR       5F)
[    0.000000] ACPI: FACP 3FEE9EF0, 0074 (r1 TOSCPL ALVISO    6040000
LOHR       32)
[    0.000000] ACPI: DSDT 3FEE3217, 6C71 (r1 TOSCPL ALVISO    6040000
MSFT  100000E)
[    0.000000] ACPI: FACS 3FEFAFC0, 0040
[    0.000000] ACPI: BOOT 3FEE9FD8, 0028 (r1 PTLTD  $SBFTBL$  6040000 
LTP        1)
[    0.000000] ACPI: MCFG 3FEE9F9C, 003C (r1 INTEL  ALVISO    6040000
LOHR       5F)
[    0.000000] ACPI: SSDT 3FEE2FE5, 022E (r1 SataRe SataAhci     1000
INTL 20030224)
[    0.000000] ACPI: SSDT 3FEE2BAA, 022B (r1  PmRef  Cpu0Ist     3000
INTL 20030224)
[    0.000000] ACPI: SSDT 3FEE29CC, 01DE (r1  PmRef  Cpu0Cst     3001
INTL 20030224)
[    0.000000] ACPI: SSDT 3FEE27B3, 0219 (r1  PmRef    CpuPm     3000
INTL 20030224)
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] Processor #0 6:13 APIC version 20
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Enabling APIC mode:  Flat.  Using 1 I/O APICs
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at 50000000 (gap:
40000000:a0000000)
[    0.000000] Built 1 zonelists.  Total pages: 259811
[    0.000000] Kernel command line: root=/dev/mapper/Base-Root ro single
[    0.000000] Enabling fast FPU save and restore... done.
[    0.000000] Enabling unmasked SIMD FPU exception support... done.
[    0.000000] Initializing CPU#0
[    0.000000] CPU 0 irqstacks, hard=c034f000 soft=c034e000
[    0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[    0.000000] Detected 1729.086 MHz processor.
[   82.100659] Console: colour VGA+ 80x25
[   82.104287] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[   82.104813] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[   82.128315] Memory: 1031112k/1047424k available (1606k kernel code,
15544k reserved, 544k data, 184k init, 129920k highmem)
[   82.128378] virtual kernel memory layout:
[   82.128379]     fixmap  : 0xfffaa000 - 0xfffff000   ( 340 kB)
[   82.128381]     pkmap   : 0xffc00000 - 0xffe00000   (2048 kB)
[   82.128383]     vmalloc : 0xf8800000 - 0xffbfe000   ( 115 MB)
[   82.128385]     lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
[   82.128386]       .init : 0xc031b000 - 0xc0349000   ( 184 kB)
[   82.128388]       .data : 0xc029183b - 0xc0319bb4   ( 544 kB)
[   82.128390]       .text : 0xc0100000 - 0xc029183b   (1606 kB)
[   82.128741] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[   82.188878] Calibrating delay using timer specific routine.. 3460.07
BogoMIPS (lpj=1730037)
[   82.188995] Security Framework v1.0.0 initialized
[   82.189054] Mount-cache hash table entries: 512
[   82.189191] CPU: L1 I cache: 32K, L1 D cache: 32K
[   82.189271] CPU: L2 cache: 2048K
[   82.189321] Intel machine check architecture supported.
[   82.189367] Intel machine check reporting enabled on CPU#0.
[   82.189422] CPU: Intel(R) Pentium(R) M processor 1.73GHz stepping 08
[   82.189539] Checking 'hlt' instruction... OK.
[   82.192970] ACPI: Core revision 20070126
[   82.193084] ACPI: Table DSDT replaced by host OS
[   82.193197] ACPI: DSDT 00000000, 6305 (r1 TOSCPL ALVISO    6040000
INTL 20051117)
[   82.202965] ENABLING IO-APIC IRQs
[   82.203196] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[   82.416878] NET: Registered protocol family 16
[   82.416994] ACPI: bus type pci registered
[   82.417047] PCI: Using MMCONFIG
[   82.417737] Setting up standard PCI resources
[   82.422950] ACPI: Interpreter enabled
[   82.422996] ACPI: (supports S0 S3 S4 S5)
[   82.423228] ACPI: Using IOAPIC for interrupt routing
[   82.468401] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   82.468914] PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
[   82.468962] PCI quirk: region 1180-11bf claimed by ICH6 GPIO
[   82.469042] 0000:00:1f.1: trying to change BAR0 from 0000 to 01F0
[   82.469090] 0000:00:1f.1: trying to change BAR1 from 0000 to 03F4
[   82.469137] 0000:00:1f.1: trying to change BAR2 from 0000 to 0170
[   82.469184] 0000:00:1f.1: trying to change BAR3 from 0000 to 0374
[   82.469927] PCI: Transparent bridge - 0000:00:1e.0
[   82.470019] PCI: Bus #07 (-#0a) is hidden behind transparent bridge
#06 (-#07) (try 'pci=assign-busses')
[   82.470074] Please report the result to linux-kernel to fix this
permanently
[   82.477076] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 12
14 15)
[   82.477633] ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 11 12
14 15) *10
[   82.478229] ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12
14 15) *11
[   82.478831] ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *11 12
14 15)
[   82.479384] ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12
14 15) *11
[   82.479979] ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 *11 12
14 15)
[   82.480532] ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12
14 15) *11
[   82.481129] ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *11 12
14 15)
[   82.481670] Linux Plug and Play Support v0.97 (c) Adam Belay
[   82.481721] pnp: PnP ACPI init
[   82.503859] pnp: PnP ACPI: found 9 devices
[   82.503925] PCI: Using ACPI for IRQ routing
[   82.503970] PCI: If a device doesn't work, try "pci=routeirq".  If it
helps, post a report
[   82.504135] pnp: 00:01: ioport range 0xfe00-0xfe7f has been reserved
[   82.504182] pnp: 00:01: ioport range 0xfe80-0xfeff has been reserved
[   82.504229] pnp: 00:01: ioport range 0xff00-0xff7f has been reserved
[   82.504277] pnp: 00:01: iomem range 0xe0000000-0xefffffff has been
reserved
[   82.504324] pnp: 00:01: iomem range 0xf0000000-0xf0003fff has been
reserved
[   82.504372] pnp: 00:01: iomem range 0xf0004000-0xf0004fff has been
reserved
[   82.504420] pnp: 00:01: iomem range 0xf0005000-0xf0005fff has been
reserved
[   82.504712] Time: tsc clocksource has been installed.
[   82.534686] PCI: Bridge: 0000:00:01.0
[   82.534732]   IO window: 3000-3fff
[   82.534777]   MEM window: b8100000-b81fffff
[   82.534822]   PREFETCH window: c8000000-cfffffff
[   82.534868] PCI: Bridge: 0000:00:1c.0
[   82.534913]   IO window: 4000-4fff
[   82.534959]   MEM window: bc000000-bfffffff
[   82.535006]   PREFETCH window: d0000000-d3ffffff
[   82.535053] PCI: Bridge: 0000:00:1c.1
[   82.535098]   IO window: 5000-5fff
[   82.535144]   MEM window: c0000000-c3ffffff
[   82.535191]   PREFETCH window: d4000000-d7ffffff
[   82.535241] PCI: Bus 7, cardbus bridge: 0000:06:04.0
[   82.535287]   IO window: 00006400-000064ff
[   82.535334]   IO window: 00006800-000068ff
[   82.535381]   PREFETCH window: 50000000-53ffffff
[   82.535428]   MEM window: 54000000-57ffffff
[   82.535475] PCI: Bridge: 0000:00:1e.0
[   82.535520]   IO window: 6000-6fff
[   82.535567]   MEM window: c4000000-c40fffff
[   82.535614]   PREFETCH window: 50000000-53ffffff
[   82.535668] ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level,
low) -> IRQ 16
[   82.536458] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level,
low) -> IRQ 17
[   82.536562] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level,
low) -> IRQ 16
[   82.536674] ACPI: PCI Interrupt 0000:06:04.0[A] -> GSI 16 (level,
low) -> IRQ 16
[   82.536778] NET: Registered protocol family 2
[   82.546708] IP route cache hash table entries: 32768 (order: 5,
131072 bytes)
[   82.546828] TCP established hash table entries: 131072 (order: 8,
1048576 bytes)
[   82.547737] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
[   82.548053] TCP: Hash tables configured (established 131072 bind 65536)
[   82.548103] TCP reno registered
[   82.550814] checking if image is initramfs... it is
[   82.926145] Freeing initrd memory: 3943k freed
[   82.926322] Simple Boot Flag at 0x36 set to 0x1
[   82.926670] highmem bounce pool size: 64 pages
[   82.926717] Total HugeTLB memory allocated, 0
[   82.926848] io scheduler noop registered
[   82.926934] io scheduler cfq registered (default)
[   82.927311] assign_interrupt_mode Found MSI capability
[   82.927524] assign_interrupt_mode Found MSI capability
[   82.927748] assign_interrupt_mode Found MSI capability
[   82.929989] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[   82.930197] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at
0x60,0x64 irq 1,12
[   82.930435] i8042.c: Detected active multiplexing controller, rev 1.1.
[   82.930548] serio: i8042 KBD port at 0x60,0x64 irq 1
[   82.930624] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[   82.930694] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[   82.930762] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[   82.930830] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[   82.930924] mice: PS/2 mouse device common for all mice
[   82.931061] TCP cubic registered
[   82.931110] NET: Registered protocol family 1
[   82.931162] Using IPI Shortcut mode
[   82.931366] Freeing unused kernel memory: 184k freed
[   82.933520] input: AT Translated Set 2 keyboard as /class/input/input0
[   83.034411] Switched to high resolution mode on CPU 0
[   83.038869] 8139too Fast Ethernet driver 0.9.28
[   83.038971] ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 21 (level,
low) -> IRQ 18
[   83.039529] eth0: RealTek RTL8139 at 0xf8820000, 00:0f:b0:a5:9a:81,
IRQ 18
[   83.041859] netconsole: local port 5000
[   83.041905] netconsole: local IP 192.168.0.20
[   83.041950] netconsole: interface eth0
[   83.041994] netconsole: remote port 5000
[   83.042039] netconsole: remote IP 192.168.0.1
[   83.042084] netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
[   83.042131] netconsole: device eth0 not up yet, forcing it
[   83.042210] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   83.042967] netconsole: carrier detect appears untrustworthy, waiting
4 seconds
[   87.059120] netconsole: network logging started
[   87.064954] SCSI subsystem initialized
[   87.070057] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level,
low) -> IRQ 19
[   88.070489] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5
Gbps 0x5 impl IDE mode
[   88.070546] ahci 0000:00:1f.2: flags: 64bit ncq pm led slum part
[   88.070671] ata1: SATA max UDMA/133 cmd 0xf8824d00 ctl 0x00000000
bmdma 0x00000000 irq 19
[   88.070789] ata2: SATA max UDMA/133 cmd 0xf8824d80 ctl 0x00000000
bmdma 0x00000000 irq 19
[   88.070910] ata3: SATA max UDMA/133 cmd 0xf8824e00 ctl 0x00000000
bmdma 0x00000000 irq 19
[   88.071027] ata4: SATA max UDMA/133 cmd 0xf8824e80 ctl 0x00000000
bmdma 0x00000000 irq 19
[   88.071091] scsi0 : ahci
[   88.528373] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   88.573162] ata1.00: ATA-7: HTS541010G9SA00, MBZOC60D, max UDMA/100
[   88.573212] ata1.00: 195371568 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   88.575453] ata1.00: configured for UDMA/100
[   88.575503] scsi1 : ahci
[   88.878284] ata2: SATA link down (SStatus 0 SControl 0)
[   88.878338] scsi2 : ahci
[   89.181217] ata3: SATA link down (SStatus 0 SControl 300)
[   89.181270] scsi3 : ahci
[   89.484151] ata4: SATA link down (SStatus 0 SControl 0)
[   89.484277] scsi 0:0:0:0: Direct-Access     ATA      HTS541010G9SA00 
MBZO PQ: 0 ANSI: 5
[   89.488409] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12)
initialised: dm-devel@redhat.com
[   89.601570] usbcore: registered new interface driver usbfs
[   89.601649] usbcore: registered new interface driver hub
[   89.601716] usbcore: registered new device driver usb
[   89.602398] USB Universal Host Controller Interface driver v3.0
[   89.602495] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level,
low) -> IRQ 20
[   89.602607] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   89.602735] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned
bus number 1
[   89.602821] uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001800
[   89.602958] usb usb1: configuration #1 chosen from 1 choice
[   89.603026] hub 1-0:1.0: USB hub found
[   89.603077] hub 1-0:1.0: 2 ports detected
[   89.705230] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level,
low) -> IRQ 19
[   89.705354] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   89.705423] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned
bus number 2
[   89.705506] uhci_hcd 0000:00:1d.1: irq 19, io base 0x00001820
[   89.705633] usb usb2: configuration #1 chosen from 1 choice
[   89.705702] hub 2-0:1.0: USB hub found
[   89.705752] hub 2-0:1.0: 2 ports detected
[   89.806175] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level,
low) -> IRQ 21
[   89.806300] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   89.806370] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned
bus number 3
[   89.806455] uhci_hcd 0000:00:1d.2: irq 21, io base 0x00001840
[   89.806582] usb usb3: configuration #1 chosen from 1 choice
[   89.806652] hub 3-0:1.0: USB hub found
[   89.806703] hub 3-0:1.0: 2 ports detected
[   89.907109] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level,
low) -> IRQ 16
[   89.907217] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[   89.907288] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned
bus number 4
[   89.907370] uhci_hcd 0000:00:1d.3: irq 16, io base 0x00001860
[   89.907488] usb usb4: configuration #1 chosen from 1 choice
[   89.907556] hub 4-0:1.0: USB hub found
[   89.907606] hub 4-0:1.0: 2 ports detected
[   89.911054] usb 1-1: new low speed USB device using uhci_hcd and
address 2
[   90.008647] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level,
low) -> IRQ 20
[   90.008762] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   90.008827] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned
bus number 5
[   90.008912] ehci_hcd 0000:00:1d.7: debug port 1
[   90.008969] ehci_hcd 0000:00:1d.7: irq 20, io mem 0xb8000000
[   90.012903] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver
10 Dec 2004
[   90.013011] usb usb5: configuration #1 chosen from 1 choice
[   90.013084] hub 5-0:1.0: USB hub found
[   90.013135] hub 5-0:1.0: 8 ports detected
[   90.114194] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level,
low) -> IRQ 21
[   90.114347] ata5: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6
bmdma 0x000118c0 irq 14
[   90.114430] ata6: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376
bmdma 0x000118c8 irq 15
[   90.114511] scsi4 : ata_piix
[   90.419698] ata5.00: ATAPI, max UDMA/33
[   90.426941] usb 1-1: device not accepting address 2, error -71
[   90.574569] ata5.00: configured for UDMA/33
[   90.574624] scsi5 : ata_piix
[   90.574727] ata6: port disabled. ignoring.
[   90.576634] scsi 4:0:0:0: CD-ROM            MATSHITA DVD-RAM UJ-841S 
1.50 PQ: 0 ANSI: 5
[   90.576836] ACPI: PCI Interrupt 0000:06:04.2[C] -> GSI 18 (level,
low) -> IRQ 21
[   90.627288] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[21] 
MMIO=[c4006800-c4006fff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[   90.636552] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[   90.636620] sda: Write Protect is off
[   90.636689] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   90.636787] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[   90.636842] sda: Write Protect is off
[   90.636913] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   90.636970]  sda:<6>usb 1-1: new low speed USB device using uhci_hcd
and address 4
[   91.072397] usb 1-1: configuration #1 chosen from 1 choice
[   91.098889] input: Logitech USB Receiver as /class/input/input1
[   91.099036] input: USB HID v1.10 Mouse [Logitech USB Receiver] on
usb-0000:00:1d.0-1
[   91.099185] usbcore: registered new interface driver usbhid
[   91.099239] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[  120.630313] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
frozen
[  120.630373] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0
cdb 0x0 data 4096 in
[  120.630375]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  120.933235] ata1: soft resetting port
[  121.088217] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  121.093545] ata1.00: configured for UDMA/100
[  121.093600] ata1: EH complete
[  121.093682] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[  121.093739] sda: Write Protect is off
[  121.093805] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  151.086611] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
frozen
[  151.086665] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0
cdb 0x0 data 4096 in
[  151.086667]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  151.389541] ata1: soft resetting port
[  151.544521] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  151.549801] ata1.00: configured for UDMA/100
[  151.549852] ata1: EH complete
[  151.549921] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[  151.549976] sda: Write Protect is off
[  151.550042] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  181.542915] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
frozen
[  181.542970] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0
cdb 0x0 data 4096 in
[  181.542971]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  181.845846] ata1: soft resetting port
[  182.000827] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  182.006151] ata1.00: configured for UDMA/100
[  182.006202] ata1: EH complete
[  182.006271] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[  182.006325] sda: Write Protect is off
[  182.006391] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  211.999220] ata1.00: NCQ disabled due to excessive errors
[  211.999271] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
frozen
[  211.999329] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0
cdb 0x0 data 4096 in
[  211.999331]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  212.302152] ata1: soft resetting port
[  212.457132] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  212.462428] ata1.00: configured for UDMA/100
[  212.462479] ata1: EH complete
[  212.462547] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[  212.462602] sda: Write Protect is off
[  212.462668] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  212.477303]  sda1 sda2 < sda5 sda6 > sda3
[  212.521233] sd 0:0:0:0: Attached scsi disk sda
[  212.524556] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  212.524782] sr 4:0:0:0: Attached scsi generic sg1 type 5
[  212.530683] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw
xa/form2 cdda tray
[  212.530745] Uniform CD-ROM driver Revision: 3.20
[  212.855075] Attempting manual resume
[  212.923490] SGI XFS with ACLs, realtime, no debug enabled
[  212.982545] Filesystem "dm-0": Disabling barriers, not supported by
the underlying device
[  212.982815] XFS mounting filesystem dm-0
[  216.458088] input: PC Speaker as /class/input/input2
[  216.869753] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007)
[  216.874226] input: PS/2 Mouse as /class/input/input3
[  216.891684] Real Time Clock Driver v1.12ac
[  216.893113] input: AlpsPS/2 ALPS GlidePoint as /class/input/input4
[  216.896321] iTCO_wdt: Found a ICH6-M TCO device (Version=2,
TCOBASE=0x1060)
[  216.896402] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[  217.001241] Linux agpgart interface v0.102 (c) Dave Jones
[  217.007834] agpgart: Detected an Intel 915GM Chipset.
[  217.024646] agpgart: AGP aperture is 256M @ 0x0
[  217.044332] ACPI: PCI Interrupt 0000:06:04.3[B] -> GSI 17 (level,
low) -> IRQ 17
[  217.058492] sdhci: Secure Digital Host Controller Interface driver
[  217.058545] sdhci: Copyright(c) Pierre Ossman
[  217.058620] sdhci: SDHCI controller found at 0000:06:04.4 [104c:8034]
(rev 0)
[  217.058684] ACPI: PCI Interrupt 0000:06:04.4[D] -> GSI 19 (level,
low) -> IRQ 19
[  217.058832] mmc0: SDHCI at 0xc4009400 irq 19 DMA
[  217.058910] mmc1: SDHCI at 0xc4009000 irq 19 DMA
[  217.058988] mmc2: SDHCI at 0xc4006400 irq 19 DMA
[  217.590753] ieee80211: 802.11 data/management/control stack, git-1.1.13
[  217.590810] ieee80211: Copyright (C) 2004-2005 Intel Corporation
<jketreno@linux.intel.com>
[  217.622453] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver,
1.2.0kmprq
[  217.622511] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[  217.622637] ACPI: PCI Interrupt 0000:06:02.0[A] -> GSI 22 (level,
low) -> IRQ 22
[  217.622770] ipw2200: Detected Intel PRO/Wireless 2200BG Network
Connection
[  218.194017] ipw2200: Radio Frequency Kill Switch is On:
[  218.194020] Kill switch must be turned off for wireless networking to
work.
[  218.194193] ipw2200: Detected geography ZZM (11 802.11bg channels, 0
802.11a channels)
[  218.194287] Yenta: CardBus bridge found at 0000:06:04.0 [1179:ff00]
[  218.194356] Yenta: Enabling burst memory read transactions
[  218.194407] Yenta: Using CSCINT to route CSC interrupts to PCI
[  218.194460] Yenta: Routing CardBus interrupts to PCI
[  218.194515] Yenta TI: socket 0000:06:04.0, mfunc 0x10aa1b22, devctl 0x66
[  218.417563] Yenta: ISA IRQ mask 0x0cf8, PCI irq 16
[  218.417622] Socket status: 30000006
[  218.417675] Yenta: Raising subordinate bus# of parent bus (#06) from
#07 to #0a
[  218.417739] pcmcia: parent PCI bridge I/O window: 0x6000 - 0x6fff
[  218.417794] pcmcia: parent PCI bridge Memory window: 0xc4000000 -
0xc40fffff
[  218.417850] pcmcia: parent PCI bridge Memory window: 0x50000000 -
0x53ffffff
[  218.419219] ACPI: PCI Interrupt 0000:00:1e.2[A] -> GSI 17 (level,
low) -> IRQ 17
[  219.231630] intel8x0_measure_ac97_clock: measured 50495 usecs
[  219.231686] intel8x0: clocking to 48000
[  219.357519] Capability LSM initialized
[  219.432905] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3])
[  219.468590] Time: acpi_pm clocksource has been installed.
[  219.481281] Non-volatile memory driver v1.2
[  219.493925] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[  219.530293] IA-32 Microcode Update Driver: v1.14a
<tigran@aivazian.fsnet.co.uk>
[  219.542486] Machine check exception polling timer started.
[  219.592529] fuse init (API version 7.8)

Full 2.6.21-rc3 boot log with pci=noacpi:
[    0.000000] Linux version 2.6.21-rc3 (root@manwe) (gcc version 4.1.2
(Ubuntu 4.1.2-0ubuntu4)) #1 PREEMPT Fri Mar 9 01:54:11 CET 2007
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] sanitize start
[    0.000000] sanitize end
[    0.000000] copy_e820_map() start: 0000000000000000 size:
000000000009f800 end: 000000000009f800 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 000000000009f800 size:
0000000000000800 end: 00000000000a0000 type: 2
[    0.000000] copy_e820_map() start: 00000000000d2000 size:
0000000000002000 end: 00000000000d4000 type: 2
[    0.000000] copy_e820_map() start: 00000000000dc000 size:
0000000000024000 end: 0000000000100000 type: 2
[    0.000000] copy_e820_map() start: 0000000000100000 size:
000000003fde0000 end: 000000003fee0000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 000000003fee0000 size:
000000000000a000 end: 000000003feea000 type: 3
[    0.000000] copy_e820_map() start: 000000003feea000 size:
0000000000016000 end: 000000003ff00000 type: 4
[    0.000000] copy_e820_map() start: 000000003ff00000 size:
0000000000100000 end: 0000000040000000 type: 2
[    0.000000] copy_e820_map() start: 00000000e0000000 size:
0000000010006000 end: 00000000f0006000 type: 2
[    0.000000] copy_e820_map() start: 00000000f0008000 size:
0000000000004000 end: 00000000f000c000 type: 2
[    0.000000] copy_e820_map() start: 00000000fed20000 size:
0000000000070000 end: 00000000fed90000 type: 2
[    0.000000] copy_e820_map() start: 00000000ff000000 size:
0000000001000000 end: 0000000100000000 type: 2
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
[    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
[    0.000000]  BIOS-e820: 000000003fee0000 - 000000003feea000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003feea000 - 000000003ff00000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0006000 (reserved)
[    0.000000]  BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[    0.000000] 126MB HIGHMEM available.
[    0.000000] 896MB LOWMEM available.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->   229376
[    0.000000]   HighMem    229376 ->   261856
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->   261856
[    0.000000] DMI present.
[    0.000000] ACPI: RSDP 000F6980, 0014 (r0 TOSCPL)
[    0.000000] ACPI: RSDT 3FEE276F, 0044 (r1 TOSCPL   RSDT    6040000 
LTP        0)
[    0.000000] ACPI: APIC 3FEE9E88, 0068 (r1 INTEL  ALVISO    6040000
LOHR       5F)
[    0.000000] ACPI: FACP 3FEE9EF0, 0074 (r1 TOSCPL ALVISO    6040000
LOHR       32)
[    0.000000] ACPI: DSDT 3FEE3217, 6C71 (r1 TOSCPL ALVISO    6040000
MSFT  100000E)
[    0.000000] ACPI: FACS 3FEFAFC0, 0040
[    0.000000] ACPI: BOOT 3FEE9FD8, 0028 (r1 PTLTD  $SBFTBL$  6040000 
LTP        1)
[    0.000000] ACPI: MCFG 3FEE9F9C, 003C (r1 INTEL  ALVISO    6040000
LOHR       5F)
[    0.000000] ACPI: SSDT 3FEE2FE5, 022E (r1 SataRe SataAhci     1000
INTL 20030224)
[    0.000000] ACPI: SSDT 3FEE2BAA, 022B (r1  PmRef  Cpu0Ist     3000
INTL 20030224)
[    0.000000] ACPI: SSDT 3FEE29CC, 01DE (r1  PmRef  Cpu0Cst     3001
INTL 20030224)
[    0.000000] ACPI: SSDT 3FEE27B3, 0219 (r1  PmRef    CpuPm     3000
INTL 20030224)
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] Processor #0 6:13 APIC version 20
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] Allocating PCI resources starting at 50000000 (gap:
40000000:a0000000)
[    0.000000] Built 1 zonelists.  Total pages: 259811
[    0.000000] Kernel command line: root=/dev/mapper/Base-Root ro single
pci=noacpi
[    0.000000] Found and enabled local APIC!
[    0.000000] Enabling fast FPU save and restore... done.
[    0.000000] Enabling unmasked SIMD FPU exception support... done.
[    0.000000] Initializing CPU#0
[    0.000000] CPU 0 irqstacks, hard=c034f000 soft=c034e000
[    0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[    0.000000] Detected 1729.052 MHz processor.
[   28.094814] Console: colour VGA+ 80x25
[   28.098208] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[   28.098736] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[   28.122214] Memory: 1031112k/1047424k available (1606k kernel code,
15544k reserved, 544k data, 184k init, 129920k highmem)
[   28.122277] virtual kernel memory layout:
[   28.122279]     fixmap  : 0xfffaa000 - 0xfffff000   ( 340 kB)
[   28.122281]     pkmap   : 0xffc00000 - 0xffe00000   (2048 kB)
[   28.122282]     vmalloc : 0xf8800000 - 0xffbfe000   ( 115 MB)
[   28.122284]     lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
[   28.122286]       .init : 0xc031b000 - 0xc0349000   ( 184 kB)
[   28.122287]       .data : 0xc029183b - 0xc0319bb4   ( 544 kB)
[   28.122289]       .text : 0xc0100000 - 0xc029183b   (1606 kB)
[   28.122640] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[   28.182778] Calibrating delay using timer specific routine.. 3460.10
BogoMIPS (lpj=1730052)
[   28.182893] Security Framework v1.0.0 initialized
[   28.182952] Mount-cache hash table entries: 512
[   28.183089] CPU: L1 I cache: 32K, L1 D cache: 32K
[   28.183169] CPU: L2 cache: 2048K
[   28.183217] Intel machine check architecture supported.
[   28.183264] Intel machine check reporting enabled on CPU#0.
[   28.183318] CPU: Intel(R) Pentium(R) M processor 1.73GHz stepping 08
[   28.183435] Checking 'hlt' instruction... OK.
[   28.186871] ACPI: Core revision 20070126
[   28.186986] ACPI: Table DSDT replaced by host OS
[   28.187101] ACPI: DSDT 00000000, 6305 (r1 TOSCPL ALVISO    6040000
INTL 20051117)
[   28.189974] ACPI: setting ELCR to 0e00 (from 0c00)
[   28.400789] NET: Registered protocol family 16
[   28.400904] ACPI: bus type pci registered
[   28.400957] PCI: Using MMCONFIG
[   28.401645] Setting up standard PCI resources
[   28.406853] ACPI: Interpreter enabled
[   28.406900] ACPI: (supports S0 S3 S4 S5)
[   28.407132] ACPI: Using PIC for interrupt routing
[   28.452326] Linux Plug and Play Support v0.97 (c) Adam Belay
[   28.452378] pnp: PnP ACPI init
[   28.474767] pnp: PnP ACPI: found 9 devices
[   28.474837] PCI: Probing PCI hardware
[   28.475352] PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
[   28.475400] PCI quirk: region 1180-11bf claimed by ICH6 GPIO
[   28.475480] 0000:00:1f.1: trying to change BAR0 from 0000 to 01F0
[   28.475527] 0000:00:1f.1: trying to change BAR1 from 0000 to 03F4
[   28.475574] 0000:00:1f.1: trying to change BAR2 from 0000 to 0170
[   28.475621] 0000:00:1f.1: trying to change BAR3 from 0000 to 0374
[   28.476362] PCI: Transparent bridge - 0000:00:1e.0
[   28.476455] PCI: Bus #07 (-#0a) is hidden behind transparent bridge
#06 (-#07) (try 'pci=assign-busses')
[   28.476509] Please report the result to linux-kernel to fix this
permanently
[   28.477400] pnp: 00:01: ioport range 0xfe00-0xfe7f has been reserved
[   28.477448] pnp: 00:01: ioport range 0xfe80-0xfeff has been reserved
[   28.477496] pnp: 00:01: ioport range 0xff00-0xff7f has been reserved
[   28.477543] pnp: 00:01: iomem range 0xe0000000-0xefffffff has been
reserved
[   28.477591] pnp: 00:01: iomem range 0xf0000000-0xf0003fff has been
reserved
[   28.477638] Time: tsc clocksource has been installed.
[   28.477687] pnp: 00:01: iomem range 0xf0004000-0xf0004fff has been
reserved
[   28.477735] pnp: 00:01: iomem range 0xf0005000-0xf0005fff has been
reserved
[   28.508000] PCI: Bridge: 0000:00:01.0
[   28.508045]   IO window: 3000-3fff
[   28.508090]   MEM window: b8100000-b81fffff
[   28.508135]   PREFETCH window: c8000000-cfffffff
[   28.508181] PCI: Bridge: 0000:00:1c.0
[   28.508226]   IO window: 4000-4fff
[   28.508273]   MEM window: bc000000-bfffffff
[   28.508319]   PREFETCH window: d0000000-d3ffffff
[   28.508367] PCI: Bridge: 0000:00:1c.1
[   28.508412]   IO window: 5000-5fff
[   28.508458]   MEM window: c0000000-c3ffffff
[   28.508504]   PREFETCH window: d4000000-d7ffffff
[   28.508555] PCI: Bus 7, cardbus bridge: 0000:06:04.0
[   28.508600]   IO window: 00006400-000064ff
[   28.508648]   IO window: 00006800-000068ff
[   28.508695]   PREFETCH window: 50000000-53ffffff
[   28.508742]   MEM window: 54000000-57ffffff
[   28.508789] PCI: Bridge: 0000:00:1e.0
[   28.508834]   IO window: 6000-6fff
[   28.508881]   MEM window: c4000000-c40fffff
[   28.508927]   PREFETCH window: 50000000-53ffffff
[   28.509056] NET: Registered protocol family 2
[   28.517623] IP route cache hash table entries: 32768 (order: 5,
131072 bytes)
[   28.517744] TCP established hash table entries: 131072 (order: 8,
1048576 bytes)
[   28.518638] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
[   28.518950] TCP: Hash tables configured (established 131072 bind 65536)
[   28.518999] TCP reno registered
[   28.521728] checking if image is initramfs... it is
[   28.897082] Freeing initrd memory: 3943k freed
[   28.897258] Simple Boot Flag at 0x36 set to 0x1
[   28.897591] highmem bounce pool size: 64 pages
[   28.897638] Total HugeTLB memory allocated, 0
[   28.897770] io scheduler noop registered
[   28.897855] io scheduler cfq registered (default)
[   28.898234] assign_interrupt_mode Found MSI capability
[   28.898443] assign_interrupt_mode Found MSI capability
[   28.898670] assign_interrupt_mode Found MSI capability
[   28.900923] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[   28.901109] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at
0x60,0x64 irq 1,12
[   28.902057] i8042.c: Detected active multiplexing controller, rev 1.1.
[   28.902162] serio: i8042 KBD port at 0x60,0x64 irq 1
[   28.902241] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[   28.902314] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[   28.902401] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[   28.902470] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[   28.902560] mice: PS/2 mouse device common for all mice
[   28.902702] TCP cubic registered
[   28.902750] NET: Registered protocol family 1
[   28.902803] Using IPI Shortcut mode
[   28.903006] Freeing unused kernel memory: 184k freed
[   28.905169] input: AT Translated Set 2 keyboard as /class/input/input0
[   29.008326] Switched to high resolution mode on CPU 0
[   29.010655] 8139too Fast Ethernet driver 0.9.28
[   29.011221] eth0: RealTek RTL8139 at 0xf8820000, 00:0f:b0:a5:9a:81,
IRQ 11
[   29.013527] netconsole: local port 5000
[   29.013573] netconsole: local IP 192.168.0.20
[   29.013618] netconsole: interface eth0
[   29.013663] netconsole: remote port 5000
[   29.013708] netconsole: remote IP 192.168.0.1
[   29.013753] netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
[   29.013801] netconsole: device eth0 not up yet, forcing it
[   29.013879] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   29.014630] netconsole: carrier detect appears untrustworthy, waiting
4 seconds
[   33.029671] netconsole: network logging started
[   33.035522] SCSI subsystem initialized
[   34.041305] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5
Gbps 0x5 impl IDE mode
[   34.041363] ahci 0000:00:1f.2: flags: 64bit ncq pm led slum part
[   34.041503] ata1: SATA max UDMA/133 cmd 0xf8824d00 ctl 0x00000000
bmdma 0x00000000 irq 11
[   34.041628] ata2: SATA max UDMA/133 cmd 0xf8824d80 ctl 0x00000000
bmdma 0x00000000 irq 11
[   34.041754] ata3: SATA max UDMA/133 cmd 0xf8824e00 ctl 0x00000000
bmdma 0x00000000 irq 11
[   34.041881] ata4: SATA max UDMA/133 cmd 0xf8824e80 ctl 0x00000000
bmdma 0x00000000 irq 11
[   34.041942] scsi0 : ahci
[   34.499179] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   34.500247] ata1.00: ATA-7: HTS541010G9SA00, MBZOC60D, max UDMA/100
[   34.500297] ata1.00: 195371568 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   34.501605] ata1.00: configured for UDMA/100
[   34.501655] scsi1 : ahci
[   34.804094] ata2: SATA link down (SStatus 0 SControl 0)
[   34.804147] scsi2 : ahci
[   35.107022] ata3: SATA link down (SStatus 0 SControl 300)
[   35.107075] scsi3 : ahci
[   35.409949] ata4: SATA link down (SStatus 0 SControl 0)
[   35.410086] scsi 0:0:0:0: Direct-Access     ATA      HTS541010G9SA00 
MBZO PQ: 0 ANSI: 5
[   35.414197] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12)
initialised: dm-devel@redhat.com
[   35.525666] usbcore: registered new interface driver usbfs
[   35.525759] usbcore: registered new interface driver hub
[   35.525834] usbcore: registered new device driver usb
[   35.526522] USB Universal Host Controller Interface driver v3.0
[   35.526634] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   35.526769] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned
bus number 1
[   35.526860] uhci_hcd 0000:00:1d.0: irq 11, io base 0x00001800
[   35.527012] usb usb1: configuration #1 chosen from 1 choice
[   35.527090] hub 1-0:1.0: USB hub found
[   35.527140] hub 1-0:1.0: 2 ports detected
[   35.628035] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   35.628131] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned
bus number 2
[   35.628224] uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001820
[   35.628362] usb usb2: configuration #1 chosen from 1 choice
[   35.628442] hub 2-0:1.0: USB hub found
[   35.628492] hub 2-0:1.0: 2 ports detected
[   35.728979] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   35.729070] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned
bus number 3
[   35.729164] uhci_hcd 0000:00:1d.2: irq 11, io base 0x00001840
[   35.729308] usb usb3: configuration #1 chosen from 1 choice
[   35.729391] hub 3-0:1.0: USB hub found
[   35.729442] hub 3-0:1.0: 2 ports detected
[   35.829912] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[   35.829972] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned
bus number 4
[   35.830083] uhci_hcd 0000:00:1d.3: irq 10, io base 0x00001860
[   35.830216] usb usb4: configuration #1 chosen from 1 choice
[   35.830297] hub 4-0:1.0: USB hub found
[   35.830347] hub 4-0:1.0: 2 ports detected
[   35.833845] usb 1-1: new low speed USB device using uhci_hcd and
address 2
[   35.931272] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   35.931352] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned
bus number 5
[   35.931449] ehci_hcd 0000:00:1d.7: debug port 1
[   35.931505] ehci_hcd 0000:00:1d.7: irq 11, io mem 0xb8000000
[   35.935482] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver
10 Dec 2004
[   35.935607] usb usb5: configuration #1 chosen from 1 choice
[   35.935689] hub 5-0:1.0: USB hub found
[   35.935740] hub 5-0:1.0: 8 ports detected
[   36.092619] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11] 
MMIO=[c4006800-c4006fff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[   36.092998] ata5: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6
bmdma 0x000118c0 irq 14
[   36.093093] ata6: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376
bmdma 0x000118c8 irq 15
[   36.093188] scsi4 : ata_piix
[   36.350721] usb 1-1: device not accepting address 2, error -71
[   36.398196] ata5.00: ATAPI, max UDMA/33
[   36.553176] ata5.00: configured for UDMA/33
[   36.553230] scsi5 : ata_piix
[   36.553348] ata6: port disabled. ignoring.
[   36.555292] scsi 4:0:0:0: CD-ROM            MATSHITA DVD-RAM UJ-841S 
1.50 PQ: 0 ANSI: 5
[   36.564056] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[   36.564122] sda: Write Protect is off
[   36.564221] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   36.564332] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[   36.564386] sda: Write Protect is off
[   36.564478] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   36.564535]  sda:<6>usb 1-1: new low speed USB device using uhci_hcd
and address 4
[   36.995244]  sda1 sda2 <<6>usb 1-1: configuration #1 chosen from 1 choice
[   37.009405]  sda5 sda6 > sda3
[   37.016674] sd 0:0:0:0: Attached scsi disk sda
[   37.019316] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   37.019376] scsi 4:0:0:0: Attached scsi generic sg1 type 5
[   37.024809] input: Logitech USB Receiver as /class/input/input1
[   37.025012] input: USB HID v1.10 Mouse [Logitech USB Receiver] on
usb-0000:00:1d.0-1
[   37.025333] usbcore: registered new interface driver usbhid
[   37.025382] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[   37.026312] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw
xa/form2 cdda tray
[   37.026370] Uniform CD-ROM driver Revision: 3.20
[   37.362728] Attempting manual resume
[   37.419339] SGI XFS with ACLs, realtime, no debug enabled
[   37.472334] Filesystem "dm-0": Disabling barriers, not supported by
the underlying device
[   37.472746] XFS mounting filesystem dm-0
[   37.662579] Starting XFS recovery on filesystem: dm-0 (logdev: internal)
[   38.461059] Ending XFS recovery on filesystem: dm-0 (logdev: internal)
[   41.585513] Linux agpgart interface v0.102 (c) Dave Jones
[   41.724841] agpgart: Detected an Intel 915GM Chipset.
[   41.741921] agpgart: AGP aperture is 256M @ 0x0
[   41.757296] input: PS/2 Mouse as /class/input/input2
[   41.776092] input: AlpsPS/2 ALPS GlidePoint as /class/input/input3
[   41.804732] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007)
[   41.804867] iTCO_wdt: Found a ICH6-M TCO device (Version=2,
TCOBASE=0x1060)
[   41.804960] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   41.851929] Real Time Clock Driver v1.12ac
[   41.879265] input: PC Speaker as /class/input/input4
[   42.130778] ieee80211: 802.11 data/management/control stack, git-1.1.13
[   42.130835] ieee80211: Copyright (C) 2004-2005 Intel Corporation
<jketreno@linux.intel.com>
[   42.140470] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver,
1.2.0kmprq
[   42.140528] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[   42.140732] ipw2200: Detected Intel PRO/Wireless 2200BG Network
Connection
[   42.195824] sdhci: Secure Digital Host Controller Interface driver
[   42.195881] sdhci: Copyright(c) Pierre Ossman
[   43.540318] ipw2200: Radio Frequency Kill Switch is On:
[   43.540320] Kill switch must be turned off for wireless networking to
work.
[   43.540528] ipw2200: Detected geography ZZM (11 802.11bg channels, 0
802.11a channels)
[   43.540731] Yenta: CardBus bridge found at 0000:06:04.0 [1179:ff00]
[   43.540817] Yenta: Enabling burst memory read transactions
[   43.540869] Yenta: Using CSCINT to route CSC interrupts to PCI
[   43.540957] Yenta: Routing CardBus interrupts to PCI
[   43.541011] Yenta TI: socket 0000:06:04.0, mfunc 0x10aa1b22, devctl 0x66
[   43.764493] Yenta: ISA IRQ mask 0x00f8, PCI irq 10
[   43.764551] Socket status: 30000006
[   43.764641] Yenta: Raising subordinate bus# of parent bus (#06) from
#07 to #0a
[   43.764699] pcmcia: parent PCI bridge I/O window: 0x6000 - 0x6fff
[   43.764789] pcmcia: parent PCI bridge Memory window: 0xc4000000 -
0xc40fffff
[   43.764839] pcmcia: parent PCI bridge Memory window: 0x50000000 -
0x53ffffff
[   43.766222] sdhci: SDHCI controller found at 0000:06:04.4 [104c:8034]
(rev 0)
[   43.766360] mmc0: SDHCI at 0xc4009400 irq 10 DMA
[   43.766457] mmc1: SDHCI at 0xc4009000 irq 10 DMA
[   43.766552] mmc2: SDHCI at 0xc4006400 irq 10 DMA
[   44.580756] intel8x0_measure_ac97_clock: measured 50508 usecs
[   44.580812] intel8x0: clocking to 48000
[   44.704886] Capability LSM initialized
[   44.780120] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3])
[   44.801715] Time: acpi_pm clocksource has been installed.
[   44.828491] Non-volatile memory driver v1.2
[   44.841139] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[   44.877491] IA-32 Microcode Update Driver: v1.14a
<tigran@aivazian.fsnet.co.uk>
[   44.889690] Machine check exception polling timer started.
[   44.939740] fuse init (API version 7.8)
[   67.168309] Restarting system.

Thanks
-- 
Mathieu

and try remove another quirk on this computers Re: [3/6] 2.6.21-rc2: known regressions

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 7924 bytes --]

On Sat, 2007-03-10 at 02:09 +0100, Mathieu Bérard wrote:
> Jeff Garzik a écrit :
> > Adrian Bunk wrote:
> >> Subject    : NCQ problem with ahci and Hitachi drive
> >> References : http://lkml.org/lkml/2007/3/4/178
> >> Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
> >> Status     : unknown
> >
> > according to the last message in that thread, it sounds like ACPI and
> > interrupt problems
> >
> Hi,
> after more testing with a 2.6.21-rc3, it appears that after several ata
> errors the boot process
> somehow continued as normal, after a "NCQ disabled due to excessive
> errors" message.
> "pci=noacpi" or "noacpi" parameters workarounds the problem "irqpoll"
> does nothing.


Hi, I have a laptop quite similar to this report, but still running
2.4.20.
With /usr/bin/hal-device-manager on (00:1f.1) 82801FB/FBM/FR/FW/FRW
(ICH6 Family) IDE Controller (rev 03
I found that I have an Hitachi Travelstar 80GN. 

And your initial report point that you have an Hitachi Travelstar 5K100
and the patch http://lkml.org/lkml/2007/2/22/8 blacklist your HD ,
correct ? 

I will try 20-rc3 to see if I have any problem.
but blacklist it is not a good solution ... 

well I recently found a quirk that is apply on laptop that I mention
here. which I remove from my kernel because I don't have a Assus and my
laptop is quirked too. 

--- linux-2.6.20.i686/drivers/pci/quirks.c.orig 2007-03-04 04:52:21.000000000 +0000
+++ linux-2.6.20.i686/drivers/pci/quirks.c      2007-03-04 04:52:41.000000000 +0000
@@ -1121,8 +1121,8 @@ static void asus_hides_smbus_lpc_ich6(st
        iounmap(base);
        printk(KERN_INFO "PCI: Enabled ICH6/i801 SMBus device\n");
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_ICH6_1,     asus_hides_smbus_lpc_ich6 );
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_ICH6_1,     asus_hides_smbus_lpc_ich6 );
+/* DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,       PCI_DEVICE_ID_INTEL_ICH6_1,     asus_hides_smbus_lpc_ich6 ); */
+/* DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL,       PCI_DEVICE_ID_INTEL_ICH6_1,     asus_hides_smbus_lpc_ich6 ); */

 /*
  * SiS 96x south bridge: BIOS typically hides SMBus device...


With this quirk I got this oops on hibernate (but computer still
working) 

Suspending console(s)
eth1: Going into suspend...
ACPI: PCI interrupt for device 0000:02:04.0 disabled
ACPI: PCI interrupt for device 0000:00:1e.3 disabled
ACPI: PCI interrupt for device 0000:00:1e.2 disabled
ACPI: PCI interrupt for device 0000:00:1d.7 disabled
ACPI: PCI interrupt for device 0000:00:1d.3 disabled
ACPI: PCI interrupt for device 0000:00:1d.2 disabled
ACPI: PCI interrupt for device 0000:00:1d.1 disabled
ACPI: PCI interrupt for device 0000:00:1d.0 disabled
ipw2200: Unable to load ucode: -22
ipw2200: Unable to load firmware: -22
ipw2200: Failed to up device
swsusp: critical section:
swsusp: Need to copy 57480 pages
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
BUG: sleeping function called from invalid context at mm/slab.c:3035
in_atomic():0, irqs_disabled():1
no locks held by pm-hibernate/22979.
irq event stamp: 0
hardirqs last  enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c042580c>] copy_process+0x311/0x1249
softirqs last  enabled at (0): [<c042580c>] copy_process+0x311/0x1249
softirqs last disabled at (0): [<00000000>] 0x0
 [<c04051c9>] show_trace_log_lvl+0x1a/0x2f
 [<c040576e>] show_trace+0x12/0x14
 [<c04057f2>] dump_stack+0x16/0x18
 [<c0421266>] __might_sleep+0xc9/0xcf
 [<c0474cb1>] kmem_cache_alloc+0x28/0xc4
 [<c046bb50>] __get_vm_area_node+0x87/0x16f
 [<c046bcae>] __get_vm_area+0x22/0x28
 [<c046bcf3>] get_vm_area+0x3f/0x43
 [<c041f0ed>] __ioremap+0xa0/0xe6
 [<c041f147>] ioremap_nocache+0x14/0x79
 [<c04f070a>] asus_hides_smbus_lpc_ich6+0x37/0x61
 [<c04ef384>] pci_fixup_device+0x70/0x7c
 [<c04f0a70>] pci_device_resume_early+0x17/0x2e
 [<c0550779>] dpm_power_up+0x41/0x53
 [<c0550798>] device_power_up+0xd/0xf
 [<c0448bc4>] swsusp_suspend+0x55/0x62
 [<c044929c>] pm_suspend_disk+0xd5/0x181
 [<c04480a7>] enter_state+0x51/0x172
 [<c044824e>] state_store+0x86/0x9c
 [<c04b0a58>] subsys_attr_store+0x20/0x25
 [<c04b0b69>] sysfs_write_file+0xb8/0xe0
 [<c0478c68>] vfs_write+0xaf/0x163
 [<c04792b6>] sys_write+0x3d/0x61
 [<c0404058>] syscall_call+0x7/0xb
 =======================
PCI: Enabled ICH6/i801 SMBus device

removing quirk resolve the oops.

BTW I have an HP Compaq nx6110 , what laptop is yours ? 

ah! and WTF I don't attach your dmesg in a file ? 
 
> 
> lspci:
> 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
> Express Processor to DRAM Controller (rev 03)
> 00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI
> Express Root Port (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) PCI Express Port 1 (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) PCI Express Port 2 (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) USB UHCI #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) USB UHCI #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) USB UHCI #3 (rev 03)
> 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) USB UHCI #4 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) USB2 EHCI Controller (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
> 00:1e.2 Multimedia audio controller: Intel Corporation
> 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
> 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
> AC'97 Modem Controller (rev 03)
> 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface
> Bridge (rev 03)
> 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) IDE Controller (rev 03)
> 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA
> Controller (rev 03)
> 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
> SMBus Controller (rev 03)
> 01:00.0 VGA compatible controller: ATI Technologies Inc M24 [Radeon
> Mobility X600]
> 06:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 06:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG
> Network Connection (rev 05)
> 06:04.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
> 06:04.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394
> Host Controller
> 06:04.3 Mass storage controller: Texas Instruments PCIxx21 Integrated
> FlashMedia Controller
> 06:04.4 Generic system peripheral [0805]: Texas Instruments
> PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
> 
> 
> /proc/interrupts:
>         CPU0      
>   0:       3242   IO-APIC-edge      timer
>   1:        863   IO-APIC-edge      i8042
>   8:          3   IO-APIC-edge      rtc
>   9:          1   IO-APIC-fasteoi   acpi
>  12:        116   IO-APIC-edge      i8042
>  14:        128   IO-APIC-edge      libata
>  15:          0   IO-APIC-edge      libata
>  16:          1   IO-APIC-fasteoi   uhci_hcd:usb4, yenta
>  17:          0   IO-APIC-fasteoi   tifm_7xx1, Intel ICH6
>  18:        249   IO-APIC-fasteoi   eth0
>  19:       2712   IO-APIC-fasteoi   libata, uhci_hcd:usb2, sdhci:slot0,
> sdhci:slot1, sdhci:slot2
>  20:         47   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
>  21:          3   IO-APIC-fasteoi   uhci_hcd:usb3, ohci1394
>  22:          1   IO-APIC-fasteoi   ipw2200
> NMI:          0
> LOC:      15767
> ERR:          0
> MIS:          0


-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2192 bytes --]

Re: and try remove another quirk on this computers Re: [3/6] 2.6.21-rc2: known regressions

[Linus Torvalds]

On Sat, 10 Mar 2007, Sergio Monteiro Basto wrote:
> 
> With this quirk I got this oops on hibernate (but computer still
> working) 

Well, strictly speaking it's a warning, not an oops per se. 

What happens is that the quirk wants to do an "ioremap_nocache()", which 
allocates memory, and that happens very early during initialization when 
interrupts are disabled.

And you're really not supposed to allocate memory, except using 
GFP_ATOMIC. But we've always been lax about that during early boot, so we 
have stuff that does. And resume ends up doing a lot of the same things 
early boot does, and shows issues like this.

So the quirk is probably still a good idea, and the warning message is 
just that - a very scary warning message, but not an indicator that 
anything is seriously screwed up for you.

(It is an indication of a real bug, though, even though it's harmless in 
practice in this case)

		Linus

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Pavel Machek <pavel@suse.cz> wrote:

> > Even if one doesn't use the fb console at all, radeonfb apparently 
> > is still required on some ThinkPad models to work around BIOS bugs:
> > 
> > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
> 
> 
> s2ram should be able to work around this, it has parts from 
> radeontool. (suspend.sf.net).

i'm wondering, do you have any idea how Windows handles the 
suspend/resume quirks problem area? Do they "curse BIOS vendors and 
maintain a large DB of DMI-driven exceptions", or do they perhaps have 
some fundamentally better approach than us? If it's the former, then we 
might as well try to bring more automatism (and more of your database) 
into the kernel itself.

btw., the s2ram database seems quite a bit spotty:

 $ ./s2ram -n
 Machine is unknown.
 This machine can be identified by:
     sys_vendor   = "System manufacturer"
     sys_product  = "System Product Name"
     sys_version  = "System Version"
     bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"

 $ ./s2ram -n
 Machine is unknown.
 This machine can be identified by:
    sys_vendor   = "Hewlett-Packard "
    sys_product  = "compaq nx9030 (PG630ET#ABD)       "
    sys_version  = "Rev 1           "
    bios_version = "F.15    "
 See http://en.opensuse.org/S2ram for details.

even at the link above i didnt find any clear algorithm about how to 
extend the quirks-list and the white-list - while i expect that most 
people experience what i did: that s2ram doesnt know their boxes. 
(otherwise they would not visit that URL at all i suspect)

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Stefan Seyfried]

On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@suse.cz> wrote:
> > s2ram should be able to work around this, it has parts from 
> > radeontool. (suspend.sf.net).
> 
> i'm wondering, do you have any idea how Windows handles the 
> suspend/resume quirks problem area? Do they "curse BIOS vendors and 
> maintain a large DB of DMI-driven exceptions", or do they perhaps have 
> some fundamentally better approach than us? If it's the former, then we 
> might as well try to bring more automatism (and more of your database) 
> into the kernel itself.

I think that in windows, you simply install the "HP nx$FOOBAR intel graphics
driver" on a nx$FOOBAR machine, and the "ASUS $FOOBAR ATI graphics driver"
on an ASUS $FOOBAR machine etc. Those drivers are mostly stock intel/ATI/
whoever drivers, but with the little bit of extra knowledge on how to wake
up the graphics chip.

And there is no console mode in Windows. If you restrict yourself to
"it works from X", many machines do not need workarounds.
 
> btw., the s2ram database seems quite a bit spotty:
> 
>  $ ./s2ram -n
>  Machine is unknown.
>  This machine can be identified by:
>      sys_vendor   = "System manufacturer"
>      sys_product  = "System Product Name"
>      sys_version  = "System Version"
>      bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"
> 
>  $ ./s2ram -n
>  Machine is unknown.
>  This machine can be identified by:
>     sys_vendor   = "Hewlett-Packard "
>     sys_product  = "compaq nx9030 (PG630ET#ABD)       "
>     sys_version  = "Rev 1           "
>     bios_version = "F.15    "
>  See http://en.opensuse.org/S2ram for details.
> 
> even at the link above i didnt find any clear algorithm about how to 
> extend the quirks-list and the white-list - while i expect that most 
> people experience what i did: that s2ram doesnt know their boxes. 
> (otherwise they would not visit that URL at all i suspect)

Ok. To be honest, you are the first reporter that seems to have read the
documentation above, but not understood what to do.

So i'll put it into even simpler steps:

 - get the current version of s2ram
 - boot your system with init=/bin/bash, mount /proc and /sys
 - try the s2ram options in the combinations listed on the above page
 - as soon as you find an option that works, please retry it from a
   full booted system (including X)
 - if it still works, please report the options used and the output of
   "s2ram -n" to the suspend-devel mailinglist.

i might consider reworking the documentation if there are more reports
about problems with the procedure.
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out." 

Re: [2/6] 2.6.21-rc2: known regressions

[Johannes Stezenbach]

On Sat, Mar 10, 2007 at 12:43:01PM +0100, Stefan Seyfried wrote:
> On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
> > 
> > i'm wondering, do you have any idea how Windows handles the 
> > suspend/resume quirks problem area? Do they "curse BIOS vendors and 
> > maintain a large DB of DMI-driven exceptions", or do they perhaps have 
> > some fundamentally better approach than us? If it's the former, then we 
> > might as well try to bring more automatism (and more of your database) 
> > into the kernel itself.
> 
> I think that in windows, you simply install the "HP nx$FOOBAR intel graphics
> driver" on a nx$FOOBAR machine, and the "ASUS $FOOBAR ATI graphics driver"
> on an ASUS $FOOBAR machine etc. Those drivers are mostly stock intel/ATI/
> whoever drivers, but with the little bit of extra knowledge on how to wake
> up the graphics chip.

That's also what the thinkwiki page suggests. It says:

"Affected Operating Systems:
  * Linux, all flavours.
  * Windows, for some models as well (only when using non-IBM drivers).
  * FreeBSD (on the A22M)"


Johannes

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Stefan Seyfried <seife@suse.de> wrote:

> > btw., the s2ram database seems quite a bit spotty:
> > 
> >  $ ./s2ram -n
> >  Machine is unknown.
> >  This machine can be identified by:
> >      sys_vendor   = "System manufacturer"
> >      sys_product  = "System Product Name"
> >      sys_version  = "System Version"
> >      bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"
> > 
> >  $ ./s2ram -n
> >  Machine is unknown.
> >  This machine can be identified by:
> >     sys_vendor   = "Hewlett-Packard "
> >     sys_product  = "compaq nx9030 (PG630ET#ABD)       "
> >     sys_version  = "Rev 1           "
> >     bios_version = "F.15    "
> >  See http://en.opensuse.org/S2ram for details.
> > 
> > even at the link above i didnt find any clear algorithm about how to 
> > extend the quirks-list and the white-list - while i expect that most 
> > people experience what i did: that s2ram doesnt know their boxes. 
> > (otherwise they would not visit that URL at all i suspect)
> 
> Ok. To be honest, you are the first reporter that seems to have read 
> the documentation above, but not understood what to do.

thanks for the compliment ;-) _I_ very much know what to do (i mailed 
the right person after all ;), but i dont really count and on the 6 
systems i tried s2ram said on 5 that it's 'unknown', i assumed it could 
possibly be due to the visible lack of clear instructions on that 
webpage ;-)

> i might consider reworking the documentation if there are more reports 
> about problems with the procedure.

Probably tweaking the webpage doesnt help because people dont get there 
- as the results plainly show it. Maybe some more automation would be 
useful too, a tool that detects failed resume and tries all those 
options that makes sense on that box or something? It's not like that 
people dont _try_ suspend/resume on Linux, it's just that they find it 
doesnt work and there is no clear mortal-usable (end-user-) way of 
fixing it and submitting the result of that fixing.

	Ingo

s2ram (was Re: [2/6] 2.6.21-rc2: known regressions)

[Pavel Machek]

Hi!

> > > Even if one doesn't use the fb console at all, radeonfb apparently 
> > > is still required on some ThinkPad models to work around BIOS bugs:
> > > 
> > > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
> > 
> > 
> > s2ram should be able to work around this, it has parts from 
> > radeontool. (suspend.sf.net).
> 
> i'm wondering, do you have any idea how Windows handles the 
> suspend/resume quirks problem area? Do they "curse BIOS vendors and 

Windows actually have (kernel) graphics drivers that know how to
resume the video. If you boot save mode, they go w/o graphics drivers,
and have similar problems to us.

> btw., the s2ram database seems quite a bit spotty:
> 
>  $ ./s2ram -n
>  Machine is unknown.
>  This machine can be identified by:
>      sys_vendor   = "System manufacturer"
>      sys_product  = "System Product Name"
>      sys_version  = "System Version"
>      bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"
> 
>  $ ./s2ram -n
>  Machine is unknown.
>  This machine can be identified by:
>     sys_vendor   = "Hewlett-Packard "
>     sys_product  = "compaq nx9030 (PG630ET#ABD)       "
>     sys_version  = "Rev 1           "
>     bios_version = "F.15    "
>  See http://en.opensuse.org/S2ram for details.

Desktops are the problem; but that nx9030 should be reasonably easy to
add.

> even at the link above i didnt find any clear algorithm about how to 
> extend the quirks-list and the white-list - while i expect that most 
> people experience what i did: that s2ram doesnt know their boxes. 
> (otherwise they would not visit that URL at all i suspect)

Did you get options for s2ram that work on your systems? Mail them to
seife@suse.de, and he'll extend the whitelist ;-). In the meantime,
just use -f <whatever>
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [2/6] 2.6.21-rc2: known regressions

[Pavel Machek]

Hi!

> > Ok. To be honest, you are the first reporter that seems to have read 
> > the documentation above, but not understood what to do.
> 
> thanks for the compliment ;-) _I_ very much know what to do (i mailed 
> the right person after all ;), but i dont really count and on the 6 

(Can we get the whitelist entries?)

> > i might consider reworking the documentation if there are more reports 
> > about problems with the procedure.
> 
> Probably tweaking the webpage doesnt help because people dont get there 
> - as the results plainly show it. Maybe some more automation would be 
> useful too, a tool that detects failed resume and tries all those 
> options that makes sense on that box or something? It's not like
> that 

Unfortunately, these tend to crash the box when you pass wrong
options, and I do not see easy way to test "can user see whats on
display" automatically.

Feel free to send patches, but I do not think it is easy/possible.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: and try remove another quirk on this computers Re: [3/6] 2.6.21-rc2: known regressions

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Fri, 2007-03-09 at 21:41 -0800, Linus Torvalds wrote:
> 
> On Sat, 10 Mar 2007, Sergio Monteiro Basto wrote:
> > 
> > With this quirk I got this oops on hibernate (but computer still
> > working) 
> 
> Well, strictly speaking it's a warning, not an oops per se. 
> 
> What happens is that the quirk wants to do an "ioremap_nocache()", which 
> allocates memory, and that happens very early during initialization when 
> interrupts are disabled.
> 
> And you're really not supposed to allocate memory, except using 
> GFP_ATOMIC. But we've always been lax about that during early boot, so we 
> have stuff that does. And resume ends up doing a lot of the same things 
> early boot does, and shows issues like this.
> 
> So the quirk is probably still a good idea, and the warning message is 
> just that - a very scary warning message, but not an indicator that 
> anything is seriously screwed up for you.
> 
> (It is an indication of a real bug, though, even though it's harmless in 
> practice in this case)

Hi, thanks 
Just to write, I test last fedora kernel(2.6.20-1.2981.fc7) which is
based on 2.6.21-rc3-git5, without any problem, less than the scary
warning, talked in this email :)

Best regards,
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2192 bytes --]

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Pavel Machek <pavel@suse.cz> wrote:

> > Probably tweaking the webpage doesnt help because people dont get 
> > there - as the results plainly show it. Maybe some more automation 
> > would be useful too, a tool that detects failed resume and tries all 
> > those options that makes sense on that box or something? It's not 
> > like that
> 
> Unfortunately, these tend to crash the box when you pass wrong 
> options, and I do not see easy way to test "can user see whats on 
> display" automatically.

you could perhaps try what X's modesetting utility does: display a 
dialog box that times out if it does not get clicked on, and reboot if 
it did not get clicked on. Likewise, detect upon the next bootup that a 
suspend-test was in progress (and didnt get back via normal resume), via 
some temporary file. That way both the 'did not resume and i had to 
power-cycle' and the 'resume did not restore my X' problems can be 
handled.

Finally, when the correct options have been established (worse-case with 
a small number of reboots and "yes, indeed the resume did not work fine" 
clicks done upon bootup by the user), automatically fill in a webform in 
firefox and ask the user to do a single click to submit that form.

techniques like that have more chance i think to get Linux 
suspend/resume anywhere near to working. The current 'rely on the 
developer' technique apparently does not work.

	Ingo

Re: [2/6] 2.6.21-rc2: known regressions

[Stefan Seyfried]

On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@suse.cz> wrote:
> > Unfortunately, these tend to crash the box when you pass wrong 
> > options, and I do not see easy way to test "can user see whats on 
> > display" automatically.
> 
> you could perhaps try what X's modesetting utility does: display a 
> dialog box that times out if it does not get clicked on, and reboot if 
> it did not get clicked on. Likewise, detect upon the next bootup that a 
> suspend-test was in progress (and didnt get back via normal resume), via 
> some temporary file. That way both the 'did not resume and i had to 
> power-cycle' and the 'resume did not restore my X' problems can be 
> handled.
> 
> Finally, when the correct options have been established (worse-case with 
> a small number of reboots and "yes, indeed the resume did not work fine" 
> clicks done upon bootup by the user), automatically fill in a webform in 
> firefox and ask the user to do a single click to submit that form.

There is ongoing work to make something like this happen, but it will
take some time (very probably the whitelist will end up in a HAL fdi-file
which gives the additional advantage that interested vendors can supply a
linux-"driver" for their notebooks which makes suspend "just work" (the
"driver" simply being a .fdi-file that lists the workaround for this
particular machine)

> techniques like that have more chance i think to get Linux 
> suspend/resume anywhere near to working. The current 'rely on the 
> developer' technique apparently does not work.

It is not too bad actually, i seem to be getting lots of whitelist
entries from people that are first time shell users, and i usually
walk them through the process in just one or two mails. But yes, it
does not scale well ;-)

I was already thinking about some more sophisticated "wildcard" matching,
something like "if it is a HP and it has an ATI gfx chip, and we do
not have an exact match, then do VBE_POST|VBE_MODE" or similar, which
would probably get many machines working fine (it turns out that almost
all new machines from a vendor with similar hardware need similar
workarounds, but for example the hp's with ATI need different quirks
than the hp's with intel. Only thinkpads seem to almost universally work
with s3_bios,s3_mode, with some x86_64 models being the exception).
Something like that should be pretty easy once the whitelist is kept
in HAL.
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out." 

Re: [3/6] 2.6.21-rc2: known regressions

[Tejun Heo]

Mathieu Bérard wrote:
> Jeff Garzik a écrit :
>> Adrian Bunk wrote:
>>> Subject    : NCQ problem with ahci and Hitachi drive
>>> References : http://lkml.org/lkml/2007/3/4/178
>>> Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
>>> Status     : unknown
>> according to the last message in that thread, it sounds like ACPI and
>> interrupt problems
>>
> Hi,
> after more testing with a 2.6.21-rc3, it appears that after several ata
> errors the boot process
> somehow continued as normal, after a "NCQ disabled due to excessive
> errors" message.
> "pci=noacpi" or "noacpi" parameters workarounds the problem "irqpoll"
> does nothing.

I was mistaken.  It can't be IRQ routing problem.  I somehow thought the
port was a ata_piix one.  Considering the reported broken NCQ feature on
the device GTF might be mangling with the drive to disable NCQ or
something.  Does giving "libata.noacpi=1" make any difference?

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3/6] 2.6.21-rc2: known regressions

[Mathieu Bérard]

Tejun Heo a écrit :
> > Mathieu Bérard wrote:
>> >> Jeff Garzik a écrit :
>>> >>> Adrian Bunk wrote:
>>>> >>>> Subject    : NCQ problem with ahci and Hitachi drive
>>>> >>>> References : http://lkml.org/lkml/2007/3/4/178
>>>> >>>> Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
>>>> >>>> Status     : unknown
>>> >>> according to the last message in that thread, it sounds like
ACPI and
>>> >>> interrupt problems
>>> >>>
>> >> Hi,
>> >> after more testing with a 2.6.21-rc3, it appears that after
several ata
>> >> errors the boot process
>> >> somehow continued as normal, after a "NCQ disabled due to excessive
>> >> errors" message.
>> >> "pci=noacpi" or "noacpi" parameters workarounds the problem "irqpoll"
>> >> does nothing.
> >
> > I was mistaken.  It can't be IRQ routing problem.  I somehow thought the
> > port was a ata_piix one.  Considering the reported broken NCQ feature on
> > the device GTF might be mangling with the drive to disable NCQ or
> > something.  Does giving "libata.noacpi=1" make any difference?
> >

Hi,
libata.noacpi=1 worked. The drive is up and running with NCQ on.
Here is the PATA/SATA related part of my DSDT table with the _GTF methods:

Device (PATA)
{
    Name (_ADR, 0x001F0001)
    OperationRegion (PACS, PCI_Config, 0x40, 0xC0)
    Field (PACS, DWordAcc, NoLock, Preserve)
    {
        PRIT,   16,
        Offset (0x04),
        PSIT,   4,
        Offset (0x08),
        SYNC,   4,
        Offset (0x0A),
        SDT0,   2,
            ,   2,
        SDT1,   2,
        Offset (0x14),
        ICR0,   4,
        ICR1,   4,
        ICR2,   4,
        ICR3,   4,
        ICR4,   4,
        ICR5,   4
    }

    Device (PRID)
    {
        Name (_ADR, 0x00)
        Method (_GTM, 0, NotSerialized)
        {
            Name (PBUF, Buffer (0x14)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00
            })
            CreateDWordField (PBUF, 0x00, PIO0)
            CreateDWordField (PBUF, 0x04, DMA0)
            CreateDWordField (PBUF, 0x08, PIO1)
            CreateDWordField (PBUF, 0x0C, DMA1)
            CreateDWordField (PBUF, 0x10, FLAG)
            Store (GETP (PRIT), PIO0)
            Store (GDMA (And (SYNC, 0x01), And (ICR3, 0x01), And (ICR0,
0x01), SDT0, And (ICR1, 0x01)), DMA0)
            If (LEqual (DMA0, 0xFFFFFFFF))
            {
                Store (PIO0, DMA0)
            }

            If (And (PRIT, 0x4000))
            {
                If (LEqual (And (PRIT, 0x90), 0x80))
                {
                    Store (0x0384, PIO1)
                }
                Else
                {
                    Store (GETT (PSIT), PIO1)
                }
            }
            Else
            {
                Store (0xFFFFFFFF, PIO1)
            }

            Store (GDMA (And (SYNC, 0x02), And (ICR3, 0x02), And (ICR0,
0x02), SDT1, And (ICR1, 0x02)), DMA1)
            If (LEqual (DMA1, 0xFFFFFFFF))
            {
                Store (PIO1, DMA1)
            }

            Store (GETF (And (SYNC, 0x01), And (SYNC, 0x02), PRIT), FLAG)
            If (And (LEqual (PIO0, 0xFFFFFFFF), LEqual (DMA0, 0xFFFFFFFF)))
            {
                Store (0x78, PIO0)
                Store (0x14, DMA0)
                Store (0x03, FLAG)
            }

            Return (PBUF)
        }

        Method (_STM, 3, NotSerialized)
        {
            CreateDWordField (Arg0, 0x00, PIO0)
            CreateDWordField (Arg0, 0x04, DMA0)
            CreateDWordField (Arg0, 0x08, PIO1)
            CreateDWordField (Arg0, 0x0C, DMA1)
            CreateDWordField (Arg0, 0x10, FLAG)
            If (LEqual (SizeOf (Arg1), 0x0200))
            {
                And (PRIT, 0x40F0, PRIT)
                And (SYNC, 0x02, SYNC)
                Store (0x00, SDT0)
                And (ICR0, 0x02, ICR0)
                And (ICR1, 0x02, ICR1)
                And (ICR3, 0x02, ICR3)
                And (ICR5, 0x02, ICR5)
                CreateWordField (Arg1, 0x62, W490)
                CreateWordField (Arg1, 0x6A, W530)
                CreateWordField (Arg1, 0x7E, W630)
                CreateWordField (Arg1, 0x80, W640)
                CreateWordField (Arg1, 0xB0, W880)
                CreateWordField (Arg1, 0xBA, W930)
                Or (PRIT, 0x8004, PRIT)
                If (LAnd (And (FLAG, 0x02), And (W490, 0x0800)))
                {
                    Or (PRIT, 0x02, PRIT)
                }

                Or (PRIT, SETP (PIO0, W530, W640), PRIT)
                If (And (FLAG, 0x01))
                {
                    Or (SYNC, 0x01, SYNC)
                    Store (SDMA (DMA0), SDT0)
                    If (LLess (DMA0, 0x1E))
                    {
                        Or (ICR3, 0x01, ICR3)
                    }

                    If (LLess (DMA0, 0x3C))
                    {
                        Or (ICR0, 0x01, ICR0)
                    }

                    If (And (W930, 0x2000))
                    {
                        Or (ICR1, 0x01, ICR1)
                    }
                }
            }

            If (LEqual (SizeOf (Arg2), 0x0200))
            {
                And (PRIT, 0x3F0F, PRIT)
                Store (0x00, PSIT)
                And (SYNC, 0x01, SYNC)
                Store (0x00, SDT1)
                And (ICR0, 0x01, ICR0)
                And (ICR1, 0x01, ICR1)
                And (ICR3, 0x01, ICR3)
                And (ICR5, 0x01, ICR5)
                CreateWordField (Arg2, 0x62, W491)
                CreateWordField (Arg2, 0x6A, W531)
                CreateWordField (Arg2, 0x7E, W631)
                CreateWordField (Arg2, 0x80, W641)
                CreateWordField (Arg2, 0xB0, W881)
                CreateWordField (Arg2, 0xBA, W931)
                Or (PRIT, 0x8040, PRIT)
                If (LAnd (And (FLAG, 0x08), And (W491, 0x0800)))
                {
                    Or (PRIT, 0x20, PRIT)
                }

                If (And (FLAG, 0x10))
                {
                    Or (PRIT, 0x4000, PRIT)
                    If (LGreater (PIO1, 0xF0))
                    {
                        Or (PRIT, 0x80, PRIT)
                    }
                    Else
                    {
                        Or (PRIT, 0x10, PRIT)
                        Store (SETT (PIO1, W531, W641), PSIT)
                    }
                }

                If (And (FLAG, 0x04))
                {
                    Or (SYNC, 0x02, SYNC)
                    Store (SDMA (DMA1), SDT1)
                    If (LLess (DMA1, 0x1E))
                    {
                        Or (ICR3, 0x02, ICR3)
                    }

                    If (LLess (DMA1, 0x3C))
                    {
                        Or (ICR0, 0x02, ICR0)
                    }

                    If (And (W931, 0x2000))
                    {
                        Or (ICR1, 0x02, ICR1)
                    }
                }
            }
        }

        Device (P_D0)
        {
            Name (_ADR, 0x00)
            Method (_GTF, 0, NotSerialized)
            {
                Name (PIB0, Buffer (0x0E)
                {
                    0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03,
                    0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF
                })
                CreateByteField (PIB0, 0x01, PMD0)
                CreateByteField (PIB0, 0x08, DMD0)
                If (And (PRIT, 0x02))
                {
                    If (LEqual (And (PRIT, 0x09), 0x08))
                    {
                        Store (0x08, PMD0)
                    }
                    Else
                    {
                        Store (0x0A, PMD0)
                        ShiftRight (And (PRIT, 0x0300), 0x08, Local0)
                        ShiftRight (And (PRIT, 0x3000), 0x0C, Local1)
                        Add (Local0, Local1, Local2)
                        If (LEqual (0x03, Local2))
                        {
                            Store (0x0B, PMD0)
                        }

                        If (LEqual (0x05, Local2))
                        {
                            Store (0x0C, PMD0)
                        }
                    }
                }
                Else
                {
                    Store (0x01, PMD0)
                }

                If (And (SYNC, 0x01))
                {
                    Store (Or (SDT0, 0x40), DMD0)
                    If (And (ICR1, 0x01))
                    {
                        If (And (ICR0, 0x01))
                        {
                            Add (DMD0, 0x02, DMD0)
                        }

                        If (And (ICR3, 0x01))
                        {
                            Store (0x45, DMD0)
                        }
                    }
                }
                Else
                {
                    Or (Subtract (And (PMD0, 0x07), 0x02), 0x20, DMD0)
                }

                Return (PIB0)
            }
        }

        Device (P_D1)
        {
            Name (_ADR, 0x01)
            Method (_GTF, 0, NotSerialized)
            {
                Name (PIB1, Buffer (0x0E)
                {
                    0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03,
                    0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF
                })
                CreateByteField (PIB1, 0x01, PMD1)
                CreateByteField (PIB1, 0x08, DMD1)
                If (And (PRIT, 0x20))
                {
                    If (LEqual (And (PRIT, 0x90), 0x80))
                    {
                        Store (0x08, PMD1)
                    }
                    Else
                    {
                        Add (And (PSIT, 0x03), ShiftRight (And (PSIT,
0x0C), 0x02), Local0)
                        If (LEqual (0x05, Local0))
                        {
                            Store (0x0C, PMD1)
                        }
                        Else
                        {
                            If (LEqual (0x03, Local0))
                            {
                                Store (0x0B, PMD1)
                            }
                            Else
                            {
                                Store (0x0A, PMD1)
                            }
                        }
                    }
                }
                Else
                {
                    Store (0x01, PMD1)
                }

                If (And (SYNC, 0x02))
                {
                    Store (Or (SDT1, 0x40), DMD1)
                    If (And (ICR1, 0x02))
                    {
                        If (And (ICR0, 0x02))
                        {
                            Add (DMD1, 0x02, DMD1)
                        }

                        If (And (ICR3, 0x02))
                        {
                            Store (0x45, DMD1)
                        }
                    }
                }
                Else
                {
                    Or (Subtract (And (PMD1, 0x07), 0x02), 0x20, DMD1)
                }

                Return (PIB1)
            }
        }
    }
}

Device (SATA)
{
    Name (_ADR, 0x001F0002)
    OperationRegion (SACS, PCI_Config, 0x40, 0xC0)
    Field (SACS, DWordAcc, NoLock, Preserve)
    {
        PRIT,   16,
        SECT,   16,
        PSIT,   4,
        SSIT,   4,
        Offset (0x08),
        SYNC,   4,
        Offset (0x0A),
        SDT0,   2,
            ,   2,
        SDT1,   2,
        Offset (0x0B),
        SDT2,   2,
            ,   2,
        SDT3,   2,
        Offset (0x14),
        ICR0,   4,
        ICR1,   4,
        ICR2,   4,
        ICR3,   4,
        ICR4,   4,
        ICR5,   4,
        Offset (0x50),
        MAPV,   2,
            ,   5,
        USCC,   1,
        Offset (0x52),
        PCSR,   8
    }
}

-- 
Mathieu
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3/6] 2.6.21-rc2: known regressions

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 97 bytes --]

Can you apply the attached patch and report what the kernel says with
ACPI turned on?

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 565 bytes --]

diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 019d8ff..6a27a7f 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -473,8 +473,8 @@ static void taskfile_load_raw(struct ata_port *ap,
 	struct ata_taskfile tf;
 	unsigned int err;
 
-	if (ata_msg_probe(ap))
-		ata_dev_printk(atadev, KERN_DEBUG, "%s: (0x1f1-1f7): hex: "
+	if (1 || ata_msg_probe(ap))
+		ata_dev_printk(atadev, KERN_INFO, "%s: (0x1f1-1f7): hex: "
 			"%02x %02x %02x %02x %02x %02x %02x\n",
 			__FUNCTION__,
 			gtf->tfa[0], gtf->tfa[1], gtf->tfa[2],

Re: [3/6] 2.6.21-rc2: known regressions

[Mathieu Bérard]

Tejun Heo a écrit :
> Can you apply the attached patch and report what the kernel says with
> ACPI turned on?
>
>   
Hi,
I got this:
[   13.523816] SCSI subsystem initialized
[   13.528914] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level,
low) -> IRQ 19
[   14.529383] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5
Gbps 0x5 impl IDE mode
[   14.529439] ahci 0000:00:1f.2: flags: 64bit ncq pm led slum part
[   14.529565] ata1: SATA max UDMA/133 cmd 0xf8824d00 ctl 0x00000000
bmdma 0x00000000 irq 19
[   14.529683] ata2: SATA max UDMA/133 cmd 0xf8824d80 ctl 0x00000000
bmdma 0x00000000 irq 19
[   14.529801] ata3: SATA max UDMA/133 cmd 0xf8824e00 ctl 0x00000000
bmdma 0x00000000 irq 19
[   14.529921] ata4: SATA max UDMA/133 cmd 0xf8824e80 ctl 0x00000000
bmdma 0x00000000 irq 19
[   14.529984] scsi0 : ahci
[   14.987273] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   15.031823] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
00 a0 ef
[   15.032119] ata1.00: ATA-7: HTS541010G9SA00, MBZOC60D, max UDMA/100
[   15.032168] ata1.00: 195371568 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   15.034170] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
00 a0 ef
[   15.034464] ata1.00: configured for UDMA/100
[   15.034515] scsi1 : ahci
[   15.337188] ata2: SATA link down (SStatus 0 SControl 0)
[   15.337241] scsi2 : ahci
[   15.640125] ata3: SATA link down (SStatus 0 SControl 300)
[   15.640178] scsi3 : ahci
[   15.943062] ata4: SATA link down (SStatus 0 SControl 0)
[   15.943191] scsi 0:0:0:0: Direct-Access     ATA      HTS541010G9SA00 
MBZO PQ: 0 ANSI: 5

and for each ata errors:
[   47.089624] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
frozen
[   47.089682] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0
cdb 0x0 data 4096 in
[   47.089684]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[   47.392549] ata1: soft resetting port
[   47.547533] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   47.549756] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
00 a0 ef
[   47.552600] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
00 a0 ef
[   47.552969] ata1.00: configured for UDMA/100
[   47.553022] ata1: EH complete
[   47.553104] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[   47.553160] sda: Write Protect is off
[   47.553226] SCSI device sda: write cache: enabled, read cache:
enabled, doesn't support DPO or FUA

-- 
Mathieu

Re: [3/6] 2.6.21-rc2: known regressions

[Tejun Heo]

Hello,

Mathieu Bérard wrote:
> [   15.031823] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
> 00 a0 ef

Okay, this is interesting.  This is Enable Device-Initiated Interface
Power State Transitions.  So, after this command is executed the device
will try to transit to partial/slumber SATA PHY power states at its
discretion, which is all cool and dandy in theory but depending on
controller and drive firmware can cause all sorts of problems.

The NCQ problem you're seeing probably is some side effect of device
initiated link PS.  Can't tell whether the controller or the drive's
firmware is problem without further info.  Due to blacklisting, NCQ
won't be turned on your drive in future kernels and link PS doesn't seem
to cause any problem no non-NCQ, so your case is taken care of here but
this leaves me a bit worried about what _GTF feeds us.

I don't think we can reliably filter out command TFs as it might even
contain vendor-specific commands but it might be better to always log
TFs executed for _GTF such that we at least know what's going on with
the drive.

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2/6] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Pavel Machek <pavel@ucw.cz> wrote:

> > Some day we may have modesetting support in the kernel for some 
> > graphics hw, right now it's pretty damn spotty.
> 
> Yep, that's the way to go.

hey, i wildly supported this approach ever since 1996, when GGI came up
:-/

	Ingo

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

[Jim Gettys]

On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote:
> * Pavel Machek <pavel@ucw.cz> wrote:
> 
> > > Some day we may have modesetting support in the kernel for some 
> > > graphics hw, right now it's pretty damn spotty.
> > 
> > Yep, that's the way to go.
> 
> hey, i wildly supported this approach ever since 1996, when GGI came up
> :-/
> 

So wildly you wrote tons of code.... ;-).

More seriously, at the time, XFree86 would have spat in your face for
any such thing.  Thankfully, times are changing.

Also more seriously, a somewhat hybrid approach is in order for mode
setting: simple mode setting isn't much code and is required for sane
behavior on crash (it is nice to get oopses onto a screen); but the full
blown mode setting/configuration problem is so large that on some
hardware, it is likely left best left to a helper process (not the X
server).

Also key to get sane behavior out of the scheduler is to get the X
server to yield (sleep in the kernel) rather than busy waiting when the
GPU is busy; a standardized interface for this for both fbdev and dri is
in order.  Right now, X is a misbehaving compute bound process rather
than the properly interactive process it can/should/will be, releasing
the CPU whenever the hardware is busy. Needless to say, this wastes
cycles and hurts interactivity with just about any scheduler you can
devise. It isn't as if this is hard; on UNIX systems we did it in 1984
or thereabouts.

Of course, in 1996, XFree86 would have ignored any such interfaces, in
its insane quest for operating system independent user space drivers
requiring no standard kernel interfaces.... (it is the second part of
this where the true insanity lay).
                                  - Jim

-- 
Jim Gettys
One Laptop Per Child

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

[Bill Davidsen]

Jim Gettys wrote:
> On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote:
>> * Pavel Machek <pavel@ucw.cz> wrote:
>>
>>>> Some day we may have modesetting support in the kernel for some 
>>>> graphics hw, right now it's pretty damn spotty.
>>> Yep, that's the way to go.
>> hey, i wildly supported this approach ever since 1996, when GGI came up
>> :-/
>>
> 
> So wildly you wrote tons of code.... ;-).
> 
> More seriously, at the time, XFree86 would have spat in your face for
> any such thing.  Thankfully, times are changing.
> 
> Also more seriously, a somewhat hybrid approach is in order for mode
> setting: simple mode setting isn't much code and is required for sane
> behavior on crash (it is nice to get oopses onto a screen); but the full
> blown mode setting/configuration problem is so large that on some
> hardware, it is likely left best left to a helper process (not the X
> server).
> 
> Also key to get sane behavior out of the scheduler is to get the X
> server to yield (sleep in the kernel) rather than busy waiting when the
> GPU is busy; a standardized interface for this for both fbdev and dri is
> in order.  Right now, X is a misbehaving compute bound process rather
> than the properly interactive process it can/should/will be, releasing
> the CPU whenever the hardware is busy. Needless to say, this wastes
> cycles and hurts interactivity with just about any scheduler you can
> devise. It isn't as if this is hard; on UNIX systems we did it in 1984
> or thereabouts.

What you say sounds good, assuming that the cost of a sleep is less than 
the cost of the busy wait. But this may be hardware, the waits may be 
very small and frequent, and if it's hitting a small hardware window 
like retrace, delays in response will cause the time period to be missed 
completely. This probably less critical with very smart cards, many of 
us don't run them.
> 
> Of course, in 1996, XFree86 would have ignored any such interfaces, in
> its insane quest for operating system independent user space drivers
> requiring no standard kernel interfaces.... (it is the second part of
> this where the true insanity lay).
>                                   - Jim
> 


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

[Jim Gettys]

On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote:

> 
> What you say sounds good, assuming that the cost of a sleep is less than 
> the cost of the busy wait. But this may be hardware, the waits may be 
> very small and frequent, and if it's hitting a small hardware window 
> like retrace, delays in response will cause the time period to be missed 
> completely. This probably less critical with very smart cards, many of 
> us don't run them.
> > 

Actually, various strategies involving short busy waiting, or looking at
DMA address registers before sleeping were commonplace.  But a
syscall/sleep/wakeup is/was pretty fast.  If you have an operation
blitting the screen (e.g. scrolling), it takes a bit of time for the GPU
to execute the command.  I see this right now on OLPC, where a wonderful
music application needs to scroll (most of) the screen left),
periodically, and we're losing samples sometimes at those operation.

Remember also, that being nice to everyone else by sleeping, there are
more cycles to go around, and the scheduler can nicely boost the X
server's priority as it will for "interactive" processes that are being
cooperative.
                                - Jim

-- 
Jim Gettys
One Laptop Per Child

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

[Bill Davidsen]

Jim Gettys wrote:
> On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote:
>
>   
>> What you say sounds good, assuming that the cost of a sleep is less than 
>> the cost of the busy wait. But this may be hardware, the waits may be 
>> very small and frequent, and if it's hitting a small hardware window 
>> like retrace, delays in response will cause the time period to be missed 
>> completely. This probably less critical with very smart cards, many of 
>> us don't run them.
>>     
>
> Actually, various strategies involving short busy waiting, or looking at
> DMA address registers before sleeping were commonplace.  But a
> syscall/sleep/wakeup is/was pretty fast.  If you have an operation
> blitting the screen (e.g. scrolling), it takes a bit of time for the GPU
> to execute the command.  I see this right now on OLPC, where a wonderful
> music application needs to scroll (most of) the screen left),
> periodically, and we're losing samples sometimes at those operation.
>   
None of that conflicts with what I said, but what works on an LCD may 
not be appropriate for a CRT. With even moderate 1024x768@70 timing the 
horizontal retrace happens ~50k/sec, and that's not an appropriate 
syscall rate. I'm just pointing out that some things a video interface 
does with simple hardware involve lots of very small windows. Don't read 
that as "don't do it," just "be careful HOW you do it."
> Remember also, that being nice to everyone else by sleeping, there are
> more cycles to go around, and the scheduler can nicely boost the X
> server's priority as it will for "interactive" processes that are being
> cooperative.
I'm going to cautiously guess that the problem might be not "how much" 
but "how soon." That is, latency might be more important than giving the 
server a lot of CPU.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979