http://bugs.freedesktop.org/show_bug.cgi?id=13801
Shuang He changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #5 from Shuang He
On Wed, Apr 22, 2009 at 11:48 AM, Shaohua Li wrote:
> drm_lock() does:
> for (;;) {
> __set_current_state(TASK_INTERRUPTIBLE);
> ...
> if (drm_lock_take(&master->lock, lock->context)) {
> < schedule() here
>
On Wed, Apr 22, 2009 at 6:52 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> On radeon at least this seems to solve a lot of our monitor misdetections.
>
> I suppose its possible if we are the end of a jiffy interval and we don't
> have 2.2ms left we could timeout early.
NAK (my own patch)
The p
http://bugs.freedesktop.org/show_bug.cgi?id=20869
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=20673
Tormod Volden changed:
What|Removed |Added
Component|DRM/Radeon |Drivers/DRI/r300
Product|DRI
On Tue, 21 Apr 2009 23:35:26 +0200
Niel Lambrechts wrote:
> Hi there,
>
> I get the following when I switch from runlevel 5 to 3 using the latest
> git kernel. I haven't noticed any other side-effects and X started up
> fine, but I'm assuming something is misbehaving and the trace might be
> mea
http://bugs.freedesktop.org/show_bug.cgi?id=13801
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=19717
Ian Romanick changed:
What|Removed |Added
AssignedTo|dri-|i...@freedesktop.org
|d
http://bugs.freedesktop.org/show_bug.cgi?id=21354
--- Comment #2 from Brian Paul 2009-04-23
09:44:08 PST ---
Created an attachment (id=25068)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25068)
patch for constant reuse
Can you try the attached patch? It tries to re-use existing con
On Thu, 2009-04-23 at 17:11 +0200, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
> > On Thu, 2009-04-23 at 14:29 +0200, Thomas Hellstrom wrote:
> >
> >> Jerome Glisse wrote:
> >>
> >>> On Thu, 2009-04-23 at 13:51 +0200, Thomas Hellstrom wrote:
> >>>
> >>>
> Jerome Glisse wro
Jerome Glisse wrote:
> On Thu, 2009-04-23 at 14:29 +0200, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Thu, 2009-04-23 at 13:51 +0200, Thomas Hellstrom wrote:
>>>
>>>
Jerome Glisse wrote:
> Hi Thomas,
>
> It seems my path for
http://bugs.freedesktop.org/show_bug.cgi?id=19415
Hugo Jacques changed:
What|Removed |Added
CC||hugo.jacq...@verint.com
--- Comment #4
http://bugs.freedesktop.org/show_bug.cgi?id=21355
Francois Gouget changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Maxim Grechkin changed:
What|Removed |Added
Attachment #25063|1 |0
is patch|
http://bugs.freedesktop.org/show_bug.cgi?id=21355
Summary: [945GME 3D] Assertion in intel_batchbuffer.c /
intel_flush_inline_primitive
Product: Mesa
Version: 7.0.3
Platform: x86 (IA32)
OS/Version: Linux (All)
Status
http://bugs.freedesktop.org/show_bug.cgi?id=21355
Francois Gouget changed:
What|Removed |Added
URL||http://www.gamershell.com/do
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Maxim Grechkin changed:
What|Removed |Added
Attachment #25058|application/octet-stream|text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Maxim Grechkin changed:
What|Removed |Added
Attachment #25059|application/octet-stream|text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Maxim Grechkin changed:
What|Removed |Added
Attachment #25060|application/octet-stream|text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Maxim Grechkin changed:
What|Removed |Added
Attachment #25061|application/octet-stream|text/plain
mime type|
On Thu, 2009-04-23 at 14:29 +0200, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
> > On Thu, 2009-04-23 at 13:51 +0200, Thomas Hellstrom wrote:
> >
> >> Jerome Glisse wrote:
> >>
> >>> Hi Thomas,
> >>>
> >>> It seems my path for bo move from system to vram is completely
> >>> wrong, i real
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Alex Deucher changed:
What|Removed |Added
Attachment #25063|application/octet-stream|text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=21354
--- Comment #1 from Francois Gouget 2009-04-23
07:10:31 PST ---
For reference, this happened with an Intel 945GME graphics card on an EeePC
1000H:
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML
Express Integr
http://bugs.freedesktop.org/show_bug.cgi?id=21354
Summary: Better optimize loading constants in VertexShaders
Product: Mesa
Version: unspecified
Platform: x86 (IA32)
URL: http://www.gamershell.com/download_16702.shtml
OS/Version: Li
On Thu, Apr 23, 2009 at 7:23 AM, Abraham Varricatt
wrote:
...
> Thank you for your reply Jerome.
>
> I was hoping that I could join in the development of the API or
> something, but if it's more than a year old ...
>
> The test applications in libdrm bug me. I can understand that
> development was
A. Hi, Eric
It is not very good to add the giant tables of modelines. It will be
perfect if the modeline is generated by using CVT/GTF algorithm.
Then I use the CVT/GTF to get the mode and find that the mode
generated by CVT/GTF is different with the default mode in Xserver.
For
Jerome Glisse wrote:
> On Thu, 2009-04-23 at 13:51 +0200, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> Hi Thomas,
>>>
>>> It seems my path for bo move from system to vram is completely
>>> wrong, i really have hard time to understand this bo move it
>>> looks way more complicate
On Thu, 2009-04-23 at 13:51 +0200, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
> > Hi Thomas,
> >
> > It seems my path for bo move from system to vram is completely
> > wrong, i really have hard time to understand this bo move it
> > looks way more complicated than it should be. Here is what i
>
Jerome Glisse wrote:
> Hi Thomas,
>
> It seems my path for bo move from system to vram is completely
> wrong, i really have hard time to understand this bo move it
> looks way more complicated than it should be. Here is what i
> do.
>
> tmp_mem = *old_mem;
> tmp_mem.mm_node = NULL;
> tmp_mem.propos
On Thu, Apr 23, 2009 at 4:38 PM, Jerome Glisse wrote:
>
> On Thu, 2009-04-23 at 14:55 +0530, Abru wrote:
> > The way GEM is designed, the memory manger is split up into 2 sections.
> > One section residing in the kernel and the other in userspace (or
> > libdrm). According to what I've read (maili
On Thu, 2009-04-23 at 14:55 +0530, Abru wrote:
> The way GEM is designed, the memory manger is split up into 2 sections.
> One section residing in the kernel and the other in userspace (or
> libdrm). According to what I've read (mailing list archives), the
> userspace section is supposed to be d
http://bugs.freedesktop.org/show_bug.cgi?id=21351
--- Comment #5 from Maxim Grechkin 2009-04-23 03:56:02
PST ---
Created an attachment (id=25063)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25063)
strace -o strace.log glxgears
--
Configure bugmail: http://bugs.freedesktop.org/use
Hi Thomas,
It seems my path for bo move from system to vram is completely
wrong, i really have hard time to understand this bo move it
looks way more complicated than it should be. Here is what i
do.
tmp_mem = *old_mem;
tmp_mem.mm_node = NULL;
tmp_mem.proposed_flags = TTM_PL_FLAG_TT | TTM_PL_MASK
http://bugs.freedesktop.org/show_bug.cgi?id=21351
--- Comment #4 from Maxim Grechkin 2009-04-23 03:35:53
PST ---
Probably similar to https://bugs.freedesktop.org/show_bug.cgi?id=21350
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
http://bugs.freedesktop.org/show_bug.cgi?id=21351
--- Comment #2 from Maxim Grechkin 2009-04-23 03:34:54
PST ---
Created an attachment (id=25060)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25060)
dmesg
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
---
http://bugs.freedesktop.org/show_bug.cgi?id=21351
--- Comment #3 from Maxim Grechkin 2009-04-23 03:35:22
PST ---
Created an attachment (id=25061)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25061)
patch used to make it work with 2.6.29
--
Configure bugmail: http://bugs.freedeskto
http://bugs.freedesktop.org/show_bug.cgi?id=21351
--- Comment #1 from Maxim Grechkin 2009-04-23 03:34:26
PST ---
Created an attachment (id=25059)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25059)
glxgears backtrace
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?
http://bugs.freedesktop.org/show_bug.cgi?id=21351
Summary: R600+DRI: glxgears crash
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: lowest
C
http://bugs.freedesktop.org/show_bug.cgi?id=21350
--- Comment #3 from Rafał Miłecki 2009-04-23 02:23:14 PST
---
Created an attachment (id=25055)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25055)
Xorg.0.log
Nothing special here I think, you can see my card is:
ATI Mobility 34xx, M8
The way GEM is designed, the memory manger is split up into 2 sections.
One section residing in the kernel and the other in userspace (or
libdrm). According to what I've read (mailing list archives), the
userspace section is supposed to be device specific. Or at least, should
be different depen
http://bugs.freedesktop.org/show_bug.cgi?id=21350
--- Comment #2 from Rafał Miłecki 2009-04-23 02:21:04 PST
---
Created an attachment (id=25054)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25054)
Full output of glxgears.
On photo output of glxgears is not full. It misses beginning
http://bugs.freedesktop.org/show_bug.cgi?id=21350
--- Comment #1 from Rafał Miłecki 2009-04-23 02:19:41 PST
---
Created an attachment (id=25053)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25053)
Photo of locked up screen.
--
Configure bugmail: http://bugs.freedesktop.org/userpre
http://bugs.freedesktop.org/show_bug.cgi?id=21350
Summary: R600+DRI: lockup on starting OpenGL app (experimental
code!)
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
43 matches
Mail list logo
