[prev in list] [next in list] [prev in thread] [next in thread] 

List:       swsusp-devel
Subject:    Re: [Swsusp] Re: [Swsusp-devel] Time for 1.0
From:       Nigel Cunningham <ncunningham () clear ! net ! nz>
Date:       2003-06-29 22:53:18
[Download RAW message or body]

Hi.

On Mon, 2003-06-30 at 10:25, Karol Kozimor wrote:
> Now, if I can add my $0.02 here:
> - a suspend cycle tends to corrupt the CPU usage stats given by ps. Try
>   running something CPU-intensive (as cat /dev/urandom > /dev/null), do a
>   ps aux, suspend/resume, repeat the ps and note the difference. top output
>   is apparently unaffected. This may seem marginal, but tends to cumulate,
>   thus preventing me from noticing the real problem, which is:
> - keventd running wild. (Possibly) any ACPI event trigerred during the
>   suspend cycle (read: closing the lid) is reportedly repeated after
>   resume, i.e. keventd falls in a loop, clogging the system logs and making
>   a fork/exec mess with handler scripts. This is easily reproducible by
>   pushing the lid button while pagedirs are written, and lefts resumed
>   system in a bad condition.

Yes, I've just started to see that too. It's new to me because I added
memory to my laptop a while ago and only just learnt that that was the
cause (via my dsdt override) of no more acpi events. Now that I'm seeing
the problem, I'm thinking about a fix too.

> I suppose the first problem may have been introduced byt the system load
> change bit. As for the second, I don't remember seeing it under previous
> versions (but then, any version after -pre7 was more or less unusable due
> to the XFS code that required patching) -- the problem must have been
> introduced somewhere between -pre8 and -pre14.

Perhaps it's the driver suspending and resuming. I'll look at it again.

> Then there's still unresolved issue of khubd freezing -- in reference to
> the discussion about the order of resuming: I don't think that resuming
> processes before drivers is a good idea, think sound or anything accessing
> removable hardware. Perhaps all the threads accessing hotplug (khubd,
> PCMCIA stuff, ethernet) could be handled specially?

Mmm. As I said in another message, I think hotplug itslef might need
special handling.

> For the good news: my panics were most probably attributed to the
> xfssyncds not being frozen, the report I sent (did I?) somewhere around
> -pre13 must have been a false positive, probably due to the fact that I did
> not issue a make clean after patching (that'll teach me!), so at least this
> problem seems to be solved.

Great. One less problem is always good!

Nigel

-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

You see, at just the right time, when we were still powerless,
Christ died for the ungodly.
	-- Romans 5:6, NIV.


_______________________________________________
swsusp mailing list
swsusp@lister.fornax.hu
http://lister.fornax.hu/mailman/listinfo/swsusp
[prev in list] [next in list] [prev in thread] [next in thread]