Reply
Thread Tools
Posts: 1,680 | Thanked: 3,685 times | Joined on Jan 2011
#1111
Originally Posted by pali View Post
After discusion on #maemo with DocScrutinizer and ShadowJK we decided to disable one i2c patch which break API and can damage n900 (patch was added in v45). When this patch is disabled - bme is broken when bq modules is loaded.

So autoloading bq module is disabled too and now is not possible to have both bme and bq. (bq module is still installed so after stopping bme is possible to manually load it).

Now I recompiling v48 and publish new version as soon as.
aww man, I was just getting into the bq27x00 'true' capacity readout.

I ask that joerg please explain what exactly the problem is with bq + bme simutaneously.

No seriously, I know I2C. WTF is the damage?
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
 

The Following User Says Thank You to vi_ For This Useful Post:
Posts: 2,153 | Thanked: 8,462 times | Joined on May 2010
#1112
 
Posts: 105 | Thanked: 49 times | Joined on Jul 2011
#1113
pali i have been using bme + bq since the day bq was released
and i'm having no problems
and i expect no problems
 
TMavica's Avatar
Posts: 2,021 | Thanked: 1,060 times | Joined on Apr 2010 @ Hong Kong
#1114
updated new version
 
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#1115
// Edit - scratch that, I reconsidered this and I was wrong here. I'm not deleting it, to not cause context havoc with posts after it

With all due respect, I also never-ever encountered any problems with bq and bme working simultaneously, and every complain about wrong "battery things" (that I've heard ago), and someone suggested it may origin in bq and bme "hostility" (cause no one got better ideas), resulted in fixing it by other means. I.e it was *not* confirmed.

I understand rationale behind requiring to drop this path - i.e. meritocratic arguments. Ho ever, I think that there is another factor we are not aware of, because in *reality* no one experienced such a problems. If I'm wrong, please point me to *confirmed* report, about it producing strange results in N900.

Sorry, but for me it's not enough to disable path in mainstream and make any people life harder, by need to recompile own version/use older version/whatever. I'll be 100% backing up removal of this, if anyone, ever, encounter even smallest glitch *confirmed* to be due of bq and bme working simultaneously in N900, due to mentioned i2c path.

Disclaimer - I really do not attack people reporting this, cause I respect ShadowJK and joerg_rw (apparently, DocScrutinizer in irc) *very* much - without any irony in that sentence, really. Ho ever, it's little strange, to read that ShadowJK never dare to use kernel-power and CSSU, but is sure that it *can't* work, and joerg_rw know (for good reasons, I admit) that it may bring harm... But, no one ever heard about such a harm on N900.

Do we *really* know about closed source bme behavior enough, that we're 100% sure there isn't any other factor - hidden from our "eyes" - that exludes such possible problems? If yes, how can anyone explain, that for such long time of bq module being loaded at boot, there is no single confirmed problem report?
// Edit - scratch that, I reconsidered this and I was wrong here. I'm not deleting it, to not cause context havoc with posts after it
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!

Last edited by Estel; 2011-07-29 at 21:11.
 

The Following User Says Thank You to Estel For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#1116
Not really that useful.. but I can "confirm" that BME + BQ has caused no problems for me (with 46 and now 47).

A few days ago during a clean-up I uninstalled AP and blacklisted BQ, because I wanted to simplify things, and I've always been happy with the battery values reported by BME.

But in any case, BQ never caused a problem for me.
 
Posts: 178 | Thanked: 91 times | Joined on May 2011 @ Mira (Venice) - Italy
#1117
I just re-flashed the N900 and I installed kernel-power v48 ... If you want I can do some tests ...
 
Posts: 1,680 | Thanked: 3,685 times | Joined on Jan 2011
#1118
...basically this patch seems to allow two processes access the same register in same chip on same I2C bus concurrently, which can never work but is happening rarely but definitely *will* happen eventually. This can cause any arbitrary problem, from garbled transmission on I2C bus causing chip malfunctions and breakage, to kernel panics or whatever...
joerg_w here explains the reasoning behind the problem with the I2C patch. While I do understand where he is coming from I am unconvinced that a multi-read or multi write operation being performed by a process would have a 'relinquish to scheduler' in the middle of writing/reading multiple bytes on the I2C bus. Well, I certainly wouldn't but fck knows what happens inside bme, in addition to this joerg_w does know what he is talking about.

How would you identify a confirmed case of I2C collision? A random reeboot here? A funny battery percent for a couple of seconds there? The fact is, there could be collisions occurring more often than we think.

What I would like is for battery charging to be taken over by either bq module (perhaps not the right place) or some replacement for BME. Apart from handling charging and updating HAL with some erroneous data it doesn't really do much else that I can want.
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.

Last edited by vi_; 2011-07-29 at 10:43.
 

The Following 2 Users Say Thank You to vi_ For This Useful Post:
Posts: 178 | Thanked: 91 times | Joined on May 2011 @ Mira (Venice) - Italy
#1119
Camera Error I don't know if is the KP or something else
http://talk.maemo.org/showthread.php...56#post1060456
 
Posts: 151 | Thanked: 93 times | Joined on Sep 2009 @ sofia, bulgaria
#1120
Hi all,

I'm trying to implement Application level filtering.

I found out that it could be achieved with iptables.

So this is a sample rule that should deny acroread program to use network:

iptables -A OUTPUT -m owner --cmd-owner acroread -j DROP


The problems is that it does not work on maemo with KP48.

iptables -A OUTPUT -m owner --cmd-owner acroread -j DROP
iptables v1.4.6: unknown option `--cmd-owner'
Try `iptables -h' or 'iptables --help' for more information.

I read that this CONFIG_IP_NF_MATCH_OWNER has to be on in the kernel. Is it on for KP48?


EDIT: I saw that cmd-owner is removed from current version. Is there an alternative to it?

Last edited by lidow; 2011-07-29 at 13:48.
 
Reply

Tags
battery-status, bq27x00_battery, kernel, kernel-power, misiak4king, noobs-cant-read, pali4president, patches, readdirections, revolverspinyou


 
Forum Jump


All times are GMT. The time now is 11:32.