Hardware: Acer Aspire 7715Z Graphics: 'Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42]' I found that after installing Debian Wheezy (kernel = vmlinuz-2.6.38-2-686), the screen goes black immediately after "Waiting for /dev to be fully populated..." is printed to the screen. I installed linux-image-3.0.0-rc4-686-pae to try to bypass the issue without success. Although, without a VDU, I logged in as a normal user and used the uname -r > file-name to test that the said kernel was in fact loaded. When I read the file in Squeeze, it confirmed that the kernel from experimental was installed. I could bypass the bug by connecting an external monitor. I also tested whether 3D acceleration was used by running an opengl screensaver but the latter froze Debian completely and I had to turn the system off. The screensaver run smoothly until I pressed a button to return to the desktop. In short, the bug manifests itself like this: When "Waiting for /dev to be fully populated..." is printed to the screen, both the CLI and GUI don't use the screen anymore. Notwithstanding all this, the system allows log ins as normal user and root. I also was capable to run a sound file using mplayer. Please report this bug upstream at <https://bugs.freedesktop.org> under product 'DRI', component 'DRM/Intel'. You should include: - The information you just provided - The other versions that have this bug - The hardware identification: 'Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42]' I also tested the laptop for the bug with knoppix 6.4.4 and it manifested the same problem. I found that kernels >= 2.6.38 manifest the bug.
Can you please attach dmesg (with drm.debug=0xe appended to your grub kernel boot parameters) and Xorg.log? I suspect we may need a register dump, but first lets see what was and wasn't detected.
Created attachment 48498 [details] dmesg
Created attachment 48499 [details] Xorg.0.log
These are the requested files with the drm.debug=0xe
Ok, thanks. The really bizarre aspect is that we are using the LVDS panel mode as supplied by the BIOS. My first guess is that i915.i915_panel_use_ssc=0 will be the fix. You can try and see if it fails ;-) But it does look like I will need the register dumps to see what is not being set correctly. If you download and build intel_reg_dumper from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and then run it once with nomodeset (i.e. without loading KMS so that we can see the BIOS state) and once after a failed boot, and please attach the results.
(In reply to comment #5) > Ok, thanks. The really bizarre aspect is that we are using the LVDS panel mode > as supplied by the BIOS. > > My first guess is that i915.i915_panel_use_ssc=0 will be the fix. You can try > and see if it fails ;-) > > But it does look like I will need the register dumps to see what is not being > set correctly. If you download and build intel_reg_dumper from > http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and then run it once with > nomodeset (i.e. without loading KMS so that we can see the BIOS state) and once > after a failed boot, and please attach the results. What should I do with i915.i915_panel_use_ssc=0? So, I should install intel_reg_dumper and run it twice: a) without kms b) during a failed boot?
(In reply to comment #6) > What should I do with i915.i915_panel_use_ssc=0? It's a kernel boot parameter similar to drm.debug, so append it to your kernel line in grub. > So, I should install intel_reg_dumper and run it twice: > a) without kms > b) during a failed boot? Yes, that will be useful.
(In reply to comment #7) > (In reply to comment #6) > > What should I do with i915.i915_panel_use_ssc=0? > > It's a kernel boot parameter similar to drm.debug, so append it to your kernel > line in grub. > > > So, I should install intel_reg_dumper and run it twice: > > a) without kms > > b) during a failed boot? > > Yes, that will be useful. I booted with i915.i915_panel_use_ssc=0. The result was exactly like when I disabled kms in the file /etc/modprobe.d/i915-kms.conf. Both the CLI and GUI loaded and I could use both of them. The GUI was however of a very poor resolution and its response was lacking. During the booting sequence, there was an error complaining of an "unknown parameter" and it was referring to the i915.i915_panel_use_ssc=0. Is intel_reg_dumper an independent program or a kernel patch?
Oh, its called i195.i915_lvds_use_ssc=0. Meh, the variable in the code is i915_panel_use_ssc which confused me. intel_reg_dumper is an external program that reads the registers directly.
(In reply to comment #9) > Oh, its called i195.i915_lvds_use_ssc=0. Meh, the variable in the code is > i915_panel_use_ssc which confused me. > > intel_reg_dumper is an external program that reads the registers directly. I found a precompiled package in Wheezy's repositories. This has the same name. Which tools do you want me to use, they are listed below and what parameters should I use if any? /usr/bin/intel_gpu_dump /usr/bin/intel_gpu_top /usr/bin/intel_reg_write /usr/bin/intel_stepping /usr/bin/intel_upload_blit_large /usr/bin/intel_upload_blit_large_gtt /usr/bin/intel_upload_blit_large_map /usr/bin/intel_upload_blit_small Should I run them as root?
Right package, too old. It doesn't contain intel_reg_dumper which is only available from the git repo. Something like: $ sudo apt-get build-dep intel-gpu-tools $ sudo apt-get install git $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools $ cd intel-gpu-tools $ ./autogen.sh $ make $ sudo ./tools/intel_reg_dumper should suffice.
(In reply to comment #11) > Right package, too old. It doesn't contain intel_reg_dumper which is only > available from the git repo. Something like: > > $ sudo apt-get build-dep intel-gpu-tools > $ sudo apt-get install git > $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > $ cd intel-gpu-tools > $ ./autogen.sh > $ make > $ sudo ./tools/intel_reg_dumper > > should suffice. Everything run fine until ./autogen.sh This is the output. What should I do now? root@edbarx-pc2:/home/edbarx/intel-gpu-tools# ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 ${ACLOCAL_FLAGS} configure.ac:89: error: must install xorg-macros 1.3 or later before running autoconf/autogen configure.ac:89: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: /usr/bin/autom4te failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 ./autogen.sh: 6: ./configure: not found
Oh, that's a nasty one to get around without actually installing a recent xutils-dev [iirc]. Check which version you have or see if installing a fresh copy helps.
Created attachment 48533 [details] intel_reg_dump output
(In reply to comment #14) > Created an attachment (id=48533) [details] > intel_reg_dump output The attachment is the output of intel_reg_dump with i915.modeset=0 passed to the kernel. The file /etc/modprobe.d/i915-kms.conf contains "options i915 modeset=1".
Can you also attach the output from intel_reg_dumper for the broken KMS-enabled configuration as well?
Created attachment 48534 [details] intel_reg_dumper output when CLI and GUI fail The output is with the kernel command line having no other parameters other than the grub default and with /etc/modprobe.d/i915-kms.conf containing "options i915 modeset=1".
i forgot to tell you what happened when I used i195.i915_lvds_use_scc=0. The computer screen went black as usual, with the exception, that just before it turned itself off, there was an instant at which I could read the text on the screen. Inform me in case you need more testing on my machine as I will be following the development of this bug report.
So the mode we set is subtly different to the BIOS's: FPB0: 0x00021307 (n = 2, m1 = 19, m2 = 7) FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8) DPLL_B: 0x99086c00 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 4, p2 = 7) DPLL_B_MD: 0x00000003 HTOTAL_B: 0x06df063f (1600 active, 1760 total) HBLANK_B: 0x06df063f (1600 start, 1760 end) HSYNC_B: 0x068f066f (1648 start, 1680 end) and our's: FPB0: 0x00021607 (n = 2, m1 = 22, m2 = 7) FPB1: 0x00021607 (n = 2, m1 = 22, m2 = 7) DPLL_B: 0x99086c00 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 4, p2 = 7) DPLL_B_MD: 0x00000000 HTOTAL_B: 0x07cf063f (1600 active, 2000 total) HBLANK_B: 0x07cf063f (1600 start, 2000 end) HSYNC_B: 0x06a9067f (1664 start, 1706 end) The first point to work out is why we are using a much larger blanking width than the BIOS (which affects our choice of clocks) and presumably throws us out of the panel spec.
I am assuming the above will affect some source code compiled into the kernel. Am I right, and if possible to tell me at this stage, which files are affected?
Right, the kernel is in charge of setting these registers. It's all a bit of mish-mash between intel_bios.c (for reading the vBIOS tables), intel_lvds.c for determining panel configuration and intel_display.c for actually setting the common modesetting registers (the PLL clocks and timings).
While I appreciate and understand that I must NOT put undue pressure on the developers, I would like to, politely, ask you whether there have been any developments regarding this bug. I beg your pardon if it is not custom to ask such questions. Thanks.
Ok, so the EDID for the panel is incorrect, yet we use that in preference to the VBT panel configuration data. EDID: 1600 1664 1706 2000 VBT: 1600 1648 1680 1760
Created attachment 48918 [details] [review] Add a module parameter to prefer the VBT mode So please apply this patch and pass i915.lvds_use_vbt_mode=1 to the kernel via the grub boot parameters.
Could you please give me the command sequence I need to patch and properly compile the kernel? Thanks.
git clone git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 git checkout drm-intel-fixes git am -3 < /path/to/above/patch cp /boot/config-`uname -r` .config make sudo make modules_install install sudo reboot # cross your fingers
I tried the: git clone git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 command, but is was taking too long and I had to stop it in the middle. I worked around by downloading the source package (linux-2.6_2.6.39.orig.tar.gz) from www.debian.org. I extracted the source, then I patched it using the command: patch -p1 -i ../../kernel-patch.cgi while being in the kernel source directory. After that, I built the kernel using these commands: a) make menuconfig (I selected the 2.6.39.1 configuration) b) make-kpkg --rootcmd fakeroot --initrd --revision=000.edbarx kernel_image kernel_headers I installed the resulting packages using dpkg -i *.deb Please, note that the kernel was compiled under Squeeze (Stable). Hopefully, what I did makes sense and was not in vain. The result: At first, the CLI was available, but that ceased to be so until the system tried to load kdm after which both the CLI and GUI became invisible. I remember, that I tried an Ubuntu version which uses kernels >= 2.6.38 and it used to properly detect and use my GPU.
Can you do an intel_reg_dumper on your patched kernel, so that I can see if the change took effect? And please also attach the full dmesg.
Created attachment 49022 [details] intel_reg_dumper output with the patch applied
Created attachment 49023 [details] dmesg with the patch applied
Created attachment 49024 [details] one of the patched files I am sending one of the patched files so that you can check whether the patch was applied properly.
Right, we have the right blanking intervals this time, but we still compute a different clock than the working BIOS configuration. Hmmm.
Do you have another patch that I can test? Thanks and excuse me for bothering you.
Today, I found that the same issue also manifests itself with vmlinuz-2.6.39-2-amd64. This means 64 bit is also affected. I confirmed the above by installing the 64 bit version of wheezy.
Out of curiosity, we found a widespread bug affecting modesetting. Just on the off-chance that this is a timing issue and a incorrect clock setting, can you please also test keithp/drm-intel-fixes [ git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git]
Could you please tell me how I can download the relevant patch from the repository? I need to avoid downloading unnecessary files to save time and bandwidth. Thanks.
Today I downloaded, compiled and installed the 2.6.39.4 kernel from kernel.org. Unfortunately, it is exhibiting the same problem: the CLI and GUI vanish as soon as kdm tries to load.
To get a kernel with Keith's fixes using a minimum of bandwith: tar -xf linux-2.6.39.4.tar.bz2 mv linux-2.6.39.4 linux && cd linux wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.39.4.bz2 bunzip2 patch-2.6.39.4.bz2 patch -p1 -R <patch-2.6.39.4 wget http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.0.bz2 bunzip2 <patch-3.0.bz2 | patch -p1 wget http://www.kernel.org/pub/linux/kernel/v3.x/testing/patch-3.1-rc1.bz2 bunzip2 <patch-3.1-rc1.bz2 | patch -p1 nice make -j4 deb-pkg Or, better: apt-get install ketchup/sid tar -xf linux-2.6.39.4.tar.bz2 mv linux-2.6.39.4 linux && cd linux ketchup 3-git nice make -j4 deb-pkg
While installing the patched kernel, I got these errors: root@edbarx-pc2:/home/edbarx/custom-kernel# ls linux-firmware-image_3.1.0-rc1-1_i386.deb linux-headers-3.1.0-rc1_3.1.0-rc1-1_i386.deb linux-image-3.1.0-rc1_3.1.0-rc1-1_i386.deb linux-libc-dev_3.1.0-rc1-1_i386.deb.no root@edbarx-pc2:/home/edbarx/custom-kernel# dpkg -i *.deb Selecting previously deselected package linux-firmware-image. (Reading database ... 176321 files and directories currently installed.) Unpacking linux-firmware-image (from linux-firmware-image_3.1.0-rc1-1_i386.deb) ... dpkg: error processing linux-firmware-image_3.1.0-rc1-1_i386.deb (--install): trying to overwrite '/lib/firmware/av7110/bootcode.bin', which is also in package firmware-linux-free 3 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Selecting previously deselected package linux-headers-3.1.0-rc1. Unpacking linux-headers-3.1.0-rc1 (from linux-headers-3.1.0-rc1_3.1.0-rc1-1_i386.deb) ... Selecting previously deselected package linux-image-3.1.0-rc1. Unpacking linux-image-3.1.0-rc1 (from linux-image-3.1.0-rc1_3.1.0-rc1-1_i386.deb) ... Setting up linux-headers-3.1.0-rc1 (3.1.0-rc1-1) ... Setting up linux-image-3.1.0-rc1 (3.1.0-rc1-1) ... update-initramfs: Generating /boot/initrd.img-3.1.0-rc1 Errors were encountered while processing: linux-firmware-image_3.1.0-rc1-1_i386.deb How should I proceed now? Thanks.
Finally, I succeeded to do as instructed and installed the resulting packages with the exception of the -dev package which should not be necessary for the kernel to do its job. However, I am very sad to inform you that the problem is still there: after the system attempts to load kdm, both the CLI and GUI vanish into thin air. This is clear that whatever has been patched has nothing to do with what is causing the problem. As this serious bug will definitely impact the great majority of Linux distributions, I am humbly asking you whether you are confident that a solution can be found within a year from now. As I see it, with this type of bug, it is useless for me to attempt to install any other distro in place of Debian, because here, we are talking about the kernel.
I have been finally able to boot Wheezy successfully. I used the acpi_osi=Linux kernel parameter and Fn + Left Arrow to turn on the back light when it was erroneously turned off by the kernel (?) or init's scripts. I am posting here because I am now convinced the solution to this bug is not some incompatible configuration in the kernel, but rather, a strange failure to turn on the back light after a successful mode setting. This means, there is absolutely no modesetting failure. The only evident failure is the failure turn the back light on. Thanks.
(In reply to comment #41) > I have been finally able to boot Wheezy successfully. I used the acpi_osi=Linux > kernel parameter and Fn + Left Arrow to turn on the back light when it was > erroneously turned off by the kernel (?) or init's scripts. > > I am posting here because I am now convinced the solution to this bug is not > some incompatible configuration in the kernel, but rather, a strange failure to > turn on the back light after a successful mode setting. > > This means, there is absolutely no modesetting failure. The only evident > failure is the failure turn the back light on. > > Thanks. I can confirm that with Acer Emachines E527, it's quite same behaviour on all modern linux distributions (ubuntu, debian, gnome 3 livecd). Till 2.6.32 it works out of the box, after it I need to manually run setpci -s 00:02.0 F4.B=00 as root to enable backlight (completely black screen until gdm screen, very dim before running setpci). 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) Subsystem: Acer Incorporated [ALI] Device 0459
Daniel, you have a choice you can either close this as not-out-bug as the BIOS is feeding the wrong modeline through the VBT (but I suspect that is due to it providing the correct one through a bios-call) and so we need a quirk to fix it up. Or accept that if the BIOS is setup correctly then the machine works. The backlight issue is secondary and tracked in the myriad of reported failures.
Ok, this smells like another incarnation of the Acer backlight panel screw-up. Please retry with the latest drm-intel-next-queued branch from http://cgit.freedesktop.org/~danvet/drm-intel/ If this does not help, please attach lspci -vvmmm so that I can add the relevant quirk entry.
Created attachment 60481 [details] output of lspci -vvmmm as root
re: drm-intel-next-queued Is it possible that I apply the patch to the i915 driver only so as to avoid recompiling thausands of drivers just to apply this patch? I am currently using the Debian (Wheezy) kernel 'vmlinuz-2.6.32-5-amd64'
Well, 2.6.32 is official graphics-stoneage. Please upgrade.
(In reply to comment #47) > Well, 2.6.32 is official graphics-stoneage. Please upgrade. To be fair, 3.1-rc1 is not *that* old.
(In reply to comment #46) > re: drm-intel-next-queued > > Is it possible that I apply the patch to the i915 driver only so as to avoid > recompiling thausands of drivers just to apply this patch? Thanks. If you use git or ketchup then a build should only require recompiling the drivers that changed. If you use "make localmodconfig", it should only involve the dozens of drivers you use rather than all of them. Instructions: 1. Get a copy of the kernel history, if you don't already have it. This takes some time, but it's a one-time thing. git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. Grab drm-intel-next. cd linux git remote add drm-intel-next \ git://people.freedesktop.org/~danvet/drm-intel git fetch drm-intel-next 3. Configure and test. git checkout origin/master cp /boot/config-$(uname) .config; # current configuration make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -j<num> for parallel build dpkg -i ../<name of package>; # as root reboot 4. Hopefully it reproduces the bug. So try the proposed change: cd linux git checkout drm-intel-next/drm-intel-next-queued make deb-pkg; # maybe with -j4 dpkg -i ../<name of package>; # as root reboot If you run into trouble or have any questions, please don't hesitate to ask. > I am currently using the Debian (Wheezy) kernel 'vmlinuz-2.6.32-5-amd64' That's the kernel in squeeze, not wheezy.
Oops, missed that piece.(In reply to comment #48) > (In reply to comment #47) > > Well, 2.6.32 is official graphics-stoneage. Please upgrade. > > To be fair, 3.1-rc1 is not *that* old. Oops sorry, missed that piece. You need this patch to get the module option: http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=7bd90909bbf9ce7c40e1da3d72b97b93839c188a If you're lucky, it still applies to 3.1, otherwise you need to download a more recent kernel first.
I am NOT experiencing the problem in Squeeze but in Wheezy. The kernel is: vmlinuz-3.2.0-2-amd64
I would also like to ask if there are better workarounds to turn on the backlight as soon as it is turned off. I am using the setpci -s command to turn the backlight on again.
I am using the kernel parameter acpi_osi=Linux to allow for brightness adjustment. I am also using the /etc/rc.local to automatically issue the setpci -s command during boot. As far as I am concerned, this bug is presently bypassed permitting myself to use Wheezy without crippling issues. However, if I find time, I am willing to contribute to the the debugging process of the kernel, obviously where modesetting is concerned. Thanks.
If you do tests, please disable both the setpci workaround and the acpi_os=Linux commandline option.
Please test the backlight-confusion branch from my git repo at: http://cgit.freedesktop.org/~danvet/drm
Could you please, indicate me how to do the test? i.e. I need to know how to patch the kernel with the indicated patch/es and how to compile it to get a .deb package.
Hi Eduardo, (In reply to comment #56) > Could you please, indicate me how to do the test? i.e. I need to know how to > patch the kernel with the indicated patch/es and how to compile it to get a > .deb package. Here you go. 0. prerequisites: apt-get install git build-essential 1. get the kernel history, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. fetch Daniel's tree: cd linux git remote add danvet \ git://people.freedesktop.org/~danvet/drm git fetch danvet 3. configure, build, test: git checkout danvet/backlight-confusion cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -j<num> for parallel build dpkg -i ../<name of package>; # as root reboot ...test test test... Thanks, Jonathan
(In reply to comment #57) > Hi Eduardo, Mph, wrong name (mixed you up with someone else). Sorry for the noise.
From the workaround description, this is another instance of the gen4 backlight fiasco. Jani is volunteered to cook up a patch for this.
Patches and discussion at [1], also available in the "backlight" branch of [2]. Please test. [1] http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/13642 [2] git://gitorious.org/jani/drm.git
Please try i915.invert_brightness=1 module parameter with kernel version v3.5 or later, see if that fixes the brightness issue, and report 'lspci -vmmnn' if it does.
Any update? Did the backlight invert param work?
timing out after 6 months... hope it's fixed anyway
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.