Topics

0.7 won't start UOS


Ross Burton
 

Hi,

My setup with an X SOS and Weston UOS works fine with 0.6, but
upgrading to 0.7 it fails:

passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get kernel path /var/lib/machines/core-image-weston.bzImage
SW_LOAD: get bootargs root=/dev/vda rw rootwait maxcpus=1 nohpet
console=tty0 console=hvc0 console=ttyS0 no_timer_check
ignore_loglevel log_buf_len=16M consoleblank=0 tsc=reliable
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x070F00
VHM api version 1.0
open hugetlbfs file /run/hugepage/acrn/huge_lv1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file /run/hugepage/acrn/huge_lv2/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/0 page size:0x200000
level 1 free/need pages:0/2 page size:0x40000000
to reserve more free pages:
to reserve pages (+orig 0): echo 2 >
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
now enough free pages are reserved!

try to setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0
level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
total_size 0x180000000

mmap ptr 0x0x7fc79e802000 -> baseaddr 0x0x7fc7c0000000
mmap 0x80000000@0x7fc7c0000000
touch 2 pages with pagesz 0x40000000

really setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0
level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
polling 33...
Listening 33...
***********************************************
virt-console backend redirected to /dev/pts/1
***********************************************
tpm: init_vtpm2:Invalid socket path!
/tmp/dm.XznMAIM 30: [0004] Address : fec00000
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 37: [0004] Interrupt : 00000002
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 46: [0004] Interrupt : 00000009
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

/tmp/dm.XznMAIM 47: [0002] Flags (decoded below) : 000D
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

vtnet tx thread closing...
mngr_client_new 113
Stop listening 33...
Stop polling 33...

I filed this as
https://github.com/projectacrn/acrn-hypervisor/issues/2795 but thought
I'd try the list too in case anyone not watching the issues has any
good ideas.

Thanks,
Ross


Geoffroy Van Cutsem
 

This is very similar to an issue we hit a little while ago related to ACPI (and IASL): 

Geoffroy

On 15 Mar 2019, at 18:34, Ross Burton <ross.burton@...> wrote:

Hi,

My setup with an X SOS and Weston UOS works fine with 0.6, but
upgrading to 0.7 it fails:

passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get kernel path /var/lib/machines/core-image-weston.bzImage
SW_LOAD: get bootargs root=/dev/vda rw rootwait maxcpus=1 nohpet
console=tty0 console=hvc0   console=ttyS0 no_timer_check
ignore_loglevel log_buf_len=16M   consoleblank=0 tsc=reliable
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x070F00
VHM api version 1.0
open hugetlbfs file /run/hugepage/acrn/huge_lv1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file /run/hugepage/acrn/huge_lv2/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/0 page size:0x200000
level 1 free/need pages:0/2 page size:0x40000000
to reserve more free pages:
to reserve pages (+orig 0): echo 2 >
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
now enough free pages are reserved!

try to setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0
level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
total_size 0x180000000

mmap ptr 0x0x7fc79e802000 -> baseaddr 0x0x7fc7c0000000
mmap 0x80000000@0x7fc7c0000000
touch 2 pages with pagesz 0x40000000

really setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0
level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
polling 33...
Listening 33...
***********************************************
virt-console backend redirected to /dev/pts/1
***********************************************
tpm: init_vtpm2:Invalid socket path!
/tmp/dm.XznMAIM     30: [0004] Address : fec00000
Error    6302 -  Flag value is too large ^  (Maximum 1 bit)

/tmp/dm.XznMAIM     37: [0004] Interrupt : 00000002
Error    6302 -    Flag value is too large ^  (Maximum 1 bit)

/tmp/dm.XznMAIM     46: [0004] Interrupt : 00000009
Error    6302 -    Flag value is too large ^  (Maximum 2 bit)

/tmp/dm.XznMAIM     47: [0002] Flags (decoded below) : 000D
Error    6302 -                Flag value is too large ^  (Maximum 2 bit)

vtnet tx thread closing...
mngr_client_new 113
Stop listening 33...
Stop polling 33...

I filed this as
https://github.com/projectacrn/acrn-hypervisor/issues/2795 but thought
I'd try the list too in case anyone not watching the issues has any
good ideas.

Thanks,
Ross




Ross Burton
 

The commit mentioned in that commit is, sadly, in the 0.7 release.

Ross

On Fri, 15 Mar 2019 at 18:31, Geoffroy Van Cutsem
<geoffroy.vancutsem@intel.com> wrote:

This is very similar to an issue we hit a little while ago related to ACPI (and IASL):
https://github.com/projectacrn/acrn-hypervisor/issues/2568

Geoffroy

On 15 Mar 2019, at 18:34, Ross Burton <ross.burton@intel.com> wrote:

Hi,

My setup with an X SOS and Weston UOS works fine with 0.6, but
upgrading to 0.7 it fails:

passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get kernel path /var/lib/machines/core-image-weston.bzImage
SW_LOAD: get bootargs root=/dev/vda rw rootwait maxcpus=1 nohpet
console=tty0 console=hvc0 console=ttyS0 no_timer_check
ignore_loglevel log_buf_len=16M consoleblank=0 tsc=reliable
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x070F00
VHM api version 1.0
open hugetlbfs file /run/hugepage/acrn/huge_lv1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file /run/hugepage/acrn/huge_lv2/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/0 page size:0x200000
level 1 free/need pages:0/2 page size:0x40000000
to reserve more free pages:
to reserve pages (+orig 0): echo 2 >
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
now enough free pages are reserved!

try to setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0
level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
total_size 0x180000000

mmap ptr 0x0x7fc79e802000 -> baseaddr 0x0x7fc7c0000000
mmap 0x80000000@0x7fc7c0000000
touch 2 pages with pagesz 0x40000000

really setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0
level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
polling 33...
Listening 33...
***********************************************
virt-console backend redirected to /dev/pts/1
***********************************************
tpm: init_vtpm2:Invalid socket path!
/tmp/dm.XznMAIM 30: [0004] Address : fec00000
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 37: [0004] Interrupt : 00000002
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 46: [0004] Interrupt : 00000009
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

/tmp/dm.XznMAIM 47: [0002] Flags (decoded below) : 000D
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

vtnet tx thread closing...
mngr_client_new 113
Stop listening 33...
Stop polling 33...

I filed this as
https://github.com/projectacrn/acrn-hypervisor/issues/2795 but thought
I'd try the list too in case anyone not watching the issues has any
good ideas.

Thanks,
Ross




Geoffroy Van Cutsem
 

Acrn-dm actually uses 'iasl' compiler from the Service OS (by default, the one in /usr/sbin)[1], could it be that it's the version of that tool that is causing trouble? The one shipped in Clear Linux these days is version 20190215. What is the version you have in your SOS?

[1] https://projectacrn.github.io/latest/developer-guides/hld/hld-devicemodel.html#acpi-emulation

Thanks,
Geoffroy

-----Original Message-----
From: acrn-users@lists.projectacrn.org [mailto:acrn-
users@lists.projectacrn.org] On Behalf Of Ross Burton
Sent: Friday, March 15, 2019 9:00 PM
To: acrn-users@lists.projectacrn.org
Subject: Re: [acrn-users] 0.7 won't start UOS

The commit mentioned in that commit is, sadly, in the 0.7 release.

Ross

On Fri, 15 Mar 2019 at 18:31, Geoffroy Van Cutsem
<geoffroy.vancutsem@intel.com> wrote:

This is very similar to an issue we hit a little while ago related to ACPI (and
IASL):
https://github.com/projectacrn/acrn-hypervisor/issues/2568

Geoffroy

On 15 Mar 2019, at 18:34, Ross Burton <ross.burton@intel.com> wrote:

Hi,

My setup with an X SOS and Weston UOS works fine with 0.6, but
upgrading to 0.7 it fails:

passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get kernel path /var/lib/machines/core-image-weston.bzImage
SW_LOAD: get bootargs root=/dev/vda rw rootwait maxcpus=1 nohpet
console=tty0 console=hvc0 console=ttyS0 no_timer_check
ignore_loglevel log_buf_len=16M consoleblank=0 tsc=reliable
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x070F00
VHM api version 1.0
open hugetlbfs file
/run/hugepage/acrn/huge_lv1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file
/run/hugepage/acrn/huge_lv2/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/0 page size:0x200000 level 1 free/need
pages:0/2 page size:0x40000000 to reserve more free pages:
to reserve pages (+orig 0): echo 2 >
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
now enough free pages are reserved!

try to setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0 level 1 - lowmem
0x80000000, biosmem 0x0, highmem 0x0 total_size 0x180000000

mmap ptr 0x0x7fc79e802000 -> baseaddr 0x0x7fc7c0000000 mmap
0x80000000@0x7fc7c0000000 touch 2 pages with pagesz 0x40000000

really setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0 level 1 - lowmem
0x80000000, biosmem 0x0, highmem 0x0 polling 33...
Listening 33...
***********************************************
virt-console backend redirected to /dev/pts/1
***********************************************
tpm: init_vtpm2:Invalid socket path!
/tmp/dm.XznMAIM 30: [0004] Address : fec00000
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 37: [0004] Interrupt : 00000002
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 46: [0004] Interrupt : 00000009
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

/tmp/dm.XznMAIM 47: [0002] Flags (decoded below) : 000D
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

vtnet tx thread closing...
mngr_client_new 113
Stop listening 33...
Stop polling 33...

I filed this as
https://github.com/projectacrn/acrn-hypervisor/issues/2795 but thought
I'd try the list too in case anyone not watching the issues has any
good ideas.

Thanks,
Ross




Xie, Nanlin
 

Thanks Ross for your trying our latest release. Could you share more about your setup, version, and steps? ACRN v0.7 requires Clear Linux OS version 28260.

Best wishes!
Nanlin

-----Original Message-----
From: acrn-users@lists.projectacrn.org [mailto:acrn-users@lists.projectacrn.org] On Behalf Of Geoffroy Van Cutsem
Sent: Saturday, March 16, 2019 4:54 AM
To: acrn-users@lists.projectacrn.org
Subject: Re: [acrn-users] 0.7 won't start UOS

Acrn-dm actually uses 'iasl' compiler from the Service OS (by default, the one in /usr/sbin)[1], could it be that it's the version of that tool that is causing trouble? The one shipped in Clear Linux these days is version 20190215. What is the version you have in your SOS?

[1] https://projectacrn.github.io/latest/developer-guides/hld/hld-devicemodel.html#acpi-emulation

Thanks,
Geoffroy

-----Original Message-----
From: acrn-users@lists.projectacrn.org [mailto:acrn-
users@lists.projectacrn.org] On Behalf Of Ross Burton
Sent: Friday, March 15, 2019 9:00 PM
To: acrn-users@lists.projectacrn.org
Subject: Re: [acrn-users] 0.7 won't start UOS

The commit mentioned in that commit is, sadly, in the 0.7 release.

Ross

On Fri, 15 Mar 2019 at 18:31, Geoffroy Van Cutsem
<geoffroy.vancutsem@intel.com> wrote:

This is very similar to an issue we hit a little while ago related
to ACPI (and
IASL):
https://github.com/projectacrn/acrn-hypervisor/issues/2568

Geoffroy

On 15 Mar 2019, at 18:34, Ross Burton <ross.burton@intel.com> wrote:

Hi,

My setup with an X SOS and Weston UOS works fine with 0.6, but
upgrading to 0.7 it fails:

passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get kernel path /var/lib/machines/core-image-weston.bzImage
SW_LOAD: get bootargs root=/dev/vda rw rootwait maxcpus=1 nohpet
console=tty0 console=hvc0 console=ttyS0 no_timer_check
ignore_loglevel log_buf_len=16M consoleblank=0 tsc=reliable
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x070F00
VHM api version 1.0
open hugetlbfs file
/run/hugepage/acrn/huge_lv1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file
/run/hugepage/acrn/huge_lv2/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/0 page size:0x200000 level 1 free/need
pages:0/2 page size:0x40000000 to reserve more free pages:
to reserve pages (+orig 0): echo 2 >
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
now enough free pages are reserved!

try to setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0 level 1 - lowmem
0x80000000, biosmem 0x0, highmem 0x0 total_size 0x180000000

mmap ptr 0x0x7fc79e802000 -> baseaddr 0x0x7fc7c0000000 mmap
0x80000000@0x7fc7c0000000 touch 2 pages with pagesz 0x40000000

really setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0 level 1 - lowmem
0x80000000, biosmem 0x0, highmem 0x0 polling 33...
Listening 33...
***********************************************
virt-console backend redirected to /dev/pts/1
***********************************************
tpm: init_vtpm2:Invalid socket path!
/tmp/dm.XznMAIM 30: [0004] Address : fec00000
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 37: [0004] Interrupt : 00000002
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 46: [0004] Interrupt : 00000009
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

/tmp/dm.XznMAIM 47: [0002] Flags (decoded below) : 000D
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

vtnet tx thread closing...
mngr_client_new 113
Stop listening 33...
Stop polling 33...

I filed this as
https://github.com/projectacrn/acrn-hypervisor/issues/2795 but
thought I'd try the list too in case anyone not watching the issues
has any good ideas.

Thanks,
Ross




Yin, Fengwei
 

On 3/16/2019 9:13 AM, Xie, Nanlin wrote:
Thanks Ross for your trying our latest release. Could you share more about your setup, version, and steps? ACRN v0.7 requires Clear Linux OS version 28260.
This error is related with new version iasl tool which has more strict
check to align with ACPI 6.x. So we update the ACPI table definition in
acrn-dm and the change breaks old iasl tool.

Ross,
Could you please just update your SOS rootfs to latest CL tag? That
will fix your issue.

Regards
Yin, Fengwei

Best wishes!
Nanlin
-----Original Message-----
From: acrn-users@lists.projectacrn.org [mailto:acrn-users@lists.projectacrn.org] On Behalf Of Geoffroy Van Cutsem
Sent: Saturday, March 16, 2019 4:54 AM
To: acrn-users@lists.projectacrn.org
Subject: Re: [acrn-users] 0.7 won't start UOS
Acrn-dm actually uses 'iasl' compiler from the Service OS (by default, the one in /usr/sbin)[1], could it be that it's the version of that tool that is causing trouble? The one shipped in Clear Linux these days is version 20190215. What is the version you have in your SOS?
[1] https://projectacrn.github.io/latest/developer-guides/hld/hld-devicemodel.html#acpi-emulation
Thanks,
Geoffroy

-----Original Message-----
From: acrn-users@lists.projectacrn.org [mailto:acrn-
users@lists.projectacrn.org] On Behalf Of Ross Burton
Sent: Friday, March 15, 2019 9:00 PM
To: acrn-users@lists.projectacrn.org
Subject: Re: [acrn-users] 0.7 won't start UOS

The commit mentioned in that commit is, sadly, in the 0.7 release.

Ross

On Fri, 15 Mar 2019 at 18:31, Geoffroy Van Cutsem
<geoffroy.vancutsem@intel.com> wrote:

This is very similar to an issue we hit a little while ago related
to ACPI (and
IASL):
https://github.com/projectacrn/acrn-hypervisor/issues/2568

Geoffroy

On 15 Mar 2019, at 18:34, Ross Burton <ross.burton@intel.com> wrote:

Hi,

My setup with an X SOS and Weston UOS works fine with 0.6, but
upgrading to 0.7 it fails:

passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get kernel path /var/lib/machines/core-image-weston.bzImage
SW_LOAD: get bootargs root=/dev/vda rw rootwait maxcpus=1 nohpet
console=tty0 console=hvc0 console=ttyS0 no_timer_check
ignore_loglevel log_buf_len=16M consoleblank=0 tsc=reliable
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x070F00
VHM api version 1.0
open hugetlbfs file
/run/hugepage/acrn/huge_lv1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file
/run/hugepage/acrn/huge_lv2/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/0 page size:0x200000 level 1 free/need
pages:0/2 page size:0x40000000 to reserve more free pages:
to reserve pages (+orig 0): echo 2 >
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
now enough free pages are reserved!

try to setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0 level 1 - lowmem
0x80000000, biosmem 0x0, highmem 0x0 total_size 0x180000000

mmap ptr 0x0x7fc79e802000 -> baseaddr 0x0x7fc7c0000000 mmap
0x80000000@0x7fc7c0000000 touch 2 pages with pagesz 0x40000000

really setup hugepage with:
level 0 - lowmem 0x0, biosmem 0x0, highmem 0x0 level 1 - lowmem
0x80000000, biosmem 0x0, highmem 0x0 polling 33...
Listening 33...
***********************************************
virt-console backend redirected to /dev/pts/1
***********************************************
tpm: init_vtpm2:Invalid socket path!
/tmp/dm.XznMAIM 30: [0004] Address : fec00000
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 37: [0004] Interrupt : 00000002
Error 6302 - Flag value is too large ^ (Maximum 1 bit)

/tmp/dm.XznMAIM 46: [0004] Interrupt : 00000009
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

/tmp/dm.XznMAIM 47: [0002] Flags (decoded below) : 000D
Error 6302 - Flag value is too large ^ (Maximum 2 bit)

vtnet tx thread closing...
mngr_client_new 113
Stop listening 33...
Stop polling 33...

I filed this as
https://github.com/projectacrn/acrn-hypervisor/issues/2795 but
thought I'd try the list too in case anyone not watching the issues
has any good ideas.

Thanks,
Ross




Ross Burton
 

On Sat, 16 Mar 2019 at 01:22, Yin, Fengwei <fengwei.yin@intel.com> wrote:
Could you please just update your SOS rootfs to latest CL tag? That
will fix your issue.
No because my SOS isn't Clear. I wasn't aware the only SOS was Clear Linux.