**** BEGIN LOGGING AT Fri Oct 04 02:59:59 2013 Oct 04 06:03:05 DAMN!! http://monitor.maemo.org/ganglia/graph_all_periods.php?h=www&m=load_one&r=hour&s=by%20name&hc=4&mc=2&st=1380866537&g=mem_report&z=large&c=maemo Oct 04 06:04:13 www hits swap? Oct 04 06:16:23 hit swap is an euphemism Oct 04 06:16:35 12063 1739 www-data 20 0 7872M 5097M 17716 R 37.0 86.3 203 18.5 05:14 13:46.92 /usr/sbin/apache2 -k start Oct 04 06:17:08 PID PPID USER PRI NI VIRT RES SHR S CPU% MEM% IORR IOWR START TIME+ Command Oct 04 06:17:34 5GB on res, that's huge. Oct 04 06:17:50 yep Oct 04 06:18:01 that's idiotic Oct 04 06:18:25 I killed it Oct 04 06:18:26 * psycho_oreos wonders if switching to a more lighter httpd might help, something like nginx for instance. *shrugs* Oct 04 06:18:36 no Oct 04 06:19:00 this is a class of madness where no tuning helps Oct 04 06:19:14 this is fundamentally wrong Oct 04 06:20:31 btw usually our apache processes are memlimited to some 100s of meg Oct 04 06:20:43 only exception: php jobs Oct 04 06:20:48 I guess if httpd cannot be lightened, it's whatever the underlying processes that depends on www-data to be using that much memory. Oct 04 06:21:09 Hmm.. then I guess it's PHP that is making it bloat? *shrugs* Oct 04 06:21:14 some php jobs lift that limit Oct 04 06:21:26 explicitly Oct 04 06:21:44 midgard "memleaks" Oct 04 06:22:25 objects with circular pointers (self-referential), so GC can't clean out destroyed objects Oct 04 06:22:57 that's what the cracks told me Oct 04 06:23:28 So in other words there needs to be one who can find out and eliminate those circular pointers. Oct 04 06:23:42 in midgard-ONE, yes Oct 04 06:24:22 or simply rewrite the php jobs to use different midgard links than exactly php Oct 04 06:24:43 thransscribe to python, bashscript, whatever Oct 04 06:25:04 when the php interpreter ends, all memory gets free'd Oct 04 06:25:12 but no sooner than that Oct 04 06:26:58 nemein "fixed" that problem by throwing a dedicated physical server (with 64GB RAM?) just on the jobs Oct 04 06:27:22 incredible Oct 04 06:27:37 I wonder which one is easier. Probably the latter one maybe easier to implement. From there on it's just a matter of tracking down broken PHP bits and pieces and rectify them. Oct 04 06:28:21 it's just that PHP in itself is broken by design, and midgard using a lot of PHP Oct 04 06:29:09 afaik the midgard core is C, but all the rest is a bunchof PHP wrappers around that Oct 04 06:29:16 Throwing more memory at it doesn't necessarily solve the issue in the long term, but it sure does save the un-necessary headaches with the initial term of migration/ownership transferral. Oct 04 06:29:24 Ahh. Oct 04 06:29:53 we would need non-PHP bindings for the functions used in those scripts, then rewrite the scripts from PHP to sth sane Oct 04 06:30:41 Heck, that would sound like a nightmare. Oct 04 06:30:52 we don't own sufficient amounts of RAM to "solve" this madness that way. We can't even plug enough RAM into our server to do this Oct 04 06:31:16 Yeah and besides adding more RAM even if it Oct 04 06:31:27 it's doable isn't going to solve it in the long run.* Oct 04 06:31:50 nope Oct 04 06:31:53 not at all Oct 04 06:33:09 it's simply inacceptable that a 200 lines linear(!) script that simply goes "for Obj in $maemo-objects; do bla bla midgard bla; done" is eating 8GB of memory Oct 04 06:33:56 it's not recursive in any way Oct 04 06:33:58 !!! Oct 04 06:34:38 so the number og objects to process is a few 100 or a very few 1000, one after the other Oct 04 06:34:47 s/og /of / Oct 04 06:34:47 DocScrutinizer05 meant: so the number of objects to process is a few 100 or a very few 1000, one after the other Oct 04 06:36:58 I'd unscrupulously replace that PHP loop by a bashscript loop that calls PHP for each single obj, and PHP ends after the object got processed and thus memory free'd Oct 04 06:37:16 Seems like lots of globbing (in programming sense). For (whatever amount there is) in (all of this area); do (all this for each). Oct 04 06:38:20 well, it's really a nightmare of poor coding Oct 04 06:38:52 or ok coding using a poor tool Oct 04 06:38:56 Some interesting factoids (maybe old, fictitious, outdated by now) that I found whilst looking to see what was midgard's role in *.m.o seems like its mainly wiki stuff: http://www.ohloh.net/p/7485/factoids Oct 04 06:39:40 no, midgard is basically our main DB Oct 04 06:39:53 o.O Oct 04 06:40:24 every project in repo is a midgard object Oct 04 06:41:33 So for the objects that are doing circular references are done none other than project's hosted on the site? Oct 04 06:43:25 net use \\%HTCSIP%\c$ /user:%USERNAME% %PASSWORD% Oct 04 06:43:25 IF exist \\%HTCSIP%\c$\%HTCSFOLDERSUBBED%\testset\addshuttles\auto (echo folder exists ) ELSE (mkdir \\%HTCSIP%\c$\%HTCSFOLDERSUBBED%\testset\addshuttles\auto) Oct 04 06:43:32 oops Oct 04 06:44:47 DocScrutinizer05: I'll look at midgard memleaks as soon as I have SSI driver working Oct 04 06:48:02 psycho_oreos: yeah, or users, groups, whatnot else Oct 04 06:48:18 *nods* ahh ok. Oct 04 06:48:41 *everything* is a midgard object Oct 04 06:49:10 except maybe garage Oct 04 06:49:20 Yeah I was thinking about wiki "objects", i.e. each wiki entry on w.m.o are deemed as objects to midgard. Oct 04 06:50:00 I dunno, some google results keep cropping up showing that it's wiki.maemo.org stuff. Oct 04 06:51:50 wiki is not related to midgard, that's wikimedia Oct 04 06:52:31 everything except (wiki|bugs).m.o is midgard though Oct 04 06:52:35 starting with Oct 04 06:52:37 ~pkg Oct 04 06:52:37 pkg is probably http://maemo.org/packages/ Oct 04 06:52:54 My bad. Speaking of wikimedia, that name does ring a bell in my head. I was looking into mirroring awhile ago. Oct 04 06:53:49 all http://maemo.org/ is midgard actually Oct 04 06:55:04 Ouch, if that's the case then I guess the cleanup won't be any easier. Oct 04 06:55:16 only garage is some other CMS of which the name I never can recall, sth with p* Oct 04 06:56:26 or maybe the p* is from postgreSQL that's used in garage by that other CMS Oct 04 06:56:40 Isn't garage run by forge Oct 04 06:56:46 yep Oct 04 06:56:56 *forge Oct 04 06:57:14 gforge, pforge sth Oct 04 06:57:25 er, gforge, yeah Oct 04 06:58:48 this stuff works mostly flawlessly Oct 04 06:59:16 mut it starts to become a nightmare as soon as garage users are synced from gforge to www midgard Oct 04 06:59:21 but* Oct 04 07:01:21 this job which also been a php script like scetched above "for u in users;... done; for g in groups ... done;" used to use 6 or more GB as well. Users: ~50k, groups a few 1000 or even <1000, can't recall Oct 04 07:01:54 that's sinply idiotic Oct 04 07:02:02 simply* Oct 04 07:03:11 what's also idiotic is the concept to sync *all* users from garage to www every 3h. even when ZILCH changed Oct 04 07:03:55 and since it's done that way, and often failed, the removal of users got removed, since otherwise every now and then 90% of user accounts would get deleted Oct 04 07:05:53 the not even funny minor deatil in all this: *garage* *knows* about each change in project/user/group db, and could ask www to simply update that particular change: ONE user to update, ONE group to add... You see where I'm aiming at Oct 04 07:07:11 they use "dd" where they should've used "rsync", to use a technical metaphor Oct 04 07:08:46 and since "dd" takes ages (hours) it's triggered by cronjob a few times a day, instead of being event-triggered by changes in garage Oct 04 07:10:50 garage *could* simply invoke a www.m.o webpage and fill in the changed data, as soon as user actually changes something in his account. NFC why the architects of maemo.org decided to poll garage and sync whole user/group db each time Oct 04 07:12:15 and particularly why that script has to run on www and not on garage Oct 04 07:12:36 broken by design Oct 04 07:12:52 and we got 2 dozen of those Oct 04 07:13:14 update download statistics etc pp Oct 04 07:14:16 one of them more "WTF?!" than the other Oct 04 07:15:19 and of course zilch docs abozt what exists, why it exists and what and how it's supposed to do Oct 04 07:15:26 about* Oct 04 07:16:17 no idea which of those 2 dozen caused today's RAM madness http://monitor.maemo.org/ganglia/graph_all_periods.php?h=www&m=load_one&r=hour&s=by%20name&hc=4&mc=2&st=1380866537&g=mem_report&z=large&c=maemo Oct 04 07:18:36 we sanitized the garage sync script by a bit of refactoring and cleanup so it now is relatively humble and needs less than 1GB usually. I guess it's what you see as regular sawtooth pattern in above link Oct 04 07:27:13 19:37:01 ShadowJK | Modern good SD have portions of the flash running as SLC, and caches stuff there before flushing to main MLC Oct 04 07:27:15 | or TLC storage area, so a simple write followed by read verify only checls if slc cache is working :P Oct 04 07:27:28 sure, that is why I suggested writing the full disk first, then comparing :P Oct 04 07:47:59 *sigh* Oct 04 07:48:02 32462 1739 www-data 20 0 1232M 945M 20280 R 11.0 16.0 0 0 07:29 2:18.92 │ ├─ /usr/sbin/apache2 -k start Oct 04 07:48:23 32462 1739 www-data 20 0 1247M 960M 20280 S 11.0 16.3 0 0 07:29 2:21.80 │ ├─ /usr/sbin/apache2 -k start Oct 04 07:49:05 prolly garagesync script Oct 04 07:49:49 32462 1739 www-data 20 0 1301M 1017M 20280 S 14.0 17.2 0 0 07:29 2:32.12 │ ├─ /usr/sbin/apache2 -k start Oct 04 07:52:17 all other apache processes are limited to ~300MB, as we have configured it: http://privatepaste.com/2c7ffe36fe Oct 04 07:59:25 32462 1739 www-data 20 0 1687M 1424M 22448 R 61.0 24.1 15.8 18.5 07:29 4:31.57 │ ├─ /usr/sbin/apache2 -k start Oct 04 09:15:57 hi all Oct 04 09:16:22 I have a little problem on my n900 Oct 04 09:16:43 in the sqlite db where sms are stored, I try to get unread messages Oct 04 09:17:13 but the problem is, something marks the message as read in the db 2-3 secs after it is received Oct 04 09:17:48 does someone have an idea on what it could be, or how to find the program responsible for this ? Oct 04 09:20:57 12835 1739 www-data 20 0 2151M 1820M 20760 S 3.0 30.8 0 2.63 08:30 16:05.58 /usr/sbin/apache2 -k start DAMN! Oct 04 09:29:11 gormux: hard to tell Oct 04 09:30:57 it seems thi sis because the messaging ui was running in the background Oct 04 09:31:37 so it means the "read" status means messaging ui saw it, and not the human user :/ Oct 04 09:31:38 I'd bet you installed some app that's somehow related to SMS. Maybe some remote control that reacts on special SMS (to e.g. erase the data or locate the device)? Oct 04 09:31:54 sure Oct 04 09:32:31 it's hard to tell if user actually *reads* the SMS, so it is tagged as "read" when it got displayed Oct 04 09:32:45 yeah... even if the screen is off Oct 04 09:33:18 it'll be harder to make what I wanted then Oct 04 09:33:24 that's actually a design flaw, if not actually a bug Oct 04 09:34:14 should only get tagged when in foreground and screen unblanked Oct 04 09:34:45 yeah, that's how it works on android Oct 04 09:35:03 but this is a known age old bug in SMS/messages UI Oct 04 09:35:44 it also doesn't sound proper SMS alarm when message UI is open when SMS comes in Oct 04 09:36:02 unclear if that's a bug or a feature Oct 04 09:41:40 so best practice: close you messaging ui as soon as you don't actively use it anymore Oct 04 09:42:09 (btw same applies to browser windows as well as basically all other apps) Oct 04 09:44:20 interactive apps running idle in background at best cause only RAM usage, but as well can cause extreme battery drain and a lot of other strange effects like the missing alarm and the tagging of SMS despite they never really got displayed on screen Oct 04 09:57:08 yeah, maybe i could kill sms ui when screen is powered off Oct 04 10:01:02 good plan, and probably quite easy to implement. dbus is your friend Oct 04 10:08:03 if rtcom-messaging-ui wasn't closed, it could be fixed to not suck (i.e. not mark it as read if the screen is off, not suppress the SMS notification if the screen is off etc) Oct 04 10:08:21 but unfortunately its closed so we cant do that :P Oct 04 10:17:06 yes, exactly Oct 04 10:19:50 http://en.qi-hardware.com/w/images/1/10/ME_382_LockedUpTechnology2.gif Oct 04 10:21:14 Nokia's differentiation ;-P Oct 04 10:27:10 * DocScrutinizer05 idly wonders wtf been the idea behind that "differentiation" mantra Oct 04 10:27:53 maybe ask Jolla, I bet it will resurrect in their business policies Oct 04 10:27:55 At least we are slowly replacing those bits of software that are mission critical with open versions (Pali Oct 04 10:28:03 (Pali's BME replacement for example) Oct 04 10:28:14 :nod: Oct 04 10:28:24 or my replacement for wl1251-cal (which no-one seems to care about) Oct 04 10:28:49 well, nobody implemented it yet Oct 04 10:29:36 we don't have the CFOSSU distro Oct 04 10:30:15 though several peeps seem to think CSSU *is* CFOSSU Oct 04 10:33:09 but for CSSU primary goal of rock solid quality it's not relevant if a component is FOSS and replacing a blob by FOSS is detrimental to quality and reliability as long as there's no better reason than just the FOSS property of the replacement Oct 04 10:34:19 IOW FOSS is a means but no reason to replace some blob Oct 04 10:34:52 fixing bugs though definitely is a good reason Oct 04 10:38:31 yeah makes sense Oct 04 10:38:56 There are parts where being FOSS would help though like MCE or cellular services daemon or dialer/messaging UI Oct 04 10:39:07 jonwil: nevertheless I think gormux' approach to "kill" (actually: close) the rtcom-messaging-ui whenever it goes to background or screen gets locked is a good workaround Oct 04 10:39:47 yeah :) Oct 04 10:40:36 jonwil: sure. Thus your wl1251-cal FOSS replacement is a pretty nice option as soon as somebody needs to fix a bug in it, or for those who are interested in getting every blob off their system Oct 04 10:41:21 for MCE I already have ~3 or 7 bugs I'd really like to fix as soon as we get a FOSS replacement Oct 04 10:41:29 if we ever get one :P Oct 04 10:42:04 I heard there are already working replacements allegedly Oct 04 10:42:20 I'm eagerly waiting Oct 04 10:42:56 Reason #1 for writing wl1251-cal and things was for alt-os-on-N900 (i.e. meego/mer/nemo/etc) where they only have a few remaining binary blobs left (having ditched closed pulseaudio blob etc) Oct 04 10:43:18 :nod: Oct 04 10:44:21 might as well come in handy for Neo900 where we need to deal with a different WLAN chip Oct 04 10:45:01 well Neo900 will have its own kernel driver Oct 04 10:45:05 and its own firmware blob Oct 04 10:45:14 we want to make that look like wl1251 as much as we can - this includes wl1251-cal i'd think Oct 04 10:45:15 and its own means of doing whatever init is needed for the device Oct 04 10:45:53 I dont think we need to make it look too much like wl1251, anything that is specific to that chip is already oss Oct 04 10:46:05 i.e. wlancond Oct 04 10:46:37 I dont think osso-wlan-security is in any way tied to the hardware specifically Oct 04 10:48:12 neither is icd-network-* Oct 04 10:48:25 yep, but stuff like setting of allowed channels is probably a good idea to keep similar to stock fremantle Oct 04 10:48:53 wifi chip is the same as in gta04? Oct 04 10:49:02 unclear yet Oct 04 10:49:13 that plan been to use same, yep Oct 04 10:49:32 My understanding was that the plan was to use the same unless a better option can be sourced Oct 04 10:49:44 but maybe that's already a EOL component and we need to find a new module anyway Oct 04 10:49:50 maybe Oct 04 10:50:52 in any case whatever chip ends up being used (which will not be a wl1251) will have its own way of setting the settings Oct 04 10:50:53 also this WLAN module attached via SPI, and we might need the SoC interface for sth different in Neo900 Oct 04 10:52:36 the concept is to adapt kernel drivers to mimic "old" N900 hw whenever possible Oct 04 10:52:50 so no changes in userland are needed Oct 04 10:55:30 only when that's absolutely not feasible we will ponder what userland bits need to get (RE'd and) adapted to work with new changed kernel API for that subsystem Oct 04 10:56:08 when both not feasible, we go for hw changes to adapt GTA04 to N900 Oct 04 10:56:42 its way too expensive Oct 04 10:56:47 saw that neo900 thing Oct 04 10:56:48 huh? Oct 04 10:56:54 clicked on the gta04 link Oct 04 10:56:59 Gh0sty: thanks, we know Oct 04 10:57:07 saw a price of 600$ to replace the hw :( Oct 04 10:57:20 *shrug* Oct 04 10:57:35 donate 50k$ and we may reduce the price Oct 04 10:57:40 I dont see a reason why we need to try to copy old kernel interfaces if we dont have to (i.e. if we can just change userland bits to talk to however mainline kernel devs would like it done) Oct 04 10:57:52 and that means you have an n900 bulky phone with some 'newer' hardware inside Oct 04 10:57:53 or buy 10k devices and we also may reduce the price Oct 04 10:58:12 Gh0sty: THANKS we know Oct 04 10:59:01 jonwil: the concept is to keep maximum compatibility to stock maemo fremantle Oct 04 10:59:21 thus kernel adaptions have priority over userland adaptions Oct 04 11:00:18 particularly when userland is hard or impossible to adapt Oct 04 11:01:02 it makes sense to support kernel interfaces where userland is too hard to change (e.g. audio stuff thanks to pulseaudio-nokia) Oct 04 11:01:28 but it doesn't make sense to make special hacked kernel modules if changing userland is better (e.g. in the case of cellular services daemon) Oct 04 11:01:38 audio is a case where we need to do hw adaption since nothing else will fly Oct 04 11:02:04 yeah I think its going to be impossible to get audio working unless we are using the same audio chip as N900 Oct 04 11:02:15 and the same speakers, microphone etc Oct 04 11:02:15 :nod: Oct 04 11:02:43 meh, speakers, phone etc are not critical, as long as they work similar Oct 04 11:02:58 micro-phone :-) Oct 04 11:03:25 speakers will be same just for mechanical reasons Oct 04 11:03:40 mic will be similar in that we'll use a digital one Oct 04 11:03:48 speakers need to be the same because of stuff in pulseaudio-nokia that rely on specifics of Nokia speakers (i.e. xprot etc) Oct 04 11:04:10 not really Oct 04 11:04:21 xprot is pretty universal Oct 04 11:04:59 it wouldn't break even for Bose501 speakers Oct 04 11:05:36 will we keep using the same BL-5J as Nokia? Oct 04 11:05:50 mix actually is just an alsa card input for the system Oct 04 11:05:57 I think we have to if we are using the same shell parts Oct 04 11:06:10 i.e. battery compartment bits Oct 04 11:06:14 I wouldn't know which other battery would fit Oct 04 11:07:11 we might provide options for a DIY smart battery like the GTA02-battery Oct 04 11:07:37 where the BQ27000 is built into the battery like it really makes sense Oct 04 11:08:02 hi Oct 04 11:08:05 hi Oct 04 11:08:51 I have an issue with maemo. Since 1 hour I can't read my conversations (or sms). When I open a conversation nothing is displaying, did you encounter this kind of issue ? Oct 04 11:09:00 Try restarting your phone Oct 04 11:09:10 i.e. turn it off then on again Oct 04 11:09:17 well...I did it several times Oct 04 11:09:21 hmnm ok Oct 04 11:09:24 no idea then :) Oct 04 11:09:48 then probably cleaning events-db is next Oct 04 11:10:07 DocScrutinizer05: how can I do this ? Oct 04 11:10:17 start with some checks Oct 04 11:10:38 obviously screen will be exact screen of N900 (because it has to be so it fits the case and because we want to keep n900 screen attributes like resistive and stylus compatibility) Oct 04 11:11:20 DocScrutinizer05: ?? Oct 04 11:11:53 janemba: pastebin the result of `ls -l /home/user/.rtcom-eventlogger/*` Oct 04 11:12:25 btw, I suspect my software development and reverse engineering work more than makes up for my non-ability to donate to maemo.org etc :) Oct 04 11:12:42 jonwil: don't worry Oct 04 11:13:06 maemo.org currently isn't short of money, only short of manpower Oct 04 11:13:49 DocScrutinizer05: ==> http://pastebin.com/0Jk8TgNf Oct 04 11:13:52 I would donate manpower but I lack the system admin skills to do that :P Oct 04 11:14:16 ugh! 6MB Oct 04 11:14:35 el-v1.db Oct 04 11:14:39 well Oct 04 11:15:08 sqlite file Oct 04 11:15:49 `cp -a /home/user/.rtcom-eventlogger/ /home/user/.rtcom-eventlogger-backup/; rm /home/user/.rtcom-eventlogger/*` Oct 04 11:15:54 then reboot Oct 04 11:15:57 hard Oct 04 11:16:04 ok Oct 04 11:16:33 all your conversations will be "lost" (in backup) Oct 04 11:16:47 but it should start to work again Oct 04 11:17:26 ok Oct 04 11:18:15 everything >1MB for el-v1.db is considered too much to allow proper operation of device Oct 04 11:18:50 the sqlite engine will eat too much RAM and CPU and time for everything Oct 04 11:19:23 delay on inbound calls, problems with displaying messages, and eventually even corruption of the db Oct 04 11:19:29 ok I will remember that Oct 04 11:20:22 after boot your rtcomm stuff should auto-create an empty el-v1.db Oct 04 11:20:46 when you moved away or deleted the monster file Oct 04 11:21:30 funny enough Nokia never considered what may happen to this stuff after a few years Oct 04 11:21:57 so no auto-cleaning or whatever got implemented, no filesize limits or whatever Oct 04 11:23:29 maybe a `mv /home/user/.rtcom-eventlogger/ /home/user/.rtcom-eventlogger-backup/; mkdir /home/user/.rtcom-eventlogger/` is even the better method Oct 04 11:23:42 yes but now I can do it myself Oct 04 11:23:52 :-) Oct 04 11:32:44 nice it works fine thx ;) Oct 04 11:33:12 :-) great. thanks for feedback Oct 04 11:34:41 ;) Oct 04 11:44:00 btw DocScrutinizer05, if Neo900 cant run Nokia Maps app, I dont consider it compatible enough with Fremantle :P Oct 04 11:44:48 best way to handle GPS is to just reverse-engineer and implement the GPS dbus interfaces :) Oct 04 11:45:00 who needs Nokia Maps? Oct 04 11:45:26 I use it :P Oct 04 11:45:32 srsly? Oct 04 11:45:38 Is there a better GPS app out there which has offline storage? Oct 04 11:46:34 I have yet to find one Oct 04 11:46:41 I liked tangogps back in the days of the freerunner, but currently on the n900 I use maep Oct 04 11:47:38 maep doesn't seem to support offline maps Oct 04 11:47:51 which is feature I need so I dont have to use up so much of my expensive mobile data Oct 04 11:48:01 or can make it work even if for some reason I cant get cell signal Oct 04 11:48:21 maep caches the map and doesn't ask every 5 minutes for a connection like nokia maps does Oct 04 11:48:49 in any case I am happy with nokia maps :) Oct 04 11:49:02 I'm not.. Oct 04 11:49:10 About the only feature that I really want but Nokia Maps is missing is the ability to use the Google Transit public transit data Oct 04 11:49:19 nokia maps is missing too much streets Oct 04 11:49:20 but I cant find ANY N900 maps app that can use that data Oct 04 11:49:31 Nokia Maps isn't missing any streets in my area Oct 04 11:50:31 or even the new housing estate where one of my family members now lives Oct 04 11:50:56 Also OSM has all forest paths Oct 04 11:52:49 If I had the skills I would write something for the N900 that can use Google Transit data Oct 04 11:53:09 both mapping and route planning Oct 04 11:53:18 but I dont have the skills Oct 04 11:53:49 ps: I think we (GolDeliCo) might hand out some Neo900 prototypes for free, for the most active fremantle porters to test the fremantle adaption Oct 04 11:55:23 btw Did I already ask if GolDeliCo still gets Omap support? Since a lot of Linux devs had to leave TI... Oct 04 11:56:08 btw re cellular modem I think the way to go is to figure out all the dbus calls and write support into ofono or gsmd or whatever so they talk to the existing N900 backend (i.e. make ofono or fsogsmd a drop-in replacement for cellular services daemon on N900) then once that is working, rewrite backend to talk to Option modem. Easier to verify by comparing stock and new cellular daemon bits. Oct 04 11:56:32 Thats just my opinion though and others may have other thoughts :) Oct 04 11:56:59 Omap support? Never knew GolDelico ever got any Oct 04 11:57:05 bonus is that we get a usable open CSD replacement for whatever someone might want one for :) Oct 04 11:58:01 jonwil: ack Oct 04 11:58:48 jonwil: and I already suggested to start such project right away, using an USB UMTS stick on N900 Oct 04 11:59:52 Better to be talking to N900 stock cellular modem than to try to talk to USB stick. Most of the relevant bits of the N900 cell modem is documented enough to figure out or can be figured out from reverse engineering :) Oct 04 12:02:34 I recon the most difficult parts of the Neo900 FPTF project are going to be (in order) Cellular audio, Cellular Modem, GPS in that order Oct 04 12:03:08 OMAP DSP may also be an issue depending on how compatible the Neo900 OMAP and the N900 OMAP are in that area Oct 04 12:17:21 freemangordon_: http://privatepaste.com/89bd7e5ff9 Oct 04 12:58:37 why I cannot reach https://duckduckgo.com/ with sudo ping and opera on N900 anymore but on PC in same network and why has Maemo a dns running? WTF Oct 04 12:59:05 spilling the beans: headroom on each side of N900 PCB: max 1.6mm. Height of Option modem module: 2.1mm Oct 04 13:00:05 ( PCB thickness: 0.8mm ;-D ) Oct 04 13:01:16 NeutrinoPower: huh? Oct 04 13:01:54 NeutrinoPower: maemo is using dnsmasq for routing Oct 04 13:02:17 DocScrutinizer05: thats gonna be too tight a fit :-/ Oct 04 13:03:00 wait and see what we might come up with, Neo900 not dead yet Oct 04 13:03:38 ~1.5 + 1.5 + 0.8 Oct 04 13:03:38 3.8 Oct 04 13:03:41 I'd be surprised if you wouldn't Oct 04 13:04:52 I for one intend to do whatever reverse engineering and programming work I can towards the Neo900 project Oct 04 13:04:55 and the porting effort Oct 04 13:05:16 and FPTF :) Oct 04 13:06:05 DocScrutinizer05: do you know the height without the rf-can? Oct 04 13:06:25 of the module? we can't do that Oct 04 13:06:59 yeah, I know, just hypothetically Oct 04 13:07:32 just hypothetically I see a modem module sitting in a hole of the PCB Oct 04 13:08:07 right, that's first thing that comes to ones mind.. Oct 04 13:08:30 not pretty, though Oct 04 13:08:30 on its own tiny support PCB, with B2B connectors to simply plug into the mainmoard Oct 04 13:08:40 but what is Oct 04 13:10:10 swapable modem Oct 04 13:10:14 actually it *might* even fit on last PCB layer when we just remove 7 of the 8 layers. But I think the remaining 0.1mm PCB are not rigid enough Oct 04 13:11:12 and not sufficient for heatsink Oct 04 13:13:12 haven't seen the inside of a n900-case, but may it be possible to move the point where the PCB sits? Oct 04 13:13:36 on the gta04 most of the components on one side Oct 04 13:14:21 I pondered that, particularly to have own PCB for kbd (to avoid mechanical stress to FBGA chips when kbd pressen and PCB bends) - evaluation not finalized Oct 04 13:14:55 good :) Oct 04 13:15:09 I'm sure I can't tell you anything new Oct 04 13:15:30 well, I'm doing that job a few years ;-) Oct 04 13:15:58 looks like :P Oct 04 13:16:34 ok, I think Nikolaus won't kill me when I disclose his 80% done feasibility study pdf Oct 04 13:19:27 maemo.cloud-7.de/hidden/Feasibility.key.pdf Oct 04 14:02:28 DocScrutinizer05: not found Oct 04 14:02:39 too late ;-) Oct 04 14:03:17 damnit, was getting some groceries Oct 04 14:07:27 looks alot harder than I thought.. Oct 04 14:36:13 yeah Oct 04 14:38:31 note that some components are fixed, especially camera (which is also "thru-hole") Oct 04 14:58:39 judging from the already setplacement of sim-card holder, battery contacs, vibra and the space in between Oct 04 14:58:49 it looks hard to find a place where the option modem will fit just considering the area it needs Oct 04 15:02:29 that is for the GTM801, which is considerably bigger than the GTM601 Oct 04 15:03:30 a tad bigger, yep Oct 04 15:05:10 think anthroposophic aka forget about 90° angles, then it might fit Oct 04 15:06:03 ah, you got me Oct 04 15:06:05 at least that's what Nikolaus told me Oct 04 15:08:09 as he's got the modem and the n900, I'm pretty sure he did some puzzling Oct 04 15:08:18 he did :-) Oct 04 15:10:00 and he was positive about my suggestion to remove a few layers of PCB to embed the 2.1mm some 0.6mm into the PCB Oct 04 15:10:37 sounds crazy Oct 04 15:10:44 as long as we can route that, with only 4 layers Oct 04 15:11:14 cost isn't an issue I guess Oct 04 15:11:23 PCB-cost Oct 04 15:11:39 cost becomes an isse after feasibility got accomplished Oct 04 15:11:55 might cost twice as much Oct 04 15:12:10 but hey Oct 04 15:12:25 still cheaper than building a new case Oct 04 15:12:31 :) Oct 04 15:13:16 another really crazy idea: lift the LCD from kbd half a few mm Oct 04 15:13:41 but THAT will get BUTT UGLY Oct 04 15:14:35 don't fiddle to much with the case.. Oct 04 15:15:02 option #3: no modem module but direct chipset-on-PCB. Downside: no more FCC approval at all Oct 04 15:15:11 no calibration done, no nuttin Oct 04 15:15:55 no tempting alternative Oct 04 15:17:34 and not even shielding, since those cages/cans are not exactly sourceable Oct 04 15:18:30 the comunity needs a factory ;-) Oct 04 15:18:48 community even Oct 04 15:21:59 shows how lucky we were that OM could use FIC's stuff Oct 04 15:23:55 at least that's what I gathered over the years Oct 04 16:17:44 yep, without FIC Openmoko wouldn't even have been thought of Oct 04 16:21:16 actually it's unclear if Sean or his Sher's nephew student peer room mate had the idea for OM Oct 04 16:23:45 * DocScrutinizer05 just tries to figure a 0.4mm wider gap between kbd and screen body Oct 04 16:24:06 maybe 0.4mm aren't even noticeable? Oct 04 16:26:12 (cans) I think tooling for the cans is ~1000EUR, so it *might* even be feasible for one metal object Oct 04 16:35:16 DocScrutinizer05: goddammit now that you said it we're all going to notice Oct 04 16:35:33 (also, won't stuff get in?) Oct 04 16:58:53 there's already a gap of >0.5mm Oct 04 16:59:23 and yes, stuff already gets in Oct 04 16:59:43 inserting a credit card can even break your FPC Oct 04 17:23:29 i am having a tough time locating discussions about setting framerate capability for /dev/video0 v4l2camsrc on the n900 -- experiments so far have only worked with 60 and 499/100. gst-inspect says 0/1, 100,1 -- wiki says nothing... Oct 04 18:37:10 has anyone tried running non-linux oses on the n900? Oct 04 18:57:10 like? Oct 04 19:05:17 a bsd or something homebrew Oct 04 19:05:29 I mainly just like the idea of dual booting my phone Oct 04 19:05:58 doesn't have to have access to camera or much of the hardware aside from display/keyboard. I just want to mess around with stuff Oct 04 21:20:11 Tekk_: A poster to community@lists.openmoko.org had NetBSD running on the Openmoko GTA02, which usually runs a Linux kernel. Oct 04 21:20:36 brolin_empey: yeah, I'm unsurprised about running stuff on openmokos Oct 04 21:20:43 but I don't have one of those :P Oct 04 21:22:41 * brolin_empey has at least 4 or 5 GTA02s but not all of them are fully functional. Oct 04 21:25:39 * brolin_empey used QtMoko on a GTA02 before he switched to Maemo 5 on a Nokia N900. Oct 04 21:34:10 brolin_empey: 6 at least, here ;-P Oct 04 21:34:38 Tekk_: I think at very least SHR and gentoo were ported to N900 Oct 04 21:34:54 and nitdroid of course :-S Oct 04 21:35:00 shr? Oct 04 21:35:05 ~shr Oct 04 21:35:05 i guess shr is The Stable Hybrid Release (SHR), intended to be a community driven distribution composed of the FSO and some basic applications, that can be configured to use several different graphical toolkits, for example GTK or EFL. SHR is based on the FSO build. At first, SHR was introduced in order to use the Openmoko2007.2 GTK software in combination with the new FSO, but things have changed. Oct 04 21:35:37 hmm Oct 04 21:35:43 also why would anyone want to run android on the n900? O.o Oct 04 21:35:58 No Fsckng Clue! Oct 04 21:36:03 :-D Oct 04 21:36:52 I know the guys who ported SHR and gentoo ;) Oct 04 21:37:05 in SHR I even helped a little bit Oct 04 21:37:20