* Re: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages
From: Adrian Bunk @ 2005-06-02 20:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Baruch Even, Andrew Morton, linux-kernel, netdev
In-Reply-To: <20050602103805.6beb4f4e@dxpl.pdx.osdl.net>
On Thu, Jun 02, 2005 at 10:38:05AM -0700, Stephen Hemminger wrote:
> On Thu, 02 Jun 2005 14:58:17 +0100
> Baruch Even <baruch@ev-en.org> wrote:
>
> >...
>
> Your right, the sysctl handler should be smarter, but that is not the problem here.
> The problem is that the default value is set to be BIC to be compatible with earlier kernels.
> Since 75% of the world isn't smart enough to figure out how to use sysctl, there is a
> question of what the default should be, and what to do if that is missing.
>
> One version had a messy ifdef chain to try and avoid the warning:
>
> char sysctl_tcp_congestion_control[] =
> #if defined(CONFIG_TCP_BIC)
> "bic"
> #elif defined(CONFIG_TCP_HTCP)
> "htcp"
> #else
> "reno"
> #endif
> ;
>
> but that was ugly.
>
> Another possibility is putting it in as yet another config value at kernel build time.
>...
One thing that currently makes all solutions harder (and the #ifdef
example above not ugly but simply wrong) is that you allow modular
congestion control options for the always static net support.
Is this really required?
The IO schedulers have a similar problem, and they are using the #ifdef
approach for selecting the default.
One approach is to actually choose the default using #ifdef's.
You could also do any kind of runtime selection, but please don't print
the warning more than once.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* RE: [-mm patch] fix recursive IPW2200 dependencies
From: Alejandro Bonilla @ 2005-06-02 20:19 UTC (permalink / raw)
To: 'Adrian Bunk', 'Andrew Morton', jkmaline, jgarzik
Cc: linux-kernel, hostap, netdev
In-Reply-To: <20050602200701.GG4992@stusta.de>
> On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.12-rc5-mm1:
> >...
> > +git-netdev-we18-ieee80211-wifi.patch
> >
> > Various things added and merged in netdev land.
> >...
>
> This results in recursive dependencies:
> - IPW2200 depends on NET_RADIO
> - IPW2200 selects IEEE80211
> - IEEE80211 selects NET_RADIO
>
>
> This patch fixes the IPW2200 dependencies in a way that they
> are similar
> to the IPW2100 dependencies.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
> linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig.old
> 2005-06-02 22:04:02.000000000 +0200
> +++ linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig
> 2005-06-02 22:04:40.000000000 +0200
> @@ -192,9 +192,8 @@
>
> config IPW2200
> tristate "Intel PRO/Wireless 2200BG and 2915ABG Network
> Connection"
> - depends on NET_RADIO && PCI
> + depends on IEEE80211 && PCI
> select FW_LOADER
> - select IEEE80211
> ---help---
> A driver for the Intel PRO/Wireless 2200BG and
> 2915ABG Network
> Connection adapters.
I think the normal usage of the name is Intel PRO/Wireless 2200BG/2915ABG
Network Connection. I'm just saying this in case that you care about Intel
Trademarking or about a more unified usage of the name of the Adapter.
maybe this is something silly.
.Alejandro
^ permalink raw reply
* Re: [2.6 patch] net/socket.c: unexport move_addr_to_kernel
From: David S. Miller @ 2005-06-02 20:14 UTC (permalink / raw)
To: bunk; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20050530205647.GW10441@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Mon, 30 May 2005 22:56:47 +0200
> I didn't find any modular usage in the kernel.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Yes, but as a part of the socket kernel API, I could
definitely see some out-of-tree code legitimately
using this interface. Let's keep it around for now.
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/ipv4/: possible cleanups
From: David S. Miller @ 2005-06-02 20:13 UTC (permalink / raw)
To: bunk; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20050530205651.GY10441@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Subject: [RFC: 2.6 patch] net/ipv4/: possible cleanups
Date: Mon, 30 May 2005 22:56:51 +0200
> This patch contains the following possible cleanups:
> - make needlessly global code static
> - #if 0 the following unused global function:
> - xfrm4_state.c: xfrm4_state_fini
> - remove the following unneeded EXPORT_SYMBOL's:
> - ip_output.c: ip_finish_output
> - ip_output.c: sysctl_ip_default_ttl
> - fib_frontend.c: ip_dev_find
> - inetpeer.c: inet_peer_idlock
> - ip_options.c: ip_options_compile
> - ip_options.c: ip_options_undo
> - tcp_ipv4.c: sysctl_max_syn_backlog
>
> Please review which of these changes are correct and which might
> conflict with pending patches.
Please keep all of the ECN implementation in the
tcp_ecn.h header file, even if the routine is only
called in one C file.
And therefore, please do not remove the tcp_enter_quickack_mode()
extern declaration from tcp.h
Thanks.
^ permalink raw reply
* [-mm patch] fix recursive IPW2200 dependencies
From: Adrian Bunk @ 2005-06-02 20:07 UTC (permalink / raw)
To: Andrew Morton, jkmaline, jgarzik; +Cc: linux-kernel, hostap, netdev
In-Reply-To: <20050601022824.33c8206e.akpm@osdl.org>
On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc5-mm1:
>...
> +git-netdev-we18-ieee80211-wifi.patch
>
> Various things added and merged in netdev land.
>...
This results in recursive dependencies:
- IPW2200 depends on NET_RADIO
- IPW2200 selects IEEE80211
- IEEE80211 selects NET_RADIO
This patch fixes the IPW2200 dependencies in a way that they are similar
to the IPW2100 dependencies.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig.old 2005-06-02 22:04:02.000000000 +0200
+++ linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig 2005-06-02 22:04:40.000000000 +0200
@@ -192,9 +192,8 @@
config IPW2200
tristate "Intel PRO/Wireless 2200BG and 2915ABG Network Connection"
- depends on NET_RADIO && PCI
+ depends on IEEE80211 && PCI
select FW_LOADER
- select IEEE80211
---help---
A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network
Connection adapters.
^ permalink raw reply
* Re: [2.6 patch] net/ipv6/ipv6_syms.c: unexport fl6_sock_lookup
From: David S. Miller @ 2005-06-02 20:06 UTC (permalink / raw)
To: bunk; +Cc: akpm, netdev, linux-kernel, yoshfuji
In-Reply-To: <20050530205653.GZ10441@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Mon, 30 May 2005 22:56:53 +0200
> There is no usage of this EXPORT_SYMBOL in the kernel.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> Acked-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* Re: [2.6 patch] remove net/ipv4/ipvs/ip_vs_proto_icmp.c?
From: David S. Miller @ 2005-06-02 20:02 UTC (permalink / raw)
To: bunk; +Cc: ja, wensong, netdev, linux-kernel
In-Reply-To: <20050515132906.GW16549@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 15 May 2005 15:29:06 +0200
> ip_vs_proto_icmp.c was never finished.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: Locking model for NAPI drivers
From: Michael Chan @ 2005-06-02 19:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <1117661650.4310.62.camel@rh4>
On Wed, 2005-06-01 at 14:34 -0700, Michael Chan wrote:
> On Wed, 2005-06-01 at 15:21 -0700, David S. Miller wrote:
> > Since the caller shuts down NAPI ->poll(), after setting the SYNC bit
> > we can just check the MAILBOX register, and if a '1' is there just
> > return. Does one need to mask out the upper bits of the regiser in
> > order to avoid seeing the IRQ tag in such a comparison?
> >
> No, just check for the value 1 since that's the value we use to disable
> interrupts. The value read back will always be 1 if 1 was previously
> written to it.
>
One more race condition:
CPU1 CPU2
tg3_poll()
__netif_rx_complete()
tg3_netif_stop()
netif_poll_disable()
tg3_full_lock()
tg3_irq_quiesce()
tg3_restart_ints()
BUG_ON(tp->irq_state)
This race condition is somewhat harmless but I think we need to take
care of it for correctness. Any simple ways to fix it?
^ permalink raw reply
* Antw: Re: [PATCH] ieee80211: Update generic definitions to latest specs.
From: gwingerde @ 2005-06-02 19:02 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, jgarzik, jbohac
On Thu, 02 Jun 2005, Jiri Benc wrote:
> On Wed, 01 Jun 2005 22:50:51 +0200, Gertjan van Wingerde wrote:
> > +#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22
> > +#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23
> > +#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24
> > (...)
> > +/* 802.11h */
> > +#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10
> > +#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11
>
> Aren't these identifiers a bit too long? It seems to be unpractical to use
> them.
>
I was thinking about that too, but couldn't find a proper shorter
version without losing the descriptive meaning.
Do you have any suggestions to shorten them?
BR, Gertjan
^ permalink raw reply
* Re: R8169 from U.S.Robotics not found by driver
From: Francois Romieu @ 2005-06-02 18:34 UTC (permalink / raw)
To: Kutschera Peter; +Cc: Linux r8169 crew, jgarzik
In-Reply-To: <3BDD1137DBC16749ACF2C93F82FCA98DA107D2@s1ms3.D01.arc.local>
Kutschera Peter <Peter.Kutschera@arcs.ac.at> :
[...]
> If you have any tips please let me know.
Upgrade to (at your option):
- 2.6.12-rc5 + Jeff Garzik's r8169 git branch;
- 2.6.12-rc5-mm2.
Both contain the latest r8169 driver. It will handle USR hardware.
If you manage to kill it, please report it.
Would your setup allow to test the driver in the Mpps range by any luck ?
--
Ueimor
^ permalink raw reply
* [PATCH] net: fix sysctl_
From: Stephen Hemminger @ 2005-06-02 18:19 UTC (permalink / raw)
To: David S. Miller; +Cc: Mitch Williams, netdev
In-Reply-To: <Pine.CYG.4.58.0505261406210.2364@mawilli1-desk2.amr.corp.intel.com>
Changing the sysctl net.core.dev_weight has no effect because the weight
of the backlog devices is set during initialization and never changed.
This patch propagates any changes to the global value affected by sysctl
to the per-cpu devices. It is done every time the packet handler
function is run.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Index: skge-0.8/net/core/dev.c
===================================================================
--- skge-0.8.orig/net/core/dev.c
+++ skge-0.8/net/core/dev.c
@@ -1732,6 +1732,7 @@ static int process_backlog(struct net_de
struct softnet_data *queue = &__get_cpu_var(softnet_data);
unsigned long start_time = jiffies;
+ backlog_dev->weight = weight_p;
for (;;) {
struct sk_buff *skb;
struct net_device *dev;
^ permalink raw reply
* [PATCH] net: allow controlling NAPI weight with sysfs
From: Stephen Hemminger @ 2005-06-02 18:14 UTC (permalink / raw)
To: David S. Miller
Cc: Mitch Williams, netdev, john.ronciak, ganesh.venkatesan,
jesse.brandeburg
In-Reply-To: <Pine.CYG.4.58.0505261406210.2364@mawilli1-desk2.amr.corp.intel.com>
Simple interface to allow changing network device scheduling weight
with sysfs. Please consider this for 2.6.12, since risk/impact is small.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Index: napi-sysfs/net/core/net-sysfs.c
===================================================================
--- napi-sysfs.orig/net/core/net-sysfs.c
+++ napi-sysfs/net/core/net-sysfs.c
@@ -184,6 +184,22 @@ static ssize_t store_tx_queue_len(struct
static CLASS_DEVICE_ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len,
store_tx_queue_len);
+NETDEVICE_SHOW(weight, fmt_ulong);
+
+static int change_weight(struct net_device *net, unsigned long new_weight)
+{
+ net->weight = new_weight;
+ return 0;
+}
+
+static ssize_t store_weight(struct class_device *dev, const char *buf, size_t len)
+{
+ return netdev_store(dev, buf, len, change_weight);
+}
+
+static CLASS_DEVICE_ATTR(weight, S_IRUGO | S_IWUSR, show_weight,
+ store_weight);
+
static struct class_device_attribute *net_class_attributes[] = {
&class_device_attr_ifindex,
@@ -193,6 +209,7 @@ static struct class_device_attribute *ne
&class_device_attr_features,
&class_device_attr_mtu,
&class_device_attr_flags,
+ &class_device_attr_weight,
&class_device_attr_type,
&class_device_attr_address,
&class_device_attr_broadcast,
^ permalink raw reply
* [PATCH] Scalable TCP (cleaned)
From: Stephen Hemminger @ 2005-06-02 17:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: John Heffner, netdev
In-Reply-To: <200505251550.42252.jheffner@psc.edu>
Here is a whitespace cleaned up version of John's scaleable TCP patch
to go with the other TCP congestion algorithms, to put in -mm.
--------
This patch implements Tom Kelly's Scalable TCP congestion control algorithm
for the modular framework.
The algorithm has some nice scaling properties, and has been used a fair bit
in research, though is known to have significant fairness issues, so it's not
really suitable for general purpose use.
Signed-off-by: John Heffner <jheffner@psc.edu>
Index: 2.6.12-rc5-tcp3/net/ipv4/Makefile
===================================================================
--- 2.6.12-rc5-tcp3.orig/net/ipv4/Makefile
+++ 2.6.12-rc5-tcp3/net/ipv4/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_high
obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
+obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
xfrm4_output.o
Index: 2.6.12-rc5-tcp3/net/ipv4/tcp_scalable.c
===================================================================
--- /dev/null
+++ 2.6.12-rc5-tcp3/net/ipv4/tcp_scalable.c
@@ -0,0 +1,68 @@
+/* Tom Kelly's Scalable TCP
+ *
+ * See htt://www-lce.eng.cam.ac.uk/~ctk21/scalable/
+ *
+ * John Heffner <jheffner@sc.edu>
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <net/tcp.h>
+
+/* These factors derived from the recommended values in the paper:
+ * .01 and and 7/8. We use 50 instead of 100 to account for
+ * delayed ack.
+ */
+#define TCP_SCALABLE_AI_CNT 50U
+#define TCP_SCALABLE_MD_SCALE 3
+
+static void tcp_scalable_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt,
+ u32 in_flight, int flag)
+{
+ if (in_flight < tp->snd_cwnd)
+ return;
+
+ if (tp->snd_cwnd <= tp->snd_ssthresh) {
+ tp->snd_cwnd++;
+ } else {
+ tp->snd_cwnd_cnt++;
+ if (tp->snd_cwnd_cnt > min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT)){
+ tp->snd_cwnd++;
+ tp->snd_cwnd_cnt = 0;
+ }
+ }
+ tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp);
+ tp->snd_cwnd_stamp = tcp_time_stamp;
+}
+
+static u32 tcp_scalable_ssthresh(struct tcp_sock *tp)
+{
+ return max(tp->snd_cwnd - (tp->snd_cwnd>>TCP_SCALABLE_MD_SCALE), 2U);
+}
+
+
+static struct tcp_congestion_ops tcp_scalable = {
+ .ssthresh = tcp_scalable_ssthresh,
+ .cong_avoid = tcp_scalable_cong_avoid,
+ .min_cwnd = tcp_reno_min_cwnd,
+
+ .owner = THIS_MODULE,
+ .name = "scalable",
+};
+
+static int __init tcp_scalable_register(void)
+{
+ return tcp_register_congestion_control(&tcp_scalable);
+}
+
+static void __exit tcp_scalable_unregister(void)
+{
+ tcp_unregister_congestion_control(&tcp_scalable);
+}
+
+module_init(tcp_scalable_register);
+module_exit(tcp_scalable_unregister);
+
+MODULE_AUTHOR("John Heffner");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Scalable TCP");
Index: 2.6.12-rc5-tcp3/net/ipv4/Kconfig
===================================================================
--- 2.6.12-rc5-tcp3.orig/net/ipv4/Kconfig
+++ 2.6.12-rc5-tcp3/net/ipv4/Kconfig
@@ -481,6 +481,15 @@ config TCP_CONG_VEGAS
window. TCP Vegas should provide less packet loss, but it is
not as aggressive as TCP Reno.
+config TCP_CONG_SCALABLE
+ tristate "Scalable TCP"
+ depends on EXPERIMENTAL
+ default n
+ ---help---
+ Scalable TCP is a sender-side only change to TCP which uses a
+ MIMD congestion control algorithm which has some nice scaling
+ properties, though is known to have fairness issues.
+ See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
endmenu
^ permalink raw reply
* Re: Unable to handle kernel paging request at virtual address 04000460
From: Stephen Hemminger @ 2005-06-02 17:44 UTC (permalink / raw)
To: raghunathan.venkatesan; +Cc: davem, linux-net, netdev, linux
In-Reply-To: <438662DA48DCAA41B1DF648BD4BD76C0E461B8@CHN-SNR-MBX01.wipro.com>
On Thu, 2 Jun 2005 09:20:21 +0530
<raghunathan.venkatesan@wipro.com> wrote:
> Hi David,
> I understand that the linux community may not be able to debug it for
> me. All I require is if people have seen similar problems (the problems
> we face are w.r.t to kfree_skb and skb_drop_fraglist crashing due to
> some reason, which could be a Memory Management issue or some thing we
> are not aware of), then let us know the patches, so that we can try them
> out here.
Turn on Debug memory allocations, spinlock debugging, sleep-inside-spinlock
checking, and preempt, it will help your debugging. If you are not building
your own kernel from source learn how.
You are probably freeing memory twice, or not doing ref counting properly
or other locking issues. Since it is your code, good luck debugging it,
if you want the community help it needs to be open source code that
is available for download or be in the kernel.org kernel.
^ permalink raw reply
* Re: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages
From: Stephen Hemminger @ 2005-06-02 17:38 UTC (permalink / raw)
To: Baruch Even; +Cc: Adrian Bunk, Andrew Morton, linux-kernel, netdev
In-Reply-To: <429F1079.5070701@ev-en.org>
On Thu, 02 Jun 2005 14:58:17 +0100
Baruch Even <baruch@ev-en.org> wrote:
> Adrian Bunk wrote:
> > On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote:
> >
> >>...
> >>Changes since 2.6.12-rc5-mm1:
> >>...
> >>+tcp-tcp_infra.patch
> >>...
> >> Steve Hemminger's TCP enhancements.
> >>...
> >
> >
> > I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages
> > kernel: bic unavailable using TCP reno
> >
> > I have no problem with such a message being shown once - but once should
> > be enough.
>
> The best solution for this would be to check the available protocols at
> setup time and not at connection creation time. This would also provide
> a better feedback to the user, since he will either see that what he set
> was taken, or it wasn't.
>
> In the current mechanism you can set the protocol to 'foo' and it will
> show back as 'foo'. You'll get complaints only once a connection is
> attempted with this protocol.
>
> It does mean some extra work in the sysctl stage, but it's better IMO to
> do it there rather than at connection setup time.
>
> Baruch
Your right, the sysctl handler should be smarter, but that is not the problem here.
The problem is that the default value is set to be BIC to be compatible with earlier kernels.
Since 75% of the world isn't smart enough to figure out how to use sysctl, there is a
question of what the default should be, and what to do if that is missing.
One version had a messy ifdef chain to try and avoid the warning:
char sysctl_tcp_congestion_control[] =
#if defined(CONFIG_TCP_BIC)
"bic"
#elif defined(CONFIG_TCP_HTCP)
"htcp"
#else
"reno"
#endif
;
but that was ugly.
Another possibility is putting it in as yet another config value at kernel build time.
To suppress the warning repeating, probably the best solution would be rewrite the string
if we have to revert to reno. But carefully to avoid SMP issues. This also implies a smarter
sysctl string handler for this value as well.
P.s: saw your comparison paper, after a little more corroboration I would like to make
H-TCP the default.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Stephen Hemminger @ 2005-06-02 17:30 UTC (permalink / raw)
To: hadi
Cc: Jon Mason, David S. Miller, mitch.a.williams, netdev,
Robert.Olsson, john.ronciak, ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <1117715207.6050.21.camel@localhost.localdomain>
On Thu, 02 Jun 2005 08:26:46 -0400
jamal <hadi@cyberus.ca> wrote:
> On Tue, 2005-31-05 at 18:28 -0500, Jon Mason wrote:
> > On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote:
> > > From: Jon Mason <jdmason@us.ibm.com>
> > > Date: Tue, 31 May 2005 17:07:54 -0500
> > >
> > > > Of course some performace analysis would have to be done to determine the
> > > > optimal numbers for each speed/duplexity setting per driver.
> > >
> > > per cpu speed, per memory bus speed, per I/O bus speed, and add in other
> > > complications such as NUMA
> > >
> > > My point is that whatever experimental number you come up with will be
> > > good for that driver on your systems, not necessarily for others.
> > >
> > > Even within a system, whatever number you select will be the wrong
> > > thing to use if one starts a continuous I/O stream to the SATA
> > > controller in the next PCI slot, for example.
> > >
> > > We keep getting bitten by this, as the Altix perf data continually shows,
> > > and we need to absolutely stop thinking this way.
> > >
> > > The way to go is to make selections based upon observed events and
> > > mesaurements.
> >
> > I'm not arguing against a /proc entry to tune dev->weight for those sysadmins
> > advanced enough to do that. I am arguing that we can make the driver smarter
> > (at little/no cost) for "out of the box" users.
> >
>
> What is the point of making the driver "smarter"?
> Recall, the algorithm used to schedule the netdevices is based on an
> extension of Weighted Round Robin from Varghese et al known as DRR (ask
> gooogle for details).
> The idea is to provide fairness amongst many drivers. As an example, if
> you have a gige driver it shouldnt be taking all the resources at the
> expense of starving the fastether driver.
> If the admin wants one driver to be more "important" than the other,
> s/he will make sure it has a higher weight.
>
In fact, since the default weighting should be based on the amount of cpu time expended
per frame rather than link speed. The point is that a more "heavy weight" driver shouldn't
starve out all the others.
^ permalink raw reply
* Re: [PATCH] ieee80211: Update generic definitions to latest specs.
From: Jiri Benc @ 2005-06-02 16:50 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: netdev, jgarzik, jbohac
In-Reply-To: <429E1FAB.6080503@home.nl>
On Wed, 01 Jun 2005 22:50:51 +0200, Gertjan van Wingerde wrote:
> +#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22
> +#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23
> +#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24
> (...)
> +/* 802.11h */
> +#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10
> +#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11
Aren't these identifiers a bit too long? It seems to be unpractical to use
them.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* R8169 from U.S.Robotics not found by driver
From: Kutschera Peter @ 2005-06-02 15:50 UTC (permalink / raw)
To: Linux r8169 crew
Hello to whoever is out there!
I found your e-mail address in r8169.c:
MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@oss.sgi.com>");
MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
Maybe you are interested in the following problem?
I just bought a new 1000MB NIC from U.S.Robotics since I was thinking there is a driver in kernel 2.6.8.
It wasn't.
But there is a driver (on the CD and also downloadable from http://www.usr.com/support/product-template.asp?prod=7902 (see linux.exe :-))
And there is also a newer driver in 2.6.11.
The different results are:
Modprobe r8169
with the driver from 2.6.8 or 2.6.11 simple has no effect - the module is loaded but there is no error message, no eth1 (it's my 2nd network card, eth0 in onboard) and nothing in dmesg :-(
I was building and using the driver from U.S.Robotics with 2.6.8 and 2.6.11:
pinguc1:~# modprobe r8169
pinguc1:~# dmesg | tail
ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 25 (level, low) -> IRQ 193
eth1: Identified chip type is 'RTL8169s/8110s'.
eth1: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at 0xf89e8000, 00:c0:49:59:28:71, IRQ 193
eth1: Auto-negotiation Enabled.
eth1: 1000Mbps Full-duplex operation.
pinguc1:~# ifup eth1
pinguc1:~# ping cluster2
PING cluster2 (192.168.1.2) 56(84) bytes of data.
64 bytes from cluster2 (192.168.1.2): icmp_seq=1 ttl=64 time=0.069 ms
Fine, isnt' it?
NO IT IS NOT :-(
It works fine for a wile but when starting to put LOTS OF DATA about this interface:
pinguc1:~# dmesg | tail
irq 193: nobody cared!
[<c012d769>] __report_bad_irq+0x31/0x77
[<c012d813>] note_interrupt+0x4c/0x71
[<c012d318>] __do_IRQ+0xd9/0x121
[<c0104e9f>] do_IRQ+0x1b/0x28
[<c0103b02>] common_interrupt+0x1a/0x20
[<c010101c>] default_idle+0x0/0x29
[<c010103f>] default_idle+0x23/0x29
[<c01010ad>] cpu_idle+0x39/0x4e
[<c0358686>] start_kernel+0x178/0x17c
handlers:
[<f89dc386>] (rtl8169_interrupt+0x0/0x7e [r8169])
Disabling IRQ #193
No interrupt - No data transfer
Maybe some of the following is usefull for you?
pinguc1:~# lspci
0000:00:00.0 Host bridge: ServerWorks GCNB-LE Host Bridge (rev 32)
0000:00:00.1 Host bridge: ServerWorks GCNB-LE Host Bridge
0000:00:02.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controlle
r (rev 02)
0000:00:04.0 Ethernet controller: U.S. Robotics: Unknown device 0116 (rev 10)
0000:00:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
0000:00:0f.0 Host bridge: ServerWorks CSB5 South Bridge (rev 93)
0000:00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93)
0000:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05)
0000:00:0f.3 ISA bridge: ServerWorks CSB5 LPC bridge
0000:00:10.0 Host bridge: ServerWorks CIOB-X2 PCI-X I/O Bridge (rev 05)
0000:00:10.2 Host bridge: ServerWorks CIOB-X2 PCI-X I/O Bridge (rev 05)
0000:01:02.0 RAID bus controller: American Megatrends Inc. MegaRAID (rev 02)
0000:01:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fu
sion-MPT Dual Ultra320 SCSI (rev 07)
pinguc1:~# hd /proc/bus/pci/01/04.0
00000000 00 10 30 00 17 01 30 02 07 00 00 01 10 48 00 00 |..0...0......H..|
00000010 01 dc 00 00 04 00 f1 fc 00 00 00 00 04 00 f0 fc |.Ü....ñü......ðü|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 28 10 35 01 |............(.5.|
00000030 00 00 e0 fc 50 00 00 00 00 00 00 00 0b 01 11 12 |..àüP...........|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 01 58 02 06 00 00 00 00 05 00 80 00 00 00 00 00 |.X..............|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100
I am not sure if this is a problem of the USR-hriver or the hardware (Dell PowerEdge 1600).
I would like to test your driver but it seems to me that your driver can't find the card.
On another PC running the same software (debian sage with 3.6.8 cernel and USR-driver on the other end of the cable) the module from USR seems to work.
If you have any tips please let me know.
In the meantime i will try another PCI slot and, as iI expect this will not help, an old 3C509. Not the best choice for a linux cluster I think.
Thanks
Peter
--
Dipl.-Ing. Peter Kutschera
tel: +43 664 620 7642
http://Peter.Kutschera.at/
mailto:Peter@Kutschera.at
^ permalink raw reply
* Re: Problems with Broadcom and Intel PRO/1000 cards
From: Alfredo Beaumont Sainz @ 2005-06-02 14:11 UTC (permalink / raw)
To: netdev
In-Reply-To: <d7mqpp$pnn$1@harrier.cohaesio.com>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
Og, 2005eko Ekaren 02a 13:34(e)an, Anders K. Pedersen(e)k idatzi zuen:
> Alfredo Beaumont Sainz wrote:
> > I've a dual opteron machine with an integrated dual Broadcom 5704
> > 10/100/1000 (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It
> > seems that I cannot make them work a Gbps. I've a crossover cable
> > connecting a interface of the Broadcom (eth1) with the Intel (eth2), but
> > they connect at 100Mbps:
> >
> > # /sbin/mii-tool -v
>
> mii-tool does not (yet) support more than 100 Mbit/s, so it will report
> a 1000 Mbit/s connection as only running 100 Mbit/s. Use ethtool for now.
Ouch, you are right. They are really working at 1000Mbit/s. I should have
checked that. They work with a crossover cable, but I still have problems with
the switch. I'll further investigate before posting again.
Thanks!
--
Alfredo Beaumont. GPG: http://aintel.bi.ehu.es/~jtbbesaa/jtbbesaa.gpg.asc
Elektronika eta Telekomunikazioak Saila (Ingeniaritza Telematikoa)
Euskal Herriko Unibertsitatea, Bilbao (Basque Country). http://www.ehu.es
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages
From: Baruch Even @ 2005-06-02 13:58 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, shemminger, linux-kernel, netdev
In-Reply-To: <20050602121511.GE4992@stusta.de>
Adrian Bunk wrote:
> On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote:
>
>>...
>>Changes since 2.6.12-rc5-mm1:
>>...
>>+tcp-tcp_infra.patch
>>...
>> Steve Hemminger's TCP enhancements.
>>...
>
>
> I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages
> kernel: bic unavailable using TCP reno
>
> I have no problem with such a message being shown once - but once should
> be enough.
The best solution for this would be to check the available protocols at
setup time and not at connection creation time. This would also provide
a better feedback to the user, since he will either see that what he set
was taken, or it wasn't.
In the current mechanism you can set the protocol to 'foo' and it will
show back as 'foo'. You'll get complaints only once a connection is
attempted with this protocol.
It does mean some extra work in the sysctl stage, but it's better IMO to
do it there rather than at connection setup time.
Baruch
^ permalink raw reply
* PATCH: ioctl send PID in netlink events
From: jamal @ 2005-06-02 13:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
This is where i was trying to get to ;->
This patch is on top of the earlier one i sent for explicit types.
I still have to think about how to best do IPV6 routes as well as ARP
and NDISC. If anyone has suggestions or wants to tackle them let me
know, the v6 route is not going to be a pretty one i think.
cheers,
jamal
This patch ensures that netlink events created as a result of programns
using ioctls (such as ifconfig, route etc) contains the correct PID of
those events.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
[-- Attachment #2: ifconf_pid_p --]
[-- Type: text/plain, Size: 3399 bytes --]
net/core/rtnetlink.c: needs update
net/ipv4/devinet.c: needs update
net/ipv4/fib_semantics.c: needs update
net/ipv6/addrconf.c: needs update
Index: net/core/rtnetlink.c
===================================================================
--- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/core/rtnetlink.c (mode:100644)
+++ uncommitted/net/core/rtnetlink.c (mode:100644)
@@ -452,7 +452,7 @@
if (!skb)
return;
- if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) {
+ if (rtnetlink_fill_ifinfo(skb, dev, type, current->pid, 0, change, 0) < 0) {
kfree_skb(skb);
return;
}
Index: net/ipv4/devinet.c
===================================================================
--- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/devinet.c (mode:100644)
+++ uncommitted/net/ipv4/devinet.c (mode:100644)
@@ -236,6 +236,7 @@
struct in_ifaddr *promote = NULL;
struct in_ifaddr *ifa1 = *ifap;
+ printk("inet_del_ifa: pid %d\n",current->pid);
ASSERT_RTNL();
/* 1. Deleting primary ifaddr forces deletion all secondaries
@@ -305,6 +306,7 @@
ASSERT_RTNL();
+ printk("inet_insert_ifa: pid %d\n",current->pid);
if (!ifa->ifa_local) {
inet_free_ifa(ifa);
return 0;
@@ -1112,7 +1114,7 @@
if (!skb)
netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, ENOBUFS);
- else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
+ else if (inet_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, EINVAL);
} else {
Index: net/ipv4/fib_semantics.c
===================================================================
--- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/fib_semantics.c (mode:100644)
+++ uncommitted/net/ipv4/fib_semantics.c (mode:100644)
@@ -276,7 +276,7 @@
struct nlmsghdr *n, struct netlink_skb_parms *req)
{
struct sk_buff *skb;
- u32 pid = req ? req->pid : 0;
+ u32 pid = req ? req->pid : n->nlmsg_pid;
int size = NLMSG_SPACE(sizeof(struct rtmsg)+256);
skb = alloc_skb(size, GFP_KERNEL);
@@ -1035,7 +1035,7 @@
}
nl->nlmsg_flags = NLM_F_REQUEST;
- nl->nlmsg_pid = 0;
+ nl->nlmsg_pid = current->pid;
nl->nlmsg_seq = 0;
nl->nlmsg_len = NLMSG_LENGTH(sizeof(*rtm));
if (cmd == SIOCDELRT) {
Index: net/ipv6/addrconf.c
===================================================================
--- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv6/addrconf.c (mode:100644)
+++ uncommitted/net/ipv6/addrconf.c (mode:100644)
@@ -2872,7 +2872,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, ENOBUFS);
return;
}
- if (inet6_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
+ if (inet6_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, EINVAL);
return;
@@ -3007,7 +3007,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS);
return;
}
- if (inet6_fill_ifinfo(skb, idev, 0, 0, event, 0) < 0) {
+ if (inet6_fill_ifinfo(skb, idev, current->pid, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL);
return;
@@ -3064,7 +3064,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS);
return;
}
- if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event, 0) < 0) {
+ if (inet6_fill_prefix(skb, idev, pinfo, current->pid, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL);
return;
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: jamal @ 2005-06-02 13:33 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050531161315.GH15391@postel.suug.ch>
On Tue, 2005-31-05 at 18:13 +0200, Thomas Graf wrote:
[..]
> So what I propose is to have the neighbour table parameters,
> e.g. everything in arp_tbl be distributed over RTM_NEIGHTBL
> and put the device specific parameters into devconfig,
> e.g. in_dev->arp_parms.
>
Right, this is what i am saying a well.
The only caveat i was pointing out is that the devconfig piece is more
than just the neighbor stuff - and of course it hasnt been written,
yet;->
The major challenge will be events - some change via /proc, sysfs etc
should generate event.
I suggest something along usage of notifier_block with something like
NETDEV_CONFIG to transport these things around. Damn, if only i can find
my patch ....
I had already started doing events based on changes from /proc or sysctl
etc.
> Absolutely, more specific:
>
> netdevice -> inet_device -> parameter set -> neighbour table
> or:
> neighbour table -> list of parameter sets -> netdevice
>
> both ways are possible right now.
Sounds good to me.
cheers,
jamal
^ permalink raw reply
* Re: PATCH: explicit typing WAS(Re: PATCH: rtnetlink explicit flags setting
From: jamal @ 2005-06-02 13:30 UTC (permalink / raw)
To: David S. Miller; +Cc: tgraf, netdev
In-Reply-To: <1117717493.6050.29.camel@localhost.localdomain>
I should say this patch is against net-2.6.13.git as of 6am this
morning.
cheers,
jamal
On Thu, 2005-02-06 at 09:04 -0400, jamal wrote:
> -------------
> This patch converts "unsigned flags" to use more explict types like u16
> instead and incrementally introduces NLMSG_NEW().
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>
^ permalink raw reply
* PATCH: explicit typing WAS(Re: PATCH: rtnetlink explicit flags setting
From: jamal @ 2005-06-02 13:04 UTC (permalink / raw)
To: David S. Miller; +Cc: tgraf, netdev
In-Reply-To: <20050531.153125.95894437.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Tue, 2005-31-05 at 15:31 -0700, David S. Miller wrote:
> From: Thomas Graf <tgraf@suug.ch>
> Date: Wed, 1 Jun 2005 00:26:46 +0200
>
> > > Please use explicit "unsigned int flags" instead of "unsigned flags".
> >
> > I converted this already in the two patches later in the thread.
>
> I see, thanks for pointing this out.
>
If you want to do it right, it should be a u16 actually ;->
In any case since we are being gracious - lets fix where i cutnpasted it
from using TheLinuxWay ;->
-------------
This patch converts "unsigned flags" to use more explict types like u16
instead and incrementally introduces NLMSG_NEW().
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
[-- Attachment #2: expl_p --]
[-- Type: text/plain, Size: 5145 bytes --]
net/ipv6/addrconf.c: needs update
net/sched/act_api.c: needs update
net/sched/cls_api.c: needs update
net/sched/sch_api.c: needs update
Index: net/ipv6/addrconf.c
===================================================================
--- faa2ccd541211d62ece040534da95da9476d4f14/net/ipv6/addrconf.c (mode:100644)
+++ uncommitted/net/ipv6/addrconf.c (mode:100644)
@@ -131,7 +131,7 @@
static int addrconf_ifdown(struct net_device *dev, int how);
-static void addrconf_dad_start(struct inet6_ifaddr *ifp, int flags);
+static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags);
static void addrconf_dad_timer(unsigned long data);
static void addrconf_dad_completed(struct inet6_ifaddr *ifp);
static void addrconf_rs_timer(unsigned long data);
@@ -491,7 +491,7 @@
static struct inet6_ifaddr *
ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen,
- int scope, unsigned flags)
+ int scope, u32 flags)
{
struct inet6_ifaddr *ifa = NULL;
struct rt6_info *rt;
@@ -1319,7 +1319,7 @@
static void
addrconf_prefix_route(struct in6_addr *pfx, int plen, struct net_device *dev,
- unsigned long expires, unsigned flags)
+ unsigned long expires, u32 flags)
{
struct in6_rtmsg rtmsg;
@@ -2228,7 +2228,7 @@
/*
* Duplicate Address Detection
*/
-static void addrconf_dad_start(struct inet6_ifaddr *ifp, int flags)
+static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
{
struct inet6_dev *idev = ifp->idev;
struct net_device *dev = idev->dev;
@@ -2670,7 +2670,7 @@
}
static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca,
- u32 pid, u32 seq, int event, unsigned flags)
+ u32 pid, u32 seq, int event, u16 flags)
{
struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
Index: net/sched/act_api.c
===================================================================
--- faa2ccd541211d62ece040534da95da9476d4f14/net/sched/act_api.c (mode:100644)
+++ uncommitted/net/sched/act_api.c (mode:100644)
@@ -428,15 +428,15 @@
static int
tca_get_fill(struct sk_buff *skb, struct tc_action *a, u32 pid, u32 seq,
- unsigned flags, int event, int bind, int ref)
+ u16 flags, int event, int bind, int ref)
{
struct tcamsg *t;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
struct rtattr *x;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*t));
- nlh->nlmsg_flags = flags;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*t), flags);
+
t = NLMSG_DATA(nlh);
t->tca_family = AF_UNSPEC;
@@ -669,7 +669,7 @@
}
static int tcf_add_notify(struct tc_action *a, u32 pid, u32 seq, int event,
- unsigned flags)
+ u16 flags)
{
struct tcamsg *t;
struct nlmsghdr *nlh;
@@ -684,8 +684,7 @@
b = (unsigned char *)skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*t));
- nlh->nlmsg_flags = flags;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*t), flags);
t = NLMSG_DATA(nlh);
t->tca_family = AF_UNSPEC;
Index: net/sched/cls_api.c
===================================================================
--- faa2ccd541211d62ece040534da95da9476d4f14/net/sched/cls_api.c (mode:100644)
+++ uncommitted/net/sched/cls_api.c (mode:100644)
@@ -322,14 +322,13 @@
static int
tcf_fill_node(struct sk_buff *skb, struct tcf_proto *tp, unsigned long fh,
- u32 pid, u32 seq, unsigned flags, int event)
+ u32 pid, u32 seq, u16 flags, int event)
{
struct tcmsg *tcm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm));
- nlh->nlmsg_flags = flags;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
tcm = NLMSG_DATA(nlh);
tcm->tcm_family = AF_UNSPEC;
tcm->tcm_ifindex = tp->q->dev->ifindex;
Index: net/sched/sch_api.c
===================================================================
--- faa2ccd541211d62ece040534da95da9476d4f14/net/sched/sch_api.c (mode:100644)
+++ uncommitted/net/sched/sch_api.c (mode:100644)
@@ -760,15 +760,14 @@
}
static int tc_fill_qdisc(struct sk_buff *skb, struct Qdisc *q, u32 clid,
- u32 pid, u32 seq, unsigned flags, int event)
+ u32 pid, u32 seq, u16 flags, int event)
{
struct tcmsg *tcm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
struct gnet_dump d;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm));
- nlh->nlmsg_flags = flags;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
tcm = NLMSG_DATA(nlh);
tcm->tcm_family = AF_UNSPEC;
tcm->tcm_ifindex = q->dev->ifindex;
@@ -997,7 +996,7 @@
static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
unsigned long cl,
- u32 pid, u32 seq, unsigned flags, int event)
+ u32 pid, u32 seq, u16 flags, int event)
{
struct tcmsg *tcm;
struct nlmsghdr *nlh;
@@ -1005,8 +1004,7 @@
struct gnet_dump d;
struct Qdisc_class_ops *cl_ops = q->ops->cl_ops;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm));
- nlh->nlmsg_flags = flags;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
tcm = NLMSG_DATA(nlh);
tcm->tcm_family = AF_UNSPEC;
tcm->tcm_ifindex = q->dev->ifindex;
^ permalink raw reply
* RE: Problems with Broadcom and Intel PRO/1000 cards
From: Alejandro Bonilla @ 2005-06-02 13:04 UTC (permalink / raw)
To: 'Alfredo Beaumont Sainz', netdev
In-Reply-To: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es>
> Hi,
>
> I've a dual opteron machine with an integrated dual Broadcom
> 5704 10/100/1000
> (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It
> seems that I cannot
> make them work a Gbps. I've a crossover cable connecting a
> interface of the
> Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps:
>
Only time that I have seen this before, it was because I was using an
incorrect cable. Make sure you have the _REAL_ Gb crossover cable.
http://logout.sh/computers/net/gigabit/
Also, I would trust in dmesg and not in some other tool.
.Alejandro
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox