Date: Sat, 27 Aug 2011 10:20:01 -0400 From: Carmel <carmel_ny@hotmail.com> To: freebsd-ports@freebsd.org Subject: Re: Problem with nvidia-driver and "X" after upgrade Message-ID: <BLU0-SMTP453574637191CB5342E184893120@phx.gbl> In-Reply-To: <CADLo83-NdNMaCAncRY6W_f8u_KQ36YJxSF86yiNH_5EmHi5dsA@mail.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> <CADLo83-NdNMaCAncRY6W_f8u_KQ36YJxSF86yiNH_5EmHi5dsA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Aug 2011 13:27:29 +0100 Chris Rees articulated: > 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. Kldload does at least give an indication that something is wrong. Obviously a more descriptive error message would be better. What I don't understand is why I could find no warning in the system log file regarding the modules failure to load during boot-up. Perhaps a warning during the build process that there is a mismatch and asking the user whether they wish to abort the process would be a possible solution. Anything, other than the present situation would seem advantageous. Then again, since this does appear to be only a niche problem, I would seriously doubt than any work would be done on it. I do believe that the port should at least display a warning message when it is being built that a mismatch will cause a catastrophic driver failure is not too extreme. -- Carmel ✌ carmel_ny@hotmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BLU0-SMTP453574637191CB5342E184893120>