* Re: RDMA will be reverted
From: David Miller @ 2006-07-01 21:45 UTC (permalink / raw)
To: tom; +Cc: rdreier, netdev, akpm
In-Reply-To: <1151708503.11835.8.camel@trinity.ogc.int>
From: Tom Tucker <tom@opengridcomputing.com>
Date: Fri, 30 Jun 2006 18:01:43 -0500
> 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 != TOE
You are taking my comment out of context. And the fact
that you removed the comment I am respond to, shows
that you really aren't following the conversation.
Roland stated that it has never been the case that we have
rejected adding support for a certain class of devices on the
kinds of merits being discussed in this thread. And I'm saying
that TOE is such a case where we have emphatically done so.
So I am not saying iWARP or RDMA is equal to TOE, and if you had
actually read this thread you would have understood that.
You're just looking for cannon fodder in my emails.
^ permalink raw reply
* Re: [PATCH 0 of 39] ipath - bug fixes, performanceenhancements,and portability improvements
From: Andrew Morton @ 2006-07-01 22:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: bos, rdreier, openib-general, linux-kernel, netdev
In-Reply-To: <20060701194323.GB10904@mellanox.co.il>
On Sat, 1 Jul 2006 22:43:23 +0300
"Michael S. Tsirkin" <mst@mellanox.co.il> wrote:
> Quoting r. Bryan O'Sullivan <bos@pathscale.com>:
> > Subject: Re: [PATCH 0 of 39] ipath - bug fixes, performanceenhancements,and portability improvements
> >
> > On Fri, 2006-06-30 at 19:31 +0300, Michael S. Tsirkin wrote:
> >
> > > OK, next week I'll put these into my tree, too.
> >
> > Thanks. The first 37 are in -mm; the last two you can drop until I sort
> > them out.
>
> What about patch 28?
>
I sent 1-27,29-37 to Linus and he has merged them. But I held #28 back based on
Roland's concerns.
^ permalink raw reply
* Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
From: Francois Romieu @ 2006-06-30 21:16 UTC (permalink / raw)
To: Marcus Better; +Cc: netdev
In-Reply-To: <e82qhq$4v0$1@sea.gmane.org>
Marcus Better <marcus@better.se> :
> I'm seeing this problem on my Acer Travelmate 223X laptop with built-in
> Realtek 8139: The ethernet stops working, usually after at most a few
> minutes operation. The problem appears in kernel 2.6.16 and 2.6.17, but not
> in 2.6.15.
Broken again :o(
In a better world, you would narrow the suspect with a git bissect [1]
between v2.6.15 and v2.6.16.
As an alternate solution, you may try the patches available at
http://www.fr.zoreil.com/people/francois/misc/8139 against v2.6.15,
starting from 0001 and going to 0006 (of course you can revert the
patches against v2.6.16 from 0006 to 0001 too). I can't claim that
each step will compile though.
[1] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
--
Ueimor
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Patrick McHardy @ 2006-07-02 4:23 UTC (permalink / raw)
To: hadi; +Cc: Stephen Hemminger, netdev, russell-tcatm, hawk,
Jesper Dangaard Brouer
In-Reply-To: <1151413263.6516.51.camel@jzny2>
Sorry, missed your reply so far.
>>Then what is the intent, it doesn't carry any other information?
>
>
> Generally it is a filter to what the ifi_flags reflect.
>>From an event architecture scalability perspective, it is useful to be
> able to look at what changed without having to query the source. That is
> what ifi_change provides. So it is not "Lazy userspace" rather it is an
> effective optimization.
> You keep less state and you have less message exchanges between user and
> kernel.
It might have been, but the situation is a bit more complicated today,
and special case solutions (aka hacks) don't work very well for the
huge diversity of interest in update messages. Besides that, it is
flawed.
>>It includes information that are not available any other way from
>>the kernel, yet the information is not transmitted reliably. How
>>could a program that relies on this possibly work reliable?
>
>
> Ok, so first lets separate them as two different issues:
>
> - Any message to user space may be lost whether it has ifi_change or
> not. You need some way to figure out a message was lost and declare your
> state may be invalid. The -ENOBUFs is one way to discover stale state.
Thats not the point. ifi_change doesn't inform you about updates, it
informs you about specific changes. And you can't determine those in
the case of lost notifications without keeping the old state yourself.
It may save you some time _comparing_ (not searching) in case it wasn't
lost, but it only contains a very limited set of information and nothing
saves you from searching the entry a message refers to based on the
primary keys (which unfortunately aren't even defined for every message
type, which means they're not even clearly defined inside the kernel.
routing rules are one example). Its a hack for some specific usage case,
and since you're defending this so hard, I'm naturally wondering if
you introduced it?
> - by looking at ifi_change i can tell what changed from about 10
> other things reflected in the flags. If you get an ENOBUFS in this case
> (or any other), it means your state is not consistent and to have
> reliable info you need to query the kernel.
The flags only reflect a single piece of information, one that userspace
needs to be able to reconstruct anyway. Once again the point: netlink
notifications are _update_ messages, not state change messages. This is
a fundamental difference, misleading userspace (see tc monitor) to
believing it is something different for very limited usage cases does
nothing good. I hereby state my believe that 99% of netlink users
are broken.
> Hope that makes sense.
Me too :)
^ permalink raw reply
* Two I/O memory regions in /proc/iomem for a NIC
From: John Que @ 2006-07-02 7:24 UTC (permalink / raw)
To: netdev
Hello,
I had noticed that there are machines where
if I ran cat /proc/iomem I see one I/O memory region for the NIC
I am using; while there are other machines where
I see 2 regions for the NIC I/O memory.
For example, on a machine with e1000 NIC adapter,
I see the following 2 I/O memory regions for the NIC:
fc9a0000-fc9bffff : 0000:03:04.0
fc9a0000-fc9bffff : e1000
fc9c0000-fc9dffff : 0000:03:03.0
fc9c0000-fc9dffff : e1000
while on a machine with realtek 8139too NIC I see only one region:
ec103000-ec1030ff : 0000:00:0a.0
ec103000-ec1030ff : 8139too
But when looking at the code of both NICs, there
is only one call to pci_request_regions(), which seems
quite similiar in both cases and is called only once;
see the call to pci_request_regions() in drivers/net/e1000/e1000_main.c
and in drivers/net/8139too.c.
Any idea why is this so ? can anybody say 3-4 sentences
about this ?
TIA,
-- John
^ permalink raw reply
* Re: Two I/O memory regions in /proc/iomem for a NIC
From: Lennert Buytenhek @ 2006-07-02 9:12 UTC (permalink / raw)
To: John Que; +Cc: netdev
In-Reply-To: <ada605fb0607020024o15c8e4b4j83f37102492e8932@mail.gmail.com>
On Sun, Jul 02, 2006 at 10:24:10AM +0300, John Que wrote:
> I had noticed that there are machines where
> if I ran cat /proc/iomem I see one I/O memory region for the NIC
> I am using; while there are other machines where
> I see 2 regions for the NIC I/O memory.
>
> For example, on a machine with e1000 NIC adapter,
> I see the following 2 I/O memory regions for the NIC:
> fc9a0000-fc9bffff : 0000:03:04.0
> fc9a0000-fc9bffff : e1000
> fc9c0000-fc9dffff : 0000:03:03.0
> fc9c0000-fc9dffff : e1000
Is it a dual-port NIC by any chance?
cheers,
Lennert
^ permalink raw reply
* Re: Two I/O memory regions in /proc/iomem for a NIC
From: Jeff Garzik @ 2006-07-02 11:12 UTC (permalink / raw)
To: John Que; +Cc: netdev
In-Reply-To: <ada605fb0607020024o15c8e4b4j83f37102492e8932@mail.gmail.com>
On Sun, Jul 02, 2006 at 10:24:10AM +0300, John Que wrote:
> Hello,
>
> I had noticed that there are machines where
> if I ran cat /proc/iomem I see one I/O memory region for the NIC
> I am using; while there are other machines where
> I see 2 regions for the NIC I/O memory.
>
> For example, on a machine with e1000 NIC adapter,
> I see the following 2 I/O memory regions for the NIC:
> fc9a0000-fc9bffff : 0000:03:04.0
> fc9a0000-fc9bffff : e1000
> fc9c0000-fc9dffff : 0000:03:03.0
> fc9c0000-fc9dffff : e1000
There could be 1001 reasons. Overall, it's not important :)
e1000 driver will reserve all regions made available by the PCI device.
Jeff
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: jamal @ 2006-07-02 13:59 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jesper Dangaard Brouer, hawk, russell-tcatm, netdev,
Stephen Hemminger
In-Reply-To: <44A74A44.4000304@trash.net>
On Sun, 2006-02-07 at 06:23 +0200, Patrick McHardy wrote:
[..]
> > - Any message to user space may be lost whether it has ifi_change or
> > not. You need some way to figure out a message was lost and declare your
> > state may be invalid. The -ENOBUFs is one way to discover stale state.
>
> Thats not the point. ifi_change doesn't inform you about updates, it
> informs you about specific changes.
yes,
> And you can't determine those in
> the case of lost notifications without keeping the old state yourself.
nod,
> It may save you some time _comparing_ (not searching) in case it wasn't
> lost,
This is one of the points of where it has value.
Take a hypothetical example of when you have a gazillion events/sec
happening, this is an exageration in case of ifi_change, just assume it
so for illustration purposes. Assume no messages are lost. Assume you
are only interested in the netdevice becoming promisc or un-promisc.
In such a case, you can quickly check if among the vector of events
that this just happened or not.
> but it only contains a very limited set of information and nothing
> saves you from searching the entry a message refers to based on the
> primary keys (which unfortunately aren't even defined for every message
> type, which means they're not even clearly defined inside the kernel.
> routing rules are one example).
In some cases it does provide you with details - example in the case of
booleans where it will tell you something changed from 0->1 or 1->0.
Actually the promisc case i gave is a bad example because it falls under
such a category although i hope it still made the point i was trying to
make.
But yes in general, it is just supposed to provide you with info of
"dude, you got a message from X and Y" - which is more useful than the
select() "dude, you got a message". You have then to go and read that
message if you are interested or if you are busy you can go later.
> Its a hack for some specific usage case,
> and since you're defending this so hard, I'm naturally wondering if
> you introduced it?
>
No, i didnt - it has been there for years; it may/must have been Alexey
who introduced it.
The reason i am defending it is i find it useful and it is a classical
approach in event management; i have seen it used in a lot of middleware
as an optimization. When you have a vector of events that can be
reported, then as optimization you dont waste resources by sending
details about the event in case nobody is interested in hearing about
the details or is ready to process them.
BTW,theres a consistency bug/hack at the moment in iproute2 on its
usage.
> > - by looking at ifi_change i can tell what changed from about 10
> > other things reflected in the flags. If you get an ENOBUFS in this case
> > (or any other), it means your state is not consistent and to have
> > reliable info you need to query the kernel.
>
> The flags only reflect a single piece of information, one that userspace
> needs to be able to reconstruct anyway. Once again the point: netlink
> notifications are _update_ messages, not state change messages. This is
> a fundamental difference, misleading userspace (see tc monitor) to
> believing it is something different for very limited usage cases does
> nothing good. I hereby state my believe that 99% of netlink users
> are broken.
>
yes, it would mislead users who dont use it appropriately such as ip mon
but that doesnt make it less valuable. I thought ip mon would bitch if
it received enobufs?
cheers,
jamal
^ permalink raw reply
* Re: Two I/O memory regions in /proc/iomem for a NIC
From: John Que @ 2006-07-02 15:37 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20060702111224.GA6624@havoc.gtf.org>
Hello,
Thanks for your answers.
I checked again: On the machine with e1000 driver, it was in fact a
machine with 2
e1000 NICs.
However, if I am not wrong, it happened I also saw 2 I/O regions on a
machine with one NIC
(RealTek 8139too) when typing cat /proc/iomem. I am not sure though.
Let me please rephrase my question:
As I understand , the NIC "probe" method is called only ONCE
(also when we have 2 NICs , which are identical so have the same
vendor ID; I hope I am not ).
So:
Could a single call to
pci_request_regions(pdev, driver_name)
result in that we see 2 regions afterwards when running
cat /proc/iomem?
As I understand, indeed this is the case.
Regards,
John
On 7/2/06, Jeff Garzik <jeff@garzik.org> wrote:
> On Sun, Jul 02, 2006 at 10:24:10AM +0300, John Que wrote:
> > Hello,
> >
> > I had noticed that there are machines where
> > if I ran cat /proc/iomem I see one I/O memory region for the NIC
> > I am using; while there are other machines where
> > I see 2 regions for the NIC I/O memory.
> >
> > For example, on a machine with e1000 NIC adapter,
> > I see the following 2 I/O memory regions for the NIC:
> > fc9a0000-fc9bffff : 0000:03:04.0
> > fc9a0000-fc9bffff : e1000
> > fc9c0000-fc9dffff : 0000:03:03.0
> > fc9c0000-fc9dffff : e1000
>
> There could be 1001 reasons. Overall, it's not important :)
>
> e1000 driver will reserve all regions made available by the PCI device.
>
> Jeff
>
>
>
>
^ permalink raw reply
* [IPROUTE]: Introduce tc monitor
From: jamal @ 2006-07-02 17:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Thomas Graf, Patrick McHardy
[-- Attachment #1: Type: text/plain, Size: 190 bytes --]
Speaking of events reminded me of this.. Managed to get some quality
time, so heres a patch against current iproute2 git that adds something
useful.
Stephen, please apply.
cheers,
jamal
[-- Attachment #2: tcmon_p --]
[-- Type: text/plain, Size: 7750 bytes --]
This patch adds ability to monitor tc events similar to ipmonitor.
User runs "tc monitor" (without quotes) and watches events of
addition, deletion and updates from qdiscs, classes, filters and
actions as they happen.
---
commit 00f2ad46f0040769f0d4e4541fe0731f20164664
tree 0b2f8dc690d5fd90269a4c4fc34dbf7fc005f4bc
parent 8f8a36487119a3cd1afe86a9649704aca088567b
author Jamal Hadi Salim <hadi@jzny2.(none)> Sun, 02 Jul 2006 13:12:51 -0400
committer Jamal Hadi Salim <hadi@jzny2.(none)> Sun, 02 Jul 2006 13:12:51 -0400
tc/Makefile | 4 +-
tc/m_action.c | 8 ++--
tc/tc.c | 5 ++-
tc/tc_class.c | 2 +
tc/tc_common.h | 5 +++
tc/tc_filter.c | 2 +
tc/tc_monitor.c | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
tc/tc_qdisc.c | 2 +
8 files changed, 128 insertions(+), 10 deletions(-)
diff --git a/tc/Makefile b/tc/Makefile
index 9d618ff..7640c58 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -1,6 +1,6 @@
TCOBJ= tc.o tc_qdisc.o tc_class.o tc_filter.o tc_util.o \
- m_police.o m_estimator.o m_action.o m_ematch.o \
- emp_ematch.yacc.o emp_ematch.lex.o
+ tc_monitor.o m_police.o m_estimator.o m_action.o \
+ m_ematch.o emp_ematch.yacc.o emp_ematch.lex.o
include ../Config
diff --git a/tc/m_action.c b/tc/m_action.c
index 2d2b0ed..a7efe72 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -293,7 +293,7 @@ tc_print_action(FILE * f, const struct r
return 0;
}
-static int do_print_action(const struct sockaddr_nl *who,
+int print_action(const struct sockaddr_nl *who,
struct nlmsghdr *n,
void *arg)
{
@@ -313,7 +313,7 @@ static int do_print_action(const struct
if (NULL == tb[TCA_ACT_TAB]) {
if (n->nlmsg_type != RTM_GETACTION)
- fprintf(stderr, "do_print_action: NULL kind\n");
+ fprintf(stderr, "print_action: NULL kind\n");
return -1;
}
@@ -434,7 +434,7 @@ int tc_action_gd(int cmd, unsigned flags
return 1;
}
- if (ans && do_print_action(NULL, &req.n, (void*)stdout) < 0) {
+ if (ans && print_action(NULL, &req.n, (void*)stdout) < 0) {
fprintf(stderr, "Dump terminated\n");
return 1;
}
@@ -536,7 +536,7 @@ #endif
perror("Cannot send dump request");
return 1;
}
- ret = rtnl_dump_filter(&rth, do_print_action, stdout, NULL, NULL);
+ ret = rtnl_dump_filter(&rth, print_action, stdout, NULL, NULL);
}
if (event == RTM_DELACTION) {
diff --git a/tc/tc.c b/tc/tc.c
index fa36ee0..789f6f6 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -181,7 +181,7 @@ static void usage(void)
{
fprintf(stderr, "Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }\n"
" tc [-force] -batch file\n"
- "where OBJECT := { qdisc | class | filter | action }\n"
+ "where OBJECT := { qdisc | class | filter | action | monitor }\n"
" OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -b[atch] [file] }\n");
}
@@ -199,6 +199,9 @@ static int do_cmd(int argc, char **argv)
if (matches(*argv, "actions") == 0)
return do_action(argc-1, argv+1);
+ if (matches(*argv, "monitor") == 0)
+ return do_tcmonitor(argc-1, argv+1);
+
if (matches(*argv, "help") == 0) {
usage();
return 0;
diff --git a/tc/tc_class.c b/tc/tc_class.c
index 894caa1..049584e 100644
--- a/tc/tc_class.c
+++ b/tc/tc_class.c
@@ -147,7 +147,7 @@ int tc_class_modify(int cmd, unsigned fl
int filter_ifindex;
__u32 filter_qdisc;
-static int print_class(const struct sockaddr_nl *who,
+int print_class(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg)
{
FILE *fp = (FILE*)arg;
diff --git a/tc/tc_common.h b/tc/tc_common.h
index 7e13582..5bfc43e 100644
--- a/tc/tc_common.h
+++ b/tc/tc_common.h
@@ -6,6 +6,11 @@ extern int do_qdisc(int argc, char **arg
extern int do_class(int argc, char **argv);
extern int do_filter(int argc, char **argv);
extern int do_action(int argc, char **argv);
+extern int do_tcmonitor(int argc, char **argv);
+extern int print_action(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg);
+extern int print_filter(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg);
+extern int print_qdisc(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg);
+ extern int print_class(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg);
struct tc_estimator;
extern int parse_estimator(int *p_argc, char ***p_argv, struct tc_estimator *est);
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index f6de840..3341b13 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -176,7 +176,7 @@ static int filter_ifindex;
static __u32 filter_prio;
static __u32 filter_protocol;
-static int print_filter(const struct sockaddr_nl *who,
+int print_filter(const struct sockaddr_nl *who,
struct nlmsghdr *n,
void *arg)
{
diff --git a/tc/tc_monitor.c b/tc/tc_monitor.c
new file mode 100644
index 0000000..1af6cf0
--- /dev/null
+++ b/tc/tc_monitor.c
@@ -0,0 +1,110 @@
+/*
+ * tc_monitor.c "tc monitor".
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Jamal Hadi Salim
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+#include <time.h>
+#include "rt_names.h"
+#include "utils.h"
+#include "tc_util.h"
+#include "tc_common.h"
+
+
+static void usage(void) __attribute__((noreturn));
+
+static void usage(void)
+{
+ fprintf(stderr, "Usage: tc monitor\n");
+ exit(-1);
+}
+
+
+int accept_tcmsg(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
+{
+ FILE *fp = (FILE*)arg;
+
+ if (n->nlmsg_type == RTM_NEWTFILTER || n->nlmsg_type == RTM_DELTFILTER) {
+ print_filter(who, n, arg);
+ return 0;
+ }
+ if (n->nlmsg_type == RTM_NEWTCLASS || n->nlmsg_type == RTM_DELTCLASS) {
+ print_class(who, n, arg);
+ return 0;
+ }
+ if (n->nlmsg_type == RTM_NEWQDISC || n->nlmsg_type == RTM_DELQDISC) {
+ print_qdisc(who, n, arg);
+ return 0;
+ }
+ if (n->nlmsg_type == RTM_GETACTION || n->nlmsg_type == RTM_NEWACTION ||
+ n->nlmsg_type == RTM_DELACTION) {
+ print_action(who, n, arg);
+ return 0;
+ }
+ if (n->nlmsg_type != NLMSG_ERROR && n->nlmsg_type != NLMSG_NOOP &&
+ n->nlmsg_type != NLMSG_DONE) {
+ fprintf(fp, "Unknown message: length %08d type %08x flags %08x\n",
+ n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
+ }
+ return 0;
+}
+
+int do_tcmonitor(int argc, char **argv)
+{
+ struct rtnl_handle rth;
+ char *file = NULL;
+ unsigned groups = RTMGRP_TC;
+
+ while (argc > 0) {
+ if (matches(*argv, "file") == 0) {
+ NEXT_ARG();
+ file = *argv;
+ } else {
+ if (matches(*argv, "help") == 0) {
+ usage();
+ } else {
+ fprintf(stderr, "Argument \"%s\" is unknown, try \"tc monitor help\".\n", *argv);
+ exit(-1);
+ }
+ }
+ argc--; argv++;
+ }
+
+ if (file) {
+ FILE *fp;
+ fp = fopen(file, "r");
+ if (fp == NULL) {
+ perror("Cannot fopen");
+ exit(-1);
+ }
+ return rtnl_from_file(fp, accept_tcmsg, (void*)stdout);
+ }
+
+ if (rtnl_open(&rth, groups) < 0)
+ exit(1);
+
+ ll_init_map(&rth);
+
+ if (rtnl_listen(&rth, accept_tcmsg, (void*)stdout) < 0) {
+ rtnl_close(&rth);
+ exit(2);
+ }
+
+ rtnl_close(&rth);
+ exit(0);
+}
diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
index e9174ab..76c78f2 100644
--- a/tc/tc_qdisc.c
+++ b/tc/tc_qdisc.c
@@ -162,7 +162,7 @@ #endif
static int filter_ifindex;
-static int print_qdisc(const struct sockaddr_nl *who,
+int print_qdisc(const struct sockaddr_nl *who,
struct nlmsghdr *n,
void *arg)
{
^ permalink raw reply related
* Re: 2.6.17: networking bug??
From: Jan Knutar @ 2006-07-02 17:39 UTC (permalink / raw)
To: John Heffner; +Cc: Mark Lord, Linux Kernel, netdev, Linus Torvalds, davem
In-Reply-To: <448EF85E.50405@psc.edu>
On Tuesday 13 June 2006 20:39, John Heffner wrote:
> The best thing you can do is try to find this broken box and inform its
> owner that it needs to be fixed. (If you can find out what it is, I'd
> be interested to know.) In the meantime, disabling window scaling will
> work around the problem for you.
I was bit by this "networking bug" too. The broken box turned out to be
the OpenBSD box I was trying to connect to.
The owner removed scrub from pf.conf, and connectivity was restored.
^ permalink raw reply
* Re: Belkin F5D7001de locks up my Athlon64 system
From: Michael Buesch @ 2006-07-02 18:28 UTC (permalink / raw)
To: Johann Uhrmann; +Cc: bcm43xx-dev, netdev, linville, Daniel Drake
In-Reply-To: <20060702113205.16230@gmx.net>
On Sunday 02 July 2006 13:32, Johann Uhrmann wrote:
> here is another log from the 2.6.17-mm4 kernel. This oops was the only
> one since reboot:
>
> bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1490:bc)[ 87.484118] bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1490:bcm43xx_find_lopair()
> [ 87.559086] bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1490:bcm43xx_find_lopair()
> [ 87.641350] bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1490:bcm43xx_find_lopair()
> [ ok ]
> * Configuring network interfaces... [ 88.126654] BUG: spinlock recursion on CPU#0, sh/9441
> [ 88.161695] lock: ffff81003acd93f0, .magic: dead4ead, .owner: sh/9441, .owner_cpu: 0
> [ 88.208502]
> [ 88.208503] Call Trace:
> [ 88.232081] [<ffffffff8026fbde>] show_trace+0xae/0x280
> [ 88.263329] [<ffffffff8026fff5>] dump_stack+0x15/0x20
> [ 88.294085] [<ffffffff80213db4>] spin_bug+0xb4/0xd0
> [ 88.324030] [<ffffffff80207651>] _raw_spin_lock+0x51/0x180
> [ 88.357591] [<ffffffff8026bd99>] _spin_lock_irqsave+0x39/0x50
> [ 88.392575] [<ffffffff885a86a5>] :bcm43xx:bcm43xx_ieee80211_hard_start_xmit+0x35/0xc0
> [ 88.439931] [<ffffffff80439d1b>] ieee80211_tx_frame+0x23b/0x2b0
> [ 88.476307] [<ffffffff80441764>] ieee80211softmac_send_mgt_frame+0x3f4/0x420
> [ 88.519427] [<ffffffff8044204f>] ieee80211softmac_auth_resp+0x30f/0x4c0
> [ 88.559954] [<ffffffff8043e3b9>] ieee80211_rx_mgt+0x759/0x830
> [ 88.595291] [<ffffffff885c00e5>] :bcm43xx:bcm43xx_rx+0x7f5/0x870
> [ 88.631757] [<ffffffff885c3601>] :bcm43xx:bcm43xx_dma_rx+0x581/0x680
> [ 88.670306] [<ffffffff885aba35>] :bcm43xx:bcm43xx_interrupt_tasklet+0x765/0xa80
> [ 88.714562] [<ffffffff80290e33>] tasklet_action+0x73/0xd0
> [ 88.747394] [<ffffffff802127c7>] __do_softirq+0x67/0xe0
> [ 88.779187] [<ffffffff80266c36>] call_softirq+0x1e/0x28
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.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_auth.c
===================================================================
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_auth.c 2006-07-02 19:37:26.000000000 +0200
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_auth.c 2006-07-02 20:19:12.000000000 +0200
@@ -116,6 +116,16 @@
kfree(auth);
}
+/* Sends an auth challenge. */
+static void
+ieee80211softmac_auth_challenge(void *_aq)
+{
+ struct ieee80211softmac_auth_queue_item *aq = _aq;
+
+ /* Send our response */
+ ieee80211softmac_send_mgt_frame(aq->mac, aq->net, IEEE80211_STYPE_AUTH, aq->state);
+}
+
/* Handle the auth response from the AP
* This should be registered with ieee80211 as handle_auth
*/
@@ -197,24 +207,25 @@
case IEEE80211SOFTMAC_AUTH_SHARED_CHALLENGE:
/* Check to make sure we have a challenge IE */
data = (u8 *)auth->info_element;
- if(*data++ != MFIE_TYPE_CHALLENGE){
+ if (*data++ != MFIE_TYPE_CHALLENGE) {
printkl(KERN_NOTICE PFX "Shared Key Authentication failed due to a missing challenge.\n");
break;
}
/* Save the challenge */
spin_lock_irqsave(&mac->lock, flags);
net->challenge_len = *data++;
- if(net->challenge_len > WLAN_AUTH_CHALLENGE_LEN)
+ if (net->challenge_len > WLAN_AUTH_CHALLENGE_LEN)
net->challenge_len = WLAN_AUTH_CHALLENGE_LEN;
- if(net->challenge != NULL)
+ if (net->challenge != NULL)
kfree(net->challenge);
net->challenge = kmalloc(net->challenge_len, GFP_ATOMIC);
memcpy(net->challenge, data, net->challenge_len);
aq->state = IEEE80211SOFTMAC_AUTH_SHARED_RESPONSE;
- spin_unlock_irqrestore(&mac->lock, flags);
- /* Send our response */
- ieee80211softmac_send_mgt_frame(mac, aq->net, IEEE80211_STYPE_AUTH, aq->state);
+ cancel_delayed_work(&aq->work);
+ INIT_WORK(&aq->work, &ieee80211softmac_auth_challenge, (void *)aq);
+ schedule_work(&aq->work);
+ spin_unlock_irqrestore(&mac->lock, flags);
return 0;
case IEEE80211SOFTMAC_AUTH_SHARED_PASS:
kfree(net->challenge);
--
Greetings Michael.
^ permalink raw reply
* [IPROUTE2] Generic netlink interface
From: jamal @ 2006-07-02 20:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Shailabh Nagar, Thomas Graf, netdev
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
very quiet today ..
Stephen,
I've been sitting on this for a while now; just tested against latest
kernels.
Another one on top of the other i.e against iproute2-git.
Shailabh, if you have time can you try just listing things, monitoring
etc; I dont think your tool fits here - but if you could try and use the
framework (cutnpaste from ctrl.c) and provide feedback i would
appreciate it.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
[-- Attachment #2: gnl-ctrl-p --]
[-- Type: text/plain, Size: 12952 bytes --]
This patch adds a generic netlink controller interface.
The controller is the only module using this at the moment.
Thomas has a sample user of genetlink that would fit here; bug him
for it.
---
commit 9cd6ca6d2a2b1b27fc3c98ecb8e081b19aa64019
tree ff513f5484e1dbe27ef8fbb6f2e31d82ffbdcb3b
parent 00f2ad46f0040769f0d4e4541fe0731f20164664
author Jamal Hadi Salim <hadi@jzny2.(none)> Sun, 02 Jul 2006 16:40:18 -0400
committer Jamal Hadi Salim <hadi@jzny2.(none)> Sun, 02 Jul 2006 16:40:18 -0400
Makefile | 2
genl/Makefile | 22 ++++
genl/ctrl.c | 284 +++++++++++++++++++++++++++++++++++++++++++++++++++++
genl/genl.c | 162 ++++++++++++++++++++++++++++++
genl/genl_utils.h | 22 ++++
5 files changed, 491 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index ac58cd9..3fc3a15 100644
--- a/Makefile
+++ b/Makefile
@@ -27,7 +27,7 @@ YACCFLAGS = -d -t -v
LDLIBS += -L../lib -lnetlink -lutil
-SUBDIRS=lib ip tc misc netem
+SUBDIRS=lib ip tc misc netem genl
LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
diff --git a/genl/Makefile b/genl/Makefile
new file mode 100644
index 0000000..4436508
--- /dev/null
+++ b/genl/Makefile
@@ -0,0 +1,22 @@
+GENLOBJ=genl.o
+
+include ../Config
+
+GENLMODULES :=
+GENLMODULES += ctrl.o
+
+GENLOBJ += $(GENLMODULES)
+
+GENLLIB :=
+
+LDFLAGS += -Wl,-export-dynamic -lm -ldl
+
+all: genl
+
+genl: $(GENLOBJ) $(LIBNETLINK) $(LIBUTIL) $(GENLLIB)
+
+install: all
+ install -m 0755 -s genl $(DESTDIR)$(SBINDIR)
+
+clean:
+ rm -f $(GENLOBJ) $(GENLLIB) genl
diff --git a/genl/ctrl.c b/genl/ctrl.c
new file mode 100644
index 0000000..0d4750d
--- /dev/null
+++ b/genl/ctrl.c
@@ -0,0 +1,284 @@
+/*
+ * ctrl.c generic netlink controller
+ *
+ * This program is free software; you can distribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: J Hadi Salim (hadi@cyberus.ca)
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+
+#include "utils.h"
+#include "genl_utils.h"
+
+static int usage(void)
+{
+ fprintf(stderr,"Usage: ctrl <CMD>\n" \
+ "CMD := get <PARMS> | list | monitor\n" \
+ "PARMS := name <name> | id <id>\n" \
+ "Examples:\n" \
+ "\tctrl ls\n" \
+ "\tctrl monitor\n" \
+ "\tctrl get name foobar\n" \
+ "\tctrl get id 0xF\n");
+ return -1;
+}
+
+int genl_ctrl_resolve_family(const char *family)
+{
+ struct rtnl_handle rth;
+ struct nlmsghdr *nlh;
+ struct genlmsghdr *ghdr;
+ int ret = 0;
+ struct {
+ struct nlmsghdr n;
+ char buf[4096];
+ } req;
+
+ memset(&req, 0, sizeof(req));
+
+ nlh = &req.n;
+ nlh->nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
+ nlh->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
+ nlh->nlmsg_type = GENL_ID_CTRL;
+
+ ghdr = NLMSG_DATA(&req.n);
+ ghdr->cmd = CTRL_CMD_GETFAMILY;
+
+ if (rtnl_open_byproto(&rth, 0, NETLINK_GENERIC) < 0) {
+ fprintf(stderr, "Cannot open generic netlink socket\n");
+ exit(1);
+ }
+
+ addattr_l(nlh, 128, CTRL_ATTR_FAMILY_NAME, family, strlen(family) + 1);
+
+ if (rtnl_talk(&rth, nlh, 0, 0, nlh, NULL, NULL) < 0) {
+ fprintf(stderr, "Error talking to the kernel\n");
+ goto errout;
+ }
+
+ {
+ struct rtattr *tb[CTRL_ATTR_MAX + 1];
+ struct genlmsghdr *ghdr = NLMSG_DATA(nlh);
+ int len = nlh->nlmsg_len;
+ struct rtattr *attrs;
+
+ if (nlh->nlmsg_type != GENL_ID_CTRL) {
+ fprintf(stderr, "Not a controller message, nlmsg_len=%d "
+ "nlmsg_type=0x%x\n", nlh->nlmsg_len, nlh->nlmsg_type);
+ goto errout;
+ }
+
+ if (ghdr->cmd != CTRL_CMD_NEWFAMILY) {
+ fprintf(stderr, "Unkown controller command %d\n", ghdr->cmd);
+ goto errout;
+ }
+
+ len -= NLMSG_LENGTH(GENL_HDRLEN);
+
+ if (len < 0) {
+ fprintf(stderr, "wrong controller message len %d\n", len);
+ return -1;
+ }
+
+ attrs = (struct rtattr *) ((char *) ghdr + GENL_HDRLEN);
+ parse_rtattr(tb, CTRL_ATTR_MAX, attrs, len);
+
+ if (tb[CTRL_ATTR_FAMILY_ID] == NULL) {
+ fprintf(stderr, "Missing family id TLV\n");
+ goto errout;
+ }
+
+ ret = *(__u16 *) RTA_DATA(tb[CTRL_ATTR_FAMILY_ID]);
+ }
+
+errout:
+ rtnl_close(&rth);
+ return ret;
+}
+
+static int print_ctrl(const struct sockaddr_nl *who, struct nlmsghdr *n,
+ void *arg)
+{
+ struct rtattr *tb[CTRL_ATTR_MAX + 1];
+ struct genlmsghdr *ghdr = NLMSG_DATA(n);
+ int len = n->nlmsg_len;
+ struct rtattr *attrs;
+ FILE *fp = (FILE *) arg;
+
+ if (n->nlmsg_type != GENL_ID_CTRL) {
+ fprintf(stderr, "Not a controller message, nlmsg_len=%d "
+ "nlmsg_type=0x%x\n", n->nlmsg_len, n->nlmsg_type);
+ return 0;
+ }
+
+ if (ghdr->cmd != CTRL_CMD_GETFAMILY &&
+ ghdr->cmd != CTRL_CMD_DELFAMILY &&
+ ghdr->cmd != CTRL_CMD_NEWFAMILY) {
+ fprintf(stderr, "Unkown controller command %d\n", ghdr->cmd);
+ return 0;
+ }
+
+ len -= NLMSG_LENGTH(GENL_HDRLEN);
+
+ if (len < 0) {
+ fprintf(stderr, "wrong controller message len %d\n", len);
+ return -1;
+ }
+
+ attrs = (struct rtattr *) ((char *) ghdr + GENL_HDRLEN);
+ parse_rtattr(tb, CTRL_ATTR_MAX, attrs, len);
+
+ if (tb[CTRL_ATTR_FAMILY_NAME]) {
+ char *name = RTA_DATA(tb[CTRL_ATTR_FAMILY_NAME]);
+ fprintf(fp, "Name: %s\n",name);
+ }
+ if (tb[CTRL_ATTR_FAMILY_ID]) {
+ __u16 *id = RTA_DATA(tb[CTRL_ATTR_FAMILY_ID]);
+ fprintf(fp, "ID: 0x%x\n",*id);
+ }
+
+ fflush(fp);
+ return 0;
+}
+
+static int ctrl_list(int cmd, int argc, char **argv)
+{
+ struct rtnl_handle rth;
+ struct nlmsghdr *nlh;
+ struct genlmsghdr *ghdr;
+ int ret = -1;
+ char d[GENL_NAMSIZ];
+ struct {
+ struct nlmsghdr n;
+ char buf[4096];
+ } req;
+
+ memset(&req, 0, sizeof(req));
+
+ nlh = &req.n;
+ nlh->nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
+ nlh->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
+ nlh->nlmsg_type = GENL_ID_CTRL;
+
+ ghdr = NLMSG_DATA(&req.n);
+ ghdr->cmd = CTRL_CMD_GETFAMILY;
+
+ if (rtnl_open_byproto(&rth, 0, NETLINK_GENERIC) < 0) {
+ fprintf(stderr, "Cannot open generic netlink socket\n");
+ exit(1);
+ }
+
+ if (cmd == CTRL_CMD_GETFAMILY) {
+ if (argc != 2) {
+ fprintf(stderr, "Wrong number of params\n");
+ return -1;
+ }
+
+ if (matches(*argv, "name") == 0) {
+ NEXT_ARG();
+ strncpy(d, *argv, sizeof (d) - 1);
+ addattr_l(nlh, 128, CTRL_ATTR_FAMILY_NAME,
+ d, strlen(d) + 1);
+ } else if (matches(*argv, "id") == 0) {
+ __u16 id;
+ NEXT_ARG();
+ if (get_u16(&id, *argv, 0)) {
+ fprintf(stderr, "Illegal \"id\"\n");
+ goto ctrl_done;
+ }
+
+ addattr_l(nlh, 128, CTRL_ATTR_FAMILY_ID, &id, 2);
+
+ } else {
+ fprintf(stderr, "Wrong params\n");
+ goto ctrl_done;
+ }
+
+ if (rtnl_talk(&rth, nlh, 0, 0, nlh, NULL, NULL) < 0) {
+ fprintf(stderr, "Error talking to the kernel\n");
+ goto ctrl_done;
+ }
+
+ if (print_ctrl(NULL, nlh, (void *) stdout) < 0) {
+ fprintf(stderr, "Dump terminated\n");
+ goto ctrl_done;
+ }
+
+ }
+
+ if (cmd == CTRL_CMD_UNSPEC) {
+ nlh->nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
+ nlh->nlmsg_seq = rth.dump = ++rth.seq;
+
+ if (rtnl_send(&rth, (const char *) nlh, nlh->nlmsg_len) < 0) {
+ perror("Failed to send dump request\n");
+ goto ctrl_done;
+ }
+
+ rtnl_dump_filter(&rth, print_ctrl, stdout, NULL, NULL);
+
+ }
+
+ ret = 0;
+ctrl_done:
+ rtnl_close(&rth);
+ return ret;
+}
+
+static int ctrl_listen(int argc, char **argv)
+{
+ struct rtnl_handle rth;
+
+ if (rtnl_open_byproto(&rth, nl_mgrp(GENL_ID_CTRL), NETLINK_GENERIC) < 0) {
+ fprintf(stderr, "Canot open generic netlink socket\n");
+ return -1;
+ }
+
+ if (rtnl_listen(&rth, print_ctrl, (void *) stdout) < 0)
+ return -1;
+
+ return 0;
+}
+
+static int parse_ctrl(struct genl_util *a, int argc, char **argv)
+{
+ argv++;
+ if (--argc <= 0) {
+ fprintf(stderr, "wrong controller params\n");
+ return -1;
+ }
+
+ if (matches(*argv, "monitor") == 0)
+ return ctrl_listen(argc-1, argv+1);
+ if (matches(*argv, "get") == 0)
+ return ctrl_list(CTRL_CMD_GETFAMILY, argc-1, argv+1);
+ if (matches(*argv, "list") == 0 ||
+ matches(*argv, "show") == 0 ||
+ matches(*argv, "lst") == 0)
+ return ctrl_list(CTRL_CMD_UNSPEC, argc-1, argv+1);
+ if (matches(*argv, "help") == 0)
+ return usage();
+
+ fprintf(stderr, "ctrl command \"%s\" is unknown, try \"ctrl -help\".\n",
+ *argv);
+
+ return -1;
+}
+
+struct genl_util ctrl_genl_util = {
+ .name = "ctrl",
+ .parse_genlopt = parse_ctrl,
+ .print_genlopt = print_ctrl,
+};
diff --git a/genl/genl.c b/genl/genl.c
new file mode 100644
index 0000000..3ae75ae
--- /dev/null
+++ b/genl/genl.c
@@ -0,0 +1,162 @@
+/*
+ * genl.c "genl" utility frontend.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Jamal Hadi Salim
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <dlfcn.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+#include <errno.h>
+#include <linux/netlink.h>
+#include <linux/rtnetlink.h> /* until we put our own header */
+#include "SNAPSHOT.h"
+#include "utils.h"
+#include "genl_utils.h"
+
+int show_stats = 0;
+int show_details = 0;
+int show_raw = 0;
+int resolve_hosts = 0;
+
+static void *BODY;
+static struct genl_util * genl_list;
+
+
+static int print_nofopt(const struct sockaddr_nl *who, struct nlmsghdr *n,
+ void *arg)
+{
+ fprintf((FILE *) arg, "unknown genl type ..\n");
+ return 0;
+}
+
+static int parse_nofopt(struct genl_util *f, int argc, char **argv)
+{
+ if (argc) {
+ fprintf(stderr, "Unknown genl \"%s\", hence option \"%s\" "
+ "is unparsable\n", f->name, *argv);
+ return -1;
+ }
+
+ return 0;
+}
+
+static struct genl_util *get_genl_kind(char *str)
+{
+ void *dlh;
+ char buf[256];
+ struct genl_util *f;
+
+ for (f = genl_list; f; f = f->next)
+ if (strcmp(f->name, str) == 0)
+ return f;
+
+ snprintf(buf, sizeof(buf), "%s.so", str);
+ dlh = dlopen(buf, RTLD_LAZY);
+ if (dlh == NULL) {
+ dlh = BODY;
+ if (dlh == NULL) {
+ dlh = BODY = dlopen(NULL, RTLD_LAZY);
+ if (dlh == NULL)
+ goto noexist;
+ }
+ }
+
+ snprintf(buf, sizeof(buf), "%s_genl_util", str);
+
+ f = dlsym(dlh, buf);
+ if (f == NULL)
+ goto noexist;
+reg:
+ f->next = genl_list;
+ genl_list = f;
+ return f;
+
+noexist:
+ f = malloc(sizeof(*f));
+ if (f) {
+ memset(f, 0, sizeof(*f));
+ strncpy(f->name, str, 15);
+ f->parse_genlopt = parse_nofopt;
+ f->print_genlopt = print_nofopt;
+ goto reg;
+ }
+ return f;
+}
+
+static void usage(void) __attribute__((noreturn));
+
+static void usage(void)
+{
+ fprintf(stderr, "Usage: genl [ OPTIONS ] OBJECT | help }\n"
+ "where OBJECT := { ctrl etc }\n"
+ " OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] }\n");
+ exit(-1);
+}
+
+int main(int argc, char **argv)
+{
+ char *basename;
+
+ basename = strrchr(argv[0], '/');
+ if (basename == NULL)
+ basename = argv[0];
+ else
+ basename++;
+
+ while (argc > 1) {
+ if (argv[1][0] != '-')
+ break;
+ if (matches(argv[1], "-stats") == 0 ||
+ matches(argv[1], "-statistics") == 0) {
+ ++show_stats;
+ } else if (matches(argv[1], "-details") == 0) {
+ ++show_details;
+ } else if (matches(argv[1], "-raw") == 0) {
+ ++show_raw;
+ } else if (matches(argv[1], "-Version") == 0) {
+ printf("genl utility, iproute2-ss%s\n", SNAPSHOT);
+ exit(0);
+ } else if (matches(argv[1], "-help") == 0) {
+ usage();
+ } else {
+ fprintf(stderr, "Option \"%s\" is unknown, try "
+ "\"genl -help\".\n", argv[1]);
+ exit(-1);
+ }
+ argc--; argv++;
+ }
+
+ if (argc > 1) {
+ int ret;
+ struct genl_util *a = NULL;
+ a = get_genl_kind(argv[1]);
+ if (NULL == a) {
+ fprintf(stderr,"bad genl %s\n",argv[1]);
+ }
+
+ ret = a->parse_genlopt(a, argc-1, argv+1);
+ return ret;
+
+ if (matches(argv[1], "help") == 0)
+ usage();
+ fprintf(stderr, "Object \"%s\" is unknown, try \"genl "
+ "-help\".\n", argv[1]);
+ exit(-1);
+ }
+
+ usage();
+}
diff --git a/genl/genl_utils.h b/genl/genl_utils.h
new file mode 100644
index 0000000..2f2314b
--- /dev/null
+++ b/genl/genl_utils.h
@@ -0,0 +1,22 @@
+#ifndef _TC_UTIL_H_
+#define _TC_UTIL_H_ 1
+
+#include "linux/genetlink.h"
+
+struct genl_util
+{
+ struct genl_util *next;
+ char name[16];
+ int (*parse_genlopt)(struct genl_util *fu, int argc, char **argv);
+ int (*print_genlopt)(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg);
+};
+
+extern int genl_ctrl_resolve_family(const char *family);
+
+/* seems to have dissapeared from netlink.h */
+static inline __u32 nl_mgrp(__u32 group)
+{
+ return group ? 1 << group : 0;
+}
+
+#endif
^ permalink raw reply related
* [RESEND] please pull from git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
From: Auke Kok @ 2006-07-02 20:58 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, auke-jan.h.kok, auke, akpm
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
tested and validated extensively over the last period.
I hope that can still be accomodated. In that light, please pull:
git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
Cheers,
Auke
---
Original message:
---
Jeff,
after comments I've made some adjustments. I'll list them below against the
old summary. The changes are available from our git-server:
Please pull from:
git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
These patches are against
netdev-2.6#upstream 612eff0e3715a6faff5ba1b74873b99e036c59fe
(Brian Haley <brian.haley@hp.com> / [PATCH] s2io: netpoll support)
> Summary of patches:
>
> [01]: fix loopback ethtool test
> [02]: rework driver hardware reset locking
> [03]: Make PHY powerup/down a function
> [04]: fix CONFIG_PM blocks
> [05]: small performance tweak by removing double code
> [06]: add smart power down code
> [07]: change printk into DPRINTK
> [08]: recycle skb
> [09]: rework module param code with uninitialized values
> [10]: force register write flushes to circumvent broken platforms
Unmodified. See comments here:
http://marc.theaimsgroup.com/?l=linux-netdev&m=115142459725123&w=2 [1]
> [11]: disable CRC stripping workaround
Removed all references to SECRC (crc stripping) instead of leaving it commented.
> [12]: fix adapter led blinking inconsistency
> [13]: add E1000_BIG_ENDIAN symbol
Dropped this patch entirely
> [14]: M88 PHY workaround
> [15]: check return value of _get_speed_and_duplex
> [16]: disable ERT
> [17]: add ich8lan core functions
> [18]: integrate ich8 support into driver
> [19]: allow user to disable ich8 lock loss workaround
> [20]: add ich8lan device ID's
> [21]: increase version to 7.1.9-k2
[1] I can drop #11 in case someone throws a fit ;) - as everyone I'd really
like to see patches 17->20 queued for 2.6.18 for obvious reasons - this is the
most important section of these patches!
Cheers,
Auke
---
drivers/net/e1000/e1000.h | 10
drivers/net/e1000/e1000_ethtool.c | 143 +--
drivers/net/e1000/e1000_hw.c | 1770 +++++++++++++++++++++++++++++++++++---
drivers/net/e1000/e1000_hw.h | 398 ++++++++
drivers/net/e1000/e1000_main.c | 384 +++++---
drivers/net/e1000/e1000_osdep.h | 13
drivers/net/e1000/e1000_param.c | 213 ++--
7 files changed, 2530 insertions(+), 401 deletions(-)
^ permalink raw reply
* Merci pour la réponce ( votre frère Mr.P.Kamara )
From: PETER KAMARA @ 2006-07-02 21:11 UTC (permalink / raw)
Mr Peter KAMARA
Email: peterkamara23@katamail.com
Tel : 00229 97 17 75 85.
Mon cher,
Je sais que mon message sera d'une grande surprise quand il vous parviendra.
Donc' je vous présente toutes mes excuses. J’ai prie pendant plusieurs jours et
après cela j'ai choisi de vous contacter parmi plusieurs autres personnes. Je
pense que vous étés digne de la recommandation de ma prière. Je vous écris
sincèrement dans le but d'obtenir votre coopération et votre confiance pouvant
me permettre d'effectuer une affaire urgente avec vous. Aussi je profite de
l'occasion pour vous faire nécessite cette affaire et ma position
actuelle. L’idée de vous écrire m'est arrivée d'une nécessite et d'une
frustration qui a pour base des perturbations momentanées issues de ma famille
d'adoption de monsieur et madame KABA williams. Mon père adoptif. Toute sa
famille et lui travaillait dans un monde d'affaire concernant l'or pendant
longtemps : ce qui jusque la n'a pas encore été reconnu comme étant un vaste
domaine riche en or qui a été acquis. Je suis Mr Peter KAMARA originaire de la
sierra Leone et ma famille d’adoption celle de Mr et mme KABA williams
originaire de la Guinée Conakry. Mon ancien père adoptif est un important homme
d’affaire qui Intervient dans le domaine du cacao et beaucoup d’autres matières
dans un autre pays a Abidjan capitale de la cote d'ivoire située en Afrique de
l'Ouest depuis 1983.mon père adoptif a achète un domaine (un hectare) qu’il a
confie pour la plantation du cacao et d’autres cultures en Guinée conakry. il
a acquis un hectare de terre auprès des membres l'ethnie susu a Conakry
capitale de la Guinée et entre temps Quatre ans après que le domaine ai été
prépare pour la culture du cacao et son exploration. il a été découvert par des
expatries français que ledit domaine est très riche en or quand mon ancien père
adoptif l'acheta en 1983.comme ce domaine se retrouvait en zone très recule elle
n'était pas considérée et n'avait même pas été enregistre par l'état sur la
liste des affaires domaniales . Quand la découverte fut faite et que mon père
et les expatries français commencèrent par extraire et exporter l’or sur
d’autres pays a travers le monde entier et que mon père décida de construire
une habitation pour l’installation de toute sa famille sur le domaine a cause
des exigences de son métier et que les villageois et autres découvrirent la
richesse en mines d'or du terrain. Ils devinrent très jaloux de lui et
commencèrent par le menacer et lui créer des problèmes de tout genre comme
quoi le terrain ne lui avait pas été réellement vendu et ils commencèrent par
le lui disputer. Devant la justice, mon père remporta le procès car il avait
tous les documents devant prouver son titre de propriétaire légal. Après la
décision de la cour en faveur de mon ancien père adoptif, les villageois aides
par d'importantes personnalités du gouvernement interjetèrent appel près la
haute cour d’appel et obtinrent satisfaction car le président est issu de leur
tribu. Voulant taire à jamais cette histoire. Des assassins furent envoies la
nuit du 07 avril 2000 dans l'habitation de ma famille adoptive tuer tout le
monde jusqu’aux enfants. Mais mon père adoptif n’avait pas succombe sur le
champ à l’époque j’étais à l’internat (école). Il avait été emmené aux soins
par des hommes de sécurité qui ont accouru parce qu'ayant entendu des coups de
feu et ont alerté la police. A l'hôpital avant de s’éteindre, MR KABA Williams
m'a fait venir de l’internat et m'a relaté toute l'histoire. Par ailleurs il
m'a soufflé très bas où se trouvaient les clés de la souterraine ou il cachait
toute sa fortune, où se trouvaient tous ses documents importants et autres .et
où sont cachés les documents des marchandises qu’il a confié a une société de
gardiennage a Cotonou en République du Bénin et il m'a ajouté que la marchandise
déposée contient 65.000.000 $ qu’il a couvert avec des pièces informatiques. Il
a déclaré près de la société de gardiennage que les marchandises confiées
étaient un ensemble de biens personnels (pièces informatiques) depuis que le
gouvernement guinéen a bloqué son compte et tous ses biens qui se trouvent en
Guinée.
Après la mort de mon feu père. J’ai du quitter la Guinée Conakry sous l’emprise
de la peur pour venir habiter dans un autre pays (République du Bénin) où se
trouvent les marchandises les fonds et profiter de l'occasion pour voir
comment faire le retrait des trois males de marchandises, après les
renseignements auprès de la société de gardiennage. C’est la semaine dernière
que la société de gardiennage a accepté faire la mutation au nom de celui qui
ferra le retrait de la marchandise.
Je viens ainsi solliciter votre aide pour le retrait de la marchandise qui
Contient les fonds ci haut indiques ici a Cotonou en République du Bénin. Je
désire aussi déplacer l'argent de ce pays pour le votre et l'investir soit dans
votre compagnie ou dans toute autre activité lucrative que vous me proposerez
mais rappelez vous que mon feu père adoptif m'a dit que la société de
gardiennage n'est pas au courant du fait que la marchandise a pour contenu de
l'argent. Tout ce qu’elle sait c’est que le contenu a rapport a des pièces
informatiques et c'est d'ailleurs pour cela que je recherche un partenaire
étranger ou une association étrangère qui pourra m'aider dans l'investissement
de fonds car je ne maîtrise pas ce domaine, et bien avant cela mon feu père
adoptif m’a défendu d'informer quelque membre de sa famille et quelque ami que
ce soit car ils doivent avoir participé de leur manière a cet événement
douloureux. Je m’engage a vous donner 50% des fonds se trouvant dans la
marchandise comme récompense pour vos interventions et le reste je le garde
pour moi pour mes propres investissements chez vous. Après avoir reçu votre
réponse. Je vous donnerai l'adresse de la société de gardiennage et aussitôt
que vous vous serrez engagé pour m’aider à récupérer tous les biens. Je vous
fournirai le numéro de téléphone et le fax de la société avec les certificats
de dépôt des trois males qui contiennent les fonds puis l'adresse de la
société de gardiennage ou se trouvent les marchandises pour raison de sécurité
et le certificat de décès de mon feu père adoptif MR KABA Williams ,cela vous
permettra de rentrer en contact avec la société de gardiennage et d'obtenir
tous les renseignements nécessaires aussi demander les formalités a remplir
et la procédure à suivre pour la mutation en votre nom et pour le retrait des
marchandises.
N’oubliez pas de me répondre sous mon email adresse privé :
peterkamara27@katamail.com et vous pouvez me joindre sur mon numéro mobile a
tout moment pour avoir plus d’information. Tel : 00229 97 17 75 85.
J’attends votre réponse au plus vite possible.
Que Dieu vous bénisse.
Votre frère.
MR PETER KAMARA
Email: peterkamara23@katamail.com
Tel : 00229 97 17 75 85.
^ permalink raw reply
* [PATCH] xfrm6: move define/ifdef check order
From: Randy.Dunlap @ 2006-07-02 21:36 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <rdunlap@xenotime.net>
The first check for #ifdef XFRM6_TUNNEL_SPI_MAGIC needs to come after
the optional #define of it, otherwise the variable won't be there
for the rest of the code to use.
Shouldn't that CONFIG_IPV6_XFRM6_TUNNEL_DEBUG be part of Kconfig
or have its name changed?
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
net/ipv6/xfrm6_tunnel.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2617-g20.orig/net/ipv6/xfrm6_tunnel.c
+++ linux-2617-g20/net/ipv6/xfrm6_tunnel.c
@@ -52,6 +52,10 @@
# define X6TPRINTK3 X6TNOPRINTK
#endif
+#ifdef CONFIG_IPV6_XFRM6_TUNNEL_DEBUG
+# define XFRM6_TUNNEL_SPI_MAGIC 0xdeadbeef
+#endif
+
/*
* xfrm_tunnel_spi things are for allocating unique id ("spi")
* per xfrm_address_t.
@@ -67,10 +71,6 @@ struct xfrm6_tunnel_spi {
#endif
};
-#ifdef CONFIG_IPV6_XFRM6_TUNNEL_DEBUG
-# define XFRM6_TUNNEL_SPI_MAGIC 0xdeadbeef
-#endif
-
static DEFINE_RWLOCK(xfrm6_tunnel_spi_lock);
static u32 xfrm6_tunnel_spi;
---
^ permalink raw reply
* [PATCH] net: add+use poison defines
From: Randy.Dunlap @ 2006-07-02 23:40 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm
From: Randy Dunlap <rdunlap@xenotime.net>
Add and use poison defines in net/.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
include/linux/poison.h | 4 ++++
net/atm/clip.c | 3 ++-
net/ipv6/netfilter/ip6_tables.c | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
--- linux-2617-g20.orig/include/linux/poison.h
+++ linux-2617-g20/include/linux/poison.h
@@ -45,6 +45,10 @@
/********** drivers/atm/ **********/
#define ATM_POISON_FREE 0x12
+/********** net/ **********/
+#define NEIGHBOR_DEAD 0xdeadbeef
+#define NETFILTER_LINK_POISON 0xdead57ac
+
/********** kernel/mutexes **********/
#define MUTEX_DEBUG_INIT 0x11
#define MUTEX_DEBUG_FREE 0x22
--- linux-2617-g20.orig/net/atm/clip.c
+++ linux-2617-g20/net/atm/clip.c
@@ -23,6 +23,7 @@
#include <linux/if.h> /* for IFF_UP */
#include <linux/inetdevice.h>
#include <linux/bitops.h>
+#include <linux/poison.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <linux/rcupdate.h>
@@ -266,7 +267,7 @@ static void clip_neigh_destroy(struct ne
DPRINTK("clip_neigh_destroy (neigh %p)\n", neigh);
if (NEIGH2ENTRY(neigh)->vccs)
printk(KERN_CRIT "clip_neigh_destroy: vccs != NULL !!!\n");
- NEIGH2ENTRY(neigh)->vccs = (void *) 0xdeadbeef;
+ NEIGH2ENTRY(neigh)->vccs = (void *) NEIGHBOR_DEAD;
}
static void clip_neigh_solicit(struct neighbour *neigh, struct sk_buff *skb)
--- linux-2617-g20.orig/net/ipv6/netfilter/ip6_tables.c
+++ linux-2617-g20/net/ipv6/netfilter/ip6_tables.c
@@ -25,6 +25,7 @@
#include <linux/vmalloc.h>
#include <linux/netdevice.h>
#include <linux/module.h>
+#include <linux/poison.h>
#include <linux/icmpv6.h>
#include <net/ipv6.h>
#include <asm/uaccess.h>
@@ -376,7 +377,7 @@ ip6t_do_table(struct sk_buff **pskb,
} while (!hotdrop);
#ifdef CONFIG_NETFILTER_DEBUG
- ((struct ip6t_entry *)table_base)->comefrom = 0xdead57ac;
+ ((struct ip6t_entry *)table_base)->comefrom = NETFILTER_LINK_POISON;
#endif
read_unlock_bh(&table->lock);
---
^ permalink raw reply
* Make other men envy you and girls worship you Most efficient products for men
From: Gino @ 2006-07-02 23:37 UTC (permalink / raw)
To: netdev
Yo!
Masculine performance has never been so easy to increase with these products
Most quality products for anyone who wants to become a champion in bed
http://www.syllabhd.com
A celebrity is someone who works hard all his life to become known and then wears dark glasses to avoid being recognized. Faith will move mountains
Gluttony kills more than the sword
^ permalink raw reply
* Imagine how your life will improve if you stopped being reproached for premature creaming once and for all.
From: Eddie @ 2006-07-03 0:50 UTC (permalink / raw)
To: newbie-owner
Halo!
Lots of men deal with this daily not knowing there's a comprehensive solution to the problem. It's obvious that a satisfied woman will be addicted to you like never before.
http://www.kyklopescf.com
Needs must when the devil drives Eat well, stay fit, die anyway. A friend in need is a friend indeed. There's no fool like an old fool. He will not regard any ransom; neither will he rest content, though thou givest many gifts.
^ permalink raw reply
* [PATCH 2/2] ATM: add+use poison defines
From: Randy.Dunlap @ 2006-07-03 1:21 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm, chas
From: Randy Dunlap <rdunlap@xenotime.net>
ATM: add and use POISON define values.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/atm/ambassador.c | 3 ++-
drivers/atm/idt77252.c | 3 ++-
include/linux/poison.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
--- linux-2617-g20.orig/drivers/atm/ambassador.c
+++ linux-2617-g20/drivers/atm/ambassador.c
@@ -31,6 +31,7 @@
#include <linux/atmdev.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
+#include <linux/poison.h>
#include <asm/atomic.h>
#include <asm/io.h>
@@ -1995,7 +1996,7 @@ static int __devinit ucode_init (loader_
}
i += 1;
}
- if (*pointer == 0xdeadbeef) {
+ if (*pointer == ATM_POISON) {
return loader_start (lb, dev, ucode_start);
} else {
// cast needed as there is no %? for pointer differnces
--- linux-2617-g20.orig/drivers/atm/idt77252.c
+++ linux-2617-g20/drivers/atm/idt77252.c
@@ -35,6 +35,7 @@ static char const rcsid[] =
#include <linux/module.h>
#include <linux/pci.h>
+#include <linux/poison.h>
#include <linux/skbuff.h>
#include <linux/kernel.h>
#include <linux/vmalloc.h>
@@ -3657,7 +3658,7 @@ probe_sram(struct idt77252_dev *card)
writel(SAR_CMD_WRITE_SRAM | (0 << 2), SAR_REG_CMD);
for (addr = 0x4000; addr < 0x80000; addr += 0x4000) {
- writel(0xdeadbeef, SAR_REG_DR0);
+ writel(ATM_POISON, SAR_REG_DR0);
writel(SAR_CMD_WRITE_SRAM | (addr << 2), SAR_REG_CMD);
writel(SAR_CMD_READ_SRAM | (0 << 2), SAR_REG_CMD);
--- linux-2617-g20.orig/include/linux/poison.h
+++ linux-2617-g20/include/linux/poison.h
@@ -44,6 +44,7 @@
/********** drivers/atm/ **********/
#define ATM_POISON_FREE 0x12
+#define ATM_POISON 0xdeadbeef
/********** net/ **********/
#define NEIGHBOR_DEAD 0xdeadbeef
^ permalink raw reply
* Job alerts in icq,odigo,skype or msn
From: Sigrid Thomae @ 2006-07-03 1:09 UTC (permalink / raw)
To: netdev
One of your friends used our send-to-a-friend-option: Check this out:
register for job alert, as well as i did - http://job-alert.net
^ permalink raw reply
* Re: IPVS Sysctl Variables
From: Horms @ 2006-07-03 1:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, wensong, ja
In-Reply-To: <20060630.142045.106433722.davem@davemloft.net>
On Fri, Jun 30, 2006 at 02:20:45PM -0700, David Miller wrote:
> From: Horms <horms@verge.net.au>
> Date: Fri, 30 Jun 2006 15:19:41 +0900
>
> > there are quite a number of entries under /proc/sys/net/ipv4/vs,
> > I swear that they were documented in Documentation/networking/
> > at some stage, but perhaps I am dreaming.
> >
> > In any case, if I clean up the information at the following URL (which a
> > probably complete list of what the options are and what they do, you don't
> > have to check if you don't want to), is it appropriate for inclusion in
> > Documentation/networking/, and if so, should it be in ip-sysctl.txt, or
> > elsewhere?
> >
> > http://www.linuxvirtualserver.org/docs/sysctl.html
>
> Good question, maybe ip-sysctl.txt is getting a bit crowded.
> I therefore wouldn't mind you putting this into networking/ipvs-sysctl.txt
Thanks, I will make that so.
--
Horms
H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/
^ permalink raw reply
* Re: netif_stop_queue() and multiple hardware queues
From: Jeremy Jackson @ 2006-07-03 2:36 UTC (permalink / raw)
To: Jeremy Jackson; +Cc: netdev
In-Reply-To: <43A09D18.9040401@coplanar.net>
I'd like to raise the question again. How can the network stack's flow
control function with hardware that has multiple physical queues? How
can these queues be exposed to tc?
After scanning the netdev mailing list activity for the last 6 months, I
can see no furthur discussion since my original post. I did notice some
churn in several 802.11 layer stacks trying to deal with multiple
hardware queues, the IPW2200 in particular.
I propose that this is an architecture/framework/API issue that the
Linux core networking code should be dealing with.
There is some fragmentation already; compare the QoS *policy*
implemented by Madwifi vs IPW2200 vs devicescape's 80211 stack. It's
worth noting that at the 80211 layer, the first 2 listed above have a
"priority" argument to (80211)_hard_start_xmit().
It would seem ideal to expose the queues of Ethernet layer hardware
(provide mechanism) and let userspace tc tools do the classifying
(sysadmin can set the policy).
Jeremy
Jeremy Jackson wrote:
> Hi,
>
> I posted this briefly on linux-net, before being redirected here.
>
> Two pieces of hardware now have Linux driver support for multiple
> hardware queues: Intel's e1000 (two queues from what I can see in the
> code) and Atheros's 5212 and up, in support of 802.11e and WME (four
> hardware queues). In the GigE case, this just reduces latency due to
> hardware queueing. In the WiFi case, the queues actually have
> significance in access to the shared medium. (ACKs can be disabled as
> well) It is also worthy of note that ADSL2, VDSL, and ADSL2+ have 4
> different latency "queues". These last two are significant; real-time
> applications suffer the most from low speed, shared, and/or
> non-deterministic media. I wonder where DOCSIS 2 is in this regard.
> Anyone? Beuler?
>
> So my question is, what's it going to take to get dev->hard_start_xmit()
> to hook up tc queues directly to hardware/driver queues?
>
> Right now, it seems no matter how elaborate a tc setup you have,
> everything funnels through one queue, where the only thing that survives
> from the classifying/queueing is skb-> priority (ie nothing). The
> hardware driver can then try to reclassify packets. I suppose you
> could hack up an iptables classifyer to set skb->priority...
>
> The Atheros driver tries to do it's own classifying by first wiping
> out skb->priority, then hard-coding a mapping (tsk - policy is for the
> sysadmin!) between VLAN tag priority, IP TOS/DSCP, and skb->priority,
> then to one of the 4 queues and ACK states, blithely ignoring any fine
> work done by tc.
>
> It's be sweet to head this nonsense off at the pass, before others
> discover the rabbit trail and make it into a trade route.
>
^ permalink raw reply
* Re: netif_stop_queue() and multiple hardware queues
From: David Miller @ 2006-07-03 4:52 UTC (permalink / raw)
To: jerj; +Cc: netdev
In-Reply-To: <44A88293.7060000@coplanar.net>
From: Jeremy Jackson <jerj@coplanar.net>
Date: Sun, 02 Jul 2006 22:36:03 -0400
> I propose that this is an architecture/framework/API issue that the
> Linux core networking code should be dealing with.
Proposals are worthless if nobody wants to do the work to actually
implement the proposal.
Your tone seems to suggest that you feel if you propose something,
someone will just jump out of their seat and implement your proposal.
That's not how this works :)
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Paul Jackson @ 2006-07-03 4:53 UTC (permalink / raw)
To: Shailabh Nagar
Cc: akpm, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel,
hadi, netdev
In-Reply-To: <44A5EDE6.3010605@watson.ibm.com>
Shailabh wrote:
> Sends a separate "registration" message with cpumask to listen to.
> Kernel stores (real) pid and cpumask.
Question:
=========
Ah - good.
So this means that I could configure a system with a fork/exit
intensive, performance critical job on some dedicated CPUs, and be able
to collect taskstat data from tasks exiting on the -other- CPUS, while
avoiding collecting data from this special job, thus avoiding any
taskstat collection performance impact on said job.
If I'm understanding this correctly, excellent.
Caveat:
=======
Passing cpumasks across the kernel-user boundary can be tricky.
Historically, Unix has a long tradition of boloxing up the passing
of variable length data types across the kernel-user boundary.
We've got perhaps a half dozen ways of getting these masks out of the
kernel, and three ways of getting them (or the similar nodemasks) back
into the kernel. The three ways being used in the sched_setaffinity
system call, the mbind and set_mempolicy system calls, and the cpuset
file system.
All three of these ways have their controversial details:
* The kernel cpumask mask size needed for sched_setaffinity calls is
not trivially available to userland.
* The nodemask bit size is off by one in the mbind and set_mempolicy
calls.
* The CPU and Node masks are ascii, not binary, in the cpuset calls.
One option that might make sense for these task stat registrations
would be to:
1) make the kernel/sched.c get_user_cpu_mask() routine generic,
moving it to non-static lib/*.c code, and
2) provide a sensible way for user space to query the size of
the kernel cpumask (and perhaps nodemask while you're at it.)
Currently, the best way I know for user space to query the kernels
cpumask and nodemask size is to examine the length of the ascii
string values labeled "Cpus_allowed:" and "Mems_allowed:" in the file
/proc/self/status. These ascii strings always require exactly nine
ascii chars to express each 32 bits of kernel mask code, if you include
in the count the trailing ',' comma or '\n' newline after each eight
ascii character word.
Probing /proc/self/status fields for these mask sizes is rather
unobvious and indirect, and requires caching the result if you care at
all about performance. Userland code in support of your taskstat
facility might be better served by a more obvious way to size cpumasks.
... unless of course you're inclined to pass cpumasks formatted as
ascii strings, in which case speak up, as I'd be delighted to
throw in my 2 cents on how to do that ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ 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