**** BEGIN LOGGING AT Mon Apr 03 09:59:59 2006 Apr 03 10:00:02 the file has been downloaded again Apr 03 10:00:09 but the problem return Apr 03 10:02:14 well.. then you'll have to unpack the file (tar xvzf ~/slug/download/ports_sources.redhat.com__20050627.tar.gz -C /tmp) Apr 03 10:02:43 repack it (cd /tmp; tar cvzf ports_sources.redhat.com__20050627.tar.gz ports_sources.redhat.com__20050627) Apr 03 10:03:05 ok, now i try Apr 03 10:03:07 move it back to the download dir (mv /tmp/ports_sources.redhat.com__20050627.tar.gz ~/slug/download/ports_sources.redhat.com__20050627.tar.gz) Apr 03 10:03:30 and create the .md5 file (cd ~/slug/download/; md5sum ports_sources.redhat.com__20050627.tar.gz > ports_sources.redhat.com__20050627.tar.gz.md5) Apr 03 10:04:54 evil: i get an error unpaking the file Apr 03 10:05:11 tar extracts some files then exits with Apr 03 10:05:28 tar: Child returned status 2 tar: Error exit delayed from previous errors Apr 03 10:08:20 my problem has also been reported here: http://www.nslu2-info.de/showthread.php?t=3807 Apr 03 10:08:49 okay, then you'll propably have to find another download server (google for ports_sources.redhat.com__20050627.tar.gz) Apr 03 10:09:45 andrea_ this problem happened several times. it should have been fixed, but it looks like the fix (reuploading the file to the server) didn't work Apr 03 10:11:15 downloaded from familiar server, now build continues ok :) Apr 03 10:13:39 that's fine andrea_ Apr 03 10:14:01 only a question: how much time it's rasonble to take 'bitbake busybox' ? Apr 03 10:14:20 It needs to build the cross compilers and stuff first. Apr 03 10:14:27 that takes a good amount of time. Apr 03 10:14:36 on my 1Ghz machine that means 2hrs+ Apr 03 10:14:40 ah ok Apr 03 10:14:46 only the first time though Apr 03 10:14:46 i ve a 3ghx p4 Apr 03 10:14:50 i ve a 3ghz p4 Apr 03 10:14:54 sure Apr 03 10:15:00 thanks Apr 03 12:00:23 anyone has used the nslu2 watchdog as explained in http://www.nslu2-linux.org/wiki/OpenSlug/Watchdog ? Apr 03 12:35:27 It's not entirely reliable Apr 03 12:35:43 if the flash is in write mode when the watchdog tries to reset, it'll hang Apr 03 12:36:04 It's (IIRC) a problem with either A0 silicon or the nslu2 design Apr 03 12:38:30 Other than that, the watchdog actually works Apr 03 12:38:57 ie, touching the watchdog devices causes the slug to reset after 60 secs Apr 03 12:39:07 (unless it's touched again before that) Apr 03 12:42:28 heh Apr 03 12:42:36 I didn't know that page Apr 03 13:09:26 NAIL: my question is 'how do i touch the watchdog' ? Apr 03 13:09:45 following that page i ve rebuilt busybox Apr 03 13:09:58 now i ve /bin/watchdog utility Apr 03 13:10:08 but no /dev/watchdog device Apr 03 13:10:40 The /dev entry is probably just not created. we might need to tell udev how to create it. Apr 03 13:11:06 for now you should be able to create it manully with mknod. I have no clue what major/minor it uses though. Apr 03 13:11:19 mmm...any advice how to create it ? Apr 03 13:11:22 oh.. Apr 03 13:12:16 ok. A quick google reports major=10, minor=130 but you'll have to test it. Apr 03 13:12:30 here's how: mknod /dev/watchdog c 10 130 Apr 03 13:12:55 keep in mind this is a temporary hack as you'd have to do this everytime you reboot. Apr 03 13:13:20 once you determine it works you could add it permanently to udev's rules. Apr 03 13:13:49 ok, but how do i reset the watchdog Apr 03 13:13:56 don't you need to rebuild the kernel with watchdog enabled though? Apr 03 13:14:02 that I don't know. Apr 03 13:14:10 It's not on the wiki? Apr 03 13:14:34 in the wiki it's said to use the 'watchdog' utility Apr 03 13:14:47 it's part of the busybox package Apr 03 13:14:58 can u tell me where i can fetch the source ? Apr 03 13:16:17 no idea. perhaps check the watchdog util usage with watchdog --help? Apr 03 13:16:46 no ok, i was meaning: Apr 03 13:16:54 that util is part of busybox Apr 03 13:17:12 where can get the source to understand how speak with the watchdog ? Apr 03 13:17:53 look under your tmp/work/ folder. Probably under busybox but I'm sure you need to enable it in the kernel too though. Apr 03 13:18:54 voodo: my dmesg tells me "IXP4xx Watchdog Timer: heartbeat 60 sec" Apr 03 13:18:59 id it not enough ? Apr 03 13:19:12 good. I guess it is enabled by default then. Apr 03 13:19:23 that depends on your application. Apr 03 13:20:08 I've never played with it so I'm not sure how exactly it is structured. I'm only familiar with hardware watchdogs in small micros. Apr 03 13:20:27 I guess the watchdog util would be used to enable/disable it. Apr 03 13:21:03 the kernel probably has some built-in code to kick the watchdog on a regular basis. Apr 03 13:21:19 the help of the utils tell me: Apr 03 13:21:49 ok Apr 03 13:21:52 tested now Apr 03 13:21:58 the behaviour is this: Apr 03 13:22:01 really? What does it sya? Apr 03 13:22:30 after lunched watchdog util it do a watch reset every 30 sec Apr 03 13:22:37 and the system stays on Apr 03 13:22:41 now Apr 03 13:22:46 if i stop the daemon Apr 03 13:22:46 I was thinking of enabling it on my robot eventually as it's real useful to protect it from crashes. I have watchdogs on all my sub-micros. Apr 03 13:22:56 the system restart after a while Apr 03 13:23:07 oh, it's a deamon. Apr 03 13:23:09 so do i think :-) Apr 03 13:23:12 sure Apr 03 13:23:17 do a ps to check Apr 03 13:23:24 yes Apr 03 13:23:37 what is it called? Apr 03 13:23:43 it's a deemon, it must rise a reset every 30 sec.. Apr 03 13:23:49 if u stop it Apr 03 13:23:56 the system reboot after a while Apr 03 13:24:08 cool. Can you update the wiki with all that extra stuff you discovered. Thank. Apr 03 13:24:14 sure Apr 03 13:24:23 Especially the major/minor test stuff. Apr 03 13:24:23 thanks for all your help! Apr 03 13:25:29 glad I could help. Apr 03 17:39:36 morning all Apr 03 17:40:34 hey eFfeM Apr 03 17:40:49 eFfeM: are you in bangalore? Apr 03 17:41:46 morn' eFfeM Apr 03 17:41:46 how did it go last saturday? Apr 03 17:41:47 nope, next week Apr 03 17:42:21 leaving 11, back 15, then on the 18th to seattle and back 22; pffff Apr 03 17:42:36 koen, had a good trip back Apr 03 17:42:42 pepijn: saturday was fun Apr 03 17:43:28 :) Apr 03 17:46:14 koen, have you ever heard something from pigi recently? someone subscribed to this ipkg PR and I got a mail about it. That reminded me that this PR is open for two months. I hope I didn't scare him away Apr 03 17:46:21 eFfeM: http://dominion.kabel.utwente.nl/Gallery/slugdag2006/IMG_2122 Apr 03 17:46:35 eFfeM: pigi commit some fixes to ipkg last week Apr 03 17:47:42 koen: do i see a wrt54g(l) there, with the 'use cd-rom' sticker stuck on top? ;) Apr 03 17:48:24 pepijn: yes, eFfeM brought one Apr 03 17:49:55 pepijn, unfortunately it is not an l Apr 03 17:50:20 needed a router to connect nslu, laptop and slm5500 Apr 03 17:51:47 what a mess ... Apr 03 17:51:57 i just installed it again behind the tv Apr 03 17:54:03 koen changed my bb file into: Apr 03 17:54:04 CFLAGS = "'-I${KERNEL_SOURCE}/include' \ Apr 03 17:54:04 '-I${KERNEL_SOURCE}/drivers/media/video'" Apr 03 17:54:04 CFLAGS_append_arm = "'-D__LINUX_ARM_ARCH__=5'" Apr 03 17:54:12 is that ok or should I use += Apr 03 17:54:43 append is OK, but don't forget a leading space Apr 03 17:54:52 e.g. " ' Apr 03 17:55:54 ok Apr 03 17:56:27 the odd thing is that if I rebuild sometimes it will rebuild all of the kernel. is that due to the RDEPENDS Apr 03 17:57:21 there is no space on other places either (and I am the only one to use CFLAGS_append_arm Apr 03 17:57:57 _append doesn't insert a leading space, += does Apr 03 17:58:06 so in your example CFLAGS would be: Apr 03 17:58:24 '-I${KERNEL_SOURCE}/drivers/media/video''-D__LINUX_ARM_ARCH__=5' Apr 03 17:58:49 ok made it CFLAGS_append_arm = " '-D__LINUX_ARM_ARCH__=5' " Apr 03 17:59:13 that should work Apr 03 18:03:01 eFfeM: still there? Apr 03 18:03:24 yes Apr 03 18:03:46 koen, rebuilding now, for some reason it wants to rebuild the kernel too... Apr 03 18:07:30 koen http://84.87.135.248/slugdag/00013.jpg (2 MB) Apr 03 18:08:56 pepijn: check out that url if you want to see how koen looks like .... Apr 03 18:09:20 10 mins Apr 03 18:23:34 terugschuifbuffer ??? ouch Apr 03 18:23:52 * pepijn is looking at pictures of slugday nl Apr 03 18:27:17 terugschuifbuffer ?? Apr 03 18:27:33 it is on picture 10 Apr 03 18:28:16 it is called 'Scollback' in the english version Apr 03 18:28:23 (MacOSX terminal) Apr 03 18:28:27 heh Apr 03 18:28:41 I'm used to ignoring stuff like that Apr 03 18:29:04 and called 'Bla tilbake' in norwegian Apr 03 18:29:24 why don't you just turn i to english... macosx makes that so easy :) Apr 03 18:29:30 sorry no idea what you are referring to Apr 03 18:30:05 eFfem: picture 10 has a picture of MacOSX terminal Apr 03 18:30:11 and a Dutch menu on top Apr 03 18:30:18 http://dominion.kabel.utwente.nl/Gallery/slugdag2006/IMG_2130 Apr 03 18:30:42 yep, that one Apr 03 18:30:42 ooooooh Apr 03 18:30:49 thought you were referring to my pick 10 Apr 03 18:30:54 s/k// Apr 03 18:30:55 eFfem meant: thought you were referring to my pic 10 Apr 03 18:32:55 any idea what causes this:pvrusb2: version magic '2.6.16 preempt ARMv__LINUX_ARM_ARCH__ gcc-3.4' should be '2.6.16 preempt ARMv5 gcc-3.4' Apr 03 18:33:39 did use the CFLAGS_append_arm Apr 03 18:34:34 weird Apr 03 18:34:57 trying again with the append_arm in the CFLAGS Apr 03 18:36:00 aargh, it is again rebuilding the whole kernel for this. koen any idea why this is ? Apr 03 18:36:21 I've had this happen probably since moving to .16 or since adding the RDEPENDS Apr 03 18:36:23 I suspect it's a bug in bitbake dependency handling Apr 03 18:36:34 yeah, feared that Apr 03 18:36:37 I usually do bitbake -b foo.bb -c clean Apr 03 18:37:28 hm, i didn't use the -b, just did bb -cclean foo; bb foo Apr 03 18:37:42 your's works much faster.... Apr 03 18:37:59 because it doesn't track dependencies Apr 03 18:38:41 ah that means it is probably also riskier Apr 03 18:39:10 indeed Apr 03 18:47:19 koen, apparently CFLAGS_append_arm does not work, here is my compile log: log.do_compile.16083 Apr 03 18:47:36 * eFfem meant: http://84.87.135.248/log.do_compile.16083 Apr 03 18:48:34 heh Apr 03 18:48:37 I know why Apr 03 18:48:42 nslu2 = armeb Apr 03 18:48:52 so ? Apr 03 18:49:04 so it needs a append_arm for LE and append_armeb for BE Apr 03 18:49:59 ah, ok Apr 03 18:50:04 testing Apr 03 18:55:54 works Apr 03 18:56:19 koen, added both: Apr 03 18:56:20 CFLAGS_append_arm = " '-D__LINUX_ARM_ARCH__=5' " Apr 03 18:56:20 CFLAGS_append_armeb = " '-D__LINUX_ARM_ARCH__=5' " Apr 03 18:56:33 actually there is a white line between htem Apr 03 18:56:42 s/htem/them/ Apr 03 18:56:42 eFfem meant: actually there is a white line between them Apr 03 23:49:56 howdy everybody from rainy SF. is there any reason why i shouldn't do an update today? Apr 03 23:52:44 mayb, that the weather is to bad for this ;) **** ENDING LOGGING AT Tue Apr 04 09:59:57 2006