linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Paul Larson

Moving this thread to the linaro-dev mailing list because I'd like it to be public discussion, and specifically to involve Rob since we talked about his interest in getting involved with LAVA development and especially the job dispatcher. 2. One queue TOTAL. One queue may seem like a bottleneck, but I don't think >> it has to be in practice. One process can monitor that queue, then launch a >> process or thread to handle each new job that comes in. >> > I think RabbitMQ message can have the ability to include the board > information in it to use one queue, and also we can use different queues for > different types of boards. > Right, but my question was, if you are already encoding information about which host to run on in the job stream, what is the advantage to having a queue for each board type, rather than a single queue? > >> >> >> Job description: >> I'd like to see some more detail here. Can you provide an example of a >> job file that would illustrate how you see it working? We also need to >> specify the underlying mechanisms that will handle parsing what's in the job >> file, and calling [something?] to do those tasks. What we have here feels >> like it might be a bit cumbersome. >> > I added an detailed one on the spec, like: > > 1. > > [Beagle-1, > http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/imx51/20110131/0/ima…, > > http://snapshots.linaro.org/11.05-daily/linaro-headless/20110131/0/images/t…, > 900, ["abrek", "LTP", 180], ["none", "echo 100 > abc", 1], ... ] > 2. > > [IMX51-2, 20100131, 900, ["abrek", "LTP", 180], ["none", "echo 100 > > abc", 1], ... ] > > This looks almost like JSON, which is what Zygmunt was originally pushing for IIRC. If we are already going down that path, seems it would be sensible to take it a step further and have defined sections. For example: Tests:[ { name:"LTP", testsuite:"abrek", subtest:"ltp", <---- not thrilled about that name "subtest", but can't think of something better to call it at the moment timeout:180, reboot_after:True }, { name:"echo test", testsuite:"shell", timeout:20 reboot_after:False } ] What do you think? Obviously, there would be other sections for things like defining the host characteristics, the image to deploy, etc. > >> >> > Other questions... >> What if we have a dependency, how does that get installed on the target >> image? For example, if I want to do a test that requires bootchart be >> installed before the system is booted, we should be able to specify that, >> and have it installed before booting. >> >> What about installing necessary test suites? How do we tell it, in >> advance, what we need to have installed, and how does it get on the image >> before we boot, or before we start testing? >> > I think validation tools, test suites and necessary files are likely to > install after test image deployment. > Yes, clearly they have to be installed after deployment, but we may also need to consider them installing BEFORE we actually boot the test image. Thanks, Paul Larson

13 years, 11 months

Linaro 11.05 Alpha-2 (part 2) candidate testing

by Jamie Bennett

Hi, Due to an xserver issue in the Ubuntu archive (xserver packages built against old xserver-xorg-core) the Alpha-2 images have been re-rolled and are ready for your testing. The links are: Hardware Packs: http://releases.linaro.org/platform/linaro-n/hwpacks/alpha-2-rc2/ Headless: http://releases.linaro.org/platform/linaro-n/headless/alpha-2-rc2/ ALIP: http://releases.linaro.org/platform/linaro-n/alip/alpha-2-rc2/ Netbook: http://releases.linaro.org/platform/linaro-n/netbook/alpha-2-rc2/ Developer Tools image: http://releases.linaro.org/platform/linaro-n/developer/alpha-2-rc2/ As always, for an explanation of how to test the images on your hardware head on over to: http://wiki.linaro.org/Releases/DailyBuilds and submit your results to: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Regards, Jamie. -- Linaro Release Manager

13 years, 11 months

RFC: Try moving kernel wg call to IRC?

by Dave Martin

Hi there, Just a thought--- is it worth experimenting with running the kernel wg meeting on IRC instead of the conf call? Personally, I find IRC meetings _much_ more digestible than conf calls (better "audio quality"; ability to scroll back when you don't hear / don't understand something etc.), but I don't know whether other people feel the same way -- that may just be my personal preference. Comparing the dev platform group's weekly IRC meeting with the kernel conf call, I've found that the IRC format works quite a lot better for me, but again, that may just be my experience. Cheers ---Dave

13 years, 11 months

Fwd: query regarding perf

by Sudip Jain

---------- Forwarded message ---------- From: Dave Martin <dave.martin(a)linaro.org> Date: Wed, Feb 2, 2011 at 4:55 PM Subject: Re: query regarding perf To: Sudip Jain <sudip.jain(a)linaro.org> On Wed, Feb 2, 2011 at 11:09 AM, Sudip Jain <sudip.jain(a)linaro.org> wrote: > I am getting the error when I execute perf on U8500 > No permission to collect stats. > Consider tweaking /proc/sys/kernel/perf_event_paranoid. > The problem I think is perf version and kernel version are not same.On > ubuntu host x86 machine, if I do sudo apt-get install linux-tools-common, > then perf runs succesfully. Even I downloaded the source code using sudo > apt-get source linux-tools-common and re-built perf. It works. Yes, you'll need the perf tools to be (reasonably) in sync with the kernel. The linux-linaro-tools package provides the tools for the released kernels, but if you're working with a development kernel it may be better to build the tools yourself, as you describe. > Recently my ubuntu host crashed, I re-installed with 10.04, the kernel > version is 2.6.32-21 and perf version is 2.6.35.8. So again I am getting the > same error (now on ubuntu host) which I mentioned above. Though now I have > the opportunity to debug the perf code, but that is not my target. > I am hoping that panda/beagle is fully supported for ubuntu mainstream AFAIK panda and beagle both ought to work, but please shout if you run into problems! Cheers ---Dave

13 years, 11 months

Linaro 11.05 Alpha-2 Candidate testing

by Jamie Bennett

Hi, The Linaro 11.05 Alpha-2 image [1] is set to be released on Thursday 3rd February (in two days !) [2] and we need your help. In addition to our in-house validation testing we ask anyone with supported hardware, as found on: http://releases.linaro.org/platform/linaro-n/hwpacks/alpha-2-rc/ to test the Alpha-2 release candidates at: Headless: http://releases.linaro.org/platform/linaro-n/headless/alpha-2-rc/ ALIP: http://releases.linaro.org/platform/linaro-n/alip/alpha-2-rc/ Netbook: http://releases.linaro.org/platform/linaro-n/netbook/alpha-2-rc/ and our new image, Developer Tools image: http://releases.linaro.org/platform/linaro-n/developer/alpha-2-rc/ Please note that due to a lack of committed support the Plasma image has been dropped from our list of regularly tested images. If you would like to see the Plasma image return and can give support to the maintenance and testing of this image please get in contact with me. Please make your way to: http://wiki.linaro.org/Releases/DailyBuilds for an explanation on how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Regards, Jamie. -- Linaro Release Manager [1] https://wiki.linaro.org/Process/Cycle/Alpha1Release [2] https://wiki.linaro.org/Releases/1105/Schedule

13 years, 11 months

Re: Linaro Image Tools 0.4.3 released

by Loïc Minier

On Wed, Feb 02, 2011, Avik Sil wrote: > Won't the link be https://launchpad.net/linaro-image-tools/+milestone/0.4.3? Yes; I failed to s/0.4.2/0.4.3 when resending; grmpf -- Loïc Minier

13 years, 11 months

[PATCH] arm: Improve MMC performance on Versatile Express

by Pawel Moll

VE suffers from serious problem with MMC transfers - low performance, errors when other IO peripherals (especially USB) are used at the same time etc. It all boils down to the MMC controller short FIFO and - in result - timing constrains. The most problematic case - USB driver hogging CPU and MMC FIFO under/overruns in the result - can be mitigated on SMP system by distributing interrupts handling for these peripherals between cores. With this, the MMC card clock can be safely (at least it looks like it) increased to 1.5MHz, improving performance. Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> --- arch/arm/mach-vexpress/v2m.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c index 4b5af01..300ac72 100644 --- a/arch/arm/mach-vexpress/v2m.c +++ b/arch/arm/mach-vexpress/v2m.c @@ -244,6 +244,7 @@ static unsigned int v2m_mmci_status(struct device *dev) static struct mmci_platform_data v2m_mmci_data = { .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34, .status = v2m_mmci_status, + .f_max = 1500000, }; static AMBA_DEVICE(aaci, "mb:aaci", V2M_AACI, NULL); @@ -391,6 +392,19 @@ static void __init v2m_init(void) for (i = 0; i < ARRAY_SIZE(v2m_amba_devs); i++) amba_device_register(v2m_amba_devs[i], &iomem_resource); + /* WARNING: HACK HACK HACK! + * + * MMCI cell has very tight timing requirements regarding interrupt + * handling (fractions of millisecond), while the USB host controller + * interrupt handler can hog the CPU for more then 1 millisecond! + * + * To mitigate the problem on SMP systems, we can set CPU affinities + * of these interrupts to different cores... */ + BUG_ON(v2m_usb_resources[1].flags != IORESOURCE_IRQ); + irq_set_affinity(v2m_usb_resources[1].start, cpumask_of(0)); + irq_set_affinity(mmci_device.irq[0], cpumask_of(1)); + irq_set_affinity(mmci_device.irq[1], cpumask_of(1)); + pm_power_off = v2m_power_off; arm_pm_restart = v2m_restart; -- 1.6.3.3

13 years, 11 months

Re: [PATCH] arm: Improve MMC performance on Versatile Express

by Russell King - ARM Linux

On Mon, Jan 24, 2011 at 05:54:18PM -0000, Pawel Moll wrote: > $ git am 0001-arm-Improve-MMC-performance-on-Versatile-Express.patch > > / # uname -a > Linux (none) 2.6.38-rc2+ #12 SMP Mon Jan 24 17:41:53 GMT 2011 armv7l GNU/Linux > / # cat /dev/sda > /dev/null & > / # dd if=/dev/mmcblk0 of=/dev/null bs=64k count=128 > 128+0 records in > 128+0 records out > 8388608 bytes (8.0MB) copied, 1.501529 seconds, 5.3MB/s > > > THERE IS NO ISSUE WITH MMCI. THE HARDWARE DOES NOT NEED "FIXING". > > I'm really pleased you think so. It's always nice to have happy customers :-) If you're flooding the system with USB traffic, enlargening the FIFO size won't help. Making the FIFO larger just decreases the _interrupt_ _latency_ requirements. It doesn't mean you can cope with the amount of data being transferred. if (cycles-to-transfer-usb-packets + cycles-to-transfer-MMC-data > available-cpu-cycles) you_are_stuffed(even_with_larger_fifo); So I'm not surprised that running USB and MMC at full speed results in MMC losing out. You will find that even with a larger FIFO, MMC will still lose out. Why? The ISP1761 can store the packets without complaint, and the host CPU can read them when it's ready. As soon as one packet is read off the host, the next packet is probably sitting there waiting for the host CPU to read it. When the ISP1761 buffer becomes full, it can tell the device to stop sending data. The result of that is the ISP1761 will be able to transfer data as fast as the host CPU can possibly go - to the exclusion of the MMC interface. No amount of FIFO (well, except several KB to cover the _largest_ size of MMC transfer we request) will resolve the problem of USB and MMC sharing the same CPU.

13 years, 11 months

l-m-c console arguments

by Amit Kucheria

Hi, I just tried to create an SD image for the beagle with l-m-c from bzr. The kernel command-line ends up containing 'console=tty0 console=NONE,115200n8'. Board configuration problem? Overriding l-m-c with --console ttyO2 doesn't work since it is added before the other consoles, so doesn't end up getting input. Shouldn't it be the last console added in the list? Regards, Amit

13 years, 11 months

Re: Bazaar and Launchpad though proxy]

by Martin Pool

Dechesne, Nicolas wrote: > I actually wrote the instructions on the wiki above. but you need to use the full bzr+ssh:// link as I put on the wiki. i have not been able to use shorthand link using lp: type of link. If you have the http_proxy environment variable set to something that allows outgoing http, and if you have a recent bzr (from eg Ubuntu Maverick) then lp urls should work through a proxy. You can set the proxy variable in the GNOME Proxy control panel, or just eg from your .bashrc: export http_proxy=http://proxy.example.com:8080/ But it may be simpler to just use bzr+ssh. Some of the ssh urls are different, for example to get a default source package branch you need eg bzr log bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/maverick/bash If you have any other problems please don't hesitate to ask in #launchpad on irc, or http://answers.launchpad.net/launchpad/ -- Martin

13 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev