Re: CVS commit: src/sys/dev

[maya]

On Fri, May 11, 2018 at 04:29:22PM +, Christos Zoulas wrote:
> In article ,
> Jason Thorpe   wrote:
> >
> >
> >> On May 11, 2018, at 12:41 AM, Maya Rashish  wrote:
> >> 
> >> Module Name:   src
> >> Committed By:  maya
> >> Date:  Fri May 11 07:41:11 UTC 2018
> >> 
> >> Modified Files:
> >>src/sys/dev/ic: bwfm.c bwfmreg.h bwfmvar.h
> >>src/sys/dev/sdmmc: if_bwfm_sdio.c
> >>src/sys/dev/usb: if_bwfm_usb.c
> >
> >It’s really helpful to also synchronize the foreign RCS ID tags when
> >you’re synchronizing the code; not just blindly synchronize them, of
> >course, but to correctly reflect what version of the code we’re on par
> >with.  Can you go back and do so with these changes?
> 
> Mail.app --> Edit --> Substitutions --> Smart Quotes :-)

ITYM export LC_ALL=en_US.UTF-8

Re: CVS commit: src/sys/dev

[Jason Thorpe]

Still, it’ll make it easier if we ever need to consult the foreign driver 
again.  A starting point to start looking at their diffs.

-- thorpej
Sent from my iPhone.

> On May 11, 2018, at 9:56 AM, m...@netbsd.org wrote:
> 
> initially I picked up the revisions one by one, but found out some
> of my changes were broken and undid them, and wanted to stick
> to minimal changes to a working driver.
> 
> jared said that our driver is intentionally different too.

Re: CVS commit: src/sys/dev

[maya]

initially I picked up the revisions one by one, but found out some
of my changes were broken and undid them, and wanted to stick
to minimal changes to a working driver.

jared said that our driver is intentionally different too.

Re: CVS commit: src/sys/dev

[Christos Zoulas]

In article ,
Jason Thorpe   wrote:
>
>
>> On May 11, 2018, at 12:41 AM, Maya Rashish  wrote:
>> 
>> Module Name: src
>> Committed By:maya
>> Date:Fri May 11 07:41:11 UTC 2018
>> 
>> Modified Files:
>>  src/sys/dev/ic: bwfm.c bwfmreg.h bwfmvar.h
>>  src/sys/dev/sdmmc: if_bwfm_sdio.c
>>  src/sys/dev/usb: if_bwfm_usb.c
>
>It’s really helpful to also synchronize the foreign RCS ID tags when
>you’re synchronizing the code; not just blindly synchronize them, of
>course, but to correctly reflect what version of the code we’re on par
>with.  Can you go back and do so with these changes?

Mail.app --> Edit --> Substitutions --> Smart Quotes :-)

christos

Re: CVS commit: src/sys/dev

[Jason Thorpe]

> On May 11, 2018, at 12:41 AM, Maya Rashish  wrote:
> 
> Module Name:  src
> Committed By: maya
> Date: Fri May 11 07:41:11 UTC 2018
> 
> Modified Files:
>   src/sys/dev/ic: bwfm.c bwfmreg.h bwfmvar.h
>   src/sys/dev/sdmmc: if_bwfm_sdio.c
>   src/sys/dev/usb: if_bwfm_usb.c

It’s really helpful to also synchronize the foreign RCS ID tags when you’re 
synchronizing the code; not just blindly synchronize them, of course, but to 
correctly reflect what version of the code we’re on par with.  Can you go back 
and do so with these changes?

> 
> Log Message:
> sync with openbsd bwfm to some extent.

Can you outline which changes you skipped?

> 
> add a txcheck
> set chip active/passive for more kinds of chips
> add wrapper around setting active/passive
> detect chip RAM
> make bwfm_rx take an mbuf
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.10 -r1.11 src/sys/dev/ic/bwfm.c
> cvs rdiff -u -r1.2 -r1.3 src/sys/dev/ic/bwfmreg.h
> cvs rdiff -u -r1.1 -r1.2 src/sys/dev/ic/bwfmvar.h
> cvs rdiff -u -r1.2 -r1.3 src/sys/dev/sdmmc/if_bwfm_sdio.c
> cvs rdiff -u -r1.4 -r1.5 src/sys/dev/usb/if_bwfm_usb.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

-- thorpej

Re: CVS commit: src/sys

[Robert Elz]

Date:Fri, 11 May 2018 12:49:11 +0100
From:Roy Marples 
Message-ID:  <99536ae5-2bcf-c8d5-7c39-f0436c6d1...@marples.name>

[Taking your reply out of order...]

  | The cvs commit increases the default size of the ICMP6 receive socket, 
  | so it's not incidental at all.

If that were true, the problem would not be fixed, as even with the bigger 
buffer,
the problem could still happen.

  | The address could also have been lost due to dhcpcd not seeing the RA 
  | the IPv6 router sent and thus timing out.

Yes.

  | This could be due to the ICMP6 receive socket overflowing and thus the 
  | kernel discards the RA.

Yes - and I have always agreed that for dhcpd learning that routing
messages have been lost, so it can react is a good idea.   It could be
for other routing daemons too, though most of those have other
recovery mechanisms.

That the problem was fixed by the dhcpcd changes was indicated in
the PR by this fragment ...

   The patch has the desired effect.  I see a couple of the
   "ipv6nd_handledata: No buffer space available" messages in the log
   from this morning, which at this point is about 5 hours ago.  Since
   then, I've also seen the usual dance where the default router expires
   and it settles on the right one again.  I still have an IPv6 address
   and my IPv6 connections are still good.

That is, even with the lost messages still being reported, everything
was good.  At that point the problem was fixed.

Also note I don't object to making the receive buffers bigger, so it is
less likely that messages will be lost - just to calling that a "fix" for
anything at all.   It isn't.

kre

Re: CVS commit: src/sys

[Roy Marples]

On 11/05/2018 12:24, Robert Elz wrote:

 Date:Fri, 11 May 2018 12:03:19 +0100
 From:Roy Marples 
 Message-ID:  

   | However, the normal amount of noise generated in his environment is no
   | longer generating any overflow messages so his problem report is indeed
   | fixed.

The PR was "loss of IPv6 address with DHCP in netbsd-8" - the messages
were incidental (indicated the cause of the problem perhaps, but were not
the problem complained of - if there had not been the other problem, the
real problem, the messages would probably have never been noticed).


The address could also have been lost due to dhcpcd not seeing the RA 
the IPv6 router sent and thus timing out.
This could be due to the ICMP6 receive socket overflowing and thus the 
kernel discards the RA.


The cvs commit increases the default size of the ICMP6 receive socket, 
so it's not incidental at all.


Roy

Re: CVS commit: src/sys

[Robert Elz]

Date:Fri, 11 May 2018 12:03:19 +0100
From:Roy Marples 
Message-ID:  

  | However, the normal amount of noise generated in his environment is no 
  | longer generating any overflow messages so his problem report is indeed 
  | fixed.

The PR was "loss of IPv6 address with DHCP in netbsd-8" - the messages
were incidental (indicated the cause of the problem perhaps, but were not
the problem complained of - if there had not been the other problem, the
real problem, the messages would probably have never been noticed).

kre

Re: CVS commit: src/sys

[Roy Marples]

On 11/05/2018 11:52, Robert Elz wrote:

 Date:Fri, 11 May 2018 09:43:59 +
 From:"Roy Marples" 
 Message-ID:  <20180511094359.e8785f...@cvs.netbsd.org>

   | This mitigates recent reports of socket overflow errors
   | and fixes PR bin/53247.

As I read the PR and what followed, the fix for 53247 was when
you fixed dhcpcd.

Increasing the receive buffer sizes is probably warranted, but
fixes nothing - it is trivial to generate enough noise routing
messages to overflow any size you care to make it.  This is
not something that can be "fixed".


You, you can artificially generate noise.
However, the normal amount of noise generated in his environment is no 
longer generating any overflow messages so his problem report is indeed 
fixed.


Roy

Re: CVS commit: src/sys

[Robert Elz]

Date:Fri, 11 May 2018 09:43:59 +
From:"Roy Marples" 
Message-ID:  <20180511094359.e8785f...@cvs.netbsd.org>

  | This mitigates recent reports of socket overflow errors
  | and fixes PR bin/53247.

As I read the PR and what followed, the fix for 53247 was when
you fixed dhcpcd.

Increasing the receive buffer sizes is probably warranted, but
fixes nothing - it is trivial to generate enough noise routing
messages to overflow any size you care to make it.  This is
not something that can be "fixed".

kre