**** BEGIN LOGGING AT Fri Nov 11 03:00:01 2016 Nov 11 07:24:32 jonwil: ’lo. Nov 11 15:59:37 freemangordon: is our thumb toolchain for cssu special? or upstream gcc can be used for producing arm thumb2 binaries correctly? Nov 11 17:00:14 Pali: nothing special, besides libc version Nov 11 17:00:29 and libc version is some special? Nov 11 17:00:35 or also comes from upstream? Nov 11 17:00:45 Pali: libc is maemo eglibc Nov 11 17:01:31 so we take current debian armhf port with thumb2 enabled binaries and it can run on n900 without any problems like hw errata segfaults? Nov 11 17:02:03 yes Nov 11 17:02:31 ok, that is great Nov 11 17:02:38 I ran devuan lxde a week or ao ago without any problems Nov 11 17:02:57 build with devuan arm-sdk Nov 11 17:03:10 which I guess uses upstream gcc Nov 11 17:03:46 Pali: by the way, do you have any idea how to test iphbd? Nov 11 17:04:17 start dsme and use it Nov 11 17:04:25 dsme is heavy user of iphbd Nov 11 17:04:25 I mean - I have it REed, but what this is supposed to do? Nov 11 17:04:28 hmm Nov 11 17:04:58 I am trying to do that in devuan 64 bit chroot :) Nov 11 17:05:07 lemme see if dsme will start there Nov 11 17:06:00 http://talk.maemo.org/showthread.php?t=89709 Nov 11 17:06:50 Pali: hmm, how to start dsme? Nov 11 17:07:04 it is started by upstart Nov 11 17:07:15 try to look at /etc/event.d/dsme Nov 11 17:07:42 yes, but this is chroot, is it safe to install upstart there? and eve installed, who is going to start it? Nov 11 17:08:50 hmm: Nov 11 17:08:53 dpkg: considering removing sysvinit in favour of upstart ... Nov 11 17:08:54 dpkg: yes, will remove sysvinit in favour of upstart Nov 11 17:08:54 dpkg: regarding upstart_0.3.8-68+0cssu9_amd64.deb containing upstart: Nov 11 17:08:54 sysvinit-core conflicts with upstart Nov 11 17:08:54 upstart (version 0.3.8-68+0cssu9) is to be installed. Nov 11 17:08:54 dpkg: error processing archive upstart_0.3.8-68+0cssu9_amd64.deb (--install): Nov 11 17:08:54 conflicting packages - not installing upstart Nov 11 17:08:55 Errors were encountered while processing: Nov 11 17:08:55 upstart_0.3.8-68+0cssu9_amd64.deb Nov 11 17:09:21 Pali: ^^^ Nov 11 17:09:49 maemo's upstart is different as debian's Nov 11 17:10:06 it will not work Nov 11 17:10:26 look at dsme's script /etc/event.d/dsme how to init daemon starting it Nov 11 17:10:31 and start it manually Nov 11 17:10:33 ok, is it ok if I remove csysvinit-core and install maemo upstart? Nov 11 17:11:01 if you do that on debian/ubuntu you will get unbootable system Nov 11 17:11:03 mind you, this is chroot, so even if I screw it, it is not a problem Nov 11 17:11:13 upstart is init daemon Nov 11 17:11:14 freemangordon: arm-sdk uses my toolchains to compile the kernel, all other bins/libs are made with vanilla (as in debian) Nov 11 17:11:27 same as systemd or sysvinit Nov 11 17:11:35 parazyd: thanks Nov 11 17:11:36 in chroot you are not running any init daemon Nov 11 17:11:47 yes, but I guess I can start it by hand Nov 11 17:12:08 yes, look at that script how upstart starting it Nov 11 17:12:13 and start it manually Nov 11 17:12:22 Pali: so, it is safe to replace sysvinit with upstart, correct? in chroot that is Nov 11 17:12:23 is upstart the only init that suffices? Nov 11 17:12:36 why you want to replace it? Nov 11 17:12:49 or what do you want to achieve? Nov 11 17:12:52 because dsme in even.t is not that simple Nov 11 17:13:05 in chroot you are not running init daemon Nov 11 17:13:09 so it will not work Nov 11 17:13:19 Pali: yes, but I can start it by hand I guess Nov 11 17:13:30 or not? Nov 11 17:13:34 what do you mean by hand? Nov 11 17:13:44 by hand = look at script and type commands manually Nov 11 17:13:48 you should rather run it all in a qemu Nov 11 17:13:48 like /sbin/upstart or whatever the binary is Nov 11 17:13:55 that will not work Nov 11 17:14:09 as I wrote in chroot you are not running init daemon Nov 11 17:14:16 init daemon = process with pid 1 Nov 11 17:14:18 Pali: ok Nov 11 17:14:30 install systemd :) Nov 11 17:14:34 parazyd: for initial stages chroot is easier to setup Nov 11 17:14:54 sicelo: freemangordon is in chroot, it will not work too Nov 11 17:15:01 :D Nov 11 17:15:06 :D Nov 11 17:15:08 :P Nov 11 17:15:08 Pali: don;t bet on that Nov 11 17:15:41 after all, this is systemd, I would not be suprised if it does kexec on it's own kernel to take over the machine from chroot :D Nov 11 17:16:45 Pali: what are the chances for dsme to reboot/shutdown my machine once started? Nov 11 17:17:21 it is possible Nov 11 17:17:53 not dsme itself, but some module Nov 11 17:17:59 :) Nov 11 17:18:16 anyway, it refuses to start because it cannot read R&D flags Nov 11 17:20:12 hmm, idea Nov 11 17:20:24 separate init daemon from maemo core daemons Nov 11 19:03:29 freemangordon: about wl1251... I sent email to lkml, you are on CC list Nov 11 20:46:39 Pali: ok Nov 11 22:41:46 Pali: well, I was able to finally start dsme in devuan chroot, but it doesn't seem to use iphbd Nov 11 22:42:47 Pali: BTW, dsme in CSSU has a nasty bug in https://github.com/community-ssu/dsme/blob/master/logging.c#L291 Nov 11 22:51:45 freemangordon: probably you need whole running system to see iphbd in action... Nov 11 22:51:47 which bug? Nov 11 22:52:14 va_list is used in 2 vXXX function, leading to a SEGFAULT Nov 11 22:52:42 I am preparing a commit to fix it Nov 11 22:55:15 Pali: https://github.com/community-ssu/dsme/commit/be8b90327aa12eeb9706bfb5d1305e3c2897e35b Nov 11 22:55:34 shit Nov 11 22:55:41 yep Nov 11 22:55:58 Pali: is this dsme supposed to be the same as in Fremantle? Nov 11 22:56:08 dsme in cssu? Nov 11 22:56:09 yes Nov 11 22:56:13 cool Nov 11 22:56:39 100% same Nov 11 22:56:41 it is weird it does not crash on n0-- Nov 11 22:56:45 *n900 Nov 11 22:56:54 optimizations? thumb2? Nov 11 22:57:15 should not matter, maybe only logging level matters Nov 11 22:57:46 see https://github.com/community-ssu/dsme/blob/be8b90327aa12eeb9706bfb5d1305e3c2897e35b/logging.c#L297 Nov 11 22:58:36 but it looks to me that any critical or higher level message should result in crash Nov 11 22:59:13 maybe its not used at all? Nov 11 22:59:21 sure it is Nov 11 22:59:41 caught up and ignored? Nov 11 22:59:46 patch looks ok Nov 11 23:00:14 Pali: and fixes the segfault, at least on devuan Nov 11 23:00:46 my guess are optimizations Nov 11 23:01:26 or vXXX somehow does not alter va_list qp Nov 11 23:01:41 *ap Nov 11 23:01:49 anyway Nov 11 23:02:16 that could be because of optimizations too... Nov 11 23:02:51 I doubt, you can't use va_list twice according to man page Nov 11 23:02:57 are you using armhf devuan? Nov 11 23:03:25 no, x86_64 Nov 11 23:03:36 :D Nov 11 23:03:46 toldya, chroot on my pc Nov 11 23:04:04 ah, that is reason Nov 11 23:04:18 x86_64 has different behaviour of va_list as arm Nov 11 23:04:36 maybe arm uses regs Nov 11 23:04:47 not the stack Nov 11 23:04:56 if va_list is implemented as struct, then subsequent calls copy it Nov 11 23:05:06 iirc the first 3 or 4 arguments are always in the regs Nov 11 23:05:08 but if as pointer, then it modify it directly... Nov 11 23:05:37 yeah Nov 11 23:06:06 iphbd uses special kernel module Nov 11 23:06:16 iphb.ko Nov 11 23:06:19 I know, but it works without it as well Nov 11 23:06:21 or how it is called Nov 11 23:08:23 there was meego libiphb git repository... does not it contains sources also of iphbd? Nov 11 23:10:30 it is implemented in a different way Nov 11 23:12:17 Pali: http://pastebin.com/3wJFL8Xj :) Nov 11 23:12:47 working :-) Nov 11 23:12:58 yeah, but doing nothing **** ENDING LOGGING AT Sat Nov 12 03:00:00 2016