linux-kernel - Re: Suspend on Dell D420

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200608081741.24099.rjw@sisk.pl>
Date:	Tue, 8 Aug 2006 17:41:23 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Steinar H. Gunderson" <sgunderson@...foot.com>
Cc:	linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...l.org>
Subject: Re: Suspend on Dell D420

On Tuesday 08 August 2006 17:01, Steinar H. Gunderson wrote:
> On Tue, Aug 08, 2006 at 04:04:00PM +0200, Rafael J. Wysocki wrote:
> > Please apply the appended patch to the SMP kernel and try the following:
> >
> > [...]
> >
> > I think (1) will work and (2) will not, but let's see. :-)
> 
> Actually, both worked just fine. The first one (testproc) gave me EPERM on
> the actual write call according to echo, but I guess that's just a side
> effect of sloppy test code :-)

Oh, I just forgot to initialize error in kernel/power/disk.c#prepare_processes.c .
Sorry.

However, this means the drivers' suspend and resume routines seem to work fine
and the problem is somehow related to the BIOS black magic that happens
during the "real" suspend.

No idea what to do next. :-(

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/