Hi,
while watching flash video in a browser I got:
irq 42: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Tainted: GW 2.6.39-rc3-mm1_64+ #1423
Call Trace:
[] __report_bad_irq+0x31/0xc0
[] note_interrupt+0x194/0x1d0
[]
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
> On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
> wrote:
> > Looking for comments on this. ?Obviously if we're going to add a new type
> > of KMS object, we'd better get the ioctl more or less right to begin with,
> > which means having
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes
wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200
> Daniel Vetter wrote:
>
>> Hi Jesse,
>>
>> I like it. It's a bit of a chicken-egg api design problem, but if a
>> proof-of-concept
>> implementation exists for an embedded chip plus something to check
On Apr 28, 2011, at 9:47 AM, Christopher James Halse Rogers wrote:
> On Wed, 2011-04-27 at 17:50 +0200, Mario Kleiner wrote:
>> On Apr 27, 2011, at 10:58 AM, dri-devel-request at lists.freedesktop.org
>> wrote:
>>> Message: 5
>>> Date: Wed, 27 Apr 2011 10:38:14 +0200
>>> From: Michel D?nzer
>>>
l see what I can come up with, but I don't think I'm sufficiently
familiar with the kms code to quickly come up with a nice API.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/5e64d8fc/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #5 from Jason Cassell 2011-04-28
16:38:02 PDT ---
Created an attachment (id=46146)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46146)
/proc/interrupts
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #4 from Jason Cassell 2011-04-28
16:36:31 PDT ---
(In reply to comment #3)
> Does that involve wobbly windows or any other effects?
It's the same problem with and without wobbly windows.
One thing I noticed with wobbly windows is
On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> We're often using a shared interrupt line for nouveau, so we have
> to be prepared that it could be called at any point in time. If
> we've suspended the device via vga switcheroo and get a stray
> interrupt on the line from another
ailable
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/1bacbf2d/attachment.pgp>
protocol. Seems like a reasonable approach.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/a42fc0d8/attachment-0001.pgp>
On Thu, 28 Apr 2011 14:33:58 -0700
Eric Anholt wrote:
> On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes virtuousgeek.org> wrote:
> > The defintion of the swap complete event was wrong; XEvents are only 32
> > bytes long, and with padding the swap event was longer. So use some
> > creative
msc_hi B32;
> CARD32 msc_lo B32;
> CARD32 sbc_hi B32;
> -CARD32 sbc_lo B32;
> } xGLXBufferSwapComplete;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/224366ee/attachment.pgp>
On Thu, 28 Apr 2011 13:46:30 -0700
Jesse Barnes wrote:
> On Thu, 28 Apr 2011 18:09:58 +1000
> Christopher James Halse Rogers
> wrote:
> > Ok. This appears to be surprisingly difficult. Particularly, the
> > vblank code indexes crtcs based on the driver-private numbering, and
> > there doesn't
On Thu, 28 Apr 2011 18:09:58 +1000
Christopher James Halse Rogers
wrote:
> Ok. This appears to be surprisingly difficult. Particularly, the
> vblank code indexes crtcs based on the driver-private numbering, and
> there doesn't appear to be a generic interface to grab this number;
> Intel uses
On Wed, 27 Apr 2011 10:32:36 +0200
Michel D?nzer wrote:
> On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at canonical.com
> wrote:
> > From: Christopher James Halse Rogers > canonical.com>
> >
> > This is the least-bad behaviour. It means that we signal the
> > vblank event
On Wed, 27 Apr 2011 16:10:59 +1000
christopher.halse.rogers at canonical.com wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> Signed-off-by: Christopher James Halse Rogers canonical.com>
> ---
> drivers/gpu/drm/drm_irq.c | 39 ---
> 1
On Wed, 27 Apr 2011 16:10:57 +1000
christopher.halse.rogers at canonical.com wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> This is the least-bad behaviour. It means that we signal the
> vblank event before it actually happens, but since we're disabling
> vblanks there's no
Use the new swap event structure packing and send it to the client if
possible. This means tracking client version information when clients
connect. If they don't support the new packing, they'll get the old
bits and fill junk into their sbc values when they receive the event.
If they do support
The swap complete event wasn't being handled fully; because XEvents are
only 32 bytes long, we were getting junk for the sbc_lo value. If the
server supports it, unpack the new structure, otherwise just return 0
for the sbc value instead of garbage.
---
configure.ac|4 ++--
XEvents are limited to 32 bytes, so use some creative stuffing to fit
all the bits we'd like to supply.
---
configure.ac |2 +-
dri2proto.h |9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5b78d6b..9505f56 100644
---
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
proto version bump.
---
configure.ac |2 +-
glxproto.h | 13 +
2
I obviously failed to count the swap event structure size after adding
and removing fields a few times, and didn't even account for padding. The
end result is that clients today won't receive the sbc_lo field at all,
and so will likely stuff junk into that field on the client side (or
zero at
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
wrote:
> Looking for comments on this. ?Obviously if we're going to add a new type
> of KMS object, we'd better get the ioctl more or less right to begin with,
> which means having all the attributes we'd like to track, plus some
> padding, available
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox wrote:
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. ?The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma
2011/4/25 St?phane Marchesin :
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes
> wrote:
>> On Mon, 25 Apr 2011 16:16:18 -0700
>> Keith Packard wrote:
>>
>>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes >> virtuousgeek.org> wrote:
>>>
>>> > Overlays are a bit like half-CRTCs. ?They have a
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes
wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter wrote:
>> Imo the real problem with formats is stride restrictions and other hw
>> restrictions (tiling, ...).
>> ARM/v4l people seem to want that to be in the kernel so that they can
>>
ing patch fix tarball creation again (removed files and one
missing Makefile)
-- next part --
A non-text attachment was scrubbed...
Name: fix-tarball-again.diff
Type: text/x-patch
Size: 808 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/e9cc31d2/attachment.bin>
priate there.
But at this point the vblank interrupts have been disabled, or at least
the driver's disable function has been called. Will that not mean that
any pending pageflips will wait indefinitely for a vblank interrupt
that's not going to come - ie: exactly the state we're warning against?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/31165f16/attachment.pgp>
On Thu, 2011-04-28 at 15:54 +1000, Dave Airlie wrote:
> On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> > We're often using a shared interrupt line for nouveau, so we have
> > to be prepared that it could be called at any point in time. If
> > we've suspended the device via vga
Nothing major, everyone must be on Easter holidays, the i915 one is
actually a fix for dual-gpu laptops where i915 caused radeon to do
something bad, the Kconfig one is because I see distros don't enable this
and its really needed for dual-gpu functionality to work at all.
Otherwise, just a
We're often using a shared interrupt line for nouveau, so we have
to be prepared that it could be called at any point in time. If
we've suspended the device via vga switcheroo and get a stray
interrupt on the line from another device, we'll read back -1 from
the device and head down all sorts of
On 19 April 2011 16:35, Brian bri...@vmware.com wrote:
Pushed, thanks.
Can you know commit this one that fixes missing files in the generated
tarball
so that one can build mesa out of the tarball?
Thx
I'll commit it soon. Thanks.
Hi
The following patch fix tarball creation again (removed
On Wed, Apr 27, 2011 at 05:49:50PM +1000, Dave Airlie wrote:
On Wed, Apr 27, 2011 at 3:34 PM, Aurelien Jarno aurel...@aurel32.net wrote:
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
So you wrote a patch that breaks it everwhere?
It seems I
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
On Wed, 2011-04-27 at 11:08 +0200, Michel Dänzer wrote:
On Mit, 2011-04-27 at 18:58 +1000, Christopher James Halse Rogers
wrote:
On Wed, 2011-04-27 at 10:32 +0200, Michel Dänzer wrote:
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
wrote:
From:
On Thu, 2011-04-28 at 15:54 +1000, Dave Airlie wrote:
On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
We're often using a shared interrupt line for nouveau, so we have
to be prepared that it could be called at any point in time. If
we've suspended the device via vga switcheroo
2011/4/25 Stéphane Marchesin stephane.marche...@gmail.com:
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
A lot of older hardware had one overlay that could be sourced to any
crtc, just not simultaneously. The tricky part is the formats and
capabilities: alpha blending, color/chromakey, gamma correction, etc.
Even the
On Apr 28, 2011, at 9:47 AM, Christopher James Halse Rogers wrote:
On Wed, 2011-04-27 at 17:50 +0200, Mario Kleiner wrote:
On Apr 27, 2011, at 10:58 AM, dri-devel-requ...@lists.freedesktop.org
wrote:
Message: 5
Date: Wed, 27 Apr 2011 10:38:14 +0200
From: Michel D?nzer mic...@daenzer.net
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
Looking for comments on this. Obviously if we're going to add a new type
of KMS object, we'd better get the ioctl more or less right to begin with,
which means having all the attributes we'd like to track, plus some
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Looking for comments on this. Obviously if we're going to add a new type
of KMS object, we'd better get the ioctl more or less right to begin with,
Hi,
while watching flash video in a browser I got:
irq 42: nobody cared (try booting with the irqpoll option)
Pid: 0, comm: swapper Tainted: GW 2.6.39-rc3-mm1_64+ #1423
Call Trace:
IRQ [810bd671] __report_bad_irq+0x31/0xc0
[810bd934] note_interrupt+0x194/0x1d0
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
proto version bump.
---
configure.ac |2 +-
glxproto.h | 13 +
2
The swap complete event wasn't being handled fully; because XEvents are
only 32 bytes long, we were getting junk for the sbc_lo value. If the
server supports it, unpack the new structure, otherwise just return 0
for the sbc value instead of garbage.
---
configure.ac|4 ++--
XEvents are limited to 32 bytes, so use some creative stuffing to fit
all the bits we'd like to supply.
---
configure.ac |2 +-
dri2proto.h |9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5b78d6b..9505f56 100644
---
I obviously failed to count the swap event structure size after adding
and removing fields a few times, and didn't even account for padding. The
end result is that clients today won't receive the sbc_lo field at all,
and so will likely stuff junk into that field on the client side (or
zero at
Use the new swap event structure packing and send it to the client if
possible. This means tracking client version information when clients
connect. If they don't support the new packing, they'll get the old
bits and fill junk into their sbc values when they receive the event.
If they do support
On Wed, 27 Apr 2011 16:10:57 +1000
christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
This is the least-bad behaviour. It means that we signal the
vblank event before it actually happens, but since we're disabling
On Wed, 27 Apr 2011 16:10:59 +1000
christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
drivers/gpu/drm/drm_irq.c | 39
On Wed, 27 Apr 2011 10:32:36 +0200
Michel Dänzer mic...@daenzer.net wrote:
On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
wrote:
From: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
This is the least-bad behaviour. It means that we
On Thu, 28 Apr 2011 18:09:58 +1000
Christopher James Halse Rogers christopher.halse.rog...@canonical.com
wrote:
Ok. This appears to be surprisingly difficult. Particularly, the
vblank code indexes crtcs based on the driver-private numbering, and
there doesn't appear to be a generic interface
On Thu, 28 Apr 2011 13:46:30 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 28 Apr 2011 18:09:58 +1000
Christopher James Halse Rogers christopher.halse.rog...@canonical.com
wrote:
Ok. This appears to be surprisingly difficult. Particularly, the
vblank code indexes crtcs based
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
On Thu, 28 Apr 2011 13:27:22 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Use the new swap event structure packing and send it to the client if
possible. This means tracking client version information when clients
connect. If they don't support the new packing, they'll get the old
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #4 from Jason Cassell bluesloth...@gmail.com 2011-04-28 16:36:31
PDT ---
(In reply to comment #3)
Does that involve wobbly windows or any other effects?
It's the same problem with and without wobbly windows.
One thing I noticed
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #5 from Jason Cassell bluesloth...@gmail.com 2011-04-28 16:38:02
PDT ---
Created an attachment (id=46146)
-- (https://bugs.freedesktop.org/attachment.cgi?id=46146)
/proc/interrupts
--
Configure bugmail:
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
v2: Also pull out the drm_vblank_put call.
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
drivers/gpu/drm/drm_irq.c | 44 ++--
1 files
60 matches
Mail list logo
