On Wed, 2006-07-05 at 20:03 -0700, David Miller wrote:
> From: Roland Dreier <[EMAIL PROTECTED]>
> Date: Wed, 05 Jul 2006 13:29:35 -0700
>
> > The way forward seems to be to merge basic iWARP support that lives in
> > drivers/infiniband, and then you can accept or reject things for
> > better inte
From: John Heffner <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2006 15:17:23 -0400
> Hm, wouldn't that violate the TCP spec?
Yes, this cannot be right. One cannot shrink the offered
window under any circumstance.
If we over-advertised the window, that isn't something we
can "clean up" like this.
-
To
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2006 00:05:04 +0200
> Fixes for some rather serious action API bugs. Please apply.
All applied, I'll push to -stable, thanks Thomas.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2006 13:29:35 -0700
> The way forward seems to be to merge basic iWARP support that lives in
> drivers/infiniband, and then you can accept or reject things for
> better integration, like notifiers for routing changes.
Let's merge in drive
[EMAIL PROTECTED] wrote:
For a newbee future contributor: is there a cheatsheet on how to submit
an addition to the ethtool for a new device (driver) support?
Just submit a patch...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
On Thu, 2006-07-06 at 03:44, Linas Vepstas wrote:
> On Wed, Jul 05, 2006 at 08:49:27AM -0700, Auke Kok wrote:
> > Zhang, Yanmin wrote:
> > >On Fri, 2006-06-30 at 00:26, Linas Vepstas wrote:
> > >>Adds PCI Error recovery callbacks to the Intel 10-gigabit ethernet
> > >>ixgb device driver. Lightly te
On Tue, 2006-07-04 at 15:29 +0200, Patrick McHardy wrote:
> Unfortunately I still didn't got to cleaning them up, so I'm sending
> them in their preliminary state. Its not much that is missing, but
> the netem usage of skb->cb needs to be integrated better, I failed
> to move it to the qdisc_skb_cb
Krzysztof Oledzki wrote:
On Wed, 5 Jul 2006, Auke Kok wrote:
David Miller wrote:
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2006 15:20:39 -0400
BTW, As an addendum this default behavior changed around 2.6.16 it
seems.
Flow control has been on by default in the tg3 driver since the
Patrick McHardy wrote:
Stefan Rompf wrote:
Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
- new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
+ new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
This change looks funky because it ignores the link stat
Stefan Rompf wrote:
> Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
>
>
>>>-new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
>>>+new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
>
>
>>This introduced a regression by propagating the __LINK_STATE_XOFF flag,
>
Hi,
I first wrote to the linux-pcmcia ML, but they said it wasn't the right
address for my issue. The driver airo (for Cisco Wlan-Cards) complains
about "failed to load transform for AES", when it is loaded and
CRYPTO_AES is not selected in Kconfig.
I've got a patch for that, maybe it's worth
On Wed, 5 Jul 2006, Auke Kok wrote:
David Miller wrote:
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2006 15:20:39 -0400
BTW, As an addendum this default behavior changed around 2.6.16 it
seems.
Flow control has been on by default in the tg3 driver since the
beginning, maybe e1000 on
On Wed, 5 Jul 2006, Auke Kok wrote:
jamal wrote:
On Tue, 2006-04-07 at 13:11 -0400, jamal wrote:
I have a device connected to a e1000 that was erroneously advertising
both tx/rx flow control but wasnt properly reacting to it. The default
setup on the e1000 has rx flow control turned on.
I
Chris Sturtivant wrote:
> Shailabh Nagar wrote:
>
>> So here's the sequence of pids being used/hashed etc. Please let
>> me know if my assumptions are correct ?
>>
>> 1. Same listener thread opens 2 sockets
>>
>> On sockfd1, does a bind() using
>> sockaddr_nl.nl_pid = my_pid1
>> On sockfd2, do
> Then why in the world would we put up explicit web pages that
> say "TOE is bad, here's a list of reasons why" if we had any
> intention of ever adding support for these kinds of devices?
I think there's a little bit of leap of logic there. Everyone agrees
that winmodems are bad and yet ther
Shailabh Nagar wrote:
So here's the sequence of pids being used/hashed etc. Please let
me know if my assumptions are correct ?
1. Same listener thread opens 2 sockets
On sockfd1, does a bind() using
sockaddr_nl.nl_pid = my_pid1
On sockfd2, does a bind() using
sockaddr_nl.nl_pid
Hi,
my name is Dawid Ciezarkiewicz. As a part of my daily job I was to write
kernel module for ebtables to let linux bridges change vlan ids in fly using
logic provided by ebtables matches. After hours of tries and kernel learning,
reading and googlin' I've finally come to the place where I've
On Wed, Jul 05, 2006 at 08:49:27AM -0700, Auke Kok wrote:
> Zhang, Yanmin wrote:
> >On Fri, 2006-06-30 at 00:26, Linas Vepstas wrote:
> >>Adds PCI Error recovery callbacks to the Intel 10-gigabit ethernet
> >>ixgb device driver. Lightly tested, works.
> >
> >Both pci_disable_device and ixgb_down wo
Hm, wouldn't that violate the TCP spec?
-John
Angelo P. Castellani wrote:
I forward the message because it seems hasn't get through to mailing
list (removing references to a word that seems blocking the message).
The previous message "[TCP] window update during recovery (continuing
on windo
Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
> > - new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
> > + new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
> This introduced a regression by propagating the __LINK_STATE_XOFF flag,
> when the queue of the underlyin
David Miller wrote:
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2006 15:20:39 -0400
BTW, As an addendum this default behavior changed around 2.6.16 it
seems.
Flow control has been on by default in the tg3 driver since the
beginning, maybe e1000 only recently started to behave that way
b
Auke Kok wrote:
Jeff,
Since my pull request from thursday I haven't heard anything anymore, so I
assume that the changes we made were sufficient.
Needless to say that I would love to see ich8 support make it into 2.6.18rc,
considering that the hardware already is out there and the code has been
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2006 13:34:30 -0700
> Well, in the past it's seemed more like patches have been rejected not
> because of a blanket refusal to consider support for certain hardware,
Then why in the world would we put up explicit web pages that
say "TOE is
John W. Linville wrote:
On Fri, Jun 30, 2006 at 12:31:00PM -0400, Jeff Garzik wrote:
The following changes since commit
fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
Malcolm Parsons:
uclinux: use PER_LINUX_32BIT in binfmt_flat
are found in the git repository at:
git://git.kernel.org/pub
From: Greg KH <[EMAIL PROTECTED]>
Date: Tue, 4 Jul 2006 15:31:01 -0700
> Do you mind if I keep this in my tree, due to the dependancies on the
> other driver core changes?
Feel free.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2006 15:20:39 -0400
> BTW, As an addendum this default behavior changed around 2.6.16 it
> seems.
Flow control has been on by default in the tg3 driver since the
beginning, maybe e1000 only recently started to behave that way
but it's the right th
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2006 13:11:56 -0400
> Clearly, this is a bad thing. Yes, the device in the first instance was
> at fault. But i have argued in the past that NAPI does just fine without
> flow control being turned on, so even chewing 5% of bandwidth on flow
> contr
Jay Lan wrote:
Shailabh Nagar wrote:
Yes. If no one registers to listen on a particular CPU, data from tasks
exiting on that cpu is not sent out at all.
Shailabh also wrote:
During task exit, kernel goes through each registered listener (small
list) and decides which
one needs to get thi
Just sent this to Andrew/Linus...
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS|7
drivers/net/8139cp.c
Ralf Baechle wrote:
+/* module parameters */
+
+static int param_set_ethaddr(const char *val, struct kernel_param *kp)
+{
+ static const char fmt[] = "%2hhx:%2hhx:%2hhx:%2hhx:%2hhx:%2hhx";
+ unsigned char * const cc = (unsigned char *) kp->arg;
+
+ if (!val) return -EINVAL;
+
+
On Wed, 2006-07-05 at 12:09 -0500, Tom Tucker wrote:
> On Sat, 2006-07-01 at 16:26 +0200, Andi Kleen wrote:
> > On Saturday 01 July 2006 01:01, Tom Tucker wrote:
> > > On Fri, 2006-06-30 at 14:16 -0700, David Miller wrote:
> > >
> > > > The TOE folks have tried to submit their hooks and drivers
>
Shailabh Nagar wrote:
> Yes. If no one registers to listen on a particular CPU, data from tasks
> exiting on that cpu is not sent out at all.
Shailabh also wrote:
> During task exit, kernel goes through each registered listener (small
> list) and decides which
> one needs to get this exit data
Phil Oester wrote:
I saw this error (once) in 2.6.13 a few weeks ago:
Jun 23 15:19:01 X kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Jun 23 15:19:01 X kernel: TDH <7e>
Jun 23 15:19:01 X kernel: TDT <7f>
Jun 23 15:19:01 X kernel: next_to_u
On Sat, 2006-07-01 at 16:26 +0200, Andi Kleen wrote:
> On Saturday 01 July 2006 01:01, Tom Tucker wrote:
> > On Fri, 2006-06-30 at 14:16 -0700, David Miller wrote:
> >
> > > The TOE folks have tried to submit their hooks and drivers
> > > on several occaisions, and we've rejected it every time.
>
jamal writes:
> The default setup on the e1000 has rx flow control turned on.
> I was sending at wire rate gige from the device - which is about
> 1.48Mpps. The e1000 was in turn sending me flow control packets
> as per default/expected behavior. Unfortunately, it was sending
> a very large
I saw this error (once) in 2.6.13 a few weeks ago:
Jun 23 15:19:01 X kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Jun 23 15:19:01 X kernel: TDH <7e>
Jun 23 15:19:01 X kernel: TDT <7f>
Jun 23 15:19:01 X kernel: next_to_use <7f>
Jun
jamal wrote:
On Tue, 2006-04-07 at 13:11 -0400, jamal wrote:
I have a device connected to a e1000 that was erroneously advertising
both tx/rx flow control but wasnt properly reacting to it.
The default setup on the e1000 has rx flow control turned on.
I was sending at wire rate gige from the d
I forward the message because it seems hasn't get through to mailing
list (removing references to a word that seems blocking the message).
The previous message "[TCP] window update during recovery (continuing
on window reduction)" references this one
Regards,
Angelo P. Castellani
-- Forw
Linsys Contractor Amit S. Kale wrote:
+while (state != PHAN_INITIALIZE_COMPLETE && loops < 20) {
+udelay(100);
+/* Window 1 call */
+read_lock(&adapter->adapter_lock);
+state = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+read_unlock(&a
Linsys Contractor Amit S. Kale wrote:
+#ifndef readq
this test fails where readq is not a macro
+static inline u64 readq(void __iomem * addr)
+{
+return readl(addr) | (((u64) readl(addr + 4)) << 32LL);
+}
+#endif
+
+#ifndef writeq
+static inline void writeq(u64 val, void __iomem * addr)
Linsys Contractor Amit S. Kale wrote:
+/**
+ * netxen_nic_set_multi - Multicast
+ **/
+void netxen_nic_set_multi(struct net_device *netdev)
+{
+struct netxen_port *port = netdev_priv(netdev);
+struct dev_mc_list *mc_ptr;
+
+mc_ptr = netdev->mc_list;
+if (netdev->flags & IFF_PROMIS
Linsys Contractor Amit S. Kale wrote:
=> +extern struct netxen_adapter *g_adapter;
+
+/*
+ * The basic unit of access when reading/writing control registers.
+ */
+
+typedef u32 netxen_crbword_t;/* single word in CRB space */
+
+#define NETXEN_HW_H0_CH_HUB_ADR0x05
+#define NETXEN_HW_H1_CH
Zhang, Yanmin wrote:
On Fri, 2006-06-30 at 00:26, Linas Vepstas wrote:
Adds PCI Error recovery callbacks to the Intel 10-gigabit ethernet
ixgb device driver. Lightly tested, works.
Both pci_disable_device and ixgb_down would access the device. It doesn't
follow Documentation/pci-error-recovery
Linsys Contractor Amit S. Kale wrote:
+#define NETXEN_NIC_FW_VERSIONID "2.1.39"
This duplicates the driver version, rather than being used for its
intended purpose, firmware version.
If firmware (or if no firmware on card, silicon) version is not
available, just use the string "n/a"
+#d
Linsys Contractor Amit S. Kale wrote:
+static int
+netxen_nic_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+{
+struct netxen_port *port = netdev_priv(dev);
+struct netxen_adapter *adapter = port->adapter;
+struct netxen_niu_phy_status status;
+
+/* read which mod
In the TCP Compound article used as a reference for the implementation, we read:
"If a retransmission timeout occurs, dwnd should be reset to zero and
the delay-based component is disabled." at page 5 of
ftp://ftp.research.microsoft.com/pub/tr/TR-2005-86.pdf
The attached patch implements this req
In this patch there is a collection of changes useful to have linux
tcp recovery close to rfc standard.
The linux kernel using this patch defaults to linux standard recovery,
when net.ipv4.tcp_rfcstrict_recovery=1 the changes in this patch are
enabled.
I've already discussed something like this
We will reimplement halt-clearing later, when we have periodic
housekeeping routines in place. This will do as a temporary fix, the
EPIPE case has not yet been seen.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c
b/drivers/net/wireless/zd1211r
Based on a patch by Matthieu CASTET.
zd1211 chip 079b:004a v4330 high 00-60-b3 AL2230_RF pa0 g--
zd1211b chip 079b:0062 v4810 high 00-60-b3 AL2230_RF pa0 g--
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c
b/drivers/net/wireless/zd1211rw/zd_us
Michael Buesch wrote:
The following patch is supposed to fix this.
I did only compile-test it. Please runtime-test it.
Thanks.
--
Softmac Shared Key Auth:
Fix recursive call into the driver by doing schedule_work.
recursive calls may result in a driver lock recursion.
Tested on zd1211rw with
Hi Greg,
> The patch needs some other changes to the driver core that are also in
> my git tree, and included in the -mm release. Specifically these
> patches are needed:
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver/device-groups.patch
>
> http:
During a recovery, we should always reduce send window if the host is
notifying a window reduction.
This is needed because in the recovery phase the host requires to
buffer the packets between the beginning of the recovery and the data
we're sending "forward" with ssthresh window and sacked_out c
jamal wrote:
> Shailabh,
>
> On Tue, 2006-04-07 at 12:37 -0400, Shailabh Nagar wrote:
> [..]
>
>>Here's a strawman for the problem we're trying to solve: get
>>notification of the close of a NETLINK_GENERIC socket that had
>>been used to register interest for some cpus within taskstats.
>>
>> Fro
On Wed, 2006-05-07 at 15:54 +0200, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2006-07-05 09:35
> > Please resubmit this patch with changing -err to -1 (i.e a one liner)
> > I went back to about 2.6.10 and this is in there. I looked at my notes
> > and i cant see any reasoning to explain this.
* jamal <[EMAIL PROTECTED]> 2006-07-05 09:35
> Please resubmit this patch with changing -err to -1 (i.e a one liner)
> I went back to about 2.6.10 and this is in there. I looked at my notes
> and i cant see any reasoning to explain this. So it is a bug.
Fine, if you think that's better.
> Is ther
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_niu.c
linux-2.6.17/drivers/net/netxen/netxen_nic_niu.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_niu.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_niu.c2006-07-05
01:18:40.36990
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_ioctl.h
linux-2.6.17/drivers/net/netxen/netxen_nic_ioctl.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_ioctl.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_ioctl.h 2006-07-05
01:18:40.3
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_main.c
linux-2.6.17/drivers/net/netxen/netxen_nic_main.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_main.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_main.c 2006-07-05
01:18:40.368
On Wed, 2006-07-05 at 16:33 +0300, Avi Kivity wrote:
> Arjan van de Ven wrote:
> >
> > From: Arjan van de Ven <[EMAIL PROTECTED]>
> >
> > > Linux version 2.6.17-git22 ([EMAIL PROTECTED]) (gcc version 4.0.3
> > (Ubuntu 4.0.3-1ubuntu5)) #20 PREEMPT Tue Jul 4 10:35:04 CEST 2006
> >
> > >
> > > [ 2381
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_init.c
linux-2.6.17/drivers/net/netxen/netxen_nic_init.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_init.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_init.c 2006-07-05
01:18:40.366
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.h
linux-2.6.17/drivers/net/netxen/netxen_nic_hw.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_hw.h 2006-07-05
01:18:40.3649070
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.c
linux-2.6.17/drivers/net/netxen/netxen_nic_hw.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.c1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_hw.c 2006-07-05
01:18:40.3649070
Arjan van de Ven wrote:
From: Arjan van de Ven <[EMAIL PROTECTED]>
> Linux version 2.6.17-git22 ([EMAIL PROTECTED]) (gcc version 4.0.3
(Ubuntu 4.0.3-1ubuntu5)) #20 PREEMPT Tue Jul 4 10:35:04 CEST 2006
>
> [ 2381.598609] =
> [ 2381.619314] [ INFO: p
Thomas,
Please resubmit this patch with changing -err to -1 (i.e a one liner)
I went back to about 2.6.10 and this is in there. I looked at my notes
and i cant see any reasoning to explain this. So it is a bug.
Is there a way to check whether this was a result of some other earlier
change or was
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic.h
linux-2.6.17/drivers/net/netxen/netxen_nic.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic.h2006-07-05
01:18:40.363907266 -0700
@@ -0
diff -Naru linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hdr.h
linux-2.6.17/drivers/net/netxen/netxen_nic_hdr.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hdr.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_hdr.h2006-07-05
01:18:40.35990
diff -Naru linux-2.6.17.orig/drivers/net/Kconfig
linux-2.6.17/drivers/net/Kconfig
--- linux-2.6.17.orig/drivers/net/Kconfig 2006-07-05 01:15:38.740111318
-0700
+++ linux-2.6.17/drivers/net/Kconfig2006-07-05 01:18:13.066500584 -0700
@@ -2311,6 +2311,11 @@
If in doubt, say N.
Hi,
I'll be sending a NetXen 1G/10G ethernet driver patch in subsequent
emails. We have made changes as per the feedback received. We would like
this driver to be included in mainline kernel.
Kindly review it and feel free to send feedback.
Thanks,
-Amit
Signed-off-by: Amit S. Kale <[EMAIL
On Tue, 4 Jul 2006, CaT wrote:
> On Fri, Jun 30, 2006 at 08:50:39AM +1000, CaT wrote:
>> Another datapoint to this is that I've had this my netcat web test
>> running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed
>> in any way. It hasn't quit. It hasn't timed out. It just sits the
Hi Stephen,
Sorry to bring you more trouble. I'm able to reproduce this 'status
0x977d977d' rx race even with a 100Mb FD connection (MTU 1500) to the
host sending the data.
Would it help if I try and capture some packet stats or a dump of
this? The packets being received at the sending host will
* Stefan Richter <[EMAIL PROTECTED]> wrote:
> I wrote:
> > (Ieee1394 core's usage of the skb_* API is entirely unrelated to
> > networking; even if eth1394 was used.)
>
> PS:
> I wonder if it wouldn't be better to migrate ieee1394 core away from
> skb_*. I didn't look thoroughly at it yet but t
> ok this is a real potential deadlock in a way, it takes two locks of 2
> skbuffs without doing any kind of lock ordering; I think the following
> patch should fix it. Just sort the lock taking order by address of the
> skb.. it's not pretty but it's the best this can do in a minimally
> invasive
I wrote:
> (Ieee1394 core's usage of the skb_* API is entirely unrelated to
> networking; even if eth1394 was used.)
PS:
I wonder if it wouldn't be better to migrate ieee1394 core away from
skb_*. I didn't look thoroughly at it yet but the benefit of using this
API appears quite low to me.
We use
On 7/4/2006 10:01 PM, Arjan van de Ven wrote:
> this is one for the networking people, and thus netdev
It's actually ieee1394 using net infrastructure for purposes which ar
unrelated to networking.
Furthermore...
> On Tue, 2006-07-04 at 21:53 +0200, Rafael J. Wysocki wrote:
>> On Monday 03 July
Refer to RFC2012, tcpAttemptFails is defined as following:
tcpAttemptFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times TCP connections have made a direct
transition to the CLOSED s
* Patrick McHardy <[EMAIL PROTECTED]> 2006-07-05 01:42
> Thomas Graf wrote:
> > @@ -834,7 +833,7 @@ tc_dump_action(struct sk_buff *skb, stru
> > a.ops = a_o;
> >
> > if (a_o->walk == NULL) {
> > - printk("tc_dump_action: %s !capable of dumping table\n", kind);
> > + pr
On Tue, Jul 04, 2006 at 08:35:37PM +0400, A.N.Kuznetsov wrote:
>
> > Different modules want different kinds of lookup.
> > So, I'm thinking about something like ilookup5.
>
> > The next question: would people agree to review a patch doing this for
> > net_devices? :)
>
> One not original sug
77 matches
Mail list logo
