#qi-hardware IRC log for Wednesday, 2011-08-31

--- Wed Aug 31 201100:00
qi-botThe build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08302011-1326/01:26
kyakjow_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?05:13
bartbesso did anyone ever get the image to run in qemu?10:25
jow_laptopkyak: up until now I didn't think anything at all :) So the problem is the api change?11:05
viricis anyone here good at hanging the linux in the nanote?13:33
viricor it's something you find hard to do?13:34
alcyhanging ? 13:44
viricyes. hang the system13:45
alcyheh. 13:45
viricI've a weird problem with a sheevaplug13:59
viricI think that 'tmpfs' don't cope well with the OOM killer13:59
viricif 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.13:59
viric(I talk about the case of no swap)13:59
viricI can reproduce the issue easily. The kernel stops working.14:00
C-Keenviric: check if you have configured the correct amount of RAM?14:03
viricyes. 512MiB14:04
viricI think that if I disable tmpfs, I'll have no trouble14:07
viricBut now I think there is some race between tmpfs and the oom killer.14:07
viricthe oom killer all the time hits fine the process it should kill14:07
viricand 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 kenrel14:08
kyakjow_laptop: yeah, the problem is the api change16:09
qi-botThe build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08312011-0427/16:23
Jay7viric: there was known OOM on Zauruses with udev16:54
Jay7may be you hit this too16:54
viricJay7: how did it go?20:28
viricJay7: 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. :)20:28
Jay7viric: I don't know details20:31
Jay7iirc, it was fixed in other version or something like20:31
viricdoes the nanonote linux stand fine processes taking lots of ram?20:32
qi-bot[commit] Werner Almesberger: cngt/cngt.c (do_key): merge common x/y positioning code (master) http://qi-hw.com/p/cae-tools/daa355420:54
qi-bot[commit] Werner Almesberger: cameo/templates/mkmk-simple: added optional BOARD_Z parameter for board thickness (master) http://qi-hw.com/p/cae-tools/679505720:54
qi-bot[commit] Werner Almesberger: cngt/cngt.c: added positioning-only mode (master) http://qi-hw.com/p/cae-tools/eb8964d20:54
qi-bot[commit] Werner Almesberger: cngt/cngt.c: added small steps (default) and long steps (with shift) (master) http://qi-hw.com/p/cae-tools/639d9a220:54
lekernelwpwrak, 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 ?21:24
lekernel(and if Murphy is there, a capacitor to absorb voltage spikes due to the parasitic capacitance of the protection diode... kidding ;-)21:25
wpwraklekernel: hmm, the series diode would add its own Vf, raising the minimum input voltage at which the whole thing can operate21:41
wpwraklekernel: 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 ;-)21:42
lekerneluse those icouplers you mentioned, then21:44
wpwrakyeah, 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.21:47
wpwrak(you can second-source some that don't carry power, though. but then you need an independent supply on the secondary side)21:48
DocScrutinizerwtf now you consider specialized optocouplers, but you don't like a solution with a rather standard MAXIM chip plus a (FET-)transistor22:11
wpwraki think you missed the irony ;-)22:18
DocScrutinizer+-50V isolation, 2 inputs22:24
DocScrutinizerhttp://www.clare.com/home/pdfs.nsf/www/AN-107.pdf/$file/AN-107.pdf p.322:47
DocScrutinizerbut yeah that needs an isolated Vcc22:48
DocScrutinizerwpwrak: I missed if you need separate isolated GND for each input as well?23:05
wpwrakyeah, no common ground23:06
wpwrakif you want common ground, connect it outside :)23:06
wpwrakwhy "ough" ? an optocoupler handles this just fine, no ?23:07
DocScrutinizerso you want to connect the N inputs to N devices that all have different GND levels?23:07
wpwraki want to connect to up to 4 devices about whose ground levels i know nothing23:07
DocScrutinizerand those 4 devices all are not prepared to drive a proper signal output for that purpose23:08
DocScrutinizerI really don't get it23:09
wpwrakit may not be an "output" to them. i may just connect somewhere into the circuit.23:09
wpwrakand 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-up23:10
wpwrakgrmbl. my first try at milling the board went amazingly well, considering that i forgot to tighten the screws holding the board in place23:11
wpwrakit only became airborne once the mill tried to cut the outline ...23:12
wpwrak(which the machine detected even without decapitating the endmill, quite nice)23:14
--- Thu Sep 1 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!