Arch Linux

If you disable xdm and use startx instead does that also cause a system lockup?

I decided to test/try other login managers: lxdm, sddm.
The results are the same as with xdm. They fail with linux/linux-zen. So it's not an xdm problem.

It seems that the only login manager I can use with current linux/linux-zen is gdm.

> If you disable xdm and use startx instead does that also cause a system lockup?

Yes, hard freeze.
I attach the Xorg.0.log that startx generated.

I suspect gdm is not affected by the same issue as it will default to using Wayland not X11.
At a guess does adding the boot parameter intel_iommu=off prevent the lock up?

Hi! I don't have the machine with me ATM.
As soon as I get back to it I'll report.
Thank's for your help.

That log doesn't look like a hard freeze. Have you switched to another TTY?

> At a guess does adding the boot parameter intel_iommu=off prevent the lock up?
Yes, with this parameter xdm/lxdm/etc... work as expected

> That log doesn't look like a hard freeze. Have you switched to another TTY?
It's the log I obtained stopping gdm from a console (sudo systemctl stop gdm) and executing startx from that same console.

Possibly  FS#55629  does intel_iommu=igfx_off also allow X to work as expected?

> does intel_iommu=igfx_off also allow X to work as expected?

Yes, with this parameter it also works.
Is it preferred over intel_iommu=off then?

https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit covers the advantages and disadvantages of using IOMMU.
With intel_iommu=igfx_off IOMMU is enabled except for the the the integrated GPU.

I'm having the same issue with GDM. Can't do anything on the most recent stable kernel (4.13.3), can't switch to another TTY, nothing. Had to downgrade to 4.12, my hardware is a ThinkPad T450s with i7 (5600u) and intel hd 5500

"intel_iommu=off" helps

same here with a ThinkPad T450s with i7 5600u and intel hd 5500. hard freeze.

journalctl say somethink like:
[drm:drm_atomic_helper_swap_state [drm_kms_helper]] *ERROR* [CRTC:32:pipe A] hw_done timed out
drm/i915: Resetting chip after gpu hang
[drm] GPU crash dump saved to /sys/class/drm/card0/error
[drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[drm] GPU HANG: ecode 8:0:0x85dffffb, in plasmashell [817], reason: Hang on rcs0, action: reset
DMAR: [DMA Read] Request device [00:02.0] fault addr bc2000 [fault reason 05] PTE Write access is not set
[...]
DMAR: DRHD: handling fault status reg 3

downgrade to 4.12.13-1 kernel is a temporary workaround.

Same on my Thinkpad T520 (i7-2620M, HD3000).

Error in my case is:
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:32:pipe A] flip_done timed out

I can work around the freezes by disabling the GPU IOMMU or downgrading to kernel 4.12.13-1.

Someone with appropriate permissions should probably change the headline of this bug, as it isn't specific to Nvidia hardware or the nouveau driver.

@FlashG0rd0n and @akellerm there is already  FS#55629  for issues when the GPU in question is using the i915 module.
As acorbi's system is not logging any output related to the issue before freezing it may or may not be  FS#55629 

I'm having a similar issue with two of my computers.
My workaround at the moment is to disable the VT-d (virtualization) feature in my bios. (no KVM at the moment)
My sandy brdige gave me a kernel panic straight away but my haswell started freezing randomly after boot.
The sandy bridge uses nvidia drivers but the haswell has just an intel graphics inside.
The kernel panic said something about IOMMU which is somehow related to VT-d.