Bug 29499 - [945GM] Screen disconnected because of missing VBIOS
[945GM] Screen disconnected because of missing VBIOS
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
XOrg git
x86 (IA32) Linux (All)
: medium normal
Assigned To: Chris Wilson
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-10 22:26 UTC by Paul Neumann
Modified: 2010-09-06 04:09 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (28.35 KB, text/plain)
2010-08-10 22:26 UTC, Paul Neumann
no flags Details
dmesg output with drm.debug=0xe (48.16 KB, text/plain)
2010-08-11 04:13 UTC, Paul Neumann
no flags Details
Fallback to guessing the DDC bus without VBIOS. (2.60 KB, patch)
2010-08-12 07:33 UTC, Chris Wilson
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Neumann 2010-08-10 22:26:08 UTC
Created attachment 37784 [details]
dmesg output

On my machine (AOpen i945GTm-VHL with a DVI and VGA connector) the DVI output does not work since it is not recognised as connected and therefore the screen does not turn on (I have not tested VGA). The problem was caused by that git commit for kernel 2.6.35: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1083333de5357577c5ec55df6c7efa17bee41c7. after reverting it everything works fine.
On the intel-gfx mailing list I got told the problem occurs because of the fact that the VBIOS is missing.
Comment 1 Chris Wilson 2010-08-11 02:59:53 UTC
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.
Comment 2 Paul Neumann 2010-08-11 04:13:33 UTC
Created attachment 37788 [details]
dmesg output with drm.debug=0xe
Comment 3 Chris Wilson 2010-08-12 07:33:32 UTC
Created attachment 37815 [details] [review]
Fallback to guessing the DDC bus without VBIOS.
Comment 4 Paul Neumann 2010-08-12 08:32:17 UTC
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...
Comment 5 Chris Wilson 2010-08-14 03:38:32 UTC
(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?
Comment 6 Paul Neumann 2010-08-16 04:13:56 UTC
(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.
Comment 7 Chris Wilson 2010-08-21 02:17:20 UTC
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.
Comment 8 Chris Wilson 2010-08-21 02:20:41 UTC
* 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.
Comment 9 Chris Wilson 2010-09-06 04:09:33 UTC
(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/