[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-release
Subject:    Test Result Summary of Linaro 12.12 Release for Linux Linaro ubuntu Quantal.
From:       amit.kucheria () linaro ! org (Amit Kucheria)
Date:       2012-12-20 12:47:27
Message-ID: CAP245DW=q-AMo+ofZovnYxTkXuTB8xTJ63NK51vN_Kk9mr8D=w () mail ! gmail ! com
[Download RAW message or body]

On Thu, Dec 20, 2012 at 4:49 PM, Alexander Sack <asac at linaro.org> wrote:
> On Thu, Dec 20, 2012 at 11:35 AM, Amit Kucheria
> <amit.kucheria at linaro.org> wrote:
> > Hi Botao,
> > 
> > 
> > > 2. Samsung Origen + Linux Linaro Quantal (Column E):
> > > 
> > > https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEowNWhZRi1zbDNNVUw1amhXTUdPcVE#gid=1
> > >  
> > > Exactly same test result as last week: network connection is unavailable,
> > > "reboot" & "halt" test failed.. Power Management test would hang system when
> > > run test "cpuhotplug_02".
> > 
> > PM-QA tests are documented here:
> > https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts
> > 
> > Are any bugs filed against the kernel or pm-qa after analysis of what is wrong?
> 
> For all bugs, except a kernel hang/oops/panic, we should be able to
> establish a procedure that bugs get sanitized by distro engineers to
> rule out the majority of "platform" induced problems and give more
> details.

That'd be appreciated. Basic stuff like check against mainline,
compare against standard Linux rootfs, check for last known working
version, git bisect the kernel to where the problem started seems like
things that could be added to that procedure.

> However, we don't have strong kernel know how, so if we see a "hang"
> or "oops", filing a but with clear instructions on how to reproduce
> it, is more or less where our ability to help debugging ends. We could
> try to make an even more minimal test case, but I would assume that in
> this case the unit tests in PMQA are minimal enough for you to act on?

PM-QA tests are mostly shell-scripts. And they're as minimal as
functional tests can be.

I'd like to work with the QA team to get to a point where they gain a
bit more understanding of the  subsystem being tested and its expected
behaviour. This would allow them to fix some bugs and help us improve
our tests too. Sometimes, it is a simple matter of kernel interfaces
changing that require updates to the tests. Other times it is missing
Kconfig options. And if someone expresses a desire to dig deeper in
the kernel in order to learn new things, we're willing to walk them
through the basics of debugging.

> > 
> > > 3. TI Panda 4430 + Linux Linaro Quantal (Column E):
> > > 
> > > https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=3
> > >  
> > > ARM DS-5 backs to work. All 3 tests, data streaming, remote SSH connection
> > > and on target application debug passed. Device Tree is unavailable, the
> > > directory "/proc/device-tree" is empty. A new issue here is power management
> > > test "cpuhotplug_07" failed. However, this test passed on TI Panda 4460.
> > 
> > Ditto.
> > 


[prev in list] [next in list] [prev in thread] [next in thread]