KBI unexpexted change in stable/11 ?

[Slawa Olhovchenkov]

I am upgrade system to latest -STABLE and now see kernel crash:

- loading virtualbox modules build on 11.1-RELEASE-p6
- loading nvidia module build on 11.1-RELEASE-p6 and start xdm

Is this expected? I am mean about loading modules builded on
11.1-RELEASE on any 11.1-STABLE.
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Mark Saad]

> On Mar 28, 2018, at 9:09 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>
> I am upgrade system to latest -STABLE and now see kernel crash:
>
> - loading virtualbox modules build on 11.1-RELEASE-p6
> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
>
> Is this expected? I am mean about loading modules builded on
> 11.1-RELEASE on any 11.1-STABLE.

I had a similar issue and it caused a kernel coredump
I tracked the virtualbox issue to something in the vbox network module . Rebuilding it fixes it but I am not sure what broke . I have a kernel core dump if anyone wants a peak.


---
Mark Saad | none...@longcount.org

[Gregory Byshenk]

On Wed, Mar 28, 2018 at 04:09:04PM +0300, Slawa Olhovchenkov wrote:
> I am upgrade system to latest -STABLE and now see kernel crash:
>
> - loading virtualbox modules build on 11.1-RELEASE-p6
> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
>
> Is this expected? I am mean about loading modules builded on
> 11.1-RELEASE on any 11.1-STABLE.

Did you rebuild your virtualbox and nvidia modules for your new
kernel? If you build a new kernel, then you need to rebuild any
modules that were installed from ports for the new version.

You can do this manually, or by adding a PORTS_MODULES line to
/etc/make.conf. This will rebuild the listed modules from ports
when you build a new kernel.

I think this will do what you need (double-check that these are
the right port names):

PORTS_MODULES= emulators/virtualbox-ose-kmod x11/nvidia-driver

-gregory

--
gregory byshenk - gbys...@byshenk.net - Leiden, NL

[tech-lists]

On 28/03/2018 14:39, Gregory Byshenk wrote:
> You can do this manually, or by adding a PORTS_MODULES line to
> /etc/make.conf. This will rebuild the listed modules from ports
> when you build a new kernel.

Hi,

Are you sure it's in /etc/make.conf and not /etc/src.conf?
--
J.

[Greg Byshenk]

On Wed, Mar 28, 2018 at 03:11:50PM +0100, tech-lists wrote:
> On 28/03/2018 14:39, Gregory Byshenk wrote:
> > You can do this manually, or by adding a PORTS_MODULES line to
> > /etc/make.conf. This will rebuild the listed modules from ports
> > when you build a new kernel.
>

> Are you sure it's in /etc/make.conf and not /etc/src.conf?

No. But it is in the man page for make.conf and not src.conf.

--
gregory byshenk - gbys...@byshenk.net - Leiden, NL

[Slawa Olhovchenkov]

On Wed, Mar 28, 2018 at 03:39:46PM +0200, Gregory Byshenk wrote:

> On Wed, Mar 28, 2018 at 04:09:04PM +0300, Slawa Olhovchenkov wrote:
> > I am upgrade system to latest -STABLE and now see kernel crash:
> >
> > - loading virtualbox modules build on 11.1-RELEASE-p6
> > - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
> >
> > Is this expected? I am mean about loading modules builded on
> > 11.1-RELEASE on any 11.1-STABLE.
>
> Did you rebuild your virtualbox and nvidia modules for your new
> kernel? If you build a new kernel, then you need to rebuild any
> modules that were installed from ports for the new version.

Only for -CURRENT, not for -STABLE:

https://lists.freebsd.org/pipermail/svn-src-all/2018-March/159649.html

John Baldwin: "In theory we try to not break existing kernel
modules on a stable branch. That is, one should be able to kldload an
if_iwn.ko built on 11.0 on a 11-stable kernel."

[Gregory Byshenk]

On Wed, Mar 28, 2018 at 05:35:51PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Mar 28, 2018 at 03:39:46PM +0200, Gregory Byshenk wrote:
> >
> > Did you rebuild your virtualbox and nvidia modules for your new
> > kernel? If you build a new kernel, then you need to rebuild any
> > modules that were installed from ports for the new version.
>
> Only for -CURRENT, not for -STABLE:
>
> https://lists.freebsd.org/pipermail/svn-src-all/2018-March/159649.html
>
> John Baldwin: "In theory we try to not break existing kernel
> modules on a stable branch. That is, one should be able to kldload an
> if_iwn.ko built on 11.0 on a 11-stable kernel."

I understand that this is true for standard kernel modules, but
I have frequently run into problems loading _ports_ modules on
a new kernel - including in STABLE.

--
gregory byshenk - gbys...@byshenk.net - Leiden, NL

[Slawa Olhovchenkov]

On Wed, Mar 28, 2018 at 05:13:48PM +0200, Gregory Byshenk wrote:

> On Wed, Mar 28, 2018 at 05:35:51PM +0300, Slawa Olhovchenkov wrote:
> > On Wed, Mar 28, 2018 at 03:39:46PM +0200, Gregory Byshenk wrote:
> > >
> > > Did you rebuild your virtualbox and nvidia modules for your new
> > > kernel? If you build a new kernel, then you need to rebuild any
> > > modules that were installed from ports for the new version.
> >
> > Only for -CURRENT, not for -STABLE:
> >
> > https://lists.freebsd.org/pipermail/svn-src-all/2018-March/159649.html
> >
> > John Baldwin: "In theory we try to not break existing kernel
> > modules on a stable branch. That is, one should be able to kldload an
> > if_iwn.ko built on 11.0 on a 11-stable kernel."
>
> I understand that this is true for standard kernel modules, but
> I have frequently run into problems loading _ports_ modules on
> a new kernel - including in STABLE.

This is general _kernel_ rule, for loading all modules, mostly for
third-party modules.

[Eric van Gyzen]

On 03/28/2018 08:09, Slawa Olhovchenkov wrote:
> I am upgrade system to latest -STABLE and now see kernel crash:
>
> - loading virtualbox modules build on 11.1-RELEASE-p6
> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
>
> Is this expected? I am mean about loading modules builded on
> 11.1-RELEASE on any 11.1-STABLE.

This is not expected. Can you bisect to find the stable/11 commit that
broke this?

If you can roll back to 11.1-RELEASE, you could probably just
buildkernel and installkernel from various points along stable/11. That
would save a lot of time by avoiding buildworld.

Eric

[John]

On Wed, 28 Mar 2018, at 15:20, Greg Byshenk wrote:
> On Wed, Mar 28, 2018 at 03:11:50PM +0100, tech-lists wrote:
> > On 28/03/2018 14:39, Gregory Byshenk wrote:
> > > You can do this manually, or by adding a PORTS_MODULES line to
> > > /etc/make.conf. This will rebuild the listed modules from ports
> > > when you build a new kernel.
> >
> > Are you sure it's in /etc/make.conf and not /etc/src.conf?
>
> No. But it is in the man page for make.conf and not src.conf.

yeah. That is... confusing! at least to me, because [I thought it would be]
src.conf that's consulted when src is built. So I ran a couple of tests and
found that it would work in either file HOWEVER if one ports module statement
was in src.conf and another, different ports module statement was in make.conf,
that the one in src.conf would get built but the one in make.conf would not.

how confusing is that. This is on 11.1-stable.

--
John
tech-...@zyxst.net

[Slawa Olhovchenkov]

On Wed, Mar 28, 2018 at 10:29:10AM -0500, Eric van Gyzen wrote:

> On 03/28/2018 08:09, Slawa Olhovchenkov wrote:
> > I am upgrade system to latest -STABLE and now see kernel crash:
> >
> > - loading virtualbox modules build on 11.1-RELEASE-p6
> > - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
> >
> > Is this expected? I am mean about loading modules builded on
> > 11.1-RELEASE on any 11.1-STABLE.
>
> This is not expected. Can you bisect to find the stable/11 commit that
> broke this?
>
> If you can roll back to 11.1-RELEASE, you could probably just
> buildkernel and installkernel from various points along stable/11. That
> would save a lot of time by avoiding buildworld.

r325665 is previos point and is good.
r331615 crashed.
Can I use some script for bisect?

[Stefan Esser]

Am 28.03.18 um 17:30 schrieb John:

> On Wed, 28 Mar 2018, at 15:20, Greg Byshenk wrote:
>> On Wed, Mar 28, 2018 at 03:11:50PM +0100, tech-lists wrote:
>>> On 28/03/2018 14:39, Gregory Byshenk wrote:
>>>> You can do this manually, or by adding a PORTS_MODULES line to
>>>> /etc/make.conf. This will rebuild the listed modules from ports
>>>> when you build a new kernel.
>>>
>>> Are you sure it's in /etc/make.conf and not /etc/src.conf?
>>
>> No. But it is in the man page for make.conf and not src.conf.
>
> yeah. That is... confusing! at least to me, because [I thought it would be]
> src.conf that's consulted when src is built. So I ran a couple of tests and
> found that it would work in either file HOWEVER if one ports module statement
> was in src.conf and another, different ports module statement was in make.conf,
> that the one in src.conf would get built but the one in make.conf would not.
>
> how confusing is that. This is on 11.1-stable.

No, its not confusing at all, if you think about it ... ;-)

/etc/make.conf is included in any case, but kernel and world builds will
include /etc/src.conf thereafter (and overwrite earlier settings read from
make.conf, unless ?= is used to preserve the earlier value, or += to append
the new values).

Regards, STefan

[Ian Lepore]

On Wed, 2018-03-28 at 16:30 +0100, John wrote:
> On Wed, 28 Mar 2018, at 15:20, Greg Byshenk wrote:
> >
> > On Wed, Mar 28, 2018 at 03:11:50PM +0100, tech-lists wrote:
> > >
> > > On 28/03/2018 14:39, Gregory Byshenk wrote:
> > > >
> > > > You can do this manually, or by adding a PORTS_MODULES line to
> > > > /etc/make.conf. This will rebuild the listed modules from ports
> > > > when you build a new kernel.
> > > Are you sure it's in /etc/make.conf and not /etc/src.conf?
> > No. But it is in the man page for make.conf and not src.conf.
> yeah. That is... confusing! at least to me, because [I thought it would be] 
> src.conf that's consulted when src is built. So I ran a couple of tests and 
> found that it would work in either file HOWEVER if one ports module statement 
> was in src.conf and another, different ports module statement was in make.conf, 
> that the one in src.conf would get built but the one in make.conf would not. 
>
> how confusing is that. This is on 11.1-stable.
>

Make.conf is for building anything that uses make(1) and the build
infrastructure in /usr/share/mk.  Src.conf is for building the freebsd
sources only.  According to build(7), the freebsd sources include
/usr/src, /usr/doc, and /usr/ports.  So settings in both make.conf and
src.conf affect ports builds.

The difference appears when you use make to build your own software
that isn't part of freebsd.  For that, make.conf settings are applied,
but not src.conf.  At least, that's what the docs say.  When I look at
the .mk files in /usr/share/mk, it appears to me that src.conf gets
used even for non-freebsd-source builds.

When both files exist, variables set in src.conf will override same-
named variables set in make.conf.  Using VAR += value in both files
will accumulate values into VAR rather than replacing them.

-- Ian

[John]

On Wed, 28 Mar 2018, at 16:49, Stefan Esser wrote:

> No, its not confusing at all, if you think about it ... ;-)

The bit for me which was confusing is that the PORTS_MODULES reference, as Gregory correctly pointed out, is in the man page for make.conf and not src.conf. So one would think what the man page referenced would go into the file that pertaining to that manpage.

The reason I've always had things like KERNCONF=KERNCONF1 GENERIC and PORTS_MODULES in src.conf is because I figured "if it gets built when base gets built then it must go in src.conf". So when Gregory mentioned it goes in make.conf, I thought perhaps I was doing it all wrong, or in an outdated way. I was surprised finding that in these contexts it didn't matter as long as one remembers as you say += ?= in make.conf
--
John
tech-...@zyxst.net

[Eric van Gyzen]

On 03/28/2018 10:35, Slawa Olhovchenkov wrote:
> On Wed, Mar 28, 2018 at 10:29:10AM -0500, Eric van Gyzen wrote:
>
>> On 03/28/2018 08:09, Slawa Olhovchenkov wrote:
>>> I am upgrade system to latest -STABLE and now see kernel crash:
>>>
>>> - loading virtualbox modules build on 11.1-RELEASE-p6
>>> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
>>>
>>> Is this expected? I am mean about loading modules builded on
>>> 11.1-RELEASE on any 11.1-STABLE.
>>
>> This is not expected. Can you bisect to find the stable/11 commit that
>> broke this?
>>
>> If you can roll back to 11.1-RELEASE, you could probably just
>> buildkernel and installkernel from various points along stable/11. That
>> would save a lot of time by avoiding buildworld.
>
> r325665 is previos point and is good.
> r331615 crashed.
> Can I use some script for bisect?

I'm not aware of a script for this. The only tool I've used is "git
bisect", which is very handy if you're already familiar with git.

Eric

[Gary Palmer]

On Wed, Mar 28, 2018 at 11:16:49AM -0500, Eric van Gyzen wrote:
> On 03/28/2018 10:35, Slawa Olhovchenkov wrote:
> > On Wed, Mar 28, 2018 at 10:29:10AM -0500, Eric van Gyzen wrote:
> >
> >> On 03/28/2018 08:09, Slawa Olhovchenkov wrote:
> >>> I am upgrade system to latest -STABLE and now see kernel crash:
> >>>
> >>> - loading virtualbox modules build on 11.1-RELEASE-p6
> >>> - loading nvidia module build on 11.1-RELEASE-p6 and start xdm
> >>>
> >>> Is this expected? I am mean about loading modules builded on
> >>> 11.1-RELEASE on any 11.1-STABLE.
> >>
> >> This is not expected. Can you bisect to find the stable/11 commit that
> >> broke this?
> >>
> >> If you can roll back to 11.1-RELEASE, you could probably just
> >> buildkernel and installkernel from various points along stable/11. That
> >> would save a lot of time by avoiding buildworld.
> >
> > r325665 is previos point and is good.
> > r331615 crashed.
> > Can I use some script for bisect?
>
> I'm not aware of a script for this. The only tool I've used is "git
> bisect", which is very handy if you're already familiar with git.

You may want to try devel/p5-App-SVN-Bisect. Never used it, so
no idea if it's functional or helpful, just found it doing a quick
search

Regards,

Gary

[Kevin Oberman]

Regardless of intent, updates to port based modules can and and will break
when the kernel is updated. lsof breaks quite often, as well. It touches
things in the kernel that are intended for internal use only, so that is to
be expected. I can't say that virtualbox-ose-kmod has had to be rebuilt
because I put it into PORTS_MODULES a couple of years ago after having it
fail on several occasions. Every time it gets broken again thee are lots of
threads in STABLE like this one.

It would be nice if this could be fixed, but it is the case.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkob...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

[Le...@lena.kiev.ua]

> From: Kevin Oberman

> Regardless of intent, updates to port based modules can and and will break
> when the kernel is updated.

Are packages for pkg.freebsd.org built on -STABLE or latest -RELEASE?

After 11.2 is released, if package for nvidia-driver
is installed or upgraded on a machine with 11.1-RELEASE,
will it crash the kernel?

If the port nvidia-driver-304 is updated before 11.2 is released,
will `pkg upgrade` crash the kernel?

[Kyle Evans]

On Thu, Mar 29, 2018 at 8:38 AM, <Le...@lena.kiev.ua> wrote:
>> From: Kevin Oberman
>
>> Regardless of intent, updates to port based modules can and and will break
>> when the kernel is updated.
>
> Are packages for pkg.freebsd.org built on -STABLE or latest -RELEASE?
>
> After 11.2 is released, if package for nvidia-driver
> is installed or upgraded on a machine with 11.1-RELEASE,
> will it crash the kernel?
>
> If the port nvidia-driver-304 is updated before 11.2 is released,
> will `pkg upgrade` crash the kernel?

Packages are built on the earliest supported release of a branch;
never from the stable branch. These packages will be built from 11.1
until it goes EOL a couple months after 11.2 release.

Breakage of packages from an earlier release of a branch is not ideal,
so it would still be most helpful if someone could bissect this so
that we can assess the breakage and figure out next steps before it
becomes a bigger problem with the impending release.

I've heard good things about the aforementioned
devel/p5-App-SVN-Bisect for these purposes.

Thanks,

Kyle Evans

[Slawa Olhovchenkov]

On Wed, Mar 28, 2018 at 11:25:08PM -0700, Kevin Oberman wrote:

> > > > r325665 is previos point and is good.
> > > > r331615 crashed.
> > > > Can I use some script for bisect?
> > >
> > > I'm not aware of a script for this. The only tool I've used is "git
> > > bisect", which is very handy if you're already familiar with git.
> >
> > You may want to try devel/p5-App-SVN-Bisect. Never used it, so
> > no idea if it's functional or helpful, just found it doing a quick
> > search
>

> It would be nice if this could be fixed, but it is the case.

r328475 bad (tzdata)
r328469 in progress (kib, sys/vm)
r328463 in progress (don't touch kernel)
r328462 good

I mean r328469 break KBI.

[Konstantin Belousov]

On Thu, Mar 29, 2018 at 09:21:43PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Mar 28, 2018 at 11:25:08PM -0700, Kevin Oberman wrote:
>
> > > > > r325665 is previos point and is good.
> > > > > r331615 crashed.
> > > > > Can I use some script for bisect?
> > > >
> > > > I'm not aware of a script for this. The only tool I've used is "git
> > > > bisect", which is very handy if you're already familiar with git.
> > >
> > > You may want to try devel/p5-App-SVN-Bisect. Never used it, so
> > > no idea if it's functional or helpful, just found it doing a quick
> > > search
> >
> > It would be nice if this could be fixed, but it is the case.
>
> r328475 bad (tzdata)
> r328469 in progress (kib, sys/vm)
> r328463 in progress (don't touch kernel)
> r328462 good
>
> I mean r328469 break KBI.

This commit is basically required to avoid significant confusion between
HEAD and stable code. Its absense might make other merges impossible or
quite hard.

In fact, my opinion is that the real bug is elsewere. We do provide
vm_map_min/max KPI, but the KPI is not KBI-stable because it encodes
struct vm_map layout into binaries which (correctly) use KPI instead
of directly accessing struct vm_map. This should be fixed, I put the
review https://reviews.freebsd.org/D14902 for it.