Re: [PATCH] linux-firmware: update firmware for mhdp8546

[Josh Boyer]

Applied and pushed out.

josh

On Fri, May 7, 2021 at 2:00 AM Parshuram Thombare  wrote:
>
> This patch updates mhdp8546 firmware to 2.1.0
> Fix memory leak in HDCP state machine.
>
> Signed-off-by: Parshuram Thombare 
> ---
>  WHENCE   |2 +-
>  cadence/mhdp8546.bin |  Bin 131072 -> 131072 bytes
>  2 files changed, 1 insertions(+), 1 deletions(-)
>  mode change 100755 => 100644 cadence/mhdp8546.bin
>
> diff --git a/WHENCE b/WHENCE
> index 440f8cd..a096d0d 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -5352,7 +5352,7 @@ Licence:
>  Driver: cdns-mhdp - Cadence MHDP8546 DP bridge
>
>  File: cadence/mhdp8546.bin
> -Version: 2.0.0
> +Version: 2.1.0
>
>  Licence: Redistributable. See LICENCE.cadence for details
>
> diff --git a/cadence/mhdp8546.bin b/cadence/mhdp8546.bin
> old mode 100755
> new mode 100644
> index 
> 2f85f57c506e3347c1f4670b9a0b96e415d2eaaa..bbb1009a22ac01d6a28c09d8acd2ae73b820bb9f
> GIT binary patch
> delta 14381
> zcmcJ0d011|_UJh$VG3Ji7D(5I{tmpmnwgDl(~nLlw0ZFbGanOK+`JGw8KwX)np{
> zy^5u6PTJh6mHte$Ep4SGskIK+D|Aw8?*-Zjk^l))KnUlp6ZGCUe82bpdilPcb@sH@
> z+H0@9_F8+Nqg47TmA+M{eZFM~__Y}6b|3HkfrNDNi}+37L~msPAzk<<{FQHh)Y5P!
> 

Re: Update firmware for Qualcomm SM8250 platform

[Josh Boyer]

Pulled and pushed out.

josh

On Thu, Apr 1, 2021 at 4:11 PM Dmitry Baryshkov
 wrote:
>
> Hello linux-firmware maintainers,
>
> Could you please pull updated firmware for Qualcomm SM8250-based
> platforms. Firmware successfully tested on Qualcomm Robotics RB5 platform.
>
>
> The following changes since commit 3f026a2f13a8f130cde849168a111ec80f12e27b:
>
>rtl_bt: Update RTL8822C BT(UART I/F) FW to 0x59A_76A3 (2021-03-22
> 10:17:18 -0400)
>
> are available in the Git repository at:
>
>https://github.com/lumag/linux-firmware sm8250-new-fw
>
> for you to fetch changes up to d8fa0cfb4a285d11fd7102efd1763f1be90fac99:
>
>qcom: sm8250: update remoteproc firmware (2021-04-01 23:05:00 +0300)
>
> 
> Dmitry Baryshkov (2):
>qcom: update a650 firmware files
>qcom: sm8250: update remoteproc firmware
>
>   WHENCE   |   2 +-
>   qcom/a650_sqe.fw | Bin 31488 -> 31804 bytes
>   qcom/sm8250/a650_zap.mbn | Bin 13964 -> 13964 bytes
>   qcom/sm8250/adsp.mbn | Bin 15515796 -> 15515796 bytes
>   qcom/sm8250/cdsp.mbn | Bin 588 -> 588 bytes
>   5 files changed, 1 insertion(+), 1 deletion(-)
>
>
>
> --
> With best wishes
> Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-firmware for Qualcomm SM8250 platforms

[Josh Boyer]

Pulled and pushed out.

josh

On Fri, Jan 22, 2021 at 5:12 PM Dmitry Baryshkov
 wrote:
>
> Hello linux-firmware maintainers,
>
> We'd like to submit firmware for Qualcomm SM8250-based platforms.
> Firmware successfully tested on Qualcomm Robotics RB5 platform.
>
> The following changes since commit d5288624259300c558480c21a860fcf94187d29d:
>
>brcm: Add NVRAM for Vamrs 96boards Rock960 (2021-01-09 07:31:33 -0500)
>
> are available in the Git repository at:
>
>https://github.com/lumag/linux-firmware qcom-rb5
>
> for you to fetch changes up to df822a848cceb185d2d50a39140ba0c9cd9f33e9::
>
>qcom: Add venus firmware files for VPU-1.0 (2021-01-23 01:10:05 +0300)
>
> 
> Dmitry Baryshkov (4):
>qcom: add firmware files for Adreno a650
>qcom: Add SM8250 Audio DSP firmware
>qcom: Add SM8250 Compute DSP firmware
>qcom: Add venus firmware files for VPU-1.0
>
>   WHENCE   |  26 ++
>   qcom/a650_gmu.bin| Bin 0 -> 41548 bytes
>   qcom/a650_sqe.fw | Bin 0 -> 31488 bytes
>   qcom/sm8250/a650_zap.mbn | Bin 0 -> 13964 bytes
>   qcom/sm8250/adsp.mbn | Bin 0 -> 15515796 bytes
>   qcom/sm8250/adspr.jsn|  21 +
>   qcom/sm8250/adspua.jsn   |  27 +++
>   qcom/sm8250/cdsp.mbn | Bin 0 -> 588 bytes
>   qcom/sm8250/cdspr.jsn|  21 +
>   qcom/vpu-1.0/venus.b00   | Bin 0 -> 692 bytes
>   qcom/vpu-1.0/venus.b01   | Bin 0 -> 7528 bytes
>   qcom/vpu-1.0/venus.b02   | Bin 0 -> 300 bytes
>   qcom/vpu-1.0/venus.b03   | Bin 0 -> 20 bytes
>   qcom/vpu-1.0/venus.b04   | Bin 0 -> 20 bytes
>   qcom/vpu-1.0/venus.b05   | Bin 0 -> 20 bytes
>   qcom/vpu-1.0/venus.b06   | Bin 0 -> 20 bytes
>   qcom/vpu-1.0/venus.b07   | Bin 0 -> 24 bytes
>   qcom/vpu-1.0/venus.b08   | Bin 0 -> 16 bytes
>   qcom/vpu-1.0/venus.b09   | Bin 0 -> 883152 bytes
>   qcom/vpu-1.0/venus.b10   | Bin 0 -> 41360 bytes
>   qcom/vpu-1.0/venus.b19   |   1 +
>   qcom/vpu-1.0/venus.mbn   | Bin 0 -> 1973540 bytes
>   qcom/vpu-1.0/venus.mdt   | Bin 0 -> 8220 bytes
>   23 files changed, 96 insertions(+)
>   create mode 100644 qcom/a650_gmu.bin
>   create mode 100644 qcom/a650_sqe.fw
>   create mode 100644 qcom/sm8250/a650_zap.mbn
>   create mode 100644 qcom/sm8250/adsp.mbn
>   create mode 100644 qcom/sm8250/adspr.jsn
>   create mode 100644 qcom/sm8250/adspua.jsn
>   create mode 100644 qcom/sm8250/cdsp.mbn
>   create mode 100644 qcom/sm8250/cdspr.jsn
>   create mode 100644 qcom/vpu-1.0/venus.b00
>   create mode 100644 qcom/vpu-1.0/venus.b01
>   create mode 100644 qcom/vpu-1.0/venus.b02
>   create mode 100644 qcom/vpu-1.0/venus.b03
>   create mode 100644 qcom/vpu-1.0/venus.b04
>   create mode 100644 qcom/vpu-1.0/venus.b05
>   create mode 100644 qcom/vpu-1.0/venus.b06
>   create mode 100644 qcom/vpu-1.0/venus.b07
>   create mode 100644 qcom/vpu-1.0/venus.b08
>   create mode 100644 qcom/vpu-1.0/venus.b09
>   create mode 100644 qcom/vpu-1.0/venus.b10
>   create mode 100644 qcom/vpu-1.0/venus.b19
>   create mode 100644 qcom/vpu-1.0/venus.mbn
>   create mode 100644 qcom/vpu-1.0/venus.mdt
>
>
>
> --
> With best wishes
> Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-firmware: add firmware for Lontium lt9611uxc DSI to HDMI bridge

[Josh Boyer]

Pulled and pushed out.

josh

On Thu, Dec 10, 2020 at 7:46 PM Dmitry Baryshkov
 wrote:
>
> Hello linux-firmware maintainers,
>
> The following changes since commit 7455a36066741a6e52fba65e04f6451b4cdfd9c4:
>
>   Merge branch 'guc_v49' of git://anongit.freedesktop.org/drm/drm-firmware 
> into main (2020-11-30 09:26:11 -0500)
>
> are available in the Git repository at:
>
>   https://github.com/lumag/linux-firmware lt9611uxc
>
> for you to fetch changes up to 63ab3db8399a504048716eb3feed2867da58876a:
>
>   linux-firmware: add firmware for Lontium LT9611UXC DSI to HDMI bridge 
> (2020-12-11 03:27:38 +0300)
>
> 
> Dmitry Baryshkov (1):
>   linux-firmware: add firmware for Lontium LT9611UXC DSI to HDMI bridge
>
>  LICENSE.Lontium  |   2 ++
>  WHENCE   |   8 
>  lt9611uxc_fw.bin | Bin 0 -> 17932 bytes
>  3 files changed, 10 insertions(+)
>  create mode 100644 LICENSE.Lontium
>  create mode 100644 lt9611uxc_fw.bin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] linux-firmware: Update firmware for Cadence MHDP8546 DP bridge

[Josh Boyer]

Applied and pushed out.

josh

On Wed, Sep 23, 2020 at 11:14 AM Swapnil Jakhade  wrote:
>
> Update firmware for Cadence MHDP8546 DP bridge to version 2.0.0.
> The firmware source code now complies with MISRA2012 and HIS
> rules and directives. Also, there are some improvements in AUX
> channel communication handling.
>
> Signed-off-by: Swapnil Jakhade 
> ---
>  WHENCE   |   4 ++--
>  cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/WHENCE b/WHENCE
> index 7511677..d4bd8cf 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -5003,10 +5003,10 @@ Licence:
>
>  --
>
> -Driver: cdns-mhdp - Cadence MHDP DP bridge
> +Driver: cdns-mhdp - Cadence MHDP8546 DP bridge
>
>  File: cadence/mhdp8546.bin
> -Version: 1.2.15
> +Version: 2.0.0
>
>  Licence: Redistributable. See LICENCE.cadence for details
>
> diff --git a/cadence/mhdp8546.bin b/cadence/mhdp8546.bin
> index 
> 40097e0ec908ab5c4b54803f4b99519ced7a5e3d..2f85f57c506e3347c1f4670b9a0b96e415d2eaaa
>  100755
> GIT binary patch
> literal 131072
> zcmeFZd03NI_Bj47Nyu_lf=ZEqCV?m-b^_XJtrh|l*|b2Fy0rtrAmUQBbabqc zW(Hzs1WG>Hg*nGZ>=#f6y=tt-wzrmahLicB+gVF{5Eq?gSMTS-)H9Y&+qv@
> z-{<-Gc)8oT+qvhSd+s^sjX;253Z+tsVOaYL3{yk={Xc|Z-%bvCS)DUko{cF6*z`d*
> zdyqwBA(58rdyemgi^)mD z^Ea*(fCfHstL2#DTh@OEW+yO^-Y?LB~JF0L!OV}FoI#nKhEj<$^CEQe=+cX
> z0RwPcFl_T=Yzz5RyAQsKrMW!*3hQqlPjcD+{rA5Z_ zS(u)f?bn=zwE-t4-G&(X-%0tx`7!g<3Bv!cMSU*v{Zb@%iPZff>=_J;X(J8uq-v#F
> z{&$Xz4;I{lF239K3j9rg?*H}Q#U!jv zA~Y7s?~1myiPR58G4F`d4vVsmh_-#^oz6c)|7-q=cl=vP@~$NHXi`i}Qd(M4R#wus
> zZAk`0QdwCNO(!+{ySZEu`Q8%AyF?8z{-`J>MU=Kyl(k8;?Jbevps4IU5~K;naUW
> z7rArt9tumx1T6cnbNio^Xt0DaXzJ#%(f zL;e4kk9j=*JyJ~F{=;1#Bgc5}%p=6_3~E=Cjd#5QZS^^~KaT-^A3k0M^X~_*d{4
> z?jvuWz*v^;xfTOL41|v$EQSySAuN!M4gg~I^om
> z=$nvkox?`wLH-Mf*F$U%!!SGa-3npIpN+1W!bX1ta1oF`3h^~44}FS_Rzo=EkEuha
> zveBCZFtsn_-H<;9aCQjSAbbm<1;Q=}JgDD14d5Uh0ezkh!PKXr?F9%NS@_B@bz(54
> zZh^WoD04EChZ!K=CWo;Q8=d9LM#~i#hC(om2Xp;G!bbb1Vb~N10T6;9$RUJ6
> zsDXY~iP`7|So{1S2yz$?)~$v$q=o_>03W_k-U4Ooq2Hr(V0 zh*QI$Ez~6dKDWaf(josdh_fNy2k~}@e*^IXKY*XbMt5-iN!jR$5GF^VybB=$
> 

Re: [PATCH v2] linux-firmware: update firmware for mhdp8546

[Josh Boyer]

On Mon, Jun 3, 2019 at 7:06 AM Damian Kos  wrote:
>
> This patch updates mhdp8546 firmware from v1.2.12 to v1.2.15.
>
> Added support for performing arbitrary I2C-over-AUX transactions.
> Corrected handling of erroneous requests for reading/writing 0 bytes over 
> DPCD.
> Add mailbox message to force uCPU fatal error.
>
> Signed-off-by: Damian Kos 
> ---
>  WHENCE   |   2 +-
>  cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)

Applied and pushed out.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] linux-firmware: update firmware for mhdp8546

[Josh Boyer via dri-devel]

On Wed, Jan 30, 2019 at 8:24 AM Damian Kos  wrote:
>
> Updated firmware for Cadence MHDP8546 DP bridge.
>
> Release version: 1.2.15

You're missing a Signed-off-by and can you please update the WHENCE
file as well?

josh

> ---
>  cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/cadence/mhdp8546.bin b/cadence/mhdp8546.bin
> index 
> 01a31f6775e1c4d8d889216e78ef90e62888c487..40097e0ec908ab5c4b54803f4b99519ced7a5e3d
>  100755
> GIT binary patch
> delta 20442
> zcmbun30PCt)-b$JCXgHz6r)0b5C}M+0$R0*1p=l_wnAH4r(PL?L)EIawOTcUmZGIC
> 

Re: [PATCH 1/1] linux-firmware: add firmware for mhdp8546

[Josh Boyer]

On Mon, Aug 20, 2018 at 8:50 AM Damian Kos  wrote:
>
> Add binary firmware for Cadence MHDP8546 DP bridge.
>
> Release version: 1.2.12
>
> Signed-off-by: Damian Kos 
> ---
>  LICENCE.cadence  |  63 +++
>  WHENCE   |   9 +++
>  cadence/mhdp8546.bin | Bin 0 -> 131072 bytes
>  3 files changed, 72 insertions(+)
>  create mode 100644 LICENCE.cadence
>  create mode 100755 cadence/mhdp8546.bin

Applied and pushed out.

Thanks.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Josh Boyer]

On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> - Document the autoselect process
>>Information about about What, Why, and [ideally] How - analogous to
>>the normal stable nominations.
>>Insert reference to the process in the patch notification email.
>
> I agree with this one, and it'll definitely happen. The story behind
> this is that this is all based on Julia Lawall's work which is well
> documented in a published paper here:
>
> https://soarsmu.github.io/papers/icse12-patch.pdf
>
> I have modified inputs and process, but it essentially is very similar
> to what's described in that paper.
>
> While I have no problem with sharing what I have so far, this is
> still very much work in progress, and things keep constantly changing
> based on comments I receive from reviewers and Greg, so I want to
> reach a more stable point before trying to explain things and change
> my mind the day after :)
>
> If anyone is really interested in seeing the guts of this mess I
> currently have I can push it to github, but bear in mind that in it's
> current state it's very custom to the configuration I have, and is
> a borderline unreadable mix of bash scripts and LUA.
>
> Ideally it'll all get cleaned up and pushed anyways once I feel
> comfortable with the quality of the process.
>
>> - Make the autoselect nominations _more_ distinct than the normal stable 
>> ones.
>>Maintainers will want to put more cognitive effort into the patches.
>
> So this came up before, and the participants of that thread agreed
> that adding "AUTOSEL" in the patch prefix is sufficient. What else
> would you suggest adding?

The root of the concern seems to be around how the stable process
currently works and how auto-selection plays into that.  When Greg
sends out the RC, the default model of "if nobody objects, this patch
will get included in the next stable release" works because a human
already identified as that needing to be included.  So the review is
looking for a NAK, but that's overriding another human's explicit
decision with reasons.  For something that is auto-selected, people
seem concerned that the default should be flipped.  Perhaps they'd be
more comfortable if auto-selected packages required a human ACK before
they are included?

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

[Josh Boyer]

On Mon, Jun 22, 2015 at 9:27 AM, Jani Nikula
 wrote:
> On Mon, 22 Jun 2015, Josh Boyer  wrote:
>> On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter  
>> wrote:
>>> We should never nest these since in theory kms drivers should know
>>> when a pipe is on/off and call the corresponding enable/disable
>>> functions for the vblank helper code only once. But for historical
>>> reasons (the shared-with-ums version of this code in modeset_pre/post
>>> needed to be able to cope with silly userspace that lost track of
>>> things) we still have this bit of "robustness" around.
>>>
>>> Enforce this with a WARN_ON, preparing to eventually rip out this
>>> special handling.
>>
>> This doesn't really provide any context in the WARN_ON itself.  It
>> will just result in a splat that looks like a kernel oops, and end
>> users and distribution maintainers will be left scratching their
>> heads.
>>
>> Could this be done with a printk warning instead, or could you at
>> least provide a pr_warn statement to help people understand why their
>> machine has an oops splat?
>
> FWIW i915_drv.h has
>
> #define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
>
> which makes it a little better...

Only a little though, and only in i915.  This is in the generic DRM
code, isn't it?  I mean, a DRM developer is certainly helped by that.
But an end user seeing this won't know it is because of nested calls.
A simple:

dev_warn("Driver has nested vblank calls.  This works but should be
fixed soon.")

or something similar would at least help people understand what is
happening and that their machine isn't actually broken yet.

josh

>>> Cc: Yogesh Mohan Marimuthu 
>>> Cc: Gaurav K Singh 
>>> Cc: Michel Dänzer 
>>> Cc: Ville Syrjälä 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>  drivers/gpu/drm/drm_irq.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>>> index f9cc68fbd2a3..3819465abe22 100644
>>> --- a/drivers/gpu/drm/drm_irq.c
>>> +++ b/drivers/gpu/drm/drm_irq.c
>>> @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
>>> vblank_disable_and_save(dev, crtc);
>>> wake_up(>queue);
>>>
>>> +   WARN_ON(vblank->inmodeset);
>>> +
>>> /*
>>>  * Prevent subsequent drm_vblank_get() from re-enabling
>>>  * the vblank interrupt by bumping the refcount.
>>> @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
>>> return;
>>>
>>> spin_lock_irqsave(>vbl_lock, irqflags);
>>> +   WARN_ON(!vblank->inmodeset);
>>> +
>>> /* Drop our private "prevent drm_vblank_get" refcount */
>>> if (vblank->inmodeset) {
>>> atomic_dec(>refcount);
>>> --
>>> 2.1.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

[Josh Boyer]

On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter  
wrote:
> We should never nest these since in theory kms drivers should know
> when a pipe is on/off and call the corresponding enable/disable
> functions for the vblank helper code only once. But for historical
> reasons (the shared-with-ums version of this code in modeset_pre/post
> needed to be able to cope with silly userspace that lost track of
> things) we still have this bit of "robustness" around.
>
> Enforce this with a WARN_ON, preparing to eventually rip out this
> special handling.

This doesn't really provide any context in the WARN_ON itself.  It
will just result in a splat that looks like a kernel oops, and end
users and distribution maintainers will be left scratching their
heads.

Could this be done with a printk warning instead, or could you at
least provide a pr_warn statement to help people understand why their
machine has an oops splat?

josh

> Cc: Yogesh Mohan Marimuthu 
> Cc: Gaurav K Singh 
> Cc: Michel Dänzer 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index f9cc68fbd2a3..3819465abe22 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> vblank_disable_and_save(dev, crtc);
> wake_up(>queue);
>
> +   WARN_ON(vblank->inmodeset);
> +
> /*
>  * Prevent subsequent drm_vblank_get() from re-enabling
>  * the vblank interrupt by bumping the refcount.
> @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
> return;
>
> spin_lock_irqsave(>vbl_lock, irqflags);
> +   WARN_ON(!vblank->inmodeset);
> +
> /* Drop our private "prevent drm_vblank_get" refcount */
> if (vblank->inmodeset) {
> atomic_dec(>refcount);
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 00/11] Miscellaneous stability patches

[Josh Boyer]

On Wed, May 27, 2015 at 8:47 AM, Josh Boyer  
wrote:
> On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio  
> wrote:
>> This set of patches mainly contains fix for some memory issues
>> using quite aggressively surfaces and other minor problems like
>> images going black after a while.
>>
>> Frediano Ziglio (11):
>>   Do not cause spice-server to clean our objects
>>   Do not leak memory if qxl_release_list_add fails
>>   Fix print statement not using uninitialized variable
>>   Avoid double free on error
>>   Handle all errors in qxl_surface_evict
>>   Fix return for qxl_release_alloc
>>   Handle correctly failures in qxl_alloc_relase_reserved
>>   Remove format string errors
>>   Move main reference counter to GEM object instead of TTM ones
>>   Simplify cleaning qxl processing command
>>   Propagate correctly errors from qxlhw_handle_to_bo
>>
>>  qxl/qxl_cmd.c | 11 ++-
>>  qxl/qxl_display.c |  2 +-
>>  qxl/qxl_drv.h |  2 +-
>>  qxl/qxl_gem.c | 10 --
>>  qxl/qxl_ioctl.c   | 46 +-
>>  qxl/qxl_object.c  | 11 ---
>>  qxl/qxl_release.c | 13 +
>>  7 files changed, 46 insertions(+), 49 deletions(-)
>
> The strip level on these patches is rather odd.  Normally one would
> see a strip level of 1 at the top of the kernel dir.  E.g.
>
> drivers/gpu/drm/qxl/qxl_gem.c
>
> in the diffstat, etc.

(Sorry for the double reply.)

Also, are any of these commits something that should be queued for
stable kernel releases?  There are a handful that look like they
should be to me.

josh

[PATCH 00/11] Miscellaneous stability patches

[Josh Boyer]

On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio  wrote:
> This set of patches mainly contains fix for some memory issues
> using quite aggressively surfaces and other minor problems like
> images going black after a while.
>
> Frediano Ziglio (11):
>   Do not cause spice-server to clean our objects
>   Do not leak memory if qxl_release_list_add fails
>   Fix print statement not using uninitialized variable
>   Avoid double free on error
>   Handle all errors in qxl_surface_evict
>   Fix return for qxl_release_alloc
>   Handle correctly failures in qxl_alloc_relase_reserved
>   Remove format string errors
>   Move main reference counter to GEM object instead of TTM ones
>   Simplify cleaning qxl processing command
>   Propagate correctly errors from qxlhw_handle_to_bo
>
>  qxl/qxl_cmd.c | 11 ++-
>  qxl/qxl_display.c |  2 +-
>  qxl/qxl_drv.h |  2 +-
>  qxl/qxl_gem.c | 10 --
>  qxl/qxl_ioctl.c   | 46 +-
>  qxl/qxl_object.c  | 11 ---
>  qxl/qxl_release.c | 13 +
>  7 files changed, 46 insertions(+), 49 deletions(-)

The strip level on these patches is rather odd.  Normally one would
see a strip level of 1 at the top of the kernel dir.  E.g.

drivers/gpu/drm/qxl/qxl_gem.c

in the diffstat, etc.

josh

qxl deadlock splat

[Josh Boyer]

Hi Dave,

Below is a qxl lockdep spew that I got with Linus' tree a few days
ago.  I actually suspect this is present in older kernels too as the
DRM merge hasn't landed yet.  If you have any ideas, I'd appreciate
it.  I tried to look at the locking a bit, but I'm not familiar with
the ww ticket locking.

josh

[  +8.261799] ==
[  +0.01] [ INFO: possible circular locking dependency detected ]
[  +0.01] 4.1.0-0.rc0.git2.1.fc23.x86_64 #1 Not tainted
[  +0.01] ---
[  +0.01] gnome-shell/1012 is trying to acquire lock:
[  +0.01]  (reservation_ww_class_acquire){+.+.+.}, at:
[] qxl_release_reserve_list+0x55/0x120 [qxl]
[  +0.08]
  but task is already holding lock:
[  +0.01]  (reservation_ww_class_mutex){+.+.+.}, at:
[] qxl_crtc_page_flip+0xbb/0x230 [qxl]
[  +0.04]
  which lock already depends on the new lock.

[  +0.02]
  the existing dependency chain (in reverse order) is:
[  +0.01]
  -> #1 (reservation_ww_class_mutex){+.+.+.}:
[  +0.02][] lock_acquire+0xc7/0x2a0
[  +0.05][] __ww_mutex_lock+0x7f/0x770
[  +0.04][]
ttm_eu_reserve_buffers+0x365/0x640 [ttm]
[  +0.07][]
qxl_release_reserve_list+0x55/0x120 [qxl]
[  +0.05][] qxl_draw_opaque_fb+0xe6/0x3c0 [qxl]
[  +0.05][]
qxl_fb_imageblit_internal+0x4d/0x70 [qxl]
[  +0.18][] qxl_fb_imageblit+0x1a7/0x1c0 [qxl]
[  +0.06][] soft_cursor+0x1ac/0x230
[  +0.03][] bit_cursor+0x68b/0x6c0
[  +0.02][] fbcon_cursor+0x10d/0x180
[  +0.01][] hide_cursor+0x2c/0x90
[  +0.04][] redraw_screen+0x188/0x250
[  +0.03][] vc_do_resize+0x4c3/0x4f0
[  +0.03][] vc_resize+0x1f/0x30
[  +0.03][] fbcon_init+0x3cc/0x610
[  +0.02][] visual_init+0xbc/0x120
[  +0.03][] do_bind_con_driver+0x17e/0x3c0
[  +0.03][] do_take_over_console+0xb4/0x1b0
[  +0.03][] do_fbcon_takeover+0x63/0xd0
[  +0.04][] fbcon_event_notify+0x6dd/0x7e0
[  +0.03][] notifier_call_chain+0x3e/0xb0
[  +0.03][]
__blocking_notifier_call_chain+0x51/0x70
[  +0.03][] blocking_notifier_call_chain+0x16/0x20
[  +0.03][] fb_notifier_call_chain+0x1b/0x20
[  +0.04][] register_framebuffer+0x222/0x370
[  +0.03][]
drm_fb_helper_initial_config+0x264/0x3c0 [drm_kms_helper]
[  +0.08][] qxl_fbdev_init+0xd4/0x100 [qxl]
[  +0.05][] qxl_modeset_init+0x229/0x260 [qxl]
[  +0.13][] qxl_driver_load+0x811/0x840 [qxl]
[  +0.03][] drm_dev_register+0xb5/0x110 [drm]
[  +0.08][] drm_get_pci_dev+0x8d/0x200 [drm]
[  +0.06][] qxl_pci_probe+0x1b/0x40 [qxl]
[  +0.03][] local_pci_probe+0x45/0xa0
[  +0.02][] pci_device_probe+0xf9/0x150
[  +0.17][] driver_probe_device+0x209/0x4b0
[  +0.04][] __driver_attach+0xa3/0xb0
[  +0.01][] bus_for_each_dev+0x73/0xc0
[  +0.02][] driver_attach+0x1e/0x20
[  +0.02][] bus_add_driver+0x188/0x260
[  +0.02][] driver_register+0x64/0xf0
[  +0.02][] __pci_register_driver+0x64/0x70
[  +0.02][] drm_pci_init+0xfa/0x130 [drm]
[  +0.07][]
acpi_cpufreq_resume+0x28/0x70 [acpi_cpufreq]
[  +0.04][] do_one_initcall+0xd8/0x210
[  +0.04][] do_init_module+0x61/0x1ce
[  +0.03][] load_module+0x2359/0x2710
[  +0.03][] SyS_init_module+0x145/0x190
[  +0.02][] system_call_fastpath+0x12/0x76
[  +0.03]
  -> #0 (reservation_ww_class_acquire){+.+.+.}:
[  +0.02][] __lock_acquire+0x1ce9/0x2050
[  +0.02][] lock_acquire+0xc7/0x2a0
[  +0.02][]
ttm_eu_reserve_buffers+0xcc/0x640 [ttm]
[  +0.04][]
qxl_release_reserve_list+0x55/0x120 [qxl]
[  +0.03][] qxl_draw_dirty_fb+0x184/0x480 [qxl]
[  +0.03][] qxl_crtc_page_flip+0x100/0x230 [qxl]
[  +0.03][]
drm_mode_page_flip_ioctl+0x1ab/0x360 [drm]
[  +0.07][] drm_ioctl+0x1df/0x6a0 [drm]
[  +0.05][] do_vfs_ioctl+0x308/0x560
[  +0.03][] SyS_ioctl+0x81/0xa0
[  +0.02][] system_call_fastpath+0x12/0x76
[  +0.02]
  other info that might help us debug this:

[  +0.01]  Possible unsafe locking scenario:

[  +0.01]CPU0CPU1
[  +0.01]
[  +0.01]   lock(reservation_ww_class_mutex);
[  +0.03]lock(reservation_ww_class_acquire);
[  +0.02]lock(reservation_ww_class_mutex);
[  +0.02]   lock(reservation_ww_class_acquire);
[  +0.03]
   *** DEADLOCK ***

[  +0.03] 3 locks 

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>>> >> Hilarity happens and since that happens under console_lock at boot-up 
>>> >> your
>>> >> machine dies.
>>> >>
>>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>>> >
>>> > I'll try that a bit later today.  Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build.  The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more.  I'll let you know if that fixes
>>> > anything.  Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first.  It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel.  Confused.  Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = _config->fb->base;
>> primary->state->crtc = _crtc->base;
>> +   primary->crtc = _crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = _crtc->base;
>> +   primary->crtc = _crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= 
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
>Hey, that seems to do the trick on the NUC machine.  Boots without
>HDMI connected and there are no backtraces.  Nice!
>
>Let me go and munge it around for a backport on top of -rc5 with the
>rest of the pile and see if both the macbook and NUC machines work
>then.  Will be a bit for it to build.

OK, that helped on all my machines I have.  No backtraces and they all
boot again as I would expect.  For the record, here is what I have on
top of -rc5:

drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch

and this patch:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;

if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+   intel_crtc->base.primary->state->crtc = _crtc->base;
+   intel_crtc->base.primary->crtc = _crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,

drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+   intel_crtc->base.primary->state->crtc = 
_crtc->base;
+   intel_crtc->base.primary->crtc = _crtc->base;
obj->frontbuffer_bits |= 
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}

which is a mash-up of:

"drm/i915: Fix atomic state when reusing the firmware fb"

and

"drm/i915: Fixup legacy plane->crtc link for initial fb config"

which you just sent out.

I think that covers everything.

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter  wrote:
> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer  
>> wrote:
>> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter  wrote:
>> >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter  
>> >>> wrote:
>> >>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter  
>> >>> >> wrote:
>> >>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >>> >> >> >> Author: Damien Lespiau 
>> >>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +
>> >>> >> >> >>
>> >>> >> >> >> drm/i915: Don't try to reference the fb in 
>> >>> >> >> >> get_initial_plane_config()
>> >>> >> >> >>
>> >>> >> >> >> From linux-next?
>> >>> >> >> >
>> >>> >> >> > Yes, building now.  Will let you know as soon as I test it on 
>> >>> >> >> > both machines.
>> >>> >> >>
>> >>> >> >> OK, with that commit applied I no longer get the kref.h splat and 
>> >>> >> >> the
>> >>> >> >> NUC machine boots headless.  I still see the backtrace below on 
>> >>> >> >> both
>> >>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff 
>> >>> >> >> from
>> >>> >> >> the NUC here:
>> >>> >> >>
>> >>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>> >> >>
>> >>> >> >> Getting better at least :).
>> >>> >> >
>> >>> >> > On top of what you currently have please also cherry-pick
>> >>> >> >
>> >>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >>> >> > Author: Damien Lespiau 
>> >>> >> > Date:   Thu Feb 5 19:24:25 2015 +
>> >>> >> >
>> >>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>> >>> >> >
>> >>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>> >>
>> >>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
>> >>> >>
>> >>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >>> >> From: Damien Lespiau 
>> >>> >> Date: Thu, 5 Feb 2015 17:22:18 +
>> >>> >> Subject: drm/i915: Store the initial framebuffer in 
>> >>> >> initial_plane_config
>> >>> >>
>> >>> >> first.  Do you want me to grab both, or should I try and figure out
>> >>> >> how to backport fb9981aa67 without it?
>> >>> >
>> >>> > Oops missed that. The active ingredient is setting 
>> >>> > crtc->primary->state->crtc like this:
>> >>> > -Daniel
>> >>> >
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> >>> > b/drivers/gpu/drm/i915/intel_display.c
>> >>> > index 1c12262029fb..bfc14a6046ea 100644
>> >>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> >>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> >>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc 
>> >>> > *intel_crtc,
>> >>> > return;
>> >>> >
>> >>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> >>> > +   intel_crtc->base.primary->state->crtc = 
>> >>> > _crtc->base;
>> >>> > update_state_fb(intel_crtc->base.primary);
>> >>> > return;
>> >>> > }
>> >>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc 
>> >>> > *intel_crtc,
>> >

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer  
wrote:
> On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter  wrote:
>> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter  wrote:
>>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter  
>>> >> wrote:
>>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>>> >> >> >> Author: Damien Lespiau 
>>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +
>>> >> >> >>
>>> >> >> >> drm/i915: Don't try to reference the fb in 
>>> >> >> >> get_initial_plane_config()
>>> >> >> >>
>>> >> >> >> From linux-next?
>>> >> >> >
>>> >> >> > Yes, building now.  Will let you know as soon as I test it on both 
>>> >> >> > machines.
>>> >> >>
>>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>>> >> >> NUC machine boots headless.  I still see the backtrace below on both
>>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>>> >> >> the NUC here:
>>> >> >>
>>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>> >> >>
>>> >> >> Getting better at least :).
>>> >> >
>>> >> > On top of what you currently have please also cherry-pick
>>> >> >
>>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>>> >> > Author: Damien Lespiau 
>>> >> > Date:   Thu Feb 5 19:24:25 2015 +
>>> >> >
>>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>>> >> >
>>> >> > from -next. Let's hope this terminates eventually ;-)
>>> >>
>>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
>>> >>
>>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>>> >> From: Damien Lespiau 
>>> >> Date: Thu, 5 Feb 2015 17:22:18 +
>>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>> >>
>>> >> first.  Do you want me to grab both, or should I try and figure out
>>> >> how to backport fb9981aa67 without it?
>>> >
>>> > Oops missed that. The active ingredient is setting 
>>> > crtc->primary->state->crtc like this:
>>> > -Daniel
>>> >
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>>> > b/drivers/gpu/drm/i915/intel_display.c
>>> > index 1c12262029fb..bfc14a6046ea 100644
>>> > --- a/drivers/gpu/drm/i915/intel_display.c
>>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> > return;
>>> >
>>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>>> > +   intel_crtc->base.primary->state->crtc = _crtc->base;
>>> > update_state_fb(intel_crtc->base.primary);
>>> > return;
>>> > }
>>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>> >
>>> > drm_framebuffer_reference(c->primary->fb);
>>> > intel_crtc->base.primary->fb = c->primary->fb;
>>> > +   intel_crtc->base.primary->state->crtc = 
>>> > _crtc->base;
>>> > obj->frontbuffer_bits |= 
>>> > INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>>> > break;
>>> > }
>>>
>>> Hm.  So I used your patch above.  The macbook boots fine and all the
>>> oops/WARNS are gone except the audio one that was unrelated and
>>> present before all of this.
>>>
>>> However, the NUC is back to not booting without HDMI plugged in.  I
>>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>>> results up here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>>
>>> The frontbuffer splat is back now.
>>>
>>> I confirmed multiple times that the NUC boots fine with the kernel
>>> that doesn't include the above patch but has the other two included
>>> (albeit with the drm_atomic WARN still).
>>>
>>> Not sure what to make of this one.
>>
>> Yeah that fail looks like we're freeing an fb that's still in use.
>> Hilarity happens and since that happens under console_lock at boot-up your
>> machine dies.
>>
>> Does that machine die the same way in drm-intel-nightly/linux-next?
>
> I'll try that a bit later today.  Out of sheer curiosity, I folded
> commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
> update) into the patch above and kicked off a build.  The theory is
> that we're picking up a bunch of other changes right in that range of
> commits, why not try one more.  I'll let you know if that fixes
> anything.  Otherwise, I'll try building drm-intel-nightly and/or
> linux-next after that.

The drm-intel-nightly build finished first.  It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel.  Confused.  Full log here:

https://jwboyer.fedorapeople.org/pub/intel-nightly.txt

I don't have much hope for my other build.

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter  wrote:
> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter  wrote:
>> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter  wrote:
>> >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> >> Author: Damien Lespiau 
>> >> >> >> Date:   Thu Feb 5 18:30:20 2015 +
>> >> >> >>
>> >> >> >> drm/i915: Don't try to reference the fb in 
>> >> >> >> get_initial_plane_config()
>> >> >> >>
>> >> >> >> From linux-next?
>> >> >> >
>> >> >> > Yes, building now.  Will let you know as soon as I test it on both 
>> >> >> > machines.
>> >> >>
>> >> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> >> NUC machine boots headless.  I still see the backtrace below on both
>> >> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> >> >> the NUC here:
>> >> >>
>> >> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >> >>
>> >> >> Getting better at least :).
>> >> >
>> >> > On top of what you currently have please also cherry-pick
>> >> >
>> >> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> >> > Author: Damien Lespiau 
>> >> > Date:   Thu Feb 5 19:24:25 2015 +
>> >> >
>> >> > drm/i915: Fix atomic state when reusing the firmware fb
>> >> >
>> >> > from -next. Let's hope this terminates eventually ;-)
>> >>
>> >> Hm.  That one doesn't apply cleanly.  I think because it needs:
>> >>
>> >> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> >> From: Damien Lespiau 
>> >> Date: Thu, 5 Feb 2015 17:22:18 +
>> >> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>> >>
>> >> first.  Do you want me to grab both, or should I try and figure out
>> >> how to backport fb9981aa67 without it?
>> >
>> > Oops missed that. The active ingredient is setting 
>> > crtc->primary->state->crtc like this:
>> > -Daniel
>> >
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index 1c12262029fb..bfc14a6046ea 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> > return;
>> >
>> > if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
>> > +   intel_crtc->base.primary->state->crtc = _crtc->base;
>> > update_state_fb(intel_crtc->base.primary);
>> > return;
>> > }
>> > @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> >
>> > drm_framebuffer_reference(c->primary->fb);
>> > intel_crtc->base.primary->fb = c->primary->fb;
>> > +   intel_crtc->base.primary->state->crtc = 
>> > _crtc->base;
>> > obj->frontbuffer_bits |= 
>> > INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> > break;
>> > }
>>
>> Hm.  So I used your patch above.  The macbook boots fine and all the
>> oops/WARNS are gone except the audio one that was unrelated and
>> present before all of this.
>>
>> However, the NUC is back to not booting without HDMI plugged in.  I
>> did the drm.debug=0xff+blacklist/insmod trick again and put the
>> results up here:
>>
>> https://jwboyer.fedorapeople.org/pub/vetters.txt
>>
>> The frontbuffer splat is back now.
>>
>> I confirmed multiple times that the NUC boots fine with the kernel
>> that doesn't include the above patch but has the other two included
>> (albeit with the drm_atomic WARN still).
>>
>> Not sure what to make of this one.
>
> Yeah that fail looks like we're freeing an fb that's still in use.
> Hilarity happens and since that happens under console_lock at boot-up your
> machine dies.
>
> Does that machine die the same way in drm-intel-nightly/linux-next?

I'll try that a bit later today.  Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build.  The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more.  I'll let you know if that fixes
anything.  Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter  wrote:
> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter  wrote:
>> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> >> Author: Damien Lespiau 
>> >> >> Date:   Thu Feb 5 18:30:20 2015 +
>> >> >>
>> >> >> drm/i915: Don't try to reference the fb in 
>> >> >> get_initial_plane_config()
>> >> >>
>> >> >> From linux-next?
>> >> >
>> >> > Yes, building now.  Will let you know as soon as I test it on both 
>> >> > machines.
>> >>
>> >> OK, with that commit applied I no longer get the kref.h splat and the
>> >> NUC machine boots headless.  I still see the backtrace below on both
>> >> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> >> the NUC here:
>> >>
>> >> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> >>
>> >> Getting better at least :).
>> >
>> > On top of what you currently have please also cherry-pick
>> >
>> > commit fb9981aa675eb7b398849915364916fd98833cfa
>> > Author: Damien Lespiau 
>> > Date:   Thu Feb 5 19:24:25 2015 +
>> >
>> > drm/i915: Fix atomic state when reusing the firmware fb
>> >
>> > from -next. Let's hope this terminates eventually ;-)
>>
>> Hm.  That one doesn't apply cleanly.  I think because it needs:
>>
>> From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
>> From: Damien Lespiau 
>> Date: Thu, 5 Feb 2015 17:22:18 +
>> Subject: drm/i915: Store the initial framebuffer in initial_plane_config
>>
>> first.  Do you want me to grab both, or should I try and figure out
>> how to backport fb9981aa67 without it?
>
> Oops missed that. The active ingredient is setting crtc->primary->state->crtc 
> like this:
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1c12262029fb..bfc14a6046ea 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> return;
>
> if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
> +   intel_crtc->base.primary->state->crtc = _crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> +   intel_crtc->base.primary->state->crtc = 
> _crtc->base;
> obj->frontbuffer_bits |= 
> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }

Hm.  So I used your patch above.  The macbook boots fine and all the
oops/WARNS are gone except the audio one that was unrelated and
present before all of this.

However, the NUC is back to not booting without HDMI plugged in.  I
did the drm.debug=0xff+blacklist/insmod trick again and put the
results up here:

https://jwboyer.fedorapeople.org/pub/vetters.txt

The frontbuffer splat is back now.

I confirmed multiple times that the NUC boots fine with the kernel
that doesn't include the above patch but has the other two included
(albeit with the drm_atomic WARN still).

Not sure what to make of this one.

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter  wrote:
>> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
>> >> Author: Damien Lespiau 
>> >> Date:   Thu Feb 5 18:30:20 2015 +
>> >>
>> >> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>> >>
>> >> From linux-next?
>> >
>> > Yes, building now.  Will let you know as soon as I test it on both 
>> > machines.
>>
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless.  I still see the backtrace below on both
>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> the NUC here:
>>
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>>
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau 
> Date:   Thu Feb 5 19:24:25 2015 +
>
> drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)

Hm.  That one doesn't apply cleanly.  I think because it needs:

>From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau 
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in initial_plane_config

first.  Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter  wrote:
> On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> > On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer > > fedoraproject.org> wrote:
>> > > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter  
>> > > wrote:
>> > >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>> > >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer > > >>> fedoraproject.org> wrote:
>> > >>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter  
>> > >>> > wrote:
>> > >>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> > >>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter > > >>> >>> ffwll.ch> wrote:
>> > >>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> > >>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer > > >>> >>> >> fedoraproject.org> wrote:
>> > >>> >>> >>
>> > >>> >>> >> 
>> > >>> >>> >>
>> > >>> >>> >> >> Xi Ruoyao (1):
>> > >>> >>> >> >>   drm/i915: Ensure plane->state->fb stays in sync with 
>> > >>> >>> >> >> plane->fb
>> > >>> >>> >>
>> > >>> >>> >> Turns out to be that commit.
>> > >>> >>> >>
>> > >>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>> > >>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> > >>> >>> >> 'for-linus' of 
>> > >>> >>> >> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> > >>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> > >>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> > >>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> > >>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: 
>> > >>> >>> >> Ensure
>> > >>> >>> >> plane->state->fb stays in sync with plane->fb
>> > >>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> > >>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> > >>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> > >>> >>> >>
>> > >>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work 
>> > >>> >>> >> again,
>> > >>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> > >>> >>> >> there.
>> > >>> >>> >
>> > >>> >>> > Can you please test the tip of drm-fixes:
>> > >>> >>> >
>> > >>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > >>> >>> > Author: Daniel Vetter 
>> > >>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>> > >>> >>> >
>> > >>> >>> > drm: Fixup racy refcounting in plane_force_disable
>> > >>> >>> >
>> > >>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > >>> >>> >
>> > >>> >>> > Because fumble that patch didn't make it to drm-fixes a while 
>> > >>> >>> > ago and
>> > >>> >>> > instead landed in drm-next.
>> > >>> >>>
>> > >>> >>> That seems to have helped with totally different issues a macbook I
>> > >>> >>> have was seeing.  However, it still doesn't fix the issue with the
>> > >>> >>> Celeron based NUC machine.
>> > >>> >>>
>> > >>> >>> I built a kernel based on Linus' latest tr

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer  
wrote:
> On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter  wrote:
>> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer  
>>> wrote:
>>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter  wrote:
>>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter  
>>> >>> wrote:
>>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer >> >>> >> fedoraproject.org> wrote:
>>> >>> >>
>>> >>> >> 
>>> >>> >>
>>> >>> >> >> Xi Ruoyao (1):
>>> >>> >> >>   drm/i915: Ensure plane->state->fb stays in sync with 
>>> >>> >> >> plane->fb
>>> >>> >>
>>> >>> >> Turns out to be that commit.
>>> >>> >>
>>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >>> >> 'for-linus' of 
>>> >>> >> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >>> >> plane->state->fb stays in sync with plane->fb
>>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>> >>
>>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >>> >> there.
>>> >>> >
>>> >>> > Can you please test the tip of drm-fixes:
>>> >>> >
>>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> > Author: Daniel Vetter 
>>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>>> >>> >
>>> >>> > drm: Fixup racy refcounting in plane_force_disable
>>> >>> >
>>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >>> >
>>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> >>> > instead landed in drm-next.
>>> >>>
>>> >>> That seems to have helped with totally different issues a macbook I
>>> >>> have was seeing.  However, it still doesn't fix the issue with the
>>> >>> Celeron based NUC machine.
>>> >>>
>>> >>> I built a kernel based on Linus' latest tree as of this morning,
>>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
>>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
>>> >>> still see the trace below.  If I do the blacklist and then insmod
>>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> >>> which starts with the same backtrace.
>>> >>>
>>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>>> >>> suspect things will work fine with that combination because the two
>>> >>> issues are unrelated.
>>> >>
>>> >> Can you please boot with drm.debug=0xff for the below case and grab
>>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>>> >> blow up the logbuf size massively. But that log should contain everything
>>> >> I need to figure out where that framebuffer we're blowing up on is going.
>>> >
>>> > I provided both with HDMI attached and without (via insmod).  If you
&g

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter  wrote:
> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer  
>> wrote:
>> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter  wrote:
>> >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter  
>> >>> wrote:
>> >>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer > >>> >> fedoraproject.org> wrote:
>> >>> >>
>> >>> >> 
>> >>> >>
>> >>> >> >> Xi Ruoyao (1):
>> >>> >> >>   drm/i915: Ensure plane->state->fb stays in sync with 
>> >>> >> >> plane->fb
>> >>> >>
>> >>> >> Turns out to be that commit.
>> >>> >>
>> >>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >>> >> 'for-linus' of 
>> >>> >> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >>> >> plane->state->fb stays in sync with plane->fb
>> >>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>> >>
>> >>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >>> >> there.
>> >>> >
>> >>> > Can you please test the tip of drm-fixes:
>> >>> >
>> >>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >>> > Author: Daniel Vetter 
>> >>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>> >>> >
>> >>> > drm: Fixup racy refcounting in plane_force_disable
>> >>> >
>> >>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >>> >
>> >>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> >>> > instead landed in drm-next.
>> >>>
>> >>> That seems to have helped with totally different issues a macbook I
>> >>> have was seeing.  However, it still doesn't fix the issue with the
>> >>> Celeron based NUC machine.
>> >>>
>> >>> I built a kernel based on Linus' latest tree as of this morning,
>> >>> without reverting 319c1d4 and adding the commit you pointed to.  The
>> >>> NUC still won't boot without HDMI connected.  With HDMI connected I
>> >>> still see the trace below.  If I do the blacklist and then insmod
>> >>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> >>> which starts with the same backtrace.
>> >>>
>> >>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>> >>> suspect things will work fine with that combination because the two
>> >>> issues are unrelated.
>> >>
>> >> Can you please boot with drm.debug=0xff for the below case and grab
>> >> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> >> blow up the logbuf size massively. But that log should contain everything
>> >> I need to figure out where that framebuffer we're blowing up on is going.
>> >
>> > I provided both with HDMI attached and without (via insmod).  If you
>> > want them emailed directly let me know, but they were large.
>> >
>> > Boot with drm.debug=0xff and HDMI connected:
>> >
>> > https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>> >
>> > Boot with drm.debug=0xff without HDMI connected and i915 loaded via
>> > manual insmod after boot:
>> >
>> > https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
>>
>> Here's one more from the macbook I mentioned.  It's showing the same
>> kref.h splat:
>>
>> https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt
>
> Ok there's at least one fixup for which we've failed to apply when porting
> the fb refcounting fix from -next. Can you please cherry-pick
>
> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
> Author: Damien Lespiau 
> Date:   Thu Feb 5 18:30:20 2015 +
>
> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>
> From linux-next?

Yes, building now.  Will let you know as soon as I test it on both machines.

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer  
wrote:
> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter  wrote:
>> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter  wrote:
>>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer >> >> fedoraproject.org> wrote:
>>> >>
>>> >> 
>>> >>
>>> >> >> Xi Ruoyao (1):
>>> >> >>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Turns out to be that commit.
>>> >>
>>> >> git bisect start 'drivers/gpu/drm/i915/'
>>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>>> >> plane->state->fb stays in sync with plane->fb
>>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>> >>
>>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>>> >> there.
>>> >
>>> > Can you please test the tip of drm-fixes:
>>> >
>>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> > Author: Daniel Vetter 
>>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>>> >
>>> > drm: Fixup racy refcounting in plane_force_disable
>>> >
>>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>>> >
>>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>>> > instead landed in drm-next.
>>>
>>> That seems to have helped with totally different issues a macbook I
>>> have was seeing.  However, it still doesn't fix the issue with the
>>> Celeron based NUC machine.
>>>
>>> I built a kernel based on Linus' latest tree as of this morning,
>>> without reverting 319c1d4 and adding the commit you pointed to.  The
>>> NUC still won't boot without HDMI connected.  With HDMI connected I
>>> still see the trace below.  If I do the blacklist and then insmod
>>> dance with HDMI unplugged it shows the same spew I reported yesterday
>>> which starts with the same backtrace.
>>>
>>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>>> suspect things will work fine with that combination because the two
>>> issues are unrelated.
>>
>> Can you please boot with drm.debug=0xff for the below case and grab
>> complete dmesg? There'll be a lot of crap in the logs, you might need to
>> blow up the logbuf size massively. But that log should contain everything
>> I need to figure out where that framebuffer we're blowing up on is going.
>
> I provided both with HDMI attached and without (via insmod).  If you
> want them emailed directly let me know, but they were large.
>
> Boot with drm.debug=0xff and HDMI connected:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
>
> Boot with drm.debug=0xff without HDMI connected and i915 loaded via
> manual insmod after boot:
>
> https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

Here's one more from the macbook I mentioned.  It's showing the same
kref.h splat:

https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter  wrote:
> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote:
>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter  wrote:
>> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer > >> fedoraproject.org> wrote:
>> >>
>> >> 
>> >>
>> >> >> Xi Ruoyao (1):
>> >> >>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Turns out to be that commit.
>> >>
>> >> git bisect start 'drivers/gpu/drm/i915/'
>> >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> >> plane->state->fb stays in sync with plane->fb
>> >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>> >>
>> >> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> >> there.
>> >
>> > Can you please test the tip of drm-fixes:
>> >
>> > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> > Author: Daniel Vetter 
>> > Date:   Fri Feb 27 12:58:13 2015 +0100
>> >
>> > drm: Fixup racy refcounting in plane_force_disable
>> >
>> > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>> >
>> > Because fumble that patch didn't make it to drm-fixes a while ago and
>> > instead landed in drm-next.
>>
>> That seems to have helped with totally different issues a macbook I
>> have was seeing.  However, it still doesn't fix the issue with the
>> Celeron based NUC machine.
>>
>> I built a kernel based on Linus' latest tree as of this morning,
>> without reverting 319c1d4 and adding the commit you pointed to.  The
>> NUC still won't boot without HDMI connected.  With HDMI connected I
>> still see the trace below.  If I do the blacklist and then insmod
>> dance with HDMI unplugged it shows the same spew I reported yesterday
>> which starts with the same backtrace.
>>
>> I'll try building a kernel with 319c1d4 reverted + your patch.  I
>> suspect things will work fine with that combination because the two
>> issues are unrelated.
>
> Can you please boot with drm.debug=0xff for the below case and grab
> complete dmesg? There'll be a lot of crap in the logs, you might need to
> blow up the logbuf size massively. But that log should contain everything
> I need to figure out where that framebuffer we're blowing up on is going.

I provided both with HDMI attached and without (via insmod).  If you
want them emailed directly let me know, but they were large.

Boot with drm.debug=0xff and HDMI connected:

https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt

Boot with drm.debug=0xff without HDMI connected and i915 loaded via
manual insmod after boot:

https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt

josh

[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter  wrote:
> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer  
>> wrote:
>>
>> 
>>
>> >> Xi Ruoyao (1):
>> >>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Turns out to be that commit.
>>
>> git bisect start 'drivers/gpu/drm/i915/'
>> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
>> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
>> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
>> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
>> plane->state->fb stays in sync with plane->fb
>> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
>> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
>>
>> Doing a straight revert on top of 4.0-rc5 makes things work again,
>> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
>> there.
>
> Can you please test the tip of drm-fixes:
>
> commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
> Author: Daniel Vetter 
> Date:   Fri Feb 27 12:58:13 2015 +0100
>
> drm: Fixup racy refcounting in plane_force_disable
>
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8218c3f4df3bb1c637c17552405039a6dd3c1ee1
>
> Because fumble that patch didn't make it to drm-fixes a while ago and
> instead landed in drm-next.

That seems to have helped with totally different issues a macbook I
have was seeing.  However, it still doesn't fix the issue with the
Celeron based NUC machine.

I built a kernel based on Linus' latest tree as of this morning,
without reverting 319c1d4 and adding the commit you pointed to.  The
NUC still won't boot without HDMI connected.  With HDMI connected I
still see the trace below.  If I do the blacklist and then insmod
dance with HDMI unplugged it shows the same spew I reported yesterday
which starts with the same backtrace.

I'll try building a kernel with 319c1d4 reverted + your patch.  I
suspect things will work fine with that combination because the two
issues are unrelated.

josh

[  +0.27] WARNING: CPU: 1 PID: 144 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.03] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper
drm sdhci_acpi sdhci mmc_core video
[  +0.12] CPU: 1 PID: 144 Comm: systemd-udevd Not tainted
4.0.0-0.rc5.git1.1.fc23.x86_64 #1
[  +0.03] Hardware name:
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.03]   b82c27d6 88003f98f688
8177ada9
[  +0.04]    88003f98f6c8
8109c78a
[  +0.04]  8802345c91a8 880234b0bd80 880234b923c0
88003fae
[  +0.04] Call Trace:
[  +0.10]  [] dump_stack+0x45/0x57
[  +0.05]  [] warn_slowpath_common+0x8a/0xc0
[  +0.04]  [] warn_slowpath_null+0x1a/0x20
[  +0.12]  [] drm_framebuffer_reference+0x7a/0x90 [drm]
[  +0.16]  [] drm_atomic_set_fb_for_plane+0x2d/0x90 [drm]
[  +0.48]  []
i9xx_get_initial_plane_config+0x295/0x3e0 [i915]
[  +0.15]  [] ? drm_modeset_unlock_all+0x36/0x70 [drm]
[  +0.31]  [] intel_modeset_init+0x9f1/0x1a40 [i915]
[  +0.27]  [] ?
valleyview_irq_postinstall+0x3b/0x50 [i915]
[  +0.34]  [] i915_driver_load+0xe5f/0x10f0 [i915]
[  +0.05]  [] ? netlink_broadcast_filtered+0x12b/0x380
[  +0.06]  [] ? kobj_ns_drop+0x50/0x50
[  +0.04]  [] ? kobject_uevent_env+0x178/0x540
[  +0.06]  [] ? devtmpfs_create_node+0x109/0x140
[  +0.04]  [] ? get_device+0x17/0x30
[  +0.05]  [] ? klist_class_dev_get+0x15/0x20
[  +0.05]  [] ? klist_add_tail+0x32/0x40
[  +0.04]  [] ? device_add+0x19f/0x6a0
[  +0.12]  [] drm_dev_register+0xb5/0x110 [drm]
[  +0.11]  [] drm_get_pci_dev+0x8d/0x200 [drm]
[  +0.22]  [] i915_pci_probe+0x3b/0x60 [i915]
[  +0.06]  [] loca

[git pull] drm fixes

[Josh Boyer]

On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer  
wrote:



>> Xi Ruoyao (1):
>>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb

Turns out to be that commit.

git bisect start 'drivers/gpu/drm/i915/'
# good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344
# bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5
git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
# bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure
plane->state->fb stays in sync with plane->fb
git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa
# first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa]
drm/i915: Ensure plane->state->fb stays in sync with plane->fb

Doing a straight revert on top of 4.0-rc5 makes things work again,
albeit with the WARN_ON(obj->frontbuffer_bits) splat still being
there.

josh

> I have a machine that no longer boots in a headless manner with -rc5.
> It's an Celeron based NUC device.  I blacklisted the i915 driver and
> it boots fine, then I ran insmod manually and got the backtrace below.
> This machine only has HDMI output on it.  If I have it connected (even
> if the monitor is set to display some other input) it will boot fine,
> but the backtrace is still present.  I'm going to guess the machine
> "hangs" in headless because X causes some further issues in the
> headless case.
>
> Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:
>
> [  +0.39] WARNING: CPU: 0 PID: 63 at
> drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
> [i915]()
> [  +0.02] WARN_ON(obj->frontbuffer_bits)
>
> which is what I thought one of these commits was supposed to fix.  I
> don't see that in -rc5, but then we have these other issues.
>
> josh
>
> Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:
>
> [  +0.063764] vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [  +0.007099] [ cut here ]
> [  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
> drm_framebuffer_reference+0x7a/0x90 [drm]()
> [  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
> ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
> iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
> bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
> snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
> snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
> fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
> snd_soc_sst_mfld_platform snd_hda_controller
> [  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
> snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
> ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
> ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
> ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
> snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
> rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
> i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
> rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
> sdhci_acpi video sdhci mmc_core
> [  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
> 4.0.0-0.rc5.git0.1.fc23.x86_64 #1
> [  +0.04] Hardware name:
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
> BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
> [  +0.03]   ee312e2f 8800b7e03688
> 8177ac09
> [  +0.04]    8800b7e036c8
> 8109c78a
> [  +0.04

[git pull] drm fixes

[Josh Boyer]

On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie  wrote:
>
> Hi Linus,
>
> a bunch of fixes across drivers,
> radeon: disable two ended allocation for now, it breaks some stuff
> amdkfd: misc fixes
> nouveau: fix irq loop problem, add basic support for GM206 (new hw)
> i915: fix some WARNs people were seeing
> exynos: fix some iommu interactions causing boot failures
>
> In other news I've some problem with my git tree and git request-pull
> [airlied at dreadlord-bne-redhat-com linux]$ git request-pull linus/master 
> origin
> warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at 
> origin
> warn: Are you sure you pushed 'HEAD' there?
>
> is happening when I just had my branch on drm-fixes, I've made it master
> to generate this pull request so the branch name isn't missing, this
> might be due to my attempt to remove my own master branch, using
> git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
> week I suppose.



>
> Damien Lespiau (1):
>   drm/i915: Make sure the primary plane is enabled before reading out the 
> fb state

> Xi Ruoyao (1):
>   drm/i915: Ensure plane->state->fb stays in sync with plane->fb

I have a machine that no longer boots in a headless manner with -rc5.
It's an Celeron based NUC device.  I blacklisted the i915 driver and
it boots fine, then I ran insmod manually and got the backtrace below.
This machine only has HDMI output on it.  If I have it connected (even
if the monitor is set to display some other input) it will boot fine,
but the backtrace is still present.  I'm going to guess the machine
"hangs" in headless because X causes some further issues in the
headless case.

Linux v4.0-rc4-199-gb314acaccd7e gets this splat in the headless state:

[  +0.39] WARNING: CPU: 0 PID: 63 at
drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object+0x2e5/0x320
[i915]()
[  +0.02] WARN_ON(obj->frontbuffer_bits)

which is what I thought one of these commits was supposed to fix.  I
don't see that in -rc5, but then we have these other issues.

josh

Backtrace via 'insmod i915.ko.xz' in headless state with 4.0-rc5:

[  +0.063764] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.007099] [ cut here ]
[  +0.37] WARNING: CPU: 1 PID: 1486 at include/linux/kref.h:47
drm_framebuffer_reference+0x7a/0x90 [drm]()
[  +0.03] Modules linked in: i915(+) ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack bnep iTCO_wdt iTCO_vendor_support
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4
iwlmvm mac80211 intel_rapl coretemp kvm_intel kvm iwlwifi btusb
bluetooth i2c_algo_bit cfg80211 drm_kms_helper crct10dif_pclmul
snd_hda_codec_hdmi crc32_pclmul crc32c_intel ghash_clmulni_intel
snd_hda_codec_realtek vfat snd_hda_codec_generic snd_intel_sst_acpi
fat serio_raw snd_intel_sst_core snd_hda_intel i2c_i801 drm
snd_soc_sst_mfld_platform snd_hda_controller
[  +0.46]  r8169 lpc_ich snd_soc_rt5640 snd_hda_codec mfd_core
snd_soc_rl6231 mii mei_txe ir_lirc_codec ir_xmp_decoder
ir_mce_kbd_decoder lirc_dev snd_soc_core ir_sharp_decoder shpchp
ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder mei ir_rc6_decoder
ir_rc5_decoder ir_nec_decoder snd_compress snd_pcm_dmaengine snd_hwdep
snd_seq snd_seq_device iosf_mbi rc_rc6_mce snd_pcm ite_cir snd_timer
rc_core dw_dmac snd dw_dmac_core regmap_i2c i2c_hid
i2c_designware_platform soundcore rfkill_gpio i2c_designware_core
rfkill snd_soc_sst_acpi nfsd auth_rpcgss nfs_acl lockd grace sunrpc
sdhci_acpi video sdhci mmc_core
[  +0.51] CPU: 1 PID: 1486 Comm: insmod Not tainted
4.0.0-0.rc5.git0.1.fc23.x86_64 #1
[  +0.04] Hardware name:
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
BIOS FYBYT10H.86A.0034.2014.0513.1413 05/13/2014
[  +0.03]   ee312e2f 8800b7e03688
8177ac09
[  +0.04]    8800b7e036c8
8109c78a
[  +0.04]  8800b7e036b8 880234b46d80 880228ef4f00
88021a54
[  +0.05] Call Trace:
[  +0.09]  [] dump_stack+0x45/0x57
[  +0.06]  [] 

[PATCH] drm/vmwgfx: Fix drm.h include

[Josh Boyer]

On Fri, Sep 5, 2014 at 1:19 PM, Josh Boyer  wrote:
> The userspace drm.h include doesn't prefix the drm directory.  This can lead
> to compile failures as /usr/include/drm/ isn't in the standard gcc include
> paths.  Fix it to be , which matches the rest of the driver drm
> header files that get installed into /usr/include/drm.
>
> Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759
>
> Fixes: 1d7a5cbf8f74e
> Reported-by: Jeffrey Bastian 
> Signed-off-by: Josh Boyer 

Ping?  Did this get queued anywhere?

josh

> ---
>  include/uapi/drm/vmwgfx_drm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
> index 4fc66f6b12ce..c472bedbe38e 100644
> --- a/include/uapi/drm/vmwgfx_drm.h
> +++ b/include/uapi/drm/vmwgfx_drm.h
> @@ -29,7 +29,7 @@
>  #define __VMWGFX_DRM_H__
>
>  #ifndef __KERNEL__
> -#include 
> +#include 
>  #endif
>
>  #define DRM_VMW_MAX_SURFACE_FACES 6
> --
> 1.9.3
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm/vmwgfx: Fix drm.h include

[Josh Boyer]

On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov  
wrote:
> Hi Josh
>
> On 05/09/14 18:19, Josh Boyer wrote:
>> The userspace drm.h include doesn't prefix the drm directory.  This can lead
>> to compile failures as /usr/include/drm/ isn't in the standard gcc include
>> paths.  Fix it to be , which matches the rest of the driver drm
>> header files that get installed into /usr/include/drm.
>>
> Is this an actual issue or a hypothetical one ? Afaict no-one is using the
> kernel drm headers, but instead the ones from libdrm are in place.
> linux-headers does not even ship /usr/include/drm on my Archlinux box.

It's shipped in kernel-headers in Fedora and I'm guessing someone hit
it at one point, but I don't know what the actual initial problem was.

> Additionally most (all?) vmwgfx components (mesa, ddx) use a local version of
> the header, which albeit not ideal should not cause issues.
>
> Or perhaps I'm missing something ?
>
>
> To the VMware guys,
>
> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>
> Cheers,
> Emil
>
> P.S. I'm against the patch in any way :)

Was that meant to say "I'm not against the patch in any way" ?

josh

[PATCH] drm/vmwgfx: Fix drm.h include

[Josh Boyer]

The userspace drm.h include doesn't prefix the drm directory.  This can lead
to compile failures as /usr/include/drm/ isn't in the standard gcc include
paths.  Fix it to be , which matches the rest of the driver drm
header files that get installed into /usr/include/drm.

Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759

Fixes: 1d7a5cbf8f74e
Reported-by: Jeffrey Bastian 
Signed-off-by: Josh Boyer 
---
 include/uapi/drm/vmwgfx_drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
index 4fc66f6b12ce..c472bedbe38e 100644
--- a/include/uapi/drm/vmwgfx_drm.h
+++ b/include/uapi/drm/vmwgfx_drm.h
@@ -29,7 +29,7 @@
 #define __VMWGFX_DRM_H__

 #ifndef __KERNEL__
-#include 
+#include 
 #endif

 #define DRM_VMW_MAX_SURFACE_FACES 6
-- 
1.9.3

WARN_ON in qxl_ttm.c with v3.17-rc1-22-g480cadc2b7e0

[Josh Boyer]

Hi Dave,

With Linus' latest tree as of this morning I'm hitting the WARN_ON
below on my KVM guest using the qxl driver.  The guest still boots and
things appear to still be working (I can log in via GDM, etc), so I'm
not sure exactly what the overall issue is.  Hoping you have some
ideas.

josh

[4.826872] [ cut here ]
[4.826886] WARNING: CPU: 0 PID: 232 at
drivers/gpu/drm/qxl/qxl_ttm.c:414 qxl_sync_obj_wait+0x182/0x220
[qxl]()
[4.826889] sync obj 301 still has outstanding releases 0 0 0 4096 1
[4.826890] Modules linked in: btrfs qxl xor drm_kms_helper
raid6_pq ttm drm 8139too virtio_pci virtio_ring virtio 8139cp
ata_generic mii pata_acpi
[4.826907] CPU: 0 PID: 232 Comm: plymouthd Not tainted
3.17.0-0.rc1.git1.1.fc22.x86_64 #1
[4.826909] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[4.826910]   cd82f575 88003a143750
818141eb
[4.826914]  88003a143798 88003a143788 8109fecd
0001
[4.826917]  880035effd18 0001 880035effd30

[4.826921] Call Trace:
[4.826927]  [] dump_stack+0x4d/0x66
[4.826931]  [] warn_slowpath_common+0x7d/0xa0
[4.826934]  [] warn_slowpath_fmt+0x5c/0x80
[4.827019]  [] ? schedule_hrtimeout_range+0x13/0x20
[4.827025]  [] qxl_sync_obj_wait+0x182/0x220 [qxl]
[4.827030]  [] ttm_bo_wait+0xb1/0x1b0 [ttm]
[4.827035]  [] ttm_bo_evict+0x63/0x3b0 [ttm]
[4.827039]  [] ? ttm_mem_evict_first+0x6c/0x1c0 [ttm]
[4.827043]  [] ? mark_held_locks+0x75/0xa0
[4.827047]  [] ? ttm_mem_evict_first+0x12b/0x1c0 [ttm]
[4.827052]  [] ttm_mem_evict_first+0x145/0x1c0 [ttm]
[4.827056]  [] ttm_bo_mem_space+0x268/0x310 [ttm]
[4.827060]  [] ttm_bo_validate+0x23a/0x2f0 [ttm]
[4.827063]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[4.827067]  [] ? print_cpu+0x41d/0xaa0
[4.827071]  [] ttm_bo_init+0x2c1/0x470 [ttm]
[4.827076]  [] qxl_bo_create+0x13f/0x1a0 [qxl]
[4.827080]  [] ? qxl_fbdev_qobj_is_fb+0x30/0x30 [qxl]
[4.827084]  [] qxl_alloc_bo_reserved+0x46/0xc0 [qxl]
[4.827088]  [] qxl_image_alloc_objects+0xae/0x140 [qxl]
[4.827092]  [] qxl_draw_dirty_fb+0x15a/0x470 [qxl]
[4.827104]  [] ?
drm_modeset_lock_all_crtcs+0x49/0x70 [drm]
[4.827108]  []
qxl_framebuffer_surface_dirty+0xa1/0xf0 [qxl]
[4.827117]  [] drm_mode_dirtyfb_ioctl+0xbe/0x160 [drm]
[4.827124]  [] drm_ioctl+0x1ec/0x660 [drm]
[4.827129]  [] ? inode_has_perm.isra.52+0x53/0x80
[4.827132]  [] do_vfs_ioctl+0x300/0x520
[4.827135]  [] SyS_ioctl+0x81/0xa0
[4.827138]  [] system_call_fastpath+0x16/0x1b
[4.827140] ---[ end trace fd5e51032668621b ]---
[4.827144] [TTM] Failed to expire sync object before buffer eviction
[4.827330] qxl :00:02.0: object_init failed for (3149824, 0x0001)
[4.827333] [drm:qxl_alloc_bo_reserved] *ERROR* failed to allocate VRAM BO

3.13 i915 brightness settings broken when going from docked -> undocked

[Josh Boyer]

On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote:
>On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer  
>wrote:
>> Hi All,
>>
>> We've had a rather weird report[1] of the brightness adjustments being
>> broken in a specific case with Thinkpad x220 hardware (SandyBridge
>> based).  If you boot the machine with it in a dock and then undock,
>> the brightness adjustments do not work.  That is with either the FN
>> keys or the GNOME brightness slider.
>>
>> I can see that the value of
>> /sys/class/backlight/acpi_video0/brightness increases/decreases but
>> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
>> changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
>> (specifically, it starts working around v3.13-10231-g53d8ab2 which is
>> right after the first DRM merge for 3.14).  With 3.13, if I undock and
>> echo a higher value in the intel_backlight_brightness sysfs entry, the
>> brightness will actually increase so it can be done manually, but it
>> does not work as you'd expect.
>>
>> I'm in the middle of trying to do a reverse bisect for which patch
>> fixes it in the 3.14-rcX series, but that's taking a while.  I thought
>> I'd email and see if anyone already knows about this situation, what
>> patch in 3.13 broke this, and which one then fixed it again.  Thus far
>> all I've gathered is that backlight handling is confusing.
>
>The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
>either because I messed it up or there's a combination of things that
>fix the issue.  So instead I did a regular git bisect between 3.12 and
>3.13 to see which commit _broke_ things and caused the above behavior.
> That landed me at:
>
>Author: Jesse Barnes 
>Date:   Thu Oct 31 18:55:49 2013 +0200
>
>drm/i915: make backlight functions take a connector
>
>I have no idea if that makes sense or not, but it's at least something
>that seems to be in a relevant area of code.  Does anyone involved in
>that know why it would cause the above symptoms on 3.13, and which
>commit(s) fix it in 3.14-rc1?

Since nobody is replying I poked around a bit myself.  The one commit
that looks somewhat relevant in 3.14-rc1 seems to be:

commit c91c9f32843a1b433de5a1ead4789a6bc8d3d914
Author: Jani Nikula 
Date:   Fri Nov 8 16:48:55 2013 +0200

drm/i915: make asle notifications update backlight on all connectors

That doesn't apply cleanly on 3.13 because of the other reworks that
went in first, so I came up with the patch below.  It seems to fix it
for my machine, but I'm waiting for confirmation from the original bug
reporter still.  Maybe this will elicit some comments?

josh

Backport of upstream commit c91c9f328

---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
 drivers/gpu/drm/i915/intel_panel.c|  4 
 3 files changed, 11 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 221ac62..d6d4349 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {

/* backlight */
struct {
+   bool present;
int level;
bool enabled;
spinlock_t lock; /* bl registers and the above bl fields */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 6d69a9b..b2a51ae 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
return ASLC_BACKLIGHT_FAILED;

mutex_lock(>mode_config.mutex);
-   /*
-* Could match the OpRegion connector here instead, but we'd also need
-* to verify the connector could handle a backlight call.
-*/
-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   if (encoder->crtc == crtc) {
-   found = true;
-   break;
-   }
-
-   if (!found) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
-   }

-   list_for_each_entry(connector, >mode_config.connector_list, head)
-   if (connector->encoder == encoder)
-   intel_connector = to_intel_connector(connector);
-
-   if (!intel_connector) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
+   DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
+   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   if (dev_priv->backlight.prese

3.13 i915 brightness settings broken when going from docked -> undocked

[Josh Boyer]

On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer  
wrote:
> Hi All,
>
> We've had a rather weird report[1] of the brightness adjustments being
> broken in a specific case with Thinkpad x220 hardware (SandyBridge
> based).  If you boot the machine with it in a dock and then undock,
> the brightness adjustments do not work.  That is with either the FN
> keys or the GNOME brightness slider.
>
> I can see that the value of
> /sys/class/backlight/acpi_video0/brightness increases/decreases but
> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
> changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
> (specifically, it starts working around v3.13-10231-g53d8ab2 which is
> right after the first DRM merge for 3.14).  With 3.13, if I undock and
> echo a higher value in the intel_backlight_brightness sysfs entry, the
> brightness will actually increase so it can be done manually, but it
> does not work as you'd expect.
>
> I'm in the middle of trying to do a reverse bisect for which patch
> fixes it in the 3.14-rcX series, but that's taking a while.  I thought
> I'd email and see if anyone already knows about this situation, what
> patch in 3.13 broke this, and which one then fixed it again.  Thus far
> all I've gathered is that backlight handling is confusing.

The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
either because I messed it up or there's a combination of things that
fix the issue.  So instead I did a regular git bisect between 3.12 and
3.13 to see which commit _broke_ things and caused the above behavior.
 That landed me at:

Author: Jesse Barnes 
Date:   Thu Oct 31 18:55:49 2013 +0200

drm/i915: make backlight functions take a connector

I have no idea if that makes sense or not, but it's at least something
that seems to be in a relevant area of code.  Does anyone involved in
that know why it would cause the above symptoms on 3.13, and which
commit(s) fix it in 3.14-rc1?

josh

[PATCH 1/1] drm/exynos: Fix build error in exynos_hdmi.c

[Josh Boyer]

On Fri, Jan 31, 2014 at 1:09 AM, Sachin Kamat  
wrote:
> 'hdmi_infoframe' is already defined in include/linux/hdmi.h.
> Rename the local variable to avoid the following build error:
> drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe' defined 
> as wrong kind of tag
>  struct hdmi_infoframe {
>
> Signed-off-by: Sachin Kamat 
> Reported-by: Josh Boyer 

This does fix the build error I saw.  I don't have hardware to test
the results with, but it now compiles correctly.  Thanks for the quick
turn around!

josh

> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a0e10ae..0d4407c 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -379,7 +379,7 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] 
> = {
> },
>  };
>
> -struct hdmi_infoframe {
> +struct hdmi_frameinfo {
> enum HDMI_PACKET_TYPE type;
> u8 ver;
> u8 len;
> @@ -682,7 +682,7 @@ static u8 hdmi_chksum(struct hdmi_context *hdata,
>  }
>
>  static void hdmi_reg_infoframe(struct hdmi_context *hdata,
> -   struct hdmi_infoframe *infoframe)
> +   struct hdmi_frameinfo *infoframe)
>  {
> u32 hdr_sum;
> u8 chksum;
> @@ -985,7 +985,7 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
>
>  static void hdmi_conf_init(struct hdmi_context *hdata)
>  {
> -   struct hdmi_infoframe infoframe;
> +   struct hdmi_frameinfo infoframe;
>
> /* disable HPD interrupts from HDMI IP block, use GPIO instead */
> hdmi_reg_writemask(hdata, HDMI_INTC_CON, 0, HDMI_INTC_EN_GLOBAL |
> --
> 1.7.9.5
>

kernfs oops with i915+i2c_core in 3.14 merge window

[Josh Boyer]

On Thu, Jan 30, 2014 at 2:20 PM, Josh Boyer  
wrote:
> On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo  wrote:
>> On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
>>> Hi All,
>>>
>>> I'm seeing the oops below on my MacBookPro 10,2 machine using i915
>>> graphics.  It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
>>> but we seem to have one report[1] of this happening well before that,
>>> in v3.13-3260-g03d11a0 as well.  Does anyone have a clue what is going
>>> on here?
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1055105
>>
>> Should be fixed by the following patch which is already queued.
>>
>>  http://lkml.kernel.org/g/20140129170403.GJ30842 at htj.dyndns.org
>
> Oh, excellent!  I'll throw that into a build and test it here.  Thanks
> for the quick reply, Tejun.

FWIW, my test build with that patch does seem to solve the problem.
Thanks again.

josh

kernfs oops with i915+i2c_core in 3.14 merge window

[Josh Boyer]

On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo  wrote:
> On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
>> Hi All,
>>
>> I'm seeing the oops below on my MacBookPro 10,2 machine using i915
>> graphics.  It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
>> but we seem to have one report[1] of this happening well before that,
>> in v3.13-3260-g03d11a0 as well.  Does anyone have a clue what is going
>> on here?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1055105
>
> Should be fixed by the following patch which is already queued.
>
>  http://lkml.kernel.org/g/20140129170403.GJ30842 at htj.dyndns.org

Oh, excellent!  I'll throw that into a build and test it here.  Thanks
for the quick reply, Tejun.

josh

kernfs oops with i915+i2c_core in 3.14 merge window

[Josh Boyer]

Hi All,

I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics.  It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
but we seem to have one report[1] of this happening well before that,
in v3.13-3260-g03d11a0 as well.  Does anyone have a clue what is going
on here?

https://bugzilla.redhat.com/show_bug.cgi?id=1055105

josh

[6.058198] INFO: trying to register non-static key.
[6.058203] the code is fine but needs lockdep annotation.
[6.058206] turning off the locking correctness validator.
[6.058210] CPU: 2 PID: 225 Comm: systemd-udevd Not tainted
3.14.0-0.rc0.git17.1.fc21.x86_64 #1
[6.058214] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
MBP102.88Z.0106.B03.1211161133 11/16/2012
[6.058219]   8b5190d0 88025cc67460
817cdb1f
[6.058225]  0002 88025cc67470 817c8aa9
88025cc67550
[6.058230]  810fa886 0002 88025cc66000
88025cc67500
[6.058236] Call Trace:
[6.058242]  [] dump_stack+0x4d/0x66
[6.058247]  [] register_lock_class.part.26+0x38/0x3c
[6.058253]  [] __lock_acquire+0x1776/0x1c40
[6.058258]  [] ? mark_held_locks+0xb9/0x140
[6.058262]  [] ? __raw_spin_lock_init+0x21/0x60
[6.058267]  [] ? lockdep_init_map+0xac/0x4a0
[6.058271]  [] lock_acquire+0xa2/0x1d0
[6.058275]  [] ? kernfs_addrm_finish+0x38/0x60
[6.058279]  [] kernfs_deactivate+0x13e/0x1a0
[6.058283]  [] ? kernfs_addrm_finish+0x38/0x60
[6.058287]  [] ? mark_held_locks+0xb9/0x140
[6.058291]  [] ? mark_held_locks+0xb9/0x140
[6.058295]  [] kernfs_addrm_finish+0x38/0x60
[6.058299]  [] kernfs_remove_by_name_ns+0x60/0xc0
[6.058304]  [] remove_files.isra.1+0x41/0x80
[6.058308]  [] sysfs_remove_group+0x47/0xa0
[6.058312]  [] sysfs_remove_groups+0x33/0x50
[6.058318]  [] device_remove_attrs+0x5e/0x80
[6.058322]  [] device_del+0x12e/0x1d0
[6.058325]  [] device_unregister+0x1e/0x60
[6.058331]  [] i2c_del_adapter+0x267/0x3b0 [i2c_core]
[6.058354]  [] intel_sdvo_init+0x20e/0x8c0 [i915]
[6.058359]  [] ? trace_hardirqs_on_caller+0x105/0x1d0
[6.058363]  [] ? trace_hardirqs_on+0xd/0x10
[6.058381]  [] ? gen6_read32+0x52/0x1c0 [i915]
[6.058398]  [] intel_modeset_init+0xb62/0xff0 [i915]
[6.058414]  [] ?
intel_power_domains_init_hw+0xa8/0x110 [i915]
[6.058429]  [] i915_driver_load+0xccc/0xec0 [i915]
[6.058440]  [] ? drm_get_minor+0x1ad/0x200 [drm]
[6.058447]  [] drm_dev_register+0x7d/0x180 [drm]
[6.058455]  [] drm_get_pci_dev+0xa0/0x220 [drm]
[6.058468]  [] i915_pci_probe+0x3b/0x60 [i915]
[6.058473]  [] local_pci_probe+0x45/0xa0
[6.058477]  [] ? pci_match_device+0xc5/0xd0
[6.058481]  [] pci_device_probe+0xf9/0x150
[6.058486]  [] driver_probe_device+0x125/0x3a0
[6.058490]  [] __driver_attach+0x93/0xa0
[6.058494]  [] ? __device_attach+0x40/0x40
[6.058498]  [] bus_for_each_dev+0x73/0xc0
[6.058502]  [] driver_attach+0x1e/0x20
[6.058505]  [] bus_add_driver+0x188/0x260
[6.058509]  [] ? 0xa0153fff
[6.058513]  [] driver_register+0x64/0xf0
[6.058516]  [] ? 0xa0153fff
[6.058520]  [] __pci_register_driver+0x60/0x70
[6.058527]  [] drm_pci_init+0x11a/0x130 [drm]
[6.058531]  [] ? 0xa0153fff
[6.058543]  [] i915_init+0x6a/0x6c [i915]
[6.058548]  [] do_one_initcall+0xfa/0x1b0
[6.058552]  [] ? set_memory_nx+0x43/0x50
[6.058557]  [] load_module+0x1eb3/0x26e0
[6.058560]  [] ? store_uevent+0x70/0x70
[6.058565]  [] ? kernel_read+0x50/0x80
[6.058569]  [] SyS_finit_module+0xa6/0xd0
[6.058574]  [] system_call_fastpath+0x16/0x1b

exynos_hdmi.c fails to build with v3.13-10094-g9b0cd30

[Josh Boyer]

Hi All,

After the DRM merge, the exynos_hdmi.c file fails to build with our
ARM config.  The error is:

drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe'
defined as wrong kind of tag
 struct hdmi_infoframe {
^
make[4]: *** [drivers/gpu/drm/exynos/exynos_hdmi.o] Error 1
make[3]: *** [drivers/gpu/drm/exynos] Error 2
make[2]: *** [drivers/gpu/drm] Error 2

which to me was a somewhat confusing error message.  After digging
further, I believe it means that there is a conflict with the
definition in exynos_hdmi.c and the one found in include/linux/hdmi.h
for what hdmi_infoframe is supposed to be.

exynos_hdmi.c:

struct hdmi_infoframe {
enum HDMI_PACKET_TYPE type;
u8 ver;
u8 len;
};


include/linux/hdmi.h:

union hdmi_infoframe {
struct hdmi_any_infoframe any;
struct hdmi_avi_infoframe avi;
struct hdmi_spd_infoframe spd;
union hdmi_vendor_any_infoframe vendor;
struct hdmi_audio_infoframe audio;
};


Could someone take a look at this?  I have no idea how this wasn't
caught before being merged.

josh

Radeon crash with v3.13-rc3-157-g17b2112

[Josh Boyer]

On Tue, Dec 10, 2013 at 5:24 PM, Josh Boyer  
wrote:
> On Tue, Dec 10, 2013 at 5:07 PM, Deucher, Alexander
>  wrote:
>>> -Original Message-
>>> From: jwboyer at gmail.com [mailto:jwboyer at gmail.com] On Behalf Of Josh
>>> Boyer
>>> Sent: Tuesday, December 10, 2013 5:04 PM
>>> To: Deucher, Alexander; Guenter Roeck; Dave Airlie
>>> Cc: Linux-Kernel at Vger. Kernel. Org; DRI mailing list; Linus Torvalds
>>> Subject: Radeon crash with v3.13-rc3-157-g17b2112
>>>
>>> Hi All,
>>>
>>> Booting today's rawhide kernel fails on my Dell XPS 8300 machine.  I
>>> added nomodeset to the command line because it seemed to glitch out
>>> when doing the handoff to the radeon driver and that let me boot far
>>> enough to start networking.  I then loaded the radeon driver with:
>>> modprobe radeon modeset=1 and was greeted with the backtrace below.
>>>
>>> I haven't done a bisect yet, but I can if needs be.  I was hoping this
>>> would trigger someone's memory.  Plain 3.13-rc3 works, so it's
>>> something in the DRM merge that Linus did after -rc3.  Given the
>>> backtrace, this one might be suspect:
>>>
>>> commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d
>>> Author: Guenter Roeck 
>>> Date:   Fri Nov 22 21:52:00 2013 -0800
>>>
>>> drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
>>>
>>
>> Should be fixed by the patch in:
>> https://bugs.freedesktop.org/show_bug.cgi?id=72457
>
> OK.  I'll give that a spin soon.  Thanks for the quick reply!

Yep, that seems to have fixed the crash.  I've added it to rawhide.  Thanks!

josh

Radeon crash with v3.13-rc3-157-g17b2112

[Josh Boyer]

On Tue, Dec 10, 2013 at 5:07 PM, Deucher, Alexander
 wrote:
>> -Original Message-
>> From: jwboyer at gmail.com [mailto:jwboyer at gmail.com] On Behalf Of Josh
>> Boyer
>> Sent: Tuesday, December 10, 2013 5:04 PM
>> To: Deucher, Alexander; Guenter Roeck; Dave Airlie
>> Cc: Linux-Kernel at Vger. Kernel. Org; DRI mailing list; Linus Torvalds
>> Subject: Radeon crash with v3.13-rc3-157-g17b2112
>>
>> Hi All,
>>
>> Booting today's rawhide kernel fails on my Dell XPS 8300 machine.  I
>> added nomodeset to the command line because it seemed to glitch out
>> when doing the handoff to the radeon driver and that let me boot far
>> enough to start networking.  I then loaded the radeon driver with:
>> modprobe radeon modeset=1 and was greeted with the backtrace below.
>>
>> I haven't done a bisect yet, but I can if needs be.  I was hoping this
>> would trigger someone's memory.  Plain 3.13-rc3 works, so it's
>> something in the DRM merge that Linus did after -rc3.  Given the
>> backtrace, this one might be suspect:
>>
>> commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d
>> Author: Guenter Roeck 
>> Date:   Fri Nov 22 21:52:00 2013 -0800
>>
>> drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
>>
>
> Should be fixed by the patch in:
> https://bugs.freedesktop.org/show_bug.cgi?id=72457

OK.  I'll give that a spin soon.  Thanks for the quick reply!

josh

Radeon crash with v3.13-rc3-157-g17b2112

[Josh Boyer]

Hi All,

Booting today's rawhide kernel fails on my Dell XPS 8300 machine.  I
added nomodeset to the command line because it seemed to glitch out
when doing the handoff to the radeon driver and that let me boot far
enough to start networking.  I then loaded the radeon driver with:
modprobe radeon modeset=1 and was greeted with the backtrace below.

I haven't done a bisect yet, but I can if needs be.  I was hoping this
would trigger someone's memory.  Plain 3.13-rc3 works, so it's
something in the DRM merge that Linus did after -rc3.  Given the
backtrace, this one might be suspect:

commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d
Author: Guenter Roeck 
Date:   Fri Nov 22 21:52:00 2013 -0800

drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups

josh

[  105.179966] [drm] radeon kernel modesetting enabled.
[  105.202044] checking generic (d000 5b) vs hw (d000 1000)
[  105.202046] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver
[  105.224345] Console: switching to colour dummy device 80x25
[  105.237823] [drm] initializing kernel modesetting (CAICOS
0x1002:0x6779 0x1B0A:0x909D).
[  105.237931] [drm] register mmio base: 0xFE62
[  105.237934] [drm] register mmio size: 131072
[  105.238185] ATOM BIOS: DeLL
[  105.238929] radeon :01:00.0: VRAM: 1024M 0x -
0x3FFF (1024M used)
[  105.238935] radeon :01:00.0: GTT: 1024M 0x4000 -
0x7FFF
[  105.238939] [drm] Detected VRAM RAM=1024M, BAR=256M
[  105.238944] [drm] RAM width 64bits DDR
[  105.241655] [TTM] Zone  kernel: Available graphics memory: 6130458 kiB
[  105.241659] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[  105.241662] [TTM] Initializing pool allocator
[  105.242085] [TTM] Initializing DMA pool allocator
[  105.243633] [drm] radeon: 1024M of VRAM memory ready
[  105.243678] [drm] radeon: 1024M of GTT memory ready.
[  105.287598] [drm] GART: num cpu pages 262144, num gpu pages 262144
[  105.289406] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[  105.297354] [drm] Loading CAICOS Microcode
[  105.332526] [drm] PCIE GART of 1024M enabled (table at 0x00273000).
[  105.334094] radeon :01:00.0: WB enabled
[  105.334100] radeon :01:00.0: fence driver on ring 0 use gpu
addr 0x4c00 and cpu addr 0x8803001ebc00
[  105.334105] radeon :01:00.0: fence driver on ring 3 use gpu
addr 0x4c0c and cpu addr 0x8803001ebc0c
[  105.345578] radeon :01:00.0: fence driver on ring 5 use gpu
addr 0x00072118 and cpu addr 0xc90012d32118
[  105.345640] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[  105.345643] [drm] Driver supports precise vblank timestamp query.
[  105.345942] radeon :01:00.0: irq 48 for MSI/MSI-X
[  105.346091] radeon :01:00.0: radeon: using MSI.
[  105.346782] [drm] radeon: irq initialized.
[  105.401411] [drm] ring test on 0 succeeded in 2 usecs
[  105.401478] [drm] ring test on 3 succeeded in 1 usecs
[  105.589796] [drm] ring test on 5 succeeded in 2 usecs
[  105.589806] [drm] UVD initialized successfully.
[  105.622555] [drm] Enabling audio 0 support
[  105.622899] [drm] ib test on ring 0 succeeded in 0 usecs
[  105.622954] ALSA sound/pci/hda/hda_eld.c:684 HDMI ATI/AMD: no
speaker allocation for ELD
[  105.623115] [drm] ib test on ring 3 succeeded in 0 usecs
[  105.776249] [drm] ib test on ring 5 succeeded
[  105.839096] [drm] Radeon Display Connectors
[  105.839100] [drm] Connector 0:
[  105.839102] [drm]   HDMI-A-1
[  105.839104] [drm]   HPD2
[  105.839106] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468
0x646c 0x646c
[  105.839109] [drm]   Encoders:
[  105.839111] [drm] DFP1: INTERNAL_UNIPHY1
[  105.839113] [drm] Connector 1:
[  105.839114] [drm]   DVI-D-1
[  105.839116] [drm]   HPD4
[  105.839118] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458
0x645c 0x645c
[  105.839121] [drm]   Encoders:
[  105.839123] [drm] DFP2: INTERNAL_UNIPHY
[  105.839124] [drm] Connector 2:
[  105.839126] [drm]   VGA-1
[  105.839128] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438
0x643c 0x643c
[  105.839131] [drm]   Encoders:
[  105.839133] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[  105.839439] [drm] Internal thermal controller with fan control
[  105.840309] BUG: unable to handle kernel paging request at 0001211f
[  105.840316] IP: []
hwmon_attributes_visible+0x1d/0x50 [radeon]
[  105.840342] PGD 319c07067 PUD 0
[  105.840346] Oops:  [#1] SMP
[  105.840349] Modules linked in: radeon(+) ipt_MASQUERADE iptable_nat
nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc
ebtable_nat ebtables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_intel x86_pkg_temp_thermal arc4 brcmsmac cordic brcmutil
snd_hda_codec coretemp b43 kvm_intel snd_hwdep snd_seq kvm

DRM_TEGRA not buildable as a module

[Josh Boyer]

On Mon, Nov 18, 2013 at 4:10 AM, Thierry Reding  wrote:
> On Sat, Nov 16, 2013 at 03:25:09PM +0100, Josh Boyer wrote:
>> Hi All,
>>
>> The commit below seems to have made the Tegra DRM driver a bool option
>> instead of tristate:
>>
>> commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9
>> Author: Thierry Reding 
>> Date:   Wed Oct 9 10:32:49 2013 +0200
>>
>> drm/tegra: Move driver to DRM tree
>>
>> In order to make subsystem-wide changes easier, move the Tegra DRM
>> driver back into the DRM tree.
>>
>> Signed-off-by: Thierry Reding 
>>
>> That means you can't build the driver as a module.  Was this intended?
>>  The changelog doesn't mention anything about that and the existing
>> help text on the option seems to imply it should be buildable as a
>> module.
>
> This was intended yes. And it wasn't really a change at all, since prior
> to the commit you mention above the DRM driver was always built into the
> host1x driver. That's why I didn't think it necessary to mention it in
> the commit message.
>
> I have some patches queued for 3.14 to enable the driver to be built as
> a module. There are some dependencies such as symbols that need to be
> exported so that the modules can be linked, so it'll require some amount
> of coordination to make that work out within one release cycle, but I'm
> hopeful that we can do it.

OK.  Thanks for the detailed reply.

josh

DRM_TEGRA not buildable as a module

[Josh Boyer]

Hi All,

The commit below seems to have made the Tegra DRM driver a bool option
instead of tristate:

commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9
Author: Thierry Reding 
Date:   Wed Oct 9 10:32:49 2013 +0200

drm/tegra: Move driver to DRM tree

In order to make subsystem-wide changes easier, move the Tegra DRM
driver back into the DRM tree.

Signed-off-by: Thierry Reding 

That means you can't build the driver as a module.  Was this intended?
 The changelog doesn't mention anything about that and the existing
help text on the option seems to imply it should be buildable as a
module.

josh

[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""

[Josh Boyer]

On Thu, Oct 31, 2013 at 1:01 PM, Jani Nikula
 wrote:
> On Thu, 31 Oct 2013, Josh Boyer  wrote:
>> On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula
>>  wrote:
>>> On Fri, 25 Oct 2013, Joseph Salisbury  
>>> wrote:
>>>> On 10/16/2013 05:02 PM, Daniel Vetter wrote:
>>>>> It's by far not that simple. Jani is working on both the underlying bug
>>>>> and a better w/a. See
>>>>>
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=59841
>>>>>
>>>>> for the full story in its entire glory.
>>>>>
>>>>> Cheers, Daniel
>>>>
>>>> Thanks for the feedback, Daniel.  Is there an estimate on what mainline
>>>> release might contain Jani's work?
>>>
>>> commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
>>> Author: Jani Nikula 
>>> Date:   Mon Oct 21 10:52:07 2013 +0300
>>>
>>> drm/i915/dp: workaround BIOS eDP bpp clamping issue
>>>
>>> and a couple of dependencies are now in Linus' tree, i.e. should be
>>> released in 3.12. The commits are also CC: stable.
>>
>> Are the dependency commits you mentioned these?
>
> Yes; sorry for not mentioning them explicitly.

No problem.  Thanks for confirming.

josh

[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""

[Josh Boyer]

On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula
 wrote:
> On Fri, 25 Oct 2013, Joseph Salisbury  
> wrote:
>> On 10/16/2013 05:02 PM, Daniel Vetter wrote:
>>> It's by far not that simple. Jani is working on both the underlying bug
>>> and a better w/a. See
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=59841
>>>
>>> for the full story in its entire glory.
>>>
>>> Cheers, Daniel
>>
>> Thanks for the feedback, Daniel.  Is there an estimate on what mainline
>> release might contain Jani's work?
>
> commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
> Author: Jani Nikula 
> Date:   Mon Oct 21 10:52:07 2013 +0300
>
> drm/i915/dp: workaround BIOS eDP bpp clamping issue
>
> and a couple of dependencies are now in Linus' tree, i.e. should be
> released in 3.12. The commits are also CC: stable.

Are the dependency commits you mentioned these?

commit 7195a50b5c7e00cc3312934fd022c3006b533d12
Author: Ville Syrj?l? 
Date:   Tue Sep 24 14:24:05 2013 +0300

drm/i915: Add HSW CRT output readout support

commit 4f56d12ebb28fceac4c6e60c8993fbfc122e1399
Author: Ville Syrj?l? 
Date:   Mon Oct 21 10:52:06 2013 +0300

drm/i915: Add support for pipe_bpp readout

josh

Re: [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
 v5:
 1 Introduce video.use_native_backlight module parameter and set its
   value to false by default as suggested by Rafael. For Win8 systems
   which have broken ACPI video backlight control, the parameter can be
   set to 1 in kernel cmdline to skip registering ACPI video's backlight
   interface. Due to this change, the acpi_video_verify_backlight_support
   is moved from video_detect.c to video.c - patch 3/4;

That's a fairly untenable position for distro kernels to be in.  They
now have to ask every user that reports an issue with the backlight to
try setting that option on the command line.  While I appreciate the
setting breaks things for some people, doesn't the Win8 issue impact
far more people?  Shouldn't it be defaulted to true?

If nothing else, can you add a config option for the default so
distros can use that to decide which way to default it and then work
on fixing the remaining users that have troubles?

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 6:10 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
 On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
  v5:
  1 Introduce video.use_native_backlight module parameter and set its
value to false by default as suggested by Rafael. For Win8 systems
which have broken ACPI video backlight control, the parameter can be
set to 1 in kernel cmdline to skip registering ACPI video's backlight
interface. Due to this change, the acpi_video_verify_backlight_support
is moved from video_detect.c to video.c - patch 3/4;

 That's a fairly untenable position for distro kernels to be in.  They
 now have to ask every user that reports an issue with the backlight to
 try setting that option on the command line.  While I appreciate the
 setting breaks things for some people, doesn't the Win8 issue impact
 far more people?  Shouldn't it be defaulted to true?

 Well, we have a rule in the kernel not to introduce regressions for users even
 if they are minority.

 If nothing else, can you add a config option for the default so
 distros can use that to decide which way to default it and then work
 on fixing the remaining users that have troubles?

 The current plan is to create a blacklist of systems where that option should
 be set.  We actually already have one, but it is at the _OSI() level, which
 is overkill in my view and may affect things beyond backlight.  Along with 
 that
 we will debug systems where setting that option (to true) causes problems to
 happen, so that we'll be able to drop it going forward (hopefully).

 Of course, distro kernels may always change the default to true if they want.

They can, but they'd need to either patch the kernel to do so, or code
it in userspace bootloader configs.  Having a config option they can
set to change the default makes it reasonable and contained within the
kernel.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 4:27 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Friday, October 11, 2013 06:01:43 PM Josh Boyer wrote:
 On Fri, Oct 11, 2013 at 6:10 PM, Rafael J. Wysocki r...@rjwysocki.net 
 wrote:
  On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
  On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
   v5:
   1 Introduce video.use_native_backlight module parameter and set its
 value to false by default as suggested by Rafael. For Win8 systems
 which have broken ACPI video backlight control, the parameter can be
 set to 1 in kernel cmdline to skip registering ACPI video's backlight
 interface. Due to this change, the acpi_video_verify_backlight_support
 is moved from video_detect.c to video.c - patch 3/4;
 
  That's a fairly untenable position for distro kernels to be in.  They
  now have to ask every user that reports an issue with the backlight to
  try setting that option on the command line.  While I appreciate the
  setting breaks things for some people, doesn't the Win8 issue impact
  far more people?  Shouldn't it be defaulted to true?
 
  Well, we have a rule in the kernel not to introduce regressions for users 
  even
  if they are minority.
 
  If nothing else, can you add a config option for the default so
  distros can use that to decide which way to default it and then work
  on fixing the remaining users that have troubles?
 
  The current plan is to create a blacklist of systems where that option 
  should
  be set.  We actually already have one, but it is at the _OSI() level, which
  is overkill in my view and may affect things beyond backlight.  Along with 
  that
  we will debug systems where setting that option (to true) causes problems 
  to
  happen, so that we'll be able to drop it going forward (hopefully).
 
  Of course, distro kernels may always change the default to true if they 
  want.

 They can, but they'd need to either patch the kernel to do so, or code
 it in userspace bootloader configs.  Having a config option they can
 set to change the default makes it reasonable and contained within the
 kernel.

 If we are to use a Kconfig option, why don't we use one instead of rather than
 in addition to a command line option?  Say, we have
 CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
 the previous version of the Aaron's patchset (the one without
 video.use_native_backlight)?

 Opinions?

If you only have a config option, users can't override the distro
settings.  If you simply have a config option for the default value,
the distros can set it without having to carry a patch (the primary
benefit), but users can still override that without having to rebuild
a kernel.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/4] Fix Win8 backlight issue

[Josh Boyer]

On Fri, Oct 11, 2013 at 11:00 PM, Yves-Alexis Perez cor...@debian.org wrote:
 On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
 On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
  On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
   v5:
   1 Introduce video.use_native_backlight module parameter and set its
 value to false by default as suggested by Rafael. For Win8 systems
 which have broken ACPI video backlight control, the parameter can be
 set to 1 in kernel cmdline to skip registering ACPI video's backlight
 interface. Due to this change, the acpi_video_verify_backlight_support
 is moved from video_detect.c to video.c - patch 3/4;
 
  That's a fairly untenable position for distro kernels to be in.  They
  now have to ask every user that reports an issue with the backlight to
  try setting that option on the command line.  While I appreciate the
  setting breaks things for some people, doesn't the Win8 issue impact
  far more people?  Shouldn't it be defaulted to true?

 Well, we have a rule in the kernel not to introduce regressions for users 
 even
 if they are minority.

 Well, for some users, the regression actually happened when support for
 Win8 OSI call was introduced.

Yes, this is true.  It's probably one of the more common bug reports
we get in this area.  Kernels prior to that have working backlight,
kernels after that don't.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 4:39 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:

  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:

  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)



 So something in this batch of commits breaks a Macbook Pro Retina I have
 sitting here.  If I boot a Fedora kernel based on  Linux
 v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
 are generally working fine.  If I boot with a kernel based on Linux
 v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
 nothing but static on the screen (like 1950s TV static).

 This machine is using i915 graphics, so I booted with nomodeset and did
 the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
 repeated the failure with that.  I've gathered a bunch of data like
 dmesg, an intel_reg_snapshot, etc.  It's all attached below.

 I'll start bisecting to see if I can narrow down the commit that broke
 things, but I thought I would give a heads up now in case anyone has any
 ideas.

Looked through the log files and didn't see a clue. And usually DP
tends to fail pretty noisily. So I think the bisect result would be
interestin. Meanwhile:

Yeah, working on that.

- do you have drm.debug=0xe dmesg for a working kernel, too?

No, but I can try and get one.

- is the panel completely dead or is just the backlight on (or panel
on but backlight off)?

Backlight is on.  Literally static flickering on the screen.
Occasionally it will flicker from static to black back and forth.  But
the backlight is clearly on and what is trying to render (the GDM screen
normally) is just coming up as static.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer jwbo...@gmail.com wrote:
 OK.  Git bisect tells me this:

 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
 commit 57c219633275c7e7413f8bc7be250dc092887458
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Apr 4 17:19:37 2013 +0200

 drm/i915: revert eDP bpp clamping code changes

Yeah, that commit is a bit dubios and for 3.11 we've already planned
to kick it out. It tries to work around an issue on a funky
pre-release hw. Does reverting this commit fix your issue?

Yes, seems so.  I reverted it on top of Linus tree as of commit
ce857229e0c3adc2 and things boot normally on the machine after that.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer  wrote:
>> OK.  Git bisect tells me this:
>>
>> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
>> commit 57c219633275c7e7413f8bc7be250dc092887458
>> Author: Daniel Vetter 
>> Date:   Thu Apr 4 17:19:37 2013 +0200
>>
>> drm/i915: revert eDP bpp clamping code changes
>
>Yeah, that commit is a bit dubios and for 3.11 we've already planned
>to kick it out. It tries to work around an issue on a funky
>pre-release hw. Does reverting this commit fix your issue?

Yes, seems so.  I reverted it on top of Linus tree as of commit
ce857229e0c3adc2 and things boot normally on the machine after that.

josh

[git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 12:57:20PM -0400, Josh Boyer wrote:
>On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
>>On Fri, May 3, 2013 at 4:39 PM, Josh Boyer  wrote:
>>> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>>>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>>>>
>>>>  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)
>>>>
>>>>are available in the git repository at:
>>>>
>>>>  git://people.freedesktop.org/~airlied/linux.git drm-next
>>>>
>>>>for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:
>>>>
>>>>  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)
>>>>
>>>>
>>>
>>> So something in this batch of commits breaks a Macbook Pro Retina I have
>>> sitting here.  If I boot a Fedora kernel based on  Linux
>>> v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
>>> are generally working fine.  If I boot with a kernel based on Linux
>>> v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
>>> nothing but static on the screen (like 1950s TV static).
>>>
>>> This machine is using i915 graphics, so I booted with nomodeset and did
>>> the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
>>> repeated the failure with that.  I've gathered a bunch of data like
>>> dmesg, an intel_reg_snapshot, etc.  It's all attached below.
>>>
>>> I'll start bisecting to see if I can narrow down the commit that broke
>>> things, but I thought I would give a heads up now in case anyone has any
>>> ideas.
>>
>>Looked through the log files and didn't see a clue. And usually DP
>>tends to fail pretty noisily. So I think the bisect result would be
>>interestin. Meanwhile:
>
>Yeah, working on that.

OK.  Git bisect tells me this:

57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
commit 57c219633275c7e7413f8bc7be250dc092887458
Author: Daniel Vetter 
Date:   Thu Apr 4 17:19:37 2013 +0200

drm/i915: revert eDP bpp clamping code changes

The behaviour around handling the eDP bpp value from vbt has been
slightly changed in

commit 3600836585e3fdef0a1410d63fe5ce4015007aac
Author: Daniel Vetter 
Date:   Wed Mar 27 00:44:59 2013 +0100

drm/i915: convert DP autodither code to new infrastructure

The old behaviour was that we used the plane's bpp (usually 24bpp) for
computing the dp link bw, but set up the pipe with the bpp value from
vbt if available. This takes the vbt bpp override into account even
for the dp link bw configuration.

On Paulo's hsw machine this resulted in a slower link clock and a
black screen - but the mode actually /should/ fit even with the lower
clock. Until we've cleared up simply stay bug-for-bug compatible with
the old code.

While at it, also restore a debug message lost in:

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter 
Date:   Wed Mar 27 00:44:58 2013 +0100

drm/i915: precompute pipe bpp before touching the hw

Cc: Paulo Zanoni 
Reviewed-by: Paulo Zanoni 
Tested-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter 

:04 04 a7529c568073885302e5ca03cce5bd224e244b57 
d5d860a0d4b04ad98d77abb1df774c1448bd1697 M  drivers

The bisect log is below.  I can try to revert it directly on top of
Linus' latest tree later.

>>- do you have drm.debug=0xe dmesg for a working kernel, too?
>
>No, but I can try and get one.

I haven't gotten to this quite yet.  I'll try to get to it over the
weekend.

josh

[jwboyer at obiwan linux]$ git bisect log
git bisect start
# good: [5a148af66932c31814e263366094b5812210b501] Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
git bisect good 5a148af66932c31814e263366094b5812210b501
# bad: [ce857229e0c3adc211944a13a5579ef84fd7b4af] ipc: fix GETALL/IPC_RM race 
for sysv semaphores
git bisect bad ce857229e0c3adc211944a13a5579ef84fd7b4af
# bad: [4ed108352d9b60a723a5071ed05e722826c2b72f] drm/radeon: put UVD PLLs in 
bypass mode
git bisect bad 4ed108352d9b60a723a5071ed05e722826c2b72f
# bad: [dc652f90e088798bfa31f496ba994ddadd5d5680] drm/i915: ensure single 
initialization and cleanup of backlight device
git bisect bad dc652f90e088798bfa31f496ba994ddadd5d5680
# good: [bb60b9695ced58768ba05b2d88fb4ee815df18f4] drm/i915: emit a hotplug 
event on resume
git bisect good bb60b9695ced58768ba05b2d88fb4ee815df18f4
# good: [8b47047bd103c9fdb50440790a2ef17fa69a35c4] drm/i915: rip out superflous 
is_dp_cpu_edp tracking
git bisect good 8b47047bd103c9fdb504

[git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
>On Fri, May 3, 2013 at 4:39 PM, Josh Boyer  wrote:
>> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>>>
>>>  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)
>>>
>>>are available in the git repository at:
>>>
>>>  git://people.freedesktop.org/~airlied/linux.git drm-next
>>>
>>>for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:
>>>
>>>  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)
>>>
>>>
>>
>> So something in this batch of commits breaks a Macbook Pro Retina I have
>> sitting here.  If I boot a Fedora kernel based on  Linux
>> v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
>> are generally working fine.  If I boot with a kernel based on Linux
>> v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
>> nothing but static on the screen (like 1950s TV static).
>>
>> This machine is using i915 graphics, so I booted with nomodeset and did
>> the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
>> repeated the failure with that.  I've gathered a bunch of data like
>> dmesg, an intel_reg_snapshot, etc.  It's all attached below.
>>
>> I'll start bisecting to see if I can narrow down the commit that broke
>> things, but I thought I would give a heads up now in case anyone has any
>> ideas.
>
>Looked through the log files and didn't see a clue. And usually DP
>tends to fail pretty noisily. So I think the bisect result would be
>interestin. Meanwhile:

Yeah, working on that.

>- do you have drm.debug=0xe dmesg for a working kernel, too?

No, but I can try and get one.

>- is the panel completely dead or is just the backlight on (or panel
>on but backlight off)?

Backlight is on.  Literally static flickering on the screen.
Occasionally it will flicker from static to black back and forth.  But
the backlight is clearly on and what is trying to render (the GDM screen
normally) is just coming up as static.

josh

[git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:
>
>  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)
>
>are available in the git repository at:
>
>  git://people.freedesktop.org/~airlied/linux.git drm-next
>
>for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:
>
>  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)
>
>

So something in this batch of commits breaks a Macbook Pro Retina I have
sitting here.  If I boot a Fedora kernel based on  Linux
v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
are generally working fine.  If I boot with a kernel based on Linux
v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
nothing but static on the screen (like 1950s TV static).

This machine is using i915 graphics, so I booted with nomodeset and did
the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
repeated the failure with that.  I've gathered a bunch of data like
dmesg, an intel_reg_snapshot, etc.  It's all attached below.

I'll start bisecting to see if I can narrow down the commit that broke
things, but I thought I would give a heads up now in case anyone has any
ideas.

josh
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.0-0.rc0.git14.1.fc20.x86_64 (jwboyer at 
vader) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Fri May 3 
08:33:19 EDT 2013
[0.00] Command line: 
BOOT_IMAGE=/vmlinuz-3.10.0-0.rc0.git14.1.fc20.x86_64 
root=/dev/mapper/fedora_obiwan-root ro rd.lvm.lv=fedora_obiwan/root rd.md=0 
rd.dm=0 rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora_obiwan/swap rhgb quiet 
LANG=en_US.UTF-8 nomodeset
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008dfff] usable
[0.00] BIOS-e820: [mem 0x0008e000-0x0008] reserved
[0.00] BIOS-e820: [mem 0x0009-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000b] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable
[0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved
[0.00] BIOS-e820: [mem 0x40005000-0x88d11fff] usable
[0.00] BIOS-e820: [mem 0x88d12000-0x88d52fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x88d53000-0x88d66fff] usable
[0.00] BIOS-e820: [mem 0x88d67000-0x88d8efff] ACPI data
[0.00] BIOS-e820: [mem 0x88d8f000-0x88e3bfff] usable
[0.00] BIOS-e820: [mem 0x88e3c000-0x88e8efff] reserved
[0.00] BIOS-e820: [mem 0x88e8f000-0x88ed6fff] usable
[0.00] BIOS-e820: [mem 0x88ed7000-0x88efefff] reserved
[0.00] BIOS-e820: [mem 0x88eff000-0x88f91fff] usable
[0.00] BIOS-e820: [mem 0x88f92000-0x88ffefff] reserved
[0.00] BIOS-e820: [mem 0x88fff000-0x88ff] usable
[0.00] BIOS-e820: [mem 0x8900-0x8f9f] reserved
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xffe7-0xffe9] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00026f5f] usable
[0.00] e820: update [mem 0x8503b190-0x8504b1cf] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0008dfff] 
usable
[0.00] reserve setup_data: [mem 0x0008e000-0x0008] 
reserved
[0.00] reserve setup_data: [mem 0x0009-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x000a-0x000b] 
reserved
[0.00] reserve setup_data: [mem 0x0010-0x1fff] 
usable
[0.00] reserve setup_data: [mem 0x2000-0x201f] 
reserved
[0.00] reserve setup_data: [mem 0x2020-0x40003fff] 
usable
[0.00] reserve setup_data: [mem 0x40004000-0x40004fff] 
reserved
[0.00] reserve setup_data: [mem 0x40005000-0x8503b18f] 
usable
[0.00] reserve setup_data: [mem 0x8503b190-0x8504b1cf] 
usable
[0.00] reserve setup_data: [mem 0x8504b1d0-0x88d11fff] 
usable
[

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer  wrote:
> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer  wrote:
>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher  
>> wrote:
>>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer  wrote:
>>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher  
>>>> wrote:
>>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>>>
>>>>>>>> So I don't think that's actually the cause of the problem.  Or at least
>>>>>>>> not that alone.  I reverted it on top of Linus' latest tree and I still
>>>>>>>> get the lockups.
>>>>>>>
>>>>>>> Actually, git bisect does seem to have gotten it correct.  Once I
>>>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>>>> d895cb1af1), things seem to be working much better.  I've rebooted a
>>>>>>> dozen times without a lockup.  The most I've seen it take on a kernel
>>>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>>>> improvement.
>>>>>>
>>>>>> I give up.  GPU issues are not my thing.  2 reboots after I sent that it
>>>>>> gave me pretty rainbow static again.  So it might have been an
>>>>>> improvement, but revert it is not a solution.
>>>>>>
>>>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>>>> suspect, but I clearly have no clue.
>>>>>
>>>>> GPUs are tricky beasts :)
>>>>
>>>> Understatement ;).
>>>>
>>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>>>> by the evergreen code.  I'll put together some patches to help narrow
>>>>> down the problem.
>>>>
>>>> Yeah, that's the biggest problem I have, not knowing which functions are
>>>> actually being executed for this card.  It looks like a combination of
>>>> stuff in evergreen.c and ni.c, but I have no idea.
>>>>
>>>> Patches would be great.  If nothing else, I'm really good at building
>>>> kernels and rebooting by now.
>>>
>>> Two possible fixes attached.  The first attempts a full reset of all
>>> blocks if the MC (memory controller) is hung.  That may work better
>>> than just resetting the MC.  The second just disables MC reset.  I'm
>>> not sure we can reliably tell if it's busy due to display requests
>>> hitting the MC periodically which would lead to needlessly resetting
>>> it possibly leading to failures like you are seeing.
>>
>> OK.  I'll test them individually.  It will probably take a bit because
>> I'll want to do numerous reboots if things seem "fixed" with one or the
>> other.
>>
>> I'll let you know how things go.
>
> I applied each individually on top of Linus' tree as of this morning
> (commit 2a7d2b96d5) built, installed, and tested.
>
> 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
> two reboots.
>
> 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
> 21 reboots without a hang/rainbow static.  You'll understand if I'm
> hesitant to declare success, but resetting the MC does indeed appear to
> be the issue.  I'll keep rebooting for a while to make sure.

OK, I'm still running on the kernel with that patch and things still
work.  The only other "issue" I'm seeing at the moment is my dmesg is
full of:

[349316.595749] radeon :01:00.0: MC busy: 0x0409, clearing.
[349436.654946] radeon :01:00.0: MC busy: 0x0409, clearing.
[349436.655997] radeon :01:00.0: MC busy: 0x0409, clearing.
[349496.698441] radeon :01:00.0: MC busy: 0x0409, clearing.
[349556.726767] radeon :01:00.0: MC busy: 0x0409, clearing.
[349556.727797] radeon :01:00.0: MC busy: 0x0409, clearing.

So hopefully your patch is on the way into Linus' tree at some point
soon.

josh

Re: [git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer jwbo...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher alexdeuc...@gmail.com 
 wrote:
 ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit

 So I don't think that's actually the cause of the problem.  Or at least
 not that alone.  I reverted it on top of Linus' latest tree and I still
 get the lockups.

 Actually, git bisect does seem to have gotten it correct.  Once I
 actually tested the revert of just that on top of Linus' tree (commit
 d895cb1af1), things seem to be working much better.  I've rebooted a
 dozen times without a lockup.  The most I've seen it take on a kernel
 with that commit included is 3 reboots, so that's definitely at least an
 improvement.

 I give up.  GPU issues are not my thing.  2 reboots after I sent that it
 gave me pretty rainbow static again.  So it might have been an
 improvement, but revert it is not a solution.

 Looking at there rest of the commits, the whole GPU rework might be
 suspect, but I clearly have no clue.

 GPUs are tricky beasts :)

 Understatement ;).

 ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
 problem anyway since it only affects 6xx/7xx and your card is handled
 by the evergreen code.  I'll put together some patches to help narrow
 down the problem.

 Yeah, that's the biggest problem I have, not knowing which functions are
 actually being executed for this card.  It looks like a combination of
 stuff in evergreen.c and ni.c, but I have no idea.

 Patches would be great.  If nothing else, I'm really good at building
 kernels and rebooting by now.

 Two possible fixes attached.  The first attempts a full reset of all
 blocks if the MC (memory controller) is hung.  That may work better
 than just resetting the MC.  The second just disables MC reset.  I'm
 not sure we can reliably tell if it's busy due to display requests
 hitting the MC periodically which would lead to needlessly resetting
 it possibly leading to failures like you are seeing.

 OK.  I'll test them individually.  It will probably take a bit because
 I'll want to do numerous reboots if things seem fixed with one or the
 other.

 I'll let you know how things go.

 I applied each individually on top of Linus' tree as of this morning
 (commit 2a7d2b96d5) built, installed, and tested.

 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
 two reboots.

 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
 21 reboots without a hang/rainbow static.  You'll understand if I'm
 hesitant to declare success, but resetting the MC does indeed appear to
 be the issue.  I'll keep rebooting for a while to make sure.

OK, I'm still running on the kernel with that patch and things still
work.  The only other issue I'm seeing at the moment is my dmesg is
full of:

[349316.595749] radeon :01:00.0: MC busy: 0x0409, clearing.
[349436.654946] radeon :01:00.0: MC busy: 0x0409, clearing.
[349436.655997] radeon :01:00.0: MC busy: 0x0409, clearing.
[349496.698441] radeon :01:00.0: MC busy: 0x0409, clearing.
[349556.726767] radeon :01:00.0: MC busy: 0x0409, clearing.
[349556.727797] radeon :01:00.0: MC busy: 0x0409, clearing.

So hopefully your patch is on the way into Linus' tree at some point
soon.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit

 So I don't think that's actually the cause of the problem.  Or at least
 not that alone.  I reverted it on top of Linus' latest tree and I still
 get the lockups.

 Actually, git bisect does seem to have gotten it correct.  Once I
 actually tested the revert of just that on top of Linus' tree (commit
 d895cb1af1), things seem to be working much better.  I've rebooted a
 dozen times without a lockup.  The most I've seen it take on a kernel
 with that commit included is 3 reboots, so that's definitely at least an
 improvement.

 I give up.  GPU issues are not my thing.  2 reboots after I sent that it
 gave me pretty rainbow static again.  So it might have been an
 improvement, but revert it is not a solution.

 Looking at there rest of the commits, the whole GPU rework might be
 suspect, but I clearly have no clue.

 GPUs are tricky beasts :)

 Understatement ;).

 ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
 problem anyway since it only affects 6xx/7xx and your card is handled
 by the evergreen code.  I'll put together some patches to help narrow
 down the problem.

 Yeah, that's the biggest problem I have, not knowing which functions are
 actually being executed for this card.  It looks like a combination of
 stuff in evergreen.c and ni.c, but I have no idea.

 Patches would be great.  If nothing else, I'm really good at building
 kernels and rebooting by now.

 Two possible fixes attached.  The first attempts a full reset of all
 blocks if the MC (memory controller) is hung.  That may work better
 than just resetting the MC.  The second just disables MC reset.  I'm
 not sure we can reliably tell if it's busy due to display requests
 hitting the MC periodically which would lead to needlessly resetting
 it possibly leading to failures like you are seeing.

OK.  I'll test them individually.  It will probably take a bit because
I'll want to do numerous reboots if things seem fixed with one or the
other.

I'll let you know how things go.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer jwbo...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit

 So I don't think that's actually the cause of the problem.  Or at least
 not that alone.  I reverted it on top of Linus' latest tree and I still
 get the lockups.

 Actually, git bisect does seem to have gotten it correct.  Once I
 actually tested the revert of just that on top of Linus' tree (commit
 d895cb1af1), things seem to be working much better.  I've rebooted a
 dozen times without a lockup.  The most I've seen it take on a kernel
 with that commit included is 3 reboots, so that's definitely at least an
 improvement.

 I give up.  GPU issues are not my thing.  2 reboots after I sent that it
 gave me pretty rainbow static again.  So it might have been an
 improvement, but revert it is not a solution.

 Looking at there rest of the commits, the whole GPU rework might be
 suspect, but I clearly have no clue.

 GPUs are tricky beasts :)

 Understatement ;).

 ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
 problem anyway since it only affects 6xx/7xx and your card is handled
 by the evergreen code.  I'll put together some patches to help narrow
 down the problem.

 Yeah, that's the biggest problem I have, not knowing which functions are
 actually being executed for this card.  It looks like a combination of
 stuff in evergreen.c and ni.c, but I have no idea.

 Patches would be great.  If nothing else, I'm really good at building
 kernels and rebooting by now.

 Two possible fixes attached.  The first attempts a full reset of all
 blocks if the MC (memory controller) is hung.  That may work better
 than just resetting the MC.  The second just disables MC reset.  I'm
 not sure we can reliably tell if it's busy due to display requests
 hitting the MC periodically which would lead to needlessly resetting
 it possibly leading to failures like you are seeing.

 OK.  I'll test them individually.  It will probably take a bit because
 I'll want to do numerous reboots if things seem fixed with one or the
 other.

 I'll let you know how things go.

I applied each individually on top of Linus' tree as of this morning
(commit 2a7d2b96d5) built, installed, and tested.

0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
two reboots.

0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
21 reboots without a hang/rainbow static.  You'll understand if I'm
hesitant to declare success, but resetting the MC does indeed appear to
be the issue.  I'll keep rebooting for a while to make sure.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer  wrote:
> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher  
> wrote:
>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer  wrote:
>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher  
>>> wrote:
>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>>
>>>>>>> So I don't think that's actually the cause of the problem.  Or at least
>>>>>>> not that alone.  I reverted it on top of Linus' latest tree and I still
>>>>>>> get the lockups.
>>>>>>
>>>>>> Actually, git bisect does seem to have gotten it correct.  Once I
>>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>>> d895cb1af1), things seem to be working much better.  I've rebooted a
>>>>>> dozen times without a lockup.  The most I've seen it take on a kernel
>>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>>> improvement.
>>>>>
>>>>> I give up.  GPU issues are not my thing.  2 reboots after I sent that it
>>>>> gave me pretty rainbow static again.  So it might have been an
>>>>> improvement, but revert it is not a solution.
>>>>>
>>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>>> suspect, but I clearly have no clue.
>>>>
>>>> GPUs are tricky beasts :)
>>>
>>> Understatement ;).
>>>
>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>>> by the evergreen code.  I'll put together some patches to help narrow
>>>> down the problem.
>>>
>>> Yeah, that's the biggest problem I have, not knowing which functions are
>>> actually being executed for this card.  It looks like a combination of
>>> stuff in evergreen.c and ni.c, but I have no idea.
>>>
>>> Patches would be great.  If nothing else, I'm really good at building
>>> kernels and rebooting by now.
>>
>> Two possible fixes attached.  The first attempts a full reset of all
>> blocks if the MC (memory controller) is hung.  That may work better
>> than just resetting the MC.  The second just disables MC reset.  I'm
>> not sure we can reliably tell if it's busy due to display requests
>> hitting the MC periodically which would lead to needlessly resetting
>> it possibly leading to failures like you are seeing.
>
> OK.  I'll test them individually.  It will probably take a bit because
> I'll want to do numerous reboots if things seem "fixed" with one or the
> other.
>
> I'll let you know how things go.

I applied each individually on top of Linus' tree as of this morning
(commit 2a7d2b96d5) built, installed, and tested.

0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
two reboots.

0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
21 reboots without a hang/rainbow static.  You'll understand if I'm
hesitant to declare success, but resetting the MC does indeed appear to
be the issue.  I'll keep rebooting for a while to make sure.

josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher  wrote:
> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer  wrote:
>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher  
>> wrote:
>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>
>>>>>> So I don't think that's actually the cause of the problem.  Or at least
>>>>>> not that alone.  I reverted it on top of Linus' latest tree and I still
>>>>>> get the lockups.
>>>>>
>>>>> Actually, git bisect does seem to have gotten it correct.  Once I
>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>> d895cb1af1), things seem to be working much better.  I've rebooted a
>>>>> dozen times without a lockup.  The most I've seen it take on a kernel
>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>> improvement.
>>>>
>>>> I give up.  GPU issues are not my thing.  2 reboots after I sent that it
>>>> gave me pretty rainbow static again.  So it might have been an
>>>> improvement, but revert it is not a solution.
>>>>
>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>> suspect, but I clearly have no clue.
>>>
>>> GPUs are tricky beasts :)
>>
>> Understatement ;).
>>
>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>> by the evergreen code.  I'll put together some patches to help narrow
>>> down the problem.
>>
>> Yeah, that's the biggest problem I have, not knowing which functions are
>> actually being executed for this card.  It looks like a combination of
>> stuff in evergreen.c and ni.c, but I have no idea.
>>
>> Patches would be great.  If nothing else, I'm really good at building
>> kernels and rebooting by now.
>
> Two possible fixes attached.  The first attempts a full reset of all
> blocks if the MC (memory controller) is hung.  That may work better
> than just resetting the MC.  The second just disables MC reset.  I'm
> not sure we can reliably tell if it's busy due to display requests
> hitting the MC periodically which would lead to needlessly resetting
> it possibly leading to failures like you are seeing.

OK.  I'll test them individually.  It will probably take a bit because
I'll want to do numerous reboots if things seem "fixed" with one or the
other.

I'll let you know how things go.

josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher  wrote:
> On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer  wrote:
>> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer  wrote:
>>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer  wrote:
>>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer  wrote:
>>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie  wrote:
>>>>>> Alex Deucher (29):
>>>>>>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>>>>   drm/radeon: halt engines before disabling MC (evergreen)
>>>>>>   drm/radeon: halt engines before disabling MC (cayman/TN)
>>>>>>   drm/radeon: halt engines before disabling MC (si)
>>>>>>   drm/radeon: use the reset mask to determine if rings are hung
>>>>>
>>>>> Something in this series of commits is causing the GPU to hang on reboot
>>>>> on my Dell XPS 8300 machine.  That has a:
>>>>>
>>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>>>>> ATI Caicos [Radeon HD 6450]
>>>>>
>>>>> card in it.  After reboots, I get a screen that looks like this:
>>>>>
>>>>> http://t.co/tPnT6xQZUK
>>>>>
>>>>> I can hit it fairly consistently after a few reboots, so I tried doing a
>>>>> git bisect on the radeon driver and it came down to:
>>>>>
>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>
>>>> So I don't think that's actually the cause of the problem.  Or at least
>>>> not that alone.  I reverted it on top of Linus' latest tree and I still
>>>> get the lockups.
>>>
>>> Actually, git bisect does seem to have gotten it correct.  Once I
>>> actually tested the revert of just that on top of Linus' tree (commit
>>> d895cb1af1), things seem to be working much better.  I've rebooted a
>>> dozen times without a lockup.  The most I've seen it take on a kernel
>>> with that commit included is 3 reboots, so that's definitely at least an
>>> improvement.
>>
>> I give up.  GPU issues are not my thing.  2 reboots after I sent that it
>> gave me pretty rainbow static again.  So it might have been an
>> improvement, but revert it is not a solution.
>>
>> Looking at there rest of the commits, the whole GPU rework might be
>> suspect, but I clearly have no clue.
>
> GPUs are tricky beasts :)

Understatement ;).

> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
> problem anyway since it only affects 6xx/7xx and your card is handled
> by the evergreen code.  I'll put together some patches to help narrow
> down the problem.

Yeah, that's the biggest problem I have, not knowing which functions are
actually being executed for this card.  It looks like a combination of
stuff in evergreen.c and ni.c, but I have no idea.

Patches would be great.  If nothing else, I'm really good at building
kernels and rebooting by now.

josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer  wrote:
> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer  wrote:
>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer  wrote:
>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie  wrote:
>>>> Alex Deucher (29):
>>>>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>>   drm/radeon: halt engines before disabling MC (evergreen)
>>>>   drm/radeon: halt engines before disabling MC (cayman/TN)
>>>>   drm/radeon: halt engines before disabling MC (si)
>>>>   drm/radeon: use the reset mask to determine if rings are hung
>>>
>>> Something in this series of commits is causing the GPU to hang on reboot
>>> on my Dell XPS 8300 machine.  That has a:
>>>
>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>>> ATI Caicos [Radeon HD 6450]
>>>
>>> card in it.  After reboots, I get a screen that looks like this:
>>>
>>> http://t.co/tPnT6xQZUK
>>>
>>> I can hit it fairly consistently after a few reboots, so I tried doing a
>>> git bisect on the radeon driver and it came down to:
>>>
>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>
>> So I don't think that's actually the cause of the problem.  Or at least
>> not that alone.  I reverted it on top of Linus' latest tree and I still
>> get the lockups.
>
> Actually, git bisect does seem to have gotten it correct.  Once I
> actually tested the revert of just that on top of Linus' tree (commit
> d895cb1af1), things seem to be working much better.  I've rebooted a
> dozen times without a lockup.  The most I've seen it take on a kernel
> with that commit included is 3 reboots, so that's definitely at least an
> improvement.

I give up.  GPU issues are not my thing.  2 reboots after I sent that it
gave me pretty rainbow static again.  So it might have been an
improvement, but revert it is not a solution.

Looking at there rest of the commits, the whole GPU rework might be
suspect, but I clearly have no clue.

josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer  wrote:
> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer  wrote:
>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie  wrote:
>>> Alex Deucher (29):
>>>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>   drm/radeon: halt engines before disabling MC (evergreen)
>>>   drm/radeon: halt engines before disabling MC (cayman/TN)
>>>   drm/radeon: halt engines before disabling MC (si)
>>>   drm/radeon: use the reset mask to determine if rings are hung
>>
>> Something in this series of commits is causing the GPU to hang on reboot
>> on my Dell XPS 8300 machine.  That has a:
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>> ATI Caicos [Radeon HD 6450]
>>
>> card in it.  After reboots, I get a screen that looks like this:
>>
>> http://t.co/tPnT6xQZUK
>>
>> I can hit it fairly consistently after a few reboots, so I tried doing a
>> git bisect on the radeon driver and it came down to:
>>
>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>
> So I don't think that's actually the cause of the problem.  Or at least
> not that alone.  I reverted it on top of Linus' latest tree and I still
> get the lockups.

Actually, git bisect does seem to have gotten it correct.  Once I
actually tested the revert of just that on top of Linus' tree (commit
d895cb1af1), things seem to be working much better.  I've rebooted a
dozen times without a lockup.  The most I've seen it take on a kernel
with that commit included is 3 reboots, so that's definitely at least an
improvement.

Now that I seem to have narrowed down which commit is broken, I'd be
happy to test fixes, etc.  Sorry for the noise from earlier today.


josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer  wrote:
> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer  wrote:
>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie  wrote:
>>> Alex Deucher (29):
>>>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>   drm/radeon: halt engines before disabling MC (evergreen)
>>>   drm/radeon: halt engines before disabling MC (cayman/TN)
>>>   drm/radeon: halt engines before disabling MC (si)
>>>   drm/radeon: use the reset mask to determine if rings are hung
>>
>> Something in this series of commits is causing the GPU to hang on reboot
>> on my Dell XPS 8300 machine.  That has a:
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>> ATI Caicos [Radeon HD 6450]
>>
>> card in it.  After reboots, I get a screen that looks like this:
>>
>> http://t.co/tPnT6xQZUK
>>
>> I can hit it fairly consistently after a few reboots, so I tried doing a
>> git bisect on the radeon driver and it came down to:
>>
>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>
> So I don't think that's actually the cause of the problem.  Or at least
> not that alone.  I reverted it on top of Linus' latest tree and I still
> get the lockups.
>
> Thus far I've reverted:
>
>   drm/radeon: use status regs to determine what to reset (6xx/7xx)
>   drm/radeon: use status regs to determine what to reset (evergreen)
>   drm/radeon: use status regs to determine what to reset (cayman)
>   drm/radeon: use status regs to determine what to reset (si)
>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>   drm/radeon: halt engines before disabling MC (evergreen)
>   drm/radeon: halt engines before disabling MC (cayman/TN)
>   drm/radeon: halt engines before disabling MC (si)
>   drm/radeon: use the reset mask to determine if rings are hung
>
> and can still recreate the issue.  I'm starting to think the problem is

Sigh.  Of course I just realized that I haven't been regenerating the
initramfs, so I'm not even testing what I'm building at this point.  So
all I know is that it's broken somewhere between the two commits in my
initial bisect log.  I've had better days.

josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer  wrote:
> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie  wrote:
>> Alex Deucher (29):
>>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>>   drm/radeon: halt engines before disabling MC (evergreen)
>>   drm/radeon: halt engines before disabling MC (cayman/TN)
>>   drm/radeon: halt engines before disabling MC (si)
>>   drm/radeon: use the reset mask to determine if rings are hung
>
> Something in this series of commits is causing the GPU to hang on reboot
> on my Dell XPS 8300 machine.  That has a:
>
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
> ATI Caicos [Radeon HD 6450]
>
> card in it.  After reboots, I get a screen that looks like this:
>
> http://t.co/tPnT6xQZUK
>
> I can hit it fairly consistently after a few reboots, so I tried doing a
> git bisect on the radeon driver and it came down to:
>
> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit

So I don't think that's actually the cause of the problem.  Or at least
not that alone.  I reverted it on top of Linus' latest tree and I still
get the lockups.

Thus far I've reverted:

  drm/radeon: use status regs to determine what to reset (6xx/7xx)
  drm/radeon: use status regs to determine what to reset (evergreen)
  drm/radeon: use status regs to determine what to reset (cayman)
  drm/radeon: use status regs to determine what to reset (si)
  drm/radeon: halt engines before disabling MC (6xx/7xx)
  drm/radeon: halt engines before disabling MC (evergreen)
  drm/radeon: halt engines before disabling MC (cayman/TN)
  drm/radeon: halt engines before disabling MC (si)
  drm/radeon: use the reset mask to determine if rings are hung

and can still recreate the issue.  I'm starting to think the problem is
in one of:

  drm/radeon: rework GPU reset on r6xx/r7xx
  drm/radeon: rework GPU reset on evergreen
  drm/radeon: rework GPU reset on cayman/TN
  drm/radeon: rework GPU reset on cayman/TN (which should be si)

Still trying to figure out exactly which code paths are used on this
card, but I'll keep poking at it.  Any ideas or tips for debug are more
than welcome.

josh

[git pull] drm merge for 3.9-rc1

[Josh Boyer]

On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie  wrote:
> Alex Deucher (29):
>   drm/radeon: halt engines before disabling MC (6xx/7xx)
>   drm/radeon: halt engines before disabling MC (evergreen)
>   drm/radeon: halt engines before disabling MC (cayman/TN)
>   drm/radeon: halt engines before disabling MC (si)
>   drm/radeon: use the reset mask to determine if rings are hung

Something in this series of commits is causing the GPU to hang on reboot
on my Dell XPS 8300 machine.  That has a:

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI Caicos [Radeon HD 6450]

card in it.  After reboots, I get a screen that looks like this:

http://t.co/tPnT6xQZUK

I can hit it fairly consistently after a few reboots, so I tried doing a
git bisect on the radeon driver and it came down to:

ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
commit ca57802e521de54341efc8a56f70571f79ffac72
Author: Alex Deucher 
Date:   Wed Jan 23 18:56:08 2013 -0500

drm/radeon: halt engines before disabling MC (6xx/7xx)

It's better to halt the engines before we disable the MC.

Signed-off-by: Alex Deucher 

Basically what seems to be happening is drm:r600_ring_test fails the ring
0 test and disables GPU accel.  Things go downhill from there, as the
driver continues to try and set hpd after the interrupts have been
disabled already.  The relevant dmesg portions are below.

I think Alex has a patch to not do that and I built a kernel with that and
the splat went away, but the actual problem of the rainbow static screen
still remains.

I can send the bisect log if people are interested.  I'll try reverting
that single commit and seeing if it fixes things on a known "bad" kernel.
I'd be happy to try further debugging suggestions if this doesn't make
sense.

josh

Full dmesg can be found here: http://paste.fedoraproject.org/3903/

[3.277618] [drm] radeon kernel modesetting enabled.
[3.277708] checking generic (d000 5b) vs hw (d000 1000)
[3.277710] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver
[3.277787] Console: switching to colour dummy device 80x25
[3.282108] [drm] initializing kernel modesetting (CAICOS
0x1002:0x6779 0x1B0A:0x909D).
[3.282286] [drm] register mmio base: 0xFE62
[3.282287] [drm] register mmio size: 131072
[3.282782] ATOM BIOS: DeLL
[3.282806] radeon :01:00.0: GPU softreset: 0x0400
[3.282808] radeon :01:00.0:   GRBM_STATUS   = 0x3828
[3.282810] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0007
[3.282812] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0007
[3.282814] radeon :01:00.0:   SRBM_STATUS   = 0x20C0
[3.282816] radeon :01:00.0:   SRBM_STATUS2  = 0x
[3.282818] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[3.282820] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[3.282822] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[3.282824] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[3.282826] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[3.291890] radeon :01:00.0: SRBM_SOFT_RESET=0x0800
[3.309450] radeon :01:00.0:   GRBM_STATUS   = 0x3828
[3.309452] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0007
[3.309454] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0007
[3.309456] radeon :01:00.0:   SRBM_STATUS   = 0x22C0
[3.309458] radeon :01:00.0:   SRBM_STATUS2  = 0x
[3.309460] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[3.309462] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[3.309464] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[3.309466] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[3.309468] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[3.309997] radeon :01:00.0: VRAM: 1024M 0x -
0x3FFF (1024M used)
[3.31] radeon :01:00.0: GTT: 512M 0x4000 -
0x5FFF
[3.314766] [drm] Detected VRAM RAM=1024M, BAR=256M
[3.314770] [drm] RAM width 64bits DDR
[3.316172] [TTM] Zone  kernel: Available graphics memory: 6131076 kiB
[3.316176] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[3.316179] [TTM] Initializing pool allocator
[3.316288] [TTM] Initializing DMA pool allocator
[3.316950] [drm] radeon: 1024M of VRAM memory ready
[3.316975] [drm] radeon: 512M of GTT memory ready.
[3.317367] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[3.317369] [drm] Driver supports precise vblank timestamp query.
[3.317529] radeon :01:00.0: irq 44 for MSI/MSI-X
[3.317599] radeon :01:00.0: radeon: using MSI.
[3.317882] [drm] radeon: 

Re: [PATCH] fbcon: fix locking harder

[Josh Boyer]

On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie airl...@gmail.com wrote:
 Okay so Alan's patch handled the case where there was no registered fbcon,
 however the other path entered in set_con2fb_map pit.

 In there we called fbcon_takeover, but we also took the console lock in a 
 couple
 of places. So push the console lock out to the callers of set_con2fb_map,

 this means fbmem and switcheroo needed to take the lock around the fb notifier
 entry points that lead to this.

 This should fix the efifb regression seen by Maarten.

 Signed-off-by: Dave Airlie airl...@redhat.com

Linus might not be taking this for 3.8 because of lack of testing, but
that doesn't mean the problems don't exist in 3.8 (and older).  Maybe
throw a CC for stable on the patch?  That way it works its way back when
it does get merged.

josh

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] fbcon: fix locking harder

[Josh Boyer]

On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie  wrote:
> Okay so Alan's patch handled the case where there was no registered fbcon,
> however the other path entered in set_con2fb_map pit.
>
> In there we called fbcon_takeover, but we also took the console lock in a 
> couple
> of places. So push the console lock out to the callers of set_con2fb_map,
>
> this means fbmem and switcheroo needed to take the lock around the fb notifier
> entry points that lead to this.
>
> This should fix the efifb regression seen by Maarten.
>
> Signed-off-by: Dave Airlie 

Linus might not be taking this for 3.8 because of lack of testing, but
that doesn't mean the problems don't exist in 3.8 (and older).  Maybe
throw a CC for stable on the patch?  That way it works its way back when
it does get merged.

josh

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Hangcheck timer elapsed... GPU hung in 3.8.0-rc2

[Josh Boyer]

On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields bfie...@fieldses.org wrote:
 I got a crash after a few minutes of running 3.8.0-rc2, was able to
 switch to a vt and look at dmesg:

   [  490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
 GPU hung
   [  490.963019] [drm] capturing error event; look for more information in 
 /debug/dri/0/i915_error_state
   [  492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
 GPU hung
   [  492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring 
 wedged!
   [  492.965621] [drm:i915_reset] *ERROR* Failed to reset chip.

 Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such
 problem.

I'm not questioning that you haven't seen that error in F17, but we have
had quite a few bug reports with similar error messages for a while now.
Apparently there are lots of ways GPUs can get hung, so they might be
different from what you're seeing.  Just wanted to point out that it
might not be a new 3.8 change that caused it.

josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2

[Josh Boyer]

On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields  wrote:
> I got a crash after a few minutes of running 3.8.0-rc2, was able to
> switch to a vt and look at dmesg:
>
>   [  490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
> GPU hung
>   [  490.963019] [drm] capturing error event; look for more information in 
> /debug/dri/0/i915_error_state
>   [  492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... 
> GPU hung
>   [  492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring 
> wedged!
>   [  492.965621] [drm:i915_reset] *ERROR* Failed to reset chip.
>
> Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such
> problem.

I'm not questioning that you haven't seen that error in F17, but we have
had quite a few bug reports with similar error messages for a while now.
Apparently there are lots of ways GPUs can get hung, so they might be
different from what you're seeing.  Just wanted to point out that it
might not be a new 3.8 change that caused it.

josh

[PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740

[Josh Boyer]

On Tue, Aug 28, 2012 at 4:50 PM,   wrote:
> From: Jerome Glisse 
>
> It seems some of those IGP dislike non dma32 page despite what
> documentation says. Fix regression since we allowed non dma32
> pages. It seems it only affect some revision of those IGP chips
> as we don't know which one just force dma32 for all of them.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=785375
>
> Signed-off-by: Jerome Glisse 
> Cc: 


This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f.  I
don't see it queued up in the stable-queue, so I thought I'd point it
out in case it was missed.

josh

> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 066c98b..8867400 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -774,7 +774,7 @@ int radeon_device_init(struct radeon_device *rdev,
> if (rdev->flags & RADEON_IS_AGP)
> rdev->need_dma32 = true;
> if ((rdev->flags & RADEON_IS_PCI) &&
> -   (rdev->family < CHIP_RS400))
> +   (rdev->family <= CHIP_RS740))
> rdev->need_dma32 = true;
>
> dma_bits = rdev->need_dma32 ? 32 : 40;
> --
> 1.7.11.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740

[Josh Boyer]

On Tue, Aug 28, 2012 at 4:50 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 It seems some of those IGP dislike non dma32 page despite what
 documentation says. Fix regression since we allowed non dma32
 pages. It seems it only affect some revision of those IGP chips
 as we don't know which one just force dma32 for all of them.

 https://bugzilla.redhat.com/show_bug.cgi?id=785375

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 Cc: sta...@vger.kernel.org


This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f.  I
don't see it queued up in the stable-queue, so I thought I'd point it
out in case it was missed.

josh

 ---
  drivers/gpu/drm/radeon/radeon_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index 066c98b..8867400 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -774,7 +774,7 @@ int radeon_device_init(struct radeon_device *rdev,
 if (rdev-flags  RADEON_IS_AGP)
 rdev-need_dma32 = true;
 if ((rdev-flags  RADEON_IS_PCI) 
 -   (rdev-family  CHIP_RS400))
 +   (rdev-family = CHIP_RS740))
 rdev-need_dma32 = true;

 dma_bits = rdev-need_dma32 ? 32 : 40;
 --
 1.7.11.2

 --
 To unsubscribe from this list: send the line unsubscribe stable in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbcon: fix race condition between console lock and cursor timer

[Josh Boyer]

On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie airl...@redhat.com wrote:
 So we've had a fair few reports of fbcon handover breakage between
 efi/vesafb and i915 surface recently, so I dedicated a couple of
 days to finding the problem.

 Essentially the last thing we saw was the conflicting framebuffer
 message and that was all.

 So after much tracing with direct netconsole writes (printks
 under console_lock not so useful), I think I found the race.

 Thread A (driver load)Thread B (timer thread)
   unbind_con_driver -  |
   bind_con_driver -|
   vc-vc_sw-con_deinit -  |
   fbcon_deinit -   |
   console_lock()|
   | |
   |   fbcon_flashcursor timer fires
   |   console_lock() - blocked for A
   |
   |
 fbcon_del_cursor_timer -
   del_timer_sync
   (BOOM)

 Of course because all of this is under the console lock,
 we never see anything, also since we also just unbound the active
 console guess what we never see anything.

 Hopefully this fixes the problem for anyone seeing vesafb-kms
 driver handoff.

 Signed-off-by: David Airlie airl...@redhat.com
 ---
  drivers/video/console/fbcon.c |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
 index 2e471c2..f8a79fc 100644
 --- a/drivers/video/console/fbcon.c
 +++ b/drivers/video/console/fbcon.c
 @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work)
 struct vc_data *vc = NULL;
 int c;
 int mode;
 +   int ret;
 +
 +   ret = console_trylock();
 +   if (ret == 0)
 +   return;

 -   console_lock();
 if (ops  ops-currcon != -1)
 vc = vc_cons[ops-currcon].d;


I have a Dell XPS 8300 machine with a Radeon card in it that started
showing this problem yesterday with 3.6-rc2 kernels.  I tested this
patch on top of v3.6-rc2-206-g10c63c9 this morning and the problem
seems to have been cleared up for me.  That includes making sure the
grub2 file has the gfxterm set, etc.

I know we've been seeing this quite a bit more on Fedora 17, so we'll
want to have some people test a 3.5 build with it but things are
looking better.

josh

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] fbcon: fix race condition between console lock and cursor timer

[Josh Boyer]

On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie  wrote:
> So we've had a fair few reports of fbcon handover breakage between
> efi/vesafb and i915 surface recently, so I dedicated a couple of
> days to finding the problem.
>
> Essentially the last thing we saw was the conflicting framebuffer
> message and that was all.
>
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
>
> Thread A (driver load)Thread B (timer thread)
>   unbind_con_driver ->  |
>   bind_con_driver ->|
>   vc->vc_sw->con_deinit ->  |
>   fbcon_deinit ->   |
>   console_lock()|
>   | |
>   |   fbcon_flashcursor timer fires
>   |   console_lock() <- blocked for A
>   |
>   |
> fbcon_del_cursor_timer ->
>   del_timer_sync
>   (BOOM)
>
> Of course because all of this is under the console lock,
> we never see anything, also since we also just unbound the active
> console guess what we never see anything.
>
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
>
> Signed-off-by: David Airlie 
> ---
>  drivers/video/console/fbcon.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 2e471c2..f8a79fc 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work)
> struct vc_data *vc = NULL;
> int c;
> int mode;
> +   int ret;
> +
> +   ret = console_trylock();
> +   if (ret == 0)
> +   return;
>
> -   console_lock();
> if (ops && ops->currcon != -1)
> vc = vc_cons[ops->currcon].d;
>

I have a Dell XPS 8300 machine with a Radeon card in it that started
showing this problem yesterday with 3.6-rc2 kernels.  I tested this
patch on top of v3.6-rc2-206-g10c63c9 this morning and the problem
seems to have been cleared up for me.  That includes making sure the
grub2 file has the gfxterm set, etc.

I know we've been seeing this quite a bit more on Fedora 17, so we'll
want to have some people test a 3.5 build with it but things are
looking better.

josh

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

gma500 opregion/power init order backtrace

[Josh Boyer]

Hi Alan,

We had a report [1] of a machine with a Cedarview chip in it not being
able to have the backlight level adjusted with the hardware function
keys in F17.  Matthew suggested that gma500 needs to work with opregion
and the reporter (CC'd) tried a rawhide kernel based on
v3.5-rc6-186-gac7d181.

I noticed there was a backtrace due to the power_ctrl_lock being used in
spin_lock_irqsave before it was actually initialized.  The backtrace is
included below.  It seems cdv_chip_setup is called before gma_power_init
in psb_drv.c and that leads to a callchain that hits this.

I'm wondering if the gma_power_init call can be moved up before
chip_setup is called.  Seems so, but I thought I would ping you to see
if you've seen this already.

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=833597

[   12.299336] BUG: spinlock bad magic on CPU#2, udevd/155
[   12.299505]  lock: power_ctrl_lock [gma500_gfx], .magic: , .owner: 
udevd/155, .owner_cpu: 2
[   12.301025] Pid: 155, comm: udevd Not tainted 3.5.0-0.rc6.git4.1.fc18.x86_64 
#1
[   12.301226] Call Trace:
[   12.301371]  [816c70e6] spin_dump+0x8c/0x91
[   12.301514]  [816c710c] spin_bug+0x21/0x26
[   12.301659]  [8134bff3] do_raw_spin_unlock+0x63/0xa0
[   12.301809]  [816cef55] _raw_spin_unlock_irqrestore+0x35/0x80
[   12.302001]  [a00763ac] gma_power_begin+0x5c/0x110 [gma500_gfx]
[   12.302025]  [a007eee7] psb_enable_pipestat+0x67/0xe0 [gma500_gfx]
[   12.302048]  [a0081218] psb_intel_opregion_enable_asle+0x38/0x70 
[gma500_gfx]
[   12.302069]  [a00812c5] psb_intel_opregion_init+0x75/0x80 
[gma500_gfx]
[   12.302092]  [a0082058] cdv_chip_setup+0x118/0x190 [gma500_gfx]
[   12.302113]  [a0076b46] psb_driver_load+0xd6/0x480 [gma500_gfx]
[   12.302146]  [a001e8b6] drm_get_pci_dev+0x186/0x2d0 [drm]
[   12.302157]  [810d283d] ? trace_hardirqs_on+0xd/0x10
[   12.302177]  [a0076845] psb_probe+0x15/0x20 [gma500_gfx]
[   12.302188]  [8136db6c] local_pci_probe+0x5c/0xd0
[   12.302197]  [8136dcf1] pci_device_probe+0x111/0x120
[   12.302209]  [81434192] driver_probe_device+0x92/0x390
[   12.302217]  [8143453b] __driver_attach+0xab/0xb0
[   12.302226]  [81434490] ? driver_probe_device+0x390/0x390
[   12.302235]  [81432125] bus_for_each_dev+0x55/0x90
[   12.302243]  [a0097000] ? 0xa0096fff
[   12.302252]  [81433a1e] driver_attach+0x1e/0x20
[   12.302259]  [81433728] bus_add_driver+0x1b8/0x2b0
[   12.302267]  [a0097000] ? 0xa0096fff
[   12.302276]  [81434c37] driver_register+0x77/0x150
[   12.302296]  [a0097000] ? 0xa0096fff
[   12.302306]  [8136c8cf] __pci_register_driver+0x6f/0xf0
[   12.302315]  [a0097000] ? 0xa0096fff
[   12.302341]  [a001eb1a] drm_pci_init+0x11a/0x130 [drm]
[   12.302348]  [a0097000] ? 0xa0096fff
[   12.302369]  [a0097017] psb_init+0x17/0x1000 [gma500_gfx]
[   12.302380]  [8100212a] do_one_initcall+0x12a/0x180
[   12.302389]  [810df546] sys_init_module+0x156/0x2280
[   12.302399]  [8135a340] ? ddebug_proc_open+0xd0/0xd0
[   12.302417]  [811c7710] ? fget_raw+0x310/0x310
[   12.302429]  [816d7ea9] system_call_fastpath+0x16/0x1b
[   12.303259] gma500 :00:02.0: GPU: power management timed out.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

gma500 opregion/power init order backtrace

[Josh Boyer]

Hi Alan,

We had a report [1] of a machine with a Cedarview chip in it not being
able to have the backlight level adjusted with the hardware function
keys in F17.  Matthew suggested that gma500 needs to work with opregion
and the reporter (CC'd) tried a rawhide kernel based on
v3.5-rc6-186-gac7d181.

I noticed there was a backtrace due to the power_ctrl_lock being used in
spin_lock_irqsave before it was actually initialized.  The backtrace is
included below.  It seems cdv_chip_setup is called before gma_power_init
in psb_drv.c and that leads to a callchain that hits this.

I'm wondering if the gma_power_init call can be moved up before
chip_setup is called.  Seems so, but I thought I would ping you to see
if you've seen this already.

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=833597

[   12.299336] BUG: spinlock bad magic on CPU#2, udevd/155
[   12.299505]  lock: power_ctrl_lock [gma500_gfx], .magic: , .owner: 
udevd/155, .owner_cpu: 2
[   12.301025] Pid: 155, comm: udevd Not tainted 3.5.0-0.rc6.git4.1.fc18.x86_64 
#1
[   12.301226] Call Trace:
[   12.301371]  [] spin_dump+0x8c/0x91
[   12.301514]  [] spin_bug+0x21/0x26
[   12.301659]  [] do_raw_spin_unlock+0x63/0xa0
[   12.301809]  [] _raw_spin_unlock_irqrestore+0x35/0x80
[   12.302001]  [] gma_power_begin+0x5c/0x110 [gma500_gfx]
[   12.302025]  [] psb_enable_pipestat+0x67/0xe0 [gma500_gfx]
[   12.302048]  [] psb_intel_opregion_enable_asle+0x38/0x70 
[gma500_gfx]
[   12.302069]  [] psb_intel_opregion_init+0x75/0x80 
[gma500_gfx]
[   12.302092]  [] cdv_chip_setup+0x118/0x190 [gma500_gfx]
[   12.302113]  [] psb_driver_load+0xd6/0x480 [gma500_gfx]
[   12.302146]  [] drm_get_pci_dev+0x186/0x2d0 [drm]
[   12.302157]  [] ? trace_hardirqs_on+0xd/0x10
[   12.302177]  [] psb_probe+0x15/0x20 [gma500_gfx]
[   12.302188]  [] local_pci_probe+0x5c/0xd0
[   12.302197]  [] pci_device_probe+0x111/0x120
[   12.302209]  [] driver_probe_device+0x92/0x390
[   12.302217]  [] __driver_attach+0xab/0xb0
[   12.302226]  [] ? driver_probe_device+0x390/0x390
[   12.302235]  [] bus_for_each_dev+0x55/0x90
[   12.302243]  [] ? 0xa0096fff
[   12.302252]  [] driver_attach+0x1e/0x20
[   12.302259]  [] bus_add_driver+0x1b8/0x2b0
[   12.302267]  [] ? 0xa0096fff
[   12.302276]  [] driver_register+0x77/0x150
[   12.302296]  [] ? 0xa0096fff
[   12.302306]  [] __pci_register_driver+0x6f/0xf0
[   12.302315]  [] ? 0xa0096fff
[   12.302341]  [] drm_pci_init+0x11a/0x130 [drm]
[   12.302348]  [] ? 0xa0096fff
[   12.302369]  [] psb_init+0x17/0x1000 [gma500_gfx]
[   12.302380]  [] do_one_initcall+0x12a/0x180
[   12.302389]  [] sys_init_module+0x156/0x2280
[   12.302399]  [] ? ddebug_proc_open+0xd0/0xd0
[   12.302417]  [] ? fget_raw+0x310/0x310
[   12.302429]  [] system_call_fastpath+0x16/0x1b
[   12.303259] gma500 :00:02.0: GPU: power management timed out.