Created attachment 109411 [details] Dmesg with drm.debug=0xe parameter. Compiled vanilla 3.6.11 kernel loaded on a Terra all in one device. When KMS i915 kernel module is loaded, all I get is a black screen. The device does not freeze and continues to boot. This device was working with vanilla 2.6.34 kernel. The device's motherboard is an MSI-7437 base board with an American Megatrends Inc. BIOS, version 080015. The graphics card is an Intel Corporation Mobile 945GSE Express Integrated Graphics Controller with PCI IDs 8086:27ae. I will attach a dmesg with the drm.debug=0xe boot parameter as well as lspci and other device information files. Since I am one of the maintainers of 2XOS and can build kernels on the fly I would be able to test any patches/suggestions that may arise.
Created attachment 109421 [details] Lspci output.
Created attachment 109431 [details] More detailed lspci output.
Created attachment 109441 [details] Device hardware information.
Can you please attach a dmesg from a working kernel (2.6.34) so that we can see what outputs are expected to be found?
Forgot to add that the device booted successfully with the modeset=0 parameter. But this disables KMS completely.
Will do. With the 2.6.34 kernel, the expected outputs where LVDS-1 and VGA-1 with the LVDS-1 as the connected port, and VGA-1 disabled.
While shifting through the 3.6.11 dmesg output, I noticed that it fails to configure the LVDS port and then it finds the VGA port disconnected. The module ends up with no connected ports.
Created attachment 109491 [details] 2.6.34 dmesg command output.
Unfortunately I cannot get the whole log as the first part is lost. But the log clearly shows which ports have been detected. This device has a custom 1366x768 resolution.
It looks like we bomb out of the sdvo detection because a command isn't supported...
Going through both logs it seems that the same command works in the 2.6.34 kernel: [drm:intel_sdvo_debug_write], SDVOB: W: 10 00 (SDVO_CMD_SET_TARGET_INPUT) [drm:intel_sdvo_debug_response], SDVOB: R: (Success) But fails in the 3.6.11 one. [drm:intel_sdvo_debug_write], SDVOB: W: 10 00 (SDVO_CMD_SET_TARGET_INPUT) [drm:intel_sdvo_read_response], SDVOB: R: (Not supported)... failed Can it be the order of calls is causing this issue?
You can increase the dmesg buffer with log_buf_len=4M or so. Can you please try again to get a complete log?
Will do.
Created attachment 109511 [details] Full DRM 2.6.34 dmesg output.
Attached you should find what you want.
I've just pushed a debug patch from Chris Wilson to my drm/i915 git trees. Can you please test the latest drm-intel-nightly branch from http://cgit.freedesktop.org/~danvet/drm-intel/ and grab the dmesg? Thanks, Daniel
OK.
Do I need to clone the drm-intel repository? And then checkout the drm-intel-nightly tree? Geoffrey
(In reply to Geoffrey Said from comment #18) > Do I need to clone the drm-intel repository? And then checkout the > drm-intel-nightly tree? You can do that, or if you have a kernel repository cloned already, it's perhaps more convenient to do this within the repo: $ git remote add drm-intel git://people.freedesktop.org/~danvet/drm-intel $ git fetch drm-intel $ git checkout drm-intel/drm-intel-nightly HTH.
Thanks for the reply. I see that the repository includes the whole kernel. It is difficult for us as we have aufs and squashfs patches which need to work with the kernel for our OS to work. Can I have the debug patch so that I can try and apply it on the 3.6 kernel? Geoffrey
(In reply to Geoffrey Said from comment #20) > Thanks for the reply. > > I see that the repository includes the whole kernel. It is difficult for us > as we have aufs and squashfs patches which need to work with the kernel for > our OS to work. > > Can I have the debug patch so that I can try and apply it on the 3.6 kernel? 3.6 is _really_ old in gfx land, maybe you can get this going using the backport-compat trees to only compile the drm drivers from that repo against your 3.6 kernel. But I've never done that myself, so can't help you with that.
Can you please indicate where I can get the backport-compat trees?
On Wed, Sep 25, 2013 at 12:21 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=61991 > > --- Comment #22 from Geoffrey Said <geoffrey@2x.com> --- > Can you please indicate where I can get the backport-compat trees? https://backports.wiki.kernel.org/index.php/Main_Page
More news guys. I have compiled the back port drm and i915 modules and these are the results: 3.7.9 back port - Same issue as with the 3.6 kernel, black screen. 3.8.3 back port - Garbled display, a lot of small columns. 3.9 back port - i915 module reports that it can use 0 memory and then a kernel stack trace. 3.10 back port - i915 module reports that it can use 0 memory and then a kernel stack trace. 3.10.4 back port - i915 module reports that it can use 0 memory and then a kernel stack trace. It seems that this graphic chip or this type of client is problematic across a whole range of kernels. If you want more information just ask.
Any chance you can test vanilla upstream kernels (maybe with a plain distro install on the same hw) to rule out issues with the backports? Also please attach the dmesg of the 3.10 backport tree, this doesn't sound good ...
Will do. At the moment I am testing standard distros.
Ubuntu 12.10 exhibits the same issue. But it runs on the 3.5 kernel. At the moment I am trying to boot Ubuntu 13.04 and OpenSuse 12.3
I am unable to boot Ubuntu 13.04 and OpenSuSE 12.3 due to the fact that I have an error with the first IDE controller. With our OS we load the generic drivers which work perfectly on this device. Unfortunately it seems that the ata_piix is compiled inside the kernels and it continues to cycle with errors. Is there anything I can do to bypass this? Will attach the 3.10 back port dmesg shortly.
Created attachment 109691 [details] Back port 3.10.4 i915 and drm modules.
Attached find the dmesg and kernel stack trace as requested for the 3.10.4 back port.
Any news?
Any updates?
Well that backport kernel is busted. Testing on latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ would be good.
Daniel is our SDVO guy :)
Timeout. Please reopen if the problem persists with recent kernels.