Bug#500794: uswsusp - s2ram does not follow kernel
Bastian Blank schreef: On Sun, Oct 05, 2008 at 11:39:15PM +0200, Tim Dijkstra wrote: Op Sun, 5 Oct 2008 14:55:30 +0200 schreef Bastian Blank [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 09:54:33AM +0200, Tim Dijkstra wrote: I looked at some numbers. We currently have +/- 400 machines listed, of which +/1 100 need no work around. Which is around 25% of all listed ones. correct It fixes suspend for more machines than it breaks. Without it (or similar functionality that can be provided by pm-utils in combination with various other packages) it will leave 75% of laptop users without a functioning suspend/resume. We already have a lot machines that do not need a quirk whitelisted, so the number of people we are `hurting' is far less than 25%. It hurts 100% of my machines, my workstation, my really old notebook, my current notebook and my test notebook. The notebooks have proper ACPI support for suspending. That is only you -- a minority of users. Let me reiterate. Suspend/resume support in the kernel is broken in the kernel for ~ 75% of machines. The symptoms are a freezing system or a system that comes up without video. Now, we have two options for suspend out of the box: 1) Let machines just try to suspend and risk dataloss 2) Only suspend machines of which we know it will work Of course in case 2) an unsupported machine doesn't mean it will never work for that machine. The person that has such a machine just has to actively figure out what `quirks' it needs, use the CLI and tell upstream so it will be added to the whitelist. Anyway: How do you intend to update the whitelist during the release cycle? Maybe I missed a mail on debian-release regarding this. That is indeed not so easy. Note that uswsusp was also part of etch. Note that nowadays in the most desktop environments suspend is triggered through HAL which has its own whitelist, uswsusp is than merely used as a back-end to execute all the quirks. IIRC, HAL's whitelist uses the same logic as uswusp: only suspend machines of which we know it will come up again. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
On Sun, Oct 05, 2008 at 11:39:15PM +0200, Tim Dijkstra wrote: Op Sun, 5 Oct 2008 14:55:30 +0200 schreef Bastian Blank [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 09:54:33AM +0200, Tim Dijkstra wrote: Do you have a number which amount of machines have problems? The number of machines that didn't came up by itself always used to be much bigger than the number that did. I looked at some numbers. We currently have +/- 400 machines listed, of which +/1 100 need no work around. Which is around 25% of all listed ones. linux-acpi is the responsible list for most of the problems. There is a standard interface for that. What do you mean standard interface? The ACPI video interface. Okay, then I insist that uswsusp is not installed along any Debian provided kernels and will enforce that with a conflict because it breaks suspend for many machines. This is nonsense. No. I did not make it an always installed package. It fixes suspend for more machines than it breaks. Without it (or similar functionality that can be provided by pm-utils in combination with various other packages) it will leave 75% of laptop users without a functioning suspend/resume. We already have a lot machines that do not need a quirk whitelisted, so the number of people we are `hurting' is far less than 25%. It hurts 100% of my machines, my workstation, my really old notebook, my current notebook and my test notebook. The notebooks have proper ACPI support for suspending. Anyway: How do you intend to update the whitelist during the release cycle? Maybe I missed a mail on debian-release regarding this. Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, Errand of Mercy, stardate 3201.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
On Thu, Oct 02, 2008 at 09:54:33AM +0200, Tim Dijkstra wrote: First of all, if you know what command-line arguments you need to suspend you can use those with --force. If you use hal (via gnome-power-manager) you can create a .fdi file that will by-pass the white-list. This is no scalable solution. Do you have a number which amount of machines have problems? The number of machines that didn't came up by itself always used to be much bigger than the number that did. linux-acpi is the responsible list for most of the problems. There is a standard interface for that. The reasoning always was: better safe than sorry. Let users first figure out what is safe consciously, before trying to suspend without knowing resume will succeed (and risking data-loss). Okay, then I insist that uswsusp is not installed along any Debian provided kernels and will enforce that with a conflict because it breaks suspend for many machines. Bastian -- War isn't a good life, but it's life. -- Kirk, A Private Little War, stardate 4211.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
Op Sun, 5 Oct 2008 14:55:30 +0200 schreef Bastian Blank [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 09:54:33AM +0200, Tim Dijkstra wrote: First of all, if you know what command-line arguments you need to suspend you can use those with --force. If you use hal (via gnome-power-manager) you can create a .fdi file that will by-pass the white-list. This is no scalable solution. No this is a way of getting your machine suspend in case you are not whitelisted yet. Do you have a number which amount of machines have problems? The number of machines that didn't came up by itself always used to be much bigger than the number that did. I looked at some numbers. We currently have +/- 400 machines listed, of which +/1 100 need no work around. linux-acpi is the responsible list for most of the problems. There is a standard interface for that. What do you mean standard interface? At the moment we have +/- 6 different ways of mucking around with the video card to get the resume succeed. Note that this application is mostly developed by two kernel-hackers (Pavel Machek and Rafael Wysocki) who have also authored a lot of the suspend/resume code in the kernel (especially software suspend). The reasoning always was: better safe than sorry. Let users first figure out what is safe consciously, before trying to suspend without knowing resume will succeed (and risking data-loss). Okay, then I insist that uswsusp is not installed along any Debian provided kernels and will enforce that with a conflict because it breaks suspend for many machines. This is nonsense. It fixes suspend for more machines than it breaks. Without it (or similar functionality that can be provided by pm-utils in combination with various other packages) it will leave 75% of laptop users without a functioning suspend/resume. We already have a lot machines that do not need a quirk whitelisted, so the number of people we are `hurting' is far less than 25%. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
Quoting Bastian Blank ([EMAIL PROTECTED]): It is unusable on an unknown amount of machines. I would have no problem with that if it is only installed on request, but it is included in the laptop task and therefor a standard package. So? That still makes a good argument for Severity: important if you think that this deserve such importance.. This could make an argument to remove it from the laptop task, maybe. (please note that I do not necessarily agree with both of those statements, I just bring you less violent options than an RC bug) But I don't see this as enough to virtually suggest that the package as is should not be shipped with lenny. As Sven pointed later, does the kernel driver know what machines will properly wake up after suspend? From my experience, this is mandatory. signature.asc Description: Digital signature
Bug#500794: uswsusp - s2ram does not follow kernel
severity 500794 whishlist tags 500794 +willnotfix thanks First of all, if you know what command-line arguments you need to suspend you can use those with --force. If you use hal (via gnome-power-manager) you can create a .fdi file that will by-pass the white-list. Bastian Blank schreef: On Wed, Oct 01, 2008 at 07:54:54PM +0200, Sven Joachim wrote: But it does not know whether the machine will come up again, and even if that's the case, the screen may remain blank forever. Such is the case on my desktop. :-( Each kernel driver is allowed to veto suspension. The video card in a machine and its driver is of course of great influence on the ability of the machine to supsend and resume, but the not the only factor. There is also for example the BIOS. There's little point in suspending a machine that won't resume correctly afterwards. Do you have a number which amount of machines have problems? The number of machines that didn't came up by itself always used to be much bigger than the number that did. I must confess that I'm not following that number that well at the moment. Also there are some maior changes in very new kernels (.27 ?) that will change that number dramatically. The reasoning always was: better safe than sorry. Let users first figure out what is safe consciously, before trying to suspend without knowing resume will succeed (and risking data-loss). grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
Package: uswsusp Version: 0.8-1.1 Severity: grave s2ram ignores if the kernel say it supports suspend-to-ram and insist on a white list. As using s2ram is currently the default method, this is unacceptable. The kernel know itself if it can suspend a machine. Bastian -- It is more rational to sacrifice one life than six. -- Spock, The Galileo Seven, stardate 2822.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
Quoting Bastian Blank ([EMAIL PROTECTED]): Package: uswsusp Version: 0.8-1.1 Severity: grave s2ram ignores if the kernel say it supports suspend-to-ram and insist on a white list. As using s2ram is currently the default method, this is unacceptable. The kernel know itself if it can suspend a machine. I don't really understand how this makes the bug grave. important, maybe. - The package is usable - It doesn't cause data loss - It does not introduce a security hole ...or I'm really missing something in your rationale. signature.asc Description: Digital signature
Bug#500794: uswsusp - s2ram does not follow kernel
On 2008-10-01 15:53 +0200, Bastian Blank wrote: Package: uswsusp Version: 0.8-1.1 Severity: grave s2ram ignores if the kernel say it supports suspend-to-ram and insist on a white list. As using s2ram is currently the default method, this is unacceptable. The kernel know itself if it can suspend a machine. But it does not know whether the machine will come up again, and even if that's the case, the screen may remain blank forever. Such is the case on my desktop. :-( There's little point in suspending a machine that won't resume correctly afterwards. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
On Wed, Oct 01, 2008 at 07:54:54PM +0200, Sven Joachim wrote: But it does not know whether the machine will come up again, and even if that's the case, the screen may remain blank forever. Such is the case on my desktop. :-( Each kernel driver is allowed to veto suspension. There's little point in suspending a machine that won't resume correctly afterwards. Do you have a number which amount of machines have problems? Bastian -- Get back to your stations! We're beaming down to the planet, sir. -- Kirk and Mr. Leslie, This Side of Paradise, stardate 3417.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500794: uswsusp - s2ram does not follow kernel
On Wed, Oct 01, 2008 at 07:23:50PM +0200, Christian Perrier wrote: Quoting Bastian Blank ([EMAIL PROTECTED]): s2ram ignores if the kernel say it supports suspend-to-ram and insist on a white list. As using s2ram is currently the default method, this is unacceptable. The kernel know itself if it can suspend a machine. I don't really understand how this makes the bug grave. important, maybe. - The package is usable It is unusable on an unknown amount of machines. I would have no problem with that if it is only installed on request, but it is included in the laptop task and therefor a standard package. Bastian -- Deflector shields just came on, Captain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
