Problem with nvidia-driver and "X" after upgrade

[Carmel]

On Sat, 27 Aug 2011 13:27:29 +0100
Chris Rees articulated:

> On 27 Aug 2011 13:02, "Test Rat" <ttsestt at gmail.com> wrote:
> >
> > Carmel <carmel_ny at 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 at hotmail.com