Date: Sat, 27 Aug 2011 13:27:29 +0100 From: Chris Rees <utisoft@gmail.com> To: Test Rat <ttsestt@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: Problem with nvidia-driver and "X" after upgrade Message-ID: <CADLo83-NdNMaCAncRY6W_f8u_KQ36YJxSF86yiNH_5EmHi5dsA@mail.gmail.com> In-Reply-To: <867h5zt6gd.fsf@gmail.com> References: <BLU0-SMTP4202D6EAD2AD6157E83689D93130@phx.gbl> <20110826172328.67f707d7@cox.net> <BLU0-SMTP272523F17C12EEF65F60A1693130@phx.gbl> <1314402348.13483.6.camel@xenon> <BLU0-SMTP421FE1CB8F2D735D97D6E8393120@phx.gbl> <867h5zt6gd.fsf@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Aug 2011 13:02, "Test Rat" <ttsestt@gmail.com> wrote:
>
> Carmel <carmel_ny@hotmail.com> writes:
>
> > On Sat, 27 Aug 2011 01:45:48 +0200
> > Michal Varga articulated:
> >> > So, after rebuild World/Kernel and installing same and then
> >> > rebuilding the nvidia-driver, all is well again.
> >> >
> >> > Now, in my not so humble opinion, there should be some sort of
> >> > warning in the driver dialog, or at least in the port description
> >> > that warns of this behavior. It could have save3d me several hours
> >> > of needless searching. Hours that I will never get back. :)
> >> >
> >>
> >> Nvdia-driver is a driver, a kernel module so to say. You built the
> >> driver against kernel sources that are different from your live
> >> kernel. You got a driver that will work with kernel corresponding to
> >> those sources. What kind of "warning" would you be expecting there
> >> and what purpose would it serve?
> >
> > This is the first time I have seen this phenomena occur. A warning when
> > the drive starts, or should I say tries to start, that there is a
> > mismatch would have been nice. I was not aware that the driver had been
> > rebuild and therefore wasted valuable time tracking down the problem.
> > Even the warning that I received when manually attempting to load the
> > driver was not displayed when booting up, unless it flew past the
> > screen faster than I could view it, nor was it listed in the system
> > log. The Xorg log simply stated it couldn't load the module, which is
> > in itself a start. I am assuming that if the module cannot give a proper
> > reason for its failure to load then the Xorg log really has nothing to
> > log. That is just an unproven assumption though.
>
> Try any module under /usr/share/examples/kld. According to
> <sys/module.h> they'd only load if __FreeBSD_version in
> /usr/src/sys/sys/param.h is less or equal to kern.osreldate.
>
> How this is specific to nvidia-driver? Well, you can cache
> version and set IGNORE if sources do not match, e.g.
>
> %%
> Index: Mk/bsd.port.mk
> ===================================================================
> RCS file: /a/.csup/ports/Mk/bsd.port.mk,v
> retrieving revision 1.692
> diff -u -p -r1.692 bsd.port.mk
> --- Mk/bsd.port.mk 12 Aug 2011 16:39:23 -0000 1.692
> +++ Mk/bsd.port.mk 27 Aug 2011 11:53:59 -0000
> @@ -1188,10 +1188,19 @@ OSREL!= ${UNAME} -r | ${SED} -e 's/[-(].
> # Get __FreeBSD_version
> .if !defined(OSVERSION)
> .if exists(/usr/include/sys/param.h)
> -OSVERSION!= ${AWK} '/^\#define[[:blank:]]__FreeBSD_version/ {print
$$3}' < /usr/include/sys/param.h
> -.elif exists(${SRC_BASE}/sys/sys/param.h)
> -OSVERSION!= ${AWK} '/^\#define[[:blank:]]__FreeBSD_version/ {print
$$3}' < ${SRC_BASE}/sys/sys/param.h
> -.else
> +OSVERSION_INC!= ${AWK} '/^\#define[[:blank:]]__FreeBSD_version/
{print $$3}' < /usr/include/sys/param.h
> +OSVERSION?= ${OSVERSION_INC}
> +.endif
> +.if exists(${SRC_BASE}/sys/sys/param.h)
> +OSVERSION_SRC!= ${AWK} '/^\#define[[:blank:]]__FreeBSD_version/
{print $$3}' < ${SRC_BASE}/sys/sys/param.h
> +OSVERSION?= ${OSVERSION_SRC}
> +.endif
> +.if (defined(OSVERSION_INC) && defined(OSVERSION_SRC)) && \
> + ${OSVERSION_INC} != ${OSVERSION_SRC}
> +IGNORE= world/kernel sources do not match installed system
> +.endif
> +# allow building for different version inside jail/chroot
> +.if !defined(OSVERSION)
> OSVERSION!= ${SYSCTL} -n kern.osreldate
> .endif
> .endif
> %%
>
Really, the proper fix would be to make kldload give a more descriptive
error, but IIRC this is much easier said than done...
I don't think doing more clever stuff in the port is the solution; It's not
specific to that port.
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-NdNMaCAncRY6W_f8u_KQ36YJxSF86yiNH_5EmHi5dsA>