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 ha
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
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:
eve:[~]%
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
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 ba
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
w
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
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 t
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 b
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
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.
-
To unsubscribe from this list: sen
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
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 net
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
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: NE
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, 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:
Th
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 P
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 multiple
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() fo
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 (y
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
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 free_ir
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 pha
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]
>
Florian,
On Fri, 02 Jun 2006, Florian Weimer wrote:
>
> I see them now. Hmm. Is there a theoretical explanation for them?
Jenkins is an ad hoc function that is far from ideal. As you know,
the ideal hash changes 1/2 the bits in the output value for each one
bit change in the input value(s).
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 a
* 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 expl
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
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?
> Eith
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]
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 WLAN_REASON_PREV_AUTH_NOT_VAL
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: Br
> > > The first parameter of strcat() must be big enough to contain the whole
> > > string.
> >
> > Will replace it with
> > sprintf(wrqu->name, "radiobtn/", radiobtn->dev_name);
>
> Or actually, I don't think the radiobtn/ won't be actually needed as prefix.
> The name passed to the radiobtn dri
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 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 fa
> >
> > 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
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 wi
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 kern
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
> N
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 2
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.
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 exa
Stephen Hemminger writes:
> I also noticed that you really don't save much by doing TX cleaning at
> hardirq, because in hardirq you need to do dev_kfree_irq and that causes
> a softirq (for the routing case where users=1). So when routing it
> doesn't make much difference, both methods ca
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
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 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, th
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)
> {
>
* 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 = 0;
a |= a1;
a << 8;
a |= a2;
a << 8;
a |= a3;
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 wi
50 matches
Mail list logo
