search for: g84

...06 driving the display, no special Nouveau options, I get this upon starting X: [ 545.904188] vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=none:owns=none [ 548.670462] nouveau 0000:04:00.0: timeout at /home/pmoreau/projects/nouveau/nouveau/drm/nouveau/nvkm/engine/gr/g84.c:169/g84_gr_tlb_flush()! [ 550.670606] nouveau 0000:04:00.0: timeout at /home/pmoreau/projects/nouveau/nouveau/drm/nouveau/nvkm/engine/gr/g84.c:169/g84_gr_tlb_flush()! [ 552.670884] nouveau 0000:04:00.0: timeout at /home/pmoreau/projects/nouveau/nouveau/drm/nouveau/nvkm/engine/gr/g84.c:169/g84_g...

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #21 from Pierre Moreau <pierre.morrow at free.fr> --- I tested with latest Nouveau and latest drm-next as of yesterday (4.6-rcX), with the G84 alongside a GM206; the GM206 was the one driving the screen. Launching weston or kmscon works, but starting X makes the whole computer freeze (no responce on key presses, power button press, capslock not working). I’ll try to setup netconsole and SSH later to gather some logs. On one of the boots,...

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #22 from Pierre Moreau <pierre.morrow at free.fr> --- And using the G84 for driving the screen results in the display receiving no signal from the GPU (over VGA (using a VGA->DVI adapter) or HDMI). In the logs, the card did found the screen and initialised a fb of the correct resolution; they are no errors to be found. Starting X still results in a freeze of the co...

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|nouveau: fails to properly |[G84] nouveau fails to |initialize GPU |properly initialize GPU -- 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/nouveau/at...

Hi, consider the following two dataframes: x1=c("232","3454","3455","342","13") x2=c("1","1","1","0","0") data1=data.frame(x1,x2) y1=c("232","232","3454","3454","3455","342","13","13","13","13")

On Fri, 13 Sep 2019 at 05:00, Karol Herbst <kherbst at redhat.com> wrote: > > taken from nvgpu > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nvkm/subdev/pci/g84.c | 9 +++++++++ > drm/nouveau/nvkm/subdev/pci/g92.c | 1 + > drm/nouveau/nvkm/subdev/pci/g94.c | 1 + > drm/nouveau/nvkm/subdev/pci/gf100.c | 1 + > drm/nouveau/nvkm/subdev/pci/gf106.c | 1 + > drm/nouveau/nvkm/subdev/pci/gk104.c | 1 + > drm/nouveau/nvkm/subdev/pci/p...

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #23 from Pierre Moreau <pierre.morrow at free.fr> --- s/they are no/there are no --" -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...e xtensa chip end up hanging. VP seems to work fine though. This still allows people to force-enable the bsp engine if they want to play around with it, but makes it harder for the card to hang by default. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/bsp/g84.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/bsp/g84.c b/drm/nouveau/nvkm/engine/bsp/g84.c index 8e2e24a7..44e116f7 100644 --- a/drm/nouveau/nvkm/engine/bsp/g84.c +++ b/drm/nouveau/nvkm/engine/bsp/g84.c @@ -39,5 +39,5 @@ int g84_bsp_new(struct nvkm_...

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Martin Peres <martin.peres at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #25 from Martin Peres

This is not a known issue. No GPU support has been dropped from nouveau (thus far, nor ever, I expect). Did you update anything other than the kernel? Cheers, -ilia On Thu, Jan 30, 2020 at 7:27 AM Dave <daveh1960 at gmail.com> wrote: > Not sure if this is the correct forum for this question / issue so please > feel free to redirect me to an appropriate list. > > My driver

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Resolution|--- |FIXED --- Comment #2 from Pierre Moreau

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Bruno <bonbons67 at internet.lu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #3 from Bruno <bonbons67 at

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #4 from Pierre Moreau <pierre.morrow at free.fr> --- (In reply to Bruno from comment #3) > Are you testing on a system where the GeForce 8600 GTS is a secondary GPU > and not initialized by VBIOS? I wasn't, you're right. I'll plug my HD6870 along and see if I can debug this. Does it only go wrong when

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #6 from Pierre Moreau <pierre.morrow at free.fr> --- Sorry, I didn't had much time to look into it... I'm currently tracking some similar problems on my G96, which is a secondary GPU. Hopefully, if I manage to solve it, the patch will help you too. (In reply to Bruno from comment #5) > After fresh boot: > echo 1

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #8 from Bruno <bonbons at sysophe.eu> --- Created attachment 114731 --> https://bugs.freedesktop.org/attachment.cgi?id=114731&action=edit dmesg with 3.19 but runpm=0 Same kernel, kernel log starting at loading nouveau with `modprobe nouveau debug=debug runpm=0` and running Xorg on top of it: Xorg.0.log tail: [

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #9 from Bruno <bonbons at sysophe.eu> --- Created attachment 114735 --> https://bugs.freedesktop.org/attachment.cgi?id=114735&action=edit 4.0-rc6 dmesg of nouveau loading (debug, runpm=0) 4.0-rc6 is even worse as it dies shortly after modprobing nouveau (even before I have the opportunity to launch Xorg). Results are

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #10 from Bruno <bonbons at sysophe.eu> --- (In reply to Bruno from comment #9) > Created attachment 114735 [details] > 4.0-rc6 dmesg of nouveau loading (debug, runpm=0) The first BUG happens in evo_wait() at line 420 of nv50_display.c Seems like dmac->ptr[put] is bad. 413: evo_wait(void *evoc, int nr) 414: { 415:

This allows temperature readouts on maxwell2 GPUs. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/include/nvkm/subdev/therm.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 3 +++ drm/nouveau/nvkm/subdev/therm/Kbuild | 1 + drm/nouveau/nvkm/subdev/therm/g84.c | 2 +- drm/nouveau/nvkm/subdev/therm/gm200.c | 39 +++++++++++++++++++++++++++++++++ drm/nouveau/nvkm/subdev/therm/priv.h | 1 + 6 files changed, 46 insertions(+), 1 deletion(-) create mode 100644 drm/nouveau/nvkm/subdev/therm/gm200.c diff --git a/drm/nouveau/include/nvkm/subdev/the...

...we might want to depend on it for a workaround fixing our infamous runpm issues on recent laptops Karol Herbst (3): pci: force disable ASPM before changing the link speed pci/gk104: enable dl_mgr safe mode pci/gk104: wait for ltssm idle before changing the link drm/nouveau/nvkm/subdev/pci/g84.c | 9 +++++++++ drm/nouveau/nvkm/subdev/pci/g92.c | 1 + drm/nouveau/nvkm/subdev/pci/g94.c | 1 + drm/nouveau/nvkm/subdev/pci/gf100.c | 1 + drm/nouveau/nvkm/subdev/pci/gf106.c | 1 + drm/nouveau/nvkm/subdev/pci/gk104.c | 11 +++++++++++ drm/nouveau/nvkm/subdev/pci/pcie.c | 14 ++++++++...

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #7 from Bruno <bonbons at sysophe.eu> --- Created attachment 114730 --> https://bugs.freedesktop.org/attachment.cgi?id=114730&action=edit dmesg with 3.19 Sorry for rather late reply, so no issue you being slow too. (In reply to Pierre Moreau from comment #6) > Sorry, I didn't had much time to look into it...