The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
I would like to start testing suspend/resume in Rawhide but I have to confess that I am at the very beginning. I've discerned from googling that it is still pretty much a script based feature, i.e. one must write scripts to have your laptop suspend or hibernate and then associate those scripts with events. This is somewhat shocking to me. I expected that a distro would automagically configure a system to DTRT from the getgo. At least do something like what XP does. Au contraire apparently. Is there any reference material available to read so that I might be a little more intelligent and helpful in testing suspend/resume functionality?
And to address Paul's question, FWIW: it doesn't much matter to me when good laptop support is in FC, just that it gets in and stays in. It certainly does appear to be long overdue functionality.
Thanks,
-pmr
On Fri, Sep 22, 2006 at 01:12:14PM -0500, Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates" "corrupts data"
Dave
On Friday 22 September 2006 22:30, Dave Jones wrote:
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates" "corrupts data"
That is fair. I am curious though, I have the same experience here, several of our laptops stopped suspending/hibernating properly after 2.6.16. Just for curiosity, what changed in this area and what needs to be done to fix it?
Regards,
Dave
José Matos wrote:
That is fair. I am curious though, I have the same experience here, several of our laptops stopped suspending/hibernating properly after 2.6.16. Just for curiosity, what changed in this area and what needs to be done to fix it?
This is frustrating for me too. My take on it is that modern distros (SLED, Fedora, Ubuntu) are, in desktop terms, ready for prime time, either matching or exceeding features offered by other O/Ses.
What's needed now is polish on the rough edges and hibernate/suspend is definitely one of those rough edges. I know that this is a tricky issue as the kernel architecture doesn't easily lend itself to hibernating and there's variation in manufacturers' implementation of standards. But it's 2006, users will expect this...
On Sat, Sep 23, 2006 at 09:16:58AM +0100, José Matos wrote:
On Friday 22 September 2006 22:30, Dave Jones wrote:
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates" "corrupts data"
That is fair. I am curious though, I have the same experience here, several of our laptops stopped suspending/hibernating properly after 2.6.16. Just for curiosity, what changed in this area and what needs to be done to fix it?
Not entirely sure, though there has been some positive feedback that 2.6.18 fixes the issues a lot of people saw in 2.6.17. There still remain some that are not working though :-/
Dave
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates" "corrupts data"
That is fair. I am curious though, I have the same experience here, several of our laptops stopped suspending/hibernating properly after 2.6.16. Just for curiosity, what changed in this area and what needs to be done to fix it?
Not entirely sure, though there has been some positive feedback that 2.6.18 fixes the issues a lot of people saw in 2.6.17. There still remain some that are not working though :-/
2.6.18 fixed the suspend that wasn't working for me (yonah based Dell D620 laptop) but the problem with the resume seems to be in the disk controller or drive. I get errors spewed up the console (which I'm going to need to write down) regarding the sata disk on the ICH7 southbridge. When I try to dump the dmesg log out to disk it comes back with it being write protected (or something to that effect - can't see it eaily with all the errors) if it wasn't for that I think the resume would work as X comes back (but don't get a full details).
Peter
Dave Jones davej@redhat.com wrote:
On Fri, Sep 22, 2006 at 01:12:14PM -0500, Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates"
Got that one right... see the thread about yum seeing no updates ;-)
"corrupts data"
Could we add "X starts, but only shows a blank screen; no keyboard or mouse response"? (Happened to me yesterday after the updates from the day before, haven't had time to corroborate)
On Sun, Sep 24, 2006 at 03:57:26PM -0400, Horst H. von Brand wrote:
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates"
Got that one right... see the thread about yum seeing no updates ;-)
"corrupts data"
Could we add "X starts, but only shows a blank screen; no keyboard or mouse response"? (Happened to me yesterday after the updates from the day before, haven't had time to corroborate)
Most of the time this is nothing to do with the kernel. But given by default the installer uses X, this comes under 'doesnt install' kinda. sorta. Ok, the user *could* use text mode, and then yum update to a hopefully fixed X, but it's a pain for some less technically inclined users. I'd add this as a "shouldfix" rather than "mustfix" personally.
Dave
Horst H. von Brand wrote:
"corrupts data"
Could we add "X starts, but only shows a blank screen; no keyboard or mouse response"? (Happened to me yesterday after the updates from the day before, haven't had time to corroborate)
That one is almost certainly "no". If there was a steadfast rule that if X failed for any user, it would block a Fedora release, then there would never ever be another Fedora release ever period.
Every release of X will categorically fail not just for one user, but for multitudes of users due to the complexity of the software compared to the number of developers working on it. Any large software project as complicated as X, the kernel, firefox, apache, etc. will always have a multitude of bugs in them by very nature of their size and complexity.
Only bugs involving data loss or widespread catastrophic problems for multitudes of users should "block" a release if the release is ever to go out the door.
This is where the "would be nice if" ideology and the "this is what happens in the real world under $constraints" realities diverge greatly.
On Sun, 24 Sep 2006 15:57:26 -0400, Horst H. von Brand wrote:
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates"
Got that one right... see the thread about yum seeing no updates ;-)
"corrupts data"
Could we add "X starts, but only shows a blank screen; no keyboard or mouse response"? (Happened to me yesterday after the updates from the day before, haven't had time to corroborate)
*sigh* Like "X starts and switches off the monitor", and correspondence in bugzilla is like talking to /dev/null.
Michael Schwendt wrote:
On Sun, 24 Sep 2006 15:57:26 -0400, Horst H. von Brand wrote:
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Not really. If we held up the release for every machine that didn't suspend/resume, we'd never ship anything.
The only real blocker items wrt to the kernel are
"doesn't install" "doesn't boot" "can't download updates"
Got that one right... see the thread about yum seeing no updates ;-)
"corrupts data"
Could we add "X starts, but only shows a blank screen; no keyboard or mouse response"? (Happened to me yesterday after the updates from the day before, haven't had time to corroborate)
*sigh* Like "X starts and switches off the monitor", and correspondence in bugzilla is like talking to /dev/null.
I agree with you that BZ is fairly inactive with responses in a lot of cases. The MGA driver is one where there are three minimum generated. I'm sure the bug reports are overwhelming and the developer cannot reply to all, hopefully the reports are reviewed.
Regarding getting X to work beyond the black screen, running X -configure and letting it generate the file in /root as a backup, reviewing the settings, then replacing xorg.conf allows me to have a working X, except for screen resolution changes. You might have better luck with X -configure than with s-c-display. S-c-display does not work beyond 800x600 resolution for me.
Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Does not appear to be a universal problem. I found that my Thinkpad A31p suspends/resumes just fine when I use Gnome (usually I use Xfce), much to my pleasant surprise.
As long as it is a situation of "some do, some don't", I don't think it is reasonable to hold up a major release like FC6.
-pmr
"Paul" == Paul Reilly pmr@pajato.com writes:
Paul> Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume. There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Paul> Does not appear to be a universal problem. I found that my Paul> Thinkpad A31p suspends/resumes just fine when I use Gnome Paul> (usually I use Xfce), much to my pleasant surprise.
You can use 'gnome-power-manager' just fine in Xfce. (I do). Or you can alternately call 'pm-suspend' or 'pm-hibernate' from a command shell just fine.
Paul> As long as it is a situation of "some do, some don't", I don't Paul> think it is reasonable to hold up a major release like FC6.
yeah. I think with scripts like pm-suspend or hibernate (from the swsusp2 site) many more laptops are working than used to be the case.
Paul> -pmr
kevin
On Fri, 22 Sep 2006 13:12:14 -0500, Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Time flies... The last Fedora kernel that suspend worked for me was created in late March (kernel-2.6.15-1.2064_FC6). This is not a Fedora problem, per se, but a generic kernel problem. I attempted a git bisect of the kernel code, but bisected code resulted in non-compilable kernels before I got very far. 2.6.16 works, 2.6.17 does not.
I have become used to suspend not working so I don't test it very often. I was quite surprised when I tested suspend in late February that it actually worked. I was a bit bummed when it stopped, but I was not too bothered by it (my work pattern avoids it because it didn't work).
I think the problem has to do with the SATA suspend/resume code. My notebook has a SATA controller which is connected to a PATA HD (Dell Inspiron 6000).
With it looking like the SATA suspend/resume will be going into 2.6.19 very soon, hopefully this problem will finally be laid to rest.
-Paul
On Sat, 23 Sep 2006 07:16:31 -0700, Paul Dickson wrote:
On Fri, 22 Sep 2006 13:12:14 -0500, Paul Johnson wrote:
The last kernel on which my Dell D820 latitude would suspend & resume was 2.6.16. For the last two months or so---all of th 2.6.17 versions--have failed. The systems suspend, but don't resume.
There are plenty of reports like this in bugzilla.redhat.com. My opinion is that FC6 should not be released as final until the problem is addressed. What do you think?
Time flies... The last Fedora kernel that suspend worked for me was created in late March (kernel-2.6.15-1.2064_FC6). This is not a Fedora problem, per se, but a generic kernel problem. I attempted a git bisect of the kernel code, but bisected code resulted in non-compilable kernels before I got very far. 2.6.16 works, 2.6.17 does not.
I have become used to suspend not working so I don't test it very often. I was quite surprised when I tested suspend in late February that it actually worked. I was a bit bummed when it stopped, but I was not too bothered by it (my work pattern avoids it because it didn't work).
I think the problem has to do with the SATA suspend/resume code. My notebook has a SATA controller which is connected to a PATA HD (Dell Inspiron 6000).
With it looking like the SATA suspend/resume will be going into 2.6.19 very soon, hopefully this problem will finally be laid to rest.
Have said the above and having a lot of updates applied, including a new 2.6.18 kernel, I decided to test suspend/resume once again.
Guess what. It now works!
I've suspended twice and hibernated once already. This is under 2.6.18-1.2689.fc6.
-Paul
Perhaps what is needed is a database of working and failing machine configurations. It would be great if some corporate sponsor could put a server together. It seems to me that we'd need to know the hardware configuration, BIOS and installed Fedora packages. Then we'd need to know whether suspend and hibernate work. This might give us a clear idea of the sort of hardware that is problematic.
Perhaps what is needed is a database of working and failing machine configurations. It would be great if some corporate sponsor could put a server together. It seems to me that we'd need to know the hardware configuration, BIOS and installed Fedora packages. Then we'd need to know whether suspend and hibernate work. This might give us a clear idea of the sort of hardware that is problematic.
I don't think we need a separate server. The HCL laptop part of the wiki would be a good place to start http://fedoraproject.org/wiki/HCL/Machines/Laptops one of the advantages is that its already there.
Peter
Paul
I think the problem has to do with the SATA suspend/resume code. My notebook has a SATA controller which is connected to a PATA HD (Dell Inspiron 6000).
I have that model. I find that it suspends and resumes really well, so long as the disk password is enabled in the BIOS. I think that ensures that the BIOS initialises the SATA hardware on resume.
-Cam