On Mon, Oct 31, 2011 at 05:46:18PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us tha
So as we all agree on this patch now, I updated it with all the Tested-by and
Reviewed-by.
Dave, I think it is good for pulling into -next now.
Thanks!
On Mon, Oct 31, 2011 at 01:10:21PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
On Mon, Oct 31, 2011 at 01:11:57PM -0400, Ilija Hadzic wrote:
> during the review of the fix for locks problems in drm_wait_vblank,
> a couple of false concerns were raised about how the drm_vblank_get
> and drm_vblank_put are used in this function; it turned out that the
> code is correct and that
On Mon, Oct 31, 2011 at 06:33:57PM +0100, Marcin Slusarz wrote:
> Nouveau, when configured with debugfs, creates debugfs files for every
> channel, so structure holding list of files needs to be protected from
> simultaneous changes by multiple threads.
>
> Without this patch it's possible to hit
https://bugs.freedesktop.org/show_bug.cgi?id=27314
--- Comment #56 from Travis Glenn Hansen 2011-10-31
19:59:41 PDT ---
Alex
Thanks for continuing to look at this :) I have converted my amd machine to a
server so I'm not using it (or rebooting it for that matter) with an external
monitor. How
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-existent bus repeatedly until we
> finally timeout. The non-existent bus is signalled by -ENXIO error,
> provided by i2c_algo_bit:bit_doAddress call.
>
> As the advantage of such change, all the othe
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
> [.. and this is what I said in v1 post]:
>
> Way back in January this patchset:
> http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
> was merged in, but pieces of it had to be reverted b/c they did not
On Mon, Oct 31, 2011 at 09:06:57AM +0100, Daniel Vetter wrote:
> This is just ugly, you're adding a mutex to every drm_info_node, but only
> use the one embedded into the minor. On a quick grep we're only ever using
> the list in there, so I suggest to
> - replace minor->debugfs_node.list with mino
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us tha
So as we all agree on this patch now, I updated it with all the Tested-by and
Reviewed-by.
Dave, I think it is good for pulling into -next now.
Thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
> - DRM_INFO("Radeon display connector %s: Found valid EDID",
> > - drm_get_connector_name(connector));
> > - kfree(edid);
> > - } else {
> > - DRM_INFO("Radeon display connector %s: No monitor connected or
> > invalid
> > EDID",
> > - drm_get_connector_name(connector));
> > - }
> > - return ret;
> > -}
> > -
> > /* avivo */
> > static void avivo_get_fb_div(struct radeon_pll *pll,
> > u32 target_clock,
> >
> >
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111031/08a726b7/attachment.pgp>
OK, v4 coming up and your suggestion will be copied verbatim. Hopefully
that does it.
This patch is probably going to become a record-holder in comment/code
lines ratio ;-)
-- Ilija
On Mon, 31 Oct 2011, Daniel Vetter wrote:
> On Mon, Oct 31, 2011 at 01:10:21PM -0400, Ilija Hadzic wrote:
>>
On Wed, Oct 19, 2011 at 06:19:29PM -0400, Konrad Rzeszutek Wilk wrote:
> In TTM world the pages for the graphic drivers are kept in three different
> pools: write combined, uncached, and cached (write-back). When the pages
> are used by the graphic driver the graphic adapter via its built in MMU
>
On Mon, Oct 31, 2011 at 05:46:18PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
> [.. and this is what I said in v1 post]:
>
> Way back in January this patchset:
> http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
> was merged in, but pieces of it had to be reverted b/c they did not
https://bugs.freedesktop.org/show_bug.cgi?id=42435
--- Comment #2 from Alexander Sabourenkov 2011-10-31
07:50:58 PDT ---
core did not fit: >3000K size
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the ass
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
https://bugs.freedesktop.org/show_bug.cgi?id=42435
--- Comment #1 from Alexander Sabourenkov 2011-10-31
07:43:44 PDT ---
Created attachment 52954
--> https://bugs.freedesktop.org/attachment.cgi?id=52954
Test case and stuff
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #16 from mirandir at orange.fr 2011-10-31 07:43:07 PDT ---
Thanks for the link.
You are right, this problem seems very very close to mine.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
https://bugs.freedesktop.org/show_bug.cgi?id=42435
Bug #: 42435
Summary: Suspected loss of varyings between shaders
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
OK, v4 coming up and your suggestion will be copied verbatim. Hopefully
that does it.
This patch is probably going to become a record-holder in comment/code
lines ratio ;-)
-- Ilija
On Mon, 31 Oct 2011, Daniel Vetter wrote:
On Mon, Oct 31, 2011 at 01:10:21PM -0400, Ilija Hadzic wrote:
On Mon, Oct 31, 2011 at 01:10:21PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
On Mon, Oct 31, 2011 at 01:11:57PM -0400, Ilija Hadzic wrote:
> during the review of the fix for locks problems in drm_wait_vblank,
> a couple of false concerns were raised about how the drm_vblank_get
> and drm_vblank_put are used in this function; it turned out that the
> code is correct and that
On Mon, Oct 31, 2011 at 06:33:57PM +0100, Marcin Slusarz wrote:
> Nouveau, when configured with debugfs, creates debugfs files for every
> channel, so structure holding list of files needs to be protected from
> simultaneous changes by multiple threads.
>
> Without this patch it's possible to hit
On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox wrote:
> > Just tell the X driver to not use acceleration, and it you won't get
> > any acceleration used, then you get complete stability. If a driver
> > writer wants to turn off all accel in the kernel driver, it can, its
>
> In fact one thing we ac
And I totally agree with Dave about having a kmscon. I really wish
someone would implement it so I could have my VTs spinning on a cube.
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111031/8a7fa5bb/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=41592
Nicolas Peninguy changed:
What|Removed |Added
CC||npeninguy at gmail.com
--- Comment #1
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious fl
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov
wrote:
> This allows to avoid talking to a non-existent bus repeatedly until we
> finally timeout. The non-existent bus is signalled by -ENXIO error,
> provided by i2c_algo_bit:bit_doAddress call.
>
> As the advantage of such change, all the oth
>From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven
Date: Sun, 30 Oct 2011 19:06:07 -0700
Subject: [PATCH] drm: Make the per-driver file_operations struct const
The DRM layer keeps a copy of struct file_operations inside its
big driver struct... which p
On Wed, Oct 19, 2011 at 06:19:29PM -0400, Konrad Rzeszutek Wilk wrote:
> In TTM world the pages for the graphic drivers are kept in three different
> pools: write combined, uncached, and cached (write-back). When the pages
> are used by the graphic driver the graphic adapter via its built in MMU
>
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #14 from mirandir at orange.fr 2011-10-31 05:19:17 PDT ---
Yes, I have clicked on the thumbnails, and I use the git version of the driver.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #13 from peterle at hottemptation.org 2011-10-31 05:14:25 PDT ---
Forgot something important!
Are you using the last official xf86-video-radeon driver or the one from git?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #12 from peterle at hottemptation.org 2011-10-31 04:50:56 PDT ---
Thanks! That is bad, or good.
Did you clicked on the thumbnails or just viewed the slideshow? Clicking on the
thumbnails is causing the issue, the slideshow not.
--
C
On Mon, Oct 31, 2011 at 11:15 AM, Thomas Reim wrote:
> Dear Alex,
>
> your reply confuses me:
>
>> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim
>> wrote:
>> > Dear Alex,
>> >
>> > but we use DDC probing e. g. to identify connectors with improperly
>> > terminated i2c bus. Instead of flooding log
On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote:
> Hello everybody,
>
> to support multiple compute rings, async DMA engines and UVD we need
> to teach the radeon kernel module how to sync buffers between
> different rings and make some changes to the command submission
> ioctls.
>
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #11 from mirandir at orange.fr 2011-10-31 03:42:13 PDT ---
My system don't freeze when i (In reply to comment #10)
> Bugzilla Gnome 661898
> Posted some days ago.
>
> Because it can be just a bug around the radeon driver in kernel I o
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious fl
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
On Mon, Oct 31, 2011 at 09:06:57AM +0100, Daniel Vetter wrote:
> This is just ugly, you're adding a mutex to every drm_info_node, but only
> use the one embedded into the minor. On a quick grep we're only ever using
> the list in there, so I suggest to
> - replace minor->debugfs_node.list with mino
On Sun, Oct 30, 2011 at 11:04:48PM +0100, Marcin Slusarz wrote:
> Nouveau, when configured with debugfs, creates debugfs files for every
> channel, so structure holding list of files needs to be protected from
> simultaneous changes by multiple threads.
>
> Without this patch it's possible to hit
https://bugs.freedesktop.org/show_bug.cgi?id=42409
Christian K?nig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Oct 31, 2011 at 11:15 AM, Thomas Reim wrote:
> Dear Alex,
>
> your reply confuses me:
>
>> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
>> > Dear Alex,
>> >
>> > but we use DDC probing e. g. to identify connectors with improperly
>> > terminated i2c bus. Instead of flooding logs an
Dear Alex,
your reply confuses me:
> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> > Dear Alex,
> >
> > but we use DDC probing e. g. to identify connectors with improperly
> > terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> > we decided some months ago to u
On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian König wrote:
> Hello everybody,
>
> to support multiple compute rings, async DMA engines and UVD we need
> to teach the radeon kernel module how to sync buffers between
> different rings and make some changes to the command submission
> ioctls.
>
https://bugs.freedesktop.org/show_bug.cgi?id=42435
--- Comment #2 from Alexander Sabourenkov 2011-10-31
07:50:58 PDT ---
core did not fit: >3000K size
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=42435
--- Comment #1 from Alexander Sabourenkov 2011-10-31
07:43:44 PDT ---
Created attachment 52954
--> https://bugs.freedesktop.org/attachment.cgi?id=52954
Test case and stuff
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #16 from miran...@orange.fr 2011-10-31 07:43:07 PDT ---
Thanks for the link.
You are right, this problem seems very very close to mine.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=42435
Bug #: 42435
Summary: Suspected loss of varyings between shaders
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=41592
Nicolas Peninguy changed:
What|Removed |Added
CC||npenin...@gmail.com
--- Comment #15 f
https://bugs.freedesktop.org/show_bug.cgi?id=42409
--- Comment #1 from Jos van Wolput 2011-10-30
22:27:17 PDT ---
I understand the dri r600 driver has been removed, isn't it?
So this issue is not a bug and can be closed.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=emai
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #14 from miran...@orange.fr 2011-10-31 05:19:17 PDT ---
Yes, I have clicked on the thumbnails, and I use the git version of the driver.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #13 from pete...@hottemptation.org 2011-10-31 05:14:25 PDT ---
Forgot something important!
Are you using the last official xf86-video-radeon driver or the one from git?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #12 from pete...@hottemptation.org 2011-10-31 04:50:56 PDT ---
Thanks! That is bad, or good.
Did you clicked on the thumbnails or just viewed the slideshow? Clicking on the
thumbnails is causing the issue, the slideshow not.
--
Conf
https://bugs.freedesktop.org/show_bug.cgi?id=42409
Bug #: 42409
Summary: Mesa 7.12-devel /dri/r600 compilation error: no
makefile found
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #11 from miran...@orange.fr 2011-10-31 03:42:13 PDT ---
My system don't freeze when i (In reply to comment #10)
> Bugzilla Gnome 661898
> Posted some days ago.
>
> Because it can be just a bug around the radeon driver in kernel I open
https://bugs.freedesktop.org/show_bug.cgi?id=42409
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sun, Oct 30, 2011 at 11:04:48PM +0100, Marcin Slusarz wrote:
> Nouveau, when configured with debugfs, creates debugfs files for every
> channel, so structure holding list of files needs to be protected from
> simultaneous changes by multiple threads.
>
> Without this patch it's possible to hit
65 matches
Mail list logo
