[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] karandpr:
Another Observation/post

So I decided to check the bug again from the beginning ....A part of the problem for bug was that the "bug" could not be replicated by kast .......I encountered the bug last week..and i have successfully replicated it over 50 times ...Makes me feel pro ...

The bug occurs due to improper shut down ..Pretty easy to replicate ...Pull the battery worked fine...

How to identify bug

The 100% battery is a giveaway really :p

Extra long boot time ................................Roughly 2-10 seconds more .

Science....

Get a dmesg .If you see these lines

msm_i2c msm_i2c.0: (00aa) Error during data xfer (-5)
bq27520 0-0055: Failed unseal when checking IT Enable. rc=-5
bq27520 0-0055: IT Enable check failed. rc=-5

This is THE CRUX OF THE BUG

Kappa Kernels in which the bug doesn't exist

Kappa 130 -Kappa 1.3

Kappa kernels on which the bug exists ...

1.4 :Kappa69.img

1.5: KaMangoV1-5.img

1.6 KaMango1.6Rel.img

1.7 Beta

KaMango1.7Beta4.img

KaMango1.7Beta9.img

KaMango474.img

KaMango478.img

KaMango481.img

KaMango483.img

KaMango485.img

The bug exists from Kappa 1.4 but it doesn't exist on 1.3 ... It's confirmed ...

How to get rid off the bug ...

1.)Flash a bugless kernel like Radeon or Mesa or Lupus.....

2.)Thats it ...

Also the converse is true .If you flash a kernel with that bug the bug continues to persist

Also Kernel Panic has the same bug ...

According to dmesg the problem lies in i2c or in the battery driver

100% is a result of this calculate_scaled_capacity

if (cs->capacity_to_scale[0] != cs->capacity_to_scale[1])
capacity = min(100,
(bd->curr_capacity * cs->capacity_to_scale[0] +
(cs->capacity_to_scale[1] >> 1)) /
cs->capacity_to_scale[1]);

But it could also be issue in the bus

sm_i2c msm_i2c.0: (00aa) Error during data xfer (-5)

The exact error code lies in 649-659 of bq27520_battery.c

static int bq27520_read_it_enabled(struct bq27520_data *bd)
{
s32 rc;

if(debugPatchMode) return -EIO;

if (bq27520_check_if_sealed(bd)) {
rc = bq27520_unseal(bd);

if (rc) {
dev_err(&bd->clientp->dev,
"Failed unseal when checking IT Enable. rc=%d\n", rc);
return rc;
}
}

mutex_lock(&bd->data_flash_lock);
rc = bq27520_setup_to_read_df_class_block(bd,
REG_EXT_CMD_DATA_FLASH_CLASS_IT, 0x00);

if (!rc)
rc = i2c_smbus_read_byte_data(bd->clientp,
REG_EXT_CMD_BLOCK_DATA);

mutex_unlock(&bd->data_flash_lock);

return rc;
}[/HIDE]

which leads us to code on line 510

static int bq27520_unseal(struct bq27520_data *bd)
{
int rc;

if(debugPatchMode) return -EIO;

rc = bq27520_write_control(bd, SUB_CMD_ENTER_CLEAR_SEAL);
if (!rc)
rc = bq27520_write_control(bd, SUB_CMD_CLEAR_SEALED);
if (!rc)
rc = bq27520_write_control(bd,
SUB_CMD_CLEAR_FULL_ACCESS_SEALED);
if (!rc)
rc = bq27520_write_control(bd,
SUB_CMD_CLEAR_FULL_ACCESS_SEALED);

bd->sealed = (!rc) ? 0 : -1;

return rc;
}

I am at my wits end here

[MENTION=373657]kast[/MENTION]

Thats my limit .I cant think of anyway to solve/code since I have no idea why rc is assigned -5 or whether there is bus error ...

My overall contribution :The bug exists on all kernels from 1.4 onwards and Kernel Panic ..and the dmesg associated with the bug ...

Have a good day hopefully :victory: