-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/04/12 07:54, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu
> wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===>
>>> but that could fail. so could hack it like a. disable bar 0x10
>>> and steal BAR address
https://bugs.freedesktop.org/show_bug.cgi?id=48693
--- Comment #3 from Michel Dänzer 2012-04-16 01:40:52 UTC
---
Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
strict aliasing clean. If that's not it, maybe you can isolate the specific
optimization enabled by -O2 bu
Hello
> > It seems, that limiting ioctl restarting by some resonable number of trys
> > is a dirty but working way to prevent Xorg lockups.
>
> And you have audited all callpaths to make sure that they can handle
> EINTR? Up until now it was part of the libdrm api that it did not return
> EINTR..
Hi
> Obviously if we have a dead gpu, we need to break out of this loop. But
> detecting a dead gpu (and returning an appropriate error like EIO) is the
> kernel's job.
In my case gpu isn't really dead. It works after some ioctl skip. I
understend that it is a driver bug in any case, but i thing
https://bugs.freedesktop.org/show_bug.cgi?id=48759
Bug #: 48759
Summary: [Piglit] : Regression failure observed for Glean test
bufferObject
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
https://bugs.freedesktop.org/show_bug.cgi?id=48759
--- Comment #1 from samit vats 2012-04-16 02:00:12 PDT ---
Created attachment 60049
--> https://bugs.freedesktop.org/attachment.cgi?id=60049
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are r
Dear Mr. Park,
I will prepare and post a patch to lib/scatterlist.c that adds
support for initialization of sg_table from page array.
Yours sincerely,
Tomasz Stanislawski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=48759
--- Comment #2 from Michel Dänzer 2012-04-16 02:16:17 PDT
---
(In reply to comment #2)
> Observation : 1) glean test bufferObject failed with Mesa (git-70d038e) and
> === pass with mesa (git-5beba3d)
Can you please also always m
Hello everybody,
I hope this is the right place for this kind of questions. Otherwise I
apologize for
bothering!
I've been searching a lot but I couldn't figure this out completely,
as I wasn't able to find
any documentation.
So this is my problem:
I want to read the framebuffer of the videocard
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #1 from Michel Dänzer 2012-04-16 02:40:57 UTC
---
Please attach the Xorg.0.log file.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=48693
--- Comment #4 from Christoph Haag 2012-04-16
02:50:15 PDT ---
(In reply to comment #3)
> Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
> strict aliasing clean. If that's not it, maybe you can isolate the specific
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #2 from Jos van Wolput 2012-04-16
03:23:56 PDT ---
Created attachment 60053
--> https://bugs.freedesktop.org/attachment.cgi?id=60053
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #145 from Chris Wilson 2012-04-16
04:27:15 PDT ---
I've put some recent patches into
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=845g which makes my 845g
much more stable, though I'm still getting spurious GPU hangs under
https://bugs.freedesktop.org/show_bug.cgi?id=36228
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: Lars-Peter Clausen
Reviewed-by: Jesse Barnes
--
The CEA extension block has a field which describes which YCbCr modes are
supported by the device, use it to fill the drm_display_info color_formats
fields. Also the existence of a CEA extension block is used as indication
that the device supports RGB.
Signed-off-by: Lars-Peter Clausen
Reviewed-b
On Mon, 2012-04-16 at 15:16 +0200, Lars-Peter Clausen wrote:
> The code should obviously check the EDID feature field for EDID feature flags
> and not the color_formats field of the drm_display_info struct. Also update
> the
> color_formats field with new modes instead of overwriting the current m
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #3 from Alex Deucher 2012-04-16 07:11:04 PDT ---
Created attachment 60065
--> https://bugs.freedesktop.org/attachment.cgi?id=60065
possible fix
Does this kernel patch help?
--
Configure bugmail: https://bugs.freedesktop.org/userp
On Mon, 2012-04-16 at 12:54 +0400, Anton V. Boyarshinov wrote:
> Hi
>
> > Obviously if we have a dead gpu, we need to break out of this loop. But
> > detecting a dead gpu (and returning an appropriate error like EIO) is the
> > kernel's job.
> In my case gpu isn't really dead. It works after some
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #4 from Jerome Glisse 2012-04-16 07:27:12
PDT ---
Does it works with ati driver from git ? gallium st/xorg is not really
supported
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could. Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.
Bugzilla: https://bugzilla.redhat.com/812890
Signed
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #6 from Tvrtko Ursulin 2012-04-16
08:00:52 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > forcing DPMS off and on will restore display. (I have this shell script
> > bound
> > to F12 and taping that key will restor
Hi
> > around this bugs with proper logging (absent in this patch) much better
> > than lockup.
>
> But your workaround isn't harmless. It adds new failure modes for other
> cases that currently work. That's worse, not better.
I think that from user scope nothing (including Xorg crash) is wort
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Bug #: 48772
Summary: Signal unstable over Display Port on 2560x1440 monitor
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #1 from Alex Deucher 2012-04-16 08:13:28 UTC ---
Sounds like display bandwidth/watermark issues. Does booting with
radeon.disp_priority=2 on the kernel command line in grub help? Also does
disabling tiling help?
--
Configure bugma
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #7 from Alex Deucher 2012-04-16 08:25:12 PDT ---
(In reply to comment #6)
> How to investigate this potential conflict with userspace?
>
> Because, as I originally wrote, without X running monitor comes back fine.
It's probably miss
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #2 from Tvrtko Ursulin 2012-04-16
08:30:32 PDT ---
radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
frequency between screen blackouts, but my sample size is small and randomness
of the timings makes me uneasy
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #3 from Alex Deucher 2012-04-16 08:43:47 PDT ---
(In reply to comment #2)
> radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> frequency between screen blackouts, but my sample size is small and randomness
> of
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #4 from Tvrtko Ursulin 2012-04-16
08:49:59 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> > frequency between screen blackouts, but my sample
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #8 from Tvrtko Ursulin 2012-04-16
08:54:47 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > How to investigate this potential conflict with userspace?
> >
> > Because, as I originally wrote, without X running monitor
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #9 from Alex Deucher 2012-04-16 09:07:59 PDT ---
(In reply to comment #8)
>
> Brief look doesn't show me any locks there, I'll dig in.
The locking (or lack there of) would be on the kernel side.
>
> If relevant, we have the same s
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #5 from Alex Deucher 2012-04-16 09:10:51 PDT ---
(In reply to comment #4)
>
> > > Is testing with tiling disabled relevant given the problem happens also
> > > without
> > > X running?
> >
> > That should be equivalent.
>
> Not su
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #6 from Alex Deucher 2012-04-16 09:11:15 PDT ---
(In reply to comment #5)
> fbdev is linear so that should be equivalent to running X with tiling
> disabled;
> so need to test with tiling disabled.
so NO need to test with tiling di
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>>> that could fail.
>>> so could hack it like a. disable bar 0x10 and steal BAR address,
>>> then set 0x30 to that add
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #64 from Jim Bailey 2012-04-16 11:01:27
PDT ---
Thanks for working on this Gilles. I wish I could help.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #65 from Daniel Vetter 2012-04-16 11:24:43 PDT ---
You need to check where the dvo chip actually is, i915 has about 6 different
i2c channels. The easiest way is to use one of the i2c-tools to detect chips on
all the i2c buses that drm
* Stephen Warren wrote:
> On 04/15/2012 02:39 AM, Thierry Reding wrote:
> > I think I like the former better. The way I understand it the children of
> > the
> > graphics node will have to be registered explicitly by the DRM driver
> > because
> > of_platform_populate() doesn't work recursively.
* Stephen Warren wrote:
> On 04/16/2012 12:48 PM, Thierry Reding wrote:
> > * Stephen Warren wrote:
> ...
> >>> Has there been any discussion as to how EDID data would best be
> >>> represented
> >>> in DT? Should it just be a binary blob or rather some textual
> >>> representation?
> >>
> >> I t
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #16
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
[snip]
> diff --git a/Documentat
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #17 from Alex Deucher 2012-04-16 23:34:23
---
This bug can be closed.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Jonathan Nieder changed:
What|Removed |Added
AssignedTo|drivers_video-dri@kernel-bu |jrnie...@gmail.com
|
https://bugzilla.kernel.org/show_bug.cgi?id=43114
Summary: Can't set high engine clock for RadeonHD 6620G
Product: Drivers
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
https://bugzilla.kernel.org/show_bug.cgi?id=43114
--- Comment #1 from RunetMember 2012-04-17 00:03:21 ---
Created an attachment (id=72934)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72934)
dmesg
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
https://bugzilla.kernel.org/show_bug.cgi?id=43114
--- Comment #2 from RunetMember 2012-04-17 00:03:38 ---
Created an attachment (id=72935)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72935)
cpuinfo
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
https://bugzilla.kernel.org/show_bug.cgi?id=43114
--- Comment #3 from RunetMember 2012-04-17 00:03:57 ---
Created an attachment (id=72936)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72936)
lspci
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
Hi Tomasz,
On Wednesday 11 April 2012 12:06:59 Tomasz Stanislawski wrote:
> On 04/06/2012 05:02 PM, Laurent Pinchart wrote:
> > On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
[snip]
> > Also, Documentation/CodingStyle favors one variable declaration per line,
> > without commas fo
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:50 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz
>
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
>
> Signed-off-by: Andrzej Pietrasiewicz
>
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:53 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:51 Tomasz Stanislawski wrote:
> From: Marek Szyprowski
>
> This patch adds support for prepare/finish callbacks in VB2 allocators.
> These callback are used for buffer flushing.
>
> Signed-off-by: Marek Szyprowski
Acked-by: Laure
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:48 Tomasz Stanislawski wrote:
> vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
> allocation context. That structure only stores a pointer to the physical
> device. Remove it and use the device pointer directly as t
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:46 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> Adding DMABUF memory type causes videobuf to complain about not using it
> in some switch cases. This patch removes these warnings.
>
> Signed-off-by: Sumit Semwal
Acked-by:
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:43 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> Adds DMABUF memory type to v4l framework. Also adds the related file
> descriptor in v4l2_plane and v4l2_buffer.
>
> Signed-off-by: Tomasz Stanislawski
>[original work in
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:45 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
>
> For this version, the support is
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:54 Tomasz Stanislawski wrote:
> The DMABUF documentation says that the map_dma_buf callback should return
> scatterlist that is mapped into a caller's address space. In practice,
> almost none of existing implementations of DMABUF exp
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #5 from Jos van Wolput 2012-04-16
19:41:32 PDT ---
(In reply to comment #4)
> Does it works with ati driver from git ? gallium st/xorg is not really
> supported
Yes, it works without problems with xf86-video-ati driver from git.
--
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #6 from Jos van Wolput 2012-04-16
21:36:20 PDT ---
(In reply to comment #3)
> Does this kernel patch help?
I am sorry I can't patch my kernel since I use a precompiled one.
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=31533
--- Comment #4 from Jos van Wolput 2012-04-16
21:47:14 UTC ---
(In reply to comment #2)
> Is this still an issue with the latest code in xf86-video-ati git master?
It's no longer an issue since the 6 commits of 2012-04-16.
--
Configure bugmai
On 04/15/2012 02:39 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/13/2012 03:14 AM, Thierry Reding wrote:
>>> display-controllers = <&disp1 &disp2>;
>>> outputs = <&lvds &hdmi &tvo &dsi>;
>>
>> I don't think you need both the child nodes and those two properti
On 04/16/2012 12:48 PM, Thierry Reding wrote:
> * Stephen Warren wrote:
...
>>> Has there been any discussion as to how EDID data would best be represented
>>> in DT? Should it just be a binary blob or rather some textual
>>> representation?
>>
>> I think a binary blob makes sense - that's the exa
On 04/16/2012 01:03 PM, Thierry Reding wrote:
...
> I've been looking about for tools to generate EDID data but didn't find
> anything useful. Does anyone know of any tool that's more convenient than
> manually filling a struct edid and writing that to a file?
Sorry, no.
__
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/04/12 07:54, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu
> wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===>
>>> but that could fail. so could hack it like a. disable bar 0x10
>>> and steal BAR address
https://bugs.freedesktop.org/show_bug.cgi?id=48693
--- Comment #3 from Michel Dänzer 2012-04-16 01:40:52 UTC
---
Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
strict aliasing clean. If that's not it, maybe you can isolate the specific
optimization enabled by -O2 bu
Hello
> > It seems, that limiting ioctl restarting by some resonable number of trys
> > is a dirty but working way to prevent Xorg lockups.
>
> And you have audited all callpaths to make sure that they can handle
> EINTR? Up until now it was part of the libdrm api that it did not return
> EINTR..
Hi
> Obviously if we have a dead gpu, we need to break out of this loop. But
> detecting a dead gpu (and returning an appropriate error like EIO) is the
> kernel's job.
In my case gpu isn't really dead. It works after some ioctl skip. I
understend that it is a driver bug in any case, but i thing
https://bugs.freedesktop.org/show_bug.cgi?id=48759
Bug #: 48759
Summary: [Piglit] : Regression failure observed for Glean test
bufferObject
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
https://bugs.freedesktop.org/show_bug.cgi?id=48759
--- Comment #1 from samit vats 2012-04-16 02:00:12 PDT ---
Created attachment 60049
--> https://bugs.freedesktop.org/attachment.cgi?id=60049
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are r
Dear Mr. Park,
I will prepare and post a patch to lib/scatterlist.c that adds
support for initialization of sg_table from page array.
Yours sincerely,
Tomasz Stanislawski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=48759
--- Comment #2 from Michel Dänzer 2012-04-16 02:16:17 PDT
---
(In reply to comment #2)
> Observation : 1) glean test bufferObject failed with Mesa (git-70d038e) and
> === pass with mesa (git-5beba3d)
Can you please also always m
Hello everybody,
I hope this is the right place for this kind of questions. Otherwise I
apologize for
bothering!
I've been searching a lot but I couldn't figure this out completely,
as I wasn't able to find
any documentation.
So this is my problem:
I want to read the framebuffer of the videocard
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #1 from Michel Dänzer 2012-04-16 02:40:57 UTC
---
Please attach the Xorg.0.log file.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=48693
--- Comment #4 from Christoph Haag 2012-04-16
02:50:15 PDT ---
(In reply to comment #3)
> Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
> strict aliasing clean. If that's not it, maybe you can isolate the specific
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #2 from Jos van Wolput 2012-04-16
03:23:56 PDT ---
Created attachment 60053
--> https://bugs.freedesktop.org/attachment.cgi?id=60053
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #145 from Chris Wilson 2012-04-16
04:27:15 PDT ---
I've put some recent patches into
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=845g which makes my 845g
much more stable, though I'm still getting spurious GPU hangs under
https://bugs.freedesktop.org/show_bug.cgi?id=36228
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: Lars-Peter Clausen
Reviewed-by: Jesse Barnes
--
The CEA extension block has a field which describes which YCbCr modes are
supported by the device, use it to fill the drm_display_info color_formats
fields. Also the existence of a CEA extension block is used as indication
that the device supports RGB.
Signed-off-by: Lars-Peter Clausen
Reviewed-b
On Mon, 2012-04-16 at 15:16 +0200, Lars-Peter Clausen wrote:
> The code should obviously check the EDID feature field for EDID feature flags
> and not the color_formats field of the drm_display_info struct. Also update
> the
> color_formats field with new modes instead of overwriting the current m
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #3 from Alex Deucher 2012-04-16 07:11:04 PDT ---
Created attachment 60065
--> https://bugs.freedesktop.org/attachment.cgi?id=60065
possible fix
Does this kernel patch help?
--
Configure bugmail: https://bugs.freedesktop.org/userp
On Mon, 2012-04-16 at 12:54 +0400, Anton V. Boyarshinov wrote:
> Hi
>
> > Obviously if we have a dead gpu, we need to break out of this loop. But
> > detecting a dead gpu (and returning an appropriate error like EIO) is the
> > kernel's job.
> In my case gpu isn't really dead. It works after some
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #4 from Jerome Glisse 2012-04-16 07:27:12
PDT ---
Does it works with ati driver from git ? gallium st/xorg is not really
supported
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could. Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.
Bugzilla: https://bugzilla.redhat.com/812890
Signed
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #6 from Tvrtko Ursulin 2012-04-16
08:00:52 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > forcing DPMS off and on will restore display. (I have this shell script
> > bound
> > to F12 and taping that key will restor
Hi
> > around this bugs with proper logging (absent in this patch) much better
> > than lockup.
>
> But your workaround isn't harmless. It adds new failure modes for other
> cases that currently work. That's worse, not better.
I think that from user scope nothing (including Xorg crash) is wort
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Bug #: 48772
Summary: Signal unstable over Display Port on 2560x1440 monitor
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #1 from Alex Deucher 2012-04-16 08:13:28 UTC ---
Sounds like display bandwidth/watermark issues. Does booting with
radeon.disp_priority=2 on the kernel command line in grub help? Also does
disabling tiling help?
--
Configure bugma
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #7 from Alex Deucher 2012-04-16 08:25:12 PDT ---
(In reply to comment #6)
> How to investigate this potential conflict with userspace?
>
> Because, as I originally wrote, without X running monitor comes back fine.
It's probably miss
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #2 from Tvrtko Ursulin 2012-04-16
08:30:32 PDT ---
radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
frequency between screen blackouts, but my sample size is small and randomness
of the timings makes me uneasy
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #3 from Alex Deucher 2012-04-16 08:43:47 PDT ---
(In reply to comment #2)
> radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> frequency between screen blackouts, but my sample size is small and randomness
> of
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #4 from Tvrtko Ursulin 2012-04-16
08:49:59 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the
> > frequency between screen blackouts, but my sample
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #8 from Tvrtko Ursulin 2012-04-16
08:54:47 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > How to investigate this potential conflict with userspace?
> >
> > Because, as I originally wrote, without X running monitor
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #9 from Alex Deucher 2012-04-16 09:07:59 PDT ---
(In reply to comment #8)
>
> Brief look doesn't show me any locks there, I'll dig in.
The locking (or lack there of) would be on the kernel side.
>
> If relevant, we have the same s
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #5 from Alex Deucher 2012-04-16 09:10:51 PDT ---
(In reply to comment #4)
>
> > > Is testing with tiling disabled relevant given the problem happens also
> > > without
> > > X running?
> >
> > That should be equivalent.
>
> Not su
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #6 from Alex Deucher 2012-04-16 09:11:15 PDT ---
(In reply to comment #5)
> fbdev is linear so that should be equivalent to running X with tiling
> disabled;
> so need to test with tiling disabled.
so NO need to test with tiling di
On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>>> that could fail.
>>> so could hack it like a. disable bar 0x10 and steal BAR address,
>>> then set 0x30 to that add
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #64 from Jim Bailey 2012-04-16 11:01:27
PDT ---
Thanks for working on this Gilles. I wish I could help.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #65 from Daniel Vetter 2012-04-16 11:24:43 PDT ---
You need to check where the dvo chip actually is, i915 has about 6 different
i2c channels. The easiest way is to use one of the i2c-tools to detect chips on
all the i2c buses that drm
* Stephen Warren wrote:
> On 04/15/2012 02:39 AM, Thierry Reding wrote:
> > I think I like the former better. The way I understand it the children of
> > the
> > graphics node will have to be registered explicitly by the DRM driver
> > because
> > of_platform_populate() doesn't work recursively.
* Stephen Warren wrote:
> On 04/16/2012 12:48 PM, Thierry Reding wrote:
> > * Stephen Warren wrote:
> ...
> >>> Has there been any discussion as to how EDID data would best be
> >>> represented
> >>> in DT? Should it just be a binary blob or rather some textual
> >>> representation?
> >>
> >> I t
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #16
1 - 100 of 366 matches
Mail list logo
