To view the message, please use an HTML compatible email viewer
Link to the online version:
http://t.emk02.com/QtBB_m/YT02MSZtPTExOTA2MyZiPTE3NzU3NyZjPTU3Mzc5NTUmaj0xMjk0NTIKJmQ9MjAxNS0wNC0yMiAxMjoxMDowMCZlPTEmaz0xJnA9MSZsPWVuJmVzPThjZmM2YjFmMTBkMjhmYTlkOWE5M2Y0ZDIwZmFjNzcxMjQ2ZWZjNjQ=
Another thing you might want to check is if you disabled no snoop. I
wrote an 82599 driver a while ago, and remember running into issues with
cache coherency on certain machines if no snoop was not disabled. Not
sure if this applies to the x540 though, but it might be worth a try.
Cheers
--
-Original Message-
From: Brandon Falk [mailto:bf...@gamozolabs.com]
Sent: Wednesday, April 22, 2015 1:10 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] [non-linux] Cache Coherency Problems on X540?
I'm writing a custom driver for a custom OS and thus this does
I'm writing a custom driver for a custom OS and thus this does not relate
to the Linux driver.
I have implemented a driver which polls for the DD and EOP flags to get set
(using legacy receive descriptors) and I have noticed a problem where these
flags both can get set very slightly before the
I can see that there is a read memory barrier in the ixgbe_clean_rx_irq()
functions with the comment This memory barrier is needed to keep us from
reading any other fields out of the rx_desc until we know the RXD_STAT_DD
bit is set which is exactly my problem, but that should emit an lfence
which
Whoops I guess hitting enter sent the email early.
The code looks roughly like such. The distance between the DD and EOP
checks and using packet contents is very short.
; rax points to the ring descriptor, thus rax+8 points to the status
.poll:
bt qword [rax + 8], 32 ; DD
jnc short .poll
bt
Please do check to see if the fence is fixing the problem. If it is not the
fence and it turns out it is some other delay then we can follow up.
Thanks,
-Greg
From: Brandon Falk [mailto:bf...@gamozolabs.com]
Sent: Wednesday, April 22, 2015 2:41 PM
To: Rose, Gregory V
Cc:
