Re: [CentOS] Simple OCSP server ??

2017-04-14 Thread Alice Wonder 

https://www.openca.org/ might fit my needs.

On 04/14/2017 06:29 PM, Alice Wonder wrote:

Hello list,

I'm contemplating running my own CA to implement the new proposed ISP
for validation of S/MIME certificates via DANE.

I already use self-signed for my MX servers (with 3 1 1 dane records on
TCP port 25) but I don't want to use self-signed for S/MIME for user
specific x.509 certs because

A) That's potentially a lot of DNS records
B) That requires a hash of the e-mail addresses in DNS

Instead, I will be using a wildcard in DNS with an intermediary that
signs the user x.509 certificates.

Using an intermediary to sign their certificates though means I can't
just revoke their certificates by removing the DNS certificate, I'll
need to provide an OCSP server for when one of their private keys gets
compromised.

I found
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Deploy_and_Install_Guide/install-oscp.html
but it looks like that is intended for enterprise, more complex than I
need.

Anyone know of a good simple script for providing OCSP ??

-=-

Not relevant to question but just important for me to note, I will *not*
be asking people to install my root certificate in their e-mail clients.
I think it is a bad practice to get users in the habit of installing
root certificates.

I think the PKI system has way way way to many root certificates as it
is. I want a world where DANE validates most certificates, and only a
few root certificates are needed for things like banks where EV
certificates are a must.

DANE as a way to validate S/MIME I think will be a godsend to e-mail
security, I hope clients implement it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] connection state tracking with DNS [was Primary DNS...]

2017-04-14 Thread Alice Wonder 

On 04/14/2017 06:54 PM, Gordon Messmer wrote:

On 04/11/2017 04:16 PM, Alice Wonder wrote:

Hi, I would like to see this addressed.
Is there a firewalld solution to this issue?



Yes:

# Disable connection tracking for UDP DNS traffic
#
https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m
conntrack --ctstate UNTRACKED -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -m
conntrack --ctstate UNTRACKED -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 100 -p
udp -m udp --dport 53 -j CT --notrack
firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 100 -p
udp -m udp --sport 53 -j CT --notrack
firewall-cmd --permanent --direct --add-rule ipv4 raw OUTPUT 100 -p udp
-m udp --dport 53 -j CT --notrack
firewall-cmd --permanent --direct --add-rule ipv4 raw OUTPUT 100 -p udp
-m udp --sport 53 -j CT --notrack
firewall-cmd --reload




Thank you!


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] connection state tracking with DNS [was Primary DNS...]

2017-04-14 Thread Gordon Messmer 

On 04/11/2017 04:16 PM, Alice Wonder wrote:

Hi, I would like to see this addressed.
Is there a firewalld solution to this issue? 



Yes:

# Disable connection tracking for UDP DNS traffic
# 
https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m 
conntrack --ctstate UNTRACKED -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -m 
conntrack --ctstate UNTRACKED -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 100 -p 
udp -m udp --dport 53 -j CT --notrack
firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 100 -p 
udp -m udp --sport 53 -j CT --notrack
firewall-cmd --permanent --direct --add-rule ipv4 raw OUTPUT 100 -p udp 
-m udp --dport 53 -j CT --notrack
firewall-cmd --permanent --direct --add-rule ipv4 raw OUTPUT 100 -p udp 
-m udp --sport 53 -j CT --notrack

firewall-cmd --reload

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Simple OCSP server ??

2017-04-14 Thread Alice Wonder 

Hello list,

I'm contemplating running my own CA to implement the new proposed ISP 
for validation of S/MIME certificates via DANE.


I already use self-signed for my MX servers (with 3 1 1 dane records on 
TCP port 25) but I don't want to use self-signed for S/MIME for user 
specific x.509 certs because


A) That's potentially a lot of DNS records
B) That requires a hash of the e-mail addresses in DNS

Instead, I will be using a wildcard in DNS with an intermediary that 
signs the user x.509 certificates.


Using an intermediary to sign their certificates though means I can't 
just revoke their certificates by removing the DNS certificate, I'll 
need to provide an OCSP server for when one of their private keys gets 
compromised.


I found 
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Deploy_and_Install_Guide/install-oscp.html 
but it looks like that is intended for enterprise, more complex than I need.


Anyone know of a good simple script for providing OCSP ??

-=-

Not relevant to question but just important for me to note, I will *not* 
be asking people to install my root certificate in their e-mail clients. 
I think it is a bad practice to get users in the habit of installing 
root certificates.


I think the PKI system has way way way to many root certificates as it 
is. I want a world where DANE validates most certificates, and only a 
few root certificates are needed for things like banks where EV 
certificates are a must.


DANE as a way to validate S/MIME I think will be a godsend to e-mail 
security, I hope clients implement it.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Possible bug with latest 7.3 installer, md RAID1, and SATADOM.

2017-04-14 Thread David C. Miller 

>> On Fri, Apr 14, 2017 at 2:28 PM, David C. Miller 
>> wrote:
>> 
>> I'm seeing a problem that I think maybe a bug with the mdraid software on
>> the latest CentOS installer. I have a couple of new supermicro servers and
>> each system has two innodisk 32GB SATADOM's that are experiencing the same
>> issue. I used the latest CentOS-7-x86_64-1611 to install to the two
>> SATADOM's a simple RAID1 for the root. The install goes just fine but when
>> I boot off the new install I see one of two behaviours. It either hangs at
>> boot, or boots fine but I start getting errors when using the system. For
>> example it will give me  the following error if I try to run yum update.
>>
>> error: rpmdb: damaged header #6 retrieved -- skipping.
>>
>> It will just hang giving that error over and over. I have to use a
>> different login session to kill it or reboot. It doesn't even log anything
>> to journelctl or /var/log/messages. At first I thought either the hardware
>> was the issue(sata port, controller, SATADOM, etc). However, I do not see
>> any issues if I don't try to raid the disks. Setting either of the
>> SATADOM's up as a single system drive works just fine. It does not matter
>> if I choose xfs or ext4 for the filesystem when I try to RAID them either.
>> Making an md RAID1 out of the two disks with 7.3 installer is the only
>> combination I see this issue with. If I use the previous 7.2
>> installer(CentOS-7-x86_64-1511) I don't see the problem at all. I can run
>> yum update, reboot, and everything is still ok. I should also point out
>> that I tested the CentOS 7.3 installer creating a md RAID1 system drive
>> using two regular spinning hard drives and that worked just fine. I was
>> wondering if anyone else has seen something similar or can confirm th
>>  is problem before I submit it as a real bug..
>>
>> TL/DR. Two different supermicro servers, both using innodisk 32GB
>> SATADOM's and latest CentOS 7.3 installer to create a RAID1 system results
>> in freezes and weird errors. Using the CentOS 7.2 installer works fine.
>>
>> David Miller.
>> ___

> From: "Cameron Smith" 
> To: "CentOS mailing list" 
> Sent: Friday, April 14, 2017 2:48:56 PM
> Subject: Re: [CentOS] Possible bug with latest 7.3 installer, md RAID1,   
> and SATADOM.

> Is there a reason you are not using the built in controller to RAID the
> SATADOMs?
> 
> As I remember on SuperMicro there are two controllers. One for the SATADOMs
> and another for the conventional disks.
> 
> Cameron

It requires additional software to monitor the hardware RAID. CentOS can 
monitor the health of the drives and the mdRAID. It is trivial to setup postfix 
to relay through my mail gateway so both smartd and md will send me an email as 
soon as it sees an issue. Relying on a hardware raid card is just one more 
point of failure. I only get HBA cards and let Linux handle it. On top of that 
I can move the drives to any other system and it will still work.

David Miller.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread Anderson, Dave 
I also just realized the C6 portion of the title/subject line here refers to 
CentOS 6, so I'd like to clarify that all my testing/issues/etc was under 
CentOS 7.3 with all patches applied.


Thanks,
-Dave



> On Apr 14, 2017, at 1:39 PM, Anderson, Dave  wrote:
> 
> So, strangely,
> 
> I have two _identical_ dualproc xeon mobos (same bios/ipmi versions, they 
> even share an enclosure, one is right side, other is left), each with 
> different cpu/memory:
> 
> 
> Using 4.9.13 with vcpu limited to 4, early in the boot process, the one that 
> _was_ booting before setting the xen vcpu args says:
> "[7.060720] smpboot: Max logical packages: 2", 
> 
> and the other one says 
> "[6.195089] smpboot: Max logical packages: 1"
> 
> 
> 
> They both have dual procs, known working/good. 
> 
> 
> The first (the one that worked unmodified) has dual 8 core (16 HT/ea) and 
> correctly detects "[0.00] smpboot: Allowing 32 CPUs, 0 hotplug CPUs". 
> It's a Xeon E5-2665v1.
> 
> The second machine (didn't work without the xen vcpu args) has dual 4 core 
> (8ht/ea) and also correctly detects "[0.00] smpboot: Allowing 16 
> CPUs, 0 hotplug CPUs". It's a Xeon E5-2643v1...so it seems like this one does 
> ok until it decides there's only one cpu package?
> 
> Thanks,
> -Dave
> 
> 
>> On Apr 14, 2017, at 13:26, Anderson, Dave  wrote:
>> 
>> Sad to say that I already tested 4.9.20-26 from your repo yesterday...it 
>> does look a little cleaner before it dies, but still dies. I have not tested 
>> it with the vcpu=4 wokaround, but I can tonight if you would like. Relevant 
>> bits below:
>> 
>> Loading Xen 4.6.3-12.el7 ...
>> Loading Linux 4.9.20-26.el7.x86_64 ...
>> Loading initial ramdisk ...
>> [0.00] Linux version 4.9.20-26.el7.x86_64 (mockbuild@) (gcc version 
>> 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Tue Apr 4 11:19:26 CDT 2017
>> 
>> 
>> 
>> [6.195089] smpboot: Max logical packages: 1
>> [6.199549] VPMU disabled by hypervisor.
>> [6.203663] Performance Events: SandyBridge events, PMU not available due 
>> to virtualization, using software events only.
>> [6.215436] NMI watchdog: disabled (cpu0): hardware events not enabled
>> [6.222139] NMI watchdog: Shutting down hard lockup detector on all cpus
>> [6.229165] installing Xen timer for CPU 1
>> [6.233849] installing Xen timer for CPU 2
>> [6.238504] installing Xen timer for CPU 3
>> [6.243139] installing Xen timer for CPU 4
>> [6.247836] installing Xen timer for CPU 5
>> [6.252478] installing Xen timer for CPU 6
>> [6.257155] installing Xen timer for CPU 7
>> [6.261795] installing Xen timer for CPU 8
>> [6.266358] smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
>> [6.272736] [ cut here ]
>> [6.277358] kernel BUG at arch/x86/kernel/cpu/common.c:997!
>> [6.280104] random: fast init done
>> [6.286333] invalid opcode:  [#1] SMP
>> [6.290343] Modules linked in:
>> [6.293430] CPU: 8 PID: 0 Comm: swapper/8 Not tainted 
>> 4.9.20-26.el7.x86_64 #1
>> [6.300568] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
>> [6.307183] task: 880058a68000 task.stack: c900400c
>> [6.313103] RIP: e030:[]  [] 
>> identify_secondary_cpu+0x57/0x80
>> [6.322019] RSP: e02b:c900400c3f08  EFLAGS: 00010086
>> [6.327333] RAX: ffe4 RBX: 88005d80a020 RCX: 
>> 81e5ffc8
>> [6.334473] RDX: 0001 RSI: 0005 RDI: 
>> 0005
>> [6.341607] RBP: c900400c3f18 R08: 00ce R09: 
>> 
>> [6.348738] R10: 0005 R11: 0006 R12: 
>> 0008
>> [6.355873] R13:  R14:  R15: 
>> 
>> [6.363006] FS:  () GS:88005d80() 
>> knlGS:
>> [6.371090] CS:  e033 DS: 002b ES: 002b CR0: 80050033
>> [6.376837] CR2:  CR3: 01e07000 CR4: 
>> 00042660
>> [6.383970] Stack:
>> [6.386004]  0008  c900400c3f28 
>> 8104ebce
>> [6.393483]  c900400c3f40 81029855  
>> c900400c3f50
>> [6.400963]  810298d0   
>> 
>> [6.408450] Call Trace:
>> [6.410907]  [] smp_store_cpu_info+0x3e/0x40
>> [6.416753]  [] cpu_bringup+0x35/0x90
>> [6.421981]  [] cpu_bringup_and_idle+0x20/0x40
>> [6.427987] Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f 
>> b7 bb da 00 00 00 44 89 e6 e8 e4 02 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b 
>> <0f> 0b 0f b7 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 e8 ce ca 81 
>> [6.448249] RIP  [] identify_secondary_cpu+0x57/0x80
>> [6.454801]  RSP 
>> [6.458305] ---[ end trace 2f9b62c5c7050204 ]---
>> 
>> 
>> So basically, it removes the "[Firmware Bug]:

Re: [CentOS] Possible bug with latest 7.3 installer, md RAID1, and SATADOM.

2017-04-14 Thread Cameron Smith 
Is there a reason you are not using the built in controller to RAID the
SATADOMs?

As I remember on SuperMicro there are two controllers. One for the SATADOMs
and another for the conventional disks.

Cameron

On Fri, Apr 14, 2017 at 2:28 PM, David C. Miller 
wrote:

> I'm seeing a problem that I think maybe a bug with the mdraid software on
> the latest CentOS installer. I have a couple of new supermicro servers and
> each system has two innodisk 32GB SATADOM's that are experiencing the same
> issue. I used the latest CentOS-7-x86_64-1611 to install to the two
> SATADOM's a simple RAID1 for the root. The install goes just fine but when
> I boot off the new install I see one of two behaviours. It either hangs at
> boot, or boots fine but I start getting errors when using the system. For
> example it will give me  the following error if I try to run yum update.
>
> error: rpmdb: damaged header #6 retrieved -- skipping.
>
> It will just hang giving that error over and over. I have to use a
> different login session to kill it or reboot. It doesn't even log anything
> to journelctl or /var/log/messages. At first I thought either the hardware
> was the issue(sata port, controller, SATADOM, etc). However, I do not see
> any issues if I don't try to raid the disks. Setting either of the
> SATADOM's up as a single system drive works just fine. It does not matter
> if I choose xfs or ext4 for the filesystem when I try to RAID them either.
> Making an md RAID1 out of the two disks with 7.3 installer is the only
> combination I see this issue with. If I use the previous 7.2
> installer(CentOS-7-x86_64-1511) I don't see the problem at all. I can run
> yum update, reboot, and everything is still ok. I should also point out
> that I tested the CentOS 7.3 installer creating a md RAID1 system drive
> using two regular spinning hard drives and that worked just fine. I was
> wondering if anyone else has seen something similar or can confirm th
>  is problem before I submit it as a real bug..
>
> TL/DR. Two different supermicro servers, both using innodisk 32GB
> SATADOM's and latest CentOS 7.3 installer to create a RAID1 system results
> in freezes and weird errors. Using the CentOS 7.2 installer works fine.
>
> David Miller.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Possible bug with latest 7.3 installer, md RAID1, and SATADOM.

2017-04-14 Thread David C. Miller 
I'm seeing a problem that I think maybe a bug with the mdraid software on the 
latest CentOS installer. I have a couple of new supermicro servers and each 
system has two innodisk 32GB SATADOM's that are experiencing the same issue. I 
used the latest CentOS-7-x86_64-1611 to install to the two SATADOM's a simple 
RAID1 for the root. The install goes just fine but when I boot off the new 
install I see one of two behaviours. It either hangs at boot, or boots fine but 
I start getting errors when using the system. For example it will give me  the 
following error if I try to run yum update.

error: rpmdb: damaged header #6 retrieved -- skipping.

It will just hang giving that error over and over. I have to use a different 
login session to kill it or reboot. It doesn't even log anything to journelctl 
or /var/log/messages. At first I thought either the hardware was the issue(sata 
port, controller, SATADOM, etc). However, I do not see any issues if I don't 
try to raid the disks. Setting either of the SATADOM's up as a single system 
drive works just fine. It does not matter if I choose xfs or ext4 for the 
filesystem when I try to RAID them either. Making an md RAID1 out of the two 
disks with 7.3 installer is the only combination I see this issue with. If I 
use the previous 7.2 installer(CentOS-7-x86_64-1511) I don't see the problem at 
all. I can run yum update, reboot, and everything is still ok. I should also 
point out that I tested the CentOS 7.3 installer creating a md RAID1 system 
drive using two regular spinning hard drives and that worked just fine. I was 
wondering if anyone else has seen something similar or can confirm th
 is problem before I submit it as a real bug..

TL/DR. Two different supermicro servers, both using innodisk 32GB SATADOM's and 
latest CentOS 7.3 installer to create a RAID1 system results in freezes and 
weird errors. Using the CentOS 7.2 installer works fine.

David Miller.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-virt] Is Xen on CentOS 7 production ready?

2017-04-14 Thread redundantl y 
I see the announcement from February that it's available, but is it
considered to be safe for Production use?  The documentation in the SIG
still only references CentOS 6.

https://wiki.centos.org/Manuals/ReleaseNotes/Xen4-01
https://wiki.centos.org/HowTos/Xen/Xen4QuickStart

Thanks.
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread Anderson, Dave 
So, strangely,

I have two _identical_ dualproc xeon mobos (same bios/ipmi versions, they even 
share an enclosure, one is right side, other is left), each with different 
cpu/memory:


Using 4.9.13 with vcpu limited to 4, early in the boot process, the one that 
_was_ booting before setting the xen vcpu args says:
"[7.060720] smpboot: Max logical packages: 2", 

and the other one says 
"[6.195089] smpboot: Max logical packages: 1"



They both have dual procs, known working/good. 


The first (the one that worked unmodified) has dual 8 core (16 HT/ea) and 
correctly detects "[0.00] smpboot: Allowing 32 CPUs, 0 hotplug CPUs". 
It's a Xeon E5-2665v1.

The second machine (didn't work without the xen vcpu args) has dual 4 core 
(8ht/ea) and also correctly detects "[0.00] smpboot: Allowing 16 CPUs, 
0 hotplug CPUs". It's a Xeon E5-2643v1...so it seems like this one does ok 
until it decides there's only one cpu package?

Thanks,
-Dave


> On Apr 14, 2017, at 13:26, Anderson, Dave  wrote:
> 
> Sad to say that I already tested 4.9.20-26 from your repo yesterday...it does 
> look a little cleaner before it dies, but still dies. I have not tested it 
> with the vcpu=4 wokaround, but I can tonight if you would like. Relevant bits 
> below:
> 
> Loading Xen 4.6.3-12.el7 ...
> Loading Linux 4.9.20-26.el7.x86_64 ...
> Loading initial ramdisk ...
> [0.00] Linux version 4.9.20-26.el7.x86_64 (mockbuild@) (gcc version 
> 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Tue Apr 4 11:19:26 CDT 2017
> 
> 
> 
> [6.195089] smpboot: Max logical packages: 1
> [6.199549] VPMU disabled by hypervisor.
> [6.203663] Performance Events: SandyBridge events, PMU not available due 
> to virtualization, using software events only.
> [6.215436] NMI watchdog: disabled (cpu0): hardware events not enabled
> [6.222139] NMI watchdog: Shutting down hard lockup detector on all cpus
> [6.229165] installing Xen timer for CPU 1
> [6.233849] installing Xen timer for CPU 2
> [6.238504] installing Xen timer for CPU 3
> [6.243139] installing Xen timer for CPU 4
> [6.247836] installing Xen timer for CPU 5
> [6.252478] installing Xen timer for CPU 6
> [6.257155] installing Xen timer for CPU 7
> [6.261795] installing Xen timer for CPU 8
> [6.266358] smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
> [6.272736] [ cut here ]
> [6.277358] kernel BUG at arch/x86/kernel/cpu/common.c:997!
> [6.280104] random: fast init done
> [6.286333] invalid opcode:  [#1] SMP
> [6.290343] Modules linked in:
> [6.293430] CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.20-26.el7.x86_64 
> #1
> [6.300568] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
> [6.307183] task: 880058a68000 task.stack: c900400c
> [6.313103] RIP: e030:[]  [] 
> identify_secondary_cpu+0x57/0x80
> [6.322019] RSP: e02b:c900400c3f08  EFLAGS: 00010086
> [6.327333] RAX: ffe4 RBX: 88005d80a020 RCX: 
> 81e5ffc8
> [6.334473] RDX: 0001 RSI: 0005 RDI: 
> 0005
> [6.341607] RBP: c900400c3f18 R08: 00ce R09: 
> 
> [6.348738] R10: 0005 R11: 0006 R12: 
> 0008
> [6.355873] R13:  R14:  R15: 
> 
> [6.363006] FS:  () GS:88005d80() 
> knlGS:
> [6.371090] CS:  e033 DS: 002b ES: 002b CR0: 80050033
> [6.376837] CR2:  CR3: 01e07000 CR4: 
> 00042660
> [6.383970] Stack:
> [6.386004]  0008  c900400c3f28 
> 8104ebce
> [6.393483]  c900400c3f40 81029855  
> c900400c3f50
> [6.400963]  810298d0   
> 
> [6.408450] Call Trace:
> [6.410907]  [] smp_store_cpu_info+0x3e/0x40
> [6.416753]  [] cpu_bringup+0x35/0x90
> [6.421981]  [] cpu_bringup_and_idle+0x20/0x40
> [6.427987] Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 
> bb da 00 00 00 44 89 e6 e8 e4 02 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 
> 0b 0f b7 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 e8 ce ca 81 
> [6.448249] RIP  [] identify_secondary_cpu+0x57/0x80
> [6.454801]  RSP 
> [6.458305] ---[ end trace 2f9b62c5c7050204 ]---
> 
> 
> So basically, it removes the "[Firmware Bug]: CPU1: APIC id mismatch. 
> Firmware: 0 APIC: 1"  lines, but otherwise dies the same way. I included a 
> few extra lines up from the panic because the "[6.195089] smpboot: Max 
> logical packages: 1" could possibly be relevant, I need to go look at a clean 
> boot to see if that was in there on this machine.
> 
> 
> Even more strangely, in addition to the machine I'm talking about which 
> panics and reboots, I had a

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread Anderson, Dave 
Sad to say that I already tested 4.9.20-26 from your repo yesterday...it does 
look a little cleaner before it dies, but still dies. I have not tested it with 
the vcpu=4 wokaround, but I can tonight if you would like. Relevant bits below:

Loading Xen 4.6.3-12.el7 ...
Loading Linux 4.9.20-26.el7.x86_64 ...
Loading initial ramdisk ...
[0.00] Linux version 4.9.20-26.el7.x86_64 (mockbuild@) (gcc version 
4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Tue Apr 4 11:19:26 CDT 2017



[6.195089] smpboot: Max logical packages: 1
[6.199549] VPMU disabled by hypervisor.
[6.203663] Performance Events: SandyBridge events, PMU not available due to 
virtualization, using software events only.
[6.215436] NMI watchdog: disabled (cpu0): hardware events not enabled
[6.222139] NMI watchdog: Shutting down hard lockup detector on all cpus
[6.229165] installing Xen timer for CPU 1
[6.233849] installing Xen timer for CPU 2
[6.238504] installing Xen timer for CPU 3
[6.243139] installing Xen timer for CPU 4
[6.247836] installing Xen timer for CPU 5
[6.252478] installing Xen timer for CPU 6
[6.257155] installing Xen timer for CPU 7
[6.261795] installing Xen timer for CPU 8
[6.266358] smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
[6.272736] [ cut here ]
[6.277358] kernel BUG at arch/x86/kernel/cpu/common.c:997!
[6.280104] random: fast init done
[6.286333] invalid opcode:  [#1] SMP
[6.290343] Modules linked in:
[6.293430] CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.20-26.el7.x86_64 #1
[6.300568] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
[6.307183] task: 880058a68000 task.stack: c900400c
[6.313103] RIP: e030:[]  [] 
identify_secondary_cpu+0x57/0x80
[6.322019] RSP: e02b:c900400c3f08  EFLAGS: 00010086
[6.327333] RAX: ffe4 RBX: 88005d80a020 RCX: 81e5ffc8
[6.334473] RDX: 0001 RSI: 0005 RDI: 0005
[6.341607] RBP: c900400c3f18 R08: 00ce R09: 
[6.348738] R10: 0005 R11: 0006 R12: 0008
[6.355873] R13:  R14:  R15: 
[6.363006] FS:  () GS:88005d80() 
knlGS:
[6.371090] CS:  e033 DS: 002b ES: 002b CR0: 80050033
[6.376837] CR2:  CR3: 01e07000 CR4: 00042660
[6.383970] Stack:
[6.386004]  0008  c900400c3f28 
8104ebce
[6.393483]  c900400c3f40 81029855  
c900400c3f50
[6.400963]  810298d0   

[6.408450] Call Trace:
[6.410907]  [] smp_store_cpu_info+0x3e/0x40
[6.416753]  [] cpu_bringup+0x35/0x90
[6.421981]  [] cpu_bringup_and_idle+0x20/0x40
[6.427987] Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 
bb da 00 00 00 44 89 e6 e8 e4 02 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 
0f b7 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 e8 ce ca 81 
[6.448249] RIP  [] identify_secondary_cpu+0x57/0x80
[6.454801]  RSP 
[6.458305] ---[ end trace 2f9b62c5c7050204 ]---


So basically, it removes the "[Firmware Bug]: CPU1: APIC id mismatch. Firmware: 
0 APIC: 1"  lines, but otherwise dies the same way. I included a few extra 
lines up from the panic because the "[6.195089] smpboot: Max logical 
packages: 1" could possibly be relevant, I need to go look at a clean boot to 
see if that was in there on this machine.


Even more strangely, in addition to the machine I'm talking about which panics 
and reboots, I had a second nearly identical machine (different CPU/ram config, 
everything else the same) which booted but had some kind of hw conflict with 
4.9.x that I never had before. It appears to be between Intel SCU and an intel 
PCIe NVMe SSD (luckily I wasn't using SCU, so I disabled that). Had that other 
machine not booted I would have just assumed 4.9.X was totally broken and sat 
on 3.18...so I'm glad that one machine booted at least :)

Thanks,
-Dave


> On Apr 14, 2017, at 05:39, Johnny Hughes  wrote:
> 
> Dave,
> 
> Take a look at this kernel as it is the one I think we are going to
> release (or a slightly newer 4.9.2x from kernel.org LTS). This version
> has some newer settings that are more redhat/fedora/centos base kernel
> like WRT what is a module and what is built into the kernel, etc.
> 
> https://people.centos.org/hughesjr/4.9.x/
> 
> Thanks,
> Johnny Hughes
> 
> On 04/14/2017 05:16 AM, Anderson, Dave wrote:
>> List moderator: feel free to delete my previous large message with 
>> attachments that's in the moderation queue...it's now obsolete anyway.
>> 
>> 
>> I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 + 
>> Kernel 4.9.13:
>> 
>> Once I finally got serial

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread PJ Welsh 
Very nice on the sleuthing!
Thanks

On Fri, Apr 14, 2017 at 5:16 AM, Anderson, Dave 
wrote:

> List moderator: feel free to delete my previous large message with
> attachments that's in the moderation queue...it's now obsolete anyway.
>
>
> I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 +
> Kernel 4.9.13:
>
> Once I finally got serial output all the way through the boot process
> (xen+dom0) I discovered the stack trace:
>
> [Firmware Bug]: CPU7: APIC id mismatch. Firmware: 0 APIC: 7
> installing Xen timer for CPU 8
> [Firmware Bug]: CPU8: APIC id mismatch. Firmware: 0 APIC: 20
> smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
> [ cut here ]
> kernel BUG at arch/x86/kernel/cpu/common.c:997!
> invalid opcode:  [#1] SMP
> Modules linked in:
> CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.13-22.el7.x86_64 #1
> Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
> random: fast init done
> task: 880058a8c4c0 task.stack: c900400b4000
> RIP: e030:[]  []
> identify_secondary_cpu+0x57/0x80
> RSP: e02b:c900400b7f08  EFLAGS: 00010086
> RAX: ffe4 RBX: 88005d80a020 RCX: 81c5be68
> RDX: 0001 RSI: 0005 RDI: 0005
> RBP: c900400b7f18 R08: 00cb R09: 0004
> R10:  R11: 0006 R12: 0008
> R13:  R14:  R15: 
> FS:  () GS:88005d80()
> knlGS:
> CS:  e033 DS: 002b ES: 002b CR0: 80050033
> CR2:  CR3: 01c07000 CR4: 00042660
> Stack:
>  0008  c900400b7f28 8104e94e
>  c900400b7f40 81029925  c900400b7f50
>  810299a0   
> Call Trace:
>  [] smp_store_cpu_info+0x3e/0x40
>  [] cpu_bringup+0x35/0x90
>  [] cpu_bringup_and_idle+0x20/0x40
> Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 bb da 00 00
> 00 44 89 e6 e8 24 03 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 0f b7
> 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 98 87 a6 81
> RIP  [] identify_secondary_cpu+0x57/0x80
>  RSP 
> ---[ end trace dc5563100443876e ]---
>
> I surmised that reducing the number of dom0 vcpu might solve this issue
> (they were unbounded)
>
> In testing adding "dom0_max_vcpus=4 dom0_vcpus_pin" to the
> GRUB_CMDLINE_XEN_DEFAULT line in /etc/defaults/grub and re-running
> grub2-mkconfig has resulted in the system I have that never booted Xen
> 4.6.3-12 + Kernel 4.9.13, booting every single time out of 5-10 tests.
>
>
> So...I don't know if there's a race condition somewhere, or
> what...but...so far this workaround has not failed me.
>
> Thanks,
> -Dave
>
>
>
> > On Fri, Apr 7, 2017 at 6:58 AM, PJ Welsh  >> wrote:
> >> I've not gotten any bites from my posting on the xen-devel mailing list.
> >> Here is the only one to-date:
> >> https://lists.xen.org/archives/html/xen-devel/2017-04/msg01069.html
> >>
> >> From that email, there needs to be some hypervisor messages.
> >>
> >> Does anyone know how to produce the hypervisor messages? I've already
> >
> >> removed the rhgb and quiet options from the boot.
> >
> >>
> >> Thanks
> >> PJ
> >
> >
> > I spoke too soon. To get more information: Please see
> >
> > https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
> >
> > and
> >
> > https://wiki.xenproject.org/wiki/Xen_Serial_Console
> >
> > or alternatively at least add "vga=keep".
> >
> > pjwelsh
>
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread PJ Welsh 
I am on holiday until Sunday, but will download the kernel now and test it
when I get back into work.
Thanks

On Fri, Apr 14, 2017 at 7:39 AM, Johnny Hughes  wrote:

> Dave,
>
> Take a look at this kernel as it is the one I think we are going to
> release (or a slightly newer 4.9.2x from kernel.org LTS). This version
> has some newer settings that are more redhat/fedora/centos base kernel
> like WRT what is a module and what is built into the kernel, etc.
>
> https://people.centos.org/hughesjr/4.9.x/
>
> Thanks,
> Johnny Hughes
>
> On 04/14/2017 05:16 AM, Anderson, Dave wrote:
> > List moderator: feel free to delete my previous large message with
> attachments that's in the moderation queue...it's now obsolete anyway.
> >
> >
> > I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 +
> Kernel 4.9.13:
> >
> > Once I finally got serial output all the way through the boot process
> (xen+dom0) I discovered the stack trace:
> >
> > [Firmware Bug]: CPU7: APIC id mismatch. Firmware: 0 APIC: 7
> > installing Xen timer for CPU 8
> > [Firmware Bug]: CPU8: APIC id mismatch. Firmware: 0 APIC: 20
> > smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
> > [ cut here ]
> > kernel BUG at arch/x86/kernel/cpu/common.c:997!
> > invalid opcode:  [#1] SMP
> > Modules linked in:
> > CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.13-22.el7.x86_64 #1
> > Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
> > random: fast init done
> > task: 880058a8c4c0 task.stack: c900400b4000
> > RIP: e030:[]  []
> identify_secondary_cpu+0x57/0x80
> > RSP: e02b:c900400b7f08  EFLAGS: 00010086
> > RAX: ffe4 RBX: 88005d80a020 RCX: 81c5be68
> > RDX: 0001 RSI: 0005 RDI: 0005
> > RBP: c900400b7f18 R08: 00cb R09: 0004
> > R10:  R11: 0006 R12: 0008
> > R13:  R14:  R15: 
> > FS:  () GS:88005d80()
> knlGS:
> > CS:  e033 DS: 002b ES: 002b CR0: 80050033
> > CR2:  CR3: 01c07000 CR4: 00042660
> > Stack:
> >  0008  c900400b7f28 8104e94e
> >  c900400b7f40 81029925  c900400b7f50
> >  810299a0   
> > Call Trace:
> >  [] smp_store_cpu_info+0x3e/0x40
> >  [] cpu_bringup+0x35/0x90
> >  [] cpu_bringup_and_idle+0x20/0x40
> > Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 bb da 00
> 00 00 44 89 e6 e8 24 03 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 0f
> b7 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 98 87 a6 81
> > RIP  [] identify_secondary_cpu+0x57/0x80
> >  RSP 
> > ---[ end trace dc5563100443876e ]---
> >
> > I surmised that reducing the number of dom0 vcpu might solve this issue
> (they were unbounded)
> >
> > In testing adding "dom0_max_vcpus=4 dom0_vcpus_pin" to the
> GRUB_CMDLINE_XEN_DEFAULT line in /etc/defaults/grub and re-running
> grub2-mkconfig has resulted in the system I have that never booted Xen
> 4.6.3-12 + Kernel 4.9.13, booting every single time out of 5-10 tests.
> >
> >
> > So...I don't know if there's a race condition somewhere, or
> what...but...so far this workaround has not failed me.
> >
> > Thanks,
> > -Dave
> >
> >
> >
> >> On Fri, Apr 7, 2017 at 6:58 AM, PJ Welsh  >>> wrote:
> >>> I've not gotten any bites from my posting on the xen-devel mailing
> list.
> >>> Here is the only one to-date:
> >>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg01069.html
> >>>
> >>> From that email, there needs to be some hypervisor messages.
> >>>
> >>> Does anyone know how to produce the hypervisor messages? I've already
> >>
> >>> removed the rhgb and quiet options from the boot.
> >>
> >>>
> >>> Thanks
> >>> PJ
> >>
> >>
> >> I spoke too soon. To get more information: Please see
> >>
> >> https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
> >>
> >> and
> >>
> >> https://wiki.xenproject.org/wiki/Xen_Serial_Console
> >>
> >> or alternatively at least add "vga=keep".
> >>
> >> pjwelsh
> >
> >
> > ___
> > CentOS-virt mailing list
> > CentOS-virt@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-virt
> >
>
>
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>
>
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread Johnny Hughes 
Dave,

Take a look at this kernel as it is the one I think we are going to
release (or a slightly newer 4.9.2x from kernel.org LTS). This version
has some newer settings that are more redhat/fedora/centos base kernel
like WRT what is a module and what is built into the kernel, etc.

https://people.centos.org/hughesjr/4.9.x/

Thanks,
Johnny Hughes

On 04/14/2017 05:16 AM, Anderson, Dave wrote:
> List moderator: feel free to delete my previous large message with 
> attachments that's in the moderation queue...it's now obsolete anyway.
> 
> 
> I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 + Kernel 
> 4.9.13:
> 
> Once I finally got serial output all the way through the boot process 
> (xen+dom0) I discovered the stack trace:
> 
> [Firmware Bug]: CPU7: APIC id mismatch. Firmware: 0 APIC: 7
> installing Xen timer for CPU 8
> [Firmware Bug]: CPU8: APIC id mismatch. Firmware: 0 APIC: 20
> smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
> [ cut here ]
> kernel BUG at arch/x86/kernel/cpu/common.c:997!
> invalid opcode:  [#1] SMP
> Modules linked in:
> CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.13-22.el7.x86_64 #1
> Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
> random: fast init done
> task: 880058a8c4c0 task.stack: c900400b4000
> RIP: e030:[]  [] 
> identify_secondary_cpu+0x57/0x80
> RSP: e02b:c900400b7f08  EFLAGS: 00010086
> RAX: ffe4 RBX: 88005d80a020 RCX: 81c5be68
> RDX: 0001 RSI: 0005 RDI: 0005
> RBP: c900400b7f18 R08: 00cb R09: 0004
> R10:  R11: 0006 R12: 0008
> R13:  R14:  R15: 
> FS:  () GS:88005d80() knlGS:
> CS:  e033 DS: 002b ES: 002b CR0: 80050033
> CR2:  CR3: 01c07000 CR4: 00042660
> Stack:
>  0008  c900400b7f28 8104e94e
>  c900400b7f40 81029925  c900400b7f50
>  810299a0   
> Call Trace:
>  [] smp_store_cpu_info+0x3e/0x40
>  [] cpu_bringup+0x35/0x90
>  [] cpu_bringup_and_idle+0x20/0x40
> Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 bb da 00 00 00 
> 44 89 e6 e8 24 03 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 0f b7 8b d4 
> 00 00 00 89 c2 44 89 e6 48 c7 c7 98 87 a6 81 
> RIP  [] identify_secondary_cpu+0x57/0x80
>  RSP 
> ---[ end trace dc5563100443876e ]---
> 
> I surmised that reducing the number of dom0 vcpu might solve this issue (they 
> were unbounded)
> 
> In testing adding "dom0_max_vcpus=4 dom0_vcpus_pin" to the 
> GRUB_CMDLINE_XEN_DEFAULT line in /etc/defaults/grub and re-running 
> grub2-mkconfig has resulted in the system I have that never booted Xen 
> 4.6.3-12 + Kernel 4.9.13, booting every single time out of 5-10 tests.
> 
> 
> So...I don't know if there's a race condition somewhere, or what...but...so 
> far this workaround has not failed me.
> 
> Thanks,
> -Dave
> 
> 
> 
>> On Fri, Apr 7, 2017 at 6:58 AM, PJ Welsh >> wrote:
>>> I've not gotten any bites from my posting on the xen-devel mailing list.
>>> Here is the only one to-date:
>>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg01069.html
>>>
>>> From that email, there needs to be some hypervisor messages.
>>>
>>> Does anyone know how to produce the hypervisor messages? I've already
>>
>>> removed the rhgb and quiet options from the boot.
>>
>>>
>>> Thanks
>>> PJ
>>
>>
>> I spoke too soon. To get more information: Please see
>>
>> https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
>>
>> and
>>
>> https://wiki.xenproject.org/wiki/Xen_Serial_Console
>>
>> or alternatively at least add "vga=keep".
>>
>> pjwelsh
> 
> 
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
> 




signature.asc
Description: OpenPGP digital signature
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] optimal windows xml config for xen

2017-04-14 Thread Christoph 


Hi

I use this config to start win7 64bit via virsh:


  marax
  6df7f16c-50e1-4541-b5b1-a91ff675a7c2
  2097152
  2097152
  8
  
hvm
/usr/lib64/xen/boot/hvmloader

  
  




  
  
  destroy
  restart
  restart
  

  
  
  
  
  


  
  
  
  
  



  
  
  
  





  

  


it is optimal for win7? does someone see any options what I could make 
better?


--
--
Greetz
Christoph
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-14 Thread Anderson, Dave 
List moderator: feel free to delete my previous large message with attachments 
that's in the moderation queue...it's now obsolete anyway.


I have found a fix/workaround for my reboot issues with Xen 4.6.3-12 + Kernel 
4.9.13:

Once I finally got serial output all the way through the boot process 
(xen+dom0) I discovered the stack trace:

[Firmware Bug]: CPU7: APIC id mismatch. Firmware: 0 APIC: 7
installing Xen timer for CPU 8
[Firmware Bug]: CPU8: APIC id mismatch. Firmware: 0 APIC: 20
smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
[ cut here ]
kernel BUG at arch/x86/kernel/cpu/common.c:997!
invalid opcode:  [#1] SMP
Modules linked in:
CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.13-22.el7.x86_64 #1
Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
random: fast init done
task: 880058a8c4c0 task.stack: c900400b4000
RIP: e030:[]  [] 
identify_secondary_cpu+0x57/0x80
RSP: e02b:c900400b7f08  EFLAGS: 00010086
RAX: ffe4 RBX: 88005d80a020 RCX: 81c5be68
RDX: 0001 RSI: 0005 RDI: 0005
RBP: c900400b7f18 R08: 00cb R09: 0004
R10:  R11: 0006 R12: 0008
R13:  R14:  R15: 
FS:  () GS:88005d80() knlGS:
CS:  e033 DS: 002b ES: 002b CR0: 80050033
CR2:  CR3: 01c07000 CR4: 00042660
Stack:
 0008  c900400b7f28 8104e94e
 c900400b7f40 81029925  c900400b7f50
 810299a0   
Call Trace:
 [] smp_store_cpu_info+0x3e/0x40
 [] cpu_bringup+0x35/0x90
 [] cpu_bringup_and_idle+0x20/0x40
Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 bb da 00 00 00 
44 89 e6 e8 24 03 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 0f b7 8b d4 00 
00 00 89 c2 44 89 e6 48 c7 c7 98 87 a6 81 
RIP  [] identify_secondary_cpu+0x57/0x80
 RSP 
---[ end trace dc5563100443876e ]---

I surmised that reducing the number of dom0 vcpu might solve this issue (they 
were unbounded)

In testing adding "dom0_max_vcpus=4 dom0_vcpus_pin" to the 
GRUB_CMDLINE_XEN_DEFAULT line in /etc/defaults/grub and re-running 
grub2-mkconfig has resulted in the system I have that never booted Xen 4.6.3-12 
+ Kernel 4.9.13, booting every single time out of 5-10 tests.


So...I don't know if there's a race condition somewhere, or what...but...so far 
this workaround has not failed me.

Thanks,
-Dave



> On Fri, Apr 7, 2017 at 6:58 AM, PJ Welsh > wrote:
>> I've not gotten any bites from my posting on the xen-devel mailing list.
>> Here is the only one to-date:
>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg01069.html
>> 
>> From that email, there needs to be some hypervisor messages.
>> 
>> Does anyone know how to produce the hypervisor messages? I've already
> 
>> removed the rhgb and quiet options from the boot.
> 
>> 
>> Thanks
>> PJ
> 
> 
> I spoke too soon. To get more information: Please see
> 
> https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
> 
> and
> 
> https://wiki.xenproject.org/wiki/Xen_Serial_Console
> 
> or alternatively at least add "vga=keep".
> 
> pjwelsh


___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt