public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: I need some serious help to debug suspend to ram problem
Date: Sat, 20 Sep 2008 22:01:07 +0300	[thread overview]
Message-ID: <48D54873.8010108@gmail.com> (raw)
In-Reply-To: <200809201810.45057.rjw@sisk.pl>

Rafael J. Wysocki wrote:
> On Saturday, 20 of September 2008, Maxim Levitsky wrote:
>> Hi,
>>
>> I hit a dead end when trying to understand 
>> why my notebook can't resume from suspend to ram
>> if this is done two times a row.
>>
>> Single suspend/resume cycle works almost perfectly 
>> (beep that goes through the sound card is muted... 
>> no morse code for me... :-(
>>
>> )
>>
>> I compiled a minimal kernel (absolutely nothing but disk drivers, all experimental option like nohz
>> turned off)
>>
>> But I had to turn SMP, since without it system won't resume first time I suspend it.
>> (How could this affect suspend?)
> 
> It could if the system is 64-bit.  In which case please have a look at
> http://bugzilla.kernel.org/show_bug.cgi?id=11237
> 
>> With SMP and minimal kernel (of course  no closed drivers), I get same behavior,
>> first resume works second hangs.
>>
>> I then added some debug code to real mode wakeup code, I put there in first
>> place instructions, that will save some magic value to rtc (to alarm
>> registers that I know are preserved during boot cycle), and I discovered   
>> sad thing that first time bios does pass control to linux, but second time
>> (when it hangs), it doesn't. 
>>
>>
>> I tried to update bios, and I got same results.
>>
>> Of course it does work with that @#$%^& OS
> 
> So we're doing something wrong.  Please try the appended patch.
Thanks a lot, but this didn't help.

It still has same pattern, first suspend/resume works perfectly, 
second suspend/resume hangs hard.
It always happens like this, first resume always work 
(unless I turn off smp in kernel (I test this again), or reserve all low memory)

Also note that if I suspend the system to ram, resume, and then suspend to disk, 
then I can suspend to ram and resume, it seems that

on suspend to ram cycle somehow arms BIOS or something else, 
so second resume in a row doesn't work.

I run 32 bit kernel here, this is a long story 
(this bios doesn't turn fan on when running 64-bit version, 
I could update it, and I know that fan issue is fixed there, 
but new bios introduces bigger bug, namely it makes fan to run almost always 
regardless of 32/64 type of os.
And it doesn't fix this suspend/resume issue, I tested this. 
I could start/stop fan manually with a script, but this could fail, 
and maybe I will do so someday.)

The bugzilla seems to be unrelated here, since bios does 
pass control there, but corrupts memory.
Here I also have seen that bios corrupts memory, 
but everything resumes fine first time, and on second time,
bios doesn't pass control (I put set of instructions in beginning 
of wakeup real mode assembly file, no page tables, GDT/LDT are used there)


Best regards,
	Maxim Levitsky

  reply	other threads:[~2008-09-20 19:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-20 12:03 I need some serious help to debug suspend to ram problem Maxim Levitsky
2008-09-20 16:10 ` Rafael J. Wysocki
2008-09-20 19:01   ` Maxim Levitsky [this message]
2008-09-21 17:22     ` Maxim Levitsky
2008-09-21 18:56       ` Rafael J. Wysocki
2008-09-22  7:59         ` Maxim Levitsky
2008-09-27 13:15           ` Rafael J. Wysocki
2008-09-27 14:53             ` Maxim Levitsky
2008-09-27 16:01               ` Rafael J. Wysocki
2008-09-27 18:12                 ` Maxim Levitsky
2008-09-21 16:00   ` Maxim Levitsky
2008-10-06 15:11     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48D54873.8010108@gmail.com \
    --to=maximlevitsky@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox