e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/1ecc3e68/attachment.html>
fix.
--
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/20130516/d8db4236/attachment.html>
ok, i will merge and retest
On Thu, May 16, 2013 at 9:49 PM, David Airlie wrote:
>>
>> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
>> the
>> kernel mode setting panic's as well.
>>
>> In this example, the first one is my fault; but then cirrus framebuffer DRM
>> mod
I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's the
kernel mode setting panic's as well.
In this example, the first one is my fault; but then cirrus framebuffer DRM
modesetting craps out.
[ 66.440071] kernel tried to execute NX-protected page - exploit attempt?
(uid
ok, i will merge and retest
On Thu, May 16, 2013 at 9:49 PM, David Airlie wrote:
>>
>> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
>> the
>> kernel mode setting panic's as well.
>>
>> In this example, the first one is my fault; but then cirrus framebuffer DRM
>> mod
ed pulse I don't know if it's easy to bypass (assuming you are
using it),
mplayer -ao alsa:device=hw=1.3 may work (assumes cat /proc/asound/cards shows
HDMI as 1)
--
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/20130516/e56c691a/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/97c0633c/attachment.html>
>
> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
> the
> kernel mode setting panic's as well.
>
> In this example, the first one is my fault; but then cirrus framebuffer DRM
> modesetting craps out.
Yeah the fix went to stable today I think
drm: don't check modeset
I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's the
kernel mode setting panic's as well.
In this example, the first one is my fault; but then cirrus framebuffer DRM
modesetting craps out.
[ 66.440071] kernel tried to execute NX-protected page - exploit attempt?
(uid
On Wed, May 15, 2013 at 4:06 PM, Rob Clark wrote:
> So while it seems nice and orthogonal/clean to couple cache and
> synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> same generic way, but I think in practice we have to make things more
> complex than they otherwise need to b
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/2a9ba6cb/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/e9b4df0c/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/04fed284/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/a3c3fa96/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64443
--- Comment #3 from Kenneth Graunke ---
But that's still several months out, and you probably don't want to wait that
long. In the meantime, you can do:
export MESA_GL_VERSION_OVERRIDE=3.2
export MESA_GLSL_VERSION_OVERRIDE=150
before launching
https://bugs.freedesktop.org/show_bug.cgi?id=56534
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=64695
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=64695
Priority: medium
Bug ID: 64695
Assignee: dri-devel@lists.freedesktop.org
Summary: Enabling both MLAA and MLAA color 2D crashes Gnome
Shell on Cayman (6950)
Severity: major
https://bugs.freedesktop.org/show_bug.cgi?id=64694
Rafael Castillo changed:
What|Removed |Added
Attachment #79451|text/plain |image/jpeg
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=64694
Rafael Castillo changed:
What|Removed |Added
Priority|medium |highest
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=64694
Priority: medium
Bug ID: 64694
Assignee: dri-devel@lists.freedesktop.org
Summary: xorg fail to start after llvm upgrade
Severity: blocker
Classification: Unclassified
OS: Lin
Signed-off-by: Russell King
---
drivers/gpu/drm/dove/dove_output.c | 20
drivers/gpu/drm/dove/dove_output.h |6 ++
drivers/gpu/drm/dove/dove_tda19988.c | 23 ++-
3 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/d
Signed-off-by: Russell King
---
drivers/gpu/drm/dove/Kconfig |9 ++
drivers/gpu/drm/dove/Makefile|2 +
drivers/gpu/drm/dove/dove_drm.h |1 +
drivers/gpu/drm/dove/dove_drv.c |4 +
drivers/gpu/drm/dove/dove_tda19988.c | 249
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 308 -
1 files changed, 301 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d6afd02..8ffb844 100644
--- a/drivers/gpu/d
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index da2917b..d6afd02 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
set this to 0x12. Thi
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 (aka Dove) SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
- dual lcd0 and lcd1 crt operatio
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/5b5c0476/attachment.html>
What follows is my DRM driver for Dove, which I've been working on with
the Solid-run Cubox, which only offers HDMI output via the TDA19988
chip.
Not everything is finished off perfectly in this driver; there's quite
a number of ragged edges (particularly with page flipping, which is
completely un
op.org/archives/dri-devel/attachments/20130516/2b8def08/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/d68ef610/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/3945d422/attachment.html>
Hi Linus,
Fix for radeon nomodeset regression, old radeon interface cliprects fix, 2
qxl crasher fixes, and a couple of minor cleanups.
I may have a new AMD hw support branch next week, its one of those doesn't
affect anything existing just adds new support, I'll see how it
shapes up and I mi
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/113927fc/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/58a11de8/attachment.html>
> I need a defconfig which would have this driver enabled.
My wish would be a minimal config. Right now, I try to build the driver
with the current config and when that fails I grep through the
(uncompressed) defconfigs for the symbol needed. Gives me 45/57 success
rate on this series. Not perfe
https://bugs.freedesktop.org/show_bug.cgi?id=64443
--- Comment #2 from romula...@gmail.com ---
(In reply to comment #1)
> r600g doesn't support OpenGL 3.2 yet - that's why it fails
Doesn't seem like it will be too long until it is supported considering this
list: http://cgit.freedesktop.org/mesa/
https://bugs.freedesktop.org/show_bug.cgi?id=64443
romula...@gmail.com changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #27 from Benjamin Lee ---
I accidentally attached radeontool output instead of radeonreg. The correct
output (radeonreg) is attached now.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #26 from Benjamin Lee ---
Created attachment 79448
--> https://bugs.freedesktop.org/attachment.cgi?id=79448&action=edit
radeonreg regs all in EFI booting
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #25 from Benjamin Lee ---
Created attachment 79447
--> https://bugs.freedesktop.org/attachment.cgi?id=79447&action=edit
radeonreg regs all in BIOS emulation mode
--
You are receiving this mail because:
You are the assignee for the
be a good long term goal to make drivers arch-independent,
and add CONFIG_SHOW_ALL_DRIVERS or such, which would allow compiling
drivers that are not used on your arch, but still compile fine.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/bf10962e/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #9 from Mike Lothian ---
I too can confirm that the two patches to llvm fix things for me
Is there any chance they could be applied to llvm 3.3 before it's released?
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #24 from Dave Witbrodt ---
(In reply to comment #19)
> (In reply to comment #18)
> > Benjamin and Parag have already indicated which firmware versions they are
> > using, and I feel it's safe to assume that Christian is also using the
The current of_get_display_timings() reads multiple display timings,
allocating memory for the entries. However, most of the time when
parsing display timings from DT data is needed, there's only one display
timing as it's not common for a LCD panel to support multiple videomodes.
This patch creat
Move the allocation of display_timing memory from of_get_display_timing() to
of_get_display_timings(). This allows us to use of_get_display_timing()
in a way that doesn't require dynamic memory allocation.
Signed-off-by: Tomi Valkeinen
Cc: Steffen Trumtrar
Cc: Laurent Pinchart
Cc: Philipp Zabel
On Thu, May 16, 2013 at 6:50 AM, Jerome Glisse wrote:
> On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski wrote:
>> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse wrote:
>>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski
>>> wrote:
On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse wrote:
>
Signed-off-by: Russell King
---
drivers/gpu/drm/dove/dove_output.c | 20
drivers/gpu/drm/dove/dove_output.h |6 ++
drivers/gpu/drm/dove/dove_tda19988.c | 23 ++-
3 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/d
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 308 -
1 files changed, 301 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d6afd02..8ffb844 100644
--- a/drivers/gpu/d
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
set this to 0x12. Thi
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
Signed-off-by: Russell King
---
drivers/gpu/drm/dove/Kconfig |9 ++
drivers/gpu/drm/dove/Makefile|2 +
drivers/gpu/drm/dove/dove_drm.h |1 +
drivers/gpu/drm/dove/dove_drv.c |4 +
drivers/gpu/drm/dove/dove_tda19988.c | 249
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index da2917b..d6afd02 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+
What follows is my DRM driver for Dove, which I've been working on with
the Solid-run Cubox, which only offers HDMI output via the TDA19988
chip.
Not everything is finished off perfectly in this driver; there's quite
a number of ragged edges (particularly with page flipping, which is
completely un
On 05/16/2013 05:15 AM, Wolfram Sang wrote:
> Lately, I have been experimenting how to improve the devm interface to make
> writing device drivers easier and less error prone while also getting rid of
> its subtle issues. I think it has more potential but still needs work and
> definately conistenc
> I need a defconfig which would have this driver enabled.
My wish would be a minimal config. Right now, I try to build the driver
with the current config and when that fails I grep through the
(uncompressed) defconfigs for the symbol needed. Gives me 45/57 success
rate on this series. Not perfe
his UVD code, though it also boots Linux without an initrd.)
--
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/20130516/16f338c0/attachment.html>
On 16/05/13 16:11, Artem Bityutskiy wrote:
> On Thu, 2013-05-16 at 18:25 +0530, Viresh Kumar wrote:
>> On 16 May 2013 17:27, Artem Bityutskiy wrote:
>>> On Thu, 2013-05-16 at 13:15 +0200, Wolfram Sang wrote:
Despite various architectures and platform dependencies, I managed to
compile
>>
The current of_get_display_timings() reads multiple display timings,
allocating memory for the entries. However, most of the time when
parsing display timings from DT data is needed, there's only one display
timing as it's not common for a LCD panel to support multiple videomodes.
This patch creat
Move the allocation of display_timing memory from of_get_display_timing() to
of_get_display_timings(). This allows us to use of_get_display_timing()
in a way that doesn't require dynamic memory allocation.
Signed-off-by: Tomi Valkeinen
Cc: Steffen Trumtrar
Cc: Laurent Pinchart
Cc: Philipp Zabel
Lately, I have been experimenting how to improve the devm interface to make
writing device drivers easier and less error prone while also getting rid of
its subtle issues. I think it has more potential but still needs work and
definately conistency, especiall in its usage.
The first thing I come u
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #14 from Andy Furniss ---
(In reply to comment #0)
> (originally reported to Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=954009)
>
> I've recently started trying out 24 Hz again as my TV handles it better, and
> XBMC is fin
https://bugs.freedesktop.org/show_bug.cgi?id=64443
romula...@gmail.com changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #23 from Benjamin Lee ---
Created attachment 79443
--> https://bugs.freedesktop.org/attachment.cgi?id=79443&action=edit
radeontool regs with fglrx
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #22 from Benjamin Lee ---
Created attachment 79442
--> https://bugs.freedesktop.org/attachment.cgi?id=79442&action=edit
radeontool regs from EFI booting
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #21 from Benjamin Lee ---
Created attachment 79441
--> https://bugs.freedesktop.org/attachment.cgi?id=79441&action=edit
radeontool regs from Apple BIOS emulation mode
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #20 from Benjamin Lee ---
I am using a monolithic kernel without initrd (CONFIG_DRM_RADEON=y and
CONFIG_EXTRA_FIRMWARE) using the exact same vmlinuz file between EFI and BIOS
modes, so I don't believe I have a ucode issue since BIOS m
On Thu, May 16, 2013 at 6:50 AM, Jerome Glisse wrote:
> On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski
> wrote:
>> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse wrote:
>>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski
>>> wrote:
On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse
but I don't know how to.
--
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/20130516/b68d95ed/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #19 from Alex Deucher ---
(In reply to comment #18)
> (In reply to comment #17)
> > Make sure you have the updated RLC ucode in addition to the UVD ucode.
> > Unfortunately, I can't reproduce this on the UEFI systems I have access to
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/
Lately, I have been experimenting how to improve the devm interface to make
writing device drivers easier and less error prone while also getting rid of
its subtle issues. I think it has more potential but still needs work and
definately conistency, especiall in its usage.
The first thing I come u
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #18 from Dave Witbrodt ---
(In reply to comment #17)
> Make sure you have the updated RLC ucode in addition to the UVD ucode.
> Unfortunately, I can't reproduce this on the UEFI systems I have access to.
Benjamin and Parag have alre
ther.
--
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/20130516/382de89f/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #12 from Pierre Ossman ---
So I tried that, and things are now back to ~110 seconds before a glitch. This
is the code in case anyone's curious:
base_bits = fls(24000);
clock_bits = fls(clock);
shift = min(32 - base_bits,
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/20130516/bca1a046/attachment.html>
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/da68eadd/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #13 from Pierre Ossman ---
Also tried upping packets per line to 8, and the glitch is still in the same
place.
More ideas? =/
--
You are receiving this mail because:
You are the assignee for the bug.
___
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/57133b86/attachment.html>
On 05/16/2013 05:15 AM, Wolfram Sang wrote:
> Lately, I have been experimenting how to improve the devm interface to make
> writing device drivers easier and less error prone while also getting rid of
> its subtle issues. I think it has more potential but still needs work and
> definately conistenc
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #11 from Pierre Ossman ---
Test results:
3.9.2 (Fedora): Glitches at around 110 seconds
plus upstream DTO stuff patched in: Dito.
plus Alex' patch: Glitches after about 20 seconds
So the suggested modification makes things much wors
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #17 from Alex Deucher ---
Make sure you have the updated RLC ucode in addition to the UVD ucode.
Unfortunately, I can't reproduce this on the UEFI systems I have access to.
--
You are receiving this mail because:
You are the assign
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/c92374ca/attachment.html>
Jean-Fran?ois,
Please run ./scripts/get_maintainer.pl on your patches before
submitting. In this case:
$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/
David Airlie (maintainer:DRM DRIVERS)
dri-devel at lists.freedesktop.org (open list:DRM DRIVERS)
linux-kernel at vger.kernel.org (open list)
On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski wrote:
> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse wrote:
>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski
>> wrote:
>>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse
>>> wrote:
On Tue, May 14, 2013 at 8:58 AM, Alex Deucher
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #16 from Dave Witbrodt ---
(In reply to comment #15)
>
> The good news is that I can reproduce the problem, and it indeed looks like
> the firmware image gets corrupted. But that seems to always happen not only
> when the image is lo
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/3afebea1/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130516/a7df61de/attachment.html>
On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski wrote:
> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse wrote:
>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski wrote:
>>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse wrote:
On Tue, May 14, 2013 at 8:58 AM, Alex Deucher
wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #9 from Eugene ---
(In reply to comment #8)
> This is most likely a mesa issue; there are several new features in mesa
> that are only enabled with a 3.8 kernel. Can one of you use git to bisect
> mesa to see what commit broke things
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #15 from Christian König ---
(In reply to comment #14)
> Try booting into runlevel 3 with radeon kms (radeon.modeset=0 on the kernel
> command line in grub, etc.), then manually load radeon with kms enabled
> (modprobe -r radeon; modp
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #14 from Alex Deucher ---
Try booting into runlevel 3 with radeon kms (radeon.modeset=0 on the kernel
command line in grub, etc.), then manually load radeon with kms enabled
(modprobe -r radeon; modprobe radeon modeset=1).
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #13 from Alex Deucher ---
(In reply to comment #12)
> Is it known what is going on exactly here?
>
> This seems almost like an incomplete new feature or a regression and hence a
> candidate to be reverted in 3.10.
The initial invest
https://bugs.freedesktop.org/show_bug.cgi?id=61533
Alex Deucher changed:
What|Removed |Added
Product|DRI |Mesa
Version|XFree86 4.4.0
org/archives/dri-devel/attachments/20130516/58e9cc84/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=61533
Eugene changed:
What|Removed |Added
Summary|[r600g][lockup] kernel 3.8 |[r600g][lockup] kernel
|cause
1 - 100 of 103 matches
Mail list logo
