Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-26 Thread Hu, Robert 
> -Original Message-
> From: Hu, Robert
> Sent: Monday, October 26, 2015 3:05 PM
> To: 'Ian Campbell' ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
> 
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> > -Original Message-
> > From: Hu, Robert
> > Sent: Sunday, October 25, 2015 10:46 AM
> > To: Ian Campbell ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> > 
> > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > > -Original Message-
> > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > Sent: Friday, October 23, 2015 9:38 PM
> > > To: Hu, Robert ; 'Ian Jackson'
> > > ; 'xen-de...@lists.xenproject.org'
> > > 
> > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp' to `ensurebridge'
> > >
> > > On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > > > > -Original Message-
> > > > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > > > Sent: Friday, October 23, 2015 4:15 PM
> > > > > To: Hu, Robert ; 'Ian Jackson'
> > > > > ; 'xen-de...@lists.xenproject.org'
> > > > > 
> > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking:
> Rename
> > > > > `nodhcp' to `ensurebridge'
> > > > >
> > > > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> > > > >
> > > > > > [Hu, Robert]
> > > > > > Seems the failure log shall be this, any idea? I've spent days on
> > > > > > debugging this:(
> > > > > > (XEN) traps.c:3290: GPF (): 82d080195082 ->
> > 82d080243d9d
> > > > > > (XEN) PCI add device :00:00.0
> > > > > > (XEN) PCI add device :00:01.0
> > > > > > (XEN) PCI add device :00:01.1
> > > > > > (XEN) PCI add device :00:01.2
> > > > > > (XEN) PCI add device :00:01.3
> > > > > > (XEN) PCI add device :00:02.0
> > > > > > (XEN) PCI add device :00:03.0
> > > > > > (XEN) d0: Forcing read-only access to MFN fed00
> > > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > > > > Issued domain 3 reboot
> > > > > > qemu: terminating on signal 1 from pid 4322
> > > > >
> > > > > Please can you report this as a regular bug in a fresh thread, that 
> > > > > way
> > > > > the relevant Xen maintainers are likely to see and react to it, rather
> > > > > than just us osstest folks.
> > > > [Hu, Robert]
> > > >
> > > > It shall be in that way after I confirm it is a bug.
> > > > Currently I'm just still not certain it is a nested bug or because of 
> > > > the
> > > > latest
> > > > osstest code change.
> > > > I was just asking for if you can recall some hint on what changes (of
> > > > osstest)
> > > > might causing this.
> > > > I'm to restore to my v12 code, with current Xen and qemu selection to
> try
> > > > again. I think by this way, I can confirm it is an actual nested bug or
> > > > not.
> > > > Then I would report this in a fresh thread.
> > >
> > [Hu, Robert]
> >
> > With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection,
> nested
> > test
> > passes.
> > I've saved l1 guest configuration, l1 network configuration, and l1 Dom0
> > kernel
> > config for further comparison. Anything else possibly related you can think
> > of?
> >
> > > A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
> > > whether it is exposed by a new osstest case or not. The people who are
> > best
> > > placed to figure out where the bug is are certainly not reading this
> > > osstest thread.
> > >
> > > So please just report it as a bug as it stands, with the relevant
> > > information.
> > [Hu, Robert]
> >
> > Nested Xen is in tech preview phase, not that production level matured.
> > It is so nit-picking that any configuration change not meeting its appetite
> will
> > induce its naughtiness, i.e. crash, I think. :)
> [Hu, Robert]
> 
> Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall
> be
> hvc0 in nested environment.
[Hu, Robert] 

A patch for this: in ts-xen-install, after exact kernel and xen, check if 
'kernkind'
for this host exist, if not, set it with existing runvar.
The hvc0 --> xvc0 happens in debian_boot_setup() --> target_kernkind_check().
If 'kernkind' runvar for host is missing, the existing code will set it to xvc0.
For our pvops kernel, it shall be hvc0.

diff --git a/ts-xen-install b/ts-xen-install
index 3d0f394..eb40c1e 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -79,6 +79,15 @@ sub extract () {
$r{"$ho->{Ident}_${part}buildjob"} // $r{"${part}buildjob"},
\%distpath);
 }
+
+if (!target_var($ho, 'kernkind'))
+{
+

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-26 Thread Hu, Robert 
> -Original Message-
> From: Hu, Robert
> Sent: Sunday, October 25, 2015 10:46 AM
> To: Ian Campbell ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
> 
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Friday, October 23, 2015 9:38 PM
> > To: Hu, Robert ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> > 
> > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > > > -Original Message-
> > > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > > Sent: Friday, October 23, 2015 4:15 PM
> > > > To: Hu, Robert ; 'Ian Jackson'
> > > > ; 'xen-de...@lists.xenproject.org'
> > > > 
> > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > > `nodhcp' to `ensurebridge'
> > > >
> > > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> > > >
> > > > > [Hu, Robert]
> > > > > Seems the failure log shall be this, any idea? I've spent days on
> > > > > debugging this:(
> > > > > (XEN) traps.c:3290: GPF (): 82d080195082 ->
> 82d080243d9d
> > > > > (XEN) PCI add device :00:00.0
> > > > > (XEN) PCI add device :00:01.0
> > > > > (XEN) PCI add device :00:01.1
> > > > > (XEN) PCI add device :00:01.2
> > > > > (XEN) PCI add device :00:01.3
> > > > > (XEN) PCI add device :00:02.0
> > > > > (XEN) PCI add device :00:03.0
> > > > > (XEN) d0: Forcing read-only access to MFN fed00
> > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > > > Issued domain 3 reboot
> > > > > qemu: terminating on signal 1 from pid 4322
> > > >
> > > > Please can you report this as a regular bug in a fresh thread, that way
> > > > the relevant Xen maintainers are likely to see and react to it, rather
> > > > than just us osstest folks.
> > > [Hu, Robert]
> > >
> > > It shall be in that way after I confirm it is a bug.
> > > Currently I'm just still not certain it is a nested bug or because of the
> > > latest
> > > osstest code change.
> > > I was just asking for if you can recall some hint on what changes (of
> > > osstest)
> > > might causing this.
> > > I'm to restore to my v12 code, with current Xen and qemu selection to try
> > > again. I think by this way, I can confirm it is an actual nested bug or
> > > not.
> > > Then I would report this in a fresh thread.
> >
> [Hu, Robert]
> 
> With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection, nested
> test
> passes.
> I've saved l1 guest configuration, l1 network configuration, and l1 Dom0
> kernel
> config for further comparison. Anything else possibly related you can think
> of?
> 
> > A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
> > whether it is exposed by a new osstest case or not. The people who are
> best
> > placed to figure out where the bug is are certainly not reading this
> > osstest thread.
> >
> > So please just report it as a bug as it stands, with the relevant
> > information.
> [Hu, Robert]
> 
> Nested Xen is in tech preview phase, not that production level matured.
> It is so nit-picking that any configuration change not meeting its appetite 
> will
> induce its naughtiness, i.e. crash, I think. :)
[Hu, Robert] 

Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall be
hvc0 in nested environment.

> >
> > Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-26 Thread Hu, Robert 
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, October 27, 2015 12:29 AM
> To: Hu, Robert 
> Cc: 'Ian Campbell' ;
> 'xen-de...@lists.xenproject.org' 
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> Hu, Robert writes ("RE: [OSSTEST PATCH 26/26] ts-xen-install: networking:
> Rename `nodhcp' to `ensurebridge'"):
> > > From: Hu, Robert
> ...
> > > Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters,
> shall
> > > be
> > > hvc0 in nested environment.
> > [Hu, Robert]
> 
> Thanks for the update.  I'm glad to hear you seem to be making
> good progress.
> 
> I think from reading this thread that this is not in fact a bug in
> anything except your osstest series, because the dom0 that is dying is
> the L1 ?  I think it's just dying because it can't find its console.
> Is that right ?
[Hu, Robert] 

It must miss something in re-constructing patch from v12, which works
well.
Yes, dying Dom0 is L1. It is dying because it try to use xvc0 as console
while its kernkind is pvops.

> 
> 
> > A patch for this: in ts-xen-install, after exact kernel and xen,
> > check if 'kernkind' for this host exist, if not, set it with
> > existing runvar.
> 
> I think that it would be better to change the default for kernkind.
> 
> At the moment kernkind runvars are looked at only in
> target_kernkind_check, which has three possible paths:
> 
> (a) eq 'pvops'
> (b) m/2618/
> (c) the rest (including undef, although undef prints a warning)
> 
> I propose to change the semantics of a missing kernkind runvar from
> (c) to (a).
> 
> 
> This is safe only if no existing flights would be affected.  (That is,
> the meaning of no existing sets of runvars would be changed.)
> 
> To check whether this would make any difference I did some database
> searches.  Since any time target_kernkind_check is called it sets a
> corresponding `console' runvar, I can search for `console' without a
> corresponding `kernkind'.  I ran this query:
> 
>   select * from (select *, (select name from runvars r2 where
>   r2.flight=r1.flight and r2.job=r1.job and r2.name=
>   replace(r1.name,'console','kernkind')) kk from runvars r1 where
>   r1.name like '%console') iq where kk is null order by flight desc;
> 
> and it found nothing since flight 7682.  So I think we can change the
> default.
> 
> 
> I therefore suggest something like this:
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index f9eba6b..48b8ffd 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -2006,7 +2006,7 @@ sub target_var ($$) {
>  sub target_kernkind_check ($) {
>  my ($gho) = @_;
>  my $pfx= target_var_prefix($gho);
> -my $kernkind= $r{$pfx."kernkind"};
> +my $kernkind= $r{$pfx."kernkind"} // 'pvops';
>  my $isguest= exists $gho->{Guest};
>  if ($kernkind eq 'pvops') {
>  store_runvar($pfx."rootdev", 'xvda') if $isguest;
> 
> 
> If you agree and this works for you please put that into your series
> with a proper commit message.  Please quote my words about existing
> flights (including the database query etc.) in the commit message.
[Hu, Robert] 

Sure.
Tested-by: Robert Hu 

> 
> Signed-off-by: Ian Jackson 
> 
> 
> Thanks,
> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-26 Thread Ian Jackson 
Hu, Robert writes ("RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: 
Rename `nodhcp' to `ensurebridge'"):
> > From: Hu, Robert
...
> > Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall
> > be
> > hvc0 in nested environment.
> [Hu, Robert] 

Thanks for the update.  I'm glad to hear you seem to be making
good progress.

I think from reading this thread that this is not in fact a bug in
anything except your osstest series, because the dom0 that is dying is
the L1 ?  I think it's just dying because it can't find its console.
Is that right ?


> A patch for this: in ts-xen-install, after exact kernel and xen,
> check if 'kernkind' for this host exist, if not, set it with
> existing runvar.

I think that it would be better to change the default for kernkind.

At the moment kernkind runvars are looked at only in
target_kernkind_check, which has three possible paths:

(a) eq 'pvops'
(b) m/2618/
(c) the rest (including undef, although undef prints a warning)

I propose to change the semantics of a missing kernkind runvar from
(c) to (a).


This is safe only if no existing flights would be affected.  (That is,
the meaning of no existing sets of runvars would be changed.)

To check whether this would make any difference I did some database
searches.  Since any time target_kernkind_check is called it sets a
corresponding `console' runvar, I can search for `console' without a
corresponding `kernkind'.  I ran this query:

  select * from (select *, (select name from runvars r2 where
  r2.flight=r1.flight and r2.job=r1.job and r2.name=
  replace(r1.name,'console','kernkind')) kk from runvars r1 where
  r1.name like '%console') iq where kk is null order by flight desc;

and it found nothing since flight 7682.  So I think we can change the
default.


I therefore suggest something like this:

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f9eba6b..48b8ffd 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2006,7 +2006,7 @@ sub target_var ($$) {
 sub target_kernkind_check ($) {
 my ($gho) = @_;
 my $pfx= target_var_prefix($gho);
-my $kernkind= $r{$pfx."kernkind"};
+my $kernkind= $r{$pfx."kernkind"} // 'pvops';
 my $isguest= exists $gho->{Guest};
 if ($kernkind eq 'pvops') {
 store_runvar($pfx."rootdev", 'xvda') if $isguest;


If you agree and this works for you please put that into your series
with a proper commit message.  Please quote my words about existing
flights (including the database query etc.) in the commit message.

Signed-off-by: Ian Jackson 


Thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-24 Thread Hu, Robert 
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, October 23, 2015 9:38 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
> 
> Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > > -Original Message-
> > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > Sent: Friday, October 23, 2015 4:15 PM
> > > To: Hu, Robert ; 'Ian Jackson'
> > > ; 'xen-de...@lists.xenproject.org'
> > > 
> > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp' to `ensurebridge'
> > >
> > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> > >
> > > > [Hu, Robert]
> > > > Seems the failure log shall be this, any idea? I've spent days on
> > > > debugging this:(
> > > > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > > > (XEN) PCI add device :00:00.0
> > > > (XEN) PCI add device :00:01.0
> > > > (XEN) PCI add device :00:01.1
> > > > (XEN) PCI add device :00:01.2
> > > > (XEN) PCI add device :00:01.3
> > > > (XEN) PCI add device :00:02.0
> > > > (XEN) PCI add device :00:03.0
> > > > (XEN) d0: Forcing read-only access to MFN fed00
> > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > > Issued domain 3 reboot
> > > > qemu: terminating on signal 1 from pid 4322
> > >
> > > Please can you report this as a regular bug in a fresh thread, that way
> > > the relevant Xen maintainers are likely to see and react to it, rather
> > > than just us osstest folks.
> > [Hu, Robert]
> >
> > It shall be in that way after I confirm it is a bug.
> > Currently I'm just still not certain it is a nested bug or because of the
> > latest
> > osstest code change.
> > I was just asking for if you can recall some hint on what changes (of
> > osstest)
> > might causing this.
> > I'm to restore to my v12 code, with current Xen and qemu selection to try
> > again. I think by this way, I can confirm it is an actual nested bug or
> > not.
> > Then I would report this in a fresh thread.
> 
[Hu, Robert] 

With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection, nested test
passes.
I've saved l1 guest configuration, l1 network configuration, and l1 Dom0 kernel
config for further comparison. Anything else possibly related you can think of?

> A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
> whether it is exposed by a new osstest case or not. The people who are best
> placed to figure out where the bug is are certainly not reading this
> osstest thread.
> 
> So please just report it as a bug as it stands, with the relevant
> information.
[Hu, Robert] 

Nested Xen is in tech preview phase, not that production level matured.
It is so nit-picking that any configuration change not meeting its appetite will
induce its naughtiness, i.e. crash, I think. :)
> 
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-23 Thread Hu, Robert 
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, October 23, 2015 4:15 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
> 
> Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> 
> > [Hu, Robert]
> > Seems the failure log shall be this, any idea? I've spent days on
> > debugging this:(
> > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > (XEN) PCI add device :00:00.0
> > (XEN) PCI add device :00:01.0
> > (XEN) PCI add device :00:01.1
> > (XEN) PCI add device :00:01.2
> > (XEN) PCI add device :00:01.3
> > (XEN) PCI add device :00:02.0
> > (XEN) PCI add device :00:03.0
> > (XEN) d0: Forcing read-only access to MFN fed00
> > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > Issued domain 3 reboot
> > qemu: terminating on signal 1 from pid 4322
> 
> Please can you report this as a regular bug in a fresh thread, that way
> the relevant Xen maintainers are likely to see and react to it, rather
> than just us osstest folks.
[Hu, Robert] 

It shall be in that way after I confirm it is a bug.
Currently I'm just still not certain it is a nested bug or because of the latest
osstest code change.
I was just asking for if you can recall some hint on what changes (of osstest)
might causing this.
I'm to restore to my v12 code, with current Xen and qemu selection to try
again. I think by this way, I can confirm it is an actual nested bug or not.
Then I would report this in a fresh thread.

> 
> Please include whatever information you can, e.g. the guest config file
> used, details about the type of guest, which level of nesting this is
> happening at, the contents of any logs under /var/log/xen in L0 and L1
> host etc.
[Hu, Robert] 

Yes, sure. I will include these in bug reporting.

> 
> If this crash is in an L1 host then you might also want to CC the
> nested hvm maintainers at Intel.
[Hu, Robert] 
Yes, thanks for remind.

> 
> See http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
> for general advice on reporting a bug and other things to consider
> including.
> 
> Thanks,
> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-23 Thread Ian Campbell 
On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Friday, October 23, 2015 4:15 PM
> > To: Hu, Robert ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> > 
> > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> > 
> > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> > 
> > > [Hu, Robert]
> > > Seems the failure log shall be this, any idea? I've spent days on
> > > debugging this:(
> > > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > > (XEN) PCI add device :00:00.0
> > > (XEN) PCI add device :00:01.0
> > > (XEN) PCI add device :00:01.1
> > > (XEN) PCI add device :00:01.2
> > > (XEN) PCI add device :00:01.3
> > > (XEN) PCI add device :00:02.0
> > > (XEN) PCI add device :00:03.0
> > > (XEN) d0: Forcing read-only access to MFN fed00
> > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > Issued domain 3 reboot
> > > qemu: terminating on signal 1 from pid 4322
> > 
> > Please can you report this as a regular bug in a fresh thread, that way
> > the relevant Xen maintainers are likely to see and react to it, rather
> > than just us osstest folks.
> [Hu, Robert] 
> 
> It shall be in that way after I confirm it is a bug.
> Currently I'm just still not certain it is a nested bug or because of the
> latest
> osstest code change.
> I was just asking for if you can recall some hint on what changes (of
> osstest)
> might causing this.
> I'm to restore to my v12 code, with current Xen and qemu selection to try
> again. I think by this way, I can confirm it is an actual nested bug or
> not.
> Then I would report this in a fresh thread.

A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
whether it is exposed by a new osstest case or not. The people who are best
placed to figure out where the bug is are certainly not reading this
osstest thread.

So please just report it as a bug as it stands, with the relevant
information.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-23 Thread Hu, Robert 
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 22, 2015 10:33 AM
> To: 'Ian Jackson' ;
> 'xen-de...@lists.xenproject.org' 
> Cc: 'Ian Campbell' 
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> > -Original Message-
> > From: Hu, Robert
> > Sent: Thursday, October 15, 2015 5:58 PM
> > To: Ian Jackson ;
> > xen-de...@lists.xenproject.org
> > Cc: Ian Campbell 
> > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > > -Original Message-
> > > From: Hu, Robert
> > > Sent: Thursday, October 15, 2015 5:39 PM
> > > To: 'Ian Jackson' ;
> > > xen-de...@lists.xenproject.org
> > > Cc: Ian Campbell 
> > > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp' to `ensurebridge'
> > >
> > > > -Original Message-
> > > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > > Sent: Saturday, September 26, 2015 3:15 AM
> > > > To: xen-de...@lists.xenproject.org
> > > > Cc: Hu, Robert ; Ian Campbell
> > > > ; Ian Jackson ;
> > Ian
> > > > Jackson 
> > > > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp'
> > > > to `ensurebridge'
> > > >
> > > > This function does not (now) always undo the DHCP configuration.
> > > > Sometimes it leaves it.  Its main function is to ensure that we have
> > > > a bridge for use by guests.
> > > >
> > > > So rename the function.
> > > >
> > > > Signed-off-by: Ian Jackson 
> > > > ---
> > > > v14: This patch was previously 4/4 of a miniature series containing
> > > >   a different way of dealing with the Nested HVM L1 DHCP
> > problem.
> > > > ---
> > > >  ts-xen-install |4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/ts-xen-install b/ts-xen-install
> > > > index d9aa694..3d0f394 100755
> > > > --- a/ts-xen-install
> > > > +++ b/ts-xen-install
> > > > @@ -247,7 +247,7 @@ sub hosts () {
> > > >  });
> > > >  }
> > > >
> > > > -sub nodhcp () {
> > > > +sub ensurebridge () {
> > > >  target_editfile_root($ho, "/etc/network/interfaces",
> > > >   "etc-network-interfaces", sub {
> > > >  my $physif= get_host_property($ho,'interface
> force',undef);
> > > > @@ -370,6 +370,6 @@ if ($checkmode) {
> > > >  adjustconfig();
> > > >  setupboot();
> > > >  setupinitd();
> > > > -nodhcp();
> > > > +ensurebridge();
> > > >  hosts();
> > > >  }
> > > [Hu, Robert]
> > > Not sure if it is caused by this patch, but after Xen installed in L1, 
> > > after L1
> > > reboot,
> > > it boots fail.
> > >
> > > Here is log dumped in L0:
> > > (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> > > LCHS=1024/255/63 s=2048
> > > (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> > > s=4096
> > > (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> > > (d53) Returned 258048 bytes of ZoneHigh
> > > (d53) e820 map has 6 items:
> > > (d53)   0:  - 0009fc00 = 1 RAM
> > > (d53)   1: 0009fc00 - 000a = 2 RESERVED
> > > (d53)   2: 000f - 0010 = 2 RESERVED
> > > (d53)   3: 0010 - bf7ff000 = 1 RAM
> > > (d53)   4: bf7ff000 - bf80 = 2 RESERVED
> > > (d53)   5: fc00 - 0001 = 2 RESERVED
> > > (d53) enter handle_19:
> > > (d53)   NULL
> > > (d53) Booting from DVD/CD...
> > > (d53) Boot failed: Could not read from CDROM (code 0004)
> > > (d53) enter handle_18:
> > > (d53)   NULL
> > > (d53) Booting from Hard Disk...
> > > (d53) Booting from :7c00
> > > (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> > > (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> > > (XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
> > > (XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
> > > (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> > > (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> > >
> >
> > I'm using latest xen.git master. Will try again with Xen 4.6 release which 
> > we
> > have
> > tested.
> [Hu, Robert]
> After fixed several environment setting issues, I just run OSSTest on Xen 
> 4.6.0
> release code. This issue still exist there, so this is probably the new patch
> which
> introduced this.


[Hu, Robert] 
Seems the failure log shall be this, any idea? I've spent days on debugging 
this:(
(XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
(XEN) PCI add device :00:00.0
(XEN) PCI add device :00:01.0
(XEN) PCI add device :00:01.1
(XEN) PCI add device

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-23 Thread Ian Campbell 
On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:

> [Hu, Robert] 
> Seems the failure log shall be this, any idea? I've spent days on
> debugging this:(
> (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> (XEN) PCI add device :00:00.0
> (XEN) PCI add device :00:01.0
> (XEN) PCI add device :00:01.1
> (XEN) PCI add device :00:01.2
> (XEN) PCI add device :00:01.3
> (XEN) PCI add device :00:02.0
> (XEN) PCI add device :00:03.0
> (XEN) d0: Forcing read-only access to MFN fed00
> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> Issued domain 3 reboot
> qemu: terminating on signal 1 from pid 4322

Please can you report this as a regular bug in a fresh thread, that way
the relevant Xen maintainers are likely to see and react to it, rather
than just us osstest folks.

Please include whatever information you can, e.g. the guest config file
used, details about the type of guest, which level of nesting this is
happening at, the contents of any logs under /var/log/xen in L0 and L1
host etc.

If this crash is in an L1 host then you might also want to CC the
nested hvm maintainers at Intel.

See http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project 
for general advice on reporting a bug and other things to consider
including.

Thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-21 Thread Hu, Robert 
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 15, 2015 5:58 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell 
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> > -Original Message-
> > From: Hu, Robert
> > Sent: Thursday, October 15, 2015 5:39 PM
> > To: 'Ian Jackson' ;
> > xen-de...@lists.xenproject.org
> > Cc: Ian Campbell 
> > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Saturday, September 26, 2015 3:15 AM
> > > To: xen-de...@lists.xenproject.org
> > > Cc: Hu, Robert ; Ian Campbell
> > > ; Ian Jackson ;
> Ian
> > > Jackson 
> > > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp'
> > > to `ensurebridge'
> > >
> > > This function does not (now) always undo the DHCP configuration.
> > > Sometimes it leaves it.  Its main function is to ensure that we have
> > > a bridge for use by guests.
> > >
> > > So rename the function.
> > >
> > > Signed-off-by: Ian Jackson 
> > > ---
> > > v14: This patch was previously 4/4 of a miniature series containing
> > >   a different way of dealing with the Nested HVM L1 DHCP
> problem.
> > > ---
> > >  ts-xen-install |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/ts-xen-install b/ts-xen-install
> > > index d9aa694..3d0f394 100755
> > > --- a/ts-xen-install
> > > +++ b/ts-xen-install
> > > @@ -247,7 +247,7 @@ sub hosts () {
> > >  });
> > >  }
> > >
> > > -sub nodhcp () {
> > > +sub ensurebridge () {
> > >  target_editfile_root($ho, "/etc/network/interfaces",
> > >   "etc-network-interfaces", sub {
> > >  my $physif= get_host_property($ho,'interface force',undef);
> > > @@ -370,6 +370,6 @@ if ($checkmode) {
> > >  adjustconfig();
> > >  setupboot();
> > >  setupinitd();
> > > -nodhcp();
> > > +ensurebridge();
> > >  hosts();
> > >  }
> > [Hu, Robert]
> > Not sure if it is caused by this patch, but after Xen installed in L1, 
> > after L1
> > reboot,
> > it boots fail.
> >
> > Here is log dumped in L0:
> > (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> > LCHS=1024/255/63 s=2048
> > (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> > s=4096
> > (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> > (d53) Returned 258048 bytes of ZoneHigh
> > (d53) e820 map has 6 items:
> > (d53)   0:  - 0009fc00 = 1 RAM
> > (d53)   1: 0009fc00 - 000a = 2 RESERVED
> > (d53)   2: 000f - 0010 = 2 RESERVED
> > (d53)   3: 0010 - bf7ff000 = 1 RAM
> > (d53)   4: bf7ff000 - bf80 = 2 RESERVED
> > (d53)   5: fc00 - 0001 = 2 RESERVED
> > (d53) enter handle_19:
> > (d53)   NULL
> > (d53) Booting from DVD/CD...
> > (d53) Boot failed: Could not read from CDROM (code 0004)
> > (d53) enter handle_18:
> > (d53)   NULL
> > (d53) Booting from Hard Disk...
> > (d53) Booting from :7c00
> > (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> > (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> > (XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
> > (XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
> > (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> > (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> >
> 
> I'm using latest xen.git master. Will try again with Xen 4.6 release which we
> have
> tested.
[Hu, Robert] 
After fixed several environment setting issues, I just run OSSTest on Xen 4.6.0
release code. This issue still exist there, so this is probably the new patch 
which
introduced this.

> 
> >
> > > --
> > > 1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-15 Thread Hu, Robert 
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson 
> Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp'
> to `ensurebridge'
> 
> This function does not (now) always undo the DHCP configuration.
> Sometimes it leaves it.  Its main function is to ensure that we have
> a bridge for use by guests.
> 
> So rename the function.
> 
> Signed-off-by: Ian Jackson 
> ---
> v14: This patch was previously 4/4 of a miniature series containing
>   a different way of dealing with the Nested HVM L1 DHCP problem.
> ---
>  ts-xen-install |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ts-xen-install b/ts-xen-install
> index d9aa694..3d0f394 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -247,7 +247,7 @@ sub hosts () {
>  });
>  }
> 
> -sub nodhcp () {
> +sub ensurebridge () {
>  target_editfile_root($ho, "/etc/network/interfaces",
>   "etc-network-interfaces", sub {
>  my $physif= get_host_property($ho,'interface force',undef);
> @@ -370,6 +370,6 @@ if ($checkmode) {
>  adjustconfig();
>  setupboot();
>  setupinitd();
> -nodhcp();
> +ensurebridge();
>  hosts();
>  }
[Hu, Robert] 
Not sure if it is caused by this patch, but after Xen installed in L1, after L1 
reboot,
it boots fail.

Here is log dumped in L0:
(d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 
s=2048
(d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=4096
(d53) Space available for UMB: ca800-ee800, f5d80-f62d0
(d53) Returned 258048 bytes of ZoneHigh
(d53) e820 map has 6 items:
(d53)   0:  - 0009fc00 = 1 RAM
(d53)   1: 0009fc00 - 000a = 2 RESERVED
(d53)   2: 000f - 0010 = 2 RESERVED
(d53)   3: 0010 - bf7ff000 = 1 RAM
(d53)   4: bf7ff000 - bf80 = 2 RESERVED
(d53)   5: fc00 - 0001 = 2 RESERVED
(d53) enter handle_19:
(d53)   NULL
(d53) Booting from DVD/CD...
(d53) Boot failed: Could not read from CDROM (code 0004)
(d53) enter handle_18:
(d53)   NULL
(d53) Booting from Hard Disk...
(d53) Booting from :7c00
(XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
(XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
(XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
(XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
(XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
(XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b


> --
> 1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-15 Thread Hu, Robert 
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 15, 2015 5:39 PM
> To: 'Ian Jackson' ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell 
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson ; Ian
> > Jackson 
> > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp'
> > to `ensurebridge'
> >
> > This function does not (now) always undo the DHCP configuration.
> > Sometimes it leaves it.  Its main function is to ensure that we have
> > a bridge for use by guests.
> >
> > So rename the function.
> >
> > Signed-off-by: Ian Jackson 
> > ---
> > v14: This patch was previously 4/4 of a miniature series containing
> >   a different way of dealing with the Nested HVM L1 DHCP problem.
> > ---
> >  ts-xen-install |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/ts-xen-install b/ts-xen-install
> > index d9aa694..3d0f394 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -247,7 +247,7 @@ sub hosts () {
> >  });
> >  }
> >
> > -sub nodhcp () {
> > +sub ensurebridge () {
> >  target_editfile_root($ho, "/etc/network/interfaces",
> >   "etc-network-interfaces", sub {
> >  my $physif= get_host_property($ho,'interface force',undef);
> > @@ -370,6 +370,6 @@ if ($checkmode) {
> >  adjustconfig();
> >  setupboot();
> >  setupinitd();
> > -nodhcp();
> > +ensurebridge();
> >  hosts();
> >  }
> [Hu, Robert]
> Not sure if it is caused by this patch, but after Xen installed in L1, after 
> L1
> reboot,
> it boots fail.
> 
> Here is log dumped in L0:
> (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> LCHS=1024/255/63 s=2048
> (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> s=4096
> (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> (d53) Returned 258048 bytes of ZoneHigh
> (d53) e820 map has 6 items:
> (d53)   0:  - 0009fc00 = 1 RAM
> (d53)   1: 0009fc00 - 000a = 2 RESERVED
> (d53)   2: 000f - 0010 = 2 RESERVED
> (d53)   3: 0010 - bf7ff000 = 1 RAM
> (d53)   4: bf7ff000 - bf80 = 2 RESERVED
> (d53)   5: fc00 - 0001 = 2 RESERVED
> (d53) enter handle_19:
> (d53)   NULL
> (d53) Booting from DVD/CD...
> (d53) Boot failed: Could not read from CDROM (code 0004)
> (d53) enter handle_18:
> (d53)   NULL
> (d53) Booting from Hard Disk...
> (d53) Booting from :7c00
> (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> (XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
> (XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
> (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> 

I'm using latest xen.git master. Will try again with Xen 4.6 release which we 
have
tested.

> 
> > --
> > 1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-09-28 Thread Ian Campbell 
On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> This function does not (now) always undo the DHCP configuration.
> Sometimes it leaves it.  Its main function is to ensure that we have
> a bridge for use by guests.
> 
> So rename the function.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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