Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Tue, May 21, 2013 at 1:28 PM, Ben Guthro  wrote:
> On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter  wrote:
>> On Tue, May 21, 2013 at 3:44 PM, Ben Guthro  wrote:
>>>> This will break kms since now you have the vbios and the linux kms driver
>>>> fighting over the same piece of hw. Does
>>>>
>>>> xset dpms force off
>>>> xset dpms force on
>>>>
>>>> cause similar issues?
>>>
>>> No, these work as expected (on 3.8)
>>> I didn't realize that these broke with KMS. I'll stick with the S3 
>>> reproduction.
>>
>> Ok, so things are at least not terribly broken.
>>
>>>> If not please make sure that vbetool isn't badly interfering with the
>>>> kernel modeset driver on suspend/resume. At least looking at your dmesg
>>>> and reg dumps vbe wreaking havoc with the kms driver seems like a rather
>>>> likely scenario. Also, can you please test latest 3.10-rc kernels?
>>>
>>> 3.10-rc2 doesn't seem to work at all - it boots to a black screen every 
>>> time.
>>
>> That otoh is ugly. Could be that though that this is the same (or a
>> similar bug) to your resume issue - in the last few kernel releases
>> we've tried very hard to unify the code between initial driver load at
>> boot-up and resume.
>
> Perhaps I should qualify "at all"
>
> It seems that it fails somewhat late in the boot process. If I remove
> the "boot splash" cli params, I can see it transition into the high
> res mode, and seemingly get into init.
> However, even if I boot to single user mode, the screen goes black.
>
> Unfortunately, both times I tried to test this, and then reboot, I
> ended up at a "grub rescue" prompt, with an unusable system.
>
>>
>> So can you please try to bisect where the boot-up regression has been
>> introduced between 3.8 and 3.10-rc2?
>
> I'm not sure I'll be able to do this.
> With the failure condition I describe above, I am unable to even ssh
> into this machine to debug, nevermind install a new kernel.
> This means I need to generate a new kernel, and install kit with that
> kernel for every bisection test.
>
> This may be more time than I am able to dedicate to this problem - but I'll 
> try.
>
> Ben

It appears I did not CC the list on my last 2 replies.
My apologies - I'll re-paste them below.


I tried to bisect this, but was unsuccessful, in that I didn't seem to
have a reproducible test case to get back into this failure condition.
It seemed that it always would succeed for me...which of course makes
bisecting near impossible.

I tried updating to 3.10-RC3...well, actually to this changeset at the
tip of Linus' tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58f8bbd2e39c3732c55698494338ee19a92c53a0

I can get X to come up now on this machine - albeit very slowly.
Once it comes up, it seems to hang, and respawn

I get a lot of these in the log now, as well:

[  392.195734] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung

Things in the log that look suspicious to me are:
[   34.293452] [drm:intel_pipe_set_base] *ERROR* pin & fence failed
[   34.293486] [drm:intel_crtc_set_config] *ERROR* failed to set mode
on [CRTC:3], err = -28


I get the following errors in the X log, that prevent it from coming up:
[76.142] (EE) intel(0): failed to set mode: No space left on device
[76.142]
Fatal server error:
[76.142] AddScreen/ScreenInit failed for driver 0
[76.142]
[76.142] (EE)



Xorg also crashes in the following manner:


[   218.876] (EE) Backtrace:
[   218.880] (EE) 0: X (xorg_backtrace+0x34) [0x7fe44fff9754]
[   218.880] (EE) 1: X (0x7fe44fe44000+0x1b96a9) [0x7fe44fffd6a9]
[   218.880] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fe44f16a000+0xfcb0) [0x7fe44f179cb0]
[   218.880] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6
(0x7fe44ddcf000+0x148c6b) [0x7fe44df17c6b]
[   218.880] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7fe44cb5a000+0x17c36) [0x7fe44cb71c36]
[   218.880] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7fe44cb5a000+0x19857) [0x7fe44cb73857]
[   218.880] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7fe44cb5a000+0xed429) [0x7fe44cc47429]
[   218.880] (EE) 7: X (0x7fe44fe44000+0x13e8ac) [0x7fe44ff828ac]
[   218.880] (EE) 8: X (0x7fe44fe44000+0x5239e) [0x7fe44fe9639e]
[   218.880] (EE) 9: X (0x7fe44fe44000+0x557a1) [0x7fe44fe997a1]
[   218.880] (EE) 10: X (0x7fe44fe44000+0x4415a) [0x7fe44fe8815a]
[   218.880] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xed) [0x7fe44ddf076d]
[   218.880] (EE) 12: X (0x7fe44fe44000+0x444b1) [0x7fe44fe884b1]
[   218.880] (EE)
[   2

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter  wrote:
> On Tue, May 21, 2013 at 3:44 PM, Ben Guthro  wrote:
>>> This will break kms since now you have the vbios and the linux kms driver
>>> fighting over the same piece of hw. Does
>>>
>>> xset dpms force off
>>> xset dpms force on
>>>
>>> cause similar issues?
>>
>> No, these work as expected (on 3.8)
>> I didn't realize that these broke with KMS. I'll stick with the S3 
>> reproduction.
>
> Ok, so things are at least not terribly broken.
>
>>> If not please make sure that vbetool isn't badly interfering with the
>>> kernel modeset driver on suspend/resume. At least looking at your dmesg
>>> and reg dumps vbe wreaking havoc with the kms driver seems like a rather
>>> likely scenario. Also, can you please test latest 3.10-rc kernels?
>>
>> 3.10-rc2 doesn't seem to work at all - it boots to a black screen every time.
>
> That otoh is ugly. Could be that though that this is the same (or a
> similar bug) to your resume issue - in the last few kernel releases
> we've tried very hard to unify the code between initial driver load at
> boot-up and resume.

Perhaps I should qualify "at all"

It seems that it fails somewhat late in the boot process. If I remove
the "boot splash" cli params, I can see it transition into the high
res mode, and seemingly get into init.
However, even if I boot to single user mode, the screen goes black.

Unfortunately, both times I tried to test this, and then reboot, I
ended up at a "grub rescue" prompt, with an unusable system.

>
> So can you please try to bisect where the boot-up regression has been
> introduced between 3.8 and 3.10-rc2?

I'm not sure I'll be able to do this.
With the failure condition I describe above, I am unable to even ssh
into this machine to debug, nevermind install a new kernel.
This means I need to generate a new kernel, and install kit with that
kernel for every bisection test.

This may be more time than I am able to dedicate to this problem - but I'll try.

Ben

>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Tue, May 21, 2013 at 9:44 AM, Ben Guthro  wrote:
> On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter  wrote:
>> On Fri, May 17, 2013 at 09:26:18AM -0400, Ben Guthro wrote:
>>> On Fri, May 17, 2013 at 7:52 AM, Ben Guthro  wrote:
>>> > On Thu, May 16, 2013 at 9:24 AM, Ben Guthro  wrote:
>>> >> On Wed, May 15, 2013 at 4:42 PM, Ben Guthro  wrote:
>>> >>> On Tue, May 14, 2013 at 5:01 PM, Ben Guthro  wrote:
>>> >>>> I am attempting to debug an issue with some Haswell laptop systems
>>> >>>> which do not restore their screen after resuming from S3 when running
>>> >>>> on the stable 3.8 kernel (3.8.13)
>>> >>>> The backlight is OK, but the screen is just black.
>>> >>>>
>>> >>>> In trying to determine what was going wrong, I tried looking at the
>>> >>>> output of intel_reg_dumper, in a good, and bad case:
>>> >>>>
>>> >>>> diff -u good_reg.txt bad_reg.txt
>>> >>>> --- good_reg.txt2013-05-14 15:08:44.361997000 +
>>> >>>> +++ bad_reg.txt 2013-05-14 15:09:20.48000 +
>>> >>>> @@ -1,5 +1,4 @@
>>> >>>> - DCC: 0x (0xf340
>>> >>>> 0xf37f 0x��
>>> >>>> -� )
>>> >>>> + DCC: 0x (0xf340
>>> >>>> 0xf37f 0x��= � )
>>> >>>> CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
>>> >>>> disabled, ch0 enh disabled, flex disabled, ep not present)
>>> >>>>C0DRB0: 0x (0x)
>>> >>>>C0DRB1: 0x (0x)
>>> >>>> @@ -63,17 +62,17 @@
>>> >>>>   PIPEA_DP_LINK_N: 0x
>>> >>>> CURSOR_A_BASE: 0x01061000
>>> >>>>  CURSOR_A_CONTROL: 0x0427
>>> >>>> -   CURSOR_A_POSITION: 0x03a3032f
>>> >>>> +   CURSOR_A_POSITION: 0x01bb03fb
>>> >>>>  FPA0: 0x (n = 0, m1 = 0, m2 = 0)
>>> >>>>  FPA1: 0x (n = 0, m1 = 0, m2 = 0)
>>> >>>>DPLL_A: 0x (disabled, non-dvo, VGA, default
>>> >>>> clock, unknown mode, p1 = 0, p2 = 0)
>>> >>>> DPLL_A_MD: 0x
>>> >>>> -HTOTAL_A: 0x0821077f (1920 active, 2082 total)
>>> >>>> -HBLANK_A: 0x0821077f (1920 start, 2082 end)
>>> >>>> - HSYNC_A: 0x081307af (1968 start, 2068 end)
>>> >>>> -VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
>>> >>>> -VBLANK_A: 0x045f0437 (1080 start, 1120 end)
>>> >>>> - VSYNC_A: 0x044b0441 (1090 start, 1100 end)
>>> >>>> +HTOTAL_A: 0x (1 active, 1 total)
>>> >>>> +HBLANK_A: 0x (1 start, 1 end)
>>> >>>> + HSYNC_A: 0x (1 start, 1 end)
>>> >>>> +VTOTAL_A: 0x (1 active, 1 total)
>>> >>>> +VBLANK_A: 0x (1 start, 1 end)
>>> >>>> + VSYNC_A: 0x (1 start, 1 end)
>>> >>>> BCLRPAT_A: 0x
>>> >>>>  VSYNCSHIFT_A: 0x
>>> >>>>  DSPBCNTR: 0x4000 (disabled, pipe A)
>>> >>>>
>>> >>>>
>>> >>>> It appears the registers that are saved, and restored in
>>> >>>> i915_save_modeset_reg / i915_restore_modeset_reg is not working
>>> >>>> properly.
>>> >>>>
>>> >>>> When I put some debug in, I discovered that it was bailing out of
>>> >>>> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
>>> >>>> However, it was set at the end of i915_init()
>>> >>>> This, of course, confuses me.
>>> >>>>
>>> >>>> Am I seeing memory corruption here?
>>> >>>
>>> >>> It looks like I misread the code here, inversing an if statement state.
>>> >>>
>>> >>> That said, I don't really have any clues as to why the display

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter  wrote:
> On Fri, May 17, 2013 at 09:26:18AM -0400, Ben Guthro wrote:
>> On Fri, May 17, 2013 at 7:52 AM, Ben Guthro  wrote:
>> > On Thu, May 16, 2013 at 9:24 AM, Ben Guthro  wrote:
>> >> On Wed, May 15, 2013 at 4:42 PM, Ben Guthro  wrote:
>> >>> On Tue, May 14, 2013 at 5:01 PM, Ben Guthro  wrote:
>> >>>> I am attempting to debug an issue with some Haswell laptop systems
>> >>>> which do not restore their screen after resuming from S3 when running
>> >>>> on the stable 3.8 kernel (3.8.13)
>> >>>> The backlight is OK, but the screen is just black.
>> >>>>
>> >>>> In trying to determine what was going wrong, I tried looking at the
>> >>>> output of intel_reg_dumper, in a good, and bad case:
>> >>>>
>> >>>> diff -u good_reg.txt bad_reg.txt
>> >>>> --- good_reg.txt2013-05-14 15:08:44.361997000 +
>> >>>> +++ bad_reg.txt 2013-05-14 15:09:20.48000 +
>> >>>> @@ -1,5 +1,4 @@
>> >>>> - DCC: 0x (0xf340
>> >>>> 0xf37f 0x��
>> >>>> -� )
>> >>>> + DCC: 0x (0xf340
>> >>>> 0xf37f 0x��= � )
>> >>>> CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
>> >>>> disabled, ch0 enh disabled, flex disabled, ep not present)
>> >>>>C0DRB0: 0x (0x)
>> >>>>C0DRB1: 0x (0x)
>> >>>> @@ -63,17 +62,17 @@
>> >>>>   PIPEA_DP_LINK_N: 0x
>> >>>> CURSOR_A_BASE: 0x01061000
>> >>>>  CURSOR_A_CONTROL: 0x0427
>> >>>> -   CURSOR_A_POSITION: 0x03a3032f
>> >>>> +   CURSOR_A_POSITION: 0x01bb03fb
>> >>>>  FPA0: 0x (n = 0, m1 = 0, m2 = 0)
>> >>>>  FPA1: 0x (n = 0, m1 = 0, m2 = 0)
>> >>>>DPLL_A: 0x (disabled, non-dvo, VGA, default
>> >>>> clock, unknown mode, p1 = 0, p2 = 0)
>> >>>> DPLL_A_MD: 0x
>> >>>> -HTOTAL_A: 0x0821077f (1920 active, 2082 total)
>> >>>> -HBLANK_A: 0x0821077f (1920 start, 2082 end)
>> >>>> - HSYNC_A: 0x081307af (1968 start, 2068 end)
>> >>>> -VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
>> >>>> -VBLANK_A: 0x045f0437 (1080 start, 1120 end)
>> >>>> - VSYNC_A: 0x044b0441 (1090 start, 1100 end)
>> >>>> +HTOTAL_A: 0x (1 active, 1 total)
>> >>>> +HBLANK_A: 0x (1 start, 1 end)
>> >>>> + HSYNC_A: 0x (1 start, 1 end)
>> >>>> +VTOTAL_A: 0x (1 active, 1 total)
>> >>>> +VBLANK_A: 0x (1 start, 1 end)
>> >>>> + VSYNC_A: 0x (1 start, 1 end)
>> >>>> BCLRPAT_A: 0x
>> >>>>  VSYNCSHIFT_A: 0x
>> >>>>  DSPBCNTR: 0x4000 (disabled, pipe A)
>> >>>>
>> >>>>
>> >>>> It appears the registers that are saved, and restored in
>> >>>> i915_save_modeset_reg / i915_restore_modeset_reg is not working
>> >>>> properly.
>> >>>>
>> >>>> When I put some debug in, I discovered that it was bailing out of
>> >>>> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
>> >>>> However, it was set at the end of i915_init()
>> >>>> This, of course, confuses me.
>> >>>>
>> >>>> Am I seeing memory corruption here?
>> >>>
>> >>> It looks like I misread the code here, inversing an if statement state.
>> >>>
>> >>> That said, I don't really have any clues as to why the display is
>> >>> black after resuming from S3
>> >
>> > It appears that S3 is not necessary.
>> >
>> > I can reproduce the black screen with just vbetool:
>> > vbetool dpms off
>> > vbetool dpms on
>> >
>> > Does this suggest a bios issue?
>>
>> This can be reliably reproduced on this machine, and worked around by
>> saving the vbestate, and restoring it after the fact:
>>
>> (in a working state)
>> vbetool vbestate save > vbe.save
>>
>> break the system:
>> vbetool dpms off
>> vbetool dpms on
>
> This will break kms since now you have the vbios and the linux kms driver
> fighting over the same piece of hw. Does
>
> xset dpms force off
> xset dpms force on
>
> cause similar issues?

No, these work as expected (on 3.8)
I didn't realize that these broke with KMS. I'll stick with the S3 reproduction.

>
> If not please make sure that vbetool isn't badly interfering with the
> kernel modeset driver on suspend/resume. At least looking at your dmesg
> and reg dumps vbe wreaking havoc with the kms driver seems like a rather
> likely scenario. Also, can you please test latest 3.10-rc kernels?

3.10-rc2 doesn't seem to work at all - it boots to a black screen every time.

Ben

>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Fri, May 17, 2013 at 7:52 AM, Ben Guthro  wrote:
> On Thu, May 16, 2013 at 9:24 AM, Ben Guthro  wrote:
>> On Wed, May 15, 2013 at 4:42 PM, Ben Guthro  wrote:
>>> On Tue, May 14, 2013 at 5:01 PM, Ben Guthro  wrote:
>>>> I am attempting to debug an issue with some Haswell laptop systems
>>>> which do not restore their screen after resuming from S3 when running
>>>> on the stable 3.8 kernel (3.8.13)
>>>> The backlight is OK, but the screen is just black.
>>>>
>>>> In trying to determine what was going wrong, I tried looking at the
>>>> output of intel_reg_dumper, in a good, and bad case:
>>>>
>>>> diff -u good_reg.txt bad_reg.txt
>>>> --- good_reg.txt2013-05-14 15:08:44.361997000 +
>>>> +++ bad_reg.txt 2013-05-14 15:09:20.48000 +
>>>> @@ -1,5 +1,4 @@
>>>> - DCC: 0x (0xf340
>>>> 0xf37f 0x��
>>>> -� )
>>>> + DCC: 0x (0xf340
>>>> 0xf37f 0x��= � )
>>>> CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
>>>> disabled, ch0 enh disabled, flex disabled, ep not present)
>>>>C0DRB0: 0x (0x)
>>>>C0DRB1: 0x (0x)
>>>> @@ -63,17 +62,17 @@
>>>>   PIPEA_DP_LINK_N: 0x
>>>> CURSOR_A_BASE: 0x01061000
>>>>  CURSOR_A_CONTROL: 0x0427
>>>> -   CURSOR_A_POSITION: 0x03a3032f
>>>> +   CURSOR_A_POSITION: 0x01bb03fb
>>>>  FPA0: 0x (n = 0, m1 = 0, m2 = 0)
>>>>  FPA1: 0x (n = 0, m1 = 0, m2 = 0)
>>>>DPLL_A: 0x (disabled, non-dvo, VGA, default
>>>> clock, unknown mode, p1 = 0, p2 = 0)
>>>> DPLL_A_MD: 0x
>>>> -HTOTAL_A: 0x0821077f (1920 active, 2082 total)
>>>> -HBLANK_A: 0x0821077f (1920 start, 2082 end)
>>>> - HSYNC_A: 0x081307af (1968 start, 2068 end)
>>>> -VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
>>>> -VBLANK_A: 0x045f0437 (1080 start, 1120 end)
>>>> - VSYNC_A: 0x044b0441 (1090 start, 1100 end)
>>>> +HTOTAL_A: 0x (1 active, 1 total)
>>>> +HBLANK_A: 0x (1 start, 1 end)
>>>> + HSYNC_A: 0x (1 start, 1 end)
>>>> +VTOTAL_A: 0x (1 active, 1 total)
>>>> +VBLANK_A: 0x (1 start, 1 end)
>>>> + VSYNC_A: 0x (1 start, 1 end)
>>>> BCLRPAT_A: 0x
>>>>  VSYNCSHIFT_A: 0x
>>>>  DSPBCNTR: 0x4000 (disabled, pipe A)
>>>>
>>>>
>>>> It appears the registers that are saved, and restored in
>>>> i915_save_modeset_reg / i915_restore_modeset_reg is not working
>>>> properly.
>>>>
>>>> When I put some debug in, I discovered that it was bailing out of
>>>> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
>>>> However, it was set at the end of i915_init()
>>>> This, of course, confuses me.
>>>>
>>>> Am I seeing memory corruption here?
>>>
>>> It looks like I misread the code here, inversing an if statement state.
>>>
>>> That said, I don't really have any clues as to why the display is
>>> black after resuming from S3
>
> It appears that S3 is not necessary.
>
> I can reproduce the black screen with just vbetool:
> vbetool dpms off
> vbetool dpms on
>
> Does this suggest a bios issue?

This can be reliably reproduced on this machine, and worked around by
saving the vbestate, and restoring it after the fact:

(in a working state)
vbetool vbestate save > vbe.save

break the system:
vbetool dpms off
vbetool dpms on

The following brings the screen back, but in a low resolution corner of X:
vbetool vbestate restore < vbe.save

And then we can get the full resolution back with the following:
xrandr --output eDP1 --off
xrandr --output eDP1 --auto


This is clearly not an ideal solution to make a product out of.

Does this point to a BIOS issue?


Is anyone out there?





>
>
>
>>>
>>> Is this an eDP training issue? Are there any changesets I can try 
>>> backporting?
>>> I tried this, but it didn't seem to help:
>>> https://patchwork.kernel.org/patch/2516601/
>>
>>
>> Below is a serial dump with drm.debug=4, after resuming from S3
>>
>> If anyone sees anything awry, being pointed in the right direction
>> would be appreciated:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Thu, May 16, 2013 at 9:24 AM, Ben Guthro  wrote:
> On Wed, May 15, 2013 at 4:42 PM, Ben Guthro  wrote:
>> On Tue, May 14, 2013 at 5:01 PM, Ben Guthro  wrote:
>>> I am attempting to debug an issue with some Haswell laptop systems
>>> which do not restore their screen after resuming from S3 when running
>>> on the stable 3.8 kernel (3.8.13)
>>> The backlight is OK, but the screen is just black.
>>>
>>> In trying to determine what was going wrong, I tried looking at the
>>> output of intel_reg_dumper, in a good, and bad case:
>>>
>>> diff -u good_reg.txt bad_reg.txt
>>> --- good_reg.txt2013-05-14 15:08:44.361997000 +
>>> +++ bad_reg.txt 2013-05-14 15:09:20.48000 +
>>> @@ -1,5 +1,4 @@
>>> - DCC: 0x (0xf340
>>> 0xf37f 0x��
>>> -� )
>>> + DCC: 0x (0xf340
>>> 0xf37f 0x��= � )
>>> CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
>>> disabled, ch0 enh disabled, flex disabled, ep not present)
>>>C0DRB0: 0x (0x)
>>>C0DRB1: 0x (0x)
>>> @@ -63,17 +62,17 @@
>>>   PIPEA_DP_LINK_N: 0x
>>> CURSOR_A_BASE: 0x01061000
>>>  CURSOR_A_CONTROL: 0x0427
>>> -   CURSOR_A_POSITION: 0x03a3032f
>>> +   CURSOR_A_POSITION: 0x01bb03fb
>>>  FPA0: 0x (n = 0, m1 = 0, m2 = 0)
>>>  FPA1: 0x (n = 0, m1 = 0, m2 = 0)
>>>DPLL_A: 0x (disabled, non-dvo, VGA, default
>>> clock, unknown mode, p1 = 0, p2 = 0)
>>> DPLL_A_MD: 0x
>>> -HTOTAL_A: 0x0821077f (1920 active, 2082 total)
>>> -HBLANK_A: 0x0821077f (1920 start, 2082 end)
>>> - HSYNC_A: 0x081307af (1968 start, 2068 end)
>>> -VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
>>> -VBLANK_A: 0x045f0437 (1080 start, 1120 end)
>>> - VSYNC_A: 0x044b0441 (1090 start, 1100 end)
>>> +HTOTAL_A: 0x (1 active, 1 total)
>>> +HBLANK_A: 0x (1 start, 1 end)
>>> + HSYNC_A: 0x (1 start, 1 end)
>>> +VTOTAL_A: 0x (1 active, 1 total)
>>> +VBLANK_A: 0x (1 start, 1 end)
>>> + VSYNC_A: 0x (1 start, 1 end)
>>> BCLRPAT_A: 0x
>>>  VSYNCSHIFT_A: 0x
>>>  DSPBCNTR: 0x4000 (disabled, pipe A)
>>>
>>>
>>> It appears the registers that are saved, and restored in
>>> i915_save_modeset_reg / i915_restore_modeset_reg is not working
>>> properly.
>>>
>>> When I put some debug in, I discovered that it was bailing out of
>>> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
>>> However, it was set at the end of i915_init()
>>> This, of course, confuses me.
>>>
>>> Am I seeing memory corruption here?
>>
>> It looks like I misread the code here, inversing an if statement state.
>>
>> That said, I don't really have any clues as to why the display is
>> black after resuming from S3

It appears that S3 is not necessary.

I can reproduce the black screen with just vbetool:
vbetool dpms off
vbetool dpms on

Does this suggest a bios issue?



>>
>> Is this an eDP training issue? Are there any changesets I can try 
>> backporting?
>> I tried this, but it didn't seem to help:
>> https://patchwork.kernel.org/patch/2516601/
>
>
> Below is a serial dump with drm.debug=4, after resuming from S3
>
> If anyone sees anything awry, being pointed in the right direction
> would be appreciated:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Wed, May 15, 2013 at 4:42 PM, Ben Guthro  wrote:
> On Tue, May 14, 2013 at 5:01 PM, Ben Guthro  wrote:
>> I am attempting to debug an issue with some Haswell laptop systems
>> which do not restore their screen after resuming from S3 when running
>> on the stable 3.8 kernel (3.8.13)
>> The backlight is OK, but the screen is just black.
>>
>> In trying to determine what was going wrong, I tried looking at the
>> output of intel_reg_dumper, in a good, and bad case:
>>
>> diff -u good_reg.txt bad_reg.txt
>> --- good_reg.txt2013-05-14 15:08:44.361997000 +
>> +++ bad_reg.txt 2013-05-14 15:09:20.48000 +
>> @@ -1,5 +1,4 @@
>> - DCC: 0x (0xf340
>> 0xf37f 0x��
>> -� )
>> + DCC: 0x (0xf340
>> 0xf37f 0x��= � )
>> CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
>> disabled, ch0 enh disabled, flex disabled, ep not present)
>>C0DRB0: 0x (0x)
>>C0DRB1: 0x (0x)
>> @@ -63,17 +62,17 @@
>>   PIPEA_DP_LINK_N: 0x
>> CURSOR_A_BASE: 0x01061000
>>  CURSOR_A_CONTROL: 0x0427
>> -   CURSOR_A_POSITION: 0x03a3032f
>> +   CURSOR_A_POSITION: 0x01bb03fb
>>  FPA0: 0x (n = 0, m1 = 0, m2 = 0)
>>  FPA1: 0x (n = 0, m1 = 0, m2 = 0)
>>DPLL_A: 0x (disabled, non-dvo, VGA, default
>> clock, unknown mode, p1 = 0, p2 = 0)
>> DPLL_A_MD: 0x
>> -HTOTAL_A: 0x0821077f (1920 active, 2082 total)
>> -HBLANK_A: 0x0821077f (1920 start, 2082 end)
>> - HSYNC_A: 0x081307af (1968 start, 2068 end)
>> -VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
>> -VBLANK_A: 0x045f0437 (1080 start, 1120 end)
>> - VSYNC_A: 0x044b0441 (1090 start, 1100 end)
>> +HTOTAL_A: 0x (1 active, 1 total)
>> +HBLANK_A: 0x (1 start, 1 end)
>> + HSYNC_A: 0x (1 start, 1 end)
>> +VTOTAL_A: 0x (1 active, 1 total)
>> +VBLANK_A: 0x (1 start, 1 end)
>> + VSYNC_A: 0x (1 start, 1 end)
>> BCLRPAT_A: 0x
>>  VSYNCSHIFT_A: 0x
>>  DSPBCNTR: 0x4000 (disabled, pipe A)
>>
>>
>> It appears the registers that are saved, and restored in
>> i915_save_modeset_reg / i915_restore_modeset_reg is not working
>> properly.
>>
>> When I put some debug in, I discovered that it was bailing out of
>> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
>> However, it was set at the end of i915_init()
>> This, of course, confuses me.
>>
>> Am I seeing memory corruption here?
>
> It looks like I misread the code here, inversing an if statement state.
>
> That said, I don't really have any clues as to why the display is
> black after resuming from S3
>
> Is this an eDP training issue? Are there any changesets I can try backporting?
> I tried this, but it didn't seem to help:
> https://patchwork.kernel.org/patch/2516601/


Below is a serial dump with drm.debug=4, after resuming from S3

If anyone sees anything awry, being pointed in the right direction
would be appreciated:


[  119.676134] ACPI: Low-level resume complete
[  119.676200] PM: Restoring platform NVS memory
[  119.676585] xen-acpi-processor: Uploading Xen processor PM info
[  119.678302] Enabling non-boot CPUs ...
[  119.678351] installing Xen timer for CPU 1
[  119.678380] cpu 1 spinlock event irq 48
[  119.679469] CPU1 is up
[  119.679496] installing Xen timer for CPU 2
[  119.679505] cpu 2 spinlock event irq 55
[  119.680524] CPU2 is up
[  119.680586] installing Xen timer for CPU 3
[  119.680590] cpu 3 spinlock event irq 62
[  119.681463] CPU3 is up
[  119.681482] installing Xen timer for CPU 4
[  119.681487] cpu 4 spinlock event irq 69
[  119.682448] CPU4 is up
[  119.682478] installing Xen timer for CPU 5
[  119.682482] cpu 5 spinlock event irq 76
[  119.683463] CPU5 is up
[  119.683490] installing Xen timer for CPU 6
[  119.683494] cpu 6 spinlock event irq 83
[  119.684483] CPU6 is up
[  119.684512] installing Xen timer for CPU 7
[  119.684517] cpu 7 spinlock event irq 90
[  119.685523] CPU7 is up
[  119.685941] ACPI: Waking up from system sleep state S3
[  120.546804] pci :01:00.0: power state changed by ACPI to D0
[  120.586931] PM: noirq resume of devices complete after 160.133 msecs
[  120.587261] PM: early resume of devices complete after 0.247 msecs
[  120.587438] xen: registering gs

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

On Tue, May 14, 2013 at 5:01 PM, Ben Guthro  wrote:
> I am attempting to debug an issue with some Haswell laptop systems
> which do not restore their screen after resuming from S3 when running
> on the stable 3.8 kernel (3.8.13)
> The backlight is OK, but the screen is just black.
>
> In trying to determine what was going wrong, I tried looking at the
> output of intel_reg_dumper, in a good, and bad case:
>
> diff -u good_reg.txt bad_reg.txt
> --- good_reg.txt2013-05-14 15:08:44.361997000 +
> +++ bad_reg.txt 2013-05-14 15:09:20.48000 +
> @@ -1,5 +1,4 @@
> - DCC: 0x (0xf340
> 0xf37f 0x��
> -� )
> + DCC: 0x (0xf340
> 0xf37f 0x��= � )
> CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
> disabled, ch0 enh disabled, flex disabled, ep not present)
>C0DRB0: 0x (0x)
>C0DRB1: 0x (0x)
> @@ -63,17 +62,17 @@
>   PIPEA_DP_LINK_N: 0x
> CURSOR_A_BASE: 0x01061000
>  CURSOR_A_CONTROL: 0x0427
> -   CURSOR_A_POSITION: 0x03a3032f
> +   CURSOR_A_POSITION: 0x01bb03fb
>  FPA0: 0x (n = 0, m1 = 0, m2 = 0)
>  FPA1: 0x (n = 0, m1 = 0, m2 = 0)
>DPLL_A: 0x (disabled, non-dvo, VGA, default
> clock, unknown mode, p1 = 0, p2 = 0)
> DPLL_A_MD: 0x
> -HTOTAL_A: 0x0821077f (1920 active, 2082 total)
> -HBLANK_A: 0x0821077f (1920 start, 2082 end)
> - HSYNC_A: 0x081307af (1968 start, 2068 end)
> -VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
> -VBLANK_A: 0x045f0437 (1080 start, 1120 end)
> - VSYNC_A: 0x044b0441 (1090 start, 1100 end)
> +HTOTAL_A: 0x (1 active, 1 total)
> +HBLANK_A: 0x (1 start, 1 end)
> + HSYNC_A: 0x (1 start, 1 end)
> +VTOTAL_A: 0x (1 active, 1 total)
> +VBLANK_A: 0x (1 start, 1 end)
> + VSYNC_A: 0x (1 start, 1 end)
> BCLRPAT_A: 0x
>  VSYNCSHIFT_A: 0x
>  DSPBCNTR: 0x4000 (disabled, pipe A)
>
>
> It appears the registers that are saved, and restored in
> i915_save_modeset_reg / i915_restore_modeset_reg is not working
> properly.
>
> When I put some debug in, I discovered that it was bailing out of
> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
> However, it was set at the end of i915_init()
> This, of course, confuses me.
>
> Am I seeing memory corruption here?

It looks like I misread the code here, inversing an if statement state.

That said, I don't really have any clues as to why the display is
black after resuming from S3

Is this an eDP training issue? Are there any changesets I can try backporting?
I tried this, but it didn't seem to help:
https://patchwork.kernel.org/patch/2516601/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] debugging Haswell eDP black screen after S3

[Ben Guthro]

I am attempting to debug an issue with some Haswell laptop systems
which do not restore their screen after resuming from S3 when running
on the stable 3.8 kernel (3.8.13)
The backlight is OK, but the screen is just black.

In trying to determine what was going wrong, I tried looking at the
output of intel_reg_dumper, in a good, and bad case:

diff -u good_reg.txt bad_reg.txt
--- good_reg.txt2013-05-14 15:08:44.361997000 +
+++ bad_reg.txt 2013-05-14 15:09:20.48000 +
@@ -1,5 +1,4 @@
- DCC: 0x (0xf340
0xf37f 0x��
-�)
+ DCC: 0x (0xf340
0xf37f 0x��=�)
CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh
disabled, ch0 enh disabled, flex disabled, ep not present)
   C0DRB0: 0x (0x)
   C0DRB1: 0x (0x)
@@ -63,17 +62,17 @@
  PIPEA_DP_LINK_N: 0x
CURSOR_A_BASE: 0x01061000
 CURSOR_A_CONTROL: 0x0427
-   CURSOR_A_POSITION: 0x03a3032f
+   CURSOR_A_POSITION: 0x01bb03fb
 FPA0: 0x (n = 0, m1 = 0, m2 = 0)
 FPA1: 0x (n = 0, m1 = 0, m2 = 0)
   DPLL_A: 0x (disabled, non-dvo, VGA, default
clock, unknown mode, p1 = 0, p2 = 0)
DPLL_A_MD: 0x
-HTOTAL_A: 0x0821077f (1920 active, 2082 total)
-HBLANK_A: 0x0821077f (1920 start, 2082 end)
- HSYNC_A: 0x081307af (1968 start, 2068 end)
-VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
-VBLANK_A: 0x045f0437 (1080 start, 1120 end)
- VSYNC_A: 0x044b0441 (1090 start, 1100 end)
+HTOTAL_A: 0x (1 active, 1 total)
+HBLANK_A: 0x (1 start, 1 end)
+ HSYNC_A: 0x (1 start, 1 end)
+VTOTAL_A: 0x (1 active, 1 total)
+VBLANK_A: 0x (1 start, 1 end)
+ VSYNC_A: 0x (1 start, 1 end)
BCLRPAT_A: 0x
 VSYNCSHIFT_A: 0x
 DSPBCNTR: 0x4000 (disabled, pipe A)


It appears the registers that are saved, and restored in
i915_save_modeset_reg / i915_restore_modeset_reg is not working
properly.

When I put some debug in, I discovered that it was bailing out of
i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
However, it was set at the end of i915_init()
This, of course, confuses me.

Am I seeing memory corruption here?


Any insight is appreciated.

Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Xen-devel] eDP screen corruption using linux 3.8 & xen 4.2

[Ben Guthro]

Adding intel-gfx to this thread in the hopes that someone there might have
some ideas since the fengzhe.zh...@intel.com address was bouncing.

Thread origins, for that list's reference:
http://markmail.org/thread/m4jhronecq4fvyk6



On Tue, Mar 5, 2013 at 11:42 AM, Jan Beulich  wrote:

> >>> On 05.03.13 at 17:33, Ben Guthro  wrote:
> > I turned up the debug, but didn't see this
> > I am seeing other oops messages in the log now though...not sure if these
> > are related.
>
> The first one likely is related (rax being 00aa00aa and
> apparently used as memory address, and that value very much
> looks like 2 pixels from a 32-bit pixel map). So I'd guess that
> there's once again some physical/machine address mixup.
>
> Jan
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm

[Ben Guthro]

On Wed, Nov 7, 2012 at 2:43 PM, Ben Guthro  wrote:
>>
>>
>> There seems to be a mismatch for these IRQ delivery - or at least exhibits 
>> the behavior similar to such a problem.
>>
>
> I was mistaken here. The i8042 IRQ would just start up the IRQ handling - but 
> the i915 driver always thinks it has pending work, and schedules it.
> It seems that the hotplug mask is not getting cleared in pch_iir (in 
> i915_irq.c)
>
> Manually clearing this bit with
> pch_iir = pch_iir ^ hotplug_mask;
> in the ironlake_irq_handler() function
>
> seems to resolve the issue - making it so I don't get the flurry of hotplug 
> work bogging down the system.
> ...but is this disabling hotplug detection entirely?
>
>

The attached patch  seems to resolve the issue of the interrupt storm
after S3 for this Ibex Peak PCH system.
Could someone comment on whether this will have any unintended side effects?



diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32e1bda..d8f2f79 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -802,8 +802,13 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)

/* check event from PCH */
if (de_iir & DE_PCH_EVENT) {
-   if (pch_iir & hotplug_mask)
+   if (pch_iir & hotplug_mask) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
+
+   if (!HAS_PCH_CPT(dev))
+   pch_iir = pch_iir ^ SDE_HOTPLUG_MASK;
+   }
+
if (HAS_PCH_CPT(dev))
cpt_irq_handler(dev, pch_iir);
else


hotplug.patch
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm

[Ben Guthro]

On Wed, Nov 7, 2012 at 11:22 AM, Ben Guthro  wrote:

> I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) -
> that has an i3 processor (M330) - and intel graphics.
> This is running under Xen-unstable, and a 3.7-rc4 pvops kernel - but can
> also be reproduced using kernels as old as 3.2.23 - and hypervisors as old
> as 4.0.4
>
> (I have cross posted here, because I am not yet sure if this is a Xen,
> pvops, or i915 issue - and would appreciate opinions in sorting it out.)
>
>
This appears to be unrelated to Xen / pvops, at the moment, after some
additional debugging, and appears to be an issue with the i915 driver with
older hardware.
I'll remove xen-devel, and Konrad from future replies to this thread.



>
> Additionally, this same trace stack is printed out at a regular 10s
> interval, after resume - where prior to resuming from S3 it is printed out
> once at boot time.
>
>
10*HZ seems to be the normal hotplug interval, when an interrupt doesn't
fire


>
> There seems to be a mismatch for these IRQ delivery - or at least exhibits
> the behavior similar to such a problem.
>
>
I was mistaken here. The i8042 IRQ would just start up the IRQ handling -
but the i915 driver always thinks it has pending work, and schedules it.
It seems that the hotplug mask is not getting cleared in pch_iir (in
i915_irq.c)

Manually clearing this bit with
pch_iir = pch_iir ^ hotplug_mask;
in the ironlake_irq_handler() function

seems to resolve the issue - making it so I don't get the flurry of hotplug
work bogging down the system.
...but is this disabling hotplug detection entirely?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm

[Ben Guthro]

I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) -
that has an i3 processor (M330) - and intel graphics.
This is running under Xen-unstable, and a 3.7-rc4 pvops kernel - but can
also be reproduced using kernels as old as 3.2.23 - and hypervisors as old
as 4.0.4

(I have cross posted here, because I am not yet sure if this is a Xen,
pvops, or i915 issue - and would appreciate opinions in sorting it out.)

The symptoms of the problem exhibit themselves by a lagging mouse in X11
after resume, when using the trackpad.

After digging in a bit, the problem seems a bit more insidious - the i915
kworker responsible for hotplug detection (i915_hotplug_work_func) seems to
be getting triggered for every PS2 IRQ - every trackpad mouse movement, and
keypress triggers tracing (with drm.debug=0x06) like the following:

Nov 6 21:41:58 rusting kernel: [ 263.924454] [drm:i915_hotplug_work_func],
running encoder hotplug functions
Nov 6 21:41:58 rusting kernel: [ 263.924468]
[drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40018,
result 0
Nov 6 21:41:58 rusting kernel: [ 263.924472] [drm:intel_crt_detect], CRT
not detected via hotplug
Nov 6 21:41:58 rusting kernel: [ 263.924475] [drm:output_poll_execute],
[CONNECTOR:11:VGA-1] status updated from 2 to 2
Nov 6 21:41:58 rusting kernel: [ 263.926771] [drm:drm_do_probe_ddc_edid],
drm: skipping non-existent adapter i915 gmbus dpc
Nov 6 21:41:58 rusting kernel: [ 263.926775] [drm:output_poll_execute],
[CONNECTOR:14:HDMI-A-1] status updated from 2 to 2
Nov 6 21:41:58 rusting kernel: [ 263.927291] [drm:intel_dp_aux_ch],
dp_aux_ch timeout status 0x5145003e
Nov 6 21:41:58 rusting kernel: [ 263.944207] [drm:intel_dp_aux_ch],
dp_aux_ch timeout status 0x5145003e
Nov 6 21:41:58 rusting kernel: [ 263.964201] [drm:intel_dp_aux_ch],
dp_aux_ch timeout status 0x5145003e
Nov 6 21:41:58 rusting kernel: [ 263.983694] [drm:intel_dp_detect], DPCD:

Nov 6 21:41:58 rusting kernel: [ 263.983704] [drm:output_poll_execute],
[CONNECTOR:17:DP-1] status updated from 2 to 2

Additionally, this same trace stack is printed out at a regular 10s
interval, after resume - where prior to resuming from S3 it is printed out
once at boot time.

This kworker consumes a significant portion of the cpu, and essentially
grinds Xorg to a halt, until the probing can catch up with the user moving
the cursor.


There seems to be a mismatch for these IRQ delivery - or at least exhibits
the behavior similar to such a problem.


Does anyone have any thoughts as to where in the software stack I should
start to dig in?
Any opinions on which component likely contains the issue is appreciated.


/btg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] assertion on intel_disable_transcoder

[Ben Guthro]

FWIW, I am able to get graphics on the screen now - Apparently only the
hdmi port works on HSW right now - which I was unaware of.
This stack was a red-herring to that problem.

Thanks for the response.

Ben

On Thu, Sep 27, 2012 at 2:34 AM, Daniel Vetter  wrote:

> On Thu, Sep 27, 2012 at 06:32:06AM +, Wang, Xingchao wrote:
> > Hi Ben,
> >
> > I have no idea about the resolution, maybe Paulo and Daniel know more
> details?
>
> Oh, it's just an older assert for pre-hsw that we haven't properly
> disabled yet. Since this code will change quite a bit with Paulo's new
> way of handling ddi/fdi on haswell, we somehow never bothered with the
> real fix. Should be quite as soon as Paulo's patchbomb lands.
> -Daniel
>
> >
> > Thanks
> > --xingchao
> >
> > From: ben.gut...@gmail.com [mailto:ben.gut...@gmail.com] On Behalf Of
> Ben Guthro
> > Sent: Wednesday, September 26, 2012 4:43 AM
> > To: Wang, Xingchao
> > Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R; Fu, Michael; Wu,
> Fengguang
> > Subject: Re: [Intel-gfx] assertion on intel_disable_transcoder
> >
> > I am seeing this same trace (and no video) on multiple Haswell SDP's,
> with 3.6-rc7 (and earlier kernels)
> >
> > Was there ever a resolution on this?
> >
> >
> >
> > On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao  <mailto:xingchao.w...@intel.com>> wrote:
> > Hi,
> >
> > Some update related to this warning.
> > Ironlake_crtc_dpms() will enable/disable crtc which pipe was
> enabled/disabled there.
> > Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and
> crtc was disabled, that causes intel_wait_for_vblank() timeout and some
> assertions.
> >
> > I think it's a bug but I have no clue where/when to enable crtc again.
> >
> > Here's part of dmesg before the warning and the message showing dpms off.
> >
> > [   19.332220] [drm:intel_lvds_init], LVDS is not present in VBT
> > [   19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4
> > [   19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B
> > [   19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
> > [   19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> > [   19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
> > [   19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> > [   19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off
> > [   19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
> > [   19.351826] [ cut here ]
> > [   19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
> assert_fdi_tx+0x87/0x90 [i915]()
> > [   19.351849] Hardware name: Shark Bay Client platform
> > [   19.351850] FDI TX state assertion failure (expected off, current on)
> > [   19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek
> snd_hda_codec_hdmi drm_kms_helper
> >  drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel
> snd_seq_midi snd_rawmidi snd_s
> > eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830
> psmouse snd_seq_device usbnet
> >  snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc
> lpc_ich microcode mac_hid video
> >  lp parport e1000e usbhid hid
> > [   19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+
> #29
> > [   19.351870] Call Trace:
> > [   19.351876]  [] warn_slowpath_common+0x7f/0xc0
> >
> > thanks
> > --xingchao
> >
> >
> > > -Original Message-
> > > From: Wang, Xingchao
> > > Sent: Tuesday, August 07, 2012 3:26 PM
> > > To: Daniel Vetter; Zanoni, Paulo R
> > > Cc: intel-gfx@lists.freedesktop.org intel-gfx@lists.freedesktop.org>; Fu, Michael; Wu, Fengguang; 'Zhenyu
> > > Wang (zhen...@linux.intel.com<mailto:zhen...@linux.intel.com>)';
> Zhao, Yakui
> > > Subject: assertion on intel_disable_transcoder
> > >
> > > Hi Daniel/Paulo,
> > >
> > > It's easy to see such WARNING in dmesg, the DDI port is not disabled
> prior to
> > > disable transcoder.
> > > I am not sure it will impact the Pipe/transcoder/DDI-port
> configurations,
> > > anyway after some times WARNING, I could not make HDMI audio work
> > > anymore.
> > > With intel_audio_dump I could see the related configurations was
> totally
> > > disabled.
> > >
> > > DDI_BUF_CTL_A 0x0080  DDI Buffer Controler A
> > > DDI_BUF_CTL_B 0x  DD

Re: [Intel-gfx] assertion on intel_disable_transcoder

[Ben Guthro]

I am seeing this same trace (and no video) on multiple Haswell SDP's, with
3.6-rc7 (and earlier kernels)

Was there ever a resolution on this?



On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao wrote:

> Hi,
>
> Some update related to this warning.
> Ironlake_crtc_dpms() will enable/disable crtc which pipe was
> enabled/disabled there.
> Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and
> crtc was disabled, that causes intel_wait_for_vblank() timeout and some
> assertions.
>
> I think it's a bug but I have no clue where/when to enable crtc again.
>
> Here's part of dmesg before the warning and the message showing dpms off.
>
> [   19.332220] [drm:intel_lvds_init], LVDS is not present in VBT
> [   19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4
> [   19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B
> [   19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
> [   19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> [   19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
> [   19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> [   19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off
> [   19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
> [   19.351826] [ cut here ]
> [   19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
> assert_fdi_tx+0x87/0x90 [i915]()
> [   19.351849] Hardware name: Shark Bay Client platform
> [   19.351850] FDI TX state assertion failure (expected off, current on)
> [   19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek
> snd_hda_codec_hdmi drm_kms_helper
>  drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel
> snd_seq_midi snd_rawmidi snd_s
> eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830
> psmouse snd_seq_device usbnet
>  snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc
> lpc_ich microcode mac_hid video
>  lp parport e1000e usbhid hid
> [   19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+ #29
> [   19.351870] Call Trace:
> [   19.351876]  [] warn_slowpath_common+0x7f/0xc0
>
> thanks
> --xingchao
>
>
> > -Original Message-
> > From: Wang, Xingchao
> > Sent: Tuesday, August 07, 2012 3:26 PM
> > To: Daniel Vetter; Zanoni, Paulo R
> > Cc: intel-gfx@lists.freedesktop.org; Fu, Michael; Wu, Fengguang; 'Zhenyu
> > Wang (zhen...@linux.intel.com)'; Zhao, Yakui
> > Subject: assertion on intel_disable_transcoder
> >
> > Hi Daniel/Paulo,
> >
> > It's easy to see such WARNING in dmesg, the DDI port is not disabled
> prior to
> > disable transcoder.
> > I am not sure it will impact the Pipe/transcoder/DDI-port configurations,
> > anyway after some times WARNING, I could not make HDMI audio work
> > anymore.
> > With intel_audio_dump I could see the related configurations was totally
> > disabled.
> >
> > DDI_BUF_CTL_A 0x0080  DDI Buffer Controler A
> > DDI_BUF_CTL_B 0x  DDI Buffer Controler B
> > DDI_BUF_CTL_C 0x0080  DDI Buffer Controler C
> > DDI_BUF_CTL_D 0x  DDI Buffer Controler D
> > DDI_BUF_CTL_E 0x8002  DDI Buffer Controler E
> > PIPE_CONF_A   0x  PIPE Configuration A
> > PIPE_CONF_B   0x  PIPE Configuration B
> > PIPE_CONF_C   0x  PIPE Configuration C
> > PIPE_CONF_EDP 0x  PIPE Configuration EDP
> > PIPE_DDI_FUNC_CTL_A   0xc4034002  PIPE DDI Function Control A
> > PIPE_DDI_FUNC_CTL_B   0xa0035000  PIPE DDI Function Control B
> > PIPE_DDI_FUNC_CTL_C   0x0003  PIPE DDI Function Control C
> > PIPE_DDI_FUNC_CTL_EDP 0x0003  PIPE DDI Function Control EDP
> > TRANS_CONF0x  Transcoder Configuration
> >
> > Thanks
> > --xingchao
> >
> > [   16.835658] [ cut here ]
> > [   16.835690] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
> > assert_fdi_tx+0x87/0x90 [i915]()
> > [   16.835691] Hardware name: Shark Bay Client platform
> > [   16.835692] FDI TX state assertion failure (expected off, current on)
> > [   16.835706] Modules linked in: snd_seq_midi_event i915(+) snd_seq
> > snd_timer drm_kms_helper snd_seq
> > _device ghash_clmulni_intel drm aesni_intel snd cryptd mcs7830 usbnet
> joydev
> > aes_x86_64 soundcore psm ouse snd_page_alloc hid_generic i2c_algo_bit
> > serio_raw video mac_hid microcode lpc_ich lp parport e10 00e usbhid hid
> > [   16.835708] Pid: 470, comm: modprobe Not tainted 3.5.0-rc46patches+
> #12
> > [   16.835709] Call Trace:
> > [   16.835715]  [] warn_slowpath_common+0x7f/0xc0
> > [   16.835718]  [] warn_slowpath_fmt+0x46/0x50
> > [   16.835728]  [] assert_fdi_tx+0x87/0x90 [i915]
> > [   16.835739]  [] ironlake_crtc_disable+0x185/0x820
> [i915]
> > [   16.835748]  [] ironlake_crtc_dpms+0x8e/0xa0 [i915]
> > [   16.835756]  [] intel_crtc_dpms+0x48/0x140 [i915]
> > [   16.835768]  [] intel_crtc_disable+0x35/0xb0 [i915]
> > [   16.835772]  []
> > drm_he

Re: [Intel-gfx] v3.6 haswell regression from v3.5?

[Ben Guthro]

I'm struggling to get back to a version that works on the Shark Bay /
Haswell platform that I have.

I did get it to work once...but have since updated the BIOS, so am not
sure if that may have an effect on this test.

v3.5 also gave a stack (below) - so without a working version, I
cannot do the bisecting.

Perhaps it is just too early in the Haswell dev cycle for me to try to
get this working?



[   16.599822] [ cut here ]
[   16.605099] WARNING: at
/data/home/bguthro/dev/newdev-tip/linux-3.5/drivers/gpu/drm/i915/intel_display.c:976
assert_fdi_tx+0x87/0x90 [i915]()
[   16.619568] Hardware name: Shark Bay Client platform
[   16.625244] FDI TX state assertion failure (expected off, current on)
[   16.632632] Modules linked in: ahci(+) libahci crc32c_intel
e1000e(+) ehci_hcd(+) i915(+) drm_kms_helper drm i2c_algo_bit video
xhci_hcd intel_agp intel_gtt
[   16.648576] Pid: 142, comm: modprobe Not tainted 3.5.0-orc #14
[   16.655275] Call Trace:
[   16.658130]  [] warn_slowpath_common+0x7f/0xc0
[   16.665023]  [] warn_slowpath_fmt+0x46/0x50
[   16.665058] usb 1-11: new low-speed USB device number 2 using xhci_hcd
[   16.679111]  [] assert_fdi_tx+0x87/0x90 [i915]
[   16.686001]  [] ironlake_crtc_disable+0x185/0x820 [i915]
[   16.689451] usb 1-11: ep 0x81 - rounding interval to 64
microframes, ep desc says 80 microframes
[   16.703942]  [] ironlake_crtc_dpms+0x8e/0xa0 [i915]
[   16.711309]  [] intel_crtc_dpms+0x48/0x140 [i915]
[   16.718487]  [] intel_crtc_disable+0x35/0xb0 [i915]
[   16.721916] usbcore: registered new interface driver usbhid
[   16.721917] usbhid: USB HID core driver
[   16.736714]  []
drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper]
[   16.746959]  [] intel_modeset_init+0x687/0xe50 [i915]
[   16.754536]  [] i915_driver_load+0xa9a/0xb80 [i915]
[   16.761932]  [] ? drm_get_minor+0x26b/0x310 [drm]
[   16.769086]  [] drm_get_pci_dev+0x191/0x2b0 [drm]
[   16.776278]  [] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   16.784065]  [] i915_pci_probe+0x1b/0x1d [i915]
[   16.791041]  [] pci_device_probe+0xb0/0x140
[   16.797631]  [] driver_probe_device+0x7e/0x220
[   16.804527]  [] __driver_attach+0xab/0xb0
[   16.810929]  [] ? driver_probe_device+0x220/0x220
[   16.818106]  [] bus_for_each_dev+0x56/0x90
[   16.824609]  [] driver_attach+0x1e/0x20
[   16.830814]  [] bus_add_driver+0x1a0/0x270
[   16.837305]  [] driver_register+0x76/0x130
[   16.843805]  [] __pci_register_driver+0x55/0xd0
[   16.850795]  [] ? notifier_call_chain+0x4d/0x70
[   16.857786]  [] drm_pci_init+0x11a/0x130 [drm]
[   16.859591] usb 1-12: new low-speed USB device number 3 using xhci_hcd
[   16.872169]  [] ? 0xa0115fff
[   16.878075]  [] i915_init+0x8b/0x8d [i915]
[   16.884568]  [] do_one_initcall+0x3f/0x170
[   16.887716] usb 1-12: ep 0x81 - rounding interval to 128
microframes, ep desc says 192 microframes
[   16.901316]  [] sys_init_module+0x8f/0x200
[   16.907797]  [] system_call_fastpath+0x16/0x1b
[   16.914692] ---[ end trace 941488b1333d181e ]---



On Fri, Aug 10, 2012 at 10:21 PM, Ben Guthro  wrote:
> I'll try to do this early next week, and report back.
>
>
> On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky  wrote:
>> On 2012-08-10 09:25, Ben Guthro wrote:
>>>
>>> Hello, I've been attempting to get a Shark Bay / Haswell platform up &
>>> running, and have been having some difficulties that I'm hoping you
>>> all can possibly help with.
>>>
>>> I first tried the 3.5 kernel, and had some success after applying the
>>> following patch:
>>> https://patchwork.kernel.org/patch/1229541/
>>>
>>> This seemed to be necessary to get the  0x0c26 PCI id to be loaded by
>>> i915, and use KMS.
>>>
>>> After doing this, I had some success, but things still would become
>>> unstable, and flash test patterns on the screen about every third
>>> boot.
>>>
>>>
>>> I figured that I would move on to the tip, and see if that fixed anything.
>>>
>>> However, at the tip, I cannot get i915 to display graphics at all -
>>> even with applying the patch above.
>>>
>>>
>>> I understand that this is still under development - but this seems
>>> like a regression from 3.5
>>> Is there a codebase that I should be using for this testing?
>>>
>>
>> Yes it is the codebase you should use. It sounds like a regression, can you
>> bisect it?
>>
>>
>>>
>>> Ben
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>> --
>> Ben Widawsky, Intel Open Source Technology Center
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] v3.6 haswell regression from v3.5?

[Ben Guthro]

I'll try to do this early next week, and report back.


On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky  wrote:
> On 2012-08-10 09:25, Ben Guthro wrote:
>>
>> Hello, I've been attempting to get a Shark Bay / Haswell platform up &
>> running, and have been having some difficulties that I'm hoping you
>> all can possibly help with.
>>
>> I first tried the 3.5 kernel, and had some success after applying the
>> following patch:
>> https://patchwork.kernel.org/patch/1229541/
>>
>> This seemed to be necessary to get the  0x0c26 PCI id to be loaded by
>> i915, and use KMS.
>>
>> After doing this, I had some success, but things still would become
>> unstable, and flash test patterns on the screen about every third
>> boot.
>>
>>
>> I figured that I would move on to the tip, and see if that fixed anything.
>>
>> However, at the tip, I cannot get i915 to display graphics at all -
>> even with applying the patch above.
>>
>>
>> I understand that this is still under development - but this seems
>> like a regression from 3.5
>> Is there a codebase that I should be using for this testing?
>>
>
> Yes it is the codebase you should use. It sounds like a regression, can you
> bisect it?
>
>
>>
>> Ben
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
> --
> Ben Widawsky, Intel Open Source Technology Center
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] v3.6 haswell regression from v3.5?

[Ben Guthro]

well...it gave me a different stack...but still no graphics:

This is with the drm-intel-fixes branch merged in - I thought that
branch might help...but it didn't seem to.


[   16.615950] [ cut here ]
[   16.621229] WARNING: at
/data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1119
assert_fdi_tx+0x87/0x90 [i915]()
[   16.635796] Hardware name: Shark Bay Client platform
[   16.641472] FDI TX state assertion failure (expected off, current on)
[   16.648863] Modules linked in: crc32c_intel ahci(+) libahci
ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp
i2c_algo_bit intel_gtt video xhci_hcd
[   16.664808] Pid: 141, comm: modprobe Not tainted 3.6.0-orc #11
[   16.671503] Call Trace:
[   16.674364]  [] warn_slowpath_common+0x7f/0xc0
[   16.681250]  [] warn_slowpath_fmt+0x46/0x50
[   16.681305] usb 1-5: new low-speed USB device number 2 using xhci_hcd
[   16.695251]  [] assert_fdi_tx+0x87/0x90 [i915]
[   16.702135]  [] ironlake_crtc_disable+0x185/0x820 [i915]
[   16.710013]  [] ironlake_crtc_dpms+0x8e/0xa0 [i915]
[   16.711864] usb 1-5: ep 0x81 - rounding interval to 64 microframes,
ep desc says 80 microframes
[   16.727384]  [] intel_crtc_dpms+0x48/0x140 [i915]
[   16.734590]  [] intel_crtc_disable+0x35/0xb0 [i915]
[   16.741932]  []
drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper]
[   16.751668] usbcore: registered new interface driver usbhid
[   16.751669] usbhid: USB HID core driver
[   16.763019]  [] intel_modeset_init+0x6b7/0xf10 [i915]
[   16.770594]  [] i915_driver_load+0xa8a/0xb90 [i915]
[   16.777977]  [] ? drm_get_minor+0x26b/0x310 [drm]
[   16.785143]  [] drm_get_pci_dev+0x191/0x2b0 [drm]
[   16.792337]  [] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   16.800125]  [] i915_pci_probe+0x4f/0x57 [i915]
[   16.807096]  [] pci_device_probe+0xb0/0x140
[   16.813689]  [] driver_probe_device+0x7b/0x240
[   16.820582]  [] __driver_attach+0xab/0xb0
[   16.826984]  [] ? driver_probe_device+0x240/0x240
[   16.834163]  [] bus_for_each_dev+0x56/0x90
[   16.840664]  [] driver_attach+0x1e/0x20
[   16.840694] usb 1-6: new low-speed USB device number 3 using xhci_hcd
[   16.854251]  [] bus_add_driver+0x190/0x290
[   16.860748]  [] driver_register+0x7a/0x160
[   16.867247]  [] __pci_register_driver+0x55/0xd0
[   16.868830] usb 1-6: ep 0x81 - rounding interval to 128
microframes, ep desc says 192 microframes
[   16.884396]  [] ? notifier_call_chain+0x4d/0x70
[   16.891397]  [] drm_pci_init+0x11a/0x130 [drm]
[   16.898260]  [] ? 0xa0124fff
[   16.904172]  [] i915_init+0x66/0x68 [i915]
[   16.910666]  [] do_one_initcall+0x3f/0x170
[   16.917167]  [] sys_init_module+0x8f/0x200
[   16.923652]  [] system_call_fastpath+0x16/0x1b
[   16.930548] ---[ end trace fa81da3bacf4c4b0 ]---

On Fri, Aug 10, 2012 at 1:16 PM, Daniel Vetter  wrote:
> On Fri, Aug 10, 2012 at 12:51:42PM -0400, Ben Guthro wrote:
>> specifically, I get the following in my serial console - it is a
>> warning...but seems to coincide with when standard vesa modes are
>> switching over to the higer res KMS modes:
>
> Can you try to boot with i915.i915_enable_rc6=0 please?
> -Daniel
>
>>
>> [   15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake
>> wait timed out
>> [   15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [   15.905161] [drm] Driver supports precise vblank timestamp query.
>> [   15.912293] vgaarb: device changed decodes:
>> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>> [   15.943700] [ cut here ]
>> [   15.949041] WARNING: at
>> /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118
>> assert_fdi_tx+0x87/0x90 [i915]()
>> [   15.963591] Hardware name: Shark Bay Client platform
>> [   15.969288] FDI TX state assertion failure (expected off, current on)
>> [   15.976678] Modules linked in: crc32c_intel ahci(+) libahci
>> ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp
>> i2c_algo_bit intel_gtt video xhci_hcd
>> [   15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9
>> [   15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd
>> [   16.006609] Call Trace:
>> [   16.009462]  [] warn_slowpath_common+0x7f/0xc0
>> [   16.016356]  [] warn_slowpath_fmt+0x46/0x50
>> [   16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes,
>> ep desc says 80 microframes
>> [   16.032989]  [] assert_fdi_tx+0x87/0x90 [i915]
>> [   16.040070]  [] ironlake_crtc_disable+0x185/0x820 [i915]
>> [   16.047923]  [] ironlake_crtc_dpms+0x8e/0xa0 [i915]
>> [   16.055302]  [] intel_crtc_dpms+0x48/0x140 [i915]
>> [   16.061100] usbcore: registered new interface driver usbhid
>> [   16.061101] usbhid: USB HID core driver
>> [  

Re: [Intel-gfx] v3.6 haswell regression from v3.5?

[Ben Guthro]

specifically, I get the following in my serial console - it is a
warning...but seems to coincide with when standard vesa modes are
switching over to the higer res KMS modes:

[   15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake
wait timed out
[   15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   15.905161] [drm] Driver supports precise vblank timestamp query.
[   15.912293] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   15.943700] [ cut here ]
[   15.949041] WARNING: at
/data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118
assert_fdi_tx+0x87/0x90 [i915]()
[   15.963591] Hardware name: Shark Bay Client platform
[   15.969288] FDI TX state assertion failure (expected off, current on)
[   15.976678] Modules linked in: crc32c_intel ahci(+) libahci
ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp
i2c_algo_bit intel_gtt video xhci_hcd
[   15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9
[   15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd
[   16.006609] Call Trace:
[   16.009462]  [] warn_slowpath_common+0x7f/0xc0
[   16.016356]  [] warn_slowpath_fmt+0x46/0x50
[   16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes,
ep desc says 80 microframes
[   16.032989]  [] assert_fdi_tx+0x87/0x90 [i915]
[   16.040070]  [] ironlake_crtc_disable+0x185/0x820 [i915]
[   16.047923]  [] ironlake_crtc_dpms+0x8e/0xa0 [i915]
[   16.055302]  [] intel_crtc_dpms+0x48/0x140 [i915]
[   16.061100] usbcore: registered new interface driver usbhid
[   16.061101] usbhid: USB HID core driver
[   16.073325]  [] intel_crtc_disable+0x35/0xb0 [i915]
[   16.080700]  []
drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper]
[   16.090943]  [] intel_modeset_init+0x6b7/0xf10 [i915]
[   16.098525]  [] i915_driver_load+0xa8a/0xb90 [i915]
[   16.105913]  [] ? drm_get_minor+0x26b/0x310 [drm]
[   16.113082]  [] drm_get_pci_dev+0x191/0x2b0 [drm]
[   16.120276]  [] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   16.128061]  [] i915_pci_probe+0x4f/0x57 [i915]
[   16.135039]  [] pci_device_probe+0xb0/0x140
[   16.141631]  [] driver_probe_device+0x7b/0x240
[   16.148525]  [] __driver_attach+0xab/0xb0
[   16.154927]  [] ? driver_probe_device+0x240/0x240
[   16.162106]  [] bus_for_each_dev+0x56/0x90
[   16.168607]  [] driver_attach+0x1e/0x20
[   16.174811]  [] bus_add_driver+0x190/0x290
[   16.181303]  [] driver_register+0x7a/0x160
[   16.187805]  [] __pci_register_driver+0x55/0xd0
[   16.193436] usb 1-6: new low-speed USB device number 3 using xhci_hcd
[   16.202180]  [] ? notifier_call_chain+0x4d/0x70
[   16.209173]  [] drm_pci_init+0x11a/0x130 [drm]
[   16.216061]  [] ? 0xa0124fff
[   16.221970]  [] i915_init+0x66/0x68 [i915]
[   16.223558] usb 1-6: ep 0x81 - rounding interval to 128
microframes, ep desc says 192 microframes
[   16.238617]  [] do_one_initcall+0x3f/0x170
[   16.245104]  [] sys_init_module+0x8f/0x200
[   16.251599]  [] system_call_fastpath+0x16/0x1b
[   16.258494] ---[ end trace 949ccd38b0452265 ]---




On Fri, Aug 10, 2012 at 12:25 PM, Ben Guthro  wrote:
> Hello, I've been attempting to get a Shark Bay / Haswell platform up &
> running, and have been having some difficulties that I'm hoping you
> all can possibly help with.
>
> I first tried the 3.5 kernel, and had some success after applying the
> following patch:
> https://patchwork.kernel.org/patch/1229541/
>
> This seemed to be necessary to get the  0x0c26 PCI id to be loaded by
> i915, and use KMS.
>
> After doing this, I had some success, but things still would become
> unstable, and flash test patterns on the screen about every third
> boot.
>
>
> I figured that I would move on to the tip, and see if that fixed anything.
>
> However, at the tip, I cannot get i915 to display graphics at all -
> even with applying the patch above.
>
>
> I understand that this is still under development - but this seems
> like a regression from 3.5
> Is there a codebase that I should be using for this testing?
>
>
> Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] v3.6 haswell regression from v3.5?

[Ben Guthro]

Hello, I've been attempting to get a Shark Bay / Haswell platform up &
running, and have been having some difficulties that I'm hoping you
all can possibly help with.

I first tried the 3.5 kernel, and had some success after applying the
following patch:
https://patchwork.kernel.org/patch/1229541/

This seemed to be necessary to get the  0x0c26 PCI id to be loaded by
i915, and use KMS.

After doing this, I had some success, but things still would become
unstable, and flash test patterns on the screen about every third
boot.


I figured that I would move on to the tip, and see if that fixed anything.

However, at the tip, I cannot get i915 to display graphics at all -
even with applying the patch above.


I understand that this is still under development - but this seems
like a regression from 3.5
Is there a codebase that I should be using for this testing?


Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Ironlake eDP training broken in 3.2.2

[Ben Guthro]

FWIW, I found the following patch that seems to solve the issue, on
this platform:

https://bugs.freedesktop.org/attachment.cgi?id=56178

linked from:
https://bugs.freedesktop.org/show_bug.cgi?id=42263

I was unable to find this committed in any of the dev trees, however.

Does this have any known issues on other platforms?



On Wed, Feb 1, 2012 at 10:17 AM, Ben Guthro  wrote:
> I'm moving my company's distro from 2.6.38 to 3.2.X  (currently 3.2.2)
> - and have found a regression in i915 that I'm hoping someone here
> might have a fix for, already.
>
> On some older platforms, I'm seeing the stack below that results in
> the screen never showing anything.
>
> Any thoughts, patches, suggestions are appreciated.
>
> - Ben Guthro
>
>
> [   28.064432] [ cut here ]
> [   28.064468] WARNING: at
> /builds/orc-precise/linux-3.2/drivers/gpu/drm/i915/intel_dp.c:1071
> ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]()
> [   28.064472] Hardware name: Latitude E5510
> [   28.064474] eDP VDD not forced on
> [   28.064475] Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4
> nf_conntrack scst_vdisk(O) nf_defrag_ipv4 crc32c ip_tables libcrc32c
> x_tables scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp
> libiscsi_tcp libiscsi scsi_transport_iscsi nfsd arc4 exportfs nfs
> snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec lockd
> iwlwifi(O) fscache auth_rpcgss psmouse snd_hwdep nfs_acl snd_pcm
> dell_laptop dell_wmi serio_raw snd_timer sparse_keymap dcdbas snd
> mac80211(O) sunrpc soundcore snd_page_alloc intel_ips ppdev
> cfg80211(O) parport_pc parport tpm_tis tpm tpm_bios usbhid hid zram(C)
> i915 tg3 ehci_hcd sdhci_pci sdhci drm_kms_helper drm intel_agp
> i2c_algo_bit intel_gtt video
> [   28.064546] Pid: 309, comm: plymouthd Tainted: G        WC O 3.2.2-orc #1
> [   28.064548] Call Trace:
> [   28.064557]  [] warn_slowpath_common+0x7f/0xc0
> [   28.064561]  [] warn_slowpath_fmt+0x46/0x50
> [   28.064573]  [] ironlake_edp_panel_vdd_off+0xbf/0xd0 
> [i915]
> [   28.064584]  [] intel_dp_commit+0x4f/0xb0 [i915]
> [   28.064590]  []
> drm_crtc_helper_set_mode+0x4eb/0x520 [drm_kms_helper]
> [   28.064597]  []
> drm_crtc_helper_set_config+0x83f/0xaf0 [drm_kms_helper]
> [   28.064603]  []
> drm_fb_helper_restore_fbdev_mode+0x40/0x60 [drm_kms_helper]
> [   28.064614]  [] intel_fb_restore_mode+0x1c/0x50 [i915]
> [   28.064623]  [] i915_driver_lastclose+0x39/0x80 [i915]
> [   28.064635]  [] drm_lastclose+0x49/0x300 [drm]
> [   28.064643]  [] drm_release+0x4fd/0x6c0 [drm]
> [   28.064648]  [] fput+0xea/0x220
> [   28.064651]  [] filp_close+0x66/0x90
> [   28.064654]  [] sys_close+0xb2/0x120
> [   28.064660]  [] system_call_fastpath+0x16/0x1b
> [   28.064662] ---[ end trace 4d53f99c84fca531 ]---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Ironlake eDP training broken in 3.2.2

[Ben Guthro]

I'm moving my company's distro from 2.6.38 to 3.2.X  (currently 3.2.2)
- and have found a regression in i915 that I'm hoping someone here
might have a fix for, already.

On some older platforms, I'm seeing the stack below that results in
the screen never showing anything.

Any thoughts, patches, suggestions are appreciated.

- Ben Guthro


[   28.064432] [ cut here ]
[   28.064468] WARNING: at
/builds/orc-precise/linux-3.2/drivers/gpu/drm/i915/intel_dp.c:1071
ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]()
[   28.064472] Hardware name: Latitude E5510
[   28.064474] eDP VDD not forced on
[   28.064475] Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack scst_vdisk(O) nf_defrag_ipv4 crc32c ip_tables libcrc32c
x_tables scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp
libiscsi_tcp libiscsi scsi_transport_iscsi nfsd arc4 exportfs nfs
snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec lockd
iwlwifi(O) fscache auth_rpcgss psmouse snd_hwdep nfs_acl snd_pcm
dell_laptop dell_wmi serio_raw snd_timer sparse_keymap dcdbas snd
mac80211(O) sunrpc soundcore snd_page_alloc intel_ips ppdev
cfg80211(O) parport_pc parport tpm_tis tpm tpm_bios usbhid hid zram(C)
i915 tg3 ehci_hcd sdhci_pci sdhci drm_kms_helper drm intel_agp
i2c_algo_bit intel_gtt video
[   28.064546] Pid: 309, comm: plymouthd Tainted: GWC O 3.2.2-orc #1
[   28.064548] Call Trace:
[   28.064557]  [] warn_slowpath_common+0x7f/0xc0
[   28.064561]  [] warn_slowpath_fmt+0x46/0x50
[   28.064573]  [] ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]
[   28.064584]  [] intel_dp_commit+0x4f/0xb0 [i915]
[   28.064590]  []
drm_crtc_helper_set_mode+0x4eb/0x520 [drm_kms_helper]
[   28.064597]  []
drm_crtc_helper_set_config+0x83f/0xaf0 [drm_kms_helper]
[   28.064603]  []
drm_fb_helper_restore_fbdev_mode+0x40/0x60 [drm_kms_helper]
[   28.064614]  [] intel_fb_restore_mode+0x1c/0x50 [i915]
[   28.064623]  [] i915_driver_lastclose+0x39/0x80 [i915]
[   28.064635]  [] drm_lastclose+0x49/0x300 [drm]
[   28.064643]  [] drm_release+0x4fd/0x6c0 [drm]
[   28.064648]  [] fput+0xea/0x220
[   28.064651]  [] filp_close+0x66/0x90
[   28.064654]  [] sys_close+0xb2/0x120
[   28.064660]  [] system_call_fastpath+0x16/0x1b
[   28.064662] ---[ end trace 4d53f99c84fca531 ]---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: fix ironlake edp panel setup (v4)

[Ben Guthro]

Sorry. no change in behavior, with my E6410.

On Tue, Jun 29, 2010 at 9:46 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> The eDP spec claims a 20% overhead for the 8:10 encoding scheme used on the 
> wire. Take this into account when picking the lane/clock speed for the panel.
>
> v3: some panels are out of spec, try our best to deal with them, don't refuse 
> modes on eDP panels, and try the largest allowed settings if all else fails 
> on eDP.
> v4: fix stupid typo, forgot to git add before amending.
>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   27 ---
>  1 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 6094e42..b4f0282 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -139,6 +139,12 @@ intel_dp_link_required(struct drm_device *dev,
>  }
>
>  static int
> +intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> +{
> +       return (max_link_clock * max_lanes * 8) / 10;
> +}
> +
> +static int
>  intel_dp_mode_valid(struct drm_connector *connector,
>                    struct drm_display_mode *mode)
>  {
> @@ -147,8 +153,11 @@ intel_dp_mode_valid(struct drm_connector *connector,
>        int max_link_clock = 
> intel_dp_link_clock(intel_dp_max_link_bw(intel_encoder));
>        int max_lanes = intel_dp_max_lane_count(intel_encoder);
>
> -       if (intel_dp_link_required(connector->dev, intel_encoder, mode->clock)
> -                       > max_link_clock * max_lanes)
> +       /* only refuse the mode on non eDP since we have seen some wierd eDP 
> panels
> +          which are outside spec tolerances but somehow work by magic */
> +       if (!IS_eDP(intel_encoder) &&
> +           (intel_dp_link_required(connector->dev, intel_encoder, 
> mode->clock)
> +            > intel_dp_max_data_rate(max_link_clock, max_lanes)))
>                return MODE_CLOCK_HIGH;
>
>        if (mode->clock < 1)
> @@ -509,7 +518,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
> drm_display_mode *mode,
>
>        for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
>                for (clock = 0; clock <= max_clock; clock++) {
> -                       int link_avail = intel_dp_link_clock(bws[clock]) * 
> lane_count;
> +                       int link_avail = 
> intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
>
>                        if (intel_dp_link_required(encoder->dev, 
> intel_encoder, mode->clock)
>                                        <= link_avail) {
> @@ -524,6 +533,18 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
> drm_display_mode *mode,
>                        }
>                }
>        }
> +
> +       if (IS_eDP(intel_encoder)) {
> +               /* okay we failed just pick the highest */
> +               dp_priv->lane_count = max_lane_count;
> +               dp_priv->link_bw = bws[max_clock];
> +               adjusted_mode->clock = intel_dp_link_clock(dp_priv->link_bw);
> +               DRM_DEBUG_KMS("Force picking display port link bw %02x lane "
> +                             "count %d clock %d\n",
> +                             dp_priv->link_bw, dp_priv->lane_count,
> +                             adjusted_mode->clock);
> +               return true;
> +       }
>        return false;
>  }
>
> --
> 1.7.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: fix ironlake edp panel setup (v2)

[Ben Guthro]

This also didn't fix the Dell E6410. I'll also note this in the bug.

I'm trying to work with some contacts at Dell to get this routed to
the right person as well...but am having limited luck with that, so
far.

On Mon, Jun 28, 2010 at 2:28 AM, Dave Airlie  wrote:
> On Mon, Jun 28, 2010 at 4:04 PM, Zhenyu Wang  wrote:
>> On 2010.06.28 09:45:14 +1000, Dave Airlie wrote:
>>> From: Dave Airlie 
>>>
>>> So the previous fix didn't work for everyone, I read the eDP spec and 
>>> claims a 20% overhead for encoding, so make sure we take this into account 
>>> when working out the bandwidth requirements.
>>>
>>> This makes my eDP panel happy also, please test on others.
>>>
>>> Signed-off-by: Dave Airlie 
>>> ---
>>>  drivers/gpu/drm/i915/intel_dp.c |   10 --
>>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 6094e42..9830243 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -139,6 +139,12 @@ intel_dp_link_required(struct drm_device *dev,
>>>  }
>>>
>>>  static int
>>> +intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>>> +{
>>> +     return (max_link_clock * max_lanes * 8) / 10;
>>> +}
>>> +
>>> +static int
>>>  intel_dp_mode_valid(struct drm_connector *connector,
>>>                   struct drm_display_mode *mode)
>>>  {
>>> @@ -148,7 +154,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
>>>       int max_lanes = intel_dp_max_lane_count(intel_encoder);
>>>
>>>       if (intel_dp_link_required(connector->dev, intel_encoder, mode->clock)
>>> -                     > max_link_clock * max_lanes)
>>> +                     > intel_dp_max_data_rate(max_link_clock, max_lanes))
>>>               return MODE_CLOCK_HIGH;
>>>
>>>       if (mode->clock < 1)
>>> @@ -509,7 +515,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
>>> drm_display_mode *mode,
>>>
>>>       for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
>>>               for (clock = 0; clock <= max_clock; clock++) {
>>> -                     int link_avail = intel_dp_link_clock(bws[clock]) * 
>>> lane_count;
>>> +                     int link_avail = 
>>> intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
>>>
>>>                       if (intel_dp_link_required(encoder->dev, 
>>> intel_encoder, mode->clock)
>>>                                       <= link_avail) {
>>> --
>>
>> sorry, this is still broken on the 16x9 panel.
>>
>> 'intel_dp_link_required' is 107840*18/8 = 242640, 'intel_dp_max_data_rate' is
>> 27*1*8/10 = 216000. So it will fail in both check.
>
> So this panel is definitely out of spec, according to the eDP table 3.2 and 
> 3.3
>
> Are you sure this is the mode it actually advertises over EDID vs some
> crazy mode stored in VBT?
>
> According to the eDP spec it needs 2 lanes and 1.62.
>
> A cvt rb 1600x900 mode would fit okay
> cvt -r 1600 900
> # 1600x900 59.82 Hz (CVT 1.44M9-R) hsync: 55.40 kHz; pclk: 97.50 MHz
> Modeline "1600x900R"   97.50  1600 1648 1680 1760  900 903 908 926 +hsync 
> -vsync
>
> Dave.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: fix ironlake edp panel setup.

[Ben Guthro]

FWIW, this didn't seem solve the boot issue I'm seeing with the Dell E6410...


On Fri, Jun 25, 2010 at 2:59 AM, Keith Packard  wrote:
> On Fri, 25 Jun 2010 16:21:40 +1000, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> We've just gotten an eDP laptop, and kms was booting to a black screen.
>>
>> as much as I hate Keith's magic * 3, it seems to work a lot better
>> than the non-magic.
>
> My *3 was based on the belief that we transmit 3 bytes for each pixel,
> independent of the pixel format. It worked pretty well for most of the
> sizes I tried...
>
> --
> keith.pack...@intel.com
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915: Dell E6410 Ironlake display detection

[Ben Guthro]

FWIW, I filed a bug here on this issue, to have something to attach
the output of various useful info
https://bugs.freedesktop.org/show_bug.cgi?id=28746


On Thu, Jun 24, 2010 at 2:55 PM, Ben Guthro
 wrote:
> I posted a similar question to LKML yesterday, but perhaps this is a
> better forum for this discussion, as it seemed to get lost amongst
> many other non-graphics related discussions.
>
> I have a problematic machine, that I have traced the problem down to
> what I think is an issue with the i915 detection of the LVDS on the
> Ironlake chip.
>
> The machine in question is a Dell Latitude E6410 - i5 laptop, with the
> intel Ironlake chip, and the failure condition is such that when the
> boot sequence switches into KMS mode, the screen
> goes black, and never comes back.
>
> It seems to be very similar to both
> https://bugs.freedesktop.org/show_bug.cgi?id=28224
> and
> https://bugs.freedesktop.org/show_bug.cgi?id=28070
>
> However, I have tried all of the patches suggested on these bugs, to
> no avail (yet)
>
> My base install is Ubuntu 10.04, and I've spun through a few kernels
> to try to bisect the problem. Unfortunately, I've been unable to find
> a kernel that works, but I have settled on linus' 2.6.35rc3 for
> debugging this...
>
> I can get the machine to come up on an external display, if switched
> at the BIOS screen...but /sys/class/card0 never shows an LVDS...and
> dmesg doesn't seem to be throwing any errors.
>
> If you have any thoughts on what I might try next, in attempting to
> debug this issue, I'd appreciate any pointers, as the intel cards
> isn't my particular area of expertise, but am capable enough to read
> the code...
>
>
> Regards,
>
> Ben
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] i915: Dell E6410 Ironlake display detection

[Ben Guthro]

I posted a similar question to LKML yesterday, but perhaps this is a
better forum for this discussion, as it seemed to get lost amongst
many other non-graphics related discussions.

I have a problematic machine, that I have traced the problem down to
what I think is an issue with the i915 detection of the LVDS on the
Ironlake chip.

The machine in question is a Dell Latitude E6410 - i5 laptop, with the
intel Ironlake chip, and the failure condition is such that when the
boot sequence switches into KMS mode, the screen
goes black, and never comes back.

It seems to be very similar to both
https://bugs.freedesktop.org/show_bug.cgi?id=28224
and
https://bugs.freedesktop.org/show_bug.cgi?id=28070

However, I have tried all of the patches suggested on these bugs, to
no avail (yet)

My base install is Ubuntu 10.04, and I've spun through a few kernels
to try to bisect the problem. Unfortunately, I've been unable to find
a kernel that works, but I have settled on linus' 2.6.35rc3 for
debugging this...

I can get the machine to come up on an external display, if switched
at the BIOS screen...but /sys/class/card0 never shows an LVDS...and
dmesg doesn't seem to be throwing any errors.

If you have any thoughts on what I might try next, in attempting to
debug this issue, I'd appreciate any pointers, as the intel cards
isn't my particular area of expertise, but am capable enough to read
the code...


Regards,

Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx