Bug 29499

Hmm, you'll want to resolve that recursive fault in the USB device first. Yikes.

Then can you boot with drm.debug=0xe and upload the dmesg, thanks.

Created attachment 37788 [details]
dmesg output with drm.debug=0xe

Created attachment 37815 [details] [review]
Fallback to guessing the DDC bus without VBIOS.

Hi Chris,
the patch you sent me did not work. When I recompiled the kernel it gave me the following errors/warnings:


  CC      drivers/gpu/drm/i915/intel_sdvo.o
drivers/gpu/drm/i915/intel_sdvo.c:2046:33: warning: ‘struct intel_sdvo’ declared inside parameter list
drivers/gpu/drm/i915/intel_sdvo.c:2046:33: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/gpu/drm/i915/intel_sdvo.c: In function ‘intel_sdvo_guess_ddc_bus’:
drivers/gpu/drm/i915/intel_sdvo.c:2054:14: error: dereferencing pointer to incomplete type
drivers/gpu/drm/i915/intel_sdvo.c:2071:14: error: dereferencing pointer to incomplete type
drivers/gpu/drm/i915/intel_sdvo.c:2078:6: error: dereferencing pointer to incomplete type
drivers/gpu/drm/i915/intel_sdvo.c: In function ‘intel_sdvo_select_ddc_bus’:
drivers/gpu/drm/i915/intel_sdvo.c:2102:3: warning: passing argument 1 of ‘intel_sdvo_guess_ddc_bus’ from incompatible pointer type
drivers/gpu/drm/i915/intel_sdvo.c:2046:1: note: expected ‘struct intel_sdvo *’ but argument is of type ‘struct intel_sdvo_priv *’

However, if I change 

static void intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo)
to
static void intel_sdvo_guess_ddc_bus(struct intel_sdvo_priv *sdvo)

everything compiles and works as expected. Don't know whether my change is really intended though...

(In reply to comment #4)
> Hi Chris,
> the patch you sent me did not work.

[snip]
 
> However, if I change 
> 
> static void intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo)
> to
> static void intel_sdvo_guess_ddc_bus(struct intel_sdvo_priv *sdvo)
> 
> everything compiles and works as expected. Don't know whether my change is
> really intended though...

That's just a difference in kernel versions, the patch was against drm-intel-next as that should be included with 2.6.36-rc1. The change you made was correct.

Can I just ask you to clarify "works as expected"? Does the patch indeed restore the previous working behaviour on your system? May I include your tested-by?

(In reply to comment #5)
> That's just a difference in kernel versions, the patch was against
> drm-intel-next as that should be included with 2.6.36-rc1. The change you made
> was correct.

Ah ok. I already wondered what tree the patch was originated from.

> Can I just ask you to clarify "works as expected"? Does the patch indeed
> restore the previous working behaviour on your system? May I include your
> tested-by?

I mean that everything works the way it worked before (up to 2.6.34). The screen is turned on, resolution is set to the screen's native...

I have no problem with including my tested-by, do as you like.

A second look:

i915 0000:00:02.0: BAR 6: can't assign [??? 0x00000000 flags 0x0] (bogus alignment)
[drm] failed to find VBIOS tables

I've a fix for this on my drm-testing branch. The issue here is that the ROM appears compressed and is not exposed via the PCI ROM and only through the OpRegion. To fix this we need to actually allocate the MCHBAR correctly (if not setup by PnP) and then use the OpRegion->VBT in preference to scanning the vBIOS ourselves.

* smacks himself.

Actually no reason to expect that we have a vBIOS with only external displays. The OpRegion fix is valid but unlikely to aid here.

(In reply to comment #8)
> * smacks himself.

* double smack

Patches upstream with fix the handling of the absent VBIOS and indeed try harder to find the right VBIOS: http://cgit.freedesktop.org/~ickle/drm-intel/