[Gta04-owner] dbus crashing with SIGBUS after suspend/resume

[Dr. H. Nikolaus Schaller]

Am 06.08.2013 um 02:28 schrieb NeilBrown:

> On Sat, 03 Aug 2013 18:39:11 +0200 EdorFaus <edorfaus at xepher.net> wrote:
> 
>> Hi,
>> 
>> On 07/01/2013 03:35 PM, Radek Polak wrote:
>>> i have quite tracked it down to the patch that enabled omap_off_mode.
>> 
>> I've been running with the v56 kernel for a little while (which disabled 
>> off_mode), and dbus no longer crashes for me, so this does indeed appear 
>> to be the cause (thank you for figuring it out).
>> 
>>> and it dbus crashed after like 2 calls
>> 
>>> Attached is diff between these two branches. Maybe it helps?
>> 
>> I noticed something suspicious in the diff that seems to align with the 
>> 2 calls part.
>> 
>> It may just be that I'm too unfamiliar with this code to see something 
>> obvious, but in the arch/arm/mach-omap2/pm34xx.c file there's this part:
>> 
>> +		if (strcmp(pwrst->pwrdm->name, "core_pwrdm") == 0) {
>> +			static int times = 0;
>> +			times++;
>> +			if (times == 1)
>> +				pwrst->next_state = PWRDM_POWER_RET;
>> +			if (times == 2)
>> +				pwrst->next_state = PWRDM_POWER_OFF;
>> +		}
>> 
>> which adds a static int, and increments it on every call - but never 
>> resets it, and only does anything the first two times (which aligns with 
>> only 2 calls working properly).
> 
> This is as intended.  I needed to ensure that on the first suspend attempt
> the state only goes to 'RETain'.  On second and later attempts it is safe to
> go to "OFF".
> So set to RET the first time, then set to OFF and leave it there.
> 
> I don't remember exactly why this works.... or even if I ever discovered why
> it works. But it does (except for the SIGBUS thing).

Just some wild guessing: AFAIR there are shadow registers for some
controls in the OMAP that are control GPIO states in OFF mode. And
they could be initialized by RETain.

The interesting question is if and why we (still?) need it and if it potentially
conflicts with something in the 3.11 kernel since Radek reported that
suspend isn't as good as it was.

> 
>> 
>> I don't know if this is actually called during suspend/resume, or 
>> whether it's actually relevant even so, but I figured I should mention 
>> it in any case, just in case I was onto something.
>> 
>> By the way, if it isn't supposed to do anything after the second time, 
>> but is still called repeatedly, there's actually a tiny bug in it (which 
>> is admittedly very unlikely to be triggered): since the int is 
>> incremented always, it will eventually overflow and become 1 again...
> 
> Yes, there is a tiny bug.  1 in every 4billion suspend cycles it will only go
> to RET instead of OFF.
> 
> Thanks,
> NeilBrown
> 
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner