Re: rpc.statd already ipv6 clean?

2019-09-24 Thread Hiroki Sato
Mihir Luthra  wrote
  in :

lu> Hi everyone,
lu>
lu> Just as mentioned in [1], rpc.statd is not ipv6 clean.
lu>
lu> Although I have been through the code, and didn't found any issues until
lu> now. The code conditionally checks for ipv6/ipv4 everywhere and uses ipv6
lu> compatible functions.
lu>
lu> As per one old commit [2], seems rpc.statd was already made to function
lu> correctly with ipv6.
lu>
lu> I searched bugzilla(thinking someone may have reported something similar,
lu> giving rise to the project), but didn't see anything similar for rpc.statd
lu> and ipv6 support.
lu>
lu> I wanted to ask if someone could share the issues they encountered while
lu> using rpc.statd with ipv6?

 I think the project page has wrong information regarding rpc.statd.
 Although it is not clean from the viewpoint of transport independent,
 it works with IPv6.

 There are more userland utilities which do not support IPv6---rwhod,
 yp*, etc.

-- Hiroki


pgpdPhqL5rI56.pgp
Description: PGP signature


[Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card (igb/ixgbe/em) loses ethernet link

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||rgri...@freebsd.org

--- Comment #17 from Rodney W. Grimes  ---
(In reply to Kubilay Kocak from comment #14)
> If this needs to / should make it into 12.1-RELEASE, please add bug 240700 to 
> this issues Blocks: field

I conncur, this is the correct thing to do.

> In doing so, it may also be worth adding re@ to the reviews for their 
> approval > to merge to releng/12.1

Please do not add re@ to bug reports for the purpose of merge requesting, there
is an official process in place that says ONCE you have committed a fix to head
and merged to stable you need to send an email request.  Involving RE@ at the
bug state is too early, only once an agreed fix has been committed, and merged
back to the appropriate branch if needed possible with out authroization is
completed should RE@ be involved, they simply do not have the time to read
through a bug being evolved and dealt with.

Regards,
Rod (former RE@ member)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-24 Thread Rodney W. Grimes
> On 24.09.2019 12:42, Andriy Gapon wrote:
> 
> > It seems that the userland component of ipfw/dummynet uses int for the 
> > bandwidth
> > represented in bit/s.  Also, int is used for passing that value from the
> > userland to the kernel.
> > 
> > What would be the best way to extend this?
> > Just use a larger type?
> > Or maybe add another field to try to preserve KBI backward compatibility?
> > 
> > Thank you.
> 
> AFAIK, we never had any public ABI or stable KBI interface announced to 
> userland or in-kernel consumers
> and had no consumers of dummynet other than ipfw(8) binary. Just increase 
> type.

Any attempt to mfc this would break KABI/userland and that is never
a good thing to do.  It may not be a public ABI, but it is an ABI,
and stability of that and backwards compatibility are always a good
thing to strive for.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card (igb/ixgbe/em) loses ethernet link

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240

--- Comment #16 from John Delano  ---
Odd, I applied this (https://reviews.freebsd.org/D21769) manually, recompiled
the kernel and it seems to have fixed the state change and the buffer warnings.

I also have https://reviews.freebsd.org/D18545 applied as well.

I have not installed https://reviews.freebsd.org/D21712

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240610] iflib: Panic with INVARIANTS: general protection fault when kldunload'ing (12.1-pre-QA)

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

Eric Joyner  changed:

   What|Removed |Added

 Status|Open|In Progress
   Assignee|n...@freebsd.org |e...@freebsd.org

--- Comment #4 from Eric Joyner  ---
Yeah. I'll MFC the fix after a bit and then close it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240610] iflib: Panic with INVARIANTS: general protection fault when kldunload'ing (12.1-pre-QA)

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

--- Comment #3 from Harald Schmalzbauer  ---
(In reply to Eric Joyner from comment #2)

Thanks, meanwhile I can confirm that
https://svnweb.freebsd.org/changeset/base/352655 fixes the issue for me on
12.1-BETA1.

I'd like to take the chance and point to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609
This seems to be a major issue, although not affecting non-debug kernels, so I
don't add bug 240700 as blocker.  Should I?

Do you take over this report and close after MFC+MFSing?

Thanks,

-harry

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240610] iflib: Panic with INVARIANTS: general protection fault when kldunload'ing (12.1-pre-QA)

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

--- Comment #2 from Eric Joyner  ---
Yeah, it looks like it.

Sorry, the original review didn't have the PR number, but it did fix a problem
we were encountering internally at Intel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240610] iflib: Panic with INVARIANTS: general protection fault when kldunload'ing (12.1-pre-QA)

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

--- Comment #1 from Harald Schmalzbauer  ---
Is https://reviews.freebsd.org/D21711 supposed to address this issue? Guess so,
will test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card (igb/ixgbe/em) loses ethernet link

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240

--- Comment #15 from Harald Schmalzbauer  ---
(In reply to Krzysztof Galazka from comment #13)

Thanks four your D21769 fix.  Unfortunately it doesn't solve the
link-state-change-issue.  Please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240658
I described why I re-opened the ticket as a separate report.

Thanks,

-harry

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240658] iflib: if_igb(4) and some if_em(4) devices don't recognize/report carrier loss.

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240658

Harald Schmalzbauer  changed:

   What|Removed |Added

 Status|Closed  |In Progress
 Resolution|DUPLICATE   |---

--- Comment #4 from Harald Schmalzbauer  ---
Initially, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240 describes a
different issue and I'd like to keep that separate, although John Delano added
comment #3, where he mentions the same link state issue. But the proposed fix
indicates this is an independent issue!

The proposed phabriactor patch in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240#c13
(https://reviews.freebsd.org/D21769) doens't fix the problem.

There's progress though: After once marking the interface down and up again,
the link state correctly changes from there on.  But right after loading the
kernel module, link state still doesn't change when physical connection was
lost (repeatedly won't change, unless you manually down/up).
Tested with 12.1-beta1, D21769+D21712 and i210, i350, 82576 (all hw.mac.type
igb ) and 82574L (em) - consistently the same behaviour.

Thanks,

-Harry

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 239704] ixgbe(4): Only one queue (of eight) enabled on 12.0-RELEASE (ProLiant DL380 Gen10)

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239704

--- Comment #7 from commit-h...@freebsd.org ---
A commit references this bug:

Author: erj
Date: Tue Sep 24 17:06:33 UTC 2019
New revision: 352656
URL: https://svnweb.freebsd.org/changeset/base/352656

Log:
  ix, ixv: Read msix_bar from device configuration

  Instead of predicting the MSI-X bar index based on the device's MAC
  type, read it from the device's PCI configuration instead.

  PR:   239704
  Submitted by: Piotr Pietruszewski 
  Reviewed by:  erj@
  MFC after:3 days
  Sponsored by: Intel Corporation
  Differential Revision:https://reviews.freebsd.org/D21547

Changes:
  head/sys/dev/ixgbe/if_ix.c
  head/sys/dev/ixgbe/if_ixv.c
  head/sys/dev/ixgbe/ixgbe.h

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-24 Thread Eugene Grosbein
On 24.09.2019 12:42, Andriy Gapon wrote:

> It seems that the userland component of ipfw/dummynet uses int for the 
> bandwidth
> represented in bit/s.  Also, int is used for passing that value from the
> userland to the kernel.
> 
> What would be the best way to extend this?
> Just use a larger type?
> Or maybe add another field to try to preserve KBI backward compatibility?
> 
> Thank you.

AFAIK, we never had any public ABI or stable KBI interface announced to 
userland or in-kernel consumers
and had no consumers of dummynet other than ipfw(8) binary. Just increase type.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240787] netgraph/ng_bridge: Replace NG_BRIDGE_MAX_LINKS with auto-incrementing (Unlimited) links

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787

l...@donnerhacke.de changed:

   What|Removed |Added

 Attachment #207757|0   |1
   is patch||

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240787] netgraph/ng_bridge: Replace NG_BRIDGE_MAX_LINKS with auto-incrementing (Unlimited) links

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787

--- Comment #2 from l...@donnerhacke.de ---
The idea is to replace the whole array by hook private storage.
This will remove the need for any limit control.

Should I provide a summary patch as replacement?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 236724] igb(4): Interfaces fail to switch active to inactive state

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2392
   ||40

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card (igb/ixgbe/em) loses ethernet link

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240

Kubilay Kocak  changed:

   What|Removed |Added

   Severity|Affects Some People |Affects Many People
   See Also||https://reviews.freebsd.org
   ||/D21712,
   ||https://reviews.freebsd.org
   ||/D21769,
   ||https://reviews.freebsd.org
   ||/D18545,
   ||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2367
   ||24

--- Comment #14 from Kubilay Kocak  ---
(In reply to Krzysztof Galazka from comment #13)

If this needs to / should make it into 12.1-RELEASE, please add bug 240700 to
this issues Blocks: field

In doing so, it may also be worth adding re@ to the reviews for their approval
to merge to releng/12.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 240787] netgraph/ng_bridge: Replace NG_BRIDGE_MAX_LINKS with auto-incrementing (Unlimited) links

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787

Kubilay Kocak  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org
  Flags||mfc-stable11?,
   ||mfc-stable12?
   Keywords||needs-qa
Summary|netgraph/ng_bridge: |netgraph/ng_bridge: Replace
   |Unlimited limit of links|NG_BRIDGE_MAX_LINKS with
   ||auto-incrementing
   ||(Unlimited) links
   Severity|Affects Only Me |Affects Some People
 Status|New |Open
 CC||n...@freebsd.org

--- Comment #1 from Kubilay Kocak  ---
Could this be made into a run-time tunable (sysctl), at least as a
simplification while auto-incrementing design is worked on/reviewed ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card (igb/ixgbe/em) loses ethernet link

2019-09-24 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240

--- Comment #13 from Krzysztof Galazka  ---
The watchdog message is cased by an issue in the iflib framework. The queue
hang detection code does not check the state of the interface. We are working
on a fix in this review: https://reviews.freebsd.org/D21712

And this patch: https://reviews.freebsd.org/D21769 should fix a problem with
em/igb not reporting current link state.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


rpc.statd already ipv6 clean?

2019-09-24 Thread Mihir Luthra
Hi everyone,

Just as mentioned in [1], rpc.statd is not ipv6 clean.

Although I have been through the code, and didn't found any issues until
now. The code conditionally checks for ipv6/ipv4 everywhere and uses ipv6
compatible functions.

As per one old commit [2], seems rpc.statd was already made to function
correctly with ipv6.

I searched bugzilla(thinking someone may have reported something similar,
giving rise to the project), but didn't see anything similar for rpc.statd
and ipv6 support.

I wanted to ask if someone could share the issues they encountered while
using rpc.statd with ipv6?

[1] https://wiki.freebsd.org/SummerOfCodeIdeas#IPv6_Userland_Cleanup
[2]
https://github.com/freebsd/freebsd/commit/83a53d0868085db818fddd8cb38eecc0c39cad8d#diff-b87e28a1a8ec4fe947f72996127f8f40

Kind Regards,
Mihir
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"