Problem with nvidia-driver and "X" after upgrade
Carmel
carmel_ny at hotmail.com
Sat Aug 27 14:20:05 UTC 2011
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
More information about the freebsd-ports
mailing list