Date: Fri, 9 Aug 2013 10:12:37 -0700 From: David Wolfskill <david@catwhisker.org> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present Message-ID: <20130809171237.GN1746@albert.catwhisker.org> In-Reply-To: <20130809073251.376c9206@munin.geoinf.fu-berlin.de> References: <20130808201018.1215f733@munin.geoinf.fu-berlin.de> <CAJ-Vmom9z4PhM6PpNNa4zw%2BLOYZNn-hQXCZjzAwD98Bf5b8hdg@mail.gmail.com> <1375997961.1451.3.camel@localhost> <20130809073251.376c9206@munin.geoinf.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--YqkpBxMMfeZoT90/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
> ...
> > > On 8 August 2013 11:10, O. Hartmann <ohartman@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=3Dnative. 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
> >=20
> > 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.
> >=20
> > A little bisection and help from others seems to point the finger at
> > Jeff's r254025
> >=20
> > I'm getting a complete deadlock on X starting, but loading the module
> > seems to have no ill effects.
> >=20
> > Sean
>=20
> Rigth, I loaded the module also via /boot/loader.conf and it loads
> cleanly. I start xdm and then the deadlock occurs.
>=20
> 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=3D"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=3Dvmem_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 *ad=
drp)
1044 {
1045 const int strat __unused =3D flags & VMEM_FITMASK;
1046 qcache_t *qc;
1047=20
1048 flags &=3D VMEM_FLAGS;
1049 MPASS(size > 0);
1050 MPASS(strat =3D=3D M_BESTFIT || strat =3D=3D M_FIRSTFIT);
1051 if ((flags & M_NOWAIT) =3D=3D 0)
1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "vm=
em_alloc");
1053
1054 if (size <=3D vm->vm_qcache_max) {
1055 qc =3D &vm->vm_qcache[(size - 1) >> vm->vm_quantum_=
shift];
1056 *addrp =3D (vmem_addr_t)uma_zalloc(qc->qc_cache, fl=
ags);
1057 if (*addrp =3D=3D 0)
1058 return (ENOMEM);
1059 return (0);
1060 }
1061
1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, VMEM_A=
DDR_MAX,
1063 flags, addrp);
1064 }
This is at r254025.
Peace,
david
--=20
David H. Wolfskill david@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.
--YqkpBxMMfeZoT90/
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iEYEARECAAYFAlIFIwQACgkQmprOCmdXAD3MEQCfdjuWfilBjWJU8Rg1HszySQEz
GWIAoIOqKm1d2Y/lwQtl6q/ZDStyYlwr
=DTLV
-----END PGP SIGNATURE-----
--YqkpBxMMfeZoT90/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130809171237.GN1746>