https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237720
--- Comment #1 from Naveen Nathan ---
There has been some suggestions that this issue might have happened due to mbuf
exhaustion. Here are a few commands which I think might help with a post-mortem
diagnosis:
$ uptime
10:25AM up 19 days,
On Fri, May 03, 2019 at 03:37:11PM -0400, Garrett Wollman wrote:
> < said:
>
> > On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
> >> Does anyone have an easy patch to keep mce(4) from trying to use 9k
> >> jumbo mbuf clusters? I think I went down this road once before but
> >>
<
said:
> On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
>> Does anyone have an easy patch to keep mce(4) from trying to use 9k
>> jumbo mbuf clusters? I think I went down this road once before but
>> the fix wasn't as obvious as it is for the Intel drivers. (I assume
>> the h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237720
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
> Does anyone have an easy patch to keep mce(4) from trying to use 9k
> jumbo mbuf clusters? I think I went down this road once before but
> the fix wasn't as obvious as it is for the Intel drivers. (I assume
> the hardware is not s
Does anyone have an easy patch to keep mce(4) from trying to use 9k
jumbo mbuf clusters? I think I went down this road once before but
the fix wasn't as obvious as it is for the Intel drivers. (I assume
the hardware is not so broken that it requires packets to be stored in
contiguous physical mem
