| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 01 May 2007 15:45:39 -0700 From: "Kok, Auke" <auke-jan.h.kok@...el.com> To: Chuck Ebbert <cebbert@...hat.com> CC: Michel Lespinasse <walken@....org>, linux-kernel@...r.kernel.org, Dave Jones <davej@...hat.com>, Jeb Cramer <cramerj@...el.com>, John Ronciak <john.ronciak@...el.com>, Jesse Brandeburg <jesse.brandeburg@...el.com>, Jeff Kirsher <jeffrey.t.kirsher@...el.com> Subject: Re: 24 lost ticks with 2.6.20.10 kernel Chuck Ebbert wrote: > Kok, Auke wrote: >> Michel Lespinasse wrote: >>> (I've added the E1000 maintainers to the thread as I found the issue >>> seems to go away after I compile out that driver. For reference, I was >>> trying to figure out why I lose exactly 24 ticks about every two >>> seconds, as shown with report_lost_ticks. This is with a DQ965GF >>> motherboard with onboard E1000). >> that's perfectly likely. The main issue is that we read the hardware >> stats every two seconds and that can consume quite some time. It's >> strange that you are losing that many ticks IMHO, but losing one or two >> might very well be. >> >> We've been playing with all sorts of solutions to this problem and >> haven't come up with a way to reduce the load of the system reading HW >> stats, and it remains the most likely culprit, allthough I don't rule >> out clean routines just yet. This could very well be exaggerated at >> 100mbit speeds as well, I never looked at that. >> >> I've had good results with 2.6.21.1 (even running tickless :)) on these >> NICs. Have you tried that yet? > > Maybe this could fix it in 2.6.20? (went into 2.6.21) well, that hasn't got anything to do with stats, but is part of the clean_tx/rx codepath. I personally don't get any lost_ticks so I can't reproduce, but that was why I was hinting that you can try it for us ;) codewise, the patch below makes our cleanup routine spend _more_ time, instead of less, which is why I think it's not the cause nor fix. Auke > > -------------------------------------------------------------------------- > > Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=46fcc86dd71d70211e965102fb69414c90381880 > Commit: 46fcc86dd71d70211e965102fb69414c90381880 > Parent: 2b858bd02ffca71391161f5709588fc70da79531 > Author: Linus Torvalds <torvalds@...dy.linux-foundation.org> > AuthorDate: Thu Apr 19 18:21:01 2007 -0700 > Committer: Linus Torvalds <torvalds@...dy.linux-foundation.org> > CommitDate: Thu Apr 19 18:21:01 2007 -0700 > > Revert "e1000: fix NAPI performance on 4-port adapters" > > This reverts commit 60cba200f11b6f90f35634c5cd608773ae3721b7. It's been > linked to lockups of the e1000 hardware, see for example > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > but it's likely that the commit itself is not really introducing the > bug, but just allowing an unrelated problem to rear its ugly head (ie > one current working theory is that the code exposes us to a hardware > race condition by decreasing the amount of time we spend in each NAPI > poll cycle). > > We'll revert it until root cause is known. Intel has a repeatable > reproduction on two different machines and bus traces of the hardware > doing something bad. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists