Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Sander Eikelenboom 
On 25/04/17 16:07, Juergen Gross wrote:
> On 25/04/17 15:12, Sander Eikelenboom wrote:
>> On 25/04/17 14:49, Juergen Gross wrote:
>>> On 25/04/17 12:33, Sander Eikelenboom wrote:
 On 25/04/17 09:01, Juergen Gross wrote:
> On 25/04/17 08:57, Sander Eikelenboom wrote:
>> On 25/04/17 08:42, Juergen Gross wrote:
>>> On 25/04/17 08:35, Sander Eikelenboom wrote:
 (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode 
 fault/trap [#6, ec=]
 (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
 fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
 (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
 (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  
 debug=y   Not tainted ]
 (XEN) [2017-04-24 21:20:53.203] CPU:0
 (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>>>
>>> Can you please tell us symbol+offset for RIP?
>>>
>>> Juergen
>>>
>>
>> Sure:
>> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
>> 8255a485
>> linux-linus/arch/x86/xen/enlighten_pv.c:288
>>
>> Which is:
>> static bool __init xen_check_xsave(void)
>> {
>> unsigned int err, eax, edx;
>>
>> /*
>>  * Xen 4.0 and older accidentally leaked the host XSAVE flag 
>> into guest
>>  * view, despite not being able to support guests using the
>>  * functionality. Probe for the actual availability of XSAVE by 
>> seeing
>>  * whether xgetbv executes successfully or raises #UD.
>>  */
>> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>>  "xor %[err], %[err]\n"
>>  "2:\n\t"
>>  ".pushsection .fixup,\"ax\"\n\t"
>>  "3: movl $1,%[err]\n\t"
>>  "jmp 2b\n\t"
>>  ".popsection\n\t"
>>  _ASM_EXTABLE(1b, 3b)
>>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>>  : "c" (0));
>>
>> return err == 0;
>
> I hoped so. :-)
>
> I posted a patch to repair this some minutes ago. Would you mind to try
> it? See:
>
> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>
>
> Juergen

 Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
 with not too many clues.
 (any output of xen debug-keys that could be of interest ?)

 --
 Sander


  \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
   \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
   /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
  /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
 
 (XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
 4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
 (XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
 (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
 (XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
 console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
 com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
 iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 
 sched=credit2
 (XEN) Xen image load base address: 0
 (XEN) Video information:
 (XEN)  VGA is graphics mode 1280x1024, 32 bpp
 (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
 (XEN) Disc information:
 (XEN)  Found 4 MBR signatures
 (XEN)  Found 4 EDD information structures
 (XEN) Xen-e820 RAM map:
 (XEN)   - 00096400 (usable)
 (XEN)  00096400 - 000a (reserved)
 (XEN)  000e4000 - 0010 (reserved)
 (XEN)  0010 - aff9 (usable)
 (XEN)  aff9 - aff9e000 (ACPI data)
 (XEN)  aff9e000 - affe (ACPI NVS)
 (XEN)  affe - b000 (reserved)
 (XEN)  ffe0 - 0001 (reserved)
 (XEN)  0001 - 00055000 (usable)
 (XEN) New Xen image base address: 0xaf80
 (XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
 (XEN) ACPI: RSDT AFF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
 (XEN) ACPI: FACP AFF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
 (XEN) ACPI: DSDT AFF905E0, 9427 (r1  A7640 A7640100  100 INTL 20051117)
 (XEN) ACPI: FACS AFF9E000, 0040
 (XEN) ACPI: APIC AFF90390, 0088 (r1 7640MS A7640100 20100913 MSFT   97)
 (

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Juergen Gross 
On 25/04/17 15:12, Sander Eikelenboom wrote:
> On 25/04/17 14:49, Juergen Gross wrote:
>> On 25/04/17 12:33, Sander Eikelenboom wrote:
>>> On 25/04/17 09:01, Juergen Gross wrote:
 On 25/04/17 08:57, Sander Eikelenboom wrote:
> On 25/04/17 08:42, Juergen Gross wrote:
>> On 25/04/17 08:35, Sander Eikelenboom wrote:
>>> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode 
>>> fault/trap [#6, ec=]
>>> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
>>> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
>>> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
>>> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y 
>>>   Not tainted ]
>>> (XEN) [2017-04-24 21:20:53.203] CPU:0
>>> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>>
>> Can you please tell us symbol+offset for RIP?
>>
>> Juergen
>>
>
> Sure:
> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
> 8255a485
> linux-linus/arch/x86/xen/enlighten_pv.c:288
>
> Which is:
> static bool __init xen_check_xsave(void)
> {
> unsigned int err, eax, edx;
>
> /*
>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
> guest
>  * view, despite not being able to support guests using the
>  * functionality. Probe for the actual availability of XSAVE by 
> seeing
>  * whether xgetbv executes successfully or raises #UD.
>  */
> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>  "xor %[err], %[err]\n"
>  "2:\n\t"
>  ".pushsection .fixup,\"ax\"\n\t"
>  "3: movl $1,%[err]\n\t"
>  "jmp 2b\n\t"
>  ".popsection\n\t"
>  _ASM_EXTABLE(1b, 3b)
>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>  : "c" (0));
>
> return err == 0;

 I hoped so. :-)

 I posted a patch to repair this some minutes ago. Would you mind to try
 it? See:

 https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html


 Juergen
>>>
>>> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
>>> with not too many clues.
>>> (any output of xen debug-keys that could be of interest ?)
>>>
>>> --
>>> Sander
>>>
>>>
>>>  \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
>>>   \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>>>   /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
>>>  /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>>> 
>>> (XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
>>> 4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
>>> (XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
>>> (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
>>> (XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
>>> console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
>>> com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
>>> iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 
>>> sched=credit2
>>> (XEN) Xen image load base address: 0
>>> (XEN) Video information:
>>> (XEN)  VGA is graphics mode 1280x1024, 32 bpp
>>> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
>>> (XEN) Disc information:
>>> (XEN)  Found 4 MBR signatures
>>> (XEN)  Found 4 EDD information structures
>>> (XEN) Xen-e820 RAM map:
>>> (XEN)   - 00096400 (usable)
>>> (XEN)  00096400 - 000a (reserved)
>>> (XEN)  000e4000 - 0010 (reserved)
>>> (XEN)  0010 - aff9 (usable)
>>> (XEN)  aff9 - aff9e000 (ACPI data)
>>> (XEN)  aff9e000 - affe (ACPI NVS)
>>> (XEN)  affe - b000 (reserved)
>>> (XEN)  ffe0 - 0001 (reserved)
>>> (XEN)  0001 - 00055000 (usable)
>>> (XEN) New Xen image base address: 0xaf80
>>> (XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
>>> (XEN) ACPI: RSDT AFF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
>>> (XEN) ACPI: FACP AFF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
>>> (XEN) ACPI: DSDT AFF905E0, 9427 (r1  A7640 A7640100  100 INTL 20051117)
>>> (XEN) ACPI: FACS AFF9E000, 0040
>>> (XEN) ACPI: APIC AFF90390, 0088 (r1 7640MS A7640100 20100913 MSFT   97)
>>> (XEN) ACPI: MCFG AFF90420, 003C (r1 7640MS OEMMCFG  20100913 MSFT   97)
>>> (XEN) ACPI: SLIC AFF90460, 0176 (r1 MSIOEMSLIC  20100913 MSFT

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Sander Eikelenboom 
On 25/04/17 14:49, Juergen Gross wrote:
> On 25/04/17 12:33, Sander Eikelenboom wrote:
>> On 25/04/17 09:01, Juergen Gross wrote:
>>> On 25/04/17 08:57, Sander Eikelenboom wrote:
 On 25/04/17 08:42, Juergen Gross wrote:
> On 25/04/17 08:35, Sander Eikelenboom wrote:
>> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
>> [#6, ec=]
>> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
>> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
>> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y  
>>  Not tainted ]
>> (XEN) [2017-04-24 21:20:53.203] CPU:0
>> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>
> Can you please tell us symbol+offset for RIP?
>
> Juergen
>

 Sure:
 # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
 8255a485
 linux-linus/arch/x86/xen/enlighten_pv.c:288

 Which is:
 static bool __init xen_check_xsave(void)
 {
 unsigned int err, eax, edx;

 /*
  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
 guest
  * view, despite not being able to support guests using the
  * functionality. Probe for the actual availability of XSAVE by 
 seeing
  * whether xgetbv executes successfully or raises #UD.
  */
 HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
  "xor %[err], %[err]\n"
  "2:\n\t"
  ".pushsection .fixup,\"ax\"\n\t"
  "3: movl $1,%[err]\n\t"
  "jmp 2b\n\t"
  ".popsection\n\t"
  _ASM_EXTABLE(1b, 3b)
  : [err] "=r" (err), "=a" (eax), "=d" (edx)
  : "c" (0));

 return err == 0;
>>>
>>> I hoped so. :-)
>>>
>>> I posted a patch to repair this some minutes ago. Would you mind to try
>>> it? See:
>>>
>>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>>>
>>>
>>> Juergen
>>
>> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
>> with not too many clues.
>> (any output of xen debug-keys that could be of interest ?)
>>
>> --
>> Sander
>>
>>
>>  \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
>>   \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>>   /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
>>  /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>> 
>> (XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
>> 4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
>> (XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
>> (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
>> (XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
>> console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
>> com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
>> iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 
>> sched=credit2
>> (XEN) Xen image load base address: 0
>> (XEN) Video information:
>> (XEN)  VGA is graphics mode 1280x1024, 32 bpp
>> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
>> (XEN) Disc information:
>> (XEN)  Found 4 MBR signatures
>> (XEN)  Found 4 EDD information structures
>> (XEN) Xen-e820 RAM map:
>> (XEN)   - 00096400 (usable)
>> (XEN)  00096400 - 000a (reserved)
>> (XEN)  000e4000 - 0010 (reserved)
>> (XEN)  0010 - aff9 (usable)
>> (XEN)  aff9 - aff9e000 (ACPI data)
>> (XEN)  aff9e000 - affe (ACPI NVS)
>> (XEN)  affe - b000 (reserved)
>> (XEN)  ffe0 - 0001 (reserved)
>> (XEN)  0001 - 00055000 (usable)
>> (XEN) New Xen image base address: 0xaf80
>> (XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
>> (XEN) ACPI: RSDT AFF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
>> (XEN) ACPI: FACP AFF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
>> (XEN) ACPI: DSDT AFF905E0, 9427 (r1  A7640 A7640100  100 INTL 20051117)
>> (XEN) ACPI: FACS AFF9E000, 0040
>> (XEN) ACPI: APIC AFF90390, 0088 (r1 7640MS A7640100 20100913 MSFT   97)
>> (XEN) ACPI: MCFG AFF90420, 003C (r1 7640MS OEMMCFG  20100913 MSFT   97)
>> (XEN) ACPI: SLIC AFF90460, 0176 (r1 MSIOEMSLIC  20100913 MSFT   97)
>> (XEN) ACPI: OEMB AFF9E040, 0072 (r1 7640MS A7640100 20100913 MSFT   97)
>> (XEN) ACPI: SRAT AFF9A5E0, 0108 (r3 AMDFAM_F_102 AMD

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Juergen Gross 
On 25/04/17 12:33, Sander Eikelenboom wrote:
> On 25/04/17 09:01, Juergen Gross wrote:
>> On 25/04/17 08:57, Sander Eikelenboom wrote:
>>> On 25/04/17 08:42, Juergen Gross wrote:
 On 25/04/17 08:35, Sander Eikelenboom wrote:
> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
> [#6, ec=]
> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y   
> Not tainted ]
> (XEN) [2017-04-24 21:20:53.203] CPU:0
> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]

 Can you please tell us symbol+offset for RIP?

 Juergen

>>>
>>> Sure:
>>> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
>>> 8255a485
>>> linux-linus/arch/x86/xen/enlighten_pv.c:288
>>>
>>> Which is:
>>> static bool __init xen_check_xsave(void)
>>> {
>>> unsigned int err, eax, edx;
>>>
>>> /*
>>>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
>>> guest
>>>  * view, despite not being able to support guests using the
>>>  * functionality. Probe for the actual availability of XSAVE by 
>>> seeing
>>>  * whether xgetbv executes successfully or raises #UD.
>>>  */
>>> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>>>  "xor %[err], %[err]\n"
>>>  "2:\n\t"
>>>  ".pushsection .fixup,\"ax\"\n\t"
>>>  "3: movl $1,%[err]\n\t"
>>>  "jmp 2b\n\t"
>>>  ".popsection\n\t"
>>>  _ASM_EXTABLE(1b, 3b)
>>>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>>>  : "c" (0));
>>>
>>> return err == 0;
>>
>> I hoped so. :-)
>>
>> I posted a patch to repair this some minutes ago. Would you mind to try
>> it? See:
>>
>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>>
>>
>> Juergen
> 
> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
> with not too many clues.
> (any output of xen debug-keys that could be of interest ?)
> 
> --
> Sander
> 
> 
>  \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
>   \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>   /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
>  /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> 
> (XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
> 4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
> (XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
> (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
> (XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
> console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
> com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
> iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 
> sched=credit2
> (XEN) Xen image load base address: 0
> (XEN) Video information:
> (XEN)  VGA is graphics mode 1280x1024, 32 bpp
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 4 MBR signatures
> (XEN)  Found 4 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)   - 00096400 (usable)
> (XEN)  00096400 - 000a (reserved)
> (XEN)  000e4000 - 0010 (reserved)
> (XEN)  0010 - aff9 (usable)
> (XEN)  aff9 - aff9e000 (ACPI data)
> (XEN)  aff9e000 - affe (ACPI NVS)
> (XEN)  affe - b000 (reserved)
> (XEN)  ffe0 - 0001 (reserved)
> (XEN)  0001 - 00055000 (usable)
> (XEN) New Xen image base address: 0xaf80
> (XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
> (XEN) ACPI: RSDT AFF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
> (XEN) ACPI: FACP AFF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
> (XEN) ACPI: DSDT AFF905E0, 9427 (r1  A7640 A7640100  100 INTL 20051117)
> (XEN) ACPI: FACS AFF9E000, 0040
> (XEN) ACPI: APIC AFF90390, 0088 (r1 7640MS A7640100 20100913 MSFT   97)
> (XEN) ACPI: MCFG AFF90420, 003C (r1 7640MS OEMMCFG  20100913 MSFT   97)
> (XEN) ACPI: SLIC AFF90460, 0176 (r1 MSIOEMSLIC  20100913 MSFT   97)
> (XEN) ACPI: OEMB AFF9E040, 0072 (r1 7640MS A7640100 20100913 MSFT   97)
> (XEN) ACPI: SRAT AFF9A5E0, 0108 (r3 AMDFAM_F_102 AMD 1)
> (XEN) ACPI: HPET AFF9A6F0, 0038 (r1 7640MS OEMHPET  20100913 MSFT   97)
> (XEN) ACPI: IVRS AFF9A730, 0110 (r1  AMD RD890S   202031 A

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Sander Eikelenboom 
On 25/04/17 13:38, Juergen Gross wrote:
> On 25/04/17 13:28, Sander Eikelenboom wrote:
>> On 25/04/17 13:00, Juergen Gross wrote:
>>> On 25/04/17 12:33, Sander Eikelenboom wrote:
 On 25/04/17 09:01, Juergen Gross wrote:
> On 25/04/17 08:57, Sander Eikelenboom wrote:
>> On 25/04/17 08:42, Juergen Gross wrote:
>>> On 25/04/17 08:35, Sander Eikelenboom wrote:
 (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode 
 fault/trap [#6, ec=]
 (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
 fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
 (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
 (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  
 debug=y   Not tainted ]
 (XEN) [2017-04-24 21:20:53.203] CPU:0
 (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>>>
>>> Can you please tell us symbol+offset for RIP?
>>>
>>> Juergen
>>>
>>
>> Sure:
>> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
>> 8255a485
>> linux-linus/arch/x86/xen/enlighten_pv.c:288
>>
>> Which is:
>> static bool __init xen_check_xsave(void)
>> {
>> unsigned int err, eax, edx;
>>
>> /*
>>  * Xen 4.0 and older accidentally leaked the host XSAVE flag 
>> into guest
>>  * view, despite not being able to support guests using the
>>  * functionality. Probe for the actual availability of XSAVE by 
>> seeing
>>  * whether xgetbv executes successfully or raises #UD.
>>  */
>> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>>  "xor %[err], %[err]\n"
>>  "2:\n\t"
>>  ".pushsection .fixup,\"ax\"\n\t"
>>  "3: movl $1,%[err]\n\t"
>>  "jmp 2b\n\t"
>>  ".popsection\n\t"
>>  _ASM_EXTABLE(1b, 3b)
>>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>>  : "c" (0));
>>
>> return err == 0;
>
> I hoped so. :-)
>
> I posted a patch to repair this some minutes ago. Would you mind to try
> it? See:
>
> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>
>
> Juergen

 Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
 with not too many clues.
 (any output of xen debug-keys that could be of interest ?)

>>> ...
 [0.00] ACPI: Early table checksum verification disabled
 [0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
 [0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
 20100913 MSFT 0097)
 [0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
 20100913 MSFT 0097)
 [0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
 0100 INTL 20051117)
 [0.00] ACPI: FACS 0xAFF9E000 40
 [0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
 20100913 MSFT 0097)
 [0.00] ACPI: MCFG 0xAFF90420 3C (v01 7640MS OEMMCFG  
 20100913 MSFT 0097)
 [0.00] ACPI: SLIC 0xAFF90460 000176 (v01 MSIOEMSLIC  
 20100913 MSFT 0097)
 [0.00] ACPI: OEMB 0xAFF9E040 72 (v01 7640MS A7640100 
 20100913 MSFT 0097)
 [0.00] ACPI: SRAT 0xAFF9A5E0 000108 (v03 AMDFAM_F_10 
 0002 AMD  0001)
 [0.00] ACPI: HPET 0xAFF9A6F0 38 (v01 7640MS OEMHPET  
 20100913 MSFT 0097)
 [0.00] ACPI: IVRS 0xAFF9A730 000110 (v01 AMDRD890S   
 00202031 AMD  )
 [0.00] ACPI: SSDT 0xAFF9A840 000DA4 (v01 A M I  POWERNOW 
 0001 AMD  0001)
 [0.00] ACPI: Local APIC address 0xfee0
 [0.00] Setting APIC ro
>>>
>>> Hmm, this seems to be only the first part of a message.
>>>
>>> Could you try debug-key "0" (probably multiple times) and have a look
>>> where dom0 vcpu 0 is spending its time?
>>>
>>>
>>> Juergen
>>>
>>
>> Here you are:
>>
>> [0.00] ACPI: Early table checksum verification disabled
>> [0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
>> [0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
>> 20100913 MSFT 0097)
>> [0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
>> 20100913 MSFT 0097)
>> [0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
>> 0100 INTL 20051117)
>> [0.00] ACPI: FACS 0xAFF9E000 40
>> [0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
>> 20100913 MS

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Juergen Gross 
On 25/04/17 13:28, Sander Eikelenboom wrote:
> On 25/04/17 13:00, Juergen Gross wrote:
>> On 25/04/17 12:33, Sander Eikelenboom wrote:
>>> On 25/04/17 09:01, Juergen Gross wrote:
 On 25/04/17 08:57, Sander Eikelenboom wrote:
> On 25/04/17 08:42, Juergen Gross wrote:
>> On 25/04/17 08:35, Sander Eikelenboom wrote:
>>> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode 
>>> fault/trap [#6, ec=]
>>> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
>>> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
>>> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
>>> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y 
>>>   Not tainted ]
>>> (XEN) [2017-04-24 21:20:53.203] CPU:0
>>> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>>
>> Can you please tell us symbol+offset for RIP?
>>
>> Juergen
>>
>
> Sure:
> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
> 8255a485
> linux-linus/arch/x86/xen/enlighten_pv.c:288
>
> Which is:
> static bool __init xen_check_xsave(void)
> {
> unsigned int err, eax, edx;
>
> /*
>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
> guest
>  * view, despite not being able to support guests using the
>  * functionality. Probe for the actual availability of XSAVE by 
> seeing
>  * whether xgetbv executes successfully or raises #UD.
>  */
> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>  "xor %[err], %[err]\n"
>  "2:\n\t"
>  ".pushsection .fixup,\"ax\"\n\t"
>  "3: movl $1,%[err]\n\t"
>  "jmp 2b\n\t"
>  ".popsection\n\t"
>  _ASM_EXTABLE(1b, 3b)
>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>  : "c" (0));
>
> return err == 0;

 I hoped so. :-)

 I posted a patch to repair this some minutes ago. Would you mind to try
 it? See:

 https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html


 Juergen
>>>
>>> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
>>> with not too many clues.
>>> (any output of xen debug-keys that could be of interest ?)
>>>
>> ...
>>> [0.00] ACPI: Early table checksum verification disabled
>>> [0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
>>> [0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
>>> 0100 INTL 20051117)
>>> [0.00] ACPI: FACS 0xAFF9E000 40
>>> [0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: MCFG 0xAFF90420 3C (v01 7640MS OEMMCFG  
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: SLIC 0xAFF90460 000176 (v01 MSIOEMSLIC  
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: OEMB 0xAFF9E040 72 (v01 7640MS A7640100 
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: SRAT 0xAFF9A5E0 000108 (v03 AMDFAM_F_10 
>>> 0002 AMD  0001)
>>> [0.00] ACPI: HPET 0xAFF9A6F0 38 (v01 7640MS OEMHPET  
>>> 20100913 MSFT 0097)
>>> [0.00] ACPI: IVRS 0xAFF9A730 000110 (v01 AMDRD890S   
>>> 00202031 AMD  )
>>> [0.00] ACPI: SSDT 0xAFF9A840 000DA4 (v01 A M I  POWERNOW 
>>> 0001 AMD  0001)
>>> [0.00] ACPI: Local APIC address 0xfee0
>>> [0.00] Setting APIC ro
>>
>> Hmm, this seems to be only the first part of a message.
>>
>> Could you try debug-key "0" (probably multiple times) and have a look
>> where dom0 vcpu 0 is spending its time?
>>
>>
>> Juergen
>>
> 
> Here you are:
> 
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
> [0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
> 20100913 MSFT 0097)
> [0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
> 20100913 MSFT 0097)
> [0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
> 0100 INTL 20051117)
> [0.00] ACPI: FACS 0xAFF9E000 40
> [0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
> 20100913 MSFT 0097)
> [0.00] ACPI: MCFG 0xAFF90420 3C (v01 7640MS OEMMCFG  
> 20100913 MSFT 0097)
> [0.00] ACPI: SLIC 0xAFF9

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Sander Eikelenboom 
On 25/04/17 13:00, Juergen Gross wrote:
> On 25/04/17 12:33, Sander Eikelenboom wrote:
>> On 25/04/17 09:01, Juergen Gross wrote:
>>> On 25/04/17 08:57, Sander Eikelenboom wrote:
 On 25/04/17 08:42, Juergen Gross wrote:
> On 25/04/17 08:35, Sander Eikelenboom wrote:
>> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
>> [#6, ec=]
>> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
>> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
>> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y  
>>  Not tainted ]
>> (XEN) [2017-04-24 21:20:53.203] CPU:0
>> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>
> Can you please tell us symbol+offset for RIP?
>
> Juergen
>

 Sure:
 # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
 8255a485
 linux-linus/arch/x86/xen/enlighten_pv.c:288

 Which is:
 static bool __init xen_check_xsave(void)
 {
 unsigned int err, eax, edx;

 /*
  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
 guest
  * view, despite not being able to support guests using the
  * functionality. Probe for the actual availability of XSAVE by 
 seeing
  * whether xgetbv executes successfully or raises #UD.
  */
 HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
  "xor %[err], %[err]\n"
  "2:\n\t"
  ".pushsection .fixup,\"ax\"\n\t"
  "3: movl $1,%[err]\n\t"
  "jmp 2b\n\t"
  ".popsection\n\t"
  _ASM_EXTABLE(1b, 3b)
  : [err] "=r" (err), "=a" (eax), "=d" (edx)
  : "c" (0));

 return err == 0;
>>>
>>> I hoped so. :-)
>>>
>>> I posted a patch to repair this some minutes ago. Would you mind to try
>>> it? See:
>>>
>>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>>>
>>>
>>> Juergen
>>
>> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
>> with not too many clues.
>> (any output of xen debug-keys that could be of interest ?)
>>
> ...
>> [0.00] ACPI: Early table checksum verification disabled
>> [0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
>> [0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
>> 20100913 MSFT 0097)
>> [0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
>> 20100913 MSFT 0097)
>> [0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
>> 0100 INTL 20051117)
>> [0.00] ACPI: FACS 0xAFF9E000 40
>> [0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
>> 20100913 MSFT 0097)
>> [0.00] ACPI: MCFG 0xAFF90420 3C (v01 7640MS OEMMCFG  
>> 20100913 MSFT 0097)
>> [0.00] ACPI: SLIC 0xAFF90460 000176 (v01 MSIOEMSLIC  
>> 20100913 MSFT 0097)
>> [0.00] ACPI: OEMB 0xAFF9E040 72 (v01 7640MS A7640100 
>> 20100913 MSFT 0097)
>> [0.00] ACPI: SRAT 0xAFF9A5E0 000108 (v03 AMDFAM_F_10 
>> 0002 AMD  0001)
>> [0.00] ACPI: HPET 0xAFF9A6F0 38 (v01 7640MS OEMHPET  
>> 20100913 MSFT 0097)
>> [0.00] ACPI: IVRS 0xAFF9A730 000110 (v01 AMDRD890S   
>> 00202031 AMD  )
>> [0.00] ACPI: SSDT 0xAFF9A840 000DA4 (v01 A M I  POWERNOW 
>> 0001 AMD  0001)
>> [0.00] ACPI: Local APIC address 0xfee0
>> [0.00] Setting APIC ro
> 
> Hmm, this seems to be only the first part of a message.
> 
> Could you try debug-key "0" (probably multiple times) and have a look
> where dom0 vcpu 0 is spending its time?
> 
> 
> Juergen
> 

Here you are:

[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
[0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
20100913 MSFT 0097)
[0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
20100913 MSFT 0097)
[0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
0100 INTL 20051117)
[0.00] ACPI: FACS 0xAFF9E000 40
[0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
20100913 MSFT 0097)
[0.00] ACPI: MCFG 0xAFF90420 3C (v01 7640MS OEMMCFG  
20100913 MSFT 0097)
[0.00] ACPI: SLIC 0xAFF90460 000176 (v01 MSIOEMSLIC  
20100913 MSFT 0097)
[0.00] ACPI: OEMB 0xAFF9E040 72 (v01 7640MS A7640100 
20100913 MSFT 0097)
[0.00] ACPI: S

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Juergen Gross 
On 25/04/17 12:33, Sander Eikelenboom wrote:
> On 25/04/17 09:01, Juergen Gross wrote:
>> On 25/04/17 08:57, Sander Eikelenboom wrote:
>>> On 25/04/17 08:42, Juergen Gross wrote:
 On 25/04/17 08:35, Sander Eikelenboom wrote:
> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
> [#6, ec=]
> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y   
> Not tainted ]
> (XEN) [2017-04-24 21:20:53.203] CPU:0
> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]

 Can you please tell us symbol+offset for RIP?

 Juergen

>>>
>>> Sure:
>>> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
>>> 8255a485
>>> linux-linus/arch/x86/xen/enlighten_pv.c:288
>>>
>>> Which is:
>>> static bool __init xen_check_xsave(void)
>>> {
>>> unsigned int err, eax, edx;
>>>
>>> /*
>>>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
>>> guest
>>>  * view, despite not being able to support guests using the
>>>  * functionality. Probe for the actual availability of XSAVE by 
>>> seeing
>>>  * whether xgetbv executes successfully or raises #UD.
>>>  */
>>> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>>>  "xor %[err], %[err]\n"
>>>  "2:\n\t"
>>>  ".pushsection .fixup,\"ax\"\n\t"
>>>  "3: movl $1,%[err]\n\t"
>>>  "jmp 2b\n\t"
>>>  ".popsection\n\t"
>>>  _ASM_EXTABLE(1b, 3b)
>>>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>>>  : "c" (0));
>>>
>>> return err == 0;
>>
>> I hoped so. :-)
>>
>> I posted a patch to repair this some minutes ago. Would you mind to try
>> it? See:
>>
>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>>
>>
>> Juergen
> 
> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
> with not too many clues.
> (any output of xen debug-keys that could be of interest ?)

> mapping kernel into physical memory
> about to get started...
> [0.00] Linux version 
> 4.11.0-rc8-20170425-linus-doflr-xennext-boris-juergen-2+ 
> (root@serveerstertje) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Tue Apr 
> 25 12:01:44 CEST 2017
> [0.00] Command line: root=/dev/mapper/serveerstertje_ssd-root ro 
> verbose earlyprintk=xen mem=2048M console=hvc0 console=tty0 
> acpi_enforce_resources=lax max_loop=30 loop_max_part=10 r8169.use_dac=1 
> loglevel=10 nomodeset 
> xen-pciback.hide=(00:14.2)(04:00.0)(08:00.0)(09:00.*)(0a:00.*)(0e:00.0)
> [0.00] x86/fpu: x87 FPU will use FXSAVE

As this is the expected message for a cpu without the XSAVE feature
(being the reason for the crash you had without my patch): can I add
your "Tested-by:" for my patch?


Juergen

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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Juergen Gross 
On 25/04/17 12:33, Sander Eikelenboom wrote:
> On 25/04/17 09:01, Juergen Gross wrote:
>> On 25/04/17 08:57, Sander Eikelenboom wrote:
>>> On 25/04/17 08:42, Juergen Gross wrote:
 On 25/04/17 08:35, Sander Eikelenboom wrote:
> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
> [#6, ec=]
> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y   
> Not tainted ]
> (XEN) [2017-04-24 21:20:53.203] CPU:0
> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]

 Can you please tell us symbol+offset for RIP?

 Juergen

>>>
>>> Sure:
>>> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
>>> 8255a485
>>> linux-linus/arch/x86/xen/enlighten_pv.c:288
>>>
>>> Which is:
>>> static bool __init xen_check_xsave(void)
>>> {
>>> unsigned int err, eax, edx;
>>>
>>> /*
>>>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
>>> guest
>>>  * view, despite not being able to support guests using the
>>>  * functionality. Probe for the actual availability of XSAVE by 
>>> seeing
>>>  * whether xgetbv executes successfully or raises #UD.
>>>  */
>>> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>>>  "xor %[err], %[err]\n"
>>>  "2:\n\t"
>>>  ".pushsection .fixup,\"ax\"\n\t"
>>>  "3: movl $1,%[err]\n\t"
>>>  "jmp 2b\n\t"
>>>  ".popsection\n\t"
>>>  _ASM_EXTABLE(1b, 3b)
>>>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>>>  : "c" (0));
>>>
>>> return err == 0;
>>
>> I hoped so. :-)
>>
>> I posted a patch to repair this some minutes ago. Would you mind to try
>> it? See:
>>
>> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
>>
>>
>> Juergen
> 
> Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, 
> with not too many clues.
> (any output of xen debug-keys that could be of interest ?)
> 
...
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x000FB100 14 (v00 ACPIAM)
> [0.00] ACPI: RSDT 0xAFF9 48 (v01 MSIOEMSLIC  
> 20100913 MSFT 0097)
> [0.00] ACPI: FACP 0xAFF90200 84 (v01 7640MS A7640100 
> 20100913 MSFT 0097)
> [0.00] ACPI: DSDT 0xAFF905E0 009427 (v01 A7640  A7640100 
> 0100 INTL 20051117)
> [0.00] ACPI: FACS 0xAFF9E000 40
> [0.00] ACPI: APIC 0xAFF90390 88 (v01 7640MS A7640100 
> 20100913 MSFT 0097)
> [0.00] ACPI: MCFG 0xAFF90420 3C (v01 7640MS OEMMCFG  
> 20100913 MSFT 0097)
> [0.00] ACPI: SLIC 0xAFF90460 000176 (v01 MSIOEMSLIC  
> 20100913 MSFT 0097)
> [0.00] ACPI: OEMB 0xAFF9E040 72 (v01 7640MS A7640100 
> 20100913 MSFT 0097)
> [0.00] ACPI: SRAT 0xAFF9A5E0 000108 (v03 AMDFAM_F_10 
> 0002 AMD  0001)
> [0.00] ACPI: HPET 0xAFF9A6F0 38 (v01 7640MS OEMHPET  
> 20100913 MSFT 0097)
> [0.00] ACPI: IVRS 0xAFF9A730 000110 (v01 AMDRD890S   
> 00202031 AMD  )
> [0.00] ACPI: SSDT 0xAFF9A840 000DA4 (v01 A M I  POWERNOW 
> 0001 AMD  0001)
> [0.00] ACPI: Local APIC address 0xfee0
> [0.00] Setting APIC ro

Hmm, this seems to be only the first part of a message.

Could you try debug-key "0" (probably multiple times) and have a look
where dom0 vcpu 0 is spending its time?


Juergen

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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Sander Eikelenboom 
On 25/04/17 09:01, Juergen Gross wrote:
> On 25/04/17 08:57, Sander Eikelenboom wrote:
>> On 25/04/17 08:42, Juergen Gross wrote:
>>> On 25/04/17 08:35, Sander Eikelenboom wrote:
 (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
 [#6, ec=]
 (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
 fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
 (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
 (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y   
 Not tainted ]
 (XEN) [2017-04-24 21:20:53.203] CPU:0
 (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>>>
>>> Can you please tell us symbol+offset for RIP?
>>>
>>> Juergen
>>>
>>
>> Sure:
>> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
>> 8255a485
>> linux-linus/arch/x86/xen/enlighten_pv.c:288
>>
>> Which is:
>> static bool __init xen_check_xsave(void)
>> {
>> unsigned int err, eax, edx;
>>
>> /*
>>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
>> guest
>>  * view, despite not being able to support guests using the
>>  * functionality. Probe for the actual availability of XSAVE by 
>> seeing
>>  * whether xgetbv executes successfully or raises #UD.
>>  */
>> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>>  "xor %[err], %[err]\n"
>>  "2:\n\t"
>>  ".pushsection .fixup,\"ax\"\n\t"
>>  "3: movl $1,%[err]\n\t"
>>  "jmp 2b\n\t"
>>  ".popsection\n\t"
>>  _ASM_EXTABLE(1b, 3b)
>>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>>  : "c" (0));
>>
>> return err == 0;
> 
> I hoped so. :-)
> 
> I posted a patch to repair this some minutes ago. Would you mind to try
> it? See:
> 
> https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html
> 
> 
> Juergen

Hmm next up seems to be a hanging dom0 kernel somewhat later during boot, with 
not too many clues.
(any output of xen debug-keys that could be of interest ?)

--
Sander


 \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
(XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
(XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
(XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 sched=credit2
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is graphics mode 1280x1024, 32 bpp
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 4 MBR signatures
(XEN)  Found 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 00096400 (usable)
(XEN)  00096400 - 000a (reserved)
(XEN)  000e4000 - 0010 (reserved)
(XEN)  0010 - aff9 (usable)
(XEN)  aff9 - aff9e000 (ACPI data)
(XEN)  aff9e000 - affe (ACPI NVS)
(XEN)  affe - b000 (reserved)
(XEN)  ffe0 - 0001 (reserved)
(XEN)  0001 - 00055000 (usable)
(XEN) New Xen image base address: 0xaf80
(XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
(XEN) ACPI: RSDT AFF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
(XEN) ACPI: FACP AFF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: DSDT AFF905E0, 9427 (r1  A7640 A7640100  100 INTL 20051117)
(XEN) ACPI: FACS AFF9E000, 0040
(XEN) ACPI: APIC AFF90390, 0088 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: MCFG AFF90420, 003C (r1 7640MS OEMMCFG  20100913 MSFT   97)
(XEN) ACPI: SLIC AFF90460, 0176 (r1 MSIOEMSLIC  20100913 MSFT   97)
(XEN) ACPI: OEMB AFF9E040, 0072 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: SRAT AFF9A5E0, 0108 (r3 AMDFAM_F_102 AMD 1)
(XEN) ACPI: HPET AFF9A6F0, 0038 (r1 7640MS OEMHPET  20100913 MSFT   97)
(XEN) ACPI: IVRS AFF9A730, 0110 (r1  AMD RD890S   202031 AMD 0)
(XEN) ACPI: SSDT AFF9A840, 0DA4 (r1 A M I  POWERNOW1 AMD 1)
(XEN) System RAM: 20479MB (20970648kB)
(XEN) SRAT: PXM 0 -> APIC 00 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 01 -> Node 0

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-25 Thread Juergen Gross 
On 25/04/17 08:57, Sander Eikelenboom wrote:
> On 25/04/17 08:42, Juergen Gross wrote:
>> On 25/04/17 08:35, Sander Eikelenboom wrote:
>>> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap 
>>> [#6, ec=]
>>> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called from entry.S: 
>>> fault at 82d080358f70 entry.o#create_bounce_frame+0x145/0x154
>>> (XEN) [2017-04-24 21:20:53.203] Domain 0 (vcpu#0) crashed on cpu#0:
>>> (XEN) [2017-04-24 21:20:53.203] [ Xen-4.9-unstable  x86_64  debug=y   
>>> Not tainted ]
>>> (XEN) [2017-04-24 21:20:53.203] CPU:0
>>> (XEN) [2017-04-24 21:20:53.203] RIP:e033:[]
>>
>> Can you please tell us symbol+offset for RIP?
>>
>> Juergen
>>
> 
> Sure:
> # addr2line -e vmlinux-4.11.0-rc8-20170424-linus-doflr-xennext-boris+ 
> 8255a485
> linux-linus/arch/x86/xen/enlighten_pv.c:288
> 
> Which is:
> static bool __init xen_check_xsave(void)
> {
> unsigned int err, eax, edx;
> 
> /*
>  * Xen 4.0 and older accidentally leaked the host XSAVE flag into 
> guest
>  * view, despite not being able to support guests using the
>  * functionality. Probe for the actual availability of XSAVE by seeing
>  * whether xgetbv executes successfully or raises #UD.
>  */
> HERE -->asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
>  "xor %[err], %[err]\n"
>  "2:\n\t"
>  ".pushsection .fixup,\"ax\"\n\t"
>  "3: movl $1,%[err]\n\t"
>  "jmp 2b\n\t"
>  ".popsection\n\t"
>  _ASM_EXTABLE(1b, 3b)
>  : [err] "=r" (err), "=a" (eax), "=d" (edx)
>  : "c" (0));
> 
> return err == 0;

I hoped so. :-)

I posted a patch to repair this some minutes ago. Would you mind to try
it? See:

https://lists.xen.org/archives/html/xen-devel/2017-04/msg02925.html


Juergen


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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Sander Eikelenboom 
On 25/04/17 08:42, Juergen Gross wrote:
> On 25/04/17 08:35, Sander Eikelenboom wrote:
>> On 25/04/17 08:14, Juergen Gross wrote:
>>> On 24/04/17 22:15, Boris Ostrovsky wrote:
 On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
> On 24/04/17 17:49, Boris Ostrovsky wrote:
>> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>>> Hi Boris,
>>>
>>> Nope, not that i am aware of.
>> If you can keep console while running this, can you add these changes
>> and see if we ever unbind the work vector (you can even add dump_stack()
>> in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)
>>
>> Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
>> work interrupt is.
>>
>> -boris
> Hmmm i f*cked up and accidently compiled a tree with "for linus 4.12"
> pulled in and ran that instead of the vanilla 4.11-rc7 (while not naming
> it "xen-next" as i normally do.
> So 4.11-rc7 is most probably fine, sorry for that noise.
>
> Since your patch doesn't apply the smp part is changed. Seems the
> problem somewhere lies in there (Vitaly's patches, general x86 stuff
> being pulled in to base that on). I can see if i can adapt the patch
> to for linus 4.12 and retest, instead of waiting for it to be pulled in
> into Linus his tree in the next merge window.

 This is trivially reproduced on 4.12 branch with

 diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
 index 84106f9..065728f 100644
 --- a/drivers/xen/sys-hypervisor.c
 +++ b/drivers/xen/sys-hypervisor.c
 @@ -148,7 +148,7 @@ static int __init xen_sysfs_uuid_init(void)
  }
  
  /* xen compilation attributes */
 -
 +void arch_irq_work_raise(void );
  static ssize_t compiler_show(struct hyp_sysfs_attr *attr, char *buffer)
  {
 int ret = -ENOMEM;
 @@ -161,7 +161,7 @@ static ssize_t compiler_show(struct hyp_sysfs_attr
 *attr, char *buffer)
 ret = sprintf(buffer, "%s\n", info->compiler);
 kfree(info);
 }
 -
 +  arch_irq_work_raise();
 return ret;
  }


 and then (if you manage to boot):

 [root@vm-0238 ~]# grep proc /proc/cpuinfo
 processor   : 0
 [root@vm-0238 ~]#
 [root@vm-0238 ~]# cat /sys/hypervisor/compilation/compiler
 [  502.160472] [ cut here ]
 [  502.160491] kernel BUG at drivers/xen/events/events_base.c:1221!



 and the fix is

 diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
 index c0e3b96..aae3253 100644
 --- a/arch/x86/xen/smp_pv.c
 +++ b/arch/x86/xen/smp_pv.c
 @@ -249,7 +249,7 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
 int max_cpus)
  
 xen_pmu_init(0);
  
 -   if (xen_smp_intr_init(0))
 +   if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
 BUG();
  
 if (!alloc_cpumask_var(&xen_cpu_initialized_map, GFP_KERNEL))
>>>
>>> Indeed. Can you please send a proper patch with your S-o-b?
>>>
>>>
>>> Juergen
>>>
>>
>> It now at least blows up very very early and reliably ;)
>> So not there yet :)
>>
>> --
>> Sander
>>
>>
>>  \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
>>   \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>>   /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
>>  /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>> 
>> (XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
>> 4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
>> (XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
>> (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
>> (XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
>> console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
>> com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
>> iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 
>> sched=credit2
>> (XEN) Xen image load base address: 0
>> (XEN) Video information:
>> (XEN)  VGA is graphics mode 1280x1024, 32 bpp
>> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
>> (XEN) Disc information:
>> (XEN)  Found 4 MBR signatures
>> (XEN)  Found 4 EDD information structures
>> (XEN) Xen-e820 RAM map:
>> (XEN)   - 00096400 (usable)
>> (XEN)  00096400 - 000a (reserved)
>> (XEN)  000e4000 - 0010 (reserved)
>> (XEN)  0010 - aff9 (usable)
>> (XEN)  aff9 - aff9e000 (ACPI data)
>> (XEN)  aff9e000 - affe (ACPI NVS)
>> (XEN)  affe - b000 (reserved)
>> (XEN)  ffe000

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Juergen Gross 
On 25/04/17 08:35, Sander Eikelenboom wrote:
> On 25/04/17 08:14, Juergen Gross wrote:
>> On 24/04/17 22:15, Boris Ostrovsky wrote:
>>> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
 On 24/04/17 17:49, Boris Ostrovsky wrote:
> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>> Hi Boris,
>>
>> Nope, not that i am aware of.
> If you can keep console while running this, can you add these changes
> and see if we ever unbind the work vector (you can even add dump_stack()
> in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)
>
> Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
> work interrupt is.
>
> -boris
 Hmmm i f*cked up and accidently compiled a tree with "for linus 4.12"
 pulled in and ran that instead of the vanilla 4.11-rc7 (while not naming
 it "xen-next" as i normally do.
 So 4.11-rc7 is most probably fine, sorry for that noise.

 Since your patch doesn't apply the smp part is changed. Seems the
 problem somewhere lies in there (Vitaly's patches, general x86 stuff
 being pulled in to base that on). I can see if i can adapt the patch
 to for linus 4.12 and retest, instead of waiting for it to be pulled in
 into Linus his tree in the next merge window.
>>>
>>> This is trivially reproduced on 4.12 branch with
>>>
>>> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
>>> index 84106f9..065728f 100644
>>> --- a/drivers/xen/sys-hypervisor.c
>>> +++ b/drivers/xen/sys-hypervisor.c
>>> @@ -148,7 +148,7 @@ static int __init xen_sysfs_uuid_init(void)
>>>  }
>>>  
>>>  /* xen compilation attributes */
>>> -
>>> +void arch_irq_work_raise(void );
>>>  static ssize_t compiler_show(struct hyp_sysfs_attr *attr, char *buffer)
>>>  {
>>> int ret = -ENOMEM;
>>> @@ -161,7 +161,7 @@ static ssize_t compiler_show(struct hyp_sysfs_attr
>>> *attr, char *buffer)
>>> ret = sprintf(buffer, "%s\n", info->compiler);
>>> kfree(info);
>>> }
>>> -
>>> +  arch_irq_work_raise();
>>> return ret;
>>>  }
>>>
>>>
>>> and then (if you manage to boot):
>>>
>>> [root@vm-0238 ~]# grep proc /proc/cpuinfo
>>> processor   : 0
>>> [root@vm-0238 ~]#
>>> [root@vm-0238 ~]# cat /sys/hypervisor/compilation/compiler
>>> [  502.160472] [ cut here ]
>>> [  502.160491] kernel BUG at drivers/xen/events/events_base.c:1221!
>>>
>>>
>>>
>>> and the fix is
>>>
>>> diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
>>> index c0e3b96..aae3253 100644
>>> --- a/arch/x86/xen/smp_pv.c
>>> +++ b/arch/x86/xen/smp_pv.c
>>> @@ -249,7 +249,7 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
>>> int max_cpus)
>>>  
>>> xen_pmu_init(0);
>>>  
>>> -   if (xen_smp_intr_init(0))
>>> +   if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
>>> BUG();
>>>  
>>> if (!alloc_cpumask_var(&xen_cpu_initialized_map, GFP_KERNEL))
>>
>> Indeed. Can you please send a proper patch with your S-o-b?
>>
>>
>> Juergen
>>
> 
> It now at least blows up very very early and reliably ;)
> So not there yet :)
> 
> --
> Sander
> 
> 
>  \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
>   \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>   /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
>  /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> 
> (XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
> 4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
> (XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
> (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
> (XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
> console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
> com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
> iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 
> sched=credit2
> (XEN) Xen image load base address: 0
> (XEN) Video information:
> (XEN)  VGA is graphics mode 1280x1024, 32 bpp
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 4 MBR signatures
> (XEN)  Found 4 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)   - 00096400 (usable)
> (XEN)  00096400 - 000a (reserved)
> (XEN)  000e4000 - 0010 (reserved)
> (XEN)  0010 - aff9 (usable)
> (XEN)  aff9 - aff9e000 (ACPI data)
> (XEN)  aff9e000 - affe (ACPI NVS)
> (XEN)  affe - b000 (reserved)
> (XEN)  ffe0 - 0001 (reserved)
> (XEN)  0001 - 00055000 (usable)
> (XEN) New Xen image base address: 0xaf80
> (XEN) ACPI: RSDP 000FB100,

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Sander Eikelenboom 
On 25/04/17 08:14, Juergen Gross wrote:
> On 24/04/17 22:15, Boris Ostrovsky wrote:
>> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
>>> On 24/04/17 17:49, Boris Ostrovsky wrote:
 On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
> Hi Boris,
>
> Nope, not that i am aware of.
 If you can keep console while running this, can you add these changes
 and see if we ever unbind the work vector (you can even add dump_stack()
 in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)

 Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
 work interrupt is.

 -boris
>>> Hmmm i f*cked up and accidently compiled a tree with "for linus 4.12"
>>> pulled in and ran that instead of the vanilla 4.11-rc7 (while not naming
>>> it "xen-next" as i normally do.
>>> So 4.11-rc7 is most probably fine, sorry for that noise.
>>>
>>> Since your patch doesn't apply the smp part is changed. Seems the
>>> problem somewhere lies in there (Vitaly's patches, general x86 stuff
>>> being pulled in to base that on). I can see if i can adapt the patch
>>> to for linus 4.12 and retest, instead of waiting for it to be pulled in
>>> into Linus his tree in the next merge window.
>>
>> This is trivially reproduced on 4.12 branch with
>>
>> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
>> index 84106f9..065728f 100644
>> --- a/drivers/xen/sys-hypervisor.c
>> +++ b/drivers/xen/sys-hypervisor.c
>> @@ -148,7 +148,7 @@ static int __init xen_sysfs_uuid_init(void)
>>  }
>>  
>>  /* xen compilation attributes */
>> -
>> +void arch_irq_work_raise(void );
>>  static ssize_t compiler_show(struct hyp_sysfs_attr *attr, char *buffer)
>>  {
>> int ret = -ENOMEM;
>> @@ -161,7 +161,7 @@ static ssize_t compiler_show(struct hyp_sysfs_attr
>> *attr, char *buffer)
>> ret = sprintf(buffer, "%s\n", info->compiler);
>> kfree(info);
>> }
>> -
>> +  arch_irq_work_raise();
>> return ret;
>>  }
>>
>>
>> and then (if you manage to boot):
>>
>> [root@vm-0238 ~]# grep proc /proc/cpuinfo
>> processor   : 0
>> [root@vm-0238 ~]#
>> [root@vm-0238 ~]# cat /sys/hypervisor/compilation/compiler
>> [  502.160472] [ cut here ]
>> [  502.160491] kernel BUG at drivers/xen/events/events_base.c:1221!
>>
>>
>>
>> and the fix is
>>
>> diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
>> index c0e3b96..aae3253 100644
>> --- a/arch/x86/xen/smp_pv.c
>> +++ b/arch/x86/xen/smp_pv.c
>> @@ -249,7 +249,7 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
>> int max_cpus)
>>  
>> xen_pmu_init(0);
>>  
>> -   if (xen_smp_intr_init(0))
>> +   if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
>> BUG();
>>  
>> if (!alloc_cpumask_var(&xen_cpu_initialized_map, GFP_KERNEL))
> 
> Indeed. Can you please send a proper patch with your S-o-b?
> 
> 
> Juergen
>

It now at least blows up very very early and reliably ;)
So not there yet :)

--
Sander


 \ \/ /___ _ __   | || | / _ \_   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \  | || || (_) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _\__, |__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_||_|(_)/_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.9-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
4.9.2-10) 4.9.2) debug=y  Mon Apr 10 20:03:03 CEST 2017
(XEN) Latest ChangeSet: Mon Apr 10 19:56:22 2017 +0200 git:7497f90-dirty
(XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
(XEN) Command line: dom0_mem=2048M,max:2048M loglvl=all loglvl_guest=all 
console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
iommu=on,verbose,debug,amd-iommu-debug conring_size=128k ucode=-1 sched=credit2
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is graphics mode 1280x1024, 32 bpp
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 4 MBR signatures
(XEN)  Found 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 00096400 (usable)
(XEN)  00096400 - 000a (reserved)
(XEN)  000e4000 - 0010 (reserved)
(XEN)  0010 - aff9 (usable)
(XEN)  aff9 - aff9e000 (ACPI data)
(XEN)  aff9e000 - affe (ACPI NVS)
(XEN)  affe - b000 (reserved)
(XEN)  ffe0 - 0001 (reserved)
(XEN)  0001 - 00055000 (usable)
(XEN) New Xen image base address: 0xaf80
(XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
(XEN) ACPI: RSDT AFF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
(XEN) ACPI: FACP AFF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: DSDT AFF905E0, 9427 (r1  A7640

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Juergen Gross 
On 24/04/17 22:15, Boris Ostrovsky wrote:
> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
>> On 24/04/17 17:49, Boris Ostrovsky wrote:
>>> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
 Hi Boris,

 Nope, not that i am aware of.
>>> If you can keep console while running this, can you add these changes
>>> and see if we ever unbind the work vector (you can even add dump_stack()
>>> in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)
>>>
>>> Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
>>> work interrupt is.
>>>
>>> -boris
>> Hmmm i f*cked up and accidently compiled a tree with "for linus 4.12"
>> pulled in and ran that instead of the vanilla 4.11-rc7 (while not naming
>> it "xen-next" as i normally do.
>> So 4.11-rc7 is most probably fine, sorry for that noise.
>>
>> Since your patch doesn't apply the smp part is changed. Seems the
>> problem somewhere lies in there (Vitaly's patches, general x86 stuff
>> being pulled in to base that on). I can see if i can adapt the patch
>> to for linus 4.12 and retest, instead of waiting for it to be pulled in
>> into Linus his tree in the next merge window.
> 
> This is trivially reproduced on 4.12 branch with
> 
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 84106f9..065728f 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -148,7 +148,7 @@ static int __init xen_sysfs_uuid_init(void)
>  }
>  
>  /* xen compilation attributes */
> -
> +void arch_irq_work_raise(void );
>  static ssize_t compiler_show(struct hyp_sysfs_attr *attr, char *buffer)
>  {
> int ret = -ENOMEM;
> @@ -161,7 +161,7 @@ static ssize_t compiler_show(struct hyp_sysfs_attr
> *attr, char *buffer)
> ret = sprintf(buffer, "%s\n", info->compiler);
> kfree(info);
> }
> -
> +  arch_irq_work_raise();
> return ret;
>  }
> 
> 
> and then (if you manage to boot):
> 
> [root@vm-0238 ~]# grep proc /proc/cpuinfo
> processor   : 0
> [root@vm-0238 ~]#
> [root@vm-0238 ~]# cat /sys/hypervisor/compilation/compiler
> [  502.160472] [ cut here ]
> [  502.160491] kernel BUG at drivers/xen/events/events_base.c:1221!
> 
> 
> 
> and the fix is
> 
> diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
> index c0e3b96..aae3253 100644
> --- a/arch/x86/xen/smp_pv.c
> +++ b/arch/x86/xen/smp_pv.c
> @@ -249,7 +249,7 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
> int max_cpus)
>  
> xen_pmu_init(0);
>  
> -   if (xen_smp_intr_init(0))
> +   if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
> BUG();
>  
> if (!alloc_cpumask_var(&xen_cpu_initialized_map, GFP_KERNEL))

Indeed. Can you please send a proper patch with your S-o-b?


Juergen


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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Boris Ostrovsky 
On 04/24/2017 12:10 PM, Sander Eikelenboom wrote:
> On 24/04/17 17:49, Boris Ostrovsky wrote:
>> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>>> Hi Boris,
>>>
>>> Nope, not that i am aware of.
>> If you can keep console while running this, can you add these changes
>> and see if we ever unbind the work vector (you can even add dump_stack()
>> in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)
>>
>> Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
>> work interrupt is.
>>
>> -boris
> Hmmm i f*cked up and accidently compiled a tree with "for linus 4.12"
> pulled in and ran that instead of the vanilla 4.11-rc7 (while not naming
> it "xen-next" as i normally do.
> So 4.11-rc7 is most probably fine, sorry for that noise.
>
> Since your patch doesn't apply the smp part is changed. Seems the
> problem somewhere lies in there (Vitaly's patches, general x86 stuff
> being pulled in to base that on). I can see if i can adapt the patch
> to for linus 4.12 and retest, instead of waiting for it to be pulled in
> into Linus his tree in the next merge window.

This is trivially reproduced on 4.12 branch with

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 84106f9..065728f 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -148,7 +148,7 @@ static int __init xen_sysfs_uuid_init(void)
 }
 
 /* xen compilation attributes */
-
+void arch_irq_work_raise(void );
 static ssize_t compiler_show(struct hyp_sysfs_attr *attr, char *buffer)
 {
int ret = -ENOMEM;
@@ -161,7 +161,7 @@ static ssize_t compiler_show(struct hyp_sysfs_attr
*attr, char *buffer)
ret = sprintf(buffer, "%s\n", info->compiler);
kfree(info);
}
-
+  arch_irq_work_raise();
return ret;
 }


and then (if you manage to boot):

[root@vm-0238 ~]# grep proc /proc/cpuinfo
processor   : 0
[root@vm-0238 ~]#
[root@vm-0238 ~]# cat /sys/hypervisor/compilation/compiler
[  502.160472] [ cut here ]
[  502.160491] kernel BUG at drivers/xen/events/events_base.c:1221!



and the fix is

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index c0e3b96..aae3253 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -249,7 +249,7 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
int max_cpus)
 
xen_pmu_init(0);
 
-   if (xen_smp_intr_init(0))
+   if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
BUG();
 
if (!alloc_cpumask_var(&xen_cpu_initialized_map, GFP_KERNEL))


-boris
...


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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Sander Eikelenboom 
On 24/04/17 17:49, Boris Ostrovsky wrote:
> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
>> Hi Boris,
>>
>> Nope, not that i am aware of.
> 
> If you can keep console while running this, can you add these changes
> and see if we ever unbind the work vector (you can even add dump_stack()
> in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)
> 
> Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
> work interrupt is.
> 
> -boris

Hmmm i f*cked up and accidently compiled a tree with "for linus 4.12"
pulled in and ran that instead of the vanilla 4.11-rc7 (while not naming
it "xen-next" as i normally do.
So 4.11-rc7 is most probably fine, sorry for that noise.

Since your patch doesn't apply the smp part is changed. Seems the
problem somewhere lies in there (Vitaly's patches, general x86 stuff
being pulled in to base that on). I can see if i can adapt the patch
to for linus 4.12 and retest, instead of waiting for it to be pulled in
into Linus his tree in the next merge window.

--
Sander



> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 7ff2f1b..fb42e82 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -136,6 +136,7 @@ void xen_smp_intr_free(unsigned int cpu)
> if (xen_hvm_domain())
> return;
>  
> +   printk("HHH %s:%d cpu%d irq=%d\n", __FUNCTION__, __LINE__, cpu,
> per_cpu(xen_irq_work, cpu).irq);
> if (per_cpu(xen_irq_work, cpu).irq >= 0) {
> unbind_from_irqhandler(per_cpu(xen_irq_work, cpu).irq,
> NULL);
> per_cpu(xen_irq_work, cpu).irq = -1;
> @@ -217,6 +218,7 @@ int xen_smp_intr_init(unsigned int cpu)
> if (rc < 0)
> goto fail;
> per_cpu(xen_irq_work, cpu).irq = rc;
> +printk("HHH %s:%d cpu%d irq=%d\n", __FUNCTION__, __LINE__, cpu,
> rc);
> per_cpu(xen_irq_work, cpu).name = callfunc_name;
>  
> if (is_xen_pmu(cpu)) {
> @@ -615,6 +617,7 @@ static inline int xen_map_vector(int vector)
> break;
> case IRQ_WORK_VECTOR:
> xen_vector = XEN_IRQ_WORK_VECTOR;
> +   printk("HHH %s:%d work interrupt on CPU%d\n",
> __FUNCTION__, __LINE__, smp_processor_id());
> break;
>  #ifdef CONFIG_X86_64
> case NMI_VECTOR:
> diff --git a/drivers/xen/events/events_base.c
> b/drivers/xen/events/events_base.c
> index 6a53577..c1f16f2 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -627,6 +627,7 @@ static void __unbind_from_irq(unsigned int irq)
> per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1;
> break;
> case IRQT_IPI:
> +   printk("HHH %s:%d cpu%d irq=%d ipi_to_irq=%d\n",
> __FUNCTION__, __LINE__, cpu, irq, per_cpu(ipi_to_irq,
> cpu)[ipi_from_irq(irq)]);
> per_cpu(ipi_to_irq, cpu)[ipi_from_irq(irq)] = -1;
> break;
> default:
> 
> 
> 
>>
>> --
>> Sander
>>
>> On 24/04/17 16:17, Boris Ostrovsky wrote:
>>> On 04/24/2017 06:06 AM, Sander Eikelenboom wrote:
 Resend: Sorry copy and pasted a wrong mailadress for the xen-devel list.


 Hi Boris / Juergen,

 This morning i got this dom0 kernel crash (it occurred sporadically
 before (during 4.11), but i didn't have serial console enabled at that
 time so i had no stacktrace, only sporadic reboots).

 It's running on an AMD phenom X6:
 Kernel 4.11.0-rc7 with as latest commit:
 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
 Xen-unstable with as latest commit:
 94836ecf1e7378b64d37624fbb81fe48fbd4c772.

 If you need more info please ask, testing will be difficult as i don't
 have a clear testcase and
 it can also run for days without trouble.
>>> Any cpu onlining/offlining during the test?
>>>
>>> XEN_IRQ_WORK_VECTOR vector is allocated for all PV VCPUs in
>>> xen_smp_intr_init() so it's somewhat odd that we fail to find it.
>>>
>>> -boris
>>>
> 


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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Boris Ostrovsky 
On 04/24/2017 10:20 AM, Sander Eikelenboom wrote:
> Hi Boris,
>
> Nope, not that i am aware of.

If you can keep console while running this, can you add these changes
and see if we ever unbind the work vector (you can even add dump_stack()
in __unbind_from_irq() for good measure)? (I added HHH for easy grepping)

Also do 'grep -i work /proc/interrupts' so that we know which IRQ the
work interrupt is.

-boris

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 7ff2f1b..fb42e82 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -136,6 +136,7 @@ void xen_smp_intr_free(unsigned int cpu)
if (xen_hvm_domain())
return;
 
+   printk("HHH %s:%d cpu%d irq=%d\n", __FUNCTION__, __LINE__, cpu,
per_cpu(xen_irq_work, cpu).irq);
if (per_cpu(xen_irq_work, cpu).irq >= 0) {
unbind_from_irqhandler(per_cpu(xen_irq_work, cpu).irq,
NULL);
per_cpu(xen_irq_work, cpu).irq = -1;
@@ -217,6 +218,7 @@ int xen_smp_intr_init(unsigned int cpu)
if (rc < 0)
goto fail;
per_cpu(xen_irq_work, cpu).irq = rc;
+printk("HHH %s:%d cpu%d irq=%d\n", __FUNCTION__, __LINE__, cpu,
rc);
per_cpu(xen_irq_work, cpu).name = callfunc_name;
 
if (is_xen_pmu(cpu)) {
@@ -615,6 +617,7 @@ static inline int xen_map_vector(int vector)
break;
case IRQ_WORK_VECTOR:
xen_vector = XEN_IRQ_WORK_VECTOR;
+   printk("HHH %s:%d work interrupt on CPU%d\n",
__FUNCTION__, __LINE__, smp_processor_id());
break;
 #ifdef CONFIG_X86_64
case NMI_VECTOR:
diff --git a/drivers/xen/events/events_base.c
b/drivers/xen/events/events_base.c
index 6a53577..c1f16f2 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -627,6 +627,7 @@ static void __unbind_from_irq(unsigned int irq)
per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1;
break;
case IRQT_IPI:
+   printk("HHH %s:%d cpu%d irq=%d ipi_to_irq=%d\n",
__FUNCTION__, __LINE__, cpu, irq, per_cpu(ipi_to_irq,
cpu)[ipi_from_irq(irq)]);
per_cpu(ipi_to_irq, cpu)[ipi_from_irq(irq)] = -1;
break;
default:



>
> --
> Sander
>
> On 24/04/17 16:17, Boris Ostrovsky wrote:
>> On 04/24/2017 06:06 AM, Sander Eikelenboom wrote:
>>> Resend: Sorry copy and pasted a wrong mailadress for the xen-devel list.
>>>
>>>
>>> Hi Boris / Juergen,
>>>
>>> This morning i got this dom0 kernel crash (it occurred sporadically
>>> before (during 4.11), but i didn't have serial console enabled at that
>>> time so i had no stacktrace, only sporadic reboots).
>>>
>>> It's running on an AMD phenom X6:
>>> Kernel 4.11.0-rc7 with as latest commit:
>>> 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
>>> Xen-unstable with as latest commit:
>>> 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
>>>
>>> If you need more info please ask, testing will be difficult as i don't
>>> have a clear testcase and
>>> it can also run for days without trouble.
>> Any cpu onlining/offlining during the test?
>>
>> XEN_IRQ_WORK_VECTOR vector is allocated for all PV VCPUs in
>> xen_smp_intr_init() so it's somewhat odd that we fail to find it.
>>
>> -boris
>>


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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Sander Eikelenboom 
Hi Boris,

Nope, not that i am aware of.

--
Sander

On 24/04/17 16:17, Boris Ostrovsky wrote:
> On 04/24/2017 06:06 AM, Sander Eikelenboom wrote:
>> Resend: Sorry copy and pasted a wrong mailadress for the xen-devel list.
>>
>>
>> Hi Boris / Juergen,
>>
>> This morning i got this dom0 kernel crash (it occurred sporadically
>> before (during 4.11), but i didn't have serial console enabled at that
>> time so i had no stacktrace, only sporadic reboots).
>>
>> It's running on an AMD phenom X6:
>> Kernel 4.11.0-rc7 with as latest commit:
>> 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
>> Xen-unstable with as latest commit:
>> 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
>>
>> If you need more info please ask, testing will be difficult as i don't
>> have a clear testcase and
>> it can also run for days without trouble.
> 
> Any cpu onlining/offlining during the test?
> 
> XEN_IRQ_WORK_VECTOR vector is allocated for all PV VCPUs in
> xen_smp_intr_init() so it's somewhat odd that we fail to find it.
> 
> -boris
> 


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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

2017-04-24 Thread Boris Ostrovsky 
On 04/24/2017 06:06 AM, Sander Eikelenboom wrote:
> Resend: Sorry copy and pasted a wrong mailadress for the xen-devel list.
>
>
> Hi Boris / Juergen,
>
> This morning i got this dom0 kernel crash (it occurred sporadically
> before (during 4.11), but i didn't have serial console enabled at that
> time so i had no stacktrace, only sporadic reboots).
>
> It's running on an AMD phenom X6:
> Kernel 4.11.0-rc7 with as latest commit:
> 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
> Xen-unstable with as latest commit:
> 94836ecf1e7378b64d37624fbb81fe48fbd4c772.
>
> If you need more info please ask, testing will be difficult as i don't
> have a clear testcase and
> it can also run for days without trouble.

Any cpu onlining/offlining during the test?

XEN_IRQ_WORK_VECTOR vector is allocated for all PV VCPUs in
xen_smp_intr_init() so it's somewhat odd that we fail to find it.

-boris

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