Please enable drm.debug=0xf to get drm core debugging, *or* apply this patch to debug the hotplug events:

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ab1a5f6dde8a..6abf092d9eb4 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -481,7 +481,7 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
 	char *event_string = "HOTPLUG=1";
 	char *envp[] = { event_string, NULL };
 
-	DRM_DEBUG("generating hotplug event\n");
+	DRM_DEBUG_KMS("generating hotplug event\n");
 
 	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
 }

Now, doing hotplug and looking at both udevadm monitor and dmesg, do you see cases where:

a) there's the "generating hotplug event" in dmesg, but you do *not* get it in udevadm monitor

*or*

b) you do hotplug but the message is not in dmesg and you don't get it in udevadm either.

Created attachment 106403 [details]
dmesg

(In reply to comment #1)
> Please enable drm.debug=0xf to get drm core debugging, *or* apply this patch
> to debug the hotplug events:
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ab1a5f6dde8a..6abf092d9eb4 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -481,7 +481,7 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
>  	char *event_string = "HOTPLUG=1";
>  	char *envp[] = { event_string, NULL };
>  
> -	DRM_DEBUG("generating hotplug event\n");
> +	DRM_DEBUG_KMS("generating hotplug event\n");
>  
>  	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
>  }
> 
> Now, doing hotplug and looking at both udevadm monitor and dmesg, do you see
> cases where:
> 
> a) there's the "generating hotplug event" in dmesg, but you do *not* get it
> in udevadm monitor
> 
> *or*
> 
> b) you do hotplug but the message is not in dmesg and you don't get it in
> udevadm either.

Enable drm.debug=0xf, then doing hotplug, the result is case a):the hotplug event is able to catch by dmesg, and not catch by udevadm monitor.

Dmesg info
[  216.014284] [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00040000, dig 0x00000000
[  216.014307] [drm:intel_hpd_irq_handler] digital hpd port B - short
[  216.014389] [drm:intel_dp_hpd_pulse] got hpd irq on port B - short
[  233.419105] [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00040000, dig 0x00000000
[  233.419130] [drm:intel_hpd_irq_handler] digital hpd port B - short
[  233.419172] [drm:intel_dp_hpd_pulse] got hpd irq on port B - short

(In reply to comment #2)
> Created attachment 106403 [details]
> dmesg
> 
> (In reply to comment #1)
> > Please enable drm.debug=0xf to get drm core debugging, *or* apply this patch
> > to debug the hotplug events:
> > 
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index ab1a5f6dde8a..6abf092d9eb4 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -481,7 +481,7 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  	char *event_string = "HOTPLUG=1";
> >  	char *envp[] = { event_string, NULL };
> >  
> > -	DRM_DEBUG("generating hotplug event\n");
> > +	DRM_DEBUG_KMS("generating hotplug event\n");
> >  
> >  	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> >  }
> > 
> > Now, doing hotplug and looking at both udevadm monitor and dmesg, do you see
> > cases where:
> > 
> > a) there's the "generating hotplug event" in dmesg, but you do *not* get it
> > in udevadm monitor
> > 
> > *or*
> > 
> > b) you do hotplug but the message is not in dmesg and you don't get it in
> > udevadm either.
> 
> Enable drm.debug=0xf, then doing hotplug, the result is case a):the hotplug
> event is able to catch by dmesg, and not catch by udevadm monitor.

I can't see "generating hotplug event" in the attached dmesg when you hotplug. Whether you end up in that function or not is crucial in figuring out where the problem is. Based on the dmesg, I think it's actually b) but I can't be sure.

Based on a hunch, please try reverting
commit 36cd7444c044806cd2a4e450a8385597221d5d25
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 2 13:44:18 2014 +1000

    drm/i915: check connector->encoder before using it.

and try again.

The failure is able to reproduce on HSW-M

(In reply to comment #4)
> The failure is able to reproduce on HSW-M

Please see comment #3.

Created attachment 106892 [details]
dmesg

(In reply to comment #3)
> (In reply to comment #2)
> > Created attachment 106403 [details]
> > dmesg
> > 
> > (In reply to comment #1)
> > > Please enable drm.debug=0xf to get drm core debugging, *or* apply this patch
> > > to debug the hotplug events:
> > > 
> > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > index ab1a5f6dde8a..6abf092d9eb4 100644
> > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > @@ -481,7 +481,7 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > >  	char *event_string = "HOTPLUG=1";
> > >  	char *envp[] = { event_string, NULL };
> > >  
> > > -	DRM_DEBUG("generating hotplug event\n");
> > > +	DRM_DEBUG_KMS("generating hotplug event\n");
> > >  
> > >  	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > >  }
> > > 
> > > Now, doing hotplug and looking at both udevadm monitor and dmesg, do you see
> > > cases where:
> > > 
> > > a) there's the "generating hotplug event" in dmesg, but you do *not* get it
> > > in udevadm monitor
> > > 
> > > *or*
> > > 
> > > b) you do hotplug but the message is not in dmesg and you don't get it in
> > > udevadm either.
> > 
> > Enable drm.debug=0xf, then doing hotplug, the result is case a):the hotplug
> > event is able to catch by dmesg, and not catch by udevadm monitor.
> 
> I can't see "generating hotplug event" in the attached dmesg when you
> hotplug. Whether you end up in that function or not is crucial in figuring
> out where the problem is. Based on the dmesg, I think it's actually b) but I
> can't be sure.
> 
> Based on a hunch, please try reverting
> commit 36cd7444c044806cd2a4e450a8385597221d5d25
> Author: Dave Airlie <airlied@redhat.com>
> Date:   Fri May 2 13:44:18 2014 +1000
> 
>     drm/i915: check connector->encoder before using it.
> 
> and try again.

On latest nightly(7101d84020f63f1da7e0c5d021cdd6be4d515de5) revert commit above, udevadm monitor still doesn't work.

Please try patch https://bugs.freedesktop.org/attachment.cgi?id=106729 from bug 83175.

Created attachment 106980 [details]
dmesg

(In reply to comment #7)
> Please try patch https://bugs.freedesktop.org/attachment.cgi?id=106729 from
> bug 83175.

udevadm monitor still doesn't work with this patch.

Hey!

I am unsure if I have the same bug. I am running a 3.16 with:

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)

When unplugging, I don't see anything in udev, but dmesg tells me:

Oct 20 21:11:31 eizo kernel: [  216.255211] [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00800000
Oct 20 21:11:31 eizo kernel: [  216.255212] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 6 - cnt: 0
Oct 20 21:11:31 eizo kernel: [  216.255223] [drm:i915_hotplug_work_func] running encoder hotplug functions
Oct 20 21:11:31 eizo kernel: [  216.255226] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 6) received hotplug event.
Oct 20 21:11:31 eizo kernel: [  216.255228] [drm:intel_hdmi_detect] [CONNECTOR:22:HDMI-A-3]
Oct 20 21:11:31 eizo kernel: [  216.255231] [drm:intel_display_power_get] enabling always-on
Oct 20 21:11:31 eizo kernel: [  216.281919] [drm:drm_detect_monitor_audio] Monitor has basic audio support
Oct 20 21:11:31 eizo kernel: [  216.281921] [drm:drm_rgb_quant_range_selectable] CEA VCDB 0x0f
Oct 20 21:11:31 eizo kernel: [  216.281923] [drm:intel_display_power_put] disabling always-on


Should I try to 3.17?

Please retest with current drm-intel-nightly.

I am experiencing this bug on HSW. udevadm monitor does not show hot plug events and it only triggers the rule below once:

SUBSYSTEM=="drm", ACTION=="change", RUN+="script.sh"

I'm using the current drm-intel-nightly and I'm using kernel 3.19.6.

Created attachment 116183 [details] [review]
Fire udev event if the hpd interrupt was fired regardless of the previous status

In i915_irq.c of the i915 kernel driver, the test in intel_hpd_irq_event, which checks the old status and the new status of the connector is not comparing the correct statuses. The attached patch assumes that there was a change at the connector if the hpd interrupt was fired and doesn't rely on checking the old and new status. This probably isn't the correct fix and the correct one would be to make sure the new status is accurate. However, with this patch, I can now see the correct events in udevadm monitor and I am not getting duplicates.

Hugh, please attach full dmesg with drm.debug=14 module parameter set, *without* your patch.

Created attachment 116225 [details]
Dmesg output after plugging waiting and then unpluging the HDMI cable

Here is the dmesg output where I plugged in an HDMI cable, waited a few seconds until I saw the output on the external screen, and then unplugged it.

Created attachment 116358 [details] [review]
drm/i915: wait a little before queuing hotplug work functions

Untested, something to try. On top of drm-intel-nightly.

(In reply to Jani Nikula from comment #15)
> Created attachment 116358 [details] [review] [review]
> drm/i915: wait a little before queuing hotplug work functions
> 
> Untested, something to try. On top of drm-intel-nightly.

The patch with drm-intel-nightly showed all of the events with udevadm. Thanks!

(In reply to Jani Nikula from comment #15)
> Created attachment 116358 [details] [review] [review]
> drm/i915: wait a little before queuing hotplug work functions
> 
> Untested, something to try. On top of drm-intel-nightly.

I had to modify the patch slightly so it compiled. dev_priv->hotplug didn't exist in any of the kernels I tried (3.19.6, 4.0.4, 4.1-rc7). So, I removed dev_priv->hotplug where I needed. For example, &dev_priv->hotplug.hotplug_work became: &dev_priv->hotplug_work. I can attach the modified patch tomorrow.

(In reply to Hugh Greenberg from comment #11)
> I am experiencing this bug on HSW. udevadm monitor does not show hot plug
> events and it only triggers the rule below once:
> 
> SUBSYSTEM=="drm", ACTION=="change", RUN+="script.sh"
> 
> I'm using the current drm-intel-nightly and I'm using kernel 3.19.6.

Btw, what's the failure mode you see after the missed event? If I'm interpreting the situation right, you should still have the picture on screen after you replug.

(In reply to Jani Nikula from comment #18)
> (In reply to Hugh Greenberg from comment #11)
> > I am experiencing this bug on HSW. udevadm monitor does not show hot plug
> > events and it only triggers the rule below once:
> > 
> > SUBSYSTEM=="drm", ACTION=="change", RUN+="script.sh"
> > 
> > I'm using the current drm-intel-nightly and I'm using kernel 3.19.6.
> 
> Btw, what's the failure mode you see after the missed event? If I'm
> interpreting the situation right, you should still have the picture on
> screen after you replug.

I'm working on 2 different bugs related to HDMI on Ubuntu Unity. The missed events didn't cause any problems, but they prevent me from running a command to fix issues when an event occurs.

1. Plugging in the HDMI cable does show a picture on the external screen and Unity is expanded to both screens, but sometimes, there are corrupted graphics on the laptop screen. xrandr --auto will refresh the screen. I can't remember the exact Compiz warning, but it couldn't apply a texture.

2. Removing the HDMI cable will not trigger Unity to resize the screen sometimes. Again xrandr --auto will resize the screen.

Without your patch, I would need to poll the connector status and I would rather not do that.

(In reply to Hugh Greenberg from comment #19)
> (In reply to Jani Nikula from comment #18)
> > (In reply to Hugh Greenberg from comment #11)
> > > I am experiencing this bug on HSW. udevadm monitor does not show hot plug
> > > events and it only triggers the rule below once:
> > > 
> > > SUBSYSTEM=="drm", ACTION=="change", RUN+="script.sh"
> > > 
> > > I'm using the current drm-intel-nightly and I'm using kernel 3.19.6.
> > 
> > Btw, what's the failure mode you see after the missed event? If I'm
> > interpreting the situation right, you should still have the picture on
> > screen after you replug.
> 
> I'm working on 2 different bugs related to HDMI on Ubuntu Unity. The missed
> events didn't cause any problems, but they prevent me from running a command
> to fix issues when an event occurs.
> 
> 1. Plugging in the HDMI cable does show a picture on the external screen and
> Unity is expanded to both screens, but sometimes, there are corrupted
> graphics on the laptop screen. xrandr --auto will refresh the screen. I
> can't remember the exact Compiz warning, but it couldn't apply a texture.
> 
> 2. Removing the HDMI cable will not trigger Unity to resize the screen
> sometimes. Again xrandr --auto will resize the screen.
> 
> Without your patch, I would need to poll the connector status and I would
> rather not do that.

Actually, xrandr --auto doesn't fix the graphics corruption, but it does force a resize.

Also, I have found that if I remove the hdmi cable slowly, I do not always see a udev event with udevadm monitor.

My theory is that we get a hotplug irq on unplug, but sometimes we manage to run the detect code before the cable is completely disconnected, and we figure the cable is still there, and keep transmitting. When the cable is plugged in again, we run the detect code, and figure nothing changed because we kept thinking the cable is there. Therefore no uevent in either case.

Hugh, here's the version I submitted upstream, I took the liberty of using your Tested-by although what you tried was a slightly different version: http://patchwork.freedesktop.org/patch/51634

Actually trying this one as well would be appreciated! :)

(In reply to Jani Nikula from comment #22)
> Hugh, here's the version I submitted upstream, I took the liberty of using
> your Tested-by although what you tried was a slightly different version:
> http://patchwork.freedesktop.org/patch/51634
> 
> Actually trying this one as well would be appreciated! :)

No problem. I will test it this evening.

(In reply to Jani Nikula from comment #22)
> Hugh, here's the version I submitted upstream, I took the liberty of using
> your Tested-by although what you tried was a slightly different version:
> http://patchwork.freedesktop.org/patch/51634
> 
> Actually trying this one as well would be appreciated! :)

It works great! Thank you.

Test it on the drm-intel-nightly branch kernel(drm-intel-nightly_4643c5_20150613+), this problem has go away. 
output info:
--------------------
root@x-byt01:~# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[94.273388] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [94.274861] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
KERNEL[106.362164] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [106.363598] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)

BTW, on the latest nightly kernel with this patch, this problem also has go away, the same as the output info.

please see the dmesg info.

Created attachment 116496 [details]
dmesg info with  latest nightly

Created attachment 116497 [details]
dmesg info with the patch

looks like it's fixed?