**** BEGIN LOGGING AT Mon Nov 28 02:59:57 2005 **** BEGIN LOGGING AT Mon Nov 28 03:50:16 2005 Nov 28 04:05:33 someone has a compiled sr_mod module for openslug2.7 ? Nov 28 04:05:53 hmm Nov 28 04:07:02 wops ipkgfind says that there is in openslug unstable... Nov 28 04:07:11 yup Nov 28 04:07:13 i didn't saw it.. Nov 28 04:07:23 should be just ipkg install kernel-module-sr-mod Nov 28 04:07:23 i'll look better ;) Nov 28 04:12:30 it says that it is for 2.6.14 but i've only a 2.6.12 image.. Nov 28 04:13:01 ipkg list | grep 2.6.14 says nothing =( Nov 28 04:13:45 ipkg list|grep "sr-mod" ? Nov 28 04:14:33 idem Nov 28 04:14:49 i think i have to add the unstable repostory Nov 28 04:15:15 probably not a very good idea Nov 28 04:15:33 sr-mod is only in unstable Nov 28 04:15:36 let's try :P Nov 28 04:16:53 I'll update the kernel in the stable feed to include sr-mod and sg-mod Nov 28 04:18:02 thanks it will be really useful Nov 28 04:18:16 i'm planning to use the slug to burn iso too Nov 28 04:19:11 yesh Nov 28 04:19:25 Now, if the autobuild is running, the module should be in the feed within 30 mins Nov 28 04:19:35 wow really thanks :D Nov 28 04:19:48 12:19 < CIA-12> repvik * r221 /releases/OpenSlug-2.7-beta/openembedded/packages/linux/openslug-kernel-2.6.12.2/defconfig: Add CD-ROM (and CDRW) support Nov 28 04:19:51 through modules Nov 28 04:21:39 nm, it won't. I have to rebuild it on my box first :P Nov 28 04:21:55 It's just been too long since I updated the stable feed. Nov 28 04:24:11 I'll have to build the whole feed from scratch. It'll take a while... Nov 28 04:26:39 i have to prepare my cross compiling environment...some day Nov 28 04:43:07 hum if i install a new kernel image what do i have to do to use it? no lilo here :PP Nov 28 11:47:52 koen, it seems there is a problem with mt, I've used ewi to check in my files, but apparently every change I have submitted last month is gone. Nov 28 11:47:56 see http://cia.navi.cx/stats/author/effem Nov 28 11:48:27 e.g. the new releases of the pvr driver that I have added or addition of cdstatus last saturday is missing Nov 28 11:48:38 any idea what is going on here? Nov 28 11:48:51 maybe committing to a wrong branch? Nov 28 11:49:52 hm, how can i find out? Nov 28 11:51:54 cia says i am on open-embedded and nslu2-linux Nov 28 11:52:27 mt list branches says: Nov 28 11:52:28 org.nslu2-linux.bitbake Nov 28 11:52:28 org.nslu2-linux.dev Nov 28 11:52:28 org.openembedded.dev Nov 28 11:52:28 org.openembedded.dreambox Nov 28 11:52:28 org.openembedded.nslu2-linux Nov 28 11:53:15 is stuff from ewi propagated properly ? it could well be that this started when I switched to ewi during the nslu2-linux outage Nov 28 11:53:32 it propagated org.openembedded.dev Nov 28 11:53:47 could you do 'monotone log' and check the output on the top? Nov 28 11:53:54 not nslu2-linux? Nov 28 11:54:42 first one says: Nov 28 11:54:43 Date: 2005-11-05T14:16:35 Nov 28 11:54:43 Branch: org.nslu2-linux.dev Nov 28 11:54:56 its a patch from rwhitby on the makefile Nov 28 11:55:10 that branch isn't used for the OE tree Nov 28 11:55:35 OE stuff should go in org.openembedded.dev Nov 28 11:55:41 so my changes are in a non-propagated branch in your tree Nov 28 11:55:51 or system or whatever you call it Nov 28 11:56:11 unpropagated and unused branch, yes Nov 28 11:56:48 only for ewi or for everyone? how did I get on this branch? Nov 28 11:57:21 cia says I am on projects openembedded and nslu2-linux Nov 28 11:58:07 and I see commits on http://cia.navi.cx/stats/author/effem, but the last one is on nov 1. Soon after that I probably changed to ewi Nov 28 11:58:46 grab some coffee and watch the news, back in 25 mins Nov 28 12:45:09 koen, can you tell me how I set my branch properly ? Nov 28 12:48:49 btw apparenty I was working on org.openembedded.dev: mt heads says: Nov 28 12:48:51 monotone: branch 'org.openembedded.dev' is currently merged: Nov 28 12:48:51 d6ed8bd922639d616c17c01d270e9edf2bc6b517 eFfeM@openembedded.org 2005-11-26T23:04:34 Nov 28 12:49:30 the mt log output was from the new tree I made with the master makefile Nov 28 12:49:32 that one says: Nov 28 12:49:34 monotone: branch 'org.nslu2-linux.dev' is currently merged: Nov 28 12:49:34 848c0a5dd66a011270c69313b2cc01ff584b1544 rwhitby@nslu2-linux.org 2005-11-05T14:16:35 Nov 28 12:50:12 it seems the master makefile is not ok or the wget cmd in the wiki gives a wrong one .. Nov 28 12:51:16 koen, the mt log from the 'old' tree says: Nov 28 12:51:18 Date: 2005-11-26T23:04:34 Nov 28 12:51:18 Branch: org.openembedded.dev Nov 28 12:51:18 Added files: Nov 28 12:51:18 openslug/openembedded/packages/cdstatus/cdstatus-0.96.05.bb Nov 28 12:51:19 openslug/openembedded/packages/cdstatus/cdstatus-0.96.05/cdstatus.patch Nov 28 12:51:19 black\out: you'll need to reflash the kernel in flash, and replace the ixp* modules with modules recompiled for that kernel. Nov 28 12:52:04 any idea where these have gone? Nov 28 12:52:06 eFfeM: try doing an explicit push of org.openembedded.dev to monotone.nslu2-linux.org Nov 28 12:53:17 koen, mt push monotone.nslu2-linux.org or do I need to add org.openembedded.dev to the cmd somewhere ? Nov 28 12:53:57 monotone push monotone.nslu2-linux.org org.openembedded.dev Nov 28 12:54:37 in progress, added --verbose Nov 28 12:57:10 monotone: bytes in | bytes out | certs out | revs out Nov 28 12:57:11 monotone: 131.1k | 1.1M | 618 | 5 Nov 28 12:57:11 monotone: successful exchange with monotone.nslu2-linux.org Nov 28 12:57:36 5 revs out, looks pretty good Nov 28 12:58:59 ok, now for the last remaining q: i decided on a fresh start yesterday, retrieved the master makefile and started from scratch but MT/options says: Nov 28 12:59:00 branch "org.nslu2-linux.dev" Nov 28 12:59:00 database "/home/slug/OpenSlugHead/monotone/nslu2-linux.db" Nov 28 12:59:00 key "" Nov 28 12:59:24 whereas the old dir said: Nov 28 12:59:29 branch "org.openembedded.dev" Nov 28 12:59:29 database "/home/slug/OpenSlugHead/monotone/nslu2-linux.db" Nov 28 12:59:29 key "" Nov 28 12:59:34 that is the old MT/options file Nov 28 13:00:50 koen, can I just change the options file to use the org.openembedded.dev branch or is there another way to do this (I want to go to the new dir as I might have nuked something in the old tree; so better safe than sorry) Nov 28 13:01:12 no idea on that Nov 28 13:01:22 I always use explicit pushes Nov 28 13:02:21 ok thanks, I'd better do that as well Nov 28 13:07:31 eFfeM: could you also try doing a direct push to monotone.vanille.de? Nov 28 13:08:07 sure, hang on Nov 28 13:09:12 in progress Nov 28 13:09:49 ehm... Nov 28 13:09:50 monotone: bytes in | bytes out | certs out | revs out Nov 28 13:09:50 monotone: 190.4k | 653.9k | 617 | 181 Nov 28 13:09:54 181 ??? Nov 28 13:11:18 it won't write all of them Nov 28 13:11:31 well it is finished Nov 28 13:14:12 if it still doesn't show up you should try adding the changes to a clean tree Nov 28 13:14:51 i.e by downloading http://ewi546.ewi.utwente.nl/OE/OE.db.bz2 using that Nov 28 13:17:46 hm, in the new tree I get now: Nov 28 13:17:48 [slug@Woonkamer openembedded]$ mt update Nov 28 13:17:48 monotone: note: branch 'org.openembedded.dev' has multiple heads Nov 28 13:17:48 monotone: note: perhaps consider 'monotone merge' Nov 28 13:17:48 monotone: already up to date at 44ef2a80f1407b2958e8f750892482362d9bb352 Nov 28 13:18:09 can I safely do that? Nov 28 13:18:13 yes Nov 28 13:20:21 in the openembedded dir or one up ? Nov 28 13:20:43 in the openembedded dir Nov 28 13:20:53 ok, that's what I did: Nov 28 13:20:54 monotone: misuse: no unique private key for cert construction Nov 28 13:21:10 this is in the new tree Nov 28 13:21:27 try importing your pub and priv key into the db Nov 28 13:22:49 mt cert ? Nov 28 13:24:11 mt read Nov 28 13:24:30 where contains the key(s) Nov 28 13:27:15 ok, now I also know why I had to make 3 copies of the key, misplaced the one on the harddisk, so I had to revert to a copy on the memory stick Nov 28 13:29:16 :) Nov 28 13:29:45 [slug@Woonkamer OpenSlugHead]$ mt read monotone: warning: key 'eFfeM@openembedded.org' is not equal to key 'eFfeM@openembedded.org' in database Nov 28 13:29:45 monotone: read 2 packets Nov 28 13:29:45 [slug@Woonkamer OpenSlugHead]$ mt merge Nov 28 13:29:45 monotone: misuse: branch 'org.nslu2-linux.dev' is merged Nov 28 13:30:04 mt merge -b org.openembedded.dev Nov 28 13:30:27 hmmm, that key warning is bad Nov 28 13:30:38 ok, i was also surprised by that Nov 28 13:31:05 it is one file with both the privkey and the pubkey Nov 28 13:31:22 i've tried the mt read twice but both time get the warning Nov 28 13:31:42 anyway now the merge worked Nov 28 13:35:05 how can I now find what it did ? Nov 28 13:35:12 mt log shows nothing Nov 28 13:35:30 that is, nothing new Nov 28 13:37:03 oops, wrong dir Nov 28 13:40:36 koen, i now see the merge in the log, i assume i still need to push that Nov 28 13:40:46 correct Nov 28 13:41:56 koen: I've gotten that key warning a bunch of times Nov 28 13:42:02 doesn't appear to do any harm though Nov 28 13:45:14 koen, I've pushed the merge both to nslu2-linux and monotone, did an update and pull after that, but the files do not show up in my dir Nov 28 13:45:24 in the log they are shown as added files though Nov 28 13:45:45 weird Nov 28 13:46:58 could your try downloading http://ewi546.ewi.utwente.nl/OE/OE.db.bz2, adding your keys, monotone pull from vanille.de, doing a checkout, adding the files, committing and pushing? Nov 28 13:46:58 can you do a pull and see if you get packages/cdstatus or packages/pvrusb2 content other than pvrusb2-mci_20050911 and pvrusb2-mci_20050911.bb ? Nov 28 13:47:25 pulling... Nov 28 13:47:53 monotone: 272.7k | 114.9k | 726 | 0 | 0 Nov 28 13:48:01 donwloading 32 MB, where should I extract Nov 28 13:48:05 hmm Nov 28 13:48:29 extract it in some dir, doesn't really matter where Nov 28 13:48:33 it's a fresh chechout Nov 28 13:48:38 checkout* Nov 28 13:49:04 ok, 2 mins to go Nov 28 13:50:49 ehm, could it be caused that the files are not in my current tree, I moved to the new tree as I got weird errors with the previous one and my new tree does not contain the files yet Nov 28 13:51:11 could be Nov 28 13:56:35 koen mt add says: Nov 28 13:56:37 monotone: misuse: working copy directory required but not found Nov 28 13:56:58 do I need to do the add in the org.openembedded.dev ? Nov 28 13:56:59 did you do a checkout of org.openembedded.dev in a new dir? Nov 28 13:57:37 yes, figured out that I needed to cd to org.openembedded.dev; this tree is a little bit different from the openslug one Nov 28 13:58:42 cd org.oe.dev/packages/ ; cp -r ~/somedir/cdstatus . Nov 28 13:58:49 or something like that Nov 28 13:59:30 yeah, done that; added my pvr changes committed them; added my cdstatus; committed them; push to vanille ? Nov 28 13:59:43 yes Nov 28 14:01:35 did 2 commits, got 2 revs out so that seems good Nov 28 14:02:00 you should be able to see them now Nov 28 14:03:07 CIA-14: eFfeM org.oe.dev * r02c04a86... /: pvrusb2-mci: added several releases that somehow did not make it to the archive Nov 28 14:03:10 [22:03] CIA-14: eFfeM org.oe.dev * r4fb1223f... /: cdstatus: created; made patch that allow both LE and BE machines to write a proper wav header Nov 28 14:03:27 looks like it worked Nov 28 14:03:30 1yesssssss Nov 28 14:03:34 i Nov 28 14:04:15 (actually I wanted to say 2yesssss0) thanks koen Nov 28 14:04:29 oops wrong ^K Nov 28 14:04:35 thanks koen Nov 28 14:05:07 your welcome Nov 28 14:06:53 koen, if you have time, could you glance over my .bb file for cdstatus Nov 28 14:07:23 i might be tempted to do dbus, hal and ivman, but I'd rather first be sure that I understood how it works Nov 28 14:08:19 dbus and hal should be already in Nov 28 14:08:29 ah, ok Nov 28 14:09:00 yeah, I see them, that only leaves ivman (which is the simplest of the 3) Nov 28 14:09:20 cdstatus looks pretty OK to me Nov 28 14:09:47 ok, I was not too sure about the install and the way I added the cdstatus.cfg file Nov 28 14:10:28 and the LDFLAGS thing (I could not get it through the compiler without it; since I feared I nuked bb or something like that I started with the new tree) Nov 28 14:12:30 still cannot build ixp4xx-csr-2.1-r0 Nov 28 14:12:35 compiler says: Nov 28 14:12:35 Makefile:1225: lib/linuxbe/qmgr-component-dependencies.d: No such file or directory Nov 28 14:12:45 probably a wrong -I or so. Nov 28 14:12:52 does this sound familar to someone? Nov 28 14:27:08 eEfeM: it's not a problem, the file doesn't exist first time round. Nov 28 14:28:55 jbowler-away, yeah, but I don't think this is ok, the resulting ipx400.ko is only 1250 bytes!!!! Nov 28 14:28:56 -rw-rw-r-- 1 slug slug 1250 Nov 28 22:05 ./ixp400_xscale_sw/lib/linuxbe/ixp400.ko Nov 28 14:29:18 and this one is 1140 Nov 28 14:29:20 -rw-r--r-- 1 slug slug 1148 Nov 28 22:05 ./install/ixp4xx-csr/lib/modules/2.6.14/kernel/drivers/ixp400/ixp400.ko Nov 28 14:29:28 1140 -> 1148 Nov 28 14:29:52 this seems way too small Nov 28 14:33:47 That's correct, it is. I think you have the same problem as Mathieu Monney Nov 28 14:33:56 yes Nov 28 14:34:26 that's why i started to build from a fresh tree (I think Mathieu did the same) Nov 28 14:34:35 it seems this is only the mod.o file Nov 28 14:34:50 What is it? Is it really a kernel module, or is it something else like a text file - it's way too small for the .ko (which should be about 800k) Nov 28 14:35:31 [slug@Woonkamer ixp400_xscale_sw]$ file ./lib/linuxbe/ixp400.ko Nov 28 14:35:31 ./lib/linuxbe/ixp400.ko: ELF 32-bit MSB relocatable, ARM, version 1 (ARM), not stripped Nov 28 14:36:12 this one is 1250 bytes, ixp400_mod.o is 1161 bytes, seems that the rest of the code is not dragged in Nov 28 14:40:19 eFfeM: can you put the log.do_compile up on pastebin? Nov 28 14:40:35 pastebin ? Nov 28 14:40:55 nevermind found it Nov 28 14:44:57 jbowler-away, don't know how to paste this easily, it is 340 lines. Nov 28 14:45:08 instead I have put it on my web server Nov 28 14:45:14 can you get it from http://84.87.135.248/log.do_compile Nov 28 14:45:19 www.pastebin.com Nov 28 14:45:46 yeah, i know the url but how do I easily put 340 lines in it (some of them which are loooooong) Nov 28 14:46:46 achso, sorry, never tried that Nov 28 14:46:57 jbowler-away, caplink811_log managed to put it on pastebin under name effem Nov 28 14:47:20 (opened the file in firefox, then did select all and pasted in pastebin Nov 28 14:50:52 Take a look at the size of the input files to the final ld command: Nov 28 14:50:54 armeb-linux-ld -r -EB lib/linuxbe/ixp400_qmgr.o lib/linuxbe/ixp400_npeMh.o lib/linuxbe/ixp400_npeDl.o lib/linuxbe/ixp400_ethAcc.o lib/linuxbe/ixp400_ethDB.o lib/linuxbe/ixp400_ethMii.o lib/linuxbe/ixp400_featureCtrl.o lib/linuxbe/ixp400_osServices.o lib/linuxbe/ixp400_oslinux.o lib/linuxbe/npeDl/IxNpeMicrocode.o /home/slug/OpenSlugHead/openslug/tmp/staging/armeb-linux/kernel/ixp_osal/lib/ixp425/linux/linuxbe/ixp_osal.o -o lib/linuxbe/ixp400. Nov 28 14:51:56 ok, one sec Nov 28 14:52:07 IxNpeMicrocode.o should be 351kbytes along Nov 28 14:52:16 .... alone ... Nov 28 14:53:10 315002 bytes to be precise Nov 28 14:53:23 351002 I mean Nov 28 14:55:14 What about the size of the output - lib/linuxbe/ixp400.o ? Nov 28 14:55:21 ixp400.o is 645291 bytes Nov 28 14:55:32 (was just checking that one) Nov 28 14:55:34 That's correct Nov 28 14:57:41 Hum... I wonder why it does the module build twice, once before, once after the build of ixp400.o Nov 28 14:58:04 are you looking at the version from my web server? the pastebin version seems truncated Nov 28 14:59:58 you lost me with the build twice, I only see this: Nov 28 14:59:59 CC [M] /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.o Nov 28 14:59:59 Building modules, stage 2. Nov 28 14:59:59 MODPOST Nov 28 14:59:59 CC /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.mod.o Nov 28 15:00:01 LD [M] /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.ko Nov 28 15:00:14 the ld cmd here does not include ixp400.o Nov 28 15:00:23 can't find the other mod build Nov 28 15:00:32 It happens in both your log and in mine - the only apparent difference is the size of the ixp400.ko Nov 28 15:01:12 The LD [M] only lists the output. Nov 28 15:02:09 ah, ok, is there an easy way to expand this? Nov 28 15:06:38 Yes, set KERNEL_VERBOSE="V=1" (at least I think that is the correct setting), looks like it is then necessary to clean and rebuild. Nov 28 15:08:00 That's it - add 'KERNEL_VERBOSE=V=1' \ in EXTRA_OEMAKE in the .bb file Nov 28 15:08:41 My actual ld command (from log.do_compile) is then: Nov 28 15:08:45 armeb-linux-uclibc-ld -r -o /home/work-tmp/jbowler/nslu2/ucslugc/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.ko /home/work-tmp/jbowler/nslu2/ucslugc/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.o /home/work-tmp/jbowler/nslu2/ucslugc/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.mod.o Nov 28 15:09:30 ok, while you were typing I found that the 2.0 version contained V=1 in the makefile patch so I added it to 2.1 makefile.patch Nov 28 15:09:32 now rebuilding Nov 28 15:10:59 hm, looks quite the same: Nov 28 15:11:01 armeb-linux-ld -r -o /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.ko /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.o /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.mod.o Nov 28 15:11:07 still I get this short .ko file Nov 28 15:11:33 And ixp400.o is definately >600kbytes ? Nov 28 15:11:37 it includes the .o file Nov 28 15:12:07 yes Nov 28 15:12:08 [slug@Woonkamer temp]$ ls -l /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.o Nov 28 15:12:09 -rw-rw-r-- 1 slug slug 645291 Nov 28 23:09 /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.o Nov 28 15:13:03 Now that's what I call compression Nov 28 15:13:47 i went to a fresh tree the other day because I got compiler or bb problems; I had to add TARGET_LDFLAGS="" to my new .bb file otherwise it would complain about -Wl,-rpath-link or something like that Nov 28 15:14:28 that is indeed compression, can we do this on video as well :-) Nov 28 15:14:38 This doesn't make any sense, because an ld -r of just two .o files should pretty much just add them together. Nov 28 15:15:37 Setting TARGET_LDFLAGS="" is a sure way of stopping things working - it causes the link to not look in staging. Nov 28 15:17:07 ok, I'll check again into that later, (that's why I created the new tree in the first place) Nov 28 15:17:35 holy batman Nov 28 15:17:38 Try running the armeb-linux-ld command by hand Nov 28 15:17:57 that is what I just did and it gives a .ko module of 640 k ! Nov 28 15:18:52 Either you have a rogue armeb-linux-ld somewhere on your path or the kernel Makefile is lying about the command (quite possible). Nov 28 15:19:44 well if there was a rogue cmd it is an odd one as it does produce a ko file Nov 28 15:20:51 there is only one in my tree Nov 28 15:20:53 636 ./openslug/tmp/cross/bin/armeb-linux-ld Nov 28 15:21:52 there might be others on my system but which does not give me one Nov 28 15:23:19 is there a way to hack a --verbose in a makefile and run that? Nov 28 15:24:16 Or maybe the stuff I added to do_stage is overwriting the file - you could try commenting out the stuff in the .bb file after the comment in do_stage Nov 28 15:24:53 this: Nov 28 15:24:55 PACKAGES = "" Nov 28 15:24:56 do_install () { Nov 28 15:24:56 } Nov 28 15:24:58 ?? Nov 28 15:25:20 or one of the earlier comments Nov 28 15:25:42 or after this one Nov 28 15:25:43 # Install the library/object Nov 28 15:25:49 The comment in do_stage which starts: Nov 28 15:25:53 # Since Module.symvers in the kernel staging directory doesn't include Nov 28 15:26:12 So comment out everything from there to the "}" Nov 28 15:27:31 ixp4xx-csr_2.1.bb - not ixp_osal_2.1.bb which is not related to this problem... Nov 28 15:27:35 got it was accidently looking in the osal file (hey it is 11.30pm here ...) Nov 28 15:28:06 nope Nov 28 15:28:34 could it be related to this one: Nov 28 15:28:36 8 ./install/ixp4xx-csr/lib/modules/2.6.14/kernel/drivers/ixp400/ixp400.ko Nov 28 15:28:49 Making things really verbose looks difficult, though you could hack on staging...kernel/scripts/Makefile.modpost Nov 28 15:28:55 I'm also surprised by the 2.6.14 in this one Nov 28 15:31:27 ok changed modpost Nov 28 15:32:48 rebuilding Nov 28 15:33:58 no result, either this is not the good place or I made a mistake Nov 28 15:38:04 got it, used an oldtimer trick, moved the ld binary to another name and created a shell script armeb-linux-ld that calls the real ld with --verbose Nov 28 15:38:58 ddin't tell me what i needed; Nov 28 15:39:00 attempt to open /home/slug/OpenSlugHead/openslug/tmp/work/ixp4xx-csr-2.1-r0/ixp400_xscale_sw/lib/linuxbe/ixp400.o succeeded Nov 28 15:48:44 jbowler-away, added an ls -l to my shell script, when it is linking ixp400.o is only 550 bytes !!!! Nov 28 15:49:36 and the link command for ixp400.o is after the linking of the .ko file !!!! Nov 28 15:51:26 shouldn't this Nov 28 15:51:31 ixp400.o : $(OBJ_DIR)/ixp400.o Nov 28 15:51:35 in the makefile read Nov 28 15:51:53 ixp4003k.o : $(OBJ_DIR)/ixp400.o Nov 28 15:52:01 so with a k ? Nov 28 15:52:41 or should this Nov 28 15:52:42 +obj-m := ixp400.o Nov 28 15:52:45 be .ko Nov 28 15:52:48 ?? Nov 28 15:53:39 jbowler-away, you're still there ?? Nov 28 16:00:41 back now Nov 28 16:01:08 ok, found the cause see above, but no solutio Nov 28 16:01:12 ok, found the cause see above, but no solution Nov 28 16:04:50 It's also reproduceable on the nslu2-linux build machine. Nov 28 16:04:58 changed the .ko dependency but that did not work Nov 28 16:05:07 good, that does not make it solely my problem :-) Nov 28 16:05:22 It must be because sometimes the second modpost doesn't rebuild the .ko Nov 28 16:06:02 yup, I don't see a 2nd modpost Nov 28 16:06:17 There was in the original log you posted - one before, one after the ld Nov 28 16:07:42 Ok - there's the difference - in your log the second MODPOST doesn't have a CC or an LD, in my log the MODPOST is followed by an LD Nov 28 16:07:47 (and a CC). Nov 28 16:07:59 So it's a timestamp problem. Nov 28 16:08:19 yeah, looks like that Nov 28 16:09:48 why is it done twice anyway ? Nov 28 16:11:14 That's what I don't understand - it definately shouldn't attempt to build the .ko before ixp400.o has been linked. Nov 28 16:12:02 where is this modpost thing coming from, I've been searching for stage 2 but cant see where it is emitted Nov 28 16:13:08 what about this Nov 28 16:13:10 touch $(OBJ_DIR)/ixp400.c Nov 28 16:13:10 cp Makefile.kmod26 $(OBJ_DIR)/Makefile Nov 28 16:13:10 make -C $(OBJ_DIR) Nov 28 16:13:11 $(LD) $(LDFLAGS) $^ -o $@ Nov 28 16:13:15 make -C $(OBJ_DIR) Nov 28 16:13:20 it is from the makefile Nov 28 16:14:02 hm, good plan jelle Nov 28 16:14:53 jbowler-away, i think i cannot be very useful with this any more and it is 0.15 by now and I have to work 12 hrs tomorrow so I think I call it a day Nov 28 16:15:02 Yes, and those lines are doing a 'touch', apparently to cause the following make to do something... Nov 28 16:15:22 the worry I have is the two makes Nov 28 16:15:25 I can work out what is going wrong now - I have a repro case on nslu2-linux Nov 28 16:16:05 i'm lost why the first make and the LD is in the clipped code above Nov 28 16:16:59 ehm, the code above is added in the makefile patch Nov 28 16:17:10 ER_OBJ) $(OSAL_MODULE) Nov 28 16:17:10 + touch $(OBJ_DIR)/ixp400.c Nov 28 16:17:10 + cp Makefile.kmod26 $(OBJ_DIR)/Makefile Nov 28 16:17:10 + make -C $(OBJ_DIR) Nov 28 16:17:11 $(LD) $(LDFLAGS) $^ -o $@ Nov 28 16:17:15 + make -C $(OBJ_DIR) Nov 28 16:17:57 although it was in the old version as well Nov 28 16:18:34 The LD is from the original Intel Makefile, the extra stuff is the hack to build a kernel module, the hack looks wrong. Nov 28 16:19:23 Hum, move the LD up I think... Nov 28 16:19:27 ok, i'll leave it for you to find a fix, you are better in this than I am Nov 28 16:21:30 catch you in a few days (or drop me an email), i won't be online tomorrow Nov 28 16:21:43 bye Nov 28 16:22:03 bye (I think I have a fix) Nov 28 18:00:56 ACTION  Nov 28 21:47:58 koen|tv: if marceln approaches you about an @openembedded.org key and monotone write access, I vouch for him - he is going to be working on the Unslung firmware for the NSLU2. Nov 28 21:59:05 jbowler-away: that problem with the small ixp400.ko smells like the one we had a long time ago where we had to add a sleep to the Makefile - see the build-annoyance.patch in openembedded for what we did. Nov 28 22:00:29 rwhitby: I may have fixed it with my last commit, it's the same problem. Nov 29 02:14:11 hi to allo Nov 29 02:14:32 anyone does know when openslug 2.8 is due ? Nov 29 02:14:41 you mean 3.0? Nov 29 02:15:17 i see in the feed Nov 29 02:15:25 that there is a 2.8 tree.. Nov 29 02:15:26 see http://article.gmane.org/gmane.comp.misc.nslu2.devel/424 Nov 29 02:15:34 is it going to ve relased ? Nov 29 02:22:00 2.8 is the feed that is used by the current unstable (ie. HEAD) Nov 29 02:22:16 ok Nov 29 02:22:41 so..ve u some idea when we get get 3.0 ? Nov 29 02:23:14 When it's ready ;) Nov 29 02:24:23 When the new intel drivers proves to be stable, probably Nov 29 02:26:49 ok nail, but i when YOU think this is going to happen ? Nov 29 02:26:51 :-) Nov 29 02:31:57 if someone sees eFfeM, let him know that I've fixed his mess in org.openembedded.dev - it seems he someone propagated from org.nslu2-linux.dev to org.openembedded.dev (who knows how, cause the Makefile simply cannot do that). Nov 29 02:32:12 He should send a very apologetic email to the OE list. Nov 29 02:43:35 ok rwhitby **** ENDING LOGGING AT Tue Nov 29 02:59:56 2005