qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [for-2.12 0/7] PCI cleanups


From: Fam Zheng
Subject: Re: [Qemu-devel] [for-2.12 0/7] PCI cleanups
Date: Tue, 5 Dec 2017 14:46:35 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

On Tue, 12/05 16:11, David Gibson wrote:
> On Tue, Dec 05, 2017 at 01:05:58PM +0800, Fam Zheng wrote:
> > On Tue, 12/05 06:49, Michael S. Tsirkin wrote:
> > > On Wed, Nov 29, 2017 at 05:18:47PM +0800, Fam Zheng wrote:
> > > > On Wed, 11/29 01:02, address@hidden wrote:
> > > > > /tmp/cc3Czn0R.s: Fatal error: can't write 3947 bytes to section 
> > > > > .debug_str of hw/arm/virt-acpi-build.o because: 'No space left on 
> > > > > device'
> > > > 
> > > > Hmm, the host is shared and what I have is a normal user account, so 
> > > > there is no
> > > > control over disk space availability.  Anyway this is completely 
> > > > unrelated to
> > > > this series. Sorry for the noise.
> > > > 
> > > > Fam
> > > 
> > > Could you disable this until you have the time to detect disk full
> > > errors?  You are training people to ignore this bot, not a good thing.
> > > 
> > 
> > Thanks for the suggestion. I've added a string match to the notification
> > condition. The problem is disk is only one factor, I dream of an AI that 
> > can be
> > trained to tell which errors are geniune bugs of the patch and which are
> > environment failures... :)
> 
> Another approach would be to have a "known good" build that runs every
> so often.  If the known good build fails, the bot disables itself (and
> tells you to investigate).  Obviously there are ways that could not
> work as well, but it should catch a fair range of spurious failures.

Interesting idea, yes. A slightly simplified way is to test the "base" of the
series and only report errors if the base can pass.

Fam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]