Created attachment 64553 [details] lspci -vvnn output Hi, I'm on Debian Sid (system up to date: Linux 3.2) and wanted to run an xserver on my hardware. Unfortunately the driver cannot be loaded (I've attached the lspci log). # modprobe i915 ERROR: could not insert 'i915': No such device I bisected the kernel (v2.6.29 was a known kernel version where I could load the module, in v2.6.30 I noticed that it doesn't) and found out that the problem has been introduced by commit 74a365b3 in the Linux kernel: commit 74a365b3f354fafc537efa5867deb7a9fadbfe27 Author: Matthew Garrett <mjg59@srcf.ucam.org> Date: Thu Mar 19 21:35:39 2009 +0000 ACPI: Populate DIDL before registering ACPI video device on Intel Intel graphics hardware that implements the ACPI IGD OpRegion spec requires that the list of display devices be populated before any ACPI video methods are called. Detect when this is the case and defer registration until the opregion code calls it. Fixes crashes on HP laptops. http://bugzilla.kernel.org/show_bug.cgi?id=11259 Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Len Brown <len.brown@intel.com> I was not really successful in reverting the commit because between v2.6.29 and v3.2.0 just too much has been changed in the code. I hope someone can help me. Regards, Lukas
Can you please attach the dmesg with drm.debug=7, perhaps there's a clue in there as to why the ACPI interferes with loading the driver.
Created attachment 64601 [details] dmesg output (kernel cmdline: drm.debug=7)
I've attached the output of dmesg with drm.debug=7. Some background information: I try to run the xserver on an a few years old embedded x86 board. On Lenny (2.6.26), we didn't have any problems with the xserver (presumably because of UMS) - the problems began with updating to Squeeze (and KMS): With Debian's 2.6.32 (KMS has been backported from 2.6.33) the xserver neglected to start at all ("no screens found"). I bisected the kernel for the first time and found out that a somewhat similar (also ACPI related) regression caused the problems: The LVDS presence check that has been fixed in commit 5f4083394de68ae7a4eb3c82b2093e3520b9cac1 doesn't work on our hardware. commit 5f4083394de68ae7a4eb3c82b2093e3520b9cac1 Author: Adam Jackson <ajax@redhat.com> Date: Tue Nov 24 10:07:00 2009 -0500 drm/i915: Fix LVDS presence check Combined patches from 2.6.33 for fixing LVDS detection. 7cf4f69d3f4511f443473954456cb91d5514756d drm/i915: Don't set up the LVDS if it isn't in the BIOS device table. 38b3037ee47fbd65a36bc7c39f60a900fbbe3b8e drm/i915: Fix LVDS presence check 6e36595a2131e7ed5ee2674be54b2713ba7f0490 drm/i915: Declare the new VBT parsing functions as static 11ba159288f1bfc1a475c994e598f5fe423fde9d drm/i915: Don't check for lid presence when detecting LVDS Acked-by: Takashi Iwai <tiwai@suse.de> Cc: Matthew Garrett <mjg@redhat.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> I reverted the commit (and backported some stability fixes from 2.6.38+) and the xserver runs perfectly. Unfortunately, not on all of our boxes. The output of `lspci -vvnn` is completely the same on all of them but nevertheless on some of them I get the symptoms described in my initial post.
Just to be sure: are you any particular options when trying to load the module? 'modinfo | grep 3582' should confirm that your chipset is listed amongst the supported PCI-IDs, so I am drawing a blank as to why it appears not to even be probed.
# modinfo i915 | grep 3582 alias: pci:v00008086d00003582sv*sd*bc03sc*i* So yes, I assume it's supported (full output of modinfo attached). > Just to be sure: are you any particular options when trying to load the module? # cat /etc/modprobe.d/i915-kms.conf options i915 modeset=1 This is the default on Debian since Squeeze.
Created attachment 64774 [details] Output of `modinfo i915`
No idea either. I guess the only thing would be to smash tons of prinkt over our driver and figure out why it doesn't like the pcidevice ...
One thing to try is the noacpi kernel option...
The dmesg you attached looks like it doesn't have any info about the i915 driver, did you try loading it before capturing the dmesg? If so, we must be bailing out really early... Any way you can add a bunch of printks or DRM_ERRORs to the module init code to see what's going on like Daniel suggested? i915_drv.c would be the place to start. Likely something we depend on in the kernel is failing and so we return -ENODEV; could be a kernel .config issue (you could try a distro .config to see) or something funky with your system. But it also sounds like you may have two issues here: one where KMS failed altogether, but another where it worked but only after you reverted the LVDS presence check?
We're not making any progress here as we can't identify the issue without extra instrumentation. By all indications this should be working.
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.