similar to: Soft lockups with Xen4CentOS 3.18.25-18.el6.x86_64

On 03/10/2016 12:05 AM, Sarah Newman wrote: > On 03/09/2016 08:15 PM, Sarah Newman wrote: >> I've been running 3.18.25-18.el6.x86_64 + our build of xen 4.4.3-9 on one host for the last couple of weeks and have gotten several soft lockups >> within the last 24 hours. I am posting here first in case anyone else has experienced the same issue. >> > > Here is mpstat

On 03/09/2016 08:15 PM, Sarah Newman wrote: > I've been running 3.18.25-18.el6.x86_64 + our build of xen 4.4.3-9 on one host for the last couple of weeks and have gotten several soft lockups > within the last 24 hours. I am posting here first in case anyone else has experienced the same issue. > Here is mpstat from around the time of the issue: 0:08:56 PM CPU %usr %nice

On Fri, 2013-06-28 at 12:17 +0800, Joe Jin wrote: > Find a similar issue http://www.gossamer-threads.com/lists/xen/devel/265611 > So copied to Xen developer as well. > > On 06/27/13 13:31, Eric Dumazet wrote: > > On Thu, 2013-06-27 at 10:58 +0800, Joe Jin wrote: > >> Hi, > >> > >> When we do fail over test with iscsi + multipath by reset the switches

From: "Francis Greaves" <francis at choughs.net> To: "Francis Greaves" <francis at choughs.net>, "centos-virt" <centos-virt at centos.org> Sent: Sunday, 3 July, 2016 11:19:49 Subject: Re: [CentOS-virt] PCI Passthrough not working Further to my last post, I have removed the xen-pciback module from the Dom0 kernel, and reloaded it as modprobe

I am having trouble getting PCI Passthrough to work from Dom0 running CentOS 7 to DomU runnning Debian 8 I am using Xen 4.6 with CentOS kernel 3.18.34-20.el7.x86_64 on a Dell Poweredge T430. I think I have set it all up correctly, but I see no message when putting a USB device into any of the USB slots on the DomU There are three other DomUs running, but I have no need of PCI Passthrough set up

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-6 Severity: normal Dear Maintainer, I'm trying to boot into xen/dom0 but so far all attempts have resulted in a crash followed by an automatic reboot. My hardware is Motherboard: Asus Sabertooth 990FX R2.0 CPU: AMD FX-8350 GPU: Sapphire Radeon R9 285 A trace of the kernel panic follows (full log captured over serial should

Hi, We had a potentially network related crash on a dom0 with Linux 4.9.39 / Xen 4.8 and as of today I can't find any fixes in stable/linux-4.9.y, xen/staging-4.8, or CPU microcode updates that look like a smoking gun. I can't rule out that it's Xen related. The backtraces are: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:1473

There is now a kernel-3.18.25-18 that fixes CVE-2016-0728 (and upgrades to the lastest 3.18 LTS kernel) for Xen4CentOS users. This kernel can be tested from here: http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/os/Packages/ (CentOS-6) and here: http://cbs.centos.org/repos/virt7-xen-common-testing/x86_64/os/Packages/ (CentOS-7) Once we get several tested installs we can move this

On 01/19/2016 03:27 PM, Phill Bandelow wrote: > I presume this addresses CVE-2016-0728? > Actually it does not .. they have not rolled that patch into the LTS 3.18 branch at kernel.org yet. As soon as it hits the LTS tree I will build a new kernel though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature

On 01/19/2016 03:37 PM, Johnny Hughes wrote: > On 01/19/2016 03:27 PM, Phill Bandelow wrote: >> I presume this addresses CVE-2016-0728? >> > > Actually it does not .. they have not rolled that patch into the LTS > 3.18 branch at kernel.org yet. > > As soon as it hits the LTS tree I will build a new kernel though. OK .. supposedly, this patch fixes the issue:

On 01/19/2016 05:22 PM, Johnny Hughes wrote: > There is now a kernel-3.18.25-18 that fixes CVE-2016-0728 (and upgrades > to the lastest 3.18 LTS kernel) for Xen4CentOS users. > > This kernel can be tested from here: > > http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/os/Packages/ > (CentOS-6) > > and here: > >

George has built and I have pushed to virt6-xen-common-testing and virt7-xen-common-testing the kernel-3.18.25-19 kernel. Please test this kernel and we can release it. It also has the fix for XSA-171: http://xenbits.xen.org/xsa/advisory-171.html Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:

On Sun, Apr 10, 2016 at 11:20 AM, T.Weyergraf <T.Weyergraf at virtfinity.de> wrote: > Hi all, > > i just stumbled over a strange performance issue with my Xen setup. > > I use centos-virt Xen since a long time on my workstation and usually never > check performance. However, yesterday I booted into the 3.18.25-19 Dom0 > kernel *without* Xen and found the system noticably

I presume this addresses CVE-2016-0728? On 19 January 2016 at 21:02, Johnny Hughes <johnny at centos.org> wrote: > There is a new xen kernel for centos-6 and centos-7 the needs testing in: > > http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/os/Packages/ > > and > > http://cbs.centos.org/repos/virt7-xen-common-testing/x86_64/os/Packages/ > > Thanks,

On Tue, Jan 19, 2016 at 9:02 PM, Johnny Hughes <johnny at centos.org> wrote: > There is a new xen kernel for centos-6 and centos-7 the needs testing in: > > http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/os/Packages/ > > and > > http://cbs.centos.org/repos/virt7-xen-common-testing/x86_64/os/Packages/ Thanks, Johnny! Just a minor question about workflow. I

There is a new xen kernel for centos-6 and centos-7 the needs testing in: http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/os/Packages/ and http://cbs.centos.org/repos/virt7-xen-common-testing/x86_64/os/Packages/ Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes

Hi all, i just stumbled over a strange performance issue with my Xen setup. I use centos-virt Xen since a long time on my workstation and usually never check performance. However, yesterday I booted into the 3.18.25-19 Dom0 kernel *without* Xen and found the system noticably more responsive. That triggered me into running a simple kernel compile benchmark and compare the results:

exit_idle() should be called after irq_enter(), otherwise it throws: [ 2.513020] [ INFO: suspicious RCU usage. ] [ 2.513076] 3.6.5 #1 Not tainted [ 2.513128] ------------------------------- [ 2.513183] include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! [ 2.513271] [ 2.513271] other info that might help us debug this: [ 2.513271] [ 2.513388] [

exit_idle() should be called after irq_enter(), otherwise it throws: [ 2.513020] [ INFO: suspicious RCU usage. ] [ 2.513076] 3.6.5 #1 Not tainted [ 2.513128] ------------------------------- [ 2.513183] include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! [ 2.513271] [ 2.513271] other info that might help us debug this: [ 2.513271] [ 2.513388] [

Hi, I''m seeing this in the current linux-next tree: ------------[ cut here ]------------ WARNING: at kernel/softirq.c:143 local_bh_enable+0x40/0x87() Modules linked in: xt_state dm_mirror dm_region_hash dm_log microcode [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted 2.6.35-rc6-next-20100729+ #29 Call Trace: <IRQ> [<ffffffff81030de3>]