Bug 10404

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.