ac100 team mailing list archive
Mailing list archive
Re: unsuccessful resume with binary driver
Am Dienstag, 20. Dezember 2011, 09:26:53 schrieb Mikko Lehtonen:
> > would it be ok if you test a 3.0 kernel to see if suspend is more
> > reliable? I
> > made some changes which maybe improve resume (in fact, the .38 code
> > always
> > failed to resume in 3.0, so it needed a fix).
> I've now done minimal testing with the 3.0 kernel.
> While the kernel otherwise seems to work just fine,
> it still fails to resume with the binary driver.
> This time I got this in my syslog, repeated many times:
> Dec 20 09:06:12 ac100 kernel: [ 38.458295] tegra_grhost tegra_grhost:
> syncpoint id 22 (3d) stuck waiting 713
> Dec 20 09:06:12 ac100 kernel: [ 38.458311] tegra_grhost tegra_grhost:
> id 10 () min 8 max 8
> Dec 20 09:06:12 ac100 kernel: [ 38.458322] tegra_grhost tegra_grhost:
> id 18 (2d_0) min 215 max 217
> Dec 20 09:06:12 ac100 kernel: [ 38.458332] tegra_grhost tegra_grhost:
> id 22 (3d) min 705 max 722
ok, that's very bad :-( I fear we cannot do something about this now. I guess we have
to wait for the ChromeOS people to catch up with the newest kernel api development,
or some other "wonder"...
If you really need reliable resume, just remove the binary blob and use the
framebuffer driver. It is fast enough for most situtations.
> >> And now that I'm going on about suspend, at some point the close lid
> >> didn't even suspend reliably, so I sometimes suspended from the
> >> menu,
> >> but as I was doing that in train just when my stop comes, I'm in a
> >> hurry
> >> and close the lid anyway, and next time it resumes (succesfully), it
> >> goes to suspend immediatelly again, so there is some double standby
> >> action going on there.
> >> (and I think I once saw a double modulated standby-led-blink)
> > mmh, I just checked it here on 3.0 and it worked as expected. So
> > again, can
> > you please test with janimos kernel?
> I need more reliable resuming to test this further.
> Mikko Lehtonen · scoopr