**** BEGIN LOGGING AT Sun Jan 17 02:59:56 2010 Jan 17 03:48:37 DocScrutinizer-8: huhu Jan 17 03:48:44 hihi Jan 17 03:49:02 should I say "haha"? Jan 17 03:49:08 k for the Jbt7kfoo driver: Jan 17 03:49:49 we use a suspend mode there which is *completely* useless and really icky to handle Jan 17 03:51:08 The driver in the .32 tree disables the jbt completely, as in turns regulators off Jan 17 03:51:15 the idea is to power down the LCD (jbt6k74 chip) *completely* by disabling 3V3_LCM via PMU LDO Jan 17 03:51:29 yep. that's the idea Jan 17 03:52:52 and we MUST take care to switch *all* data lines and clocks and foo which run to ylcm chip to either logical low aka 0V or to high-Z aka input Jan 17 03:53:21 not to reverse feed the chip via e.g. the video data lines from glamo to lcm Jan 17 03:54:31 yup Jan 17 03:54:57 then on resume somebody (kernel, maybe bootloader (too)) has to initialize the whole junk much the same way it's done on power on Jan 17 03:55:32 yup Jan 17 03:56:10 finally we should reach a state were we see no difference in LCM handling between resume and power on. Jan 17 03:56:43 and as we never seen a WSOD on power on, this should cure the issue for suspend as well Jan 17 03:59:05 btw for the data/clock states during suspend a output+low is preferable to a high-z state. active pull down, you know :-) Jan 17 03:59:50 i've seen lots of WOSDs on power on Jan 17 04:00:32 lars_: so *all* the jbt foo is solidly drawn to unpowered state' even the possibly esisting Cs etc Jan 17 04:00:42 lars_: duh Jan 17 04:01:01 if we are going to reintialize glamo completely we could cut it's power aswell, i guess? Jan 17 04:01:27 we can't cut glamo power afaik Jan 17 04:01:39 we have no way to do it Jan 17 04:02:01 not sure about that though Jan 17 04:03:39 hm... the regulator is shared between serveral components Jan 17 04:04:22 yep Jan 17 04:04:33 that's what I thought Jan 17 04:09:00 it can be a vreg driver? Jan 17 04:10:06 errm huh? Jan 17 04:10:39 the jbt driver Jan 17 04:10:48 it's really just a special vreg Jan 17 04:11:12 AAAH VReg Jan 17 04:11:38 when will linux really map to soc and soc hardware? Jan 17 04:13:38 well I guess that's what it is done like in .32 Jan 17 04:14:27 to care about the data/clock lines is quite beyond vreg though Jan 17 04:15:24 yeah, but until mux scenarios make it Jan 17 04:15:49 it's easier just to wrap them with vreg or rfkill or some other partial abstraction Jan 17 04:16:51 sorry not my domain, to be honest Jan 17 05:03:13 vreg? **** ENDING LOGGING AT Sun Jan 17 06:31:16 2010 **** BEGIN LOGGING AT Sun Jan 17 06:31:40 2010 Jan 17 06:40:43 voltage regulator, it's a kernel api that represents a hardware register that controls amount of current a device can draw as well as on/off Jan 17 10:41:29 moin Jan 17 10:46:39 moin Jan 17 11:38:39 moin Jan 17 11:44:36 moooooooin Jan 17 12:09:03 DocScrutinizer, the sound is breaking for me ..even the signal level is high ..i m using A7 Jan 17 12:09:05 DocScrutinizer, can u help me with this Jan 17 12:11:28 i m using Moko11 gsm firmware Jan 17 12:11:47 UberNeo: what do you mean by "breaking"? Jan 17 12:12:33 it getting cutoff during calls..like wht usually happens when the signals become low Jan 17 12:12:36 UberNeo: and GSM fw 11 has nothing to do with it. But I gather you're taking care. That's fine :-) Jan 17 12:13:20 does the call terminate? or is it audio dropouts? Jan 17 12:13:35 audio dropouts Jan 17 12:13:42 which distro? Jan 17 12:13:53 SHR-U ..sep image Jan 17 12:13:54 moin PaulFertser Jan 17 12:14:17 DocScrutinizer: moin :) Jan 17 12:14:22 please update to testing as mentioned in /topic Jan 17 12:14:46 err should... Jan 17 12:15:01 WTF? Do I have to lock the topic? Jan 17 12:16:11 also in frameworkd.conf file i have put "ti_calypso_dsp_mode = none" Jan 17 12:17:11 UberNeo: in the newer testing there're two volume slider during call that you might want to tweak. Should help. Jan 17 12:17:31 please update to testing Jan 17 12:17:48 as not mentioned in /topic Jan 17 12:17:52 ;-P Jan 17 12:18:29 but i am using SHR-U ..sep image ..and previously it was fine .. Jan 17 12:20:06 DocScrutinizer, and its not happening everytime ..sometimes the sound is smooth Jan 17 12:20:40 hmm you might have either messed up some mixer settings or the dsp mode, or you got a hw bug or simply a flaw in your carrier's exchange and audio postprocessing Jan 17 12:21:44 anyway please update to testing, as almost everybody meanwhile lost knowledge about september U flaws and catches Jan 17 12:22:42 OK ..btw is there any other way to increase the call volume ..except making the control 4 level as 127 max in gsmhandset.state file Jan 17 12:22:57 or you simply reflash your beloved 0808(?) (0906?) U version again Jan 17 12:23:59 UberNeo: yes, there's AT+CLVL= cmd (or similar) Jan 17 12:24:16 should be set to max by FSO Jan 17 12:24:33 where do i need to make changes for that Jan 17 12:24:50 you should not make changes to that Jan 17 12:24:59 should be set to max by FSO Jan 17 12:26:32 though I seem to remember some evil friggin hackers used that cmd to implement a volume control at a certain timespan in the past - until I shot them down :-P Jan 17 12:29:57 heyho Jan 17 12:30:19 ho hey Jan 17 12:32:15 DocScrutinizer, i gave AT+CLVL=6 ..now the volume is very low after this Jan 17 12:32:27 so??? Jan 17 12:32:41 i dont know wht was default Jan 17 12:33:08 or what max i can give for AT+CLVL Jan 17 12:33:11 me neither. something like 127 or 200 Jan 17 12:34:02 UberNeo: reset the modem and then ask for AT+CLVL? and AT+CLVL=? to see default? Jan 17 12:35:38 lindi-: that's not exactly helpful. As I mentioned before you 1)should NOT mess around with AT+CLVL as 2) FSO is supposed to set it (and that might be a value NOT equal to modem's default after reset) Jan 17 12:36:44 DocScrutinizer: sure but it is is always good to verify that the expected things happen Jan 17 12:37:18 when i set AT+CLVL=200 ..i m getting the old high volume but the voice is still breaking :( Jan 17 12:37:41 lindi-: what *are* the expected things? I don't even have an idea if there is *any* modem default for CLVL Jan 17 12:38:01 DocScrutinizer: well the first command was about discovering what the default value is :) Jan 17 12:38:27 DocScrutinizer: then you read the source to find out what fso is trying to set it and see if it differs from the default Jan 17 12:38:45 lindi-, AT+CLVL? give me 200 Jan 17 12:38:47 then finally you can query the value and see if it is the default or the one that fo sets it to Jan 17 12:39:04 * DocScrutinizer sighs and anders off Jan 17 12:39:07 UberNeo: what AT+CLVL commands has FSO sent to the chip? Jan 17 12:39:50 lindi-, tht i m not sure Jan 17 12:40:16 UberNeo: if you want to understand the issue you migt want to check that out Jan 17 12:40:41 * DocScrutinizer returns for a second, just to sarcastically suggest you concentrate on cpu clock scaling deviders rather than AT+CLVL, to fix UberNeo's problem Jan 17 12:42:02 cpu clock scaling? Jan 17 12:42:48 not good? how about PMU regulator setting fpor cpu core voltage then? Jan 17 12:43:29 DocScrutinizer: has that caused audio issues in the past? Jan 17 12:43:48 has AT+CLVL? Jan 17 12:43:54 the max which i can set on AT+CLVL=250 Jan 17 12:44:09 255 Jan 17 12:44:17 DocScrutinizer: afaik yes when it was not set to maximum value? Jan 17 12:44:18 so wtf? Jan 17 12:44:24 are you happy now? Jan 17 12:44:40 DocScrutinizer: hmm? Jan 17 12:46:07 let me anticipate UberNeo's very next posting: "on 250 sound still broken" Jan 17 12:46:49 and [2010-01-17 13:24:50] you should not make changes to that Jan 17 12:47:03 [2010-01-17 13:24:59] should be set to max by FSO Jan 17 12:47:15 UberNeo, +CLVL: 175 Jan 17 12:47:25 playya: are you using FSO? Jan 17 12:47:30 DocScrutinizer, you are absolutely right ..ther volume has bit increased but sometimes its still broken Jan 17 12:47:31 yes Jan 17 12:47:46 playya: I guess FSO does not set it to max then? Jan 17 12:47:51 hooray. now we got enough helping hands to *finally fix* that *friggind clvl issue* Jan 17 12:48:09 let me check the source Jan 17 12:48:30 i just used mickeyterm and AT+CLVL? Jan 17 12:48:40 * DocScrutinizer away for good. Good luck and enjoy your sunday afternoon leissure hacking Jan 17 12:49:56 AT+CLVL=255 has really helped a lot Jan 17 12:50:41 playya: I only find DeviceSetSpeakerVolume but nothing that calls it Jan 17 12:51:25 then it might be a dbus method and should be called from e.g. SHR Jan 17 12:51:53 playya: aha, it bypasses its own api Jan 17 12:51:59 playya: ./framework/subsystems/ogsmd/modems/ti_calypso/channel.py: c.append( "+CLVL=255" ) # audio output: set to maximum Jan 17 12:52:07 playya: and does not set the volume using SetSpeakerVolume Jan 17 12:53:20 because IT IS NOT *SUPPOSED* TO BE USED FOR SETTING SPEAKER VOLUME!!!1!11!!!1111!! Jan 17 12:54:00 needs to be 255 AND NOBODY EVER TOUCH IT Jan 17 12:54:10 period Jan 17 12:56:23 DocScrutinizer, it means ..the max which we can get is byr AT+CLVL=255 and control 4 value =127 in gsmhandset.state file Jan 17 12:56:41 and btw. please don't ping me about it ever again unless you make a *good* story out of it why it can _cause_ _dropouts_ Jan 17 12:56:48 DocScrutinizer: well it seems that in playaa's case something set it to 175 -- we need to figure out what to fix it Jan 17 12:57:37 DocScrutinizer: also fso might want to remove the API for setting speaker volume if it is not meant to be set Jan 17 12:57:37 lindi-, AT+CLVL=175 is lowering the volume Jan 17 12:57:59 playya: any idea what in your system could be setting it to 175? Jan 17 12:58:00 grrrrrrrrrrrrrrrrrRRRRRRRRRRRRrr Jan 17 12:58:23 set-speaker-volume probably does the right thing: change control#4 in mixer Jan 17 12:59:48 (why in your system...) maybe because that's a system prior to the point where I convinced mickey to set it to 255. 175 was old value Jan 17 13:00:25 lindi-, nope Jan 17 13:00:58 playya: can you configure ogsmd to log all traffic and look at the AT+CLVL commands? Jan 17 13:01:50 let me check if ogsmd is that flexible Jan 17 13:04:58 UberNeo: please switch to SHR-testing Jan 17 13:05:22 yes..i m downloading the latest image Jan 17 13:10:07 ok. restarting Jan 17 13:10:29 keep your fingers crossed that i didN't break frameworkd Jan 17 13:12:27 nice. enlightenment segfaulted Jan 17 13:15:43 yeah, that happens quite often on my phone too :( Jan 17 13:16:02 have you tried to attach gdb to the process? Jan 17 13:20:28 to a python script ... Jan 17 13:22:06 last time I checked enlightenment was written in c ;) Jan 17 13:27:26 ah. i thought you meant frameworkd Jan 17 13:29:04 lindi-, maybe it's affiliated to: WARNING Attempted to send something while serial is not open. Jan 17 14:03:30 playya: hard to say. full log and bug report? Jan 17 14:15:42 i think it's fsodeviced, because i only have GPS and GSM resource Jan 17 15:08:52 <\marco> hi to all Jan 17 15:09:50 <\marco> I've some problem after last upgrade of the unstable image ( I know upgrading isn't supported ^_^ but, maybe, it's not related ) Jan 17 15:10:08 <\marco> I've no ringtone or msgtone Jan 17 15:10:18 <\marco> and the frameworkd.log says: Jan 17 15:10:27 <\marco> 2010.01.17 16:05:44.728 oeventsd.action ERROR signal StopSound emited an error org.freedesktop.DBus.Error.ServiceUnknown: The name org.freesmartphone.odeviced was not provided by any .service files Jan 17 15:12:09 \marco: do you have fsodeviced installed? Jan 17 15:12:21 it's not running and it can't be activated Jan 17 15:12:50 <\marco> checking.. :) Jan 17 15:12:57 <\marco> root@om-gta02 ~ $ opkg list_installed | grep fsodeviced Jan 17 15:12:57 <\marco> fsodeviced - 1:0.9.0+gitr895+1b329ccc044eb087a6f8a7c7c61022c162f51ab2-r1.6.4 Jan 17 15:13:52 <\marco> the service isn't running Jan 17 15:14:00 <\marco> trying again Jan 17 15:14:05 \marco: /etc/init.d/fsodeviced restart? Jan 17 15:14:26 JaMa: shouldn't it get activated by dbus? Jan 17 15:14:26 <\marco> JaMa: I've just started it.. trying again ;) Jan 17 15:14:55 PaulFertser: IIRC just fsousaged is and fsogsmd was Jan 17 15:15:02 <\marco> mhm Jan 17 15:15:07 <\marco> no dice Jan 17 15:15:22 <\marco> ps says there's no fsodeviced process Jan 17 15:15:22 \marco: and running fsodeviced from terminal? Jan 17 15:15:33 do you have /etc/freesmartphone/fsodeviced.conf? Jan 17 15:15:48 <\marco> mhm no Jan 17 15:15:52 <\marco> no fsodeviced.conf Jan 17 15:16:07 opkg files fsodeviced doesn't show that file? Jan 17 15:16:20 <\marco> let me see Jan 17 15:16:31 <\marco> root@om-gta02 ~ $ opkg files fsodeviced Jan 17 15:16:31 <\marco> Package fsodeviced (1:0.9.0+gitr895+1b329ccc044eb087a6f8a7c7c61022c162f51ab2-r1.6.4) is installed on root and has the following files: Jan 17 15:16:31 <\marco> root@om-gta02 ~ $ Jan 17 15:16:34 <\marco> nice :D Jan 17 15:16:46 \marco: and you have different version than I have.. 1:0.9.0+gitr24+44a4aabf382995c9f3141ec09b202f0e569a484d-r1.9.4 Jan 17 15:16:54 \marco: great upgrade you had there :) Jan 17 15:16:59 <\marco> :D Jan 17 15:17:21 \marco: when did you run opkg update? :) Jan 17 15:17:23 ~curse opkg Jan 17 15:17:28 May you be reincarnated as a Windows XP administrator, opkg ! Jan 17 15:17:32 <\marco> JaMa: few minutes ago :P Jan 17 15:19:03 <\marco> should I try to reinstall fsodeviced? Jan 17 15:19:49 <\marco> mhm.. I've two different version of fsodeviced in the pkg tree Jan 17 15:20:05 <\marco> r895 and r898 Jan 17 15:20:50 <\marco> oh.. maybe the version is the last part :P Jan 17 15:21:01 <\marco> r1.6.4 and r1.9.4 Jan 17 15:22:05 <\marco> mhm Jan 17 15:22:08 <\marco> ok Jan 17 15:22:21 <\marco> I've start another opkg upgrade Jan 17 15:22:34 <\marco> it's upgrading fsodeviced now :/ Jan 17 15:22:49 mrmoku: any idea why fsodeviced moved from armv4 arch to om-gta02? Jan 17 15:23:16 ouch, no Jan 17 15:23:19 mrmoku: maybe it happen everytime you add device specific patch/source Jan 17 15:23:24 <\marco> the question is: why opkg didn't upgrade it the first time? Jan 17 15:23:37 ohh, probably because there is device specific config now :( Jan 17 15:23:45 mrmoku: which make sense.. because you can have multiple packages in same feed for multiple devices Jan 17 15:23:58 JaMa: probably the config should be in a different package Jan 17 15:24:09 like it is done with frameworkd Jan 17 15:24:12 mrmoku: no I think it's fine.. Jan 17 15:24:29 mrmoku: just that older package shouldn't be in feed (rsync --delete :)) Jan 17 15:24:36 :) Jan 17 15:24:40 yeah Jan 17 15:24:48 mrmoku: and opkg should pick newest (from om-gta02 dir) Jan 17 15:24:51 <\marco> ok.. all it's working, now. Seems to be some not-upgraded pkgs Jan 17 15:25:09 because in opkg.conf is arch priority set that om-gta02 is higher Jan 17 15:25:10 brb Jan 17 15:26:31 <\marco> thanks you all for the help :) Jan 17 15:28:17 ^^ that's kind of users i like. They ask specific questions, they provide relevant parts of logs... Why the hell not everybody is like that? :( Jan 17 15:29:46 ok, what is the most annoying phonefsod/phoneuid bug I should take a look at? Jan 17 15:30:41 <\marco> :D Jan 17 15:31:01 <\marco> thank you PaulFertser :) Jan 17 15:33:17 mrmoku: feed nuked.. (but IIRC I did it once already :)) Jan 17 15:33:41 mrmoku: and last fsodeviced without machine specific config is still there.. Jan 17 15:33:53 mrmoku: but should be ignored by opkg (unless you have om-gta01) Jan 17 15:34:59 <\marco> mhm.. when I rotate the screen with xrandr (leaving out the noise problem) and revert it to normal orientation, the display seems shifted up ( but the touching area is the same..) is this a known problem? Jan 17 15:35:14 * DocScrutinizer51 yawns with passion Jan 17 15:42:37 yeeeha. raining on the snow and frozen floor Jan 17 15:42:51 <\marco> if I connect via VNC the screen is displayed correctly.. Jan 17 15:42:51 * DocScrutinizer51 considers to go back to bed Jan 17 15:43:18 JaMa: python-pygame builds fine here (minimal distro) Jan 17 15:43:44 mickey|sports: last time I hecked it was because of smpeg.. did you try to rebuild smpeg too? Jan 17 15:43:51 s/hecked/checked/ Jan 17 15:43:52 JaMa meant: mickey|sports: last time I checked it was because of smpeg.. did you try to rebuild smpeg too? Jan 17 15:43:58 mickey|sports: hey :-) just tested mdbus on maemo. works great Jan 17 15:44:07 \marco: what x driver are you using? Jan 17 15:44:42 <\marco> lindi-: how can I check? Jan 17 15:44:46 JaMa: smpeg built fine as well Jan 17 15:44:52 DocScrutinizer51: cool :) Jan 17 15:44:56 \marco: what distro? Jan 17 15:45:02 <\marco> shr-unstable :) Jan 17 15:45:15 \marco: opkg list | grep glamo is my very wild guess :) Jan 17 15:45:28 <\marco> eheh ok :) Jan 17 15:45:47 <\marco> root@om-gta02 ~ $ opkg list_installed | grep glamo Jan 17 15:45:47 <\marco> xf86-video-glamo - 2:1.0.0+gitr152+9918e082104340da42eb92b6bdefce4d9266a6a4-r3.4 Jan 17 15:47:02 <\marco> lindi-: any idea? :) Jan 17 15:51:23 TAsn: ping Jan 17 15:51:26 mickey|sports: hmm on my host now too.. I'll retry on shr buildhost.. Jan 17 15:51:43 mrmoku, pong Jan 17 15:51:45 TAsn: I want to fix #758 Jan 17 15:51:50 (offline mode) Jan 17 15:51:50 sec Jan 17 15:52:06 ok Jan 17 15:52:07 cool Jan 17 15:52:14 I suggest you just keep a flag Jan 17 15:52:16 and you wanted to discuss that :) Jan 17 15:52:22 I mean Jan 17 15:52:22 t Jan 17 15:52:29 that just check the previous state Jan 17 15:52:35 if it went from suspended to ready Jan 17 15:52:44 (there is a suspended state, right?) Jan 17 15:52:53 the you should not register and turn ant on Jan 17 15:52:56 otherwise, you should Jan 17 15:52:57 think so, yes Jan 17 15:53:00 oh actually Jan 17 15:53:18 remove last line (the oh actually) Jan 17 15:53:23 I mean, that's great for an easy fix Jan 17 15:53:32 but a way to set offline mode from phonefsod is needed Jan 17 15:53:40 as we may want it to be persistent on reboots Jan 17 15:53:49 with/in/whatever :P Jan 17 15:54:20 are we sure it is phonefsod re-enabling GSM on resume? Jan 17 15:55:24 yes Jan 17 15:55:27 (I think) Jan 17 15:55:32 I think there's a debug message Jan 17 15:55:41 anyone insterested in EFL build 45257? 3 aditional patches were needed to make it compile at all :) Jan 17 15:56:07 mrmoku, brb (getting something to eat) Jan 17 15:56:11 mrmoku, though I'm still mostly here Jan 17 15:56:23 ok, will investigate meanwhile... Jan 17 15:56:31 mrmoku, the most important thing Jan 17 15:56:42 is checking there is a "suspended" state Jan 17 15:56:50 and that it's not just me remembering something not really there Jan 17 15:57:20 worst case, just keep a flag that'll let it turn gsm on only once Jan 17 15:57:27 which is an ugly hack, but is quite ok :P Jan 17 15:57:37 won't hurt anyone atm. Jan 17 16:07:18 mickey|sports: can you please check how your smpeg staging looks like? On my buildhost I "fixed" it 17.12. with that additional link libsmpeg-0.4.so -> libsmpeg-0.4.so.0 http://pastebin.ca/1754793, maybe you have the same from some old build? Jan 17 16:10:06 mickey|sports: I can fix it easily in do_stage() but I was trying to use new staging and failed.. Jan 17 16:13:07 lrwxrwxrwx 1 mickey mickey 21 2010-01-17 16:15 libsmpeg-0.4.so -> libsmpeg-0.4.so.0.1.4 Jan 17 16:13:07 lrwxrwxrwx 1 mickey mickey 21 2010-01-17 16:15 libsmpeg-0.4.so.0 -> libsmpeg-0.4.so.0.1.4 Jan 17 16:13:07 -rwxr-xr-x 1 mickey mickey 295242 2010-01-17 16:15 libsmpeg-0.4.so.0.1.4 Jan 17 16:13:07 lrwxrwxrwx 1 mickey mickey 15 2010-01-17 16:15 libsmpeg.so -> libsmpeg-0.4.so Jan 17 16:13:12 freshly built Jan 17 16:19:36 wow interesting.. Jan 17 16:21:36 <[Rui]> hi! Jan 17 16:27:24 mickey|sports: smpeg-1_0.4.5+svnr370-r0 aka smpeg_svn.bb? Jan 17 16:36:55 PaulFertser: hi, can you please review my patch for https://docs.openmoko.org/trac/ticket/2327? Jan 17 16:38:51 just off-topic question, why you want disable preemption? Jan 17 16:39:19 not really so offtopic :) Jan 17 16:40:11 preemption allows kernel preempt itself, its a nice feature for low-latency systems I think Jan 17 16:40:41 yep, it decrease perfomance little bit, but its improve respond times to irq-s Jan 17 16:40:55 ok, this can be viewed from 3 different points. Jan 17 16:41:29 lets say mine in 1st, what about 2 others? Jan 17 16:41:35 no, from 2 :). 1. from theoretical 2. from testing point of view. Jan 17 16:41:47 first, i have to say that point 2 in not really done Jan 17 16:42:45 I thought spin-lock problems was widely discuccessed Jan 17 16:43:04 wait a bit, i'll decribe in depth :) Jan 17 16:43:09 ok) Jan 17 16:47:04 oh, i rechecked, in fact we have bare numbers of NOPREEMPT+NOPREEMTDEBUG vs PREEMPT+NOPREEMPTDEBUG Jan 17 16:47:16 say we have (2), see http://www.bsdmn.com/openmoko/debugoptstesting/report.txt Jan 17 16:47:32 nopreempt vs DEBUG_PREEMPT lines. Jan 17 16:48:09 so, testing really shown improvement Jan 17 16:49:31 few % Jan 17 16:49:45 now from theoretical. Jan 17 16:49:45 with which tool you did it? lmnmench? I would like test it myself) Jan 17 16:49:59 sure :) Jan 17 16:50:07 i used lmbench 2.5 Jan 17 16:50:52 http://sourceforge.net/projects/lmbench/files/lmbench/2.5/lmbench-2.5.tgz/download Jan 17 16:51:02 3.0 didn't work for me. Jan 17 16:51:19 lmbench build system is quite non-standard Jan 17 16:51:54 i think you'll have hard time to build it with cross-compilation Jan 17 16:52:07 even debian do not include it for arm for some reason Jan 17 16:52:29 you're aware everything <10% is considered mere noise and thus irrelevant? Jan 17 16:53:39 max_posedon: please, tell me if you find any mistakes. in fact, i published kernels and configs, so you can check which options each kernel have. Jan 17 16:54:22 DocScrutinizer: i wrote long essay about noise and revelance for Werner, openmoko-kernel. Jan 17 16:54:42 mrmoku, add lmbench-2.5 to feeds plz Jan 17 16:54:49 OE have it, and it builds fine Jan 17 16:55:09 ( http://tinderbox.openembedded.net/packages/lmbench/ ) Jan 17 16:55:27 DocScrutinizer: quick conclusion - 1. 10%+10%=20%, 2. 10% is huge 3. noise measured in other way Jan 17 16:55:39 max_posedon: nice Jan 17 16:56:16 max_posedon: now, thoretical aspect Jan 17 16:56:58 10% + 10% is 0% as well. 10% is 100% unnoticeable to user. Noise measurement is a very fine art Jan 17 16:58:18 max_posedon: first, what is low latency? this means time to react on user action. you may consider that how (for example in SHR) we have latency measured in seconds. Jan 17 16:58:33 s/how/now/ Jan 17 16:58:33 gena2x meant: max_posedon: first, what is low latency? this means time to react on user action. you may consider that now (for example in SHR) we have latency measured in seconds. Jan 17 16:58:43 I just want be possible answer calls and speak via bluetooth, when I copy smth via wifi to mSD Jan 17 16:59:07 max_posedon, why not? Jan 17 16:59:08 its not about latency of UI, its about latency of irq interrupts Jan 17 16:59:45 with non-preemptable kernel, irq from gsm, can't be handled until mSD driver write smth right now Jan 17 16:59:51 irq interrupts handling is not related to PREEMT. Jan 17 16:59:55 for GPRS coomunication mainsys<->modem a small latency may actually make a huge difference for thruput Jan 17 17:00:36 gena2x, it is! Preemption means, that more priority interrupt can stop(preemtp) other interrupt Jan 17 17:01:15 and do his really important job, and then return to interrupt which was suspended Jan 17 17:01:25 max_posedon i may be wrong, but preemption in case of kernel is ability to interrupt _system call_ Jan 17 17:02:11 http://en.wikipedia.org/wiki/Kernel_preemption Jan 17 17:02:28 max_posedon: this just adds _more_ places to do sheduling. Jan 17 17:02:31 well it's really a bad idea to kick this without really good idea about the impacts to e.g. HDQ readout, or vibrator PWM, or modem GPRS IRQ handling... :-( Jan 17 17:03:01 yep, it will descrise performance Jan 17 17:03:19 but it also allows "priorities to irqs" Jan 17 17:03:19 max_posedon: where is interrupt handling on wiki? Jan 17 17:03:46 max_posedon, no i think this is complete different topic Jan 17 17:04:14 I think rt.wiki.kernel.org is good resource Jan 17 17:04:32 max_posedon: i see exactly what I said on link you provided. Jan 17 17:04:56 I freankly speaking don't know a lot, just played a bit with real time linux kernel Jan 17 17:05:18 max_posedon: real time kernel is another different beast i think. Jan 17 17:05:44 but this features (preemption/tickless system/etc) comes from there Jan 17 17:06:10 also, on that link system call is just example, anyway, main different Jan 17 17:06:31 max_posedon: i think tickless system is other beast. main reason for tickless is power consumptions, but a bit of performance also :) Jan 17 17:06:58 preemptable kernel allows kernel suspend less important not finished handlers to do more important, agree? Jan 17 17:07:14 max_posedon: lets speak strictly on our topic or we'll go to far far travel. Jan 17 17:07:43 I still think that its all about same, about topic of what preempt means) Jan 17 17:07:56 I *completely* fail to see the rationale in messing around with kernel elementary setups to squeeze out maybe 3% *in some cases* and very likely introduce a shitload of new bugs/races/deadlocks whatever. While in userland there is a python based system eating up megatons of memory and heating cpu spinning busy idle. That's totally nuts Jan 17 17:07:58 let finish with interrupts Jan 17 17:08:25 first. Jan 17 17:08:40 do you agree that interrupt are not related to preemption? Jan 17 17:09:46 sorry, I'm not, may be I'm stupid, but still not) Jan 17 17:10:36 so, lets continue on this, topic. wait a bit, i got phoe call Jan 17 17:12:37 DocScrutinizer: not everyone has such a python based system :) Jan 17 17:14:44 DocScrutinizer, you don't know does we still have this issue, but I remember time, when I can listen music on neo, when I typed on illume-keyboard Jan 17 17:14:53 every press music stops for a moment Jan 17 17:14:55 gena2x: lmbench is non-free according to debian Jan 17 17:15:10 every key-press - stopped.. Jan 17 17:15:22 imo preemtion should not be disabled Jan 17 17:15:26 ok, i've back Jan 17 17:15:29 I defenetly want avoid this and similar problems. Jan 17 17:16:05 lars_: have fun. you're facing the *real* experts Jan 17 17:16:47 lindi-: hm... i thought lmbech is in i386 but not for arm somehow, but ok. Jan 17 17:17:03 DocScrutinizer: thank you for constuctive comments Jan 17 17:17:04 I'm stupid monkey, I know), I just still doesn't understand disabling preemption, you can ignore me all, and I'll just try understand all myself) Jan 17 17:17:09 gena2x: $ show-package-versions lmbench | nc paste.dyndns.org 1234 Jan 17 17:17:10 http://paste.debian.net/56942/ Jan 17 17:18:09 (closed wrong window) Jan 17 17:18:30 max_posedon: wait, we are far from finishing. i'm far from ideal too, i know many non-ideal persons also :) Jan 17 17:20:47 lars_: i think that we can disable it and then reenable if we'll get latency problems. Jan 17 17:21:06 gena2x: is lmbench multithreaded? Jan 17 17:21:22 gena2x: lmbench seems to be clearly non-free unfortunately :( Jan 17 17:21:31 lars_: 3.0 is. Jan 17 17:21:59 gena2x: and who's here to decide it's actually latency problems when reports like "batget shows empty bat every 5 minutes" start to pile up?? Jan 17 17:22:27 lindi-: yes, but notice for which arches it was compiled for some reason - only i386 ia64 sparc. Jan 17 17:22:57 gena2x: yep Jan 17 17:22:59 lars_: no, wait, don't really know, may be it is multiprocessor Jan 17 17:23:21 s/multiprocessor/multiprocess/ Jan 17 17:23:22 gena2x meant: lars_: no, wait, don't really know, may be it is multiprocess Jan 17 17:23:47 gena2x: if you only have one process running you will ofcourse see some improvement with preemtion disabled Jan 17 17:24:15 lars_: important question is how much. Jan 17 17:24:28 lars_: will it be measurable. Jan 17 17:24:43 lars_: tests show that it is. Jan 17 17:24:50 but for any real world usecase i doubt that it has any noticable impacts. Jan 17 17:24:59 i can prove it, though Jan 17 17:25:05 s/can/can't Jan 17 17:25:30 lars_: this tests in fact show impact all apllications Jan 17 17:26:16 lars_: NO_DEBUG+NO_PREEMPT at least has noticeable impact on emacs and aptitude :) Jan 17 17:26:21 lars_: context switching time for example, pipe bandwidth, unix domain socket transfer speed - really not single-task tests Jan 17 17:26:47 lindi-: and NO_DEBUG+PREEMT has not? Jan 17 17:26:48 lars_: and this influences whole system Jan 17 17:26:53 lars_: i have not tested Jan 17 17:27:50 lars_: and main problem with the pov 'it's so few % - 5%' is that 5%+%5 in this case is not just 10%, but might be %12 Jan 17 17:28:14 lars_: and in sum, we can get huge benefit Jan 17 17:29:36 lars_: i know, that premmpt is need and recommended for audio recoding distributions, for gaming Jan 17 17:30:40 but we are very far from such kind of load in our freerunner Jan 17 17:30:40 so wtf are you suggesting to disable it for a multimedia targeted device? Jan 17 17:33:28 in fact, as I said before, i did measure of PREEMPT+DEBUG vs NOPRREMT+DEBUG Jan 17 17:34:18 oh, here is trick: it should be PREEMPT+NODEBUG vs NOPREEMPT+NODEBUG Jan 17 17:34:55 that's why i am speaking only about 'debug' in that huge thread (notice /debug in the end of header) Jan 17 17:35:13 Hi ,I have downloaded the latest 15 Jan SHR-U image ..but 2 main problems ..1) I am unable to ssh into into even sshd is running 2)No sound ..neither in call not even ringtone Jan 17 17:35:21 can anybody help me with this Jan 17 17:35:33 UberNeo, I think you load wrong kernel Jan 17 17:35:49 did you forgot flash kernel? Jan 17 17:36:35 so, lets back to theory - testing is not really valid Jan 17 17:37:06 i think that preemption only adds more sheduling points to our poor device. Jan 17 17:37:31 and this is bad, as sheduling in such points impact performance Jan 17 17:37:43 i have flashed the latest kernel http://build.shr-project.org/shr-testing/images/om-gta02/uImage-om-gta02-latest.bin Jan 17 17:38:21 in other side, i see no benefit in having preemption enabled Jan 17 17:38:59 gena2x: scheduling impacts performance every time. So I suggest you discard the scheduler all together. Wll yield the highest performance possible. At least for your test case Jan 17 17:39:03 as we have no problems it designed to fix on desktops where all that sheduling stuff is almost free Jan 17 17:39:17 I think neo require this sheduling points, if you doing smth multitasking Jan 17 17:39:31 DocScrutinizer: yes, that's why people invented tickless kernels ;) Jan 17 17:39:49 just use case: copy film via wifi to uSD, and you have incomming call Jan 17 17:39:54 max_posedon, does the above kernel is fine or shall i flash http://build.shr-project.org/shr-testing/images/om-gta02/uImage-2.6.29-oe11+gitr119861+a15608f241a40b41fed5bffe511355c2067c4e88-r6.1-om-gta02.bin Jan 17 17:40:00 aha. Jan 17 17:40:16 I afraid of that you won't be able answer and speak Jan 17 17:40:26 max_posedon: do you really have some problems in this case Jan 17 17:40:47 I still have preempt kernel Jan 17 17:40:49 gena2x: i just read the backlog and max_posedon is right. irq handlers can be preempted Jan 17 17:41:08 lars_: I'll check code now. Jan 17 17:41:17 gena2x: sure Jan 17 17:41:27 port freedos to freerunner Jan 17 17:41:30 fdos32 Jan 17 17:41:54 max_posedon, any workable kernel ..which is stable Jan 17 17:42:12 but, if preempt will be disabled, mmc driver may not give anough resources to more important gsm/serial and sound interrupts Jan 17 17:42:33 UberNeo, sorry, I didn't flashed that images and kernel. I can't be defently sure, but usually all works Jan 17 17:42:54 try reflash, and download specific kernel, not strange symlink named "latest" Jan 17 17:43:11 UberNeo, you can ran vala-terminal and see, does any module loaded Jan 17 17:43:17 max_posedon: have you checking this somehow - by testing or kernel code review or this is how you think things should work? Jan 17 17:43:34 JaMa: yes, smpeg-1_0.4.5+svnr370-r0 Jan 17 17:43:40 s/checking/checked/ Jan 17 17:43:42 gena2x meant: max_posedon: have you checked this somehow - by testing or kernel code review or this is how you think things should work? Jan 17 17:43:52 you mean that use case, or "preeption" teory? Jan 17 17:43:56 mickey|sports: and those files you have in staging not package, right? Jan 17 17:44:09 max_posedon: yes, i mean mmc problem. Jan 17 17:44:09 max_posedon: i've moved the mmc drivers request handler into it's own thread earlier today. so now you can even renice it Jan 17 17:44:16 this whole debate resembles me to a guy that found that tiny jumper on his cars motormanagement electronics written "leaded super high octane" and "leadfree low octane". He found that "high octane" gave him 5km/h more speed, and he didn'T care for any other implications until he found out the hard way Jan 17 17:44:38 mickey|sports: I've added that link I have on my host.. to make python-pygame built ok.. but it still should be fixed better Jan 17 17:45:10 DocScrutinizer: all other implications are taken in consideration. Jan 17 17:45:23 lars_, own thread inside kernel? Jan 17 17:45:26