sicelo | i think you should not remove those extra patches | 05:18 |
---|---|---|
sicelo | "we dont have an equiavlent to 0005-kernel-dma-workaround-n900-modem-oops.patch" -- https://github.com/IMbackK/droid4-linux/commit/5259a862010ee65366db1a2ad7427b0686ab7443 | 05:24 |
sicelo | could the n900-61 branch not have been in maemo-leste namespace? i think it would help so we don't have to wonder where stuff like https://github.com/maemo-leste/droid4-linux/commit/7c2221dca56dca6d711f89ad635a8fbc5f5a91ab came from | 05:28 |
sicelo | wut! i have h-d now. nothing i did however | 05:38 |
sicelo | oh, there *is* something i did ... i used the N900 that has b0rk modem. using the one with working modem results in the reset. Wizzup, so it's what i mentioned the other day - the dma patch isn't enough in 6.1 unfortunately ): | 05:56 |
sicelo | i wonder what we need to do in order to enable/use pstore on N900? maybe use the 'log' partition on the OneNAND? freemangordon, would you have an idea? | 06:07 |
SuperMarioSF | hi | 06:12 |
SuperMarioSF | long time no see | 06:12 |
SuperMarioSF | about two phones, I'm unable to get another one on good condition. | 06:13 |
SuperMarioSF | so should I ship the existing one? | 06:13 |
sicelo | what phones are you referring to? :-/ | 06:16 |
SuperMarioSF | The Chinese exclusive Motorora Milestone 3 (XT883) | 06:17 |
SuperMarioSF | I was planned to get 2 of them | 06:17 |
SuperMarioSF | but I have only got one in good condition, full of everything. | 06:18 |
SuperMarioSF | images will be sent here soon. | 06:22 |
SuperMarioSF | woah | 06:27 |
SuperMarioSF | i got lucky | 06:27 |
SuperMarioSF | just found another one in good condition | 06:27 |
SuperMarioSF | the one for months | 06:27 |
SuperMarioSF | and for a similar price as th first one | 06:28 |
sicelo | oh great, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/pstore-blk.rst ... this could work for N900 | 06:40 |
Wizzup | well, missed SuperMarioSF :) | 09:53 |
Wizzup | sicelo: well cherry-picking reverts doesn't work well | 09:54 |
Wizzup | you need to re-do the revert | 09:54 |
Wizzup | maybe this is also what uvos did with the memory compaction commit, seeing he made a leste-config PR instead of reverting, but if it works... | 09:55 |
sicelo | i also tried revert. did the same thing iirc. but i can try again when i find time (this week hectic though) | 10:22 |
Wizzup | I can do it a few days from now if you bug me | 10:25 |
sicelo | ok. i guess it's a bit urgent since the kernel is already out (in -devel, of course) | 10:29 |
Wizzup | sicelo: right, maybe we should use -experimental for unstable kernels | 10:37 |
Wizzup | @supermariosf - drop me a msg for sending it | 10:39 |
buZz | hehe with the 2250mAh , it takes almost 2hrs to charge from 0% to full | 13:03 |
buZz | even at 1.5A inputcurrent | 13:04 |
buZz | but seems to work superwell, hope the videos etc are all well taken, we'll edit all the material soon | 13:04 |
uvos__ | so did you edit the eeprom? | 13:19 |
buZz | i didnt try yet | 13:21 |
tmlind | uvos__: i don't think the battery eeprom can be updated? | 13:33 |
buZz | would seem weird to me too, you'd be able to 'explode' ppls batteries | 13:36 |
buZz | by overwriting with wrong stuff, once you have root | 13:36 |
uvos__ | tmlind: no idea, i was just asking buZz to see if so | 13:40 |
uvos__ | its not impossible that its really a eeprom instead of a prom | 13:40 |
buZz | hmhm, i'll try later anyway | 13:40 |
tmlind | forgot what the chip on the battery pcb is, but i recall it says on the chip and has a public doc available, some ds something i think | 13:43 |
buZz | isnt that the gauge chip? | 13:44 |
buZz | i have a loose BMS now (ripped the flex connector) i can take closeups later | 13:44 |
tmlind | ok, looks like i have a pdf named DS2450.pdf along with my notes, maybe that's it | 13:46 |
tmlind | https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/177.html | 13:53 |
tmlind | seems to require 12v controller to reprogram? | 13:53 |
freemangordon | buZz: set input current to 1800 | 14:07 |
freemangordon | (assuming your charger allows that) | 14:08 |
buZz | freemangordon: oh i'll try later, is that the max? afaik this usb wallwart can do 2.5A | 14:10 |
buZz | also, its limit is on the current to battery | 14:10 |
buZz | so 1000000 on the device is 900000 on wallwart, or sim ilar | 14:11 |
buZz | similar* | 14:11 |
freemangordon | the max(according to specs) is unlimited, but I don't think this can be set | 14:15 |
freemangordon | also, 1800 is what android sets | 14:15 |
freemangordon | and later on adjusts, somehow | 14:15 |
freemangordon | the limit shall be set on the charger | 14:16 |
freemangordon | don;t touch the battery | 14:16 |
freemangordon | I think it has 1200mA constant current setr | 14:16 |
uvos__ | i think buZz is asking what is cpcap max charge current | 14:25 |
uvos__ | iirc this is just under 2.5A | 14:26 |
buZz | ah cool, thats about 1C charging for this 2250mAh | 14:27 |
buZz | it does accept 2500000 as limit , anyway | 14:33 |
uvos__ | i gues theoreticly anthing motorola dident use isent validated thermally | 14:36 |
uvos__ | so maybe watch out with that @ using full current cpcap can do register wise | 14:36 |
uvos__ | but im sure its really fine | 14:37 |
Wizzup | freemangordon: https://github.com/maemo-leste/dsme/pull/6 | 14:42 |
Wizzup | care to check? | 14:42 |
BlagovestPetrov[ | https://hastebin.com/omuyitacaj.coffeescript Wizzup | 15:29 |
BlagovestPetrov[ | there is something with the l10n packages | 15:30 |
BlagovestPetrov[ | nvm, it happened because osso-applet-display has broken dependencies. l10n packages are fine | 15:31 |
BlagovestPetrov[ | freemangordon: hildon-desktop is also failing because of gcc flags | 17:06 |
BlagovestPetrov[ | it's using Tidy which is a wrapper library on top of Clutter | 17:07 |
BlagovestPetrov[ | there are some inline functions which are too bit for the standard gcc settings. | 17:07 |
BlagovestPetrov[ | should we ignore the warning? | 17:07 |
BlagovestPetrov[ | or we can convert them to standard functions. It may cause performance issues.. | 17:08 |
freemangordon | Wizzup: looks good | 17:20 |
freemangordon | BlagovestPetrov[: how exactly it is failing? | 17:21 |
freemangordon | buZz: not really, the real limit is 1800 | 17:22 |
freemangordon | anything above that is still 1800 | 17:22 |
BlagovestPetrov[ | https://hastebin.com/daziviwuho.yaml | 17:23 |
freemangordon | buZz: https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1/drivers/power/supply/cpcap-charger.c#L307 | 17:23 |
BlagovestPetrov[ | https://hastebin.com/ixoleravax.properties this is the function :) | 17:25 |
freemangordon | WTF is max-inline-insns-single ? | 17:25 |
BlagovestPetrov[ | something which limits the size of the inline functions | 17:27 |
freemangordon | BlagovestPetrov[: try if -finline-limit=1000 will fix it | 17:27 |
BlagovestPetrov[ | I'm not sure what "size" means - memory utilized? | 17:27 |
BlagovestPetrov[ | or cpu time? | 17:28 |
freemangordon | the number of pseudo-instructions IIUC | 17:28 |
BlagovestPetrov[ | it will probably fix it. I'll try :) | 17:28 |
freemangordon | but, I wonder why we hit that now | 17:28 |
freemangordon | this is not something new | 17:29 |
buZz | freemangordon: tried abit, havent seen it draw over 1.2A from charger | 17:31 |
buZz | but still pretty full now | 17:31 |
freemangordon | that's why | 17:31 |
buZz | uhuh | 17:31 |
freemangordon | on empty battery it will draw 1200+device usage | 17:31 |
buZz | ah, like that , yeah, we'll see later :) | 17:32 |
freemangordon | BlagovestPetrov[: maybe older compiler issued less instructions? | 17:32 |
BlagovestPetrov[ | yeah | 17:32 |
freemangordon | but maybe you are right and this function shall not be marked as inline | 17:33 |
freemangordon | now it saves one call I guess | 17:33 |
BlagovestPetrov[ | :) | 17:46 |
freemangordon | yup, just remove that inline and call it a day | 17:48 |
SuperMarioSF | I'm back | 18:35 |
SuperMarioSF | Just replaced a new battery in my droid 4, battery life and charge speed seems much better than before. | 18:38 |
SuperMarioSF | recalibrating battery | 18:39 |
SuperMarioSF | just found some weird thing about the APN provision issue | 18:39 |
SuperMarioSF | I have a dead SIM card, which have no subscription any more on it, but card itself works. | 18:40 |
SuperMarioSF | It can provision its APN correctly, first try | 18:40 |
SuperMarioSF | but when I swap to my daily driving SIM card, 3G signal seems okay but APN provisioning have problem | 18:41 |
SuperMarioSF | two SIM card are for GSM based network, but have different operator. | 18:41 |
SuperMarioSF | maybe there is some weird issue related to China Unicom's SIM card. | 18:42 |
SuperMarioSF | but for now, just receieving SMS is already working enough for me, and character encoding is correct. | 18:43 |
SuperMarioSF | if anyone want to dig deeper on this issue just contact me. | 18:44 |
SuperMarioSF | I currently have no idea about this problem and I don't have much spare time to read the source code myself. | 18:44 |
SuperMarioSF | and that's the reason why I didn't shown for a long time, because my work is too busy. | 18:45 |
Wizzup | hi | 18:53 |
SuperMarioSF | hi | 18:53 |
Wizzup | SuperMarioSF: send you a private message btw | 19:05 |
Wizzup | uvos: I built leste-config | 19:05 |
Wizzup | freemangordon: thanks for checking | 19:11 |
BlagovestPetrov[ | SuperMarioSF: dragast? | 19:16 |
BlagovestPetrov[ | oh, no. I though you are someone else :) | 19:18 |
SuperMarioSF | i have no idea what or who dragast is. | 19:18 |
Wizzup | heh | 19:19 |
Wizzup | BlagovestPetrov[: I see how that happened :D | 19:19 |
Wizzup | SuperMarioSF: nevermind, someone we know | 19:20 |
uvos | SuperMarioSF: both me and i think buZz too have had that issue with the apn | 20:15 |
uvos | so its not that operator specificly but rather lots of operators | 20:15 |
SuperMarioSF | that's weird | 20:15 |
SuperMarioSF | since the working SIM card was for a "virtual operator" | 20:16 |
SuperMarioSF | which shouldn't in any of pre-defined list. | 20:16 |
SuperMarioSF | and that operator name were shown correctly | 20:17 |
SuperMarioSF | so is there a way to define a operator information manually? | 20:17 |
SuperMarioSF | or even better, an option for forcing (for debug or workaround purpose) | 20:18 |
uvos | theres a dbus call | 20:18 |
uvos | i dont remebmer it by heart | 20:18 |
uvos | Wizzup: knows | 20:18 |
SuperMarioSF | you mean something like 'mdbus2 -s org.ofono /motmdm_0/context1 org.ofono.ConnectionContext.SetProperty Active true' ? | 20:19 |
uvos | well not that one | 20:19 |
uvos | but a dbus call | 20:20 |
SuperMarioSF | ok | 20:20 |
uvos | i switched operators so i dont need it anymore | 20:20 |
uvos | so wait for Wizzup to respond | 20:20 |
SuperMarioSF | well I don't have much choice. | 20:20 |
uvos | dose sending sms work for you? | 20:20 |
SuperMarioSF | the only other operator doesn't even have 3G any more. | 20:21 |
uvos | it dosent for me | 20:21 |
SuperMarioSF | SMS is working fine. | 20:21 |
SuperMarioSF | and I just got bombed with SMS an hour ago. | 20:21 |
uvos | outgoing | 20:21 |
uvos | on my device incomeing sms works fine but outgoing just hang in ofonos send buffer | 20:21 |
SuperMarioSF | just tested | 20:23 |
SuperMarioSF | working | 20:23 |
SuperMarioSF | my first message went to conntest loopback | 20:23 |
SuperMarioSF | and I switched to ofono, it works. | 20:23 |
uvos | probubly i should unload contest in the default configureation again | 20:24 |
SuperMarioSF | the only operator have HSDPA support in China is China Unicom, so switching to another operator is out of question, except virtual operators (which is often unreliable) | 20:27 |
uvos | sicelo: im rebuilding the kernel with the extra pmos patches now | 20:40 |
uvos | ill try to test it later | 20:40 |
uvos | Wizzup: please do test and get some serial if issues persit | 20:40 |
uvos | persist | 20:40 |
sicelo | those will not fix the problem, unfortunately | 20:47 |
uvos | freemangordon: found the issue with charging_sdl | 21:17 |
uvos | freemangordon: there was a bug in it that caused it to missread the battery when its _callibrated_ | 21:18 |
uvos | apperantly the changes in cpcap-battery ment its callibrated more often when charging_sdl starts | 21:18 |
uvos | its fixed, was a boolean inversion | 21:18 |
freemangordon | uvos: ah, so there was a bug after all? great that you smashed it, will test as soon as I can. | 21:22 |
uvos | freemangordon: yeah i was looking at the estimation code path so hard i just dident see it | 21:23 |
uvos | it will be in the repo asap | 21:23 |
freemangordon | ok | 21:28 |
uvos | ill also make it use sw rendering | 21:29 |
uvos | hopefully removing the hang | 21:29 |
uvos | just a workaround ofc | 21:29 |
uvos | im testing that rn | 21:29 |
freemangordon | never had hangs here | 21:29 |
freemangordon | but yes, we don;t need GPU | 21:29 |
uvos | it hangs in a drm ioctl and pvrk sometimes complains about a zero sized surface | 21:31 |
uvos | (cant make it happen rn) | 21:31 |
uvos | yeah dont really need the gpu here anyhow | 21:31 |
uvos | but maybe its related to the xorg hang in some helpfull way | 21:31 |
Wizzup | uvos: what dbus call do you mean | 21:45 |
uvos | Wizzup: giveing ofono apn | 21:45 |
Wizzup | probably just GetProperties on the ConnectionContext | 21:45 |
uvos | you set the apn with GetPorperies | 21:46 |
uvos | interesting | 21:46 |
uvos | :P | 21:46 |
Wizzup | SetProperty AccessPointName ... | 21:50 |
Wizzup | but GetProperties call will give you the exact property names | 21:50 |
uvos | Wizzup: ok, its not for me but for SuperMarioSF | 21:51 |
uvos | SuperMarioSF: ^^^ | 21:51 |
Wizzup | freemangordon: if you merge a PR for chimaera, can you please add it here: https://github.com/maemo-leste/bugtracker/issues/644 | 22:35 |
buZz | freemangordon: now on 50%, charger doesnt see >1.5A draw | 23:41 |
buZz | so i guess 1500000 for input limit is pretty much the limit? | 23:41 |
buZz | ever so briefly ; POWER_SUPPLY_CURRENT_NOW=1580000 | 23:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!