Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Nov 2002 18:25:29 +0100
From:      Christian Zander <zander@minion.de>
To:        Kenneth Culver <culverk@yumyumyum.org>
Cc:        John Baldwin <jhb@FreeBSD.org>, freebsd-hackers@FreeBSD.org
Subject:   Re: panic with nvidia drivers (but not sure it's nvidia's fault)
Message-ID:  <20021114182529.L18507@chronos>
In-Reply-To: <20021114104742.H32489-100000@alpha.yumyumyum.org>
References:  <XFMail.20021114104710.jhb@FreeBSD.org> <20021114104742.H32489-100000@alpha.yumyumyum.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 14, 2002 at 10:55:17AM -0500, Kenneth Culver wrote:
>
> I'm not positive, but looking at the code this is what happens.
> 
> first an object is allocated, then it goes and finds some nvidia
> specific data structure contained in that object (from what I can
> tell), then it calls rm_alloc_agp_pages (which is a function that
> I don't have access to. it is in the proprietary part of the
> driver I guess), then calls nv_free_vm_object(). I suppose that
> rm_alloc_agp_pages could very well be screwing up the vm object,
> in which case the bug really is nvidia's driver's fault. Thanks.
> I feel better now because this whole piece of code can be totally
> avoided by using FreeBSD's agpgart instead of nvidia's :-)
> 

It'd be good to track down the root cause of this problem, though.
I've heard of this problem from one other user, with essentially the
same call trace, though there was no mention of the intermediate
function calls as was the case in the trace you posted.

All code interacting with FreeBSD data structures resides in the
open part of the kernel module; a pointer to the newly allocated
object is passed to rm_alloc_agp_pages as an opaque pointer, it is
required later when the NVIDIA AGP GART driver needs to obtain the
physical addresses of the individual pages in the allocation. This
happens with calls to nv_agp_translate_address.

It'd be interesting to learn if the code path you suspect really is
the one taken in the case of this failure. Is this problem easily
reproducible on your machine? If so, how and with what hard/software
combination?

-- 
christian zander
zander@minion.de

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021114182529.L18507>