From owner-freebsd-current@freebsd.org Mon May 15 14:53:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01736D6EDAB; Mon, 15 May 2017 14:53:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C39FAA8A; Mon, 15 May 2017 14:53:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v4FErA7I009142; Mon, 15 May 2017 23:53:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 15 May 2017 23:53:10 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: jbtakk@iherebuywisely.com, freebsd-ports@freebsd.org Subject: Re: [RFC] rename nvidia-driver port binaries [ and other comments] Message-Id: <20170515235310.9f60289e486c202cc5be7978@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 14:53:14 -0000 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-unsubscribe@freebsd.org" > -- Tomoaki AOKI