https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #44 from Camaleón 2012-01-25 23:41:02 PST ---
(In reply to comment #42)
> Ok, just to fill in the blanks: was this a regression? Was there a
> kernel or X or GNOME upgrade before which the system worked fine and
> after which it bro
https://bugs.freedesktop.org/show_bug.cgi?id=33376
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 i9xx_c
> >
> > 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 include for the nvidia (?) suspend/resume issu
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 incorrectly
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 d
On Wed, Jan 25, 2012 at 6:31 PM, Linus Torvalds
wrote:
> 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
On Thu, Jan 26, 2012 at 1:37 AM, Daniel Vetter wrote:
> 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.
>> >
>> [snip]
>>
>> >+struct sg_table
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 th
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.
Ok
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 dc97b3409a790d2a21aac6e5cdb99558b59
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 replyin
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 10
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 th
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 s
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 m
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 ver
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 we
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 presum
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 commi
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?
http://pkg-xorg.al
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... b
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 that
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 buf
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/userprefs.cgi?ta
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 l
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/userprefs.c
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
move_notify() to after move() has
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, 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 includ
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 includ
On Wed, 25 Jan 2012 23:11:00 +0100, Daniel Vetter wrote:
> I'm a bit unhappy how generic code in intel_display.c calls function out
> of intel_dp.c. And choose_pipe_bpp_dither already has special cases for
> quite a few other encoders ... Could we add an ->adjust_bpc function to
> intel_encoder t
le
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/7ef774f2/attachment.pgp>
On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter wrote:
> I think we could compute this in crtc->mode_fixup (crtc->prepare doesn't
> have the mode and adjusted_mode arguments). We could then store the
> computed bpc and dithering in one of the private fields. We'd still have
> to loop over all e
tel.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/743e859b/attachment.pgp>
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 i9xx_c
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 incorrectly
On Wed, Jan 25, 2012 at 01:17:51PM -0800, Keith Packard wrote:
> On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes
> 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 don't get the or
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:
>
>
On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes
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 don't get the order mixed up again...
Ideally, we'd figure out a way to compute this only
t;clock values after it sets the
bpp, but that 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>
On Wed, 25 Jan 2012 08:16:25 -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 incorrectly. Fix
code?
--
Jesse Barnes, 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>
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #43 from Jonathan Nieder 2012-01-25 12:39:49
PST ---
bugzilla-dae...@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.
Ok, j
> 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
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
discover
application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120125/4b85a236/attachment.pgp>
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 th
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 cal
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 th
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 t
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 s
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 use
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 m
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 vers
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:
>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #40 from Jonathan Nieder 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 packages we wo
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, 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 f
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-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
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 10:41 AM, Ben Skegg
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 apert
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #38 from Jonathan Nieder 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?
http://pkg-xorg.aliot
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 m
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... bu
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/userprefs.cgi?tab
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 object
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.
>>>
>>> move
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #35 from Jonathan Nieder 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] drm driver load
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 commit moves th
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 dr
https://bugs.freedesktop.org/show_bug.cgi?id=44919
Benjamin Franzke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
end up with unnece
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/userprefs.cg
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-dae...@freedesktop.org wrote:
> >
> > > The user reported that system crashed after a while.
> >
> > Interesting --- so
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
end up with unnece
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 cal
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 commi
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
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 fi
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 addre
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 addre
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 fi
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 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 f
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 dr
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 someth
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 th
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 t
1 - 100 of 114 matches
Mail list logo
