[Intel-gfx] [PATCH] drm/i915: Fail to load driver if KMS request without GEM
The i915's implementation of KMS requires GEM in order to manage the
memory and execution domains of the framebuffer and associated
resources. By the point at which we detect broken a BIOS and need to
disable GEM, we have already registered ourselves as a KMS driver with
several subsystems. Rather than introducing a fragile unwind and attempt
to continue with UMS, spit out an error and unload the driver.
References:
[Bug 15754] IP: [a0207589] drm_mm_search_free+0x49/0x90 [drm]
BUG: unable to handle kernel NULL pointer dereference at (null)
https://bugzilla.kernel.org/show_bug.cgi?id=15754
[drm:i915_driver_load] *ERROR* Detected broken video BIOS with
262140/262144kB of video memory stolen.
[drm:i915_driver_load] *ERROR* Disabling GEM. (try reducing stolen
memory or updating the BIOS to fix).
i915 :00:02.0: irq 30 for MSI/MSI-X
[drm] set up 255M of stolen space
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [a0207589] drm_mm_search_free+0x49/0x90 [drm]
PGD 69719067 PUD 69dda067 PMD 0
Oops: [#1] PREEMPT SMP
last sysfs file: /sys/module/snd_seq_oss/initstate
CPU 1
Pid: 867, comm: modprobe Not tainted 2.6.33-ARCH #1 G43Twins-FullHD/To
Be Filled By O.E.M.
RIP: 0010:[a0207589] [a0207589]
drm_mm_search_free+0x49/0x90 [drm]
RSP: 0018:8800699f3af8 EFLAGS: 00010246
RAX: RBX: RCX:
RDX: 1000 RSI: 1000 RDI: 8800693d0f78
RBP: 8800699f3b18 R08: 1000 R09:
R10: R11: R12: 880068de70c0
R13: 1000 R14: R15: 8800689cb000
FS: 7fa93f4e5700() GS:88000188()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 695a CR4: 000406e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process modprobe (pid: 867, threadinfo 8800699f2000, task 8800694f4740)
Stack:
880068de73c0 880068de70c0 8800689cb000 1000
0 8800699f3b68 a0299f63 8800693d0f78 120068de70c0
0 8800689cb000 880068de73c0 880068de70c0 8800689cb000
Call Trace:
[a0299f63] i915_gem_object_bind_to_gtt+0x83/0x360 [i915]
[a029a2e5] i915_gem_object_pin+0xa5/0xb0 [i915]
[a029a3c5] i915_gem_init_ringbuffer+0xd5/0x510 [i915]
[a028dbee] i915_driver_load+0x4ce/0xd00 [i915]
[a0205d37] ? drm_sysfs_device_add+0x87/0xb0 [drm]
[a0203363] ? drm_get_minor+0x1d3/0x330 [drm]
[a02037e6] drm_get_dev+0x326/0x580 [drm]
[a02bc0a5] i915_pci_probe+0x10/0xd0 [i915]
[811e98a2] local_pci_probe+0x12/0x20
[811ea8e0] pci_device_probe+0x80/0xb0
[8127b12a] ? driver_sysfs_add+0x5a/0x90
[8127b273] driver_probe_device+0x93/0x1a0
[8127b413] __driver_attach+0x93/0xa0
[8127b380] ? __driver_attach+0x0/0xa0
[8127a8f8] bus_for_each_dev+0x68/0x90
[8127b0c9] driver_attach+0x19/0x20
[8127a0ad] bus_add_driver+0xcd/0x2d0
[8127b718] driver_register+0x78/0x140
[811eab91] __pci_register_driver+0x51/0xd0
[a02d6000] ? i915_init+0x0/0x52 [i915]
[a01fdc31] drm_init+0x111/0x120 [drm]
[810eb0cd] ? register_shrinker+0x4d/0x60
[a02d6000] ? i915_init+0x0/0x52 [i915]
[a02d6050] i915_init+0x50/0x52 [i915]
[81002047] do_one_initcall+0x37/0x1a0
[8108ed17] sys_init_module+0xd7/0x250
[81009fc2] system_call_fastpath+0x16/0x1b
Code: eb 29 49 8b 41 28 31 d2 49 f7 f5 85 d2 74 39 44 89 c0 29 d0 48 89 c2 48
01 f2 49 39 d2 73 29 0f 1f 00 49 89 da 4c 89 d3 4d 89 d9 4d 8b 19 49 39 f9 41
0f 18 0b 74 2b 4d 8b 51 30 4d 89 cc 49 39
RIP [a0207589] drm_mm_search_free+0x49/0x90 [drm]
RSP 8800699f3af8
CR2:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 851a2f8..39a685e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1672,6 +1672,13 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
dev_priv-has_gem = 0;
}
+ if (dev_priv-has_gem == 0
+ drm_core_check_feature(dev, DRIVER_MODESET)) {
+ DRM_ERROR(kernel modesetting requires GEM, disabling
driver.\n);
+ ret = -ENODEV;
+ goto out_iomapfree;
+ }
+
dev-driver-get_vblank_counter = i915_get_vblank_counter;
dev-max_vblank_count = 0xff; /* only 24 bits of frame count */
if (IS_G4X(dev) || IS_IRONLAKE(dev) || IS_GEN6(dev)) {
--
1.7.1
___
Re: [Intel-gfx] [PATCH] drm/i915: Add CxSR support on Pineview DDR3
On 2010.05.17 22:07:30 +0800, Li Peng wrote: Pineview with DDR3 memory has different latencies to enable CxSR. This patch updates CxSR latency table to add Pineview DDR3 latency configuration. It also adds one flag is_ddr3 for checking DDR3 setting in MCHBAR. This is not against drm-intel-next? which has commit d4294342f to cleanup wm setup for pineview. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Unexpected behaviour of xrandr and the Intel driver on monitor hotplug
Hello, Before I file bugs, I'd like to check that the behaviour I'm seeing is unexpected. In all testing, I'm on an Intel 945 platform, running Fedora 12 for most of the stack (including the kernel), but with recent git master of xserver, xf86-video-intel, libdrm and mesa. In all cases, I'm testing the behaviour of the system with the command xrandr --prop. I'm trying to use xrandr to replace an external EDID parser in our product; the ultimate goal is to present the user with the xrandr modes to choose from, flagging the monitor's preferred mode as such, but permitting users to force other modes (e.g. because your VGA over Cat5e solution doesn't handle the display's native resolution). The mode set in the xorg.conf file is named NTB-vesa_cvt-1360x768. I'm seeing two problems, which I'll describe, then give xrandr output for, so that you can see what's confusing me. The first bit of misbehaviour I'm seeing is caching of EDID across hotplug events. If I boot my system with no display attached, I correctly see no EDID property. When I connect a monitor via VGA, using cabling that supports DDC, I see EDID. When I unplug the monitor, I continue to see the old EDID. When I then plug in using a cable that doesn't support DDC, I see an extra mode appear in the mode list, but the EDID has not changed. Connecting using the original cable, or disconnecting cables completely removes this extra mode. In xrandr terms: On boot without a cable: # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected 1360x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm NTB-vesa_cvt-1360x768 59.8*+ 1600x1200 60.0 1400x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x60060.3 640x48060.0 59.9 DVI1 disconnected (normal left inverted right x axis y axis) Attach a monitor to VGA1: # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1920x1200 60.0 + 1600x1200 60.0 1280x1024 60.0 1024x768 60.0 800x60060.3 640x48060.0 DVI1 disconnected (normal left inverted right x axis y axis) Unplug that monitor (where's this EDID coming from?): # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1280x1024 60.0 1024x768 60.0 800x60060.3 640x48060.0 DVI1 disconnected (normal left inverted right x axis y axis) Plug in a different monitor via a cable that doesn't support DDC (where's the EDID coming from? Where does 848x480 come from?): # xrandr --prop VGA1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1280x1024 60.0 1024x768 60.0 800x60060.3 848x48060.0 640x48060.0 59.9 DVI1 disconnected (normal left inverted right x axis y axis) Finally, unplug the cable (where's this EDID from? Why has 848x480 disappeared?): # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832
Re: [Intel-gfx] Intel drivers
Hello! I would like to know if your team is working on adding h.264 hardware decoding support for the Intel GMA 4500MHD graphics card and if yes, when it might be available! Thank you! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Query on Intel IGP and audio over displayport
On Mon, May 17, 2010 at 3:16 AM, Zhenyu Wang zhen...@linux.intel.com wrote: On 2010.05.15 03:46:35 +0200, Mikael Öhman wrote: Hello. I was wondering if it was possible to send audio over displayport using a Core i5 661 (Clarkdale) IGP. I have seen some charts indicating that the hardware actually supports it, but I'm not even sure if I should ask here or perhaps to some ALSA mailing list. On google I have only found things related to DP-HMDI with audio, which I don't need. Yeah, we're looking into that actually. And current difficult is how to identify the DP sink device really has audio support. One is to use EDID CEA ext 'basic audio' feature, and another I've tried is to parse DPCD downstream device type. Unfortunately the DP monitors we have now don't have sane indication for them all, so we don't have good hardware to verify this (also tried windows driver but still failed with DP audio on it). Maybe we should just use EDID to determine whether enable audio or not. Xorg.log do contain some EDID output. I don't know what tool i should use otherwise. get-edid gives me some errors (and it tries to parse my second monitor only, I need to disconnect it when i get home). It doesn't give me any more information anyway. (II) intel(0): EDID for output DP3 (II) intel(0): Manufacturer: NEC Model: 677a Serial#: 0 (II) intel(0): Year: 2009 Week: 49 (II) intel(0): EDID Version: 1.4 (II) intel(0): Digital Display Input (II) intel(0): 8 bits per channel (II) intel(0): Digital interface is DisplayPort snip (II) intel(0): Monitor name: EA231WMi (II) intel(0): Serial No: 9Z104746NB (II) intel(0): Number of EDID sections to follow: 1 (II) intel(0): EDID (in hex): (II) intel(0): 000038a37a67 (II) intel(0): 31130104a5331d78e2f805a4554d9d25 (II) intel(0): 125054bfef8081008140818081c09500 (II) intel(0): 9040b300a9c0023a801871382d40582c (II) intel(0): 4500fe1f111e00fd00384c1f (II) intel(0): 5311000a20202020202000fc0045 (II) intel(0): 41323331574d690a2020202000ff (II) intel(0): 00395a3130343734364e420a202001a5 If i read the specification for EDID correctly, 01 would specify 1 extension block. The extension block doesn't seem to printed in Xorg.0.log aplay only lists card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog] card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital] card 0: Intel [HDA Intel], device 3: INTEL HDMI 0 [INTEL HDMI 0] card 0: Intel [HDA Intel], device 7: INTEL HDMI 1 [INTEL HDMI 1] and naturally I've tried them all, with no sound. I'm using Debian unstable, and xserver-xorg-video-intel 2.11 (everything else also uptodate with Sid if that matters.) You may try to force 'has_audio' to true in intel_dp.c, and try with HDA HDMI codec. Let me know if that'll work for you, and what's your monitor model? I have a NEC EA231WMi I just accidentally found that my monitor had the option to select sound from DP (and I can't test it with any other equipment). I will test it be hardcoding has_audio=true tonight. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
Hi On Mon, May 17, 2010 at 09:43:02AM +0800, Zou, Nanhai wrote: You may check how user space works in VAAPI code, if you have an Ironlake system. We have install guide at http://intellinuxgraphics.org/h264.html. We have some customer requests for H.264 decoding, so we point to an early kernel and a similar patch on that page. I'll try this out. But likely takes a while till I get around - there's enough other stuff going on to keep me busy. Actually no additional synchronize was add to user space, after BSD decoding is done, we map the BSD output for media pipe input command stream, at this point kernel will wait BSD decoding done before it begin media pipe. so unprivileged client can not damage GPU with this. Though this is not the most efficient way to do the work, One of our optimize plan is to have double ring buffer for H.264 decoding later, e.g. while BSD is decoding to one buffer, media pipe may consume another buffer, So media and BSD ring can work in parallel. Once we begin to do that, we may need to design a better synchronize method. Well, that's exactly the problem. You simply can't optimize a kernel interface once it's in use. And if you try to, your users will get the pitchforks and scream bloody murder trying to get you ;) So we need to get these patches right (at least the semantics of the interface) beforehand. Thanks Zou Nan hai Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
