* David Miller [EMAIL PROTECTED] [070303 08:22]:
BTW, I think I figured out a way to get rid of
lost_{skb,cnt}_hint. The fact of the matter in this case is that
the setting of the tag bits always propagates from front of the queue
onward. We don't get holes mid-way.
So what we can do is
Geoff, I suspect gelic_net might have the same problem...
Cheers,
Ben.
On Fri, 2007-03-02 at 18:39 +0100, Norbert Eicker wrote:
On Fri 2.3.2007 00:34, Linas Vepstas wrote:
On Thu, Mar 01, 2007 at 04:52:54PM -0600, Chris Engel wrote:
I tried to apply this patch to 2.6.21-rc2 and CHECKSUM_HW
On Sat, 2007-03-03 at 04:06 +0100, Andi Kleen wrote:
Jan-Bernd Themann [EMAIL PROTECTED] writes:
Are there any concerns about this approach?
Yes. You should fix the NAPI code instead of trying to work
around it.
NAPI is being fixed but the fix will take time to get in. In the
meantime,
On Fri, Mar 02, 2007 at 12:45:36PM -0800, Michael K. Edwards ([EMAIL
PROTECTED]) wrote:
On 3/2/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Thank you for this report. (Still avoiding cache misses studies, while they
obviously are the limiting factor)
1) The entire point of going to a
On Fri, 2 Mar 2007, David Miller wrote:
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 1 Mar 2007 20:13:40 +0200
One drawback for this approach is that you now walk the entire sack
block when you advance one packet. If you consider a 10,000 packet queue
which had several losses at the
Am Freitag, 2. März 2007 22:26 schrieb David Miller:
The DHCP client should only care about a particular interface's
traffic, the one it wants to listen on.
Also, a DHCP client should close the socket between address acquisition and
renewal. The only interesting events in that period are
On Sat, 3 Mar 2007, Ilpo Järvinen wrote:
On Fri, 2 Mar 2007, David Miller wrote:
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 1 Mar 2007 20:13:40 +0200
One drawback for this approach is that you now walk the entire sack
block when you advance one packet. If you consider a 10,000
On Fri, Mar 02, 2007 at 08:22:11PM -0800, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: 03 Mar 2007 03:14:29 +0100
That's pretty common with many x86 server boards because
they come with two NICs by default but must people only
plug the cable into one. However the distro
m a a [EMAIL PROTECTED] ac uk schreef:
Hello,
This is a rather strange e-mail for these mailing
lists, I know. I am a third year Social Anthropology
student in the University of Durham doing my
dissertation (thesis) on the Anthropology of
GNU/Linux. I would really appreciate if you could
Hi,
I'd be glad if someone could review the at76_usb wireless driver, it
adds support for the at76c503, at76c505 and at76c505a wireless USB
adapters. Since it exceeds the lists size limit, please
git-clone http://honk.sigxcpu.org/git/at76c503a.git/
The projects homepage is:
Pavel should know better and have told you that wireless got it's own
list ;)
Quoting fully to make linux-wireless aware. I guess we'll want to take
out netdev on replies to this.
johannes
On Sat, 2007-03-03 at 16:00 +0100, Guido Guenther wrote:
Hi,
I'd be glad if someone could review the
Looks pretty good, a few more comments.
KEVENT_* constants and functions are really really confusing when the
kevent subsystem is being discussed on netdev all the time. They're
also quite meaningless, please rename them to something like
AT76_DEVEVENT_* or whatever. While at that, the kevent()
David Miller wrote:
From: John Heffner [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 16:16:39 -0500
Please don't apply the patch I sent. I've been thinking about this a
bit harder, and it may not fix this particular problem. (Hard to say
without knowing exactly what it is.) As the comment above
Hi,
From: Florian Zumbiehl [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 13:38:44 +0100
As noone seems to have an opinion on this: Here is a patch that does
work for me and that should solve the problem as far as that is easily
possible. It is based on the assumption that an interface's
Hello
I've always felt uncomfortable by the usability of the wireless-tools
(iwconfig, iwlist), but I really love iproute2. That's why I started to
implement ip wifi.
My GIT tree is located at:
http://cthulhu.c3d2.de/~astro/git/iproute2.git/
I wonder if this has a chance to get merged in
Hi,
I noticed that the PPPoE code doesn't allow session id 0x to be used
for an actual session but rather considers 0 a special value denoting
that the socket is unbound. Now, when reading RFC 2516, I couldn't really
find anything that would forbid 0x as a session id. Only 0x is
On Sun, 4 Mar 2007 02:26:53 +0100
Stephan Maka [EMAIL PROTECTED] wrote:
Hello
I've always felt uncomfortable by the usability of the wireless-tools
(iwconfig, iwlist), but I really love iproute2. That's why I started
to implement ip wifi.
My GIT tree is located at:
From: Florian Zumbiehl [EMAIL PROTECTED]
Date: Sun, 4 Mar 2007 03:30:00 +0100
I noticed that the PPPoE code doesn't allow session id 0x to be used
for an actual session but rather considers 0 a special value denoting
that the socket is unbound. Now, when reading RFC 2516, I couldn't really
From: Florian Zumbiehl [EMAIL PROTECTED]
Date: Sun, 4 Mar 2007 02:55:16 +0100
Below you find a slightly changed version of the patch
I already applied your first patch, so if you have any
fixes to submit please provide them as relative patches
to your original change.
Thank you.
-
To
Dear All:
Our IS/IT in their infinite wisdom made us to switch from ESP to UDP
encapsulation for the VPN. It worked ok for a while, but the following
seems to happen now (not sure how recently it started, sorry).
At first, everything works fine. A VPN client sends its packets through
a
20 matches
Mail list logo
