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 wh
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 netdev-2.6
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 s
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 syst
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 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 n
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 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 n
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 h
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
ft
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 si
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 patch
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
Kok, Auke wrote:
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 t
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 ha
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 lo
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 li
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 li
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 h
19 matches
Mail list logo
