**** BEGIN LOGGING AT Mon Nov 01 02:59:57 2010 Nov 01 03:00:30 Weiss, if you are interested, easy/fast way to crash Xserver -> download wifi-radar from http://download.berlios.de/wifi-radar/wifi-radar-2.0.s08.tar.bz2 and execute it (python). Xserver segfaults Nov 01 11:13:46 morning Nov 01 11:13:51 hi Nov 01 11:17:23 mickey|office, for battery charging we should have one part in kernel(charge indication) and one part in userland(charging) right? Nov 01 11:18:17 yes, a proper battery driver would help Nov 01 11:18:25 and e.g. a sysfs node to enable charging would rock Nov 01 11:18:39 ah you want charging in kernel too? Nov 01 11:18:46 or just battery charge indication Nov 01 11:18:47 ? Nov 01 11:19:06 I thought you wanted the charge part in userspace Nov 01 11:19:43 it depends on what we can get :) Nov 01 11:19:51 i would _like_ to have charging in kernel Nov 01 11:19:54 since i believe it belongs there Nov 01 11:19:58 but if noone writes the kernel driver Nov 01 11:20:02 we have to do it in userspace Nov 01 11:20:14 btw it has to act differently when you have a wall charger,usb cable etc... Nov 01 11:20:53 btw I checked the n900 accelerometers Nov 01 11:20:58 it's a sysfs node Nov 01 11:21:01 and seem active Nov 01 11:21:10 I bet it eat battery life Nov 01 11:22:15 I'll try to work on battery charging for kernel then, but first battery display Nov 01 11:22:26 s/display/charge indication Nov 01 11:23:06 I've also 2 other urgent stuff to do: Nov 01 11:23:14 *iwconfig wlan0 power on Nov 01 11:23:50 *echo ondemand > /sys/device/cpu/cpu0/cpufreq/scaling_governor init script or fix the kernel Nov 01 11:24:16 shouldn't we switch to git for the kernel? Nov 01 11:24:27 or oe patches are good? Nov 01 11:28:47 git is always preferrable IMO Nov 01 11:28:56 ok Nov 01 11:28:56 makes it easier to branch and try things Nov 01 11:29:01 indeed Nov 01 11:30:09 so I should push something to linux-2.6 in fso? Nov 01 11:30:39 and then? Nov 01 11:30:48 I change SRC_URI in 2.6.28 for n900? Nov 01 11:31:03 or I make a 2.6.28-n900 recipe? Nov 01 11:32:21 lets do 2.6.28-n900 first, and when we're satisfied with it, adding it back to the main 2.6.28 Nov 01 11:32:32 ok Nov 01 11:33:03 also I already told you that I won't work on modem in order not to polute it with low quality code, what do you think of it? Nov 01 11:48:06 well, there are enough construction sites so we better concentrate on different things. let electranox handle the modem for now Nov 01 11:48:18 i'm busy with gdbus for the next couple of weeks anyways Nov 01 11:48:45 mickey|office, sre is online and morphis will be back in 30min Nov 01 11:49:01 maybe time to talk about fso<->libisi with them Nov 01 11:49:37 sounds good Nov 01 12:09:41 sre can talk from 14:15-16:00 only, morphis should be back in 30min Nov 01 12:12:08 heyho Nov 01 12:52:45 moin morphis Nov 01 12:52:57 playya: heyho Nov 01 13:11:59 GNUtoo|laptop: will sre come to IRC? Nov 01 13:26:41 morphis, I don't know, ask him Nov 01 13:27:03 ok Nov 01 13:30:31 "sre: give me some minutes" Nov 01 13:35:45 maybe we could start to ping mickey|office Nov 01 13:35:55 mickey|office: ping Nov 01 13:36:14 mickey|office: ping :-) Nov 01 13:36:35 distribued ping? Nov 01 13:36:44 yup :) Nov 01 13:36:47 sound like a ping botnet Nov 01 13:37:01 ping implosion Nov 01 13:37:11 or pong implosion Nov 01 13:37:18 (taken from ack implosion) Nov 01 13:37:35 hi ho Nov 01 13:37:56 hehe Nov 01 13:37:57 mickey|office: heyho Nov 01 13:38:09 anybody already looked at libisi? Nov 01 13:38:38 I tried it and talked to sre to make him render the lib compilable for oe Nov 01 13:39:03 I didn't test the pin with non-hardcoded number tough, he asked me to and I forgott Nov 01 13:39:51 sre is electranox or am I mixing up people? Nov 01 13:40:00 jepp he is Nov 01 13:40:05 GNUtoo|laptop: ok Nov 01 13:40:08 k, so far so good Nov 01 13:40:14 first thing we need is a vala vapi file for libisi Nov 01 13:40:20 so someone needs to check what libisi can do and not Nov 01 13:40:22 right, after the vapi Nov 01 13:40:35 mickey|office, I know what it can do Nov 01 13:40:41 nearly nothing for now: Nov 01 13:40:53 https://elektranox.org/n900/libisi/index.html Nov 01 13:40:54 what its doing is one step Nov 01 13:40:56 you can register Nov 01 13:41:00 we should know how it is working Nov 01 13:41:09 but you can't send sms or make calls Nov 01 13:41:11 do we send packages over a connection ? Nov 01 13:41:32 I don't know I didn't read the source code of the low level lib Nov 01 13:41:48 morphis: I think so Nov 01 13:41:50 as I see in the code it works a lot with callbacks Nov 01 13:41:56 https://git.ring0.de/libisi/tree/test/network.vala Nov 01 13:42:16 baah one callback for each property ... Nov 01 13:42:55 and it seems like you are communicating through each callback with another one Nov 01 13:43:04 see https://git.ring0.de/libisi/tree/test/authenticate.vala Nov 01 13:43:23 maybe that should be wrapped so we can do Nov 01 13:43:23 maybe we should wait for sre Nov 01 13:43:35 yield modem.authenticate(xxx) in fsogsmd Nov 01 13:43:46 just my impressions about what I see :) Nov 01 13:43:58 as I have to leave in the next 10 minutes Nov 01 13:47:09 so it seem that now everybody is here Nov 01 13:48:11 here's what was said before: http://pastebin.com/j1NLiWzN Nov 01 13:50:31 sre_ /\/\/\ Nov 01 13:51:01 "sre: so fertig mit essen" Nov 01 13:51:07 hi Nov 01 13:51:10 ah ok Nov 01 13:51:15 ;) Nov 01 13:51:15 ? Nov 01 13:51:29 the vapi files comes together with the lib Nov 01 13:51:46 https://git.ring0.de/libisi/tree/data/libisi.vapi Nov 01 13:52:04 so libisi works mostly with callbacks, right? Nov 01 13:52:23 yes Nov 01 13:52:26 ok Nov 01 13:52:57 I use nokia's lowlevel code from ofono (gisi), which uses callbacks Nov 01 13:53:02 maybe we should wrap this so we can use it the right way in fsogsmd Nov 01 13:53:04 so libisi uses callbacks, too Nov 01 13:53:42 hm Nov 01 13:53:49 mickey|office: whats your opinion? Nov 01 13:54:31 until now we got most responses in sync for a command Nov 01 13:54:38 in AT or msmcomm Nov 01 13:54:51 so there was the cut between solicited and unsolicited responses Nov 01 13:55:03 but with libisi it seems that we don't have this anymore Nov 01 13:55:09 anyway I have to leave Nov 01 13:55:17 will look at the log later Nov 01 13:55:19 bye Nov 01 13:55:40 cya Nov 01 13:55:54 bye Nov 01 13:56:09 well Nov 01 13:56:25 at the bottom of fsogsmd, there is an asynchronous command queue Nov 01 13:56:36 so i guess we can make libisi fit in there Nov 01 13:57:02 if we really want yield(), we can add vala async wrappers later Nov 01 13:57:09 but that should not be the problem for now Nov 01 13:57:17 for now it's important the we have modem init and registration Nov 01 13:57:19 SIM PIN Nov 01 13:57:27 camping to network Nov 01 13:57:31 receiving some status info Nov 01 13:57:37 once we have that, we can move from there Nov 01 13:57:48 that much is working in libisi Nov 01 13:57:51 all that is already in libisi Nov 01 13:58:00 I tested it and it works Nov 01 13:58:38 but for modem init some sysfs writes are needed, which I did not put into libisi Nov 01 13:59:05 we could add it to fsodeviced/resource Nov 01 13:59:26 and the sysfs are different between 2.6.28 and 2.6.35 according to sre_ Nov 01 14:00:15 at least ofono guys have different files for maemos's 2.6.28 kernel and meego's kernel Nov 01 14:02:51 ofono's code for enabling/disabling the modem is quite nice btw Nov 01 14:02:54 well, we have sysfs write for powering up and down modem on gta02, so i think that's not a problem :P Nov 01 14:02:55 they use a state machine Nov 01 14:03:42 ok Nov 01 14:04:32 sre_, there're a lot of imho strange delegates like: Nov 01 14:04:35 [CCode (cname = "isi_device_info_cb", has_target = false)] Nov 01 14:04:35 public delegate void device_info_cb(bool error, string msg, void *user_data); Nov 01 14:05:04 user_data is the same as in glib's delegates? Nov 01 14:05:41 yes it's just a forwarded pointer Nov 01 14:06:17 ok Nov 01 14:07:00 vala should generate correct code if you remove the has_target=false annotations and the user_data parameter Nov 01 14:09:21 the vapi is handwritten, isn't it? Nov 01 14:10:02 yes the vapi is handwritten Nov 01 14:10:27 are vala's CCodes documented somewhere? Nov 01 14:11:54 at least glib-2.0.vapi also uses has_target = false for its delegates Nov 01 14:12:14 yes. if you don't have a user_data pointer Nov 01 14:12:36 ah :) Nov 01 14:16:29 sre_, http://live.gnome.org/Vala/CodeAttributes Nov 01 14:17:41 thx Nov 01 14:27:50 the API is quite Cish Nov 01 14:46:17 playya: https://git.ring0.de/libisi/commit/?id=c053aae3dee0536130c8ef01862d1c5ff47c413e Nov 01 14:46:20 what's cish? Nov 01 14:53:06 sehr stark c orientiert Nov 01 14:54:02 looks good Nov 01 14:56:43 I'm tried to get an api which fits more to vala specific things like: http://pastebin.com/wSPyxByY Nov 01 14:57:02 (not working yet because of the ownership transfer) Nov 01 15:04:01 sre_, you are elektranox? Nov 01 15:04:06 yes Nov 01 15:04:25 ah. OK Nov 01 15:04:51 sre is just based on my real name ;) Nov 01 15:06:40 yes Nov 01 15:08:36 mrmoku, do you have shadowjk's website address? Nov 01 15:10:36 sre_, gisi is imported from the ofono repository? Nov 01 15:46:05 playya: yes Nov 01 15:54:34 GNUtoo|laptop: sorry, no Nov 01 15:54:43 well... let me check where I got that script from Nov 01 15:54:46 ok Nov 01 15:54:47 thanks Nov 01 15:54:49 * mrmoku digs into backlog Nov 01 15:57:11 GNUtoo|laptop: http://enivax.net/jk/n900/charge.sh.txt Nov 01 15:58:10 mrmoku, thanks a lot Nov 01 15:59:19 # Assuming a nice round number 20mOhm for bq27200 sense resistor Nov 01 15:59:20 :D Nov 01 17:25:43 heyho Nov 01 17:29:00 * dos1 just installed todays SHR image on N900 Nov 01 17:29:31 mrmoku, JaMa, GNUtoo: nice work! Nov 01 17:30:25 i expected much more things to configure after first boot :D Nov 01 17:56:00 dos1: nice to hear :) Nov 01 18:03:13 strange thing - there is GTA01 kernel in /boot directory ;o Nov 01 18:03:29 n900 kernel is in /boot/boot/ Nov 01 18:04:15 yeah, noticed that too Nov 01 18:20:19 freesmartphone.org: 03mickey 07gdbus * r10bca242142c 10cornucopia/fsonetworkd/ (4 files in 3 dirs): fsonetworkd: (gdbus) migrate to gdbus Nov 01 18:31:04 mrmoku: Meego is recommended to be booted via u-boot Nov 01 18:31:38 is opimd using structs as hastable values somewhere? Nov 01 18:31:54 or genereal in variants? Nov 01 18:33:50 dos1: huh? how that? Nov 01 18:34:18 mrmoku: http://wiki.meego.com/ARM/N900/Install/U-Boot_from_scratch Nov 01 18:38:13 why the hell didn't they just fix kexec with pr1.3 kernel?... Nov 01 18:38:35 hehe, good question :P Nov 01 18:39:30 it was even fixed before by community and provided with those "power kernels"... Nov 01 18:42:15 freesmartphone.org: 03mickey 07gdbus * r5f44d06238aa 10cornucopia/fsotdld/ (19 files in 12 dirs): fsotdld: (gdbus) start with gdbus conversion Nov 01 18:43:00 mickeyl: ping Nov 01 18:55:19 dos1: tgough, even with power kernel I had no success with kexec Nov 01 19:03:39 dos1: did kexec work for you? Nov 01 19:03:43 no :( Nov 01 19:04:10 though tried only with pr1.3 kernel Nov 01 19:04:17 They all claimed they fixed it. Nov 01 19:04:28 What was the actual patch that's fixing kexec? Nov 01 19:04:43 Have you guys seen the diff between pr1.2 and pr1.3 kernel? Nov 01 19:05:10 https://garage.maemo.org/plugins/ggit/browse.php/?p=h-e-n;a=commitdiff;h=a2abd51199b9e61542a24ae9086ac1c6263106c4 Nov 01 19:05:15 PaulFertser: now idea... but power kernel is with kexec Nov 01 19:05:20 Here it is, along with the debian changelog they provided. Nov 01 19:05:33 even before pr1.3 i think Nov 01 19:13:42 NB#170888 - Dual boot in kernel for enabling MeeGo Nov 01 19:14:34 mrmoku, JaMa: what do I need to do in order to build shr (using OE) for armel? Nov 01 19:17:03 TAsn: your tablet? Nov 01 19:17:08 yes. Nov 01 19:17:15 you need a machine.conf Nov 01 19:17:31 that goes where? Nov 01 19:17:54 to conf :P Nov 01 19:18:00 how is that thing called? Nov 01 19:18:02 smartq? Nov 01 19:18:19 http://git.openembedded.net/cgit.cgi/openembedded/tree/conf/machine/smartq5.conf Nov 01 19:18:38 close Nov 01 19:18:39 smartq7 Nov 01 19:18:43 hmm Nov 01 19:18:56 then take this one :P Nov 01 19:18:56 http://git.openembedded.net/cgit.cgi/openembedded/tree/conf/machine/smartqv7.conf Nov 01 19:19:03 http://git.openembedded.net/cgit.cgi/openembedded/tree/conf/machine/smartqv7.conf Nov 01 19:19:05 yeah :P Nov 01 19:19:17 and of course Nov 01 19:19:21 follow our guide for building with the makefile Nov 01 19:19:22 remove this xserver-kdrive crap Nov 01 19:19:29 and just set MACHINE = smartqv7 Nov 01 19:19:32 instead of om-gta02 Nov 01 19:19:48 and report where it breaks :P Nov 01 19:19:51 :P Nov 01 19:22:29 follow our guide for building with the makefile Nov 01 19:22:31 what guide? Nov 01 19:23:29 building shr? Nov 01 19:25:29 TAsn: yup Nov 01 19:25:43 nothing about confs there Nov 01 19:26:32 shr-unstable/conf/auto.conf Nov 01 19:26:39 is your friend Nov 01 19:28:41 hm.. this machine.conf (smartq) looks pretty lame. Nov 01 19:28:43 and lacking Nov 01 19:28:44 and old Nov 01 19:32:36 will have to tweak it, or so it seems. Nov 01 19:38:18 TAsn: in what sense lame? Nov 01 19:38:28 dunno, it's empty :P Nov 01 19:38:32 no kernel modules Nov 01 19:38:46 (for the image at least) Nov 01 19:38:57 MACHINE_EXTRA_RRECOMMENDS = "marvell-sdio-fw kernel-modules" Nov 01 19:39:05 should install all kernel modules in the image Nov 01 19:39:26 oh, didn't see that. Nov 01 19:39:41 isn't that bad though? Nov 01 19:39:51 over including stuffL Nov 01 19:39:52 ? Nov 01 19:40:54 hmm...dunno Nov 01 19:40:57 don't think so Nov 01 19:41:06 anyway... just try what happens :) Nov 01 19:41:18 PaulFertser: list of patches needed for kexec to work with old pr1.2 kernel is on http://wiki.meego.com/ARM/N900/Install/kexec Nov 01 19:41:22 yeah Nov 01 19:41:25 well make setup Nov 01 19:41:27 is taking ages anyway :P Nov 01 19:47:59 1 John Difool 103 Nov 01 19:48:00 28.10.2010 22:09 Nov 01 19:48:05 uups Nov 01 19:48:32 JaMa: did you succeed? Nov 01 19:52:58 freesmartphone.org: 03Frederik.Sdun 07vala-dbus-binding-tool * rfd89af4941d6 10/src/vala-dbus-binding-tool.vala: gdbus: generate convinience method to convert Variants to structs Nov 01 19:53:34 Variants -> struct doesn't work yet :( Nov 01 19:54:18 no struct -> Variant :D Nov 01 19:55:25 JaMa: thanks :) Nov 01 19:56:06 mrmoku, I should just steal lines 24-29 excluding 27 from om-gta02 right Nov 01 19:56:07 L Nov 01 19:56:08 ? Nov 01 19:58:33 mrmoku, hm.. it seems that it needs python2 but I have python3 as default in arch Nov 01 19:58:35 ffs Nov 01 19:58:42 what to do? Nov 01 19:58:55 use it to go surfing ;) Nov 01 19:59:39 huh? Nov 01 19:59:45 I'll just sed bitbake Nov 01 19:59:51 but I wonder if there'll be more trouble Nov 01 20:00:12 ahh... in arch like arch the distro... not architecture :P Nov 01 20:00:24 hmm Nov 01 20:00:40 JaMa: is bitbake from master python3 ready? Nov 01 20:03:04 that'd be better than the hack I did :P Nov 01 20:03:19 find and sed :P Nov 01 20:07:33 building... :) Nov 01 20:08:45 mrmoku, http://pastebin.com/KAKsQp9N Nov 01 20:09:04 wth is wrong with bitbake? :P Nov 01 20:09:07 it prints everything ugly. Nov 01 20:17:36 mrmoku: still not with pr1.3 kernel and since then hunting in glamo woods :/ Nov 01 20:17:58 mrmoku: yes.. you can switch it in that chroot :) Nov 01 20:21:07 JaMa: "To clarify, this works booting 2.6.33-rc1 in a loop, booting Nov 01 20:21:07 the Maemo kernel with kexec does not seem to boot very far Nov 01 20:21:07 at all for some reason. I'll look into that next. Nov 01 20:21:08 " Nov 01 20:24:35 where are you reading it? Nov 01 20:25:29 JaMa: basically the source of the patches: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg21465.html Nov 01 20:25:56 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg21250.html in fact Nov 01 20:27:52 JaMa: i mean it looks like those patches you gave a link me to are applied (three of them, without DCC which is kind of debug console, i think it's not strictly needed for kexec). Nov 01 20:29:46 yes some pr1.3 announcements said they sould be applied.. but still didn't work for me Nov 01 20:31:24 JaMa: they're applied. Are you trying to boot a 2.6.35 kernel or at least 2.6.33? Nov 01 20:31:49 See, the maemo kernel hangs due to this: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg21256.html Nov 01 20:32:42 JaMa: i mean i actually took a look at the patches you gave me a link to and compared to the official pr1.3 source and they seem to be there all right. Nov 01 20:33:30 PaulFertser: yes I have tried to boot SHR 2.6.35 and meego 2.6.35 Nov 01 20:34:04 JaMa: hm, strange... Probably means they first got it working and then broke by something else. Nov 01 20:34:17 but I've also started kexec from ssh connection over vpn.. Nov 01 20:34:54 PaulFertser: stskeeps wrote in a blog that one problem is driver for ext mmc not re-initializing correctly... or something like that Nov 01 20:35:04 so I haven't seen any output from it and maybe vpn connection was killed too soon (but I guess kexec -e doesn't need terminal once executed..) Nov 01 20:35:45 maybe I should use --no-ifdown at least.. Nov 01 20:35:53 well, here everything just hangs after kexec -e :P Nov 01 20:36:09 then it's the same as here Nov 01 20:36:15 yup, here too Nov 01 20:36:24 I'm really puzzled about that. The patches are there included in pr1.3 and it doesn't seem like anything else should brake kexec... Nov 01 20:36:46 Does anybody (meego folks?) has JTAG access to check? Nov 01 20:37:06 though i tried only 2.6.28, so that would be normal Nov 01 20:37:32 mrmoku/dos1 have you tried it from meego kernel? Nov 01 20:37:47 JaMa: no, PR1.3 and power kernel Nov 01 20:37:52 PaulFertser: not blog... here: http://lists.meego.com/pipermail/meego-dev/2010-May/002277.html Nov 01 20:38:08 ant said something about kexec issues with eglibc.. so maybe it won't work from SHR Nov 01 20:38:46 here only PR1.2 and 1.3 kernels, from both SHR and Maemo Nov 01 20:39:06 mrmoku: no blockers there... Nov 01 20:39:30 dos1: have you successfully tried kexecing those before? Nov 01 20:40:06 PaulFertser: no, it was always hanging Nov 01 20:40:28 I mean the author of the patches said kexecing _maemo_ (and derived) kernels doesn't work for him. Nov 01 20:40:51 That if you are testing kexec functionality, you must be trying to kexec at least 2.6.33. Nov 01 20:40:58 ok Nov 01 20:41:11 So probably PR1.3 kernel is all right in this regard. Nov 01 20:41:22 (capable of booting recent meego kernels) Nov 01 20:42:00 ok Nov 01 20:47:02 mickeyl: double ping Nov 01 20:47:21 triple ping Nov 01 20:49:59 desperate ping Nov 01 20:50:04 imaginary ping Nov 01 20:50:12 filthy ping ;) Nov 01 20:50:16 thoughtful ping Nov 01 20:50:32 last-call ping Nov 01 20:50:43 offtopic ping Nov 01 20:51:04 ping-pong ping Nov 01 20:51:35 tennis ping Nov 01 20:51:41 quick question: how to build shr-u images for different machines in my OE build env? MACHINE="machine1 machine2" ? Nov 01 20:52:52 pespin: one after the other Nov 01 20:53:34 mrmoku, so I have to build, then change config, then build another time? Nov 01 20:53:52 yes or set those in for cycle :) Nov 01 20:54:24 you can even use environment variable to set it if you add it to BB_ENV_WHITELIST Nov 01 20:54:57 err export BB_ENV_EXTRAWHITE="MACHINE DISTRO" Nov 01 20:54:59 ok :) Nov 01 20:55:22 I just thoguht that btibake was able to handle different machines in the same build Nov 01 20:56:29 PaulFertser: same with meego kernel... just hangs Nov 01 20:56:31 well it still has to build MACHINE_ARCH for each one.. so it's almost the same Nov 01 20:56:45 mrmoku: weird Nov 01 20:56:54 mrmoku: but thanks for testing. Nov 01 20:56:55 mrmoku: do you also have 1.1 relase? Nov 01 20:57:33 JaMa: yup Nov 01 20:57:46 did not manage to boot it yet though :P Nov 01 20:58:26 mrmoku: not even with flasher? Nov 01 21:00:00 23:53 < E0x> tell with a week using my n900 with pr1.3 i can really see a huge improve in the battery life Nov 01 21:00:06 at #maemo Nov 01 21:00:33 JaMa: let me try Nov 01 21:02:18 JaMa: no, getting a kernel ooops Nov 01 21:02:34 unknown-block(179,1) Nov 01 21:03:32 JaMa: it shows me all available partitions... nice Nov 01 21:03:44 but mmcblkp1pX is not there Nov 01 21:04:29 and yes... back cover is in place :-) Nov 01 21:05:35 mrmoku: that's probably the problem Stskeeps described (not finding external mmc). Nov 01 21:06:07 PaulFertser: but this was not kexec... tried to boot with flasher instead Nov 01 21:06:19 mrmoku: probably similar problem. Nov 01 21:06:57 mrmoku: do you have rootfs on uSD card, right? Nov 01 21:07:24 mrmoku: I had problem with pre 1.1 kernel but that was because of missing btrfs support in kernel Nov 01 21:07:41 mrmoku: it listed all available partitions and then no rootfs Nov 01 21:07:53 hmm Nov 01 21:07:54 s/partitions/supported fs/ Nov 01 21:07:54 JaMa meant: mrmoku: it listed all available supported fs and then no rootfs Nov 01 21:08:05 PaulFertser: it's the external I see there though Nov 01 21:08:27 meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 Nov 01 21:08:28 but with kernel-n900-2.6.35.3-15.1.armv7l/boot/vmlinuz-2.6.35.3-15.1-n900 and then meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 it worked ok Nov 01 21:08:30 meego-handset-armv7l-n900-1.1-mmcblk0p.raw Nov 01 21:08:55 huh... 15.1 Nov 01 21:09:49 mrmoku: fucking mess... Nov 01 21:10:45 mrmoku: well I didn't write whole raw image.. (because I had already 2nd partition with SHR and 3rd with swap.. so I've only written 1st partition extraced from this image to already created partition on uSD Nov 01 21:11:35 hmm Nov 01 21:14:16 JaMa: how did you extract the partition? Nov 01 21:14:55 NOTE: Running task 1345 of 8980 Nov 01 21:15:00 a lot faster than it used to on my old pc Nov 01 21:15:09 but still bah so much time :P Nov 01 21:34:04 mrmoku: dd bs=512 skip=1 if=meego-handset-armv7l-n900-1.1-mmcblk0p.raw of=/dev/sdj1 count=3125000 Nov 01 21:34:18 JaMa: ahh, ok Nov 01 21:35:02 JaMa: I did dd again according to the original instructions Nov 01 21:35:19 * mrmoku should have read them more careful the other day :P Nov 01 21:35:21 still the same though Nov 01 21:35:35 did you write it to dev/sdX not dev/sdXn, right? ;) Nov 01 21:35:44 this time yes :P Nov 01 21:36:04 :) Nov 01 21:36:28 and are you able to mount that btrfs partition on desktop with uSD in card reader? Nov 01 21:38:03 hmm... no Nov 01 21:38:41 0002 mok@gonzales[pts/1]:~/Downloads/n900-> LANG=C sudo mount -t btrfs /dev/mmcblk0p1 /mnt/neo/ Nov 01 21:38:44 mount: /dev/mmcblk0p1: can't read superblock Nov 01 21:43:00 what's gonzales? :) Nov 01 21:43:11 does it have BTRFS enabled in kernel? Nov 01 21:43:57 I can read it just fine with my 2.6.36 Nov 01 21:46:15 JaMa: gonzales is my laptop... and yes, it has btrfs :) Nov 01 21:46:15 0002 mok@gonzales[pts/1]:~/Downloads/n900-> cat /proc/filesystems | grep btrfs btrfs Nov 01 21:46:45 0002 mok@gonzales[pts/1]:~/Downloads/n900-> cat /proc/version Nov 01 21:46:45 Linux version 2.6.35.6-48.fc14.x86_64 (mockbuild@x86-02.phx2.fedoraproject.org) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Fri Oct 22 15:36:08 UTC 2010 Nov 01 21:50:26 anyway... will find out tomorrow Nov 01 21:50:31 gnight Nov 01 21:53:09 gnight Nov 01 22:15:54 JaMa, why does it build gnome-vfs in shr image? Nov 01 22:22:20 at least due desktop-file-utils **** ENDING LOGGING AT Tue Nov 02 02:59:57 2010