Re: [BISECTED] [REGRESSION] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Thu, 2009-04-09 at 15:06 +0300, Maxim Levitsky wrote:
> On Tue, 2009-04-07 at 17:24 +0200, Rafael J. Wysocki wrote:
> > On Tuesday 07 April 2009, Maxim Levitsky wrote:
> > > Hi,
> > 
> > Hi,
> > 
> > > This is first time, I am actually happy about a regression....
> > > 
> > > I have a notebook, aspire 5720G that fails to do two suspends to ram in
> > > row.
> > > 
> > > for example I can do s2ram->s2disk->s2ram->...
> > > but can't s2ram->s2ram.
> > > 
> > > Well that at least was the situation till now.
> > > Also there is no way to debug this - bios doesn't pass control back to
> > > linux on failed resume. I tried probably every guess I could come with.
> > > 
> > > Now, after a commit a0d4922da2e4ccb0973095d8d29f36f6b1b5f703 which I
> > > finally bisected, I can't anymore do two suspends to ram at all,
> > > regardless of suspend to disk in between. Also bios doesn't pass control
> > > when resume fails.
> > 
> > I wonder what happens if the in-between s2disk is in the "shutdown" mode.
> > Theoretically, it should work as a cold boot, so the second s2ram should work
> > in this case.
> > 
> > > I actually did 3 bisects, as I had to find fixes to 2 more s2ram bugs
> > > that were fixed.
> > > the fixes are:
> > > 
> > > a0e280e0f33f6c859a235fb69a875ed8f3420388
> > > 1e70c7f7a9d4a3d2cc78b40e1d7768d99cd79899
> > 
> > Commit a0d4922da2e4ccb0973095d8d29f36f6b1b5f703 has been modified quite a bit
> > by some later commits due to regressions it introduced.
> > 
> > > Now, why I am happy about this:
> > > It seems that a suspend cycle changes something that explodes on next
> > > resume. a s2disk cycle cleared this, but not anymore, thus the poison
> > > must be somehow connected to the
> > > a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
> > 
> > Hint: it would be a lot easier to read the message if you included the subjects
> > of the commits too. :-)
> > 
> Sure, sorry ;-)
> 
> > > PCI state?? I tried restoring it from saved file, (created on suspend)
> > > but this didn't help.
> > > (Only a single register, which looks like a clear or write register
> > > changed).
> > > 
> > > 
> > > Also this commits narrows down the search, now it is clear that this is
> > > usb related. No wonder bios pokes at usb on resume and stalls.....
> > > 
> > > 
> > > It could even be connected to bios handoff, maybe we don't do that on
> > > resume?
> > > 
> > > (Note: this regression is present all way to latest -git)
> > 
> > I'm not sure if we really should consider this as a regression.  s2ram clearly
> > didn't work correctly on your machine before and the s2disk in between
> > is not really relevant here IMO.
> Yet, this allowed me at least lalf the time to do s2ram.
> s2disk eats battery, if I suspend the system for short time
> 
> 
> > 
> > > What do you think?
> > 
> > Well, not much apart from the observation that the problem with s2ram on your
> > machine is probably related to USB.  In fact, on Intel chipsets there seem to
> > be some strange links between the USB controllers (most notably EHCI) and
> > the core chipset that don't appear to be well documented and this may be the
> > case in which they show up.  Dunno.
> 
> Sorry for late reply,
> 
> I now semi-bisected, the change inside this patch.
> 
> First, UHCI doesn't affect anything.
> 
> Then, if I move 'late' suspend functions inside normal ones, everything
> returns works like it used to be (I need to retest this statement, I did
> other changes too).
Yep, just moving content of late suspend and content of early resume to
normal suspend/resume functions fixes this issue.

> 
> 
> Also, I got a idea about, think about this:
> my notebook has a webcam, a usb UVC webcam.
> 
> Fact that it has firmware, can't be argued, it has to be true.
> Suppose its firmware is stored in bios?
> In this case, bios would load it on resume from ram, thus it will need
> fully functional ehci controller.
> We do something wrong, or more correctly, bios has some wrong
> assumptions (read assume windows driver) about ehci state.
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
>