On 12.08.2019 11:59, Holger Hoffstätte wrote:
> On 8/9/19 10:52 AM, Holger Hoffstätte wrote:
>> On 8/9/19 10:25 AM, Eric Dumazet wrote:
>> (snip)
So that didn't take long - got another timeout this morning during some
random light usage, despite sg/tso being disabled this time.
On 8/9/19 10:52 AM, Holger Hoffstätte wrote:
On 8/9/19 10:25 AM, Eric Dumazet wrote:
(snip)
So that didn't take long - got another timeout this morning during some
random light usage, despite sg/tso being disabled this time.
Again the only common element is the xmit_more patch. :(
Not sure whet
On 09.08.2019 10:52, Holger Hoffstätte wrote:
> On 8/9/19 10:25 AM, Eric Dumazet wrote:
> (snip)
>>>
>>> So that didn't take long - got another timeout this morning during some
>>> random light usage, despite sg/tso being disabled this time.
>>> Again the only common element is the xmit_more patch.
On 8/9/19 10:25 AM, Eric Dumazet wrote:
(snip)
So that didn't take long - got another timeout this morning during some
random light usage, despite sg/tso being disabled this time.
Again the only common element is the xmit_more patch. :(
Not sure whether you want to revert this right away or wait
On Fri, Aug 9, 2019 at 10:04 AM Holger Hoffstätte
wrote:
>
> On 8/8/19 10:08 PM, Heiner Kallweit wrote:
> (..snip..)
> >>>
> >>> I was about to ask exactly that, whether you have TSO enabled. I don't
> >>> know what
> >>> can trigger the HW issue, it was just confirmed by Realtek that this chip
On 8/8/19 10:08 PM, Heiner Kallweit wrote:
(..snip..)
I was about to ask exactly that, whether you have TSO enabled. I don't know what
can trigger the HW issue, it was just confirmed by Realtek that this chip
version
has a problem with TSO. So the logical conclusion is: test w/o TSO, ideally th
On 08.08.2019 21:52, Holger Hoffstätte wrote:
> On 8/8/19 8:17 PM, Heiner Kallweit wrote:
>> On 08.08.2019 17:53, Holger Hoffstätte wrote:
>>> On 8/8/19 4:37 PM, Holger Hoffstätte wrote:
Hello Heiner -
On 7/28/19 11:25 AM, Heiner Kallweit wrote:
> There was a previous attemp
On 8/8/19 8:17 PM, Heiner Kallweit wrote:
On 08.08.2019 17:53, Holger Hoffstätte wrote:
On 8/8/19 4:37 PM, Holger Hoffstätte wrote:
Hello Heiner -
On 7/28/19 11:25 AM, Heiner Kallweit wrote:
There was a previous attempt to use xmit_more, but the change had to be
reverted because under load s
On 08.08.2019 17:53, Holger Hoffstätte wrote:
> On 8/8/19 4:37 PM, Holger Hoffstätte wrote:
>>
>> Hello Heiner -
>>
>> On 7/28/19 11:25 AM, Heiner Kallweit wrote:
>>> There was a previous attempt to use xmit_more, but the change had to be
>>> reverted because under load sometimes a transmit timeout
On 8/8/19 4:37 PM, Holger Hoffstätte wrote:
Hello Heiner -
On 7/28/19 11:25 AM, Heiner Kallweit wrote:
There was a previous attempt to use xmit_more, but the change had to be
reverted because under load sometimes a transmit timeout occurred [0].
Maybe this was caused by a missing memory barrie
Hello Heiner -
On 7/28/19 11:25 AM, Heiner Kallweit wrote:
There was a previous attempt to use xmit_more, but the change had to be
reverted because under load sometimes a transmit timeout occurred [0].
Maybe this was caused by a missing memory barrier, the new attempt
keeps the memory barrier
From: Heiner Kallweit
Date: Sun, 28 Jul 2019 11:25:19 +0200
> There was a previous attempt to use xmit_more, but the change had to be
> reverted because under load sometimes a transmit timeout occurred [0].
> Maybe this was caused by a missing memory barrier, the new attempt
> keeps the memory ba
There was a previous attempt to use xmit_more, but the change had to be
reverted because under load sometimes a transmit timeout occurred [0].
Maybe this was caused by a missing memory barrier, the new attempt
keeps the memory barrier before the call to netif_stop_queue like it
is used by the drive
13 matches
Mail list logo
