On 5/31/06, Ingo Molnar [EMAIL PROTECTED] wrote:
* Jesse Brandeburg [EMAIL PROTECTED] wrote:
well, when running e1000 through some code paths on FC4 +
2.6.17-rc5-mm1 + ingo's latest rollup patch, with this lockdep debug
option enabled I got this:
e1000: eth1: e1000_watchdog_task: NIC Link
On Thu, Jun 01, 2006 at 12:40:10PM -0600, Brian F. G. Bidulock ([EMAIL
PROTECTED]) wrote:
So what are your thoughts about my sequence number approach (for
connected sockets)?
Depending on how you are going to use it.
Generic socket code does not have TCP sequence numbers since it must
work
On Fri, Jun 02, 2006 at 07:40:38AM +0200, Florian Weimer ([EMAIL PROTECTED])
wrote:
* Evgeniy Polyakov:
That is wrong. And I have a code and picture to show that,
and you dont - prove me wrong :)
Here we go:
static inline num2ip(__u8 a1, __u8 a2, __u8 a3, __u8 a4)
{
__u32 a
Hello, developers.
Attached initial benchmark of netchannel with memcpy() into kernelspace
area, which could be mapped from userspace versus socket code using
1gbit link.
As you can see from the graph, netchannels outperforms sockets in speed,
but it's CPU usage is higher too.
It is possible,
Larry Finger wrote:
This statement fails to compile on my system using Linus' tree, because
ieee80211softmac_disassoc needs a second argument - the reason. It seems
as if WLAN_REASON_PREV_AUTH_NOT_VALID would be appropriate.
Thanks for pointing that out. This patch depends on a patch titled
Hello, developers.
Attached netchannel psubsystem patch which implements TCP memcpy()
(into preallocated area which could be mapped) reading and
UDP copy_to_user()/memcpy() reading.
Implementations fairly ugly yet.
Netchannels currently use two queue dereferencings to work with socket's
queue
We're currently developing a new Ethernet device driver for a 10G IBM chip
for System p. (ppc64)
A later version of the driver should end up in mainline kernel.
How should we proceed to get first comments by the community?
Either post this code as a patch to netdev or
put a full tarball on for
On Fri, Jun 02, 2006 at 11:09:56AM +0100, Daniel Drake wrote:
Larry Finger wrote:
This statement fails to compile on my system using Linus' tree, because
ieee80211softmac_disassoc needs a second argument - the reason. It seems
as if WLAN_REASON_PREV_AUTH_NOT_VALID would be appropriate.
On Thu, Jun 01, 2006 at 07:34:47PM +0200, Patrick McHardy wrote:
Frank van Maarseveen wrote:
ok, now tc -s -d qdisc show says (after noticing missing netconsole
packets):
qdisc pfifo_fast 0: dev eth0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1
1
Sent 155031 bytes 2067 pkt
Meelis Roos wrote:
Then lets try something different. Please enable the
DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and
post the results, if any.
On bootup I get this in dmesg (one Bad offset has been added):
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter
Very strange, this means that the initial table data must somehow
be wrong, but for some reason it still seems to get past the
size and offset checks for the filter table. I can't see how
loading the filter table could fail after the Finished chain ..
messages without another message. Which
Meelis Roos wrote:
Very strange, this means that the initial table data must somehow
be wrong, but for some reason it still seems to get past the
size and offset checks for the filter table. I can't see how
loading the filter table could fail after the Finished chain ..
messages without
The problem is that we can't synchronously cancel an
outstanding connect request. Once we've asked the adapter to
connect, we can't tell him to stop, we have to wait for it to
fail. During the time period between when we ask to connect
and the adapter says yeah-or-nay, the user hits
On Fri, Jun 02, 2006 at 02:35:59PM +0200, me wrote:
[...]
This is a tcpdump done after rebooting posio
to 2.6.13.2 showing how it should have looked:
[snip]
The 2.6.13.2 data is inconsistent. The bug appears to be present there at
well after closer examination. So there must be another
Frank van Maarseveen wrote:
The 2.6.13.2 data is inconsistent. The bug appears to be present there at
well after closer examination. So there must be another factor involved
because I have at least one case logged where 2.6.13.2 did work (the
sirkka log in my previous mail). Applying your
On Fri, Jun 02, 2006 at 04:16:08PM +0200, Patrick McHardy wrote:
Which network driver are you using?
I've seen it with two completely different NICs at the sender side:
:02:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro
100] (rev 05)
:02:00.0 Ethernet controller:
John W. Linville wrote:
On Fri, Jun 02, 2006 at 11:09:56AM +0100, Daniel Drake wrote:
Larry Finger wrote:
This statement fails to compile on my system using Linus' tree, because
ieee80211softmac_disassoc needs a second argument - the reason. It seems
as if
Evgeniy,
I agree, even with constant source IP, the hash still should have
performed better (but didn't). Constant source IP and varying
port is a realistic data set for a port proxy.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
On Fri, 2 Jun 2006 13:02:37 +0200 Christoph Raisch wrote:
We're currently developing a new Ethernet device driver for a 10G IBM chip
for System p. (ppc64)
A later version of the driver should end up in mainline kernel.
How should we proceed to get first comments by the community?
Either
Anand Kumria wrote:
Hi David,
Do you know the status of your RFC3927 ARP patch? Is it likely to make
it into a mainline kernel?
That would be up to the kernel network maintainers.
There were some discussions about whether it made sense for the kernel
to support the behavior required by the
* Evgeniy Polyakov:
:) thats true, but to be 100% honest I used different code to test for
hash artifacts...
Ah, okay.
But it still does not fix artifacts with for example const IP and random
ports or const IP and linear port selection.
I see them now. Hmm. Is there a theoretical
On Fri, Jun 02, 2006 at 09:36:54AM -0700, David Daney wrote:
Anand Kumria wrote:
Hi David,
Do you know the status of your RFC3927 ARP patch? Is it likely to make
it into a mainline kernel?
That would be up to the kernel network maintainers.
There were some discussions about whether
On Fri, 2 Jun 2006 05:40:51 -0700
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=6638
Summary: tg3 output freezes on compaq nc6000
Kernel Version: 2.6.16.19
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
Went backed and looked at the RFC. The problem was just a simple
translation of table to C array (0 based). Added this to the TCP testing
repository.
Subject: [PATCH] Problem observed by Xiaoliang (David) Wei:
When snd_cwnd is smaller than 38 and the connection is in
congestion avoidance
Hi,
This patch suggests a fix for the MSI/MSI-X load failure.
Please review the patch.
Symptoms:
When a driver is loaded with MSI followed by MSI-X, the load fails indicating
that the MSI vector is still active. And vice versa.
Suspected rootcause:
This happens inspite of driver calling
On Fri, 02 Jun 2006 21:16:53 +0100
Daniel Drake [EMAIL PROTECTED] wrote:
Here's a strange one. Cantao (on CC) bought what he thought was a cheap
realtek PCI NIC, it actually turns out it is a Rsltek (yes, Rsltek)
8139D card.
It includes an old (2.4/2.5) driver which claims to be for Silan
On Fri, 2 Jun 2006 13:28:46 -0700
Stephen Hemminger [EMAIL PROTECTED] wrote:
On Fri, 02 Jun 2006 21:16:53 +0100
Daniel Drake [EMAIL PROTECTED] wrote:
Here's a strange one. Cantao (on CC) bought what he thought was a cheap
realtek PCI NIC, it actually turns out it is a Rsltek (yes,
On Fri, Jun 02, 2006 at 03:21:37PM -0400, Ravinandan Arakali wrote:
Symptoms:
When a driver is loaded with MSI followed by MSI-X, the load fails indicating
that the MSI vector is still active. And vice versa.
Suspected rootcause:
This happens inspite of driver calling free_irq() followed
Rajesh,
It's possible that the current behavior is by design but once the driver is
loaded with MSI, you need a reboot to be able to load MSI-X. And vice versa. I
found this rather restrictive.
I did test the fix multiple times. For eg. multiple load/unload iterations of
MSI followed by
New code added in 2.6.17 caused setup_irq to print a warning when
running ethtool -t eth0 offline.
This test marks the request_irq call made by this test as a probe to
see if the interrupt is shared or not.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL
On Fri, Jun 02, 2006 at 03:19:47PM -0700, Auke Kok wrote:
Because upstream and upstream-fixes have a whitespace conflict in them,
I've prepared two separate git branches to pull from so that a subsequent
pull or merge from upstream-fixes into upstream doesn't resolve into a
conflict:
That
Jeff Garzik wrote:
On Fri, Jun 02, 2006 at 03:19:47PM -0700, Auke Kok wrote:
Because upstream and upstream-fixes have a whitespace conflict in them,
I've prepared two separate git branches to pull from so that a subsequent
pull or merge from upstream-fixes into upstream doesn't resolve into a
On Fri, 2006-06-02 at 11:22 -0700, Andrew Morton wrote:
On Fri, 2 Jun 2006 05:40:51 -0700
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=6638
Summary: tg3 output freezes on compaq nc6000
Kernel Version: 2.6.16.19
Status: NEW
David Daney [EMAIL PROTECTED] wrote:
There were some discussions about whether it made sense for the kernel
to support the behavior required by the RFC. Other comments debated the
wisdom of using a tightly targeted patch specific to the RFC, or whether
a more general but intrusive
Has anyone done an implementation of RFC3742 for Linux? It looks interesting,
but
would need some integration with current ABC code.
There was some evidence of a version in old Web100 code, but it's gone now. Was
it deemed a mistake?
-
To unsubscribe from this list: send the line unsubscribe
Herbert,
On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
David Daney [EMAIL PROTECTED] wrote:
There were some discussions about whether it made sense for the kernel
to support the behavior required by the RFC. Other comments debated the
wisdom of using a tightly targeted
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 2 Jun 2006 12:05:07 -0700
Went backed and looked at the RFC. The problem was just a simple
translation of table to C array (0 based). Added this to the TCP
testing repository.
Patch applied, thanks a lot.
-
To unsubscribe from this list:
David Miller wrote:
RFC3927 seem to be an intellectual property mine field, I really don't
see how we can include this in the Linux kernel.
Go to http://www.ietf.org/ipr;, click on Search the IPR
disclosures, then enter 3927 in the Enter RFC number field and
click SEARCH.
RFC3927 may be a
Anand Kumria wrote:
Herbert,
On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
David Daney [EMAIL PROTECTED] wrote:
There were some discussions about whether it made sense for the kernel
to support the behavior required by the RFC. Other comments debated the
wisdom of using a
From: David Daney [EMAIL PROTECTED]
Date: Fri, 02 Jun 2006 17:55:17 -0700
RFC3927 may be a mine field, but the only thing that has to be changed
in the kernel to support it is to somehow configure the arp driver to
broadcast unconditionally on certain interfaces.
Ok, I'd have to see the
Rolled my sleeve's up and gave this a try...
This is a implementation of Sally Floyd's Limited Slow Start
for Large Congestion Windows.
Summary from RFC:
Limited Slow-Start introduces a parameter, max_ssthresh, and
modifies the slow-start mechanism for values of the congestion window
Rajesh Shah writes:
The current MSI code actually does this deliberately, not by
accident. It's got a lot of complex code to track devices and
vectors and make sure an enable_msi - disable - enable sequence
gives a driver the same vector. It also has policies about
reserving vectors based on
On Fri, Jun 02, 2006 at 05:58:27PM -0700, David Daney wrote:
Anand Kumria wrote:
Herbert,
On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
David Daney [EMAIL PROTECTED] wrote:
There were some discussions about whether it made sense for the kernel
to support the behavior
Hi,
There are plenty of people who still use ifconfig to list the addresses
assigned to their network interfaces (I know, ifconfig is broken) and
who then parse the output.
However the kernel puts link-local scoped address first if the address
list of an interface, so an interface like:
On Sat, Jun 03, 2006 at 12:50:02PM +1000, Anand Kumria wrote:
I guess it would be something set during RTM_NEWADDR (and returned by
RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
defaulting to 1. When set to 0, generate a broadcast ARP for the
address.
Address
Anand Kumria [EMAIL PROTECTED] wrote:
There are plenty of people who still use ifconfig to list the addresses
assigned to their network interfaces (I know, ifconfig is broken) and
who then parse the output.
If people insist on using hammers on screws, the answer is not to improve
the hammer.
46 matches
Mail list logo
