[Bug 215209] Kernel panic at boot under XEN: integer divide fault while in kernel mode

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215209

--- Comment #7 from commit-h...@freebsd.org ---
A commit references this bug:

Author: cperciva
Date: Tue Dec 13 06:54:14 UTC 2016
New revision: 310013
URL: https://svnweb.freebsd.org/changeset/base/310013

Log:
  Check that blkfront devices have a non-zero number of sectors and a
  non-zero sector size.  Such a device would be a virtual disk of zero
  bytes; clearly not useful, and not something we should try to attach.

  As a fortuitous side effect, checking that these values are non-zero
  here results in them not *becoming* zero later on the function.  This
  odd behaviour began with r309124 (clang 3.9.0) but is challenging to
  debug; making any changes to this function whatsoever seems to affect
  the llvm optimizer behaviour enough to make the unexpected zeroing of
  the sector_size variable cease.

  PR:   215209
  Security: The potential for variables to unexpectedly become zero
has worrying consequences for security in general, but
not so much in this particular context.

Changes:
  head/sys/dev/xen/blkfront/blkfront.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: [PATCH]netfront: need release all resources after adding and removing NICs time and again

[liuyingdong]

Hello Roger,
I want to know how about this patch,Please let me know if you have any 
questions.
Thanks.

  Yours

On 2016/11/11 10:04, liuyingdong wrote:
> Hello Roger,
>   Sorry, I am a freshman. I ran the following command to git kernel 
> source of freebsd 10.2.0:
>   git clone https://github.com/freebsd/freebsd.git
>   git checkout origin/release/10.2.0
>   On the base of the above, I make a patch file as fellows:
> 
> diff --git a/sys/dev/xen/netfront/netfront.c b/sys/dev/xen/netfront/netfront.c
> index d89c0e0..903eb98 100644
> --- a/sys/dev/xen/netfront/netfront.c
> +++ b/sys/dev/xen/netfront/netfront.c
> @@ -2172,6 +2172,46 @@ netfront_detach(device_t dev)
>  }
> 
>  static void
> +netif_release_rx_bufs_copy(struct netfront_info *np)
> +{
> + struct mbuf *m;
> + int i, ref;
> + int busy = 0, inuse = 0;
> +
> + XN_RX_LOCK(np);
> +
> + for (i = 0; i < NET_RX_RING_SIZE; i++) {
> + ref = np->grant_rx_ref[i];
> +
> + if (ref == GRANT_REF_INVALID)
> + continue;
> +
> + inuse++;
> +
> + m = np->rx_mbufs[i];
> +
> + if (!gnttab_end_foreign_access_ref(ref))
> + {
> + busy++;
> + continue;
> + }
> +
> + gnttab_release_grant_reference(>gref_rx_head, ref);
> + np->grant_rx_ref[i] = GRANT_REF_INVALID;
> + add_id_to_freelist(np->rx_mbufs, i);
> +
> + m_freem(m);
> + }
> +
> + if (busy)
> + device_printf(np->xbdev, "Unable to release %d of %d "
> + "inuse grant references out of %ld total.\n",
> + busy, inuse, NET_RX_RING_SIZE);
> + 
> + XN_RX_UNLOCK(np);
> +}
> +
> +static void
>  netif_free(struct netfront_info *info)
>  {
>   XN_LOCK(info);
> @@ -2185,6 +2225,13 @@ netif_free(struct netfront_info *info)
>   info->xn_ifp = NULL;
>   }
>   ifmedia_removeall(>sc_media);
> + 
> + netif_release_tx_bufs(info);
> + if (info->copying_receiver)
> + netif_release_rx_bufs_copy(info);
> +
> + gnttab_free_grant_references(info->gref_tx_head);
> + gnttab_free_grant_references(info->gref_rx_head);
>  }
> 
>  static void
> 
> 
> Yours Yingdong Liu
> 
> 
> -邮件原件-
> 发件人: roger@citrix.com [mailto:roger@citrix.com]
> 发送时间: 2016年11月8日 21:05
> 收件人: Liuyingdong
> 抄送: freebsd-xen@freebsd.org; Zhaojun (Euler); Suoben
> 主题: Re: [PATCH]netfront: need release all resources after adding and removing 
> NICs time and again
> 
> On Fri, Nov 04, 2016 at 07:43:41AM +, Liuyingdong wrote:
>> On xen,freebsd 10.2 virtual machines hang after adding and removing NICs 
>> time and again(more than 30 times).
>> I found error log is as follows:
>> "netfront can't alloc tx grant refs"
> 
> Hello,
> 
> Thanks for the patch, although I'm not able to import it, git complain with:
> 
> patch:  malformed patch at line 7: }
> 
> Could you please resend it using git send-email?
> 
> I also have a couple of comments below regarding style.
> 
>>
>> Signed-off-by: Yingdong Liu
>>
>> diff --git a/dev/xen/netfront/netfront.c b/dev/xen/netfront/netfront.c
>> index 5497139..e96bbba 100644
>> --- a/dev/xen/netfront/netfront.c
>> +++ b/dev/xen/netfront/netfront.c
>> @@ -790,6 +790,44 @@ netif_release_tx_bufs(struct netfront_info *np)
>>}
>> }
> 
> Missing new line.
> 
>> +static void
> netif_release_rx_bufs_copy(struct netfront_info *np)
> 
> This needs to be on a new line.
> 
>> +{
>> +   struct mbuf *m;
>> +   int i, ref;
>> +   int busy = 0, inuse = 0;
>> +
>> +   XN_RX_LOCK(np);
>> +
>> +   for (i = 0; i < NET_RX_RING_SIZE; i++) {
>> +ref = np->grant_rx_ref[i];
>> +
>> +if (ref == GRANT_REF_INVALID)
>> +  continue;
>> +
>> +inuse++;
>> +
>> +m = np->rx_mbufs[i];
>> +
>> +if (!gnttab_end_foreign_access_ref(ref))
>> +{
>> +  busy++;
>> +  continue;
>> +}
>> +
>> +gnttab_release_grant_reference(>gref_rx_head, ref);
>> +np->grant_rx_ref[i] = GRANT_REF_INVALID;
>> +add_id_to_freelist(np->rx_mbufs, i);
>> +
>> +m_freem(m);
>> +   }
>> +
>> +   if (busy)
>> +DPRINTK("%s: Unable to release %d of %d inuse grant 
>> references out of %ld total.\n",
>> +  __FUNCTION__, busy, inuse,
>> + NET_RX_RING_SIZE);
> 
> Please use device_printf for this instead of the function name. Also, could 
> you align the string so it doesn't extend past 80 characters?
> 
> Roger.
> 

___
freebsd-xen@freebsd.org mailing list

[Bug 215209] Kernel panic at boot under XEN: integer divide fault while in kernel mode

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215209

--- Comment #6 from Sylvain Garrigues  ---
(In reply to Colin Percival from comment #5)

I had a system running CURRENT as of Nov. 3 so it was pre-r309124 and I
upgraded to CURRENT as of Dec. 10.

At first since the machine didn't survive a reboot I thought I did a bad
mergemaster on passwd files. So I installed a fresh EC2 AMI which also happened
to be from CURRENT-amd64-2016-12-10 and I had the same issue. I looked at the
console and saw the kernel panic.

Tried the EC2 AMI from CURRENT-amd64-2016-11-30, same problem.
Finally tried the EC2 AMI from CURRENT-amd64-2016-11-01, NO problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

[Bug 215209] Kernel panic at boot under XEN: integer divide fault while in kernel mode

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215209

--- Comment #4 from Roger Pau Monné  ---
I don't seem to be able to reproduce this with r309875, can you check if you
still get the panic with that or any later revision?

Thanks, Roger.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

RE: 11-RELEASE and live migration

[Jay West]

My setup...

Hosts: Two Dell R310's, each one as follows: 32gb ram, L3480 cpu, 4 gigabit
nics, two 300gb disks (mirrored), where the local disk is used only to hold
xenserver 7.0 with all patches up through and including today. These
machines are 100% up to date on firmware, patches, bios, etc.

Network: Two Dell powerconnect 6224's, stacked via dual round-robin CX4
cables. There's an untagged management vlan, an untagged data vlan, and an
untagged ISCSI vlan - identical ports are members on each switch. On each
host, the two builtin nics (data) are connected one leg in each switch (same
vlan). The two addin ports (Intel Pro/1000) (iSCSI) on each host are also
connected one leg in each switch. The switches are 100% up to date on
firmware/OS. Client access to this is via a stack of Juniper EX2200's
trunked back to the 6224's.

Storage: OEM version of a Tyan 2U 12 bay SAS box, similar to Tyan
S8226WGM3NR but with 7 gigabit NICS builtin. 32gb ram, FreeNAS 9.10.1-U4,
and dual AMD C32's (12 cores total). One nic is used for ILO, another for
management, another is unused , and the remaining four gigabit ports are
connected two legs in each switch (same vlan, iscsi only, 9000mtu).
Multipath is configured and active.

The storage box is using mirrored vdev's with ZFS on top, 100% of which
present an iSCSI target so the box is doing nothing but iscsi (and an NFS
iso share for installing vm's). So in Xencenter... there is one storage
repository containing all the NAS space. Xencenter then creates the vdisks
inside that for each VM to use.

FreeBSD 10X doesn't seem to have this problem. FreeBSD11 definitely does,
and apparently I'm not the only one who can see it. I should also point out
that Windows VM's (both Server 2012 R2 and 7 pro - both 64bit) have no
problem migrating to another host and then back. And FreeBSD can definitely
migrate to another host - just not then back to the first (at least...
immediately. I haven't tried waiting an hour or so and then trying the
migration back).

I also cannot select the source host as the destination in Xencenter. The
host servers are completely identical in every respect. All vm's disk is via
iSCSI as above.

I also have a completely separate architecture that is identical to the
above, except much larger, using xenserver 6.5, HP DL1000's, and cisco 3750G
stacks. I have not yet tested freebsd11 on that installation; I assumed it
wouldn't be much help as it's older versions of all the code.

The smaller architecture above is not yet in production, so I can do testing
on it. The larger installation mentioned later above is production, and I
can't do much major testing there.

Hopefully some of this info helps!

J
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org]
On Behalf Of Hoyer-Reuther, Christian
Sent: Monday, December 12, 2016 4:40 AM
To: Roger Pau Monné ; h...@dhcp-3-221.uk.xensource.com
Cc: freebsd-xen@freebsd.org; owner-freebsd-...@freebsd.org
Subject: Re: 11-RELEASE and live migration

Hello,

I cannot select the source host as destination when I migrate from
XenCenter.

All 3 hosts use the same hardware. Disk backend for all VMs is iSCSI.

Regards,

Christian

> -Ursprüngliche Nachricht-
> Von: Roger Pau Monné [mailto:roger@citrix.com]
> Gesendet: Montag, 12. Dezember 2016 11:32
> An: Hoyer-Reuther, Christian; h...@dhcp-3-221.uk.xensource.com
> Cc: freebsd-xen@freebsd.org; owner-freebsd-...@freebsd.org
> Betreff: Re: 11-RELEASE and live migration
> 
> On Thu, Dec 08, 2016 at 10:33:37AM +0100, Hoyer-Reuther, Christian wrote:
> > I did some tests and I see the problem too.
> >
> > XenServer 6.5 SP1 with almost all patches (3 hosts in pool), FreeBSD 
> > 11.0-
> RELEASE-p2, xe-guest-utilities-6.2.0_2 installed via pkg.
> >
> > First migration from host 3 to host 1 is ok.
> >
> > Some seconds later I start a new migration from host 1 to host 2 and 
> > when
> migration finishes (as seen in XenCenter) then the VM switches to the 
> VGABios screen ("Plex86/Bochs VGABios (PCI) current-cvs 01 Sep 2016 ...
> cirrus-compatible VGA is detected"). The VM seem to hang and does not 
> respond. In XenCenter I see that all the CPU's of the VM go up to 100 
> percent.
> >
> > Then after 17 minutes the VGABios screen disappears and I see the 
> > console,
> the CPU usage as seen in XenCenter goes down. I logged in as root 
> before I started the first migration and root is still logged in. So 
> it was a hang and not a reboot.
> >
> > 20 minutes later I start a new migration from host 2 to host 3 and 
> > the
> problem occurs again.
> >
> > This problem does not exist with 10.3-RELEASE on the same hosts.
> 
> Hello,
> 
> So far I've only tested local migration (migration using the same host 
> as source and destination), and that seems to work fine (I've done +50 
> consecutive migrations with only 10s separation between them). Is 
> there a change that you could also try to reproduce this with 

Re: 11-RELEASE and live migration

[Hoyer-Reuther, Christian]

Hello,

I cannot select the source host as destination when I migrate from XenCenter.

All 3 hosts use the same hardware. Disk backend for all VMs is iSCSI.

Regards,

Christian

> -Ursprüngliche Nachricht-
> Von: Roger Pau Monné [mailto:roger@citrix.com]
> Gesendet: Montag, 12. Dezember 2016 11:32
> An: Hoyer-Reuther, Christian; h...@dhcp-3-221.uk.xensource.com
> Cc: freebsd-xen@freebsd.org; owner-freebsd-...@freebsd.org
> Betreff: Re: 11-RELEASE and live migration
> 
> On Thu, Dec 08, 2016 at 10:33:37AM +0100, Hoyer-Reuther, Christian wrote:
> > I did some tests and I see the problem too.
> >
> > XenServer 6.5 SP1 with almost all patches (3 hosts in pool), FreeBSD 11.0-
> RELEASE-p2, xe-guest-utilities-6.2.0_2 installed via pkg.
> >
> > First migration from host 3 to host 1 is ok.
> >
> > Some seconds later I start a new migration from host 1 to host 2 and when
> migration finishes (as seen in XenCenter) then the VM switches to the
> VGABios screen ("Plex86/Bochs VGABios (PCI) current-cvs 01 Sep 2016 ...
> cirrus-compatible VGA is detected"). The VM seem to hang and does not
> respond. In XenCenter I see that all the CPU's of the VM go up to 100
> percent.
> >
> > Then after 17 minutes the VGABios screen disappears and I see the console,
> the CPU usage as seen in XenCenter goes down. I logged in as root before I
> started the first migration and root is still logged in. So it was a hang
> and not a reboot.
> >
> > 20 minutes later I start a new migration from host 2 to host 3 and the
> problem occurs again.
> >
> > This problem does not exist with 10.3-RELEASE on the same hosts.
> 
> Hello,
> 
> So far I've only tested local migration (migration using the same host as
> source
> and destination), and that seems to work fine (I've done +50
> consecutive migrations with only 10s separation between them). Is there a
> change
> that you could also try to reproduce this with local migration?
> 
> Are you using the same exact hardware on the source and the destination? Are
> you
> all using iSCSI as the disk backend for this VMs?
> 
> Thanks, Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: 11-RELEASE acting as vbd backend

[Roger Pau Monné]

On Fri, Dec 09, 2016 at 09:32:17AM -0700, Nathan Friess wrote:
> On 16-12-09 07:46 AM, Roger Pau Monné wrote:
> > Hello,
> > 
> > Sorry for the delay, there was a huge can of worms behind this. I have a
> > solution, but it requires patching both Xen and the FreeBSD kernel. Please 
> > bear
> > with me, I will send those patches once ready.
> 
> It sounds like you might know this already, but I did some more digging and
> here is what I can see so far...
> 
> The important command is "xl devd".  Running that under truss, it is trying
> to open /dev/xen/xenbus and that was the cause of the No such file error.
> It looks like the 10.3 tools used to open /dev/xen/xenstore instead.
> 
> I can get around this by exporting XENSTORED_PATH="/dev/xen/xenstore".
> 
> Now xl devd is stuck at:
> 
> libxl: error: libxl_event.c:639:libxl__ev_xswatch_register: create watch for
> path /local/domain/7/backend: Invalid argument
> 
> So it seems like an API issue with asking the kernel or dom0 to set a watch
> for new backend devices.

Yes, the current xenstore user-space device on FreeBSD is missing the ability 
to 
register xenstore watches. As said, I will hopefully be able to send the 
patches 
soon.

Thanks, Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: 11-RELEASE and live migration

[Roger Pau Monné]

On Thu, Dec 08, 2016 at 10:33:37AM +0100, Hoyer-Reuther, Christian wrote:
> I did some tests and I see the problem too.
> 
> XenServer 6.5 SP1 with almost all patches (3 hosts in pool), FreeBSD 
> 11.0-RELEASE-p2, xe-guest-utilities-6.2.0_2 installed via pkg.
> 
> First migration from host 3 to host 1 is ok.
> 
> Some seconds later I start a new migration from host 1 to host 2 and when 
> migration finishes (as seen in XenCenter) then the VM switches to the VGABios 
> screen ("Plex86/Bochs VGABios (PCI) current-cvs 01 Sep 2016 ... 
> cirrus-compatible VGA is detected"). The VM seem to hang and does not 
> respond. In XenCenter I see that all the CPU's of the VM go up to 100 percent.
> 
> Then after 17 minutes the VGABios screen disappears and I see the console, 
> the CPU usage as seen in XenCenter goes down. I logged in as root before I 
> started the first migration and root is still logged in. So it was a hang and 
> not a reboot.
> 
> 20 minutes later I start a new migration from host 2 to host 3 and the 
> problem occurs again.
> 
> This problem does not exist with 10.3-RELEASE on the same hosts.

Hello,

So far I've only tested local migration (migration using the same host as 
source 
and destination), and that seems to work fine (I've done +50 
consecutive migrations with only 10s separation between them). Is there a 
change 
that you could also try to reproduce this with local migration?

Are you using the same exact hardware on the source and the destination? Are 
you 
all using iSCSI as the disk backend for this VMs?

Thanks, Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

[Bug 215209] Kernel panic at boot under XEN: integer divide fault while in kernel mode

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215209

Roger Pau Monné  changed:

   What|Removed |Added

 CC||roy...@freebsd.org

--- Comment #3 from Roger Pau Monné  ---
I'm aware of this, I've already realised last week but haven't been able to
debug it. Will get to it now. In the meantime, you can boot the the previous
kernel using:

> boot kernel.old

From the loader command line.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"