Hi Peter,
We have some ideas and are working on a patch for you to try. Since we won't
really be able to test it can you do that if we get it to you? Do you know how
to patch a driver? Or should we send you the whole thing (a complete new
driver like you would get off of our SF site)?
Chee
-Original Message-
From: Don Smith [mailto:smit...@cs.unc.edu]
Sent: Thursday, June 06, 2013 12:37 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] Cannot set parameters for igb
Here is the relevant information. Help understanding why this does not
work according to the README fil
Module parameters aren't well-liked in the kernel and they won't let
them into the code. Sourceforge is a different matter. You can get the
same setting using ethtool -C rx-usecs 0.
On Thu, 6 Jun 2013, Don Smith wrote:
> Here is the relevant information. Help understanding why this does not
> wo
On Thu, Jun 6, 2013 at 1:10 PM, Ronciak, John wrote:
> OK so a couple of thing kind of stand out. What interface is the e1000 on?
> eth0? That's not being called out or you filtered it out from the dmesg.
> Early on eth2 is the e1000 interface but later it's one of the Gianfar
> interfaces.
OK so a couple of thing kind of stand out. What interface is the e1000 on?
eth0? That's not being called out or you filtered it out from the dmesg. Early
on eth2 is the e1000 interface but later it's one of the Gianfar interfaces.
Can you clear this up for us?
Also, it looks like you have a
Here is the relevant information. Help understanding why this does not
work according to the README file description for 3.2.10 will be greatly
appreciated. The driver module was installed with the distribution, not
built from the code on Sourceforge.
Thank you.
-- Don Smith
===
On Thu, Jun 6, 2013 at 11:23 AM, Ronciak, John wrote:
> I agree with Jesse but this driver has been in the field for a very long time
> with no reports like this coming to us. Can you send us the dmesg when this
> is happening? I want to see if there are messages from the driver like if
> the
I agree with Jesse but this driver has been in the field for a very long time
with no reports like this coming to us. Can you send us the dmesg when this is
happening? I want to see if there are messages from the driver like if the
down is being delayed somehow. Or re-enabled.
Thanks.
Cheer
On Thu, 6 Jun 2013 09:38:50 -0700
Peter LaDow wrote:
> On Thu, Jun 6, 2013 at 12:30 AM, Peter P Waskiewicz Jr
> wrote:
> > What about the pre-emption behavior of the kernel? Namely Processor type
> > and Features -> Preemption Model. Are you using no preemption, or forced
> > preemption?
>
>
On Thu, Jun 6, 2013 at 12:30 AM, Peter P Waskiewicz Jr
wrote:
> What about the pre-emption behavior of the kernel? Namely Processor type
> and Features -> Preemption Model. Are you using no preemption, or forced
> preemption?
Ok. I've done testing. Yes, we were building with PREEMPT_FULL.
I'v
On 6/6/13, Peter P Waskiewicz Jr wrote:
> What about the pre-emption behavior of the kernel? Namely Processor
> type and Features -> Preemption Model. Are you using no preemption, or
> forced preemption?
It is PREEMPT_FULL. I'll turn it off and give it a spin.
Thanks,
Pete
---
On 05/06/2013 18:59, Eric Dumazet wrote:
> On Wed, 2013-06-05 at 18:46 +0300, Eliezer Tamir wrote:
>> On 05/06/2013 18:39, Eric Dumazet wrote:
>>> On Wed, 2013-06-05 at 18:30 +0300, Eliezer Tamir wrote:
On 05/06/2013 18:21, Eric Dumazet wrote:
>>
> It would also make sense to give end_time
On 06.06.2013 02:02, Allan, Bruce W wrote:
>> -Original Message-
>> From: Allan, Bruce W [mailto:bruce.w.al...@intel.com]
>> Sent: Monday, June 03, 2013 4:28 PM
>> To: Hrvoje Habjanić; e1000-devel@lists.sourceforge.net
>> Subject: Re: [E1000-devel] [PATCH] Packet drops/loss with 82579LM - f
On 06/05/2013 08:34 PM, Peter LaDow wrote:
> On 6/5/13, Ronciak, John wrote:
>> So I have a couple of questions. Does this happen with a non-preemptive
>> kernel? I understand that you probably need to use a preemptive kernel but
>> for testing purposes it would be good to know. We don't always
14 matches
Mail list logo