**** BEGIN LOGGING AT Sat Oct 01 02:59:56 2005 Oct 01 03:21:05 hurray. got my second slug... Oct 01 03:30:16 hi conradl Oct 01 03:30:25 hi, wat do i need to modify to build 2.6.13.2 as kernel i.s.o. 2.6.12.2 ? Oct 01 03:31:08 ai... openslug/unslung? Oct 01 03:31:19 openslug Oct 01 03:32:18 I just don't know the details of bitbake and where it decides to map bb openslug-kernel to use openslug-kernel.2.6.12.2 Oct 01 03:32:56 i have a bug which could be solved in 13.2 (saw a patch for the file on the web) Oct 01 03:33:25 hi Oct 01 03:33:29 but the patch changes several things, so instead of patching locally I'd prefer to go to 13.2 or 14.2 Oct 01 03:33:31 hi Oct 01 03:34:23 I just built from the mastermakefile, doesn;'t that get you what you want? Oct 01 03:34:35 nope, that gives 2.6.12 Oct 01 03:35:00 checking... Oct 01 03:36:45 where in my fs can i find the version? Oct 01 03:38:32 *Head/openslug/tmp/work/ Oct 01 03:39:13 there is a dir that (on my sys) is named: openslug-kernel-2.6.12.2-r17 Oct 01 03:39:25 ls -d openslug* Oct 01 03:39:42 one level deeper is a linux dir Oct 01 03:42:14 indeed. you are right. Oct 01 03:42:50 so you probably should compile from the latest head, right? Oct 01 03:43:40 yes Oct 01 03:43:57 actually last sundays, I'm making some local patches Oct 01 03:44:28 but there is a 13.2 package in openembedded/packages Oct 01 03:44:35 just don't know how to bb it Oct 01 03:46:53 ok, probed a lttle bit further Oct 01 03:46:55 bb -b openslug-kernel_2.6.13.2.bb Oct 01 03:47:00 does the job. Oct 01 03:47:08 (apparently, it is running now) Oct 01 03:57:35 morning Oct 01 03:58:14 g'morning to you to Oct 01 03:58:39 +o Oct 01 03:58:54 |-) Oct 01 04:00:49 hi dwery Oct 01 04:01:16 dwery, i'm still fighting with i2c and 1205 Oct 01 04:01:23 tell me Oct 01 04:02:03 i see the 1205 attaching twice, first time is the normal one, 2nd time is again when the pvr is initialising Oct 01 04:03:08 and then it attaches to the wrong bus. if I then disconnet the bus the i2c adapter gets torn down, the memory is freed; next time the 1205 accesses the adaptor it crashes Oct 01 04:03:16 which driver? Oct 01 04:03:20 mine or original? Oct 01 04:03:20 (because the adaptor data has been released) Oct 01 04:03:25 1205 and pvrusb2 Oct 01 04:03:33 oh sorry, original still Oct 01 04:03:55 would your changes affect this? I was more suspecting the i2c subsystem Oct 01 04:04:05 saw some patches for it from .12 -> .13 Oct 01 04:04:06 my driver has a detection routine to avoid attaching to the wrong chip Oct 01 04:05:37 ok, i'm convinced Oct 01 04:05:54 but still curious on why it actually would try to do so Oct 01 04:06:38 it's the way it was designed Oct 01 04:06:41 iirc Oct 01 04:07:41 it wasn't meant to run on a multi bus system Oct 01 04:07:49 hm, seen something interesting hang on Oct 01 04:11:53 got it! Oct 01 04:12:04 i2c_add_adaptor says: Oct 01 04:12:05 /* inform drivers of new adapters */ Oct 01 04:12:06 list_for_each(item,&drivers) { Oct 01 04:12:06 driver = list_entry(item, struct i2c_driver, list); Oct 01 04:12:06 if (driver->flags & I2C_DF_NOTIFY) Oct 01 04:12:06 /* We ignore the return code; if it fails, too bad */ Oct 01 04:12:07 driver->attach_adapter(adap); Oct 01 04:12:25 so it informs all driver Oct 01 04:12:48 adn the x1205 attach says: Oct 01 04:12:49 static int x1205_attach(struct i2c_adapter *adapter) Oct 01 04:12:49 { Oct 01 04:12:49 struct rtc_time tm; Oct 01 04:12:49 struct timespec tv; Oct 01 04:12:50 int errno; Oct 01 04:12:52 x1205_i2c_client.adapter = adapter; Oct 01 04:13:07 followed by: Oct 01 04:13:08 if ((x1205_get_datetime(&x1205_i2c_client, &tm, X1205_CCR_BASE)) != NOERR) //test for functional driver Oct 01 04:13:08 return -EIO; Oct 01 04:13:25 and if this fails (which it will as we are on the wrong adapter Oct 01 04:13:33 yep Oct 01 04:13:46 then x1205_i2c_client.adapter will have the wrong value ! Oct 01 04:13:57 exactly. Oct 01 04:14:12 ok, is that fixed in your driver? Oct 01 04:14:30 yes Oct 01 04:15:38 but remember that bus 0 must be the ixp4xx one otherwise the rtc side of the code will simply not work (shouldn't harm anyway) Oct 01 04:16:16 it is Oct 01 04:16:19 ok Oct 01 04:16:33 btw.. i'm wrong, it should work. Oct 01 04:17:06 the first x1205 clock is the one which wil be used as system rtc Oct 01 04:18:26 is 14.2 on the head? Oct 01 04:19:05 brb Oct 01 04:23:29 back Oct 01 04:43:35 jbowler-zzz: ping Oct 01 04:52:37 dwery: see proposal sent by me to nslu2-linux for led colour sequences Oct 01 04:53:44 rwhitby-away: i forgot to subscribe to that list :) Oct 01 04:53:51 rwhitby-away: i'll chec the archives Oct 01 04:55:00 dwery: I think we should treat the ready/status led as a single led with multiple states. Then the synchronisation of red/green/amber is done in the kernel driver. Oct 01 04:55:44 rwhitby-away: that's doable, but not with the "arm-wide" interface Oct 01 04:56:29 in that interface you have red, green and amber (red+green) Oct 01 04:57:05 right - we would just use the green one, and it would allow blinking ready/status green/off. Oct 01 05:00:06 yes, mybe you can use the "arm-wide" as low level and write something over it to handle blinking and particular states (init failure) Oct 01 05:01:16 but to report init states or other kernel failures you will have to "tap" into a lot of different kernel files Oct 01 05:01:30 yeah, it needs some thought on how to do it best ... Oct 01 05:01:53 I don't know if this is acceptable upstream. Oct 01 05:03:10 I was thinking that the led is initialised to Red/Off, then all subsequent changes are done by userland scripts (i.e. /linuxrc, and /etc/init.d/foo) Oct 01 05:03:31 the only one I'm not sure about is the kernel panic Oct 01 05:03:54 and also init failure Oct 01 05:03:55 nick rwhitby Oct 01 05:06:25 dwery: init failure is handled by the led staying at the Red/Off blinking that it was initialised to, and not getting set to the next state by /linuxrc (cause init failed) Oct 01 05:06:43 right :) Oct 01 05:07:09 so we must have blinking in the kernel driver Oct 01 05:07:18 yes. Did you see my post? Oct 01 05:07:29 yes, just finished to read it Oct 01 05:08:30 suggestions about how to implement blinking? Oct 01 05:08:44 dunno - I would ask jbowler about that Oct 01 05:09:01 it doesn't quite fit the arm-wide interface Oct 01 05:09:11 (I'm the requirements and consistency with other archs guy, not the implementation guy :-) Oct 01 05:09:16 :D Oct 01 05:12:01 perhaps when you claim the led, a different interface comes into play, and when you release it, you're back to the arm-wide interface for the cpu status stuff. Oct 01 05:12:53 (e.g. the different interface could be the one in Documentation/ibm-acpi.txt extended to handle the arbitrary sequences) Oct 01 05:13:43 I read ibm-acpi.txt and gave a quick look to he code... it seems there's some kind of hw support.. have to check. Oct 01 05:14:40 yeah, I'm only talking about the interface (echoing strings to a /proc device), not the implementation (which would need to be incorporated with the arm-wide interface implementation) Oct 01 05:15:27 rwhitby: leds looking good Oct 01 05:15:31 read your mail Oct 01 05:16:19 There's other states available too Oct 01 05:16:27 ie, fast blink/slow blink Oct 01 05:16:30 i think we should ask the arm guys about how to blink a led :) Oct 01 05:17:11 NAiL: fast blink/slow blink is hard to describe to a user unless they are seeing both rates to be able to compare them. Oct 01 05:17:27 and it would also potentially differ for turbo and non-turbo slugs Oct 01 05:17:43 sequences of colours are unambiguous and precise. Oct 01 05:18:41 (that's my rationale for a single rate of blinking) Oct 01 05:19:19 (apart from the disk activity and cpu activity states - they use rates to indicate things) Oct 01 05:19:53 they're separate, since they don't use a fixed flash rate Oct 01 05:20:50 dwery: do you know where the cpu state stuff is triggered? Oct 01 05:21:48 rwhitby: arch/arm/kernel/process.c Oct 01 05:22:30 rwhitby: the timer part is in arch/arm/kernel/time.c Oct 01 05:27:00 ok, so it's just idle_start and idle_end. Oct 01 05:27:38 so on idle_start we go blank, and on idle_end we go green. Oct 01 05:28:39 rwhitby: redinthe current code. do we need a cpu idleness indication in OpenSlug? Oct 01 05:29:19 dwery: current code being what? Oct 01 05:29:44 rwhitby-away: the one on my development machine :-D Oct 01 05:31:04 03rwhitby 07org.nslu2-linux.dev * re14fbd1c... 10/ (Makefile common/openembedded.mk): Added foo-kernel targets Oct 01 05:31:39 dwery: ah, ok - so it can be green then Oct 01 05:31:56 ok. the timer, when/if enabled will be red then Oct 01 05:32:26 hmm - can we just do the same as lart and make that green too? Oct 01 05:32:45 but then you would have the timer override cpu activity Oct 01 05:34:31 so the timer would set it red (or maybe amber?) and then the cpu status stuff would set it back to off or green. Oct 01 05:35:52 rwhitby: LEDS_TIMER and LEDS_CPU work indipendently. Sometimes the led will be amber indeed Oct 01 05:35:58 in OpenSlug Oct 01 05:36:10 it think both LEDS_TIMER and LEDS_CPU should be off Oct 01 05:37:18 dwery: why would we turn them off in openslug. And you're still thinking of the ready/status as two leds. If you think of it as one led, then timer would set it to red, and idle would set it off or green. No amber in sight. Oct 01 05:37:51 (unless we chose amber instead of red for the timer, in which case no red would be seen) Oct 01 05:38:04 rwhitby: because in the arm-wide implementation they're actually two leds Oct 01 05:38:13 and the events arenot syncronized Oct 01 05:38:24 dwery: not in lart Oct 01 05:38:30 in lart they are one led Oct 01 05:38:34 yes Oct 01 05:38:37 and we can syncronise them in leds-nslu2.c Oct 01 05:38:39 but it's not syncronized too Oct 01 05:39:28 ok Oct 01 05:39:29 see lart_leds_event - we do the synchronisation in there. Oct 01 05:40:14 didn't you said you want a steady red during boot? Oct 01 05:41:05 right - the leds would start of not being claimed by the timer/idle stuff - it would be controlled by init scripts until S99finish, when it would be turned over to timer/idle Oct 01 05:41:13 s/start of/start off/ Oct 01 05:41:29 (and taken back again by the shutdown scripts) Oct 01 05:42:20 rwhitby: understood. so they actually start in the "claimed" state (which means claimed by the user in arm-wide-let-interface lingo) . Oct 01 05:42:29 I'm going to modify the code Oct 01 05:42:36 will you like to play with it? Oct 01 05:42:43 we just need some way of having the additional interface (the one which can do sequences of colours) drive the low-level arm-wide interface. Oct 01 05:43:04 dwery: I'll trust your testing against my specification :-) Oct 01 05:43:37 (I don't have a spare slug that I can use for kernel testing at the moment) Oct 01 05:43:45 rwhitby: i'm a kernel guy, we need a tester guy :) Oct 01 05:44:10 dwery: I vote for NAiL :-) Oct 01 05:44:38 rwhitby: me too., That's two votes for NAiL Oct 01 05:44:46 noone else? no? Oct 01 05:44:55 NAiL: you got it :-D Oct 01 05:45:15 NAiL: congratulations, you must be very proud. Oct 01 05:46:13 eh... I just got a spare slug, do you need anything tested? Oct 01 05:46:15 :) Oct 01 05:46:30 jelle: do you have serial? Oct 01 05:47:00 (cause you need to be able to see the kernel boot to test when the leds change) Oct 01 05:47:13 hm.... no... Oct 01 05:47:26 well, there's your first task :-) Oct 01 05:47:34 I guess I should get my soldering iron out... :) Oct 01 05:47:48 not that my laptop has serial either... Oct 01 05:48:08 oh, found an old spare laptop as well Oct 01 05:48:11 we mostly use usb->serial old throw-out mobile phone data cables Oct 01 05:48:51 serial on slug, usb on laptop or the other way around? Oct 01 05:49:14 serial on slug, usb on four port usb1.1 hub on the back of an asus wl500g wireless router :-) Oct 01 05:49:41 http://www.nslu2-linux.org/gallery/slug-central Oct 01 05:50:52 jelle: which compiling environment do you have? Oct 01 05:50:54 heh Oct 01 05:50:59 WHAT NOW?! Oct 01 05:51:00 :P Oct 01 05:51:07 ok, send me stuff to test ;) Oct 01 05:51:22 I have colinux Oct 01 05:51:23 NAiL: i'm preparing the patch. As a bonus, you'll get the new x1205 driver :) Oct 01 05:51:34 cool :) Oct 01 05:52:17 now, where did that serial cable of mine go... Oct 01 05:55:36 dwery: so the idea would be that the arm-wide /sys/devices/system/leds/leds0/event interface is claimed at startup, and there is a separate interface (perhaps /sys/devices/system/leds/leds1/event, or /proc/drivers/led) which handles the repeating sequences and calls the primitives from the first interface, and it's the second interface which the userland scripts drive. Oct 01 05:55:59 rwhitby: yep Oct 01 05:56:48 rwhitby: the first is quite done, just without syncronization. Oct 01 05:57:35 building the patchset, based on 2.6.14-rc3 Oct 01 06:01:00 it will be interesting to see how the timer and cpu stuff interacts on a slug Oct 01 06:01:12 (i.e. whether the timer colour will be visible) Oct 01 06:02:22 oh.. it's a very nice effect Oct 01 06:02:31 you should have seen it :) Oct 01 06:02:32 :-D Oct 01 06:05:08 so you see all three of green, off and red ? Oct 01 06:05:46 yep, sometimes Oct 01 06:05:52 amber too Oct 01 06:08:28 anyone know where the conventions for the structure under /sysfs is documented? Oct 01 06:11:14 fs/sysfs? Oct 01 06:11:30 http://lwn.net/Kernel/LDD3/ seems like a good resource to have on hand ... Oct 01 06:12:19 dwery: fs/sysfs is the implementation, but doesn't provide any conventions on how to properly structure your additions to syfs Oct 01 06:12:25 oh Oct 01 06:13:29 maybe Documentation/driver-model Oct 01 06:15:04 http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf - page 323 Oct 01 06:26:11 trying to get my slugwebserver going, but I'm not sure if it works from outside. Anybody care to do a ping or a webbrowser to my site? Oct 01 06:27:09 jelle: ip? Oct 01 06:27:21 jellealten.nl should work (no www) Oct 01 06:27:42 Hello! Oct 01 06:27:48 cool... Oct 01 06:27:50 web seem sok Oct 01 06:27:55 no pings Oct 01 06:28:16 sounds reasonable, so my firewall works too, only forwarding port 80 to my slug port 81. Oct 01 06:28:35 was wondering if my napt rules work. thanks a lot Oct 01 06:29:05 now i'd like to make it a vpn server, hope that's not a bad idea. Oct 01 06:32:53 patchset ready. will you get it rom the mlist or want me to bcc ? Oct 01 06:33:12 dwery: just send it to nslu2-developers Oct 01 06:33:21 ok Oct 01 06:34:48 mm Oct 01 06:34:56 I'm short of a serial Oct 01 06:35:14 my last cable doesn't work Oct 01 06:38:57 patchset sent. Oct 01 06:41:51 brb Oct 01 06:42:05 dwery: that {red,green,amber,opt1, opt2} {on,off} interface doesn't quite fit right for us Oct 01 06:43:41 although I guess if you say that each colour completely overrides the others, and it is not additive, then it should be fine (i.e. "red", "green", "amber" refer to the ready/status led, and opt1 and opt2 refer to the disk leds. Oct 01 06:44:35 so a "red on" followed by a "green on" does *not* give you amber, it gives you solid green. Oct 01 06:45:05 and any of "red off", "green off", or "amber off" will blank the ready/status led Oct 01 06:45:55 and then we have the separate, more powerful, colour sequencing interface overlay that. Oct 01 06:50:57 actually, is additive Oct 01 06:51:23 but that's the low-level interface Oct 01 06:51:31 arm-wide Oct 01 06:51:41 we will build anotherone on top of this Oct 01 06:51:54 and i gues we'nn need ioctls Oct 01 06:52:06 and/or exported functions Oct 01 06:52:35 hang on, why does the low-level interface have to be additive? Oct 01 06:53:10 the _leds_event procedure can do whatever it likes (i.e. make it additive, or not) Oct 01 06:53:13 it doesnt have to, i just cloned other interfaces Oct 01 06:54:03 we would want it to *not* be additive, so the higher level colour sequencer doesn't need to keep a memory of what was on previously Oct 01 06:54:59 (and so the user always gets a green if they turn on green when they use the low-level interface) Oct 01 06:55:38 ok Oct 01 06:56:09 03koen 07org.openembedded.dev * ra08a0a22... 10/packages/linux/handhelds-pxa-2.6_2.6.12-hh3.bb: packages/linux/handhelds-pxa-2.6_2.6.12-hh3.bb: remove extraversion patch since it has been applied upstream Oct 01 06:56:25 if i do amber on and then red off what should happen? Oct 01 06:56:56 the led would go off Oct 01 06:57:17 specifying which color to switch off is redundant in this case, innit? Oct 01 06:57:36 if you switch anything off on the status led, it should go off Oct 01 06:57:40 yes, but that's the way the interface that we're bastardising is specified :-) Oct 01 06:57:47 aha Oct 01 06:57:52 rwhitby: don't tell that upstream :-D Oct 01 06:58:21 dwery: *we're* the upstream for leds-nslu2.c Oct 01 06:58:26 :-D Oct 01 06:59:42 looks like the only thing we need to convince upstream of is the opt1, opt2 addition Oct 01 07:00:07 yes Oct 01 07:00:50 you've put them after led_halted in leds.h ? Oct 01 07:01:23 yes Oct 01 07:02:38 BTW, you need to change the header in nslu2-leds.c Oct 01 07:03:29 oooops :-D Oct 01 07:03:46 I always forgot that Oct 01 07:04:04 i subscribed to l-a-k but still waiting mod approval Oct 01 07:04:20 so I think is up to you to convice them about opt1/2 :-D Oct 01 07:06:16 we could always not use this interface for the disk leds :-) Oct 01 07:07:17 I'm wondering why they dont have /sys/devices/system/leds/leds{1,2,3,4,...} Oct 01 07:07:50 dunno... Oct 01 07:07:58 ok, the interface is not additive now Oct 01 07:08:20 how does that look (visually) compared to before? Oct 01 07:09:24 I have yet to compile :) Oct 01 07:10:26 wait... cpu/timer .. tell me again how do you want them, wrt my latest patch Oct 01 07:10:50 BTW, the CONFIG_CMDLINE in the defconfig patch should probably load initrd from flash ... Oct 01 07:11:23 rwhitby: yep.. that is a personal configuration of mine.. I use no initrd Oct 01 07:12:09 So normally (when things are running), the led is green. When the machine is idle, the led is black. When the timer goes off, the led goes red (or maybe amber - not sure which will make more sense). Oct 01 07:13:08 or maybe the timer inverts the current state of the led (wrt green and black) Oct 01 07:14:16 * dwery confused Oct 01 07:15:01 led_idle_start: turn off red and green Oct 01 07:15:14 led_idle_end: turn off red, turn on green. Oct 01 07:15:48 led_timer: take current state of led, turn off red, toggle green. Oct 01 07:16:09 thanks :-D Oct 01 07:16:26 or alternatively: led_timer: turn on red, turn off green. Oct 01 07:16:39 or alternatively: led_timer: turn on red, turn on green. Oct 01 07:17:23 I don't know which of those three alternatives will look best, and will be not confused with one of the other init startup colour sequences done by the init scripts Oct 01 07:17:33 Hi Oct 01 07:17:41 stripwax: nice work on the wiki pages Oct 01 07:18:00 rwhiby - thanks! Could someone approve the external links on that page please? Oct 01 07:18:23 which page again? Oct 01 07:18:26 http://www.nslu2-linux.org/wiki/HowTo/BuildMpd Oct 01 07:19:22 done Oct 01 07:19:26 brill! Oct 01 07:19:45 is it linked onto the main howto page? Oct 01 07:20:22 pretty sure it's linked from SlugAsAudioPlayer Oct 01 07:20:28 cool Oct 01 07:21:08 I'll see if I can get build mpd and libao as ipkg..# Oct 01 07:21:21 s/get// Oct 01 07:21:25 rwhitby: led_timer nees to toggle, otherwise you would not notice anything with cpu idle Oct 01 07:23:41 is there a relationship between the timing/ Oct 01 07:23:43 ? Oct 01 07:24:50 i'll try toggling green.. that way you'll have a constant rate with cpu idle and a more flickering rate when not idle Oct 01 07:27:40 right - that seems to be what leds-lart is doing Oct 01 07:29:33 compiling... Oct 01 07:33:47 it seems to be in a disco but it works :) Oct 01 07:34:36 what happens when the slug is idle/ Oct 01 07:34:39 ? Oct 01 07:34:51 bloody shift key .... Oct 01 07:34:56 quasi-steady blinking Oct 01 07:35:09 blinking green Oct 01 07:35:19 yes Oct 01 07:35:30 i would like to try to not turn the green of in idle_start Oct 01 07:35:32 and then what happens when the slug is loaded? Oct 01 07:36:01 a flickering like and hard disk light Oct 01 07:36:06 s/and/an/ Oct 01 07:36:49 still just flickering green, right? no other colours. Oct 01 07:37:00 yes Oct 01 07:37:57 what do you expect by not turning off the green in idle_start? Oct 01 07:38:44 is it right that I need openslug if I want to setup a VPN server? can't use unslung? something to do with TUN/TAP Oct 01 07:38:45 a more steady rate when idle Oct 01 07:38:51 and less flicker when busy Oct 01 07:38:53 seems fine Oct 01 07:38:56 i've just tested it Oct 01 07:39:09 jelle: openvpn works on both unslung and openslug Oct 01 07:39:18 dwery: so you're happy with the result? Oct 01 07:39:20 the tun.o kernel module is in both feeds Oct 01 07:39:43 rwhitby: yeah, seems comparable with the requirements Oct 01 07:39:52 * NAiL panics Oct 01 07:39:57 but i liked the red led more :-D Oct 01 07:39:57 dwery: but is it useful? Oct 01 07:40:09 *both* my slugs seem to have stopped booting all of a sudden Oct 01 07:40:14 yes, you have a clear indication of the idleness state of the slug Oct 01 07:40:22 I installed the kernel-module-tun, openssl, openvpn, and set up a vpn thing. now it says: Cannot open TUN/TAP dev /dev/net/tun: No such dev Oct 01 07:40:26 dwery: what did the red led do? Oct 01 07:40:38 I used red for cpu and green for timer Oct 01 07:40:43 jelle: you gotta load the module. do "lsmod" and see if "tun" is loaded Oct 01 07:40:56 jelle: did you create the device file ? Oct 01 07:40:57 nope, it's not. Oct 01 07:41:22 rwhitby: I think it's more user friendly now Oct 01 07:41:23 i did a mkdir /dev/net and mknod /dev/net/tun c 10 200 Oct 01 07:41:24 jelle: modprobe tun Oct 01 07:41:27 dwery: you used red and green on the ready/status led ? or two separate leds? Oct 01 07:41:43 rwhitby: separate. Oct 01 07:41:52 "modprobe: could not parse module s.deb" Oct 01 07:42:18 dwery: the way it is now resembles the old sun workstations.. cool :) Oct 01 07:42:50 dwery: so now we have freed up the solid green state for something else :-) Oct 01 07:42:56 -:D Oct 01 07:42:59 :-D Oct 01 07:43:37 I think solid green, actually, means your CPU is unbeliveably busy and your timers are f.. up :-D Oct 01 07:44:30 dwery: is it any more useful if the timer toggling is turned off? Oct 01 07:44:58 you would end with the led of most of the time... not user friend i think Oct 01 07:45:12 if yopu want to turn off the timer Oct 01 07:45:29 then the green shpuld be on when idle imho Oct 01 07:46:03 a couple of ifdef would do that Oct 01 07:46:32 should we invert the meaning of green and off for the cpu status? Oct 01 07:46:52 ah... insmod tun... Oct 01 07:46:58 rwhitby: let me try and see Oct 01 07:49:07 Hmm - I think idle as off makes more sense, cause you have the power led (and other leds) to tell that the box is still on. But it's worth looking at, cause it might be counter-intuitive. Oct 01 07:51:04 it's almost comparable Oct 01 07:52:18 I would leave it with idle = on plus and ifdef to turn it off when the timer is not enabled in the .config Oct 01 07:54:24 why does idle=on look better? Oct 01 07:54:38 (compared to idle=off) Oct 01 07:55:54 they're almost the same.. Oct 01 07:56:59 so why are you tending towards idle=on ? Oct 01 07:57:21 because it would require one less ifdef to give the lead a meaning if LEDS_TIMER is not enabled Oct 01 07:58:01 or are you saying "idle = do nothing" when LEDS_TIMER is enable, and "idle=turn off" when LEDS_TIMER is not enabled ? Oct 01 07:59:30 timer on: idle_start = green on, idle_end = do nothing; timer off: idle_start = green on, idle_end = green off Oct 01 08:00:08 but why is that better than: Oct 01 08:00:42 timer on: idle_start = do nothing, idle_end = green on; timer off: idle_start = green off, idle_end = green on Oct 01 08:00:43 ? Oct 01 08:01:09 cause just like disk activity, I think most people equate idle with led off. Oct 01 08:01:44 because you'll end with a led that is called ready/status which would be off most of the time Oct 01 08:01:54 now a led off doesn't make me think the thing is ready Oct 01 08:02:00 especiallyif it's a green one Oct 01 08:02:12 ok, that's a good point. Oct 01 08:03:05 so as the slug gets more heavily loaded, the ready status light is off more often than it is on. Oct 01 08:04:01 let me try.. do you have a quick way to load it? Oct 01 08:05:34 cat /dev/zero > /dev/null ? Oct 01 08:06:25 nope :( Oct 01 08:06:38 monotone update ? Oct 01 08:07:01 md5sum < /dev/urandom ? Oct 01 08:07:19 cat /dev/zero|gzip -|gunzip ->/dev/null Oct 01 08:08:04 that gives ~100% cpu usage Oct 01 08:09:12 yep. and the led doesn't react as expected. let me try to revert the last change Oct 01 08:10:20 grrr Oct 01 08:10:32 * NAiL notes that hwclock from util-linux *still* breaks Oct 01 08:11:20 dwery: so the colour sequencer higher-level interface could just send led events over to the low-level interface, right ? Oct 01 08:11:29 rwhitby: yes Oct 01 08:11:33 NAiL: explain... Oct 01 08:12:15 dwery: hwclock hangs the slug Oct 01 08:12:22 so it doesn't finish booting Oct 01 08:12:48 dwery: so the existing IOCTL interface could remain (during the transition period), and a new improved colour sequencer interface added by jbowler ? Oct 01 08:13:06 03repvik * r212 10/releases/OpenSlug-2.7-beta/openembedded/packages/util-linux/util-linux.inc: Change hwclock u-a priority to lower than busybox's hwclock. Fixes hang-on-boot Oct 01 08:13:24 NAiL: my hwclock works fine... maybe a different one? Oct 01 08:13:43 dwery: yes, you use busybox hwclock Oct 01 08:13:44 rwhitby: it could remain but you can't have both of them active at the same time Oct 01 08:13:44 03repvik * r213 10/releases/OpenSlug-2.7-beta/openembedded/packages/util-linux/util-linux_2.12q.bb: Bump PR Oct 01 08:13:53 util-linux hwclock is not working for some reason Oct 01 08:14:08 dwery: the IOCTL one could send led events too .... Oct 01 08:14:58 rwhitby: you meen keep the current ioctl to send events to the arm-wide? Oct 01 08:15:06 yeah Oct 01 08:15:35 then all three interfaces can be active at the same time :-) Oct 01 08:15:45 and the events just come in some order ... Oct 01 08:17:58 dwery: should the rtc patch be separated out from the other stuff in nslu2-general.patch ? (since it will be going to a different upstream maintainer, right?) Oct 01 08:18:33 oh, sorry, you've already got the x1205 patch separate. Oct 01 08:20:05 ~lart monotone Oct 01 08:20:05 * jbot slaps monotone upside and over the head with one freakishly huge killer whale named hugh Oct 01 08:23:17 dwery: for the panic change to solid red, there is a panic_notifier_list on which you can register something in the nslu2-leds.c file Oct 01 08:23:34 nice! Oct 01 08:23:37 i'll do Oct 01 08:24:10 cool Oct 01 08:24:42 dwery: I just had an idea. Oct 01 08:26:14 actually, that's not gonna work. I was about to suggest we use red and green for ready/status, and then use amber and blue for the two disk leds. But then we have no way to synchronise turning ready/status to amber. Oct 01 08:26:25 "blue"? Oct 01 08:26:41 it's a value in led_event_t Oct 01 08:26:57 aha Oct 01 08:27:17 I'm looking for a way that we can do everything through deepak (ixp4xx) instead of having to go direct to arm kernel maintainers Oct 01 08:27:36 yeah Oct 01 08:27:51 (e.g. opt1 and opt2 affects more than just nslu2 stuff. Oct 01 08:28:44 rwhitby: ack Oct 01 08:29:18 but it's the best we can do at the moment. and it does allow us to have a common low-level interface Oct 01 08:29:20 ~lart monotone Oct 01 08:29:20 * jbot strangles monotone with a 9-pole serial cable Oct 01 08:29:34 ok, I'm done for the night Oct 01 08:29:45 nite Oct 01 08:29:58 ~emulate rwhitby Oct 01 08:29:59 Another Satisfied Customer! Oct 01 08:30:04 Doh! Oct 01 08:30:10 ~emulate rwhitby Oct 01 08:30:12 Well, my work here is done. Oct 01 08:30:23 rwhitby-asleep: bye Oct 01 08:30:44 dwery: thanks for the collaboration. Do you think we got a good result? Oct 01 08:30:50 yep Oct 01 08:31:03 but still have to try on the bust slug :) Oct 01 08:31:08 thnk you too Oct 01 08:31:12 03nail 07org.openembedded.dev * rd712046f... 10/packages/udev/ (files/init udev_070.bb): Oct 01 08:31:12 udev: Make sure we're using busybox's mount when moving .static mount. Oct 01 08:31:12 (busybox mount uses "-o move" vs. util-linux mount "--move") Oct 01 08:31:21 03nail 07org.openembedded.dev * r3af749f4... 10/conf/distro/openslug.conf: Re-add udev to the firmware image. The change appears to have been lost somewhere Oct 01 08:38:27 dwery: I think we need to add a separate /sys and event queue for each of the disk leds, cause we might want to claim and release them individually. Oct 01 08:38:47 quite possible Oct 01 08:38:51 then we don't need opt1 and opt2 any more too :-) Oct 01 08:38:58 :) Oct 01 08:41:04 03nail 07org.openembedded.dev * rf8b587c0... 10/packages/util-linux/ (util-linux.inc util-linux_2.12q.bb): util-linux: change hwclock u-a prio to be lower than busybox Oct 01 08:41:11 Hmm - currently only one leds_event function call. Oct 01 08:41:27 .. function call interface. Oct 01 08:44:53 dwery: I would suggest leaving out opt1 and opt2 until we sort out how to handle multiple leds properly. Oct 01 08:45:01 rwhitby-asleep: ok Oct 01 08:52:27 * rwhitby-asleep goes to bed Oct 01 08:55:43 mm.. w've got a problem Oct 01 08:55:52 when cpu is in use bye a single task Oct 01 08:56:07 idle_start and idle_stop are called just once Oct 01 08:56:13 so there's no flickering on the led Oct 01 09:06:05 well.. i could set the module to have a slower blinking when idle and a faster one when busy Oct 01 09:18:20 it doesn't look good :( Oct 01 09:49:28 hurray, i got openvpn working. Oct 01 09:50:15 congrats ;) Oct 01 09:50:21 does the selftest work? Oct 01 09:50:32 vg jelle Oct 01 09:50:58 I can connect trough my lan onto my slug and open directories on that fileserver. Oct 01 09:51:04 03jbowler 07org.openembedded.dev * r27d97f68... 10/packages/ixp4xx/ (ixp-osal_1.5.bb ixp4xx-csr_1.5.bb): Oct 01 09:51:04 ixp4xx: corrected licenses and dependencies Oct 01 09:51:04 It is necessary to download the .zip files from Intel by hand before Oct 01 09:51:04 building this package. Oct 01 09:51:41 but I had to advance my clock on the client one day. The certificate I generated is valid starting tomorrow.... ??? Strange thing. Oct 01 09:51:44 jelle, did you learn something that should be added to the wiki? (http://www.nslu2-linux.org/wiki/HowTo/SetUpOpenVPNServer) Oct 01 09:51:58 jelle: openvpn --help .. there's a crypto self-test there... see if that works Oct 01 09:53:23 checking .... Oct 01 09:53:53 --test-crypto Oct 01 09:54:08 there were some problems with the selftest failing a while back Oct 01 09:56:04 03justinp 07org.openembedded.dev * r16e005d2... 10/packages/ (5 files in 2 dirs): efl, e17: use cvs:// instead of viewcvs for SRC_URI Oct 01 09:58:32 OpenVPN crypto self-test mode SUCCEEDED. Oct 01 09:58:42 good :) Oct 01 10:02:36 well, I didn't do the ipkg -force-depends install openvpn, so I had to do an install on kernel-module-tun, openssl and openvpn. Oct 01 10:05:51 eFfeM: I read the wiki page, sounds fine, but how did you find it? I see no references to it from the main howto page. Maybe it's my blind spot... Oct 01 10:14:46 jelle, type openvpn in the search field Oct 01 10:14:57 can someone with write access to the howto page fix this? Oct 01 10:15:10 would be nice. Oct 01 10:15:45 mmkay Oct 01 10:15:46 If we don't get a reaction here, I'll send a yahoogroupmessage. Oct 01 10:16:00 seems good Oct 01 10:16:10 anyone any knowledge on nfs? Oct 01 10:16:26 thanks NAiL, I think it would have helped me some. But struggling myself was a lot of fun too Oct 01 10:16:32 done Oct 01 10:17:09 my only knowledge of nfs was a carton box that I kicked to pieces a few years ago out of frustration... no help from this side. Oct 01 10:17:53 i find it more convenient and faster than samba, but can't get it to run on .14 Oct 01 10:17:53 what is this routing that I should do? where will it help me? Oct 01 10:31:11 03koen 07org.openembedded.dev * r66b8d8c4... 10/conf/machine/h2200.conf: conf/machine/h2200.conf: add machine config for the iPAQ h22xx since it uses different jffs2 params as h3900.conf Oct 01 11:31:31 dwery-away, i'm now on 2.6.14 with your x1205 code, but the driver does not seem to find the device Oct 01 11:33:32 d Oct 01 11:33:42 /sys/bus/i2c/devices is empty, /sys/bus/i2c/drivers contains x1205 together with i2c_adapter, eeprom and device_driver Oct 01 11:33:42 hi, how do I create /dev/snd? Oct 01 11:33:51 mknod Oct 01 11:34:22 are there any numbers behind mknod? Oct 01 11:34:43 yes, major & minor no Oct 01 11:35:03 how do I know which numbers I need? Oct 01 11:35:18 depends on what you actually loaded. Oct 01 11:35:25 my slug does not have /dev/snd Oct 01 11:35:37 but my fedora system has /dev/snd as a directory with a number of devices Oct 01 11:35:52 crw------- 1 slug root 116, 0 Oct 1 11:02 controlC0 Oct 01 11:35:52 crw------- 1 slug root 116, 32 Oct 1 11:02 controlC1 Oct 01 11:35:52 crw------- 1 slug root 116, 24 Oct 1 11:02 pcmC0D0c Oct 01 11:35:52 crw------- 1 slug root 116, 16 Oct 1 11:02 pcmC0D0p Oct 01 11:35:52 crw------- 1 slug root 116, 25 Oct 1 11:02 pcmC0D1c Oct 01 11:35:52 crw------- 1 slug root 116, 26 Oct 1 11:02 pcmC0D2c Oct 01 11:35:54 crw------- 1 slug root 116, 27 Oct 1 11:02 pcmC0D3c Oct 01 11:35:56 crw------- 1 slug root 116, 20 Oct 1 11:02 pcmC0D4p Oct 01 11:35:58 crw------- 1 slug root 116, 56 Oct 1 11:02 pcmC1D0c Oct 01 11:36:00 crw------- 1 slug root 116, 33 Oct 1 11:02 timer Oct 01 11:36:04 so mkdir /dev/snd;cd /dev/snd Oct 01 11:36:14 mknod controlC0 c 116 0 Oct 01 11:36:14 etc Oct 01 11:37:11 I am installing soundcore and audio-modules together with an mp3-tool, but when I start this tool it alerts me with missing /dev/snd Oct 01 11:37:23 and its missing on my unslung Oct 01 11:37:33 try the above. otherwise revert to doc or google Oct 01 11:37:41 ok thx Oct 01 12:17:40 dyoung-zzzz, I found why the wintv pvr usb code is crashing. There is an issue in the 2.6.12 x1205 driver that can cause this. I moved to 2.6.14, but there tveeprom.h has been changed, so I could not really get it running Oct 01 13:05:11 wee, the npe is working on debian LE Oct 01 14:16:23 <[g2]> Jacmet hey congrats ! Oct 01 14:16:50 <[g2]> which version 1.5 or 2.0 ? Oct 01 14:17:24 <[g2]> eFfeM, congrats on the pvr crash issue Oct 01 14:17:40 <[g2]> what exactly about the x1205 causes the crash ? Oct 01 14:17:50 <[g2]> and why don't you just build the nslu2 kernel without it Oct 01 14:17:59 <[g2]> and get a time update with ntp or ntpdate Oct 01 15:23:43 simple question: my init.d/S24openvpn seems to not start automatically after reboot, can I check logfiles if anything gets started in init.d? Oct 01 15:23:55 I know, it is basic linux... Oct 01 15:25:48 add a line like echo "bla" > /tmp/myfile to S24openvpn Oct 01 15:27:49 did you make it ugo+x ? Oct 01 15:28:49 hm... good question... Oct 01 15:29:43 and, whats happen if you excute S24openvpn via commandline? Oct 01 15:29:58 that works... Oct 01 15:30:13 ok, I forgot to chmod+x it... Oct 01 15:30:25 testing reboot now. Oct 01 15:31:54 there is some discussion on the speed of samba and things like errors appearing in log files. what log files can I check to see if ethernet / samba are doing fine? Oct 01 15:32:40 Reboot! VPN and mythttp started fine now! thanks. Oct 01 15:39:21 np - make sure you update the wiki so others can emulate your success! Oct 01 15:41:42 does anyone know how to fix the saslpasswd2 : generic failure problem with the 2.7-beta feed of openslug? Oct 01 15:41:48 I did... :) Oct 01 15:41:58 jelle: thx Oct 01 15:52:34 also added the chmod +x note in the thttpd wiki. Oct 01 15:58:29 hm, I'd like to make a slug-kernel ebuild for gentoo/armeb.. guess I can pull the sources from monotone somehow? Oct 01 16:03:29 what are you building on? Oct 01 16:04:13 can you use the MasterMakefile? Oct 01 16:09:39 building nslu2 :) Oct 01 16:10:25 building on.. Oct 01 16:11:10 native building? cool Oct 01 16:11:56 sure.. :) Oct 01 16:12:17 I prefer to keep my systems "self sustained" :) Oct 01 16:14:19 Comments on the new nslu2-linux logo at http://www.nslu2-linux.org ? (you may need to reload a couple of times to get it) Oct 01 16:16:47 hehe.. the "slug"? Oct 01 16:17:36 yep Oct 01 16:18:32 nice :) Oct 01 16:21:10 very nice. I saw a note somewhere that this might be the one. it is good. Oct 01 16:21:40 kolla, doesn't the build take forever on a slug? Oct 01 16:22:08 I build on colinux within windows. Oct 01 16:24:56 nah.. it's ok Oct 01 16:25:05 I'm never in a rush :) Oct 01 16:26:00 only bigger stuff takes time.. glibc in particular Oct 01 16:26:36 but with USE="userlocales" it also isnt that tedious Oct 01 16:26:57 not like I install X11 on it anyhow :) Oct 01 16:30:24 I'll put tother a gentoo how-to on the wiki soon, I just need to prepare a stage1, but I got some issues with catalyst I need to figure out Oct 01 16:31:09 once the stage1 is done, I have a second slug I'll use as "test bed" for the installation, and make notes as I move along :) Oct 01 16:36:00 sounds good! do your thing... Oct 01 16:36:31 I'm off to bed now. We'll talk later again, thanks for the help Oct 01 17:29:08 hm, I wonder if anyone ever tried to add more ram to the wl-hdd Oct 01 17:29:18 16MB is just a tad too little :| Oct 01 22:18:44 have somebody build ncurses successfully? Oct 02 00:08:00 got it Oct 02 00:08:38 I think an lcd display on the nslu2 should now work Oct 02 00:16:39 jbot, test Oct 02 00:16:41 Test Passed! Oct 02 01:00:04 conradl: what type of drive do you have in the ds101 ? Oct 02 01:10:27 jbot, test Oct 02 01:10:28 Test Failed! Oct 02 02:22:11 how do i tell my unslung slug to be a dns? Oct 02 02:25:31 jelle-brb: ipkg install dnsmasq? Oct 02 02:26:38 i'll lookint that, thanks. Oct 02 02:27:23 won't this class with the vpn part? or is it already in vpn? Oct 02 02:28:20 why should it? Oct 02 02:29:41 maybe the vpn server was already doing dhcp for the clients, but I guess not. Oct 02 02:30:47 the dhcpd stuff in dnsmasq is optional... Oct 02 02:58:24 rignt. **** ENDING LOGGING AT Sun Oct 02 02:59:56 2005