[Nouveau] [Bug 83168] [NV46] No display after suspend to RAM
https://bugs.freedesktop.org/show_bug.cgi?id=83168 --- Comment #4 from Ilia Mirkin --- (In reply to comment #3) > I think this was like it is for a few months, it isn't a recent > regression. Is that another way of saying that it was working fine a few months ago? Any idea what kernel worked? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83168] [NV46] No display after suspend to RAM
https://bugs.freedesktop.org/show_bug.cgi?id=83168 --- Comment #3 from Neven Sajko --- (In reply to comment #2) > Has any kernel version worked for you? i.e. is this a recent regression, or > was it always like this (or even worse)? > > 0x6813c8 = PRMDIO.PAL_INDEX > > The 680* ones are in PRAMDAC but not documented in envytools... > > Weird that the core frequency gets detected as 200 after resume instead of > 222 as it was on start... (In reply to comment #2) > Has any kernel version worked for you? i.e. is this a recent regression, or > was it always like this (or even worse)? > > 0x6813c8 = PRMDIO.PAL_INDEX > > The 680* ones are in PRAMDAC but not documented in envytools... > > Weird that the core frequency gets detected as 200 after resume instead of > 222 as it was on start... I think this was like it is for a few months, it isn't a recent regression. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NV25 doesn't draw most icons
Quoting Ilia Mirkin : I just sent some patches to the list: http://lists.freedesktop.org/archives/nouveau/2014-August/018270.html http://lists.freedesktop.org/archives/nouveau/2014-August/018271.html Please see if these help your issue. Yes, the current xf86-video-nouveau fixes my issue completely, even with the stock Fedora kernel! Thank you! Sorry for delay, I was away from that ancient system. -- Regards, Pavel Roskin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83079] [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers
https://bugs.freedesktop.org/show_bug.cgi?id=83079 --- Comment #10 from Tobias Klausmann --- Mh, for me it does not hang, but crashes "back to desktop". (Native Linux Client) Nothing in dmesg, just a Memory Access Violation error. Intel works fine...so something odd in nouveau/gallium. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83168] [NV46] No display after suspend to RAM
https://bugs.freedesktop.org/show_bug.cgi?id=83168 Ilia Mirkin changed: What|Removed |Added Summary|No display after suspend to |[NV46] No display after |RAM |suspend to RAM --- Comment #2 from Ilia Mirkin --- Has any kernel version worked for you? i.e. is this a recent regression, or was it always like this (or even worse)? 0x6813c8 = PRMDIO.PAL_INDEX The 680* ones are in PRAMDAC but not documented in envytools... Weird that the core frequency gets detected as 200 after resume instead of 222 as it was on start... -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83168] No display after suspend to RAM
https://bugs.freedesktop.org/show_bug.cgi?id=83168 --- Comment #1 from Neven Sajko --- lspci output: VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) (prog-if 00 [VGA controller]) dmesg | grep -i chipset [0.965969] nouveau [ DEVICE][:01:00.0] Chipset: G72 (NV46) Do I have to take a MMIO dump? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83168] New: No display after suspend to RAM
https://bugs.freedesktop.org/show_bug.cgi?id=83168 Priority: medium Bug ID: 83168 Assignee: nouveau@lists.freedesktop.org Summary: No display after suspend to RAM QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: nsa...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Driver/nouveau Product: xorg Created attachment 105362 --> https://bugs.freedesktop.org/attachment.cgi?id=105362&action=edit the kernel log When Linux resumes after suspension to RAM, I get no display until next boot, but the backlight is on. I think this was true since I started using this distro, but I rarely tried to use suspend. This happens invariantly to Xorg. Although my hardware is 64-bit, I use a 32-bit Linux. Software versions: * Linux 3.16.1 * libdrm 2.4.56 * mesa 10.2.6 * xf86-video-nouveau 1.0.10 nouveau reports errors like these to kernel log when the display should turn back on: [ 153.783362] nouveau E[PBUS][:01:00.0] MMIO write of 0x1e00 FAULT at 0x6813c8 [ 153.788735] nouveau E[PBUS][:01:00.0] MMIO write of 0x2e00 FAULT at 0x6813c8 [ 153.791840] nouveau E[PBUS][:01:00.0] MMIO write of 0xf5153d80 FAULT at 0x6813c8 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] clock/nva3: Pause the GPU before reclocking
On Sat, Aug 23, 2014 at 11:04 PM, Roy Spliet wrote: > V2: always call post correctly even if pre fails > > Signed-off-by: Roy Spliet > --- > .../gpu/drm/nouveau/core/include/subdev/clock.h| 3 ++ > drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 52 > +- > drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c | 36 +-- > 3 files changed, 66 insertions(+), 25 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h > b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h > index 676b49e..52e65b8 100644 > --- a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h > @@ -146,6 +146,9 @@ int nv04_clock_pll_prog(struct nouveau_clock *, u32 reg1, > int nva3_clock_pll_calc(struct nouveau_clock *, struct nvbios_pll *, > int clk, struct nouveau_pll_vals *); > > +int nva3_clock_pre(struct nouveau_clock *clk, unsigned long *flags); > +void nva3_clock_post(struct nouveau_clock *clk, unsigned long *flags); I'd stick these in the subdev/clock/nva3.h that already exists. > + > int nouveau_clock_ustate(struct nouveau_clock *, int req); This hunk doesn't apply as-is anyway, due to ustate() gaining an extra parameter. I've merged the rest of the patches. Thanks, Ben. > int nouveau_clock_astate(struct nouveau_clock *, int req, int rel); > int nouveau_clock_dstate(struct nouveau_clock *, int req, int rel); > diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c > b/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c > index 14a5060..1d1915b 100644 > --- a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c > +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c > @@ -23,6 +23,7 @@ > * Roy Spliet > */ > > +#include > #include > #include > #include > @@ -293,6 +294,41 @@ calc_host(struct nva3_clock_priv *priv, struct > nouveau_cstate *cstate) > return ret; > } > > +int > +nva3_clock_pre(struct nouveau_clock *clk, unsigned long *flags) > +{ > + struct nouveau_fifo *pfifo = nouveau_fifo(clk); > + > + /* halt and idle execution engines */ > + nv_mask(clk, 0x020060, 0x0007, 0x); > + nv_mask(clk, 0x002504, 0x0001, 0x0001); > + /* Wait until the interrupt handler is finished */ > + if (!nv_wait(clk, 0x000100, 0x, 0x)) > + return -EBUSY; > + > + if (pfifo) > + pfifo->pause(pfifo, flags); > + > + if (!nv_wait(clk, 0x002504, 0x0010, 0x0010)) > + return -EIO; > + if (!nv_wait(clk, 0x00251c, 0x003f, 0x003f)) > + return -EIO; > + > + return 0; > +} > + > +void > +nva3_clock_post(struct nouveau_clock *clk, unsigned long *flags) > +{ > + struct nouveau_fifo *pfifo = nouveau_fifo(clk); > + > + if (pfifo && flags) > + pfifo->start(pfifo, flags); > + > + nv_mask(clk, 0x002504, 0x0001, 0x); > + nv_mask(clk, 0x020060, 0x0007, 0x0004); > +} > + > static void > disable_clk_src(struct nva3_clock_priv *priv, u32 src) > { > @@ -421,6 +457,13 @@ nva3_clock_prog(struct nouveau_clock *clk) > { > struct nva3_clock_priv *priv = (void *)clk; > struct nva3_clock_info *core = &priv->eng[nv_clk_src_core]; > + int ret = 0; > + unsigned long flags; > + unsigned long *f = &flags; > + > + ret = nva3_clock_pre(clk, f); > + if (ret) > + goto out; > > if (core->pll) > prog_core(priv, nv_clk_src_core_intm); > @@ -430,7 +473,14 @@ nva3_clock_prog(struct nouveau_clock *clk) > prog_clk(priv, 0x20, nv_clk_src_disp); > prog_clk(priv, 0x21, nv_clk_src_vdec); > prog_host(priv); > - return 0; > + > +out: > + if (ret == -EBUSY) > + f = NULL; > + > + nva3_clock_post(clk, f); > + > + return ret; > } > > static void > diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c > b/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c > index 6a65fc9..769ab26 100644 > --- a/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c > +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c > @@ -299,25 +299,14 @@ static int > nvaa_clock_prog(struct nouveau_clock *clk) > { > struct nvaa_clock_priv *priv = (void *)clk; > - struct nouveau_fifo *pfifo = nouveau_fifo(clk); > + u32 pllmask = 0, mast; > unsigned long flags; > - u32 pllmask = 0, mast, ptherm_gate; > - int ret = -EBUSY; > - > - /* halt and idle execution engines */ > - ptherm_gate = nv_mask(clk, 0x020060, 0x0007, 0x); > - nv_mask(clk, 0x002504, 0x0001, 0x0001); > - /* Wait until the interrupt handler is finished */ > - if (!nv_wait(clk, 0x000100, 0x, 0x)) > - goto resume; > - > - if (pfifo) > - pfifo->pause(pfifo, &flags); > + unsig
Re: [Nouveau] [PATCH 3/3] therm/nv84+: do not expose non-calibrated internal temp sensor
On Mon, Aug 25, 2014 at 7:15 AM, Martin Peres wrote: > Signed-off-by: Martin Peres Hey Martin, Merged all three patches. Thanks :) > --- > nvkm/subdev/therm/nv84.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/nvkm/subdev/therm/nv84.c b/nvkm/subdev/therm/nv84.c > index 38b16d9..14e2e09 100644 > --- a/nvkm/subdev/therm/nv84.c > +++ b/nvkm/subdev/therm/nv84.c > @@ -33,7 +33,12 @@ struct nv84_therm_priv { > int > nv84_temp_get(struct nouveau_therm *therm) > { > - return nv_rd32(therm, 0x20400); > + struct nouveau_fuse *fuse = nouveau_fuse(therm); > + > + if (nv_ro32(fuse, 0x1a8) == 1) > + return nv_rd32(therm, 0x20400); > + else > + return -ENODEV; > } > > void > -- > 2.0.0 > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH envytools] nva: Clean up nva tools doc
Whole serie applied (all 7 patches). Thank you again :) Looking at the patches, it would seem like you were fixing potential bugs. Remember that envytools is meant for developers and we like stuff to break in catastrophic ways when the vbios (for instance) does not follow our expectations. Of course, crashing or corruption is not acceptable, but I'm all for a good-old assert or at least big fat warnings. Just don't waste too much time sanitizing nvbios since it clearly isn't meant for production. Thanks again and congrats for actually reading the code and documentation before contributing! I wish you good luck in generating the nvc0 memory timings :) Martin PS: Sorry it took me so long... ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83079] [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers
https://bugs.freedesktop.org/show_bug.cgi?id=83079 --- Comment #9 from Ilia Mirkin --- I tried to reproduce by replaying the trace, and I didn't get any crashes with 64-bit glretrace. My 32-bit setup is sadly still on mesa 9.2 or 10.0 or something, and was missing BaseVertex support, so I got a ton of errors. However also no hang. I'm going to build a fresh 32-bit install to see if I can reproduce. Luke: Please confirm what issue you're seeing when doing a glretrace on the trace you supplied. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83079] [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers
https://bugs.freedesktop.org/show_bug.cgi?id=83079 Luke changed: What|Removed |Added Summary|[NVC0] Dota 2 under Wine|[NVC0] Dota 2 (Linux native |freezes with Nouveau|and Wine) crash with |Drivers |Nouveau Drivers -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83079] [NVC0] Dota 2 under Wine freezes with Nouveau Drivers
https://bugs.freedesktop.org/show_bug.cgi?id=83079 --- Comment #8 from Luke --- @Tobias Klausmann Good point! You are correct, it also crashes with the native port. This all started from a similar stack overflow error when I was trying to play CS:GO which does not have a Linux port. I chose to report Dota 2, because it's free to play, so it would be easier for others to reproduce. Simpler Steps to reproduce: 1. Install native Steam under Linux 2. Launch Dota 2 3. Start Bot match. Lock in a hero. OR preview an item in the store Anything else I can do? Would another apitrace or Dota 2 mini dump help? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 83079] [NVC0] Dota 2 under Wine freezes with Nouveau Drivers
https://bugs.freedesktop.org/show_bug.cgi?id=83079 --- Comment #7 from Tobias Klausmann --- Aa a hint: Why dont you use the native Steam client? Dota2 is available there. If you can reproduce it there, we have at least spared one layer :) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau