| --- Wed Aug 31 2011 | 00:00 | |
| qi-bot | The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08302011-1326/ | 01:26 |
|---|---|---|
| kyak | 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? | 05:13 |
| bartbes | so did anyone ever get the image to run in qemu? | 10:25 |
| jow_laptop | kyak: up until now I didn't think anything at all :) So the problem is the api change? | 11:05 |
| viric | is anyone here good at hanging the linux in the nanote? | 13:33 |
| viric | or it's something you find hard to do? | 13:34 |
| alcy | hanging ? | 13:44 |
| viric | :) | 13:45 |
| viric | yes. hang the system | 13:45 |
| alcy | heh. | 13:45 |
| viric | I've a weird problem with a sheevaplug | 13:59 |
| viric | I think that 'tmpfs' don't cope well with the OOM killer | 13:59 |
| viric | 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. | 13:59 |
| viric | (I talk about the case of no swap) | 13:59 |
| viric | I can reproduce the issue easily. The kernel stops working. | 14:00 |
| C-Keen | viric: check if you have configured the correct amount of RAM? | 14:03 |
| viric | yes. 512MiB | 14:04 |
| viric | I think that if I disable tmpfs, I'll have no trouble | 14:07 |
| viric | But now I think there is some race between tmpfs and the oom killer. | 14:07 |
| viric | the oom killer all the time hits fine the process it should kill | 14:07 |
| viric | 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 | 14:08 |
| kyak | jow_laptop: yeah, the problem is the api change | 16:09 |
| qi-bot | The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08312011-0427/ | 16:23 |
| Jay7 | viric: there was known OOM on Zauruses with udev | 16:54 |
| Jay7 | may be you hit this too | 16:54 |
| viric | Jay7: how did it go? | 20:28 |
| viric | 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. :) | 20:28 |
| Jay7 | viric: I don't know details | 20:31 |
| Jay7 | iirc, it was fixed in other version or something like | 20:31 |
| viric | does 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/daa3554 | 20: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/6795057 | 20:54 |
| qi-bot | [commit] Werner Almesberger: cngt/cngt.c: added positioning-only mode (master) http://qi-hw.com/p/cae-tools/eb8964d | 20: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/639d9a2 | 20:54 |
| lekernel | 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 ? | 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 |
| wpwrak | lekernel: hmm, the series diode would add its own Vf, raising the minimum input voltage at which the whole thing can operate | 21:41 |
| wpwrak | 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 ;-) | 21:42 |
| lekernel | use those icouplers you mentioned, then | 21:44 |
| wpwrak | 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. | 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 |
| DocScrutinizer | wtf now you consider specialized optocouplers, but you don't like a solution with a rather standard MAXIM chip plus a (FET-)transistor | 22:11 |
| DocScrutinizer | ? | 22:11 |
| wpwrak | i think you missed the irony ;-) | 22:18 |
| DocScrutinizer | maybe | 22:23 |
| DocScrutinizer | http://www.maxim-ic.com/datasheet/index.mvp/id/3368 | 22:24 |
| DocScrutinizer | +-50V isolation, 2 inputs | 22:24 |
| DocScrutinizer | http://www.maxim-ic.com/pst/run.mvp?q=isolated&image.x=0&image.y=0&image=submit | 22:29 |
| DocScrutinizer | http://www.clare.com/home/pdfs.nsf/www/AN-107.pdf/$file/AN-107.pdf p.3 | 22:47 |
| DocScrutinizer | but yeah that needs an isolated Vcc | 22:48 |
| DocScrutinizer | wpwrak: I missed if you need separate isolated GND for each input as well? | 23:05 |
| wpwrak | yeah, no common ground | 23:06 |
| DocScrutinizer | ouch | 23:06 |
| wpwrak | if you want common ground, connect it outside :) | 23:06 |
| wpwrak | why "ough" ? an optocoupler handles this just fine, no ? | 23:07 |
| DocScrutinizer | so you want to connect the N inputs to N devices that all have different GND levels? | 23:07 |
| wpwrak | i want to connect to up to 4 devices about whose ground levels i know nothing | 23:07 |
| DocScrutinizer | :-S | 23:08 |
| DocScrutinizer | and those 4 devices all are not prepared to drive a proper signal output for that purpose | 23:08 |
| DocScrutinizer | I really don't get it | 23:09 |
| wpwrak | it may not be an "output" to them. i may just connect somewhere into the circuit. | 23:09 |
| wpwrak | 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 | 23:10 |
| wpwrak | grmbl. my first try at milling the board went amazingly well, considering that i forgot to tighten the screws holding the board in place | 23:11 |
| wpwrak | it 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 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!