Bug description: When my xserver starts and tries to enable kernel mode setting I get an OOPS and a blank screen with no console switching possible. Enabling KMS per default through kernel config in i915-drm results in that OOPS at boot-time but without a blank screen. System environment: -- chipset: Intel Corporation 82801DBM (ICH4-M) -- system architecture: IA32 -- xf86-video-intel: 2.6.3 -- xserver: 1.6.0 and 1.6.1 -- mesa: 7.4 called intel-dri -- libdrm: 2.4.9 -- kernel: Linux cruss 2.6.29.1-minimal #10 PREEMPT Thu Apr 16 03:24:30 CEST 2009 i686 Intel(R) Pentium(R) M processor 1.70GHz GenuineIntel GNU/Linux (and 2.6.30-rc2) -- Linux distribution: archlinux(.org) -- Machine or mobo model: Dell Latitude D500, ICH4 -- Display connector: Intel Corporation 82852/855GM Integrated Graphics Device Reproducing steps: 1) Install v2.6.3 of xf86-video-intel 2) startx Additional info: 1) Not occuring at boot-time shutdown/reboot ist still possible over ssh. 2) intel agpgart / drm are built-in in my kernel config. 3) Option "DRI" "off" on v2.6.3 precludes triggering the bug. 4) My distribution repo provides a so called xf86-video-intel-legacy package including v2.3.2 of xf86-video-intel patched to run with Xorg 1.6.0/1 which works fine, without KMS/DRI2 features I guess. 5) startx withough Xorg.conf (=configuration through hal) does not help. 6) This is how Xorg.log ends: (II) intel(0): [DRI] installation complete 7) This is bug related dmesg output: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<(null)>] (null) *pde = 00000000 Oops: 0000 [#1] PREEMPT last sysfs file: /sys/devices/virtual/dmi/id/chassis_asset_tag Modules linked in: nls_iso8859_15 cifs nls_base cryptomgr aead crypto_blkcipher crypto_hash aes_generic crypto_algapi lib80211_crypt_ccmp crypto ipw2200 libipw lib80211 Pid: 15300, comm: X Not tainted (2.6.29.1 #3) Latitude D500 EIP: 0060:[<00000000>] EFLAGS: 00213246 CPU: 0 EIP is at 0x0 EAX: 00000000 EBX: c1734e00 ECX: 00000040 EDX: c1734e00 ESI: 00000000 EDI: f2513874 EBP: 00000000 ESP: f6972dec DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process X (pid: 15300, ti=f6972000 task=f2522320 task.ti=f6972000) Stack: c024a59d 000000d0 00000000 00000000 f73a5960 f2513874 00000020 c024a690 00000000 00000000 c037d026 00000000 f6b63700 00000000 f73a5a20 f73a5960 f7022000 f73a5a20 f73a5960 c037fb07 00000000 c0258118 00000003 00001000 Call Trace: [<c024a59d>] read_cache_page_async+0x6d/0x150 [<c024a690>] read_cache_page+0x10/0x60 [<c037d026>] i915_gem_object_get_page_list+0x96/0x100 [<c037fb07>] i915_gem_object_bind_to_gtt+0x167/0x240 [<c0258118>] shmem_file_setup+0xf8/0x1f0 [<c037fd35>] i915_gem_object_pin+0x155/0x1a0 [<c037e1f2>] i915_gem_init_object+0x12/0x50 [<c036a0af>] drm_gem_object_alloc+0x6f/0xb0 [<c037fe8f>] i915_gem_init_ringbuffer+0x10f/0x490 [<c021b526>] update_curr+0x126/0x190 [<c0238a11>] getnstimeofday+0x51/0x120 [<c0238a11>] getnstimeofday+0x51/0x120 [<c0380253>] i915_gem_entervt_ioctl+0x43/0xf0 [<c023bc23>] clockevents_program_event+0xa3/0x170 [<c036896e>] drm_ioctl+0xee/0x2f0 [<c0239252>] update_wall_time+0x492/0x8d0 [<c0238a11>] getnstimeofday+0x51/0x120 [<c0380210>] i915_gem_entervt_ioctl+0x0/0xf0 [<c027fb70>] vfs_ioctl+0x80/0x90 [<c027fd3b>] do_vfs_ioctl+0x7b/0x5d0 [<c023cd32>] tick_dev_program_event+0x32/0xb0 [<c023d210>] tick_nohz_handler+0xa0/0xd0 [<c02802cd>] sys_ioctl+0x3d/0x70 [<c02034b1>] sysenter_do_call+0x12/0x25 [<c0490000>] packet_setsockopt+0xa0/0x4b0 Code: Bad EIP value. EIP: [<00000000>] 0x0 SS:ESP 0068:f6972dec ---[ end trace cd6f39543d792843 ]--- ###
Supplemental: Linux 2.6.30-rc3 fails also.
Linux 2.6.30-rc3 (frame pointers enabled) dmesg output after startx: ### BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<(null)>] (null) *pde = 00000000 Oops: 0000 [#1] PREEMPT last sysfs file: /sys/devices/virtual/dmi/id/chassis_asset_tag Modules linked in: cryptomgr aead pcompress crypto_blkcipher crypto_hash aes_gen eric crypto_algapi lib80211_crypt_ccmp crypto ipw2200 libipw lib80211 Pid: 1704, comm: X Not tainted (2.6.30-rc3-testing #5) Latitude D500 EIP: 0060:[<00000000>] EFLAGS: 00213246 CPU: 0 EIP is at 0x0 EAX: 00000000 EBX: c17c7720 ECX: 00000040 EDX: c17c7720 ESI: 00000000 EDI: f70a29f4 EBP: f6b6cdcc ESP: f6b6cdb4 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process X (pid: 1704, ti=f6b6c000 task=f71d13e0 task.ti=f6b6c000) Stack: c023c07b 00000000 00000000 00000000 f6b69e80 00000020 f6b6cddc c023c10b 00000000 00000000 f6b6cdfc c032f33a 00000000 f6aef000 f70a29f4 f6b69e80 f6aef000 f6b69e80 f6b6ce2c c032fda4 00001000 f7021b84 f7021bac f7021ba4 Call Trace: [<c023c07b>] ? read_cache_page_async+0x7b/0xff [<c023c10b>] ? read_cache_page+0xc/0x3f [<c032f33a>] ? i915_gem_object_get_pages+0x94/0xe3 [<c032fda4>] ? i915_gem_object_bind_to_gtt+0x17f/0x21e [<c032fe64>] ? i915_gem_object_pin+0x21/0x138 [<c0330111>] ? i915_gem_init_ringbuffer+0x196/0x3f2 [<c022e713>] ? getnstimeofday+0x54/0xd7 [<c03303d3>] ? i915_gem_entervt_ioctl+0x66/0xf4 [<c031d712>] ? drm_ioctl+0x1ee/0x273 [<c033036d>] ? i915_gem_entervt_ioctl+0x0/0xf4 [<c0207012>] ? __switch_to_xtra+0x106/0x175 [<c0201812>] ? __switch_to+0x102/0x137 [<c0217017>] ? finish_task_switch+0x2f/0x6c [<c04075cc>] ? __schedule+0x2b7/0x2f7 [<c022b5e9>] ? unlock_hrtimer_base+0x1b/0x26 [<c022b6a6>] ? hrtimer_try_to_cancel+0x39/0x40 [<c02652e9>] ? vfs_ioctl+0x50/0x69 [<c0265727>] ? do_vfs_ioctl+0x425/0x45f [<c022b4fd>] ? hrtimer_wakeup+0x0/0x1c [<c026578d>] ? sys_ioctl+0x2c/0x45 [<c02028f4>] ? sysenter_do_call+0x12/0x26 Code: Bad EIP value. EIP: [<00000000>] 0x0 SS:ESP 0068:f6b6cdb4 CR2: 0000000000000000 ---[ end trace 4a173482a1d6f812 ]--- ### For testing I updated xf86-video-intel to 2.7.0 with no effect. Xorg.0.log still ends with (II) intel(0): [DRI] installation complete
Under these circumstances I _un_successfully tried to enable the right i2c driver for my machine, cause i915-drm enables i2c-subsystem anyway. I assume that the bios of my Latitude D500 hides this SMBus and access is only given through acpi-subsystem according to kernel i2c documentation. May that be a source of this problem?
2.6.30-rc2 is working for me (from drm-intel-next), with compiz even. But I'm using the driver from git (something close to 2.7.0). Can you re-test with more recent 2D driver bits?
Also, please attach your X log and dmesg from the failure.
Created attachment 25309 [details] Kernel Oops, complete dmesg
I have compiled a new kernel 2.6.30-rc4 with intel agp/drm modules but still I get this OOPS (dmesg attached) when i915 module loads with kernel mode setting enabled by default, or when X (xf86-video-intel>=2.6.0) enables kernel mode setting in that i915 drm module or when i915 is built-in with kernel mode setting enabled (freeze at boot) or when it is built-in and X starts and enables KMS. For me it seems not to be a bug regarding xorg stuff. When started Xorg with kernel mode setting enabled by default or driver versions of xf86-video-intel that will try to enable the log ever ends this way: (II) intel(0): [DRI] installation complete Not enabling KMS per default in kernel config and using old xf86-video-drivers that do not try to enable it at all safes the kernel and X.
Created attachment 25313 [details] really complete dmesg with i915 configured without KMS per default
Created attachment 25314 [details] complete Xorg.0.log when starting without KMS enabled by default
Option "Tiling" "off" to xf86-video-intel eliminates (EE) intel(0): Failed to set tiling on front buffer: Invalid argument (EE) intel(0): Failed to set tiling on back buffer: Invalid argument (EE) intel(0): Failed to set tiling on depth buffer: Invalid argument but OOPS and frozen screen resist.
(In reply to comment #0) > System environment: > -- xf86-video-intel: 2.6.3 and 2.7.0 > -- xserver: 1.6.1 > -- mesa: 7.4.1 and called intel-dri > -- libdrm: 2.4.9 > -- kernel: 2.6.30-rc4
There may still be issues with buidling both agp & drm into the kernel. Can you try with just agp builtin and drm & i915 loaded after boot?
(In reply to comment #12) > There may still be issues with buidling both agp & drm into the kernel. Can > you try with just agp builtin and drm & i915 loaded after boot? Of course. Please take a look at the latest attachment.
Created attachment 25539 [details] the ultimate thing ;)
Created attachment 25540 [details] the ultimate thing ;) 2nd try
Ok there's something weird going on here. You're getting a panic at load time that indicates GEM hasn't been initialized properly, or there's an issue with your shared memory setup. Can you attach the kernel config you've been using? You might also try using Fedora's kernel config; it's been working on my 855.
Created attachment 25620 [details] kernel config I like to use
.30-rc5 with same results. Does it make sense to assign this on kernel bugzilla?
Created attachment 25678 [details] scenario with latest fedora kernel config
That fedora config thing worked. So I guess that I missed a thing in my kernel config. But this may tell that it is not automatically checked as it should be. I will have a look at that later. Right now I have to enjoy that shiny new KMS thing! Sorry for all this, thanks and regards.
Yes. There is a difficulty to get the configuration that is needed. The problem is that ACPI_VIDEO is absolutely important, but it is invisible in menuconfig till you set CONFIG_BACKLIGHT_CLASS_DEVICE && CONFIG_VIDEO_OUTPUT_CONTROL to "m" or "y". THEN ACPI_VIDEO option is showing up and tells that it DEPENDS on those two things. GNAAAAAAAAAARRRRRR Where are those hours ?
Supplemental: I have located another "unseen" dependency. If you don't want your X to crash enabling KMS with new intel drivers or a crash at boot-time with enabled (per default KMS) you have to check following things in your kernel config: CONFIG_TMPFS=y CONFIG_VIDEO_OUTPUT_CONTROL=y/m* CONFIG_BACKLIGHT_LCD_SUPPORT=y/m* CONFIG_BACKLIGHT_CLASS_DEVICE=y/m* CONFIG_ACPI_VIDEO=y/m* *Select y for CONFIG_DRM_I915_KMS=y Select m for CONFIG_DRM_I915_KMS=n Regards.
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.