← Back to team overview

ac100 team mailing list archive

Re: unsuccessful resume with binary driver

 



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





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



Follow ups

References