Re: [linux-linus test] 55255: regressions - FAIL

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-05-12 at 13:35 +0100, Julien Grall wrote:
> On 12/05/15 11:07, Ian Campbell wrote:
> > On Mon, 2015-05-11 at 18:09 +0000, osstest service user wrote:
> >> flight 55255 linux-linus real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/55255/
> >>
> >> Regressions :-(
> >>
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  test-armhf-armhf-xl-arndale   6 xen-boot                  fail REGR. vs. 50329
> > 
> > This is a real failure (and I suspect the others are just things which
> > happened to run on arndale).
> > 
> > Tail of
> > http://logs.test-lab.xenproject.org/osstest/logs/55255/test-armhf-armhf-xl-arndale/serial-arndale-metrocentre.log is below.
> > 
> > The "outdated DT detected, suspend/resume will NOT work" is due to the
> > lack of an interrupt-controller property on the pmu device, which I fear
> > we may be suppressing somewhere while making the dom0 dtb.
> 
> It seems that Osstest is using the device tree provided by the debian
> installer.
> 
> I did try with the device tree provided by Linux and it boots without no
> issue.
> 
> We may want to use the device tree attached to every Linux version in
> order to avoid a such problem. Although, I don't much know

Yes, we probably should update things to use the dtb from the kernel
build.

> > The following null pointer exception I think is probably a bug arising
> > from trying to continue on regardless.
> 
> I gave a quick look to see what happens. pmu_base_addr is NULL because
> it's initialized only when the PMU is an interrupt controller (see
> exynos_pmu_irq_init). So the first pmu_*read* will segfault.
> 
> I suspect it's an unwanted behavior because the warning only says
> suspend/resume won't work. Not the kernel will crash.

Right, I think this should probably also be fixed. It might be as simple
as turning the existing pr_warn into pr_warn+return?

> Although, we know that DT is often tight to the kernel version. So I'm
> not sure if we should care of it.
> 
> Regards,
>