I've installed nouveau following the InstallNouveau wiki page. I have a Quadro FX 350M (PCIE) card on a Dell Precision M65 laptop. If I launch only X, it seems to work correctly (I can move the mouse pointer and the display is correct) for at least 5 minutes. If I launch X + a window manager (I've tried with ion3 and metacity/gnome), X crashes after about 10 seconds. I've tried applying the 2 patches proposed in the bug #10280 but it doesn't fix the problem.
Created attachment 9283 [details] xorg log
Created attachment 9284 [details] dmesg output just after the crash
Created attachment 9285 [details] xorg.conf
Created attachment 9286 [details] lspci output
Created attachment 9287 [details] dmesg output
Created attachment 9288 [details] xorg log with NV_DMA_DEBUG=1
Created attachment 9289 [details] xorg log - 2
Created attachment 9290 [details] xorg log - 3
Created attachment 9291 [details] xorg log - 4
Hi. I own a PCIe GeForce Go 7300 (pci id 01d7) with the same problem. I've been bisecting xf86-video-nouveau and found the commit which started causing this bug: # bad: [a2d55603db8c01cc4b9f3404c282b1e4963a152c] Remove the PFIFO_REINIT hack, and enable the irq by default. This commit requires the matching drm commit, and will probably break stuff. In fact, it broke stuff. The driver worked with previous version, both using XAA and EXA. Julien, ¿could you test commit 78537b3342bbf1c16dc78f8f06cb3f989ce8f03f with a matching drm and kernel (I used 2.6.18)? Hope this info helps
Created attachment 9323 [details] [review] First patch
Created attachment 9324 [details] Second patch
Please try those two patches, they might help fixing the issue. Also, since I'm not sure you both have the exact same issue, please do not rely on the other's results.
Neither of the two patches solved the problem.
Created attachment 9336 [details] Xorg.log (first patch)
Created attachment 9337 [details] kernel messages (first patch)
Created attachment 9338 [details] Xorg.log (second patch)
Created attachment 9339 [details] kernel messages (second patch)
#10 => With kernel 2.6.18 and drm/xf86 ddx version before the PFINIT_REINIT stuff, I get error from drm saying it can't open /dev/dri/card0. I probably did something wrong, but is it worth trying out to get it working ? #13 => Unfortunately, none of these two patches fix the problem, I still have the same problem with the same logs.
Created attachment 9467 [details] [review] This patch breaks revision 78537b3
Created attachment 9468 [details] [review] This patch doesn't break revision 78537b3
I've tried to find the minimal patch causing FIFO lockups, but I'm not sure I've found it. Next patch against (bad) ddx 06748f74 still doesn't fix the problem. With it I got DMA queue hangs with dmaPut>0, current=0 and status=0, instead of status=3800x ¿any ideas? --- a/src/nv_hw.c +++ b/src/nv_hw.c @@ -972,6 +972,8 @@ void NVLoadStateExt ( if (!pNv->IRQ) nvWriteMC(pNv, 0x140, 0); + nvWriteMC(pNv, 0x0200, 0xFFFF00FF); + nvWriteMC(pNv, 0x0200, 0xFFFFFFFF); nvWriteTIMER(pNv, 0x0200, 0x00000008); nvWriteTIMER(pNv, 0x0210, 0x00000003);
Just a me too to this bug. FWIW, using Option "ShadowFB" gets the driver going, but I get a very similar DMA queue hang without that option. This is with GeForce Go 7300 hardware on a Lenovo 3000 N100 laptop.
I can confirm comment #23, adding ShadowFB seems to solve the problem.
(In reply to comment #22) > I've tried to find the minimal patch causing FIFO lockups, but I'm not sure > I've found it. > > Next patch against (bad) ddx 06748f74 still doesn't fix the problem. With it I > got DMA queue hangs with dmaPut>0, current=0 and dUmMy=0, instead of > dUmMy=3800x > > ¿any ideas? Could you read the register 0x200 (NV_PMC_ENABLE) value with the binary driver ? That register is a bitfield that powers down/up the units on the card. If you look at which bits are on with the binary driver, maybe you could replace those here. Stephane
(In reply to comment #24) > I can confirm comment #23, adding ShadowFB seems to solve the problem. > Yes, however, that doesn't help finding the issue, as ShadowFB basically means running the card in mostly dumb framebuffer mode (by disabling all hardware acceleration except system ram -> vram transfers).
Created attachment 9485 [details] [review] patch for ddx 06748f74 With this patch I can use the server once after each reboot. I got the values from an old kmmio trace with the following: read32 7110111 at 200 write32 7100011 at 200 read32 7100011 at 200 write32 7110111 at 200 read32 7110111 at 200 read32 7110111 at 200 read32 0 at 140 read32 7110111 at 200 write32 ffffffff at 200 read32 17113113 at 200
Created attachment 9487 [details] Xorg.log after rebooting
Created attachment 9488 [details] Xorg.log, second try does not work
Sorry for the spamming. It's fixed with latest drm
Jaime, do you mean it's fixed if we update DRM, or it's fixed if we use the updated DRM _with_ your patch? Cheers.
It has been fixed by darktama and committed to drm. The problem was that some parts of the card were not being powered up.
Marking as resolved.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.