In gmane.linux.network, you wrote:
> But the CPU has done more work. The flood ping will always show
> increased CPU with these changes because the driver always stays in the
> NAPI poll list. For typical LAN traffic, the average CPU usage doesn't
> increase as much, though more measurements wou
On Mon, Jul 02, 2007 at 05:10:48PM -0700, Rick Jones wrote:
> Rambling a bit, and recognizing that "e1000new" was probably just a
> strawman name, but I suspect that a _very_ different name for the new
> driver would be a good thing, rather than a varition on the e1000 theme.
I rather liked the
On Fri, Jun 29, 2007 at 12:51:02PM -0700, Kok, Auke wrote:
> For distro's not following kernel.org releases we have the perfect
> solution: A fully tested 7.5.5 driver on sourceforge that was extensively
> tested against RHEL5 for instance, but also a lot of other older kernels.
I'm sure you and
On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote:
> I understand there is some delay in getting e1000-7.5.5 into the
> upstream kernel given the major re-working of the chipset specific
> parts.
>
> I wonder would it be feasible in the meantime to backport the ich9
> sup
On Tue, Jun 12, 2007 at 02:26:58PM -0700, David Miller wrote:
> The MAC is still very much centralized in most designs.
>
> So one way they'll do it is to support assigning N MAC addresses,
> and you configure the input filters of the chip to push packets
> for each MAC to the proper receive queue
On Tue, Jun 12, 2007 at 02:55:34PM -0700, David Miller wrote:
> These chips allow this too, Microsoft defined a standard for
> RX queue interrupt hashing by flow so everyone puts it, or
> something like it, in hardware.
I think you're referring to "RSS"?
http://www.microsoft.com/whdc/device/netwo
I recall mention of a tool that could dynamically monitor kernel packet
queues in linux using netlink, but I can't remember a unique enough name
for good googling. Does this sound familiar to anyone? iirc it was
written by Thomas Graf?
Jason
-
To unsubscribe from this list: send the line "unsubsc
On Tue, Feb 13, 2007 at 04:00:36PM +, Ben Gamari wrote:
> That being said, now come the problems. When I first loaded the driver,
> I found that it had created two interfaces as mentioned in earlier
> threads. On my machine these are named eth1 and wlan0_rename (can
> someone confirm what the n
On Thu, Sep 28, 2006 at 10:52:24AM -0500, Larry Finger wrote:
> I had very good luck with my first AP, a Linksys WRT54G V1, that I
> bought a second when the power supply failed in the first. Little did
> I know that a VxWorks license costs less than the extra memory needed
> to run Linux. Or was i
[EMAIL PROTECTED] said:
> The code for frame diverter is unmaintained and has bitrotted.
> The number of users is very small and the code has lots of problems.
> If anyone is using it, they maybe exposing themselves to bad packet attacks.
I seem to recall looking at frame diverter and thinking tha
[EMAIL PROTECTED] said:
> And BTW I want to remind the entire world that the last time Intel
> cried wolf to all of us about vendors using broken EEPROMs with their
> networking chips it turned out to be a bug in one of the patches Intel
> put into the Linux driver. :-)
>
> Intel should really humb
On Fri, Jul 21, 2006 at 09:27:23PM +0200, Michael Buesch wrote:
> What is a major change? Why only on major change? Why not on
> simple changes, too? Simple changes sometimes introduce bugs, too.
the version number has whatever meaning you choose to assign to it.
Including none, if you so choose.
On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> I am not going to maintain a bogus version number.
> What about simply returning 1.0 and be done with it.
> I don't think it matters. 1.0 is as bogus as any other value.
Put it to use! Increment it whenever there's a major change in
On Mon, Jun 05, 2006 at 08:41:38PM -0700, Jouni Malinen wrote:
> Do you happen to have a wireless sniffer that you could use to capture
> the frames? It would be interesting to see whether such a capture log
> could be mapped into the dropped frames shown in the kernel debug log.
I don't know. Wou
On Mon, Jun 05, 2006 at 06:31:48AM -0700, Jouni Malinen wrote:
> These are not normal, i.e., they should not really show up unless
> something goes wrong.
If these are a real problem, I'll gladly help debug it. I'm using
2.6.17-rc5's bcm43xx and the in-kernel ieee80211 softmac stack. I'm
using wpa
other wpa-using station on the same AP is
within range.
These events are still being counted in the statistics.
Signed-off-by: Jason Lunz <[EMAIL PROTECTED]>
---
net/ieee80211/ieee80211_crypt_ccmp.c | 11 ---
1 file changed, 11 deletions(-)
Index: linux-2.6.17-rc5-git11/net/ieee80211/i
On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?
I assume it disables the radio without any help fro
[EMAIL PROTECTED] said:
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we
>
> A. be handling t
18 matches
Mail list logo
