lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Jun 2007 10:58:44 -0500 From: Milton Miller <miltonm@....com> To: Milton Miller <miltonm@....com> Cc: Jeff Garzik <jeff@...zik.org>, Jeff Garzik <jgarzik@...ox.com>, e1000-devel@...ts.sourceforge.net, David Acker <dacker@...net.com>, netdev@...r.kernel.org, Jesse Brandeburg <jesse.brandeburg@...el.com>, "Kok, Auke" <auke-jan.h.kok@...el.com>, Jeff Kirsher <jeffrey.t.kirsher@...el.com>, Scott Feldman <sfeldma@...ox.com>, John Ronciak <john.ronciak@...el.com> Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits) 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 enough to apply (manually it >>> shows some fuzz, but otherwise it's OK). >>> Jeff, please `git-revert d52df4a35af569071fda3f4eb08e47cc7023f094` >>> to revert the following patch for now: >>> --- >>> commit d52df4a35af569071fda3f4eb08e47cc7023f094 >>> Author: Scott Feldman <sfeldma@...ox.com> >>> Date: Wed Nov 9 02:18:52 2005 -0500 >>> [netdrvr e100] experiment with doing RX in a similar manner to >>> eepro100 >>> I was going to say that eepro100's speedo_rx_link() does the >>> same DMA >>> abuse as e100, but then I noticed one little detail: eepro100 >>> sets both >>> EL (end of list) and S (suspend) bits in the RFD as it chains >>> it to the >>> RFD list. e100 was only setting the EL bit. Hmmm, that's >>> interesting. >>> That means that if HW reads a RFD with the S-bit set, it'll >>> process >>> that RFD and then suspend the receive unit. The receive unit >>> will >>> resume when SW clears the S-bit. There is no need for SW to >>> restart >>> the receive unit. Which means a lot of the receive unit state >>> tracking >>> code in the driver goes away. >>> So here's a patch against 2.6.14. (Sorry for inlining it; the >>> mailer >>> I'm using now will mess with the word wrap). I can't test this >>> on >>> XScale (unless someone has an e100 module for Gumstix :) . It >>> should >>> be doing exactly what eepro100 does with RFDs. I don't believe >>> this >>> change will introduce a performance hit because the S-bit and >>> EL-bit go >>> hand-in-hand meaning if we're going to suspend because of the >>> S- bit, >>> we're on the last resource anyway, so we'll have to wait for SW >>> to >>> replenish. >>> (cherry picked from 29e79da9495261119e3b2e4e7c72507348e75976 >>> commit) >>> --- >> >> A little bit more is needed to explain why we're reverting it for >> now. Jeff, please insert this into the revert commit. >> >> Auke >> >> -- >> This patch attempted to fix e100 for non-cache coherent memory >> architectures by using the cb style code that eepro100 had and using >> the EL and s bits from the RFD list. Unfortunately the hardware >> doesn't work exactly like this and therefore this patch actually >> breaks e100 on those systems. > > on all systems. (Both the &| typo and the removed restart logic). > >> Reverting the change brings it back to the previously known good >> state for 2.6.22. The pending rewrite in progress to this code can >> then be safely merged later. >> >> Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com> >> Jeff I don't see this in netdev upstream-fixes. Are you waiting on Auke to respond to this? milton - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists