On 25.03.2014, at 02:18, Rick Macklem wrote:
> Christopher Forgeron wrote:
>>
>>
>>
>> This is regarding the TSO patch that Rick suggested earlier. (With
>> many thanks for his time and suggestion)
>>
>>
>> As I mentioned earlier, it did not fix the issue on a 10.0 system. It
>> did make it
Hey guys,
I have nothing on your code level to add, but.. while investigating this
issue I ran into the guy that originally created the bug (
http://www.freebsd.org/cgi/query-pr.cgi?pr=183390&cat=). In the email
exchange that followed he told me that had found a workaround by running a
specific -S
Hi Simon,
Try checking out the "9.2 ixgbe tx queue hang' thread here, and see if it
applies to you.
On Tue, Mar 25, 2014 at 1:55 AM, k simon wrote:
> Hi,Lists:
> I have got lots of "no buffer available" on 10-stable with igb nic.
> But em and bce works well. And I tried force igb to 4 or 8
Hi guys,
I'm in meetings today, so I'll respond to the other emails later.
Just wanted to clarify about tp->t_tsomax : I can't make a solid assertion
about it's value as I only tracked it briefly. I did see it being !=
if_hw_tsomax, but that was a short test and should really be checked more
ca
There has been a long thread on stable about sshd processes being hung due
to sockets remaining in a CLOSED state for extended periods in 10-stable.
This did not seem to be happening with 9.2. (Not sure about 10.0.)
Was here a change in the network stack on 10 that would have kept CLOSED
sockets a
This isn't the same as the polled driver; this is sending and receiving a
single packet at a time.
I've gotten (at least to a somewhat workable degree) Apple's KDP ported to
FreeBSD. I've only changed the dev/e1000/if_lem.c driver for now (that's the
one VMWare shows up as :)), but since I'm n
You might want to take a look at the projects/sv branch, which
implement kernel core dumps over the network. We had to solve a
similar problem there (in lem, em, igb and ixgbe) and ended up
piggybacking on most of the DEVICE_POLLING code to do it. The work
ended up stalling over objections over c
I'm quite positive that an IP_MAXPACKET = 65518 would fix this, as I've
never seen a packet overshoot by more than 11 bytes, although that's just
in my case. It's next up on my test list.
BTW, to answer the next message: I am expierencing the error with a raw ix
or lagg interface. Originally I w
On Mar 25, 2014, at 12:15 PM, Ryan Stone wrote:
> You might want to take a look at the projects/sv branch, which
> implement kernel core dumps over the network. We had to solve a
> similar problem there (in lem, em, igb and ixgbe) and ended up
> piggybacking on most of the DEVICE_POLLING code to
Markus Gebert wrote:
>
> On 25.03.2014, at 02:18, Rick Macklem wrote:
>
> > Christopher Forgeron wrote:
> >>
> >>
> >>
> >> This is regarding the TSO patch that Rick suggested earlier. (With
> >> many thanks for his time and suggestion)
> >>
> >>
> >> As I mentioned earlier, it did not fix
On 25.03.2014, at 22:46, Rick Macklem wrote:
> Markus Gebert wrote:
>>
>> On 25.03.2014, at 02:18, Rick Macklem wrote:
>>
>>> Christopher Forgeron wrote:
This is regarding the TSO patch that Rick suggested earlier. (With
many thanks for his time and suggestion)
>>>
Markus Gebert wrote:
>
> On 25.03.2014, at 22:46, Rick Macklem wrote:
>
> > Markus Gebert wrote:
> >>
> >> On 25.03.2014, at 02:18, Rick Macklem
> >> wrote:
> >>
> >>> Christopher Forgeron wrote:
>
>
>
> This is regarding the TSO patch that Rick suggested earlier.
> >>>
Update:
I'm changing my mind, and I believe Rick's TSO patch is fixing things
(sorry). In looking at my notes, it's possible I had lagg on for those
tests. lagg does seem to negate the TSO patch in my case.
kernel.10stable_basicTSO_65535/
- IP_MAXPACKET = 65535;
- manually forced (no if statem
On 25.03.2014, at 23:21, Rick Macklem wrote:
> Markus Gebert wrote:
>>
>> On 25.03.2014, at 22:46, Rick Macklem wrote:
>>
>>> Markus Gebert wrote:
On 25.03.2014, at 02:18, Rick Macklem
wrote:
> Christopher Forgeron wrote:
>>
>>
>>
>> This is regar
Hi,
First off, I hope you don't mind that I cross-posted this,
but I wanted to make sure both the NFS/iSCSI and networking
types say it.
If you look in this mailing list thread:
http://docs.FreeBSD.org/cgi/mid.cgi?1850411724.1687820.1395621539316.JavaMail.root
you'll see that several people hav
Christopher Forgeron wrote:
> Update:
>
> I'm changing my mind, and I believe Rick's TSO patch is fixing
> things
> (sorry). In looking at my notes, it's possible I had lagg on for
> those
> tests. lagg does seem to negate the TSO patch in my case.
>
Ok, that's useful information. It implies t
On 26.03.2014, at 00:06, Christopher Forgeron wrote:
> Update:
>
> I'm changing my mind, and I believe Rick's TSO patch is fixing things
> (sorry). In looking at my notes, it's possible I had lagg on for those
> tests. lagg does seem to negate the TSO patch in my case.
I’m glad to hear you co
Markus Gebert wrote:
>
> On 26.03.2014, at 00:06, Christopher Forgeron
> wrote:
>
> > Update:
> >
> > I'm changing my mind, and I believe Rick's TSO patch is fixing
> > things
> > (sorry). In looking at my notes, it's possible I had lagg on for
> > those
> > tests. lagg does seem to negate the
That's interesting. I see here in the r251296 commit Andre says :
Drivers can set ifp->if_hw_tsomax before calling ether_ifattach() to
change the limit.
I wonder if we add your same TSO patch to if_lagg.c before line 356's
ether_ifattach() will fix it.
Ultimately, it will need to load the
On Tue, Mar 25, 2014 at 07:10:35PM -0400, Rick Macklem wrote:
> Hi,
>
> First off, I hope you don't mind that I cross-posted this,
> but I wanted to make sure both the NFS/iSCSI and networking
> types say it.
> If you look in this mailing list thread:
>
> http://docs.FreeBSD.org/cgi/mid.cgi?185
On Tue, Mar 25, 2014 at 8:21 PM, Markus Gebert
wrote:
>
>
> Is 65517 correct? With Ricks patch, I get this:
>
> dev.ix.0.hw_tsomax: 65518
>
Perhaps a difference between 9.2 and 10 for one of the macros? My code is:
ifp->if_hw_tsomax = IP_MAXPACKET - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN);
Thanks, Christopher. But I think my problem may does not related to
TSO issue. I have tried disable tso with "ifconfig igb(x) -tso" and
ovserved with "netstat -ihw 1", and found "oErrs" does not disappeared.
Regards
Simon
于 14-3-25 22:08, Christopher Forgeron 写道:
Hi Simon,
Try checking o
22 matches
Mail list logo
