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

NeilBrown neilb at suse.de
Tue Aug 6 02:28:50 CEST 2013


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).

> 
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20130806/6f7f5450/attachment.bin>


More information about the Gta04-owner mailing list