Message-Id: <200809271801.38449.rjw@sisk.pl>
Date:	Sat, 27 Sep 2008 18:01:37 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Maxim Levitsky <maximlevitsky@...il.com>
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

On Saturday, 27 of September 2008, Maxim Levitsky wrote:
> Rafael J. Wysocki wrote:
> > On Monday, 22 of September 2008, Maxim Levitsky wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Sunday, 21 of September 2008, Maxim Levitsky wrote:
> >>>> Maxim Levitsky wrote:
> >>>>> 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)
> >>>> I did same test for kernel without SMP, yes it hangs on first resume, but bios
> >>>> does pass control to linux, so while this is a minor bug, it is unrelated.
> >>> Still, I'd be interested in debugging this one too, if possible.  That may be
> >>> easier too. ;-)
> >> I take a look at that.
> >>
> >>>> I also tested noapic, pci=nommconf. No luck.
> >>>>
> >>>> Pattern is always the same, first resume works always, second doesn't.
> >>>> It is sad since first resume is almost perfect (when I have free time I need to look at sound codec datasheet
> >>>> and fix few issues there, anyways here alsa has few issues, all this is trivial, I already fixed all issues with desktop
> >>>> which has a sigmatel codec)
> >>> If you have more than 2 GB of RAM, you can try iommu=soft .
> >>>
> >>> I guess that all of the /sys/power/pm_test tests are passed?
> >> Well, I didn't run /sys/power/pm_test. 
> >> But this system has rock solid suspend to disk, I use it always.
> > 
> > Please look at http://bugzilla.kernel.org/show_bug.cgi?id=11415 .
> 
> Hi,
> 
> 
> I took a look there, but it doesn't seem to be similar to my issue,
> my issue is much bigger :-(
> 
> They tell that 2.6.24 works, but here nothing works, I was never able to do
> two suspends in row.
> 
> What I did find interesting was that they mention hardware locks of several kind there, so I am thinking
> could that be related to EC code, could it be that EC code confuses it somehow, so next boot doesn't work?
> Some hardware lock that kernel forgets to unlock, and that prevents bios from resume
> 
> Here ec switches to polled mode almost instantly, due to that bogus 'interrupt storm', I tried to increase interrupt threshold,
> and no more polled mode, but nether working second resume :-(

Have you tried the patch from http://bugzilla.kernel.org/show_bug.cgi?id=10724#c142 ?

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/

Powered by blists - more mailing lists