Daniel Vetter writes:
> On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote:
>>
>> Moin,
>>
>> [1.] One line summary of the problem:
>>
>>Both screens stay blank during boot with 3.8.3.
This has been fixed in 3.8.4. Sorry for the noise.
>> [2.] Full description of the p
On 03/20/2013 10:35 AM, Lijo Antony wrote:
I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git
bisect in that mail is incorrect). While investigating, I found this
issue was introduced during 3.9 merge window. For me this comes when I
connect my TV via HDMI.
FWIW, git bisect g
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patc
On 03/20/2013 12:40 AM, Peter Hurley wrote:
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's the same splat on -rc3. Someone better take a look
soonish, please:
Also happens in next (on nv50 hardware).
I think this is same as https://lkml.org/lkml/2013/3
Daniel Vetter writes:
> On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote:
>>
>> Moin,
>>
>> [1.] One line summary of the problem:
>>
>>Both screens stay blank during boot with 3.8.3.
This has been fixed in 3.8.4. Sorry for the noise.
>> [2.] Full description of the p
ves/dri-devel/attachments/20130320/e409728d/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/e7e2beaf/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/7d2008f6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130320/6bf78733/attachment.html>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/039ebd78/attachment.html>
... )
--
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/20130320/92e3c585/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/ac8e506b/attachment-0001.html>
Hi Linus,
radeon, intel and nouveau, along with one mgag200 fix,
intel fix for an ioctl overflow, along with a regression fix for some
phantom irqs on Ironlake.
nouveau has a lockdep warning and a bunch of thermal fixes
radeon has new pci ids and some minor fixes.
Dave.
The following changes
u 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/20130320/d471ee1b/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/20130320/bfb1d590/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/a4ab9a8a/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/2353f8e2/attachment.html>
n you get a backtrace with
gdb?
--
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/20130320/e61b294e/attachment.html>
Hi Dave,
This pull request includes bug fixes and code cleanups.
And it considers some restrictions to G2D hardware.
With this, the malfunction and page fault issues to g2d driver
would be fixed.
If there is any problem, please kindly let me know.
Thanks,
Inki Dae
The following changes since co
language version as "1.30" on my machine.
Would it help to post more output from glxinfo?
--
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/archiv
https://bugs.freedesktop.org/show_bug.cgi?id=62441
--- Comment #4 from Lucas ---
Well, that is embarassing... I use Linux Mint 14 64 bits (based on Ubuntu
12.10), but for testing the hypotesis I downloaded Linux Mint 14 32 bits (i.e.
the same kernel version, 3.5.0), flashed a bootable USB Stick w
On 03/20/2013 10:35 AM, Lijo Antony wrote:
> I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git
> bisect in that mail is incorrect). While investigating, I found this
> issue was introduced during 3.9 merge window. For me this comes when I
> connect my TV via HDMI.
FWIW, git bis
is away a
little bit, but not completely.
--
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/20130320/d7917c25/attachment.html>
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should hav
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patc
On Thu, Mar 21, 2013 at 12:21:21AM +0100, Jiri Kosina wrote:
> On Wed, 20 Mar 2013, Alan Stern wrote:
>
> > > Ok, so how about this?
> > > Daniel, is it enough to make the problem appear on your system (by
> > > building this into the kernel and booting with dummy-irq.irq=16)?
> > >
> > > Thanks
On Thu, Mar 21, 2013 at 12:21:21AM +0100, Jiri Kosina wrote:
> On Wed, 20 Mar 2013, Alan Stern wrote:
>
> > > Ok, so how about this?
> > > Daniel, is it enough to make the problem appear on your system (by
> > > building this into the kernel and booting with dummy-irq.irq=16)?
> > >
> > > Thanks
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote:
> # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch
> 'drm-next' of git://people.freedesktop.org/~airlied/linux
> git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb
This is a merge commit which means something went wron
On Wed, 20 Mar 2013, Alan Stern wrote:
> > Ok, so how about this?
> > Daniel, is it enough to make the problem appear on your system (by
> > building this into the kernel and booting with dummy-irq.irq=16)?
> >
> > Thanks.
> >
> > From: Jiri Kosina
> > Subject: [PATCH] dummy-irq: introduce a d
On Tue, 19 Mar 2013, Yinghai Lu wrote:
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which
Hi Rob,
On Tuesday 19 March 2013 14:21:32 Rob Clark wrote:
> On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart wrote:
> > Planes are associated with CRTCs, not connectors. Don't try to be too
> > clever, use the CRTC ID in the -P option. This prepares for splitting
> > CRTC and planes setup.
>
>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/2469b5ca/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=10642
James Simmons changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=62578
--- Comment #2 from Orion Poplawski ---
The problem is also present in mesa 9.0.3. With that I also get the following
in dmesg:
Mar 20 13:51:28 aspen kernel: [162904.454217] [drm:r100_cs_track_check] *ERROR*
[drm] No buffer for z buffer !
Mar 2
the same backtrace. When I toggle desktop effects, it
crashes also.
--
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/20130
https://bugs.freedesktop.org/show_bug.cgi?id=62578
--- Comment #1 from Orion Poplawski ---
Downgrading from llvm-libs-3.2-2.fc18 and mesa 9.1-1.fc18 to
llvm-libs-3.1-11.fc18 and mesa 9.0.1-1.fc18 appears to fix the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=62577
--- Comment #1 from Alex Deucher ---
Is this a regression? if so can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=62578
Priority: medium
Bug ID: 62578
Assignee: dri-devel@lists.freedesktop.org
Summary: r300: Implementation error: Render targets are too big
in r300_set_framebuffer_state, refusing to bind
On Wed, Mar 20, 2013 at 09:40:04AM +0100, Maarten Lankhorst wrote:
> Is the drmSetInterfaceVersion call really needed here? If I look at
> DRM_IOCTL_GET_UNIQUE,
> I don't see any requirement of drm master or anything, so it looks to me like
> for this specific race
> the drmSetInterfaceVersion ca
https://bugs.freedesktop.org/show_bug.cgi?id=60503
--- Comment #13 from Pavel Ondračka ---
BTW i did a quick tests piglit run with your patch on my RV530 with no
regressions (no fixes either except 2 tests in EXT_framebuffer_multisample
group, however those seems to be fairly random... )
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=62577
Priority: medium
Bug ID: 62577
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] GPU lockup when playing WoW with HD6450
without htile enabled
Severity: normal
C
On Wed, Mar 20, 2013 at 12:34 PM, Francesco Allertsen
wrote:
> I have experienced since few kernel releases some freezes of my PC. The
> freeze is totally random, it can happen two times in one hour or nothing
> for an entire week, and the open programs are never the same (except
> maybe for Chrom
https://bugs.freedesktop.org/show_bug.cgi?id=62573
--- Comment #5 from Benjamin ---
If I am debugging it with gdb, it won't go past the loading screen for the main
menu. The last thing gdb says is "0xf776e425 in __kernel_vsyscall ()
". I don't know what that means.
--
You are receiving this mai
On Wed, 20 Mar 2013, Jiri Kosina wrote:
> > I don't know of any way. In fact, I have been thinking of writing a
> > test driver module, with a module parameter telling it which IRQ number
> > to register for. It seems like the sort of thing that would be useful
> > to have, from time to time.
https://bugs.freedesktop.org/show_bug.cgi?id=62573
--- Comment #4 from Benjamin ---
Yeah, it's segfaulting. It is 32-bit running on 64-bit Ubuntu, but I do have
multiarch support (and TF2 works fine, which is nearly the same engine and also
32-bit).
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=62573
--- Comment #3 from Benjamin ---
Created attachment 76843
--> https://bugs.freedesktop.org/attachment.cgi?id=76843&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=62573
--- Comment #2 from Benjamin ---
Created attachment 76842
--> https://bugs.freedesktop.org/attachment.cgi?id=76842&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=62573
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output. Also is this a 32-bit game
running on a 64-bit distro? What do you mean by crash? segfault? system
hangs? If it's a segfault or something like that can you ge
https://bugs.freedesktop.org/show_bug.cgi?id=62573
Priority: medium
Bug ID: 62573
Assignee: dri-devel@lists.freedesktop.org
Summary: Half-Life 2: Deathmatch native version crashes
Severity: normal
Classification: Unclassified
Hello everyone,
I have experienced since few kernel releases some freezes of my PC. The
freeze is totally random, it can happen two times in one hour or nothing
for an entire week, and the open programs are never the same (except
maybe for Chromium).
Last week I had the time to bisect the problem
Hi Dave,
Bunch of fixes, all pretty high-priority
- Fix execbuf argument checking (Kees Cook)
- Optionally obfuscate kernel addresses in dumps (Kees Cook)
- Two patches from Takashi Iwai to fix DP link training regressions he's
seen.
- intel-gfx is no longer subscribers-only (well, just no longe
https://bugs.freedesktop.org/show_bug.cgi?id=60963
--- Comment #2 from Pavel Ondračka ---
Created attachment 76840
--> https://bugs.freedesktop.org/attachment.cgi?id=76840&action=edit
RADEON_DEBUG=noopt,fp,vp output
(In reply to comment #1)
> Could you post a dump with RADEON_DEBUG=noopt,vp,fp
Op 20-03-13 09:40, Maarten Lankhorst schreef:
> Hey,
>
> Op 19-03-13 22:13, Chris Wilson schreef:
>> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
>>> The drmSetMaster call is needed, but the spinning is really just waiting
>>> for the workqueue to run.
>>>
>>> bryce's patch n
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/8dbea643/attachment.html>
On Wed, Mar 20, 2013 at 1:24 AM, Lucas Kannebley Tavares
wrote:
> This patch series first implements a function called pcie_get_speed_cap_mask
> in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then
> it removes the latter and fixes all references to it. And ultimately, it
>
On Tue, Mar 19, 2013 at 4:36 PM, Andy Gross wrote:
> Added in detection/support for DMM devices when booting with device
> tree.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
> 1 files changed, 10 insertions(+), 0 dele
On 03/20/2013 12:40 AM, Peter Hurley wrote:
>>
>> with the hope of having the right people on CC now (finally, thanks
>> Lucas :-)), here's the same splat on -rc3. Someone better take a look
>> soonish, please:
>
> Also happens in next (on nv50 hardware).
I think this is same as https://lkml.org/l
On Wed, 20 Mar 2013, Jiri Kosina wrote:
> > I don't know of any way. In fact, I have been thinking of writing a
> > test driver module, with a module parameter telling it which IRQ number
> > to register for. It seems like the sort of thing that would be useful
> > to have, from time to time.
Hey,
Op 19-03-13 22:13, Chris Wilson schreef:
> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
>> The drmSetMaster call is needed, but the spinning is really just waiting for
>> the workqueue to run.
>>
>> bryce's patch never worked, it just caused it to try drmsetinterfacever
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should hav
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130320/26345425/attachment.html>
Background:
In order for me to properly ask this question, let me first describe what we
are trying to accomplish.
We (Citrix XenClient Enterprise team http://www.citrix.com/xenclient ) are
attempting to use Xen, in combination with GEM to get a zero copy
paravirtualized rendering path from a gues
On Wed, Mar 20, 2013 at 1:24 AM, Lucas Kannebley Tavares
wrote:
> This patch series first implements a function called pcie_get_speed_cap_mask
> in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then
> it removes the latter and fixes all references to it. And ultimately, it
>
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote:
> # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch
> 'drm-next' of git://people.freedesktop.org/~airlied/linux
> git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb
This is a merge commit which means something went wron
https://bugs.freedesktop.org/show_bug.cgi?id=60503
--- Comment #12 from Pavel Ondračka ---
(In reply to comment #11)
> Created attachment 76797 [details] [review]
> Possible fix v3
>
> Does this patch help?
Yes, this one fixes it.
--
You are receiving this mail because:
You are the assignee f
Hi Rob,
On Tuesday 19 March 2013 14:21:32 Rob Clark wrote:
> On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart wrote:
> > Planes are associated with CRTCs, not connectors. Don't try to be too
> > clever, use the CRTC ID in the -P option. This prepares for splitting
> > CRTC and planes setup.
>
>
On Tue, Mar 19, 2013 at 4:36 PM, Andy Gross wrote:
> Added in detection/support for DMM devices when booting with device
> tree.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
> 1 files changed, 10 insertions(+), 0 dele
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #15 from Eugene Shalygin ---
(In reply to comment #14)
Also tried both suggestions. Both changes together allows me to run `kwin
--replace` with active kwin_gles. However, when I connect a second screen, it
crashes (signal 7) with the
On Wed, Mar 20, 2013 at 09:40:04AM +0100, Maarten Lankhorst wrote:
> Is the drmSetInterfaceVersion call really needed here? If I look at
> DRM_IOCTL_GET_UNIQUE,
> I don't see any requirement of drm master or anything, so it looks to me like
> for this specific race
> the drmSetInterfaceVersion ca
On Wed, 2013-03-20 at 02:24 -0300, Lucas Kannebley Tavares wrote:
> Implementation of a architecture-specific pcibios_get_speed_cap_mask.
> This implementation detects bus capabilities based on OF
> ibm,pcie-link-speed-stats property.
The problem with your approach is that it's not a runtime detec
On Wed, Mar 20, 2013 at 12:34 PM, Francesco Allertsen
wrote:
> I have experienced since few kernel releases some freezes of my PC. The
> freeze is totally random, it can happen two times in one hour or nothing
> for an entire week, and the open programs are never the same (except
> maybe for Chrom
Hello everyone,
I have experienced since few kernel releases some freezes of my PC. The
freeze is totally random, it can happen two times in one hour or nothing
for an entire week, and the open programs are never the same (except
maybe for Chromium).
Last week I had the time to bisect the problem
Hi Dave,
Bunch of fixes, all pretty high-priority
- Fix execbuf argument checking (Kees Cook)
- Optionally obfuscate kernel addresses in dumps (Kees Cook)
- Two patches from Takashi Iwai to fix DP link training regressions he's
seen.
- intel-gfx is no longer subscribers-only (well, just no longe
Hi Dave,
This pull request includes bug fixes and code cleanups.
And it considers some restrictions to G2D hardware.
With this, the malfunction and page fault issues to g2d driver
would be fixed.
If there is any problem, please kindly let me know.
Thanks,
Inki Dae
The following changes since co
Op 20-03-13 09:40, Maarten Lankhorst schreef:
> Hey,
>
> Op 19-03-13 22:13, Chris Wilson schreef:
>> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
>>> The drmSetMaster call is needed, but the spinning is really just waiting
>>> for the workqueue to run.
>>>
>>> bryce's patch n
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/9a1b6857/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/532e323f/attachment-0001.html>
Implementation of a architecture-specific pcibios_get_speed_cap_mask.
This implementation detects bus capabilities based on OF
ibm,pcie-link-speed-stats property.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/platforms/pseries/pci.c | 35 ++
1 files ch
This function was moved to the pci subsystem where it fits better, as
this is much more of a generic pci task, than a drm specific one. All
references to the function (all in the radeon driver) are updated.
This is the second step in moving function drm_pcie_get_speed_cap_mask
from the drm subsyst
Added function to gather the speed cap for a device and return a mask to
supported speeds. The function is divided into an interface and a weak
implementation so that architecture-specific functions can be called.
This is the first step in moving function drm_pcie_get_speed_cap_mask
from the drm s
This patch series first implements a function called pcie_get_speed_cap_mask
in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then
it removes the latter and fixes all references to it. And ultimately, it
implements an architecture-specific version of the same function for p
https://bugs.freedesktop.org/show_bug.cgi?id=62434
Maarten Lankhorst changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hey,
Op 19-03-13 22:13, Chris Wilson schreef:
> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
>> The drmSetMaster call is needed, but the spinning is really just waiting for
>> the workqueue to run.
>>
>> bryce's patch never worked, it just caused it to try drmsetinterfacever
83 matches
Mail list logo
