**** BEGIN LOGGING AT Fri Apr 01 02:59:58 2011
Apr 01 04:20:25 <morphis> mickeyl: ping
Apr 01 04:26:21 <morphis> mickeyl: I find out whats causing the "dcd+ dsr+ break- ring- framing- parity- overrun" line settings
Apr 01 05:08:49 <morphis> mickeyl: we only get the line with the changed line settings from kernel once after a kernel reboot
Apr 01 05:08:50 <morphis> Jan  1 00:52:59 palmpre user.info kernel: [   80.760000] cdc_acm 1-1:1.0: set control lines: dtr+ rts+
Apr 01 05:08:50 <morphis> Jan  1 00:52:59 palmpre user.info kernel: [   80.760000] cdc_acm 1-1:1.0: set line: dte_rate=115200 char_format=0 parity_type=0 data_bits=8
Apr 01 05:08:50 <morphis> Jan  1 00:52:59 palmpre user.info kernel: [   80.770000] cdc_acm 1-1:1.0: input control lines: dcd+ dsr- break- ring- framing- parity- overrun-
Apr 01 05:08:52 <morphis> Jan  1 00:52:59 palmpre user.info kernel: [   80.790000] cdc_acm 1-1:1.0: input control lines: dcd+ dsr+ break- ring- framing- parity- overrun-
Apr 01 05:08:55 <morphis> Jan  1 00:53:05 palmpre user.warn kernel: [   87.200000] acm_tty_close:
Apr 01 05:08:57 <morphis> Jan  1 00:53:06 palmpre user.info kernel: [   87.390000] cdc_acm 1-1:1.0: set control lines: dtr- rts-
Apr 01 05:09:00 <morphis> Jan  1 00:53:07 palmpre user.info kernel: [   88.990000] cdc_acm 1-1:1.0: set control lines: dtr+ rts+
Apr 01 05:09:03 <morphis> Jan  1 00:53:09 palmpre user.warn kernel: [   90.860000] acm_tty_close:
Apr 01 05:09:07 <morphis> Jan  1 00:53:09 palmpre user.info kernel: [   91.050000] cdc_acm 1-1:1.0: set control lines: dtr- rts-
Apr 01 05:09:10 <morphis> later we don't get it anymore
Apr 01 05:09:14 <morphis> there seems to be some "tty reset to initial state" logic in pppd
Apr 01 05:09:32 <morphis> as with ppp the line settings are changed every time
Apr 01 07:27:08 <CIA-66> SHR: 03Martin.Jansa 07shr-chroot * rf2d98df86fae 10/ (49 files in 16 dirs): system upgrade
Apr 01 07:27:17 <CIA-66> SHR: 03Martin.Jansa 07shr-chroot * r2a3ebf4ab48a 10/ (1985 files in 179 dirs): system upgrade
Apr 01 07:49:05 <dent> morgen
Apr 01 07:50:26 <dent> I've got some questions about FSO Usage interface
Apr 01 07:51:32 <dent> I assume fso impl. (ousaged?) does some reference counting - so when two clients request a resource and then one client releases the resource
Apr 01 07:51:47 <dent> the other client can still count on the resource being available, right?
Apr 01 07:52:56 <PaulFertser> dent: yes
Apr 01 07:53:14 <PaulFertser> dent: nowadays that's handled by fsousaged -- a vala reimplementation.
Apr 01 07:53:19 <PaulFertser> dent: but semantics is the same.
Apr 01 07:53:24 <dent> ah, true, thanks
Apr 01 07:53:43 <dent> now,w hat if client crashes? can fsousaged handle this?
Apr 01 07:54:01 <dent> i.e. requests resource, crashes -> doesn't explicitly release
Apr 01 07:54:15 <PaulFertser> dent: the client crashes and thus releases the dbus bus, so the resource will be automatically refcounted down.
Apr 01 07:54:24 <dent> good
Apr 01 07:54:53 <dent> that also means that if I want to hold a resource, I have to hold the interface proxy to Usage, right?
Apr 01 07:56:16 <PaulFertser> dent: i have already forgotten how exactly that's called in dbus :)
Apr 01 07:56:58 <dent> ok :)
Apr 01 07:57:25 <dent> one more thing that is on my mind - what is the proper sequence of requesting a resource, to avoid races, i.e.:
Apr 01 07:57:58 <dent> (now I'm unsire wgat is async and what is sync... sigh)
Apr 01 07:58:11 <dent> anyway, simply: I want to request a resource and wait for it being available
Apr 01 07:58:38 <PaulFertser> dent: iirc requesting is not async
Apr 01 07:59:00 <dent> so, when the Request call succeeds, it means the device is already available?
Apr 01 07:59:11 * dent though I might have to wait for ResourceChanged signal
Apr 01 07:59:26 <dent> but then it would get tricky in case resource was already available before, by some other client
Apr 01 08:01:43 <PaulFertser> dent: you do not have to, when you call RequestResource syncroniously.
Apr 01 08:01:58 <dent> yeah, I do... ok, then it's easy
Apr 01 08:02:08 <dent> almost too easy :)
Apr 01 09:51:45 <mickey|office> morning
Apr 01 09:54:01 <mrmoku> morning mickey|office :P
Apr 01 09:54:25 <mrmoku> enjoy the time you're still able to say morning short before midday ;)
Apr 01 09:55:49 <mickey|office> heh
Apr 01 09:56:20 <mickey|office> actually i just came from the gynaecologist, so it's not quite the beginning of the day anymore ;)
Apr 01 09:56:41 <mrmoku> :)
Apr 01 10:08:51 <TAsn> mrmoku, archlinux.org
Apr 01 10:08:52 <TAsn> :)
Apr 01 10:12:44 <mrmoku> TAsn: ahh... yeah, almost forgot... today is 1st :P
Apr 01 10:13:30 <TAsn> yeah :)
Apr 01 10:13:32 <TAsn> a fun day.
Apr 01 10:16:45 <mickey|office> hmm
Apr 01 10:17:01 <PaulFertser> My professional holiday btw
Apr 01 10:17:05 <mickey|office> i was pondering whether to issue a statement '/me quits Vala. Java is da bomb', but i didn't bother ;)
Apr 01 10:18:15 <TAsn> mickey|office, :)
Apr 01 10:19:36 <mickey|office> mrmoku: i don't have u-boot. do i need it for the newer kernels on n900?
Apr 01 10:22:41 <mrmoku> mickey|office: according to Gnutoo it is too big to be booted directly...
Apr 01 10:23:16 <mickey|office> darn
Apr 01 10:23:16 <mrmoku> JaMa: what is *the good* u-boot for n900 ?
Apr 01 10:24:09 <mrmoku> mickey|office: maybe we could try to shrink it a bit
Apr 01 10:24:18 <mrmoku> no idea where the limit is though
Apr 01 10:24:27 <mrmoku> and gnutoo is not here 
Apr 01 10:25:13 <JaMa> the one listed on wiki, mmt
Apr 01 10:25:39 <JaMa> http://build.shr-project.org/shr-unstable/images/nokia900/u-boot-nokia900-2010.06+gitr0+bd2313078114c4b44c4a5ce149af43bcb7fc8854-r68.bin
Apr 01 10:26:35 <JaMa> mrmoku: the one with .ok is the same
Apr 01 10:27:04 <JaMa> mrmoku: and .dos-like is booting emmc by default (with kbd closed)
Apr 01 10:27:45 <mickey|office> where does it look for the uImage?
Apr 01 10:29:09 <JaMa> 5/boot/uImage
Apr 01 10:31:14 <mickey|office> hmm... ookay...
Apr 01 10:33:03 <morphis> heyho
Apr 01 10:33:06 <morphis> mickey|office: ping
Apr 01 10:34:42 <CIA-66> freesmartphone.org: 03morphis 07msmcomm * re9afab3d3a87 10/libmsmcomm/ (10 files in 5 dirs): libmsmcomm: implement most supplementary service messages
Apr 01 10:34:44 <CIA-66> freesmartphone.org: 03morphis 07msmcomm * r64fcd6413ff7 10/msmcommd/src/ (Makefile.am dbusservice.vala supsservice.vala): msmcommd: implement sups service interface
Apr 01 10:34:46 <CIA-66> freesmartphone.org: 03morphis 07msmcomm * rc80763b13815 10/msmcomm-specs/src/ (Makefile.am sups.vala): msmcomm-specs: add interface definition for sups service
Apr 01 10:34:54 <mickey|office> hier bei der Arbeit...
Apr 01 10:35:11 <morphis> mickey|office: :)
Apr 01 10:35:35 <morphis> mickey|office: I looked a little bit closer at the whole line settings thing for ppp
Apr 01 10:37:16 <morphis> mickey|office: I compared the termios settings pppd sets and what we use and wrote a little test app which does the same as pppd but pppd still is causing the input-control-line entry in the kernel log every when it starts and my test app not
Apr 01 10:37:49 <morphis> so it must be another option somewhere in pppd which is causing the ttyACM0 node to reconfigure it's input control line everytime when it starts
Apr 01 10:38:30 <morphis> but I don't know for which option I have to look for
Apr 01 10:39:20 <mickey|office> ok, so we need to dive into the pppd source code to check what it's doing when it controls the modem lines
Apr 01 10:40:55 <morphis> correct
Apr 01 10:41:10 <morphis> I already checked out the sources and took a look at the sys-linux.c file
Apr 01 10:41:23 <morphis> thats the place where it does the tty configuration
Apr 01 10:41:53 <morphis> btw. do you have time now to talk about or should we defer the discussion?
Apr 01 10:52:18 <mickey|office> give me 10 minutes for the bathroom, then i'm back. now is a good time, today is not too busy here
Apr 01 10:56:47 <CIA-66> freesmartphone.org: 03morphis 07msmcomm * r0cce4c352424 10/msmcomm-specs/src/sups.vala: msmcomm-specs: add missing async identifier
Apr 01 10:57:34 <morphis> mickey|office: ok, I have to leave for some minutes as I have to catch my train but we will be available over GPRS then
Apr 01 10:57:49 <morphis> train leaves at 13.24
Apr 01 11:02:36 <morphis> mickey|office: my test program is here: http://pastie.org/1743207
Apr 01 11:27:12 <morphis> mickey|office: so I am back
Apr 01 11:27:24 <morphis> let's see how stable the connection is ...
Apr 01 11:28:17 <mickey|office> yep
Apr 01 11:30:19 <morphis> mickey|office: do you already looked at my simple test program?
Apr 01 11:31:31 <morphis> Jan  1 07:16:11 palmpre user.info kernel: [   39.430000] cdc_acm 1-1:1.0: set control lines: dtr+ rts+
Apr 01 11:31:32 <morphis> Jan  1 07:16:11 palmpre user.info kernel: [   39.430000] cdc_acm 1-1:1.0: set line: dte_rate=115200 char_format=0 parity_type=0 data_bits=8
Apr 01 11:31:32 <morphis> Jan  1 07:16:11 palmpre user.info kernel: [   39.450000] cdc_acm 1-1:1.0: input control lines: dcd+ dsr- break- ring- framing- parity- overrun-
Apr 01 11:31:32 <morphis> Jan  1 07:16:11 palmpre user.info kernel: [   39.480000] cdc_acm 1-1:1.0: input control lines: dcd+ dsr+ break- ring- framing- parity- overrun-
Apr 01 11:31:34 <morphis> Jan  1 07:16:14 palmpre user.warn kernel: [   42.440000] acm_tty_close:
Apr 01 11:31:36 <morphis> Jan  1 07:16:14 palmpre user.info kernel: [   42.630000] cdc_acm 1-1:1.0: set control lines: dtr- rts-
Apr 01 11:31:40 <morphis> this is the output after a reboot and running test-serial
Apr 01 11:31:47 <morphis> looks good
Apr 01 11:32:08 <morphis> but if I restart it it looks like this
Apr 01 11:32:11 <morphis> ^[[AJan  1 07:16:45 palmpre user.info kernel: [   73.370000] cdc_acm 1-1:1.0: set control lines: dtr+ rts+
Apr 01 11:32:11 <morphis> Jan  1 07:16:48 palmpre user.warn kernel: [   76.370000] acm_tty_close:
Apr 01 11:32:11 <morphis> Jan  1 07:16:48 palmpre user.info kernel: [   76.560000] cdc_acm 1-1:1.0: set control lines: dtr- rts-
Apr 01 11:32:21 <morphis> no more input control line settings
Apr 01 11:38:32 <morphis> mickeyl: when starting pppd the input control line changes occur after the chat program is executed
Apr 01 11:46:21 <morphis> mickey|office: ah I think I solved the problem
Apr 01 11:46:39 <morphis> I got the line
Apr 01 11:46:43 <morphis> input control lines: dcd+ dsr+ break- ring- framing- parity- overrun-
Apr 01 11:46:48 <morphis> with my test-serial tool
Apr 01 11:47:05 <morphis> even after I have executed pppd and the tool x times before
Apr 01 11:47:21 <mickey|office> ok, excellent
Apr 01 11:47:29 <morphis> mickey|office: if you look at the code
Apr 01 11:47:33 <morphis> it's still the same
Apr 01 11:47:34 <morphis> btu
Apr 01 11:47:43 <morphis> s/btu/but/
Apr 01 11:47:43 <apt> morphis meant: but
Apr 01 11:47:57 <morphis> set_termios(fd);
Apr 01 11:47:58 <morphis> 	setdtr(fd, 0);
Apr 01 11:47:58 <morphis> 	sleep(1);
Apr 01 11:47:58 <morphis> 	setdtr(fd, 1);
Apr 01 11:47:58 <morphis> 	char buffer[100];
Apr 01 11:47:58 <morphis> 	snprintf(buffer, 100, "ATZ\r");
Apr 01 11:47:59 <morphis> 	write(fd, buffer, 100);
Apr 01 11:48:02 <morphis> in main()
Apr 01 11:48:09 <morphis> with
Apr 01 11:48:11 <morphis> void setdtr (int tty_fd, int on)
Apr 01 11:48:12 <morphis> {
Apr 01 11:48:12 <morphis>     int modembits = TIOCM_DTR;
Apr 01 11:48:13 <morphis>     ioctl(tty_fd, (on ? TIOCMBIS : TIOCMBIC), &modembits);
Apr 01 11:48:15 <morphis> }
Apr 01 11:48:26 <morphis> thats what pppd does
Apr 01 11:49:03 <morphis> with the comment in pppd "in case modem is off hook"
Apr 01 11:49:20 <mickey|office> hmm, ok
Apr 01 11:49:59 <morphis> as with dtr we say the modem "hey we have data to send" and it then reconfigures the usb device
Apr 01 11:49:59 <mickey|office> so you think it could be enough to execute this before launching the internal ppp.open or before sending the commands?
Apr 01 11:50:21 <morphis> pppd does it before sending any command
Apr 01 11:50:42 <morphis> maybe we should integrate it in our transport
Apr 01 11:51:07 <mickey|office> yes, this is actually something that should be handled by the serial transport
Apr 01 11:51:18 <morphis> ok
Apr 01 11:51:54 <morphis> but it should not be executed for all users of the serial transport, right?
Apr 01 11:53:39 <mickey|office> no, it should be a function so we can issue it on-demand
Apr 01 11:53:43 <mickey|office> or rather, yes.
Apr 01 12:01:22 <mickey|office> bbiab, lunch
Apr 01 12:12:13 <morphis> do you discovered the same problem with the internal stack on other devices?
Apr 01 12:12:44 <morphis> mickey|office: or which type of serial dev node do you used for testing the internal ppp stack?
Apr 01 12:12:51 <morphis> mickey|office: not a usb serial right?
Apr 01 12:15:39 <morphis> would be interesting if we have the same problem with other modems connected via usb serial
Apr 01 12:16:37 <morphis> I am unsure where to place the dtr-cycle as it is currently palmpre-specific
Apr 01 12:17:01 <morphis> so maybe we should create another transport type and add it there?
Apr 01 12:17:33 <morphis> or add a configure switch which we than check within the serial transport?
Apr 01 12:18:23 <morphis> mickey|office: hm, we already set the dtr line when hard = true in the serial channel
Apr 01 12:19:11 <morphis> I have to leave
Apr 01 12:19:14 <morphis> bye
Apr 01 13:20:01 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * r3dc51651db68 10/libfsotransport/fsotransport/basetransport.vala: libfsotransport: refactor port speed parsing into own method
Apr 01 13:20:10 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * r9a692bc30d2c 10/fsogsmd/src/plugins/modem_qualcomm_palm/ (Makefile.am atchannel.vala plugin.vala): fsogsmd: modem_qualcomm_palm: use our own at channel implementation as data channel
Apr 01 14:20:04 <Martix> no news today?
Apr 01 16:00:01 <morphis> heyho
Apr 01 16:03:05 <morphis> mickey|office: what about adding an config option like [libfsotransport] dtr_cycle = 1?
Apr 01 16:05:06 <morphis> hm, but we do not access the config within libfsotransport
Apr 01 16:19:43 <morphis> GNUtoo: heyho
Apr 01 16:19:56 <GNUtoo> hi
Apr 01 16:23:05 <GNUtoo> mrmoku, hi, any news?
Apr 01 16:23:08 <GNUtoo> on what are you working?
Apr 01 16:24:15 <morphis> me?
Apr 01 16:24:30 <GNUtoo> I wanted to ask about n900
Apr 01 16:24:34 <GNUtoo> the current status
Apr 01 16:24:38 <morphis> ah ok
Apr 01 16:25:31 <mrmoku> GNUtoo: next thing I'm going to do is to try all n900 mediators that do not depend on network registration
Apr 01 16:25:37 <mrmoku> that's not many anyway :P
Apr 01 16:25:43 <mrmoku> to see if that works
Apr 01 16:25:54 <mrmoku> I gave up on building a libnl1 image
Apr 01 16:26:07 <GNUtoo> ah
Apr 01 16:26:15 <GNUtoo> so I've 3 things to do:
Apr 01 16:26:18 <GNUtoo> *buglabs stuff
Apr 01 16:26:21 <GNUtoo> *libnl1
Apr 01 16:26:29 <GNUtoo> *kenrel 
Apr 01 16:26:30 <GNUtoo> ?
Apr 01 16:26:52 <mrmoku> I guess mickey|office would appreciate a kernel he could flash directly
Apr 01 16:42:13 <mrmoku> GNUtoo: another thing I could do is see what's up with fsodeviced
Apr 01 16:42:55 <GNUtoo> in what sense?
Apr 01 16:46:59 <mrmoku> in the sense that it segfaults a lot when enabling the wanted plugins
Apr 01 16:53:12 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * r2533394552c0 10/libfsotransport/fsotransport/serial.vala: libfsotransport: implement option for serial transport to cycle dtr line
Apr 01 16:53:15 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * r88534291a9d1 10/fsogsmd/src/plugins/pdp_ppp_internal/plugin.vala: fsogsmd: pdp_ppp_internal: use cycle dtr option of serial transport if config option is set
Apr 01 16:53:37 <morphis> mrmoku, GNUtoo: someone of you already tried to use fsoaudiod on the n900?
Apr 01 16:53:48 <GNUtoo> no
Apr 01 16:53:56 <GNUtoo> how to try?
Apr 01 16:54:06 <GNUtoo> I also want to try on htcdream
Apr 01 16:54:14 <GNUtoo> I bet it works on om-gta02 tough
Apr 01 16:54:58 <morphis> it should
Apr 01 16:55:00 <morphis> as it uses alsa
Apr 01 16:55:09 <morphis> GNUtoo: do you already have it installed?
Apr 01 16:55:23 <morphis> first step is to create a config for the device
Apr 01 16:55:57 <GNUtoo> morphis, I think so, I need to boot it tough
Apr 01 16:56:01 <GNUtoo> let me boot it
Apr 01 16:56:04 <morphis> ok
Apr 01 16:56:19 <morphis> GNUtoo: so you have some time to try?
Apr 01 16:56:40 <GNUtoo> yes
Apr 01 16:56:45 <morphis> great
Apr 01 16:57:03 <morphis> which alsa scenario files do we have for the n900?
Apr 01 16:57:40 <GNUtoo> none
Apr 01 16:57:47 <GNUtoo> we had some for 2.6.28
Apr 01 16:58:14 <morphis> ok you need them to try
Apr 01 16:58:39 <morphis> the mode:device combination is mapped in the background to scenario files
Apr 01 16:58:53 <GNUtoo> ah?
Apr 01 16:58:59 <GNUtoo> maybe I should try on the dream then
Apr 01 16:59:14 <GNUtoo> for n900 we need a kernel and modem
Apr 01 16:59:43 <morphis> GNUtoo: new audio api does not speak in scenarios
Apr 01 16:59:54 <morphis> you have two modes: normal and calll
Apr 01 17:00:06 <morphis> and a lot of devices like: backspeaker, frontspeaker, ...
Apr 01 17:00:12 <GNUtoo> ok
Apr 01 17:00:25 <GNUtoo> maybe let's see that later then if it's not urgent?
Apr 01 17:00:26 <morphis> e.g. normal:backspeaker is stereoout
Apr 01 17:00:33 <morphis> it's not :)
Apr 01 17:00:37 <GNUtoo> ok
Apr 01 17:00:49 <morphis> but someone should try as I didn't tested the alsa backend
Apr 01 17:00:55 <GNUtoo> because kernel, fsodeviced.conf and modem is urgent
Apr 01 17:00:58 <GNUtoo> ah?
Apr 01 17:00:59 <GNUtoo> ok
Apr 01 17:01:10 <GNUtoo> then ask someone with om-gta02
Apr 01 17:02:28 <morphis> on htc dream do you have no scenarios, right?
Apr 01 17:02:44 <GNUtoo> hmmm indeed
Apr 01 17:02:46 <GNUtoo> no routing
Apr 01 17:02:54 <GNUtoo> I've om-gta02 too
Apr 01 17:03:50 <morphis> ok
Apr 01 17:03:51 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * rfabefdb01833 10/fsoaudiod/conf/ (4 files in 2 dirs): fsoaudiod: add initial configuration for nokia n900
Apr 01 17:04:08 <morphis> I added a config for the n900 so you see how it should look like
Apr 01 17:04:16 <GNUtoo> fsoaudiod is in the feeds of om-gta02?
Apr 01 17:04:29 <morphis> it should
Apr 01 17:04:39 <morphis> as it is in the dependencies of shr-image 
Apr 01 17:04:43 <GNUtoo> ok
Apr 01 17:04:46 <morphis> somewhere in the deep ...
Apr 01 17:04:56 <GNUtoo> let me re-ask:
Apr 01 17:05:04 <GNUtoo> are the official shr feeds up to date
Apr 01 17:05:41 <morphis> don't know
Apr 01 17:05:58 <morphis> don't use it since I played with my om-gta02 a long time ago :)
Apr 01 17:06:09 <GNUtoo> ah you have om-gta02?
Apr 01 17:06:10 <morphis> s/use it/used them/
Apr 01 17:06:10 <apt> morphis meant: don't used them since I played with my om-gta02 a long time ago :)
Apr 01 17:06:14 <morphis> yes
Apr 01 17:06:18 <morphis> somewhere :)
Apr 01 17:06:19 <GNUtoo> so you can try
Apr 01 17:06:34 <morphis> but I am about 100km away from it
Apr 01 17:06:43 <GNUtoo> ahh ok
Apr 01 17:06:55 <GNUtoo> then I've to build I guess
Apr 01 17:07:10 <GNUtoo> mdbus -s should return something?
Apr 01 17:07:15 <GNUtoo> for fsoaudiod
Apr 01 17:08:05 <GNUtoo> I've fsoaudiod in path
Apr 01 17:08:10 <GNUtoo> for om-gta02
Apr 01 17:08:16 <GNUtoo> I'll connect an usb cable
Apr 01 17:09:09 <morphis> jepp
Apr 01 17:09:23 <morphis> you can use it with mdbus2 (it's the only way atm)
Apr 01 17:09:29 <GNUtoo> org.freesmartphone.oaudiod
Apr 01 17:09:34 <morphis> correct
Apr 01 17:09:45 <GNUtoo> what should I do now?
Apr 01 17:09:45 <morphis> but first check the config file
Apr 01 17:10:16 <GNUtoo> ok
Apr 01 17:10:19 <GNUtoo> where is it?
Apr 01 17:10:27 <GNUtoo> /etc/freesmartphone/conf/
Apr 01 17:10:30 <GNUtoo> om-gta02
Apr 01 17:10:37 <GNUtoo> maybe
Apr 01 17:10:42 <mickeyl> hmm
Apr 01 17:11:10 <GNUtoo> no config
Apr 01 17:11:13 <morphis> ok
Apr 01 17:11:13 <GNUtoo> no fsoaudiod.conf
Apr 01 17:11:17 <morphis> I will create one for you
Apr 01 17:11:22 <morphis> mickeyl: you saw my last commits?
Apr 01 17:11:27 <GNUtoo> only:
Apr 01 17:11:40 <GNUtoo> ./palm_pre/fsoaudiod.conf
Apr 01 17:11:40 <GNUtoo> ./default/fsoaudiod.conf
Apr 01 17:11:43 <morphis> GNUtoo: do you know the path to the scenario files?
Apr 01 17:11:56 <mickeyl> morphis: yes, looks exciting... does it work? :D
Apr 01 17:11:56 <GNUtoo> yes
Apr 01 17:12:26 <GNUtoo> http://www.pastie.org/1744404
Apr 01 17:12:43 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * rc0e7dd3289c0 10/fsoaudiod/ (5 files in 3 dirs): fsoaudiod: add configuration file for the openmoko gta phones
Apr 01 17:12:47 <morphis> mickeyl: I am on the way trying it ...
Apr 01 17:13:05 <mickeyl> ok, crossing fingers
Apr 01 17:13:07 <morphis> GNUtoo: it's the openmoko_gta directory?
Apr 01 17:13:14 * mickeyl fighst against ISI in the meantime
Apr 01 17:13:19 <GNUtoo> yes
Apr 01 17:13:26 <GNUtoo> aka OM-GTA02
Apr 01 17:13:31 <GNUtoo> aka OM-GTA01
Apr 01 17:13:32 <GNUtoo> etc...
Apr 01 17:13:34 <morphis> ok
Apr 01 17:13:38 <GNUtoo> it's the same symilinked
Apr 01 17:13:59 <morphis> take the config files I checked in
Apr 01 17:14:06 <morphis> fsoaudiod.conf and alsa.conf you need
Apr 01 17:14:15 <morphis> put them into the openmoko_gta directory
Apr 01 17:14:18 <GNUtoo> the ones for n900?
Apr 01 17:14:19 <GNUtoo> ok
Apr 01 17:14:55 <morphis> no the openmoko_gta ones
Apr 01 17:15:18 <morphis> is there a alsa-default symlink in the openmoko_gta directory?
Apr 01 17:17:39 <morphis> if not change the entry cardname = default to cardname = 2.6.34 (or your kernel version, look the alsa-* directories in openmoko_gta) in alsa.conf
Apr 01 17:17:52 <morphis> but backup your old alsa.conf before
Apr 01 17:18:06 <morphis> the one before you copied mine on your device
Apr 01 17:18:25 <GNUtoo> ok
Apr 01 17:19:44 <GNUtoo> hmmm
Apr 01 17:19:49 <GNUtoo> the alsa.conf is quite different
Apr 01 17:20:06 <morphis> the new one?
Apr 01 17:20:28 <GNUtoo> a diff from old to new show quite some differences
Apr 01 17:20:37 <GNUtoo> I'll put the new one
Apr 01 17:21:16 <morphis> jepp
Apr 01 17:21:18 <morphis> do that
Apr 01 17:21:21 <morphis> you need the new one
Apr 01 17:21:25 <morphis> the structure has changed
Apr 01 17:21:30 <morphis> but save the old one
Apr 01 17:21:55 <morphis> mickeyl: I am rebooting with new fsogsmd ...
Apr 01 17:22:16 <nschle85> hello, fennec does not run under gta02, (illegal instruction) how do i check the compiler flags ? or what is the best way to find the illegal instruction ?
Apr 01 17:26:01 <lindi-> nschle85: gdb?
Apr 01 17:28:24 <morphis> mickeyl: hmpf "[WARN]  libfsotransport <Serial /dev/ttyACM0@115200 (fd 26)>: could not set dtr bit for serial transport: Bad address"
Apr 01 17:29:21 <mickeyl> hmm
Apr 01 17:29:33 <morphis> it's the output of strerror(...)
Apr 01 17:30:22 <morphis> hm
Apr 01 17:30:48 <morphis> mickeyl: is the O_NOCTTY relevant?
Apr 01 17:31:22 <morphis> it's not ...
Apr 01 17:32:13 <morphis> ah 
Apr 01 17:32:33 <morphis> I did ioctl(fd, ..., bits) but it should be ioctl(fd, ..., &bits)
Apr 01 17:33:00 <mickeyl> ah, heh
Apr 01 17:33:58 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * rd496c3449816 10/libfsotransport/fsotransport/serial.vala: libfsotransport: supply a pointer to ioctl ...
Apr 01 17:34:36 <morphis> mickeyl: btw. the APN for each provide we have in some database right?
Apr 01 17:35:05 <mickeyl> correect
Apr 01 17:35:07 <mickeyl> fsodatad
Apr 01 17:36:08 <morphis> good
Apr 01 17:36:23 <morphis> than SHR should use this and not rely on the use to enter it
Apr 01 17:36:51 <morphis> and someone should correct this in shr-settings
Apr 01 17:37:26 <nschle85> lindi-: how do i debug a application running on GTA02 ?
Apr 01 17:38:08 <morphis> nschle85: gdb <command>
Apr 01 17:38:13 <morphis> then on the prompt: run
Apr 01 17:38:17 <GNUtoo> http://www.pastie.org/1744493
Apr 01 17:38:41 <morphis> GNUtoo: uups I did a mistake in the config
Apr 01 17:38:56 <morphis> please add [fsoaudio.router_alsa] before [fsoaudio.manager]
Apr 01 17:39:58 <nschle85> morphis: so gdb must be installed on gta02 and i must install the dbg version of fennec ?
Apr 01 17:40:18 <morphis> jepp
Apr 01 17:40:18 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * r89da03491292 10/fsoaudiod/conf/ (nokia_n900/fsoaudiod.conf openmoko_gta/fsoaudiod.conf): fsoaudiod: correct machine configuration files to load router alsa plugin
Apr 01 17:40:25 <GNUtoo> nschle85, what's the issue?
Apr 01 17:40:36 <morphis> mickeyl: so it's rebuilding ...
Apr 01 17:40:37 <lindi-> nschle85: just like you do on your PC?
Apr 01 17:40:38 <nschle85> GNUtoo: Illegal Instruction
Apr 01 17:40:54 <nschle85> GNUtoo: no more info
Apr 01 17:41:01 <GNUtoo> JaMa, hi, there is something wrong with the build process, fennec, wesnoth, and another app got illegal instruction
Apr 01 17:41:12 <GNUtoo> that's not normal
Apr 01 17:41:29 <JaMa> maybe another thumb issue?
Apr 01 17:41:30 <nschle85> GNUtoo: running fennec
Apr 01 17:41:40 <GNUtoo> no idea
Apr 01 17:41:51 <GNUtoo> om-gta02 support thumb right?
Apr 01 17:42:19 <GNUtoo> (I don't see why it doesn't support it, but it could be disabled in the kernel)
Apr 01 17:42:32 <GNUtoo> s/doesn't/wouldn't
Apr 01 17:42:46 <JaMa> GNUtoo: yes it supports that and it's intentionally enabled
Apr 01 17:42:56 <GNUtoo> ok
Apr 01 17:43:44 <GNUtoo> morphis, what should I run now that the log looks fine?
Apr 01 17:43:46 <JaMa> the problem is when there is arm instruction while in thumb mode.. but first you have to know which illegal instruction it was and in what mode that happen
Apr 01 17:43:49 <GNUtoo> morphis, could you fix the log
Apr 01 17:43:56 <morphis> I fixed it
Apr 01 17:44:01 <GNUtoo> ok
Apr 01 17:44:04 <morphis> "please add [fsoaudio.router_alsa] before [fsoaudio.manager]"
Apr 01 17:44:04 <GNUtoo> thanks
Apr 01 17:44:21 <GNUtoo> ok 
Apr 01 17:44:24 <GNUtoo> I see it now
Apr 01 17:44:28 <morphis> ok
Apr 01 17:44:36 <nschle85> GNUtoo: ill try to debug fennec, to find the instruction
Apr 01 17:44:40 <morphis> with that the logfile should look better
Apr 01 17:45:15 <GNUtoo> nschle85, ok
Apr 01 17:45:26 <GNUtoo> nschle85, I fear that gdb on target is not a good idea
Apr 01 17:45:36 <GNUtoo> it can OOM the device very easely
Apr 01 17:45:42 <GNUtoo> altough I've a solution
Apr 01 17:45:46 <GNUtoo> gdbserver + gdb
Apr 01 17:45:57 <GNUtoo> http://elinux.org/GDB
Apr 01 17:46:04 <GNUtoo> howto here ^^^
Apr 01 17:46:21 <nschle85> GNUtoo: ok, ill try to setup
Apr 01 17:46:29 <GNUtoo> but maybe without the -dbg packages it consume less memory
Apr 01 17:46:36 <GNUtoo> worth trying without -dbg
Apr 01 17:46:42 <GNUtoo> since you need only assembly
Apr 01 17:46:46 <GNUtoo> so try on target first
Apr 01 17:46:59 <nschle85> GNUtoo: ok, i try on target
Apr 01 17:47:19 <nschle85> GNUtoo: but first i need a compiled gdb package :-)
Apr 01 17:47:28 <GNUtoo> opkg install gdb?
Apr 01 17:47:51 <nschle85> GNUtoo: no, i have my own sandbog
Apr 01 17:47:57 <nschle85> sandbox
Apr 01 17:48:20 <nschle85> GNUtoo: bitbake gdb i think :-)
Apr 01 17:50:56 <GNUtoo> ok
Apr 01 17:51:31 <morphis> mickeyl: kernel log looks good now
Apr 01 17:51:44 <morphis> mickeyl: but ipcp still does not work ...
Apr 01 17:52:11 <morphis> "PPP stack now offline. Disconnect reason is G_AT_PPP_REASON_IPCP_FAIL"
Apr 01 17:53:00 <morphis> hm but the dtr cycle does not work ..
Apr 01 17:57:28 <morphis> mickeyl: hm I am playing a little bit with the timings, maybe that helps
Apr 01 17:59:04 <morphis> mickeyl: it's our tty configuration
Apr 01 18:03:46 <nschle85> GNUtoo: gdb /usr/lib/fennec/fennec
Apr 01 18:03:51 <nschle85> GNUtoo: run
Apr 01 18:03:59 <GNUtoo> yes
Apr 01 18:04:03 <GNUtoo> and then wait for the crash
Apr 01 18:04:05 <GNUtoo> and run
Apr 01 18:04:07 <GNUtoo> disass
Apr 01 18:04:19 <GNUtoo> check if you're on the correct frame tough
Apr 01 18:04:41 <nschle85> Program received signal SIGILL, Illegal instruction.
Apr 01 18:04:41 <nschle85> 0x0000cf8c in ?? ()
Apr 01 18:05:09 <GNUtoo> bt
Apr 01 18:05:11 <morphis> hm
Apr 01 18:05:17 <GNUtoo> do you get some frames?
Apr 01 18:05:24 <GNUtoo> if not install -dbg
Apr 01 18:05:27 <nschle85> GNUtoo: No function contains program counter for selected frame.
Apr 01 18:05:29 <GNUtoo> and use gdbserver
Apr 01 18:05:31 <GNUtoo> ok
Apr 01 18:05:37 <GNUtoo> then install the -dbg
Apr 01 18:06:01 <GNUtoo> I can't forward my internet connection to my openmoko anymore after my trisquel upgrade
Apr 01 18:06:13 <GNUtoo> altough DNS works
Apr 01 18:06:18 <GNUtoo> with 192.168.1.1
Apr 01 18:06:22 <GNUtoo> any ideas?
Apr 01 18:09:20 <morphis> mickeyl: ping
Apr 01 18:12:56 <CIA-66> freesmartphone.org: 03morphis 07cornucopia * r031f50b03777 10/fsogsmd/src/plugins/pdp_ppp_internal/plugin.vala: fsogsmd: pdp_ppp_internal: send modem line reset command when initializing channel
Apr 01 18:13:34 <morphis> mickeyl: run mterm2 /dev/ttyACM0 and look at the kernel log
Apr 01 18:13:46 <morphis> mickeyl: no input control line settings message occur
Apr 01 18:13:55 <morphis> mickeyl: then type ATZ end press enter ...
Apr 01 18:14:19 <morphis> mickeyl: without dtr_cycle ...
Apr 01 18:15:55 <nschle85> GNUtoo: i cannot debug on gta02 the debug symbols are not found 
Apr 01 18:16:14 <GNUtoo> nschle85, then install fennec-dbg
Apr 01 18:16:23 <nschle85> GNUtoo: already done
Apr 01 18:16:27 <Heinervdm> nschle85: set sysroot /
Apr 01 18:16:44 <GNUtoo> ah right
Apr 01 18:16:52 <GNUtoo> too bad I've no internet on om-gta02
Apr 01 18:16:55 <GNUtoo> I'll try wifi
Apr 01 18:17:12 <GNUtoo> but wifi often has PSM
Apr 01 18:17:44 <GNUtoo> ahhh
Apr 01 18:17:49 <GNUtoo> tap0 was the interface
Apr 01 18:18:49 <nschle85> Heinervdm: did not help
Apr 01 18:19:09 <mrmoku> 1056  02:35:29.125823 poll([{fd=6, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=22, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=2
Apr 01 18:19:12 <Heinervdm> nschle85: you can try to make a debug build
Apr 01 18:19:13 <mrmoku> 6, events=POLLIN, revents=POLLIN}, {fd=17, events=POLLIN}], 8, 0) = 1
Apr 01 18:19:15 <mrmoku> 1056  02:35:29.126556 read(26, "a\26\0\0\204\262\1\0\3\0\1\0\t\0\0\0", 16) = 16
Apr 01 18:19:18 <mrmoku> 1056  02:35:29.126922 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Apr 01 18:19:21 <mrmoku> hmm
Apr 01 18:19:30 <Heinervdm> nschle85: for this you have to add DEBUG_BUILD = 1 to your local.conf
Apr 01 18:21:31 <nschle85> Heinervdm: ok and then bitbake clean fennec; bitbake fennec ?
Apr 01 18:21:41 <Heinervdm> nschle85: yes
Apr 01 18:22:09 <nschle85> Heinervdm: ok, this will take several deciminutes :-)
Apr 01 18:22:18 <JaMa> is DEBUG_BUILD still needed after http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=6536f018653333267483aa3d98b1e40b7a060e96 ?
Apr 01 18:22:58 <JaMa> -dbg packages should be usefull already :/
Apr 01 18:23:04 <Heinervdm> JaMa: no idea, as i haven't build oe.dev for a long time
Apr 01 18:23:57 <mrmoku> GNUtoo, mickeyl: it's the kernel_idle plugin that crashes fsodeviced on n900
Apr 01 18:24:14 <GNUtoo> mrmoku, no idea
Apr 01 18:24:20 <GNUtoo> I've commented almost everything
Apr 01 18:24:22 <GNUtoo> and I think
Apr 01 18:24:29 <GNUtoo> that more than one thing makes it crash
Apr 01 18:24:58 <mickeyl> mrmoku: ok, i'd be grateful for a backtrace
Apr 01 18:25:12 <mrmoku> mickeyl: yeah, will work on that
Apr 01 18:25:22 <mrmoku> GNUtoo: it was no question :)
Apr 01 18:25:42 <GNUtoo> ok
Apr 01 18:25:43 <GNUtoo> bbl
Apr 01 18:26:35 <mrmoku> GNUtoo: I can enable all plugins but kernel_idle
Apr 01 18:26:37 <morphis> mickeyl: you saw my messages?
Apr 01 18:27:12 <mickeyl> morphis: yes, but i didn't understand ;)
Apr 01 18:27:19 <morphis> ok
Apr 01 18:27:28 <morphis> I tried to with fsogsmd and dtr_cycle
Apr 01 18:27:42 <morphis> I got no the kernel message with the changed input control settings
Apr 01 18:27:49 <morphis> s/no/not/
Apr 01 18:27:49 <apt> morphis meant: I got not the kernel message with the changed input control settings
Apr 01 18:27:57 <mickeyl> ok
Apr 01 18:28:00 <morphis> then I tried with mterm2
Apr 01 18:28:08 <morphis> simply opening does nothing on the kernel side
Apr 01 18:28:21 <morphis> but sending ATZ as command gives us the line we want ...
Apr 01 18:28:28 <mickeyl> ooh
Apr 01 18:28:43 <mickeyl> we're not sending ATZ in pdp_ppp_internal yet
Apr 01 18:28:54 <mickeyl> i would not have thought that it was necessary
Apr 01 18:28:54 <morphis> I added it with my last commit
Apr 01 18:28:56 <mickeyl> odd
Apr 01 18:29:01 <morphis> we will see
Apr 01 18:29:50 <mrmoku> JaMa: will tell you in some minute... installing fsodeviced-dbg right now :)
Apr 01 18:29:51 <morphis> I tried many stuff like comparing all the tty settings against our settings
Apr 01 18:30:00 <morphis> but nothing works
Apr 01 18:30:13 <morphis> in the end I discovered that I am sending ATZ in my little test-tool
Apr 01 18:30:21 <mrmoku> JaMa: yay, much, much better :-D
Apr 01 18:31:08 <mrmoku> mickeyl: http://pastebin.com/Vgyibn3e
Apr 01 18:32:32 <mrmoku> mickeyl: var bytesread = Posix.read( source.unix_get_fd(), &ev, sizeof(Linux.Input.Event) );
Apr 01 18:32:47 <JaMa> mrmoku: great :)
Apr 01 18:32:52 <mrmoku> is probably the thing... at least that would be in sync with my strace...
Apr 01 18:32:54 <mickeyl> hmm, strange
Apr 01 18:32:59 <mrmoku> that read is the last thing in there
Apr 01 18:33:00 <mickeyl> ok, thanks. i don't understand it atm.
Apr 01 18:33:04 <mickeyl> but will take a look
Apr 01 18:33:29 <mrmoku> yeah, ok
Apr 01 18:35:00 <JaMa> sorry with delay on 2.6.39-rc1 :/ had to stay at work over night and still not regenerated from that 
Apr 01 18:35:33 <mrmoku> JaMa: great thing bts work finally :)
Apr 01 18:35:42 <mrmoku> ~hail whoever fixed that
Apr 01 18:35:43 * apt bows down to whoever fixed that and chants, "I'M NOT WORTHY!!"
Apr 01 18:36:10 <JaMa> mrmoku: GNUtoo forced me to change that :)
Apr 01 18:36:19 <JaMa> ~hail GNUtoo 
Apr 01 18:36:20 * apt bows down to GNUtoo and chants, "I'M NOT WORTHY!!"
Apr 01 18:36:35 <nschle85> JaMa: i am always surprised how you manage your job and shr development :-)
Apr 01 18:37:15 * JaMa managed to be single again.. that's it :/
Apr 01 18:37:41 <mrmoku> ouch... I would have thought you managed to clone yourself instead...
Apr 01 18:42:25 <morphis> mickeyl: "PPP stack now offline. Disconnect reason is G_AT_PPP_REASON_IPCP_FAIL"
Apr 01 18:42:31 <morphis> will try again tomorrow
Apr 01 18:42:46 <morphis> now other things are more important in real live :)
Apr 01 18:42:48 <morphis> byebye
Apr 01 18:42:51 <mickeyl> morphis: ok, *sigh*
Apr 01 18:43:02 <morphis> don't give up! we will get it!
Apr 01 18:43:10 <mickeyl> :))
Apr 01 18:48:09 <mrmoku> mickeyl: another problem with fsogsmd on n900 is release and re-request does not work
Apr 01 18:48:12 <mrmoku> minor problem though
Apr 01 18:49:28 <mickeyl> hmm, yeah
Apr 01 18:49:42 <mrmoku> mickeyl: other than that the few implemented mediators that don't need registration work
Apr 01 18:49:48 <mrmoku> apart from ListProviders
Apr 01 18:49:57 <mrmoku> that does make mdbus2 segfault
Apr 01 18:50:02 <mickeyl> try with cli-framework
Apr 01 18:50:05 <mickeyl> it works there
Apr 01 18:50:10 <mrmoku> ahh, ok
Apr 01 18:50:12 <mickeyl> no idea what's still missing in mdbus2
Apr 01 18:50:15 <mickeyl> i thought we fixed that bug
Apr 01 18:50:23 * mrmoku installs mdbus2-dbg :P
Apr 01 18:50:45 * mickeyl desperate
Apr 01 18:50:59 * mrmoku happy, because debug packages finally work :)
Apr 01 18:54:24 <mrmoku> mickeyl, playya_: http://pastebin.com/pJTnpwn9
Apr 01 18:58:14 <pespin> mickeyl, don't be desperate, probably mdbus2 segfault is because of April Fool's Day! ;)
Apr 01 18:58:38 <mrmoku> unfortunatelly it segfaulted some day ago too ;)
Apr 01 18:59:01 <mickeyl> heh
Apr 01 18:59:07 <mickeyl> i'm not desperate because of mdbus2
Apr 01 18:59:11 <mickeyl> this is peanuts...
Apr 01 18:59:18 <mickeyl> ISI not behaving is killing me
Apr 01 19:04:30 <GNUtoo> what should I look first?
Apr 01 19:04:32 <GNUtoo> kernel or isi?
Apr 01 19:08:55 <GNUtoo> basically my idea was to link against libnl1
Apr 01 19:14:57 <nschle85> GNUtoo: fennec is still compiling... hope i can run the debug version today
Apr 01 19:16:47 <GNUtoo> ok
Apr 01 19:20:02 <mrmoku> GNUtoo: finally the -dbg packages from OE produce good backtraces :-)
Apr 01 19:20:12 <GNUtoo> ok nice
Apr 01 19:20:23 <GNUtoo> so it made it to the feeds
Apr 01 19:20:25 <GNUtoo> nice
Apr 01 19:20:36 <GNUtoo> ?
Apr 01 19:20:48 <mrmoku> to the 'official' SHR feeds?
Apr 01 19:21:03 <GNUtoo> yes
Apr 01 19:21:05 <mrmoku> I would think so... but I tried with the n900-oe tree
Apr 01 19:21:09 <GNUtoo> ok 
Apr 01 19:22:19 <JaMa> mrmoku: most packages weren't rebuilt since then
Apr 01 19:22:28 <mrmoku> ah, ok
Apr 01 19:22:41 <mrmoku> will be fixed by next rebuild from scratch then :P
Apr 01 19:23:08 <JaMa> yup
Apr 01 19:24:17 <nschle85> JaMa: did you talk about that fennec-dbg package does not provide dbg symbols ?
Apr 01 19:26:54 <JaMa> no, vice-versa, it should provide dbg symbols if you build it after http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=6536f018653333267483aa3d98b1e40b7a060e96
Apr 01 19:28:05 <nschle85> JaMa: sorry, i built it for the first time yesterday :-(
Apr 01 19:28:27 <nschle85> JaMa: the patch is from the beginnig of March
Apr 01 19:33:28 <JaMa> nschle85: it wont help with fennect because there is FULL_OPTIMIZATION overwritten in recipe
Apr 01 19:33:56 <JaMa> nschle85: right fix is to add DEBUG_FLAGS to FULL_OPTIMIZATION in fennec_hg.bb
Apr 01 19:35:16 <mickeyl> mrmoku: do you still have the modem power cycle script somewhere?
Apr 01 19:35:45 <mrmoku> mickeyl: the binary you mean?
Apr 01 19:35:53 <mickeyl> yes, if it was a binary
Apr 01 19:36:03 <nschle85> JaMa: ok, i belive you, and will this be done ?
Apr 01 19:36:04 <mrmoku> mickeyl: http://build.shr-project.org/tests/mrmoku/n900/n900-modem-power
Apr 01 19:36:07 <mickeyl> thanks
Apr 01 19:36:10 <mrmoku> yw
Apr 01 19:36:43 <mrmoku> mickeyl: is there anything one could try to support you in your isi fight?
Apr 01 19:38:00 <JaMa> nschle85: I don't care about fennec, so probably not by me (any time soon)
Apr 01 19:38:17 <JaMa> nschle85: but you can test it and send patch to OE ML
Apr 01 19:38:37 <nschle85> JaMa: which browser do you prefer on Freerunner ?
Apr 01 19:39:01 * JaMa is not browsing from fr :/
Apr 01 19:39:19 <JaMa> and when I had to, I've used midori/dillo2/eve
Apr 01 19:39:32 <mrmoku> nschle85: I really, really doubt fennec would rock on the FR
Apr 01 19:39:51 <mrmoku> even on n900 it does not really rock
Apr 01 19:39:52 <mickeyl> mrmoku: hmm... i don't know. it could be interesting to catch a dump of all packages maemo|meego sends from start to successful registration. i'm afraid we have a timing or order issue, but i'm completely clueless where to start debugging that
Apr 01 19:40:02 <mickeyl> all i do is blindly shuffling around commands atm.
Apr 01 19:40:03 <GNUtoo> do we have a libnl1 fsogsmd?
Apr 01 19:40:08 <mickeyl> which is extremely frustrating
Apr 01 19:40:14 <mickeyl> since nothing seems to have an effect
Apr 01 19:40:36 <PaulFertser> nschle85: links2 has graphics mode which is ok too.
Apr 01 19:41:30 <nschle85> i tried midori, but its very unhandy ...
Apr 01 19:42:17 <mrmoku> mickeyl: hmm, ok :/
Apr 01 19:43:08 <mickeyl> i don't even know whether the libnl issue is breaking things or whether my init sequence is still broken
Apr 01 19:43:18 <mickeyl> all i know is that nothing works with this image here
Apr 01 19:43:27 <mickeyl> (modemwise)
Apr 01 19:43:52 <mickeyl> bbl, i need a brek
Apr 01 19:43:54 <mickeyl> break,e ven
Apr 01 19:44:11 <nschle85> PaulFertser: thank you, screen shots looks good.
Apr 01 19:48:49 <nschle85> mrmoku: why does fennec not rock on N900 ?
Apr 01 19:53:07 <nschle85> GNUtoo: shame me.... no debugging symbols found
Apr 01 19:53:18 <GNUtoo> I'll try later
Apr 01 19:53:24 <GNUtoo> I've satrted a build for om-gta02
Apr 01 19:54:24 <DocScrutinizer> yo, what's been the hoax of the day here?
Apr 01 19:54:54 <PaulFertser> DocScrutinizer: RoadRunner
Apr 01 19:54:59 <nschle85> GNUtoo: is DEBUG_BUILD = 1 right or should it be DEBUG_BUILD = "1" ?
Apr 01 19:55:26 <DocScrutinizer> PaulFertser: hehe, FeeRunner successor?
Apr 01 19:55:33 <GNUtoo> DEBUG_BUILD = "1"
Apr 01 19:55:34 <lars_> PaulFertser: do you remember that the 8 second on-key shutdown for the pcf50633 was a issue of different default register settings? and not like the driver claims, that it is only supported by certain versions of the chip
Apr 01 19:55:36 <PaulFertser> DocScrutinizer: meego based :)
Apr 01 19:55:41 <GNUtoo> let me look
Apr 01 19:56:05 <nschle85> GNUtoo: ok ill compile again :-)
Apr 01 19:56:12 <GNUtoo> that's it
Apr 01 19:56:27 <GNUtoo> I will try to link fsogsmd to libnl1
Apr 01 19:56:27 <PaulFertser> lars_: i'll check the datasheet
Apr 01 19:56:45 <JaMa> GNUtoo: 21:29:28 < JaMa> nschle85: right fix is to add DEBUG_FLAGS to FULL_OPTIMIZATION in fennec_hg.bb
Apr 01 19:56:55 * DocScrutinizer YAWNS on meego. Now even Qt folks contribute to making it a BS on 0.1
Apr 01 19:57:45 <DocScrutinizer> the even shove that polling shit down maemo users' throat now, with introduction of QtMobility
Apr 01 19:58:11 <JaMa> lars_: do you have newer repo to push? I had to replace couple of s/set_irq_chip_and_handler/irq_set_chip_and_handler/g and glamo is still using old irq api
Apr 01 19:58:31 <DocScrutinizer> PaulFertser: you noticed what I spotted yesterday?
Apr 01 19:58:44 <DocScrutinizer> the polling of prox sensor...
Apr 01 19:58:44 <PaulFertser> DocScrutinizer: Qt polling g-meters?
Apr 01 19:58:46 <lars_> JaMa: but thats 2.6.39 stuff
Apr 01 19:59:02 <DocScrutinizer> PaulFertser: worse, the proximity sensor, at 100Hz
Apr 01 19:59:05 <PaulFertser> Oh my
Apr 01 19:59:17 <DocScrutinizer> while that lil switch can operate no fatser than 2.5Hz
Apr 01 19:59:31 <JaMa> lars_: yup, I'm trying to backport your patches from linux-next on top of linux-2.6.git
Apr 01 19:59:36 <DocScrutinizer> and of course has a proper GPIO line to trigger IRQ
Apr 01 19:59:41 <GNUtoo> JaMa, is libnl1 static only like it was said on the oe ml?
Apr 01 19:59:53 <JaMa> ?
Apr 01 20:00:14 <JaMa> did you read that patch?
Apr 01 20:00:16 <GNUtoo> yes
Apr 01 20:00:24 <GNUtoo> it just set some flags
Apr 01 20:00:42 <nschle85> GNUtoo: can you make the change in fennec_hg.bb JaMa supposed ? 
Apr 01 20:00:56 <GNUtoo> +       $(LIBNL_LIBS) \
Apr 01 20:01:01 <DocScrutinizer> PaulFertser: http://qt.gitorious.org/qt-mobility/qt-mobility/blobs/master/plugins/sensors/n900/n900proximitysensor.cpp#line54
Apr 01 20:01:02 <GNUtoo> +       $(LIBNL_CFLAGS) \
Apr 01 20:01:03 <lars_> JaMa: why do you want to build a .39-rc1 kernel for the freerunner?
Apr 01 20:01:05 <JaMa> GNUtoo: http://git.openembedded.org/cgit.cgi/openembedded/diff/recipes/libnl/libnl1-1.1/build.only.static.lib.patch?id=f9e42413323c6f402e1e6efd2067373e4bf54a59
Apr 01 20:01:16 <GNUtoo> ahh that patch
Apr 01 20:01:23 <GNUtoo> I was looking at the network manager one
Apr 01 20:01:35 <GNUtoo> nschle85, is it urgent?
Apr 01 20:01:43 <GNUtoo> because I would rather want to work on n900 modem
Apr 01 20:01:51 <GNUtoo> if I deblock mickeyl we could advance
Apr 01 20:02:00 <nschle85> GNUtoo: i think its necesary to find the illegal instruction
Apr 01 20:02:24 <GNUtoo> ok but wouldn't fennec be too slow at the end?
Apr 01 20:02:38 <JaMa> lars_: just because I'm using git version for spitz and for OE I can easier add patch with diff from your branches then new recipe using whole new git repo (linux-next)
Apr 01 20:02:39 <GNUtoo> nschle85, not to mention that I couldn't test
Apr 01 20:02:40 <nschle85> or please tell me what to add there, because  I do not understand bb files.
Apr 01 20:02:56 <GNUtoo> nschle85, if you wanit for om-gta02 to build locally for me I could look
Apr 01 20:03:11 <GNUtoo> note that I can build the night
Apr 01 20:04:06 <nschle85> GNUtoo: its not urgent for me but i thought i can help, but i cannot create any dbg version of fennec
Apr 01 20:04:10 <lars_> JaMa: but why .39-rc1 and not .38?
Apr 01 20:04:25 <GNUtoo> nschle85, ok I can try, what does gdb says?
Apr 01 20:04:26 <JaMa> lars_: I have .38 already and it doesn't boot for me
Apr 01 20:04:36 <GNUtoo> did it warn about libraries or smoething like that?
Apr 01 20:04:47 <JaMa> lars_: so wanted to give .39-rc a try before debuging why .38 wont boot
Apr 01 20:04:53 <lars_> i see
Apr 01 20:05:48 <nschle85> GNUtoo: Reading symbols from /usr/lib/fennec/fennec...(no debugging symbols found)...done.
Apr 01 20:05:48 <nschle85> (gdb)
Apr 01 20:06:01 <lars_> JaMa: try .38 with 05a035eb613bd9af73c7786e9cb8ef8e7883e7ff
Apr 01 20:07:33 <GNUtoo> nschle85, could you pastebin the full log
Apr 01 20:08:24 <nschle85> GNUtoo: full log of what ?
Apr 01 20:08:42 <GNUtoo> the gdb session
Apr 01 20:08:53 <GNUtoo> because fennec is one thing
Apr 01 20:09:02 <GNUtoo> but there are tons of libraries fennec depends upon
Apr 01 20:09:11 <nschle85> GNUtoo: ok
Apr 01 20:09:40 <PaulFertser> lars_: if i understand it correctly, OM were ordering pcf50633 variant 09 and that has onkey_mode=0 which means holding the key can't turn the device off.
Apr 01 20:10:20 <DocScrutinizer> while mentioning it: What's OM using for lis302 driver? We got a proper IRQ driven kernel driver, with configurable highpass and IRQ thresholds? And a sysnode and associated kevent to hook in?
Apr 01 20:10:59 <lars_> PaulFertser: but we can change that, right?
Apr 01 20:11:09 <PaulFertser> lars_: it looks like indeed we can.
Apr 01 20:11:21 <DocScrutinizer> umm, I *could* dig that up (pcf50633 variant)
Apr 01 20:11:35 <PaulFertser> lars_: hm, sorry
Apr 01 20:11:36 <DocScrutinizer> thought it should already be on wiki
Apr 01 20:11:41 <PaulFertser> lars_: datasheet says it's R
Apr 01 20:11:53 <PaulFertser> DocScrutinizer: was there only one?
Apr 01 20:11:56 <lars_> mine says it's RW
Apr 01 20:12:02 <DocScrutinizer> afaik yes
Apr 01 20:12:19 <PaulFertser> Rev. 06 -- 05 March 2008
Apr 01 20:12:31 <PaulFertser> OOCMODE 7:6 onkey_mode
Apr 01 20:12:38 <DocScrutinizer> it's for sure r/w, otherwise makes no sense
Apr 01 20:12:38 <JaMa> lars_: ok, building with updated defconfig, 05a035eb613bd9af73c7786e9cb8ef8e7883e7ff was already included in oe patch
Apr 01 20:13:02 <nschle85> GNUtoo: http://pastebin.com/Ej7sVaDm
Apr 01 20:14:02 <lars_> I have Rev. 08, but the date says april 2005
Apr 01 20:14:32 <DocScrutinizer> lol
Apr 01 20:15:23 <lars_> but maybe it is a different document
Apr 01 20:15:36 <DocScrutinizer> that's what I was about to suggest
Apr 01 20:15:43 <DocScrutinizer> compare doc #
Apr 01 20:16:17 <PaulFertser> PCF50633UM_6
Apr 01 20:16:28 <DocScrutinizer> for chips that complex there's always datasheet, app notes, user manual, whatnot else
Apr 01 20:16:38 <PaulFertser> User Manual here :)
Apr 01 20:17:06 <DocScrutinizer> lemme fire locate on my PC here
Apr 01 20:17:29 <GNUtoo> nschle85, the CRC mismatch means the .debug version doesn't match the normal lib
Apr 01 20:17:38 <GNUtoo> so reinstall one of both
Apr 01 20:17:44 <GNUtoo> opkg update before 
Apr 01 20:17:47 <GNUtoo> opkg upgrade
Apr 01 20:17:56 <GNUtoo> may solve it
Apr 01 20:17:57 <GNUtoo> or not
Apr 01 20:19:18 <nschle85> GNUtoo: did not solve
Apr 01 20:19:25 <DocScrutinizer> URGH
Apr 01 20:19:59 <DocScrutinizer> jr@halley:~> locate 50633|wc -l
Apr 01 20:20:01 <DocScrutinizer> 84
Apr 01 20:20:05 <GNUtoo> mickeyl, where is libnl autoconf stuff in fsogsmd?
Apr 01 20:20:27 <GNUtoo> nschle85, at least the crc are gone?
Apr 01 20:21:48 <DocScrutinizer>  /windows/D/OM/OpenMoko/varaha_docs/docs/by_component/pcf50633/PCF50633HN-04-N3rev0.6NXP.pdf    /windows/D/OM/OpenMoko/varaha_docs/docs/by_component/pcf50633/PCF50633HN-N1-Battery-Portable-Power-Management-HVQFN68-0V8-Spec.pdf   /windows/D/OM/OpenMoko/varaha_docs/docs/by_component/pcf50633/PCF50633_N3B HTOL issue 20070615.pdf 
Apr 01 20:22:16 <DocScrutinizer> a selection of the most intriguing ones
Apr 01 20:22:24 <lars_> hm, i think i'll just remove the emulation code. force_shutdown was never set to anything anyway
Apr 01 20:23:11 <PaulFertser> lars_: on my device holding the button for 8 seconds worked to shut it down. 
Apr 01 20:23:58 <PaulFertser> DocScrutinizer: (lis302 driver) not sure about the current state, i remember we used to have a nice driver.
Apr 01 20:24:22 <DocScrutinizer> :-)
Apr 01 20:26:08 <DocScrutinizer> (50633) I also got several "bookmarks" like /home/jr/.kde/share/apps/kpdf/663672.PCF50633HN-N1-Battery-Portable-Power-Management-HVQFN68-0V8-Spec.pdf.xml
Apr 01 20:27:30 <lars_> PaulFertser: i only get "ONKEY1S held for X seconds"
Apr 01 20:29:21 <lars_> PaulFertser: what rev was your freerunner?
Apr 01 20:29:40 <PaulFertser> lars_: is. revision 6
Apr 01 20:30:04 <lars_> same here
Apr 01 20:30:22 <JaMa> lars_: it worked (poweroff after 8s) for me only after https://gitorious.org/shr/linux/commit/0472afa4465842d6f767d9499a2a2469c645b38b
Apr 01 20:31:30 <DocScrutinizer> got pcf50633-variants.txt here, 654B. You need that?
Apr 01 20:32:01 <lars_> DocScrutinizer: i have a backup of the openmoko docs folder as well
Apr 01 20:32:09 <DocScrutinizer> aah ok
Apr 01 20:32:29 <PaulFertser> lars_: 0x10 register is 0x15 for me.
Apr 01 20:32:53 <PaulFertser> So onkey_mode is 0
Apr 01 20:33:24 <PaulFertser> I think i actually saw it turning off but i can try now if you want (still running andy-tracking here)
Apr 01 20:34:12 <lars_> just had a look at mach-gta02.c and there is a force_shutdown
Apr 01 20:34:54 <lars_> in andy-tracking
Apr 01 20:36:12 <PaulFertser> Yes, there is :)
Apr 01 20:37:20 <GNUtoo> mickeyl, ping?
Apr 01 20:37:24 <GNUtoo> sigh
Apr 01 20:38:10 <lars_> but anyway that emulation code has to go. it messes with the rtc irq, which could cause undefinded behaviour
Apr 01 20:38:29 <lars_> and imo the 8s shutdown is policy
Apr 01 20:39:00 <lars_> and doesn't really belong into the kernel. and if at all it should be in the input driver and not the core irq handler
Apr 01 20:39:59 <PaulFertser> I guess it was supposed that it should work no matter what else had already failed.
Apr 01 20:42:24 <lars_> ok, i'll move it to the input driver
Apr 01 20:42:58 <lars_> i want to use the irq handler for the pcf50633 and the pcf50606 so there can't be any hardcoded irq numbers in there
Apr 01 20:44:23 <PaulFertser> To me personally that code has no real value, i took out the back cover so many times and it's still working fine, i see no reason to not unplug the battery when i want to turn it off. 
Apr 01 20:44:45 <DocScrutinizer> you're aware of PCF50633_N3B HTOL issue 20070615.pdf ?
Apr 01 20:45:13 <lars_> no
Apr 01 20:47:13 <DocScrutinizer> the 8s shutdown is supposed to work *always*, the kernel driver is just to _delay_ it by resetting timer, so kernel has time to clean up - if the kernel still is working
Apr 01 20:47:21 <DocScrutinizer> IIRC
Apr 01 20:47:42 <lars_> that doesn't make sense
Apr 01 20:47:44 <PaulFertser> DocScrutinizer: the variant seems wrong so pcf50633 is not properly configured.
Apr 01 20:48:07 <PaulFertser> DocScrutinizer: and probably it can't be configured, at least according to the version i have.
Apr 01 20:48:22 <DocScrutinizer> yes, it can be configured afaik
Apr 01 20:48:38 <DocScrutinizer> and iirc we got a variant that's default enabled
Apr 01 20:48:42 <lars_> even with the delay the kernel is shutdown abruptly
Apr 01 20:49:05 <DocScrutinizer> lars_: that's the kernel's problem then
Apr 01 20:49:20 <lars_> DocScrutinizer: is 20070615.pdf a report or something?
Apr 01 20:50:09 <JaMa> lars_: 2.6.38 fails for me somewhere in glamo_irq_demux_handler :/ 
Apr 01 20:50:17 <DocScrutinizer> the pcf50633 tells kernel "I got a power press, in 8s I'll shut down (if user keeps holding button, and *if you're not resetting my 8s timer*)"
Apr 01 20:50:40 <DocScrutinizer> lars_: yep, about charge current degradation
Apr 01 20:51:56 <DocScrutinizer> (pcf50633) the kernel then should do two things: 1) shutdown system immediately (umount, flush, etc)  2) reset 8s timer until the shutdown completed
Apr 01 20:53:08 <DocScrutinizer> if the kernel is so busy it can't service this request from pcf50633 for >8s then it's the supposed operation mode the system gets shut down hard
Apr 01 20:53:57 <DocScrutinizer> this function shouldn't get kicked out of kernel
Apr 01 20:54:24 <DocScrutinizer> neither should it get disabled in pcf50633 register settings
Apr 01 20:54:28 <lars_> DocScrutinizer: the pcf50633 does not do that
Apr 01 20:54:30 <PaulFertser> And yet it is.
Apr 01 20:54:39 <lars_> (tell the kernel, i'll shutdown)
Apr 01 20:55:06 <DocScrutinizer> it doesn't ??
Apr 01 20:55:21 <lars_> not if onkey_mode is 0
Apr 01 20:55:28 <DocScrutinizer> I thought it triggers an IRQ line and you read out what'S the IRQ source then
Apr 01 20:56:34 <PaulFertser> DocScrutinizer: it very much looks like the pcf variant we got has that "turn off after 8 sec" feature disabled.
Apr 01 20:56:45 <DocScrutinizer> o.O
Apr 01 20:57:25 <DocScrutinizer> thne we should enable it on bootup
Apr 01 20:57:46 <PaulFertser> DocScrutinizer: the datasheet i have says it's R/O.
Apr 01 20:58:13 <DocScrutinizer> I doubt that's correct. But meh, I looked at those ds maybe 2 years ago
Apr 01 20:58:57 <DocScrutinizer> it doesn't make any sense to have such a hardcoded bit that's only readout
Apr 01 21:00:31 <lars_> well, it's easy enough to find out
Apr 01 21:01:44 <PaulFertser> DocScrutinizer: pmu 10=55 does nothing here
Apr 01 21:02:35 <DocScrutinizer> sorry, no operational system here to help and reproduce
Apr 01 21:28:09 <mickeyl> GNUtoo: fsogsmd does not link directly to libnl. libgisi links to it and iirc libfosbasics
Apr 01 21:28:21 <GNUtoo> ok
Apr 01 21:28:24 <GNUtoo> thanks a lot
Apr 01 21:28:41 <mickeyl> np. good luck
Apr 01 21:28:43 <GNUtoo> do you still have aurora images with libnl1 and a working fsogsmd?
Apr 01 21:29:00 <mickeyl> unfortunately not 
Apr 01 21:29:07 <mickeyl> i didn't save them
Apr 01 21:29:10 <GNUtoo> do you know how to recreate it?
Apr 01 21:29:17 <GNUtoo> srcrev of oe
Apr 01 21:29:20 <GNUtoo> distro
Apr 01 21:29:22 <GNUtoo> local config
Apr 01 21:29:24 <GNUtoo> etc...
Apr 01 21:29:32 <GNUtoo> s/local config/local.conf/
Apr 01 21:29:44 <mickeyl> all configs are on amethyst in my oe dir
Apr 01 21:29:49 <mickeyl> the only unknown is SRCDIR
Apr 01 21:29:54 <mickeyl> oe rev, i mean
Apr 01 21:29:58 <GNUtoo> ok
Apr 01 21:30:01 <mickeyl> but that we can get by inspecting older irc logs i guess
Apr 01 21:30:07 <GNUtoo> so you don't even have the image on microsd?
Apr 01 21:30:16 <GNUtoo> because you have some files telling that
Apr 01 21:30:34 <GNUtoo> for instance for SHR:
Apr 01 21:30:47 <GNUtoo> cat /etc/shr-version gives 3 lines and one of them is
Apr 01 21:30:48 <GNUtoo> Revision: 58b8da5
Apr 01 21:31:35 <mickeyl> hmm, wait
Apr 01 21:31:47 <mickeyl> ok, we're lucky
Apr 01 21:31:51 <mickeyl> got an image here
Apr 01 21:31:51 <GNUtoo> wow
Apr 01 21:31:58 <mickeyl> it's from 02-28
Apr 01 21:32:02 <GNUtoo> keep it safe
Apr 01 21:32:11 <GNUtoo> cat /etc/*-version?
Apr 01 21:32:55 <mickeyl> mickey@saphir:/tmp/foo/etc$ cat version 
Apr 01 21:32:55 <mickeyl> 201102281737
Apr 01 21:33:03 <GNUtoo> ok thanks
Apr 01 21:33:06 <ftn> Hey there. I'm translating a python application for the olpc with gettext. Can you tell me where should I put the translations and if the translated files should be anmed in any specific way?, please.
Apr 01 21:38:31 <mrmoku> mickeyl: hmm... there is a commit in ofono from 24th
Apr 01 21:38:32 <mrmoku> isimodem: fix network registration for older modems
Apr 01 21:38:51 <mrmoku> dunno if the one in n900 is accounting as old modem though
Apr 01 21:46:52 <GNUtoo> mrmoku, maybe you could try it
Apr 01 21:46:57 <GNUtoo> I've to build aurora
Apr 01 21:47:13 <mrmoku> GNUtoo: try ofono?
Apr 01 21:47:18 <mickeyl> mrmoku: this refers to the cdma version
Apr 01 21:47:29 <mrmoku> ah, ok
Apr 01 21:47:38 <mickeyl> and... registration worked fine with libnl1
Apr 01 21:47:44 <GNUtoo> try to import the commit
Apr 01 21:47:52 <mickeyl> after my last commit it was even reliable
Apr 01 21:48:13 <GNUtoo> then we link to static libnl1
Apr 01 21:48:16 <GNUtoo> and we're good?
Apr 01 21:48:25 <mickeyl> i have no idea
Apr 01 21:48:29 <mickeyl> this image is kind of strange
Apr 01 21:48:34 <mickeyl> as stuff links both to libnl1 and libnl2
Apr 01 21:48:41 <mickeyl> no idea why magically this seemed to work back then
Apr 01 21:49:20 <mickeyl> and what's even more confusing... back then it did work with forwarding as well
Apr 01 21:49:33 <mickeyl> and i sure as hell have no libnl1 here on my system
Apr 01 21:50:45 <mickeyl> hmm
Apr 01 21:51:03 <mickeyl> libgisi doesn't link libnl1 at all
Apr 01 21:51:06 <mickeyl> huh
Apr 01 21:54:55 <mickeyl> i'd even try ofono to take a look
Apr 01 21:55:07 <mickeyl> but i have no idea how to configure this now that they're using udev rules
Apr 01 21:55:38 <mrmoku> mickeyl: IIRC the rules just set some environment variables
Apr 01 21:56:53 <mrmoku> hmm... no... nvm
Apr 01 21:57:34 <GNUtoo> where is aurora.conf?
Apr 01 21:58:51 <mickeyl> conf/distro/
Apr 01 21:59:02 <mickeyl> (amethyst/~mickey/oe)
Apr 01 22:00:13 <GNUtoo> I've no such thing in oe.dev
Apr 01 22:00:45 <GNUtoo> and I don't find it either in http://amethyst.openembedded.net/~mickey/oe/
Apr 01 22:00:53 <GNUtoo> http://amethyst.openembedded.net/~mickey/oe/ seem to use aurora as distro
Apr 01 22:01:17 <mickeyl> http://amethyst.openembedded.net/~mickey/oe/openembedded/conf/distro/aurora.conf
Apr 01 22:01:38 <GNUtoo> ah ok
Apr 01 22:01:40 <GNUtoo> thanks
Apr 01 22:45:08 <mickeyl> ok, i don't know what's wrong with kernel or the image, but ofono (via forwarding) fails as well here
Apr 01 22:45:19 <mickeyl> and with that g'night
**** ENDING LOGGING AT Sat Apr 02 02:59:58 2011