IRC log of #maemo-ssu for Wednesday, 2013-09-04

« Tuesday, 2013-09-03 Index Thursday, 2013-09-05 »
*** RST38h has quit IRC00:04
*** RST38h has joined #maemo-ssu00:06
*** NIN101 has quit IRC00:07
*** nox- has joined #maemo-ssu00:14
*** sunny_s has joined #maemo-ssu00:16
*** RST38h has quit IRC00:17
*** RST38h has joined #maemo-ssu00:19
*** RST38h has quit IRC00:32
*** RST38h has joined #maemo-ssu00:32
*** Vlad_on_the_road has quit IRC00:44
*** M4rtinK has joined #maemo-ssu01:03
*** dos1 has quit IRC01:15
*** Martix has quit IRC01:16
jon_yDocScrutinizer05: yeah, GPL still the best license01:23
jon_yhow you like it now BSD guys? :)01:23
jon_yBSD code would have been locked down tight and gone forever01:23
*** luf has quit IRC01:24
*** xes has quit IRC01:39
*** xes has joined #maemo-ssu01:40
*** RST38h has quit IRC01:53
*** dos1 has joined #maemo-ssu02:06
*** lansiir has joined #maemo-ssu02:14
*** oldtopman has quit IRC02:17
*** M4rtinK has quit IRC02:21
*** BCMM has quit IRC02:28
*** dos1 has quit IRC02:38
*** i_a_delta_GB has joined #maemo-ssu02:42
*** kolp has quit IRC02:45
*** i_a_delta_GB has quit IRC02:51
*** handaxe has quit IRC02:52
*** xes has quit IRC02:53
*** handaxe has joined #maemo-ssu02:54
*** RST38h has joined #maemo-ssu03:41
*** mkaindl has quit IRC03:42
RST38h.join #maemo03:42
*** mkaindl has joined #maemo-ssu03:43
*** dafox has quit IRC04:04
*** nox- has quit IRC04:19
*** amiconn has quit IRC05:15
*** amiconn_ has joined #maemo-ssu05:15
*** amiconn_ is now known as amiconn05:15
*** sunny_s has quit IRC06:55
*** mickname has quit IRC06:59
*** mickname has joined #maemo-ssu06:59
*** lansiir has quit IRC07:36
ototoFatPhil: what about "Linaro's" powertop?08:44
ototoOh, the kernel is different, right...08:45
FatPhilototo: I presume Linaro's is based on Intel's, and is x86-based?08:46
freemangordonmorning08:47
freemangordonFatPhil: please tell me about the bug you think you found in KP, I can't sleep :D08:48
FatPhilarse, my laptop went flat again lsat night, and I was so tired when I got home, I forgot to plug it in again...08:50
freemangordonFatPhil: which patch is buggy?08:50
FatPhilit's 2 lines of code being commented out.08:51
FatPhilhowever, it leaves the controllign 'if', which then acts upon the return statement that follows08:51
FatPhilrather than the lines that were commented out08:51
FatPhilOK, have enough juice to power up...08:52
freemangordongood :)08:52
FatPhilpower-supply-no-verbose.diff08:54
FatPhilThe correct patch is to just remove the whole if.08:55
FatPhilDon't comment code out - we have version control systems for remembering old versions.08:55
freemangordonFatPhil: hmm I guess Pali commented that out while being sleepy :)08:56
* freemangordon is going to look at the patch08:56
freemangordonFatPhil: hmm, I am not sure this is not done on purpose. Still, it is ugly08:59
freemangordonoh, wait, this can't be on purpose08:59
freemangordonyep, definitely a bug08:59
freemangordonwhich will bite Pali's ass in case of ENODEV09:00
FatPhilif you give me a couple of email addresses, I'll send my changes for review09:03
FatPhilJust written a quick patch09:03
FatPhiland fucking git decides to do a garbage collect just as I'm in a rush...09:03
freemangordonFatPhil: pali.rohar at gmail.com, freemangordon at abv.bg09:04
freemangordonFatPhil: did yo utake a look at big patches like dsp backport and smartreflex fixes?09:06
ototoFatPhil: LinARo (ARM)09:07
FatPhilfreemangordon: not got to the DSP one yet. Don't remember the smartreflex one.09:08
freemangordonototo: are sources available online?09:08
FatPhilQuoth nokia auto-responder: "Please note that only written requests are accepted. We do not reply to requests by e-mail."09:08
freemangordonFatPhil: Pali did that a week or so ago(wrote an email)09:09
freemangordonwe had a good fun when he received the "maemo sources) :D09:09
freemangordonhe received a dvd image, which contains CD image, which contains .debs from repository.maemo.org :D09:10
*** sunny_s has joined #maemo-ssu09:14
FatPhiluuencoded09:14
ototofreemangordon: sure, git.linaro.org. On technical details I'd suggest contacting sanjayr or amitk on #linaro-big.little09:14
FatPhilI have links inside Linaro too (chatting to 2 of them occasionally on IRC)09:15
FatPhilboth are very cooperative09:15
ototoFatPhil: you have +1 link ;)09:15
* ototo !09:15
freemangordonototo: I will take a look at it, though I think in "our" powertop there are some Nokia-made changes to fit with the kernel changes09:16
FatPhilCool.09:17
FatPhilmail on its way...09:17
freemangordonhmm, this is intel powertop09:17
freemangordonhttps://git.linaro.org/gitweb?p=tools/powertop-2.0.git;a=tree;f=src/cpu;h=e1e37b1bb3607ae819e8b5301fd2198ebb90f395;hb=HEAD09:17
freemangordonFatPhil: thanks!09:18
FatPhilintel_cpus.{h,cpp}09:22
ototohttps://cards.linaro.org/browse/PMWG-1909:23
ototoI assume it works on ARM :)09:24
FatPhil"You must log in to access this page."09:24
*** Vlad_on_the_road has joined #maemo-ssu09:25
FatPhilnokia's powertop is a fork of intel's 1.12 version, which bit-by-bit had everything intel removed from it.09:25
FatPhilSo a binary scanner won't detect any GPL code in it.09:25
FatPhilAnyway, I need to find a rift in time and space, so that I can be at work hald an hour ago...09:26
freemangordonheh, same here :)09:29
freemangordonthough I have to run as I have a meeting in 30 mins09:29
ototoOh, sorry, that link will become public most likely this week. Apologies.09:34
ototoBasically it's about keeping powertop 2.0 working on ARM09:35
*** discopig has quit IRC09:39
*** discopig has joined #maemo-ssu09:42
*** discopig is now known as bromide09:51
FatPhilIs there a way to query the modem and find out what mobile networks are visible to it?10:16
FatPhilPLMN?10:16
FatPhilThat'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!10:18
*** Martix has joined #maemo-ssu10:21
*** n900-dk_ has quit IRC10:24
*** DrCode has quit IRC10:25
*** DrCode has joined #maemo-ssu10:29
*** n900-dk has joined #maemo-ssu10:29
*** sunny_s has quit IRC11:02
*** kolp has joined #maemo-ssu11:05
*** FlameReaper has joined #maemo-ssu11:10
*** Martix has quit IRC11:21
*** Pali has joined #maemo-ssu11:23
*** Pali is now known as Guest3257211:23
*** Martix has joined #maemo-ssu11:24
*** Guest32572 has quit IRC11:25
*** Pali_ has joined #maemo-ssu11:26
*** Pali_ is now known as Pali11:28
*** M4rtinK has joined #maemo-ssu11:32
*** M4rtinK has quit IRC11:56
*** Martix has quit IRC11:56
freemangordonPali: hi, did you see the mail from FatPhil? the patch for bq .ko11:57
FatPhilototo: does your PMWG link differ much from https://blueprints.launchpad.net/linaro-powertop/+spec/ensure-powertop-2.0-runs-on-arm12:04
FatPhilMy signed-off-by line needs changing!!!! I ain't been at nokia for a long time12:06
ototoFatPhil: we're migrating to JIRA and JIRA version is basically the same at the moment, but not yet made public12:06
FatPhilErm "09:15 < ototo> FatPhil: you have +1 link ;)" - not! you already were one of my links you silly chappy!12:08
ototo:>12:09
* ototo -> lunch12:09
FatPhilWhat's the root of this problem: "udev does not working with separate /usr and /"12:13
FatPhilIMHO, udev shouldn't care. A udev that does care is braindead.12:13
*** sunny_s has joined #maemo-ssu12:16
*** BCMM has joined #maemo-ssu12:26
*** FlameReaper has quit IRC12:32
*** handaxe has joined #maemo-ssu12:41
*** dafox has joined #maemo-ssu12:50
Palifreemangordon: I got that mail13:06
Paliis not that patch in cssu?13:06
FatPhilPali - patch in CSSU has dangling if statement13:07
FatPhilwhich then grabs the return13:07
PaliFatPhil: ok, now I see where is problem13:10
PaliFatPhil: you are still in nokia that you used nokia address?13:11
FatPhilI 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.13:12
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)13:14
FatPhilIn fact the mail settings are completely fucked. I've not used "fatphil@..." as my email address for years, I prefer just "pc" now,13:16
FatPhilPali: 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.13:19
PaliFatPhil: changes to mce, hal and dsme?13:20
Palior other sources?13:20
FatPhilwhatever's thrashing the CPU13:20
FatPhilit's doing a poll() with the wrong flags.13:20
FatPhilKernel's API changed in 2.6.29.13:20
Palihal and dsme are open, so this can be fixed in cssu...13:21
Palibut what with mce?13:21
Palido you know how to fix poll()?13:21
Paliwhich flags needs to be fixed?13:21
FatPhilcalls need the PRI flag added, IIRC.13:22
FatPhilA virtual file always has data, so POLL_IN always returns immediately13:22
FatPhilWe went over this roadbump in the HArmattan days. I was the guy who filed all the bugs against userspace!13:23
PaliFatPhil: nice13:24
Paliso there is already patch for dsme and hal?13:24
FatPhilI don't know how closely related the n9 versions are to the n900 versions.13:25
FatPhilbut the n9 versions ahve the fix13:25
Palin9 version of dsme is very different13:27
PaliFatPhil: do you have patches/commits for dsme or other daemons used in n9?13:44
Palifreemangordon: ping13:45
PaliFatPhil: I commited your kernel patch to kernel-power git repository on garage.maemo.org13:48
*** FlameReaper has joined #maemo-ssu13:56
*** dos1 has joined #maemo-ssu14:01
FatPhilPali: 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 home14:02
PaliFatPhil: ok, let me know... fixing these userspace bugs will be usefull for running upstream kernel on n90014:03
*** dos11 has joined #maemo-ssu14:07
*** dos1 has quit IRC14:08
*** dos11 is now known as dos114:22
*** FlameReaper has quit IRC14:23
*** Milhouse has quit IRC15:09
*** arcean has joined #maemo-ssu15:11
*** Milhouse has joined #maemo-ssu15:37
*** Milhouse has quit IRC15:44
*** Milhouse has joined #maemo-ssu15:55
*** Milhouse has quit IRC16:03
*** dafox has quit IRC16:05
*** Milhouse has joined #maemo-ssu16:15
*** arcean has quit IRC16:21
*** arcean has joined #maemo-ssu16:24
*** Milhouse has quit IRC16:25
*** DrCode has quit IRC16:48
*** Milhouse has joined #maemo-ssu16:54
*** DrCode has joined #maemo-ssu16:59
*** Milhouse has quit IRC17:04
DocScrutinizer05(([2013-09-04 08:06:36] <freemangordon> FatPhil: did yo utake a look at big patches like dsp backport and smartreflex fixes?)) ~sr17:23
*** Milhouse has joined #maemo-ssu17:34
*** Milhouse has quit IRC17:41
*** Milhouse has joined #maemo-ssu18:08
*** Milhouse has quit IRC18:15
freemangordonPali: pong18:16
Palifreemangordon: did you remember problem with upstream 3.x kernel and non working gsm/3g stack?18:16
freemangordonPali: on maemo?18:17
Paliyes18:17
freemangordonyep, I remember, but didn;t try to figure out what exactly is the problem18:17
freemangordonPali: why do you ask?18:18
PaliI'm asking if you was able to find out why it not worked18:18
Palinow we know why hald/dsme/mce using 100% cpu18:18
freemangordonPali: I didn't try18:18
freemangordonyeah :)18:18
Palisee chanlog18:18
freemangordonsaw it18:19
freemangordonI guess we can fix that with some LD_PRELOAD18:19
Palithis, camera and telephony are problems which needs to be solved for using 3.x kernels on maemo18:19
freemangordoncamera?18:19
freemangordonwhat is the problem with camera?18:20
Palino drivers for 3.x kernels yet18:21
Palino working drivers18:22
freemangordonoh, not good18:23
freemangordonPali: on a side note - ke-recv is still not in cssu-devel :)18:23
Paliok, I will push it18:23
FatPhilhas anyone been mad enough to bisect the camera issues?18:23
freemangordonFatPhil: none I am aware of :)18:24
freemangordonbut we'll have to do it someday18:24
freemangordonwell, I guess my experience with porting the DSP driver will help a bit :D18:25
PaliFatPhil: camera problem is that there is no driver in upstream kernel18:25
Palistack of 2.6.28 is different as in 3.x18:25
Paliand driver cannot be easy forward-ported18:25
Palifrom 2.6.2818:25
freemangordonPali: hmm, there is a port18:25
freemangordoniirc18:25
Paliyes, there is port, but not working18:25
Paliit compiles, but thats all18:26
freemangordonmissing board code?18:26
Palino, eveyrthing is there18:26
Palibut it is not working18:26
freemangordonhow did you test it?18:26
Palimplayer18:26
freemangordonany error?18:26
Paligreen/black screen18:26
Palior some error18:26
Paliioctl18:26
PaliI also used media-ctl to set configs18:27
freemangordonok, I'll take care of that when it comes to it18:27
Palinoting helped18:27
ShadowJKsame commandline works on 2.6.28?18:27
Paliin upstream kernel is only driver for fron webcam18:27
Palibut missing board data18:27
ShadowJKany difference with -vo x11 (in case it's Xv that's not working)18:27
PaliI used some provided by some developer but same problem, green/black screen or ioctl error18:28
PaliShadowJK: no18:28
Palithere was also some errors in dmesg18:28
Palikernel was unable to detect/compute some clks...18:28
freemangordonPali: well, if it doesn;t work with stock, why do you expect to work with 3.x?18:28
PaliI do not remember exactly18:28
FatPhilmaybe clock framework has changed18:29
FatPhilA bisect should identify that18:29
Palifreemangordon: with stock kernel camera working18:29
freemangordonFatPhil: not "maybe"18:29
freemangordonPali: iirc we already have a problem with the clock framework been changed18:29
freemangordonwe had to add some clock in the board code18:30
Paliyes I know, clk_prepare18:30
freemangordon:nod:18:30
freemangordonmost probably it is the same18:30
Palibut this was fixed18:30
freemangordonsame problem18:30
FatPhilwhat version of the kernel did you try to rebase to?18:30
freemangordon3.2 iirc18:31
Palihttps://gitorious.org/linux-n900/linux-n90018:31
freemangordonthat was me, pali tried 3.5 iirc18:31
Pali3.818:31
Pali3.918:31
Paliand 3.1018:31
freemangordonoh, yes18:31
ShadowJKthere"s also the weird multiplexer thing infront of the two cams, is that stuff in newer kernels?18:31
freemangordonwait, it was me to boot maemo with 3.5 :D18:31
PaliFatPhil: in gitorious is full tree with all my patches18:31
freemangordonPali: my powervr backport?18:31
*** M4rtinK has joined #maemo-ssu18:32
PaliI have it too18:32
freemangordonforward-port18:32
freemangordonis it in the tree?18:32
Paliyes18:32
freemangordongood18:32
Paliin 3.10 was problem because there is removed lot of procfs api18:32
*** NIN101 has joined #maemo-ssu18:32
freemangordonthe bad news about that is that we won;t be able to use it on neo90018:32
Paliand I commented lot of pvr code in 3.10 because of that18:32
freemangordonbecause of the newer sgx core18:33
FatPhilpah - 500 Server Error from https://gitorious.org/linux-n900/linux-n900/commits/a6d3bd274b85218bf7dda925d14db81e1a8268b318:33
PaliFatPhil: gitorious has some problems...18:33
freemangordonso we'll have to use either nemo or harm driver18:33
Palitry to clone git repo directly18:34
Pali$ git clone git://gitorious.org/linux-n900/linux-n900.git18:34
freemangordonFatPhil: or better said - gitorious is fubar for the last 2 weeks18:34
Paliand see branch v3.10-n90018:34
freemangordonPali: hmm, maybe FatPhil can help with Secure PPA API patch18:34
Paliit only needs some correct comments :-)18:35
Palido you have link on lkml.org?18:35
freemangordonas it seems we'll have to send it to Linus for it to be upstreamed :D18:35
freemangordonI'll ask google18:35
freemangordonPali: that one? https://lkml.org/lkml/2013/2/28/11618:36
DocScrutinizer05~tell freemangordon about sr18:36
Paliok, here is last version: https://lkml.org/lkml/2013/8/5/4418:37
freemangordonDocScrutinizer05: hmm?18:37
*** dos1 is now known as dos1118:37
Paliand here is second patch: https://lkml.org/lkml/2013/7/10/23818:38
DocScrutinizer05hmm?18:38
DocScrutinizer05~sr18:38
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.<<18:38
*** dos11 is now known as dos118:38
freemangordonDocScrutinizer05: I was told thumb2 can;t be workarounded too, so what?18:38
DocScrutinizer05so you weren't told that by Nokia and TI18:39
freemangordonwrong, there is a bug on BMO18:39
freemangordonand nokia stated it can;t be fixed/used18:39
Paliand here today is Dave responce: https://lkml.org/lkml/2013/9/4/22518:39
DocScrutinizer05and 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?18:40
freemangordonDocScrutinizer05: what I found is that EVERY n900 I got data from, has EXACTLY the same EFUSE calibration values for OPP3-OPP518:41
DocScrutinizer05mind you, you needed toolchain 4.7(?) to make thumb work18:41
freemangordonDocScrutinizer05: no, I needed binutils >= 2.20, but that is irelevant18:42
DocScrutinizer05wow what a finding, I'm absolutely sure Nokia didn't know18:42
freemangordonthay just nothing to fix/workaround it, that's it18:43
freemangordon*they18:43
freemangordonDocScrutinizer05: not to say I don;t get it what we are arguing for18:43
freemangordonDocScrutinizer05: so far there is only 1 report that might be related to SR making a device unstable18:44
DocScrutinizer05I challenge your claim that you found the fix for a bug you even don't know about18:44
freemangordonsorry, you lost me on that one.18:45
freemangordonTI somehow had screwed EFUSE calibration in the course of manifacturing those OMAPS18:45
DocScrutinizer05uhuh18:46
DocScrutinizer05and how is that causing memory corruption?18:46
freemangordonyep, there is no other sane explanation for those EFUSE values18:46
freemangordonDocScrutinizer05: if your CPU is undervolted, guess ;)18:46
DocScrutinizer05I guess TI is savvy enough how to operate their CPU18:47
DocScrutinizer05if they didn't find a fix for memory corruption then I simply doubt you found it18:47
freemangordonthe poing here being - if EFUSE calibration value is wrong (which it is), SR will undevolt some CPUs too much, below the stable threshold18:48
DocScrutinizer05some????18:48
freemangordonafter that happens, you might expect lots of funnty things to happen - including corrupted cacheline to be written to RAM18:49
freemangordonDocScrutinizer05: yes, some18:49
DocScrutinizer05and you think TI and Nokia were too dull to patch kernel so it overrides any supposedly incorrect SR table?18:49
freemangordonSR EFUSE calibration is device (CPU) specific18:49
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 calibration18:49
ShadowJKConsidering 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 :)18:49
freemangordonDocScrutinizer05: it is waaay easier to just disable it18:50
DocScrutinizer05that's bullshit18:50
freemangordonDocScrutinizer05: please, read what I write till the end18:50
freemangordon18:41 <freemangordon> DocScrutinizer05: what I found is that EVERY n900 I got data from, has EXACTLY the same EFUSE calibration values for OPP3-OPP518:50
DocScrutinizer05and an isnult to TI and Nokia, who claimed they were NOT ABLE to fix it18:50
freemangordonI am not trying to insult anyone18:52
DocScrutinizer05you'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"18:52
freemangordonsr works on most of the devices running KP for almost an year18:52
freemangordonDocScrutinizer05: BTW where you got TI/Nokia statement from?18:53
DocScrutinizer05yeah sure, data corruption is not anything you notice immediately and associate to SR being enabled when you see the fallout18:53
DocScrutinizer05freemangordon: maybe I don't want to disclose where from I got it18:54
freemangordonwell, please disclose to the extent you're allowed or want, what is the reason thay are unable to fix it18:54
DocScrutinizer05attach a Lauterbach to a OMAP3 devel board and *then* check memory integrity under SR18:54
DocScrutinizer05I have no further info on that. Maybe others here are willing to shed more light on it, maybe not18:55
freemangordonDocScrutinizer05: ofc there will be corruption if your calibration is fcked up18:55
dos1well, I could suspect that except being dull and/or lazy, there's also enough time and/or money factor18:56
freemangordonthat one too18:56
DocScrutinizer05of course TI and Nokia didn't know about that¡18:56
dos1but that's just a small note from someone outside the discussion :P18:56
freemangordonDocScrutinizer05: point here being? why they didn;t fix thumb2?18:56
DocScrutinizer05because they had no gcc4.7 at that time18:57
DocScrutinizer05and maybe because TI patch not even been published in early stage of maemo5 development18:57
freemangordongcc 4.7 is not needed, what you need is binutils 2.19 iirc18:58
freemangordonbesides ARM errata workaround18:58
DocScrutinizer05whatever is needed, you had to do an update since it's not even included in published maemo5 SDK18:58
DocScrutinizer05so evidently it wasn't available to Nokia devels at time of early development, and thus they went for non-thumb18:59
freemangordonpublished Maemo SDK vmware inage comes with DEB_BUILD_OPTIONS=...,thumb18:59
freemangordon*image18:59
DocScrutinizer05meh, discussions with you about that stuff always tend to end like discussing drug abuse with a junky19:00
dos1isn't facebook widget compiled with thumb?19:00
freemangordonit is19:00
freemangordonnot widget, but the underlying framework19:00
ShadowJKTo be fair, neither side makes any actual technical arguments ;-)19:01
ShadowJKAnd 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 sr19:03
freemangordonTBH 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 further19:05
*** DrCode has quit IRC19:06
freemangordonjust one more thing - remember Nokia's statements re OC and USB host mode?19:06
freemangordonBoth were classified as impossible, IIRC19:07
DocScrutinizer05USB statement been absolutely correct19:07
DocScrutinizer05OC statement been absolutely correct19:07
*** bromide has quit IRC19:07
DocScrutinizer05USB OTG still is impossible19:07
DocScrutinizer05and OC still burns your CPU in no time, compared to nominal lifespan of device as designed by product requirement specs19:08
DocScrutinizer05and original Igor Stopa(?) statement been "you must not lock CPU to 600MHz or it will die"19:09
freemangordonDocScrutinizer05: that's irrelevant, they said OC is IMPOSSIBLE. IIRC. Might be wrong as well, it was > 3 years ago19:10
DocScrutinizer05in my book this implies that CPU even less can handle >600MHz19:10
DocScrutinizer05nobody ever said OC is impossible. Or point me to that statement and I stand corrected19:11
DocScrutinizer05if anything, Nokia said "OC *MUST NOt* be done"19:11
ShadowJKThey forgot to consider whether cpu life is less than modem or usbport life anyhow ;-)19:12
DocScrutinizer05not "cannot be done"19:12
dos1ShadowJK: :D19:12
freemangordonwill try to find it19:12
DocScrutinizer05and 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 else19:13
*** discopig has joined #maemo-ssu19:13
ShadowJKThe "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 apps19:14
DocScrutinizer05it's not even *claiming* to fix the original root problem, since we been unaware of it19:14
keriothe only thing remotely close to memory corruption is some graphical glitches, that apparently happen even when SR is disabled19:16
keriofmg's smartreflex WORKSFORME19:16
kerioon two N900s19:16
DocScrutinizer05kerio: shut up please. WFM is BS19:16
keriono, i'm fairly sure that it works for me19:17
DocScrutinizer05you don't even know if it "works for you"19:17
DocScrutinizer05I seem to recall quite a bunch of issue reports from your side recently19:17
keriohuh, my wifi?19:18
kerioit doesn't work under rescueOS either19:18
DocScrutinizer05so what?19:18
kerioso... it's not smartreflex?19:18
DocScrutinizer05that's implying the assumption about non-permanent damage from SR only being a true and certified one19:19
DocScrutinizer05you have not even a good error vector analysis for your problems, how do you dare to claim they are unrelated to SR?19:20
DocScrutinizer05have 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?19:21
*** DrCode has joined #maemo-ssu19:21
DocScrutinizer05have you verified every single other of the bazillion possibilities how SR and your problem could be related?19:22
kerionope, i have not19:22
DocScrutinizer05please f* off with "WFM"!19:22
kerioi also haven't verified that my aunt's toaster is causing the wifi problem19:22
DocScrutinizer05you simply lack the technical background to contribute anything meaningful to this discussion19:23
Sc0rpius:O19:25
DocScrutinizer05sorry for sounding like a dick, but that "WFM" pattern is a recurring PITA since 10 years, since evrybody thinks they are experts19:28
DocScrutinizer05WFM == watch f*cking moron19:29
FatPhilIt's certainly possible that Igor Stoppa made some pronouncements about OC, and that would probably have been in 2009 @ MDC in Amsterdam?19:29
DocScrutinizer05yes, sounds about right19:30
FatPhilkerio: I have, in a lab environment, seen memory corruption on some devices when SR was enabled.19:30
FatPhilIt was a silicon quality issue, IIRC, and some devices were worse than others.19:30
DocScrutinizer05here you are19:30
DocScrutinizer05sure thing, for that class of problem19:31
DocScrutinizer05did you consider modified Vcore and Vram for the OPPs?19:31
FatPhilI wasn't in the PM team19:32
FatPhilbut I'm sure they did19:32
DocScrutinizer05I am rather sure that team was savvy enough to consider that fix19:32
FatPhilI was only called onto the problem because one of the guys knew that I could interpret hex stack dumps, and solve logic problems.19:33
FatPhilOh, yeah, the team was savvy.19:33
DocScrutinizer05so 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 problem19:33
DocScrutinizer05but *generally* SR *can not get fixed*19:34
DocScrutinizer05it _might_ work for you, or not19:35
DocScrutinizer05odds are it probably will work19:35
* ShadowJK has recently been experimenting with limiting cpu to 500MHz while he's at work and mostly listening to podcasts19:36
FatPhiland any conclusion that it seems to be working for you tells you *nothing* about any other device19:36
ShadowJKI wonder where the sweet spot would be19:36
DocScrutinizer05but 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 corruption19:37
DocScrutinizer05or even CSSU-Stable update19:37
DocScrutinizer05or your toaster19:37
DocScrutinizer05(the last one specially for kerio ;-D )19:38
FatPhilhe's the kind of person who overclocks his toaster, is he? Does that affect buttery usage?19:39
DocScrutinizer05it makes life easier when your butter is cold19:39
kerioyou just need to avoid heat issues so the bread doesn't get burnt19:40
kerioinstall a liquid nitrogen cooling system19:40
keriocoldest toaster ever19:40
freemangordonFatPhil: what I discovered re SR, is that calibrations in EFUSE, which are supposed to be different for every device, are acually the same19:40
freemangordonfor frequencies - 500, 550, and 60019:41
DocScrutinizer05kerio: sorry! I went a bit upset. But honestly nobody on earth could tell the side effects of RAM data corruption19:41
*** discopig has quit IRC19:42
DocScrutinizer05freemangordon: so what? Nokia and TI decided they disable/block/discard SR anyway, so why should they take care about those efuse tables?19:42
freemangordonFatPhil: 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-Opp519:42
kerioDocScrutinizer05: i think his point is that he finds instability with the stock values but not with his corrected values19:42
freemangordonDocScrutinizer05: and why those are different for OPP1 and Opp2? why are those programmed even?19:43
DocScrutinizer05quite possible but largely unrelated to the original issue19:43
freemangordonFatPhil: 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 idea19:44
DocScrutinizer05freemangordon: 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 assumptions19:44
freemangordonI can, as long as it works19:45
freemangordonbecause this is all I have19:46
DocScrutinizer05I'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 patch19:46
freemangordonI don;t have access ti TI internal memos, whatnot19:46
freemangordonDocScrutinizer05: and you're statement is based on what but assumtions?19:46
DocScrutinizer05on reports from somebody inside Nokia19:47
freemangordonabout sierr?19:47
DocScrutinizer05see backscroll19:47
freemangordonAnd I explained how those memory errors are related to the wrong calibration values, iirc19:48
DocScrutinizer05no, you explained how SOME memory errors are attributable to flawed SR tables in EFUSE19:49
*** discopig has joined #maemo-ssu19:50
freemangordonah, I see your point. Well I can't explain memory errors I don;t see, sorry19:50
DocScrutinizer05you however didn't explain how you are going to catch the last 0.5% of devices that have flawed chips19:50
freemangordonDocScrutinizer05: WHY 0.5%?19:51
freemangordonwhy19:51
DocScrutinizer05and SR got disabled for sake of those 0.5%19:51
freemangordonno, SR doesn't work on maybe 50% without that patch19:51
DocScrutinizer050.5% because I had to pick an arbitrary number that might please you19:51
DocScrutinizer05freemangordon: you're missing the point still19:52
DocScrutinizer05freemangordon: 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 patch19:52
freemangordonI don;t. What I say, is that you don;t have any hard facts that anything is broken besides EFUSE calibration19:53
DocScrutinizer05it's those 0.007% that Nokia decided to keep SR out19:53
DocScrutinizer05THEHECKK! see backscroll!!!19:53
freemangordonDocScrutinizer05: I see no hard facts there19:53
DocScrutinizer05honestly you can't be that dull!19:54
freemangordonthat anything but EFUSE calibration is broken19:54
DocScrutinizer05MEH! futile19:54
freemangordon:nod:19:54
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?20:00
DocScrutinizer05s/D/S/.20:00
DocScrutinizer05answer: 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 issues20:02
DocScrutinizer05concluding a "they must have barred the house because without railings it's of course dangerous" is silly20:03
freemangordonDocScrutinizer05: EFUSE calibrations are done while the SoC is manifactured, Nokia has nothiing to do with it20:04
DocScrutinizer05so what?20:05
DocScrutinizer05what is your brilliant patch to fix that problem that Nokia and TI never thought of?20:06
ShadowJKFrom 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"20:07
*** Milhouse has joined #maemo-ssu20:07
DocScrutinizer05when 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?20:07
DocScrutinizer05this 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 defect20:13
*** luf has joined #maemo-ssu20:14
freemangordonDocScrutinizer05: and who "paid" for the thumb2 SiErr?20:14
kerioprobably TI, by reducing the cost of each chip by $amount20:14
freemangordonluf: hi!20:14
luffreemangordon: hello20:14
DocScrutinizer05even 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 bakers20:15
DocScrutinizer05freemangordon: obviously for thumb2 it's TI to pay, but maybe they got refunded by ARM20:15
freemangordonDocScrutinizer05: 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 measurement20:16
FatPhilDocScrutinizer05: 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"20:16
DocScrutinizer05FatPhil: sounds reasonable20:16
FatPhili..e it definitely was shitty hardware earlier! :-)20:17
*** Milhouse has quit IRC20:17
DocScrutinizer05what i said20:17
freemangordonFatPhil: and are there N900s in the wild with the "old" silicon?20:17
DocScrutinizer05he doesn't know20:17
FatPhilTrying to work out how to tell silicon versions...20:18
DocScrutinizer05on system level it's easy20:18
DocScrutinizer05read out /proc/cpu or somesuch20:18
FatPhilThere are definitely different spins out in the real world, yes20:18
freemangordonbecause I have 2101 HW revision, which seems to be the lowest in production (in the wild)20:19
DocScrutinizer05CPU variant     : 0x120:19
DocScrutinizer05CPU part        : 0xc0820:19
freemangordonI don;t know if HW revision is related to SoC revision, but I guess so20:19
DocScrutinizer05CPU revision    : 320:19
DocScrutinizer05one of those *might* have the info you're looking for20:20
FatPhilneither of those is the distinguishing feature20:20
DocScrutinizer05freemangordon: nope, hw revision is not directly related to SoC revision20:20
freemangordon:(20:20
FatPhilGonna sniff some nolo console logs....20:21
*** dafox has joined #maemo-ssu20:22
DocScrutinizer05spruf9820:22
DocScrutinizer05good luck, it's somewhere in those 3000+ pages20:22
DocScrutinizer05search for "mask" maybe20:23
FatPhilshit, no I'm not, until I find a kettle lead...20:23
FatPhilanyone shouting "look on the kettle" gets a slap20:24
DocScrutinizer05been adressed at freemangordon20:24
freemangordonwould that do the job?20:25
freemangordonIDCODE: 4b7ae02f20:25
freemangordonProduction ID: 00000000 00000000 000000cc cafeb7ae20:25
freemangordonDie ID: 0a003019 04036ec2 00000000 3ec6000420:25
DocScrutinizer05I 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 not20:25
DocScrutinizer05Die ID sounds good!20:26
freemangordon"/sys/power/idcode"20:26
DocScrutinizer05Die ID: 0c004012 040364fb 00000000 44f6000420:27
DocScrutinizer05now for the _insider_ this tells 100% unabiguous if that chip is prone to SR probelms or not20:28
FatPhilDie ID: 0200600a 04014023 00000000 1fde0004   <- early silicon20:28
freemangordonFatPhil: which is the magic walue we should look for?20:29
freemangordonvalue*20:29
DocScrutinizer05that's not THAT easy ;-)20:29
FatPhilNFI, alas20:29
freemangordonwell, maybe with a bit of bitmasking :)20:29
DocScrutinizer05probably spruf98 has some instructions how to dissect and transcode this Die ID20:29
FatPhilAnd NFKL either (neither the kettle nor the underclocked toaster has one)20:29
FatPhilAlas anything 3530 won't necessarily have any bearing on 3430 things20:31
*** arcean_ has joined #maemo-ssu20:31
DocScrutinizer05indeed20:33
DocScrutinizer05and for "our" chip you hardly get *any* info at all20:33
*** arcean has quit IRC20:33
DocScrutinizer05so sorry, my hint / pointer to SPRUF98 been a red herring20:34
DocScrutinizer05I'm absolutely sure the Die ID bitmask has no dedicated bit for "SR supported/not supported"20:35
DocScrutinizer05so it's futile after all, since you don't know anything useful from that whole info about Die20:36
DocScrutinizer05you just have to live with the fact that SR is most probably broken for a (possibly small) percentage of N90020:38
FatPhilIt also probably depends on twl4030 version too20:39
DocScrutinizer05and no patch can fix that20:39
DocScrutinizer05indeed20:39
DocScrutinizer05USB PHY (->hostmode) problem definuitely did20:40
DocScrutinizer05can 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?20:42
FatPhilThat's the fairest summary.20:44
freemangordonsure, but I still wait for someone to report instabilty. For stock frequencies that is.20:47
DocScrutinizer05sure, would be very interesting to find a device that's riddled by this SR problem20:47
freemangordonif such device exists, as I still think the only problem is the broken calibration :)20:48
DocScrutinizer05no, there definitely been another problem, and it's just the question if it leaked from prototypes into mass production20:49
DocScrutinizer05we can't tell about that, since we got no way to find out20:50
DocScrutinizer05until we find first device that actually exhibits the problem and then we know it leaked into mp. But we never can prove it didn't20:50
freemangordonDocScrutinizer05: 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 there20:50
DocScrutinizer05interesting factoid20:51
freemangordonwhen she got the device, there were some applications I saw for the first time, and the PR version was before PR1.0 iirc20:52
dos1still could be the same WFM syndrom as discussed earlier20:52
freemangordondos1: 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 there20:53
dos1yeah, probability is small20:54
dos1but non-zero :D20:54
DocScrutinizer05"you don't see" is a moot point20:55
DocScrutinizer05up to anybody's guess but the fab manager to tell which devices have which SoC20:55
FatPhilTo Nokia, if one person has a 1 in a 1000 chance of ever seeing it, then hundreds of people will return their device.20:56
DocScrutinizer05don't think they come from TI one by one and get assembled to PCB just in time. there are batches20:56
DocScrutinizer05wild speculations about "I don't see how...." - we can as well stop that as it doesn't get us anywhere20:58
DocScrutinizer05nuff say, FatPhil commented on my final relevant statement in an acknowledging way. That's just fine for me. I'm out20:59
*** Milhouse has joined #maemo-ssu21:01
*** Vlad_on_the_road has quit IRC21:05
FatPhilI'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.21:06
FatPhilDie ID: 0401901e 040360e0 00000000 1e14000421:06
FatPhilI have several other devices at home home21:07
*** Milhouse has quit IRC21:08
*** FlameReaper has joined #maemo-ssu21:10
FatPhilThe code's hilarious:21:11
FatPhil * @brief twl_workaround - implement errata XYZ21:11
FatPhil * XYZ errata workaround requires the TWL DCDCs to use21:11
FatPhil * HFCLK - for this you need to write to all OSC regs to21:11
FatPhil * enable this path21:11
*** arcean_ has quit IRC21:12
FatPhilAnd I think that was one of the SR-related bugs21:13
FatPhil        if ((TWL_SIL_TYPE(twl4030_rev) == TWL_SIL_5030) &&21:13
FatPhil                (TWL_SIL_REV(twl4030_rev) <= TWL_REV_1_1))21:13
FatPhil                apply_workaround = 1;21:13
freemangordonFatPhil: i sthat released?21:14
DocScrutinizer05yup21:14
DocScrutinizer05definitely looks like SR related21:15
freemangordonyep, released, it is in KP21:17
*** Milhouse has joined #maemo-ssu21:20
freemangordonFatPhil: description of XYZ: http://gitorious.org/angstrom/angstrom-linux/source/3669413721fc8b84607f093d128a0f8dde7c3157:drivers/mfd/twl4030-power.c#L54921:20
*** iDont has joined #maemo-ssu21:24
freemangordoniDont: I pushed bb-power in thumb repo finally, sorry for the delay21:25
iDonthi freemangordon, thanks and don't worry about the delay21:26
*** Milhouse has quit IRC21:26
freemangordon:)21:26
iDontthose who want to run the latest version before it hits the repos, can always find debs in bb-power's garage page21:27
freemangordonthumb2 version? ok21:27
iDontyeah, all variants can be found there. It's always a lot of work to upload every file separately with each release :P21:28
freemangordoniDont: I just use mc ;)21:28
iDontyou can automate uploading to the files section of garage pages?21:29
freemangordonNFC, I just select all the files and press F521:29
iDontah ok21:30
*** Milhouse has joined #maemo-ssu21:38
freemangordonPali: 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 upstreamed21:43
freemangordons/DSP/DSB/21:43
infobotfreemangordon meant: Pali: hmm, iiuc what Dave says, something like " @not really sure DSB it is needed here, copied from omap_smc2()" could finally make him happy so we'll have that patch upstreamed21:43
*** Vlad_on_the_road has joined #maemo-ssu21:44
Palifreemangordon: will you create new patch?21:45
freemangordonPali: no :)21:46
freemangordonI have nothing set up here, sorry21:46
freemangordonPali: is thre any problem on your side, besides free time?21:46
freemangordon*thre21:47
freemangordonWTF?21:47
freemangordonTHERE21:47
Palino nothing21:47
*** Milhouse has quit IRC21:49
freemangordonIt will just take me lots more time to clone, set up git email, learn how to use it, ets21:50
ShadowJKhey my N900 just crashed :(21:50
freemangordonmaybe I should do that anyway someday, but not now :)21:50
ShadowJK(I/O stall/deadlock that's been hitting me every 1-7 weeks since 2009)21:51
DocScrutinizer05ShadowJK: weird stuff, I never seen such IO deadlock21:51
freemangordonShadowJK: hmm, do you use sto VM settings?21:52
DocScrutinizer05ShadowJK: which fs?21:52
DocScrutinizer05ShadowJK: which interface?21:52
DocScrutinizer05ShadowJK: which kernel?21:52
freemangordonwtf is with my kbd?!?21:53
freemangordon*stock21:53
DocScrutinizer05bread crumbs21:53
DocScrutinizer05I know that effect ;-D21:53
DocScrutinizer05particularly bad on laptop type short stroke keys21:54
freemangordonhmm, no, it is full size PC105 kbd attached to my desktop21:54
ShadowJKnr_requests modified, min-free inxcrease21:55
ShadowJKemmc stall21:55
DocScrutinizer05lot of full size kbds with laptop keys out there21:55
DocScrutinizer05one in front of me, typing on it21:55
DocScrutinizer05ShadowJK: ext3?21:56
freemangordonShadowJK: tweak page-cluster and swappiness21:56
DocScrutinizer05or whole MMC phy interface?21:56
DocScrutinizer05well, I guess you can't tell21:57
*** Milhouse has joined #maemo-ssu22:04
ShadowJKIt looks more like kernel stops processing requests22:08
ShadowJKI've had it happen with various page-cluster and swappiness settings too22:09
ShadowJKFeels like it happens more often with lower swappiness22:09
freemangordonmore often? weird.22:11
*** Milhouse has quit IRC22:11
DocScrutinizer05ShadowJK: syslog on NAND?22:16
DocScrutinizer05or even: you checked mtdoops?22:17
freemangordonDocScrutinizer05: on WD kicked in?22:17
DocScrutinizer05whatever it been, i'd hope for it either being diagnosable via shell, via syslog, or via kernel OOPS22:18
DocScrutinizer05when MMC interface blows chunks, syslog on NAND and mtdoops partiton (also NAND) are your best options22:19
ShadowJKit was wd reboot22:19
ShadowJKThere's never anything in logs, and kernel doesn't oops22:20
*** Milhouse has joined #maemo-ssu22:23
DocScrutinizer05well, wd doesn't oops22:24
DocScrutinizer05I suggest to disable watchdogs22:24
DocScrutinizer05and enable sysreq keys22:24
DocScrutinizer05only way to get info out of a true kernel freeze22:24
*** Milhouse has quit IRC22:29
*** Vlad_on_the_road has quit IRC22:44
ShadowJKsometimes I can get dmesg and manually T to sysrq-trigger22:44
FatPhilbeware - noise on uart lines can be interpreted as sysrq commands22:45
DocScrutinizer05haha, nice22:54
DocScrutinizer05maybe that's even the *cause* of ShadowJK's problem then22:54
DocScrutinizer05though, wouldn't that need "console tty" or sth on kernel commandline?22:55
FatPhilconsole=tty022:56
DocScrutinizer05afaik _normally_ the UART3 that might be used as console tty is disabled by default22:56
FatPhilthat cmdline gives console logs to the jig when the R&D flags are appropriately set22:56
DocScrutinizer05via kernel cmdline that either gets passed by NOLO or is compiled in to kernel22:56
DocScrutinizer05yep, CAL R&D flags22:57
DocScrutinizer05as long as ShadowJK hasn't set them so tty console gets used, it shouldn't cause any troubles with noise22:58
FatPhilyup22:58
ShadowJKYeah it's not set23:03
*** Martix has joined #maemo-ssu23:06
*** iDont has quit IRC23:25
FatPhilHmm, I haven't had a rant about the insane renaming of the mmc devices recently. That's weird. Cos it's truly insane.23:36
*** Vlad_on_the_road has joined #maemo-ssu23:36
freemangordonFatPhil: 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=HEAD23:37
freemangordon?23:37
FatPhildoes that make it 0 (no card) or 1 & 2 (with card)?23:40
FatPhiland if you add a card, it will be 1. So a card is always 1.23:41
freemangordonthe patch? it makes internal card /dev/mmcblk0 and external /dev/mmcblk123:41
ShadowJKmmc renaming madness was going on in Chinook too :) (and diablo..)23:45
FatPhilEither it's late, or find_next_zero_bit() has a bug...23:47
DocScrutinizer05FatPhil: there's not much you can do about MMC-IF renaming resp not renaming23:48
*** FlameReaper has quit IRC23:49
DocScrutinizer05the 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 to23:50
ShadowJKFatPhil; is that used in swapout?23:51
DocScrutinizer05if no uSD is inserted, then kernel skips to next mmc interface which happens to be connected to eMMC, and that one is named mmcblk0 then23:51
FatPhilOK, didn't know about the booting-from-uSD reasons, that almost makes the behaviour sensible23:54
DocScrutinizer05:nod:23:54
FatPhilYEah, reading the patch, it does enumerate them as you say.23:55
FatPhilit's late....23:55
DocScrutinizer05if it wasn't for booting, the EE had for sure mounted eMMC to UF1 and uSD to IF223:55
DocScrutinizer05s/UF/IF/23:55
infobotDocScrutinizer05 meant: if it wasn't for booting, the EE had for sure mounted eMMC to IF1 and uSD to IF223:55
FatPhilHowever, I still think find_next_zero_bit has a bug!23:55
DocScrutinizer05if you share a http: URL, i'm willing to review it23:56
DocScrutinizer05preferably http://mxr23:57
FatPhilso, does the fanoush patch mess up uSD booting?23:57
FatPhilthat's a silly question23:57
DocScrutinizer05http://mxr.maemo.org/fremantle/source/kernel/drivers/23:57
DocScrutinizer05indeed ;-D23:58
DocScrutinizer05as long as it doesn't patch BOOTROM, x-loader or NOLO, it prolly doesn't23:58
FatPhilI think I like the fanoush patch!23:59
« Tuesday, 2013-09-03 Index Thursday, 2013-09-05 »

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!