X problems after enabling VT-d in BIOS

[Joonas....@safe-mail.net]

Hi,

I installed R2 rc1 with no problems. After installation I noticed
that VT-d is disabled in the BIOS CPU settings.

After enabling the following two settings in the BIOS:
Intel(R) Virtualization Technology [Enabed]
Inte(R) VT-d Feature [Enabled]

I rebooted and was no longer able to startup as usual.

The X server would show 5 parallel and overlapping screens.

When I disable VT-d in the BIOS, everything works fine again.

So I tried to reinstall with VT-d enabled, but the installer has the same
problem (5 parallel+overlapping screens).

I also tried
"Install Qubes in basic graphics mode"
with no success.

So I went trough all other options in the troubleshooting menu:

NOT working kernels:
--------------------
- 3.7.4-5 (5 parallel and overlapping screens)
The boot terminates with what looks like a kernel panic but it is not readable because of the overlapping.

- 3.11.10-2 does NOT work (5 parallel and overlapping screens)

- 3.12.14-4 does NOT work (5 parallel and overlapping screens)

If you have an ThinkPad X201 with an i5-520M CPU (Intel graphics) and run into similar issues you probably want to choose the following kernel (which was the only one I was able to use without
running into the X/kernel panic problem with VT-d enabled):

3.9.2-2

regards,
Joonas

[Rainier Wolfcastle]

Can you post your /var/log/Xorg.0.log file?

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Can you post your /var/log/Xorg.0.log file?

How can I get hold of the Xorg log file?
(The installer fails in a very early stage and is not writing anything
to disk at that point.)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTXXKRAAoJEG58zmw5nc+vVU0P/iN6NvyNxQ0HAKis6KvWCSVy
V9vZH+aw991iKnBblt+sfforpXd1St1HRFuKLH3JoWxCRvxbCZWJB2PwZnf+RSlm
jq0vg3l2P3DleC0qRYkNvf3wwbTe08YZD/83bP3bGLp99ULbeBZ1bNQ39BdPX8W+
OqQUbkQHIm7W9X138l4DkZJsom3XRpg0kKouYxwn3jumCHSjUyy8aWwwUGczNUs/
fKxzXWcOMUhRkvgOnAaZ+KKGSi+4l080pQB+g6uZZu/gqOUTtawdrLsLtsGDAe7T
fxZVT+eLUrW8sEKyo3lsJwN6QfMufe7BHQtu4ECjEQml+bY/lcn2iL/JZv1TS1XN
TcYpSH4dWpZejCnlMAOAXOiVfsYQ5I4iRKmqW+JReTM3b41DAdNbDzaGGd5u1hux
Fbn2HogXXmzfu1pzwsUQAuIiCo+HatfqRjyuWS6C9LdNvEnXlcfMU0wc82uk+5Ud
5sHXNGTiZyl/nrRZgw9mU//BSl4pjlyUBAtNy4pBs1dPyC5ylZUOAGH8a7ydt90o
OeorYqCnCre2xRh7dWejTbD+WsgIv05QZVjhqnofqnHPyVeiyUJomVAmu+umHCoh
wWDYTg/RSyGFIOHc0rXTe7fS+i31ZMFjrcivEOHWXzmH4ZrBQpIkWX9q7DLKM35R
LlbU7UnGETrR0auaPuSg
=Tn2B
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 27.04.2014 23:11, Joonas Lehtonen wrote:
>> Can you post your /var/log/Xorg.0.log file?
>
> How can I get hold of the Xorg log file?
> (The installer fails in a very early stage and is not writing anything
> to disk at that point.)

You can switch to tty2 and copy the log somewhere (AFAIR installer Xorg log is
saved in /tmp/X.log).

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> You can switch to tty2 and copy the log somewhere (AFAIR installer
> Xorg log is saved in /tmp/X.log).

Besides being an X problem, framebuffer has also a problem.

Since the readability on tty2 is 0 (comparable to [1]), could you tell
me where I could copy the logfile to (what is the default path of the
usb drive I'm installing from?).

I'll type that 'cp' command blindly into the shell and have a look at
the drive afterwards.

I also did try
'vga=normal nomodeset' or vga=711 and nofb, but that way I only get a
black screen (nothing there on tty2).



[1]
http://askubuntu.com/questions/314461/graphics-on-boot-split-into-three-sections
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTXYRMAAoJEG58zmw5nc+vTt0P/2LZ3wpUTAwtuqtLSKxrLy6t
eHzAbScUtEnnhmGxuTd1yyQLmT6uthjj/ZDrbUGpNdJV5bTYbMtn85tWVytW9Iq/
rIFuj4fZFhfyloXL67XzPWxB8QwR/im6GBrBD9gZ19dEP4J6cIwfKLRTqrfd8W6h
VF+b2E6zmx9gUIiWfCmHRIDIb+9qpLlDfHut2sAL85w8yiliMpPUvv2Tspi4Oei9
Z7933xjyaKdiy8ob8jVSo/JceTUyECbOtH/CDwPyOZV96HvObGQY87ncNmwi/sZt
VzYPKpNnd/z1Y3Ppau1d34yg361TJKEXE3PVdrOmJq3Waw6snx4wgGlft2NwwGbh
If60w3o2Tev1DrKLtEh/TnkU1Z2N4axJAs2gj7paK4MyktqqtA9H/jC3E32EWdO4
eJSSqKCTW49TQenR4V2TQ5BsW9brxT8lFZR7d9VP8NtBkHb2u+vg6bn0H7RHZNKv
YC9bL1ET0yVPxdcyttukR1Y+Vheu8JQikFaU1zWBrqfdnhVuGXWSy4fjo4mfk2QG
SX5fPfnk3W7f3QU9NKsQYuuJFfiW+h0Rgg4ZKPEnPP3sZboPimEcygxyCULmHF01
EQrA+Mni/HlCwUb7wnxIBBDT0NFa/IH2KSxx76+kO2EpVeckMzu+kDWJ6AnCoFPt
9XK/lhSZNv0/ntc+uAtT
=RECZ
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> what is the default path of the usb drive I'm installing from?

ok, I looked it up with the working kernel, it is:

/run/install/repo/

I'll try to get all logs via
cp -a /tmp /run/install/repo/logs
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTXYW7AAoJEG58zmw5nc+vIZEP+QHUXtoIFQuJSuXj3fTvNTmp
I4633CSjnvjoHrr6Rm41mMOIoNv7R8eKipgjzvsaBGHzsIiN7UzQJz2kZ+yFvEGq
2rIS6xVFarIyPpgIXXD1LlDYAvaHhL/XNSBQTFffnS9syU7sLa5XMMVmq/u79IgB
AhAKo7uTtKUWhqXsj0pYwIQxN2jWG4qBsTRC8t79KKzJXdHvqNAuEAcdHafyKwZM
2uStaAklJbyvXkohNlD5Qoa2L0WeZ6Xh85w6RABCkAADdPuqBEFpSzHq/vxrL2vu
82xnm8tA3bsAfkwfOLu2Bj2AahaYHn7Yxmi/OskqbjRUbF0uD6YuQp2CX044dNUy
hlAI9kDtSEYgpKll2kbs/IHSgDuGT886fdQofgoV0egUt1DFEJpwk7/iQYEUfhDR
f53lsWT78VoXz5o+apy12WO9Tz+LPVHKxW5/4laTmlL7x51XMlRW6FZWhOHu2SG+
4f8N4+oxtAC1M83ly3hNR+VX9KrEElXIH5PHveLVEqAuiv/lkb7q2muX2bkj+uH3
iG8xuDbHoixG5zgfhD6uM/fTW2+NgqfHu/ZHSa9jY2m/gq1M3Ll4Dfpyff10RWjU
gbcu5vvX7vFR9Puboz5vFycCYw2FNQguFdVB4kG1/rqiRk5JPPM3huIvKBw207nh
v5ppRWtEug9s8EtwGcvV
=etP8
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Can you post your /var/log/Xorg.0.log file?

Find attached the logfile.

After looking at it myself I guess there is not much useful in there.

(I had about 10sec before the kernel panic would occur and prevent me
from copying anything)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTXqVOAAoJEG58zmw5nc+vj/cQAKd6bZ33ZGmQUK9Ji60r8CdA
UVhOA4NpXfJGHktcsP3TviXoGkuutudeoSL2Nkl5KyEZU9ChNZuRh5jXNdud76yA
uMUyi04IVnYU+rLehoGrL2T4tdfd3I2gKZUT5EYqwYpdZBhLFu5VSqty+VgxayLF
0gdXgdEAOxqtCxznOz1okNbBGBVuGgbDOtRdR+0Bo0aueArlcFARlcvhR6sRdZqe
dwI6Q4V1RKY/7an4mUXZVBxK0eeyga1SUxTIxhfh3kTPTTyQxpb4kKHD2KpxrY8x
/7mCBrmLXIXFmHdQgKWYrtuNfU7cOvsI2EU26dcvL1NT9h1U6XJowvxuLgzXRxLA
qOLTXZcxVqat2RgDAKc1J45vrgT9eGwbkitKqlmY9DgTuGoy/uWNH74Wj6dPcV+O
IPJPP5KSIPCHe7uRaOEUH0wBZnDuZZAsYJTQqDnJyLmCzKD/WyEu6lwR2C1r8fnj
W+7aAScIS0a2sFWz2kYBs6EKXIPAV5NYEa7LgClzUUYiGv94SKJ/ARUdhvQvcUWL
1cKI2bEbSgr3S0SMbEAhb9odn/7a0JkUhs7k1oNS6tiTjpFR1frwLdaM8UjX9HCh
ZWrdsUGYARzEs27n0qp1t1L+s79IlVXF0NMt6gKvvPU7V4E3+3GFyxYVP8Sd1As3
0/kMVLgCTqHK1xlgdsv2
=SMQ4
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 28.04.2014 21:00, Joonas Lehtonen wrote:
>> Can you post your /var/log/Xorg.0.log file?
>
> Find attached the logfile.
>
> After looking at it myself I guess there is not much useful in there.

Indeed, nothing related to the crash. Do you have real serial port in this
machine (docking station or something)? This would ease collecting the logs.

> (I had about 10sec before the kernel panic would occur and prevent me
> from copying anything)

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Indeed, nothing related to the crash. Do you have real serial port
> in this machine (docking station or something)? This would ease
> collecting the logs.

using kernel 3.7.4-5 I was able to get more relevant logs (since it
doesn't end up in a kernel panic)

last lines from X.log:

[ 24.919] (II) config/udev: Adding input device PC Speaker
(/dev/input/event7)
[ 24.919] (II) No input driver specified, ignoring this device.
[ 24.919] (II) This device may have been added with another device
file.
[ 34.000] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 35.664] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[ 35.664] (EE) intel(0): When reporting this, please include
i915_error_state from debugfs and the full dmesg.


relevant dmesg lines:

[ 35.791107] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 35.791117] [drm] capturing error event; look for more information
in /debug/dri/0/i915_error_state
[ 37.511111] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 37.511241] [drm:i915_reset] *ERROR* GPU hanging too fast,
declaring wedged!
[ 37.511244] [drm:i915_reset] *ERROR* Failed to reset chip.


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTXruzAAoJEG58zmw5nc+v06sP/jTNGRLOVQUa8+F93NR2u3o+
GabQD1bwLoX1mdP4pc3hrdXyUwdBAFdkTjfm5FyuyhWuh5YLk2/xtaLv3U7mJd/6
3tc6m5upnLPLftm4NW3IZCbaZuXfdSpJ2DryatgfiH95r5lMxHDs94oO/cvXLhVC
Ax5AtBXz5LPfm/pznjKdvexVP4E3kuHWlMqvRzK4pCqMSfvwdfoJqoe5ZX8Mndik
5EoAKByHj8G651Wy3GeMJdrVDoLjoxmF61qB9feeMqViEMKFDELhriltAxzXulPU
qBzg0f1f5Kky5OKJw9mVwXP/VU8N/5Yh5ivD08Fa4MfZ2tLTb7oHyT+4wqXr5iOm
dLfwd/KecSGRAEuwrlV+wunuXmqRAGypP4QTGpVC2N5/VvtnKCAq+yovp9v3rUsw
nBk8xP2Xrd9vOUdsjd6rfCMrEnGWB1xrrDTq7jyH9R829vzSrntWSidfXkxuHIrz
eS0+2G22WrKKEatg1eMCAbtL4plFlTvLYgdFDTXrj2bEQoITjoeqL4gW0SzeQ7/h
zk+WYv3BghCyg/VYNJPoX82equMNxpIEdRQYDqeNi+YWy6w0UuXb2reDi1aYP6hV
w+ExiJ0MCRc9VYUd4ZvxjHjQ6oAxnmzrE2vqxcbS5gOqejpBsEN4b64SmFPrzu0P
hF5TKWaZyXPzgS7Mcl/O
=Dfv2
-----END PGP SIGNATURE-----

[Rainier Wolfcastle]

Is it also possible to post your Xorg when you disable VT-d?

[Rainier Wolfcastle]

On Tuesday, April 29, 2014 6:36:03 AM UTC+10, Joonas Lehtonen wrote:

Something else to try is disabling Render C-State (RC6) in the kernel as there are problems with it when VT-d is enabled.

The cmdline boot flag is i915.i915_enable_rc6=0

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Is it also possible to post your Xorg when you disable VT-d?

Xorg logfile with VT-d disabled is attached.
This log file is from an actual installed OS (not from the installer).

I looked at it using a visual diff tool, you will notice the first
difference at line 120:

[ 48.959] (++) using VT number 1



I gave 'i915.i915_enable_rc6=0' a try, but it had no effect (tested
with 3.12.14 only).


Thanks for your continued help with debugging this issue!
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTX+WbAAoJEG58zmw5nc+v9ycQAK06wM0xCSZGVRTjowiW5hgU
ZGdZ9zG9yfZauHxCsJV4tmJ2DtMYa2xQAVfKKjekvUdiJ7Ni4fMrer3CvLS+i2TT
bQzNJdmUEbNi+CBebY5+Fs4DuXPP66IxKBRr2POPj+DAgdVyv0VY9HQ0pIwsMOvc
M9vIM/XCmfHd2yq46ht/OaeOLRw9ffZjNyFRnJygWjEL0wDXkjYhky78SgdSBpL+
4UwF+rQ0sqFNoqcwLX5iv6wlVSZXhGHgLfJWO21cuLocnvl/SVDiQem10RHdqhzs
jxhVBhRwGIlmanFxJY0QAiPJghOGgpaHXT+K40Ufpamv6D+izf2DYZ0WzQV+w2bs
tOsNSjicahj9xNeOzmaFM484cpSjCyRsazbe20jaQe+UrVgSyr48CJoBjbaRbIDC
QVks9vMzdud7MqymfFaBeNznqd7T325ofKSNI4VvQ7I/j/ktZZqDs5zMn+X4jLIi
uRdesW+4vSOfFZs4kZ4ANjKQIby86hPjtlIYMT5kjSe2CR7LB/jRv9ky9zHGJoAF
dhEIQRrMPbTWpWFsqTH2Ch3UYdZbkb+q/6BvcieY/aq8rLWJYi1W82gwUqNQuCb1
fdnRJw64hnHKN7aDftZuflnHcAARje4umlUrwr+2RDMxsr1aNgBY/Ywd3TbN0k9N
9bfgu/z10WjySsJywaNn
=LpuT
-----END PGP SIGNATURE-----

[Rainier Wolfcastle]

On Tuesday, April 29, 2014 1:47:07 PM UTC-4, Joonas Lehtonen wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Is it also possible to post your Xorg when you disable VT-d?

Xorg logfile with VT-d disabled is attached.
This log file is from an actual installed OS (not from the installer).

I looked at it using a visual diff tool, you will notice the first
difference at line 120:

[    48.959] (++) using VT number 1

Yes, the terminal used by the installer is different from the one you use on normal boot, hence the difference in numbers here.

 

I gave 'i915.i915_enable_rc6=0' a try, but it had no effect (tested
with 3.12.14 only).


Thanks for your continued help with debugging this issue!
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTX+WbAAoJEG58zmw5nc+v9ycQAK06wM0xCSZGVRTjowiW5hgU
ZGdZ9zG9yfZauHxCsJV4tmJ2DtMYa2xQAVfKKjekvUdiJ7Ni4fMrer3CvLS+i2TT
bQzNJdmUEbNi+CBebY5+Fs4DuXPP66IxKBRr2POPj+DAgdVyv0VY9HQ0pIwsMOvc
M9vIM/XCmfHd2yq46ht/OaeOLRw9ffZjNyFRnJygWjEL0wDXkjYhky78SgdSBpL+
4UwF+rQ0sqFNoqcwLX5iv6wlVSZXhGHgLfJWO21cuLocnvl/SVDiQem10RHdqhzs
jxhVBhRwGIlmanFxJY0QAiPJghOGgpaHXT+K40Ufpamv6D+izf2DYZ0WzQV+w2bs
tOsNSjicahj9xNeOzmaFM484cpSjCyRsazbe20jaQe+UrVgSyr48CJoBjbaRbIDC
QVks9vMzdud7MqymfFaBeNznqd7T325ofKSNI4VvQ7I/j/ktZZqDs5zMn+X4jLIi
uRdesW+4vSOfFZs4kZ4ANjKQIby86hPjtlIYMT5kjSe2CR7LB/jRv9ky9zHGJoAF
dhEIQRrMPbTWpWFsqTH2Ch3UYdZbkb+q/6BvcieY/aq8rLWJYi1W82gwUqNQuCb1
fdnRJw64hnHKN7aDftZuflnHcAARje4umlUrwr+2RDMxsr1aNgBY/Ywd3TbN0k9N
9bfgu/z10WjySsJywaNn
=LpuT
-----END PGP SIGNATURE-----

Something else you can try is manually creating an xorg.conf file for your device, monitor, and screen. For your device fix the driver as vesa and then boot it without VT-d to make sure it reads the file and loads properly. Then turn VT-d on and see if you have the same problem. This would help isolating whether it is an intel driver issue, which it probably is given the GPU hangs, or somehting else.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Something else you can try is manually creating an xorg.conf file
> for your device, monitor, and screen. For your device fix the
> driver as vesa and then boot it without VT-d to make sure it reads
> the file and loads properly. Then turn VT-d on and see if you have
> the same problem.

Unfortunately I'm having problems with vesa as well (no matter if VT-d
is enabled or not)

Xorg.0.log (kernel modul i915 has been blacklisted, otherwise vesa
would be ignored even though being configured in xorg.conf) VT-d
disabled, vesa fails:
VESA(0): V_BIOS address 0x28eb0 out of range

http://pastie.org/9128660

In the dmesg output I noticed a line that caught my attention (even
though I don't know whether it is something to worry about):

pciback 0000:02:00.0: Driver tried to write to a read-only
configuration space field at offset 0xd2, size 2


At this point I'm wondering if a BIOS or XEN update would help..

I'll try to reach out to xen-devel (as the log entry suggests).


dmesg from a 3.9.2 kernel with VT-d disabled:
http://pastie.org/9128651

dmesg from a 3.9.2 kernel with VT-d enabled (no real difference):
http://pastie.org/9128655

0000:02:00.0 is the Intel Graphics card
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTYVuUAAoJEG58zmw5nc+vlU4QANwoWYU584ZR1BHvdS+MJgHd
Yilg5SudLOAclNB3Q3/tzSOXhIC19Era0kKRvRkYfJtOwQOOGIGD9WsqO7CssAQp
CEFfcTh5PIwZ4TipXXRUMJYaZ2RTtt5D54gsv8DgzbRq3Frf9Jh03rYSUndvWceG
5zhk5DcwRcILlFAZEXpcQBEk7xBqRbriAr4Y84Ix73z39f/pKdq6Ob1/cwn+DH5X
8BYLwdXwqLPu/IV7eeUMiN4ynvoID+NhHmd7vCqxVAZaS8hBQuzpFQSJoAGq5Oih
BpOfVcQiVWl3cXWz/TRnjTQHGlPXhJrd1gGCL3vf73HXuOfTI2gyKNIjvdYJwmWK
/IPtNeJCMI+x5gZxiIAOZ4fKG7AB/IQi9QB9JekhH0SrjDKL7ADHJWQ9UgwW7vE5
Bh0F0jYn0KteZm1ejLynujkD/bmpDxMRvjBwc3ucUHqt3lyKsWKksgF7dmLf1+MA
LIhmK9h+d3Jf6WLRojzhePOrGT4f3ZwcL2AIJqGNZvsbCz16KUuuVjHF4groxuVx
pLLRTBbbJske4PoFgI+N3Ch5cY/NMgYRu7sB+ZZhQhiWuZfwXDW6dXN+lmPEVFKJ
SvFsdNEuGDWqsvsU3aCeuoxSDdtsypX+mt6yql4Pk+mkRDwjv53xRLOLEEXsW7Kq
eSo2XJy/G6MCFlYa1Hay
=s1S0
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 30.04.2014 22:22, Joonas Lehtonen wrote:
>> Something else you can try is manually creating an xorg.conf file
>> for your device, monitor, and screen. For your device fix the
>> driver as vesa and then boot it without VT-d to make sure it reads
>> the file and loads properly. Then turn VT-d on and see if you have
>> the same problem.
>
> Unfortunately I'm having problems with vesa as well (no matter if VT-d
> is enabled or not)
>
> Xorg.0.log (kernel modul i915 has been blacklisted, otherwise vesa
> would be ignored even though being configured in xorg.conf) VT-d
> disabled, vesa fails:
> VESA(0): V_BIOS address 0x28eb0 out of range
>
> http://pastie.org/9128660
>
> In the dmesg output I noticed a line that caught my attention (even
> though I don't know whether it is something to worry about):
>
> pciback 0000:02:00.0: Driver tried to write to a read-only
> configuration space field at offset 0xd2, size 2
>
>
> At this point I'm wondering if a BIOS or XEN update would help..
>
> I'll try to reach out to xen-devel (as the log entry suggests).
>
>
> dmesg from a 3.9.2 kernel with VT-d disabled:
> http://pastie.org/9128651
>
> dmesg from a 3.9.2 kernel with VT-d enabled (no real difference):
> http://pastie.org/9128655
>
> 0000:02:00.0 is the Intel Graphics card

Are you trying to assign GPU to some VM? This is the only way where pciback is
used.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>> pciback 0000:02:00.0: Driver tried to write to a read-only
>> configuration space field at offset 0xd2, size 2
>>
>>
>> At this point I'm wondering if a BIOS or XEN update would help..
>>
>> I'll try to reach out to xen-devel (as the log entry suggests).
>>
>>
>> dmesg from a 3.9.2 kernel with VT-d disabled:
>> http://pastie.org/9128651
>>
>> dmesg from a 3.9.2 kernel with VT-d enabled (no real
>> difference): http://pastie.org/9128655
>>
>> 0000:02:00.0 is the Intel Graphics card
>
> Are you trying to assign GPU to some VM? This is the only way where
> pciback is used.

This is a fresh install with default AppVMs without any further
configuration (besides the xorg.conf and i915 blacklisting).

I did not try to assign a GPU to an AppVM (or any other).

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTYWKnAAoJEG58zmw5nc+vaOsP/3OErkrhms1mPtHqpaqhTAsH
pWZEhvORqf6u4fVhiWH9762ApdhguFh7kLsScDDXwOFuJnkqTth8A1I4WQjTPIxR
X1zxW8PIV32jXik95s+xefJCR+RX1LhQJOrZsGh0JgbPrMm6XsoJrwbCG9Fnomji
ayuw308ff2eSj0lKO8xJO9piUf5EqSrJed+hlbDf8qSHrThyd60KdMXUebPt4jpu
4kJtXJX6hxhHMNxq8q3qlCyQu2hflMNKaRZbw4bIG59ikM2/w5JfBm7cdnFpFhy/
ru9YszAqIWBK4unQlGDGeiOBMt7lZijneKAE+3t7Shc452BCNcroH/YAbczvNhdE
4CtVzlr8XUOGPSz9k2jk3Y1p6UeSgf1VmgyvZXaABP/p5sxI4zGfj9ublf2NU7pr
lzJgZZkiZxoF/F/F5Z6eWI/QaDYpXmlfjcR7BG4y5aEEd7jfYFGMweV4vfLpOJs+
lz3nb59+1dgNKtXM6qZOafrhc2B8/Rd0yKq1am5kBifT98jzG9igAKEMv7/RX4O0
5fV9U2gPCna3mf293K1eAbJxZqD6zRousCvny8bWLGkqZi4iJjMvzSKOlgaHmYFO
bWqaR3O90NfvnkBEdUBy7mtxikJUHUHJmVAru1II6HDUDBt0eAIWQmjdlcKWIrnb
7nipiyTWIsm/31B1Xers
=Hpve
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> I'll try to reach out to xen-devel (as the log entry suggests).

Just a heads up:
Before reaching out to xen-devel I wanted to verify if I'm able to
observe this on a "native" (not sure if/how much Qubes actually
modifies) and recent Xen, so I installed a native FC20 + Xen from the
Fedora repo.

Versions used:
- - Xen 4.3.2
- - FC20 kernel 3.13.x

I did not have any X problems (VT-d enabled). So maybe my problem has
been fixed in a more recent Xen and or Linux kernel.

I suppose it is not possible to run Qubes-OS with a more recent
Xen/kernel version?

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTYYUDAAoJEG58zmw5nc+v4TUP+gKDOA/IKcUCdxj8ZuIa9x8h
fz2E8e3+wrPJe4GqzLYD3HKVXroUPXwSc34TZEsCsgD0533XMDYf25X1TsQeF38g
rrr1htIcPbLk+3CIUsa3rNNAPDknzrOrldmpmqW/PCSf8eNmYKf8RBoZ/qIqF/c2
QNXf9xK0lpnq+mANysmmiyTMYCqonuEB51miNoMFRR8ye1Dc14bAqy+gBTXRFOOn
gg0txKeRPpHtp7Rt3HyyQl/n4KFXua/pb3BxYrmIKK6YEEOhku8mAOkYSp+baxTK
KdU6KSK/TRokuugIkhjpfaGfulIcVWdy9c8NbOkm/b1ibyxinRY+8d9JOCnISfZ2
flinMeYA9MnkZoPvnI0zobD+XxOBI5QqMXo8RGFEWawFuQH44omnTl7RVvZ6iPhV
7RlpdRbQ5tZK8RWNvx1SxYW5higghbfTQYtJ8UJJI7cyyWiRW5TEdZtLYBXEqLVr
+ujEMyAQt9V0EVta0DSMG/woRIPsAQZKpu4QKuptEmv9obs1tUDDWNnbH+JyzPvY
wcfPcxGlSx/aH6T1EW6DQ1UPJVBKtVkXPYR+ymWvevg0MwLsA/+ID11sW862hhna
0p37e2iIrNdOu+Gk78t9n3YjiX3waBFTmdwZyLQHH2fPYtIMZPQt/b1i58X5vsNk
ij6T2/6oz14RBV2p4g/I
=VGHY
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 01.05.2014 01:19, Joonas Lehtonen wrote:
>> I'll try to reach out to xen-devel (as the log entry suggests).
>
> Just a heads up:
> Before reaching out to xen-devel I wanted to verify if I'm able to
> observe this on a "native" (not sure if/how much Qubes actually
> modifies) and recent Xen, so I installed a native FC20 + Xen from the
> Fedora repo.
>
> Versions used:

> - Xen 4.3.2

> - FC20 kernel 3.13.x
>
> I did not have any X problems (VT-d enabled). So maybe my problem has
> been fixed in a more recent Xen and or Linux kernel.
>
> I suppose it is not possible to run Qubes-OS with a more recent
> Xen/kernel version?

For kernel - it is possible. You can even try to use FC20 package directly.
Check instruction here:
http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0#Howtodowngradeaspecificpackage
(yes, it will be treated by yum as downgrade, even if Fedora package looks
newer than Qubes one)

But for Xen it isn't currently possible.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>> Versions used:
>>> - Xen 4.3.2 - FC20 kernel 3.13.x
>>>
>>> I did not have any X problems (VT-d enabled). So maybe my
>>> problem has been fixed in a more recent Xen and or Linux
>>> kernel.
>>>
>>> I suppose it is not possible to run Qubes-OS with a more
>>> recent Xen/kernel version?
> For kernel - it is possible. You can even try to use FC20 package
> directly. Check instruction here:
> http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0#Howtodowngradeaspecificpackage
>
>
(yes, it will be treated by yum as downgrade, even if Fedora package looks
> newer than Qubes one)

I installed* kernel-3.13.10-200.fc20 from the fedora repo and
everything works fine now with VT-d enabled.
So my assumption is that my problem has been fixed somewhere between
kernel 3.12.x and 3.13.10, but fc20 will soon see 3.14.2 and I'll see
if things still work fine with that one.

So for now this is fixed for me.

Rainier and Marek, thank you for your help!


If there is no specific reason to not upgrade to FC kernels by
default, why not make it the default kernel in qubes-os?





*) downgrading kernel packages does not work since they allow multiple
concurrent installed kernel packages.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTYhPTAAoJEG58zmw5nc+vWssP/RDHJynci89AhLo7Oe5bqBUG
mvwieLtnmETnHyPdk1NH1AgFQO9PBUABWgujwX70y0CcPxILbxFLdY7bH0W7dcfs
5doyQad4PQqQC3vsGInL4vd4SuDGWB7FbJDqnnrUL1Y25RIl9yFX7lKJhgwnwEJl
gQ4OXeLAhdjqstr9Lld3A/i3B4WJXzeQpFMSVQQh6Gx79dau4CODBVRbe2v17nyY
XxRevz1sdr4EAgxAymGgWo6WD7UtFrdmbTUYqkngXNQQjpekhm9xU55DKnXknl1G
6j9jElSvuRrMetYeQWLmZ/Yr0EWQ8XBCD88BBjL2FEtQ0I2BtcWjuBGHRPGnNjuO
n8DdmcKoQ5yWA8gioSFPGaXDMvaUdBCzHcm1RJ2qEd1VnOzPXBPt59E46K1a1I56
tnAM/+Yritc6e3NNO0kmiPLyP/UMZq7seRfcDKpw3mRccUFIEMugTcoh1zzOchzX
M+LJjqFPTIa5EvoVssmeztA01Co/ZVWnG7ugFJ4UhE/anSoci7Tj4xPf4DdQjGuU
hJAq0svSYso/xW7FKhYW19eQecI8J+2vxaUKaZQEk5ieDY0y8O7nyNTKqss6flWe
uPdTLduewR7H/2iaB1/HsQr3ERdVd5oFyB8wav9EjVpPzVOMwwoBy6gLwKJl5ieH
JJhUF+k2MCM1x9a/sXFQ
=uFrp
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 01.05.2014 11:28, Joonas Lehtonen wrote:
>>> Versions used:
>>>> - Xen 4.3.2 - FC20 kernel 3.13.x
>>>>
>>>> I did not have any X problems (VT-d enabled). So maybe my
>>>> problem has been fixed in a more recent Xen and or Linux
>>>> kernel.
>>>>
>>>> I suppose it is not possible to run Qubes-OS with a more
>>>> recent Xen/kernel version?
>> For kernel - it is possible. You can even try to use FC20 package
>> directly. Check instruction here:
>> http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0#Howtodowngradeaspecificpackage
>
>
> (yes, it will be treated by yum as downgrade, even if Fedora package looks
>> newer than Qubes one)
>
> I installed* kernel-3.13.10-200.fc20 from the fedora repo and
> everything works fine now with VT-d enabled.
> So my assumption is that my problem has been fixed somewhere between
> kernel 3.12.x and 3.13.10, but fc20 will soon see 3.14.2 and I'll see
> if things still work fine with that one.
>
> So for now this is fixed for me.
>
> Rainier and Marek, thank you for your help!
>
>
> If there is no specific reason to not upgrade to FC kernels by
> default, why not make it the default kernel in qubes-os?

There are some Qubes-specific patches, mostly to make ACPI S3 working. 3.12.x
is the first upstream release containing them, but still, there are rather
often some fixes needed for Xen on desktop system not included in upstream
release for a long time.

[Marek Marczykowski-Górecki]

On 01.05.2014 22:58, Marek Marczykowski-Górecki wrote:
> On 01.05.2014 11:28, Joonas Lehtonen wrote:
>>>> Versions used:
>>>>> - Xen 4.3.2 - FC20 kernel 3.13.x
>>>>>
>>>>> I did not have any X problems (VT-d enabled). So maybe my
>>>>> problem has been fixed in a more recent Xen and or Linux
>>>>> kernel.
>>>>>
>>>>> I suppose it is not possible to run Qubes-OS with a more
>>>>> recent Xen/kernel version?
>>> For kernel - it is possible. You can even try to use FC20 package
>>> directly. Check instruction here:
>>> http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0#Howtodowngradeaspecificpackage
>>
>>
>> (yes, it will be treated by yum as downgrade, even if Fedora package looks
>>> newer than Qubes one)
>>
>> I installed* kernel-3.13.10-200.fc20 from the fedora repo and
>> everything works fine now with VT-d enabled.
>> So my assumption is that my problem has been fixed somewhere between
>> kernel 3.12.x and 3.13.10, but fc20 will soon see 3.14.2 and I'll see
>> if things still work fine with that one.
>>
>> So for now this is fixed for me.
>>
>> Rainier and Marek, thank you for your help!
>>
>>
>> If there is no specific reason to not upgrade to FC kernels by
>> default, why not make it the default kernel in qubes-os?
>
> There are some Qubes-specific patches, mostly to make ACPI S3 working. 3.12.x

3.11.x, not 3.12. But 3.12 is the first such kernel selected as longterm support.

[sampab...@googlemail.com]

On Thursday, May 1, 2014 at 10:28:51 AM UTC+1, Joonas Lehtonen wrote:
> I installed* kernel-3.13.10-200.fc20 from the fedora repo and
> everything works fine now with VT-d enabled.
> So my assumption is that my problem has been fixed somewhere between
> kernel 3.12.x and 3.13.10, but fc20 will soon see 3.14.2 and I'll see
> if things still work fine with that one.
>
> So for now this is fixed for me.

I'm thinking of getting an X201 i5-520M HD3000 like yours, also for use with Qubes OS.

Is yours still working for you? How about with R2rc2, R2, or R3rc1 (e.g. were tweaks still needed, or did those work straight off)?

Anything else to be aware of? (Please feel free to put your reply in a new thread if it's beyond the scope of this one!)

Thanks :)

[Me]

What's the current status of this? Currently I am using Qubes without VT-d enabled on my X201 and haven't found a way to boot without graphic problems whenever VT-d is active.

Does the described kernel exchange work? What possible workarounds are we able to use?

[dbo...@gmail.com]

I have the same no-boot problems on my x220 tablet when vt-d and virtualisation are enabled in the bios. R3.1rc2

[marek]

This is how the problem looks visually on a X201. Other Linux distributions - ranging from Kernel 2.6 to 4.2 give no problems.

Let me know what can be done here. Qubes without VT-d is pretty much useless for me and I bought the X201 just for using it with Qubes.

[Eric Shelton]

On Saturday, February 27, 2016 at 9:50:48 AM UTC-5, marek wrote:

This is how the problem looks visually on a X201. Other Linux distributions - ranging from Kernel 2.6 to 4.2 give no problems.

Let me know what can be done here. Qubes without VT-d is pretty much useless for me and I bought the X201 just for using it with Qubes.

You might want to explore things like 'intel_iommu=igfx_off' (kernel command line option) and 'iommu=igfx_off' (Xen command line option - not sure if that patch got pulled in).  

The following link deals with a patch for some special quirks for pre-Sandy Bridge IGD graphics in combination with Xen's VT-d implementation: https://groups.google.com/forum/#!topic/qubes-devel/wGd97IoBAPE (patch available at https://gist.github.com/ktemkin/0e81b93654ae800a5609 - note that this issue was never resolved on xen-devel to the point where a patch was rolled into Xen proper, probably due to lack of interest in development for older processors).  You will need to sort out compiling the hypervisor (vmm-xen) to apply the patch (see https://www.qubes-os.org/doc/qubes-r3-building/).  If that patch does help out - maybe we can consider rolling it into Qubes to improve the situation for hardware such as yours.

Here is another post by the same user (using an X200) that may be relevant to you: https://groups.google.com/d/msg/qubes-users/bHQHjXqinaU/RHGjfFijDAAJ  

Good luck.  There are very few users using Qubes on pre-Sandy Bridge CPUs, so for the most part you are looking at having to sort this out on your own.  VT-d was basically a niche feature for a while, and it is only in the last couple of generations of Intel processors that Intel and vendors have gotten their acts together.  Notebooks built around pre-Sandy Bridge CPUs seem to be particularly difficult to deal with.

Eric

[marek]

Great news, booting Vanilla Debian Testing with Xen 4.6 with iommu=no-igfx works perfectly.
No graphics bugs. Trying with Qubes as soon as possible

[marek]

Unfortunately, the patch[1] apparently didn't make it into the Xen used in Qubes, or the SysLinux
doesn't pass the correct Xen args.

1. https://github.com/xenserver/xen-4.6/commit/146341187adf99cde71a8d63dbf4733d6a3932ca

[marek]

I hacve to correct myself. It works. I will provide instructions asap.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> On Sunday, February 28, 2016 at 3:28:31 PM UTC+1, marek wrote:
> >
> > Great news, booting Vanilla Debian Testing with Xen 4.6 with

> > *iommu=no-igfx* works perfectly.

It is here, at least in Xen 4.6.0 used in Qubes 3.1

https://github.com/mirage/xen/commit/146341187adf99cde71a8d63dbf4733d6a3932ca
(mirror on github, in contrast to original gitweb, does display in which
branch and tags it is included)

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW0wjaAAoJENuP0xzK19cs9TsIAIYN2yPNl9hpORvgIWhihD1b
9/8oRSUCSlgwXFJAmEZ5u2BYC+u8NAxzM8EmraqvwBrj7mS/+VMjiDsH4/7hlbzg
tsxkG5CXPir4hP8bQTUBVmUYh/7PBMD8slSMJpg4xYbvLp6D9fkGOt15UqMHlqUj
eNCtGI/v6ck8wziHcVZeqzzZZ9Jj1y0eg0jQFVjphrAphFrT5JU6Ubmju1CG1ww1
SK5oJ/guGI7ff3XlcQjNMOGJLTjAmVaCuzmV0Uc7aCoa2mt/Y1goajliJjKG1E+Z
YGCOkzzPUpYakw0sMb4PRfRdxUIlxcinTEhsSxZxBM8GNcqtQx+tLWGE+m7jLRs=
=y29q
-----END PGP SIGNATURE-----