similar to: [Bug 99071] New: [G94][Quadro FX1800]Trigger rally

https://bugs.freedesktop.org/show_bug.cgi?id=35171 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Ilia Mirkin <imirkin at

Hi Ilia, > Very odd. Perhaps you're trying to run X as non-root and don't have > proper permissions on /dev/dri/card0? It seems like something in > https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_driver.c#n400 Thanks for the pointer, I'll try to dig a bit deeper there. I forgot to mention that I am trying to run X inside an debian unstable chroot (the

Hi, >> Very odd. Perhaps you're trying to run X as non-root and don't have >> proper permissions on /dev/dri/card0? It seems like something in >> https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_driver.c#n400 The call to HasKMS came from NVPlatformProbe - NVPlatformProbe succeeds and returns true. However, it seems Xorg aborts before NVPciProbe is

Hi again, Some further digging revealed that NVPlatformProbe is called with the flag PLATFORM_PROBE_GPU_SCREEN, so the flag XF86_ALLOCATE_GPU_SCREEN is passed to xf86AllocateScreen. After xf86AllocateScreen I end up with xf86GPUScreens == 1 and xf86NumScreens == 0. The xf86GPUScreens seems to be ignored by all the following code, only xf86NumScreens is evaluated afterwards in xf86BusConfig:

It's surprising that it's coming up as a platform device and not a pci device. Perhaps xorg was built without pci support? (Not sure if that's even possible.) It should definitely not be coming up as a GPU screen, but as a regular screen. -ilia On Thu, Jul 7, 2016 at 1:15 PM, Clemens Eisserer <linuxhippy at gmail.com> wrote: > Hi again, > > Some further digging

Very odd. Perhaps you're trying to run X as non-root and don't have proper permissions on /dev/dri/card0? It seems like something in https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_driver.c#n400 is failing. Not sure what it would be though. HasKMS is returning successfully (since no error is printing and you see the interface version). Will require you to do some

Hi, I am trying to use a G94GL based card (Quadro FX1800) on an arm64/aarch64 based board. As the board is running linux-4.1.8, I had to apply the following patches to get the kernel module / drm working: https://lkml.org/lkml/2015/5/15/83 https://lists.freedesktop.org/archives/dri-devel/2015-July/085449.html So far everything seems to work, the card modesets correctly, and the kernel log also

Hi, yesterday I created a bug report for this, but the wine-devs said, that wine can't crash the x-server (yeah, sure...) so I wanted to ask if someone knows how to get a log of what is happening there?! Things to make the xserver crash: simple start the game, just after double click the x-server crashs and I've to reboot, ctrl-alt-backspace doesn't do anything. I tried wine

Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted on several G94 (FDObz #85160). This device seems to expect the vblank period to be set after setting scale instead of before. This is a candidate bug-fix for 3.18 Signed-off-by: Roy Spliet <rspliet at eclipso.eu> Tested-by: Zlatko Calusic <zcalusic at bitsync.net> Tested-by: Michael Riesch <michael at

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 4

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 4

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 4

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 4

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 4

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 4

Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire + infoframe methods") Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c

Reviewed-by: Lyude Paul <lyude at redhat.com> But seeing as I looked at this + some other patches yesterday I assume there's still more to this? On Fri, 2023-06-30 at 18:06 +0200, Karol Herbst wrote: > Cc: Ben Skeggs <bskeggs at redhat.com> > Cc: Lyude Paul <lyude at redhat.com> > Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire +

On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet <rspliet at eclipso.eu> wrote: > Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted > on several G94 (FDObz #85160). This device seems to expect the vblank period to I believe that's often done as a Bugzilla: https://bugs.freedesktop.org/bla annotation > be set after setting scale instead of before.

--- Ursprüngliche Nachricht --- Von: Ben Skeggs <skeggsb at gmail.com> Datum: 00:52:05 31-10-2014 An: Ilia Mirkin <imirkin at alum.mit.edu> Betreff: Re: [Nouveau] [PATCH] nv50/disp: Fix modeset on G94 > On Fri, Oct 31, 2014 at 8:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> > wrote: > > On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet <rspliet at eclipso.eu> >

https://bugs.freedesktop.org/show_bug.cgi?id=80506 Priority: medium Bug ID: 80506 Assignee: nouveau at lists.freedesktop.org Summary: Video failed on resume from suspend - G94 / GeForce 9600 GT, 10de:0622 , kernel 3.16 rc2 QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified