https://bugs.freedesktop.org/show_bug.cgi?id=29556
--- Comment #3 from Marc 2010-08-15 04:45:10 PDT ---
with the above patch the problem got not really cured here. It just happens
more seldom. So there is still something wrong with the blit code in d-r-t.
--
Configure bugmail: https://bugs.free
Always zero-init a structure on the stack which is returned by a
function. Otherwise you may leak random stack data from previous
function calls.
This fixes the following warning I was seeing:
CC [M] drivers/gpu/drm/radeon/radeon_atombios.o
drivers/gpu/drm/radeon/radeon_atombios.c: In function
https://bugs.freedesktop.org/show_bug.cgi?id=29556
--- Comment #4 from Stefano Carignano 2010-08-15 07:02:15
PDT ---
(In reply to comment #3)
> with the above patch the problem got not really cured here. It just happens
> more seldom. So there is still something wrong with the blit code in d-r-t
https://bugs.freedesktop.org/show_bug.cgi?id=28771
--- Comment #21 from Hans Nieser 2010-08-15 09:12:43 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > To use vblank_mode for dri2 in .drirc you need a seperate dri2 driver with
> > vblank_mode specified, driconf doesn't handle it
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #10 from Da Fox 2010-08-15 14:21:55 PDT
---
I tried with kernel 2.6.35.2 over the weekend, and this issue is still present.
However there is a slight urge to get this fixed, because the rest of the
system will start to depend on m
On Sun, Aug 15, 2010 at 07:32:15PM -0700, Linus Torvalds wrote:
> I started wondering why 'top' was showing an otherwise idle system as
> having a load average of 0.5+, and worker threads constantly using the
> CPU.
>
> So I did a system-wide profile, and got the attached output (look at
> it in a
On Sun, 2010-08-15 at 19:32 -0700, Linus Torvalds wrote:
> I started wondering why 'top' was showing an otherwise idle system as
> having a load average of 0.5+, and worker threads constantly using the
> CPU.
>
> So I did a system-wide profile, and got the attached output (look at
> it in a really
On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie wrote:
>
> At least we should replace mdelay with msleep in those functions.
How precise does the timing have to be? I think i2c is self-clocking,
so it's ok to see big skews? Becuase msleep() can be off by quite a
bit (mdelay can too, but it's _way_ m
On Sun, Aug 15, 2010 at 9:06 PM, Andy Lutomirski wrote:
>
> You might be hitting the infamous hotplug storm [1]. The symptoms vary by
> kernel version.
Hmm. I don't think it's a storm. The drm.debug=4 thing shows things
just every 10 seconds. That seems pretty controlled.
Of course, it seems to
On Sun, 2010-08-15 at 21:01 -0700, Linus Torvalds wrote:
> On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie wrote:
> >
> > At least we should replace mdelay with msleep in those functions.
>
> How precise does the timing have to be? I think i2c is self-clocking,
> so it's ok to see big skews? Becuase
https://bugs.freedesktop.org/show_bug.cgi?id=29556
--- Comment #3 from Marc 2010-08-15 04:45:10 PDT ---
with the above patch the problem got not really cured here. It just happens
more seldom. So there is still something wrong with the blit code in d-r-t.
--
Configure bugmail: https://bugs.free
Always zero-init a structure on the stack which is returned by a
function. Otherwise you may leak random stack data from previous
function calls.
This fixes the following warning I was seeing:
CC [M] drivers/gpu/drm/radeon/radeon_atombios.o
drivers/gpu/drm/radeon/radeon_atombios.c: In function
https://bugs.freedesktop.org/show_bug.cgi?id=29556
--- Comment #4 from Stefano Carignano 2010-08-15
07:02:15 PDT ---
(In reply to comment #3)
> with the above patch the problem got not really cured here. It just happens
> more seldom. So there is still something wrong with the blit code in d-r-t
https://bugs.freedesktop.org/show_bug.cgi?id=28771
--- Comment #21 from Hans Nieser 2010-08-15 09:12:43 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > To use vblank_mode for dri2 in .drirc you need a seperate dri2 driver with
> > vblank_mode specified, driconf doesn't handle it
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #10 from Da Fox 2010-08-15 14:21:55
PDT ---
I tried with kernel 2.6.35.2 over the weekend, and this issue is still present.
However there is a slight urge to get this fixed, because the rest of the
system will start to depend on m
I started wondering why 'top' was showing an otherwise idle system as
having a load average of 0.5+, and worker threads constantly using the
CPU.
So I did a system-wide profile, and got the attached output (look at
it in a really wide terminal).
There seems to be something _seriously_ wrong with
On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie wrote:
>
> At least we should replace mdelay with msleep in those functions.
How precise does the timing have to be? I think i2c is self-clocking,
so it's ok to see big skews? Becuase msleep() can be off by quite a
bit (mdelay can too, but it's _way_ m
On Sun, Aug 15, 2010 at 9:06 PM, Andy Lutomirski wrote:
>
> You might be hitting the infamous hotplug storm [1]. ?The symptoms vary by
> kernel version.
Hmm. I don't think it's a storm. The drm.debug=4 thing shows things
just every 10 seconds. That seems pretty controlled.
Of course, it seems to
When I ran "make headers_check" on upstream I got following
set of warnings for the drm headers:
usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without #include
usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without #include
usr/include/drm/mga_drm.h:260: found __[
19 matches
Mail list logo