**** BEGIN LOGGING AT Thu Dec 03 04:00:14 2009 Dec 03 04:01:53 you mean like ... DBus? Dec 03 05:27:34 martin_office: is 8040 still an issue after the latest round of changes? Dec 03 05:27:47 martin_office: To my knowledge 5530, F3507 and F3607 all work fine Dec 03 05:30:26 denkenz, I will have a try. but if you do not do any change on it, I am afraid that my card still can not work. Dec 03 05:30:51 holtmann: Didn't you have your 5530 working yesterday or is that a different one? Dec 03 05:31:05 martin_office: Then send me a log of the issue, I don't have this card Dec 03 05:31:33 ok, Dec 03 09:06:51 denkenz, I have tried on 0.12. 8040 issue still can be reproduced. I have to add the patch to fix it. Dec 03 11:00:43 denkenz: I wish, that's why I ask. there's a significant amount of code in java talking to a samll daemon in c which further delagates to a library in c Dec 03 16:19:35 martin_office: which patch, and where's my log? :) Dec 03 16:21:33 I guess the dun and hfp stuff will be handled the same way Dec 03 16:21:44 server plugins for different client protocols? Dec 03 16:21:52 including dbus service itself Dec 03 16:32:06 seriously, why would we invent another binary protocol when we have dbus? Dec 03 16:42:26 we didn't invent it Dec 03 16:42:33 it already exxists Dec 03 16:42:42 I just need to emulate it Dec 03 16:42:52 So just find some java-dbus bindings Dec 03 16:42:55 I'm sure some exist Dec 03 16:43:02 Or better yet, dump android ;) Dec 03 16:43:34 and I don't get your question about dun and hfp Dec 03 16:44:11 just that we already have to emulate a client protocol (AT and the AT like hfp) for those Dec 03 16:44:20 so there must be infrastructure for that Dec 03 16:45:15 Well, modem emulation does not yet exist, so no Dec 03 16:45:18 yeah, android is not for me, but I'd rather support one user phone stack than three, including a throwaway broken one Dec 03 16:45:30 There's some basic support for HFP in BlueZ, but it doesn't work that well Dec 03 16:45:52 At least for oFono anyway Dec 03 16:47:49 And I don't see how modem emulation helps you any Dec 03 16:48:35 it doesn't Dec 03 16:49:05 but I don't want to add this stuff in a way that's incompatible with upstream ofono Dec 03 16:49:24 the goal is not replace dbus but complement it only if the module is loaded Dec 03 16:49:54 the protocol is just structs for things like CLIP data Dec 03 16:50:04 I didn't design it Dec 03 16:56:47 Ok, are you talking about Java UI communicating with oFono Dec 03 16:57:03 or are you talking about oFono driver communicating with the modem via some weird protocol? Dec 03 17:41:24 denkenz: Is someone working on HFP now? I already get the zhenhua patches and moved all the code from ofono-hfp.c to gateway.c, now I need to adapt it to the new API. Dec 03 17:41:49 padovan: zhenhua is still working mpty support for HFP in oFono Dec 03 17:41:56 padovan: So no one is working BlueZ side Dec 03 17:42:11 padovan: We assumed you would be Dec 03 17:43:24 denkenz: yes, I will. Dec 03 18:58:57 padovan: Cool, how close are we to having something to test? Dec 03 19:02:59 denkenz: It's working, but I just got the zhenhua patches and moved his code to gateway.c. I going to create the org.bluez.HFGW.RegisterAgent/UnregisterAgent stuff now. Dec 03 19:04:35 Ok cool Dec 03 19:04:54 holtmann: We'll probably have to depend on dbus 1.3 soon I guess Dec 03 20:41:08 denkenz: java ui to a rild, I want to replace rild with ofonod but use the same binary protocol to talk with the java side Dec 03 20:41:21 modem is AT thankfully Dec 03 20:41:37 ril - radio interface layer Dec 03 20:42:25 heh, good luck with that. Dec 03 20:43:01 yeah Dec 03 20:43:09 if we can avoid it we will Dec 03 20:43:19 but I don't really use android myself anyway Dec 03 20:44:14 tmzt: i'm still more interested in seeing Mer run on Dream than anything involving Android/Replicant, personally Dec 03 20:44:46 yes Dec 03 20:44:57 but most of the work will be done in that case Dec 03 20:45:38 to complete the cross polination I'm looking at something new from fso on the ui side Dec 03 20:46:00 but if it's vala and that causes an issue I'm unlikely to go with it Dec 03 20:46:19 someone should just sit down and start writing a Qt UI for oFono Dec 03 20:46:31 Bet you'll have more than FSO in like a week Dec 03 20:46:43 the thing is it has a tiny state based dbus interface to a second daemon that is very similar to ofono's property setup Dec 03 20:47:05 that daemon then talks over fbus to the gsm parts with their low level protocol Dec 03 20:47:10 dbus Dec 03 20:47:22 hah, it's possible Dec 03 20:47:42 bbut it needs to handle all of the state transitions needed in a mobile phone Dec 03 20:47:58 since ofono api is ui centric that might not be hard Dec 03 20:48:16 and ther is a new qt project for limited mer devices Dec 03 20:48:22 called qtablet/liquid Dec 03 20:48:27 Most are taken care of, I'm thinking of a few extras that could make the job of call state transitions trivial for the UI Dec 03 20:48:56 well, look at fsophoneuid we are trying to work out the architecture Dec 03 20:49:05 Still, its not like FSO handles any advanced use cases anyway :) Dec 03 20:49:06 I talked it over with tasn yesterday Dec 03 20:49:27 it should be able to support any new screen we need Dec 03 20:50:44 Qt can already do some screen scaling Dec 03 20:50:51 Particularly if you use a GL backend Dec 03 20:50:53 I don't know qt Dec 03 20:50:57 not scaling Dec 03 20:51:12 and we don't have gl the gl ones are using clutter Dec 03 20:51:33 ah, I mean screen in the sense of full screen dialog Dec 03 20:51:44 or call progress screen or whatever Dec 03 20:51:49 My point is, Qt Animation + Qt Widgets + awesome Qt DBus bindings -> UI written very quickly Dec 03 20:52:12 right, ok Dec 03 21:00:06 what's awesome about Qt D-Bus bindings? Dec 03 21:00:40 They're simply the best ones I've used. There's much I hate about them, but not so much like I hate glib ones Dec 03 21:01:27 there's a nother issue I have to wonder about Dec 03 21:01:44 how is audio routing going to be handled? should we be using pulse Dec 03 21:02:06 what I don't want to do is embed it in the driver itself Dec 03 21:02:12 Audio depends very much on the architecture Dec 03 21:02:18 as the current hacked up android ril does Dec 03 21:03:01 right Dec 03 21:03:08 In general oFono core won't care about audio, it is up to Pulse/AudioManager/whatever to figure out Dec 03 21:03:16 but there's some common attributes of most mobile phones Dec 03 21:03:50 which is that something has to be done to switch between pcm from the application processor and pcm to/from the modem Dec 03 21:04:13 usually no transport is required on the application processor in that mode Dec 03 21:04:14 again, the logic has to be in the UI or Pulse/AudioManager Dec 03 21:04:17 it just works Dec 03 21:04:22 in the ui? Dec 03 21:04:35 UI has to say, turn on speaker or turn on bluetooth Dec 03 21:04:39 for e911 it has to be possible to call without X Dec 03 21:04:54 there's really no way around that Dec 03 21:04:57 So in that respect it has to be in the UI Dec 03 21:05:06 Pulse/AudioManager can set defaults of course Dec 03 21:05:07 no ui without X Dec 03 21:05:11 right Dec 03 21:05:16 How do you dial without X? ;) Dec 03 21:05:17 audiomanager? Dec 03 21:05:22 ask fr people Dec 03 21:05:28 they hold down a key Dec 03 21:05:58 http://moblin.org/projects/audio-manager Dec 03 21:06:08 okay, I'll loom Dec 03 21:06:10 look Dec 03 21:06:46 some people also want one click answer for incoming calls Dec 03 21:06:53 even if ui notifier is failed Dec 03 21:07:36 oFono can support that too Dec 03 21:07:48 Point is, someone needs to write the first UI, then we'll be swimming in them Dec 03 21:08:44 I see Dec 03 21:08:46 e Dec 03 21:10:45 tmzt: when Nokia's ISI/phoned backend for ofono moves on a bit, it'd be much easier to continue our telepathy <-> ofono work and then the Nokia N900 could use ofono as a backend :) Dec 03 21:10:49 *phonet Dec 03 21:11:55 yes, phonet backend is suffering from some bit rot now I bet Dec 03 21:13:34 isn't courmisch working on it? Dec 03 21:13:40 git log shows otherwise Dec 03 21:13:59 Robot101: see discussions between wjt and i :) Dec 03 21:14:26 dilinger: when/where? Dec 03 21:16:10 ? Dec 03 21:16:29 courmisch: Phonet/ISI support. Mainly GPRS etc. Dec 03 21:17:04 I have some kernel side work atm Dec 03 21:18:24 I would be nice to see that part working with Phonet. Properly most useful for the desktop people that wanna use Nokia phones for dialup. Just to let you know. Dec 03 21:18:36 hey robot Dec 03 21:18:56 I just want call initiation through tp Dec 03 21:18:58 progress can be standalone Dec 03 21:19:21 a muc mapping for multiline would be cool but not easy Dec 03 21:19:28 afaik, call already works with ISI Dec 03 21:19:29 the channel api is awesome though Dec 03 21:19:42 except the audio path is not managed by ofono Dec 03 21:21:18 Are there descriptions of what needs to be done for the audio to work somewhere? Dec 03 21:21:32 And is audio management same for all ISI devices or not? Dec 03 21:21:47 oh no Dec 03 21:21:55 only N900 supports audio routing Dec 03 21:22:02 tmzt: there's API work ongoing for that; http://bugs.freedesktop.org/show_bug.cgi?id=24936 for Call, http://bugs.freedesktop.org/show_bug.cgi?id=24906 for Conference Dec 03 21:22:16 tmzt: we're drafting... what dilinger said :D Dec 03 21:22:54 and in fact, audio is not ISI Dec 03 21:23:03 it's a separate channel on the SSI port Dec 03 21:25:14 courmisch: And that should be an ALSA driver, but not sure if that work got every finished or if it is still a char device pipe. Dec 03 21:27:44 yeah there was a talk at plumbers conf about the pulseaudio work, some "interesting" plugins to pull the audio out Dec 03 21:27:54 I think kai has some clue about ALSA and he was adamant that it's not currently possible Dec 03 21:28:14 we've got a few guys working on cleaning up and upstreaming the pulseaudio stuff atm Dec 03 21:28:28 but I think there were problems with ALSA about the latency which meant it had to be side-stepped somehow Dec 03 21:28:40 I don't quite remember Dec 03 21:28:57 but yeah, kai hacks on jackd and stuff so he knows his audio :) Dec 03 22:00:57 cool Dec 03 22:01:07 we have some similar issues on msm Dec 03 22:01:12 alsa doesn't map well Dec 03 22:02:01 hi Dec 03 22:04:33 someone asked us to come Dec 03 22:04:38 here we are Dec 03 22:04:41 hi at all Dec 03 22:04:42 :) Dec 03 22:05:04 courmisch: know anything more about the alsa issue? Dec 03 22:05:12 yes Dec 03 22:05:27 its the well know buffer free problem Dec 03 22:05:46 means that it doesnt check the correct free memory Dec 03 22:05:52 I don't much Dec 03 22:05:59 my local expert just says ALSA can't do it Dec 03 22:06:02 respectivly doesnt recognize the correct buffer Dec 03 22:06:21 courmisch: local expert? Dec 03 22:06:34 courmisch: ALSA can't do it?? Dec 03 22:06:37 why? Dec 03 22:06:45 mmm Dec 03 22:06:56 there are no problems, there are only solutions Dec 03 22:07:00 yes indeed it doesn't check the free memory Dec 03 22:07:08 GNUtoo: jup Dec 03 22:07:09 basically here's what it does: Dec 03 22:07:35 mplayer calls this syscall: Dec 03 22:08:16 s/syscall/ioctl: Dec 03 22:08:52 if you write directly from /dev/urandom into /dev/dsp Dec 03 22:09:04 it creates a Oop and a reboot Dec 03 22:09:48 SNDRV_PCM_IOCTL_STATUS Dec 03 22:09:53 then I have: Dec 03 22:10:14 runtime->buffer_size:2400 | status->avail:0 Dec 03 22:10:34 and the dmesg is full of that debug message I put in Dec 03 22:10:36 so... Dec 03 22:10:39 I did that: Dec 03 22:13:44 snd_pcm_period_elapsed(prtd->playback_substream); Dec 03 22:13:52 s/did/moved Dec 03 22:15:29 to a better place Dec 03 22:15:37 courmisch, do you have more details btw Dec 03 22:16:02 what could we do ? Dec 03 22:16:28 basically I'm able to make it play for a fraction of second Dec 03 22:16:41 but then comes this problem of the status Dec 03 22:17:43 courmisch, does your local expert follow the alsa-devel mailing list? Dec 03 22:21:56 GNUtoo: in economy: not possible means, I don't feel like I dont want invest this much time to implement a good driver Dec 03 22:22:01 :) Dec 03 22:22:41 It means something like: we prefer to just modify the userpace and kernel space until we have something windows-ce like... Dec 03 22:23:15 tmzt, courmisch is silent...is he checking? Dec 03 22:23:22 dunno Dec 03 22:24:12 hmm are there some detailed datasheets for sound-chip and graphics-chip? Dec 03 22:29:12 mmm Dec 03 22:37:46 the qdsp driver does: Dec 03 22:38:13 return buf - start Dec 03 22:38:41 if he's still there he should be able to read Dec 03 22:38:59 you want to talk to kai I think but I don't know where he is Dec 03 22:39:52 mmm Dec 03 22:40:19 first I'd like to know how much they know about the msm alsa driver Dec 03 22:40:30 so I know how much I would have to explain Dec 03 22:40:35 nothing, the question is whether the issues are the same Dec 03 22:40:55 ah they faced the sames issues? Dec 03 22:41:15 not sure Dec 03 22:41:24 kai said alsa won't work on n900 Dec 03 22:41:33 n900 uses a serial transport for pcm Dec 03 22:41:34 ah ok Dec 03 22:41:45 I think muxed into a serial link with dma buffers Dec 03 22:41:53 not sure if mcbsp is used or not Dec 03 22:42:32 btw the nothing refered to how much I have to explain or to how much they know Dec 03 22:44:42 so...quick question...I've what's written to the DSP Dec 03 22:44:49 what should I do with it? Dec 03 22:44:56 s/what's/how much Dec 03 22:51:10 the question is, why does writing into dsp cause the kernel to Oops and reboot Dec 03 22:51:26 and where is this oops happening exactly? Dec 03 22:51:47 mmm Dec 03 22:51:57 status is not just the things written to the dsp Dec 03 22:52:09 leviathan, buffer problems Dec 03 22:53:01 mhmm Dec 03 22:53:11 someone solved the exact same issue Dec 03 22:53:17 with his serial driver Dec 03 22:53:30 by extending the IRQ-lock Dec 03 22:53:35 raw_lock Dec 03 22:53:53 but the kernel makros he used arent available anymore Dec 03 22:53:58 in the actual kernel Dec 03 22:55:57 leviathan, what issue? Dec 03 22:56:11 the buffer problems? Dec 03 22:56:31 the Oops Dec 03 22:56:48 Internal error: Oops: 817 [#1] PREEMPT Dec 03 22:56:56 Unable to handle kernel paging request at virtual address 00001000 Dec 03 22:58:01 ok Dec 03 22:58:07 do you have the whole trace? Dec 03 22:58:41 leviathan, so you made progress and didn't have time to tell me about? Dec 03 22:59:54 http://pastebin.com/m5d761bf7 Dec 03 23:00:04 yes Dec 03 23:00:16 because it was yesterday, when I was travelling around Dec 03 23:00:24 between ETHZ and Chaostreff Dec 03 23:00:32 I was debugging in the train Dec 03 23:00:45 I alway was so tired Dec 03 23:01:04 until I sleeped something from 16.00h until 23.00h Dec 03 23:01:13 now I'm awake Dec 03 23:01:21 but I'm still totaly tired Dec 03 23:01:50 tomorrow I've just one lecture Dec 03 23:01:57 so enough time to code around Dec 03 23:01:59 myabe you need a bh or workqueue or something Dec 03 23:02:04 if it's locking Dec 03 23:02:20 the problem is, that its exactly NOT locking Dec 03 23:02:52 what do you read on lin 127? Dec 03 23:03:10 as I can see, after googling around Dec 03 23:03:19 and after some tracing Dec 03 23:03:30 that DMA kills alsa Dec 03 23:03:47 it also kills other drivers, with unclean locking Dec 03 23:03:55 but it also kills alsa Dec 03 23:04:04 have you looked at omap? Dec 03 23:04:07 driver Dec 03 23:04:32 nope, but I will Dec 03 23:05:06 the problem seems to be Dec 03 23:05:17 that dma uses space of other drivers Dec 03 23:05:35 but removes his data after a cycle Dec 03 23:05:53 in smem? Dec 03 23:05:55 and replaces the RAM with the old content of the other driver Dec 03 23:05:57 how can that be? Dec 03 23:06:15 dunno, thats what I read, searching for an explanation Dec 03 23:06:36 it uses temporarally unused RAM belonging to other drivers Dec 03 23:06:53 which do not lock theire memory clean Dec 03 23:07:24 what drivers? Dec 03 23:07:29 alsa Dec 03 23:07:30 :) Dec 03 23:07:31 that's probably a linux thing Dec 03 23:07:36 jup Dec 03 23:07:44 I mean allocator Dec 03 23:08:08 two drivers accessing same memory ==> Oops Dec 03 23:08:09 can you poison it? Dec 03 23:08:25 dont have any poison around ;-) Dec 03 23:08:36 only nikotin and koffee Dec 03 23:08:53 fill it with junk Dec 03 23:08:59 I did Dec 03 23:08:59 and trace that Dec 03 23:09:04 right Dec 03 23:09:10 cat /dev/urandom > /dev/dsp Dec 03 23:09:14 what driver? Dec 03 23:09:20 thats where the trace comes from Dec 03 23:09:41 no, I mean fill the allocated space with a identifiable hex code Dec 03 23:09:54 oh, ok Dec 03 23:09:59 what driver is writing over or being written over? Dec 03 23:10:49 mmm Dec 03 23:11:01 http://pastebin.com/m5d761bf7 line 127 Dec 03 23:11:36 GNUtoo: we can select between GUI and sound... Wunderfull... >_< Dec 03 23:11:51 *Wonderfull Dec 03 23:12:06 GUI and sound? Dec 03 23:12:39 on line 127 dma ist deployed to handle framebuffer update Dec 03 23:12:57 and this causes a memory corruption Dec 03 23:13:07 ah ok Dec 03 23:13:13 wow Dec 03 23:13:16 wow!!! Dec 03 23:13:32 so this refresh patch is wrong Dec 03 23:13:46 and it was erronously attributed to me Dec 03 23:13:56 :) Dec 03 23:14:00 leviathan, did you get sound working without the GUI? Dec 03 23:14:09 no Dec 03 23:14:26 might be, that its realy beacause the framebuffer refreshment Dec 03 23:14:36 that would be fucking crap Dec 03 23:14:57 because then we would have need to lock the memory against each others memory Dec 03 23:16:10 yes I did it, the first time I realy managed to communicate, why I see somewhere a bug xD Dec 03 23:16:25 could you try Dec 03 23:16:35 to fix it? Dec 03 23:16:39 needs time Dec 03 23:16:53 no without framebuffer Dec 03 23:17:07 oh, ok Dec 03 23:17:21 first I'll smoke Dec 03 23:17:24 then I'll try Dec 03 23:17:25 ok Dec 03 23:20:21 leviathan, are you still there? Dec 03 23:20:48 how did you get an oops and not a pannic where you can't see the panic message? Dec 03 23:26:16 ssh root@192.168.0.202 Dec 03 23:26:21 while true; do Dec 03 23:26:23 dmesg -c Dec 03 23:26:24 done Dec 03 23:26:32 ssh root@192.168.0.202 Dec 03 23:26:43 cat /dev/urandom > /dev/dsp Dec 03 23:26:57 holding camera button and rebooting into fastboot Dec 03 23:27:08 :) Dec 03 23:28:30 the problem seems to be, unclean memory reservation in the alsa driver Dec 03 23:28:46 so I'll attack the spinlock method used in the driver Dec 03 23:28:51 and optimize it Dec 03 23:29:42 ok Dec 03 23:29:47 msm-pcm.h Dec 03 23:29:54 look into stuct Dec 03 23:29:58 audio_locks Dec 03 23:30:59 ohh, theres my raw_lock Dec 03 23:32:21 arch/arm/include/asm/spinlock_types.h Dec 03 23:33:02 ok, I have an idea how it might work Dec 03 23:36:11 I'll go soon Dec 03 23:36:15 me too Dec 03 23:36:23 I'll have to get up in the morning Dec 03 23:36:27 for linear algebra Dec 03 23:36:39 afterwards I'll check out the issue again Dec 03 23:37:26 ohh Dec 03 23:37:48 the fix for DMA, I tried breaks the framebuffer at all Dec 03 23:37:57 I don't get any terminal at all -_- Dec 03 23:38:28 okeee Dec 03 23:38:33 tomorrow again Dec 03 23:39:11 good night Dec 03 23:42:07 btw I retried Dec 03 23:42:35 and usb debug didn't work for kernel panic Dec 03 23:42:48 as I bet that the usb is not directly connected to the msm soc Dec 03 23:42:54 s/soc/main cpu Dec 03 23:43:09 like on omap for instace if I remember well Dec 03 23:43:12 bye Dec 03 23:43:29 usb debug means your while trye Dec 03 23:43:32 *true Dec 04 00:03:11 akiniemi: Can the nokia hardware detect whether a Phase 1/Phase2, Phase2+,Phase3 sim is inserted? Dec 04 00:54:14 denkenz: i think you're busy in GPRS work and may not change the voice call part now. right? Dec 04 00:54:45 shall I first submit patches like list_calls and send_dtmf stuff Dec 04 00:54:51 for hfp Dec 04 01:22:02 it depends, feel free to submit the list calls and send_dtmf as I don't think I had any problems with those two Dec 04 01:51:20 denkenz: fine. and i'd send the patch about g_source_remove(vd->clcc_source) when voicecall_remove in atmodem **** ENDING LOGGING AT Fri Dec 04 02:59:57 2009