On Wed, Jan 25, 2012 at 08:16:26AM -0800, Keith Packard wrote:
> The DP configuration must match the pipe configuration, and until mode
> set we don't know what BPC will be used. Delay all decisions about BPC
> until mode set, computing the target BPC in both intel_dp_mode_fixup
> and either
On Wed, Jan 25, 2012 at 08:16:25AM -0800, Keith Packard wrote:
> It is never correct to use intel_crtc->bpp in intel_dp_link_required,
> so instead pass an explicit bpp in to this function. This patch
> only supports 18bpp and 24bpp modes, which means that 10bpc modes will
> be computed
On Wed, Jan 25, 2012 at 01:17:51PM -0800, Keith Packard wrote:
> On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes virtuousgeek.org> wrote:
>
> > Yeah, looks like I got this wrong when I added the pipe bpp field.
> > Wonder if there's a good way to catch this sort of bug with an assert
> > so we
On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote:
> Hi Sumit,
>
> On 12/26/2011 10:23 AM, Sumit Semwal wrote:
> >This is the first step in defining a dma buffer sharing mechanism.
> >
> >A new buffer object dma_buf is added, with operations and API to allow easy
> >sharing of
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #43 from Jonathan Nieder 2012-01-25
12:39:49 PST ---
bugzilla-daemon at freedesktop.org wrote:
> I have finally to surrender. If anyone thinks on anything we can try, you can
> contact directly to me or add the information here.
On Wed, 2012-01-25 at 09:39 +0100, Thomas Hellstrom wrote:
> On 01/25/2012 09:05 AM, Ben Skeggs wrote:
> > On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote:
> >> On 01/25/2012 06:34 AM, Ben Skeggs wrote:
> >>> From: Ben Skeggs
> >>>
> >>> Both changes in
On Fri, Jan 20, 2012 at 6:53 PM, Laurent Pinchart
wrote:
> Hi Summit,
>
> Sorry for the late review. I know that this code is now in mainline, but I
> still have a couple of comments. I'll send patches if you agree with them.
Hi Laurent,
Thanks for your review; apologies for being late in
On 01/25/2012 07:12 PM, Dave Airlie wrote:
> On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom
> wrote:
>> On 01/25/2012 04:37 PM, Jerome Glisse wrote:
>>> On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggswrote:
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
> On 01/25/2012
OK, revisiting this again, please see inline below,
On 01/10/2012 06:46 PM, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote:
>> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
>>> Hi!
>>>
>>> When TTM was originally written, it was assumed
Hi Linus,
bunch of regression fixes since TTM rework and radeon initialisation,
modesetting fixes for Alex to fix some black screens on kms start type
issues, and two radeon ACPI fixes that make some laptops no oops on
startup.
I think Intel have some -fixes coming soon which I'll send in a
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #42 from Jonathan Nieder 2012-01-25
10:57:27 PST ---
Jonathan Nieder wrote:
> One can get
> fairly recent versions of most packages from sid or experimental.
Though at the
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #41 from Camale?n 2012-01-25 10:56:22 PST
---
(In reply to comment #40)
> Mesa is libgl1-mesa-dri and libgl1-mesa-glx. The DDX driver is[1]
> xserver-xorg-video-radeon and libdrm-radeon1, I suppose. One can get
> fairly recent
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #40 from Jonathan Nieder 2012-01-25
10:41:38 PST ---
bugzilla-daemon at freedesktop.org wrote:
> Thanks! But... ... the use runs "wheezy" which I guess includes an updated
> version of the packages (btw, what are the packages
https://bugs.freedesktop.org/show_bug.cgi?id=33376
--- Comment #7 from Thomas Lindroth 2012-01-25
10:39:33 PST ---
I think this problem was fixed in a recent update. I've been experiencing it
for a long time but not any longer. The fix probably went in some time during
the past few months.
--
On Wed, 2012-01-25 at 08:24 +, Dave Airlie wrote:
> On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs wrote:
> > From: Ben Skeggs
> >
> > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
> > regressions in the nouveau driver.
> >
> > move_notify() was originally able to
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #39 from Camale?n 2012-01-25 10:35:48 PST
---
(In reply to comment #38)
> bugzilla-daemon at freedesktop.org wrote:
>
> > How could we test a new ddx (sorry to ask but, what's that? :-?) or an
> > udpated
> > mesa without breaking
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
> regressions in the nouveau driver.
>
> move_notify() was originally able to presume that bo->mem is the old node,
> and new_mem is the new node. The above
On 01/24/2012 03:47 PM, Daniel Vetter wrote:
> On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote:
>> If the master tries to authenticate a client using drm_authmagic and
>> that client has already closed its drm file descriptor,
>> either wilfully or because it was terminated, the
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
> On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote:
>> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
>>> On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings
and
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #38 from Jonathan Nieder 2012-01-25
10:17:22 PST ---
bugzilla-daemon at freedesktop.org wrote:
> How could we test a new ddx (sorry to ask but, what's that? :-?) or an udpated
> mesa without breaking many things?
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
> On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote:
>> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
>>> On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings
and
On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom
wrote:
> On 01/25/2012 04:37 PM, Jerome Glisse wrote:
>>
>> On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs ?wrote:
>>>
>>> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
>
> My
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #37 from Camale?n 2012-01-25 10:10:06 PST
---
(In reply to comment #36)
> It's a GPU lockup. Unfortunately, they tend to be really hard to track down.
> You might try a newer ddx or mesa.
We're open to test anything, whatever...
On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote:
> On 01/25/2012 06:34 AM, Ben Skeggs wrote:
> > From: Ben Skeggs
> >
> > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
> > regressions in the nouveau driver.
> >
> > move_notify() was originally able to presume
Hi Sumit,
On 12/26/2011 10:23 AM, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - creation of a
https://bugs.freedesktop.org/show_bug.cgi?id=45018
Alexandre Demers changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #36 from Alex Deucher 2012-01-25 09:54:47 PST
---
It's a GPU lockup. Unfortunately, they tend to be really hard to track down.
You might try a newer ddx or mesa.
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #35 from Jonathan Nieder 2012-01-25
09:37:29 PST ---
bugzilla-daemon at freedesktop.org wrote:
> Syslog with "drm.debug=6" + call trace
Summary follows. Log is from 25 January.
15:55 bootup
15:55 [after 22 seconds] drm driver
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #34 from Camale?n 2012-01-25 09:17:55 PST
---
Created attachment 56153
--> https://bugs.freedesktop.org/attachment.cgi?id=56153
Syslog with "drm.debug=6" + call trace
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #33 from Camale?n 2012-01-25 09:16:12 PST
---
(In reply to comment #32)
> (In reply to comment #31)
> > bugzilla-daemon at freedesktop.org wrote:
> >
> > > The user reported that system crashed after a while.
> >
> > Interesting
From: Ben Skeggs
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to presume that bo->mem is the old node,
and new_mem is the new node. The above commit moves the call to
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
>
> My main concern is that we blindly and unnecessarily set up GPU bindings and
> end up with unnecessary code in TTM, and furthermore that we communicate
> that bad practice to future driver writers.
> This "unnecessary code" is like 5 lines of cleanup
On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie wrote:
>
> bunch of regression fixes since TTM rework and radeon initialisation,
> modesetting fixes for Alex to fix some black screens on kms start type
> issues, and two radeon ACPI fixes that make some laptops no oops on
> startup.
Does that
signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/7ef774f2/attachment.pgp>
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/743e859b/attachment.pgp>
On Wed, Jan 25, 2012 at 1:21 PM, Thomas Hellstrom
wrote:
> On 01/25/2012 07:12 PM, Dave Airlie wrote:
>>
>> On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom
>> ?wrote:
>>>
>>> On 01/25/2012 04:37 PM, Jerome Glisse wrote:
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs
?wrote:
>
t seems to break the abstraction even more.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/69402a60/attachment.pgp>
nes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/15a3d7cb/attachment.pgp>
> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
> symbols can be used by the binary blobs, possibly with an open-sourced
> shim which provides the buffer-sharing interface to the binary blobs?
> Are there any reasons to not consider this approach?
The GPL requires all the
-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/4b85a236/attachment.pgp>
On Tue, Jan 24, 2012 at 7:12 PM, Martin Nyhus wrote:
> On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse
> wrote:
>> Can you please both test if attached patch fix it for you ?
>
> Thanks. It looks good too me, but it crashes a little later due to vma->node
> being invalid:
>
> Jan 25 00:54:21
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu:
> Em 25-01-2012 10:30, Alan Cox escreveu:
>>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
>>> symbols can be used by the binary blobs, possibly with an open-sourced
>>> shim which provides the buffer-sharing interface to
Em 25-01-2012 10:30, Alan Cox escreveu:
>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
>> symbols can be used by the binary blobs, possibly with an open-sourced
>> shim which provides the buffer-sharing interface to the binary blobs?
>> Are there any reasons to not consider
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter wrote:
> On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
>> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
>> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
>> > wrote:
>> > > EXPORT_SYMBOL_GPL is intended to be
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote:
> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
>> On 01/25/2012 10:41 AM, Ben Skeggs wrote:
>> >
>> > My main concern is that we blindly and unnecessarily set up GPU bindings
>> > and
>> > end up with unnecessary code in TTM, and
On 01/25/2012 09:05 AM, Ben Skeggs wrote:
> On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote:
>> On 01/25/2012 06:34 AM, Ben Skeggs wrote:
>>> From: Ben Skeggs
>>>
>>> Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
>>> regressions in the nouveau driver.
>>>
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=44919
Benjamin Franzke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
> regressions in the nouveau driver.
>
> move_notify() was originally able to presume that bo->mem is the old node,
> and new_mem is the new node. The above
On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
> regressions in the nouveau driver.
>
> move_notify() was originally able to presume that bo->mem is the old node,
> and new_mem is the new node. ?The
The DP configuration must match the pipe configuration, and until mode
set we don't know what BPC will be used. Delay all decisions about BPC
until mode set, computing the target BPC in both intel_dp_mode_fixup
and either i9xx_crtc_mode_set or ironlake_crtc_mode_set. It might be
slightly better to
It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be
Here's a couple of patches that fix some bpc (bits per component)
computation issues with DisplayPort. The problem was that the
DisplayPort code tried to figure out the 'current' bpc by looking at
the bpp stored in an associated crtc, but that was never right (as
described in the message for the
On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark wrote:
> On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
> wrote:
>> On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark wrote:
>>> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
>>> wrote:
On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark
wrote:
On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark wrote:
> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
> wrote:
>> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark wrote:
>>> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>>> wrote:
On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark wrote:
> On
Sorry Jerome, I didn't have time to properly finish the patch and
update the CS checker properly.
Also evergreen_cs_track_check has been a no-op for a long time and
this patch doesn't make it any more exploitable.
Marek
On Wed, Jan 25, 2012 at 12:43 AM, Jerome Glisse wrote:
> On Tue, Jan 24,
On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse
wrote:
> Can you please both test if attached patch fix it for you ?
Thanks. It looks good too me, but it crashes a little later due to vma->node
being invalid:
Jan 25 00:54:21 callisto kernel: [ 119.038357] [drm] nouveau_vm_unmap vma
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
From: Ben Skeggsbske...@redhat.com
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to presume that bo-mem is the old node,
and new_mem is the new node. The
On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote:
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
From: Ben Skeggsbske...@redhat.com
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to
On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs skeg...@gmail.com wrote:
From: Ben Skeggs bske...@redhat.com
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to presume that bo-mem is the old node,
and
On Wed, 2012-01-25 at 08:24 +, Dave Airlie wrote:
On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs skeg...@gmail.com wrote:
From: Ben Skeggs bske...@redhat.com
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was
On 01/25/2012 09:05 AM, Ben Skeggs wrote:
On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote:
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
From: Ben Skeggsbske...@redhat.com
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
https://bugs.freedesktop.org/show_bug.cgi?id=44919
Benjamin Franzke benjaminfran...@googlemail.com changed:
What|Removed |Added
Status|NEW
On Wed, 2012-01-25 at 09:39 +0100, Thomas Hellstrom wrote:
On 01/25/2012 09:05 AM, Ben Skeggs wrote:
On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote:
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
From: Ben Skeggsbske...@redhat.com
Both changes in
On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse j.gli...@gmail.com
wrote:
Can you please both test if attached patch fix it for you ?
Thanks. It looks good too me, but it crashes a little later due to vma-node
being invalid:
Jan 25 00:54:21 callisto kernel: [ 119.038357] [drm]
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary blobs?
Are there any reasons to not consider this approach?
The GPL requires all the code of
On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
On Fri, Jan 20, 2012 at 6:53 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Summit,
Sorry for the late review. I know that this code is now in mainline, but I
still have a couple of comments. I'll send patches if you agree with them.
Hi Laurent,
Thanks for your review;
Em 25-01-2012 10:30, Alan Cox escreveu:
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary blobs?
Are there any reasons to not consider this
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu:
Em 25-01-2012 10:30, Alan Cox escreveu:
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings and
end up with unnecessary code in TTM, and furthermore that we communicate
that bad practice to future driver writers.
This unnecessary code is like 5 lines of cleanup if
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings and
end up with unnecessary code in TTM, and furthermore that we communicate
that bad practice to future driver
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings
and
end up with unnecessary code in TTM,
It is never correct to use intel_crtc-bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be
The DP configuration must match the pipe configuration, and until mode
set we don't know what BPC will be used. Delay all decisions about BPC
until mode set, computing the target BPC in both intel_dp_mode_fixup
and either i9xx_crtc_mode_set or ironlake_crtc_mode_set. It might be
slightly better to
Here's a couple of patches that fix some bpc (bits per component)
computation issues with DisplayPort. The problem was that the
DisplayPort code tried to figure out the 'current' bpc by looking at
the bpp stored in an associated crtc, but that was never right (as
described in the message for the
On Tue, Jan 24, 2012 at 7:12 PM, Martin Nyhus martin.ny...@gmx.com wrote:
On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse j.gli...@gmail.com
wrote:
Can you please both test if attached patch fix it for you ?
Thanks. It looks good too me, but it crashes a little later due to vma-node
being
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.com wrote:
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings and
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #33 from Camaleón noela...@gmail.com 2012-01-25 09:16:12 PST ---
(In reply to comment #32)
(In reply to comment #31)
bugzilla-dae...@freedesktop.org wrote:
The user reported that system crashed after a while.
Interesting
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #34 from Camaleón noela...@gmail.com 2012-01-25 09:17:55 PST ---
Created attachment 56153
-- https://bugs.freedesktop.org/attachment.cgi?id=56153
Syslog with drm.debug=6 + call trace
--
Configure bugmail:
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.com wrote:
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
On 01/25/2012 10:41 AM, Ben Skeggs wrote:
My main concern is that we blindly and unnecessarily set up GPU bindings and
On 01/24/2012 03:47 PM, Daniel Vetter wrote:
On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote:
If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to
On 01/25/2012 06:34 AM, Ben Skeggs wrote:
From: Ben Skeggsbske...@redhat.com
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to presume that bo-mem is the old node,
and new_mem is the new node. The
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #35 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 09:37:29
PST ---
bugzilla-dae...@freedesktop.org wrote:
Syslog with drm.debug=6 + call trace
Summary follows. Log is from 25 January.
15:55 bootup
15:55 [after 22 seconds]
Hi Sumit,
On 12/26/2011 10:23 AM, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #36 from Alex Deucher ag...@yahoo.com 2012-01-25 09:54:47 PST ---
It's a GPU lockup. Unfortunately, they tend to be really hard to track down.
You might try a newer ddx or mesa.
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=45018
Alexandre Demers alexandre.f.dem...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #37 from Camaleón noela...@gmail.com 2012-01-25 10:10:06 PST ---
(In reply to comment #36)
It's a GPU lockup. Unfortunately, they tend to be really hard to track down.
You might try a newer ddx or mesa.
We're open to test
On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom tho...@shipmail.org wrote:
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.com wrote:
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote:
On 01/25/2012 10:41 AM, Ben Skeggs
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #38 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 10:17:22
PST ---
bugzilla-dae...@freedesktop.org wrote:
How could we test a new ddx (sorry to ask but, what's that? :-?) or an udpated
mesa without breaking many things?
OK, revisiting this again, please see inline below,
On 01/10/2012 06:46 PM, Jerome Glisse wrote:
On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote:
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
Hi!
When TTM was originally written, it was assumed that GPU
On 01/25/2012 07:12 PM, Dave Airlie wrote:
On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstromtho...@shipmail.org wrote:
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.comwrote:
On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #39 from Camaleón noela...@gmail.com 2012-01-25 10:35:48 PST ---
(In reply to comment #38)
bugzilla-dae...@freedesktop.org wrote:
How could we test a new ddx (sorry to ask but, what's that? :-?) or an
udpated
mesa without
https://bugs.freedesktop.org/show_bug.cgi?id=33376
--- Comment #7 from Thomas Lindroth thomas.lindr...@gmail.com 2012-01-25
10:39:33 PST ---
I think this problem was fixed in a recent update. I've been experiencing it
for a long time but not any longer. The fix probably went in some time during
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #40 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 10:41:38
PST ---
bugzilla-dae...@freedesktop.org wrote:
Thanks! But... ... the use runs wheezy which I guess includes an updated
version of the packages (btw, what are the
On Wed, Jan 25, 2012 at 1:21 PM, Thomas Hellstrom tho...@shipmail.org wrote:
On 01/25/2012 07:12 PM, Dave Airlie wrote:
On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstromtho...@shipmail.org
wrote:
On 01/25/2012 04:37 PM, Jerome Glisse wrote:
On Wed, Jan 25, 2012 at 10:21 AM, Ben
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #41 from Camaleón noela...@gmail.com 2012-01-25 10:56:22 PST ---
(In reply to comment #40)
Mesa is libgl1-mesa-dri and libgl1-mesa-glx. The DDX driver is[1]
xserver-xorg-video-radeon and libdrm-radeon1, I suppose. One can get
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #42 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 10:57:27
PST ---
Jonathan Nieder wrote:
One can get
fairly recent versions of most packages from sid or experimental.
Hi Linus,
bunch of regression fixes since TTM rework and radeon initialisation,
modesetting fixes for Alex to fix some black screens on kms start type
issues, and two radeon ACPI fixes that make some laptops no oops on
startup.
I think Intel have some -fixes coming soon which I'll send in a
On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote:
Hi Sumit,
On 12/26/2011 10:23 AM, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer
A bunch of patches which fix IVB-specific troubles:
* A selection of code which was labeled for SNB, but needs to be run on
IVB as well.
* A replacement for the quick-hack IVB lost-IRQ issue. This appears to
help on SNB as well, but for now it's only enabled on IVB in case we
1 - 100 of 114 matches
Mail list logo