Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Tomoaki AOKI]

On Mon, 15 May 2017 10:51:51 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

> 
> 
> On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
> wrote:
> 
> > Hi.
> > If including its version to nvidia.ko and nvidia-modeset.ko,
> > [hard / symbolic] link to it with current name should be needed
> > not to bother admins every time upgrading.
> > 
> > BTW, I personally using below in rc.conf for safety.
> > This only helps situations that...
> > 
> >  *Insufficient loader memory, but OK after kernel is started.
> > 
> >  *Accidentally backed to older version that doesn't have
> >   nvidia-modeset.ko and only nvidia-modeset.ko is written in
> >   /boot/loader.conf.
> > 
> > ## Temporary settings for nvidia-driver when failed loading via loader.conf
> > kldstat -q -n nvidia.ko
> > if [ 0 -ne $? ] ; then
> >   echo "Loading nvidia-driver modules via rc.conf."
> > #  kldload nvidia
> >   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> > #kldload nvidia-modeset
> > kld_list="${kld_list} nvidia-modeset.ko"
> >   else
> > #kldload nvidia
> > kld_list="${kld_list} nvidia.ko"
> >   fi
> > fi
> > 
> > 
> > On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> > "Jeffrey Bouquet"  wrote:
> > 
> > >  Just had a unique to me, unbootable backup [beside the point,
> > > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > > 
> > >   12.0 - CURRENT
> > > 
> > >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > > for me to peruse as I was in the terminal ]
> > > 
> > > Lessons I learned, maybe
> > > 
> > > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > > nvidia-modeset-37539.ko
> > >   which would make one's diagnosis a fix easier. 
> > > 
> > > [suggestions]
> > > 
> > > ... Document that the kernel will load a /boot/modules/_nvidia.ko if 
> > > you'd thus made it 'unavailable'
> > > ... document better that one can load nvidia[modeset] later than 
> > > /boot/loader.conf [cli, rc.conf...]
> > > 
> > > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > > ] 
> > > ... I had a make.conf in place, 'trapping' a
> > > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > > install in failure
> > > ... I had no clue if Xorg was at fault, and luckily did not have to 
> > > rebuild.
> > > ... I had no access to the forums, as the desktop could not be loaded 
> > > [yet]
> > > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > > usable module numbers,
> > > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > > its 5 digit number
> > > as above.
> > > ... I was taken aback by the less infomative
> > > this client has the .39 but the module has the .26 ... 
> > > specifically stating which file/port/kernel module the 'client' 
> > > refers to
> > >and which specific modules 'this module' was referring to.  Unknown if 
> > > that is
> > >fixable here in a .c, .h , or is closed-source upstream in nvidia 
> > > [corp ] where we can
> > > ask them to be more specific or code in some more verbose error 
> > > messages.
> > > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > > files out of the
> > >   way and do a simple rebuild of the nvidia-driver.
> > > [... Not relieved that the nvidia-driver needed install during the 
> > > mesa-lib reshuffle,  maybe
> > >did not need to be, just a hazy recollection on my part.  So ignore 
> > > this little bit ]
> > > 
> > > ... All in all a learning experience.  Howsoever, I would like this 
> > > nvidia stuff to be put eventuall
> > >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > > yearly will have a more
> > >  authoritative flowchart of sorts to determine the next course of action.
> > >something like
> > >   if ... this thta
> > >if... this that
> > >if ... this that
> > >   OTOH... error message... a... you may need to...
> > >...
> > >error message ... r... you may need to...
> > > 
> > >  ... And it would have maybe saved a bit of time here, and I would almost 
> > > if eventually
> > >  possible be sure to copy /usr/src/UPDATING to 
> > > /usr/ports/x11/nvidia-driver for
> > >  more easy access if the desktop was broken
> > > 
> > > 
> > > Apologies for the hurried post. Indeed, I have tasked myself to write it 
> > > up here
> > > locally [ still in scribbled notations...] so I can forestall/fix more 
> > > quickly this
> > > error the next time.
> > > also...
> > > Running late  in other personal matters, and out of time.
> > > 
> > > Respectfully..
> > > 
> > > J. Bouquet 
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > 

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
wrote:

> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
> 
> BTW, I personally using below in rc.conf for safety.
> This only helps situations that...
> 
>  *Insufficient loader memory, but OK after kernel is started.
> 
>  *Accidentally backed to older version that doesn't have
>   nvidia-modeset.ko and only nvidia-modeset.ko is written in
>   /boot/loader.conf.
> 
> ## Temporary settings for nvidia-driver when failed loading via loader.conf
> kldstat -q -n nvidia.ko
> if [ 0 -ne $? ] ; then
>   echo "Loading nvidia-driver modules via rc.conf."
> #  kldload nvidia
>   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> #kldload nvidia-modeset
> kld_list="${kld_list} nvidia-modeset.ko"
>   else
> #kldload nvidia
> kld_list="${kld_list} nvidia.ko"
>   fi
> fi
> 
> 
> On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> "Jeffrey Bouquet"  wrote:
> 
> >  Just had a unique to me, unbootable backup [beside the point,
> > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > 
> >   12.0 - CURRENT
> > 
> >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > for me to peruse as I was in the terminal ]
> > 
> > Lessons I learned, maybe
> > 
> > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > nvidia-modeset-37539.ko
> >   which would make one's diagnosis a fix easier. 
> > 
> > [suggestions]
> > 
> > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> > thus made it 'unavailable'
> > ... document better that one can load nvidia[modeset] later than 
> > /boot/loader.conf [cli, rc.conf...]
> > 
> > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > ] 
> > ... I had a make.conf in place, 'trapping' a
> > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > install in failure
> > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> > ... I had no access to the forums, as the desktop could not be loaded [yet]
> > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > usable module numbers,
> > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > its 5 digit number
> > as above.
> > ... I was taken aback by the less infomative
> > this client has the .39 but the module has the .26 ... 
> > specifically stating which file/port/kernel module the 'client' refers 
> > to
> >and which specific modules 'this module' was referring to.  Unknown if 
> > that is
> >fixable here in a .c, .h , or is closed-source upstream in nvidia [corp 
> > ] where we can
> > ask them to be more specific or code in some more verbose error 
> > messages.
> > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > files out of the
> >   way and do a simple rebuild of the nvidia-driver.
> > [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> > reshuffle,  maybe
> >did not need to be, just a hazy recollection on my part.  So ignore this 
> > little bit ]
> > 
> > ... All in all a learning experience.  Howsoever, I would like this nvidia 
> > stuff to be put eventuall
> >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > yearly will have a more
> >  authoritative flowchart of sorts to determine the next course of action.
> >something like
> >   if ... this thta
> >if... this that
> >if ... this that
> >   OTOH... error message... a... you may need to...
> >...
> >error message ... r... you may need to...
> > 
> >  ... And it would have maybe saved a bit of time here, and I would almost 
> > if eventually
> >  possible be sure to copy /usr/src/UPDATING to 
> > /usr/ports/x11/nvidia-driver for
> >  more easy access if the desktop was broken
> > 
> > 
> > Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> > here
> > locally [ still in scribbled notations...] so I can forestall/fix more 
> > quickly this
> > error the next time.
> > also...
> > Running late  in other personal matters, and out of time.
> > 
> > Respectfully..
> > 
> > J. Bouquet 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> 
> -- 
> Tomoaki AOKI


I found just then that one can load it manually
first, though the nvidia.ko  [ one has newly built ] THEN
the nvidia-modeset.ko  

if it has not been loaded via /boot/loader.conf which did not load it
in the 

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Tomoaki AOKI]

Hi.
If including its version to nvidia.ko and nvidia-modeset.ko,
[hard / symbolic] link to it with current name should be needed
not to bother admins every time upgrading.

BTW, I personally using below in rc.conf for safety.
This only helps situations that...

 *Insufficient loader memory, but OK after kernel is started.

 *Accidentally backed to older version that doesn't have
  nvidia-modeset.ko and only nvidia-modeset.ko is written in
  /boot/loader.conf.

## Temporary settings for nvidia-driver when failed loading via loader.conf
kldstat -q -n nvidia.ko
if [ 0 -ne $? ] ; then
  echo "Loading nvidia-driver modules via rc.conf."
#  kldload nvidia
  if [ -e /boot/modules/nvidia-modeset.ko ] ; then
#kldload nvidia-modeset
kld_list="${kld_list} nvidia-modeset.ko"
  else
#kldload nvidia
kld_list="${kld_list} nvidia.ko"
  fi
fi


On Mon, 15 May 2017 06:41:33 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

>  Just had a unique to me, unbootable backup [beside the point,
> just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> 
>   12.0 - CURRENT
> 
>   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
> me to peruse as I was in the terminal ]
> 
> Lessons I learned, maybe
> 
> [RFC]  rename nvidia-driver.ko to include its version, for instance 
> nvidia-modeset-37539.ko
>   which would make one's diagnosis a fix easier. 
> 
> [suggestions]
> 
> ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> thus made it 'unavailable'
> ... document better that one can load nvidia[modeset] later than 
> /boot/loader.conf [cli, rc.conf...]
> 
> [ mini 'what fixed it for you '  and/or stalled the same ... 
> ] 
> ... I had a make.conf in place, 'trapping' a
> make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> install in failure
> ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> ... I had no access to the forums, as the desktop could not be loaded [yet]
> ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> usable module numbers,
> THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 
> 5 digit number
> as above.
> ... I was taken aback by the less infomative
> this client has the .39 but the module has the .26 ... 
> specifically stating which file/port/kernel module the 'client' refers to
>and which specific modules 'this module' was referring to.  Unknown if 
> that is
>fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
> where we can
> ask them to be more specific or code in some more verbose error messages.
> ...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
> out of the
>   way and do a simple rebuild of the nvidia-driver.
> [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> reshuffle,  maybe
>did not need to be, just a hazy recollection on my part.  So ignore this 
> little bit ]
> 
> ... All in all a learning experience.  Howsoever, I would like this nvidia 
> stuff to be put eventuall
>  in /usr/src/UPDATING so the half or third of persons who run into this 
> yearly will have a more
>  authoritative flowchart of sorts to determine the next course of action.
>something like
>   if ... this thta
>if... this that
>if ... this that
>   OTOH... error message... a... you may need to...
>...
>error message ... r... you may need to...
> 
>  ... And it would have maybe saved a bit of time here, and I would almost if 
> eventually
>  possible be sure to copy /usr/src/UPDATING to 
> /usr/ports/x11/nvidia-driver for
>  more easy access if the desktop was broken
> 
> 
> Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> here
> locally [ still in scribbled notations...] so I can forestall/fix more 
> quickly this
> error the next time.
> also...
> Running late  in other personal matters, and out of time.
> 
> Respectfully..
> 
> J. Bouquet 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

 Just had a unique to me, unbootable backup [beside the point,
just a sidebar comment... ]  quandry dealing with the nvidia-driver update
that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]

  12.0 - CURRENT

  [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
me to peruse as I was in the terminal ]

Lessons I learned, maybe

[RFC]  rename nvidia-driver.ko to include its version, for instance 
nvidia-modeset-37539.ko
  which would make one's diagnosis a fix easier. 

[suggestions]

... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus 
made it 'unavailable'
... document better that one can load nvidia[modeset] later than 
/boot/loader.conf [cli, rc.conf...]

[ mini 'what fixed it for you '  and/or stalled the same ... 
] 
... I had a make.conf in place, 'trapping' a
make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
install in failure
... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
... I had no access to the forums, as the desktop could not be loaded [yet]
... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable 
module numbers,
THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 
digit number
as above.
... I was taken aback by the less infomative
this client has the .39 but the module has the .26 ... 
specifically stating which file/port/kernel module the 'client' refers to
   and which specific modules 'this module' was referring to.  Unknown if that 
is
   fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
where we can
ask them to be more specific or code in some more verbose error messages.
...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
out of the
  way and do a simple rebuild of the nvidia-driver.
[... Not relieved that the nvidia-driver needed install during the mesa-lib 
reshuffle,  maybe
   did not need to be, just a hazy recollection on my part.  So ignore this 
little bit ]

... All in all a learning experience.  Howsoever, I would like this nvidia 
stuff to be put eventuall
 in /usr/src/UPDATING so the half or third of persons who run into this yearly 
will have a more
 authoritative flowchart of sorts to determine the next course of action.
   something like
  if ... this thta
   if... this that
   if ... this that
  OTOH... error message... a... you may need to...
   ...
   error message ... r... you may need to...

 ... And it would have maybe saved a bit of time here, and I would almost if 
eventually
 possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver 
for
 more easy access if the desktop was broken


Apologies for the hurried post. Indeed, I have tasked myself to write it up here
locally [ still in scribbled notations...] so I can forestall/fix more quickly 
this
error the next time.
also...
Running late  in other personal matters, and out of time.

Respectfully..

J. Bouquet 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"