Created attachment 119429 [details] dmesg log of boot on Intel Broadwell with i915.enable_fdc=0. I am posting this bug with incomplete information because I suspect that tracking down a bug report about "Unclaimed register detected AFTER [my emphasis] writing register 0x4510c" may be a lot easier than the more mysterious bug reports about an unclaimed register access being detected before some register access event. I imagine that this a matter of confirming what register 0x4510c is, confirming that it does not exist on Broadwell and figuring out what code is incorrectly doing that access. Anyhow, here is the bug report in more detail. Linux 4.3 booted with the command line argument "i915.enable_fbc=0" on an Intel Broadwell i3-5010U processor emitted the warning message "Unclaimed register detected after writing to register 0x4510c", along with a call trace showing that error occurred at ilk_update_wm+0x7da (the stack trace is attached). I have only observed this problem when I have added some other debug messages of my own, although I suspect that this just indicates that timing is a factor in reproducing the problem. If register 0x4510c exists in Broadwell, then I would expect that accessing it would never set the unclaimed register flag. As another warning, I should mention that I suspect that the attached call trace is at least slightly inaccurate, because 0x7da probably exceeds the length of the function ilk_update_wm (I guess the "ilk" prefix means "Iron Lake" graphics), and I I don't think ilk_update_vm calls the i915 register access functions directly. However, I am hoping that the register address might be enough to determine which register that does not exist on Broadwell was being accessed. Please note that the attached dmesg log includes some additional call traces, because I had modified the unclaimed register access code to By the way, I passed "i915.enabled_fbc=0" because my attempts to track down a warning message about "Unclaimed register detected before writing to register 0x..." (where the register number varies), indicated that the previous i915 register access (which did not trigger an unclaimed register warning) was a read from ilk_fbc_disable. I will probably file a separate bug report about that if I can track it down the point where I think I have information that would help point to the cause.
I don't know how I missed this: $ egrep -i 4510c drivers/gpu/drm/i915/*.h drivers/gpu/drm/i915/i915_reg.h:#define WM2_LP_ILK 0x4510c The only .c file containing the string WM2_LP_ILK is drivers/gpu/drm/i915/intel_pm.c, and the term "watermark" appears close to those uses, so I guess that is what "WM" stands for. It looks like this register is written unconditionally in ilk_init_lp_watermarks, and I am just guessing from the function name that it gets executed at initialization, so maybe there is something wrong with the other debugging code that I added. I expect I'll look into this tomorrow, but wanted to post this update now to avoid prompting anyone else do this bit of research that I should have done before posting. I apologize for not including this information in my initial bug report.
Please just drop i915.enable_fbc=0 module parameter, it's disabled by default and might lead people astray.
Hi, Jani. Thank you for responding to my bug. It is useful for me to know that someone else has read it and thought about it for a moment. However, I think you may be missing the point. It is not my end goal to disable frame buffer compression (enable_fbc=0), although I don't understand what you mean by "it might lead users astray". I am just providing that argument to document how I produced the problem. The big news in this bug report is the word "after" in the unclaimed register error. That means that the register number in the errror message probably really is the invalid register number (in this case, 0x4510c = WM2_LP_ILK). Since this happens to be a register that is not used in very many places, it is probable that there is very little left to do figure out and resolve this problem for someone who knows more than I do about which when hardware supports which registers. Here is a non-exhaustive list of possible responses that I was hoping for: 1) "It turns out that WM2_LP_ILK does not exist in Broadwell, so we need to change function _________ to test for Broadwell and do _____________ in that case." 2) "Actually WM2_LP_ILK does exist in Broadwell, so you are probably observing some race with another core touching a nonexistent register while we're doing a polling loop on WM2_LP_ILK." 3) "Thanks for the report, but I have determined that your bug really is specific to enabled_fbc=0 and not indicative of any problem that could effect enabled_fbc=1. Supporting enable_fbc=0 is very low priority to me (and everyone else, as far as I know), but please feel free to track it down on your own update this bug report with a proposed fix." I'm not being sarcastic here. If you meant something other than example #3 by your response, I would be interested in knowing. Thank you, in any case, for your response. Just getting an indication that enable_fbc=0 is rarely used was helpful. Thanks again for your response.
Adam, I barely spent a minute looking at the bug in a firehose stream of bugs. My only point was, you're bringing up i915.enable_fbc in a way that might lead people (people as in other developers, not users) astray when looking at this bug. FBC is disabled by default, therefore i915.enable_fbc=0 is a no-op, and shouldn't change anything for the issue you're seeing.
Hi, Jani. I'm sorry for misunderstanding your previous comment. Somehow I thought you meant that enabled_fbc=0 was deprecated, not that it was a no-op since it is already the default. Based on your point, I am retitling this bug to remove mention of enabled_fbc=0. Thanks for your comments, and sorry for the lengthy incorrect reaction on my part. I'll update here if I have any news on this that I think might be helpful.
Is this still an issue with the latest upstream driver?
Timeout - marking resolved+worksforme. Please reopen this if failure still exists with the latest kernel (preferable from drm-tip). Adam - I also apologize loooong delay until getting back to you.
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.