Re: [PATCHES] radeon drm kms i2c fixes

AFAIK recompiling the Xorg driver should be enough in openSUSE 11.2. Cheers, Johannes 2010/3/15 Jean Delvare : > On Thu, 11 Mar 2010 13:35:47 -0500, Alex Deucher wrote: >> On Thu, Mar 11, 2010 at 1:00 PM, Jean Delvare wrote: >> > I have the following in my machine: >> > 02:00.0 VGA compatible co

Re: i915: gpu wedged [was: mmotm 2010-01-15-15-34 uploaded]

Sorry, forgot to reply to all lists last time... Looks like bug #15004 (kernel) or #25475 (Xorg). Cheers, Johannes -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data

Re: i915: gpu wedged [was: mmotm 2010-01-15-15-34 uploaded]

Am 23.01.2010 19:17, schrieb Jiri Slaby: > On 01/23/2010 01:56 PM, Jiri Slaby wrote: >> and kernel says: >> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung >> render error detected, EIR: 0x >> [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 >> (aw

Re: 2.6.33-rc3-git3: Reported regressions 2.6.31 -> 2.6.32

On 10.01.2010 23:45, Rafael J. Wysocki wrote: > This message contains a list of some regressions introduced between 2.6.31 and > 2.6.32, for which there are no fixes in the mainline I know of. If any of > them > have been fixed already, please let me know. > > If you know of any other unresolved

Re: 2.6.32 / intel: starts ok but display suddenly blanks out

Hello, the same behaviour can be confirmed for 945GM using 2.6.32.1. Cheers, Johannes Am 16.12.2009 11:24, schrieb Adrian von Bidder: > Heyho! > > Is this already being investigated? > > (intel / X from squeeze == sid) > > X starts ok, but after some time (something like 15min) suddenly decid

Re: radeon kernel module fails to compile

Don't use that branch, it is outdated, the drm kernel stuff for radeon went into mainline long time ago. Please take kernel source from vanilla instead. Cheers, Johannes 2009/10/7 Johannes Obermayr : > Hi, > > I tried compiling radeon kernel module from nouveau/linux-2.6 on openSUSE > Build Servi

radeon KMS command stream errors

Hi folks, trying the latest kernel (git commit b592972493c38665efd7d429a01b23fcb21e331a) with radeon KMS, libdrm (5a73f066ba149816cc0fc2de4b97ec4714cf8ebc) with experimental-api, Mesa (dc516d6e2afe7f157dbe5aad1288e5624b27e093) and xf86-video-ati (447a2ce1b88aa2d6d5713e93174c4002617720f7) with a sl

[PATCH] drm/i915: correct typo in error message

Signed-off-by: Johannes Engel --- drivers/gpu/drm/i915/intel_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index e4652dc..a0c6dc5 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm

Re: [PATCH] drm/i915: correct typo in error message

Quoting Johannes Engel, On 05/16/2009 03:44 PM: > Signed-off-by: Johannes Engel > --- > drivers/gpu/drm/i915/intel_fb.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c > index e4

Re: [i915] unknown parameter

Jesse Barnes wrote: >> get fences failed: -1 >> param: 6, val: 0 >> glxgears: Error: couldn't get an RGB, Double-buffered visual. >> >> What's wrong here? Anything I can do to help? Is that related to Jesse's >> recent patch changing the fences check? >> > > The new get fences check shouldn't

[i915] unknown parameter

Hi folks, using latest kernel from airlied/drm-next together with git master as of today for modular X.org my kernel log shows a few messages like these: [ 390.305982] [drm] Initialized drm 1.1.0 20060810 [ 390.370356] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 390.370366] p

Re: intel text mode restore problem

Norbert Preining wrote: > Where can I get this intel_reg_dumper from? Is there a tree to check > out, or a ready made binary from x86_64 (Debian/unstable)? > It is residing in the git repository of the intel driver. Cheers, Johannes.

Re: [PATCH] vblank rework for drm-next

Maksym Veremeyenko wrote: > [EMAIL PROTECTED] drm-2.6]# patch -p1 < ../drm-next-vblank-rework-2.patch > patching file drivers/gpu/drm/drm_drv.c > patching file drivers/gpu/drm/drm_irq.c > Hunk #2 succeeded at 221 with fuzz 2. > Hunk #3 succeeded at 238 (offset -3 lines). > Hunk #4 succeeded at 280

[GEM i945] X server eats lots of cpu after resuming from s2ram

Hi guys, since I do not quite know who is the culprit for that problem, I want to ask here first before filing a bug report. Maybe one of you has got an idea how to deal with that. The problem is as follows: Using kernel 2.6.27-rc* with the GEM extensions from Eric's drm-gem-merge branch as of

modesetting-gem

Dear All, since Jesse merged the modesetting-gem branch to the intel driver we need the corresponding merge in drm as well, since the driver relies on that. But at least for me the kernel modules need some unknown symbols (kernel 2.6.27-rc3 with Eric's drm-gem-merge branch patches): WARNING:

Re: [PATCH 1/1 repost #1] DRM: don't enable irqs in locking

Thomas Hellström wrote: > Johannes Engel wrote: >> Thomas Hellström wrote: >>> Yes, this bug could occur, but the remedy is not to use >>> spin_lock_irqsave() for lock_data::spinlock but to avoid calling >>> drm_lock_take with the drm_device::tasklet_lock he

Re: [PATCH 1/1 repost #1] DRM: don't enable irqs in locking

Thomas Hellström wrote: > Yes, this bug could occur, but the remedy is not to use > spin_lock_irqsave() for lock_data::spinlock but to avoid calling > drm_lock_take with the drm_device::tasklet_lock held with irqs disabled. > I'll see if I can come up with a patch. Hi Thomas, any news on that so

[PATCH 1/1] Replace drmBO by drm_buffer_object

Hi folks, what do you think about this patch? It makes Mesa compile with TTM-api again. Cheers, Johannes >From 4915d2a7a385995ca6ce9cb58029121f6c8e18d3 Mon Sep 17 00:00:00 2001 From: Johannes Engel <[EMAIL PROTECTED]> Date: Mon, 11 Aug 2008 12:20:55 +0100 Subject: [PATCH 1/1] Repl

[PATCH 1/1] Adapt on_each_cpu

17 00:00:00 2001 From: Johannes Engel <[EMAIL PROTECTED]> Date: Wed, 30 Jul 2008 13:16:48 +0100 Subject: [PATCH 1/1] Adapt on_each_cpu Since kernel 2.6.27 on_each_cpu lost its retry argument Signed-off-by: Johannes Engel <[EMAIL PROTECTED]> --- linux-core/drm_ttm.c |4 1 f

Re: Replace nopfn by fault

00:00:00 2001 From: Johannes Engel <[EMAIL PROTECTED]> Date: Tue, 29 Jul 2008 22:17:04 +0100 Subject: [PATCH 1/1] Replace nopfn by fault This is necessary since kernel 2.6.27 will ship whithout nopfn. The method .fault is assumed to be present in kernels >= 2.6.23. Signed-off-by: Jo

Re: Replace nopfn by fault

iable DRM_HAS_FAULT which is defined for kernels from 2.6.23 and decides about using .fault or .nopfn. I attach a corrected version. Cheers, Johannes >From afa7bf20a62ce37b00c06a1ac53527656e4c1c43 Mon Sep 17 00:00:00 2001 From: Johannes Engel <[EMAIL PROTECTED]> Date: Tue, 29 Jul 2008

Replace nopfn by fault

Hi, folks, as Ross mentioned four days ago, nopfn has gone from the kernel tree. Therefore we need to adapt drm_vm.c to use fault instead. What do you think about the attached patch? Cheers, Johannes >From ba506005a6e7f7beaaedad7919eebf44b6e6db5b Mon Sep 17 00:00:00 2001 From: Johannes En

true boolean in drm_agpsupport.c

Hi folks, since my compiler always complains about that during (aborted) compilation of the kernel modules I decided to send that patch to the ML. Can we safely replace TRUE/FALSE by the boolean values true/false? Cheers, Johannes Signed-off-by: Johannes Engel <[EMAIL PROTECTED]> Repla

Re: [drm-gem] failing to compile

Stefano Avallone wrote: Hi all, after the last commit to the drm-gem branch of mesa/drm ("intel-gem: Add two new ioctls for managing tiling on objects."), I am no more able to compile the i915 drm kernel module. The problem is an implicit declaration of pci_read_base in i915_gem_tiling.c I

Re: Status of everything?

Ben Gamari wrote: > What trees are you pulling from. Pulling from drm/modesetting-gem and > mesa/drm-gem I'm getting some pretty obvious build errors (e.g. struct > drm_gem_open never defined). That's exactly what I am doing. Upto now I did not experience any of these errors. Cheers, Johannes --

Re: Status of everything?

Ben Gamari wrote: > On the note of GEM, would it be worth pulling down the GEM trees to play > around with and submit bugs against? Is the code in a state at all > resembling stable (can you run a moderately standard X session for more > than 10 seconds)? As far as I can tell this is working nearly

Re: drm-gem libdrm automake fix

Steven J Newbury wrote: > When building with a separate objdir -I$(top_srcdir)/libdrm needs to be > added to the intel Makefile.am otherwise only $(top_builddir)/libdrm is > included which doesn't contain the source headers. > > I've also been unable to build the drm-gem DRM module against the > cu

Re: GEM merging to master

Keith Packard wrote: > On Thu, 2008-06-12 at 16:06 +0100, Johannes Engel wrote: > >> Quoting He, Shuang: >> >>> You may need to build mesa with --enable-ttm-api, and update drm >>> kernel modules as well whose source is under drm/linux-core, >>&g

Re: GEM merging to master

Quoting He, Shuang: > You may need to build mesa with --enable-ttm-api, and update drm > kernel modules as well whose source is under drm/linux-core, Thanks for your hint, I had that symbol already enabled. Once I enabled ttm-api in Mesa I get the following (of course after recompiling xserver a

Re: GEM merging to master

Quoting Eric Anholt: > We're getting close to ready to mark GEM on Intel as done. We've got > one failing testcase that we isolated this week with interrupt handling, > and we've got a fix in testing that appears to be doing the job. > > Tomorrow I'm planning on merging the GEM code to master of a

Re: i915 performance, master, i915tex & gem

Thomas Hellström schrieb: > Johannes Engel wrote: >> Hi, everyone, >> >> I wonder how you got any OpenGL-app running using Keith's GEM tree. >> For me even glxgears turns the screen black although AFAIK not >> necessarily crashing the Xserver. >> I

Re: i915 performance, master, i915tex & gem

Johannes Engel schrieb: > Hi, everyone, > > I wonder how you got any OpenGL-app running using Keith's GEM tree. > For me even glxgears turns the screen black although AFAIK not > necessarily crashing the Xserver. > I will further investigate on that. OK, at lea

Re: i915 performance, master, i915tex & gem

Hi, everyone, I wonder how you got any OpenGL-app running using Keith's GEM tree. For me even glxgears turns the screen black although AFAIK not necessarily crashing the Xserver. I will further investigate on that. Best regards, Johannes

Re: intel-batchbuffer and DRI2

Jie Luo schrieb: > Johannes Engel wrote: >> Hello! >> >> Running intel-batchbuffer with DRI2 (mesa, drm, modular X.Org from git >> master resp. intel-batchbuffer), most things work quite well except >> frequent and regular crashes of X.org. >> Last exampl

intel-batchbuffer and DRI2

Hello! Running intel-batchbuffer with DRI2 (mesa, drm, modular X.Org from git master resp. intel-batchbuffer), most things work quite well except frequent and regular crashes of X.org. Last example some minutes ago working with eclipse (just writing). X.Org log is attached. Greetings, Johann

intel-batchbuffer with DRI2

Hi, Kristian and the rest of the DRI world! ;) Testing your most recent DRI2 work on my 945GM I ran into trouble starting compiz. Digging a little bit deeper I recognized, that glXGetFBConfigs seems not to return any FBConfig at all. But glxinfo lists a whole lot of them: ~/software/mesa/progs/

Re: DRI2 direct rendering

Thanks a lot for your work, Kristian! Testing DRI2 on my 945GM I get ~> glxgears calling DRI2CreateDrawable, XID 0x2c2, GLX ID 0x2c2 success, head 0x30, handle 0x2 DRM_I915_EXECBUFFER: -16 glxgears: intel_context.c:1010: UNLOCK_HARDWARE: Assertion `intel->batch->cliprect_mode != REFERENCE

Re: [Mesa3d-dev] Updated i915tex

Thomas Hellström wrote: > Hi! > > Tungsten Graphics has decided to push an updated version of i915tex, > that works with the latest xf86-video-intel and drm. The driver will be > available on the mesa i915tex-branch, which is based off the mesa_7_0 > branch. Hi, Thomas! I just tested the new co

Re: [Mesa3d-dev] Updated i915tex

Thomas Hellström schrieb: > Hi! > > Tungsten Graphics has decided to push an updated version of i915tex, > that works with the latest xf86-video-intel and drm. The driver will be > available on the mesa i915tex-branch, which is based off the mesa_7_0 > branch. Hi, Thomas! I just tested the new