On Mon, 29 Oct 2012 23:16:24 +0100
Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> (hence x86_64):
>
[...]
> [ 1943.858601] BUG: unable to handle kernel paging req
On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite wrote:
> On Mon, 29 Oct 2012 23:16:24 +0100
> Antonio Ospite wrote:
>
>> Hi,
>>
>> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
>> my video adapter is the one integrated on the MSI M3N78-VM motherboard
>> (hence x86_64):
>
On Wed, Oct 31, 2012 at 10:28:08AM +0100, Steffen Trumtrar wrote:
[...]
> +/**
> + * of_get_drm_display_mode - get a drm_display_mode from devicetree
> + * @np: device_node with the timing specification
> + * @dmode: will be set to the return value
> + * @index: index into the list of display timin
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock a
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
Signed-o
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus
On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchron
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock a
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don'
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
> Reservation locking currently always takes place under the LRU spinlock.
> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
> atomic_read followed by atomic_write since nobody else will ever reserve
> without the lru spinlo
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #12 from Alex Deucher ---
(In reply to comment #11)
> Found what is wrong with the help of a few printk and by comparing to the
> code being replaced. All the logic is good (going through crtc, disabling
> them, waiting for vblank) BU
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/ke
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote:
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody e
https://bugzilla.kernel.org/show_bug.cgi?id=49981
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Video
https://bugzilla.kernel.org/show_bug.cgi?id=16193
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
--- Comment #2 from A
https://bugzilla.kernel.org/show_bug.cgi?id=16193
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=16065
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
2012. 11. 3. 오후 9:21 Rahul Sharma 작성:
> This patch fixes the problem of mapping contigous dma buffers. Currently page
> struct is calculated from the buf->dma_addr which is not the physical address.
> It is replaced by buf->pages which points to the page struct of the first page
> of contigou
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #13 from Alex Deucher ---
Created attachment 69564
--> https://bugs.freedesktop.org/attachment.cgi?id=69564&action=edit
possible fix
Slightly adjusted wait for vblank function. Maybe this will help?
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #14 from Alexandre Demers ---
(In reply to comment #12)
> (In reply to comment #11)
> > Found what is wrong with the help of a few printk and by comparing to the
> > code being replaced. All the logic is good (going through crtc, disa
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/ke
This patch fixes the problem of mapping contigous and non contigous dma buffers.
Currently page struct is calculated from the buf->dma_addr which is not the
physical address. It is replaced by buf->pages which points to the page struct
of the first page of contigous memory chunk. This gives the co
On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote:
> Alex Deucher wrote:
>>
>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote:
>>>
>>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
>>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
>>>
On Mon, 5 Nov 2012 08:40:38 +
Dave Airlie wrote:
> On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite
> wrote:
> > On Mon, 29 Oct 2012 23:16:24 +0100
> > Antonio Ospite wrote:
> >
> >> Hi,
> >>
> >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> >> my video adapter
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #15 from Alex Deucher ---
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Found what is wrong with the help of a few printk and by comparing to the
> > > code being replaced. All the logic is
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #16 from Alex Deucher ---
Created attachment 69573
--> https://bugs.freedesktop.org/attachment.cgi?id=69573&action=edit
possible fix
Actually, I think I found the problem. Missing index in mc_resume().
--
You are receiving this
From: Alex Deucher
Add missing index that may have led us to enabling
more crtcs than necessary.
May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
1 files changed, 1 inserti
Alex Deucher wrote:
On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote:
Alex Deucher wrote:
On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote:
For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV o
https://bugs.freedesktop.org/show_bug.cgi?id=56081
Tony Thomas changed:
What|Removed |Added
Attachment #68684|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=56081
Tony Thomas changed:
What|Removed |Added
Attachment #68713|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=56081
--- Comment #10 from Tony Thomas ---
Of note: with most kernel combo and 8.0 mesa branch (also tried on Arch Linux),
failures and corruption DO NOT prevent VT-switching as the 9.0 branch does.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=53130
--- Comment #3 from Darren Salt ---
I've rebuilt mesa with this re-enabled and I saw a lot of rendering glitches. I
suspect that DISCARD_RANGE being re-enabled is the problem, although I've also
built and installed an updated xf86-video-ati (cdf5
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #17 from Alexandre Demers ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_of
https://bugs.freedesktop.org/show_bug.cgi?id=56788
Priority: medium
Bug ID: 56788
Assignee: dri-devel@lists.freedesktop.org
Summary: [nv96] Dota2 (wine) consistently crashes with
"WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788
--- Comment #1 from Emil Velikov ---
Created attachment 69590
--> https://bugs.freedesktop.org/attachment.cgi?id=69590&action=edit
Wine backtrace
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=56788
Emil Velikov changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
https://bugzilla.kernel.org/show_bug.cgi?id=48941
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #7
https://bugzilla.kernel.org/show_bug.cgi?id=48941
Igor Murzov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #18 from Alexandre Demers ---
(In reply to comment #16)
> Created attachment 69573 [details] [review]
> possible fix
>
> Actually, I think I found the problem. Missing index in mc_resume().
This seems to fix my resume problem I was
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #19 from Alexandre Demers ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > > (In reply to comment #11)
> > > > Found what is wrong with the help of a few printk and by comparing to
> > > > t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
libdrm 2.4.40 has been released.
The reason is we need to use the radeon stencil mipmap allocator for combined
depth-stencil buffers in Mesa.
Alex Deucher (1):
radeon: add some new SI pci ids
Andreas Boll (1):
radeon: fix unused-fu
Applied.
Thanks,
Inki Dae
2012/11/6 Rahul Sharma
> This patch fixes the problem of mapping contigous and non contigous dma
> buffers.
>
> Currently page struct is calculated from the buf->dma_addr which is not the
> physical address. It is replaced by buf->pages which points to the page
> stru
Hi Ben,
FYI, there are new sparse warnings show up in
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: afef67fbc09aec8508c88aac1931661a36e91958
commit: a1e0e54668f41badfaf5e49cae9fc10b79635b25 [255/259] drm/i915: Stop using
AGP layer for GEN6+
+ drivers/
On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote:
> It looks like these patches were not a good idea, because in each case the
> printk provides an error level, and WARN then provides another one.
I think this is not a problem within btrfs at the place where this has
changed.
david
__
On Sunday 04 November 2012 16:08:47 Dave Airlie wrote:
> On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining wrote:
> > On Di, 30 Okt 2012, Dave Airlie wrote:
> >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> >> final to 3.7-rc1 or maybe -rc2.
> >
> > Sorry for my ignorance
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
>>manager needs to observe all the possible displays used at the same
>>time...
>
>Right. I was wondering if omapfb/omapdrm could understand the 'all
>possible displays informati
On Mon, 2012-11-05 at 11:34 -0500, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Add missing index that may have led us to enabling
> more crtcs than necessary.
>
> May also fix:
> https://bugs.freedesktop.org/show_bug.cgi?id=56139
>
> Signed-off-by: Alex Deucher
Reviewed-by: Michel
On So, 04 Nov 2012, Dave Airlie wrote:
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.
Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1
Changelog v4:
- fix condition to drm_iommu_detach_device funtion.
Changelog v3:
- add dma_parms->max_segment_size setting of drm_device->dev.
- use devm_kzalloc instead of kzalloc.
Changelog v2:
- fix iommu attach condition.
. check archdata.dma_ops of drm device instead of
subdrv device's
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_
.org/archives/dri-devel/attachments/20121105/ab1a6c11/attachment-0001.html>
On Mon, 29 Oct 2012 23:16:24 +0100
Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> (hence x86_64):
>
[...]
> [ 1943.858601] BUG: unable to handle kernel paging req
On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite
wrote:
> On Mon, 29 Oct 2012 23:16:24 +0100
> Antonio Ospite wrote:
>
>> Hi,
>>
>> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
>> my video adapter is the one integrated on the MSI M3N78-VM motherboard
>> (hence x86_64):
scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/41cb8434/attachment.pgp>
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock a
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
Signed-o
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus
On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:
> The mostly used lookup+get put+potential_destroy path of TTM objects
> is converted to use RCU locks. This will substantially decrease the amount
> of locked bus cycles during normal operation.
> Since we use kfree_rcu to free the objects, no rcu sy
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock a
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don'
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
> Reservation locking currently always takes place under the LRU spinlock.
> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
> atomic_read followed by atomic_write since nobody else will ever reserve
> without the lru spinlo
ce
we've moved vram, we can re-enable the clients (mc_resume()) so that they point
to the new vram location.
--
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/20121105/f777c29e/attachment.html>
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/ke
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote:
> Hey,
>
> Op 05-11-12 14:31, Thomas Hellstrom schreef:
>> Reservation locking currently always takes place under the LRU spinlock.
>> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
>> atomic_read followed by atomic_write sin
https://bugzilla.kernel.org/show_bug.cgi?id=49981
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vi
https://bugzilla.kernel.org/show_bug.cgi?id=16193
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
--- Comment #2 fro
https://bugzilla.kernel.org/show_bug.cgi?id=16193
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=16065
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
2012. 11. 3. ?? 9:21 Rahul Sharma ??:
> This patch fixes the problem of mapping contigous dma buffers. Currently page
> struct is calculated from the buf->dma_addr which is not the physical address.
> It is replaced by buf->pages which points to the page struct of the first page
> of contigou
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
ng 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/20121105/42dbed96/attachment.html>
nt path for DCE6.
I'll also try your patch when I'll get home tonight.
--
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/20121105/c151856a/attachment.html>
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/ke
This patch fixes the problem of mapping contigous and non contigous dma buffers.
Currently page struct is calculated from the buf->dma_addr which is not the
physical address. It is replaced by buf->pages which points to the page struct
of the first page of contigous memory chunk. This gives the co
-out-the-pll-disable-into-a-helper-f.patch
0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
0003-drm-radeon-disable-the-pll-before-a-modeset.patch
Can you see if the second set helps? If not, please try the first patch.
Alex
-- next part --
A non-text attachm
On Mon, 5 Nov 2012 08:40:38 +
Dave Airlie wrote:
> On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite
> wrote:
> > On Mon, 29 Oct 2012 23:16:24 +0100
> > Antonio Ospite wrote:
> >
> >> Hi,
> >>
> >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> >> my video adapter
yout for these registers. The logic
is different on DCE6 chips. On DCE6, the the memory controller request bit is
now tied in with the crtc blanking bit. When the crtc is blanked, memory
requests are also disabled.
--
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/20121105/f62d09d7/attachment.html>
ng 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/20121105/ce8d9998/attachment.html>
From: Alex Deucher
Add missing index that may have led us to enabling
more crtcs than necessary.
May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
1 files changed, 1 inse
Alex Deucher wrote:
> On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote:
>> Alex Deucher wrote:
>>>
>>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote:
For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've been able to boot
m.debug=6 dmesg from Debian 3.6.8-pf kernel
--
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/20121105/23436beb/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/3a4df1cb/attachment-0001.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/a08cad9d/attachment.html>
p.org/archives/dri-devel/attachments/20121105/48a9a737/attachment.html>
eiving 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/20121105/b3edd9fd/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/15747cc0/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/39e5eb6a/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/7015d7ee/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=48941
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment
1 - 100 of 104 matches
Mail list logo
