David Acker wrote:
What is the status of this patch? Is there anything folks would like me
to do in order to move it forward? As an FYI, my company has been using
this patch since I posted it and so far we have not had any problems
with it.
-Ack
Jeff merged it in netdev-2.6#upstream so it
Kok, Auke wrote:
David Acker wrote:
What is the status of this patch? Is there anything folks would like me
to do in order to move it forward? As an FYI, my company has been using
this patch since I posted it and so far we have not had any problems
with it.
-Ack
Jeff merged it in
What is the status of this patch? Is there anything folks would like me to do in order to move it forward? As an FYI,
my company has been using this patch since I posted it and so far we have not had any problems with it.
-Ack
Auke Kok wrote:
From: David Acker [EMAIL PROTECTED]
On the
Jeff Garzik wrote:
Kok, Auke wrote:
David Acker wrote:
What is the status of this patch?
Jeff merged it in netdev-2.6#upstream so it is queued for 2.6.25.
However, we could consider pushing this patch to 2.6.24 since it's a
valid fix.
Andrew has also been carrying this patch in -mm for a
From: David Acker [EMAIL PROTECTED]
On the systems that have cache incoherent DMA, including ARM, there
is a race condition between software allocating a new receive buffer
and hardware writing into a buffer. The two race on touching the last
Receive Frame Descriptor (RFD). It has its el-bit
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next link equal to 0.
When
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next
Kok, Auke wrote:
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit
David Acker wrote:
Jeff Garzik wrote:
David Acker wrote:
Let me know if there is any other information I can provide you. I
will look through the code to see what could be going on with your
machine. I will also look into reproducing these results with a
newer kernel. This may be tricky
James Chapman wrote:
David Acker wrote:
Jeff Garzik wrote:
pktgen outputs for the various cases modified/unmodified[/others?]
would be nice, if you have a spot of time.
Jeff
I am not familiar with pktgen but I seem to have it working for a
simple test.
I edited the 1-1 example from
Jeff Garzik wrote:
David Acker wrote:
Let me know if there is any other information I can provide you. I
will look through the code to see what could be going on with your
machine. I will also look into reproducing these results with a newer
kernel. This may be tricky since compulab's
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru too much, but
I haven't had time to
David Acker wrote:
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru too much, but
I
David Acker wrote:
Let me know if there is any other information I can provide you. I will
look through the code to see what could be going on with your machine.
I will also look into reproducing these results with a newer kernel.
This may be tricky since compulab's patches are pretty stale
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next link equal to 0.
When
18 matches
Mail list logo
