From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [linux-linus test] 55255: regressions - FAIL Date: Tue, 12 May 2015 13:53:53 +0100 Message-ID: <1431435233.8263.154.camel@citrix.com> References: <1431425244.8263.126.camel@citrix.com> <5551F3A2.9050500@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5551F3A2.9050500@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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, >