From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon Date: Mon, 25 Jan 2016 21:32:43 +0100 Message-ID: <20160125203243.GW11240@phenom.ffwll.local> References: <56A19C98.8020208@daenzer.net> <20160122151835.GM23290@intel.com> <56A5A171.7000205@daenzer.net> <56A6203D.3030803@gmail.com> <20160125132310.GS23290@intel.com> <56A626D5.2040808@gmail.com> <20160125145309.GT23290@intel.com> <56A64F86.9080605@gmail.com> <20160125185122.GV11240@phenom.ffwll.local> <56A677C6.4050909@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by gabe.freedesktop.org (Postfix) with ESMTPS id DDF7B6E159 for ; Mon, 25 Jan 2016 12:32:36 -0800 (PST) Received: by mail-wm0-f45.google.com with SMTP id b14so99324060wmb.1 for ; Mon, 25 Jan 2016 12:32:36 -0800 (PST) Content-Disposition: inline In-Reply-To: <56A677C6.4050909@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Mario Kleiner Cc: Michel =?iso-8859-1?Q?D=E4nzer?= , LKML , dri-devel@lists.freedesktop.org, Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Vlastimil Babka List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBKYW4gMjUsIDIwMTYgYXQgMDg6MzA6MTRQTSArMDEwMCwgTWFyaW8gS2xlaW5lciB3 cm90ZToKPiAKPiAKPiBPbiAwMS8yNS8yMDE2IDA3OjUxIFBNLCBEYW5pZWwgVmV0dGVyIHdyb3Rl Ogo+ID5PbiBNb24sIEphbiAyNSwgMjAxNiBhdCAwNTozODozMFBNICswMTAwLCBNYXJpbyBLbGVp bmVyIHdyb3RlOgo+ID4+UmVhZGRpbmcgRGFuaWVsLCB3aGljaCBzb21laG93IGdvdCBkcm9wcGVk IGZyb20gdGhlIGNjLgo+ID4+Cj4gPj5PbiAwMS8yNS8yMDE2IDAzOjUzIFBNLCBWaWxsZSBTeXJq w6Rsw6Qgd3JvdGU6Cj4gPj4+T24gTW9uLCBKYW4gMjUsIDIwMTYgYXQgMDI6NDQ6NTNQTSArMDEw MCwgTWFyaW8gS2xlaW5lciB3cm90ZToKPiA+Pj4+Cj4gPj4+Pgo+ID4+Pj5PbiAwMS8yNS8yMDE2 IDAyOjIzIFBNLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPj4+Pj5PbiBNb24sIEphbiAyNSwg MjAxNiBhdCAwMjoxNjo0NVBNICswMTAwLCBNYXJpbyBLbGVpbmVyIHdyb3RlOgo+ID4+Pj4+Pgo+ ID4+Pj4+Pgo+ID4+Pj4+Pk9uIDAxLzI1LzIwMTYgMDU6MTUgQU0sIE1pY2hlbCBEw6RuemVyIHdy b3RlOgo+ID4+Pj4+Pj5PbiAyMy4wMS4yMDE2IDAwOjE4LCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6 Cj4gPj4+Pj4+Pj5PbiBGcmksIEphbiAyMiwgMjAxNiBhdCAxMjowNjowMFBNICswOTAwLCBNaWNo ZWwgRMOkbnplciB3cm90ZToKPiA+Pj4+Pj4+Pj4KPiA+Pj4+Pj4+Pj5bIFRyaW1taW5nIEtERSBm b2xrcyBmcm9tIENjIF0KPiA+Pj4+Pj4+Pj4KPiA+Pj4+Pj4+Pj5PbiAyMS4wMS4yMDE2IDE5OjA5 LCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4+Pj4+Pj4+Pj5PbiBUaHUsIEphbiAyMSwgMjAxNiBh dCAwNTozNjo0NlBNICswOTAwLCBNaWNoZWwgRMOkbnplciB3cm90ZToKPiA+Pj4+Pj4+Pj4+Pk9u IDIxLjAxLjIwMTYgMTY6NTgsIERhbmllbCBWZXR0ZXIgd3JvdGU6Cj4gPj4+Pj4+Pj4+Pj4+Cj4g Pj4+Pj4+Pj4+Pj4+Q2FuIHlvdSBwbGVhc2UgcG9pbnQgbWUgYXQgdGhlIHZibGFuayBvbi9vZmYg anVtcCBidWcgcGxlYXNlPwo+ID4+Pj4+Pj4+Pj4+Cj4gPj4+Pj4+Pj4+Pj5BRkFJUiBJIG9yaWdp bmFsbHkgcmVwb3J0ZWQgaXQgaW4gcmVzcG9uc2UgdG8KPiA+Pj4+Pj4+Pj4+Pmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvYXJjaGl2ZXMvZHJpLWRldmVsLzIwMTUtQXVndXN0LzA4Nzg0MS5o dG1sCj4gPj4+Pj4+Pj4+Pj4sIGJ1dCBJIGNhbid0IGZpbmQgdGhhdCBpbiB0aGUgYXJjaGl2ZXMs IHNvIG1heWJlIHRoYXQgd2FzIGp1c3Qgb24gSVJDLgo+ID4+Pj4+Pj4+Pj4+U2VlCj4gPj4+Pj4+ Pj4+Pj5odHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL2FyY2hpdmVzL2RyaS1kZXZlbC8yMDE2 LUphbnVhcnkvMDk5MTIyLmh0bWwKPiA+Pj4+Pj4+Pj4+Pi4gQmFzaWNhbGx5LCBJIHJhbiBpbnRv IHRoZSBidWcgZml4ZWQgYnkgeW91ciBwYXRjaCBiZWNhdXNlIHRoZSBjb3VudGVyCj4gPj4+Pj4+ Pj4+Pj5qdW1wZWQgZm9yd2FyZCBvbiBldmVyeSBEUE1TIG9mZiwgc28gaXQgaGl0IHRoZSAzMi1i aXQgYm91bmRhcnkgYWZ0ZXIKPiA+Pj4+Pj4+Pj4+Pmp1c3QgYSBmZXcgZGF5cy4KPiA+Pj4+Pj4+ Pj4+Cj4gPj4+Pj4+Pj4+Pk9rLCBzbyBqdXN0IHVuY292ZXJlZCB0aGUgb3ZlcmZsb3cgYnVnLgo+ ID4+Pj4+Pj4+Pgo+ID4+Pj4+Pj4+Pk5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgImp1c3QiLCBi dXQgdG8gYmUgY2xlYXI6IFRoZSBkcm1fdmJsYW5rX29uL29mZgo+ID4+Pj4+Pj4+PmNvdW50ZXIg anVtcGluZyBidWcgKHNpbWlsYXIgdG8gdGhlIGJ1ZyB0aGlzIHRocmVhZCBpcyBhYm91dCksIHdo aWNoCj4gPj4+Pj4+Pj4+ZXhwb3NlZCB0aGUgb3ZlcmZsb3cgYnVnLCBpcyBzdGlsbCBhbGl2ZSBh bmQga2lja2luZyBpbiA0LjUuIEl0IHNlZW1zCj4gPj4+Pj4+Pj4+dG8gaGFwcGVuIHdoZW4gdHVy bmluZyBvZmYgdGhlIENSVEM6Cj4gPj4+Pj4+Pj4+Cj4gPj4+Pj4+Pj4+W2RybTpkcm1fdXBkYXRl X3ZibGFua19jb3VudF0gdXBkYXRpbmcgdmJsYW5rIGNvdW50IG9uIGNydGMgMDogY3VycmVudD0y MTgxMDQ2OTQsIGRpZmY9MCwgaHc9OTE2IGh3X2xhc3Q9OTE2Cj4gPj4+Pj4+Pj4+W2RybTpyYWRl b25fZ2V0X3ZibGFua19jb3VudGVyX2ttc10gY3J0YyAwOiBkaXN0IGZyb20gdmJsYW5rIHN0YXJ0 IDMKPiA+Pj4+Pj4+Pj5bZHJtOmRybV9jYWxjX3ZibHRpbWVzdGFtcF9mcm9tX3NjYW5vdXRwb3Nd IGNydGMgMCA6IHYgMHg3IHAoMjE5OSwtNDUpQCA3MzA0LjMwNzM1NCAtPiA3MzA0LjMwODAwNiBb ZSAwIHVzLCAwIHJlcF0KPiA+Pj4+Pj4+Pj5bZHJtOnJhZGVvbl9nZXRfdmJsYW5rX2NvdW50ZXJf a21zXSBjcnRjIDA6IGRpc3QgZnJvbSB2Ymxhbmsgc3RhcnQgMwo+ID4+Pj4+Pj4+Pltkcm06ZHJt X3VwZGF0ZV92YmxhbmtfY291bnRdIHVwZGF0aW5nIHZibGFuayBjb3VudCBvbiBjcnRjIDA6IGN1 cnJlbnQ9MjE4MTA0Njk0LCBkaWZmPTE2Nzc2MzAxLCBodz0xIGh3X2xhc3Q9OTE2Cj4gPj4+Pj4+ Pj4KPiA+Pj4+Pj4+Pk5vdCBzdXJlIHdoYXQgYnVnIHdlJ3JlIHRhbGtpbmcgYWJvdXQgaGVyZSwg YnV0IGhlcmUgdGhlIGh3IGNvdW50ZXIKPiA+Pj4+Pj4+PmNsZWFybHkganVtcHMgYmFja3dhcmRz Lgo+ID4+Pj4+Pj4+Cj4gPj4+Pj4+Pj4+W2RybTpyYWRlb25fZ2V0X3ZibGFua19jb3VudGVyX2tt c10gUXVlcnkgZmFpbGVkISBzdGF0IDMKPiA+Pj4+Pj4+Pj5bZHJtOnJhZGVvbl9nZXRfdmJsYW5r X2NvdW50ZXJfa21zXSBRdWVyeSBmYWlsZWQhIHN0YXQgMwo+ID4+Pj4+Pj4+Pltkcm06ZHJtX3Vw ZGF0ZV92YmxhbmtfY291bnRdIHVwZGF0aW5nIHZibGFuayBjb3VudCBvbiBjcnRjIDE6IGN1cnJl bnQ9MCwgZGlmZj0wLCBodz0wIGh3X2xhc3Q9MAo+ID4+Pj4+Pj4+Pltkcm06cmFkZW9uX2dldF92 YmxhbmtfY291bnRlcl9rbXNdIFF1ZXJ5IGZhaWxlZCEgc3RhdCAzCj4gPj4+Pj4+Pj4+W2RybTpy YWRlb25fZ2V0X3ZibGFua19jb3VudGVyX2ttc10gUXVlcnkgZmFpbGVkISBzdGF0IDMKPiA+Pj4+ Pj4+Pj5bZHJtOmRybV91cGRhdGVfdmJsYW5rX2NvdW50XSB1cGRhdGluZyB2YmxhbmsgY291bnQg b24gY3J0YyAyOiBjdXJyZW50PTAsIGRpZmY9MCwgaHc9MCBod19sYXN0PTAKPiA+Pj4+Pj4+Pj5b ZHJtOnJhZGVvbl9nZXRfdmJsYW5rX2NvdW50ZXJfa21zXSBRdWVyeSBmYWlsZWQhIHN0YXQgMwo+ ID4+Pj4+Pj4+Pltkcm06cmFkZW9uX2dldF92YmxhbmtfY291bnRlcl9rbXNdIFF1ZXJ5IGZhaWxl ZCEgc3RhdCAzCj4gPj4+Pj4+Pj4+W2RybTpkcm1fdXBkYXRlX3ZibGFua19jb3VudF0gdXBkYXRp bmcgdmJsYW5rIGNvdW50IG9uIGNydGMgMzogY3VycmVudD0wLCBkaWZmPTAsIGh3PTAgaHdfbGFz dD0wCj4gPj4+Pj4+Pj4+W2RybTpyYWRlb25fZ2V0X3ZibGFua19jb3VudGVyX2ttc10gUXVlcnkg ZmFpbGVkISBzdGF0IDEKPiA+Pj4+Pj4+Pj5bZHJtOmRybV9jYWxjX3ZibHRpbWVzdGFtcF9mcm9t X3NjYW5vdXRwb3NdIGNydGMgMCA6IHYgMHgxIHAoMCwwKUAgNzMwNC4zMTcxNDAgLT4gNzMwNC4z MTcxNDAgW2UgMCB1cywgMCByZXBdCj4gPj4+Pj4+Pj4+W2RybTpyYWRlb25fZ2V0X3ZibGFua19j b3VudGVyX2ttc10gUXVlcnkgZmFpbGVkISBzdGF0IDEKPiA+Pj4+Pj4+Pj5bZHJtOmRybV91cGRh dGVfdmJsYW5rX2NvdW50XSB1cGRhdGluZyB2YmxhbmsgY291bnQgb24gY3J0YyAwOiBjdXJyZW50 PTIzNDg4MDk5NSwgZGlmZj0xNjc3NzIxNSwgaHc9MCBod19sYXN0PTEKPiA+Pj4+Pj4+Pgo+ID4+ Pj4+Pj4+U2FtZSBoZXJlLgo+ID4+Pj4+Pj4KPiA+Pj4+Pj4+QXQgbGVhc3Qgb25lIG9mIHRoZSBq dW1wcyBpcyBleHBlY3RlZCwgYmVjYXVzZSB0aGlzIGlzIGFyb3VuZCB0dXJuaW5nCj4gPj4+Pj4+ Pm9mZiB0aGUgQ1JUQyBmb3IgRFBNUyBvZmYuIERvbid0IGtub3cgeWV0IHdoeSB0aGVyZSBhcmUg dHdvIGp1bXBzIGJhY2sKPiA+Pj4+Pj4+dGhvdWdoLgo+ID4+Pj4+Pj4KPiA+Pj4+Pj4+Cj4gPj4+ Pj4+Pj5UaGVzZSB0aGluZ3MganVzdCBkb24ndCBoYXBwZW4gb24gaTkxNSBiZWNhdXNlIGRybV92 Ymxhbmtfb2ZmKCkgYW5kCj4gPj4+Pj4+Pj5kcm1fdmJsYW5rX29uKCkgYXJlIGFsd2F5cyBjYWxs ZWQgYXJvdW5kIHRoZSB0aW1lcyB3aGVuIHRoZSBodyBjb3VudGVyCj4gPj4+Pj4+Pj5taWdodCBn ZXQgcmVzZXQuIE9yIGF0IGxlYXN0IHRoYXQncyBob3cgaXQgc2hvdWxkIGJlLgo+ID4+Pj4+Pj4K PiA+Pj4+Pj4+V2hpY2ggaXMgb2YgY291cnNlIHRoZSBpZGVhIG9mIERhbmllbCdzIHBhdGNoICh3 aGljaCBpcyB3aGF0IEknbSBnZXR0aW5nCj4gPj4+Pj4+PnRoZSBhYm92ZSB3aXRoKSBvciBNYXJp bydzIHBhdGNoIGFzIHdlbGwsIGJ1dCBjbGVhcmx5IHNvbWV0aGluZydzIHN0aWxsCj4gPj4+Pj4+ Pndyb25nLiBJdCdzIGNlcnRhaW5seSBwb3NzaWJsZSB0aGF0IGl0J3Mgc29tZXRoaW5nIGluIHRo ZSBkcml2ZXIsIGJ1dAo+ID4+Pj4+Pj5zaW5jZSBjYWxsaW5nIGRybV92YmxhbmtfcHJlL3Bvc3Rf bW9kZXNldCBmcm9tIHRoZSBzYW1lIHBsYWNlcyBzZWVtcyB0bwo+ID4+Pj4+Pj53b3JrIGZpbmUg KGlnbm9yaW5nIHRoZSByZWdyZXNzaW9uIGRpc2N1c3NlZCBpbiB0aGlzIHRocmVhZCkuLi4gRG8K PiA+Pj4+Pj4+ZHJtX3ZibGFua19vbi9vZmYgcmVxdWlyZSBzb21ldGhpbmcgZWxzZSB0byBoYW5k bGUgdGhpcyBjb3JyZWN0bHk/Cj4gPj4+Pj4+Pgo+ID4+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj5J IHN1c3BlY3QgaXQgaXMgYmVjYXVzZSB2YmxhbmtfZGlzYWJsZV9hbmRfc2F2ZSBjYWxscwo+ID4+ Pj4+PmRybV91cGRhdGVfdmJsYW5rX2NvdW50KCkgdW5jb25kaXRpb25hbGx5LCBldmVuIGlmIHZi bGFuayBpcnFzIGFyZQo+ID4+Pj4+PmFscmVhZHkgb2ZmLgo+ID4+Pj4+Pgo+ID4+Pj4+PlNvIG9u IGEgbWFudWFsIGRpc3BsYXkgZGlzYWJsZSAtPiByZWVuYWJsZSB5b3UgZ2V0IHNvbWV0aGluZyBs aWtlCj4gPj4+Pj4+Cj4gPj4+Pj4+QXQgZGlzYWJsZToKPiA+Pj4+Pj4KPiA+Pj4+Pj5DYWxsIHRv IGRwbXMtb2ZmIC0tPiBhdG9tYmlvc19jcnRjX2RwbXMoRFBNU19PRkYpIC0tPiBkcm1fdmJsYW5r X29mZiAtPgo+ID4+Pj4+PnZibGFua19kaXNhYmxlX2FuZF9zYXZlIC0+IGlycXMgb2ZmLCBkcm1f dXBkYXRlX3ZibGFua19jb3VudCgpIGNvbXB1dGVzCj4gPj4+Pj4+ZmluYWwgY291bnQuCj4gPj4+ Pj4+Cj4gPj4+Pj4+VGhlbiB0aGUgY3J0YyBpcyBzaHV0IGRvd24gYW5kIGl0cyBodyBjb3VudGVy IHJlc2V0cyB0byB6ZXJvLgo+ID4+Pj4+Pgo+ID4+Pj4+PkF0IHJlZW5hYmxlOgo+ID4+Pj4+Pgo+ ID4+Pj4+Pk1vZGVzZXR0aW5nIC0+IGRybV9jcnRjX2hlbHBlcl9zZXRfbW9kZSAtPiBjcnRjX2Z1 bmNzLT5wcmVwYXJlKGNydGMpIC0+Cj4gPj4+Pj4+YXRvbWJpb3NfY3J0Y19wcmVwYXJlKCkgLT4g YXRvbWJpb3NfY3J0Y19kcG1zKERQTVNfT0ZGKSAtPgo+ID4+Pj4+PmRybV92Ymxhbmtfb2ZmIC0+ IHZibGFua19kaXNhYmxlX2FuZF9zYXZlIC0+IEEgcG9pbnRsZXNzCj4gPj4+Pj4+ZHJtX3VwZGF0 ZV92YmxhbmtfY291bnQoKSB3aGlsZSB0aGUgaHcgY291bnRlciBpcyBhbHJlYWR5IHJlc2V0IHRv IHplcm8KPiA+Pj4+Pj4tLT4gVW53YW50ZWQgY291bnRlciBqdW1wLgo+ID4+Pj4+Pgo+ID4+Pj4+ Pgo+ID4+Pj4+PlRoZSBwcm9ibGVtIGRvZXNuJ3QgaGFwcGVuIG9uIGEgcHVyZSBtb2Rlc2V0IHRv IGEgZGlmZmVyZW50IHZpZGVvCj4gPj4+Pj4+cmVzb2x1dGlvbi9yZWZyZXNoIHJhdGUsIGFzIHRo ZW4gd2Ugb25seSBoYXZlIG9uZSBjYWxsIGludG8KPiA+Pj4+Pj5hdG9tYmlvc19jcnRjX2RwbXMo RFBNU19PRkYpLgo+ID4+Pj4+Pgo+ID4+Pj4+PkkgdGhpbmsgdGhlIGZpeCBpcyB0byBmaXggdmJs YW5rX2Rpc2FibGVfYW5kX3NhdmUoKSB0byBvbmx5IGNhbGwKPiA+Pj4+Pj5kcm1fdXBkYXRlX3Zi bGFua19jb3VudCgpIGlmIHZibGFuayBpcnFzIGdldCBhY3R1YWxseSBkaXNhYmxlZCwgbm90IG9u Cj4gPj4+Pj4+bm8tb3AgY2FsbHMuIEkgd2lsbCB0cnkgdGhhdCBub3cuCj4gPj4+Pj4KPiA+Pj4+ Pkl0IGRvZXMgdGhhdCBvbiBwdXJwb3NlLiBPdGhlcndpc2UgdGhlIHZibGFuayBjb3VudGVyIHdv dWxkIGFwcGVhciB0bwo+ID4+Pj4+aGF2ZSBzdGFsbGVkIHdoaWxlIHRoZSBpbnRlcnJ1cHQgd2Fz IG9mZi4KPiA+Pj4+Pgo+ID4+Pj4KPiA+Pj4+T2ssIHRoYXQncyB3aGF0IHRoZSBjb21tZW50cyB0 aGVyZSBzYXksIGFsdGhvdWdoIGkgZG9uJ3Qgc2VlIGF0bS4gd2h5Cj4gPj4+PnRoYXQgcGVyY2Vp dmVkIHN0YWxsIHdvdWxkIGJlIGEgYmlnIHByb2JsZW0uIEkgY2hlY2tlZCBhbGwgY2FsbGVycyBv Zgo+ID4+Pj52YmxhbmtfZGlzYWJsZV9hbmRfc2F2ZSgpLiBUaGV5IGFyZSBhbGwgY2FyZWZ1bCB0 byBub3QgY2FsbCB0aGF0Cj4gPj4+PmZ1bmN0aW9uIGlmIHZibGFua3MgYXJlIGFscmVhZHkgZGlz YWJsZWQuIFRoZSBvbmx5IGV4Y2VwdGlvbiBpcwo+ID4+Pj5kcm1fdmJsYW5rX29mZigpLiBJZiBk cm1fdmJsYW5rX29mZi9vbiBpcyBzdXBwb3NlZCB0byBwcm90ZWN0IGttcwo+ID4+Pj5kcml2ZXJz IHdoaWNoIGhhdmUgcmVzZXR0aW5nIGh3IGNvdW50ZXJzIG9yIG90aGVyIHByb2JsZW1hdGljIGJl aGF2aW91cgo+ID4+Pj5kdXJpbmcgbW9kZXNldHMgZXRjLiB0aGVuIHRoaXMgd2lsbCBicmVhay4g RS5nLiwgY2FsbGluZyB0aGUgdmJsYW5rCj4gPj4+PnRpbWVzdGFtcGluZyBzdHVmZiBpcyBhbHNv IG5vdCBzYWZlL3dlbGwtZGVmaW5lZCBkdXJpbmcgbW9kZXNldHMgd2hlbgo+ID4+Pj50aGUgdGlt ZXN0YW1waW5nIGNvbnN0YW50cyBhcmUgbm90ICh5ZXQpIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUg bmV3IG1vZGUKPiA+Pj4+dGltaW5nIG9mIHRoZSBtb2Rlc2V0IGluIHByb2dyZXNzLgo+ID4+Pgo+ ID4+PlRoZSBpZGVhIGlzIHRvIG1haW50YWluIHRoZSBhcHBlYXJhbmNlIHRoYXQgdGhlIGNvdW50 ZXIgdGlja3MgYWxsIHRoZQo+ID4+PnRpbWUgYXMgbG9uZyBhcyB0aGUgY3J0YyBpcyBhY3RpdmUu IFdoaWxlIHRoYXQgbWF5IG5vdCBiZSByZWFsbHkKPiA+Pj5yZXF1aXJlZCBpbiBjYXNlIGlmIG5v IG9uZSBpcyBjdXJyZW50bHkgaW50ZXJlc3RlZCBpbiB0aGUgdmJsYW5rCj4gPj4+Y291bnRlciwg SSB0aGluayBpdCdzIGEgbmljZSB0aGluZyB0byBoYXZlIGp1c3QgdG8gbWFrZSB0aGUgYmVoYXZp b3VyCj4gPj4+b2YgdGhlIGNvdW50ZXIgY29uc2lzdGVudC4KPiA+Pj4KPiA+Pj5BcyBmYXIgYXMg Y2FsbGluZyBkcm1fdmJsYW5rX29mZigpIGFmdGVyIHRoZSBodyBjb3VudGVyIGdvdCByZXNldCwg d2VsbCwKPiA+Pj50aGF0IG5vdCBjb3JyZWN0LiBJdCBzaG91bGQgYmUgY2FsbGVkIGJlZm9yZSB0 aGUgcmVzZXQuCj4gPj4KPiA+PldoYXQgcmFkZW9uIGRvZXMgaXMgY2FsbGluZyBkcm1fdmJsYW5r X29mZiBhdCBiZWdpbm5pbmcgb2YgRFBNU19PRkYuIFRoZQo+ID4+Zmlyc3QgY2FsbCB0byBETVBT X09GRiB3aWxsIGNhbGwgZHJtX3ZibGFua19vZmYoKSBhbmQgcmVhbGx5IGRpc2FibGUKPiA+PnZi bGFuay1pcnFzIGlmIHRoZXkgd2VyZSBydW5uaW5nLCB1cGRhdGluZyB0aGUgY291bnRzL3RzIGEg bGFzdCB0aW1lLiBCdXQKPiA+PnRoZW4gdGhlIGRwbXMgb2ZmIHdpbGwgcmVzZXQgdGhlIGh3IGNv dW50ZXIgdG8gemVyby4gV2hlbiBvbmUgcmVlbmFibGVzIHRoZQo+ID4+ZGlzcGxheSwgYSBzZWNv bmQgY2FsbCB0byBEUE1TX09GRiB3aWxsIG5vdyBjYWxsIGRybV92Ymxhbmtfb2ZmIGFnYWluIHdo ZW4KPiA+Pml0IGFwcGFyZW50bHkgc2hvdWxkbid0Lgo+ID4+Cj4gPj5JIGp1c3QgdGVzdGVkIHRo aXMgcGF0Y2gsIHdoaWNoIGZpeGVzIHRoZSBjb3VudGVyIGp1bXBzIG9uIHJhZGVvbi1rbXMgd2l0 aAo+ID4+bXkgb3IgRGFuaWVsJ3MgZHJtX3ZibGFua19vZmYgcGF0Y2hlcyB0byByYWRlb246Cj4g Pgo+ID5UaGlzIG1pZ2h0IGJlIGR1ZSB0byB0aGUgbGVnYWN5IGhlbHBlcnMsIHdoaWNoIGp1c3Qg bG92ZSB0byByZWR1bmRhbnRseQo+ID5kaXNhYmxlIHN0dWZmIHRoYXQncyBvZmYgYWxyZWFkeS4g VGhlIHByb2JsZW0gSSBzZWUgd2l0aCBuby1vcGluZyB0aGVzZQo+ID5vdXQgaXMgdGhhdCBmb3Ig YXRvbWljIGRyaXZlcnMgKHdoaWNoIHJlYWxseSBzaG91bGQgZ2V0IHRoaXMgcmlnaHQpIHRoaXMK PiA+bWlnaHQgcGFwZXIgb3ZlciBidWdzOiBFLmcuIHdoZW4geW91IGZvcmdldCB0byBjYWxsIF9v ZmYoKSB3aGVuIGRpc2FibGluZwo+ID50aGUgY3J0YywgdGhlbiBjYWxsaW5nIF9vbigpIHR3aWNl IGluIGEgcm93IGlzIGluZGVlZCBhIHNlcmlvdXMgYnVnLgo+ID5TaW1pbGFyIHdoZW4geW91IGZv cmdldCB0byBjYWxsIF9vbigpIGFuZCBoYXZlIG11bHRpcGxlIF9vZmYoKSBjYWxscyBpbiBhCj4g PnJvdy4KPiA+Cj4gPlNvIG5vdCBzdXJlIHdoYXQgdG8gZG8gaGVyZS4KPiA+LURhbmllbAo+ID4K PiAKPiBZZXMsIHRoZSBsZWdhY3kgaGVscGVycyBjYXVzZSB0d28gY2FsbHMgdG8gZHBtcyBvZmYg aWYgb25lIGRpc2FibGVzIGEKPiBkaXNwbGF5LiBGaXJzdCBkdXJpbmcgZGlzcGxheSBkaXNhYmxl IGFzIGludGVuZGVkLiBUaGVuIHdoZW4gb25lIHJlZW5hYmxlcwo+IHRoZSBkaXNwbGF5IGR1cmlu ZyBtb2Rlc2V0dGluZyBhcyBwYXJ0IG9mIGNydGNfZnVuY3MtPnByZXBhcmUoKSAtIGF0IGxlYXN0 Cj4gb24gcmFkZW9uLgo+IAo+IE1heWJlIHRoZSBtaW5pbXVtIHRoaW5nIHRoYXQgd291bGQgaGVs cCBpcyB0byBqdXN0IGNoZWNrIGZvcgo+IHZibGFuay0+aW5tb2Rlc2V0IGluIGRybV92Ymxhbmtf b2ZmKCkuIElmIHRoYXQgd291bGQgYmUgdGhlIGNhc2Ugd2UnZCBrbm93Cj4gaXQgaXMgYSByZWR1 bmRhbnQgY2FsbCBhbmQgY291bGQgbm8tb3AgaXQgYW5kIGRvIGEKPiBXQVJOX09OKHZibGFuay0+ aW5tb2Rlc2V0KT8KCkkgaGF2ZSB0aGF0IGhlcmUgbG9jYWxseSwgYmxvd3MgdXAgYWxsIG92ZXIg dGhlIHBsYWNlIG9uIHJhZG9lbi4gQW5kIGFsc28Kd291bGQgYmxvdyB1cCBldmVyeXdoZXJlIGVs c2UuCgpJIHdhcyB0aGlua2luZyBvZiBhZGRpbmcgdGhlIHZibGFuay0+aW5tb2Rlc2V0IGNoZWNr IHRvIHJhZGVvbi9hbWRncHUsCndpdGggYSBub3RlIHdoeSBpdCdzIG5lZWRlZCAobGVnYWN5IGNy dGMgaGVscGVycyBqdXN0IHN1Y2spLgoKPiBkcm1fdmJsYW5rX29uKCkgaSBkb24ndCBrbm93IGhv dyB0byB0cmVhdCwgYnV0IHRoYXQgb25lIGNhbGxzCj4gZHJtX3Jlc2V0X3ZibGFua190aW1lc3Rh bXAoKSB3aGljaCBzaG91bGQgYmUgbGVzcyBwcm9ibGVtYXRpYyBpZiBjYWxsZWQKPiByZWR1bmRh bnRseS4KCkkgdGhpbmsgZXZlbiBsZWdhY3kgY3J0YyBoZWxwZXJzIGRvbid0IGVuYWJsZSBzdHVm ZiBhZ2FpbiBpZiBpdCdzIG5vdCBiZWVuCmRpc2FibGVkIGJlZm9yZS4gU28gb24gZHJtX3ZibGFu a19vbigpIHdlIG1pZ2h0IGJlIGFibGUgdG8gcHV0IGEgV0FSTl9PTgppbiBwbGFjZSAuLi4KCj4g Tm93IHRoZSBwYXRjaCBpIHdhbnQgdG8gdHJ5IG5leHQgdG8gZml4IHRoZSBkcm1fdmJsYW5rX3By ZS9wb3N0X21vZGVzZXQKPiByZWdyZXNzaW9uIGluIExpbnV4IDQuNC80LjUgaXMgdG8gYWRkIGEg Li4uCj4gCj4gaWYgKChkaWZmID4gMSkgJiYgdmJsYW5rLT5pbm1vZGVzZXQpIGRpZmYgPSAxOwo+ IAo+IC4uLiB0byB0aGUgYm90dG9tIG9mIGRybV91cGRhdGVfdmJsYW5rX2NvdW50KCkuIFRoYXQg c2hvdWxkIGhvcGVmdWxseQo+IHJlc3RvcmUgdGhlIHByZS9wb3N0X21vZGVzZXQgYmVoYXZpb3Ig YXMgY2xvc2UgdG8gdGhlIG9yaWdpbmFsIGJlaGF2aW9yIGFzCj4gcG9zc2libGUuIEFzIGEgc2lk ZSBlZmZlY3QgaXQgd291bGQgYWxzbyBwcmV2ZW50IHRoZSBjb3VudGVyIGp1bXAgY2F1c2VkIGJ5 Cj4gcmVkdW5kYW50IGNhbGxzIHRvIGRybV92Ymxhbmtfb2ZmKCkuCgpIbSwgY2FuIHdlIGp1c3Qg ZnJvYiBwcmUvcG9zdF9tb2Rlc2V0IG9ubHkgd2l0aCBzb21lIGNoZWNrcz8gSSdkIGxpa2UgdG8K bm90IHB1dCB0aGF0IGtpbmQgb2YgIkkgaGF2ZSBubyBpZGVhIGFib3V0IG15IGh3IHN0YXRlIiBo YWNrcyBpbnRvIHRoZSBuZXcKaGVscGVycy4gT3RoZXJ3aXNlIG5vdCBldmVuIGF0b21pYyBkcml2 ZXJzIGNhbiBzdGFydCB0byBnYWluIFdBUk5fT05zIHRvCmVuZm9yY2UgY29ycmVjdCB1c2FnZSwg d2hpY2ggd291bGQgYmUgYSByZWFsIGJ1bW1lciBpbW8uCi1EYW5pZWwKLS0gCkRhbmllbCBWZXR0 ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCmh0dHA6Ly9ibG9nLmZmd2xs LmNoCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1k ZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8v bGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758359AbcAYUcj (ORCPT ); Mon, 25 Jan 2016 15:32:39 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:35170 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757349AbcAYUcg (ORCPT ); Mon, 25 Jan 2016 15:32:36 -0500 Date: Mon, 25 Jan 2016 21:32:43 +0100 From: Daniel Vetter To: Mario Kleiner Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Michel =?iso-8859-1?Q?D=E4nzer?= , Alex Deucher , Vlastimil Babka , LKML , dri-devel@lists.freedesktop.org, Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon Message-ID: <20160125203243.GW11240@phenom.ffwll.local> Mail-Followup-To: Mario Kleiner , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Michel =?iso-8859-1?Q?D=E4nzer?= , Alex Deucher , Vlastimil Babka , LKML , dri-devel@lists.freedesktop.org, Christian =?iso-8859-1?Q?K=F6nig?= References: <56A19C98.8020208@daenzer.net> <20160122151835.GM23290@intel.com> <56A5A171.7000205@daenzer.net> <56A6203D.3030803@gmail.com> <20160125132310.GS23290@intel.com> <56A626D5.2040808@gmail.com> <20160125145309.GT23290@intel.com> <56A64F86.9080605@gmail.com> <20160125185122.GV11240@phenom.ffwll.local> <56A677C6.4050909@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56A677C6.4050909@gmail.com> X-Operating-System: Linux phenom 4.3.0-1-amd64 User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2016 at 08:30:14PM +0100, Mario Kleiner wrote: > > > On 01/25/2016 07:51 PM, Daniel Vetter wrote: > >On Mon, Jan 25, 2016 at 05:38:30PM +0100, Mario Kleiner wrote: > >>Readding Daniel, which somehow got dropped from the cc. > >> > >>On 01/25/2016 03:53 PM, Ville Syrjälä wrote: > >>>On Mon, Jan 25, 2016 at 02:44:53PM +0100, Mario Kleiner wrote: > >>>> > >>>> > >>>>On 01/25/2016 02:23 PM, Ville Syrjälä wrote: > >>>>>On Mon, Jan 25, 2016 at 02:16:45PM +0100, Mario Kleiner wrote: > >>>>>> > >>>>>> > >>>>>>On 01/25/2016 05:15 AM, Michel Dänzer wrote: > >>>>>>>On 23.01.2016 00:18, Ville Syrjälä wrote: > >>>>>>>>On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote: > >>>>>>>>> > >>>>>>>>>[ Trimming KDE folks from Cc ] > >>>>>>>>> > >>>>>>>>>On 21.01.2016 19:09, Daniel Vetter wrote: > >>>>>>>>>>On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote: > >>>>>>>>>>>On 21.01.2016 16:58, Daniel Vetter wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>Can you please point me at the vblank on/off jump bug please? > >>>>>>>>>>> > >>>>>>>>>>>AFAIR I originally reported it in response to > >>>>>>>>>>>http://lists.freedesktop.org/archives/dri-devel/2015-August/087841.html > >>>>>>>>>>>, but I can't find that in the archives, so maybe that was just on IRC. > >>>>>>>>>>>See > >>>>>>>>>>>http://lists.freedesktop.org/archives/dri-devel/2016-January/099122.html > >>>>>>>>>>>. Basically, I ran into the bug fixed by your patch because the counter > >>>>>>>>>>>jumped forward on every DPMS off, so it hit the 32-bit boundary after > >>>>>>>>>>>just a few days. > >>>>>>>>>> > >>>>>>>>>>Ok, so just uncovered the overflow bug. > >>>>>>>>> > >>>>>>>>>Not sure what you mean by "just", but to be clear: The drm_vblank_on/off > >>>>>>>>>counter jumping bug (similar to the bug this thread is about), which > >>>>>>>>>exposed the overflow bug, is still alive and kicking in 4.5. It seems > >>>>>>>>>to happen when turning off the CRTC: > >>>>>>>>> > >>>>>>>>>[drm:drm_update_vblank_count] updating vblank count on crtc 0: current=218104694, diff=0, hw=916 hw_last=916 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] crtc 0: dist from vblank start 3 > >>>>>>>>>[drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 0 : v 0x7 p(2199,-45)@ 7304.307354 -> 7304.308006 [e 0 us, 0 rep] > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] crtc 0: dist from vblank start 3 > >>>>>>>>>[drm:drm_update_vblank_count] updating vblank count on crtc 0: current=218104694, diff=16776301, hw=1 hw_last=916 > >>>>>>>> > >>>>>>>>Not sure what bug we're talking about here, but here the hw counter > >>>>>>>>clearly jumps backwards. > >>>>>>>> > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > >>>>>>>>>[drm:drm_update_vblank_count] updating vblank count on crtc 1: current=0, diff=0, hw=0 hw_last=0 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > >>>>>>>>>[drm:drm_update_vblank_count] updating vblank count on crtc 2: current=0, diff=0, hw=0 hw_last=0 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 3 > >>>>>>>>>[drm:drm_update_vblank_count] updating vblank count on crtc 3: current=0, diff=0, hw=0 hw_last=0 > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 1 > >>>>>>>>>[drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 0 : v 0x1 p(0,0)@ 7304.317140 -> 7304.317140 [e 0 us, 0 rep] > >>>>>>>>>[drm:radeon_get_vblank_counter_kms] Query failed! stat 1 > >>>>>>>>>[drm:drm_update_vblank_count] updating vblank count on crtc 0: current=234880995, diff=16777215, hw=0 hw_last=1 > >>>>>>>> > >>>>>>>>Same here. > >>>>>>> > >>>>>>>At least one of the jumps is expected, because this is around turning > >>>>>>>off the CRTC for DPMS off. Don't know yet why there are two jumps back > >>>>>>>though. > >>>>>>> > >>>>>>> > >>>>>>>>These things just don't happen on i915 because drm_vblank_off() and > >>>>>>>>drm_vblank_on() are always called around the times when the hw counter > >>>>>>>>might get reset. Or at least that's how it should be. > >>>>>>> > >>>>>>>Which is of course the idea of Daniel's patch (which is what I'm getting > >>>>>>>the above with) or Mario's patch as well, but clearly something's still > >>>>>>>wrong. It's certainly possible that it's something in the driver, but > >>>>>>>since calling drm_vblank_pre/post_modeset from the same places seems to > >>>>>>>work fine (ignoring the regression discussed in this thread)... Do > >>>>>>>drm_vblank_on/off require something else to handle this correctly? > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>I suspect it is because vblank_disable_and_save calls > >>>>>>drm_update_vblank_count() unconditionally, even if vblank irqs are > >>>>>>already off. > >>>>>> > >>>>>>So on a manual display disable -> reenable you get something like > >>>>>> > >>>>>>At disable: > >>>>>> > >>>>>>Call to dpms-off --> atombios_crtc_dpms(DPMS_OFF) --> drm_vblank_off -> > >>>>>>vblank_disable_and_save -> irqs off, drm_update_vblank_count() computes > >>>>>>final count. > >>>>>> > >>>>>>Then the crtc is shut down and its hw counter resets to zero. > >>>>>> > >>>>>>At reenable: > >>>>>> > >>>>>>Modesetting -> drm_crtc_helper_set_mode -> crtc_funcs->prepare(crtc) -> > >>>>>>atombios_crtc_prepare() -> atombios_crtc_dpms(DPMS_OFF) -> > >>>>>>drm_vblank_off -> vblank_disable_and_save -> A pointless > >>>>>>drm_update_vblank_count() while the hw counter is already reset to zero > >>>>>>--> Unwanted counter jump. > >>>>>> > >>>>>> > >>>>>>The problem doesn't happen on a pure modeset to a different video > >>>>>>resolution/refresh rate, as then we only have one call into > >>>>>>atombios_crtc_dpms(DPMS_OFF). > >>>>>> > >>>>>>I think the fix is to fix vblank_disable_and_save() to only call > >>>>>>drm_update_vblank_count() if vblank irqs get actually disabled, not on > >>>>>>no-op calls. I will try that now. > >>>>> > >>>>>It does that on purpose. Otherwise the vblank counter would appear to > >>>>>have stalled while the interrupt was off. > >>>>> > >>>> > >>>>Ok, that's what the comments there say, although i don't see atm. why > >>>>that perceived stall would be a big problem. I checked all callers of > >>>>vblank_disable_and_save(). They are all careful to not call that > >>>>function if vblanks are already disabled. The only exception is > >>>>drm_vblank_off(). If drm_vblank_off/on is supposed to protect kms > >>>>drivers which have resetting hw counters or other problematic behaviour > >>>>during modesets etc. then this will break. E.g., calling the vblank > >>>>timestamping stuff is also not safe/well-defined during modesets when > >>>>the timestamping constants are not (yet) updated to reflect the new mode > >>>>timing of the modeset in progress. > >>> > >>>The idea is to maintain the appearance that the counter ticks all the > >>>time as long as the crtc is active. While that may not be really > >>>required in case if no one is currently interested in the vblank > >>>counter, I think it's a nice thing to have just to make the behaviour > >>>of the counter consistent. > >>> > >>>As far as calling drm_vblank_off() after the hw counter got reset, well, > >>>that not correct. It should be called before the reset. > >> > >>What radeon does is calling drm_vblank_off at beginning of DPMS_OFF. The > >>first call to DMPS_OFF will call drm_vblank_off() and really disable > >>vblank-irqs if they were running, updating the counts/ts a last time. But > >>then the dpms off will reset the hw counter to zero. When one reenables the > >>display, a second call to DPMS_OFF will now call drm_vblank_off again when > >>it apparently shouldn't. > >> > >>I just tested this patch, which fixes the counter jumps on radeon-kms with > >>my or Daniel's drm_vblank_off patches to radeon: > > > >This might be due to the legacy helpers, which just love to redundantly > >disable stuff that's off already. The problem I see with no-oping these > >out is that for atomic drivers (which really should get this right) this > >might paper over bugs: E.g. when you forget to call _off() when disabling > >the crtc, then calling _on() twice in a row is indeed a serious bug. > >Similar when you forget to call _on() and have multiple _off() calls in a > >row. > > > >So not sure what to do here. > >-Daniel > > > > Yes, the legacy helpers cause two calls to dpms off if one disables a > display. First during display disable as intended. Then when one reenables > the display during modesetting as part of crtc_funcs->prepare() - at least > on radeon. > > Maybe the minimum thing that would help is to just check for > vblank->inmodeset in drm_vblank_off(). If that would be the case we'd know > it is a redundant call and could no-op it and do a > WARN_ON(vblank->inmodeset)? I have that here locally, blows up all over the place on radoen. And also would blow up everywhere else. I was thinking of adding the vblank->inmodeset check to radeon/amdgpu, with a note why it's needed (legacy crtc helpers just suck). > drm_vblank_on() i don't know how to treat, but that one calls > drm_reset_vblank_timestamp() which should be less problematic if called > redundantly. I think even legacy crtc helpers don't enable stuff again if it's not been disabled before. So on drm_vblank_on() we might be able to put a WARN_ON in place ... > Now the patch i want to try next to fix the drm_vblank_pre/post_modeset > regression in Linux 4.4/4.5 is to add a ... > > if ((diff > 1) && vblank->inmodeset) diff = 1; > > ... to the bottom of drm_update_vblank_count(). That should hopefully > restore the pre/post_modeset behavior as close to the original behavior as > possible. As a side effect it would also prevent the counter jump caused by > redundant calls to drm_vblank_off(). Hm, can we just frob pre/post_modeset only with some checks? I'd like to not put that kind of "I have no idea about my hw state" hacks into the new helpers. Otherwise not even atomic drivers can start to gain WARN_ONs to enforce correct usage, which would be a real bummer imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch