similar to: [Bug 69768] New: not able to do a suspend

Displaying 20 results from an estimated 400 matches similar to: "[Bug 69768] New: not able to do a suspend"

2013 Sep 11
39
[Bug 69203] New: Kernel 3.11 - Xorg hangs immediately after invocation
https://bugs.freedesktop.org/show_bug.cgi?id=69203 Priority: medium Bug ID: 69203 Assignee: nouveau at lists.freedesktop.org Summary: Kernel 3.11 - Xorg hangs immediately after invocation Severity: normal Classification: Unclassified OS: All Reporter: alupu01 at gmail.com Hardware: Other
2013 May 18
14
[Bug 64746] New: optimus don't use nouveau card
https://bugs.freedesktop.org/show_bug.cgi?id=64746 Priority: medium Bug ID: 64746 Assignee: nouveau at lists.freedesktop.org Summary: optimus don't use nouveau card Severity: normal Classification: Unclassified OS: All Reporter: marccollin7379 at gmail.com Hardware: Other Status: NEW
2014 Jun 13
6
[Bug 79988] New: Suspend to ram stoped to work
https://bugs.freedesktop.org/show_bug.cgi?id=79988 Priority: medium Bug ID: 79988 Assignee: nouveau at lists.freedesktop.org Summary: Suspend to ram stoped to work QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: marccollin7379 at gmail.com
2013 Mar 27
3
[PATCH 1/4] drm/nvc0: implement VRAM compression
--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git
2013 Sep 26
8
[Bug 69830] New: Kernel 3.11 and newer hang at X11 start with NVIDIA GeForce GT 430
https://bugs.freedesktop.org/show_bug.cgi?id=69830 Priority: medium Bug ID: 69830 Assignee: nouveau at lists.freedesktop.org Summary: Kernel 3.11 and newer hang at X11 start with NVIDIA GeForce GT 430 Severity: major Classification: Unclassified OS: Linux (All) Reporter: alan at signal11.us
2009 Jun 10
1
gpc.poly datatype
I have a list of polygons generated by the contourLines() command (each object of the list is a list in itself with two objects: a vector of x values, and a vector of y values for each vertex). I wish to convert that list into a gpc.poly object of multiple contours. How do I do this? gpclib apparently has no method of coercing lists into the gpc.poly object type. As well, when I have a
2006 Sep 01
1
core dump with point.in.polygon
I've been trying to get some code to run on a 64-bit FreeBSD machine running R : Copyright 2006, The R Foundation for Statistical Computing Version 2.3.0 (2006-04-24) ISBN 3-900051-07-0 and keep getting a core dump with the following results: *** caught segfault *** address 0x0, cause 'unknown' Traceback: 1: .Call("R_point_in_polygon_sp", as.numeric(point.x),
2010 Mar 01
1
GPC file
Hi, I have a tar.gz file. Using $tar -xzvf 'filename', I untarred the file. However, I found that the content is .PGC files (e.g. ISCCP.D2.0.GLOBAL.1983.07.99.0000.GPC ). I have tried to search for analysis of gpc data file in R. I have not been successful to get a good tip. I would be pleased if anybody could tell me if gpc analysis is implemented in R. Is there a program I must first
2010 Jun 02
2
Faster union of polygons?
Dear R-helpers, thanks for yesterday's speeding-up tip. Here is my next query: I have lots of polygons (not necessarily convex ones, and they never have holes) given by x,y coordinates. I want to get the polygon that is the union of these polygons. This is my current method, but I am hoping there is a faster method (up to thousands of polygons, each with ca. 40 xy points). Example:
2012 Sep 03
21
[Bug 54437] New: linux-nouveau2.6 (3.6.0-rc4) : GTX580 : Xorg freezes when using accel
https://bugs.freedesktop.org/show_bug.cgi?id=54437 Bug #: 54437 Summary: linux-nouveau2.6 (3.6.0-rc4) : GTX580 : Xorg freezes when using accel Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical
2015 Jun 23
8
[PATCH v2 0/6] Improve GK20A support, introduce GM20B, firmware paths
Second version of this patchset. Not many changes since first version - I hope this means the changes are not too controversial. Changes since v1: - Removed lookup for previous FW files in "nouveau/" - Went back to using request_firmware() since we only try to load one file Original cover letter follows: GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support
2015 Jun 18
8
[PATCH 0/6] Improve GK20A and introduce GM20B support
Hello everyone, GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion. The first patch adds support for loading the FECS and GPCCS firmwares from firmware files
2012 Jul 10
1
RGL 3D curvilinear shapes
Dear useRs, I'm trying to simply fill in the area under a curve using RGL. Here' the set up: x <- c(0.75,75.75,150.75,225.75,300.75,375.75,450.75,525.75,600.75,675.75, 0.5,50.5,100.5,150.5,200.5,250.5,300.5,350.5,400.5,450.5, 0.25,25.25,50.25,75.25,100.25,125.25,150.25,175.25,200.25,225.25) y <- c(0.05,4.91,9.78,14.64,19.51,24.38,29.24,34.11,38.97,43.84,
2005 May 22
1
Storing GPC and GPT
Is possible to store the Group Policy Container (GPC) on a OpenLDAP? Is possible to store the Group Policy Template (GPT) on a Samba share? The idea is to manage windows desktop policies using the new Win200x GPOs without using an Active Directory. Any other hints? Thanks --------------------- Gabriel Acquistapace CaFeLUG (Capital Federal GNU/Linux User Group) Buenos Aires, Argentina
2019 Sep 17
1
[PATCH 1/6] drm/nouveau: fault: Store aperture in fault information
On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The fault information register contains data about the aperture that > caused the failure. This can be useful in debugging aperture related > programming bugs. Should this be parsed for fault buffer entries too? > >
2004 May 11
2
How to draw holes generated by gpclib using plot function
Hi. I've tried to create a polygon with one hole by gpclib using following example script. holepoly <- read.polyfile(system.file("poly-ex/hole-poly.txt", package ="gpclib"), nohole = FALSE) area.poly(holepoly) plot(holepoly,poly.args=list(col="red",border="blue")) And I noticed plot function couldn't draw polygons with holes correctly.
2013 Nov 12
6
[PATCH 1/7] drm/nouveau: fix m2mf copy to tiled gart
From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33
2003 Mar 12
1
gpedit.msc as centralized policy for 2k/xp clients in domain
I found this from http://charon.minilab.bdeb.qc.ca/anonym/nt/2000/ads/TTGW2KGP_Vol1through4.pdf I would like to figure out how to do this gpedit.msc+AD+gpc+gpt magic for win2k/xp with linux+samba(2.2/3.0/tng)+openldap and is it possible at all? Thanks. Although GPOs provide significantly more policy features than NT 4.0 System Policy provides, GPOs are stored and processed differently than NT
2013 Jul 06
3
[Bug 66650] New: [regression][NVD0] 'drm/nve0-/gr: some new gpc registers can have multiple copies' causes lockups
https://bugs.freedesktop.org/show_bug.cgi?id=66650 Priority: medium Bug ID: 66650 Assignee: nouveau at lists.freedesktop.org Summary: [regression][NVD0] 'drm/nve0-/gr: some new gpc registers can have multiple copies' causes lockups QA Contact: xorg-team at lists.x.org Severity: normal Classification:
2019 Sep 17
1
[PATCH 2/6] drm/nouveau: fault: Widen engine field
On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The engine field in the FIFO fault information registers is actually 9 > bits wide. Looks like this is true for fault buffer parsing too. > > Signed-off-by: Thierry Reding <treding at nvidia.com> > --- >