On Jun 6, 2007, at 4:28 AM, Milton Miller wrote:
On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
Kok, Auke wrote:
Hmm git-revert seems to do the job right. I checked it with git-show
| patch -p1 -R and the results look OK. The two patches on top of
the one we want to revert are unrelated
On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
Kok, Auke wrote:
Hmm git-revert seems to do the job right. I checked it with git-show
| patch -p1 -R and the results look OK. The two patches on top of the
one we want to revert are unrelated enough to apply (manually it
shows some fuzz, but
First, a question especially to Auke and Jeff:
Since this patch both reverts the broken change that is currently in
-rc and creates the fixed driver, I'm not sure I like the subject
stating on ARM, although that is the feature of the rewrite, and was
the intent of merging the previous patch.
On Jun 5, 2007, at 8:34 AM, David Acker wrote:
Milton Miller wrote:
On Jun 1, 2007, at 3:45 PM, David Acker wrote:
Ok, I took a stab at coding and testing these ideas. Below is a
patch against 2.6.22-rc3.
Let me know what you think.
I think you got most of the ideas. As Auke noted, your
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we
don't end up killing e100 in it. Should we drop the current fixes in
it to be on the safe side and
On Jun 1, 2007, at 3:45 PM, David Acker wrote:
Ok, I took a stab at coding and testing these ideas. Below is a patch
against 2.6.22-rc3.
Let me know what you think.
I think you got most of the ideas. As Auke noted, your coding style
is showing again. And your mailer again munged
On May 29, 2007, at 10:58 AM, David Acker wrote:
Ok, I finally got some time to code this out and study it and Ihave
some
questions.
Milton Miller wrote:
We add two flags to struct rx: one says this packet is EL, and one
says
it is or was size 0. We create a function, find_mark_el
Some further thoughts ...
On May 24, 2007, at 12:26 AM, Milton Miller wrote:
On May 23, 2007, at 4:32 PM, David Acker wrote:
Milton Miller wrote:
My current reading of the manual is that the C bit will not be
set on an RFD that is size 0. It goes on to processes EL and
S, and decides to stop
On May 24, 2007, at 7:51 AM, David Acker wrote:
Milton Miller wrote:
Comments? Questions?
This sounds pretty reasonable. I will take a stab at coding this up
today; I always think better looking at code.
Thanks.
By the way, find_mark_el should probably get passed
the old fill point
I tried to remove anything we were in agreement with.
On May 22, 2007, at 5:07 PM, David Acker wrote:
Milton Miller wrote:
Many of the issues you bring have been in the e100 for some time. If
you ignore the s-bit patch, I basically did the the following:
moved the el-bit to before the last
Auke Kok pointed out I had left an unfinished thought this
morning ... well, here's a completion, but I will mostly
think about David's latest proposal.
I think I was debating proposing this, then got side
tracked then hit send.
On May 23, 2007, at 9:02 AM, Milton Miller wrote:
What if we
On May 23, 2007, at 4:32 PM, David Acker wrote:
Milton Miller wrote:
My current reading of the manual is that the C bit will not be
set on an RFD that is size 0. It goes on to processes EL and
S, and decides to stop and interrupt RNR or suspend, or just
go to the next packet.
I double checked
On May 21, 2007, at 12:45 PM, Kok, Auke wrote:
Milton Miller wrote:
On May 18, 2007, at 12:11 PM, David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped
to 10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new
code seems to misbehave
On May 18, 2007, at 12:11 PM, David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and
[dropping Andrew, Jeff, and LKML]
On May 4, 2007, at 4:43 PM, David Acker wrote:
David Acker wrote:
So far my testing has shown both the original and the new version of
the S-bit patch work in that no corruption seemed to occur over long
term runs.
I spoke too soon. Further testing has not
of list and s bits would not be set
in the template nor cleared when linking in recieve skbs, so
as long as the kernel can keep up with the 100Mb card we
wouldn't see the adapter go off the linked list, possibly
explaining any successful use of this patch written against
2.6.14).
Signed-off-by: Milton
16 matches
Mail list logo
