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 suggestion,
* 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);
+
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
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
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
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 way.
* 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 the benefit
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
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 there,
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
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.
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
@@
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
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_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
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
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
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
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
* 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 there a
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:
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.598609]
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. So it
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
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
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
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.
From looking at
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
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
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
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
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
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
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
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_PROMISC)
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)
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
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
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 23
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
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.
iWARP
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_use
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
on several
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 and
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;
+
+
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
control is
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 thing
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:
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
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
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
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
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]
More
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
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 underlying device is
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
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 would access
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
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 there's
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
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
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
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, does a bind() using
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,
when the queue of 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 state mask.
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
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 so
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 tested, works.
[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
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.
sarcasm
Let's merge in
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
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
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 integration,
74 matches
Mail list logo
