[BetterBatteryStats] Tungstwenty:
This is not the case.

The 0x00080000 value we're seeing in the log is not an address, but rather a bit mask. Bit 19 in this particular case, since 1 << 19 (decimal) = 00000000 00001000 00000000 00000000 = 0x00080000

The challenge is now to understand which physical device is using bit 19 to signal the CPU that it should interrupt whatever is happening to call the appropriate IRQ. Or, in this scenario, prevent it from going to sleep since there's an IRQ handler to be called to handle the HW interruption, do whatever must be done, and mark this interruption as handled before the next one appears.

More below.

I searched the web for this but the files that contain it are in "sound/..." so it doesn't make a lot of sense that all the interruption bits are allocated just for the sound part, right? These variables must be for some other stuff and not for the CPU interrupt lines.

Again, those 2 sources seem to indicate way too many values to be what we want.

Also, searching for 0x00080000 is probably less likely to give us what we want than 1 << 19 (or 1 << 0x13) which none of them are that simple.

Well, I did find it despite my skepticism about it :p

If you want to follow, I'll be mentioning siyah-s2 sources (it's an I9100 right?), specifically under /arch/arm, but it should pretty much be a deduction that can be adapted for other platforms.

Some "magic" addresses from memory can also be found in the Exynos specs.

The logged message comes from this part of plat-samsung.c:

u32 pending_eint = pm_check_eint_pend();
if (pending_eint) {
pr_warn("%s: Aborting sleep, EINT PENDING(0x%08x)\n",
__func__, pending_eint);
return -EBUSY;
}

Grepping pm_check_eint_pend under arch/arm shows that for exynos4, you have in mach_exynos/pm-exynos4.c:

static unsigned int exynos4_pm_check_eint_pend(void)
{
int i;
u32 wakeup_int_pend, pending_eint = 0;

for (i = 0; i < 4; i++) {
wakeup_int_pend =
(__raw_readl(S5P_EINT_PEND(i)) & 0xff) << (i * 8);
pending_eint |= wakeup_int_pend & ~s3c_irqwake_eintmask;
}

return pending_eint;
}

...
if (soc_is_exynos4210())
pm_check_eint_pend = exynos4_pm_check_eint_pend;
...

And searching a bit more, S5P_EINT_PEND(0 to 3) is:

#define S5P_EINT_PEND(x)	(EXYNOS_EINT40PEND + ((x) * 0x4))
...
#define EXYNOS_EINT40PEND	(EINT_BASE_ADD + 0xF40)

F40 does appear in the spec, as

WAKEUP_INT0_PEND | 0x0F40 | External Interrupt WAKEUP_INT0 Pending Register | 0x0000_0000
WAKEUP_INT1_PEND | 0x0F44 | External Interrupt WAKEUP_INT1 Pending Register | 0x0000_0000
WAKEUP_INT2_PEND | 0x0F48 | External Interrupt WAKEUP_INT2 Pending Register | 0x0000_0000
WAKEUP_INT3_PEND | 0x0F4C | External Interrupt WAKEUP_INT3 Pending Register | 0x0000_0000

Basicaly, bit 7 of WAKEUP_INT2_PEND is on. Which device is it?

Looking for that s3c_irqwake_eintmask, which reflects the ones that are to be checked upon suspension, shows that's its used in some other places in conjunction with the IRQ_EINT_BIT macro:

int s3c_irqext_wake(struct irq_data *data, unsigned int state)
{
unsigned long bit = 1L << IRQ_EINT_BIT(data->irq);

if (!(s3c_irqwake_eintallow & bit))
return -ENOENT;

printk(KERN_INFO "wake %s for irq %d\n",
state ? "enabled" : "disabled", data->irq);

if (!state)
s3c_irqwake_eintmask |= bit;
else
s3c_irqwake_eintmask &= ~bit;

return 0;
}

After a bit of manual search for the submacros invoked by IRQ_EINT_BIT, I finally found a match between an irq (under e.g. /proc/interrupts) and the bits that are in the wakeup mask printed when entering and leaving deep sleep:

<4>[89550.659109] s3c_pm_enter(3)
<4>[89550.659156] sleep: irq wakeup masks: [COLOR="Red"]fffffffd,cb37bd7f[/COLOR]
<1>[89550.659420] PM: SLEEP
<1>[89550.659439] ARM_COREx_STATUS CORE1[0x00070000], CORE2[0x00000000], CORE3[0x00000000]
<6>[90159.948334] WAKEUP_STAT: 0x80000001
<6>[90159.948334] WAKEUP_INTx_PEND: 0x0, 0x0, 0x80, 0x0
<4>[90159.948334] s3c_pm_enter: post sleep, preparing to return
<4>[90159.948334] S3C PM Resume (post-restore)

It's:

EINT_bit = IRQ - 352​

:victory:

My /proc/interrupts file shows the following in the external interrupts area:

...
238: 0 COMBINER s5p-sysmmu.13
281: 603329 COMBINER s3cfb
353: 0 exynos-eint k3g
354: 42 exynos-eint proximity_int
356: 248597 exynos-eint mxt224_ts
359: 2311 exynos-eint max8997-irq
361: 25930 exynos-eint hostwake
365: 52 exynos-eint
366: 7 exynos-eint phone_active
367: 0 exynos-eint pn544
368: 8 exynos-eint gpio_keys
369: 9 exynos-eint gpio_keys
370: 6370 exynos-eint akm_int
371: 2 exynos-eint max17042 fuel alert
372: 1 exynos-eint Si4709
373: 23152 exynos-eint
374: 0 exynos-eint bt host_wake
375: 546 exynos-eint gpio_keys
378: 0 exynos-eint sec_headset_detect
380: 0 exynos-eint s3c-sdhci.2
381: 29 exynos-eint gpio_keys
383: 1 exynos-eint hpd
389: 942 s5p_gpioint sec_touchkey
397: 0 s5p_gpioint sii9234
430: 15 max8997 chg-insert
431: 14 max8997 chg-remove

The mask fffffffd,cb37bd7f means that all irqs are masked from waking up the system, except for:

7 -> 359 -> max8997-irq

9 -> 361 -> hostwake

14 -> 366 -> phone_active

19 -> 371 -> max17042 fuel alert

22 -> 374 -> bt host_wake

23 -> 375 -> gpio_keys

26 -> 378 -> sec_headset_detect

28 -> 380 -> s3c-sdhci.2

29 -> 381 -> gpio_keys

If I enable slide2wake, the new mask will be fffffffd,cb37bd6f which now includes:

4 -> 356 -> mxt224_ts (touch screen)

which makes sense :good:

So, with this reasoning and if the same math applies (the "352" magic value is different on e.g. exynos5), the mask 0x00800000 indicates bit 19, irq "max17042 fuel alert".

Either there's a hardware problem that makes the interruption be raised a lot of times (repair) OR it might be a kernel bug that doesn't properly clear the pending interrupt status after it has been handled.

The first reason is the most likely given the "low batt alerted" messages, which are logged from "max17042_fuelgauge_u1.c".

@picollo78, could you post the contents of /proc/interrupts just to make sure your device has the same mappings as the ones I described?

Run this on a terminal:

su
cat /proc/interrupts > /sdcard/interrupts.txt

And attach the interrupts.txt file

Also, can you flash a custom kernel instead of the one you're using, to see if that changes anything? (perhaps with a kmsg / dmesg dump as well, under those conditions). If you haven't tried that before, that is.