Bug#433872: [Suspend-devel] nx6325 fails to resume from s2ram
On Thu, Sep 13, 2007 at 09:30:54PM +0200, Rafael J. Wysocki wrote: On Thursday, 13 September 2007 20:58, Tim Dijkstra wrote: Hi guys, I got this report, any ideas? Yes (I have this box :-)). Use a newer kernel. As far as I remember, everything later than 2.6.22 should work (except for some broken -mm releases). Generally (maybe we should put this into some README :-), the Kernel should be as new as the whitelist entry date. -- Stefan Seyfried QA / RD Team Mobile Devices| Any ideas, John? SUSE LINUX Products GmbH, Nürnberg | Well, surrounding them's out. This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Bug#432018: [Suspend-devel] wrong title, T61 works with -a1
On Mon, Jul 30, 2007 at 03:31:43AM +, Joe Nahmias wrote: On Tue, Jul 17, 2007 at 05:00:42PM +0200, Stefan Seyfried wrote: But -a3 works, too? Then i'd take that one, since most thinkpads work well with -a 3 and i'd like to avoid too many special cases. Yes, -a3 works as well. Verified both in console and X. Thanks, Thanks for confirming, added to the whitelist. -- Stefan Seyfried QA / RD Team Mobile Devices| Any ideas, John? SUSE LINUX Products GmbH, Nürnberg | Well, surrounding them's out. This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Bug#432018: [Suspend-devel] wrong title, T61 works with -a1
On Fri, Jul 06, 2007 at 06:57:23PM +, Joe Nahmias wrote: retitle 432018 Please add ThinkPad T61 to whitelist with -a1 thanks Sorry, I made a mistake in the title -- the body of the report is correct. The s3_bios acpi_sleep parameter [-a1] is all that is necessary for the backlight to work. But -a3 works, too? Then i'd take that one, since most thinkpads work well with -a 3 and i'd like to avoid too many special cases. Thanks for reporting. -- Stefan Seyfried QA / RD Team Mobile Devices| Any ideas, John? SUSE LINUX Products GmbH, Nürnberg | Well, surrounding them's out. This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Bug#415441: [Suspend-devel] s2disk and raid
On Tue, Apr 03, 2007 at 05:55:21PM +0200, Tim Dijkstra wrote: Hi, I've got a bugreport [0] from a user trying to use raid and uswsusp. He's using initramfs-tools available in debian. I'll describe the problem and my analysis, maybe you can comment on what you think. A warning: I only have a casual understanding of raid, never looked at any code related to it. This is a setup where root maybe on raid, but swap isn't. Swap on raid will be very difficult to support, I think. it depends :-) Now comes a crucial point. The script that finds the raid array, finds the array in an unclean state and starts syncing. bad. Don't do that. Data will be lost. After this, resume finds an image in the swap partition and starts the resume process. Part of this process is freezing everything but itself, which fails on the process/thread that does the syncing. IMO, the problem comes from the fact we started syncing, before we could start resume. Yes. Now the problem could theoretically be solved by not starting the assembly of the array once it is discovered, but modifying the initramfs to do the assembly after we have had the chance to resume. Yes. The debian-maintainer of mdadm thinks that the suspend process should have left the array in a clean state, but this is IMHO impossible. We are freezing userspace. A mdamd process looking after the array will probably get into trouble if we come back from suspend and we have done something to the array in the mean time. Yes. What do you think? You are right, he is wrong. Do not touch anything before resume. -- Stefan Seyfried Any ideas, John? Well, surrounding them's out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410320: [Suspend-devel] Bug#410320: s2ram: whitelist entry
Hi,
On Mon, Feb 12, 2007 at 09:30:17PM +0100, Tim Dijkstra wrote:
Hi Guys,
I just got this report
On Fri, 9 Feb 2007 18:19:59 +0100
Bill Allombert [EMAIL PROTECTED] wrote:
Package: uswsusp
Version: 0.3~cvs20060928-6
Severity: wishlist
Hello Tim,
With etch-amd64 on my new laptop, s2ram work fine with that option:
#s2ram -f -a 1
Here the laptop ID:
#This machine can be identified by:
sys_vendor = FUJITSU SIEMENS
sys_product = Amilo Si 1520
sys_version = Rev 1
bios_version = 1.10
Current CVS already has this entry:
{ FUJITSU SIEMENS,Amilo Si 1520,, ,
S3_BIOS|S3_MODE },
I'm not really an expert in those video hacks. What would Bill have
missed without S3_MODE? Higher resolution console maybe?
Yes, vesafb.
With S3_BIOS, you usually end in plain VGA mode (as after VBE_POST), S3_MODE
then sets back the VESA mode (same as VBE_MODE), at least IIUC, which should
be a noop in the case of non-fbdev console.
Bill, if you could try if your machine also wirks with s2ram -f -a3,
this would confirm the entry which is already in the whitelist.
Thanks,
Stefan
--
Stefan Seyfried
Any ideas, John?
Well, surrounding them's out.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410320: [Suspend-devel] Bug#410320: s2ram: whitelist entry
On Mon, Feb 12, 2007 at 11:49:49PM +0100, Bill Allombert wrote:
On Mon, Feb 12, 2007 at 09:52:09PM +0100, Stefan Seyfried wrote:
Hi,
{ FUJITSU SIEMENS,Amilo Si 1520,, ,
S3_BIOS|S3_MODE },
Bill, if you could try if your machine also wirks with s2ram -f -a3,
this would confirm the entry which is already in the whitelist.
I just tested and it works fine.
Thanks for testing, this means that the current whitelist entry as in
CVS will work fine for you, and that this bug can probably be closed
as will be fixed with the next version update :-)
Have fun,
Stefan
--
Stefan Seyfried
Any ideas, John?
Well, surrounding them's out.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
