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
_______________________________________________
Mailing list: https://launchpad.net/~ac100
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ac100
More help : https://help.launchpad.net/ListHelp
