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
>
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
Zymunt tried to send this to validation, but it bounced.
Begin forwarded message:
> From: Zygmunt Bazyli Krynicki <zkrynicki(a)gmail.com>
> Date: 9 July 2013 15:48:58 GMT+01:00
> To: Dave Pigott <dave.pigott(a)linaro.org>
> Subject: Fwd: Automatically testing and landing approved LAVA merge requests
>
>
>
> ---------- Forwarded message ----------
> From: Zygmunt Krynicki <zkrynicki(a)gmail.com>
> Date: 2013/7/5
> Subject: Automatically testing and landing approved LAVA merge requests
> To: linaro-validation(a)lists.linaro.org
> Cc: tyler.baker(a)linaro.org
>
>
> Hi.
>
> I'm working on CI that automatically tests and lands approved branches to lp:lava subprojects. Currently the process of adding another project to support is manual. It requires adding a few lines to tarmac configuration file and creating the required ci-info directory.
>
> I've done that for lp:lava-tool and lp:lava-server (which fails CI today) and I'm doing that for lp:lava-dispatcher (also fails today).
>
> Currently the automatic merges are *already enabled* for lp:lava-tool. Any merge request that has at least one "approved" review comment the whole merge request is switched to "approved" state is automatically landed. Failure to run tests obviously prevents landing with an appropriate comment being added to the merge request. Merges happen every hour, I can easily make that more common if you want to though.
>
> Currently all testing happens on Ubuntu 12.04.2 LTS. If required we can enable testing on any OS of choice without much issues but someone should add 1GB to the machine that runs all tests for proper virtualization support. I was thinking that we could extend that to Fedora and Debian if there is interest.
>
> I'll be rolling this out with Tyler's approval to all the other projects in the LAVA group. Currently the CI information (how to run tests, etc) is inside the lava-landing-tests repository but it can be moved to particular project repositories (the code already supports that).
>
> I've pushed the code to https://github.com/zyga/lava-landing-tests - comments, questsions, bugs, pull requests are all welcome.
>
> Thanks
> ZK
>
---------- Forwarded message ----------
From: Paul Sokolovsky <paul.sokolovsky(a)linaro.org>
Date: 9 July 2013 00:09
Subject: LAVA Server on ARM?..
To: linaro-validation(a)linaro.org, Tyler Baker <tyler.baker(a)linaro.org>,
Antonio Terceiro <antonio.terceiro(a)linaro.org>, Riku Voipio <
riku.voipio(a)linaro.org>
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
On 8 July 2013 14:48, Siarhei Siamashka <siarhei.siamashka(a)gmail.com> wrote:
> And naturally, any PSU rated for just something like 1A will not work
> right, that's a common sense. The modern multi-core ARM boards can
> easily consume a lot more than this under load. But at least 2.5A or
> 3A should be sufficient if you don't attach many power hungry USB
> peripherals.
>
AFAICR, that PSU is 2.5A, but I could be wrong. I'll check when I get back
home. But it is cheap, and it could itself overheat, too.
So, for the time being, I'll leave it on 920MHz and keep the bots running
until we sort out the power/temp problem.
Anyway, I'd like to move away from Pandas to something with a bit more
horse power.
cheers,
--renato