Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<cladamw>
( rc3, 0x32 full pass ) After test, it finally passed with f/w existed earlier. Now yield reaches up to 80pcs. There's another four sets passed with latest f/w but crc/midi/phy id tests. So I think yield soon will go to 84 sets.
<cladamw>
( rc3, cases ) The _last_ case will be run out today. :-)
<cladamw>
xiangfu, just git pull autotest-m1 and make done. Did it include crc check already?
<xiangfu>
cladamw, no.
<cladamw>
xiangfu, so 54662a8e is not the final. Isn't it?
<xiangfu>
what '54662a8e'?
<cladamw>
checksum i think. "CRC32 (boot.bin): 54662a8e" after 'make'. Is it?
<xiangfu>
cladamw, every build the CRC (boot.bin) is different.
<xiangfu>
when you run this boot.bin the fist line will display which commit you using. and if there are code modify not commit.
<cladamw>
ah ~ so this number is commit # we're using not checksum. okay ... tks!
<xiangfu>
cladamw, it's like "*** Built: Dec 16 2011 at 10:34:43 (rev 50d40bb)"
<xiangfu>
build date and which commit you using.
<xiangfu>
if there are code modified. there are '+' at the end of 'rev'
<cladamw>
phew ~ I'm the last one to know the this. :-)
<cladamw>
xiangfu, btw~ if final image is done, let me know. Thanks a lot! :)
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<xiangfu>
the crc32 check in test boot.bin. only fault at standby.fpg.
<xiangfu>
works fine with other images.
<xiangfu>
cladamw, now we can know the image check only fault at standby.fpg.
<cladamw>
xiangfu, hmm. sounds bad. Well, I just finished assembling out last light blue case, no case more here. :-)
mumptai [mumptai!~calle@brmn-4d0ae712.pool.mediaWays.net] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<cladamw>
wpwrak, he :) not precisely confirmed if flux but almost and indeed that BTN2 level is neither full hi nor low, so fpga can be placed in unknown situation though to activate bootup or else. :-)
<wpwrak>
yes, button at weird levels could explain it. maybe the flux produced that "crosstalk" from flash signals.
<cladamw>
yeah... from clear evidences we just guessed likes in such way. Now surely BTN2 level is purely when pressing it. And heat air let flux under fpga to get well-protected on each ball.
<wpwrak>
remember that we once discussed an ultrasound bath, for cleaning such things ? did you ever go searching for one ?
<cladamw>
i remembered, Not get it yet.
<cladamw>
are you trying to say using ultrasound mechanism to decompose flux in the future?
<cladamw>
the idea of discussing to use ultrasound bath was to clean "bits and small pieces" after tearing off films while assembling m1 with case.
<wpwrak>
it should work very well for flux, too. particularly for the "water-soluble" kind
<wpwrak>
and even more so if the bath can be heated :)
<wpwrak>
when they did the rework at the factory, did they clean off the flux ?
<cladamw>
I guessed not.
<wpwrak>
they should be able to do better :)
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<cladamw>
that time they also heavily have load at that moment. Since I can see the board surface so that I can surely they didn't do clean that area of 'reset circuit'.
<cladamw>
oah ~ yes
<wpwrak>
xiangfu: i think you got caught by our NULL pointer checks ;-))
<xiangfu>
wpwrak, oh. added recently?
<wpwrak>
cladamw: heavy load is a poor excuse. cleaning off the flux should about as optional as using it in the first place ;-)
<cladamw>
in other words, this failure was caused by on my site own. and also the area is too nearby fpga. And unfortunately that area(BTN2 ball under fpga) is also nearby rework circuit. :-)
<wpwrak>
xiangfu: many weeks ago :)
<xiangfu>
wpwrak, I update the makefile a little. try to always follow the 80 rules. :)
<xiangfu>
wpwrak, hmm... where is the NULL pointer checks code?
<wpwrak>
xiangfu: (makefile) yes, i've seen it. very nice ! thanks !
<wpwrak>
xiangfu: in "hardware", the FPGA :)
<wpwrak>
xiangfu: the first ~512 kB should be "forbidden"
<xiangfu>
wpwrak, even read
<wpwrak>
segfault-on-read catches a LOT of problems :)
<xiangfu>
Scopeuk, Hi
<Scopeuk>
hi
<xiangfu>
you have saw the DMX fixture video. just double check. since you ask me about the DMX update. :)
<Scopeuk>
i havent no i missed it
<Scopeuk>
got the link?
<wpwrak>
cladamw: maybe they used "no clean" flux and thought that one really doesn't have to clean it. i've once made that mistake, too ;-)
<xiangfu>
wpwrak, what should I do? disable CRC check on standby.fpg temporary?
<cladamw>
wpwrak, the idea of ultrasound bath (or 'water-souble') is definitely my top job before rc4 to prepare/study.
<wpwrak>
cladamw: ultrasound should also work for other types of flux. also, you can use pretty much any liquid that doesn't explode or attack steel. so .. no strong acids and go easy on the nitroglycerine :) but demineralized/distilled water, alcohol, flux remover, etc., should be fine
<cladamw>
wpwrak, I would like to ask minbo or else manufacturers to know how they dealt with larger production if many bga chips on boards.
<wpwrak>
xiangfu: we (sebastien and some other folks) discussed having some kind of switch to turn the NULL pointer trap on, so it would be off by default and get enabled in the BIOS. not sure if this bit was implemented, though, or if the trap is permanent
<wpwrak>
xiangfu: so yes, for now, i'd just skip the standby check. if you get to the point of checking, you can be pretty certain that standby is okay anyway ;-)
<cladamw>
wpwrak, they must have smarter way to clean quickly includes bath with liquid.
<wpwrak>
cladamw: i've read of some baths with hot water under pressure. kinda like a dishwasher, but more intense. (and without the nasty chemicals you use in a dishwasher)
<cladamw>
wpwrak, under pressure?
<wpwrak>
cladamw: but ultrasound should also be popular. the good ones (designed for electronics) vary the frequency, so that you don't get resonances that could damage the chips
<wpwrak>
(pressure) water jets getting sprayed on the circuit. like in a dishwasher :)
<wpwrak>
(but don't try to use a dishwasher :)
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<cladamw>
wpwrak, oah~ thanks now understood your pressure words. :-) yeah... the frequency knowledge you taught me then.
<cladamw>
wpwrak, i think that i need to find other factory who "unlocked manufacturer knowledge".
<wpwrak>
none of this should be much of a secret :)
<Scopeuk>
looks good xiangfu
<cladamw>
wpwrak, i'm doing with the same way to another board. Good luck to me. :)
<wpwrak>
hehe, we have a yield problem now. it's too high ! ;-)
<cladamw>
wpwrak, hey... Did you check my 0x2f pre-rc4 board?
<cladamw>
that board was my _first_ during rc3 production. All through hole type of connectors I soldered not by reflow machine. So its bottom side is super ugly and also not clean. :)
<cladamw>
wpwrak, cause smt machine was still running, so diy.
Alarm [Alarm!~chatzilla@lp.gustaveferrie-176-74.cnt.nerim.net] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<GitHub175>
[autotest-m1] xiangfu pushed 3 new commits to master: http://git.io/B_lEMw
<GitHub175>
[autotest-m1/master] follow the 80 characters rule - Xiangfu Liu
<GitHub175>
[autotest-m1/master] Put the -lbase to the end, give error sometimes - Xiangfu Liu
<GitHub175>
[autotest-m1/master] Ignore CRC check on Standby.fpg, because the 'NULL pointer checks' under FPGA - Xiangfu Liu
<wpwrak>
(reading your rework) wow, it's even crazier than it looks ;-)
<cladamw>
oah ~ yeah...i glued it.
<wpwrak>
i need to un-crowd my bench a bit for a more serious analysis. i'll check that usb stuff next week, after the NOR torture
<cladamw>
alright...good luck...Measuring two VBUSs connections from AP4142A's pin7(OUT1 = usb -A port) and pin6(OUT2 = usb - B port) _before_ testing usb stuff. :-)
<wpwrak>
torture test is running
<wpwrak>
and USB works fine after i installed the ancient 2011-07-13
<wpwrak>
so maybe that was just some version mixup
<wpwrak>
(2011-07-13) i picked that old thing because of the known to be good test software, for image CRCs
<kristianpaul>
I think jon likes to drop some milkydrop effects between slidshows, so i wonder if separate firmware will do the Job as Well
<kristianpaul>
but lets him to answer :)
<wpwrak>
quite frankly, i have no clue what he's doing :)
<wpwrak>
for slideshows with effects, perhaps it could be nice to have a means to run the effect processing in only a part of the screen, with the actual slide covering the rest
<wpwrak>
but i don't know how well that would work in practice
<kristianpaul>
yeah, a video from the talk he gave will light us more
<kristianpaul>
ignoring that res is still low fore presenteations, the other features he request still really that messy to implement?
<wpwrak>
you mean better IR control ? no, that's fine. we should have a fully configurable input system anyway.
<wpwrak>
but it's something that's a bit further down the road
<xiangfu>
wpwrak, when m1 do rendering. which hardware core is using?
<wpwrak>
(low res) not sure about that. the title overlay (F1) looks okay. and you wouldn't want to use a much smaller font for slides anyway
<wpwrak>
xiangfu: eh, cool ! you already did it :)
<wpwrak>
you should post that on the list
<xiangfu>
wpwrak, the case quality is pretty good. with the big 'aiguille' not break the plastic
<xiangfu>
wpwrak, all you need is a thick wood when you drill the hole. :)
<wpwrak>
yeah. and you could even use a smaller drill
<wpwrak>
and the right position for the center :)
<xiangfu>
wpwrak, yes. that will be perfect.
<xiangfu>
wpwrak, I will reply you email.
<xiangfu>
wpwrak, I have another bigger hole on the top of the case.
<xiangfu>
wpwrak, I was thinking about it for the memcard. but after I drill the hole I found you can never plug a memcard though this hole :)
<wpwrak>
you would need very thin and very flexible fingers ;-)))
<xiangfu>
wpwrak, if I have that fingers. I don't think I needs use those fingers. maybe mind-control works :)
<wpwrak>
yeah. while the rest of the industry is still excited about capacitative touch screens and multi touch, we should move on and explore telekinetic interfaces :)
elldekaa [elldekaa!~hyviquel@gue01.insa-rennes.fr] has joined #milkymist
<GitHub19>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/k7fUaw
<GitHub19>
[milkymist-ng/master] Pay a bit more attention to PEP8 - Sebastien Bourdeauducq
<GitHub23>
[migen/master] Pay a bit more attention to PEP8 - Sebastien Bourdeauducq
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
krispaul [krispaul!~krispaul@2001:0:53aa:64c:107b:1afb:415a:74c5] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
Gurty [Gurty!~princess@ALyon-256-1-61-147.w90-9.abo.wanadoo.fr] has joined #milkymist
krispaul [krispaul!~krispaul@2001:0:53aa:64c:28:2a0a:415a:74c5] has joined #milkymist
<whitequark>
Xst: INFERNAL_ERROR:1:main.cpp:4769
<lekernel>
infernal? :)
<wpwrak>
now we're getting to the poodle's core :)
<whitequark>
lekernel: :D
<whitequark>
it's the _correct_ reading of xst's errors
<lekernel>
whitequark: screenshot :)
<wpwrak>
btw, 1078 cycles and counting. that's already 1.5-2x the average time to failure with M1rc3. i'll do a lock bit check at 5000. then add another 5000.
<whitequark>
lekernel: that's not a real error message. just my interpretation, albeit more correct in regards to debugging them.
<krispaul>
ah
<lekernel>
whitequark: you should try migen fhdl - it should only generate code patterns that do not crash the xst parser :)
<lekernel>
plus it will force you to build a synchronous circuit
<lekernel>
memories aren't supported yet, but if you know a tad of python, it shouldn't be hard
<whitequark>
lekernel: well, I know python, and I hate it
<whitequark>
besides my personal preference, I don't see a need in another layer
<lekernel>
if you compare it to the little mess in milkymist's system.v and conbus, I trust you'll at least recognize some value in it.
<lekernel>
the TMU is another area that can largely benefit from that other layer
<whitequark>
oh yes, reminds me of my pipeline
<whitequark>
well, the idea is nice
<whitequark>
still, python isn't something I will use in my own project. for milkymist, fine, if everyone does, I'll do too
<lekernel>
what's your argument against python?
<whitequark>
it wasn't designed -- more of "tangled up" (examples are everywhere: print, global functions, strange functions in stdlib, confusing array accessors, etc.); 3.x fixes a lot of that, but also introduces a lot of incompatibility. I heard even 2.7/2.5 has incompatible changes. It does not have some really good features which have proved their usefulness (proper lambdas), it has a _completely braindead_ C API (Py_INCREF(Py_None); and so on), an
<whitequark>
I'm not saying that Python is bad for migen, even through I'd rather see it in any other language.
<whitequark>
(about udev: I think not anymore. I've did that ~year ago, and it was a hard build and runtime dependency of some of its components (extras?). They're fixed that AFAIK, but that still sucked a lot. Python in embedded...)
<wpwrak>
_any_ other language ? like, brainfuck ? :)
<whitequark>
wpwrak: any other appropriate language. There is no other one I dislike as much as Python. The problem with snakeish thing is more social than technical.
<whitequark>
and brainfuck is just an interesting challenge to build a processor with modern features, but not too complex to take months
<whitequark>
given the background of a lot of people here: has FSO stack been rewritten in C because Python was too cpu, memory energy hungry?
<wpwrak>
naw, python isn't *that* evil. it's not a language i feel terribly comfortable with either, though. it has a certain "designed for beginners" feel to it.
<whitequark>
wpwrak: Guido (Python's author) is _explicitly against optimizations_
<whitequark>
just think about it
<wpwrak>
;-)
<whitequark>
they allocate every number literal on heap
<whitequark>
(and destroy it when it leaves scope)
<whitequark>
preallocating -1..100 has given a 30% boost in performance
<wpwrak>
;-))
<wpwrak>
that encourages really good coding practices ;)
<whitequark>
it just gives me an continuous facepalm when I try to write in it
<whitequark>
back when I've used Ubuntu on my desktop
<whitequark>
putting * * * * * killall -9 python in crontab has fixed all the problems with performance
<wpwrak>
well, there are more things. like the use of \, the mandatory indentation that makes it hard to add instrumentation for debugging, then of course the changing of initializers, and so on. in the end, it will do what you want, but you feel dirty.
<whitequark>
yes! exactly.
<whitequark>
the indentation thing is the least disturbing for me (it's also the most flamewar'd one, I think). I'm happy using other languages with mandatory indentation, like CoffeeScript. It's fine on its own (and when it is done properly)
<whitequark>
i.e. no spaces/tabs conflict, etc.
<whitequark>
and no conflict with sed -i s,\s\+$,, *
<whitequark>
krispaul: my WM is based on Lua. it's a bit tedious to write in it, but at least it was explicitly designed in such a way, it is consistent and it's fine for its scope (embedding)
<krispaul>
tedious yeah :/
<whitequark>
my personal preference is Ruby or Scheme
<whitequark>
but I doubt anyone here will select Scheme :)
<whitequark>
the two things I like most in Ruby are: a) its Lisp ancestry -- wide and appropriate/trivial use of lambdas and b) after you get a grasp of it, every next feature of language feels obvious -- it in almost all cases behaves just what you're expecting it to work
<wpwrak>
lekernel: btw, how bad would the memory bandwidth impact be if we grew the OSD to the full size of the screen ? do you think we could use the present OSD mechanism but at full screen size, with the usual patches running underneath ? (full screen size = in rendering mode)
<wpwrak>
lekernel: what i'm after is an overlay for configuration. so that you don't have to do things like go to the GUI just to adjust the audio sensitivity.
<lekernel>
why not a complete patch editor in overlay? :)
<lekernel>
the "livecoding" button in the current patch editor
<wpwrak>
yes .. but is this a real button i've never noticed or a hypothetical button ?
<lekernel>
a hypothetical one
<wpwrak>
ah :)
<lekernel>
regarding the overall speed of a full-screen overlay, I don't really know... try it
<wpwrak>
hehe, ok :)
<lekernel>
if memory bandwidth is a problem, disabling semi transparency should help
<lekernel>
but then you can't use antialiased fonts
<wpwrak>
which may look suckish. hmm. let's hope for the best then :)
<lekernel>
without semi transparency, the TMU is fairly efficient. it won't read-modify-write the destination framebuffer but use the DRAM's byte masking signals instead.
<lekernel>
so you get only one write instead of a read, a bus turnaround, and a write
<wpwrak>
ah, nice
<wpwrak>
well, with the increased color depth, it would be one bus word at a time anyway
<lekernel>
the DRAM bus is 64-bit
<lekernel>
and it'll be 128 with the increased resolution ;)
<wpwrak>
huh ? how ?
<lekernel>
it's DDR at the system frequency, so it reads two 32-bit words in one cycle, which are then serialized/deserialized in one 64-bit word per cycle
<lekernel>
I plan to switch to DDR at twice the system frequency
<lekernel>
and 1:4 serialization
<wpwrak>
oh. our DDR can handle this already ?
<lekernel>
yes, 160MHz shouldn't be a problem
<wpwrak>
kewl
<lekernel>
actually it can do 200MHz at 2.6V
<wpwrak>
double the memory bus speed, with just a few verilog changes. mimic that, intel and amd ! ;-)
<lekernel>
the problem is it's not 'a few'
<lekernel>
otherwise I'd have done that already :)
<wpwrak>
a few here, a few there, ... we all know how such things build up :)
<wpwrak>
yup. of labsw. i'm torture-testing the M1's NOR behaviour
<whitequark>
wtf is GitHub*?
<whitequark>
no namechanges, no join/leaves and nothing in nickname list
<lekernel>
I set the channel in "outside messages accepted" to limit the github bot visual pollution
<lekernel>
it posts without joining the channel
<lars_>
magic!
<krispaul>
boo? :)
<krispaul>
wpwrak: are you going up to resnder or just testing powercycle so far?
<wpwrak>
phew. took me a while to decode that ;-)
<whitequark>
resnder?
<wpwrak>
what i do is that i boot into performance mode and have "tunnel" render for ~4 seconds
<krispaul>
s/resnder/render
<krispaul>
got it, thanks :)
<wpwrak>
total time from boot out of standby to power cut is 15 seconds
<whitequark>
5760 times per 24 hours
<whitequark>
that is, 5760 power cycles and 1 Werner gone insane from the continuous clicking.
<wpwrak>
close :) there are also 3 seconds for power cycling
<whitequark>
4800, then
<wpwrak>
i've had that thing click on me some 50'000 times already. i think i can't possibly get any more insane from it at this point :)
<whitequark>
does it work, eh, around _two weeks_?!
<wpwrak>
plus any delays the shell and the commands invoked may have :)
<wpwrak>
the real number i get is about 4600 per 24 hours
<wpwrak>
the 50k weren't in a single run. but yes, i had that stuff run for weeks
<wpwrak>
(in total)
<whitequark>
do you have a wife or children (yet)?
<whitequark>
just curious
<whitequark>
I'd rather kill myself after fifth hour
<wpwrak>
(subjects interfering with hacking) new :)
<wpwrak>
s/new/naw/
<whitequark>
haha :)
<wpwrak>
(5th hour) it's all automated. very enjoyable to watch, and to think that adam did that manually. for some 500 cycles per run.
<whitequark>
yes, I think that first five hours or so I'd just watch it work
<whitequark>
and then I'd try to do something different
<whitequark>
click-click....
<whitequark>
click-click...
<whitequark>
*head asplodes*
<wpwrak>
hmm, when i reach 10k cycles, i'll have a 1:1.6M chance of the bug still being there and just not having happened yet
<wpwrak>
you grow used to it after a day or two :)
* whitequark
drops a pen on the floor
<whitequark>
it has a non-zero probability of tunneling straight through it
<whitequark>
it just has not happened before
mumptai [mumptai!~calle@brmn-4dbccd41.pool.mediaWays.net] has joined #milkymist
<whitequark>
sigh. failed this time, too :/
<wpwrak>
;-)
<whitequark>
what's the outcome of the possible bug?
<whitequark>
NOR suicide?
<wpwrak>
if i add another day, the probability would be around 1:2000M :-)
<wpwrak>
corruption of some NOR content. can be a few bits in a data word or, perversely, also a lock bit
<whitequark>
"perversely"?
<whitequark>
it, ehh, _corrupts the NOR content perversely_?
<wpwrak>
corruption of the lock bit prevents further corruption of data
<whitequark>
ah, got it
<whitequark>
why does that happen? ringing on the control lines?
<wpwrak>
that is, unless the lock bit is corrupted back to unlocked. which theoretically could also happen
<krispaul>
ah, wait so this was with locking i tought that wasnt necesary after the reset fixes..
<wpwrak>
the hypothesis is that it's FPGA core power going down faster than the power supply of FPGA I/O and NOR. so when the core dies, it may send out some random noise, which gets amplified by the still operational I/O section and is seen by the NOR.
<wpwrak>
every once in a while, on of those bad patterns will be a valid write ...
<krispaul>
or may be i'm complery ignorant of this topic and is prety normal this locking feature
<wpwrak>
and even less often, it will be a valid NOR lock command
<krispaul>
s/complery/complete
<whitequark>
wpwrak: sounds like a zombie movie scenario
<whitequark>
besides that, how would you fix this? more caps on Vcore?
<wpwrak>
krispaul: i was describing the behaviour without locking
<krispaul>
yes i noticed that
<krispaul>
vodoo caps :)
<wpwrak>
krispaul: in theory, we could also get an uncommanded unlock. that would break the work-around we have now, namely that we lock the most susceptible areas of the NOR.
<wpwrak>
krispaul: but the probability of this happening is pretty low. you probably break off the power socket first, assuming that the normal way of power-cycling is by unplugging power
<krispaul>
yeah, eve lock corruption and all the fun with it:)
<krispaul>
eveN
<wpwrak>
whitequark: we have a reset circuit that holds the FPGA in reset when the rail ramps up or down. alas, it's referenced to the slower of the two rails. so, while it does its job when powering on, it has no effect when powering off
<wpwrak>
whitequark: th two rails are fed from separate regulators that are supplied by a common input. the solution we're looking at now is to reference the reset circuit to the common input
<wpwrak>
this means it will force a reset long before the rails (behind their own regulators) start dropping
cjdavis [cjdavis!~cjdavis@cpe-71-67-99-208.cinci.res.rr.com] has joined #milkymist
<wpwrak>
and the cutoff point is set at the minimum input voltage of the regulator of the rail with the highest voltage
<whitequark>
yeah, I see
<wpwrak>
well, there is a bit of slack there. but that also happens to be the rail we already know to be "slow". so being a few mV off won't matter
<whitequark>
wpwrak: what do you mean by "slack"?
<wpwrak>
the lower end of the tolerance of the reset chip's threshold is below the upper end of the tolerance for the regulator's minimum input
<wpwrak>
we had to go a bit low because the system would get too trigger-happy and also kill itself if you connected some USB device
<whitequark>
won't bigger capacitors on VBUS also help?
<wpwrak>
BIG capacitors ;-)
<whitequark>
yes
<whitequark>
is that a problem?
<wpwrak>
we're adding a current-limiting switch, just in case
<wpwrak>
monster caps are inconvenient and can get expensive
<wpwrak>
no, the current-limiting switch is the appropriate solution for the inrush current problem
<whitequark>
does the voltage past these two main regulators also fall too low?
<whitequark>
I guess no...
<wpwrak>
well, the scenario is that power is removed from the system. so everything goes down.