linux-kernel - Re: I need some serious help to debug suspend to ram problem

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: <48D54873.8010108@gmail.com>
Date:	Sat, 20 Sep 2008 22:01:07 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: I need some serious help to debug suspend to ram problem

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
--
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/