Hi Dave,
I've quickly looked at the qa report and one bug seems to be a benign
warning due to one of Adam's paranoia patches. The other is a modeset
failure because the kernel detects more modes (and the new ones fail).
Could be either due to the CEA patch or one of the dp bandwidth patches.
The o
Chad Versace (1):
intel: Fix bufmgr_gem->gen for gen > 4
Eric Anholt (17):
intel: Add a regression test for 2D decode, which I'm about to refactor.
intel: Track the current packet location in the decode context.
intel: Drop the code for counting parsing failures.
inte
https://bugs.freedesktop.org/show_bug.cgi?id=45709
--- Comment #4 from Kai 2012-02-07 09:22:50 PST
---
(In reply to comment #3)
> Does it work with stable Mesa, 7.11.2?
>
> If it is a regression it might be similar to bug 44647, that one is caused by
> a
> removed flush.
No, 7.11.2 shows the
On Son, 2012-02-05 at 00:38 +0100, acrux wrote:
>
> unable to have a working radeon kms framebuffer with linux-3.3-rc2 on ppc
> video card: Radeon X1650PRO PCIE
Is this a regression? If yes, can you bisect?
> [drm] GART: num cpu pages 131072, num gpu pages 131072
The driver detects the CPU pag
On Son, 2012-02-05 at 00:41 +0100, acrux wrote:
> unable to have a working radeon kms framebuffer with linux-3.3-rc2 on ppc
> video card: Radeon 9250 PCI
Is this a regression? If yes, can you bisect?
> Machine check in kernel mode.
> Data Write PLB Error
> Machine Check exception is imprecise
>
https://bugs.freedesktop.org/show_bug.cgi?id=45641
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #6 from John 2012-02-07 12:22:13 PST ---
It seems quite random to me.
Also I remember it happening around the 3.0 release, but I cannot say that the
issue is coming from there.
For all I know it could be KDE messing up somewhere or so
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 435a3d9..22e0afe 100644
--- a/drivers/gpu/drm/radeon/rade
On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
> On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
>
> > I remember at one point you had a plan along the lines of passing shmem
> > fds across the protocol. I'm curious what happened to that -- too hard
> > to get the passing to
On 2/7/12 6:28 PM, Ben Widawsky wrote:
On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
If you can, I recommend using the intel gtt mapping type of mmap ioctl,
where it gives you back an offset that you use the mmap syscall on, and
implement the vgem_gem_fault to map its pages, inst
https://bugzilla.kernel.org/show_bug.cgi?id=42678
--- Comment #5 from Torsten Kaiser
2012-02-07 06:59:30 ---
Not completely sure about that. I wait until the screensaver kicks in (or
better: let KDEs powerdevil switch the monitor off, I do not have a screensaver
programm running) an then le
Hi Dave,
I've quickly looked at the qa report and one bug seems to be a benign
warning due to one of Adam's paranoia patches. The other is a modeset
failure because the kernel detects more modes (and the new ones fail).
Could be either due to the CEA patch or one of the dp bandwidth patches.
The o
Chad Versace (1):
intel: Fix bufmgr_gem->gen for gen > 4
Eric Anholt (17):
intel: Add a regression test for 2D decode, which I'm about to refactor.
intel: Track the current packet location in the decode context.
intel: Drop the code for counting parsing failures.
inte
https://bugs.freedesktop.org/show_bug.cgi?id=45709
--- Comment #4 from Kai 2012-02-07 09:22:50 PST
---
(In reply to comment #3)
> Does it work with stable Mesa, 7.11.2?
>
> If it is a regression it might be similar to bug 44647, that one is caused by
> a
> removed flush.
No, 7.11.2 shows the
On Son, 2012-02-05 at 00:38 +0100, acrux wrote:
>
> unable to have a working radeon kms framebuffer with linux-3.3-rc2 on ppc
> video card: Radeon X1650PRO PCIE
Is this a regression? If yes, can you bisect?
> [drm] GART: num cpu pages 131072, num gpu pages 131072
The driver detects the CPU pag
On Son, 2012-02-05 at 00:41 +0100, acrux wrote:
> unable to have a working radeon kms framebuffer with linux-3.3-rc2 on ppc
> video card: Radeon 9250 PCI
Is this a regression? If yes, can you bisect?
> Machine check in kernel mode.
> Data Write PLB Error
> Machine Check exception is imprecise
>
https://bugs.freedesktop.org/show_bug.cgi?id=45641
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at
lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #6 from John 2012-02-07 12:22:13 PST
---
It seems quite random to me.
Also I remember it happening around the 3.0 release, but I cannot say that the
issue is coming from there.
For all I know it could be KDE messing up somewhere or s
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 435a3d9..22e0afe 100644
--- a/drivers/gpu/drm/radeon/rade
On 2/7/12 6:28 PM, Ben Widawsky wrote:
> On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
>>> If you can, I recommend using the intel gtt mapping type of mmap ioctl,
>>> where it gives you back an offset that you use the mmap syscall on, and
>>> implement the vgem_gem_fault to map its
The TTM page can be allocated from high memory. In such case it is
wrong to use the page_address(page) as the virtual address for the high memory
page.
Signed-off-by: Zhao Yakui
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/
BAD MSG:
correctly
The TTM page can be allocated from high memory. In such case it is
wrong to use the page_address(page) as the virtual address for the high
memory page.
Signed-off-by: Zhao Yakui
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |5 -
1 files changed, 4 insertions(+), 1 deletio
24 matches
Mail list logo
