This error is reported by cppcheck:
drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over
|| always evaluates to true. Did you intend to use && instead?
It looks like cppcheck is correct, so fix this. No test was run.
Cc: David Airlie
Cc: Alex Deucher
Cc: dri-devel at l
On Friday, January 28, 2011, Robert P. J. Day wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" > crashcourse.ca> wrote:
> > > sadly, no change -- still black screen. again, rebooted
> > > successfully under commit 8a327f23. j
On Fri, Jan 28, 2011 at 5:35 PM, Stefan Weil wrote:
> This error is reported by cppcheck:
> drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over
> || always evaluates to true. Did you intend to use && instead?
Yes, should be &&.
Thanks,
Reviewed-by: Alex Deucher
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=22472
Radu Andries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" wrote:
> all right. and since we're beyond git bisection, can you post a
> list of say 2 or 3 tests you want me to try in order? as you're the
> expert here, it would make more sense for you to try to optimize the
> search pattern he
On Fri, 28 Jan 2011 10:54:20 -0500 (EST), "Robert P. J. Day" wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" > crashcourse.ca> wrote:
> > > victory is mine! ok, that premature return seems to have solved it,
> > > i'm up and
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please
> try that and see if it makes a difference.
as a quick followup, i applied the following simple patch:
$ git
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" wrote:
> victory is mine! ok, that premature return seems to have solved it,
> i'm up and running under this new kernel. are we getting close?
Not even close. We just disabled functionality that was working in 2.6.37;
the interactio
https://bugs.freedesktop.org/show_bug.cgi?id=33674
--- Comment #1 from Alex Deucher 2011-01-28 15:34:53 PST ---
did you update anything other than the kernel (mesa, ddx, etc.)? If it's just
the kernel can you bisect?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
https://bugs.freedesktop.org/show_bug.cgi?id=33674
--- Comment #1 from Alex Deucher 2011-01-28 15:34:53 PST
---
did you update anything other than the kernel (mesa, ddx, etc.)? If it's just
the kernel can you bisect?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=33674
Summary: KMS, kernel, Second Monitor becomes complete blur when
loading fullscreen GL
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=33674
Summary: KMS, kernel, Second Monitor becomes complete blur when
loading fullscreen GL
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> On Friday, January 28, 2011, Robert P. J. Day wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" > > crashcourse.ca> wrote:
> > > > sadly, no change -- still black screen. ag
On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day" wrote:
> > That would be easy to test by returning early in intel_opregion_setup():
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_
> > index 9efccb9..8c93201 100644
> > --- a/drivers/gpu/drm/
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" wrote:
> sadly, no change -- still black screen. again, rebooted
> successfully under commit 8a327f23. just to be clear, here's "git
> diff":
>
> $ git diff
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 71
On Fri, Jan 28, 2011 at 5:35 PM, Stefan Weil wrote:
> This error is reported by cppcheck:
> drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over
> || always evaluates to true. Did you intend to use && instead?
Yes, should be &&.
Thanks,
Reviewed-by: Alex Deucher
>
>
This error is reported by cppcheck:
drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over
|| always evaluates to true. Did you intend to use && instead?
It looks like cppcheck is correct, so fix this. No test was run.
Cc: David Airlie
Cc: Alex Deucher
Cc: dri-devel@list
On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" wrote:
> > fix your boot issue or do we need to go back to using uncached:
> >
> > + return ioremap(phys, size);
>
> is that the next change you want me to try?
Yes. (Replacing the current return ioremap_*(phys, size).)
-Chris
Signed-off-by: Matthew Bullock
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index af61fc2..e4695db 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" wrote:
> so the culprit appears to be:
>
> b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> commit b705120e4198315f4ae043de06c62f65e0851fd3
> Author: Michael Karcher
> Date: Sun Jan 23 18:17:17 2011 +
>
> d
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > all right. and since we're beyond git bisection, can you post a
> > list of say 2 or 3 tests you want me to try in order? as you're the
> > expert here, it would
https://bugs.freedesktop.org/show_bug.cgi?id=33139
--- Comment #8 from Alex Deucher 2011-01-28 13:10:17 PST ---
(In reply to comment #7)
> May I ask how you can work such magic from such a distance? Do you have
> similar hardware with which you can reproduce the bug, and then just make the
> bug
https://bugs.freedesktop.org/show_bug.cgi?id=33139
--- Comment #8 from Alex Deucher 2011-01-28 13:10:17 PST
---
(In reply to comment #7)
> May I ask how you can work such magic from such a distance? Do you have
> similar hardware with which you can reproduce the bug, and then just make the
> bu
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please
> try that and see if it makes a difference.
as a quick followup, i applied the following simple patch:
$ git
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> On Friday, January 28, 2011, Robert P. J. Day wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
> > > wrote:
> > > > sadly, no change -- still black screen. again, rebooted
On Friday, January 28, 2011, Robert P. J. Day wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
> > wrote:
> > > sadly, no change -- still black screen. again, rebooted
> > > successfully under commit 8a327f23. just to be cle
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > victory is mine! ok, that premature return seems to have solved it,
> > i'm up and running under this new kernel. are we getting close?
>
> Not even close. We jus
On Fri, 28 Jan 2011, Chris Wilson wrote:
> We're starting to get into ACPI backlight breakage territory... We
> have identified that the regression was much earlier, just masked by
> other breakage.
as additional info, i went through this for a while during the
2.6.37-rc* progression. it came,
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #19 from Marek Olšák 2011-01-28 10:56:20 PST ---
I think I know the reason why it's slow with the rename_regs pass.
The statistics of the most complex shader are:
FRAGMENT PROGRAM ~~~
~ 108 Instructions
~ 71 Vector Ins
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #19 from Marek Ol??k 2011-01-28 10:56:20 PST
---
I think I know the reason why it's slow with the rename_regs pass.
The statistics of the most complex shader are:
FRAGMENT PROGRAM ~~~
~ 108 Instructions
~ 71 Vector In
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > victory is mine! ok, that premature return seems to have solved it,
> > i'm up and running under this new kernel. are we getting close?
>
> Not even close. We jus
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day"
> wrote:
> > all right. and since we're beyond git bisection, can you post a
> > list of say 2 or 3 tests you want me to try in order? as you're the
> > expert here, it would make more sen
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > sadly, no change -- still black screen. again, rebooted
> > successfully under commit 8a327f23. just to be clear, here's "git
> > diff":
> >
> > $ git diff
> > di
On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
> >> TTM_PAGE_FLAG_DMA32 (l
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > > fix your boot issue or do we need to go back to using uncached:
> > >
> > > + return ioremap(phys, size);
> >
> > is that the next change you want me to try
Signed-off-by: Matthew Bullock
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index af61fc2..e4695db 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
>> If the TTM layer has used the DMA API to setup pages that are
>> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
>> array for pages that
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author:
On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > Well, we have two endpoints, so let git attack:
> >
> > $ git bisect start
> > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> > $ git bisect bad abb72c828878a2c69b2cf
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author:
https://bugs.freedesktop.org/show_bug.cgi?id=33139
Dave Witbrodt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=33139
Dave Witbrodt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" wrote:
>
> one more observation which should nail things down:
>
> On Thu, 27 Jan 2011, Robert P. J. Day wrote:
>
> > ok, i'm getting different results from this morning, not sure why,
> > but i'm fairly confident i've isolated it
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > Well, we have two endpoints, so let git attack:
> > >
> > > $ git bisect start
> > > $ git bisect good 58bbf018a70c
On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day"
wrote:
> all right. and since we're beyond git bisection, can you post a
> list of say 2 or 3 tests you want me to try in order? as you're the
> expert here, it would make more sense for you to try to optimize the
> search pattern h
On Fri, 28 Jan 2011, Chris Wilson wrote:
> We're starting to get into ACPI backlight breakage territory... We
> have identified that the regression was much earlier, just masked by
> other breakage.
as additional info, i went through this for a while during the
2.6.37-rc* progression. it came,
On Fri, 28 Jan 2011 10:54:20 -0500 (EST), "Robert P. J. Day"
wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day"
> > wrote:
> > > victory is mine! ok, that premature return seems to have solved it,
> > > i'm up and running und
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day"
> wrote:
> > victory is mine! ok, that premature return seems to have solved it,
> > i'm up and running under this new kernel. are we getting close?
>
> Not even close. We just disabled fu
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day"
wrote:
> victory is mine! ok, that premature return seems to have solved it,
> i'm up and running under this new kernel. are we getting close?
Not even close. We just disabled functionality that was working in 2.6.37;
the interacti
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day"
> wrote:
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > >
On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day"
wrote:
> > That would be easy to test by returning early in intel_opregion_setup():
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_
> > index 9efccb9..8c93201 100644
> > --- a/drivers/gpu/drm
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
> wrote:
> > sadly, no change -- still black screen. again, rebooted
> > successfully under commit 8a327f23. just to be clear, here's "git
> > diff":
> >
> > $ git diff
> > diff --git a/in
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
wrote:
> sadly, no change -- still black screen. again, rebooted
> successfully under commit 8a327f23. just to be clear, here's "git
> diff":
>
> $ git diff
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7
On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
> >> TTM_PAGE_FLAG_DMA32 (l
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day"
> wrote:
> > > fix your boot issue or do we need to go back to using uncached:
> > >
> > > + return ioremap(phys, size);
> >
> > is that the next change you want me to try?
>
> Yes. (R
On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
>> If the TTM layer has used the DMA API to setup pages that are
>> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
>> array for pages that
On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day"
wrote:
> > fix your boot issue or do we need to go back to using uncached:
> >
> > + return ioremap(phys, size);
>
> is that the next change you want me to try?
Yes. (Replacing the current return ioremap_*(phys, size).)
-Chris
https://bugs.freedesktop.org/show_bug.cgi?id=33139
--- Comment #6 from Benjamin Franzke
2011-01-28 06:36:27 PST ---
(In reply to comment #5)
> Created an attachment (id=42615)
View: https://bugs.freedesktop.org/attachment.cgi?id=42615
Review: https://bugs.freedesktop.org/review?bug=33139&attac
https://bugs.freedesktop.org/show_bug.cgi?id=33139
--- Comment #6 from Benjamin Franzke
2011-01-28 06:36:27 PST ---
(In reply to comment #5)
> Created an attachment (id=42615)
View: https://bugs.freedesktop.org/attachment.cgi?id=42615
Review: https://bugs.freedesktop.org/review?bug=33139&attac
On Fri, 28 Jan 2011, Chris Wilson wrote:
> Well, we have two endpoints, so let git attack:
>
> $ git bisect start
> $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
>
> That shouldn't take more than a few recompiles to identify
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"
> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karc
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"
> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karc
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"
wrote:
> so the culprit appears to be:
>
> b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> commit b705120e4198315f4ae043de06c62f65e0851fd3
> Author: Michael Karcher
> Date: Sun Jan 23 18:17:17 2011 +
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=33648
--- Comment #1 from Pavel Ondračka 2011-01-28 05:54:33 PST
---
Created an attachment (id=42642)
--> (https://bugs.freedesktop.org/attachment.cgi?id=42642)
screenshot
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day"
> wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > Well, we have two endpoints, so let git attack:
> > >
> > > $ git bisect start
> > > $ git bisect good 58bbf018a70c562437eeae121
https://bugs.freedesktop.org/show_bug.cgi?id=33648
--- Comment #1 from Pavel Ondra?ka 2011-01-28 05:54:33
PST ---
Created an attachment (id=42642)
--> (https://bugs.freedesktop.org/attachment.cgi?id=42642)
screenshot
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=33648
Summary: Black line in Lightsmark with Z compression enabled
(RV530)
Product: Mesa
Version: git
Platform: Other
URL: http://dee.cz/lightsmark/Lightsmark2008.2.0.tar.bz2
https://bugs.freedesktop.org/show_bug.cgi?id=33648
Summary: Black line in Lightsmark with Z compression enabled
(RV530)
Product: Mesa
Version: git
Platform: Other
URL: http://dee.cz/lightsmark/Lightsmark2008.2.0.tar.bz2
https://bugs.freedesktop.org/show_bug.cgi?id=32945
--- Comment #16 from Sven Arvidsson 2011-01-28 04:38:04 PST ---
No change with the latest commits, but caps->hiz_ram = 0; makes the problem go
away.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=32945
--- Comment #16 from Sven Arvidsson 2011-01-28 04:38:04 PST ---
No change with the latest commits, but caps->hiz_ram = 0; makes the problem go
away.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
On Fri, 28 Jan 2011, Chris Wilson wrote:
> Well, we have two endpoints, so let git attack:
>
> $ git bisect start
> $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
>
> That shouldn't take more than a few recompiles to identify
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #18 from Pavel Ondračka 2011-01-28 03:42:50 PST
---
(In reply to comment #17)
> The right side of this screenshot that you posted:
> https://bugs.freedesktop.org/attachment.cgi?id=42516
> Looks a lot like what I see when I disable th
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #18 from Pavel Ondra?ka 2011-01-28 03:42:50
PST ---
(In reply to comment #17)
> The right side of this screenshot that you posted:
> https://bugs.freedesktop.org/attachment.cgi?id=42516
> Looks a lot like what I see when I disable th
On Fri, 28 Jan 2011, Chris Wilson wrote:
> Well, we have two endpoints, so let git attack:
>
> $ git bisect start
> $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
>
> That shouldn't take more than a few recompiles to identify
https://bugs.freedesktop.org/show_bug.cgi?id=32945
--- Comment #15 from Marek Olšák 2011-01-28 03:08:44 PST ---
If the latest commits don't help, please add the following line at the end of
r300_chipset.c and test again:
caps->hiz_ram = 0;
--
Configure bugmail: https://bugs.freedesktop.org/use
https://bugs.freedesktop.org/show_bug.cgi?id=32945
--- Comment #15 from Marek Ol??k 2011-01-28 03:08:44 PST
---
If the latest commits don't help, please add the following line at the end of
r300_chipset.c and test again:
caps->hiz_ram = 0;
--
Configure bugmail: https://bugs.freedesktop.org/us
Hi Linus,
radeon and nouveau fixes only, a couple of regressions, one evergreen
GPU hang under load, and one big endian fix.
Dave.
The following changes since commit 6663050edd9c2e8b1e1f55c09459144d84c045f0:
Merge branch 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-26
09:0
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #17 from Tom Stellard 2011-01-28 01:36:08 PST
---
The right side of this screenshot that you posted:
https://bugs.freedesktop.org/attachment.cgi?id=42516
Looks a lot like what I see when I disable the reg rename pass.
I've double ch
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #17 from Tom Stellard 2011-01-28 01:36:08
PST ---
The right side of this screenshot that you posted:
https://bugs.freedesktop.org/attachment.cgi?id=42516
Looks a lot like what I see when I disable the reg rename pass.
I've double ch
On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day"
wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > Well, we have two endpoints, so let git attack:
> >
> > $ git bisect start
> > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> > $ git bisect bad abb72c828878a2c69b2c
On Fri, 28 Jan 2011, Chris Wilson wrote:
> Well, we have two endpoints, so let git attack:
>
> $ git bisect start
> $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
>
> That shouldn't take more than a few recompiles to identify
https://bugs.freedesktop.org/show_bug.cgi?id=32296
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=32296
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day"
wrote:
>
> one more observation which should nail things down:
>
> On Thu, 27 Jan 2011, Robert P. J. Day wrote:
>
> > ok, i'm getting different results from this morning, not sure why,
> > but i'm fairly confident i've isolated i
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #16 from Pavel Ondračka 2011-01-28 00:53:06 PST
---
I'm puzzled, because here with mesa master + disable scheduler rewrite patch, I
get the wrong behavior (right part of
https://bugs.freedesktop.org/attachment.cgi?id=42516 ). However
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #16 from Pavel Ondra?ka 2011-01-28 00:53:06
PST ---
I'm puzzled, because here with mesa master + disable scheduler rewrite patch, I
get the wrong behavior (right part of
https://bugs.freedesktop.org/attachment.cgi?id=42516 ). However
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote:
> Konrad, Dave
>
> Given our previous discussion on the list, I believe these patches
> shouldn't introduce any regressions in the non-Xen case, however we
> should probably be prepared to back them out quickly if that turns
> out t
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #15 from Tom Stellard 2011-01-28 00:22:12 PST
---
Created an attachment (id=42627)
--> (https://bugs.freedesktop.org/attachment.cgi?id=42627)
Screenshot with scheduler patch
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #15 from Tom Stellard 2011-01-28 00:22:12
PST ---
Created an attachment (id=42627)
--> (https://bugs.freedesktop.org/attachment.cgi?id=42627)
Screenshot with scheduler patch
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #14 from Tom Stellard 2011-01-28 00:21:18 PST
---
Created an attachment (id=42626)
--> (https://bugs.freedesktop.org/attachment.cgi?id=42626)
Screenshot with RADEON_DEBUG=noopt
--
Configure bugmail: https://bugs.freedesktop.org/us
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #14 from Tom Stellard 2011-01-28 00:21:18
PST ---
Created an attachment (id=42626)
--> (https://bugs.freedesktop.org/attachment.cgi?id=42626)
Screenshot with RADEON_DEBUG=noopt
--
Configure bugmail: https://bugs.freedesktop.org/us
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #13 from Tom Stellard 2011-01-28 00:20:29 PST
---
I'm pretty sure this is a bug in the scheduler. I'm attaching screenshots
comparing running with this patch:
https://bugs.freedesktop.org/attachment.cgi?id=42514 to running with
RADE
https://bugs.freedesktop.org/show_bug.cgi?id=31830
--- Comment #13 from Tom Stellard 2011-01-28 00:20:29
PST ---
I'm pretty sure this is a bug in the scheduler. I'm attaching screenshots
comparing running with this patch:
https://bugs.freedesktop.org/attachment.cgi?id=42514 to running with
RADE
94 matches
Mail list logo
