Re: Getting ACRN to work
clear@clr-sos-guest~ $ gnome-terminal -v --display :0
# _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
# _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)
|
 | ||||||||||||
Sent: Thursday, March 12, 2020 3:20 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
Hi Dubravko.
I agree, it does not look like the minor differences would be the cause of your troubles.
If/when you get an SSH session going, can you try to launch the gnome-terminal from that session (for GNOME on X): gnome-terminal -v --display :1
When you have a graphical environment up and running, are you able to use one of the other tty session (Ctrl-Alt-F3 as an example)?
I must confess that I’m rather puzzled by this problem…
Geoffroy
From: acrn-users@... <acrn-users@...>
On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 10, 2020 1:45 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work
Hi Geoffroy,
Please find attached the comparison of /proc/mounts content, left side with ACRN, right side without ACRN but with the same kernel. They're mostly identical, I don't know if smaller differences could be important.
In both cases where terminal does and doesn't work, I've got all the logs by running a shell script at Linux startup. I think the script runs under root account.
I've wanted to use ssh over network, but I suspect there is something wrong with the Ethernet IC - some days it works, some days it doesn't. We don't think it has anything to do with ACRN, must be the IC or the soldering or something on the PCB. Yesterday it didn't work so I've made the script. Today it works, but I don't trust it so I've reused the script anyway.
Regards,
Dubravko
|
|
||||||||||||
From:
acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 10, 2020 12:10 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
Can you check (paste) the actual content of /proc/mounts, I want to make sure that devpts is mounted under /dev/pts in both cases.
When you checked the output of ‘ls -l /dev/pts/*’ in the config where the terminal works, did you run that from a terminal or a console (or a serial port connection)?
Thanks,
Geoffroy
From:
acrn-users@... <acrn-users@...>
On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Monday, March 9, 2020 4:09 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work
Hi Geoffroy,
With ACRN (Terminal doesn't work):
/proc/mounts:
lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts
/dev/pts/*:
c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx
Without ACRN but with the same kernel (Terminal works), the content is the same.
Regards,
Dubravko
|
|
||||||||||||
From:
acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?
Thanks,
Geoffroy
From:
acrn-users@... <acrn-users@...>
On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work
Hi Xinjun and Geofrroy,
I've made more tests and found a combination of settings where mouse cursor is working well.
This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:
sos: "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
If I modify just these two settings in the list above, that crashes too:
"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"
This, however, works (found on a link provided by Geoffroy):
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0
With these, at the login screen, depending on which desktop compositor I choose, this happens:
- GNOME of Xorg (default) = bad flickering mouse
- GNOME Flashback / Metacity = good mouse cursor
- GNOME on Wayland = good mouse cursor
- Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it
In all 4 variations, Terminal doesn't work.
Terminal settings:
$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f
$ ls -l /usr/lib/modules
total 16
drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */
drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */
drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */
drwxr-xr-x 3 root root 4096 Mar 3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */
$ sudo cat /sys/kernel/debug/dri/0/i915_display_info
Password:
CRTC info
---------
CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24
fb: 93, pos: 0x0, size: 1920x1080
encoder 57: type: DDI B, connectors:
connector 58: type: DP-1, status: connected, mode:
id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5
No cursor plane available on this platform
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0
--Plane id 29: type=PRI, crtc_pos= 0x 0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)
--Plane id 34: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
--Plane id 39: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
underrun reporting: cpu=yes pch=yes
CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
Connector info
--------------
connector 58: type DP-1, status: connected
name:
physical dimensions: 480x270mm
subpixel order: Unknown
CEA rev: 0
DPCD rev: 11
audio support: no
DP branch device present: no
modes:
id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5
id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5
id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5
id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5
id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa
id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5
id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5
id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa
id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6
connector 68: type HDMI-A-1, status: disconnected
audio support: no
modes:
I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.
Regards,
Dubravko
|
|
||||||||||||
From:
acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners
), which is a hack in kernel driver i915 display module. To make it's work, it requires both UOS and SOS has the correct kernel parameters. And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)
and uos is Android.
here is the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)
sos: "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d
i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2
i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"
You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.
And after switch to kbl/whl nuc platform, things changed. As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor. We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design. The cursor plane could be used by App who explicity claimed.
2. Pipe A. Currently we focus on WaaG (Windows as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"
in SOS to let SOS use pipe B or others. Then UOS and SOS should both have display output now but has some limitations. Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting. The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.
Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output.
Thanks,
Xinyun