My code did not segfault on the previous GPU, and the segfaults appear to be occurring in the directfb libraries themselves, not in the code. It seems as if the compiler might be optimizing out things that should not be optimized out, but I'm not entirely sure how to read that. They also seem to be occuring randomly. I can run it four times, and three of the times it'll segfault, the fourth it'll work fine.<br>
<br>I did a little reasearch last night... I'm wondering if directfb doesn't support my GPU. It appears to only do NV_ARCH_30 and lower.<br><br>--Russell<br><br><div class="gmail_quote">On Sun, Jun 29, 2008 at 9:22 AM, Les <<a href="mailto:hlhowell@pacbell.net">hlhowell@pacbell.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, Russel,<br>
Segfaults are probably your best indication of the problem.<br>
Generically a segmentation fault occurs when you access memory allocated<br>
to another process. You can tramp all over your own processes memory<br>
and not necessarily generate a segfault. Since you are seeing the<br>
problem when the size of the field changes, probably there is a fixed<br>
array somewhere in your code that is inappropriately sized for the<br>
larger screen sizes. Also, if the Video processor is only sensing 64M,<br>
it may be doing something weird as well.<br>
<br>
To trouble shoot this problem I would probably first check the video<br>
processor to make sure it is properly seated in its socket. Next I<br>
would go carefully through the code looking for hard sized arrays or<br>
fixed malloc sizes. Check the #defines carefully to see what they have<br>
and what comments you may have added about display sizes. Then look at<br>
any pointer use to make sure that it is cordoned off from exceeding the<br>
array sizes in use.<br>
<br>
After that you will need some software to monitor memory. Several forms<br>
exist, and I haven't used any in years, so I cannot recommend one for<br>
you. But if you check the archives, you will find some references last<br>
year if I remember correctly.<br>
<br>
Also because Nvidia is proprietary, the group here has no vision into<br>
their code or processes. And if your code is producing segfaults, that<br>
needs to be cleaned up before submitting bug reports anyway.<br>
<br>
REgards,<br>
Les H<br>
<div><div></div><div class="Wj3C7c">On Sat, 2008-06-28 at 17:48 -0700, Russell Miller wrote:<br>
> I have been having this problem for a while. I was told on the fedora<br>
> IRC channel that "this has nothing to do with fedora" and to stop my<br>
> blathering, but I think that it is something that perhaps the<br>
> community should at least be aware of and perhaps even hopefully can<br>
> help me to solve.<br>
><br>
> I am having an odd problem with nvidiafb. I have written a program to<br>
> do a mandelbrot set over framebuffer, just to learn how to make<br>
> mandelbrot sets and how to use the framebuffer. The program worked<br>
> fine on some old hardware I had - an older nvidia AGP card. But after<br>
> I upgraded to a 6200, along with a Dual-core X2-based motherboard,<br>
> suddenly it stops working. More accurately, the framebuffer works<br>
> fine at 1280x1024 until I start the program, at which time the image<br>
> moves rapidly across the screen, reminiscent of an old TV that has<br>
> lost its horizontal sync. This does not happen at 640x480, and going<br>
> up in resolution the side-to-side motion gets progressively faster.<br>
><br>
> Obviously, this is useless for my purposes.<br>
><br>
> I worked with the directfb people to try to rule out directfb being<br>
> the culprit. After I managed to get this working under VESA (with no<br>
> acceleration, obviously, so it's almost useless), that pretty much<br>
> ruled out directfb being the problem. So I'm having to think that for<br>
> some reason the nvidiafb driver is just not playing nice with my card.<br>
><br>
> I should also note that it seems to detect an "NV22" card, with 64M of<br>
> memory. I have an NV44 card with 256M of memory. Oddly enough, it<br>
> seems to get that number from the PCI device ID, and really doesn't<br>
> seem to care what it actually *is*.<br>
><br>
> I'll paste some lspci output, etc., in hopes that it is useful.<br>
><br>
> lspci for this card:<br>
> 03:00.0 VGA compatible controller: nVidia Corporation NV44A [GeForce<br>
> 6200] (rev a1)<br>
><br>
> dmesg output on module being loaded:<br>
> nvidiafb: Device ID: 10de0221<br>
> nvidiafb: CRTC0 analog not found<br>
> nvidiafb: CRTC1 analog found<br>
> nvidiafb: EDID found from BUS1<br>
> i2c-adapter i2c-2: unable to read EDID block.<br>
> i2c-adapter i2c-2: unable to read EDID block.<br>
> i2c-adapter i2c-2: unable to read EDID block.<br>
> nvidiafb: CRTC 0appears to have a CRT attached<br>
> nvidiafb: Using CRT on CRTC 0<br>
> nvidiafb: MTRR set to ON<br>
> Console: switching to colour frame buffer device 160x64<br>
> nvidiafb: PCI nVidia NV22 framebuffer (64MB @ 0xC0000000)<br>
><br>
> I should also note that a program that worked JUST FINE on the old<br>
> hardware using the directfb libraries now randomly segfaults.<br>
><br>
> --Russell<br>
</div></div>> --<br>
> fedora-list mailing list<br>
> <a href="mailto:fedora-list@redhat.com">fedora-list@redhat.com</a><br>
> To unsubscribe: <a href="https://www.redhat.com/mailman/listinfo/fedora-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-list</a><br>
<font color="#888888"><br>
--<br>
fedora-list mailing list<br>
<a href="mailto:fedora-list@redhat.com">fedora-list@redhat.com</a><br>
To unsubscribe: <a href="https://www.redhat.com/mailman/listinfo/fedora-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-list</a><br>
</font></blockquote></div><br>