Re: status update for current development on ASUS M2N

Re: status update for current development on ASUS M2N

[Nigel Cunningham]

Hi.

----- Original Message -----
From: "Georg C. F. Greve" <greve@gnu.org>
Date: Thu, 30 Sep 2004 11:59:54 +0200
To: ncunningham@linuxmail.org
Subject: Re: [SoftwareSuspend-devel] status update for current development on ASUS M2N

>  || On Mon, 27 Sep 2004 20:11:41 +1000
>  || Nigel Cunningham <ncunningham@linuxmail.org> wrote: 
> 
>  nc> Could I get you to compile kdb in as well. If you then press the
>  nc> Sys Rq key when the CPU is being chewed, you should be able to
>  nc> use ps and btp <process number> to get an idea of what is going
>  nc> on.
> 
> I am now running kernel
<< patch-2.6.9-rc2-plus_5.txt >>

>
> 
> and also created a version with kdb and heavy debugging.
> 
> This kernel shows the same behaviour and can suspend/resume so I can
> get into kdb and do btp. Unfortunately I seem to be too stupid to find
> the way to get the output somehow saved or written anywhere.
> 
> Not having the time (and motivation, to be honest) to write down all
> the names and numbers -- and also not feeling that sending digital
> photographs is the best way of communicating that output -- I don't
> know how to give you that information.
> 
> Can you tell me how to do this, please?

The simplest way is to do a digital photograph, I'm afraid. The 'nice' way is to hook up a serial console and capture the output. If you do a photo, just send it to me, please.

Regards,

Nigel
-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

Re: status update for current development on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

 || On Fri, 01 Oct 2004 07:48:08 +1000
 || "Nigel Cunningham" <ncunningham@linuxmail.org> wrote: 

 >> Can you tell me how to do this, please?

 nc> The simplest way is to do a digital photograph, I'm afraid. The
 nc> 'nice' way is to hook up a serial console and capture the output.

That is rather inconvenient.

I'm curious. Any reason that nobody implemented something to do this?

I would assume that a kdb buffer that is reserved at startup,
initalized with 0s and into which only kdb can write during debugging.

When kdb is left and the buffer is different from 0, the contents are
dumped to dmesg/syslog.

This appears to me like it would be a rather simple solution to avoid
having to send around pictures or using a second computer...


 nc> If you do a photo, just send it to me, please.

Just did that. Please confirm that you got it and it did not get stuck
anywhere on the way.

Hope this helps,

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: status update for current development on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 402 bytes --]

 || On Sat, 02 Oct 2004 00:31:57 +0200
 || "Georg C. F. Greve" <greve@gnu.org> wrote: 

 nc> If you do a photo, just send it to me, please.

 gg> Just did that. Please confirm that you got it and it did not get
 gg> stuck anywhere on the way.

I hope you got it... in the days of spam I am not so confident about
the reliability of email anymore.

Quick update:

The situation persists for the kernel


[-- Attachment #1.2: patch-2.6.9-rc3-plus_1.txt --]
[-- Type: text/plain, Size: 561 bytes --]

Patches contained:

linux-2.6.8
patch-2.6.9-rc3

software-suspend-2.1-rc1-for-2.6.9-rc3

2.6.9-rc3-mm1/swsusp-fix-highmem.patch
	bk-acpi.patch
	acpi-compile-fix.patch
	acpi-x86_64-build-fix.patch
	bk-agpart.patch
	bk-alsa.patch
	bk-cpufreq.patch
	cpufreq-ondemand-prevent-various-divide-underflows.patch
	cpufreq-ondemand-account-iowait-as-idle-time.patch

ipw2100-0.55

arch/i386/kernel/i8259.c:

  * changed device_initcall(i8259A_init_sysfs);
         to late_initcall(i8259A_init_sysfs);
    (needed for suspend to RAM)

Makefile:

  * added -plus version


[-- Attachment #1.3: Type: text/plain, Size: 277 bytes --]


in the same way, as far as I can tell.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: status update for current development on ASUS M2N

[Nigel Cunningham]

Hi.

On Sat, 2004-10-02 at 08:31, Georg C. F. Greve wrote:
>  || On Fri, 01 Oct 2004 07:48:08 +1000
>  || "Nigel Cunningham" <ncunningham@linuxmail.org> wrote: 
> 
>  >> Can you tell me how to do this, please?
> 
>  nc> The simplest way is to do a digital photograph, I'm afraid. The
>  nc> 'nice' way is to hook up a serial console and capture the output.
> 
> That is rather inconvenient.
> 
> I'm curious. Any reason that nobody implemented something to do this?
> 
> I would assume that a kdb buffer that is reserved at startup,
> initalized with 0s and into which only kdb can write during debugging.
> 
> When kdb is left and the buffer is different from 0, the contents are
> dumped to dmesg/syslog.

Something like printk :> It wouldn't work with suspending because we're
overwriting such buffers when copying the original kernel back (with the
contents from suspend-time). Furthermore, it won't help if you get such
a crash because you're never going to start syslogd and get the data
written.

Sorry.

Nigel

Re: status update for current development on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

 || On Wed, 06 Oct 2004 09:44:23 +1000
 || Nigel Cunningham <ncunningham@linuxmail.org> wrote: 

 >> When kdb is left and the buffer is different from 0, the contents
 >> are dumped to dmesg/syslog.

 nc> Something like printk :> It wouldn't work with suspending because
 nc> we're overwriting such buffers when copying the original kernel
 nc> back (with the contents from suspend-time). Furthermore, it won't
 nc> help if you get such a crash because you're never going to start
 nc> syslogd and get the data written.

I agree that it would not help in all cases.

In this case it would have helped, though. The machine is running,
syslog is doing its job -- that is how I got the sysrq-T output.

So if kbd had support for that, we could have saved ourselves the
trouble of taking a photograph of the screen and mailing that around.

Speaking of which: Since you told me that you did not see it, I just
resent it, please let me know whether it reaches you this time.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

status update for current development on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 50 bytes --]

Hi all,

FYI:

My latest kernel, which looks like

[-- Attachment #1.2: Patch description for 2.6.9-rc2-plus_4 --]
[-- Type: text/plain, Size: 576 bytes --]

Patches contained:

linux-2.6.8
patch-2.6.9-rc2

software-suspend-108-for-2.6.9-rc2 (without kdb)
software-suspend-108-fixes (from http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/linux-2.6-software-suspend-fixes.patch?rev=1.3)

2.6.9-rc2-mm3/bk-acpi.patch
	./acpi-compile-fix.patch
	./acpi-x86_64-build-fix.patch
	./bk-agpgart.patch
	./bk-alsa.patch
	./bk-cpufreq.patch

ipw2100-0.54

arch/i386/kernel/i8259.c: 

  * changed device_initcall(i8259A_init_sysfs);
         to late_initcall(i8259A_init_sysfs);
    (needed for suspend to RAM)

Makefile:

  * added -plus version


[-- Attachment #1.3: Type: text/plain, Size: 1140 bytes --]



seems not so bad.

Both suspend to ram and suspend to disk via swsusp2 (108) appear to
work fine. I completed a few cycles without problems.

However: If I suspend to ram once and then suspend to disk, resume
From disk works fine, but about 20 seconds to 1 minute later, the
load suddenly jumps to 100% and stays there.

The kacpid process seems to run wild and eat all available time, it
looks like some kind of wild loop, but there is no output. I can
normally shut the machine down -- although it takes a while.

I've tried compiling ACPI as modules and unloading the modules as well
as restarting the acpid before/after suspend to disk. Upon reloading
the modules things hang with "thermal" -- but that seems arbitrary,
the effect still shows up even if no thermal is loaded.

Not sure this helps anyone improve things, still wanted to give you
the feedback, though.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: status update for current development on ASUS M2N

[Nigel Cunningham]

Hi Georg.

On Mon, 2004-09-27 at 18:47, Georg C. F. Greve wrote:
> The kacpid process seems to run wild and eat all available time, it
> looks like some kind of wild loop, but there is no output. I can
> normally shut the machine down -- although it takes a while.

Could I get you to compile kdb in as well. If you then press the Sys Rq
key when the CPU is being chewed, you should be able to use ps and btp
<process number> to get an idea of what is going on. There have been
thermal issues reported on the help list. They might be related. I'll
see if I can reproduce anything on my desktop.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

Re: status update for current development on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

 || On Mon, 27 Sep 2004 20:11:41 +1000
 || Nigel Cunningham <ncunningham@linuxmail.org> wrote: 

 nc> Could I get you to compile kdb in as well. 

I wish I could give you the info, tried compiling things in, but
unfortunately the machine dies on suspend to disk when the kdb code is
compiled in, it seems.

Unfortunately I'm lacking the time to investigate it further right
now, but I will try later if I get the chance.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: status update for current development on ASUS M2N

[Karol Kozimor]

Thus wrote Georg C. F. Greve:
> However: If I suspend to ram once and then suspend to disk, resume
> From disk works fine, but about 20 seconds to 1 minute later, the
> load suddenly jumps to 100% and stays there.

I had that issue too, with 2.6.9-rc1 I s'pose, but I thought it was just
bug #3193 revisited and didn't really investigate. Does changing swsusp2 to
_not_ use ACPI S4 help?
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl