https://bugs.freedesktop.org/show_bug.cgi?id=42090
--- Comment #2 from Fabio Pedretti 2011-10-24 00:19:29
PDT ---
(In reply to comment #1)
> Created attachment 52640 [details] [review]
> Possible fix
>
> Does this patch fix the problem?
Yes (tested on current git and also with
0dc97e7fd49a5b8d
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #2 from Alex Deucher 2011-10-24 06:22:51 PDT ---
Is there some reason why you want to use UMS? It's not really supported any
more.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
On Sat, Oct 22, 2011 at 12:38, Alex Deucher wrote:
> On Fri, Oct 21, 2011 at 3:29 PM, Jean Delvare wrote:
> > Hi Alex,
> >
> > On Friday 21 October 2011 08:05:48 pm Alex Deucher wrote:
> >> On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare
> >> > Does anyone know at which speed hardware I2C engine
On Thu, Oct 20, 2011 at 10:33, Jean Delvare wrote:
> Just to clarify: by "connectivity is setup", do you mean code in the
> driver setting the GPIO pin direction etc., or a display being
> connected to the graphics card?
>
> I admit I am a little surprised. I2C buses should have their lines up
>
On 10/08/2011 12:03 AM, Marek Olšák wrote:
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom wrote:
OK. First I think we need to make a distinction: bo sync objects vs driver
fences. The bo sync obj api is there to strictly provide functionality that
the ttm bo subsystem is using, and that
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #3 from Michal 2011-10-24 08:56:25 PDT ---
Well, yes, ums is about 2x faster then kms.
I think the problem is somewhere in textures. Lowering texture quality in
openarena, fps jumps from 5 to 60. The same with etracer, with low res t
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom wrote:
> On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
>>
>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>
>>>
>>> On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
>>>
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hell
On 10/24/2011 06:42 PM, Marek Olšák wrote:
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom wrote:
On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
On Fri,
Hi Thomas,
I have made no progress so far due to lack of time.
Would you mind if I fixed the most important things first, which are:
- sync objects are not ordered, (A)
- every sync object must have its corresponding sync_obj_arg, (B)
and if I fixed (C) some time later.
I planned on moving the t
On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I was hoping that we could get rid of the dma_address shuffling into
> core TTM,
> like I mentioned in the review. From what I can tell it's now only
> used in the backend and
> core ttm doesn't care about it.
>
> Is
Marek,
The problem is that the patch adds a lot of complicated code where it's
not needed, and I don't want to end up reverting that code and
re-implementing the new Radeon gem ioctl by myself.
Having a list of two fence objects and waiting for either of them
shouldn't be that complicated to
Alright then.
Dave, if you are reading this, feel free not to include the two
patches I sent you in the next pull request.
Marek
On Mon, Oct 24, 2011 at 7:28 PM, Thomas Hellstrom wrote:
> Marek,
>
> The problem is that the patch adds a lot of complicated code where it's not
> needed, and I don'
On 10/24/2011 07:27 PM, Konrad Rzeszutek Wilk wrote:
On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
Konrad,
I was hoping that we could get rid of the dma_address shuffling into
core TTM,
like I mentioned in the review. From what I can tell it's now only
used in the backen
> >For that there are couple of architectural issues I am not sure how to solve.
> >
> >There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> >to say: "here is a 'struct page *', give me the bus address". Currently
> >this is solved by keeping an array of DMA addresses along with t
https://bugs.freedesktop.org/show_bug.cgi?id=42067
--- Comment #3 from Harald Judt 2011-10-24 11:25:31 PDT ---
This was caused by enabling texture compression in core settings. Turning it
off makes the icons look right again.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #4 from Roland Scheidegger 2011-10-24 11:30:14
PDT ---
Some performance difference is expected due to kms not supporting tiling on
r200, though I would expect a 2x difference only if you also enabled hyperz
manually.
That said, if pe
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #5 from Marek Olšák 2011-10-24 11:46:25 PDT ---
I am leaning to believe that tiling can make such a difference.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=42067
--- Comment #4 from Harald Judt 2011-10-24 11:58:24 PDT ---
I think this might rather be a duplicate of bug 38173.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Y
https://bugs.freedesktop.org/show_bug.cgi?id=42175
Bug #: 42175
Summary: RV730: Display errors in glxgears & WebGL
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #1 from Stefan 2011-10-24 14:06:39 PDT ---
Created attachment 52710
--> https://bugs.freedesktop.org/attachment.cgi?id=52710
glxgears screenshot
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #2 from Stefan 2011-10-24 14:07:44 PDT ---
Created attachment 52713
--> https://bugs.freedesktop.org/attachment.cgi?id=52713
Lesson 3 screenshot
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #3 from Alex Deucher 2011-10-24 14:44:38 PDT ---
Can you bisect?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #4 from Stefan 2011-10-24 14:55:59 PDT ---
(In reply to comment #3)
> Can you bisect?
The change took place between 7.11-rc1 and -rc2:
a8907c6005d7935b4520255e12184c139471b5b9 is the first bad commit
commit a8907c6005d7935b4520255e1
- Original Message -
> On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> > From: Jakob Bornecrantz
> >
> > Signed-off-by: Jakob Bornecrantz
> > Signed-off-by: Thomas Hellstrom
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +-
> > 1 files changed, 9 i
From: Jerome Glisse
Since force handling rework of d0d0a225e6ad43314c9aa7ea081f76adc5098ad4
we could end up bouncing connector status btw disconnected and unknown.
When connector status change a call to output_poll_changed happen which
in turn ask again for detect but with force set.
So set the
On Mon, Oct 24, 2011 at 6:16 PM, wrote:
> From: Jerome Glisse
>
> Since force handling rework of d0d0a225e6ad43314c9aa7ea081f76adc5098ad4
> we could end up bouncing connector status btw disconnected and unknown.
> When connector status change a call to output_poll_changed happen which
> in turn
On Mon, Oct 24, 2011 at 03:01:23PM -0700, Jakob Bornecrantz wrote:
>
> - Original Message -
> > On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> > > From: Jakob Bornecrantz
> > >
> > > Signed-off-by: Jakob Bornecrantz
> > > Signed-off-by: Thomas Hellstrom
> > > ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #4 from Chris Rankin 2011-10-24 15:24:33
PDT ---
This bug is still happening after this new commit:
commit 2717b8f034db16cf551e167aa5ce3a9be3bf730b
Author: Mathias Fröhlich
Date: Sat Oct 8 21:33:23 2011 +0200
winsys/radeon:
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #6 from Michal 2011-10-24 15:42:28 PDT ---
In tests I'm using fluxbox without any compositing. My card is radeon 9100
(rebranded 8500) with 128mb vram. Libtxc library didn't change anything.
RADEON_DEBUG=fall puts in loop:
R200 begin
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #5 from Marek Olšák 2011-10-24 16:18:42 PDT ---
Created attachment 52721
--> https://bugs.freedesktop.org/attachment.cgi?id=52721
possible fix
Can you try this patch?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.c
On Fri, Oct 7, 2011 at 19:20, Michael Witten wrote:
> Date: Fri, 16 Sep 2011 20:45:30 +
>
> The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
> specify the size of an array, each element of which looks
> like this:
>
> struct radeon_debugfs {
> struct drm_info_list *files
This adds a new optional chunk to the CS ioctl that specifies optional flags
to the CS parser. Why this is useful is explained below. Note that some regs
no longer need the NOP relocation packet if this feature is enabled.
Tested on r300g and r600g with this flag disabled and enabled.
Assume there
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #14 from dmotd 2011-10-24 16:46:17
PDT ---
(In reply to comment #13)
> Try the following options in the kernel command line in grub:
> pci=nomsi
> noapic
> irqpoll
> and see if any of them help.
I have been running my machine with a
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #15 from Alex Deucher 2011-10-24 16:47:39 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > Try the following options in the kernel command line in grub:
> > pci=nomsi
> > noapic
> > irqpoll
> > and see if any of them
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #6 from Chris Rankin 2011-10-24 16:53:50
UTC ---
(In reply to comment #5)
> Can you try this patch?
Sorry, no change.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #7 from Roland Scheidegger 2011-10-24 17:03:22
PDT ---
Yes that's a fallback. Not sure why it would trigger texture mode fallback.
You could try attaching a debugger and see where r200Fallback gets that true
mode bit and work from th
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #5 from Stefan 2011-10-24 17:32:00 PDT ---
Mesa 7.12-devel (git-faa16dc) Works. No crash, no picture errors.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Maybe you are looking at the wrong branch, but I see it in drm-next (it
has been there since Oct 10)
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=c245cb9e15055ed5dcf7eaf29232badb0059fdc1
On Mon, 24 Oct 2011, Michael Witten wrote:
On Fri, Oct 7, 2011 at 19:20, Michael Wit
Can anyone give a suggestion, is wait-vblank fully implemented in page_flip()
for nouveau drm driver?
At 2011-10-24 14:30:55,chris wrote:
Dear,
I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
code, git drm 2.4.36.
When I run the vbltest program, it prints "60
2011/10/25 chris :
> Can anyone give a suggestion, is wait-vblank fully implemented in
> page_flip() for nouveau drm driver?
>
>
> At 2011-10-24 14:30:55,chris wrote:
>
> Dear,
>
> I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
> code, git drm 2.4.36.
> When I run th
e(&e->base.file_priv->event_wait);
6214 }
6215
6216 drm_vblank_put(dev, intel_crtc->pipe);
6217
Is there anyone use the same driver and found this issues can tell me "is it a
bug"?
Thanks!
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111024/26405bf2/attachment.htm>
https://bugs.freedesktop.org/show_bug.cgi?id=42090
--- Comment #2 from Fabio Pedretti 2011-10-24 00:19:29
PDT ---
(In reply to comment #1)
> Created attachment 52640 [details] [review]
> Possible fix
>
> Does this patch fix the problem?
Yes (tested on current git and also with
0dc97e7fd49a5b8d
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #2 from Alex Deucher 2011-10-24 06:22:51 PDT
---
Is there some reason why you want to use UMS? It's not really supported any
more.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivin
odonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111024/0db900e3/attachment.html>
and update the patch to use this option?
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111024/2d0c722f/attachment.htm>
On 10/08/2011 12:03 AM, Marek Ol??k wrote:
> On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom
> wrote:
>
>> OK. First I think we need to make a distinction: bo sync objects vs driver
>> fences. The bo sync obj api is there to strictly provide functionality that
>> the ttm bo subsystem is usi
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #3 from Michal 2011-10-24 08:56:25 PDT ---
Well, yes, ums is about 2x faster then kms.
I think the problem is somewhere in textures. Lowering texture quality in
openarena, fps jumps from 5 to 60. The same with etracer, with low res t
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom wrote:
> On 10/08/2011 01:27 PM, Ville Syrj?l? wrote:
>>
>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>
>>>
>>> On 10/08/2011 12:26 PM, Ville Syrj?l? wrote:
>>>
On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hell
On 10/24/2011 06:42 PM, Marek Ol??k wrote:
> On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom
> wrote:
>
>> On 10/08/2011 01:27 PM, Ville Syrj?l? wrote:
>>
>>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>>
>>>
On 10/08/2011 12:26 PM, Ville Syrj?l? wr
Hi Thomas,
I have made no progress so far due to lack of time.
Would you mind if I fixed the most important things first, which are:
- sync objects are not ordered, (A)
- every sync object must have its corresponding sync_obj_arg, (B)
and if I fixed (C) some time later.
I planned on moving the t
On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I was hoping that we could get rid of the dma_address shuffling into
> core TTM,
> like I mentioned in the review. From what I can tell it's now only
> used in the backend and
> core ttm doesn't care about it.
>
> Is
Marek,
The problem is that the patch adds a lot of complicated code where it's
not needed, and I don't want to end up reverting that code and
re-implementing the new Radeon gem ioctl by myself.
Having a list of two fence objects and waiting for either of them
shouldn't be that complicated to i
Alright then.
Dave, if you are reading this, feel free not to include the two
patches I sent you in the next pull request.
Marek
On Mon, Oct 24, 2011 at 7:28 PM, Thomas Hellstrom
wrote:
> Marek,
>
> The problem is that the patch adds a lot of complicated code where it's not
> needed, and I don
On 10/24/2011 07:27 PM, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
>
>> Konrad,
>>
>> I was hoping that we could get rid of the dma_address shuffling into
>> core TTM,
>> like I mentioned in the review. From what I can tell it's now only
>>
> >For that there are couple of architectural issues I am not sure how to solve.
> >
> >There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> >to say: "here is a 'struct page *', give me the bus address". Currently
> >this is solved by keeping an array of DMA addresses along with t
https://bugs.freedesktop.org/show_bug.cgi?id=42067
--- Comment #3 from Harald Judt 2011-10-24 11:25:31 PDT ---
This was caused by enabling texture compression in core settings. Turning it
off makes the icons look right again.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #4 from Roland Scheidegger 2011-10-24
11:30:14 PDT ---
Some performance difference is expected due to kms not supporting tiling on
r200, though I would expect a 2x difference only if you also enabled hyperz
manually.
That said, if pe
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #5 from Marek Ol??k 2011-10-24 11:46:25 PDT
---
I am leaning to believe that tiling can make such a difference.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=42067
--- Comment #4 from Harald Judt 2011-10-24 11:58:24 PDT ---
I think this might rather be a duplicate of bug 38173.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Y
https://bugs.freedesktop.org/show_bug.cgi?id=42175
Bug #: 42175
Summary: RV730: Display errors in glxgears & WebGL
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #1 from Stefan 2011-10-24 14:06:39 PDT ---
Created attachment 52710
--> https://bugs.freedesktop.org/attachment.cgi?id=52710
glxgears screenshot
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #2 from Stefan 2011-10-24 14:07:44 PDT ---
Created attachment 52713
--> https://bugs.freedesktop.org/attachment.cgi?id=52713
Lesson 3 screenshot
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #3 from Alex Deucher 2011-10-24 14:44:38 PDT
---
Can you bisect?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #4 from Stefan 2011-10-24 14:55:59 PDT ---
(In reply to comment #3)
> Can you bisect?
The change took place between 7.11-rc1 and -rc2:
a8907c6005d7935b4520255e12184c139471b5b9 is the first bad commit
commit a8907c6005d7935b4520255e1
- Original Message -
> On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> > From: Jakob Bornecrantz
> >
> > Signed-off-by: Jakob Bornecrantz
> > Signed-off-by: Thomas Hellstrom
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +-
> > 1 files changed, 9 i
From: Jerome Glisse
Since force handling rework of d0d0a225e6ad43314c9aa7ea081f76adc5098ad4
we could end up bouncing connector status btw disconnected and unknown.
When connector status change a call to output_poll_changed happen which
in turn ask again for detect but with force set.
So set the
On Mon, Oct 24, 2011 at 6:16 PM, wrote:
> From: Jerome Glisse
>
> Since force handling rework of d0d0a225e6ad43314c9aa7ea081f76adc5098ad4
> we could end up bouncing connector status btw disconnected and unknown.
> When connector status change a call to output_poll_changed happen which
> in turn
On Mon, Oct 24, 2011 at 03:01:23PM -0700, Jakob Bornecrantz wrote:
>
> - Original Message -
> > On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> > > From: Jakob Bornecrantz
> > >
> > > Signed-off-by: Jakob Bornecrantz
> > > Signed-off-by: Thomas Hellstrom
> > > ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #4 from Chris Rankin 2011-10-24
15:24:33 PDT ---
This bug is still happening after this new commit:
commit 2717b8f034db16cf551e167aa5ce3a9be3bf730b
Author: Mathias Fr?hlich
Date: Sat Oct 8 21:33:23 2011 +0200
winsys/radeon:
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #6 from Michal 2011-10-24 15:42:28 PDT ---
In tests I'm using fluxbox without any compositing. My card is radeon 9100
(rebranded 8500) with 128mb vram. Libtxc library didn't change anything.
RADEON_DEBUG=fall puts in loop:
R200 begin
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #5 from Marek Ol??k 2011-10-24 16:18:42 PDT
---
Created attachment 52721
--> https://bugs.freedesktop.org/attachment.cgi?id=52721
possible fix
Can you try this patch?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.
On Fri, Oct 7, 2011 at 19:20, Michael Witten wrote:
> Date: Fri, 16 Sep 2011 20:45:30 +
>
> The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
> specify the size of an array, each element of which looks
> like this:
>
> ?struct radeon_debugfs {
> ? ? ? ? ?struct drm_info_list ? ?*files
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #14 from dmotd 2011-10-24
16:46:17 PDT ---
(In reply to comment #13)
> Try the following options in the kernel command line in grub:
> pci=nomsi
> noapic
> irqpoll
> and see if any of them help.
I have been running my machine with a
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #15 from Alex Deucher 2011-10-24 16:47:39 PDT
---
(In reply to comment #14)
> (In reply to comment #13)
> > Try the following options in the kernel command line in grub:
> > pci=nomsi
> > noapic
> > irqpoll
> > and see if any of them
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #6 from Chris Rankin 2011-10-24
16:53:50 UTC ---
(In reply to comment #5)
> Can you try this patch?
Sorry, no change.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail b
Maybe you are looking at the wrong branch, but I see it in drm-next (it
has been there since Oct 10)
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=c245cb9e15055ed5dcf7eaf29232badb0059fdc1
On Mon, 24 Oct 2011, Michael Witten wrote:
> On Fri, Oct 7, 2011 at 19:20, Michael Witt
78 matches
Mail list logo