Re: svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-11 Thread Eitan Adler 
On 11 March 2018 at 14:04, Helge Oldach  wrote:
> Pintér, Olivér wrote on Sun, 11 Mar 2018 18:17:44 +0100 (CET):
>> On Thu, Mar 8, 2018 at 12:51 PM, Pintér, Olivér 

> Reverting r330206 (only, but keeping the succeeding commits) fixed it for me, 
> as described in the PR.

r330206 has been reverted.

-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-11 Thread Rodney W. Grimes 
> > On 11 March 2018 at 10:53, Rodney W. Grimes
> >  wrote:
> > 
> > >> Sorry, -ENOTIME for 8265 this weekend, but it working fine (and much more
> > >> stable) with 7260.
> > >
> > > Thanks for keeping us informed.
> > >
> > > I am uncertain as to the state of iwm in stable/11, should the
> > > Intel 8565ac work, or not?  I have exchanged an additional
> > > round of email with the volunteer tester, he says he is
> > > running an unmodified stable/11, now trying to find out if he
> > > is updating that regular or not.  Hopefully we can have some
> > > test results soon.
> > 
> > There has been a lot of discussion on this thread and I did not have
> > time to digest it all.
> > 
> > That being said
> > 
> > - stable works for my hardware
> > - there is one known issue that I have not yet resolved. I originally
> > committed to resolving it this past week, but held off due to the long
> > discussion here
> > - I will take full responsibility for ensuring that anything working
> > before my changes continues to work on stable
> > - however, I will need reports of people who are able to help bisect
> > to the broken changes
> 
> Simple question you could answer before I have this guy do a bunch
> of work, *should* the Intel 8565AC work in stable/11 now?  There
> is a specific PR and commit to ^/head that adds this functionality,
> did that get merged and stay, or ?

Specifically: from bug 220229 and commit r324434

-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-11 Thread Rodney W. Grimes 
> On 11 March 2018 at 10:53, Rodney W. Grimes
>  wrote:
> 
> >> Sorry, -ENOTIME for 8265 this weekend, but it working fine (and much more
> >> stable) with 7260.
> >
> > Thanks for keeping us informed.
> >
> > I am uncertain as to the state of iwm in stable/11, should the
> > Intel 8565ac work, or not?  I have exchanged an additional
> > round of email with the volunteer tester, he says he is
> > running an unmodified stable/11, now trying to find out if he
> > is updating that regular or not.  Hopefully we can have some
> > test results soon.
> 
> There has been a lot of discussion on this thread and I did not have
> time to digest it all.
> 
> That being said
> 
> - stable works for my hardware
> - there is one known issue that I have not yet resolved. I originally
> committed to resolving it this past week, but held off due to the long
> discussion here
> - I will take full responsibility for ensuring that anything working
> before my changes continues to work on stable
> - however, I will need reports of people who are able to help bisect
> to the broken changes

Simple question you could answer before I have this guy do a bunch
of work, *should* the Intel 8565AC work in stable/11 now?  There
is a specific PR and commit to ^/head that adds this functionality,
did that get merged and stay, or ?

Thanks,
-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-11 Thread Eitan Adler 
On 11 March 2018 at 10:53, Rodney W. Grimes
 wrote:

>> Sorry, -ENOTIME for 8265 this weekend, but it working fine (and much more
>> stable) with 7260.
>
> Thanks for keeping us informed.
>
> I am uncertain as to the state of iwm in stable/11, should the
> Intel 8565ac work, or not?  I have exchanged an additional
> round of email with the volunteer tester, he says he is
> running an unmodified stable/11, now trying to find out if he
> is updating that regular or not.  Hopefully we can have some
> test results soon.

There has been a lot of discussion on this thread and I did not have
time to digest it all.

That being said

- stable works for my hardware
- there is one known issue that I have not yet resolved. I originally
committed to resolving it this past week, but held off due to the long
discussion here
- I will take full responsibility for ensuring that anything working
before my changes continues to work on stable
- however, I will need reports of people who are able to help bisect
to the broken changes


-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-11 Thread Rodney W. Grimes 
> On Thu, Mar 8, 2018 at 12:51 PM, Pint?r, Oliv?r 
> wrote:
> 
> >
> >
> > On Thu, Mar 8, 2018 at 12:18 AM, Rodney W. Grimes <
> > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> >> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> >> > > On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
> >> > >> On 6 March 2018 at 08:26, John Baldwin  wrote:
> >> > >> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
> >> > >> >> On 5 March 2018 at 10:08, John Baldwin  wrote:
> >> > >> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
> >> > >> >> >> Author: eadler
> >> > >> >> >> Date: Mon Mar  5 07:54:57 2018
> >> > >> >> >> New Revision: 330451
> >> > >> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451
> >> > >> >> >>
> >> > >> >> >> Log:
> >> > >> >> >>   MFC r306837:
> >> > >> >> >>
> >> > >> >> >>   [net80211] extend the ieee80211_rx_stats struct to include
> >> more information.
> >> > >> >> >
> >> > >> >> > Have you thought about the KBI implications of this change and
> >> some of the
> >> > >> >> > other changes you've merged?
> >> > >> >>
> >> > >> >> I do have a copy of the modules from 11.1 and have loaded them at
> >> > >> >> various points in time after merging. That said, I am not perfect.
> >> > >> >> Unfortunately, my -STABLE box did not have fully functioning
> >> drivers
> >> > >> >> before these changes so its difficult to test anything beyond
> >> "loads
> >> > >> >> and does not panic.". I havn't done so today yet, but that will
> >> happen
> >> > >> >> soon.
> >> > >> >>
> >> > >> >> Ensuring these things work through code inspection is certainly
> >> > >> >> possible and I've skipped over several changes as a result.
> >> > >> >
> >> > >> > Loading a module doesn't alone doesn't actually test for breakage.
> >> > >>
> >> > >> I'm aware. In this case I should likely just revert this change since
> >> > >> its a pretty blatant break.
> >> > >
> >> > > I suspect many of these changes for iwm, etc. are all intertwined so
> >> I'm not
> >> > > sure if you can leave out individual ones.
> >> >
> >> > Possibly. I do have iwm working on my laptop though. I also know of
> >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> >> > addressing it some time this week.
> >>
> >> I believe I also have a tester of stable/11 iwm patches avaliable,
> >> he has an 8265?
     Its an 8565, my mistake.
> >>
> >
> > At weekend I will test them.
> >
> 
> Sorry, -ENOTIME for 8265 this weekend, but it working fine (and much more
> stable) with 7260.

Thanks for keeping us informed.

I am uncertain as to the state of iwm in stable/11, should the
Intel 8565ac work, or not?  I have exchanged an additional
round of email with the volunteer tester, he says he is
running an unmodified stable/11, now trying to find out if he
is updating that regular or not.  Hopefully we can have some
test results soon.

Thanks,
-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-11 Thread Pintér , Olivér 
On Thu, Mar 8, 2018 at 12:51 PM, Pintér, Olivér 
wrote:

>
>
> On Thu, Mar 8, 2018 at 12:18 AM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On 7 March 2018 at 09:37, John Baldwin  wrote:
>> > > On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
>> > >> On 6 March 2018 at 08:26, John Baldwin  wrote:
>> > >> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
>> > >> >> On 5 March 2018 at 10:08, John Baldwin  wrote:
>> > >> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
>> > >> >> >> Author: eadler
>> > >> >> >> Date: Mon Mar  5 07:54:57 2018
>> > >> >> >> New Revision: 330451
>> > >> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451
>> > >> >> >>
>> > >> >> >> Log:
>> > >> >> >>   MFC r306837:
>> > >> >> >>
>> > >> >> >>   [net80211] extend the ieee80211_rx_stats struct to include
>> more information.
>> > >> >> >
>> > >> >> > Have you thought about the KBI implications of this change and
>> some of the
>> > >> >> > other changes you've merged?
>> > >> >>
>> > >> >> I do have a copy of the modules from 11.1 and have loaded them at
>> > >> >> various points in time after merging. That said, I am not perfect.
>> > >> >> Unfortunately, my -STABLE box did not have fully functioning
>> drivers
>> > >> >> before these changes so its difficult to test anything beyond
>> "loads
>> > >> >> and does not panic.". I havn't done so today yet, but that will
>> happen
>> > >> >> soon.
>> > >> >>
>> > >> >> Ensuring these things work through code inspection is certainly
>> > >> >> possible and I've skipped over several changes as a result.
>> > >> >
>> > >> > Loading a module doesn't alone doesn't actually test for breakage.
>> > >>
>> > >> I'm aware. In this case I should likely just revert this change since
>> > >> its a pretty blatant break.
>> > >
>> > > I suspect many of these changes for iwm, etc. are all intertwined so
>> I'm not
>> > > sure if you can leave out individual ones.
>> >
>> > Possibly. I do have iwm working on my laptop though. I also know of
>> > one open PR assigned to me w.r.t. a model I don't own. I'll be
>> > addressing it some time this week.
>>
>> I believe I also have a tester of stable/11 iwm patches avaliable,
>> he has an 8265?
>>
>
> At weekend I will test them.
>

Sorry, -ENOTIME for 8265 this weekend, but it working fine (and much more
stable) with 7260.


>
>
>>
>> --
>> Rod Grimes
>> rgri...@freebsd.org
>> ___
>> svn-src-stable...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
>> To unsubscribe, send any mail to "svn-src-stable-11-unsubscribe
>> @freebsd.org"
>>
>
>
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-10 Thread Mark Linimon 
On Sat, Mar 10, 2018 at 08:27:43AM +, Alexey Dokuchaev wrote:
> one can update their machines and go back easily if things went south.

After wasting time, like I did most of Thursday.

mcl
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-10 Thread Alexey Dokuchaev 
On Fri, Mar 09, 2018 at 10:50:02AM -0700, Ian Lepore wrote:
> On Fri, 2018-03-09 at 11:02 +, Alexey Dokuchaev wrote:
> > I often have mixed feelings when I see lots of similar changes (i.e.
> > that make up for better hardware support, esp. on a laptop) MFCed.
> > I'd rather see laptop users run -CURRENT and leave -STABLE branches
> > for very conservative (server?) users who can't/don't want to afford
> > the risks of running -CURRENT or require ABI stability in a really
> > long run, rather than binge-merging things. :-)
> > 
> > By default it should be -CURRENT all over; it's a very good thing
> > that we as a Project ourselves are doing this as part of our own
> > dogfood eating strategy.
> 
> Some of us have to use our freebsd machines to earn a living, and we
> can't afford the time and resources to set our jobs aside and debug
> our working machines on a daily basis.

It's 2018 Ian, -CURRENT is not as much of a flux as it used to be (but
it takes a lot more time to build now).  Disks got larger, filesystems
learned snapshots; one can update their machines and go back easily if
things went south.  Development, collaboration, testing/CI, etc. tools
also got better, people no longer commit their WIP to -CURRENT in hope
that it'll work (at least not as often as 15-20 years ago. :-)

./danfe
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Ian Lepore 
On Fri, 2018-03-09 at 11:02 +, Alexey Dokuchaev wrote:
> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> > 
> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> > > 
> > > ...
> > > I suspect many of these changes for iwm, etc. are all intertwined
> > > so I'm not sure if you can leave out individual ones.
> > Possibly. I do have iwm working on my laptop though. I also know of
> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> > addressing it some time this week.
> I often have mixed feelings when I see lots of similar changes (i.e.
> that make up for better hardware support, esp. on a laptop) MFCed.
> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> for very conservative (server?) users who can't/don't want to afford
> the risks of running -CURRENT or require ABI stability in a really
> long run, rather than binge-merging things. :-)
> 
> By default it should be -CURRENT all over; it's a very good thing
> that we as a Project ourselves are doing this as part of our own
> dogfood eating strategy.
> 
> ./danfe
> 

Some of us have to use our freebsd machines to earn a living, and we
can't afford the time and resources to set our jobs aside and debug our
working machines on a daily basis.  We have the same right to use an up
to date and stable OS as "very conservative server users".

Discouraging MFCs because your opinion is that everyone should run
current is, not to put too fine a point on it, 'totally f'ing crazy'.

-- Ian

___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Rodney W. Grimes 
[ Charset UTF-8 unsupported, converting... ]
> On 03/09/2018 10:00, Warner Losh wrote:
> >
> >
> > On Fri, Mar 9, 2018 at 8:44 AM, Kyle Evans  > > wrote:
> >
> > On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
> >  > > wrote:
> > >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> > >> > On 7 March 2018 at 09:37, John Baldwin  > > wrote:
> > >> > > ...
> > >> > > I suspect many of these changes for iwm, etc. are all
> > intertwined
> > >> > > so I'm not sure if you can leave out individual ones.
> > >> >
> > >> > Possibly. I do have iwm working on my laptop though. I also
> > know of
> > >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> > >> > addressing it some time this week.
> > >>
> > >> I often have mixed feelings when I see lots of similar changes
> > (i.e.
> > >> that make up for better hardware support, esp. on a laptop) MFCed.
> > >> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> > >> for very conservative (server?) users who can't/don't want to
> > afford
> > >> the risks of running -CURRENT or require ABI stability in a really
> > >> long run, rather than binge-merging things. :-)
> > >>
> > >> By default it should be -CURRENT all over; it's a very good thing
> > >> that we as a Project ourselves are doing this as part of our own
> > >> dogfood eating strategy.
> > >
> > > As a data point just last night a person came into #freebsd irc
> > > channel with a none working wireless nic on a desktop, he was
> > > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
> > >
> > > Someone had already told him to try urtwn driver, which in
> > > -current is the right driver and supports this device.
> > >
> > > It did not work for him.? This is about when I came in to the
> > > discussion, and helped to confirm that -current did infact
> > > have support for this device, and that this supported had
> > > existed in -current for 16 months, and that this support
> > > would not be a simple grab a couple driver files and build
> > > it on 11.1.
> > >
> > > The commit to add this support involves 46 files, which 18
> > > of are new files.
> > >
> > > My feelings are if this driver has been in -current for
> > > 16 months why is it NOT in -stable yet?? I know part of
> > > the answer "its not a simple merge".? But as a project
> > > this is egg on our face.? We can merge a new very complicated
> > > change to a our boot code, within a few months (thank you
> > > kevans for that work), but we can not merge back a
> > > device driver in 16?
> > >
> >
> > I had the same questions- this exact same person had hopped over to
> > #freebsd-wifi and I had walked through this same process, identifying
> > it as "not MFC-able" at this point because so many commits having been
> > left un-merged prior to it. I've already recently gone through the fun
> > of catching up on one and a half years worth of unmerged work in
> > stand, I'm not really prepared to do it again quite yet.
> >
> > It felt pretty bad having to tell him that his only option here was to
> > either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
> > especially since stable/11 is still supposed to be supported for
> > another three (3!) years, and I had to leave before I could help him
> > walk through getting it setup on -CURRENT properly
> >
> >
> > one has to wonder why 12.0 is so far in the future
> 
> My thoughts precisely.? If there is so much interesting content in head,
> it's time for a release.

A release of 12.0 would not remove the demands from those running 11.x
to have driver support for FOO.  It would simply give us the ability
to answer with "update to 12", while this would be a valid answer, it
is one I see as lack luster which often drives people to other platforms.

And as someone else pointed out, 11 has 3 years of life left.

-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Eric van Gyzen 
On 03/09/2018 10:00, Warner Losh wrote:
>
>
> On Fri, Mar 9, 2018 at 8:44 AM, Kyle Evans  > wrote:
>
> On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
>  > wrote:
> >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> >> > On 7 March 2018 at 09:37, John Baldwin  > wrote:
> >> > > ...
> >> > > I suspect many of these changes for iwm, etc. are all
> intertwined
> >> > > so I'm not sure if you can leave out individual ones.
> >> >
> >> > Possibly. I do have iwm working on my laptop though. I also
> know of
> >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> >> > addressing it some time this week.
> >>
> >> I often have mixed feelings when I see lots of similar changes
> (i.e.
> >> that make up for better hardware support, esp. on a laptop) MFCed.
> >> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> >> for very conservative (server?) users who can't/don't want to
> afford
> >> the risks of running -CURRENT or require ABI stability in a really
> >> long run, rather than binge-merging things. :-)
> >>
> >> By default it should be -CURRENT all over; it's a very good thing
> >> that we as a Project ourselves are doing this as part of our own
> >> dogfood eating strategy.
> >
> > As a data point just last night a person came into #freebsd irc
> > channel with a none working wireless nic on a desktop, he was
> > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
> >
> > Someone had already told him to try urtwn driver, which in
> > -current is the right driver and supports this device.
> >
> > It did not work for him.  This is about when I came in to the
> > discussion, and helped to confirm that -current did infact
> > have support for this device, and that this supported had
> > existed in -current for 16 months, and that this support
> > would not be a simple grab a couple driver files and build
> > it on 11.1.
> >
> > The commit to add this support involves 46 files, which 18
> > of are new files.
> >
> > My feelings are if this driver has been in -current for
> > 16 months why is it NOT in -stable yet?  I know part of
> > the answer "its not a simple merge".  But as a project
> > this is egg on our face.  We can merge a new very complicated
> > change to a our boot code, within a few months (thank you
> > kevans for that work), but we can not merge back a
> > device driver in 16?
> >
>
> I had the same questions- this exact same person had hopped over to
> #freebsd-wifi and I had walked through this same process, identifying
> it as "not MFC-able" at this point because so many commits having been
> left un-merged prior to it. I've already recently gone through the fun
> of catching up on one and a half years worth of unmerged work in
> stand, I'm not really prepared to do it again quite yet.
>
> It felt pretty bad having to tell him that his only option here was to
> either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
> especially since stable/11 is still supposed to be supported for
> another three (3!) years, and I had to leave before I could help him
> walk through getting it setup on -CURRENT properly
>
>
> one has to wonder why 12.0 is so far in the future

My thoughts precisely.  If there is so much interesting content in head,
it's time for a release.

Eric
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Warner Losh 
On Fri, Mar 9, 2018 at 9:09 AM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
> >  wrote:
> > >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> > >> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> > >> > > ...
> > >> > > I suspect many of these changes for iwm, etc. are all intertwined
> > >> > > so I'm not sure if you can leave out individual ones.
> > >> >
> > >> > Possibly. I do have iwm working on my laptop though. I also know of
> > >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> > >> > addressing it some time this week.
> > >>
> > >> I often have mixed feelings when I see lots of similar changes (i.e.
> > >> that make up for better hardware support, esp. on a laptop) MFCed.
> > >> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> > >> for very conservative (server?) users who can't/don't want to afford
> > >> the risks of running -CURRENT or require ABI stability in a really
> > >> long run, rather than binge-merging things. :-)
> > >>
> > >> By default it should be -CURRENT all over; it's a very good thing
> > >> that we as a Project ourselves are doing this as part of our own
> > >> dogfood eating strategy.
> > >
> > > As a data point just last night a person came into #freebsd irc
> > > channel with a none working wireless nic on a desktop, he was
> > > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
> > >
> > > Someone had already told him to try urtwn driver, which in
> > > -current is the right driver and supports this device.
> > >
> > > It did not work for him.  This is about when I came in to the
> > > discussion, and helped to confirm that -current did infact
> > > have support for this device, and that this supported had
> > > existed in -current for 16 months, and that this support
> > > would not be a simple grab a couple driver files and build
> > > it on 11.1.
> > >
> > > The commit to add this support involves 46 files, which 18
> > > of are new files.
> > >
> > > My feelings are if this driver has been in -current for
> > > 16 months why is it NOT in -stable yet?  I know part of
> > > the answer "its not a simple merge".  But as a project
> > > this is egg on our face.  We can merge a new very complicated
> > > change to a our boot code, within a few months (thank you
> > > kevans for that work), but we can not merge back a
> > > device driver in 16?
> > >
> >
> > I had the same questions- this exact same person had hopped over to
> > #freebsd-wifi and I had walked through this same process, identifying
> > it as "not MFC-able" at this point because so many commits having been
> > left un-merged prior to it. I've already recently gone through the fun
> > of catching up on one and a half years worth of unmerged work in
> > stand, I'm not really prepared to do it again quite yet.
>
> But but but.. you did it so well the first time!!! :-)
> I can fully appreciate that you do not desire to do another
> massive merge.
>
> > It felt pretty bad having to tell him that his only option here was to
> > either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
> > especially since stable/11 is still supposed to be supported for
> > another three (3!) years, and I had to leave before I could help him
> > walk through getting it setup on -CURRENT properly.
>
> When I left the #freebsd channel he was downloading, and others
> there are capable of helping him get up and running.
>
> One thing that did come up while discussing some of the issues
> with merging head to stable was it might be usefull if we add
> yet another marker line:
> Changes ABI/KABI:   yes
> to the commit messages, at least if marked you can be pretty
> sure that merging is going to involve additional work, lack
> of this mark would not guarantee you didnt have an ABI issue
> as they are easy to overlook and you would still need to
> look for those types of problems.
>

Given our past experience, it is often the case that people make changes
and aren't aware it's an ABI change, or forget that it is an ABI change
once testing is done. Or not realize a change in place X affects Y that
affects Z that makes it an ABI change. We've had several changes to CAM
that we had to redo because people didn't realize they were breaking
something. And at least one of them I approved knowing what changed, but
not groking the implications of the change.


> I have been told by someone there are some tools that can
> mechanically look for ABI changes.
>

This is the only way forward that may work, but it's much harder in the
kernel where the interfaces aren't well enumerated.

But we have to look at why so much is desirable to MFC. It's been a long
time since a major release and a lot has gone into 12 on the assumption the
release would be maybe 30 months from 11.0. The current schedule doesn't
have it going out for quite some time. Another

Re: svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Rodney W. Grimes 
> On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
>  wrote:
> >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> >> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> >> > > ...
> >> > > I suspect many of these changes for iwm, etc. are all intertwined
> >> > > so I'm not sure if you can leave out individual ones.
> >> >
> >> > Possibly. I do have iwm working on my laptop though. I also know of
> >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> >> > addressing it some time this week.
> >>
> >> I often have mixed feelings when I see lots of similar changes (i.e.
> >> that make up for better hardware support, esp. on a laptop) MFCed.
> >> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> >> for very conservative (server?) users who can't/don't want to afford
> >> the risks of running -CURRENT or require ABI stability in a really
> >> long run, rather than binge-merging things. :-)
> >>
> >> By default it should be -CURRENT all over; it's a very good thing
> >> that we as a Project ourselves are doing this as part of our own
> >> dogfood eating strategy.
> >
> > As a data point just last night a person came into #freebsd irc
> > channel with a none working wireless nic on a desktop, he was
> > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
> >
> > Someone had already told him to try urtwn driver, which in
> > -current is the right driver and supports this device.
> >
> > It did not work for him.  This is about when I came in to the
> > discussion, and helped to confirm that -current did infact
> > have support for this device, and that this supported had
> > existed in -current for 16 months, and that this support
> > would not be a simple grab a couple driver files and build
> > it on 11.1.
> >
> > The commit to add this support involves 46 files, which 18
> > of are new files.
> >
> > My feelings are if this driver has been in -current for
> > 16 months why is it NOT in -stable yet?  I know part of
> > the answer "its not a simple merge".  But as a project
> > this is egg on our face.  We can merge a new very complicated
> > change to a our boot code, within a few months (thank you
> > kevans for that work), but we can not merge back a
> > device driver in 16?
> >
> 
> I had the same questions- this exact same person had hopped over to
> #freebsd-wifi and I had walked through this same process, identifying
> it as "not MFC-able" at this point because so many commits having been
> left un-merged prior to it. I've already recently gone through the fun
> of catching up on one and a half years worth of unmerged work in
> stand, I'm not really prepared to do it again quite yet.

But but but.. you did it so well the first time!!! :-)
I can fully appreciate that you do not desire to do another
massive merge. 

> It felt pretty bad having to tell him that his only option here was to
> either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
> especially since stable/11 is still supposed to be supported for
> another three (3!) years, and I had to leave before I could help him
> walk through getting it setup on -CURRENT properly.

When I left the #freebsd channel he was downloading, and others
there are capable of helping him get up and running.

One thing that did come up while discussing some of the issues
with merging head to stable was it might be usefull if we add
yet another marker line:
Changes ABI/KABI:   yes
to the commit messages, at least if marked you can be pretty
sure that merging is going to involve additional work, lack
of this mark would not guarantee you didnt have an ABI issue
as they are easy to overlook and you would still need to
look for those types of problems.

I have been told by someone there are some tools that can
mechanically look for ABI changes.

-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Warner Losh 
On Fri, Mar 9, 2018 at 8:44 AM, Kyle Evans  wrote:

> On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
>  wrote:
> >> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> >> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> >> > > ...
> >> > > I suspect many of these changes for iwm, etc. are all intertwined
> >> > > so I'm not sure if you can leave out individual ones.
> >> >
> >> > Possibly. I do have iwm working on my laptop though. I also know of
> >> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> >> > addressing it some time this week.
> >>
> >> I often have mixed feelings when I see lots of similar changes (i.e.
> >> that make up for better hardware support, esp. on a laptop) MFCed.
> >> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> >> for very conservative (server?) users who can't/don't want to afford
> >> the risks of running -CURRENT or require ABI stability in a really
> >> long run, rather than binge-merging things. :-)
> >>
> >> By default it should be -CURRENT all over; it's a very good thing
> >> that we as a Project ourselves are doing this as part of our own
> >> dogfood eating strategy.
> >
> > As a data point just last night a person came into #freebsd irc
> > channel with a none working wireless nic on a desktop, he was
> > attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
> >
> > Someone had already told him to try urtwn driver, which in
> > -current is the right driver and supports this device.
> >
> > It did not work for him.  This is about when I came in to the
> > discussion, and helped to confirm that -current did infact
> > have support for this device, and that this supported had
> > existed in -current for 16 months, and that this support
> > would not be a simple grab a couple driver files and build
> > it on 11.1.
> >
> > The commit to add this support involves 46 files, which 18
> > of are new files.
> >
> > My feelings are if this driver has been in -current for
> > 16 months why is it NOT in -stable yet?  I know part of
> > the answer "its not a simple merge".  But as a project
> > this is egg on our face.  We can merge a new very complicated
> > change to a our boot code, within a few months (thank you
> > kevans for that work), but we can not merge back a
> > device driver in 16?
> >
>
> I had the same questions- this exact same person had hopped over to
> #freebsd-wifi and I had walked through this same process, identifying
> it as "not MFC-able" at this point because so many commits having been
> left un-merged prior to it. I've already recently gone through the fun
> of catching up on one and a half years worth of unmerged work in
> stand, I'm not really prepared to do it again quite yet.
>
> It felt pretty bad having to tell him that his only option here was to
> either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
> especially since stable/11 is still supposed to be supported for
> another three (3!) years, and I had to leave before I could help him
> walk through getting it setup on -CURRENT properly
>

one has to wonder why 12.0 is so far in the future

Warner
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Kyle Evans 
On Fri, Mar 9, 2018 at 9:28 AM, Rodney W. Grimes
 wrote:
>> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
>> > On 7 March 2018 at 09:37, John Baldwin  wrote:
>> > > ...
>> > > I suspect many of these changes for iwm, etc. are all intertwined
>> > > so I'm not sure if you can leave out individual ones.
>> >
>> > Possibly. I do have iwm working on my laptop though. I also know of
>> > one open PR assigned to me w.r.t. a model I don't own. I'll be
>> > addressing it some time this week.
>>
>> I often have mixed feelings when I see lots of similar changes (i.e.
>> that make up for better hardware support, esp. on a laptop) MFCed.
>> I'd rather see laptop users run -CURRENT and leave -STABLE branches
>> for very conservative (server?) users who can't/don't want to afford
>> the risks of running -CURRENT or require ABI stability in a really
>> long run, rather than binge-merging things. :-)
>>
>> By default it should be -CURRENT all over; it's a very good thing
>> that we as a Project ourselves are doing this as part of our own
>> dogfood eating strategy.
>
> As a data point just last night a person came into #freebsd irc
> channel with a none working wireless nic on a desktop, he was
> attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.
>
> Someone had already told him to try urtwn driver, which in
> -current is the right driver and supports this device.
>
> It did not work for him.  This is about when I came in to the
> discussion, and helped to confirm that -current did infact
> have support for this device, and that this supported had
> existed in -current for 16 months, and that this support
> would not be a simple grab a couple driver files and build
> it on 11.1.
>
> The commit to add this support involves 46 files, which 18
> of are new files.
>
> My feelings are if this driver has been in -current for
> 16 months why is it NOT in -stable yet?  I know part of
> the answer "its not a simple merge".  But as a project
> this is egg on our face.  We can merge a new very complicated
> change to a our boot code, within a few months (thank you
> kevans for that work), but we can not merge back a
> device driver in 16?
>

I had the same questions- this exact same person had hopped over to
#freebsd-wifi and I had walked through this same process, identifying
it as "not MFC-able" at this point because so many commits having been
left un-merged prior to it. I've already recently gone through the fun
of catching up on one and a half years worth of unmerged work in
stand, I'm not really prepared to do it again quite yet.

It felt pretty bad having to tell him that his only option here was to
either hop on -CURRENT + rtwn(4) or grab a stable/11 supported NIC-
especially since stable/11 is still supposed to be supported for
another three (3!) years, and I had to leave before I could help him
walk through getting it setup on -CURRENT properly.
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Rodney W. Grimes 
> On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> > > ...
> > > I suspect many of these changes for iwm, etc. are all intertwined
> > > so I'm not sure if you can leave out individual ones.
> > 
> > Possibly. I do have iwm working on my laptop though. I also know of
> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> > addressing it some time this week.
> 
> I often have mixed feelings when I see lots of similar changes (i.e.
> that make up for better hardware support, esp. on a laptop) MFCed.
> I'd rather see laptop users run -CURRENT and leave -STABLE branches
> for very conservative (server?) users who can't/don't want to afford
> the risks of running -CURRENT or require ABI stability in a really
> long run, rather than binge-merging things. :-)
> 
> By default it should be -CURRENT all over; it's a very good thing
> that we as a Project ourselves are doing this as part of our own
> dogfood eating strategy.

As a data point just last night a person came into #freebsd irc
channel with a none working wireless nic on a desktop, he was
attemtping to use a Realteak RTL8192EU on 11.1-RELEASE.

Someone had already told him to try urtwn driver, which in
-current is the right driver and supports this device.

It did not work for him.  This is about when I came in to the
discussion, and helped to confirm that -current did infact
have support for this device, and that this supported had
existed in -current for 16 months, and that this support
would not be a simple grab a couple driver files and build
it on 11.1.

The commit to add this support involves 46 files, which 18
of are new files.

My feelings are if this driver has been in -current for
16 months why is it NOT in -stable yet?  I know part of
the answer "its not a simple merge".  But as a project
this is egg on our face.  We can merge a new very complicated
change to a our boot code, within a few months (thank you
kevans for that work), but we can not merge back a
device driver in 16?

As a semi- regular visit to the FreeBSD irc help room,
I try to go there once a month and spend 8 hours helping
people with any problem them might have, I see this lack
of driver support in stable/ regularly.  On my last visit
it was the iwn driver adding 8565 support, I reached out
to GNN who did the -current work, again a significant
time ago, the commit had a MFC: 1 month in it.  George
replied to me that it turned out to be non-trivial to
merge due to other dependencies.  I procurred an offer
from the reporting person to test patches if I could
get them put togeather, and he accepted.  George agreed
to review these patches for me.

A few days later eadler merged a good deal of code in
this area.  I informed George of concerns about that
and left it lie.

Jhb stepped in and clearly identified abi breakage,
which I believe has been reverted.  

I have made an offer to eadler to pass my tester of
the Intel 8565 on to him, which I have received no reply
from him, but from someone else that said they would
test it "this weekend"  I do not know if stable/11 is
in a state that this driver should or should not
work now.

Regards,
-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-09 Thread Alexey Dokuchaev 
On Wed, Mar 07, 2018 at 02:53:49PM -0800, Eitan Adler wrote:
> On 7 March 2018 at 09:37, John Baldwin  wrote:
> > ...
> > I suspect many of these changes for iwm, etc. are all intertwined
> > so I'm not sure if you can leave out individual ones.
> 
> Possibly. I do have iwm working on my laptop though. I also know of
> one open PR assigned to me w.r.t. a model I don't own. I'll be
> addressing it some time this week.

I often have mixed feelings when I see lots of similar changes (i.e.
that make up for better hardware support, esp. on a laptop) MFCed.
I'd rather see laptop users run -CURRENT and leave -STABLE branches
for very conservative (server?) users who can't/don't want to afford
the risks of running -CURRENT or require ABI stability in a really
long run, rather than binge-merging things. :-)

By default it should be -CURRENT all over; it's a very good thing
that we as a Project ourselves are doing this as part of our own
dogfood eating strategy.

./danfe
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-08 Thread Pintér , Olivér 
On Thu, Mar 8, 2018 at 12:18 AM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On 7 March 2018 at 09:37, John Baldwin  wrote:
> > > On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
> > >> On 6 March 2018 at 08:26, John Baldwin  wrote:
> > >> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
> > >> >> On 5 March 2018 at 10:08, John Baldwin  wrote:
> > >> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
> > >> >> >> Author: eadler
> > >> >> >> Date: Mon Mar  5 07:54:57 2018
> > >> >> >> New Revision: 330451
> > >> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451
> > >> >> >>
> > >> >> >> Log:
> > >> >> >>   MFC r306837:
> > >> >> >>
> > >> >> >>   [net80211] extend the ieee80211_rx_stats struct to include
> more information.
> > >> >> >
> > >> >> > Have you thought about the KBI implications of this change and
> some of the
> > >> >> > other changes you've merged?
> > >> >>
> > >> >> I do have a copy of the modules from 11.1 and have loaded them at
> > >> >> various points in time after merging. That said, I am not perfect.
> > >> >> Unfortunately, my -STABLE box did not have fully functioning
> drivers
> > >> >> before these changes so its difficult to test anything beyond
> "loads
> > >> >> and does not panic.". I havn't done so today yet, but that will
> happen
> > >> >> soon.
> > >> >>
> > >> >> Ensuring these things work through code inspection is certainly
> > >> >> possible and I've skipped over several changes as a result.
> > >> >
> > >> > Loading a module doesn't alone doesn't actually test for breakage.
> > >>
> > >> I'm aware. In this case I should likely just revert this change since
> > >> its a pretty blatant break.
> > >
> > > I suspect many of these changes for iwm, etc. are all intertwined so
> I'm not
> > > sure if you can leave out individual ones.
> >
> > Possibly. I do have iwm working on my laptop though. I also know of
> > one open PR assigned to me w.r.t. a model I don't own. I'll be
> > addressing it some time this week.
>
> I believe I also have a tester of stable/11 iwm patches avaliable,
> he has an 8265?
>

At weekend I will test them.


>
> --
> Rod Grimes
> rgri...@freebsd.org
> ___
> svn-src-stable...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
> To unsubscribe, send any mail to "svn-src-stable-11-
> unsubscr...@freebsd.org"
>
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-07 Thread Rodney W. Grimes 
> On 7 March 2018 at 09:37, John Baldwin  wrote:
> > On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
> >> On 6 March 2018 at 08:26, John Baldwin  wrote:
> >> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
> >> >> On 5 March 2018 at 10:08, John Baldwin  wrote:
> >> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
> >> >> >> Author: eadler
> >> >> >> Date: Mon Mar  5 07:54:57 2018
> >> >> >> New Revision: 330451
> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451
> >> >> >>
> >> >> >> Log:
> >> >> >>   MFC r306837:
> >> >> >>
> >> >> >>   [net80211] extend the ieee80211_rx_stats struct to include more 
> >> >> >> information.
> >> >> >
> >> >> > Have you thought about the KBI implications of this change and some 
> >> >> > of the
> >> >> > other changes you've merged?
> >> >>
> >> >> I do have a copy of the modules from 11.1 and have loaded them at
> >> >> various points in time after merging. That said, I am not perfect.
> >> >> Unfortunately, my -STABLE box did not have fully functioning drivers
> >> >> before these changes so its difficult to test anything beyond "loads
> >> >> and does not panic.". I havn't done so today yet, but that will happen
> >> >> soon.
> >> >>
> >> >> Ensuring these things work through code inspection is certainly
> >> >> possible and I've skipped over several changes as a result.
> >> >
> >> > Loading a module doesn't alone doesn't actually test for breakage.
> >>
> >> I'm aware. In this case I should likely just revert this change since
> >> its a pretty blatant break.
> >
> > I suspect many of these changes for iwm, etc. are all intertwined so I'm not
> > sure if you can leave out individual ones.
> 
> Possibly. I do have iwm working on my laptop though. I also know of
> one open PR assigned to me w.r.t. a model I don't own. I'll be
> addressing it some time this week.

I believe I also have a tester of stable/11 iwm patches avaliable,
he has an 8265?

-- 
Rod Grimes rgri...@freebsd.org
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-07 Thread Eitan Adler 
On 7 March 2018 at 09:37, John Baldwin  wrote:
> On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
>> On 6 March 2018 at 08:26, John Baldwin  wrote:
>> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
>> >> On 5 March 2018 at 10:08, John Baldwin  wrote:
>> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
>> >> >> Author: eadler
>> >> >> Date: Mon Mar  5 07:54:57 2018
>> >> >> New Revision: 330451
>> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451
>> >> >>
>> >> >> Log:
>> >> >>   MFC r306837:
>> >> >>
>> >> >>   [net80211] extend the ieee80211_rx_stats struct to include more 
>> >> >> information.
>> >> >
>> >> > Have you thought about the KBI implications of this change and some of 
>> >> > the
>> >> > other changes you've merged?
>> >>
>> >> I do have a copy of the modules from 11.1 and have loaded them at
>> >> various points in time after merging. That said, I am not perfect.
>> >> Unfortunately, my -STABLE box did not have fully functioning drivers
>> >> before these changes so its difficult to test anything beyond "loads
>> >> and does not panic.". I havn't done so today yet, but that will happen
>> >> soon.
>> >>
>> >> Ensuring these things work through code inspection is certainly
>> >> possible and I've skipped over several changes as a result.
>> >
>> > Loading a module doesn't alone doesn't actually test for breakage.
>>
>> I'm aware. In this case I should likely just revert this change since
>> its a pretty blatant break.
>
> I suspect many of these changes for iwm, etc. are all intertwined so I'm not
> sure if you can leave out individual ones.

Possibly. I do have iwm working on my laptop though. I also know of
one open PR assigned to me w.r.t. a model I don't own. I'll be
addressing it some time this week.

>> > Batching
>> > up changes into a single diff is also helpful since if an API changes back
>> > and forth in HEAD multiple times, collapsing them means that for stable you
>> > may only need a single compat shim rather than several.
>>
>> Understood. My intention in doing them one-by-one was to make it
>> easier to bisect if something goes wrong.
>
> For stable I think we also want to balance this with:
>
> 1) Not putting stable in a known-broken state.  If there are followup fixes
>either for compile or runtime performances, those followup fixes should
>always be included in the commit that merges the original change.

To the extent possible I tried to do this.

> 2) Preserving ABI.  The desire to avoid putting stable into known-broken
>state means that MFCs should include the ABI shims along with the original
>change.

This part I missed very clearly. I'll be sure to be more careful in the future.





-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-07 Thread Adrian Chadd 
(*whispers* you have to upgrade everything all at ooonnnce.)



-adrian
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-07 Thread John Baldwin 
On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
> On 6 March 2018 at 08:26, John Baldwin  wrote:
> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
> >> On 5 March 2018 at 10:08, John Baldwin  wrote:
> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
> >> >> Author: eadler
> >> >> Date: Mon Mar  5 07:54:57 2018
> >> >> New Revision: 330451
> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451
> >> >>
> >> >> Log:
> >> >>   MFC r306837:
> >> >>
> >> >>   [net80211] extend the ieee80211_rx_stats struct to include more 
> >> >> information.
> >> >
> >> > Have you thought about the KBI implications of this change and some of 
> >> > the
> >> > other changes you've merged?
> >>
> >> I do have a copy of the modules from 11.1 and have loaded them at
> >> various points in time after merging. That said, I am not perfect.
> >> Unfortunately, my -STABLE box did not have fully functioning drivers
> >> before these changes so its difficult to test anything beyond "loads
> >> and does not panic.". I havn't done so today yet, but that will happen
> >> soon.
> >>
> >> Ensuring these things work through code inspection is certainly
> >> possible and I've skipped over several changes as a result.
> >
> > Loading a module doesn't alone doesn't actually test for breakage.
> 
> I'm aware. In this case I should likely just revert this change since
> its a pretty blatant break.

I suspect many of these changes for iwm, etc. are all intertwined so I'm not
sure if you can leave out individual ones.
 
> > Batching
> > up changes into a single diff is also helpful since if an API changes back
> > and forth in HEAD multiple times, collapsing them means that for stable you
> > may only need a single compat shim rather than several.
> 
> Understood. My intention in doing them one-by-one was to make it
> easier to bisect if something goes wrong.

For stable I think we also want to balance this with:

1) Not putting stable in a known-broken state.  If there are followup fixes
   either for compile or runtime performances, those followup fixes should
   always be included in the commit that merges the original change.

2) Preserving ABI.  The desire to avoid putting stable into known-broken
   state means that MFCs should include the ABI shims along with the original
   change.

-- 
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-06 Thread Eitan Adler 
On 6 March 2018 at 08:26, John Baldwin  wrote:
> On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
>> On 5 March 2018 at 10:08, John Baldwin  wrote:
>> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
>> >> Author: eadler
>> >> Date: Mon Mar  5 07:54:57 2018
>> >> New Revision: 330451
>> >> URL: https://svnweb.freebsd.org/changeset/base/330451
>> >>
>> >> Log:
>> >>   MFC r306837:
>> >>
>> >>   [net80211] extend the ieee80211_rx_stats struct to include more 
>> >> information.
>> >
>> > Have you thought about the KBI implications of this change and some of the
>> > other changes you've merged?
>>
>> I do have a copy of the modules from 11.1 and have loaded them at
>> various points in time after merging. That said, I am not perfect.
>> Unfortunately, my -STABLE box did not have fully functioning drivers
>> before these changes so its difficult to test anything beyond "loads
>> and does not panic.". I havn't done so today yet, but that will happen
>> soon.
>>
>> Ensuring these things work through code inspection is certainly
>> possible and I've skipped over several changes as a result.
>
> Loading a module doesn't alone doesn't actually test for breakage.

I'm aware. In this case I should likely just revert this change since
its a pretty blatant break.

>   It also tends to be a lot harder to find these
> breakages in code one didn't write.

This is true

> I think for net80211 you need to generate a diff of all of the wireless
> related changes you have MFC'd to stable/11 and then review that for ABI
> changes and come up with a plan for how to restore the ABI and get re@'s
> approval.  (kib@ is a pretty good resource for devising ABI shims.)

I'll take a look to see what else I broke / changed and either revert
or write up a shim. Thanks!


> Batching
> up changes into a single diff is also helpful since if an API changes back
> and forth in HEAD multiple times, collapsing them means that for stable you
> may only need a single compat shim rather than several.

Understood. My intention in doing them one-by-one was to make it
easier to bisect if something goes wrong.


-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-06 Thread Alexey Dokuchaev 
On Tue, Mar 06, 2018 at 08:26:43AM -0800, John Baldwin wrote:
> The fact that there are back-to-back ABI breakages also suggests that it is
> much better to consolidate MFCs into larger commits [...]

+1.

> I think that going forward you shouldn't MFC changes if you aren't certain
> about the ABI implications until you have had someone review them.  Batching
> up changes into a single diff is also helpful since if an API changes back
> and forth in HEAD multiple times, collapsing them means that for stable you
> may only need a single compat shim rather than several.

+1.

./danfe
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-06 Thread John Baldwin 
On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
> On 5 March 2018 at 10:08, John Baldwin  wrote:
> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
> >> Author: eadler
> >> Date: Mon Mar  5 07:54:57 2018
> >> New Revision: 330451
> >> URL: https://svnweb.freebsd.org/changeset/base/330451
> >>
> >> Log:
> >>   MFC r306837:
> >>
> >>   [net80211] extend the ieee80211_rx_stats struct to include more 
> >> information.
> >
> > Have you thought about the KBI implications of this change and some of the
> > other changes you've merged?
> 
> I do have a copy of the modules from 11.1 and have loaded them at
> various points in time after merging. That said, I am not perfect.
> Unfortunately, my -STABLE box did not have fully functioning drivers
> before these changes so its difficult to test anything beyond "loads
> and does not panic.". I havn't done so today yet, but that will happen
> soon.
> 
> Ensuring these things work through code inspection is certainly
> possible and I've skipped over several changes as a result.

Loading a module doesn't alone doesn't actually test for breakage.  That only
breaks if you remove symbols.  Changing the semantics of how functions work
or the layout of a structure that is passed between structures is an ABI change
even if it doesn't change the function signature.  In this case, this change
inserts new fields and changes the size of 'struct ieee80211_rx_stats'.  Thus
if a otus(4) or iwm(4) driver built against the prior revision (330450) is
used with a kernel built with this revision (330451), the driver will pass in
an 'rxs' structure in a call to ieee80211_input_mimo() that is smaller, and
in the first few lines of i80211_input_mimo() these statements will
overflow that pointer and read stack garbage:

85  int
86  ieee80211_input_mimo(struct ieee80211_node *ni, struct mbuf *m,
87  struct ieee80211_rx_stats *rx)
88  {
89  struct ieee80211_rx_stats rxs;
90  
91  if (rx) {
92  memcpy(, rx, sizeof(*rx));
93  } else {

Furthermore, the now garbage 'rxs' (since fields in *rx are in different
places so even the bits of 'rxs' that isn't stack garbage will be wrong)
will now be used by other routines in net80211.  Your next MFC commit then
causes another ABI breakage as it removes the 'rx' parameter from the
function.  You can't do that.  If you don't know how to recognize those types
of ABI breakages, then you probably shouldn't be MFC'ing changes without
getting some sort of review.  It also tends to be a lot harder to find these
breakages in code one didn't write.

The fact that there are back-to-back ABI breakages also suggests that it is
much better to consolidate MFCs into larger commits because you limit the
amount of compatibilty ABI shims you have to provide.

I think for net80211 you need to generate a diff of all of the wireless
related changes you have MFC'd to stable/11 and then review that for ABI
changes and come up with a plan for how to restore the ABI and get re@'s
approval.  (kib@ is a pretty good resource for devising ABI shims.)

I think that going forward you shouldn't MFC changes if you aren't certain
about the ABI implications until you have had someone review them.  Batching
up changes into a single diff is also helpful since if an API changes back
and forth in HEAD multiple times, collapsing them means that for stable you
may only need a single compat shim rather than several.

-- 
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-05 Thread Eitan Adler 
On 5 March 2018 at 10:08, John Baldwin  wrote:
> On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
>> Author: eadler
>> Date: Mon Mar  5 07:54:57 2018
>> New Revision: 330451
>> URL: https://svnweb.freebsd.org/changeset/base/330451
>>
>> Log:
>>   MFC r306837:
>>
>>   [net80211] extend the ieee80211_rx_stats struct to include more 
>> information.
>
> Have you thought about the KBI implications of this change and some of the
> other changes you've merged?

I do have a copy of the modules from 11.1 and have loaded them at
various points in time after merging. That said, I am not perfect.
Unfortunately, my -STABLE box did not have fully functioning drivers
before these changes so its difficult to test anything beyond "loads
and does not panic.". I havn't done so today yet, but that will happen
soon.

Ensuring these things work through code inspection is certainly
possible and I've skipped over several changes as a result.


-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-05 Thread John Baldwin 
On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote:
> Author: eadler
> Date: Mon Mar  5 07:54:57 2018
> New Revision: 330451
> URL: https://svnweb.freebsd.org/changeset/base/330451
> 
> Log:
>   MFC r306837:
>   
>   [net80211] extend the ieee80211_rx_stats struct to include more information.

Have you thought about the KBI implications of this change and some of the
other changes you've merged?  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.  If this structure is used by
any device drivers directly then changing its layout would seem to break
existing modules that were built against the old ABI and pass in pointers to
the old structures to functions in the kernel.  There are some fuzzy areas in
the ABI we try to preserve, but we generally try to keep drivers working.

Also, we may choose to break the ABI if there is a strong argument for it,
but then that is usually something discussed with re@ and noted in the commit
log and UPDATING.

-- 
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"

svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

2018-03-04 Thread Eitan Adler 
Author: eadler
Date: Mon Mar  5 07:54:57 2018
New Revision: 330451
URL: https://svnweb.freebsd.org/changeset/base/330451

Log:
  MFC r306837:
  
  [net80211] extend the ieee80211_rx_stats struct to include more information.
  
  There are a variety of more interesting RX statistics that we should
  keep track of but we don't.  This is a starting point for adding more
  information.
  
  Specifically:
  
  * now the RX rate information and some of the packet status is
passed up;
  * The 32 bit or 64 bit TSF is passed up;
  * the PHY mode is passed up;
  * the "I'm decap'ed AMSDU!" state is passed up;
  * number of RX chains is bumped to 4.
  
  This is all mostly a placeholder for getting the data into the RX status
  before we pass it up to net80211 - unfortunately we don't yet enforce
  that drivers provide it, nor do we pass the provided info back up the
  stack so anyone can use the data.
  
  We're going to need to use some of this data moving forward.
  Notably, now that some hardware can do AMSDU decap for us (the intel iwm
  driver can do it when we flip it on; the ath10k port I'm doing does
  it for us) then we need to pass it up through the stack so the duplicate
  RX sequence numbers and crypto/IV details don't cause the packet to
  be dropped and/or counted against a replay counter.
  
  It's also the beginning of being able to do more interesting node
  accounting in net80211.  Specifically, once drivers start populating
  per-packet rate information, AMPDU information, timestamps, etc,
  we can start providing histograms of rate-versus-RSSI, account
  for receive time spent per node and other such interesting things.
  
  (Note: I'm also hoping to include ranging and RTT information for
  future chipset support; and it's likely going to include it in
  this kind of fashion.)

Modified:
  stable/11/sys/dev/iwm/if_iwm.c
  stable/11/sys/dev/otus/if_otus.c
  stable/11/sys/dev/usb/wlan/if_rsu.c
  stable/11/sys/net80211/ieee80211_freebsd.h
  stable/11/sys/net80211/ieee80211_input.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/dev/iwm/if_iwm.c
==
--- stable/11/sys/dev/iwm/if_iwm.c  Mon Mar  5 07:33:00 2018
(r330450)
+++ stable/11/sys/dev/iwm/if_iwm.c  Mon Mar  5 07:54:57 2018
(r330451)
@@ -3259,8 +3259,8 @@ iwm_mvm_rx_rx_mpdu(struct iwm_softc *sc, struct mbuf *
}
 
/* rssi is in 1/2db units */
-   rxs.rssi = rssi * 2;
-   rxs.nf = sc->sc_noise;
+   rxs.c_rssi = rssi * 2;
+   rxs.c_nf = sc->sc_noise;
 
if (ieee80211_radiotap_active_vap(vap)) {
struct iwm_rx_radiotap_header *tap = >sc_rxtap;

Modified: stable/11/sys/dev/otus/if_otus.c
==
--- stable/11/sys/dev/otus/if_otus.cMon Mar  5 07:33:00 2018
(r330450)
+++ stable/11/sys/dev/otus/if_otus.cMon Mar  5 07:54:57 2018
(r330451)
@@ -1710,8 +1710,8 @@ otus_sub_rxeof(struct otus_softc *sc, uint8_t *buf, in
/* Add RSSI/NF to this mbuf */
bzero(, sizeof(rxs));
rxs.r_flags = IEEE80211_R_NF | IEEE80211_R_RSSI;
-   rxs.nf = sc->sc_nf[0];  /* XXX chain 0 != combined rssi/nf */
-   rxs.rssi = tail->rssi;
+   rxs.c_nf = sc->sc_nf[0];/* XXX chain 0 != combined rssi/nf */
+   rxs.c_rssi = tail->rssi;
/* XXX TODO: add MIMO RSSI/NF as well */
ieee80211_add_rx_params(m, );
 

Modified: stable/11/sys/dev/usb/wlan/if_rsu.c
==
--- stable/11/sys/dev/usb/wlan/if_rsu.c Mon Mar  5 07:33:00 2018
(r330450)
+++ stable/11/sys/dev/usb/wlan/if_rsu.c Mon Mar  5 07:54:57 2018
(r330451)
@@ -1540,8 +1540,8 @@ rsu_event_survey(struct rsu_softc *sc, uint8_t *buf, i
rxs.c_ieee = le32toh(bss->config.dsconfig);
rxs.c_freq = ieee80211_ieee2mhz(rxs.c_ieee, IEEE80211_CHAN_2GHZ);
/* This is a number from 0..100; so let's just divide it down a bit */
-   rxs.rssi = le32toh(bss->rssi) / 2;
-   rxs.nf = -96;
+   rxs.c_rssi = le32toh(bss->rssi) / 2;
+   rxs.c_nf = -96;
 
/* XXX avoid a LOR */
RSU_UNLOCK(sc);

Modified: stable/11/sys/net80211/ieee80211_freebsd.h
==
--- stable/11/sys/net80211/ieee80211_freebsd.h  Mon Mar  5 07:33:00 2018
(r330450)
+++ stable/11/sys/net80211/ieee80211_freebsd.h  Mon Mar  5 07:54:57 2018
(r330451)
@@ -620,33 +620,82 @@ int   ieee80211_add_xmit_params(struct mbuf *m,
 intieee80211_get_xmit_params(struct mbuf *m,
struct ieee80211_bpf_params *);
 
-#defineIEEE80211_MAX_CHAINS3
+/*
+ * Note: this is fine for 3x3 (and 4x4) 11n HT40;
+ * but getting EVM information for VHT80, VHT160
+ * will involve more than 6 EVM pilots.
+ */
+#define