**** BEGIN LOGGING AT Tue Jun 15 02:59:57 2010
Jun 15 10:08:45 <trupheenix> join #openmoko-debian
Jun 15 10:16:48 <trupheenix> anyone got ideas for a splash screen? animated one?
Jun 15 16:25:42 <leviathan> GNUtoo|laptop: hi
Jun 15 16:26:00 <leviathan> watch this: http://pastebin.com/SAxU0fww
Jun 15 16:26:03 <leviathan> ^_^
Jun 15 16:26:09 <leviathan> ubiformat now works
Jun 15 16:34:03 <Q-Master> ~seen panicking
Jun 15 16:34:15 <apt> panicking <~michael@mail1-urbizone.urbizone.be> was last seen on IRC in channel #openmoko, 128d 1h 27m 47s ago, saying: 'ok'.
Jun 15 16:34:27 <leviathan> wow
Jun 15 16:35:45 <GNUtoo|laptop> leviathan, hi
Jun 15 16:36:55 <GNUtoo|laptop> leviathan, wow,I bet the patch is yours,is it commited?
Jun 15 16:37:04 <leviathan> nope
Jun 15 16:37:17 <leviathan> its sooo hackish
Jun 15 16:37:19 <GNUtoo|laptop> nope for the commit?
Jun 15 16:37:20 <GNUtoo|laptop> ok
Jun 15 16:37:27 <leviathan> and ubifs now oopses -_-
Jun 15 16:37:30 <leviathan> while attaching
Jun 15 16:37:31 <GNUtoo|laptop> ah ok
Jun 15 16:37:40 <leviathan> but ubiformat now works xD
Jun 15 16:37:46 <GNUtoo|laptop> ok
Jun 15 16:38:40 <GNUtoo|laptop> anyway,ubifs didn't work before,ask mickeyl but if the code is hackish but the commits are clean it would be ok for me
Jun 15 16:39:00 <GNUtoo|laptop> but I'd like to ear mickeyl's opinion
Jun 15 16:39:38 <leviathan> ok
Jun 15 16:39:50 <leviathan> its just not very portable atm
Jun 15 16:39:52 <leviathan> :-)
Jun 15 16:39:57 <GNUtoo|laptop> ok
Jun 15 16:40:11 <leviathan> means its just applyable for the first subpage
Jun 15 16:40:18 <GNUtoo|laptop> ahh ok
Jun 15 16:40:19 <leviathan> if you request the second it crashes
Jun 15 16:40:22 <leviathan> like NOW
Jun 15 16:40:25 <GNUtoo|laptop> understood
Jun 15 16:40:31 <leviathan> I'll work it out
Jun 15 16:40:39 <GNUtoo|laptop> ok
Jun 15 16:40:40 <leviathan> needs some additional memcpy and memset ;-)
Jun 15 16:40:45 <GNUtoo|laptop> ok
Jun 15 16:40:45 <leviathan> ahh, and >> and <<
Jun 15 16:40:47 <leviathan> :-)
Jun 15 16:40:57 <GNUtoo|laptop> shift?
Jun 15 16:41:02 <leviathan> jup
Jun 15 16:41:11 <GNUtoo|laptop> ok
Jun 15 16:41:20 <leviathan> first shift it, then cut it
Jun 15 16:41:31 * GNUtoo|laptop wonder why there is an arrow up on the shift keys
Jun 15 16:41:31 <leviathan> so you get you 64byte subpage out of your 2048
Jun 15 16:41:40 <GNUtoo|laptop> it should be >> for right shift
Jun 15 16:41:46 <GNUtoo|laptop> and << for left shift
Jun 15 16:41:52 <GNUtoo|laptop> but it would confuse people
Jun 15 16:41:57 <leviathan> because in mathematics it has another sense
Jun 15 16:42:02 <leviathan> it means a lot bigger than
Jun 15 16:42:03 <GNUtoo|laptop> (I'm making a joke about keyboards)
Jun 15 16:42:08 <leviathan> or a lot smaller then
Jun 15 16:42:15 <leviathan> strict bigger, smaller then
Jun 15 16:42:25 <leviathan> for example
Jun 15 16:42:30 <GNUtoo|laptop> btw I made a basic proc node
Jun 15 16:42:36 <GNUtoo|laptop> for what mickyl asked
Jun 15 16:42:37 <leviathan> ok
Jun 15 16:42:42 <leviathan> very well
Jun 15 16:42:44 <GNUtoo|laptop> hi mickey_office 
Jun 15 16:48:13 * mickey_office  going home
Jun 15 16:48:14 <mickey_office> l8er
Jun 15 17:03:25 <ThibG> larsc, I've used the read_worker for a moment yesterday, no single error (or none I've noticed)
Jun 15 17:22:36 <larsc> ThibG: my testcase was `dd if=bigfile of=/dev/mmcblk0p1; dd if=/dev/mmcblk0p1 of=anotherfile` and then compare the checksums
Jun 15 17:24:57 <leviathan> GNUtoo|laptop: http://gitorious.org/htc-msm-2-6-32/leviathan-incoming/commit/5c6b19b4d3415b334054b2ce1aca844254acd99c
Jun 15 17:25:04 <leviathan> now a cleaner implementation
Jun 15 17:25:06 <leviathan> if you wish
Jun 15 17:25:10 <leviathan> I can IFDEF it
Jun 15 17:25:15 <GNUtoo|laptop> yes better
Jun 15 17:25:18 <leviathan> ok
Jun 15 17:25:45 <GNUtoo|laptop> #IF SOMETHING
Jun 15 17:25:53 <GNUtoo|laptop> #define SOMETHING 0
Jun 15 17:33:19 <leviathan> http://gitorious.org/htc-msm-2-6-32/leviathan-incoming/commit/a9f75d49142d25cc7d37b358158412550c47a0c0
Jun 15 17:33:43 <leviathan> now virtual subpage writing
Jun 15 17:33:45 <leviathan> :-)
Jun 15 17:34:04 <leviathan> first I read a whole page
Jun 15 17:34:30 <leviathan> then I make memset for the concerning terrain
Jun 15 17:34:44 <leviathan> and overwrite the page
Jun 15 17:34:57 <leviathan> a bit overhead
Jun 15 17:35:00 <leviathan> but anyways
Jun 15 17:35:08 <leviathan> its only 2KiB
Jun 15 17:39:11 <ThibG> larsc, ok, I've only checked the sums of large files repetively, not copied them around
Jun 15 17:40:08 <ThibG> and when dd'ing from the large file to /dev/null, the rate is ~3MB/s with IRQ, and ~5MB/s with worker :)
Jun 15 17:44:36 <CIA-56> freesmartphone.org: 03mickey 07cornucopia * r4c214f83c786 10/fsotdld/src/plugins/provider_gps_nmea/plugin.vala: fsotdld: parse $GPRMC
Jun 15 17:47:23 <leviathan> Yeeha, I implemented virtual subpage size reading ^_^
Jun 15 17:50:56 <leviathan> so
Jun 15 17:51:06 <leviathan> now I only have to fix the oops in ubiattach
Jun 15 17:51:09 <leviathan> then I have ubifs
Jun 15 17:51:11 <leviathan> :=D
Jun 15 17:52:49 <CIA-56> freesmartphone.org: 03vfebvre 07utilities * r929f26902af8 10/palmpre/read_tokens/ (13 files in 2 dirs): 
Jun 15 17:52:49 <CIA-56> freesmartphone.org: palmpre: read_tokens: Added proper automake environment
Jun 15 17:52:49 <CIA-56> freesmartphone.org: * Added proper automake environment
Jun 15 17:54:11 <PaulFertser> leviathan: cool :) hope it'll be more failsafe, because experiments with ubifs on FR gave unexpectedly suboptimal results (trashed fs after several hard shutdowns).
Jun 15 17:54:33 <PaulFertser> leviathan: but it's rather cool you got subpage working, congratulations :)
Jun 15 17:54:48 <leviathan> thx! ^^
Jun 15 17:55:10 <leviathan> as soon as I get the whole SP functionality, I'll send a patchset to the android people
Jun 15 17:55:15 <leviathan> perhaps they are interested too
Jun 15 17:55:18 <leviathan> ^^
Jun 15 18:01:40 <larsc> ThibG: it might be a good idea to create a own thread or workqueue for copying from the sd card. because otherwise it will block the global workqueue
Jun 15 18:11:23 <GNUtoo|laptop> PaulFertser, yes I've lost my fs once
Jun 15 18:11:37 <GNUtoo|laptop> I've its backup on a file
Jun 15 18:11:46 <GNUtoo|laptop> but It's said to be self-healing
Jun 15 18:11:55 <GNUtoo|laptop> and it didn't self-heal
Jun 15 18:14:01 <PaulFertser> GNUtoo|laptop: and it's said to be journalling and hence fault-tolerant. And it isn't tolerant. It's all weird stuff. I'm not sure how it can happen that way. Is it possible subpage writes are unreliable on FR NAND?
Jun 15 18:14:27 <GNUtoo|laptop> even an ext3/4 filesystem can have issues
Jun 15 18:14:31 <GNUtoo|laptop> see barriers
Jun 15 18:15:43 <PaulFertser> GNUtoo|laptop: i do not remember having problems with ext3. And reiserfs3 did a nasty joke to me just a week ago.
Jun 15 18:16:02 <GNUtoo|laptop> lol I had dataloss with reiserfs too in the old days
Jun 15 18:16:24 <GNUtoo|laptop> basically the distros don't enable barriers
Jun 15 18:16:34 <GNUtoo|laptop> so what should be atomic is not atomic
Jun 15 18:16:47 <GNUtoo|laptop> maybe it's default in the recent kernel,not shure
Jun 15 18:16:54 <PaulFertser> GNUtoo|laptop: i'm not sure. I've read a lot about ext3 issues, they all were caused by buggy apps.
Jun 15 18:17:09 <GNUtoo|laptop> PaulFertser, do you know the barrier issue?
Jun 15 18:17:16 <GNUtoo|laptop> it's not very well knows
Jun 15 18:17:19 <GNUtoo|laptop> *known
Jun 15 18:17:22 <PaulFertser> GNUtoo|laptop: probably no
Jun 15 18:17:30 <PaulFertser> GNUtoo|laptop: i've forgotten the details
Jun 15 18:17:36 <GNUtoo|laptop> ok I'll try to find a lwn article
Jun 15 18:18:04 <GNUtoo|laptop> me too but I remember that ext3/4 is not 100% safe unless you activated barriers
Jun 15 18:18:21 <GNUtoo|laptop> which resulted in 30% performance loss
Jun 15 18:21:51 <PaulFertser> GNUtoo|laptop: no filesystem is "safe", especially when apps have wrong assumptions.
Jun 15 18:22:02 <GNUtoo|laptop> ok
Jun 15 18:27:39 * [Rui] waves. any chance to get glib-json or json-c in repo?
Jun 15 18:31:21 <PaulFertser> GNUtoo|laptop: (barriers) i've read on wikipedia about it now, interesting and worrying stuff.
Jun 15 18:32:31 <GNUtoo|laptop> ok
Jun 15 18:36:31 <ThibG> larsc, you mean, from µSD to µSD? That could be done without involving the CPU, no?
Jun 15 18:37:50 <larsc> no, i mean when we copy from the sd card to the main memory
Jun 15 18:40:54 <ThibG> _read_worker is already a dedicated workqueue, no?
Jun 15 18:41:08 <larsc> is it?
Jun 15 18:41:16 <ThibG> seems like it
Jun 15 18:41:32 <larsc> wait, i'll check
Jun 15 18:42:38 <larsc> nope
Jun 15 18:42:52 <ThibG> (but it loops from the moment it's called to the moment the read finished)à
Jun 15 18:42:53 <ThibG> -à
Jun 15 18:42:58 <larsc> there is one global work queue
Jun 15 18:43:46 <larsc> once a work is scheduled in a work queue it blocks all other works in that queue until its finished
Jun 15 18:44:05 <larsc> but it's possible to create a dedicated work queue with its own thread
Jun 15 18:44:06 <GNUtoo|laptop> mickey|wm, hi are you back?
Jun 15 18:44:15 <ThibG> oh, ok, I see
Jun 15 18:45:54 <larsc> and since copying the data can take a few seconds it's a good idea to put it in its own thread
Jun 15 18:46:41 <[Rui]> json-c's the most promising
Jun 15 18:49:23 <ThibG> larsc, makes sense
Jun 15 18:50:59 <larsc> i once made a patch which put the whole request processing in one thread which used completions to wait for certain events
Jun 15 18:51:34 <larsc> but it didn't worked quite and so I dropped it again
Jun 15 18:52:12 <ThibG> completions?
Jun 15 18:52:49 <larsc> uhm. completion block a thread until they are completed ;)
Jun 15 18:53:22 <ThibG> hum ok
Jun 15 18:53:29 <larsc> what you usually do is
Jun 15 18:53:39 <larsc> completion_init(&completion);
Jun 15 18:53:54 <larsc> start_some_request_which_eventually_triggers_an_irq();
Jun 15 18:54:04 <larsc> compleition_wait(&completion);
Jun 15 18:54:17 <larsc> and then in the irq handler complete(&completion);
Jun 15 18:54:40 <ThibG> ok, interesting :)
Jun 15 19:01:51 <ThibG> do you think it's worth using a dedicated workqueue?
Jun 15 19:02:10 <ThibG> or refactor the request processing as you intended before, instead?
Jun 15 19:20:52 <leviathan> GNUtoo|laptop: could you please have a look onto my patches?
Jun 15 19:21:00 <leviathan> it seems now to be something with ubi
Jun 15 19:21:19 <GNUtoo|laptop> leviathan, which patch?
Jun 15 19:22:07 <leviathan> the subpage page
Jun 15 19:22:16 <GNUtoo|laptop> the one in gtorious?
Jun 15 19:22:21 <leviathan> jup
Jun 15 19:22:25 <GNUtoo|laptop> what am I suposed to do with it?
Jun 15 19:22:41 <GNUtoo|laptop> you know nand better than me
Jun 15 19:22:45 <leviathan> uhm
Jun 15 19:23:04 <leviathan> just try to ubiattach after formating an unneded partition
Jun 15 19:23:12 <leviathan> e.g. userdata after backup
Jun 15 19:23:16 <leviathan> would be mtd5
Jun 15 19:23:22 <leviathan> and then look at the error
Jun 15 19:23:44 <leviathan> i'll push some additional changes
Jun 15 19:23:47 <GNUtoo|laptop> I really don't see how I could be helpfull,you know that part better than me
Jun 15 19:23:49 <GNUtoo|laptop> ok
Jun 15 19:23:50 <leviathan> which will bring more light into my problem
Jun 15 19:25:10 <leviathan> do now a pull
Jun 15 19:25:20 <leviathan> and enable virtual SP ops in mtd options
Jun 15 19:25:21 <GNUtoo|laptop> ok
Jun 15 19:25:31 <leviathan> then you will see my problem
Jun 15 19:25:59 <leviathan> it trys to read a hudge amount of data
Jun 15 19:26:01 <leviathan> 11 pages
Jun 15 19:26:11 <leviathan> starting by a non existing base adress
Jun 15 19:26:20 <leviathan> at least I beliefe its not existing...
Jun 15 19:26:31 <GNUtoo|laptop> ah you need help for tracking that bug
Jun 15 19:26:35 <leviathan> yes
Jun 15 19:26:37 <leviathan> :-)
Jun 15 19:26:38 <GNUtoo|laptop> ok
Jun 15 19:27:15 <GNUtoo|laptop> your changes are disabled by default right?
Jun 15 19:27:54 <leviathan> uhm
Jun 15 19:27:56 <leviathan> oopsy
Jun 15 19:27:58 <leviathan> no
Jun 15 19:28:01 <leviathan> its default yes
Jun 15 19:28:04 <GNUtoo|laptop> then make a new commit
Jun 15 19:28:08 <leviathan> yes
Jun 15 19:28:10 <leviathan> I'll do
Jun 15 19:28:11 <leviathan> mom
Jun 15 19:28:14 <GNUtoo|laptop> because we may need nand
Jun 15 19:28:17 <GNUtoo|laptop> for instance
Jun 15 19:28:26 <GNUtoo|laptop> *it can be used with yaffs2
Jun 15 19:28:35 <GNUtoo|laptop> *I use it for my android chroot for gps
Jun 15 19:31:04 <leviathan> uhm
Jun 15 19:31:07 <leviathan> of course
Jun 15 19:31:19 <leviathan> my changes are just thought as improvement
Jun 15 19:31:25 <leviathan> not destroyment of android ;-)
Jun 15 19:31:37 <GNUtoo|laptop> yes but I'm not shure they don't break something
Jun 15 19:31:38 <leviathan> android will not remark anything of these changes
Jun 15 19:31:56 <leviathan> its just some improvement for enabling other filesystems
Jun 15 19:31:59 <GNUtoo|laptop> hy it can be used with yaffs2 I mean somehting oe based
Jun 15 19:32:00 <leviathan> like eg. jffs2
Jun 15 19:32:13 <GNUtoo|laptop> like IMAGE_FSTYPE += "yaffs2"
Jun 15 19:32:20 <leviathan> I KNOW
Jun 15 19:32:29 <GNUtoo|laptop> ok
Jun 15 19:32:30 <leviathan> but yaffs2 doesnt do ANY compression
Jun 15 19:32:36 <leviathan> we loose 2/3 of our space
Jun 15 19:32:38 <GNUtoo|laptop> yes I know
Jun 15 19:32:50 <leviathan> with subpage compression gets possible
Jun 15 19:32:54 <GNUtoo|laptop> ok
Jun 15 19:33:06 <leviathan> anyway
Jun 15 19:33:07 <GNUtoo|laptop> can we do something like raid or lvm with ubi?
Jun 15 19:33:13 <leviathan> yes
Jun 15 19:33:20 <GNUtoo|laptop> wow
Jun 15 19:33:21 <leviathan> thats another reason, why I want it
Jun 15 19:33:23 <leviathan> :-)
Jun 15 19:33:30 <GNUtoo|laptop> so no need to touch the partition scheme
Jun 15 19:34:48 <leviathan> oops, it was mtd manager itself, we need to make raid
Jun 15 19:34:53 <leviathan> but it also requests subpage
Jun 15 19:34:56 <leviathan> that was it
Jun 15 19:35:04 <leviathan> went again over my notes here
Jun 15 19:35:14 <leviathan> anyways
Jun 15 19:35:19 <GNUtoo|laptop> ok
Jun 15 19:35:21 <leviathan> we need subpage functionality
Jun 15 19:35:59 <GNUtoo|laptop> yes but do we really need it now?
Jun 15 19:36:13 <GNUtoo|laptop> I mean the phone is half-usable
Jun 15 19:36:16 <leviathan> sooner or later :-)
Jun 15 19:36:25 <GNUtoo|laptop> mickeyl is for the later
Jun 15 19:36:31 <leviathan> im for sooner
Jun 15 19:36:43 <leviathan> additionally I'm nearly at the goal
Jun 15 19:36:49 <leviathan> I can smell the prey
Jun 15 19:36:50 <leviathan> ^^
Jun 15 19:36:53 <GNUtoo|laptop> I know,you want to swap micro-sd cards
Jun 15 19:36:59 <GNUtoo|laptop> ok
Jun 15 19:39:27 <leviathan> and in addition
Jun 15 19:39:33 <leviathan> if we have nand under controll
Jun 15 19:39:38 <leviathan> we can make installer images
Jun 15 19:39:41 <leviathan> for sd cards
Jun 15 19:40:03 <GNUtoo|laptop> realy?
Jun 15 19:40:05 <leviathan> what makes it very easy for n00bs to install and test
Jun 15 19:40:07 <leviathan> of course
Jun 15 19:40:08 <GNUtoo|laptop> who will make them?
Jun 15 19:40:11 <GNUtoo|laptop> also:
Jun 15 19:40:12 <leviathan> ME
Jun 15 19:40:14 <leviathan> :-)
Jun 15 19:40:16 <GNUtoo|laptop> we have fastboot
Jun 15 19:40:31 <ThibG> larsc, what doesn't please me with the read_worker is all the checks duplicated with the IRQ handling code
Jun 15 19:40:34 <GNUtoo|laptop> and don't expect people to be too much nobish
Jun 15 19:40:41 <GNUtoo|laptop> remember they rooted the phone
Jun 15 19:44:06 <leviathan> GNUtoo|laptop: hmm, ok
Jun 15 19:44:09 <leviathan> anyway
Jun 15 19:44:12 <leviathan> one error
Jun 15 19:44:16 <leviathan> then I have it ;-)
Jun 15 19:45:44 <CIA-56> freesmartphone.org: 03Frederik.Sdun 07utilities * rc48b06f82ceb 10/palmpre/preboot/data/themes/default/default.edc: preboot: remove external elm module from edc
Jun 15 19:45:45 <CIA-56> freesmartphone.org: 03Frederik.Sdun 07utilities * ra8b55b5cb1a2 10/palmpre/read_tokens/ (13 files in 2 dirs): Merge branch 'master' of fso:utilities
Jun 15 19:50:26 <GNUtoo|laptop> leviathan, how do you know you won't get a new error after that
Jun 15 19:50:51 <leviathan> because its the last stage of the fs check, where it fails
Jun 15 19:51:11 <leviathan> only possibilty is subpagesize write
Jun 15 19:51:19 <leviathan> because I did not implement it yet
Jun 15 19:51:24 <leviathan> but if no one wants
Jun 15 19:51:27 <leviathan> someone needs
Jun 15 19:53:54 <leviathan> GNUtoo|laptop: But I know now, why it fails
Jun 15 19:54:06 <leviathan> it wants to start in the middle of a subpage
Jun 15 19:54:15 <leviathan> thats not allowed from dma
Jun 15 19:54:17 <leviathan> so it fails
Jun 15 19:59:38 <GNUtoo|laptop> leviathan, I was just asked to remaster some cds
Jun 15 20:01:09 <leviathan> uhhh?
Jun 15 20:01:28 <leviathan> ok
Jun 15 20:01:29 <GNUtoo|laptop> leviathan, is that normal that mount segfault when you don't tell -tyaffs2 ?
Jun 15 20:01:41 <leviathan> uhm, sry
Jun 15 20:01:51 <leviathan> is fixed soon
Jun 15 20:01:54 <leviathan> ^_^"
Jun 15 20:01:54 <GNUtoo|laptop> ok
Jun 15 20:02:10 <GNUtoo|laptop> dmesg has some [  559.021087] msm_nand_read_subpage: 71bf000 512
Jun 15 20:02:23 <leviathan> should be fixed soon
Jun 15 20:02:30 <GNUtoo|laptop> ok np
Jun 15 20:03:13 <TAsn> !seen raster
Jun 15 20:03:16 <cdbot2> raster (~raster@enlightenment/developer/raster) was last seen quitting from #openmoko-cdevel 5 hours, 33 minutes ago stating (Quit: Gettin' stinky!).
Jun 15 20:03:16 <TAsn> ~seen raster
Jun 15 20:03:18 <apt> raster <~raster@enlightenment/developer/raster> was last seen on IRC in channel #oe, 7d 10h 40m 2s ago, saying: 'going too?'.
Jun 15 20:03:27 <TAsn> Yay, two bots :P
Jun 15 20:05:44 <[Rui]> ok, I'm trying to make a bb file for json-c 0.9 (latest version) as I'm going to need it for elmdentica.
Jun 15 20:06:04 <[Rui]> however, their release tar.gz file isn't made with make dist-gz
Jun 15 20:06:51 <leviathan> GNUtoo|laptop: should be fixed now
Jun 15 20:07:03 <[Rui]> as such it seems that "inherit autotools" doesn't work well, right? what should I use instead?
Jun 15 20:07:07 <GNUtoo|laptop> ok
Jun 15 20:09:31 <leviathan> ok, seems to be already a write issue
Jun 15 20:09:41 <leviathan> I'm further then I thought -_-
Jun 15 20:12:50 <leviathan> GNUtoo|laptop: oops
Jun 15 20:12:51 <leviathan> nope
Jun 15 20:12:56 <leviathan> it cant read that much
Jun 15 20:13:02 <leviathan> because of RAM
Jun 15 20:13:08 <leviathan> so dma fucks up
Jun 15 20:13:10 <leviathan> ...
Jun 15 20:13:18 <leviathan> its not allowed to read that much
Jun 15 20:13:22 <GNUtoo|laptop> ah
Jun 15 20:13:25 <leviathan> wtf?
Jun 15 20:14:34 <leviathan> http://pastebin.com/S0bjtVym
Jun 15 20:16:56 <GNUtoo|laptop> leviathan, addr2line is your friend
Jun 15 20:17:09 <leviathan> addr2line?
Jun 15 20:17:17 <leviathan> where is it?
Jun 15 20:17:44 <leviathan> ohhh
Jun 15 20:17:46 <leviathan> nice ^_^
Jun 15 20:18:47 <[Rui]> nevermind, one WORKDIR too many
Jun 15 20:22:12 <GNUtoo|laptop> it's in your binutils cross toolchain
Jun 15 20:22:26 <GNUtoo|laptop> another trick:
Jun 15 20:22:34 <GNUtoo|laptop> there are messages in dmesg
Jun 15 20:22:41 <GNUtoo|laptop> they often do something like that:
Jun 15 20:22:48 <GNUtoo|laptop> function_name: message
Jun 15 20:22:55 <GNUtoo|laptop> so grep System.map
Jun 15 20:22:58 <GNUtoo|laptop> for function name
Jun 15 20:23:01 <GNUtoo|laptop> get the address
Jun 15 20:23:11 <GNUtoo|laptop> and with addr2line you get the file and the line
Jun 15 20:23:21 <GNUtoo|laptop> no need of cscope etc...
Jun 15 20:29:30 <leviathan> GNUtoo|laptop: hmm, ok, thx!
Jun 15 20:30:07 <leviathan> I'm try'n to catch the bug
Jun 15 20:31:03 <leviathan> the DMA buffer in oob read gets somehow a NULL-pointer
Jun 15 20:31:09 <leviathan> if you request too much space...
Jun 15 20:31:10 <leviathan> hmm
Jun 15 21:39:31 <leviathan> GNUtoo|laptop: I'll sleep now
Jun 15 21:40:01 <GNUtoo|laptop> ok me too
Jun 15 23:18:52 <misc> mhh, did I miss something with kernel developpement, why is there #ifdef __cplusplus  in some ar6000 header ?
Jun 15 23:19:10 <misc> ( i mean, either there is some subtilities , or that's quite ugly )
Jun 15 23:33:11 <larsc> the driver is from atheros and afaik they use it on multiple platforms
Jun 15 23:33:21 <larsc> feel free to send cleanup patches
**** ENDING LOGGING AT Wed Jun 16 02:59:56 2010