Bug 73694

Reading this slightly related bug report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/912387 gave me the idea of trying to set a lower res on the external screen and sure enough 1024x768 works as does 1280x0124 but anything higher 1650x1050 or 1920x1080 again produces the stream of those same error message in kernel.log and the sexternal screen goes black. Switching between any of the lower resolutions does *not* produce the error messages.

Really hope this can help point in the direction of what could be going wrong...

Created attachment 92231 [details] [review]
reverse dp link params selection

Please test the attached patch. If it doesn't work out please boot with drm.debug=0xe and attach the complete dmesg.

Ok, WOW! first off thanks Daniel for looking at this so quickly!

I applied the patch to my local 3.13 kernel (at commit 09f2344d0896eb458a639b922224c7a202c11599) and it works perfectly now!!
and no more error messages at all.

I guess there needs to be some kind of check for this dock to reverse that for loop? All I know at the moment is that its a Dell "E/Port Plus Advanced Port Replicator (ANZ)" but I'm happy to dig further to get you any other info you may need to be able to identify it.

Also should I also report this in the Ubuntu bugtracker  or will it just trickle down to them eventually? 

I ask as this Dell Laptop (at least in the US) is actually marked as being "Certified Pre-Install":
http://www.ubuntu.com/certification/hardware/201304-13408/

though I suspect they did not actually test if it worked with the docking station.

This patch is gold!

I can confirm that the suggested patch solves the problem with the external screen not starting correctly on boot or resume from sleep on a Dell Latitude E7440 + E-Dock. Currently running a drm-intel 3.13.0-rc8 kernel on Fedora 20 with the proposed patch and the external screen now starts as it should. I no longer have a problem where a kworker process eats CPU for about 5 minutes until the screen is detected making the computer more or less unusable during that time, and repeatedly writes out "failed to train dp aborting" in dmesg, so a massive improvement.

Only remaining problem is to sort out issues with washed out colors on the external monitor in Gnome (which existed before I applied this patch as well).

Thanks for this one.

Problem fixed with this patch!

Same configuration Dell E7440 + eDock with an external monitor.

Thanks

Same problem here, with E7240.  I applying the patch against Debian's 3.12 and it worked marvelously.

Is this going to be applied upstream ?

(In reply to comment #6)
> Is this going to be applied upstream ?

This is a tough one. The display port spec tells us to do things in the order of the patch, and we've tried it before, *but* it regresses some setups. In order to apply this, we'd have to figure out how to deal with those. Unfortunately the "no regressions rule" trumps "correct by the specs", even when the latter fixes stuff.

> those. Unfortunately the "no regressions rule" trumps "correct by the
> specs", even when the latter fixes stuff.

How about making it an option to the module ?  Yes I know this is an ugly solution, but will spare some of us the need to recompile the entire kernel.  And a "please follow the specs" option (when the default is not to follow) does not seem entirely unreasonable, does it ?

I'll tempt fate and submitted this patch for inclusion ... maybe it works this time around ;-)

(In reply to comment #9)
> I'll tempt fate and submitted this patch for inclusion ... maybe it works
> this time around ;-)

Daniel thats excellant news! thank you! is there a lkml thread that I should follow to keep up with its status?

Patch is in my -next queue heading towards 3.15:

commit 3263b11d780dd6888684c9144dcfe433176d9139
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Mar 3 11:18:10 2014 +0100

    drm/i915: reverse dp link param selection, prefer fast over wide again

I'm running Arch Linux on a docked Dell E7440. With this patch applied to Arch's 3.13.5 kernel, the 'failed to train DP' error disappears but xrandr still reports the output as DP1 independent of physical port. Further, xrandr fails to separate dual monitors and reports them as a combined screen on DP1.

I tried various Ubuntu distributions (12.04, 13.10 and 14.04) and Linux Mint 16 (Cinnamon and XFCE) on a docked Dell E7240 connected to two Displayport monitors. Xrandr only detects a connection on DP2. I am able to set the resolution to 3840x1080 to get one large desktop, but two seperate 1920x1080 desktops are not possible.

Emil, you have a different bug remaining. Please file a new report - smashing everything from different people into the same report just leads to chaos.

(In reply to comment #14)
> Emil, you have a different bug remaining. Please file a new report -
> smashing everything from different people into the same report just leads to
> chaos.

Sorry! The original post mentioned how xrandr always reported the output as DP1, so I though it could be related. Tanks for your response.

(In reply to comment #15)
> (In reply to comment #14)
> > Emil, you have a different bug remaining. Please file a new report -
> > smashing everything from different people into the same report just leads to
> > chaos.
> 
> Sorry! The original post mentioned how xrandr always reported the output as
> DP1, so I though it could be related. Tanks for your response.

Would anyone be willing to open a new bug report to have this addressed?  I'd do it myself but I'm quite inexperienced.

Thanks!

(In reply to comment #16)
> Would anyone be willing to open a new bug report to have this addressed? 
> I'd do it myself but I'm quite inexperienced.
> 
> Thanks!

I have done some search and I think the problem is lack of support for Multi Stream Transport as reported in bug 72795 at https://bugs.freedesktop.org/show_bug.cgi?id=72795

Sorry Daniel, I think I am going to ruin everyones day:  due to a hardware fault, I recently had first the LCD, lvds cable and then finally motherboard.

It was only after the motherboard was replaced that I had a working screen, so I don't have any data with combination of old motherboard and new screen_lvds cable, sorry.

BUT the end result of this has been that 3.14 kernel with this patch applied no longer works - I don't get the previous errors in dmesg, but neither can I get res higher than 1024x768 on the external screen when plugged into the edock. And with the patch removed, 3.14 kernel works fine with ext screen via edock!

Looking at my dmesg now, the main difference I can see is that with the new motherboard I now have the next version of the "BIOS":

[Mon Apr 14 09:02:05 2014] DMI: Dell Inc. Latitude E7440/0WK2DM, BIOS A05 09/23/2013

where previously it was:
[Wed Apr  2 09:06:45 2014] DMI: Dell Inc. Latitude E7440/03HFCG, BIOS A04 09/05/2013

Please let me know if I can provide any more info that will help - as I suspect once people start using e74xx laptops with the newer bios version and edock and 3.15 this is going to generate more bugs reports :-(

Please post dmesg *and* intel_reg_dumper output for both the patch applied and without the patch. Thanks.

Hi Maskim, I also tried with different kernel versions and I have the following result:
- kernel 3.11 without patches: external monitor not working
- kernel 3.11 with this patch: works
- kernel 3.13 with and w/o patches: not working
- kernel 3.15-rc2: works
Could you give kernel 3.15 a try?

(In reply to comment #20)
> Hi Maskim, I also tried with different kernel versions and I have the
> following result:
> - kernel 3.11 without patches: external monitor not working
> - kernel 3.11 with this patch: works
> - kernel 3.13 with and w/o patches: not working
> - kernel 3.15-rc2: works
> Could you give kernel 3.15 a try?

Yes sure I can pull 3.15, build it and give it a go. But given that Daniel said he was submitting the patch for inclusion into 3.15 I'm guessing it's already in the current 3.15 rc ?

Jani sorry I haven't had time to get back to this til now, but I'll also get the dmesg and intel_reg_dumper outputs with & without the patch on 3.14 and post them here.

(In reply to comment #2)
> Created attachment 92231 [details] [review] [review]
> reverse dp link params selection
> 
> Please test the attached patch. If it doesn't work out please boot with
> drm.debug=0xe and attach the complete dmesg.

Hello Daniel Vetter,

sorry, but your patch makes things worse.

With kernel 3.15.7 (that includes your patch), I get lots of these messages when I do Alt-F1 to switch from X to console. The monitor connected via display port stays black:

[ 1775.967734] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
[ 1776.016555] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.031180] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.045291] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.059590] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.074084] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.088169] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.102208] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.103948] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
[ 1776.532617] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.546898] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.560964] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.575010] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.589319] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.603417] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.617493] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.619235] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
[ 1776.669307] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.683639] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.697915] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.711962] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.726033] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.740120] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.754225] [drm:intel_dp_start_link_train] *ERROR* too many voltage retries, give up
[ 1776.756172] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting


With kernel 3.13.0, I get only one batch of these messages, but the monitor was working correctly.

My setup is:
Ubuntu trusty 14.04
Intel on board graphic
One monitor via display port, one monitor via analog VGA connector (15pin).

I tried the new kernel to debug another problem and stumbled upon this issue.

I suggest you revert your patch on upcoming linux or make it configurable.

Best regards,
Tobias

Sorry, I confused some things.

The code in 3.13.0 (that worked with one batch of these error messages) is:
                for (clock = 0; clock <= max_clock; clock++) {
                        for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {

The code in 3.15.7 (DP-connected monitor stays black, flooding the error messages) is:
                for (clock = min_clock; clock <= max_clock; clock++) {
                        for (lane_count = min_lane_count; lane_count <= max_lane_count; lane_count <<= 1) {

Both are not identical to your patch.
I recognized that these two loops were swapped a few times in the past.
Therefore I was a little confused.

Nevertheless, the last mentioned kernel version does not work for me.

Best regards,
Tobias

I am seeing something very much like this on a Dell Lattitude E7440 with an old EPort Plus docking station and an external 1920x1200 monitor attached to the first DVI connector.  xrandr output below.  I am running Ubuntu 14.04 with the Ubuntu kernel team 3.15.8-031508-generic build.  Quite often, after boot-up or after the screen saver has run the external monitor is shown by xrandr but remains black, and I see "*ERROR* failed to train DP, aborting" in the dmesg output.  Usually undocking and re-docking the laptop once or twice makes the external display come back on.

I am attaching a dmesg log with drm.debug=0xe when the problem occurred shortly after boot, and a second containing the additional messages shown after I undocked and re-docked the laptop once, restoring the display.

$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 32767 x 32767
eDP1 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 309mm x 173mm
   1920x1080      60.0*+   59.9  
   1680x1050      60.0     59.9  
   1600x1024      60.2  
   1400x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x960       60.0  
   1360x768       59.8     60.0  
   1152x864       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200      59.6*+
   1920x1080      60.2  
   1600x1200      60.1  
   1280x1024      76.0     75.0     60.0  
   1152x921       66.0  
   1152x864       75.0  
   1024x768       75.1     75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     60.0  
   720x400        70.1  
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Created attachment 104151 [details]
dmesg output from boot until the problem occurred

Created attachment 104152 [details]
Additional dmesg output after re-docking

Why is the bugfix within commit 38aecea0 (https://github.com/torvalds/linux/commit/38aecea0ccbb909d635619cba22f1891e589b434) reverted in v3.15.7 (https://github.com/torvalds/linux/commit/c6930992948adf0f8fc1f6ff1da51c5002a2cf95)?

Before v3.15.7 all works fine for me. I can plug the second screen to my DELL e-port-dock and the display works as expected. After switching to > v3.15.7 (i.e. v3.16.0) my problems come back.

When the system resumes from sleep it needs half a minute to switch on the external display. Same is when switching to console with CTRL+ALT+F1.

It seems, that the bug initially fixed with https://bugs.freedesktop.org/attachment.cgi?id=92231 is back again.

... same as Michael Thayer's post

Can someone please reproduce and grab new logs from drm-intel-nightly branch of cgit.freedesktop.org/drm-intel?

Testing with drm-intel-nightly (top of tree is 2ea23cd593ba60ead60e2f796fae675aa4475b1a) on a Dell E7240 (Haswell). Running up to date Debian testing, xserver-xorg-video-intel version 2:2.21.15-2+b2.

Boot undocked, everything fine.
Plug into dock, attached monitor is not detected (tried both DVI ports on the dock and the VGA port, xrandr shows nothing connected).

Boot docked, monitor (attached to DVI port 1) is detected, text KMS console message display on both, once X starts built in laptop screen goes dark. Turns out this is the backlight - if I hit the backlight keyboard keys it shows a normal screen ok.
Unplug from dock, X restarts (back to gdm3 login).
Plug back into dock, dock attached monitor is not detected.

I'm not seeing anything that looks helpful in the dmesg (there's a pipe A underrun error when booting docked) but I'll attach dmesg-no-dock and dmesg-docked. I think it should be clear from when the USB devices change when the laptop is being docked and undocked.

Created attachment 107939 [details]
Booting undocked, then plugging into the dock.

Created attachment 107940 [details]
Booting docked, unplugging from the dock, then plugging back into the dock

I'm also seeing the attached - would adding the debug from i915.mmio_debug be helpful? Eventually I see a whole cascade of the slowpath warnings such that the way to recover seems to be a reboot, but as far as I can tell this only happens when the laptop is docked (external monitor still not working, but it's handy for power + usb devices).

Oct 16 19:53:00 mixian kernel: [  239.611414] [drm:hsw_unclaimed_reg_detect.isra.11] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.
Oct 16 19:53:00 mixian kernel: [  239.611414] ------------[ cut here ]------------
Oct 16 19:53:00 mixian kernel: [  239.611422] WARNING: CPU: 0 PID: 378 at drivers/gpu/drm/i915/intel_runtime_pm.c:675 intel_display_power_put+0x14c/0x160()
Oct 16 19:53:00 mixian kernel: [  239.611495] Modules linked in: ctr ccm binfmt_misc bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc arc4 qmi_wwan cdc_wdm joydev us
bnet mii iwlmvm mac80211 qcserial usb_wwan usbserial uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core hid_multitouch v4l2_common ecb videodev media iwlwifi cfg80211 btusb blu
etooth psmouse serio_raw x86_pkg_temp_thermal intel_powerclamp pcspkr snd_hda_codec_hdmi tpm_tis snd_hda_codec_realtek tpm i2c_i801 snd_hda_codec_generic snd_hda_intel snd_hda_controll
er evdev snd_hda_codec snd_hwdep snd_pcm snd_timer battery processor ac fuse autofs4 algif_skcipher af_alg hid_generic usbhid crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_i
ntel sg ehci_pci sdhci_pci ehci_hcd xhci_hcd usbcore usb_common thermal i2c_hid hid sdhci_acpi sdhci mmc_core
Oct 16 19:53:00 mixian kernel: [  239.611501] CPU: 0 PID: 378 Comm: kworker/0:4 Not tainted 3.17.0+ #6
Oct 16 19:53:00 mixian kernel: [  239.611502] Hardware name: Dell Inc. Latitude E7240/0V120R, BIOS A08 02/18/2014
Oct 16 19:53:00 mixian kernel: [  239.611508] Workqueue: events edp_panel_vdd_work
Oct 16 19:53:00 mixian kernel: [  239.611514]  0000000000000009 ffffffff8166d071 0000000000000000 ffffffff810a8152
Oct 16 19:53:00 mixian kernel: [  239.611518]  ffff8804085a002c ffff8804085a8838 ffff88041ea12780 0000000000000000
Oct 16 19:53:00 mixian kernel: [  239.611521]  ffff8804085a0000 ffffffff81412bfc ffff880409fb2508 ffff88040949ee80
Oct 16 19:53:00 mixian kernel: [  239.611522] Call Trace:
Oct 16 19:53:00 mixian kernel: [  239.611528]  [<ffffffff8166d071>] ? dump_stack+0x41/0x51
Oct 16 19:53:00 mixian kernel: [  239.611533]  [<ffffffff810a8152>] ? warn_slowpath_common+0x72/0x90
Oct 16 19:53:00 mixian kernel: [  239.611536]  [<ffffffff81412bfc>] ? intel_display_power_put+0x14c/0x160
Oct 16 19:53:00 mixian kernel: [  239.611541]  [<ffffffff810be142>] ? process_one_work+0x142/0x3e0
Oct 16 19:53:00 mixian kernel: [  239.611544]  [<ffffffff810be6b3>] ? worker_thread+0x63/0x480
Oct 16 19:53:00 mixian kernel: [  239.611546]  [<ffffffff810be650>] ? rescuer_thread+0x270/0x270
Oct 16 19:53:00 mixian kernel: [  239.611551]  [<ffffffff810c2c0a>] ? kthread+0xca/0xe0
Oct 16 19:53:00 mixian kernel: [  239.611555]  [<ffffffff810c2b40>] ? kthread_create_on_node+0x180/0x180
Oct 16 19:53:00 mixian kernel: [  239.611559]  [<ffffffff816736ec>] ? ret_from_fork+0x7c/0xb0
Oct 16 19:53:00 mixian kernel: [  239.611563]  [<ffffffff810c2b40>] ? kthread_create_on_node+0x180/0x180
Oct 16 19:53:00 mixian kernel: [  239.611565] ---[ end trace d31a378ee49c147f ]---
Oct 16 19:53:00 mixian kernel: [  239.611566] ------------[ cut here ]------------

This unclaimed mmio is helpful, can you please reboot your -nightly giving kernel the i915.mmio_debug=1 paramenter at linux boot cmdline? Than when you reproduce the error the log will show exactly what register we are read/writing that we shouldn't.

[  119.561399] ------------[ cut here ]------------
[  119.561408] WARNING: CPU: 0 PID: 4 at drivers/gpu/drm/i915/intel_uncore.c:525 hsw_unclaimed_reg_debug+0x65/0x80()
[  119.561410] Unclaimed register detected before reading register 0xc7204
[  119.561465] Modules linked in: ctr ccm binfmt_misc bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc arc4 qmi_wwan cdc_wdm usbnet mii joydev snd_hda_codec_realtek qcserial snd_hda_codec_generic usb_wwan usbserial iwlmvm mac80211 snd_hda_codec_hdmi ecb x86_pkg_temp_thermal intel_powerclamp iwlwifi pcspkr psmouse btusb serio_raw bluetooth i2c_i801 hid_multitouch snd_hda_intel snd_hda_controller snd_hda_codec cfg80211 snd_hwdep snd_pcm snd_timer tpm_tis tpm evdev processor battery ac fuse autofs4 algif_skcipher af_alg hid_generic usbhid crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel sg sdhci_pci ehci_pci ehci_hcd xhci_hcd usbcore usb_common thermal sdhci_acpi sdhci i2c_hid mmc_core hid
[  119.561469] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.17.0+ #6
[  119.561470] Hardware name: Dell Inc. Latitude E7240/0V120R, BIOS A08 02/18/2014
[  119.561475] Workqueue: events edp_panel_vdd_work
[  119.561479]  0000000000000009 ffffffff8166d071 ffff88040a19fd28 ffffffff810a8152
[  119.561482]  ffff880408580000 ffff88040a19fd78 ffff88041ea12780 ffff880408580068
[  119.561485]  0000000000000246 ffffffff810a81b7 ffffffff819be048 ffffffff00000030
[  119.561486] Call Trace:
[  119.561493]  [<ffffffff8166d071>] ? dump_stack+0x41/0x51
[  119.561498]  [<ffffffff810a8152>] ? warn_slowpath_common+0x72/0x90
[  119.561501]  [<ffffffff810a81b7>] ? warn_slowpath_fmt+0x47/0x50
[  119.561507]  [<ffffffff81187c1d>] ? next_online_pgdat+0x1d/0x50
[  119.561510]  [<ffffffff81447115>] ? hsw_unclaimed_reg_debug+0x65/0x80
[  119.561513]  [<ffffffff814498ce>] ? gen6_read32+0x4e/0x130
[  119.561516]  [<ffffffff81449880>] ? gen6_read8+0x130/0x130
[  119.561519]  [<ffffffff8147a224>] ? edp_have_panel_vdd+0x34/0x40
[  119.561522]  [<ffffffff8147abed>] ? edp_panel_vdd_off_sync+0x2d/0x1b0
[  119.561525]  [<ffffffff8147ad95>] ? edp_panel_vdd_work+0x25/0x30
[  119.561529]  [<ffffffff810be142>] ? process_one_work+0x142/0x3e0
[  119.561532]  [<ffffffff810be6b3>] ? worker_thread+0x63/0x480
[  119.561535]  [<ffffffff810be650>] ? rescuer_thread+0x270/0x270
[  119.561540]  [<ffffffff810c2c0a>] ? kthread+0xca/0xe0
[  119.561544]  [<ffffffff810c2b40>] ? kthread_create_on_node+0x180/0x180
[  119.561549]  [<ffffffff816736ec>] ? ret_from_fork+0x7c/0xb0
[  119.561553]  [<ffffffff810c2b40>] ? kthread_create_on_node+0x180/0x180
[  119.561555] ---[ end trace d3b671e0e63801ff ]---
[  119.561561] ------------[ cut here ]------------

Created attachment 108948 [details]
Booting docked, no unplugging, drm-intel-nightly 2014-11-05

dmesg of kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-11-05-vivid/
hardware: e7440 with Dell Advanced E/Port-Replikator II (452-11415)

Hi,
I'm using Ubuntu 14.04 with kernel 3.15.6 without any problems.
My hardware: e7440 with Dell Advanced E/Port-Replikator II (452-11415).
The 1080i monitor ist attached to DP port1. 

I've tried to boot with a drm-intel-nightly kernel from today.
Boot docked and notebook display closed.
The KMS console appear, X didn't start.

Ok, usually DP training bugs all look the same but arent' the same bug actually. Which means with the pile of people here there's no way we can have a chance at this since everyone will have slightly different results when testing.

So please everyone file new bug reports if you're still experiencing issues, I'll close this one here as too much chaos. Unfortunately bugzilla has no sane way to split bugs, so balancing too much towards duplicated bug reports is the way to go.

Thanks, Daniel

G

Hello Daniel,

Still seeing this with Linux 4.0.0rc2 (don't ask, I updated to that a bit ago to test something else and never bothered updating further as everything was working).  I could create a new report as you suggested, but before I bother you with that, how likely is it that it is actually a hardware problem?

Thanks, Michael