On Wed, 08 May 2013, Ville Syrjälä wrote:
> On Wed, May 08, 2013 at 05:03:31PM +0100, Damien Lespiau wrote:
>> +static const char *connector_status_str(enum drm_connector_status status)
>> +{
>> +switch (status) {
>> +case connector_status_connected:
>> +return "connected";
>>
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #17 from Thilo Cestonaro ---
Hey ho,
I updated to ubuntu raring latest again and the bug is still bugging me ;).
Please let me know if I can provide more info so the bug can be fixed.
Greetings
Thilo
--
You are receiving this mai
I will release a new version of libdrm after this is committed.
---
radeon/radeon_surface.c |9 ++---
radeon/radeon_surface.h |1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 288b5e2..56012da 100644
--- a/radeo
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #15 from Tom Stellard ---
(In reply to comment #8)
> (In reply to comment #7)
> > I would recommend using bfgminer for bitcoin mining. It auto-detects the
> > mesa platform, and disabled unsupported features. All you need to do to g
https://bugzilla.kernel.org/show_bug.cgi?id=57831
Luke-Jr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #7 from Alex Deucher 2013-05-09
23:06:32 ---
That's not something I'd like to support in the driver. If you can't get the
vbios, you probably have bigger problems.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cg
If NO_DMA=y:
drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_g
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #6 from Luke-Jr 2013-05-09
22:52:11 ---
For the workaround, I meant the driver ignoring the vbios ROM, and instead
loading it from a firmware file. ;)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130509/d5d36893/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #5 from Alex Deucher 2013-05-09
22:32:47 ---
You should be able to pass the existing pci rom resource through to the VM, but
I'm not really a KVM expert. Just about every graphics driver is going to need
the vbios image so there
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #4 from Luke-Jr 2013-05-09
22:19:33 ---
Confirmed both the fglrx and radeon systems are getting the Cirrus (emulated)
VGA ROM instead of the Radeon ROM.
Is there a way I can override/provide the Radeon ROM to the driver as a
wor
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #14 from Aaron Watry ---
> @Aaron, could you use pyrit or any other OpenCL tools with yours HD6850
> without lockup?
I get the same error from pyrit (cpyrit-opencl) as you do:
> awatry@veer:~/src/opencl_applications/cpyrit-opencl-0.
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #3 from Alex Deucher 2013-05-09
21:01:41 ---
No both drivers need the vbios image. The closed driver either gets the vbios
via some alternative means or it has some sort of fallback image if it can't
find the actual vbios image.
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #2 from Luke-Jr 2013-05-09
20:47:30 ---
I guess I assumed that the hardware end should be working fine since fglrx
works. Is needing the PCI ROM something unique to the free drivers?
--
Configure bugmail: https://bugzilla.kerne
On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
This comment is wrong, as i said we need MTRR on PAT system for VRAM.
Che
The original line,
WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp);
wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where
MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into
MGA1064_PIX_CLK_CTL. Change the line to write properly into
MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use
the same
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
Tested-by: Jul
On Thu, May 9, 2013 at 5:30 PM, Marek Ol??k wrote:
> I will release a new version of libdrm after this is committed.
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c |9 ++---
> radeon/radeon_surface.h |1 +
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git
On Thu, May 9, 2013 at 4:44 PM, Jerome Glisse wrote:
> On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski
> wrote:
>> A fair number of drivers (mostly graphics) add write-combining MTRRs.
>> Most ignore errors and most add the MTRR even on PAT systems which don't
>> need to use MTRRs.
>
> This comm
Hello,
ping also here.. any other information needed about this nouveau kernel crash?
Thanks,
-- Pasi
On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi K?rkk?inen wrote:
> Hello,
>
> Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:
>
> $ lspci | grep VGA
> 00:02.0
Hello,
Any comments? Should I provide more logs, or try something I didn't try yet?
Thanks,
-- Pasi
On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi K?rkk?inen wrote:
> Hello,
>
> Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled
> in BIOS,
> and only the Nvidia dis
The original line,
WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp);
wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where
MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into
MGA1064_PIX_CLK_CTL. Change the line to write properly into
MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use
the same
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
---
drivers/g
: 2.1 Mesa 9.1.2
OpenGL shading language version string: 1.20
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130509/24a38
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #1 from Luke-Jr 2013-05-10
00:40:46 ---
Created an attachment (id=101051)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101051)
kernel patch by workaround VBIOS issue
--
Configure bugmail: https://bugzilla.kernel.org/user
https://bugzilla.kernel.org/show_bug.cgi?id=57921
Summary: NULL pointer dereference in radeon_bo_create
Product: Drivers
Version: 2.5
Kernel Version: 3.9.0
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
This comment is wrong, as i said we need MTRR on PAT system for VRAM.
Che
esktop.org/archives/dri-devel/attachments/20130509/c2d57955/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57831
Luke-Jr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, May 9, 2013 at 5:30 PM, Marek Olšák wrote:
> I will release a new version of libdrm after this is committed.
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c |9 ++---
> radeon/radeon_surface.h |1 +
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #7 from Alex Deucher 2013-05-09 23:06:32
---
That's not something I'd like to support in the driver. If you can't get the
vbios, you probably have bigger problems.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cg
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #6 from Luke-Jr 2013-05-09
22:52:11 ---
For the workaround, I meant the driver ignoring the vbios ROM, and instead
loading it from a firmware file. ;)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--
https://bugs.freedesktop.org/show_bug.cgi?id=64376
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
There are no users left in drivers/gpu.
Signed-off-by: Andy Lutomirski
---
This is new in v2. The code I'm deleting is kind of gross.
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
add
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..15cd34b 100644
--- a/drivers/gpu/drm/radeon/radeon_obj
Christopher Harvey writes:
> The Following should be CC'd to stable:
> * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
> * drm/mgag200: Fix framebuffer base address programming
>
> The others are bug fixes, but aren't critical. I'm sitting on some
> hardware cursor code that depend
i915 open-coded logic that was essentially equivalent to the new API.
Signed-off-by: Andy Lutomirski
---
Changes from v1: More cleanup
drivers/gpu/drm/i915/i915_dma.c | 44 ++---
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/ast/ast_ttm.c
Several drivers currently use mtrr_add through various #ifdef guards
and/or drm wrappers. The vast majority of them want to add WC MTRRs
on x86 systems and don't actually need the MTRR if PAT (i.e.
ioremap_wc, etc) are working.
arch_phys_wc_add and arch_phys_wc_del are new functions, available
on
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
x86 systems with MTRRs, add MTRRs and report errors, and that do
I forgot to include some acked and tested-by lines in v1 of this
series.
No code changes in v2.
thanks,
Christopher Harvey (4):
drm/mgag200: Don't change unrelated registers during modeset
drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
drm/mgag200: Convert counter delays to jiffi
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #5 from Alex Deucher 2013-05-09 22:32:47
---
You should be able to pass the existing pci rom resource through to the VM, but
I'm not really a KVM expert. Just about every graphics driver is going to need
the vbios image so there
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #4 from Luke-Jr 2013-05-09
22:19:33 ---
Confirmed both the fglrx and radeon systems are getting the Cirrus (emulated)
VGA ROM instead of the Radeon ROM.
Is there a way I can override/provide the Radeon ROM to the driver as a
wor
er touched it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130509/19e08833/attachment.html>
I will release a new version of libdrm after this is committed.
---
radeon/radeon_surface.c |9 ++---
radeon/radeon_surface.h |1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 288b5e2..56012da 100644
--- a/radeo
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc
If NO_DMA=y:
drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_g
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #3 from Alex Deucher 2013-05-09 21:01:41
---
No both drivers need the vbios image. The closed driver either gets the vbios
via some alternative means or it has some sort of fallback image if it can't
find the actual vbios image.
The Following should be CC'd to stable:
* drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
* drm/mgag200: Fix framebuffer base address programming
The others are bug fixes, but aren't critical. I'm sitting on some
hardware cursor code that depends on all of these patches before it
can g
From: Dave Airlie
if the surface is evicted, this validation will happen
to the wrong place, I noticed this with other work I was
doing, haven't seen it go wrong in practice.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/driv
https://bugzilla.kernel.org/show_bug.cgi?id=57831
--- Comment #2 from Luke-Jr 2013-05-09
20:47:30 ---
I guess I assumed that the hardware end should be working fine since fglrx
works. Is needing the PCI ROM something unique to the free drivers?
--
Configure bugmail: https://bugzilla.kerne
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130509/bd98261e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57831
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
There are no users left in drivers/gpu.
Signed-off-by: Andy Lutomirski
---
This is new in v2. The code I'm deleting is kind of gross.
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
add
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..15cd34b 100644
--- a/drivers/gpu/drm/radeon/radeon_obj
i915 open-coded logic that was essentially equivalent to the new API.
Signed-off-by: Andy Lutomirski
---
Changes from v1: More cleanup
drivers/gpu/drm/i915/i915_dma.c | 44 ++---
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/ast/ast_ttm.c
Several drivers currently use mtrr_add through various #ifdef guards
and/or drm wrappers. The vast majority of them want to add WC MTRRs
on x86 systems and don't actually need the MTRR if PAT (i.e.
ioremap_wc, etc) are working.
arch_phys_wc_add and arch_phys_wc_del are new functions, available
on
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
x86 systems with MTRRs, add MTRRs and report errors, and that do
Christopher Harvey writes:
> The Following should be CC'd to stable:
> * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
> * drm/mgag200: Fix framebuffer base address programming
>
> The others are bug fixes, but aren't critical. I'm sitting on some
> hardware cursor code that depend
Higher bits of the base address of framebuffers weren't being
programmed properly. This caused framebuffers that didn't happen to be
allocated at a low enough address to not be displayed properly.
Signed-off-by: Christopher Harvey
Signed-off-by: Mathieu Larouche
Acked-by: Julia Lemire
Tested-by
Signed-off-by: Christopher Harvey
Acked-by: Julia Lemire
Tested-by: Julia Lemire
Acked-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/m
The original line,
WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp);
wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where
MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into
MGA1064_PIX_CLK_CTL. Change the line to write properly into
MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use
the same
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
Tested-by: Jul
I forgot to include some acked and tested-by lines in v1 of this
series.
No code changes in v2.
thanks,
Christopher Harvey (4):
drm/mgag200: Don't change unrelated registers during modeset
drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
drm/mgag200: Convert counter delays to jiffi
Higher bits of the base address of framebuffers weren't being
programmed properly. This caused framebuffers that didn't happen to be
allocated at a low enough address to not be displayed properly.
Signed-off-by: Christopher Harvey
Signed-off-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mga
The original line,
WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp);
wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where
MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into
MGA1064_PIX_CLK_CTL. Change the line to write properly into
MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use
the same
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
---
drivers/g
The Following should be CC'd to stable:
* drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
* drm/mgag200: Fix framebuffer base address programming
The others are bug fixes, but aren't critical. I'm sitting on some
hardware cursor code that depends on all of these patches before it
can g
https://bugs.freedesktop.org/show_bug.cgi?id=63236
Eugene changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, May 9, 2013 at 9:20 AM, Chris Cummins
wrote:
> The intention here is to make the output of dmesg with full verbosity a
> bit easier for a human to parse. This commit transforms:
>
> [drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc010645b
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130509/7d88c138/attachment.html>
Hello,
ping also here.. any other information needed about this nouveau kernel crash?
Thanks,
-- Pasi
On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi Kärkkäinen wrote:
> Hello,
>
> Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:
>
> $ lspci | grep VGA
> 00:02.0
Hello,
Any comments? Should I provide more logs, or try something I didn't try yet?
Thanks,
-- Pasi
On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi Kärkkäinen wrote:
> Hello,
>
> Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled
> in BIOS,
> and only the Nvidia dis
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #9 from Dave Witbrodt ---
Noting Benjamin's experience with EFI in comment 8, I took a look at my 3
machines on which I am trying the UVD support. I have a laptop, a desktop, and
another (inexpensive) desktop which I use as a file se
On Thu, May 9, 2013 at 9:20 AM, Chris Cummins
wrote:
> The intention here is to make the output of dmesg with full verbosity a
> bit easier for a human to parse. This commit transforms:
>
> [drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc010645b
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc
https://bugs.freedesktop.org/show_bug.cgi?id=64376
--- Comment #1 from Alex Deucher ---
You need to make sure the VM has access to the PCI rom.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-de
https://bugzilla.kernel.org/show_bug.cgi?id=57831
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
vel/attachments/20130509/53f21447/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57831
Summary: radeon fatal error during GPU init (Radeon 5850, KVM
GPU passthrough)
Product: Drivers
Version: 2.5
Kernel Version: 3.9.0
Platform: All
OS/Version: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #64 from udo ---
Weird thing is that with 3.8.10 the box has been stable for a few days without
weird radeon-related errors.
Currently trying 3.9.1.
Git mesa, llvm, libclc, xf-video-ati etc
--
You are receiving this mail because:
Y
Hi all,
This post introduces a new helper framework based on dma fence. And the
purpose of this post is to collect other opinions and advices before RFC
posting.
First of all, this helper framework, called fence helper, is in progress
yet so might not have enough comments in codes and also might
90 matches
Mail list logo
