Bug 58436

How hard is the freeze? Is the machine still accessible over the network? Are you able to switch to a VT?

The freeze is total:
- the machine is not anymore accessible over the network
- the mouse and the keyboard are not responding anymore => it is not possible to switch to another VT

In a nutshell I would declare it legally dead.

Hm, that's pretty bad. If you have a second machine, can you try to setup netconsole loggind (will require some yelling&screaming to get that going, I can try to dig out howtos if you want). If you have that set up, enable full drm debuggin with

# echo 0xf > /sys/module/drm/parameter/debug

while the netconsole is logged on the other side, then hang your machine with the VGA unplug/plug. If we're lucky the netconsole output has some useful information.

Created attachment 71754 [details]
Netconsole log when unplugging the VGA connector

I have grabbed the logs using netconsole using this howto: https://wiki.ubuntu.com/Kernel/Netconsole

On Ubuntu, the drm debug file is in a directory called "parameters" so to enable full drm debugging I used:

echo 0xf > /sys/module/drm/parameters/debug

I don't know if the logs contain useful information, they end with these 2 lines: 

[  277.344263] [drm:i965_irq_handler], hotplug event received, stat 0x08000800
[  277.344291] [drm:i915_hotplug_work_func], running encoder hotplug functions

Hope this helps.

Hm, seems to be fairly garbled, which can happen if too much goes over console and the netconsole tx/rx side gets overloaded (it doesn't resend obviously ...). It looks though as if we attempt a modeset, so new stuff for you to test:
- Maybe try to enable the netconsole only at runtime, ime that helps with such cases (it's already garbled in early boot ...).
- Please start X with a really dumb desktop enviroment (failsafe with just a shell) to check whether the automatic modeset is the issue, or the hotplug handling itself. You can't just stop X, since the kms fbcon will also do an automatic modeset.
- Please boot with VGA plugged in and enable/disable the VGA output with xrandr manually (your DE might again get in the way, some do a lot of automagic for display configuration).

If we're really unlucky, the above works and the kernel only dies when the modeset follows the hotplug right away ...

Disregard my comment, I've looked at the wrong netconsole output - too many bugs ...


It seems to indeed die right when the hotplug handling is run, which is strange. I need to cook further debug patches. For reference, can you please boot with drm.debug=0xe added to your kernel cmdline, boot and attach the complete dmesg? It'll tell us tons about what your hw looks like.

Created attachment 71767 [details]
dmesg obtained after boot with drm.debug=0xe

The "non asle set request??" line is a bit interesting, which happens when probing the VGA output:

[    9.492349] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1]
[    9.492356] non asle set request??

Can you please check whether that always happens (you need drm.debug=0xe enabled, ofc)? You should be able to force a probe cycle by running xrandr.

Created attachment 76881 [details]
new dmesg obtained after boot with drm.debug=0xe

Obtained with boot parameter drm.debug=14

No logs are written to /var/logs/dmesg when running xrandr with drm.debug=0xe.
I have tried xrandr and xrandr --output VGA1 --auto

I have attached the dmesg file obtained after booting the system.

Presuming fixed on latest kernel versions, please reopen if this is still broken. Thanks.

The problem is still present with latest kernel 3.12.0.
Tested on Ubuntu 13.10 64 bit.

Shot in the dark: If you disable acpi on the kernel cmdline, does this still happen? I wonder whether we have a hw issue at hand here or whether this is just a really ugly interaction with the firmware.

The problem disappears when acpi is off.

Cool, occasional a wild guess succeeeds. Looks like your acpi implementation is doing something truly nasty behind our backs. Can you please file a bug on bugzilla.kernel.org for this issue and link to this report here?

If it turns out it's an issue on the gfx side then we can easily move it back on kernel bz to the intel driver.

Thanks Daniel !
Kernel bug report :
https://bugzilla.kernel.org/show_bug.cgi?id=66771