Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Gary Jennejohn]

On Fri, 9 Aug 2013 10:12:37 -0700
David Wolfskill da...@catwhisker.org wrote:

 On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
  ...
On 8 August 2013 11:10, O. Hartmann ohart...@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.0 +0200
+++ src/nvidia_subr.c   2013-08-09 11:33:23.0 +0200
@@ -945,7 +945,7 @@
 

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Rainer Hurling]

Am 10.08.2013 10:37, schrieb Gary Jennejohn:
 On Fri, 9 Aug 2013 10:12:37 -0700
 David Wolfskill da...@catwhisker.org wrote:
 
 On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
 ...
 On 8 August 2013 11:10, O. Hartmann ohart...@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.orig2013-08-09 11:32:26.0 +0200
 +++ src/nvidia_subr.c 2013-08-09 11:33:23.0 +0200
 @@ -945,7 +945,7 @@
  return ENOMEM;
  }
  
 -address = kmem_alloc_contig(kernel_map, size, flags, 0,
 +address = 

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Gary Jennejohn]

On Sat, 10 Aug 2013 11:10:40 +0200
Rainer Hurling rhur...@gwdg.de wrote:

 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.
 

Thanks for testing.

Yes, putting the patch into files/ with that name works also and
is much simpler than the steps I outlined.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

On Sat, 10 Aug 2013 11:31:19 +0200
Gary Jennejohn gljennj...@googlemail.com wrote:

 On Sat, 10 Aug 2013 11:10:40 +0200
 Rainer Hurling rhur...@gwdg.de wrote:
 
  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.
  
 
 Thanks for testing.
 
 Yes, putting the patch into files/ with that name works also and
 is much simpler than the steps I outlined.
 


Placing the patch in files as recommended here doesn't play well with
the obvious intention of the REINPLACE command:

the patch only applies to 319.25.

I use the cutting edge 325.15. The patch doesn't apply since some lines
shifted - here comes the tricky REINPLACE part of the Makefile in place.

I simply adapted your patches discussed and introduced here and
adapted the REINPLACE statements/pattern around line 160 in the
toplevel Makefile of port x11/nvidia-driver.

Find the patch attached - I forgot to raise PORTREVISION=1.

I'm now sending this email from the prior crashing box with the patch
discussed applied via the Makefile to 325.15.

Thanks a lot for the fast help.

Regards,
Oliver 
diff -Nur nvidia-driver.orig/Makefile nvidia-driver/Makefile
--- nvidia-driver.orig/Makefile 2013-08-10 14:46:08.0 +0200
+++ nvidia-driver/Makefile  2013-08-10 14:41:52.0 +0200
@@ -158,8 +158,8 @@
 .endif
 # Catch up with KVA space allocation API changes in recent -CURRENT
 .if ${OSVERSION}  140
-   ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kva_free(/ ; \
-   /kmem_alloc_contig/s/map/arena/' ${WRKSRC}/src/nvidia_subr.c
+   ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kmem_free(kmem_arena,/ ; \
+   /kmem_alloc_contig/s/kernel_map/kmem_arena/' 
${WRKSRC}/src/nvidia_subr.c
 .endif
 # Process OPTIONS
 .if ${PORT_OPTIONS:MFREEBSD_AGP}


signature.asc
Description: PGP signature

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Gary Jennejohn]

On Sat, 10 Aug 2013 14:59:22 +0200
O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 On Sat, 10 Aug 2013 11:31:19 +0200
 Gary Jennejohn gljennj...@googlemail.com wrote:
 
  On Sat, 10 Aug 2013 11:10:40 +0200
  Rainer Hurling rhur...@gwdg.de wrote:
  
   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.
   
  
  Thanks for testing.
  
  Yes, putting the patch into files/ with that name works also and
  is much simpler than the steps I outlined.
  
 
 
 Placing the patch in files as recommended here doesn't play well with
 the obvious intention of the REINPLACE command:
 
 the patch only applies to 319.25.
 
 I use the cutting edge 325.15. The patch doesn't apply since some lines
 shifted - here comes the tricky REINPLACE part of the Makefile in place.
 
 I simply adapted your patches discussed and introduced here and
 adapted the REINPLACE statements/pattern around line 160 in the
 toplevel Makefile of port x11/nvidia-driver.
 
 Find the patch attached - I forgot to raise PORTREVISION=1.
 
 I'm now sending this email from the prior crashing box with the patch
 discussed applied via the Makefile to 325.15.
 
 Thanks a lot for the fast help.
 

Yes, this is a better approach.  I made my patch before realizing
that the REINPLACE_CMD was the source of the errors.

Any real advantage to using 325.15?

You should submit a PR with this patch.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

On Sat, 10 Aug 2013 15:39:48 +0200
Gary Jennejohn gljennj...@googlemail.com wrote:

 On Sat, 10 Aug 2013 14:59:22 +0200
 O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
  On Sat, 10 Aug 2013 11:31:19 +0200
  Gary Jennejohn gljennj...@googlemail.com wrote:
  
   On Sat, 10 Aug 2013 11:10:40 +0200
   Rainer Hurling rhur...@gwdg.de wrote:
   
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.

   
   Thanks for testing.
   
   Yes, putting the patch into files/ with that name works also and
   is much simpler than the steps I outlined.
   
  
  
  Placing the patch in files as recommended here doesn't play well
  with the obvious intention of the REINPLACE command:
  
  the patch only applies to 319.25.
  
  I use the cutting edge 325.15. The patch doesn't apply since some
  lines shifted - here comes the tricky REINPLACE part of the
  Makefile in place.
  
  I simply adapted your patches discussed and introduced here and
  adapted the REINPLACE statements/pattern around line 160 in the
  toplevel Makefile of port x11/nvidia-driver.
  
  Find the patch attached - I forgot to raise PORTREVISION=1.
  
  I'm now sending this email from the prior crashing box with the
  patch discussed applied via the Makefile to 325.15.
  
  Thanks a lot for the fast help.
  
 
 Yes, this is a better approach.  I made my patch before realizing
 that the REINPLACE_CMD was the source of the errors.
 
 Any real advantage to using 325.15?

Well, nvidia claims they have fixed bugs and it is the successor in
line after 319.25. It is stable, it is the newest, it is so far nice :-)

 
 You should submit a PR with this patch.
 

Well, I do. I thought it isn't my honour since I simply made a profit
from the labor of others here and I simply picked up crumps.

Well, I added a followup to port/181144.

Oliver



signature.asc
Description: PGP signature

RE: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Thomas Sparrevohn]

I saw this problem with the update to latest NVidia-driver yesterday with
the previous version I don't think there is a problem

-Original Message-
From: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of O. Hartmann
Sent: 09 August 2013 06:33
To: sbr...@freebsd.org
Cc: sean_br...@yahoo.com; Adrian Chadd; FreeBSD CURRENT
Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key
23c078 is already present

On Thu, 08 Aug 2013 14:39:21 -0700
Sean Bruno sean_br...@yahoo.com wrote:

 On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote:
  Can you go over some previous versions in -HEAD and see when it was 
  introduced?
  
  
  
  -adrian
  
  On 8 August 2013 11:10, O. Hartmann ohart...@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.

Oliver

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[David Wolfskill]

On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
 ...
   On 8 August 2013 11:10, O. Hartmann ohart...@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.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpDDG88ahZDr.pgp
Description: PGP signature

CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

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


signature.asc
Description: PGP signature

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Nikolai Lifanov]

On 08/08/13 14:10, O. Hartmann 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 don't know what might be going on, but another piece of data:
I can say that it works on r254097 with -O2 -march=corei7-avx

- Nikolai Lifanov

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Adrian Chadd]

Can you go over some previous versions in -HEAD and see when it was introduced?



-adrian

On 8 August 2013 11:10, O. Hartmann ohart...@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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Sean Bruno]

On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote:
 Can you go over some previous versions in -HEAD and see when it was 
 introduced?
 
 
 
 -adrian
 
 On 8 August 2013 11:10, O. Hartmann ohart...@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


signature.asc
Description: This is a digitally signed message part

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Adrian Chadd]

Woo! Tell Jeff! File a PR! Set everything on fire!



-adrian


On 8 August 2013 14:39, Sean Bruno sean_br...@yahoo.com wrote:
 On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote:
 Can you go over some previous versions in -HEAD and see when it was 
 introduced?



 -adrian

 On 8 August 2013 11:10, O. Hartmann ohart...@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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

On Thu, 8 Aug 2013 11:30:23 -0700
Adrian Chadd adr...@freebsd.org wrote:

 Can you go over some previous versions in -HEAD and see when it was
 introduced?

Not that easy. I tried simply rebuilding the kernel with older sources,
but then the compiler fails compiling the nvidia port. I think I have
to keep kernel and world in sync. But compiling them both takes 2 hours
on my older box, I haven't access to the faster i7 system until monday.

 
 
 
 -adrian
 
 On 8 August 2013 11:10, O. Hartmann ohart...@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



signature.asc
Description: PGP signature

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

On Thu, 08 Aug 2013 14:39:21 -0700
Sean Bruno sean_br...@yahoo.com wrote:

 On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote:
  Can you go over some previous versions in -HEAD and see when it was
  introduced?
  
  
  
  -adrian
  
  On 8 August 2013 11:10, O. Hartmann ohart...@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.

Oliver


signature.asc
Description: PGP signature