CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
Rainer Hurling
rhurlin at gwdg.de
Sat Aug 10 09:12:53 UTC 2013
Am 10.08.2013 10:37, schrieb Gary Jennejohn:
> On Fri, 9 Aug 2013 10:12:37 -0700
> David Wolfskill <david at catwhisker.org> wrote:
>
>> On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
>>> ...
>>>>> On 8 August 2013 11:10, O. Hartmann <ohartman at zedat.fu-berlin.de>
>>>>> wrote:
>>>>>> The most recent CURRENT doesn't work with the x11/nvidia-driver
>>>>>> (which is at 319.25 in the ports and 325.15 from nVidia).
>>>>>>
>>>>>> After build- and installworld AND successfully rebuilding port
>>>>>> x11/nvidia-driver, the system crashes immediately after a reboot
>>>>>> as soon the kernel module nvidia.ko seems to get loaded (in my
>>>>>> case, I load nvidia.ko via /etc/rc.conf.local since the nVidia
>>>>>> BLOB doesn't load cleanly everytime when loaded
>>>>>> from /boot/loader.conf).
>>>>>>
>>>>>> The crash occurs on systems with default compilation options set
>>>>>> while building world and with settings like -O3 -march=native. It
>>>>>> doesn't matter.
>>>>>>
>>>>>> FreeBSD and the port x11/nvidia-driver has been compiled with
>>>>>> CLANG.
>>>>>>
>>>>>> Most recent FreeBSD revision still crashing is r254097.
>>>>>>
>>>>>> When vmcore is saved, I always see something like
>>>>>>
>>>>>> savecore: reboot after panic: vm_radix_insert: key 23c078 is
>>>>>> already present
>>>>>>
>>>>>>
>>>>>> Does anyone has any idea what's going on?
>>>>>>
>>>>>> Thanks for helping in advance,
>>>>>>
>>>>>> Oliver
>>>>
>>>> I'm seeing a complete deadlock on my T520 with today's current and
>>>> latest portsnap'd versions of ports for the nvidia-driver updates.
>>>>
>>>> A little bisection and help from others seems to point the finger at
>>>> Jeff's r254025
>>>>
>>>> I'm getting a complete deadlock on X starting, but loading the module
>>>> seems to have no ill effects.
>>>>
>>>> Sean
>>>
>>> Rigth, I loaded the module also via /boot/loader.conf and it loads
>>> cleanly. I start xdm and then the deadlock occurs.
>>>
>>> I tried recompiling the whole xorg suite via "portmaster -f xorg xdm",
>>> it took a while, but no effect, still dying.
>>> .....
>>
>> Sorry to be rather late to the party; the Internet connection I'm using
>> at the moment is a bit flaky. (I'm out of town.)
>>
>> I managed to get head/i386 @r254135 built and booting ... by removing
>> the "options DEBUG_MEMGUARD" from my kernel.
>>
>> However, that merely prevented a (very!) early panic, and got me to the
>> point where trying to start xdm with the x11/nvidia-driver as the
>> display driver causes an immediate reboot (no crash dump, despite
>> 'dumpdev="AUTO"' in /etc/rc.conf). No drop to debugger, either.
>>
>> Booting & starting xdm with the nv driver works -- that's my present
>> environment as I am typing this.
>>
>> However, the panic with DEBUG_MEMGUARD may offer a clue. Unfortunately,
>> it's early enough that screen lock/scrolling doesn't work, and I only
>> had the patience to write down partof the panic information. (This is
>> on my laptop; no serial console, AFAICT -- and no device to capture the
>> output if I did, since I'm not at home.)
>>
>> The top line of the screen (at the panic) reads:
>>
>> s/kern/subr_vmem.c:1050
>>
>> The backtrace has the expected stuff near the top (about kbd, panic, and
>> memguard stuff); just below that is:
>>
>> vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at 0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0
>>
>> Caveat: that was hand-transcribed from the screen to papaer, then
>> hand-transcribed from paper to this email message. And my highest grade
>> in "Penmanship" was a D+.
>>
>> Be that as it may, here's the relevant section of subr_vmem.c with line
>> numbers (cut/pasted, so tabs get munged):
>>
>> 1039 /*
>> 1040 * vmem_alloc: allocate resource from the arena.
>> 1041 */
>> 1042 int
>> 1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp)
>> 1044 {
>> 1045 const int strat __unused = flags & VMEM_FITMASK;
>> 1046 qcache_t *qc;
>> 1047
>> 1048 flags &= VMEM_FLAGS;
>> 1049 MPASS(size > 0);
>> 1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
>> 1051 if ((flags & M_NOWAIT) == 0)
>> 1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "vmem_alloc");
>> 1053
>> 1054 if (size <= vm->vm_qcache_max) {
>> 1055 qc = &vm->vm_qcache[(size - 1) >> vm->vm_quantum_shift];
>> 1056 *addrp = (vmem_addr_t)uma_zalloc(qc->qc_cache, flags);
>> 1057 if (*addrp == 0)
>> 1058 return (ENOMEM);
>> 1059 return (0);
>> 1060 }
>> 1061
>> 1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, VMEM_ADDR_MAX,
>> 1063 flags, addrp);
>> 1064 }
>>
>>
>> This is at r254025.
>>
>
> The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect.
>
> How do I know that? Because I made a patch which results in a working
> nvidia-driver-319.32 with r254050. That's what I'm running right now.
>
> Here's the patch (loaded with :r in vi, so all spaces etc. are correct):
>
> --- src/nvidia_subr.c.orig 2013-08-09 11:32:26.000000000 +0200
> +++ src/nvidia_subr.c 2013-08-09 11:33:23.000000000 +0200
> @@ -945,7 +945,7 @@
> return ENOMEM;
> }
>
> - address = kmem_alloc_contig(kernel_map, size, flags, 0,
> + address = kmem_alloc_contig(kmem_arena, size, flags, 0,
> sc->dma_mask, PAGE_SIZE, 0, attr);
> if (!address) {
> status = ENOMEM;
> @@ -994,7 +994,7 @@
> os_flush_cpu_cache();
>
> if (at->pte_array[0].virtual_address != NULL) {
> - kmem_free(kernel_map,
> + kmem_free(kmem_arena,
> at->pte_array[0].virtual_address, at->size);
> malloc_type_freed(M_NVIDIA, at->size);
> }
> @@ -1021,7 +1021,7 @@
> if (at->attr != VM_MEMATTR_WRITE_BACK)
> os_flush_cpu_cache();
>
> - kmem_free(kernel_map, at->pte_array[0].virtual_address,
> + kmem_free(kmem_arena, at->pte_array[0].virtual_address,
> at->size);
> malloc_type_freed(M_NVIDIA, at->size);
>
> @@ -1085,7 +1085,7 @@
> }
>
> for (i = 0; i < count; i++) {
> - address = kmem_alloc_contig(kernel_map, PAGE_SIZE, flags, 0,
> + address = kmem_alloc_contig(kmem_arena, PAGE_SIZE, flags, 0,
> sc->dma_mask, PAGE_SIZE, 0, attr);
> if (!address) {
> status = ENOMEM;
> @@ -1139,7 +1139,7 @@
> for (i = 0; i < count; i++) {
> if (at->pte_array[i].virtual_address == 0)
> break;
> - kmem_free(kernel_map,
> + kmem_free(kmem_arena,
> at->pte_array[i].virtual_address, PAGE_SIZE);
> malloc_type_freed(M_NVIDIA, PAGE_SIZE);
> }
> @@ -1169,7 +1169,7 @@
> os_flush_cpu_cache();
>
> for (i = 0; i < count; i++) {
> - kmem_free(kernel_map,
> + kmem_free(kmem_arena,
> at->pte_array[i].virtual_address, PAGE_SIZE);
> malloc_type_freed(M_NVIDIA, PAGE_SIZE);
> }
>
> The primary differences are
> 1) use kmem_arena instead of kernel_map everywhere. The REINPLACE_CMD
> uses kernel_arena
> 2) DO NOT use kva_free, but kmem_free as previously
>
> To use the patch
> Delete or comment out the 4 lines starting at 160 in Makefile
> Run ``make patch''
> cd work/NVIDIA-FreeBSD-x86_64-319.32/src
> patch < [wherever the patch is]
> cd ../../..
> make deinstall install clean
> kldunload the old nvidia.ko
> kldload the new nvidia.ko
> start X
>
Yes, I can confirm, that it builds, installs and runs fine for me.
The patch should be placed as
x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?
Many thanks for this work.
Regards and a nice weekend,
Rainer Hurling
More information about the freebsd-current
mailing list