http://bugs.freedesktop.org/show_bug.cgi?id=17768
Gordon Jin changed:
What|Removed |Added
Component|DRM/other |DRM/Intel
Keywords|
http://bugs.freedesktop.org/show_bug.cgi?id=18180
Gordon Jin changed:
What|Removed |Added
AssignedTo|dri-|[email protected]
http://bugs.freedesktop.org/show_bug.cgi?id=18967
Gordon Jin changed:
What|Removed |Added
Summary|Xorg freeze after using |Xorg freeze after using
|
http://bugs.freedesktop.org/show_bug.cgi?id=19170
Gordon Jin changed:
What|Removed |Added
AssignedTo|dri-|[email protected]
|de...@li
http://bugs.freedesktop.org/show_bug.cgi?id=19249
Gordon Jin changed:
What|Removed |Added
AssignedTo|dri-|[email protected]
http://bugs.freedesktop.org/show_bug.cgi?id=19415
Gordon Jin changed:
What|Removed |Added
Component|DRM/other |DRM/Intel
--
Configure bugmail: http://
The basic problem was
mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap())
struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
We have plenty of places where we want to hold device state the same
(struct_mutex) while we move a non-trivial amount of data
(copy_from/to_user()), s
http://bugzilla.kernel.org/show_bug.cgi?id=12628
Summary: [i915] WARN_ON drivers/gpu/drm/i915/i915_gem.c:2470
Product: Drivers
Version: 2.5
KernelVersion: 2.6.28.2
Platform: All
OS/Version: Linux
Tree: Mainline
Statu
http://bugs.freedesktop.org/show_bug.cgi?id=19632
Gordon Jin changed:
What|Removed |Added
AssignedTo|dri-|[email protected]
|de.
http://bugs.freedesktop.org/show_bug.cgi?id=19786
Gordon Jin changed:
What|Removed |Added
AssignedTo|dri-|[email protected]
|de.
On Tuesday, February 3, 2009 4:17 pm Johannes Engel wrote:
> 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 c
http://bugs.freedesktop.org/show_bug.cgi?id=19698
--- Comment #7 from Dave Airlie 2009-02-03 17:05:56
PST ---
I can't see why the hell this is failing, the only think I can think of is a
bug in libdrm somehow,
you could try making libdrm and using it instead of the system one
The other o
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
On Mon, Feb 2, 2009 at 5:36 PM, Michel Dänzer wrote:
> On Mon, 2009-02-02 at 17:31 -0500, Alex Deucher wrote:
>> On Mon, Feb 2, 2009 at 5:11 PM, Michel Dänzer wrote:
>> > On Mon, 2009-02-02 at 17:06 -0500, Alex Deucher wrote:
>> >> On Sat, Jan 31, 2009 at 8:26 AM, Michel Dänzer wrote:
>> >> > On
On Tuesday, February 3, 2009 3:50 pm Johannes Engel wrote:
> 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 000
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
http://bugzilla.kernel.org/show_bug.cgi?id=12419
--- Comment #2 from [email protected] 2009-02-03 15:02 ---
On Tuesday 20 January 2009, Wang Chen wrote:
> Rafael J. Wysocki said the following on 2009-1-20 5:32:
> > This message has been generated automatically as a part of a report
> > of
Record and restore the kernel framebuffer for all crtc on panic
and lastclose.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/intel_fb.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/i
On Tue, 2009-02-03 at 09:47 -0800, Jesse Barnes wrote:
> On Tuesday, February 3, 2009 9:26 am Michel Dänzer wrote:
> > On Tue, 2009-02-03 at 08:58 -0800, Jesse Barnes wrote:
> > > What I'm saying is that anything greater than a few hundred frames (up
> > > to the limit) will be caught by the timeou
On Tuesday, February 3, 2009 9:26 am Michel Dänzer wrote:
> On Tue, 2009-02-03 at 08:58 -0800, Jesse Barnes wrote:
> > What I'm saying is that anything greater than a few hundred frames (up
> > to the limit) will be caught by the timeout,
>
> If it wasn't for the problems that triggered all these d
On Tue, 2009-02-03 at 08:58 -0800, Jesse Barnes wrote:
> On Tuesday, February 3, 2009 1:34 am Michel Dänzer wrote:
> > On Mon, 2009-02-02 at 18:15 -0800, Jesse Barnes wrote:
> > > On Monday, February 2, 2009 2:49 pm Michel Dänzer wrote:
> > >
> > > though I'm not sure why we need a frame count cap
On Tuesday, February 3, 2009 1:34 am Michel Dänzer wrote:
> On Mon, 2009-02-02 at 18:15 -0800, Jesse Barnes wrote:
> > On Monday, February 2, 2009 2:49 pm Michel Dänzer wrote:
> >
> > As for the higher level question, I hope we both agree that we should fix
> > this up,
>
> I'm fine with it, as lon
http://bugs.freedesktop.org/show_bug.cgi?id=19932
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=19932
Summary: flightgear shows strange things
Product: Mesa
Version: CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component:
>> Are there any patch i could try?
>> Is it possible to run a git bisect excluding all drm commits to find
>> the other bug?
> hello,
>
> I tried 2.6.29-rc3, and things got a little better. Suspend/resume
> results in a garbage video, but now i have access to my desktop via SSH
> after resum
Abru wrote:
> Hi guys,
>
> I have a netbook based on a VIA chipset. I've been trying for sometime
> to port the DRM modesetting functions to it. (Without much success so
> far..) For reference, I'm looking at the i915 code. (Making VIA-specific
> changes, as I understand)
>
> What stumps me at t
Hi guys,
I have a netbook based on a VIA chipset. I've been trying for sometime
to port the DRM modesetting functions to it. (Without much success so
far..) For reference, I'm looking at the i915 code. (Making VIA-specific
changes, as I understand)
What stumps me at the moment is how ring-buff
I can confirm that this patch fixes the problem. I tested with the locking
validator, and it looks like locking is now fine on my hardware.
Thanks everyone for tracking down this issue.
-Daniel
On Tue, Feb 03, 2009 at 09:58:16AM +, Dave Airlie wrote:
> On Mon, 2 Feb 2009, Andrew Morton wrote
On Mon, Feb 02, 2009 at 10:44:48PM -0800, Andrew Morton wrote:
> > Enabling kms works flawlessly now, but when I fire up X, the screen blanks
> > (no more blinking cursors), then X hangs. vt-switchings doesn't work
> > anymore, otherwise the machine looked fine (ping on the network was fine,
> > co
On Mon, 2 Feb 2009, Andrew Morton wrote:
> (cc's added)
>
> On Sat, 31 Jan 2009 16:25:08 +0100 Daniel Vetter wrote:
>
> > On Thu, Jan 29, 2009 at 01:48:25PM -0800, Andrew Morton wrote:
> > > On Thu, 29 Jan 2009 13:24:17 -0800
> > > Jesse Barnes wrote:
> > > > On Thursday, January 29, 2009 12:
On Mon, 2009-02-02 at 18:15 -0800, Jesse Barnes wrote:
> On Monday, February 2, 2009 2:49 pm Michel Dänzer wrote:
>
> As for the higher level question, I hope we both agree that we should fix
> this
> up,
I'm fine with it, as long as it's clear that it's just a workaround for
bad counter behavi
http://bugzilla.kernel.org/show_bug.cgi?id=12356
--- Comment #5 from [email protected] 2009-02-03 01:31 ---
Ok, MSI helps me. I think it's worth to force MSI in code whenever user enables
i915 drm...
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
On Tue, Jan 6, 2009 at 7:10 AM, Kristian Høgsberg wrote:
> The kernel shouldn't be in the business of telling user space which
> driver to load. The kernel defers mapping PCI IDs to module names
> to user space and we should do the same for DRI drivers.
>
> And in fact, that's how it does work to
>
> BTW. Do you guys want me to remove the drm_local_map_t typedef
> completely in favor of struct drm_local_map ? I have a patch here going
> part way through that, it's fairly trivial, so if you want it, I can
> easily finish it.
One less typedef is always welcome.
Dave.
>
> Cheers,
> Ben.
>
> Don't worry I've applied the patches with Erics comment replacing your one.
>
> All 3 are queued in drm-next.
Thanks !
I'll let you know when I finally get a chance to tackle the other
issues.
BTW. Do you guys want me to remove the drm_local_map_t typedef
completely in favor of struct drm_lo
On Mon, Jan 5, 2009 at 7:55 AM, Kristian Høgsberg wrote:
> Under kernel modesetting, we manage the device at all times, regardless
> of VT switching and X servers, so the only decent thing to do is to
> claim the PCI device. In that case, we call the suspend/resume hooks
> directly from the pci d
On Tue, Feb 3, 2009 at 7:21 AM, Benjamin Herrenschmidt
wrote:
>
>>
>> Could this comment instead be maybe:
>>
>> Because the kernel-userspace ABI is fixed at a 32-bit offset, while PCI
>> resources may live above that, we ignore the map offset for maps of type
>> _DRM_FRAMEBUFFER or _DRM_REGISTERS
37 matches
Mail list logo
