From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon Date: Mon, 25 Jan 2016 16:53:09 +0200 Message-ID: <20160125145309.GT23290@intel.com> References: <56A07D97.6030606@daenzer.net> <20160121075849.GH19130@phenom.ffwll.local> <56A0989E.30006@daenzer.net> <20160121100905.GL19130@phenom.ffwll.local> <56A19C98.8020208@daenzer.net> <20160122151835.GM23290@intel.com> <56A5A171.7000205@daenzer.net> <56A6203D.3030803@gmail.com> <20160125132310.GS23290@intel.com> <56A626D5.2040808@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id A721B6E47C for ; Mon, 25 Jan 2016 06:53:14 -0800 (PST) Content-Disposition: inline In-Reply-To: <56A626D5.2040808@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 T24gTW9uLCBKYW4gMjUsIDIwMTYgYXQgMDI6NDQ6NTNQTSArMDEwMCwgTWFyaW8gS2xlaW5lciB3 cm90ZToKPiAKPiAKPiBPbiAwMS8yNS8yMDE2IDAyOjIzIFBNLCBWaWxsZSBTeXJqw6Rsw6Qgd3Jv dGU6Cj4gPiBPbiBNb24sIEphbiAyNSwgMjAxNiBhdCAwMjoxNjo0NVBNICswMTAwLCBNYXJpbyBL bGVpbmVyIHdyb3RlOgo+ID4+Cj4gPj4KPiA+PiBPbiAwMS8yNS8yMDE2IDA1OjE1IEFNLCBNaWNo ZWwgRMOkbnplciB3cm90ZToKPiA+Pj4gT24gMjMuMDEuMjAxNiAwMDoxOCwgVmlsbGUgU3lyasOk bMOkIHdyb3RlOgo+ID4+Pj4gT24gRnJpLCBKYW4gMjIsIDIwMTYgYXQgMTI6MDY6MDBQTSArMDkw MCwgTWljaGVsIETDpG56ZXIgd3JvdGU6Cj4gPj4+Pj4KPiA+Pj4+PiBbIFRyaW1taW5nIEtERSBm b2xrcyBmcm9tIENjIF0KPiA+Pj4+Pgo+ID4+Pj4+IE9uIDIxLjAxLjIwMTYgMTk6MDksIERhbmll bCBWZXR0ZXIgd3JvdGU6Cj4gPj4+Pj4+IE9uIFRodSwgSmFuIDIxLCAyMDE2IGF0IDA1OjM2OjQ2 UE0gKzA5MDAsIE1pY2hlbCBEw6RuemVyIHdyb3RlOgo+ID4+Pj4+Pj4gT24gMjEuMDEuMjAxNiAx Njo1OCwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+Pj4+Pj4+Pgo+ID4+Pj4+Pj4+IENhbiB5b3Ug cGxlYXNlIHBvaW50IG1lIGF0IHRoZSB2Ymxhbmsgb24vb2ZmIGp1bXAgYnVnIHBsZWFzZT8KPiA+ Pj4+Pj4+Cj4gPj4+Pj4+PiBBRkFJUiBJIG9yaWdpbmFsbHkgcmVwb3J0ZWQgaXQgaW4gcmVzcG9u c2UgdG8KPiA+Pj4+Pj4+IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvYXJjaGl2ZXMvZHJp LWRldmVsLzIwMTUtQXVndXN0LzA4Nzg0MS5odG1sCj4gPj4+Pj4+PiAsIGJ1dCBJIGNhbid0IGZp bmQgdGhhdCBpbiB0aGUgYXJjaGl2ZXMsIHNvIG1heWJlIHRoYXQgd2FzIGp1c3Qgb24gSVJDLgo+ ID4+Pj4+Pj4gU2VlCj4gPj4+Pj4+PiBodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL2FyY2hp dmVzL2RyaS1kZXZlbC8yMDE2LUphbnVhcnkvMDk5MTIyLmh0bWwKPiA+Pj4+Pj4+IC4gQmFzaWNh bGx5LCBJIHJhbiBpbnRvIHRoZSBidWcgZml4ZWQgYnkgeW91ciBwYXRjaCBiZWNhdXNlIHRoZSBj b3VudGVyCj4gPj4+Pj4+PiBqdW1wZWQgZm9yd2FyZCBvbiBldmVyeSBEUE1TIG9mZiwgc28gaXQg aGl0IHRoZSAzMi1iaXQgYm91bmRhcnkgYWZ0ZXIKPiA+Pj4+Pj4+IGp1c3QgYSBmZXcgZGF5cy4K PiA+Pj4+Pj4KPiA+Pj4+Pj4gT2ssIHNvIGp1c3QgdW5jb3ZlcmVkIHRoZSBvdmVyZmxvdyBidWcu Cj4gPj4+Pj4KPiA+Pj4+PiBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJqdXN0IiwgYnV0IHRv IGJlIGNsZWFyOiBUaGUgZHJtX3ZibGFua19vbi9vZmYKPiA+Pj4+PiBjb3VudGVyIGp1bXBpbmcg YnVnIChzaW1pbGFyIHRvIHRoZSBidWcgdGhpcyB0aHJlYWQgaXMgYWJvdXQpLCB3aGljaAo+ID4+ Pj4+IGV4cG9zZWQgdGhlIG92ZXJmbG93IGJ1ZywgaXMgc3RpbGwgYWxpdmUgYW5kIGtpY2tpbmcg aW4gNC41LiBJdCBzZWVtcwo+ID4+Pj4+IHRvIGhhcHBlbiB3aGVuIHR1cm5pbmcgb2ZmIHRoZSBD UlRDOgo+ID4+Pj4+Cj4gPj4+Pj4gW2RybTpkcm1fdXBkYXRlX3ZibGFua19jb3VudF0gdXBkYXRp bmcgdmJsYW5rIGNvdW50IG9uIGNydGMgMDogY3VycmVudD0yMTgxMDQ2OTQsIGRpZmY9MCwgaHc9 OTE2IGh3X2xhc3Q9OTE2Cj4gPj4+Pj4gW2RybTpyYWRlb25fZ2V0X3ZibGFua19jb3VudGVyX2tt c10gY3J0YyAwOiBkaXN0IGZyb20gdmJsYW5rIHN0YXJ0IDMKPiA+Pj4+PiBbZHJtOmRybV9jYWxj X3ZibHRpbWVzdGFtcF9mcm9tX3NjYW5vdXRwb3NdIGNydGMgMCA6IHYgMHg3IHAoMjE5OSwtNDUp QCA3MzA0LjMwNzM1NCAtPiA3MzA0LjMwODAwNiBbZSAwIHVzLCAwIHJlcF0KPiA+Pj4+PiBbZHJt OnJhZGVvbl9nZXRfdmJsYW5rX2NvdW50ZXJfa21zXSBjcnRjIDA6IGRpc3QgZnJvbSB2Ymxhbmsg c3RhcnQgMwo+ID4+Pj4+IFtkcm06ZHJtX3VwZGF0ZV92YmxhbmtfY291bnRdIHVwZGF0aW5nIHZi bGFuayBjb3VudCBvbiBjcnRjIDA6IGN1cnJlbnQ9MjE4MTA0Njk0LCBkaWZmPTE2Nzc2MzAxLCBo dz0xIGh3X2xhc3Q9OTE2Cj4gPj4+Pgo+ID4+Pj4gTm90IHN1cmUgd2hhdCBidWcgd2UncmUgdGFs a2luZyBhYm91dCBoZXJlLCBidXQgaGVyZSB0aGUgaHcgY291bnRlcgo+ID4+Pj4gY2xlYXJseSBq dW1wcyBiYWNrd2FyZHMuCj4gPj4+Pgo+ID4+Pj4+IFtkcm06cmFkZW9uX2dldF92YmxhbmtfY291 bnRlcl9rbXNdIFF1ZXJ5IGZhaWxlZCEgc3RhdCAzCj4gPj4+Pj4gW2RybTpyYWRlb25fZ2V0X3Zi bGFua19jb3VudGVyX2ttc10gUXVlcnkgZmFpbGVkISBzdGF0IDMKPiA+Pj4+PiBbZHJtOmRybV91 cGRhdGVfdmJsYW5rX2NvdW50XSB1cGRhdGluZyB2YmxhbmsgY291bnQgb24gY3J0YyAxOiBjdXJy ZW50PTAsIGRpZmY9MCwgaHc9MCBod19sYXN0PTAKPiA+Pj4+PiBbZHJtOnJhZGVvbl9nZXRfdmJs YW5rX2NvdW50ZXJfa21zXSBRdWVyeSBmYWlsZWQhIHN0YXQgMwo+ID4+Pj4+IFtkcm06cmFkZW9u X2dldF92YmxhbmtfY291bnRlcl9rbXNdIFF1ZXJ5IGZhaWxlZCEgc3RhdCAzCj4gPj4+Pj4gW2Ry bTpkcm1fdXBkYXRlX3ZibGFua19jb3VudF0gdXBkYXRpbmcgdmJsYW5rIGNvdW50IG9uIGNydGMg MjogY3VycmVudD0wLCBkaWZmPTAsIGh3PTAgaHdfbGFzdD0wCj4gPj4+Pj4gW2RybTpyYWRlb25f Z2V0X3ZibGFua19jb3VudGVyX2ttc10gUXVlcnkgZmFpbGVkISBzdGF0IDMKPiA+Pj4+PiBbZHJt OnJhZGVvbl9nZXRfdmJsYW5rX2NvdW50ZXJfa21zXSBRdWVyeSBmYWlsZWQhIHN0YXQgMwo+ID4+ Pj4+IFtkcm06ZHJtX3VwZGF0ZV92YmxhbmtfY291bnRdIHVwZGF0aW5nIHZibGFuayBjb3VudCBv biBjcnRjIDM6IGN1cnJlbnQ9MCwgZGlmZj0wLCBodz0wIGh3X2xhc3Q9MAo+ID4+Pj4+IFtkcm06 cmFkZW9uX2dldF92YmxhbmtfY291bnRlcl9rbXNdIFF1ZXJ5IGZhaWxlZCEgc3RhdCAxCj4gPj4+ Pj4gW2RybTpkcm1fY2FsY192Ymx0aW1lc3RhbXBfZnJvbV9zY2Fub3V0cG9zXSBjcnRjIDAgOiB2 IDB4MSBwKDAsMClAIDczMDQuMzE3MTQwIC0+IDczMDQuMzE3MTQwIFtlIDAgdXMsIDAgcmVwXQo+ ID4+Pj4+IFtkcm06cmFkZW9uX2dldF92YmxhbmtfY291bnRlcl9rbXNdIFF1ZXJ5IGZhaWxlZCEg c3RhdCAxCj4gPj4+Pj4gW2RybTpkcm1fdXBkYXRlX3ZibGFua19jb3VudF0gdXBkYXRpbmcgdmJs YW5rIGNvdW50IG9uIGNydGMgMDogY3VycmVudD0yMzQ4ODA5OTUsIGRpZmY9MTY3NzcyMTUsIGh3 PTAgaHdfbGFzdD0xCj4gPj4+Pgo+ID4+Pj4gU2FtZSBoZXJlLgo+ID4+Pgo+ID4+PiBBdCBsZWFz dCBvbmUgb2YgdGhlIGp1bXBzIGlzIGV4cGVjdGVkLCBiZWNhdXNlIHRoaXMgaXMgYXJvdW5kIHR1 cm5pbmcKPiA+Pj4gb2ZmIHRoZSBDUlRDIGZvciBEUE1TIG9mZi4gRG9uJ3Qga25vdyB5ZXQgd2h5 IHRoZXJlIGFyZSB0d28ganVtcHMgYmFjawo+ID4+PiB0aG91Z2guCj4gPj4+Cj4gPj4+Cj4gPj4+ PiBUaGVzZSB0aGluZ3MganVzdCBkb24ndCBoYXBwZW4gb24gaTkxNSBiZWNhdXNlIGRybV92Ymxh bmtfb2ZmKCkgYW5kCj4gPj4+PiBkcm1fdmJsYW5rX29uKCkgYXJlIGFsd2F5cyBjYWxsZWQgYXJv dW5kIHRoZSB0aW1lcyB3aGVuIHRoZSBodyBjb3VudGVyCj4gPj4+PiBtaWdodCBnZXQgcmVzZXQu IE9yIGF0IGxlYXN0IHRoYXQncyBob3cgaXQgc2hvdWxkIGJlLgo+ID4+Pgo+ID4+PiBXaGljaCBp cyBvZiBjb3Vyc2UgdGhlIGlkZWEgb2YgRGFuaWVsJ3MgcGF0Y2ggKHdoaWNoIGlzIHdoYXQgSSdt IGdldHRpbmcKPiA+Pj4gdGhlIGFib3ZlIHdpdGgpIG9yIE1hcmlvJ3MgcGF0Y2ggYXMgd2VsbCwg YnV0IGNsZWFybHkgc29tZXRoaW5nJ3Mgc3RpbGwKPiA+Pj4gd3JvbmcuIEl0J3MgY2VydGFpbmx5 IHBvc3NpYmxlIHRoYXQgaXQncyBzb21ldGhpbmcgaW4gdGhlIGRyaXZlciwgYnV0Cj4gPj4+IHNp bmNlIGNhbGxpbmcgZHJtX3ZibGFua19wcmUvcG9zdF9tb2Rlc2V0IGZyb20gdGhlIHNhbWUgcGxh Y2VzIHNlZW1zIHRvCj4gPj4+IHdvcmsgZmluZSAoaWdub3JpbmcgdGhlIHJlZ3Jlc3Npb24gZGlz Y3Vzc2VkIGluIHRoaXMgdGhyZWFkKS4uLiBEbwo+ID4+PiBkcm1fdmJsYW5rX29uL29mZiByZXF1 aXJlIHNvbWV0aGluZyBlbHNlIHRvIGhhbmRsZSB0aGlzIGNvcnJlY3RseT8KPiA+Pj4KPiA+Pj4K PiA+Pgo+ID4+IEkgc3VzcGVjdCBpdCBpcyBiZWNhdXNlIHZibGFua19kaXNhYmxlX2FuZF9zYXZl IGNhbGxzCj4gPj4gZHJtX3VwZGF0ZV92YmxhbmtfY291bnQoKSB1bmNvbmRpdGlvbmFsbHksIGV2 ZW4gaWYgdmJsYW5rIGlycXMgYXJlCj4gPj4gYWxyZWFkeSBvZmYuCj4gPj4KPiA+PiBTbyBvbiBh IG1hbnVhbCBkaXNwbGF5IGRpc2FibGUgLT4gcmVlbmFibGUgeW91IGdldCBzb21ldGhpbmcgbGlr ZQo+ID4+Cj4gPj4gQXQgZGlzYWJsZToKPiA+Pgo+ID4+IENhbGwgdG8gZHBtcy1vZmYgLS0+IGF0 b21iaW9zX2NydGNfZHBtcyhEUE1TX09GRikgLS0+IGRybV92Ymxhbmtfb2ZmIC0+Cj4gPj4gdmJs YW5rX2Rpc2FibGVfYW5kX3NhdmUgLT4gaXJxcyBvZmYsIGRybV91cGRhdGVfdmJsYW5rX2NvdW50 KCkgY29tcHV0ZXMKPiA+PiBmaW5hbCBjb3VudC4KPiA+Pgo+ID4+IFRoZW4gdGhlIGNydGMgaXMg c2h1dCBkb3duIGFuZCBpdHMgaHcgY291bnRlciByZXNldHMgdG8gemVyby4KPiA+Pgo+ID4+IEF0 IHJlZW5hYmxlOgo+ID4+Cj4gPj4gTW9kZXNldHRpbmcgLT4gZHJtX2NydGNfaGVscGVyX3NldF9t b2RlIC0+IGNydGNfZnVuY3MtPnByZXBhcmUoY3J0YykgLT4KPiA+PiBhdG9tYmlvc19jcnRjX3By ZXBhcmUoKSAtPiBhdG9tYmlvc19jcnRjX2RwbXMoRFBNU19PRkYpIC0+Cj4gPj4gZHJtX3ZibGFu a19vZmYgLT4gdmJsYW5rX2Rpc2FibGVfYW5kX3NhdmUgLT4gQSBwb2ludGxlc3MKPiA+PiBkcm1f dXBkYXRlX3ZibGFua19jb3VudCgpIHdoaWxlIHRoZSBodyBjb3VudGVyIGlzIGFscmVhZHkgcmVz ZXQgdG8gemVybwo+ID4+IC0tPiBVbndhbnRlZCBjb3VudGVyIGp1bXAuCj4gPj4KPiA+Pgo+ID4+ IFRoZSBwcm9ibGVtIGRvZXNuJ3QgaGFwcGVuIG9uIGEgcHVyZSBtb2Rlc2V0IHRvIGEgZGlmZmVy ZW50IHZpZGVvCj4gPj4gcmVzb2x1dGlvbi9yZWZyZXNoIHJhdGUsIGFzIHRoZW4gd2Ugb25seSBo YXZlIG9uZSBjYWxsIGludG8KPiA+PiBhdG9tYmlvc19jcnRjX2RwbXMoRFBNU19PRkYpLgo+ID4+ Cj4gPj4gSSB0aGluayB0aGUgZml4IGlzIHRvIGZpeCB2YmxhbmtfZGlzYWJsZV9hbmRfc2F2ZSgp IHRvIG9ubHkgY2FsbAo+ID4+IGRybV91cGRhdGVfdmJsYW5rX2NvdW50KCkgaWYgdmJsYW5rIGly cXMgZ2V0IGFjdHVhbGx5IGRpc2FibGVkLCBub3Qgb24KPiA+PiBuby1vcCBjYWxscy4gSSB3aWxs IHRyeSB0aGF0IG5vdy4KPiA+Cj4gPiBJdCBkb2VzIHRoYXQgb24gcHVycG9zZS4gT3RoZXJ3aXNl IHRoZSB2YmxhbmsgY291bnRlciB3b3VsZCBhcHBlYXIgdG8KPiA+IGhhdmUgc3RhbGxlZCB3aGls ZSB0aGUgaW50ZXJydXB0IHdhcyBvZmYuCj4gPgo+IAo+IE9rLCB0aGF0J3Mgd2hhdCB0aGUgY29t bWVudHMgdGhlcmUgc2F5LCBhbHRob3VnaCBpIGRvbid0IHNlZSBhdG0uIHdoeSAKPiB0aGF0IHBl cmNlaXZlZCBzdGFsbCB3b3VsZCBiZSBhIGJpZyBwcm9ibGVtLiBJIGNoZWNrZWQgYWxsIGNhbGxl cnMgb2YgCj4gdmJsYW5rX2Rpc2FibGVfYW5kX3NhdmUoKS4gVGhleSBhcmUgYWxsIGNhcmVmdWwg dG8gbm90IGNhbGwgdGhhdCAKPiBmdW5jdGlvbiBpZiB2YmxhbmtzIGFyZSBhbHJlYWR5IGRpc2Fi bGVkLiBUaGUgb25seSBleGNlcHRpb24gaXMgCj4gZHJtX3ZibGFua19vZmYoKS4gSWYgZHJtX3Zi bGFua19vZmYvb24gaXMgc3VwcG9zZWQgdG8gcHJvdGVjdCBrbXMgCj4gZHJpdmVycyB3aGljaCBo YXZlIHJlc2V0dGluZyBodyBjb3VudGVycyBvciBvdGhlciBwcm9ibGVtYXRpYyBiZWhhdmlvdXIg Cj4gZHVyaW5nIG1vZGVzZXRzIGV0Yy4gdGhlbiB0aGlzIHdpbGwgYnJlYWsuIEUuZy4sIGNhbGxp bmcgdGhlIHZibGFuayAKPiB0aW1lc3RhbXBpbmcgc3R1ZmYgaXMgYWxzbyBub3Qgc2FmZS93ZWxs LWRlZmluZWQgZHVyaW5nIG1vZGVzZXRzIHdoZW4gCj4gdGhlIHRpbWVzdGFtcGluZyBjb25zdGFu dHMgYXJlIG5vdCAoeWV0KSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIG5ldyBtb2RlIAo+IHRpbWlu ZyBvZiB0aGUgbW9kZXNldCBpbiBwcm9ncmVzcy4KClRoZSBpZGVhIGlzIHRvIG1haW50YWluIHRo ZSBhcHBlYXJhbmNlIHRoYXQgdGhlIGNvdW50ZXIgdGlja3MgYWxsIHRoZQp0aW1lIGFzIGxvbmcg YXMgdGhlIGNydGMgaXMgYWN0aXZlLiBXaGlsZSB0aGF0IG1heSBub3QgYmUgcmVhbGx5CnJlcXVp cmVkIGluIGNhc2UgaWYgbm8gb25lIGlzIGN1cnJlbnRseSBpbnRlcmVzdGVkIGluIHRoZSB2Ymxh bmsKY291bnRlciwgSSB0aGluayBpdCdzIGEgbmljZSB0aGluZyB0byBoYXZlIGp1c3QgdG8gbWFr ZSB0aGUgYmVoYXZpb3VyCm9mIHRoZSBjb3VudGVyIGNvbnNpc3RlbnQuCgpBcyBmYXIgYXMgY2Fs bGluZyBkcm1fdmJsYW5rX29mZigpIGFmdGVyIHRoZSBodyBjb3VudGVyIGdvdCByZXNldCwgd2Vs bCwKdGhhdCBub3QgY29ycmVjdC4gSXQgc2hvdWxkIGJlIGNhbGxlZCBiZWZvcmUgdGhlIHJlc2V0 LgoKPiAKPiAtbWFyaW8KPiAKPiAKPiA+Pgo+ID4+IE90aGVyd2lzZSBrbXMgZHJpdmVycyB3b3Vs ZCBoYXZlIHRvIGJlIGNhcmVmdWwgdG8gbmV2ZXIgY2FsbAo+ID4+IGRybV92Ymxhbmtfb2ZmIG11 bHRpcGxlIHRpbWVzIGJlZm9yZSBjYWxsaW5nIGRybV92Ymxhbmtfb24sIGJ1dCB0aGUgaGVscAo+ ID4+IHRleHQgdG8gZHJtX3ZibGFua19vbigpIGNsYWltcyB0aGF0IHVuYmFsYW5jZWQgY2FsbHMg dG8gdGhlc2UgZnVuY3Rpb25zCj4gPj4gYXJlIHBlcmZlY3RseSBmaW5lLgo+ID4+Cj4gPj4gLW1h cmlvCj4gPj4KPiA+Pgo+ID4+Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4KPiA+CgotLSAKVmlsbGUgU3ly asOkbMOkCkludGVsIE9UQwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3Rv cC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1k ZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757282AbcAYOxR (ORCPT ); Mon, 25 Jan 2016 09:53:17 -0500 Received: from mga09.intel.com ([134.134.136.24]:38634 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755543AbcAYOxP (ORCPT ); Mon, 25 Jan 2016 09:53:15 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,344,1449561600"; d="scan'208";a="868165434" Date: Mon, 25 Jan 2016 16:53:09 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Mario Kleiner Cc: 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: <20160125145309.GT23290@intel.com> References: <56A07D97.6030606@daenzer.net> <20160121075849.GH19130@phenom.ffwll.local> <56A0989E.30006@daenzer.net> <20160121100905.GL19130@phenom.ffwll.local> <56A19C98.8020208@daenzer.net> <20160122151835.GM23290@intel.com> <56A5A171.7000205@daenzer.net> <56A6203D.3030803@gmail.com> <20160125132310.GS23290@intel.com> <56A626D5.2040808@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56A626D5.2040808@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > -mario > > > >> > >> Otherwise kms drivers would have to be careful to never call > >> drm_vblank_off multiple times before calling drm_vblank_on, but the help > >> text to drm_vblank_on() claims that unbalanced calls to these functions > >> are perfectly fine. > >> > >> -mario > >> > >> > >> > >> > >> > >> > >> > > -- Ville Syrjälä Intel OTC