David Acker wrote:
Milton Miller wrote:
In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
talks about emulating another driver by setting addtional bits and
the being unable to test when submitted. Seeing the & operator to
set more bits made me suspicious, and indeed the bits are defined
in positive logic:
cb_s = 0x4000,
cb_el = 0x8000,
So anding those together would be 0. I'm guessing they should
be or'd, but don't have hardware here to test, much like the
committed patch. In fact, I'll let someone else do the compile
test too. I'll update the comment.
I wonder if this worked for me because the hardware also spun on the
link field being NULL? Since the RU base is also set to 0, the
calculated physical address would be 0 as well. I would imagine if the
hardware tried to read/write to very low addresses across PCI, there
would be issues. I will retest with a small receive pool to try to hit
the problem.
I will also run these tests with the new patch and with a smaller
receive pool (default is 256) to make the pool run out more often.
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. The previous S-bit patch may have only worked due to something
specific about how my PCI companion chip handles I/O to low memory
addresses (from dereferencing a link address of 0). Perhaps the e100
handles the NULL link as well, but given that the manual does not seem
to state what happens when the hardware encounters a buffer with a link
of 0, I think Milton's fix is the proper way to do it. The old eepro
driver did set both bits although it did it with a hardcoded constant.
I will continue testing with slab debug on but that will take longer.
Has anyone tried this on other platforms?
-Ack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/