2011-08-31 01:26 The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08302011-1326/ 2011-08-31 05:13 jow_laptop: what do you think about the ffmpeg update? Will it be reverted or we must live with it and adapt/throw away other packages? 2011-08-31 10:25 so did anyone ever get the image to run in qemu? 2011-08-31 11:05 kyak: up until now I didn't think anything at all :) So the problem is the api change? 2011-08-31 13:33 is anyone here good at hanging the linux in the nanote? 2011-08-31 13:34 or it's something you find hard to do? 2011-08-31 13:44 hanging ? 2011-08-31 13:45 :) 2011-08-31 13:45 yes. hang the system 2011-08-31 13:45 heh. 2011-08-31 13:59 I've a weird problem with a sheevaplug 2011-08-31 13:59 I think that 'tmpfs' don't cope well with the OOM killer 2011-08-31 13:59 if you manage to be writing small things often to a tmpfs, and at the same time you have a OOM killer situation, it will hang. 2011-08-31 13:59 (I talk about the case of no swap) 2011-08-31 14:00 I can reproduce the issue easily. The kernel stops working. 2011-08-31 14:03 viric: check if you have configured the correct amount of RAM? 2011-08-31 14:04 yes. 512MiB 2011-08-31 14:07 I think that if I disable tmpfs, I'll have no trouble 2011-08-31 14:07 But now I think there is some race between tmpfs and the oom killer. 2011-08-31 14:07 the oom killer all the time hits fine the process it should kill 2011-08-31 14:08 and sometimes the system keeps on running fine... and suddenly, just at one oom kill, the kernel kill report is the last thing you can expect from that kenrel 2011-08-31 16:09 jow_laptop: yeah, the problem is the api change 2011-08-31 16:23 The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08312011-0427/ 2011-08-31 16:54 viric: there was known OOM on Zauruses with udev 2011-08-31 16:54 may be you hit this too 2011-08-31 20:28 Jay7: how did it go? 2011-08-31 20:28 Jay7: I know the process that takes lots of RAM. I want linux to kill it - that's what I expect. I don't want linux to hang. :) 2011-08-31 20:31 viric: I don't know details 2011-08-31 20:31 iirc, it was fixed in other version or something like 2011-08-31 20:32 does the nanonote linux stand fine processes taking lots of ram? 2011-08-31 20:54 [commit] Werner Almesberger: cngt/cngt.c (do_key): merge common x/y positioning code (master) http://qi-hw.com/p/cae-tools/daa3554 2011-08-31 20:54 [commit] Werner Almesberger: cameo/templates/mkmk-simple: added optional BOARD_Z parameter for board thickness (master) http://qi-hw.com/p/cae-tools/6795057 2011-08-31 20:54 [commit] Werner Almesberger: cngt/cngt.c: added positioning-only mode (master) http://qi-hw.com/p/cae-tools/eb8964d 2011-08-31 20:54 [commit] Werner Almesberger: cngt/cngt.c: added small steps (default) and long steps (with shift) (master) http://qi-hw.com/p/cae-tools/639d9a2 2011-08-31 21:24 wpwrak, for your optocoupler thing, what about 1) putting a forward diode in series 2) having a resistor connected in parallel to to optocoupler diode so the protection diode takes all the voltage when the polarity is reversed ? 2011-08-31 21:25 (and if Murphy is there, a capacitor to absorb voltage spikes due to the parasitic capacitance of the protection diode... kidding ;-) 2011-08-31 21:41 lekernel: hmm, the series diode would add its own Vf, raising the minimum input voltage at which the whole thing can operate 2011-08-31 21:42 lekernel: i.e., i'd like to be able to handle 1.8 V systems. that's kinda the next step after 3.3 V. future-proofing ;-) 2011-08-31 21:44 use those icouplers you mentioned, then 2011-08-31 21:47 yeah, with them it would be easy ;-) but they're rare birds. e.g., there doesn't even seem to be a second source for functionally similar parts. guess we just have to sit out these 20 years until the technology becomes safe to use. 2011-08-31 21:48 (you can second-source some that don't carry power, though. but then you need an independent supply on the secondary side) 2011-08-31 22:11 wtf now you consider specialized optocouplers, but you don't like a solution with a rather standard MAXIM chip plus a (FET-)transistor 2011-08-31 22:11 ? 2011-08-31 22:18 i think you missed the irony ;-) 2011-08-31 22:23 maybe 2011-08-31 22:24 http://www.maxim-ic.com/datasheet/index.mvp/id/3368 2011-08-31 22:24 +-50V isolation, 2 inputs 2011-08-31 22:29 http://www.maxim-ic.com/pst/run.mvp?q=isolated&image.x=0&image.y=0&image=submit 2011-08-31 22:47 http://www.clare.com/home/pdfs.nsf/www/AN-107.pdf/$file/AN-107.pdf p.3 2011-08-31 22:48 but yeah that needs an isolated Vcc 2011-08-31 23:05 wpwrak: I missed if you need separate isolated GND for each input as well? 2011-08-31 23:06 yeah, no common ground 2011-08-31 23:06 ouch 2011-08-31 23:06 if you want common ground, connect it outside :) 2011-08-31 23:07 why "ough" ? an optocoupler handles this just fine, no ? 2011-08-31 23:07 so you want to connect the N inputs to N devices that all have different GND levels? 2011-08-31 23:07 i want to connect to up to 4 devices about whose ground levels i know nothing 2011-08-31 23:08 :-S 2011-08-31 23:08 and those 4 devices all are not prepared to drive a proper signal output for that purpose 2011-08-31 23:09 I really don't get it 2011-08-31 23:09 it may not be an "output" to them. i may just connect somewhere into the circuit. 2011-08-31 23:10 and yes, i realize that my approach has its limitations. e.g., i couldn't probe a line with a very weak drive, e.g., a pull-up 2011-08-31 23:11 grmbl. my first try at milling the board went amazingly well, considering that i forgot to tighten the screws holding the board in place 2011-08-31 23:12 it only became airborne once the mill tried to cut the outline ... 2011-08-31 23:14 (which the machine detected even without decapitating the endmill, quite nice)