| 00:41.55 | *** join/#maemo-ssu RST38h (marat@wsip-184-180-40-182.ri.ri.cox.net) |
| 00:42.24 | RST38h | .join #maemo |
| 00:43.15 | *** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 02:15.35 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 03:59.44 | *** join/#maemo-ssu mickname (mickname@low6.kyla.fi) |
| 05:44.59 | ototo | FatPhil: what about "Linaro's" powertop? |
| 05:45.32 | ototo | Oh, the kernel is different, right... |
| 05:46.59 | FatPhil | ototo: I presume Linaro's is based on Intel's, and is x86-based? |
| 05:47.27 | freemangordon | morning |
| 05:48.09 | freemangordon | FatPhil: please tell me about the bug you think you found in KP, I can't sleep :D |
| 05:50.25 | FatPhil | arse, my laptop went flat again lsat night, and I was so tired when I got home, I forgot to plug it in again... |
| 05:50.56 | freemangordon | FatPhil: which patch is buggy? |
| 05:51.18 | FatPhil | it's 2 lines of code being commented out. |
| 05:51.41 | FatPhil | however, it leaves the controllign 'if', which then acts upon the return statement that follows |
| 05:51.51 | FatPhil | rather than the lines that were commented out |
| 05:52.34 | FatPhil | OK, have enough juice to power up... |
| 05:52.42 | freemangordon | good :) |
| 05:54.15 | FatPhil | power-supply-no-verbose.diff |
| 05:55.27 | FatPhil | The correct patch is to just remove the whole if. |
| 05:55.49 | FatPhil | Don't comment code out - we have version control systems for remembering old versions. |
| 05:56.27 | freemangordon | FatPhil: hmm I guess Pali commented that out while being sleepy :) |
| 05:56.37 | freemangordon | is going to look at the patch |
| 05:59.14 | freemangordon | FatPhil: hmm, I am not sure this is not done on purpose. Still, it is ugly |
| 05:59.49 | freemangordon | oh, wait, this can't be on purpose |
| 05:59.55 | freemangordon | yep, definitely a bug |
| 06:00.23 | freemangordon | which will bite Pali's ass in case of ENODEV |
| 06:03.00 | FatPhil | if you give me a couple of email addresses, I'll send my changes for review |
| 06:03.07 | FatPhil | Just written a quick patch |
| 06:03.45 | FatPhil | and fucking git decides to do a garbage collect just as I'm in a rush... |
| 06:04.22 | freemangordon | FatPhil: pali.rohar at gmail.com, freemangordon at abv.bg |
| 06:06.36 | freemangordon | FatPhil: did yo utake a look at big patches like dsp backport and smartreflex fixes? |
| 06:07.04 | ototo | FatPhil: LinARo (ARM) |
| 06:08.23 | FatPhil | freemangordon: not got to the DSP one yet. Don't remember the smartreflex one. |
| 06:08.31 | freemangordon | ototo: are sources available online? |
| 06:08.49 | FatPhil | Quoth nokia auto-responder: "Please note that only written requests are accepted. We do not reply to requests by e-mail." |
| 06:09.19 | freemangordon | FatPhil: Pali did that a week or so ago(wrote an email) |
| 06:09.47 | freemangordon | we had a good fun when he received the "maemo sources) :D |
| 06:10.24 | freemangordon | he received a dvd image, which contains CD image, which contains .debs from repository.maemo.org :D |
| 06:14.34 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 06:14.38 | FatPhil | uuencoded |
| 06:14.46 | ototo | freemangordon: sure, git.linaro.org. On technical details I'd suggest contacting sanjayr or amitk on #linaro-big.little |
| 06:15.21 | FatPhil | I have links inside Linaro too (chatting to 2 of them occasionally on IRC) |
| 06:15.27 | FatPhil | both are very cooperative |
| 06:15.51 | ototo | FatPhil: you have +1 link ;) |
| 06:15.58 | ototo | ! |
| 06:16.06 | freemangordon | ototo: I will take a look at it, though I think in "our" powertop there are some Nokia-made changes to fit with the kernel changes |
| 06:17.07 | FatPhil | Cool. |
| 06:17.12 | FatPhil | mail on its way... |
| 06:17.14 | freemangordon | hmm, this is intel powertop |
| 06:17.29 | freemangordon | https://git.linaro.org/gitweb?p=tools/powertop-2.0.git;a=tree;f=src/cpu;h=e1e37b1bb3607ae819e8b5301fd2198ebb90f395;hb=HEAD |
| 06:18.12 | freemangordon | FatPhil: thanks! |
| 06:22.49 | FatPhil | intel_cpus.{h,cpp} |
| 06:23.48 | ototo | https://cards.linaro.org/browse/PMWG-19 |
| 06:24.07 | ototo | I assume it works on ARM :) |
| 06:24.48 | FatPhil | "You must log in to access this page." |
| 06:25.21 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 06:25.46 | FatPhil | nokia's powertop is a fork of intel's 1.12 version, which bit-by-bit had everything intel removed from it. |
| 06:25.59 | FatPhil | So a binary scanner won't detect any GPL code in it. |
| 06:26.25 | FatPhil | Anyway, I need to find a rift in time and space, so that I can be at work hald an hour ago... |
| 06:29.03 | freemangordon | heh, same here :) |
| 06:29.38 | freemangordon | though I have to run as I have a meeting in 30 mins |
| 06:34.33 | ototo | Oh, sorry, that link will become public most likely this week. Apologies. |
| 06:35.15 | ototo | Basically it's about keeping powertop 2.0 working on ARM |
| 06:42.32 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 07:16.39 | FatPhil | Is there a way to query the modem and find out what mobile networks are visible to it? |
| 07:16.53 | FatPhil | PLMN? |
| 07:18.16 | FatPhil | That's brought back memories of a job I had in about 1998, when I wrote the code to take the list from the modem, and pass it to the application layer. Woh, I've forgotten almost everything! |
| 07:21.47 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 07:29.48 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 07:29.51 | *** join/#maemo-ssu n900-dk (~kgu@freebox.dk) |
| 08:05.46 | *** join/#maemo-ssu kolp (~quassel@212.255.29.151) |
| 08:10.23 | *** join/#maemo-ssu FlameReaper (~assassin@183.171.165.53) |
| 08:23.23 | *** join/#maemo-ssu Pali (~pali@2001:718:1e03:a01::1ca) |
| 08:24.49 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 08:26.04 | *** join/#maemo-ssu Pali_ (~pali@Maemo/community/contributor/Pali) |
| 08:32.02 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-125-57.net.upcbroadband.cz) |
| 08:57.25 | freemangordon | Pali: hi, did you see the mail from FatPhil? the patch for bq .ko |
| 09:04.58 | FatPhil | ototo: does your PMWG link differ much from https://blueprints.launchpad.net/linaro-powertop/+spec/ensure-powertop-2.0-runs-on-arm |
| 09:06.06 | FatPhil | My signed-off-by line needs changing!!!! I ain't been at nokia for a long time |
| 09:06.49 | ototo | FatPhil: we're migrating to JIRA and JIRA version is basically the same at the moment, but not yet made public |
| 09:08.17 | FatPhil | Erm "09:15 < ototo> FatPhil: you have +1 link ;)" - not! you already were one of my links you silly chappy! |
| 09:09.50 | ototo | :> |
| 09:09.56 | ototo | -> lunch |
| 09:13.14 | FatPhil | What's the root of this problem: "udev does not working with separate /usr and /" |
| 09:13.45 | FatPhil | IMHO, udev shouldn't care. A udev that does care is braindead. |
| 09:16.45 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 09:26.27 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 09:41.53 | *** join/#maemo-ssu handaxe (~communi@m176-70-44-115.cust.tele2.se) |
| 09:50.38 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 10:06.47 | Pali | freemangordon: I got that mail |
| 10:06.59 | Pali | is not that patch in cssu? |
| 10:07.24 | FatPhil | Pali - patch in CSSU has dangling if statement |
| 10:07.35 | FatPhil | which then grabs the return |
| 10:10.52 | Pali | FatPhil: ok, now I see where is problem |
| 10:11.29 | Pali | FatPhil: you are still in nokia that you used nokia address? |
| 10:12.54 | FatPhil | I sent that mail from a machine that I used to use when I worked from home, and I've not set the defaults back to something sane since I left nokia. |
| 10:14.18 | FatPhil | (And in fact I suspect that I never even used that machine for sending patches anyway - as it din't have the git-email package installed) |
| 10:16.21 | FatPhil | In fact the mail settings are completely fucked. I've not used "fatphil@..." as my email address for years, I prefer just "pc" now, |
| 10:19.33 | FatPhil | Pali: regarding http://talk.maemo.org/showpost.php?p=1334283&postcount=59 "mce, dsme and HAL not working (all daemons run at 100% CPU)" - I'm pretty sure I know what the problem is - it needs source changes to the userspace packages though. |
| 10:20.05 | Pali | FatPhil: changes to mce, hal and dsme? |
| 10:20.14 | Pali | or other sources? |
| 10:20.28 | FatPhil | whatever's thrashing the CPU |
| 10:20.39 | FatPhil | it's doing a poll() with the wrong flags. |
| 10:20.57 | FatPhil | Kernel's API changed in 2.6.29. |
| 10:21.30 | Pali | hal and dsme are open, so this can be fixed in cssu... |
| 10:21.34 | Pali | but what with mce? |
| 10:21.48 | Pali | do you know how to fix poll()? |
| 10:21.59 | Pali | which flags needs to be fixed? |
| 10:22.19 | FatPhil | calls need the PRI flag added, IIRC. |
| 10:22.48 | FatPhil | A virtual file always has data, so POLL_IN always returns immediately |
| 10:23.26 | FatPhil | We went over this roadbump in the HArmattan days. I was the guy who filed all the bugs against userspace! |
| 10:24.09 | Pali | FatPhil: nice |
| 10:24.17 | Pali | so there is already patch for dsme and hal? |
| 10:25.16 | FatPhil | I don't know how closely related the n9 versions are to the n900 versions. |
| 10:25.23 | FatPhil | but the n9 versions ahve the fix |
| 10:27.23 | Pali | n9 version of dsme is very different |
| 10:44.59 | Pali | FatPhil: do you have patches/commits for dsme or other daemons used in n9? |
| 10:45.18 | Pali | freemangordon: ping |
| 10:48.08 | Pali | FatPhil: I commited your kernel patch to kernel-power git repository on garage.maemo.org |
| 10:56.26 | *** join/#maemo-ssu FlameReaper (~assassin@173.160.48.60.kmr03-home.tm.net.my) |
| 11:01.02 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 11:02.30 | FatPhil | Pali: I don't remember having any userspace apart from powertop. There might be something hiding inside my scratchbox, but I've forgotten how to use that. I'll have a peek this evening when I'm home |
| 11:03.37 | Pali | FatPhil: ok, let me know... fixing these userspace bugs will be usefull for running upstream kernel on n900 |
| 11:07.30 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 12:11.00 | *** join/#maemo-ssu arcean (~arcean@aael230.neoplus.adsl.tpnet.pl) |
| 12:37.47 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 12:55.57 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 13:15.14 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 13:24.11 | *** join/#maemo-ssu arcean (~arcean@aael230.neoplus.adsl.tpnet.pl) |
| 13:54.57 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 13:59.01 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 14:23.48 | DocScrutinizer05 | (([2013-09-04 08:06:36] <freemangordon> FatPhil: did yo utake a look at big patches like dsp backport and smartreflex fixes?)) ~sr |
| 14:34.02 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 15:08.46 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 15:16.16 | freemangordon | Pali: pong |
| 15:16.47 | Pali | freemangordon: did you remember problem with upstream 3.x kernel and non working gsm/3g stack? |
| 15:17.01 | freemangordon | Pali: on maemo? |
| 15:17.05 | Pali | yes |
| 15:17.27 | freemangordon | yep, I remember, but didn;t try to figure out what exactly is the problem |
| 15:18.00 | freemangordon | Pali: why do you ask? |
| 15:18.29 | Pali | I'm asking if you was able to find out why it not worked |
| 15:18.42 | Pali | now we know why hald/dsme/mce using 100% cpu |
| 15:18.42 | freemangordon | Pali: I didn't try |
| 15:18.51 | freemangordon | yeah :) |
| 15:18.54 | Pali | see chanlog |
| 15:19.04 | freemangordon | saw it |
| 15:19.30 | freemangordon | I guess we can fix that with some LD_PRELOAD |
| 15:19.37 | Pali | this, camera and telephony are problems which needs to be solved for using 3.x kernels on maemo |
| 15:19.57 | freemangordon | camera? |
| 15:20.07 | freemangordon | what is the problem with camera? |
| 15:21.58 | Pali | no drivers for 3.x kernels yet |
| 15:22.04 | Pali | no working drivers |
| 15:23.21 | freemangordon | oh, not good |
| 15:23.43 | freemangordon | Pali: on a side note - ke-recv is still not in cssu-devel :) |
| 15:23.53 | Pali | ok, I will push it |
| 15:23.55 | FatPhil | has anyone been mad enough to bisect the camera issues? |
| 15:24.17 | freemangordon | FatPhil: none I am aware of :) |
| 15:24.26 | freemangordon | but we'll have to do it someday |
| 15:25.00 | freemangordon | well, I guess my experience with porting the DSP driver will help a bit :D |
| 15:25.16 | Pali | FatPhil: camera problem is that there is no driver in upstream kernel |
| 15:25.26 | Pali | stack of 2.6.28 is different as in 3.x |
| 15:25.35 | Pali | and driver cannot be easy forward-ported |
| 15:25.39 | Pali | from 2.6.28 |
| 15:25.43 | freemangordon | Pali: hmm, there is a port |
| 15:25.47 | freemangordon | iirc |
| 15:25.51 | Pali | yes, there is port, but not working |
| 15:26.01 | Pali | it compiles, but thats all |
| 15:26.09 | freemangordon | missing board code? |
| 15:26.16 | Pali | no, eveyrthing is there |
| 15:26.20 | Pali | but it is not working |
| 15:26.27 | freemangordon | how did you test it? |
| 15:26.34 | Pali | mplayer |
| 15:26.42 | freemangordon | any error? |
| 15:26.44 | Pali | green/black screen |
| 15:26.47 | Pali | or some error |
| 15:26.49 | Pali | ioctl |
| 15:27.05 | Pali | I also used media-ctl to set configs |
| 15:27.09 | freemangordon | ok, I'll take care of that when it comes to it |
| 15:27.10 | Pali | noting helped |
| 15:27.25 | ShadowJK | same commandline works on 2.6.28? |
| 15:27.29 | Pali | in upstream kernel is only driver for fron webcam |
| 15:27.35 | Pali | but missing board data |
| 15:27.55 | ShadowJK | any difference with -vo x11 (in case it's Xv that's not working) |
| 15:28.07 | Pali | I used some provided by some developer but same problem, green/black screen or ioctl error |
| 15:28.23 | Pali | ShadowJK: no |
| 15:28.33 | Pali | there was also some errors in dmesg |
| 15:28.51 | Pali | kernel was unable to detect/compute some clks... |
| 15:28.58 | freemangordon | Pali: well, if it doesn;t work with stock, why do you expect to work with 3.x? |
| 15:28.59 | Pali | I do not remember exactly |
| 15:29.12 | FatPhil | maybe clock framework has changed |
| 15:29.17 | FatPhil | A bisect should identify that |
| 15:29.17 | Pali | freemangordon: with stock kernel camera working |
| 15:29.25 | freemangordon | FatPhil: not "maybe" |
| 15:29.54 | freemangordon | Pali: iirc we already have a problem with the clock framework been changed |
| 15:30.12 | freemangordon | we had to add some clock in the board code |
| 15:30.12 | Pali | yes I know, clk_prepare |
| 15:30.23 | freemangordon | :nod: |
| 15:30.31 | freemangordon | most probably it is the same |
| 15:30.34 | Pali | but this was fixed |
| 15:30.39 | freemangordon | same problem |
| 15:30.54 | FatPhil | what version of the kernel did you try to rebase to? |
| 15:31.05 | freemangordon | 3.2 iirc |
| 15:31.16 | Pali | https://gitorious.org/linux-n900/linux-n900 |
| 15:31.17 | freemangordon | that was me, pali tried 3.5 iirc |
| 15:31.21 | Pali | 3.8 |
| 15:31.23 | Pali | 3.9 |
| 15:31.26 | Pali | and 3.10 |
| 15:31.28 | freemangordon | oh, yes |
| 15:31.41 | ShadowJK | there"s also the weird multiplexer thing infront of the two cams, is that stuff in newer kernels? |
| 15:31.42 | freemangordon | wait, it was me to boot maemo with 3.5 :D |
| 15:31.45 | Pali | FatPhil: in gitorious is full tree with all my patches |
| 15:31.58 | freemangordon | Pali: my powervr backport? |
| 15:32.04 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-125-57.net.upcbroadband.cz) |
| 15:32.06 | Pali | I have it too |
| 15:32.08 | freemangordon | forward-port |
| 15:32.21 | freemangordon | is it in the tree? |
| 15:32.28 | Pali | yes |
| 15:32.33 | freemangordon | good |
| 15:32.47 | Pali | in 3.10 was problem because there is removed lot of procfs api |
| 15:32.53 | *** join/#maemo-ssu NIN101 (~NIN@p5DD282DA.dip0.t-ipconnect.de) |
| 15:32.56 | freemangordon | the bad news about that is that we won;t be able to use it on neo900 |
| 15:32.59 | Pali | and I commented lot of pvr code in 3.10 because of that |
| 15:33.13 | freemangordon | because of the newer sgx core |
| 15:33.44 | FatPhil | pah - 500 Server Error from https://gitorious.org/linux-n900/linux-n900/commits/a6d3bd274b85218bf7dda925d14db81e1a8268b3 |
| 15:33.59 | Pali | FatPhil: gitorious has some problems... |
| 15:33.59 | freemangordon | so we'll have to use either nemo or harm driver |
| 15:34.05 | Pali | try to clone git repo directly |
| 15:34.13 | Pali | $ git clone git://gitorious.org/linux-n900/linux-n900.git |
| 15:34.16 | freemangordon | FatPhil: or better said - gitorious is fubar for the last 2 weeks |
| 15:34.24 | Pali | and see branch v3.10-n900 |
| 15:34.57 | freemangordon | Pali: hmm, maybe FatPhil can help with Secure PPA API patch |
| 15:35.14 | Pali | it only needs some correct comments :-) |
| 15:35.20 | Pali | do you have link on lkml.org? |
| 15:35.31 | freemangordon | as it seems we'll have to send it to Linus for it to be upstreamed :D |
| 15:35.45 | freemangordon | I'll ask google |
| 15:36.18 | freemangordon | Pali: that one? https://lkml.org/lkml/2013/2/28/116 |
| 15:36.29 | DocScrutinizer05 | ~tell freemangordon about sr |
| 15:37.25 | Pali | ok, here is last version: https://lkml.org/lkml/2013/8/5/44 |
| 15:37.40 | freemangordon | DocScrutinizer05: hmm? |
| 15:38.10 | Pali | and here is second patch: https://lkml.org/lkml/2013/7/10/238 |
| 15:38.11 | DocScrutinizer05 | hmm? |
| 15:38.17 | DocScrutinizer05 | ~sr |
| 15:38.17 | infobot | [SmartReflex] >>Again, TI and we [Nokia] couldn't fix SmartReflex - we say memory corruption in front of our own eyes with that enabled, so we had to ship that disabled.<< |
| 15:38.37 | freemangordon | DocScrutinizer05: I was told thumb2 can;t be workarounded too, so what? |
| 15:39.00 | DocScrutinizer05 | so you weren't told that by Nokia and TI |
| 15:39.14 | freemangordon | wrong, there is a bug on BMO |
| 15:39.27 | freemangordon | and nokia stated it can;t be fixed/used |
| 15:39.45 | Pali | and here today is Dave responce: https://lkml.org/lkml/2013/9/4/225 |
| 15:40.34 | DocScrutinizer05 | and they been right, until you found that monitor call. what call you found for smartreflex that Nokia and TI didn't think of or simply didn't have available at the time they seen SR bugs? |
| 15:41.39 | freemangordon | DocScrutinizer05: what I found is that EVERY n900 I got data from, has EXACTLY the same EFUSE calibration values for OPP3-OPP5 |
| 15:41.57 | DocScrutinizer05 | mind you, you needed toolchain 4.7(?) to make thumb work |
| 15:42.29 | freemangordon | DocScrutinizer05: no, I needed binutils >= 2.20, but that is irelevant |
| 15:42.30 | DocScrutinizer05 | wow what a finding, I'm absolutely sure Nokia didn't know |
| 15:43.08 | freemangordon | thay just nothing to fix/workaround it, that's it |
| 15:43.16 | freemangordon | *they |
| 15:43.35 | freemangordon | DocScrutinizer05: not to say I don;t get it what we are arguing for |
| 15:44.26 | freemangordon | DocScrutinizer05: so far there is only 1 report that might be related to SR making a device unstable |
| 15:44.28 | DocScrutinizer05 | I challenge your claim that you found the fix for a bug you even don't know about |
| 15:45.10 | freemangordon | sorry, you lost me on that one. |
| 15:45.54 | freemangordon | TI somehow had screwed EFUSE calibration in the course of manifacturing those OMAPS |
| 15:46.07 | DocScrutinizer05 | uhuh |
| 15:46.21 | DocScrutinizer05 | and how is that causing memory corruption? |
| 15:46.30 | freemangordon | yep, there is no other sane explanation for those EFUSE values |
| 15:46.48 | freemangordon | DocScrutinizer05: if your CPU is undervolted, guess ;) |
| 15:47.09 | DocScrutinizer05 | I guess TI is savvy enough how to operate their CPU |
| 15:47.34 | DocScrutinizer05 | if they didn't find a fix for memory corruption then I simply doubt you found it |
| 15:48.18 | freemangordon | the poing here being - if EFUSE calibration value is wrong (which it is), SR will undevolt some CPUs too much, below the stable threshold |
| 15:48.32 | DocScrutinizer05 | some???? |
| 15:49.11 | freemangordon | after that happens, you might expect lots of funnty things to happen - including corrupted cacheline to be written to RAM |
| 15:49.21 | freemangordon | DocScrutinizer05: yes, some |
| 15:49.33 | DocScrutinizer05 | and you think TI and Nokia were too dull to patch kernel so it overrides any supposedly incorrect SR table? |
| 15:49.41 | freemangordon | SR EFUSE calibration is device (CPU) specific |
| 15:49.57 | DocScrutinizer05 | [2013-09-04 17:41:38] <freemangordon> DocScrutinizer05: what I found is that EVERY n900 I got data from, has EXACTLY the same EFUSE calibration |
| 15:49.58 | ShadowJK | Considering TI totally screwed up the memory controller on omap4, to the point that omap4 performed worse than omap3... TI messing stuff up wouldn't surprise me :) |
| 15:50.01 | freemangordon | DocScrutinizer05: it is waaay easier to just disable it |
| 15:50.28 | DocScrutinizer05 | that's bullshit |
| 15:50.37 | freemangordon | DocScrutinizer05: please, read what I write till the end |
| 15:50.40 | freemangordon | 18:41 <freemangordon> DocScrutinizer05: what I found is that EVERY n900 I got data from, has EXACTLY the same EFUSE calibration values for OPP3-OPP5 |
| 15:50.47 | DocScrutinizer05 | and an isnult to TI and Nokia, who claimed they were NOT ABLE to fix it |
| 15:52.02 | freemangordon | I am not trying to insult anyone |
| 15:52.33 | DocScrutinizer05 | you're basing your claim that you were the one who found the fix for that bug on assumptions like "TI and Nokia were too dull and/or toolazy to even consider doing what I did" |
| 15:52.34 | freemangordon | sr works on most of the devices running KP for almost an year |
| 15:53.10 | freemangordon | DocScrutinizer05: BTW where you got TI/Nokia statement from? |
| 15:53.47 | DocScrutinizer05 | yeah sure, data corruption is not anything you notice immediately and associate to SR being enabled when you see the fallout |
| 15:54.08 | DocScrutinizer05 | freemangordon: maybe I don't want to disclose where from I got it |
| 15:54.51 | freemangordon | well, please disclose to the extent you're allowed or want, what is the reason thay are unable to fix it |
| 15:54.55 | DocScrutinizer05 | attach a Lauterbach to a OMAP3 devel board and *then* check memory integrity under SR |
| 15:55.29 | DocScrutinizer05 | I have no further info on that. Maybe others here are willing to shed more light on it, maybe not |
| 15:55.56 | freemangordon | DocScrutinizer05: ofc there will be corruption if your calibration is fcked up |
| 15:56.03 | dos1 | well, I could suspect that except being dull and/or lazy, there's also enough time and/or money factor |
| 15:56.12 | freemangordon | that one too |
| 15:56.19 | DocScrutinizer05 | of course TI and Nokia didn't know about that¡ |
| 15:56.38 | dos1 | but that's just a small note from someone outside the discussion :P |
| 15:56.58 | freemangordon | DocScrutinizer05: point here being? why they didn;t fix thumb2? |
| 15:57.23 | DocScrutinizer05 | because they had no gcc4.7 at that time |
| 15:57.54 | DocScrutinizer05 | and maybe because TI patch not even been published in early stage of maemo5 development |
| 15:58.01 | freemangordon | gcc 4.7 is not needed, what you need is binutils 2.19 iirc |
| 15:58.14 | freemangordon | besides ARM errata workaround |
| 15:58.39 | DocScrutinizer05 | whatever is needed, you had to do an update since it's not even included in published maemo5 SDK |
| 15:59.25 | DocScrutinizer05 | so evidently it wasn't available to Nokia devels at time of early development, and thus they went for non-thumb |
| 15:59.26 | freemangordon | published Maemo SDK vmware inage comes with DEB_BUILD_OPTIONS=...,thumb |
| 15:59.29 | freemangordon | *image |
| 16:00.13 | DocScrutinizer05 | meh, discussions with you about that stuff always tend to end like discussing drug abuse with a junky |
| 16:00.19 | dos1 | isn't facebook widget compiled with thumb? |
| 16:00.23 | freemangordon | it is |
| 16:00.41 | freemangordon | not widget, but the underlying framework |
| 16:01.55 | ShadowJK | To be fair, neither side makes any actual technical arguments ;-) |
| 16:03.56 | ShadowJK | And it's not likely to be ever resolved, as the people with the technical expertise no longer have any interest in omap3, and probably don't remember enough detail anymore to be able to answer whether fixing up forgotten calibrations would have a chance to alter the performance and stability of sr |
| 16:05.13 | freemangordon | TBH I didn;t/don;t want to enter any lenghty discussions over SR right now. Just because I lack time. Will try to summarize what I know and will put it on a wiki page, so we can discuss it further |
| 16:06.38 | freemangordon | just one more thing - remember Nokia's statements re OC and USB host mode? |
| 16:07.03 | freemangordon | Both were classified as impossible, IIRC |
| 16:07.10 | DocScrutinizer05 | USB statement been absolutely correct |
| 16:07.21 | DocScrutinizer05 | OC statement been absolutely correct |
| 16:07.42 | DocScrutinizer05 | USB OTG still is impossible |
| 16:08.21 | DocScrutinizer05 | and OC still burns your CPU in no time, compared to nominal lifespan of device as designed by product requirement specs |
| 16:09.38 | DocScrutinizer05 | and original Igor Stopa(?) statement been "you must not lock CPU to 600MHz or it will die" |
| 16:10.29 | freemangordon | DocScrutinizer05: that's irrelevant, they said OC is IMPOSSIBLE. IIRC. Might be wrong as well, it was > 3 years ago |
| 16:10.38 | DocScrutinizer05 | in my book this implies that CPU even less can handle >600MHz |
| 16:11.08 | DocScrutinizer05 | nobody ever said OC is impossible. Or point me to that statement and I stand corrected |
| 16:11.55 | DocScrutinizer05 | if anything, Nokia said "OC *MUST NOt* be done" |
| 16:12.07 | ShadowJK | They forgot to consider whether cpu life is less than modem or usbport life anyhow ;-) |
| 16:12.11 | DocScrutinizer05 | not "cannot be done" |
| 16:12.21 | dos1 | ShadowJK: :D |
| 16:12.22 | freemangordon | will try to find it |
| 16:13.38 | DocScrutinizer05 | and no matter what they said, this doesn't change the fact that your supposed fix to SR is a fix to an assumed laziness, not anything else |
| 16:13.44 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 16:14.26 | ShadowJK | The "lock the cpu" thing is mostly because omap2 was so slow to enter/exit C3/C4, and so slow at changing frequencies, that the UI became about 10 times more reponsive if you locked the cpu to 400MHz.. The "lock frequency" apps were very popular in Chinook and Diablo, and Nokia wanted to make sure N900 wouldn't get as many "lock to 600" apps as iphone has fart apps |
| 16:14.29 | DocScrutinizer05 | it's not even *claiming* to fix the original root problem, since we been unaware of it |
| 16:16.23 | kerio | the only thing remotely close to memory corruption is some graphical glitches, that apparently happen even when SR is disabled |
| 16:16.32 | kerio | fmg's smartreflex WORKSFORME |
| 16:16.38 | kerio | on two N900s |
| 16:16.52 | DocScrutinizer05 | kerio: shut up please. WFM is BS |
| 16:17.02 | kerio | no, i'm fairly sure that it works for me |
| 16:17.07 | DocScrutinizer05 | you don't even know if it "works for you" |
| 16:17.40 | DocScrutinizer05 | I seem to recall quite a bunch of issue reports from your side recently |
| 16:18.00 | kerio | huh, my wifi? |
| 16:18.06 | kerio | it doesn't work under rescueOS either |
| 16:18.32 | DocScrutinizer05 | so what? |
| 16:18.43 | kerio | so... it's not smartreflex? |
| 16:19.07 | DocScrutinizer05 | that's implying the assumption about non-permanent damage from SR only being a true and certified one |
| 16:20.09 | DocScrutinizer05 | you have not even a good error vector analysis for your problems, how do you dare to claim they are unrelated to SR? |
| 16:21.35 | DocScrutinizer05 | have you verified that WiFi doesn't have a local EEPROM or NOR flash that occasionally gets currupted by bogus data when some driver freaks out thanks to SR? |
| 16:21.56 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 16:22.04 | DocScrutinizer05 | have you verified every single other of the bazillion possibilities how SR and your problem could be related? |
| 16:22.20 | kerio | nope, i have not |
| 16:22.29 | DocScrutinizer05 | please f* off with "WFM"! |
| 16:22.42 | kerio | i also haven't verified that my aunt's toaster is causing the wifi problem |
| 16:23.22 | DocScrutinizer05 | you simply lack the technical background to contribute anything meaningful to this discussion |
| 16:25.14 | Sc0rpius | :O |
| 16:28.08 | DocScrutinizer05 | sorry for sounding like a dick, but that "WFM" pattern is a recurring PITA since 10 years, since evrybody thinks they are experts |
| 16:29.18 | DocScrutinizer05 | WFM == watch f*cking moron |
| 16:29.31 | FatPhil | It's certainly possible that Igor Stoppa made some pronouncements about OC, and that would probably have been in 2009 @ MDC in Amsterdam? |
| 16:30.04 | DocScrutinizer05 | yes, sounds about right |
| 16:30.12 | FatPhil | kerio: I have, in a lab environment, seen memory corruption on some devices when SR was enabled. |
| 16:30.36 | FatPhil | It was a silicon quality issue, IIRC, and some devices were worse than others. |
| 16:30.36 | DocScrutinizer05 | here you are |
| 16:31.00 | DocScrutinizer05 | sure thing, for that class of problem |
| 16:31.49 | DocScrutinizer05 | did you consider modified Vcore and Vram for the OPPs? |
| 16:32.13 | FatPhil | I wasn't in the PM team |
| 16:32.18 | FatPhil | but I'm sure they did |
| 16:32.35 | DocScrutinizer05 | I am rather sure that team was savvy enough to consider that fix |
| 16:33.27 | FatPhil | I was only called onto the problem because one of the guys knew that I could interpret hex stack dumps, and solve logic problems. |
| 16:33.43 | FatPhil | Oh, yeah, the team was savvy. |
| 16:33.45 | DocScrutinizer05 | so verdict revised: SR still has potential to cause memory corruption, but odds are you got one of a batch with better silicon that doesn't show this problem |
| 16:34.54 | DocScrutinizer05 | but *generally* SR *can not get fixed* |
| 16:35.11 | DocScrutinizer05 | it _might_ work for you, or not |
| 16:35.35 | DocScrutinizer05 | odds are it probably will work |
| 16:36.37 | ShadowJK | has recently been experimenting with limiting cpu to 500MHz while he's at work and mostly listening to podcasts |
| 16:36.46 | FatPhil | and any conclusion that it seems to be working for you tells you *nothing* about any other device |
| 16:36.56 | ShadowJK | I wonder where the sweet spot would be |
| 16:37.21 | DocScrutinizer05 | but odds also are you blame the last SHR update when somethig goes haywire, though in fact you got a lemon with poor silicon and SR caused RAM corruption |
| 16:37.42 | DocScrutinizer05 | or even CSSU-Stable update |
| 16:37.53 | DocScrutinizer05 | or your toaster |
| 16:38.22 | DocScrutinizer05 | (the last one specially for kerio ;-D ) |
| 16:39.26 | FatPhil | he's the kind of person who overclocks his toaster, is he? Does that affect buttery usage? |
| 16:39.49 | DocScrutinizer05 | it makes life easier when your butter is cold |
| 16:40.03 | kerio | you just need to avoid heat issues so the bread doesn't get burnt |
| 16:40.16 | kerio | install a liquid nitrogen cooling system |
| 16:40.28 | kerio | coldest toaster ever |
| 16:40.59 | freemangordon | FatPhil: what I discovered re SR, is that calibrations in EFUSE, which are supposed to be different for every device, are acually the same |
| 16:41.10 | freemangordon | for frequencies - 500, 550, and 600 |
| 16:41.21 | DocScrutinizer05 | kerio: sorry! I went a bit upset. But honestly nobody on earth could tell the side effects of RAM data corruption |
| 16:42.27 | DocScrutinizer05 | freemangordon: so what? Nokia and TI decided they disable/block/discard SR anyway, so why should they take care about those efuse tables? |
| 16:42.35 | freemangordon | FatPhil: every N900 I got data from (I asked on TMO for users to provide their EFUSE values) have different values for OPP1 and OPP2 and same values for OPP3-Opp5 |
| 16:42.57 | kerio | DocScrutinizer05: i think his point is that he finds instability with the stock values but not with his corrected values |
| 16:43.16 | freemangordon | DocScrutinizer05: and why those are different for OPP1 and Opp2? why are those programmed even? |
| 16:43.24 | DocScrutinizer05 | quite possible but largely unrelated to the original issue |
| 16:44.29 | freemangordon | FatPhil: so, what I did is to use calibrations for OPP1 and OPP2 (which seem to be correct), to interpolate the values for higher OPPs. Simplified explanation, but should give the idea |
| 16:44.44 | DocScrutinizer05 | freemangordon: don't ask me! I don't trust in my own assumptions about why sth got done as little as I trust in yours. All I know is that we can't base a fix on those assumptions |
| 16:45.24 | freemangordon | I can, as long as it works |
| 16:46.09 | freemangordon | because this is all I have |
| 16:46.27 | DocScrutinizer05 | I'm absolutely convinced that your patch fixes SR in a way it would work (and obviously *does* work) on good devices. The bug why SR got disabled though is some SiErr that is not tackled by your patch |
| 16:46.28 | freemangordon | I don;t have access ti TI internal memos, whatnot |
| 16:46.52 | freemangordon | DocScrutinizer05: and you're statement is based on what but assumtions? |
| 16:47.08 | DocScrutinizer05 | on reports from somebody inside Nokia |
| 16:47.17 | freemangordon | about sierr? |
| 16:47.25 | DocScrutinizer05 | see backscroll |
| 16:48.25 | freemangordon | And I explained how those memory errors are related to the wrong calibration values, iirc |
| 16:49.50 | DocScrutinizer05 | no, you explained how SOME memory errors are attributable to flawed SR tables in EFUSE |
| 16:50.08 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 16:50.26 | freemangordon | ah, I see your point. Well I can't explain memory errors I don;t see, sorry |
| 16:50.37 | DocScrutinizer05 | you however didn't explain how you are going to catch the last 0.5% of devices that have flawed chips |
| 16:51.10 | freemangordon | DocScrutinizer05: WHY 0.5%? |
| 16:51.14 | freemangordon | why |
| 16:51.19 | DocScrutinizer05 | and SR got disabled for sake of those 0.5% |
| 16:51.43 | freemangordon | no, SR doesn't work on maybe 50% without that patch |
| 16:51.48 | DocScrutinizer05 | 0.5% because I had to pick an arbitrary number that might please you |
| 16:52.14 | DocScrutinizer05 | freemangordon: you're missing the point still |
| 16:52.51 | DocScrutinizer05 | freemangordon: it doesn't matter if 50% or 100% don't work without your patches. It's about the 0.1% that doesn't work despite your patch |
| 16:53.07 | freemangordon | I don;t. What I say, is that you don;t have any hard facts that anything is broken besides EFUSE calibration |
| 16:53.26 | DocScrutinizer05 | it's those 0.007% that Nokia decided to keep SR out |
| 16:53.47 | DocScrutinizer05 | THEHECKK! see backscroll!!! |
| 16:53.59 | freemangordon | DocScrutinizer05: I see no hard facts there |
| 16:54.05 | DocScrutinizer05 | honestly you can't be that dull! |
| 16:54.14 | freemangordon | that anything but EFUSE calibration is broken |
| 16:54.33 | DocScrutinizer05 | MEH! futile |
| 16:54.39 | freemangordon | :nod: |
| 17:00.13 | DocScrutinizer05 | "oh! this house is barred, there's a sign `don't enter! Danger!`. Locking in I find there are no railings at the stairways and balcony. I fix taht lack of railings and declare the house is fixed now and safe to use" SANE or NOT DANE? |
| 17:00.53 | DocScrutinizer05 | s/D/S/. |
| 17:02.28 | DocScrutinizer05 | answer: most likely not sane, since ther *reason* why there are no railings is maybe that they stopped bothering when they found out the house has static issues |
| 17:03.32 | DocScrutinizer05 | concluding a "they must have barred the house because without railings it's of course dangerous" is silly |
| 17:04.51 | freemangordon | DocScrutinizer05: EFUSE calibrations are done while the SoC is manifactured, Nokia has nothiing to do with it |
| 17:05.21 | DocScrutinizer05 | so what? |
| 17:06.07 | DocScrutinizer05 | what is your brilliant patch to fix that problem that Nokia and TI never thought of? |
| 17:07.35 | ShadowJK | From TI's point of view, and what they usually did for other things, it's "oh we forgot to burn calibration. No matter, we'll do it in the next silicon revision, bug closed" |
| 17:07.47 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 17:07.55 | DocScrutinizer05 | when a team of experts looks into RAM corruption with SR enabled, and they realize that SR EFUSE values are wrong, don't you think they considered same patches you did? |
| 17:13.32 | DocScrutinizer05 | this is about real money, they definitely had tried to make it work, or made sure it's absolutely clear who's to blame and needs to "pay" for that defect |
| 17:14.25 | *** join/#maemo-ssu luf (~luf@ip-89-103-184-55.net.upcbroadband.cz) |
| 17:14.27 | freemangordon | DocScrutinizer05: and who "paid" for the thumb2 SiErr? |
| 17:14.45 | kerio | probably TI, by reducing the cost of each chip by $amount |
| 17:14.47 | freemangordon | luf: hi! |
| 17:14.54 | luf | freemangordon: hello |
| 17:15.04 | DocScrutinizer05 | even inside TI the department that burns EFUSE will make sure they used exactly the values they got from department of application support, and that department will make sure their values been in line with what they got told from chip bakers |
| 17:15.34 | DocScrutinizer05 | freemangordon: obviously for thumb2 it's TI to pay, but maybe they got refunded by ARM |
| 17:16.12 | freemangordon | DocScrutinizer05: SR calibration is done per device, I don;t know the exact procedure (ofc), but you need to put the SoC in a socket and do some measurement |
| 17:16.13 | FatPhil | DocScrutinizer05: after sniffing around, it appears that the more recent silicon was much better, and it was considered "fixed, but we're still not willing to risk it" |
| 17:16.47 | DocScrutinizer05 | FatPhil: sounds reasonable |
| 17:17.06 | FatPhil | i..e it definitely was shitty hardware earlier! :-) |
| 17:17.15 | DocScrutinizer05 | what i said |
| 17:17.30 | freemangordon | FatPhil: and are there N900s in the wild with the "old" silicon? |
| 17:17.42 | DocScrutinizer05 | he doesn't know |
| 17:18.08 | FatPhil | Trying to work out how to tell silicon versions... |
| 17:18.23 | DocScrutinizer05 | on system level it's easy |
| 17:18.37 | DocScrutinizer05 | read out /proc/cpu or somesuch |
| 17:18.40 | FatPhil | There are definitely different spins out in the real world, yes |
| 17:19.21 | freemangordon | because I have 2101 HW revision, which seems to be the lowest in production (in the wild) |
| 17:19.56 | DocScrutinizer05 | CPU variant : 0x1 |
| 17:19.58 | DocScrutinizer05 | CPU part : 0xc08 |
| 17:19.58 | freemangordon | I don;t know if HW revision is related to SoC revision, but I guess so |
| 17:19.59 | DocScrutinizer05 | CPU revision : 3 |
| 17:20.16 | DocScrutinizer05 | one of those *might* have the info you're looking for |
| 17:20.33 | FatPhil | neither of those is the distinguishing feature |
| 17:20.49 | DocScrutinizer05 | freemangordon: nope, hw revision is not directly related to SoC revision |
| 17:20.54 | freemangordon | :( |
| 17:21.26 | FatPhil | Gonna sniff some nolo console logs.... |
| 17:22.29 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 17:22.41 | DocScrutinizer05 | spruf98 |
| 17:22.57 | DocScrutinizer05 | good luck, it's somewhere in those 3000+ pages |
| 17:23.25 | DocScrutinizer05 | search for "mask" maybe |
| 17:23.44 | FatPhil | shit, no I'm not, until I find a kettle lead... |
| 17:24.05 | FatPhil | anyone shouting "look on the kettle" gets a slap |
| 17:24.24 | DocScrutinizer05 | been adressed at freemangordon |
| 17:25.30 | freemangordon | would that do the job? |
| 17:25.33 | freemangordon | IDCODE: 4b7ae02f |
| 17:25.35 | freemangordon | Production ID: 00000000 00000000 000000cc cafeb7ae |
| 17:25.37 | freemangordon | Die ID: 0a003019 04036ec2 00000000 3ec60004 |
| 17:25.54 | DocScrutinizer05 | I consider it rather futile anyway, since you still can't tell *which* mask revision is prone to the RAM corruption with SR and which is not |
| 17:26.05 | DocScrutinizer05 | Die ID sounds good! |
| 17:26.27 | freemangordon | "/sys/power/idcode" |
| 17:27.04 | DocScrutinizer05 | Die ID: 0c004012 040364fb 00000000 44f60004 |
| 17:28.16 | DocScrutinizer05 | now for the _insider_ this tells 100% unabiguous if that chip is prone to SR probelms or not |
| 17:28.22 | FatPhil | Die ID: 0200600a 04014023 00000000 1fde0004 <- early silicon |
| 17:29.01 | freemangordon | FatPhil: which is the magic walue we should look for? |
| 17:29.13 | freemangordon | value* |
| 17:29.15 | DocScrutinizer05 | that's not THAT easy ;-) |
| 17:29.30 | FatPhil | NFI, alas |
| 17:29.36 | freemangordon | well, maybe with a bit of bitmasking :) |
| 17:29.53 | DocScrutinizer05 | probably spruf98 has some instructions how to dissect and transcode this Die ID |
| 17:29.58 | FatPhil | And NFKL either (neither the kettle nor the underclocked toaster has one) |
| 17:31.04 | FatPhil | Alas anything 3530 won't necessarily have any bearing on 3430 things |
| 17:31.52 | *** join/#maemo-ssu arcean_ (~arcean@aaem165.neoplus.adsl.tpnet.pl) |
| 17:33.05 | DocScrutinizer05 | indeed |
| 17:33.30 | DocScrutinizer05 | and for "our" chip you hardly get *any* info at all |
| 17:34.09 | DocScrutinizer05 | so sorry, my hint / pointer to SPRUF98 been a red herring |
| 17:35.53 | DocScrutinizer05 | I'm absolutely sure the Die ID bitmask has no dedicated bit for "SR supported/not supported" |
| 17:36.35 | DocScrutinizer05 | so it's futile after all, since you don't know anything useful from that whole info about Die |
| 17:38.51 | DocScrutinizer05 | you just have to live with the fact that SR is most probably broken for a (possibly small) percentage of N900 |
| 17:39.06 | FatPhil | It also probably depends on twl4030 version too |
| 17:39.13 | DocScrutinizer05 | and no patch can fix that |
| 17:39.20 | DocScrutinizer05 | indeed |
| 17:40.21 | DocScrutinizer05 | USB PHY (->hostmode) problem definuitely did |
| 17:42.56 | DocScrutinizer05 | can we agree that SR is sufficiently discussed now, and though it might be perfectly safe for most N900 users with freemangordon's patch, there's a chance that it will not work for some users? |
| 17:44.49 | FatPhil | That's the fairest summary. |
| 17:47.07 | freemangordon | sure, but I still wait for someone to report instabilty. For stock frequencies that is. |
| 17:47.58 | DocScrutinizer05 | sure, would be very interesting to find a device that's riddled by this SR problem |
| 17:48.38 | freemangordon | if such device exists, as I still think the only problem is the broken calibration :) |
| 17:49.35 | DocScrutinizer05 | no, there definitely been another problem, and it's just the question if it leaked from prototypes into mass production |
| 17:50.04 | DocScrutinizer05 | we can't tell about that, since we got no way to find out |
| 17:50.53 | DocScrutinizer05 | until we find first device that actually exhibits the problem and then we know it leaked into mp. But we never can prove it didn't |
| 17:50.59 | freemangordon | DocScrutinizer05: a friend of mine have a device which seems to be produced mid 2009 or something, she bought it second hand. Yet SR is perfectly stable there |
| 17:51.37 | DocScrutinizer05 | interesting factoid |
| 17:52.26 | freemangordon | when she got the device, there were some applications I saw for the first time, and the PR version was before PR1.0 iirc |
| 17:52.27 | dos1 | still could be the same WFM syndrom as discussed earlier |
| 17:53.59 | freemangordon | dos1: could be, but if we have a SiErr(so, it is not only the calibrations to blame) , I don't see how it won't appear there |
| 17:54.42 | dos1 | yeah, probability is small |
| 17:54.50 | dos1 | but non-zero :D |
| 17:55.08 | DocScrutinizer05 | "you don't see" is a moot point |
| 17:55.52 | DocScrutinizer05 | up to anybody's guess but the fab manager to tell which devices have which SoC |
| 17:56.15 | FatPhil | To Nokia, if one person has a 1 in a 1000 chance of ever seeing it, then hundreds of people will return their device. |
| 17:56.41 | DocScrutinizer05 | don't think they come from TI one by one and get assembled to PCB just in time. there are batches |
| 17:58.01 | DocScrutinizer05 | wild speculations about "I don't see how...." - we can as well stop that as it doesn't get us anywhere |
| 17:59.32 | DocScrutinizer05 | nuff say, FatPhil commented on my final relevant statement in an acknowledging way. That's just fine for me. I'm out |
| 18:01.33 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 18:06.33 | FatPhil | I've not yet examined all the changes that have been made since I last looked at the kernel. It's entirely possible that issues have been worked around. |
| 18:06.50 | FatPhil | Die ID: 0401901e 040360e0 00000000 1e140004 |
| 18:07.16 | FatPhil | I have several other devices at home home |
| 18:10.12 | *** join/#maemo-ssu FlameReaper (~assassin@183.171.172.184) |
| 18:11.58 | FatPhil | The code's hilarious: |
| 18:11.59 | FatPhil | <PROTECTED> |
| 18:11.59 | FatPhil | <PROTECTED> |
| 18:11.59 | FatPhil | <PROTECTED> |
| 18:11.59 | FatPhil | <PROTECTED> |
| 18:13.51 | FatPhil | And I think that was one of the SR-related bugs |
| 18:13.52 | FatPhil | <PROTECTED> |
| 18:13.53 | FatPhil | <PROTECTED> |
| 18:13.53 | FatPhil | <PROTECTED> |
| 18:14.34 | freemangordon | FatPhil: i sthat released? |
| 18:14.35 | DocScrutinizer05 | yup |
| 18:15.19 | DocScrutinizer05 | definitely looks like SR related |
| 18:17.51 | freemangordon | yep, released, it is in KP |
| 18:20.05 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 18:20.50 | freemangordon | FatPhil: description of XYZ: http://gitorious.org/angstrom/angstrom-linux/source/3669413721fc8b84607f093d128a0f8dde7c3157:drivers/mfd/twl4030-power.c#L549 |
| 18:24.59 | *** join/#maemo-ssu iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 18:25.49 | freemangordon | iDont: I pushed bb-power in thumb repo finally, sorry for the delay |
| 18:26.22 | iDont | hi freemangordon, thanks and don't worry about the delay |
| 18:26.44 | freemangordon | :) |
| 18:27.15 | iDont | those who want to run the latest version before it hits the repos, can always find debs in bb-power's garage page |
| 18:27.40 | freemangordon | thumb2 version? ok |
| 18:28.14 | iDont | yeah, all variants can be found there. It's always a lot of work to upload every file separately with each release :P |
| 18:28.45 | freemangordon | iDont: I just use mc ;) |
| 18:29.24 | iDont | you can automate uploading to the files section of garage pages? |
| 18:29.54 | freemangordon | NFC, I just select all the files and press F5 |
| 18:30.10 | iDont | ah ok |
| 18:38.40 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 18:43.19 | freemangordon | Pali: hmm, iiuc what Dave says, something like " @not really sure DSP it is needed here, copied from omap_smc2()" could finally make him happy so we'll have that patch upstreamed |
| 18:43.39 | freemangordon | s/DSP/DSB/ |
| 18:44.03 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 18:45.56 | Pali | freemangordon: will you create new patch? |
| 18:46.08 | freemangordon | Pali: no :) |
| 18:46.18 | freemangordon | I have nothing set up here, sorry |
| 18:46.58 | freemangordon | Pali: is thre any problem on your side, besides free time? |
| 18:47.06 | freemangordon | *thre |
| 18:47.10 | freemangordon | WTF? |
| 18:47.13 | freemangordon | THERE |
| 18:47.16 | Pali | no nothing |
| 18:50.10 | freemangordon | It will just take me lots more time to clone, set up git email, learn how to use it, ets |
| 18:50.18 | ShadowJK | hey my N900 just crashed :( |
| 18:50.28 | freemangordon | maybe I should do that anyway someday, but not now :) |
| 18:51.08 | ShadowJK | (I/O stall/deadlock that's been hitting me every 1-7 weeks since 2009) |
| 18:51.59 | DocScrutinizer05 | ShadowJK: weird stuff, I never seen such IO deadlock |
| 18:52.15 | freemangordon | ShadowJK: hmm, do you use sto VM settings? |
| 18:52.19 | DocScrutinizer05 | ShadowJK: which fs? |
| 18:52.43 | DocScrutinizer05 | ShadowJK: which interface? |
| 18:52.57 | DocScrutinizer05 | ShadowJK: which kernel? |
| 18:53.11 | freemangordon | wtf is with my kbd?!? |
| 18:53.19 | freemangordon | *stock |
| 18:53.26 | DocScrutinizer05 | bread crumbs |
| 18:53.46 | DocScrutinizer05 | I know that effect ;-D |
| 18:54.17 | DocScrutinizer05 | particularly bad on laptop type short stroke keys |
| 18:54.53 | freemangordon | hmm, no, it is full size PC105 kbd attached to my desktop |
| 18:55.25 | ShadowJK | nr_requests modified, min-free inxcrease |
| 18:55.30 | ShadowJK | emmc stall |
| 18:55.43 | DocScrutinizer05 | lot of full size kbds with laptop keys out there |
| 18:55.58 | DocScrutinizer05 | one in front of me, typing on it |
| 18:56.16 | DocScrutinizer05 | ShadowJK: ext3? |
| 18:56.37 | freemangordon | ShadowJK: tweak page-cluster and swappiness |
| 18:56.44 | DocScrutinizer05 | or whole MMC phy interface? |
| 18:57.04 | DocScrutinizer05 | well, I guess you can't tell |
| 19:04.17 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 19:08.30 | ShadowJK | It looks more like kernel stops processing requests |
| 19:09.19 | ShadowJK | I've had it happen with various page-cluster and swappiness settings too |
| 19:09.36 | ShadowJK | Feels like it happens more often with lower swappiness |
| 19:11.12 | freemangordon | more often? weird. |
| 19:16.52 | DocScrutinizer05 | ShadowJK: syslog on NAND? |
| 19:17.21 | DocScrutinizer05 | or even: you checked mtdoops? |
| 19:17.23 | freemangordon | DocScrutinizer05: on WD kicked in? |
| 19:18.23 | DocScrutinizer05 | whatever it been, i'd hope for it either being diagnosable via shell, via syslog, or via kernel OOPS |
| 19:19.41 | DocScrutinizer05 | when MMC interface blows chunks, syslog on NAND and mtdoops partiton (also NAND) are your best options |
| 19:19.49 | ShadowJK | it was wd reboot |
| 19:20.23 | ShadowJK | There's never anything in logs, and kernel doesn't oops |
| 19:23.10 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 19:24.10 | DocScrutinizer05 | well, wd doesn't oops |
| 19:24.25 | DocScrutinizer05 | I suggest to disable watchdogs |
| 19:24.40 | DocScrutinizer05 | and enable sysreq keys |
| 19:24.59 | DocScrutinizer05 | only way to get info out of a true kernel freeze |
| 19:44.34 | ShadowJK | sometimes I can get dmesg and manually T to sysrq-trigger |
| 19:45.37 | FatPhil | beware - noise on uart lines can be interpreted as sysrq commands |
| 19:54.25 | DocScrutinizer05 | haha, nice |
| 19:54.40 | DocScrutinizer05 | maybe that's even the *cause* of ShadowJK's problem then |
| 19:55.22 | DocScrutinizer05 | though, wouldn't that need "console tty" or sth on kernel commandline? |
| 19:56.06 | FatPhil | console=tty0 |
| 19:56.09 | DocScrutinizer05 | afaik _normally_ the UART3 that might be used as console tty is disabled by default |
| 19:56.52 | FatPhil | that cmdline gives console logs to the jig when the R&D flags are appropriately set |
| 19:56.56 | DocScrutinizer05 | via kernel cmdline that either gets passed by NOLO or is compiled in to kernel |
| 19:57.33 | DocScrutinizer05 | yep, CAL R&D flags |
| 19:58.09 | DocScrutinizer05 | as long as ShadowJK hasn't set them so tty console gets used, it shouldn't cause any troubles with noise |
| 19:58.38 | FatPhil | yup |
| 20:03.27 | ShadowJK | Yeah it's not set |
| 20:06.04 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 20:36.00 | FatPhil | Hmm, I haven't had a rant about the insane renaming of the mmc devices recently. That's weird. Cos it's truly insane. |
| 20:36.29 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 20:37.48 | freemangordon | FatPhil: which one is insane - what Nokia did or https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=blob;f=kernel-power-2.6.28/debian/patches/mmcnames-fanoush.diff;h=2124e1f1a9eeb9b434fdca9fe27cb2170ed12b33;hb=HEAD |
| 20:37.56 | freemangordon | ? |
| 20:40.08 | FatPhil | does that make it 0 (no card) or 1 & 2 (with card)? |
| 20:41.27 | FatPhil | and if you add a card, it will be 1. So a card is always 1. |
| 20:41.32 | freemangordon | the patch? it makes internal card /dev/mmcblk0 and external /dev/mmcblk1 |
| 20:45.02 | ShadowJK | mmc renaming madness was going on in Chinook too :) (and diablo..) |
| 20:47.37 | FatPhil | Either it's late, or find_next_zero_bit() has a bug... |
| 20:48.09 | DocScrutinizer05 | FatPhil: there's not much you can do about MMC-IF renaming resp not renaming |
| 20:50.54 | DocScrutinizer05 | the point simply being: kernel enumerates mmc interfaces in the sequence it finds working storage on them, starting scan at lowest numbered interface which for booting-from-uSD reasons has to be the interface which uSd is connected to |
| 20:51.45 | ShadowJK | FatPhil; is that used in swapout? |
| 20:51.52 | DocScrutinizer05 | if no uSD is inserted, then kernel skips to next mmc interface which happens to be connected to eMMC, and that one is named mmcblk0 then |
| 20:54.45 | FatPhil | OK, didn't know about the booting-from-uSD reasons, that almost makes the behaviour sensible |
| 20:54.58 | DocScrutinizer05 | :nod: |
| 20:55.17 | FatPhil | YEah, reading the patch, it does enumerate them as you say. |
| 20:55.20 | FatPhil | it's late.... |
| 20:55.29 | DocScrutinizer05 | if it wasn't for booting, the EE had for sure mounted eMMC to UF1 and uSD to IF2 |
| 20:55.38 | DocScrutinizer05 | s/UF/IF/ |
| 20:55.54 | FatPhil | However, I still think find_next_zero_bit has a bug! |
| 20:56.29 | DocScrutinizer05 | if you share a http: URL, i'm willing to review it |
| 20:57.04 | DocScrutinizer05 | preferably http://mxr |
| 20:57.25 | FatPhil | so, does the fanoush patch mess up uSD booting? |
| 20:57.46 | FatPhil | that's a silly question |
| 20:57.47 | DocScrutinizer05 | http://mxr.maemo.org/fremantle/source/kernel/drivers/ |
| 20:58.13 | DocScrutinizer05 | indeed ;-D |
| 20:58.48 | DocScrutinizer05 | as long as it doesn't patch BOOTROM, x-loader or NOLO, it prolly doesn't |
| 20:59.41 | FatPhil | I think I like the fanoush patch! |
| 21:00.15 | *** join/#maemo-ssu FlameReaper (~assassin@183.171.161.174) |
| 21:00.21 | DocScrutinizer05 | FatPhil: maybe better pick option one for today, from >>Either it's late, or find_next_zero_bit() has a bug...<< |
| 21:00.29 | freemangordon | FatPhil: can't find any difference between KP and upstream in find_next_zero_bit |
| 21:01.26 | freemangordon | even the commnts match |
| 21:01.31 | freemangordon | *comments |
| 21:05.01 | DocScrutinizer05 | idly wonders whether we should ask the guy that hosts mxr to eventually move it to the maemo.org server infra |
| 21:26.50 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:02.09 | *** join/#maemo-ssu Handaxe (~user@m176-70-44-115.cust.tele2.se) |
| 22:02.39 | *** part/#maemo-ssu Handaxe (~user@m176-70-44-115.cust.tele2.se) |
| 22:43.36 | ShadowJK | I forget, did he go to palm/hp? |
| 22:47.53 | DocScrutinizer05 | RIM? |
| 22:48.52 | DocScrutinizer05 | tbh I even forgot who's hosting it, crashie or time less |
| 22:49.08 | ShadowJK | one of those |
| 22:49.40 | DocScrutinizer05 | could do a whois, but too lazy |
| 22:49.41 | ShadowJK | I think HP was the one doing shotgun recruitment around elopcalypse time |
| 22:51.09 | DocScrutinizer05 | prolly crashie then, since mxr.m.o for sure not hosted by a (ex-)Nokian |
| 22:51.55 | DocScrutinizer05 | timeless worked on microB |
| 22:53.16 | DocScrutinizer05 | also crash is hosting one of the mirrors, and I'd bet on IPs of the mirror and mxr are identical or at least close |
| 22:55.16 | ShadowJK | timeless |
| 22:56.12 | ShadowJK | crashanddie is, iirc, a very vocal and temperamental community member |
| 23:00.01 | DocScrutinizer05 | hmm |
| 23:00.03 | DocScrutinizer05 | ok |
| 23:05.38 | ShadowJK | I wonder if timeless is working on firefoxos now |
| 23:12.24 | DocScrutinizer05 | ask him! he's over at #maemo |
| 23:55.45 | *** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com) |