Re: svn commit: r332091 - stable/11/sys/vm
On Thursday, April 12, 2018 12:49:35 AM Slawa Olhovchenkov wrote: > On Wed, Apr 11, 2018 at 02:27:48PM -0700, John Baldwin wrote: > > > On Wednesday, April 11, 2018 10:49:20 PM Konstantin Belousov wrote: > > > On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote: > > > > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > > > > > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > > > > > > > > > > > Author: kib > > > > > > Date: Fri Apr 6 09:25:08 2018 > > > > > > New Revision: 332091 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > > > > > > > > > Log: > > > > > > MFC r331760: > > > > > > Make vm_map_max/min/pmap KBI stable. > > > > > > > > > > > > Modified: > > > > > > stable/11/sys/vm/vm_map.c > > > > > > stable/11/sys/vm/vm_map.h > > > > > > Directory Properties: > > > > > > stable/11/ (props changed) > > > > > > > > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > > > > > nvidia (build on 11.1-RELEASE) also don't work > > > > > > > > Yes, this only helps with the future KBI, it doesn't restore the > > > > existing one. However, r320889 which was committed earlier should > > > > have restored the KBI? > > > > > > I am not sure. It might have, but there might be more breakage > > > accumulated. My current opinion is that both vbox and nvidia (as well as > > > in-tree and out of tree drm modules) must be marked as tied. The modules > > > definitely depends on much more kernel interfaces than a typical HBA or > > > network controller driver, for which the stability claim is actually > > > intended to apply. > > > > I do think virtualbox is probably too hard to make work, but I didn't think > > the nvidia driver was that bad. > > > > I think that for kmods in ports we should consider moving to a different > > model > > than we currently do where the port installs the source for the kernel > > module to a standard location and we could have a way to rebuild all of the > > modules as needed. This would permit us to provide PORTS_MODULES-type > > functionality via either ports or packages (and it is a bit more flexible as > > you wouldn't to deinstall/reinstall the package each time you just wanted to > > rebuild the kernel module). > > > > I would suggest something like /usr/local/src/modules/ and a > > 'LOCAL_MODULES' kernel option that is a list of ' ' to replace > > PORTS_MODULES. A package could still ship an initial module by default, but > > recompiling the module would either overwrite it, or if the module is built > > as > > part of the kernel (via LOCAL_MODULES) the new one would be installed with > > the > > kernel itself into /boot/kernel leaving the one from the package in > > /boot/modules. For tied modules we could simply build it with a strict > > MODULE_DEPEND line on the kernel so that the pre-built module won't load on > > newer kernels and then encourage the user to use LOCAL_MODULES in > > pkg-message. > > Using LOCAL_MODULES would be better than PORTS_MODULES as it would DTRT if > > you > > move kernel to kernel.old during an upgrade, etc. > > Hmm, what about packages? I am use nvidia driver as package. Yes, in this model, the package would include the necessary sources to rebuild the kernel module as part of the package, installed to /usr/local/src/modules/nvidia-driver or some such. The package could still install a pre-built module to /boot/modules/nvidia-driver.ko, but if you had 'options LOCAL_MODULES="nivida-driver" in your kernel config, then each time you built a kernel it would build an nvidia-driver.ko from /usr/local/src/modules/nvidia-driver that would be installed to /boot/kernel and would thus take precedence over the version in /boot/modules. For kernel modules that really need to be tied to the current kernel we would recommend using LOCAL_MODULES when using custom kernels in the pkg-message. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r332091 - stable/11/sys/vm
On Wed, Apr 11, 2018 at 02:27:48PM -0700, John Baldwin wrote: > On Wednesday, April 11, 2018 10:49:20 PM Konstantin Belousov wrote: > > On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote: > > > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > > > > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > > > > > > > > > Author: kib > > > > > Date: Fri Apr 6 09:25:08 2018 > > > > > New Revision: 332091 > > > > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > > > > > > > Log: > > > > > MFC r331760: > > > > > Make vm_map_max/min/pmap KBI stable. > > > > > > > > > > Modified: > > > > > stable/11/sys/vm/vm_map.c > > > > > stable/11/sys/vm/vm_map.h > > > > > Directory Properties: > > > > > stable/11/ (props changed) > > > > > > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > > > > nvidia (build on 11.1-RELEASE) also don't work > > > > > > Yes, this only helps with the future KBI, it doesn't restore the > > > existing one. However, r320889 which was committed earlier should > > > have restored the KBI? > > > > I am not sure. It might have, but there might be more breakage > > accumulated. My current opinion is that both vbox and nvidia (as well as > > in-tree and out of tree drm modules) must be marked as tied. The modules > > definitely depends on much more kernel interfaces than a typical HBA or > > network controller driver, for which the stability claim is actually > > intended to apply. > > I do think virtualbox is probably too hard to make work, but I didn't think > the nvidia driver was that bad. > > I think that for kmods in ports we should consider moving to a different model > than we currently do where the port installs the source for the kernel > module to a standard location and we could have a way to rebuild all of the > modules as needed. This would permit us to provide PORTS_MODULES-type > functionality via either ports or packages (and it is a bit more flexible as > you wouldn't to deinstall/reinstall the package each time you just wanted to > rebuild the kernel module). > > I would suggest something like /usr/local/src/modules/ and a > 'LOCAL_MODULES' kernel option that is a list of ' ' to replace > PORTS_MODULES. A package could still ship an initial module by default, but > recompiling the module would either overwrite it, or if the module is built as > part of the kernel (via LOCAL_MODULES) the new one would be installed with the > kernel itself into /boot/kernel leaving the one from the package in > /boot/modules. For tied modules we could simply build it with a strict > MODULE_DEPEND line on the kernel so that the pre-built module won't load on > newer kernels and then encourage the user to use LOCAL_MODULES in pkg-message. > Using LOCAL_MODULES would be better than PORTS_MODULES as it would DTRT if you > move kernel to kernel.old during an upgrade, etc. Hmm, what about packages? I am use nvidia driver as package. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r332091 - stable/11/sys/vm
On Wednesday, April 11, 2018 10:49:20 PM Konstantin Belousov wrote: > On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote: > > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > > > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > > > > > > > Author: kib > > > > Date: Fri Apr 6 09:25:08 2018 > > > > New Revision: 332091 > > > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > > > > > Log: > > > > MFC r331760: > > > > Make vm_map_max/min/pmap KBI stable. > > > > > > > > Modified: > > > > stable/11/sys/vm/vm_map.c > > > > stable/11/sys/vm/vm_map.h > > > > Directory Properties: > > > > stable/11/ (props changed) > > > > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > > > nvidia (build on 11.1-RELEASE) also don't work > > > > Yes, this only helps with the future KBI, it doesn't restore the > > existing one. However, r320889 which was committed earlier should > > have restored the KBI? > > I am not sure. It might have, but there might be more breakage > accumulated. My current opinion is that both vbox and nvidia (as well as > in-tree and out of tree drm modules) must be marked as tied. The modules > definitely depends on much more kernel interfaces than a typical HBA or > network controller driver, for which the stability claim is actually > intended to apply. I do think virtualbox is probably too hard to make work, but I didn't think the nvidia driver was that bad. I think that for kmods in ports we should consider moving to a different model than we currently do where the port installs the source for the kernel module to a standard location and we could have a way to rebuild all of the modules as needed. This would permit us to provide PORTS_MODULES-type functionality via either ports or packages (and it is a bit more flexible as you wouldn't to deinstall/reinstall the package each time you just wanted to rebuild the kernel module). I would suggest something like /usr/local/src/modules/ and a 'LOCAL_MODULES' kernel option that is a list of ' ' to replace PORTS_MODULES. A package could still ship an initial module by default, but recompiling the module would either overwrite it, or if the module is built as part of the kernel (via LOCAL_MODULES) the new one would be installed with the kernel itself into /boot/kernel leaving the one from the package in /boot/modules. For tied modules we could simply build it with a strict MODULE_DEPEND line on the kernel so that the pre-built module won't load on newer kernels and then encourage the user to use LOCAL_MODULES in pkg-message. Using LOCAL_MODULES would be better than PORTS_MODULES as it would DTRT if you move kernel to kernel.old during an upgrade, etc. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r332091 - stable/11/sys/vm
On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote: > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > > > > > Author: kib > > > Date: Fri Apr 6 09:25:08 2018 > > > New Revision: 332091 > > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > > > Log: > > > MFC r331760: > > > Make vm_map_max/min/pmap KBI stable. > > > > > > Modified: > > > stable/11/sys/vm/vm_map.c > > > stable/11/sys/vm/vm_map.h > > > Directory Properties: > > > stable/11/ (props changed) > > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > > nvidia (build on 11.1-RELEASE) also don't work > > Yes, this only helps with the future KBI, it doesn't restore the > existing one. However, r320889 which was committed earlier should > have restored the KBI? I am not sure. It might have, but there might be more breakage accumulated. My current opinion is that both vbox and nvidia (as well as in-tree and out of tree drm modules) must be marked as tied. The modules definitely depends on much more kernel interfaces than a typical HBA or network controller driver, for which the stability claim is actually intended to apply. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r332091 - stable/11/sys/vm
On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote: > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > > > > > Author: kib > > > Date: Fri Apr 6 09:25:08 2018 > > > New Revision: 332091 > > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > > > Log: > > > MFC r331760: > > > Make vm_map_max/min/pmap KBI stable. > > > > > > Modified: > > > stable/11/sys/vm/vm_map.c > > > stable/11/sys/vm/vm_map.h > > > Directory Properties: > > > stable/11/ (props changed) > > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > > nvidia (build on 11.1-RELEASE) also don't work > > Yes, this only helps with the future KBI, it doesn't restore the > existing one. However, r320889 which was committed earlier should > have restored the KBI? Sorry, miss you point. I am update to last stable/11, build and install kernel and check old modules. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r332091 - stable/11/sys/vm
On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > > > Author: kib > > Date: Fri Apr 6 09:25:08 2018 > > New Revision: 332091 > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > Log: > > MFC r331760: > > Make vm_map_max/min/pmap KBI stable. > > > > Modified: > > stable/11/sys/vm/vm_map.c > > stable/11/sys/vm/vm_map.h > > Directory Properties: > > stable/11/ (props changed) > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > nvidia (build on 11.1-RELEASE) also don't work Yes, this only helps with the future KBI, it doesn't restore the existing one. However, r320889 which was committed earlier should have restored the KBI? -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r332091 - stable/11/sys/vm
On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote: > Author: kib > Date: Fri Apr 6 09:25:08 2018 > New Revision: 332091 > URL: https://svnweb.freebsd.org/changeset/base/332091 > > Log: > MFC r331760: > Make vm_map_max/min/pmap KBI stable. > > Modified: > stable/11/sys/vm/vm_map.c > stable/11/sys/vm/vm_map.h > Directory Properties: > stable/11/ (props changed) -STABLE still crashed after load vboxnet build on 11.1-RELEASE nvidia (build on 11.1-RELEASE) also don't work ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r332091 - stable/11/sys/vm
Author: kib Date: Fri Apr 6 09:25:08 2018 New Revision: 332091 URL: https://svnweb.freebsd.org/changeset/base/332091 Log: MFC r331760: Make vm_map_max/min/pmap KBI stable. Modified: stable/11/sys/vm/vm_map.c stable/11/sys/vm/vm_map.h Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/vm/vm_map.c == --- stable/11/sys/vm/vm_map.c Fri Apr 6 02:57:58 2018(r332090) +++ stable/11/sys/vm/vm_map.c Fri Apr 6 09:25:08 2018(r332091) @@ -4257,6 +4257,27 @@ vm_map_lookup_done(vm_map_t map, vm_map_entry_t entry) vm_map_unlock_read(map); } +vm_offset_t +vm_map_max_KBI(const struct vm_map *map) +{ + + return (map->max_offset); +} + +vm_offset_t +vm_map_min_KBI(const struct vm_map *map) +{ + + return (map->min_offset); +} + +pmap_t +vm_map_pmap_KBI(vm_map_t map) +{ + + return (map->pmap); +} + #include "opt_ddb.h" #ifdef DDB #include Modified: stable/11/sys/vm/vm_map.h == --- stable/11/sys/vm/vm_map.h Fri Apr 6 02:57:58 2018(r332090) +++ stable/11/sys/vm/vm_map.h Fri Apr 6 09:25:08 2018(r332091) @@ -205,6 +205,11 @@ struct vm_map { #defineMAP_BUSY_WAKEUP 0x02 #ifdef _KERNEL +#ifdef KLD_MODULE +#definevm_map_max(map) vm_map_max_KBI((map)) +#definevm_map_min(map) vm_map_min_KBI((map)) +#definevm_map_pmap(map)vm_map_pmap_KBI((map)) +#else static __inline vm_offset_t vm_map_max(const struct vm_map *map) { @@ -228,6 +233,7 @@ vm_map_modflags(vm_map_t map, vm_flags_t set, vm_flags { map->flags = (map->flags | set) & ~clear; } +#endif /* KLD_MODULE */ #endif /* _KERNEL */ /* @@ -288,6 +294,9 @@ void vm_map_wakeup(vm_map_t map); void vm_map_busy(vm_map_t map); void vm_map_unbusy(vm_map_t map); void vm_map_wait_busy(vm_map_t map); +vm_offset_t vm_map_max_KBI(const struct vm_map *map); +vm_offset_t vm_map_min_KBI(const struct vm_map *map); +pmap_t vm_map_pmap_KBI(vm_map_t map); #definevm_map_lock(map)_vm_map_lock(map, LOCK_FILE, LOCK_LINE) #definevm_map_unlock(map) _vm_map_unlock(map, LOCK_FILE, LOCK_LINE) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"