Created attachment 31850 [details] crash log I'm running Opensuse 11.1 on a BlueSens netbook with an intel 945GME chipset. I have the lastest Xorg packages from the X11/Xorg repository for openSuse 11.1 and the lastest kernel. Since 2nd of Dec package update Xorg crashed with "no kernel modesetting driver found". So i tried rebooting with i915.modeset=1 and since then it simply crashes with "no screens found" error. I tried with no Xorg.conf at all, with my usual xorg.conf file and with the sax2 config, same problem with all. When running 'X -configure' intel driver complains that modeset is not enabled. When i connect a VGA external monitor, X server seems to run without problems on that screen, but the LVDS monitor keeps unnoticed. I have attached the Xorg.conf, but everything seems normal X -version: X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux hector 2.6.32-39-pae #1 SMP 2009-12-08 02:05:56 +0100 i686 Build Date: 08 December 2009 04:00:05AM xorg-x11-driver-video package version 7.4-141.4 xorg-x11-driver-input package version 7.4-53.8 This is my first bug report ever. Sorry if i did something wrong. At least i havent found it as reported yet.
Hi again, I did some testing and could confirm its a KMS problem. The intel driver is forcing KMS from version 2.9.1, so i went back to 2.9.0 and disabled KMS with "nomodeset" and everything is back to work normally.
Will you please add the boot option of "nomodeset" and attach the following outputs on your box ? a. acpidump.out b. vbios.dump The acpidump.out can be obtained by using the latest acpidump tool(pmtools-2007116.tar.bz2), which can be downloaded in: http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ The vbios.dump can be obtained by using the following commands: 1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom 2. cat /sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump 3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom thanks.
Created attachment 31911 [details] acpidump
Created attachment 31912 [details] vbios
(In reply to comment #4) > Created an attachment (id=31912) [details] > vbios > Will you please boot the system with the boot option of "nomodeset" and attach the output of " cat /proc/acpi/button/lid/*/*"? It will be great if you can attach the output of dmidecode on your box. Thanks.
Created attachment 31913 [details] dmidecode output
(In reply to comment #5) > Will you please boot the system with the boot option of "nomodeset" and attach > the output of " cat /proc/acpi/button/lid/*/*"? The output is: type: Lid Switch state: closed Obviously, the screen is open and working right now! :S The screen turns off properly when I close the lid, however this seems not to be noticed by the system (suspend to RAM option when closing the lid does not work). > > It will be great if you can attach the output of dmidecode on your box. Done.
(In reply to comment #7) > (In reply to comment #5) > > Will you please boot the system with the boot option of "nomodeset" and attach > > the output of " cat /proc/acpi/button/lid/*/*"? > > The output is: > > type: Lid Switch > state: closed Thanks for the confirmation. I get the reason that nothing is displayed on LVDS. Now the LID status is used to check whether the LVDS is connected or not. When it is closed, the LVDS will be detected as disconnectd. Otherwise it is detected as connected. When the system is booted with the KMS enabled, the LVDS is detected as disconnected as the LID status is closed. In such case nothing is displayed on LVDS. This is related with the broken BIOS. Of course we can put this box into one DMI check list, which doesn't use the LID status to check whether the LVDS is connected or not. Thanks. > > Obviously, the screen is open and working right now! :S The screen turns off > properly when I close the lid, however this seems not to be noticed by the > system (suspend to RAM option when closing the lid does not work). > > > > > It will be great if you can attach the output of dmidecode on your box. > Done. >
Created attachment 31920 [details] [review] try the debug patch and see whether the issue still exists Will you please try the debug patch and see whether the issue still exists? Thanks.
Hi, the patched kernel works well. What's the next step to get that future versions of the kernel include the patch?
The patch is already shipped in Eric's drm-intel-next tree. commit a3cb5195f6db58dbebd8a31b877ddce082c9b63d Author: Zhao Yakui <yakui.zhao@intel.com> Date: Fri Dec 11 09:26:10 2009 +0800 drm/i915: Add MALATA PC-81005 to ACPI LID quirk list So this bug will be marked as the resolved. Thanks.
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.