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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240
Rodney W. Grimes changed:
What|Removed |Added
CC||rgri...@freebsd.org
--- Comment
> 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?
> > Ju
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/D185
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610
Eric Joyner changed:
What|Removed |Added
Status|Open|In Progress
Assignee|n...@
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
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 assi
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 th
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.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240658
Harald Schmalzbauer changed:
What|Removed |Added
Status|Closed |In Progress
Resoluti
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 devi
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 ty
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787
l...@donnerhacke.de changed:
What|Removed |Added
Attachment #207757|0 |1
is patch|
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 b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724
Kubilay Kocak changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240
Kubilay Kocak changed:
What|Removed |Added
Severity|Affects Some People |Affects Many People
See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787
Kubilay Kocak changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Flag
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.fr
18 matches
Mail list logo
