Hi all,
Some of you probably know bits about this already, but the LAVA team
has been working to implement features around privacy of test jobs and
results in LAVA.
One feature that has actually been present from the beginning but
hardly used is that bundle streams have defined access rules. Most
streams for the last year or so have been anonymous, which means that
anyone can see results in the stream, and anyone can put results in
the stream.
If a stream is not anonymous, it can either be owned by a person or a
group, and independently it can be public or private. Only the owner
(or members of the owning team) can put results into a non-anonymous
bundle and only the owner (or members of the owning team) can see the
results in a private bundle. Everyone can see the results in a public
bundle.
All this information about a bundle is encoded in its name:
public personal
/ -or- / -or- / {person-or-team name} / {bundle name} /
personal team
The reason for going on about this is that it is now possible to
create jobs for LAVA that can submit to a non-anonymous stream and
that the visibility rules for a _job_ are the same as the _stream_ it
will submit results to (also, if you try to submit a job that will
submit to a stream you cannot submit to yourself, this will be
rejected at submission time, rather than failing right at the end of
the job). So, I wanted to submit a job that would submit to a private
strteam of mine, I might put this in my LAVA job:
"command": "submit_results",
"parameters":
{
"server": "http://validation.linaro.org/lava-serverRPC2/",
"stream": "/private/personal/mwhudson/random/"
}
We've already converted most of the automatically submitted jobs over to
using private streams (visible to members of ~linaro on Launchpad) per
the new privacy policy, but this email should give you an idea of what
is possible when setting up new jobs.
Cheers,
mwh & the LAVA team
Hi
I was cross-compiling a Linux kernel 2.6.38 for a Gumstix Overo
which is a tiny ARM (TI OMAP 35xx) based single board computer.
I was using Linaro cross compiler (arm-linux-gnueabi-gcc) did not
give an uImage that gets pass the Loading uImage. My console is
ttyO2 and therefore it was not an issue. So I used Code Sourcey
G++ Lite (64 bits version without ia32 library) and the kernel image
uImage.bin built with the same configuration file (.config) but with
different cross compiler can boot up to the stage that the kernel
tries to mount ext3 partition on microSD card. So I suspect the
package gcc-linux-arm-gnueabi has some bugs. I have a working
2.6.35 kernel (although I do not have the .config file with settings
which I have used to build that) that was built with Linaro Gcc 4.3
or 4.4. I suspect the Linaro Gcc 4.5.x and above are giving me a
problem. I used the Linaro media create tool with root file system
and hardware pack but it also could not help me boot nor give me
the right config file which I can use to cross compile a working
kernel (that is booting kernel) for Overo computer.
So I tried also native compilation using Linaro GCC 4.5 but it is
not working. I wonder has anyone face the same issue like me,
I think I am wrong somewhere (the last time I cross compile the
kernel was pretty much straight forward and I dont remember I
had to patch the kernel I fetched from a git repository. But I will
be glad to hear who has faced similar problems like me. Any tips
will be appreciated. Even better, I will be glad to learn where did
you download (git fetch or git clone or wget or just http download),
your tool chain, your workstation (my original laptop was 32 bits
dual core DELL and now I am using a 64 bits Intel i7 so I am not
sure which set up is biting me). Any tip or link will be appreciated.
Sincerely
Aung
Hey Arnd, Rob,
So after Arnd's help sorting a workaround for the mmc driver, I'm
now trying to sort out the following HDMI failure I'm seeing w/ the
current 3.5-rc with my Panda Board.
[ 2.973693] omapdss error: HPD IRQ request failed
[ 2.978759] omapdss HDMI error: failed to power on device
[ 2.982391] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
usb-ehci-omap.09
[ 2.996459] omapdss error: failed to power on
[ 3.001037] omapfb omapfb: Failed to enable display 'hdmi'
[ 3.006805] omapfb omapfb: failed to initialize default display
[ 3.013183] Console: switching to colour dummy device 80x30
[ 3.022430] omapfb omapfb: failed to setup omapfb
[ 3.027374] omapfb: probe of omapfb failed with error -5
Any guesses on this?
thanks
-john
Hello,
are there any thoughts on how much of the perf.data is portable and how much it should be?
I'm interesting in recording scheduler activity on one machine and then replaying on
another. As I can see, replaying x86 perf.data on ARM doesn't work. At least, should it
work with a small subset of recorded events (for example, sched:sched_switch,
sched:sched_process_exit, sched:sched_process_fork, sched:sched_wakeup
and sched:sched_migrate_task) on the same architecture?
Thanks in advance,
Dmitry