Hey Lava devs,
I realise that right now might not be the best time in the development
cycle to mention this, but I've just watched an interesting talk on
really using postgres with Django:
http://www.youtube.com/watch?v=S-kbfpRpVsY
In particular, I think the (already postgres-specific) horrific code I
wrote for matching tags on job dispatch could be replaced with simple
tags arrays on Job and Device and a "<@" operator.
There are some other bits that could potentially be used (e.g. the JSON
stuff, maybe hstore for test results) but this part jumped out at me!
Cheers,
mwh
Hi all,
We need to take staging down for a while to move it from it's current cloud node to the master node, so that we can release a node from the cloud so that the multi-node dispatcher can run on bare metal. I plan to do the migration tomorrow morning starting at 08:00UTC. If all goes well, staging should be back up before 12:00UTC.
If anyone knows a reason why I should delay this, please let me know by e-mail before 08:00UTC tomorrow.
Thanks
Dave
Hi All,
Something I've been meaning to do for a long time is synchronise the latest LAVA master images with lava-create-master, and I've now completed this and tidied things up.
The definitive master images can now be found at:
http://images.validation.linaro.org/lava-masters/
I've tidied the directory above this up, so if you were relying on the master images being there, please note the change.
Thanks
Dave
Hello,
On 9 July 2013 09:03, Riku Voipio <riku.voipio(a)linaro.org> wrote:
> Hi,
>
> No i have not seen such issues with pyrhon on arm. Do you have some simple
> testcase?
>
So far I tried hint in one of those messages - to rebuild Python locally
which is supposed to fix the issue, but it didn't for me (I used
dpkg-buildpackage, i.e. config for official package).
As for testcase, there's no simple few-lines C file to reproduce it - I'd
love to do some ARM porting work, but all this is diversion from LAVA work
(I just got only Chromebook on my hands, and trying to install LAVA there
for testing). I can prepare a script which downloads/builds/starts a small
package which reproduces issue if that would be helpful.
> Riku
> 9.7.2013 0.09 "Paul Sokolovsky" <paul.sokolovsky(a)linaro.org> kirjoitti:
>
> Hello,
>>
>> So, did anyone really run complete LAVA server install (as produced by
>> lava-deployment-tool) on an ARM board? Myself, after working around upstart
>> issues pertinent specifically to chroot on Chromebook (upstart issues), I
>> hit this uwsgi issue:
>> http://lists.unbit.it/pipermail/uwsgi/2012-January/003349.html .
>>
>> Riku, did you hear about such problems with embedding Python on ARM (that
>> thread mentions problems with at least 2 packages)?
>>
>> Thanks,
>> Paul
>>
>>
Hi Folks,
I'm running two buildbots here at home and am getting consistent failures
from the Pandas because of overheating. I've set up a monitor that will
tell me the current CPU temperature and the allowed maximum, and when the
bot passes 90%, it shuts itself off.
The problem is that I'm running with heat-sinks and the boards are on top
of three fans, so there really isn't much more I can do to solve this
problem.
I personally think this is a hardware problem, since everything is in the
same die, CPU, GPU and RAM, and the physical dimensions of the chip are
quite small. I remember when Intel started overheating (around 486DX66) and
the die was huge (more head dissipation), plus RAM and GPU were separate,
and it still needed a hefty heat-sink.
It's true that gates are far smaller today, but it's not true that a dual
core 1.3GHz + GPU + RAM will produce less heat on a small die than a 66KHz
CPU on a huge die, so why anyone think it's a good idea to release a 1+GHz
chip without *any* form of heat dissipation is beyond my comprehension.
Manufacturers only got away with it, so far, because people rarely use 100%
of the CPU power for extended periods of time, because ARM devices end up
as set-top boxes, mobile phones and tablets. However, even those devices
will heat up when playing 2 h films or games, and they do have some form of
heat sink.
We, at the toolchain group, make things worse by using 100% CPU, 24 / 7,
something that Panda boards, or Arndales were not designed to do. However,
with ARM moving into the server space, their designs will have to be
re-thought, and what a better place than Linaro for making sure we get it
right?
For the time being, I believe we *must* have air conditioning in the Lab
all the time, and we *must* have heat-sinks on every board, and we *must*
monitor the CPU temperature of the boards, at least until we're comfortable
that they're not failing all the time.
Can we make a temperature monitor (like the one attached) a default feature
on Linaro Ubuntu distributions? We could dump that info to the syslog/dmesg
whenever it crosses the (say) 75% threshold, and report more often when it
crosses the 95%, possibly dumping the processe(s) that are consuming more
CPU at the time, to enable post-mortem debugging.
cheers,
--renato
As a side note, the quad-A9 ODroid does ship with a massive heat-sink,
which also serves as a fancy case. Quite clever, really.
Hi all,
Some time ago, we deployed 5 WiFi Access Points in the lab, supporting 802.11a,n,g,b etc. In the office we're having various problems with both the LAB Wifi and the normal office WiFi.
We'd like to perform some tests when we get back from Connect, and were wondering if anyone is performing WiFi tests on any boards, and if so, could we schedule some down time for all the routers? Obviously those tests would need to be halted for the day we pick for testing.
Please let me know about any WiFi tests that are run.
I'll let you know nearer the time, when exactly we'll be taking them offline.
Thanks
Dave
LAVA has support for remapping urls when fetching test images, using a
regular expression to match the url and rewrite it. The maps are configured
in a file called 'urlmapping.txt' which is usually placed in the dispatcher
config directory.
As this was a seemingly undocumented feature, and we no longer need this
functionality in the LAVA Lab, I am proposing to remove it.
If you are using this code in your LAVA deployment please let me know.
Thanks,
Matt Hart
Hi, Tyler && Matt
Thanks very much, I will try to a attend the session remotely(just a bit
late, I'm in UTC+8 China).
Again, thank you very much and your answer.
Best regards,
Jinghui.Shi
2013/7/10 Tyler Baker <tyler.baker(a)linaro.org>
> Hello Jinghui,
>
> We have a training session at Linaro Connect Europe 2013 to answer this
> very question. I believe this session will answer many question you might
> have, hopefully you can attend. We are hosting this session at 14:00 -
> 16:00 UTC in the Ulster room. If you cannot attend I have attached the
> presentation to this e-mail. Please let us know if you have any specific
> questions.
>
> Thanks,
>
>
> On 9 July 2013 20:13, jinghui shi <fddllinaro(a)gmail.com> wrote:
>
>> Hi,
>>
>> I'm tring to deploy my own board in LAVA(a board that haven't been
>> supported by LAVA lib).
>> But something puzzling me...
>>
>> According to the LAVA docs(
>> http://lava.readthedocs.org/en/latest/index.html),
>> LAVA server seems workable on debug mode, But still, I don't know how to
>> deploy my own board(from Fujitsu) in lava. I got some docs from
>> _http://lava.readthedocs.org/en/latest/index.html_, but a bit too
>> simple,
>>
>> So, Are there any docs that explain deploying lava to a board more detail?
>>
>> To explain the image format, How to write a .json file, what kind of
>> fields are there for a
>> .json file, what is the format, what every field means, what the
>> field's function,
>> how to add my own tests and so on.
>>
>>
>>
>> Best regards,
>> Jinghui.Shi
>>
>> _______________________________________________
>> linaro-validation mailing list
>> linaro-validation(a)lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-validation
>>
>
>
>
> --
> Tyler Baker
> Technical Architect, LAVA
> Linaro.org | Open source software for ARM SoCs
> Follow Linaro: http://www.facebook.com/pages/Linaro
> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
>