Re: 2.6.21-mm2: ACPI exception on resume
Hi! > > >> I shouldn't have to upgrade my BIOS to work with a new kernel any more > > >> than I should have to upgrade my browser. > > > > > >We don't agree there, as you are not talking about a stable kernel series. > > > > Ah, so you're planning on submitting these patches for 2.7 then? 2.6 > > is perpetually stable. Matt is quite correct; feel free to ask for > > clarifications from Linus et al if you need guidance. > > 2.6.x.y is stable. 2.6.x is not by any reasonably strict definition of Wrong. 2.6.x is stable as in 'must not break userspace, must not regress'. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On 5/23/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: On Wed, 23 May 2007, Ray Lee wrote: > Which is the crux of my problem with your statement. I feel we > shouldn't give the wrong idea to those authors. They need to know that > the expectation is that 2.6.x is a stable series, and 2.6.x.y is for > dealing with unavoidable mistakes. Well, the only case where I feel a regression is justified is one where it is caused by a bug in the firmware or the hardware. Here's the problem. Each of the people testing the kernel is a 'canary in the coalmine.' If one person is having trouble, then it's likely that there are ten more that will have the same issue. The real problem here is that those other ten people aren't going to know how to fix it, other than "it used to work, so obviously the kernel is now doing something wrong." This is particularly bad for firmware, where upgrading it may introduce new regressions. I understand that there are broken firmwares out there -- I have a laptop with one. But there needs to be a way to support broken systems and the sane ones simultaneously. This is a requirement for the ACPI tree, for example, and it seems to work. All of this is assuming that the firmware really was at fault. It's also possible that it's just doing something different than before, and both behaviors are valid and should be dealt with gracefully. At which point my personal opinion is that users of firmware/hardware *that have a fix available* are to be told to apply the fix, unless the problem is so serious that it could potentially cause extreme damage (loss of human life, permanent hardware damage, major data loss). Those are extreme. My point is that if you know who all those people are, and are willing to contact them, then sure, that's viable. Otherwise, the bottom line is that the kernel used to deal with a problem gracefully, and now it doesn't. There's no telling how many other people will get bit by the same problem, and most of those people aren't going to know what to do about it, other than to downgrade the kernel, and wait for it to magically get fixed by someone else. If there is no fix the user can apply, then it really depends on how damaging it is to work around the issue for others: you don't punish those who have non-broken stuff to avoid problems for those that have broken stuff. I understand your point of view, but another way to look at it is that we always want to make forward progress on the code. If we don't, then we're never going to have a good metric (measure) of how we're doing. Fortunately, most of the time one can come up with a fix that causes little to no loss to those with non-broken hardware/firmware. And I'm sure those with the Big Brains(tm) can do so again. Thanks, Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Wed, 23 May 2007, Ray Lee wrote: > The problem is when the maintainers/submitters get the wrong > impression, that 2.6.x.y is there to clean up the mess they made. The Now, that I agree with completely. > Which is the crux of my problem with your statement. I feel we > shouldn't give the wrong idea to those authors. They need to know that > the expectation is that 2.6.x is a stable series, and 2.6.x.y is for > dealing with unavoidable mistakes. Well, the only case where I feel a regression is justified is one where it is caused by a bug in the firmware or the hardware. At which point my personal opinion is that users of firmware/hardware *that have a fix available* are to be told to apply the fix, unless the problem is so serious that it could potentially cause extreme damage (loss of human life, permanent hardware damage, major data loss). If there is no fix the user can apply, then it really depends on how damaging it is to work around the issue for others: you don't punish those who have non-broken stuff to avoid problems for those that have broken stuff. Fortunately, most of the time one can come up with a fix that causes little to no loss to those with non-broken hardware/firmware. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On 5/23/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: On Tue, 22 May 2007, Ray Lee wrote: > On 5/22/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > >We don't agree there, as you are not talking about a stable kernel series. > > Ah, so you're planning on submitting these patches for 2.7 then? 2.6 > is perpetually stable. Matt is quite correct; feel free to ask for > clarifications from Linus et al if you need guidance. 2.6.x.y is stable. 2.6.x is not by any reasonably strict definition of stable. Unless you can explain how the stuff that went in 2.6.21 could be added to a stable series kernel, do not even bother replying. I owe you an apology, I was a bit snippy there. However, to answer your question, they got in by accident and lax testing on the part of the submitters. As someone who has written and maintains a lot of deployed software that gets upgraded live, I feel comfortable in saying that maintaining a perpetually stable software series while allowing new features is entirely possible. The problem is when the maintainers/submitters get the wrong impression, that 2.6.x.y is there to clean up the mess they made. The best of all worlds, in terms of everybody's time spent debugging and fixing, is if the patches are well-tested before submission. If the submitters feel that 2.6.x is an unstable series, then they have no reason to heavily test that code before it goes in. Which is the crux of my problem with your statement. I feel we shouldn't give the wrong idea to those authors. They need to know that the expectation is that 2.6.x is a stable series, and 2.6.x.y is for dealing with unavoidable mistakes. And for the record, the patches are NOT mine, but since I am the one usually dealing directly with thinkpad firmware, I jumped in to help debug things as a thinkpad firmware was *probably* to blame. Again, my apologies; I was out of line. Thanks for helping. Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Wed, May 23, 2007 at 10:56:27PM +0200, Rafael J. Wysocki wrote: > On Wednesday, 23 May 2007 19:48, Matt Mackall wrote: > > On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote: > > > On Wed, 23 May 2007, Rafael J. Wysocki wrote: > > > > While I agree with that, it would really be helpful if you tested the > > > > latest -rc > > > > kernel and saw if the bug was present in there. > > > > > > > > If the bug is not present in the latest -rc, it'll be possible to > > > > identify the > > > > patch that causes it to appear in -mm and find the reason of the > > > > breakage. > > > > > > And, once we know the reason, we will be able to find out how to best fix > > > the > > > problem. > > > > > > So, do please test latest -rc, or bissect to the last known-good kernel. > > > As > > > I said, we need further data points to do anything. > > > > This isn't conclusive as this bug is fairly hard to trigger, but it > > looks like the culprit may have been this patch and not anything in > > -mm or mainline. So the below patch doesn't help the problem it was > > intended for (lid switch no longer wakes up S2R after a S2D cycle) and > > appears to be implicated in making my EC unhappy. > > Yes, this was just a debug patch. > > We broke quite a few systems by placing platform_finish() before > device_resume() and I suspected your system could be one of them. > > Apparently, that's not the case. > > In 2.6.22-rc2 we also moved platform_prepare() to after device_suspend() > and that's why I asked you to test this kernel. Will get to it eventually. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Wednesday, 23 May 2007 19:48, Matt Mackall wrote: > On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote: > > On Wed, 23 May 2007, Rafael J. Wysocki wrote: > > > While I agree with that, it would really be helpful if you tested the > > > latest -rc > > > kernel and saw if the bug was present in there. > > > > > > If the bug is not present in the latest -rc, it'll be possible to > > > identify the > > > patch that causes it to appear in -mm and find the reason of the breakage. > > > > And, once we know the reason, we will be able to find out how to best fix > > the > > problem. > > > > So, do please test latest -rc, or bissect to the last known-good kernel. As > > I said, we need further data points to do anything. > > This isn't conclusive as this bug is fairly hard to trigger, but it > looks like the culprit may have been this patch and not anything in > -mm or mainline. So the below patch doesn't help the problem it was > intended for (lid switch no longer wakes up S2R after a S2D cycle) and > appears to be implicated in making my EC unhappy. Yes, this was just a debug patch. We broke quite a few systems by placing platform_finish() before device_resume() and I suspected your system could be one of them. Apparently, that's not the case. In 2.6.22-rc2 we also moved platform_prepare() to after device_suspend() and that's why I asked you to test this kernel. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 23 May 2007, Rafael J. Wysocki wrote:
> > While I agree with that, it would really be helpful if you tested the
> > latest -rc
> > kernel and saw if the bug was present in there.
> >
> > If the bug is not present in the latest -rc, it'll be possible to identify
> > the
> > patch that causes it to appear in -mm and find the reason of the breakage.
>
> And, once we know the reason, we will be able to find out how to best fix the
> problem.
>
> So, do please test latest -rc, or bissect to the last known-good kernel. As
> I said, we need further data points to do anything.
This isn't conclusive as this bug is fairly hard to trigger, but it
looks like the culprit may have been this patch and not anything in
-mm or mainline. So the below patch doesn't help the problem it was
intended for (lid switch no longer wakes up S2R after a S2D cycle) and
appears to be implicated in making my EC unhappy.
-
Can you please check if the appended debug patch helps?
Rafael
---
kernel/power/disk.c |4 ++--
kernel/power/user.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.21-rc7/kernel/power/disk.c
===
--- linux-2.6.21-rc7.orig/kernel/power/disk.c
+++ linux-2.6.21-rc7/kernel/power/disk.c
@@ -170,9 +170,9 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
resume_console();
+ platform_finish();
pr_debug("PM: writing image.\n");
error = swsusp_write();
if (!error)
@@ -189,9 +189,9 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
resume_console();
+ platform_finish();
Thaw:
unprepare_processes();
Finish:
Index: linux-2.6.21-rc7/kernel/power/user.c
===
--- linux-2.6.21-rc7.orig/kernel/power/user.c
+++ linux-2.6.21-rc7/kernel/power/user.c
@@ -170,11 +170,11 @@ static inline int snapshot_suspend(int p
}
enable_nonboot_cpus();
Resume_devices:
+ device_resume();
+ resume_console();
if (platform_suspend)
platform_finish();
- device_resume();
- resume_console();
Finish:
mutex_unlock(&pm_mutex);
return error;
@@ -202,11 +202,11 @@ static inline int snapshot_restore(int p
enable_nonboot_cpus();
Resume_devices:
+ device_resume();
+ resume_console();
if (platform_suspend)
platform_finish();
- device_resume();
- resume_console();
Finish:
pm_restore_console();
mutex_unlock(&pm_mutex);
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Wed, 23 May 2007, Rafael J. Wysocki wrote: > While I agree with that, it would really be helpful if you tested the latest > -rc > kernel and saw if the bug was present in there. > > If the bug is not present in the latest -rc, it'll be possible to identify the > patch that causes it to appear in -mm and find the reason of the breakage. And, once we know the reason, we will be able to find out how to best fix the problem. So, do please test latest -rc, or bissect to the last known-good kernel. As I said, we need further data points to do anything. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Tue, 22 May 2007, Ray Lee wrote: > On 5/22/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > >> I shouldn't have to upgrade my BIOS to work with a new kernel any more > >> than I should have to upgrade my browser. > > > >We don't agree there, as you are not talking about a stable kernel series. > > Ah, so you're planning on submitting these patches for 2.7 then? 2.6 > is perpetually stable. Matt is quite correct; feel free to ask for > clarifications from Linus et al if you need guidance. 2.6.x.y is stable. 2.6.x is not by any reasonably strict definition of stable. Unless you can explain how the stuff that went in 2.6.21 could be added to a stable series kernel, do not even bother replying. And for the record, the patches are NOT mine, but since I am the one usually dealing directly with thinkpad firmware, I jumped in to help debug things as a thinkpad firmware was *probably* to blame. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Wednesday, 23 May 2007 03:48, Matt Mackall wrote: > On Tue, May 22, 2007 at 09:19:43PM -0300, Henrique de Moraes Holschuh wrote: > > On Tue, 22 May 2007, Matt Mackall wrote: > > > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh > > > wrote: > > > > On Mon, 21 May 2007, Matt Mackall wrote: > > > > > BIOS Information > > > > > Vendor: IBM > > > > > Version: 1RETDHWW (3.13 ) > > > > > Release Date: 10/29/2004 > > > > > > > > > > No sign of any EC version in the output. > > > > > > > > This is a buggy, ancient version of the BIOS, which probably means you > > > > have > > > > an old and slightly buggy EC firmware. I recommend you to upgrade to > > > > BIOS > > > > 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more > > > > details. > > > > > > Really, I'd much prefer my kernel not regress instead. Updating > > > firmware is just introducing more potential instability and ignoring > > > the problem. > > > > We can't very much know if the kernel is really buggy, then. > > Whether the 'bug' is in the firmware or the kernel, it is the kernel > that has regressed. Suspend worked fine for 2+ years before this. > > Breaking working systems, either software or hardware, is a bad idea. > I shouldn't have to upgrade my BIOS to work with a new kernel any more > than I should have to upgrade my browser. While I agree with that, it would really be helpful if you tested the latest -rc kernel and saw if the bug was present in there. If the bug is not present in the latest -rc, it'll be possible to identify the patch that causes it to appear in -mm and find the reason of the breakage. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On 5/22/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > I shouldn't have to upgrade my BIOS to work with a new kernel any more > than I should have to upgrade my browser. We don't agree there, as you are not talking about a stable kernel series. Ah, so you're planning on submitting these patches for 2.7 then? 2.6 is perpetually stable. Matt is quite correct; feel free to ask for clarifications from Linus et al if you need guidance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Tue, 22 May 2007, Matt Mackall wrote: > Whether the 'bug' is in the firmware or the kernel, it is the kernel > that has regressed. Suspend worked fine for 2+ years before this. That means something, but not that much. The kernel could have been doing broken things for two years in ACPI that happened to not trigger a bug in someone's firmware, for example. And when the kernel was fixed (to, e.g., do it right by the spec or unbreak other firmwares that did it by the spec) and that triggered the bug. We really need to find the cause of the regression to know. > Breaking working systems, either software or hardware, is a bad idea. We shouldn't do it for frivoulous reasons, of course. > I shouldn't have to upgrade my BIOS to work with a new kernel any more > than I should have to upgrade my browser. We don't agree there, as you are not talking about a stable kernel series. And btw, unless you hunt down someone that also has the bug and uses an up-to-date BIOS (or something else to give an extra data point that discards a possible firmware bug in your version of the BIOS), or bissect to pinpoint what caused the regression, this thread will go nowhere. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Tue, May 22, 2007 at 09:19:43PM -0300, Henrique de Moraes Holschuh wrote: > On Tue, 22 May 2007, Matt Mackall wrote: > > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote: > > > On Mon, 21 May 2007, Matt Mackall wrote: > > > > BIOS Information > > > > Vendor: IBM > > > > Version: 1RETDHWW (3.13 ) > > > > Release Date: 10/29/2004 > > > > > > > > No sign of any EC version in the output. > > > > > > This is a buggy, ancient version of the BIOS, which probably means you > > > have > > > an old and slightly buggy EC firmware. I recommend you to upgrade to BIOS > > > 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more > > > details. > > > > Really, I'd much prefer my kernel not regress instead. Updating > > firmware is just introducing more potential instability and ignoring > > the problem. > > We can't very much know if the kernel is really buggy, then. Whether the 'bug' is in the firmware or the kernel, it is the kernel that has regressed. Suspend worked fine for 2+ years before this. Breaking working systems, either software or hardware, is a bad idea. I shouldn't have to upgrade my BIOS to work with a new kernel any more than I should have to upgrade my browser. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Tue, 22 May 2007, Matt Mackall wrote: > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 21 May 2007, Matt Mackall wrote: > > > BIOS Information > > > Vendor: IBM > > > Version: 1RETDHWW (3.13 ) > > > Release Date: 10/29/2004 > > > > > > No sign of any EC version in the output. > > > > This is a buggy, ancient version of the BIOS, which probably means you have > > an old and slightly buggy EC firmware. I recommend you to upgrade to BIOS > > 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more > > details. > > Really, I'd much prefer my kernel not regress instead. Updating > firmware is just introducing more potential instability and ignoring > the problem. We can't very much know if the kernel is really buggy, then. I'd say we need a report from someone with another thinkpad that uses the 1R BIOS that has an up-to-date BIOS, to know for sure. Since that includes the T41 and T42, chances are others would have spoken up about it already if it affected the more recent versions of the 1R BIOS. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 21 May 2007, Matt Mackall wrote: > > BIOS Information > > Vendor: IBM > > Version: 1RETDHWW (3.13 ) > > Release Date: 10/29/2004 > > > > No sign of any EC version in the output. > > This is a buggy, ancient version of the BIOS, which probably means you have > an old and slightly buggy EC firmware. I recommend you to upgrade to BIOS > 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more > details. Really, I'd much prefer my kernel not regress instead. Updating firmware is just introducing more potential instability and ignoring the problem. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Mon, 21 May 2007, Matt Mackall wrote: > BIOS Information > Vendor: IBM > Version: 1RETDHWW (3.13 ) > Release Date: 10/29/2004 > > No sign of any EC version in the output. This is a buggy, ancient version of the BIOS, which probably means you have an old and slightly buggy EC firmware. I recommend you to upgrade to BIOS 3.21 and EC 3.04. See http://thinkwiki.org/wiki/BIOS_Upgrade for more details. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Sun, May 20, 2007 at 12:52:59AM -0300, Henrique de Moraes Holschuh wrote: > > > On Sat, 19 May 2007, Matt Mackall wrote: > > > > usually does, then go black and the machine will become totally > > > > unresponsive, even to holding down the power button for 30+ seconds. > > > > > > Now, that means either the BIOS or EC have been thrown out of whack, > > > otherwise one of the two would have force-powered-off the machine a bit > > > after 10s. > > > > > > Are you using the latest BIOS and EC firmware available? > > > > No, I've been running the same BIOS without issue for two years. > > Version of BIOS and EC firmware, please? It is in the dmidecode output. BIOS Information Vendor: IBM Version: 1RETDHWW (3.13 ) Release Date: 10/29/2004 No sign of any EC version in the output. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Sat, 19 May 2007, Matt Mackall wrote: > On Sat, May 19, 2007 at 05:45:04PM -0300, Henrique de Moraes Holschuh wrote: > > On Sat, 19 May 2007, Matt Mackall wrote: > > > usually does, then go black and the machine will become totally > > > unresponsive, even to holding down the power button for 30+ seconds. > > > > Now, that means either the BIOS or EC have been thrown out of whack, > > otherwise one of the two would have force-powered-off the machine a bit > > after 10s. > > > > Are you using the latest BIOS and EC firmware available? > > No, I've been running the same BIOS without issue for two years. Version of BIOS and EC firmware, please? It is in the dmidecode output. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Sunday, 20 May 2007 00:40, Matt Mackall wrote: > On Sat, May 19, 2007 at 08:24:16PM +0200, Rafael J. Wysocki wrote: > > Hi, > > > > On Saturday, 19 May 2007 18:57, Matt Mackall wrote: > > > Starting with 2.6.21-mm2, I'm seeing occassional failures to resume > > > from suspend-to-ram on my Thinkpad R51. The screen will flash as it > > > usually does, then go black and the machine will become totally > > > unresponsive, even to holding down the power button for 30+ seconds. > > > But the hard drive light will occassionally flash, so the machine is > > > clearly not completely dead at this point. > > > > Does the mainline (as of 2.6.22-rc2) do this? > > Dunno. I've triggered it twice since -mm2 was released, never before > that point. -mm1 was fine. Can you please test 2.6.22-rc2? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Sat, May 19, 2007 at 08:24:16PM +0200, Rafael J. Wysocki wrote: > Hi, > > On Saturday, 19 May 2007 18:57, Matt Mackall wrote: > > Starting with 2.6.21-mm2, I'm seeing occassional failures to resume > > from suspend-to-ram on my Thinkpad R51. The screen will flash as it > > usually does, then go black and the machine will become totally > > unresponsive, even to holding down the power button for 30+ seconds. > > But the hard drive light will occassionally flash, so the machine is > > clearly not completely dead at this point. > > Does the mainline (as of 2.6.22-rc2) do this? Dunno. I've triggered it twice since -mm2 was released, never before that point. -mm1 was fine. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Sat, May 19, 2007 at 05:45:04PM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 19 May 2007, Matt Mackall wrote: > > usually does, then go black and the machine will become totally > > unresponsive, even to holding down the power button for 30+ seconds. > > Now, that means either the BIOS or EC have been thrown out of whack, > otherwise one of the two would have force-powered-off the machine a bit > after 10s. > > Are you using the latest BIOS and EC firmware available? No, I've been running the same BIOS without issue for two years. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
On Sat, 19 May 2007, Matt Mackall wrote: > usually does, then go black and the machine will become totally > unresponsive, even to holding down the power button for 30+ seconds. Now, that means either the BIOS or EC have been thrown out of whack, otherwise one of the two would have force-powered-off the machine a bit after 10s. Are you using the latest BIOS and EC firmware available? If you are at the latest BIOS and EC releases, does ec_intr=0 fix the issue? > 08:57:27 [drm] Loading R200 Microcode > 08:57:27 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2 > 08:57:27 ACPI: EC: input buffer is not empty, aborting transaction > 08:57:28 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2 Yep, EC is confused. Not Good! -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: ACPI exception on resume
Hi, On Saturday, 19 May 2007 18:57, Matt Mackall wrote: > Starting with 2.6.21-mm2, I'm seeing occassional failures to resume > from suspend-to-ram on my Thinkpad R51. The screen will flash as it > usually does, then go black and the machine will become totally > unresponsive, even to holding down the power button for 30+ seconds. > But the hard drive light will occassionally flash, so the machine is > clearly not completely dead at this point. Does the mainline (as of 2.6.22-rc2) do this? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
