| Summary: | [hsw] KMS does not work on Dell XPS 8700 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | comes | ||||||||||||||
| Component: | DRM/Intel | Assignee: | Paulo Zanoni <przanoni> | ||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | medium | CC: | intel-gfx-bugs, przanoni | ||||||||||||||
| Version: | unspecified | ||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Did it ever work? (nomodeset does not count) No never. See: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038178.html http://lists.freedesktop.org/archives/intel-gfx/2014-January/038211.html for more info. Another case of a hsw dying on the very first modeset ... One for Paulo. Just to make sure: After the "freeze", you can't even SSH to the machine, right? Pressing caps lock/num lock won't trigger the Keyboard LEDs, right? Can you please boot with nomodeset and then "cat /proc/cmdline" and paste it here? I find it really really weird that we only detected HDMI at the HW state readout code, but then drm_enable_connectors thinks VGA is connected, then we do this: [ 100.312604] [drm:drm_enable_connectors], connector 9 enabled? yes [ 100.312606] [drm:drm_enable_connectors], connector 12 enabled? no [ 100.312608] [drm:drm_enable_connectors], connector 15 enabled? no [ 100.312610] [drm:drm_enable_connectors], connector 17 enabled? yes [ 100.312612] [drm:drm_target_preferred], looking for cmdline mode on connector 9 [ 100.312614] [drm:drm_target_preferred], looking for preferred mode on connector 9 [ 100.312617] [drm:drm_target_preferred], found mode 1024x768 [ 100.312619] [drm:drm_target_preferred], looking for cmdline mode on connector 17 [ 100.312621] [drm:drm_target_preferred], looking for preferred mode on connector 17 [ 100.312623] [drm:drm_target_preferred], found mode 1280x1024 [ 100.312625] [drm:drm_setup_crtcs], picking CRTCs for 8192x8192 config [ 100.312629] [drm:drm_setup_crtcs], desired mode 1024x768 set on crtc 3 [ 100.312631] [drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 5 Connector 17 is HDMI, but connector 9 is VGA. For some reason the DRM layer things CRT is connected. Just a quick test we could do, in case you're familiar with compiling/testing Kernels: remove the "intel_crt_init()" call from intel_setup_outputs() from intel_display.c. That would explain at leas that the problem is the bad CRT detection. After the freeze the keyboard is dead. Caps lock doesn't trigger the LED. cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.13.0-rc7-1-vanilla root=UUID=51611992-b00f-4c9c-932d-61e9b6b423fc load_ramdisk=1 init=linuxrc nomodeset resume=/dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F33NKC-part3 splash=verbose quiet showopts I have removed the "intel_crt_init()" call and now kms works. (In reply to comment #5) > I have removed the "intel_crt_init()" call and now kms works. This is the first non-ULT machine that seems to not have the CRT display. Can you please download intel-gpu-tools [0], compile it, and then run: sudo ./tools/intel_reg_read -d 0xc2014 0x42014 0x42020 ... and then paste the output here? I'm hoping bit 6 of 0xc2014 will be 1, then the patch will be easy :) Thanks, Paulo [0]: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools Created attachment 92683 [details] [review] Possible patch Possible patch, in case bit 6 of 0xc2014 is actuallty 1. This is the output of ./tools/intel_reg_read -d 0xc2014 0x42014 0x42020 0xC2014 : 0x6 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0x42014 : 0x24000002 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0x42020 : 0x0 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Bit 6 of 0xc2014 is not 1. Therefore the patch doesn't work (tested). (In reply to comment #8) > This is the output of ./tools/intel_reg_read -d 0xc2014 0x42014 0x42020 > > 0xC2014 : 0x6 > 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 > 6 5 4 3 2 1 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 1 1 0 > 0x42014 : 0x24000002 > 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 > 6 5 4 3 2 1 0 > 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 1 0 > 0x42020 : 0x0 > 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 > 6 5 4 3 2 1 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 > > Bit 6 of 0xc2014 is not 1. > Therefore the patch doesn't work (tested). That means your machine claims it does have a VGA/CRT output. It's really weird that the log files say CRT is disconnected, but drm_setup_crtcs() thinks it's connected... I wonder if there's something wrong with your framebuffer setup or something like that. Can you please boot the machine with nomodeset, grab the full "dmesg" and paste it here? Did you ever boot a distro standard Kernel with a standard .config file? Does it work? What happens if you add back that intel_crt_init() call, but instead of booting your machine with an HDMI monitor, you boot it with a CRT/VGA monitor? Does it also freeze? Thanks, Paulo Created attachment 92749 [details]
requested dmesg output with nomodeset
attached dmesg output booting opensuse 13.1 kernel with nomodeset
I installed openSUSE 12.3 and 13.1 on the PC and it only boots if I add the option nomodeset otherwise it freeze.
This machine does not have a VGA connector. It has a Display Port connector and a HDMI connector. I cannot attach a VGA monitor to it.
May be this will help: If only one monitor is connected to the PC one fb device is created: cat /sys/devices/pci0000:00/0000:00:02.0/graphics/fb0/name inteldrmfb But if I connect two monitor: DP1, HDMI2 then two framebuffers appears: cat /sys/devices/platform/efifb.0/graphics/fb0/name EFI VGA cat /sys/devices/pci0000:00/0000:00:02.0/graphics/fb1/name inteldrmfb Can it be that this "EFI VGA" framebuffer is what makes drm_setup_crtcs() think that a CRT is connected even if it isn't? Also when two monitors are connected vt01 is unreadable the background is a pattern of black and white vertical stripes and the text is scrambled. vt02 and higher are ok. cat /sys/devices/platform/efifb.0/graphics/fb0/virtual_size 640,350 this makes grub2 use such resolution to display the boot menu (with only one monitor grub2 uses the proper monitor resolution). One weird thing I noticed: the dmesg w/ nomodeset had vesafb, but then w/ two monitors connected efifb is there, which already seems weird to me. And then for some reason efifb is not getting kicked out by i915. What's the dmesg like w/o nomodeset and 1 monitor and 2 monitor cases? (In reply to comment #11) > May be this will help: > If only one monitor is connected to the PC one fb device is created: > > cat /sys/devices/pci0000:00/0000:00:02.0/graphics/fb0/name > inteldrmfb > > But if I connect two monitor: DP1, HDMI2 then two framebuffers appears: > > cat /sys/devices/platform/efifb.0/graphics/fb0/name > EFI VGA > > cat /sys/devices/pci0000:00/0000:00:02.0/graphics/fb1/name > inteldrmfb > > Can it be that this "EFI VGA" framebuffer is what makes drm_setup_crtcs() > think that a CRT is connected even if it isn't? > > Also when two monitors are connected vt01 is unreadable > the background is a pattern of black and white vertical stripes > and the text is scrambled. vt02 and higher are ok. > cat /sys/devices/platform/efifb.0/graphics/fb0/virtual_size > 640,350 > this makes grub2 use such resolution to display the boot menu (with only > one monitor grub2 uses the proper monitor resolution). Just to confirm: the bug still happens on both cases, with and without 2 monitors, right? > Just to confirm: the bug still happens on both cases, with and without 2 monitors, right?
Yes the bug happens with one or two monitors connected.
I will post later the dmesg output w/o nomodeset and 1 and 2 monitor connected.
Created attachment 92896 [details]
dmesg output without nomodeset and one monitor
Created attachment 92897 [details]
dmesg output without nomodeset and two monitors
Created attachment 95280 [details] [review] Skipping CRT initialization for DELL XPS 8700 I created this patch that simply works as it does skip the crt initialization for the XPS 8700 (it's ok as this PC does not have onboard VGA connector). It may be useful to anybody else who has my problem. If this fix or a better one can go upstream that would be great. Patch looks good, simply needs to be submitted to intel-gfx@lists.freedesktop.org as a proper kernel patch (i.e. with commit message and signed-off-by line, bugzilla link and all that). Can you please do that? Merged to 3.15-fixes with cc: stable. commit 2c533f62728983ea4d1113061d56b22076c00cb5 Author: Giacomo Comes <comes@naic.edu> Date: Thu Apr 3 14:13:55 2014 -0400 Skip intel_crt_init for Dell XPS 8700 Thanks for providing this patch! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 91952 [details] dmesg over netconsole On my Dell XPS 8700 kms does not work. If I boot without nomodeset the PC freeze and after 45 seconds reboot. To get a dmesg output I booted without loading the i915 module, started netconsole and insmod i915.ko. I used drm-intel-next-2014-01-10.