Created attachment 126335 [details] dmesg with drm.debug=0xe Steps to reproduce: 1. Boot machine (Haswell, also saw on Skylake) with MST monitor (Dell UP2414Q, DP1.2 enabled) attached. It boots fine. 2. Disable the monitor with button on front. 3. Re-enable the monitor. Nothing appears on the screen. It goes to sleep. 4. Switch to linux console (C-A-F1) and back. It brings the monitor back alive. 5. Switch to linux console again. Kernel crashes.
Created attachment 126336 [details] xrandr
ping?
Also hitting this with kernel 4.8.0-0.rc8.git0.1.fc25.x86_64 on Haswell. Happens just by exiting an X session, i.e. the X server exiting.
Created attachment 127006 [details] Different logs
Hello all, I was trying with different Kernels from: http://kernel.ubuntu.com/~kernel-ppa/mainline/ Including 4.7, 4.8.0 and 4.8rc8 The problem with 4.7 and beyond, before 4.8 seems to be CPU pipe A FIFO underrun For 4.8 and beyond, the error is a little bit more specific. Blaming the dp_link_training_clock. Hardware: Intel Nuc 6i5SYH In some cases i need an extra monitor because 4k monitor didn't come back from sleep I tried with different software configuration as well facing same behavior. Software configuration: Component : drm url : http://cgit.freedesktop.org/mesa/drm tag : libdrm-2.4.68 commit : fc09c5ab84240e9b6bd0bed01685ef004f56c4fa author : Kenneth Graunke <kenneth@whitecape.org> age : 4 months ago Component : mesa url : http://cgit.freedesktop.org/mesa/mesa tag : mesa-12.0.1 commit : 04277f058d00238937e664cf546c43b16cea7b2b author : Emil Velikov <emil.velikov@collabora.com> age : 8 weeks ago Component : xf86-video-intel url : http://cgit.freedesktop.org/xorg/driver/xf86-video-intel tag : 2.99.917-701-g205146b commit : 205146b0fdc8db016e5cfeeae5a6b25df3470ebc author : Chris Wilson <chris@chris-wilson.co.uk> Component : libva url : http://cgit.freedesktop.org/libva tag : libva-1.7.2.pre1 commit : 9927bd2fbbb1d923fd6a8932a3cdbb5c9185ee22 author : Xiang Haihao <haihao.xiang@intel.com> Component : intel-driver url : http://cgit.freedesktop.org/vaapi/intel-driver tag : 1.7.2.pre1 commit : ce444fb412966ca6afbb1331b7cae8ab621c1108 author : Xiang Haihao <haihao.xiang@intel.com> Component : cairo url : http://cgit.freedesktop.org/cairo tag : 1.15.2 commit : db8a7f1697c49ae4942d2aa49eed52dd73dd9c7a author : Bryce Harrington <bryce@osg.samsung.com> Component : xserver url : http://cgit.freedesktop.org/xorg/xserver tag : xorg-server-1.18.3 commit : 9454cd51da9b38b974cff7c8b7125901f6403848 author : Adam Jackson <ajax@redhat.com> Component : macros url : https://cgit.freedesktop.org/xorg/util/macros tag : util-macros-1.19.0-2-gd7acec2 commit : d7acec2 author : Andreas Boll <andreas.boll.dev@gmail.com> age : 8 months ago Component : intel-gpu-tools url : https://cgit.freedesktop.org/xorg/app/intel-gpu-tools tag : intel-gpu-tools-1.16 commit : a28e9e38a9efc6daf5a08d60d29adcd3e328fe6f author : Marius Vlad <marius.c.vlad@intel.com>
Created attachment 127029 [details] dp mst null pointer deref on broadwell Reproduced on Broadwell with daisy chained DP MST setup. Reproduced by simply switching off and back on the first display in the chain. Attached dmesg starts from hitting the power button to re-enable display. Today's drm-intel-nightly.
From looking at the dmesg Jani posted, it seems like the NULL pointer dereference is with the topology discovery / management code in the DRM driver. It's definitely the sideband worker thread that had the crash, if the stack trace is to be trusted. In Krill's case the crash happens in the frame buffer helpers, but ultimately it's likely the same condition that caused the problem. Powering down the primary monitor likely also means powering down the primary DP MST branch device in the case of powering down the first monitor in a series of daisy-chained monitors. I wouldn't necessarily expect any of the downstream monitors to work right in that case, and honestly we probably ought to be able to catch and deal with this case like an unplug event. Our drivers should handle that case gracefully, however.
I am trying to get my daisy chain DP MST setup up and running but somehow the second monitor is not turning on, I am using the Dell Monitor which has the support for MST embedded within the monitor itself (not using the hub). Will sync w/ Jim tomorrow on this. Jim also suggested to manually unplugging the power when connected to the DP MST hub and with that it reproduces a CPU pipe A FIFO underrun (it seems to be a different problem than the null pointer because the kernel didn't crash, only errored out).
Fails the same way with a DP MST capable monitor also *without* the secondary display.
I was able to get the daisy chain Monitor setup up and running using both the Dell Monitor with built-in support for MST and the HUB and still I am not able to see the null pointer. I am only able to see the CPU pipe A FIFO underrun as reported by Elio above, but that's a separate issue than the null pointer being reported. I was trying things on SKY, will try on HSW and BDW tomorrow.
unfortunately the steps to repro from comment #1 are not working for me, so it's making progress on this bug rather slow. I was able to see the null pointer only one time, however the stack trace although similar it wasn't exactly the same (see attachment). Specifically, step #4, where I am supposed to get the screen back is not happening for me, it stays black the entire time with no crash. Step #5 above, where another mode setting occurs I am able to get the screen back but no crash either. (I am on skylake + nightly). I have been trying the above steps consistently 10+ times. Looking at the stack trace and the problem appears to be starting when drm_probe_ddc() gets called from drm_get_edid() inside drm_edid.c. The adapter as a parameter is being passed but never check for null, specifically the call to drm_do_probe_ddc_edid() derefences some of the fields of adapter struct when the call to i2c_transfer() gets called, most likely causing the crash. I am attaching a debug patch as reference.
Created attachment 127155 [details] stack trace
Created attachment 127156 [details] [review] debug patch null pointer
Finally, I am able to consistently repro this problem on HWS/BDW by disabling RC6 power states (i915.enable_rc6=0) at least since the drm-nightly from Oct 1 (http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2016-10-01/ The tip of the drm-nightly at least since Oct 7 doesn't repro the null pointer exception. The display stays black but forcing a mode setting change switching from text mode (CTRL+ ALT + F1) to gfx mode (C+A+F7) "fixes" the black screen and the UI screen is able to come back. Next steps: 1. Ask Tomi or someone else to see if they no longer are able to repro the null pointer on the latest drm-nightly. 1. Continue bisecting the tree to see when the null pointer disappear as it seems in the latest nightly I am not able to see the nullpointer anymore.
Tried today's nightly, works fine. This might be something we could use a reverse bisect for, to backport the fix. Kiryl, can you try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel to see if you can reproduce with that?
Nope. The same.
Created attachment 127227 [details] dmesg for drm-intel-nightly, de34f4da7f62
Oops. I've compiled the wrong kernel tree. It's Linus' current master.
Okay, I don't see the NULL pointer dereference. But, step 4 doesn't bring the monitor back alive anymore. Still no luck :(
Created attachment 127228 [details] dmesg for drm-intel-nightly, 41409515b7b3 Few attempts of monitor power-cycle, console-and-back, Xorg restart.
(In reply to Kirill A. Shutemov from comment #19) > Okay, I don't see the NULL pointer dereference. > > But, step 4 doesn't bring the monitor back alive anymore. Still no luck :( If you force a modeset switching from console back to graphics you can get the monitor back (CTRL+ALT+F1 -> CTRL+ALT+F7)
I tried exactly that. It produces a lot of messages in dmesg, but monitor still says "no signal".
Using the pre-builts drm-nightly kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/ it looks like the fix for the null pointer entered sometime between Oct 5 and Oct 6. I'll continue the bisection tomorrow. Bad commit - cod/tip/drm-intel-nightly/2016-10-05 (2e47fbed60d05480cfbd097c1912e6823c0310ee) Goog commmit - cod/tip/drm-intel-nightly/2016-10-06 (2dff18acaa95a26b882a5f9910d7ded514f18415) The delta between those two nightly builds: csanta@graypixels:~/temp2/cod/tip/drm-intel-nightly/2016-10-05$ git log --pretty=oneline cod/tip/drm-intel-nightly/2016-10-06..cod/tip/drm-intel-nightly/2016-10-04 35ceb7ced7dc45fe6db94e36e3d36089557994f4 drm-intel-nightly: 2016y-10m-03d-20h-05m-29s UTC integration manifest c649d02d17ff44a674531e59f62d789f020ab3df Merge remote-tracking branch 'origin/topic/core-for-CI' into drm-intel-nightly 8978146d3e9d0f82c375772e0afd437a7e14c40a Merge remote-tracking branch 'origin/topic/drm-misc' into drm-intel-nightly e274358357f992003d3602c7bffccba5e65efbb6 Merge remote-tracking branch 'sound-upstream/for-next' into drm-intel-nightly 135b00745346d3b9b61c5fcde114c982a78a1401 Merge remote-tracking branch 'drm-upstream/drm-next' into drm-intel-nightly 50d07cc835486b055c320884e4c72e3d6e8b324c Merge remote-tracking branch 'origin/drm-intel-next-queued' into drm-intel-nightly 262f75a6288346db44038c63b7a95ee68f8b7bea drm: Undo damage to page_flip_ioctl 0c238e65d7dc62c5cae138cec720fec7baa07a24 drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it a4cb6284e28b90761145f3ffa454a515ac4644ba drm/bridge: analogix_dp: Add analogix_dp_psr_supported 6c4d6f9f997c5dafccb54b52167f0c4d0ea37874 drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops e80559f71b0c35a099532c583e251f4faf572c95 drm: Document caveats around atomic event handling 5bc0fc9a545641b19bdfa32911fd755b41b428ab drm/i915: Fix build when !CONFIG_DEBUG_FS 26e19227e2d405af48ef53d421a3c5bc4b499a3d uapi: add missing install of sync_file.h 844f9ee731472c7c8ce99851e7eafc98b8190293 drm: Simplify drm_printk to reduce object size quite a bit 5a86d6fbff2e403ab9eb86d0997ee0f2435258bc drm/i915: Account for sink max TMDS clock when checking the port clock 3be453e6cddf6eeca1cf69cdff750a31be011702 drm/i915: Replace a bunch of connector->base.display_info with a local variable 462de098327ebcd63a09cbdf22df36efc1266bf9 drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld() 52655e01952a944fb889be7e56781572507148ad drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID dc4b7a0aa6d523acd8331f9590ab42d5348cc307 drm/edid: Reduce the number of times we parse the CEA extension block b5ec14f5eb6193a46e0d7854da70123504c4ab36 drm/edid: Don't pass around drm_display_info needlessly 21da17eaa02bdf727a1e3141bdd603f2f79df407 drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info 84aa822007328e00386bde83760499ab146157fc drm/edid: Make max_tmds_clock kHz instead of MHz 66f2d60f872f242c578263324e848479f6b7b786 drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID 1be05eabb2ae5af798f09300fc13ed008ff13c8a drm/edid: Clear old audio latency values before parsing the new EDID da2bf7e805921494df5ebe18e99c790b1fbb450c drm: Convert prime dma-buf <-> handle to rbtree 0482bae6012924aa01b06e33431a57b9e971888c drm: Restore lost drm_framebuffer_unreference in drm_mode_page_flip_ioctl 24454c2c4b4bfac5ea8b1d2ec6a61ea20abea6ab drm: Add frame CRC debugfs files only for drivers that have CRTC ea568478ad07e6dcf90fc02265760f703b50fb3d drm/i915: Put "cooked" vlank counters in frame CRC lines 13fa0253d97a781bd52e836439827916a21ff2af drm/i915: Use new CRC debugfs API 48c787899882ec9c3e111a81801c82d10da17810 drm: Add API for capturing frame CRCs 21165bd933acd4b9d5bb81cc15cfa1fc1258ddc5 drm/i915/debugfs: Move out pipe CRC code 849fccd258ec702381328c0a52442d268ff96082 Merge remote-tracking branch 'airlied/drm-next' into topic/drm-misc bd233af436baccc9c600902b1726bcd0b6ada63d drm/sti: mark symbols static where possible 490896bc2382b0ed77b78d6242103706b4d06fe4 drm/mediatek: mark symbols static where possible 492ec801668a48db7751a8cf591a19c5f79ca57a drm/rockchip: mark symbols static where possible 4e6ee0192b2d66083b56a3e0b863d556e642ffa7 drm/rockchip: add missing header dependencies
To make the bisect more simpler I moved the bisection to the drm-intel tree instead of the Ubuntu one. Using the following two commits as starting point for the bisect: Bad commit: a4fce9cb782ad340ee5576a38e934e5e75832dc6 Good commit: 14740bb25ec36fe4ce8042af3eb48aeb45e5bc13 the commit that introduced the null pointer seems to be this one: 27d4efc5591a5853de54713bc717de73c8951e17 is the first bad commit commit 27d4efc5591a5853de54713bc717de73c8951e17 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Oct 3 10:55:15 2016 +0300 drm/i915: Move long hpd handling into the hotplug work We can't rely on connector->status in the detect() hook if the long hpd was already handled by the dig_port_work as that won't update connector->status. Thus we have to defer the long hpd handling entirely until the hotplug work runs to avoid the double long hpd handling the "detect_done" flag is trying to prevent. We'll start to depend on connector->status being up to date in a following patch. Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: Arno <blouin.arno@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> which makes sense since there are changes related to display port. I'll continue tomorrow looking into the changes.
Minor correction, the above commit from the bisect is the actual fix to the null pointer/black screen issue. commit 27d4efc5591a5853de54713bc717de73c8951e17 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Oct 3 10:55:15 2016 +0300 drm/i915: Move long hpd handling into the hotplug work @Kirill/Jani can you please verify this at your end? Reverting this commit from today's nightly as well as the before/after of Oct 3 by git hard --reset 27d4efc5591a I obtain the same result.
[The commit is v4.9-rc1 as 1015811609c0.] Yes, I don't see the NULL pointer dereference anymore with the commit. But exactly the same commit also breaks the workaround I use to wake up the screen (switch-to-console-and-back). I don't have anymore a mean to make display work again after it went to sleep. :( May be that's a different bug, I don't know.
(In reply to Kirill A. Shutemov from comment #26) > [The commit is v4.9-rc1 as 1015811609c0.] > > Yes, I don't see the NULL pointer dereference anymore with the commit. > > But exactly the same commit also breaks the workaround I use to wake up the > screen (switch-to-console-and-back). I don't have anymore a mean to make > display work again after it went to sleep. :( > > May be that's a different bug, I don't know. Can you grab some dmegs logs w/ drm.debug=0xe from that case?
@Vylle, Kirill, The null pointer was indirectly fix with the above commit (27d4efc5591a5853de54713bc717de73c8951e17). Can we close this bug and open a new with the new problem you're referring to? Otherwise, this bugzilla will become too polluted. Carlos
Okay, I'll open new bug.
Reopening since the "fix" was just due to another regression, and once that's fixed the oops back.
I pushed a few potential patches to git://github.com/vsyrjala/linux.git dp_mst_fixes Totally untested as of now.
Hi Ville, I tested the following 3 patches on today's drm-nightly: 1. drm/i915: Refresh that status of MST capable connectors in ->detect() 2. drm/fb-helper: Fix connector ref leak on error 3. drm/fb-helper: Keep references for the current set of used connectors You're right, after applying #1, the null pointer issue comes back but after applying #2, and doing the display power on/off to repro the bug, the system freezes and never comes back again. Same behavior if then applying patch #3 on top, which is supposed to be the fix. Carlos
(In reply to Carlos Santa from comment #32) > Hi Ville, > > I tested the following 3 patches on today's drm-nightly: > > 1. drm/i915: Refresh that status of MST capable connectors in ->detect() > 2. drm/fb-helper: Fix connector ref leak on error > 3. drm/fb-helper: Keep references for the current set of used connectors > > You're right, after applying #1, the null pointer issue comes back but after > applying #2, and doing the display power on/off to repro the bug, the system > freezes and never comes back again. Same behavior if then applying patch #3 > on top, which is supposed to be the fix. Freezes hard enough to not leave a trace in netconsole/serial etc. ? Logs would be nice.
(In reply to Ville Syrjala from comment #33) > (In reply to Carlos Santa from comment #32) > > Hi Ville, > > > > I tested the following 3 patches on today's drm-nightly: > > > > 1. drm/i915: Refresh that status of MST capable connectors in ->detect() > > 2. drm/fb-helper: Fix connector ref leak on error > > 3. drm/fb-helper: Keep references for the current set of used connectors > > > > You're right, after applying #1, the null pointer issue comes back but after > > applying #2, and doing the display power on/off to repro the bug, the system > > freezes and never comes back again. Same behavior if then applying patch #3 > > on top, which is supposed to be the fix. > > Freezes hard enough to not leave a trace in netconsole/serial etc. ? Logs > would be nice. Ok, I got the log using dmesg -w. It's actually oopsing the same way as before, see the attachment 10 [details]-21-2016. More on the traces, the "adapter" parameter being passed to i2c_transfer() from drm_do_probe_ddc_edid() although is not NULL it appears to arrive with invalid data, the pointer that gets de-referenced is this one "adapter->algo->master_xfer". Adding more traces I was able to track the sequence to: i2c_transfer() drm_do_probe_ddc_edid() drm_get_edid() port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr, port, proppath); drm_dp_add_port(port->connector, &port->aux.ddc) drm_dp_send_link_address() The port->connector is what gets passed to drm_get_edid() as a reference, I am guessing that this "port" somehow is becoming invalid from within intel_dp_add_mst_connector().
Created attachment 127461 [details] 10-21-2016.dmesg stack trace
*** Bug 98408 has been marked as a duplicate of this bug. ***
(In reply to Carlos Santa from comment #35) > Created attachment 127461 [details] > 10-21-2016.dmesg stack trace Pushed another little thing to dp_mst_fixes 3852841d51ba ("drm/dp/mst: Clear port->pdt when tearing down the i2c adapter") I don't particularly like how that code is structured, so can't say with any certainty that this would help, but let's try anyway.
(In reply to Ville Syrjala from comment #37) > (In reply to Carlos Santa from comment #35) > > Created attachment 127461 [details] > > 10-21-2016.dmesg stack trace > > Pushed another little thing to dp_mst_fixes > 3852841d51ba ("drm/dp/mst: Clear port->pdt when tearing down the i2c > adapter") > > I don't particularly like how that code is structured, so can't say with any > certainty that this would help, but let's try anyway. With this last patch, it still fails the same way as before, no changes to the values inside the struct that defines the port->connector, it seems it's corrupted as it's no NULL but not valid at the same time. In my debugging I added one simple check here, @@ -1162,7 +1164,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch *mstb, drm_dp_put_port(port); goto out; } - if (port->port_num >= DP_MST_LOGICAL_PORT_0) { + printk("************* Carlos %s %d port_num: %d port_status: %d\n",__FUNCTION__,__LINE__,port->port_num, port->conne + if (port->port_num >= DP_MST_LOGICAL_PORT_0 && port->connector->status != connector_status_unknown) { port->cached_edid = drm_get_edid(port->connector, &port->aux.ddc); drm_mode_connector_set_tile_property(port->connector); } where I skip calling drm_get_edid() if the status of the port becomes "unknown",and with that the crash is avoided ( I still have to force the modeset with CRTL+F1, CRTL+F7). This shows that the struct port->connector is certainly not NULL yet it seems to arrive to this point with invalid data, perhaps corrupted? Another observation, one has to press the On/Off button for this to become a problem, if I leave the system to suspend and then wake up the monitor with the mouse, then I don't see the crash, so maybe it's a cleanup problem during the off button sequence???
Pushed another kludge: 1547e21b7ebf ("drm/dp/mst: Check peer device type before attempting EDID read") Let's see if that helps at all.
Yeah, that does help avoid the crash, the port->pdt comes as 0x0 which is equal to DP_PEER_DEVICE_NONE. The screen is still black after pushing the ON button but to get the display back I force a modeset with CTRL+F1 and CTRL+7.
The same for me: it survived few power cycles. And it still requires console-and-back to get screen on. Is it a separate bug?
(In reply to Kirill A. Shutemov from comment #41) > The same for me: it survived few power cycles. And it still requires > console-and-back to get screen on. Is it a separate bug? I haven't really thought it through, but I think what might be happening is that the fbdev hotplug processing never happens in this case. Presumably we should actually do it at the restore_fbdev time since the hotplug happened while fbdev was not in charge of things and so couldn't respond to the hotplug at the time when it actually happened. I guess we could call it a new bug, just so the bug report won't be full of oops reports. But I think we may want to hold off opening a new bug until/if these current patches are accepted. I'll go send them out now.
Marking this as Resolved, as this patch fixes the crash with the null pointer 1547e21b7ebf ("drm/dp/mst: Check peer device type before attempting EDID read") Ville has submitted it to the mailing list and it's currently under review.
(In reply to Carlos Santa from comment #43) > Marking this as Resolved, as this patch fixes the crash with the null pointer > > 1547e21b7ebf ("drm/dp/mst: Check peer device type before attempting EDID > read") > > Ville has submitted it to the mailing list and it's currently under review. Please do not close bugs before the patches have landed in drm-intel repo.
commit 4da5caa6a6f82cda3193bca855235b87debf78bd Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Oct 26 12:05:55 2016 +0300 drm/dp/mst: Check peer device type before attempting EDID read
(In reply to Jani Nikula from comment #45) > commit 4da5caa6a6f82cda3193bca855235b87debf78bd > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > Date: Wed Oct 26 12:05:55 2016 +0300 > > drm/dp/mst: Check peer device type before attempting EDID read closing as fixed
It looks like got broken on the way upstream. Or some other bug was introduced in the same batch of patches. dp_mst_fixes_4 from Ville's repo works fine, but upstream 4da5caa6a6f8 doesn't.
@Kirill, can you be more specific about the issue that you're seeing that caused to reopen this bug? On yesterday's drm-nightly I am not able to see the NULL pointer crash after pressing the On/Off button in the MST setup I have. This was easily reproduced before. Are you still seeing the NULL pointer or something else?
(In reply to Kirill A. Shutemov from comment #47) > It looks like got broken on the way upstream. Or some other bug was > introduced in the same batch of patches. > > dp_mst_fixes_4 from Ville's repo works fine, but upstream 4da5caa6a6f8 > doesn't. Still oops or just fail to light up the display? https://patchwork.freedesktop.org/patch/117191/ hasn't made its way into Linus's tree yet. Which can explain things not lighting up.
Nothing lighting up. I'll check the patch.
Yes, the patch helps.
fc22b787890f ("drm/i915: Refresh that status of MST capable connectors in ->detect()") is included in Dave's pull request to Linus today: http://lkml.kernel.org/r/CAPM=9tw1YEq-FGCc7Wm=BBQc0jShEECM6_uVQwZ-BpOAsOGB=A@mail.gmail.com
Linus' tree is fine now.
Thanks for the follow-up, and your patience, Kirill!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.