Re: [Xen-devel] [linux-4.1 test] 63030: regressions - FAIL

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Oct 21, 2015 at 10:44:48AM +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 10:24 +0100, Wei Liu wrote:
> > On Wed, Oct 21, 2015 at 10:04:14AM +0100, Ian Campbell wrote:
> > > On Tue, 2015-10-20 at 16:24 +0100, Wei Liu wrote:
> > > > But this is only code inspection,  so I'm not very confident whether
> > > > everything does what it says it does.
> > > 
> > > Right,. I think this one probably needs someone to setup a system in a
> > > similar configuration and play with it.
> > > 
> > 
> > Is there an easy way to do that? Say, give me some runes so that I can
> > lock a machine in Cambridge instance, run the failing test case.
> 
> I could[0] but, why can't you just set things up on your existing test
> hosts, either using standalone mode or by just installing the guest by
> hand?
> 
> That's what I would do (probably the latter) in the first instance. It's
> very likely IME that you are going to need to poke at this interactively
> while debugging and to run repeated migrations etc to trigger the issue.
> IMHO trying to use osstest for such manual debugging is just going to get
> in the way.
> 

I could do all these manually, but not without paying much attention:
allocating a new test box (all my test boxes are in use at the moment),
run standalone mode, use standalone mode to install the test box, grab
various tarballs from osstest website if I don't want to build them
again, put them in suitable location and use standalone script to fiddle
with standalone mode database, manually install a guest etc etc,  let
alone the bug we're hunting might not be reproducible on the new test
box due to different hardware and external environment (as we've already
witnessed in production osstest system), then I'm left in dilemma
wondering whether I should repeat all these things (well, part of) again
or just give up.

This looks like a list of endless tedious tasks and it could go wrong
many places in between. If I can get OSSTest to lock a box and run up to
the point that it reproduces the issue that would be of great help.

Furthermore, I can write down all the runes I use so that other people
can do the same to reproduce bugs discovered in osstest. That would
certainly help lower the barrier for people who want to help triaging
bugs.

Wei.

> > > xen-netfront.c calls netdev_notify_peers (née netif_notify_peers). I
> > > seem
> > > to vaguely recall that setting some sysctl (arp_notify?) can be
> > > required to
> > > allow that to actually do anything but I think that has been fixed i.e.
> > > NETDEV_NOTIFY_PEERS is unconditional in inetdev_event() and only
> > > NETDEV_CHANGEADDR is gated.
> > > 
> > 
> > Found your patch posted in 2011.
> > 
> > https://patchwork.ozlabs.org/patch/82813/
> > 
> > I think you're right and the said behaviour exists in Wheezy's 3.2
> > kernel.
> 
> This ended up as d11327ad6695db8117c78d70611e71102ceec2ac and:
> 
> $ git describe --contains d11327ad6695db8117c78d70611e71102ceec2ac
> v2.6.38-rc6~20^2~10
> 
> ...suggests this was in mainline long before 3.2.
> 
> Ian.
> 
> [0] ./mg-allocate -U <timespan> <machine-name>
> Where timespan is digits followed by d (for days), h (for hours) etc.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel