On Fri, Jan 08, 2010 at 11:45:35PM -0500, Michael Breuer wrote:Ok - good, and thank you for all your help.
On 1/8/2010 4:48 PM, Michael Breuer wrote:Ok - since alt2 introduces less changes and is acked by Stephen
On 1/8/2010 4:29 PM, Jarek Poplawski wrote:Ok - ran alt1 and alt2, both with MMAP, no DMAR and disable_msi.
...
BTW, don't hurry with that yet, but in the next test, please tryWill do - still up from yesterday... no more dropped packets...
alternative 2 again (i.e. with MMAP + no DMAR + disable_msi).
none of the dns errors either. To be expected I suppose as long as
I'm trying to sniff it. Assuming no immediate erorrs with alt2, no
DMAR + disable_msi I'll report back after it's been up for a
while.
--
Both seem to behave similarly. No logged errors;
already, I'll resend it with your "Tested-by" in a new thread to clear
things a bit.
I'll play around with this after I figure out what's actually being dropped and why. Looking at ethtool, over 99% of RX packets are in the >=1024 bucket. I'll play with weight and perhaps rmem as time permits.large numbers of dropped RX packets.You might try some tweaking with another sky2 parameter "copybreak"
or even editing its "NAPI_WEIGHT" variable.
Ok - I'll get onto mainline and then deal with DMAR.One odd thing: when driving every sort ofIt looks like DMAR is the main candidate for a new linux-kernel@ or
traffic through, I was able to hose the client adapter (win7)
repeatedly by runnnig the win7 backup and connecting Windows Media
Player to a Mediatomb stream while also running a remote X11
session. Looks like the SSDP traffic that occurs at the same time as
the SMB traffic and X11 traffic takes out the adapter on Win7 -
Nforce.
Reran with msi enabled, MMAP and no DMAR. Also no errors; much
faster, and the Win7 side survives the same conditions that don't
work when msi is disabled. Doesn't make sense to me, but it is what
it is.
Going to leave this up for a while and see if things remain functional.
bugzilla bug report. You should also consider reporting these ipv6
problems, especially if you think they can trigger TX timeouts. (In
both cases it would be good to try current mainline first, when you
get it workable.)
Thanks,
Jarek P.