* [PATCH 06/10] sysctl: Remove broken sunrpc debug binary sysctls
From: Eric W. Biederman @ 2007-08-10 1:04 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Alexey Dobriyan, netdev, David Miller,
trond.myklebust
In-Reply-To: <m1vebo8avf.fsf_-_@ebiederm.dsl.xmission.com>
This is debug code so no need to support binary sysctl,
and the binary sysctls as they were written were not
consistent with what showed up in /proc so remove
the binary sysctl support.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/sunrpc/sysctl.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/sysctl.c b/net/sunrpc/sysctl.c
index 738db32..864b541 100644
--- a/net/sunrpc/sysctl.c
+++ b/net/sunrpc/sysctl.c
@@ -114,7 +114,6 @@ done:
static ctl_table debug_table[] = {
{
- .ctl_name = CTL_RPCDEBUG,
.procname = "rpc_debug",
.data = &rpc_debug,
.maxlen = sizeof(int),
@@ -122,7 +121,6 @@ static ctl_table debug_table[] = {
.proc_handler = &proc_dodebug
},
{
- .ctl_name = CTL_NFSDEBUG,
.procname = "nfs_debug",
.data = &nfs_debug,
.maxlen = sizeof(int),
@@ -130,7 +128,6 @@ static ctl_table debug_table[] = {
.proc_handler = &proc_dodebug
},
{
- .ctl_name = CTL_NFSDDEBUG,
.procname = "nfsd_debug",
.data = &nfsd_debug,
.maxlen = sizeof(int),
@@ -138,7 +135,6 @@ static ctl_table debug_table[] = {
.proc_handler = &proc_dodebug
},
{
- .ctl_name = CTL_NLMDEBUG,
.procname = "nlm_debug",
.data = &nlm_debug,
.maxlen = sizeof(int),
--
1.5.1.1.181.g2de0
^ permalink raw reply related
* Re: [PATCH 1/1] NFS: change the ip_map cache code to handle IPv6 addresses
From: Neil Brown @ 2007-08-10 1:06 UTC (permalink / raw)
To: Aurélien Charbon; +Cc: netdev ML, Mailing list NFSv4
In-Reply-To: <46BAC0B9.1020207@ext.bull.net>
On Thursday August 9, aurelien.charbon@ext.bull.net wrote:
> Here is a small part of missing pieces of IPv6 support for the server.
> It deals with the ip_map caching code part.
>
> It changes the ip_map structure to be able to store INET6 addresses.
> It adds also the changes in address hashing, and mapping to test it with
> INET addresses.
Thanks - this generally seems to make sense. A few specific comments:
> @@ -1558,6 +1558,7 @@
Please use "diff -p" to include the C function name. It makes the
patch easier to read.
> + for (i = 0; i < ncp->cl_naddr; i++) {
> + /* Mapping address */
> + addr6.s6_addr32[0] = 0;
> + addr6.s6_addr32[1] = 0;
> + addr6.s6_addr32[2] = htonl(0xffff);
> + addr6.s6_addr32[3] = (uint32_t)ncp->cl_addrlist[i].s_addr;
> + auth_unix_add_addr(addr6, dom);
> + }
You do this conversion several times, and each time it is indented
strangely... Maybe create an inline (if there isn't one already) to
do this.
> extern void auth_domain_put(struct auth_domain *item);
> -extern int auth_unix_add_addr(struct in_addr addr, struct auth_domain
> *dom);
> +extern int auth_unix_add_addr(struct in6_addr addr, struct auth_domain
> *dom);
Your mailer is wrapping long lines. This is bad.
> static int ip_map_match(struct cache_head *corig, struct cache_head *cnew)
> {
> struct ip_map *orig = container_of(corig, struct ip_map, h);
> struct ip_map *new = container_of(cnew, struct ip_map, h);
> return strcmp(orig->m_class, new->m_class) == 0
> - && orig->m_addr.s_addr == new->m_addr.s_addr;
> + && memcmp(orig->m_addr.s6_addr,
> new->m_addr.s6_addr,sizeof(struct in6_addr));
> }
I think you have inverted the sense of the test. The original tests
for equality. The new tests for inequality. For memcmp (and strcmp),
always use "function(arg1, argc) COMPARE_OP 0"
e.g.
memcmp(orig, new, size) == 0
or use ipv6_addr_equal.
Also please run ./scripts/checkpatch.pl on the patch. You need a
space after that comma.
> @@ -125,7 +129,7 @@
> struct ip_map *item = container_of(citem, struct ip_map, h);
>
> strcpy(new->m_class, item->m_class);
> - new->m_addr.s_addr = item->m_addr.s_addr;
> + memcpy(&new->m_addr.s6_addr,
> &item->m_addr.s6_addr,sizeof(item->m_addr.s6_addr));
Ditto..... did you test this code?
> }
> static void update(struct cache_head *cnew, struct cache_head *citem)
> {
> @@ -151,20 +155,28 @@
> {
> char text_addr[20];
> struct ip_map *im = container_of(h, struct ip_map, h);
> - __be32 addr = im->m_addr.s_addr;
> +
> + __be32 addr[4];
> + int i;
> + for (i=0;i<4;i++)
> + addr[i] = im->m_addr.s6_addr[i];
^^^^
I think you mean "s6_addr32" ??
>
> - snprintf(text_addr, 20, "%u.%u.%u.%u",
> - ntohl(addr) >> 24 & 0xff,
> - ntohl(addr) >> 16 & 0xff,
> - ntohl(addr) >> 8 & 0xff,
> - ntohl(addr) >> 0 & 0xff);
> + snprintf(text_addr, 20, "%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x",
> + ntohl(addr[3]) >> 16 & 0xff,
^^^^
should be 0xffff ???
Now I know you didn't test the code :-)
> + ntohl(addr[3]) >> 0 & 0xff,
> + ntohl(addr[2]) >> 16 & 0xff,
> + ntohl(addr[2]) >> 0 & 0xff,
> + ntohl(addr[1]) >> 16 & 0xff,
> + ntohl(addr[1]) >> 0 & 0xff,
> + ntohl(addr[0]) >> 16 & 0xff,
> + ntohl(addr[0]) >> 0 & 0xff);
This code would read better if you did
__be16 addr[8];
for (i = 0; i < 8 ; i++)
addr[i] = im->m_addr.s6_addr16[i];
snprintf(........
ntohs(addr[7]),
ntohs(addr[6]),
....
Also, I think that if it is a (converted) IPv4 address, it should be
printed as a dotted-quad.
> + addr.s6_addr32[0] = htonl((b1<<16)|b2);
> + addr.s6_addr32[1] = htonl((b3<<16)|b4);
> + addr.s6_addr32[2] = htonl((b5<<16)|b6);
> + addr.s6_addr32[3] = htonl((b7<<16)|b8);
Assign to addr.s6_addr16[].
> - seq_printf(m, "%s %d.%d.%d.%d %s\n",
> + seq_printf(m, "%s %04x.%04x.%04x.%04x.%04x.%04x.%04x.%04x %s\n",
> im->m_class,
> - ntohl(addr.s_addr) >> 24 & 0xff,
> - ntohl(addr.s_addr) >> 16 & 0xff,
> - ntohl(addr.s_addr) >> 8 & 0xff,
> - ntohl(addr.s_addr) >> 0 & 0xff,
> + ntohl(addr.s6_addr32[3]) >> 16 & 0xffff,
> + ntohl(addr.s6_addr32[3]) & 0xffff,
> + ntohl(addr.s6_addr32[2]) >> 16 & 0xffff,
> + ntohl(addr.s6_addr32[2]) & 0xffff,
> + ntohl(addr.s6_addr32[1]) >> 16 & 0xffff,
> + ntohl(addr.s6_addr32[1]) & 0xffff,
> + ntohl(addr.s6_addr32[0]) >> 16 & 0xffff,
> + ntohl(addr.s6_addr32[0]) & 0xffff,
Again, s6_addr16[], and keep the dotted-quad for IPv4.
In fact ( borrowing Chuck's suggestion)
if (is_ipv4)
seq_printf(m, "%s "NIPQUAD_FMT" %s\n", im->m_class,
NIPQUAD((addr.s6_addr32[0])), ....);
else
seq_printf(m, "%s "NIP6_FMT" %s\n", im->m_class,
NIP6(addr), ...);
Thanks,
NeilBrown
^ permalink raw reply
* Potential u32 classifier bug.
From: Waskiewicz Jr, Peter P @ 2007-08-10 1:07 UTC (permalink / raw)
To: netdev
I've recently been trying to use tc with u32 classifiers to filter
ethernet traffic based on ethertype. Although we found and fixed an
issue in the sch_prio call to tc_classify() (thanks Patrick!), this
didn't fix the actual filtering issue. For those of you who are curious
or are tc-savy, I'm really in a bind and need some help. This is what I
have so far:
Filter to identify and move traffic to a different flow:
# tc qdisc add dev eth2 root handle 1: rr bands 8 priomap 7 7 6 6 5 5 4
4 3 3 2 2 1 1 0 0 multiqueue
# tc filter add dev eth2 parent 1: protocol 802_3 prio 1 u32 match u32
0x00000800 0x0000ffff at 12 flowid 1:6
Now this hits tc_classify(), and tp->protocol and skb->protocol match
(be16 of 8 - ETH_P_802_3, which is what I expect), so u32_classify() is
called through the tp->classify() func pointer. This is where things
get weird.
In net/sched/cls_u32.c, u32_classify() grabs a reference to part of the
network header. This is question number one: how can the filter look at
the ethernet (mac) header if it's grabbing a reference to the network
header:
u8 *ptr = skb_network_header(skb);
I would think that for a protocol of 802.3, one would want:
u8 *ptr = skb_mac_header(skb);
Changing this though doesn't fix the filter. Further down is a rather
horrible match criteria to make sure the filter is looking at the right
data before it applies the whole filter list on the skb:
if
((*(u32*)(ptr+key->off+(off2&key->offmask))^key->val)&key->mask) {
Now if this matches (meaning it evaluates to zero), we can move on. If
not, we go to the next key node and try again. Run out of key nodes, we
return -1 and take the default mapping from IP TOS to Linux priority,
and get queued to a band.
My big question is: Has anyone recently used the 802_3 protocol in tc
with u32 and actually gotten it to work? I can't see how the
u32_classify() code can look at the mac header, since it is using the
network header accessor to start looking. I think this is an issue with
the classification code, but I'm looking to see if I'm doing something
stupid before I really start digging into this mess.
Thanks in advance,
PJ Waskiewicz
Intel Corporation
peter.p.waskiewicz.jr@intel.com <mailto:peter.p.waskiewicz.jr@intel.com>
^ permalink raw reply
* Re: [PATCH 1/1] NFS: change the ip_map cache code to handle IPv6 addresses
From: Neil Brown @ 2007-08-10 1:11 UTC (permalink / raw)
To: chuck.lever; +Cc: Aurélien Charbon, Mailing list NFSv4, netdev ML
In-Reply-To: <46BB2F65.4080602@oracle.com>
On Thursday August 9, chuck.lever@oracle.com wrote:
> >>
> >> How have you tested the effectiveness of the new hash function?
> >
> > I have not tested that point but I can easily imagine there are better
> > solutions.
> > Perhaps we can keep the same function for an IPv4 address (only taking
> > the 32 bits of IPv4 addr), and then design one for IPv6 addresses.
>
> I see that, to generate the hash, you would be xor-ing the FF and 00
> bytes in the canonicalized IPv4 address. Yes, perhaps a better function
> is needed, or as you say, one specifically for IPv6 and one for
> canonicalized IPv4.
>
I suspect that the given hash function will be as good as any other.
The values in each byte of an IPv6 are likely to be either evenly
distributed, or constant.
Each the first case you don't need a clever hash function to
distribute them, while in the second, no hash function can improve the
distribution.
NeilBrown
^ permalink raw reply
* Re: net-2.6.24 GIT state
From: David Miller @ 2007-08-10 1:27 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0708091721030.24369@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 9 Aug 2007 17:40:07 +0300 (EEST)
> Next step:
>
> http://www.cs.helsinki.fi/u/ijjarvin/tcp-rebase/after-reorder/
>
> ...I put some effort to reorganization and there's the result, please
> _don't_ take the new SACK block-validator yet as I haven't yet put it
> under any testing (it's the only difference this reordering of patches
> seems to have introduced :-)). The first five commits touch left_out (4
> latest fix bug and "flaws" I made in the first commit), I could combine
> them into a single one if you want to.
I applied everything up until the SACK validator to net-2.6.24
Thanks for doing all of this merging work, I very much appreciate
it.
> ...Notice that part of the next step includes work that hasn't yet been
> posted to netdev at all (was from my not yet submitted wip portion of
> it). Would you prefer me to post them using the usual procedure?
Everything I hit today which had not been posted before was trivial
fix or a reasonable small cleanup.
Why don't you just post the patches to the list one-by-one from
now on so we can review them in parallel with merging into
net-2.6.24?
Thanks again Ilpo!
^ permalink raw reply
* Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
From: Paul E. McKenney @ 2007-08-10 1:28 UTC (permalink / raw)
To: Chris Snook
Cc: linux-kernel, linux-arch, torvalds, netdev, akpm, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46BB69F8.5000502@redhat.com>
On Thu, Aug 09, 2007 at 03:24:40PM -0400, Chris Snook wrote:
> Paul E. McKenney wrote:
> >On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
> >>Paul E. McKenney wrote:
> >>>On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
> >>>> If you're depending on volatile writes
> >>>>being visible to other CPUs, you're screwed either way, because the CPU
> >>>>can hold that data in cache as long as it wants before it writes it to
> >>>>memory. When this finally does happen, it will happen atomically,
> >>>>which is all that atomic_set guarantees. If you need to guarantee that
> >>>>the value is written to memory at a particular time in your execution
> >>>>sequence, you either have to read it from memory to force the compiler
> >>>>to store it first (and a volatile cast in atomic_read will suffice for
> >>>>this) or you have to use LOCK_PREFIX instructions which will invalidate
> >>>>remote cache lines containing the same variable. This patch doesn't
> >>>>change either of these cases.
> >>>The case that it -can- change is interactions with interrupt handlers.
> >>>And NMI/SMI handlers, for that matter.
> >>You have a point here, but only if you can guarantee that the interrupt
> >>handler is running on a processor sharing the cache that has the
> >>not-yet-written volatile value. That implies a strictly non-SMP
> >>architecture. At the moment, none of those have volatile in their
> >>declaration of atomic_t, so this patch can't break any of them.
> >
> >This can also happen when using per-CPU variables. And there are a
> >number of per-CPU variables that are either atomic themselves or are
> >structures containing atomic fields.
>
> Accessing per-CPU variables in this fashion reliably already requires a
> suitable smp/non-smp read/write memory barrier. I maintain that if we
> break anything with this change, it was really already broken, if less
> obviously. Can you give a real or synthetic example of legitimate code
> that could break?
My main concern is actually the lack of symmetry -- I would expect
that an atomic_set() would have the same properties as atomic_read().
It is easy and cheap to provide them with similar properties, so why not?
Debugging even a single problem would consume far more time than simply
giving them corresponding semantics.
But you asked for examples. These are synthetic, and of course legitimacy
is in the eye of the beholder.
1. Watchdog variable.
atomic_t watchdog = ATOMIC_INIT(0);
...
int i;
while (!done) {
/* Do so stuff that doesn't take more than a few us. */
/* Could do atomic increment, but throughput penalty. */
i++;
atomic_set(&watchdog, i);
}
do_something_with(&watchdog);
/* Every so often on some other CPU... */
if ((new_watchdog = atomic_read(&watchdog)) == old_watchdog)
die_horribly();
old_watchdog = new_watchdog;
If atomic_set() did not have volatile semantics, the compiler
would be within its rights optimizing it to simply get the
final value of "i" after exit from the loop. This would cause
the watchdog check to fail spuriously. Memory barriers are
not required in this case, because the CPU cannot hang onto
the value for very long -- we don't care about the exact value,
or about exact synchronization, but rather about whether or
not the value is changing.
In this (toy) example, one might replace the atomic_set() with
an atomic increment (though that might be too expensive in some
cases) or with something like:
atomic_set(&watchdog, atomic_read(&watchdog) + 1);
However, other cases might not permit this transformation,
for example, an existing heavily used API might take int rather
than atomic_t.
Some will no doubt argue that this example should use a
macro or an asm similar to the "forget()" asm put forward
elsewhere in this thread.
2. Communicating both with interrupt handler and with other CPUs.
For example, data elements that are built up in a location visible
to interrupts and NMIs, and then added as a unit to a data structure
visible to other CPUs. This more-realistic example is abbreviated
to the point of pointlessness as follows:
struct foo {
atomic_t a;
atomic_t b;
};
DEFINE_PER_CPU(struct foo *, staging) = NULL;
/* Create element in staging area. */
__get_cpu_var(staging) = kzalloc(sizeof(*p), GFP_WHATEVER);
if (__get_cpu_var(staging) == NULL)
die_horribly();
/* allocate an element of some per-CPU array, get the result in "i" */
atomic_set(__get_cpu_var(staging).a, i);
/* allocate another element of a per-CPU array, with result in "i" */
atomic_set(__get_cpu_var(staging).b, i);
rcu_assign_pointer(some_global_place, __get_cpu_var(staging));
If atomic_set() didn't have volatile semantics, then an interrupt
or NMI handler could see the atomic_set() to .a and .b out of
order due to compiler optimizations.
Remember, you -did- ask for these!!! ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 1:47 UTC (permalink / raw)
To: ebiederm; +Cc: akpm, linux-kernel, devel, adobriyan, netdev, davem, yoshfuji
In-Reply-To: <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com>
Hello.
In article <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 18:56:09 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
> - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> sysctl names for a function that works with proc.
>
> - In neighbour.c reorder the table to put the possibly unused entries
> at the end so we can remove them by terminating the table early.
>
> - In neighbour.c kill the entries with questionable binary sysctl
> handling behavior.
>
> - In neighbour.c if we don't have a strategy routine remove the
> binary path. So we don't the default sysctl strategy routine
> on data that is not ready for it.
>
I disagree. It is bad to remove existing interface.
Ditto for other patches.
Regards,
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: David Miller @ 2007-08-10 1:49 UTC (permalink / raw)
To: yoshfuji; +Cc: ebiederm, akpm, linux-kernel, devel, adobriyan, netdev
In-Reply-To: <20070810.104710.28739250.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST)
> I disagree. It is bad to remove existing interface.
> Ditto for other patches.
I think perhaps you misunderstand what Eric is doing.
sys_sysctl() isn't working properly for these cases and it is both a
deprecated interface and not worth the pain of adding support
in these cases.
The fact that nobody complains that none of this stuff works
via sys_sysctl() to me proves that it is never used.
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Andrew Morton @ 2007-08-10 1:55 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: ebiederm, linux-kernel, devel, adobriyan, netdev, davem
In-Reply-To: <20070810.104710.28739250.yoshfuji@linux-ipv6.org>
On Fri, 10 Aug 2007 10:47:10 +0900 (JST) YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote:
> Hello.
>
> In article <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 18:56:09 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
> >
> > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> > sysctl names for a function that works with proc.
> >
> > - In neighbour.c reorder the table to put the possibly unused entries
> > at the end so we can remove them by terminating the table early.
> >
> > - In neighbour.c kill the entries with questionable binary sysctl
> > handling behavior.
> >
> > - In neighbour.c if we don't have a strategy routine remove the
> > binary path. So we don't the default sysctl strategy routine
> > on data that is not ready for it.
> >
>
> I disagree. It is bad to remove existing interface.
But it is good to remove bad interfaces, if we possibly can.
It is worth making the attempt. Does anyone know of anything which will
break? I fed NET_NEIGH_ANYCAST_DELAY at random into
http://www.google.com/codesearch and came up with nothing...
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 2:14 UTC (permalink / raw)
To: davem; +Cc: ebiederm, akpm, linux-kernel, devel, adobriyan, netdev, yoshfuji
In-Reply-To: <20070809.184921.11594412.davem@davemloft.net>
In article <20070809.184921.11594412.davem@davemloft.net> (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller <davem@davemloft.net> says:
> From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
> Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST)
>
> > I disagree. It is bad to remove existing interface.
> > Ditto for other patches.
>
> I think perhaps you misunderstand what Eric is doing.
>
> sys_sysctl() isn't working properly for these cases and it is both a
> deprecated interface and not worth the pain of adding support
> in these cases.
Would you explain why it does not work properly
for those cases?
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Eric W. Biederman @ 2007-08-10 2:12 UTC (permalink / raw)
To: Andrew Morton
Cc: YOSHIFUJI Hideaki / 吉藤英明,
linux-kernel, devel, adobriyan, netdev, davem
In-Reply-To: <20070809185521.c3ab1afd.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> But it is good to remove bad interfaces, if we possibly can.
>
> It is worth making the attempt. Does anyone know of anything which will
> break? I fed NET_NEIGH_ANYCAST_DELAY at random into
> http://www.google.com/codesearch and came up with nothing...
My current policy is that since I could only find 5 real world linux
programs that even call sys_sysctl, that if I find a broken sysctl
binary interface I'm lazy and just remove it. The only networking one
I know of is radvd.
Added to that I just pushed an autochecking sysctl patch to Andrew
that fails register_sysctl_table if the sysctl table is broken. And
all of these showed up. So some fix was needed or things would have
been even worse.
Eric
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 2:22 UTC (permalink / raw)
To: ebiederm; +Cc: akpm, linux-kernel, devel, adobriyan, netdev, davem, yoshfuji
In-Reply-To: <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com>
In article <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 18:56:09 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
> - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> sysctl names for a function that works with proc.
:
Well, retrans_time_ms and base_reachable_time_ms supercedes
retrans_time and base_reachable_time, we've warned for long
time for its deprecation. So, maybe, it is time to remove
the old interfaces (retrans_time and base_reachable_time)
and simplify ndisc_ifinfo_syctl_change().
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Eric W. Biederman @ 2007-08-10 2:23 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, ebiederm, akpm, linux-kernel, devel, adobriyan, netdev
In-Reply-To: <20070810.111420.29442251.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
> Would you explain why it does not work properly
> for those cases?
Mostly no appropriate strategy routine was setup to
report the data to the caller of sys_sysctl.
Eric
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 2:29 UTC (permalink / raw)
To: ebiederm; +Cc: davem, akpm, linux-kernel, devel, adobriyan, netdev, yoshfuji
In-Reply-To: <m1odhg6sbv.fsf@ebiederm.dsl.xmission.com>
In article <m1odhg6sbv.fsf@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 20:23:16 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
> YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
>
> > Would you explain why it does not work properly
> > for those cases?
>
> Mostly no appropriate strategy routine was setup to
> report the data to the caller of sys_sysctl.
I assume that default strategy have been existing for it, no?!
Maybe, I do miss something...
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Eric W. Biederman @ 2007-08-10 2:35 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, akpm, linux-kernel, devel, adobriyan, netdev
In-Reply-To: <20070810.112915.63714468.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
> In article <m1odhg6sbv.fsf@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007
> 20:23:16 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
>> YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
>>
>> > Would you explain why it does not work properly
>> > for those cases?
>>
>> Mostly no appropriate strategy routine was setup to
>> report the data to the caller of sys_sysctl.
>
> I assume that default strategy have been existing for it, no?!
> Maybe, I do miss something...
I'd have to go through it case by case. But in general
unless your proc_handler is proc_dointvec the default
strategy routine which does a raw binary copy of your data
out will generally do the wrong thing.
So especially if your data is jiffies or otherwise needs
processing you don't want to use the default strategy
routine.
Until relatively recently no one was really policing the
sysctl interfaces and even now it isn't too serious.
Eric
^ permalink raw reply
* [PATCH 2.6.24]S2io: Default to IntA interrupt type when there are less than 4 CPUs in the system.
From: Sivakumar Subramani @ 2007-08-10 5:04 UTC (permalink / raw)
To: netdev, jeff; +Cc: support
- Default to IntA interrupt type when there are less than 4 CPUs in the system.
Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com>
Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
---
diff -Nurp 2.0.26.2/drivers/net/s2io.c 2.0.26.3/drivers/net/s2io.c
--- 2.0.26.2/drivers/net/s2io.c 2007-08-07 13:39:45.000000000 -0700
+++ 2.0.26.3/drivers/net/s2io.c 2007-08-07 15:51:45.000000000 -0700
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.2"
+#define DRV_VERSION "2.0.26.3"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -452,7 +452,7 @@ S2IO_PARM_INT(l3l4hdr_size, 128);
/* Frequency of Rx desc syncs expressed as power of 2 */
S2IO_PARM_INT(rxsync_frequency, 3);
/* Interrupt type. Values can be 0(INTA), 2(MSI_X) */
-S2IO_PARM_INT(intr_type, 2);
+S2IO_PARM_INT(intr_type, DEF_MSI_X);
/* Large receive offload feature */
S2IO_PARM_INT(lro, 0);
/* Max pkts to be aggregated by LRO at one time. If not specified,
@@ -7671,10 +7671,11 @@ static int s2io_verify_parm(struct pci_d
if (*dev_intr_type != INTA)
napi = 0;
- if ((*dev_intr_type != INTA) && (*dev_intr_type != MSI_X)) {
+ if ((intr_type != INTA) && (intr_type != MSI_X)) {
DBG_PRINT(ERR_DBG, "s2io: Wrong intr_type requested. "
"Defaulting to INTA\n");
*dev_intr_type = INTA;
+ intr_type = INTA;
}
if ((*dev_intr_type == MSI_X) &&
@@ -7752,8 +7753,19 @@ s2io_init_nic(struct pci_dev *pdev, cons
struct mac_info *mac_control;
struct config_param *config;
int mode;
- u8 dev_intr_type = intr_type;
+ u8 dev_intr_type;
+ int no_cpus = 1;
+ no_cpus = num_online_cpus();
+ if(DEF_MSI_X == intr_type) {
+ /* Don't enable MSI-X if there are less than 4 CPUs */
+ if(no_cpus < 4)
+ intr_type = INTA;
+ else
+ intr_type = MSI_X;
+ }
+
+ dev_intr_type = intr_type;
if ((ret = s2io_verify_parm(pdev, &dev_intr_type)))
return ret;
diff -Nurp 2.0.26.2/drivers/net/s2io.h 2.0.26.3/drivers/net/s2io.h
--- 2.0.26.2/drivers/net/s2io.h 2007-08-07 13:39:45.000000000 -0700
+++ 2.0.26.3/drivers/net/s2io.h 2007-08-07 13:40:18.000000000 -0700
@@ -433,6 +433,7 @@ struct config_param {
u64 tx_intr_type;
#define INTA 0
#define MSI_X 2
+#define DEF_MSI_X 99
u8 intr_type;
u8 napi;
^ permalink raw reply
* [PATCH][Take2] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free
From: Tomohiro Kusumi @ 2007-08-10 5:16 UTC (permalink / raw)
To: auke-jan.h.kok, cramerj, john.ronciak, jesse.brandeburg,
jeffrey.t.kirsher
Cc: gregkh, netdev, linux-kernel
Dear Auke
http://lkml.org/lkml/2007/5/16/275
> I'm ok with the bottom part of the patch, but I do not like the modification of
> the pci device ID table in this way. As Arjan van der Ven previously commented
> as well, this makes it hard for future device ID's to be bound to the driver.
>
> On top of that, there is no logical correlation between the mapping and
> chipsets, so a lot of information is lost in that table. It really does not show
> which _chipsets_ support this functionality.
>
> I think if we want to work with this, we need some way of mapping the device
> ID's back to chipsets, and enable the feature on that basis.
This patches will meet your need in the way that it shows correlation
between their device IDs and the chipsets. It does not use the existing
macro INTEL_E1000_ETHERNET_DEVICE() to see whether the device uses I/O
port or not. Instead of modifying the PCI device table, I've added another
function called e1000_test_legacy_ioport() which tells you whether the PCI
device uses legacy I/O port or not by checking its chipset.
But one thing I want to say is that I am not sure about the chipsets that
require legacy I/O port. I found the following code in e1000 driver code
and it seems to be the only part that is using I/O port. So I thought
the following chipsets are the only ones using legacy I/O port.
I might be wrong, so any comments would be helpful.
drivers/net/e1000/e1000_hw.c
524 int32_t
525 e1000_reset_hw(struct e1000_hw *hw)
526 {
...
618 switch (hw->mac_type) {
619 case e1000_82544:
620 case e1000_82540:
621 case e1000_82545:
622 case e1000_82546:
623 case e1000_82541:
624 case e1000_82541_rev_2:
625 /* These controllers can't ack the 64-bit write when issuing the
626 * reset, so use IO-mapping as a workaround to issue the reset */
627 E1000_WRITE_REG_IO(hw, CTRL, (ctrl | E1000_CTRL_RST));
> I also would like this option to be non-default, IOW use legacy IO by default,
> and allow the user to specify a module load option to disable use of this feature:
I've also added the module parameter so that the user can select whether
he or she wants to enable the legacy I/O port free. The legacy I/O port free
option is non-default.
Rest of the part has not been changed since my previous patch. Any comments
would be helpful.
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@jp.fujitsu.com>
---
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000.h linux-2.6.22/drivers/net/e1000/e1000.h
--- linux-2.6.22.org/drivers/net/e1000/e1000.h 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000.h 2007-08-10 09:56:03.000000000 +0900
@@ -342,6 +342,9 @@ struct e1000_adapter {
boolean_t quad_port_a;
unsigned long flags;
uint32_t eeprom_wol;
+
+ int use_ioport;
+ int bars;
};
enum e1000_state_t {
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000_main.c linux-2.6.22/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.org/drivers/net/e1000/e1000_main.c 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000_main.c 2007-08-10 13:09:25.000000000 +0900
@@ -222,6 +222,11 @@ static pci_ers_result_t e1000_io_error_d
static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
static void e1000_io_resume(struct pci_dev *pdev);
+static unsigned int enable_legacy_ioport_free = 0;
+module_param(enable_legacy_ioport_free, uint, 0644);
+MODULE_PARM_DESC(enable_legacy_ioport_free, "Enable legacy I/O port free (default:0)");
+static int e1000_test_legacy_ioport(struct pci_dev *pdev);
+
static struct pci_error_handlers e1000_err_handler = {
.error_detected = e1000_io_error_detected,
.slot_reset = e1000_io_slot_reset,
@@ -868,8 +873,22 @@ e1000_probe(struct pci_dev *pdev,
int i, err, pci_using_dac;
uint16_t eeprom_data = 0;
uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
- if ((err = pci_enable_device(pdev)))
+ int bars = 0;
+ int use_ioport = 0;
+
+ if (enable_legacy_ioport_free) {
+ if ((use_ioport = e1000_test_legacy_ioport(pdev)) < 0) {
+ E1000_ERR("e1000_test_legacy_ioport failed, aborting\n");
+ return -1;
+ }
+ if (use_ioport)
+ bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
+ else
+ bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ }
+ else if ((err = pci_enable_device(pdev))) {
return err;
+ }
if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK)) &&
!(err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))) {
@@ -883,7 +902,8 @@ e1000_probe(struct pci_dev *pdev,
pci_using_dac = 0;
}
- if ((err = pci_request_regions(pdev, e1000_driver_name)))
+ if ((enable_legacy_ioport_free && (err = pci_request_selected_regions(pdev, bars, e1000_driver_name))) ||
+ (err = pci_request_regions(pdev, e1000_driver_name)))
goto err_pci_reg;
pci_set_master(pdev);
@@ -902,6 +922,10 @@ e1000_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
adapter->hw.back = adapter;
adapter->msg_enable = (1 << debug) - 1;
+ if (enable_legacy_ioport_free) {
+ adapter->use_ioport = use_ioport;
+ adapter->bars = bars;
+ }
mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
@@ -911,12 +935,14 @@ e1000_probe(struct pci_dev *pdev,
if (!adapter->hw.hw_addr)
goto err_ioremap;
- for (i = BAR_1; i <= BAR_5; i++) {
- if (pci_resource_len(pdev, i) == 0)
- continue;
- if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
- adapter->hw.io_base = pci_resource_start(pdev, i);
- break;
+ if (!enable_legacy_ioport_free || adapter->use_ioport) {
+ for (i = BAR_1; i <= BAR_5; i++) {
+ if (pci_resource_len(pdev, i) == 0)
+ continue;
+ if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
+ adapter->hw.io_base = pci_resource_start(pdev, i);
+ break;
+ }
}
}
@@ -1182,7 +1208,10 @@ err_sw_init:
err_ioremap:
free_netdev(netdev);
err_alloc_etherdev:
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, bars);
+ else
+ pci_release_regions(pdev);
err_pci_reg:
err_dma:
pci_disable_device(pdev);
@@ -1234,7 +1263,10 @@ e1000_remove(struct pci_dev *pdev)
iounmap(adapter->hw.hw_addr);
if (adapter->hw.flash_address)
iounmap(adapter->hw.flash_address);
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, adapter->bars);
+ else
+ pci_release_regions(pdev);
free_netdev(netdev);
@@ -5175,7 +5207,8 @@ e1000_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- if ((err = pci_enable_device(pdev))) {
+ if ((enable_legacy_ioport_free && (err = pci_enable_device_bars(pdev, adapter->bars))) ||
+ (err = pci_enable_device(pdev))) {
printk(KERN_ERR "e1000: Cannot enable PCI device from suspend\n");
return err;
}
@@ -5320,4 +5353,43 @@ static void e1000_io_resume(struct pci_d
}
+/*
+ * e1000_test_legacy_ioport - see if the device uses legacy I/O port
+ * @pdev: Pointer to PCI device
+ *
+ * This function tests if the PCI device uses I/O port.
+ * If yes the function returns 1, if no the function returns 0.
+ * The function returns -1 if there is an error.
+ */
+
+static int e1000_test_legacy_ioport(struct pci_dev *pdev)
+{
+ int ret;
+ struct e1000_hw hw;
+ memset(&hw, 0, sizeof(hw));
+
+ hw.mac_type = e1000_undefined;
+ hw.device_id = pdev->device;
+ pci_read_config_byte(pdev, PCI_REVISION_ID, &hw.revision_id);
+
+ if (e1000_set_mac_type(&hw) < 0)
+ return -1;
+
+ switch (hw.mac_type) {
+ case e1000_82540:
+ case e1000_82541:
+ case e1000_82541_rev_2:
+ case e1000_82544:
+ case e1000_82545:
+ case e1000_82546:
+ ret = 1;
+ break;
+ default:
+ ret = 0;
+ break;
+ }
+
+ return ret;
+}
+
/* e1000_main.c */
^ permalink raw reply
* Re: [PATCH][Take2] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free
From: Tomohiro Kusumi @ 2007-08-10 5:40 UTC (permalink / raw)
To: auke-jan.h.kok, cramerj, john.ronciak, jesse.brandeburg,
jeffrey.t.kirsher
Cc: gregkh, netdev, linux-kernel
In-Reply-To: <46BBF49F.6060701@jp.fujitsu.com>
Dear Auke
Sorry I sent the wrong patch.
I resubmit the patch.
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@jp.fujitsu.com>
---
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000.h linux-2.6.22/drivers/net/e1000/e1000.h
--- linux-2.6.22.org/drivers/net/e1000/e1000.h 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000.h 2007-08-10 09:56:03.000000000 +0900
@@ -342,6 +342,9 @@ struct e1000_adapter {
boolean_t quad_port_a;
unsigned long flags;
uint32_t eeprom_wol;
+
+ int use_ioport;
+ int bars;
};
enum e1000_state_t {
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000_main.c linux-2.6.22/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.org/drivers/net/e1000/e1000_main.c 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000_main.c 2007-08-10 14:27:41.000000000 +0900
@@ -222,6 +222,11 @@ static pci_ers_result_t e1000_io_error_d
static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
static void e1000_io_resume(struct pci_dev *pdev);
+static unsigned int enable_legacy_ioport_free = 0;
+module_param(enable_legacy_ioport_free, uint, 0644);
+MODULE_PARM_DESC(enable_legacy_ioport_free, "Enable legacy I/O port free (default:0)");
+static int e1000_test_legacy_ioport(struct pci_dev *pdev);
+
static struct pci_error_handlers e1000_err_handler = {
.error_detected = e1000_io_error_detected,
.slot_reset = e1000_io_slot_reset,
@@ -868,8 +873,25 @@ e1000_probe(struct pci_dev *pdev,
int i, err, pci_using_dac;
uint16_t eeprom_data = 0;
uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
- if ((err = pci_enable_device(pdev)))
+ int bars = 0;
+ int use_ioport = 0;
+
+ if (enable_legacy_ioport_free) {
+ if ((use_ioport = e1000_test_legacy_ioport(pdev)) < 0) {
+ E1000_ERR("e1000_test_legacy_ioport failed, aborting\n");
+ return -1;
+ }
+ if (use_ioport)
+ bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
+ else
+ bars = pci_select_bars(pdev, IORESOURCE_MEM);
+
+ if ((err = pci_enable_device_bars(pdev, bars)))
+ return err;
+ }
+ else if ((err = pci_enable_device(pdev))) {
return err;
+ }
if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK)) &&
!(err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))) {
@@ -883,7 +905,8 @@ e1000_probe(struct pci_dev *pdev,
pci_using_dac = 0;
}
- if ((err = pci_request_regions(pdev, e1000_driver_name)))
+ if ((enable_legacy_ioport_free && (err = pci_request_selected_regions(pdev, bars, e1000_driver_name))) ||
+ (err = pci_request_regions(pdev, e1000_driver_name)))
goto err_pci_reg;
pci_set_master(pdev);
@@ -902,6 +925,10 @@ e1000_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
adapter->hw.back = adapter;
adapter->msg_enable = (1 << debug) - 1;
+ if (enable_legacy_ioport_free) {
+ adapter->use_ioport = use_ioport;
+ adapter->bars = bars;
+ }
mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
@@ -911,12 +938,14 @@ e1000_probe(struct pci_dev *pdev,
if (!adapter->hw.hw_addr)
goto err_ioremap;
- for (i = BAR_1; i <= BAR_5; i++) {
- if (pci_resource_len(pdev, i) == 0)
- continue;
- if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
- adapter->hw.io_base = pci_resource_start(pdev, i);
- break;
+ if (!enable_legacy_ioport_free || adapter->use_ioport) {
+ for (i = BAR_1; i <= BAR_5; i++) {
+ if (pci_resource_len(pdev, i) == 0)
+ continue;
+ if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
+ adapter->hw.io_base = pci_resource_start(pdev, i);
+ break;
+ }
}
}
@@ -1182,7 +1211,10 @@ err_sw_init:
err_ioremap:
free_netdev(netdev);
err_alloc_etherdev:
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, bars);
+ else
+ pci_release_regions(pdev);
err_pci_reg:
err_dma:
pci_disable_device(pdev);
@@ -1234,7 +1266,10 @@ e1000_remove(struct pci_dev *pdev)
iounmap(adapter->hw.hw_addr);
if (adapter->hw.flash_address)
iounmap(adapter->hw.flash_address);
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, adapter->bars);
+ else
+ pci_release_regions(pdev);
free_netdev(netdev);
@@ -5175,7 +5210,8 @@ e1000_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- if ((err = pci_enable_device(pdev))) {
+ if ((enable_legacy_ioport_free && (err = pci_enable_device_bars(pdev, adapter->bars))) ||
+ (err = pci_enable_device(pdev))) {
printk(KERN_ERR "e1000: Cannot enable PCI device from suspend\n");
return err;
}
@@ -5320,4 +5356,43 @@ static void e1000_io_resume(struct pci_d
}
+/*
+ * e1000_test_legacy_ioport - see if the device uses legacy I/O port
+ * @pdev: Pointer to PCI device
+ *
+ * This function tests if the PCI device uses I/O port.
+ * If yes the function returns 1, if no the function returns 0.
+ * The function returns -1 if there is an error.
+ */
+
+static int e1000_test_legacy_ioport(struct pci_dev *pdev)
+{
+ int ret;
+ struct e1000_hw hw;
+ memset(&hw, 0, sizeof(hw));
+
+ hw.mac_type = e1000_undefined;
+ hw.device_id = pdev->device;
+ pci_read_config_byte(pdev, PCI_REVISION_ID, &hw.revision_id);
+
+ if (e1000_set_mac_type(&hw) < 0)
+ return -1;
+
+ switch (hw.mac_type) {
+ case e1000_82540:
+ case e1000_82541:
+ case e1000_82541_rev_2:
+ case e1000_82544:
+ case e1000_82545:
+ case e1000_82546:
+ ret = 1;
+ break;
+ default:
+ ret = 0;
+ break;
+ }
+
+ return ret;
+}
+
/* e1000_main.c */
^ permalink raw reply
* Re: net-2.6.24 GIT state
From: Ilpo Järvinen @ 2007-08-10 6:57 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <20070809.182719.99676246.davem@davemloft.net>
On Thu, 9 Aug 2007, David Miller wrote:
> I applied everything up until the SACK validator to net-2.6.24
Ok, thanks.
> Everything I hit today which had not been posted before was trivial
> fix or a reasonable small cleanup.
...Yeah, I know that but don't want to give impression that something
gets "sneaked" in...
> Why don't you just post the patches to the list one-by-one from
> now on so we can review them in parallel with merging into
> net-2.6.24?
Ok, will do. ...I thought that at some point that would be wise way
forward...
--
i.
^ permalink raw reply
* Fwd: bug in kernel 2.6.20.9 in ipv6 dest opt <help>
From: md ayyaz @ 2007-08-10 7:04 UTC (permalink / raw)
To: netdev
In-Reply-To: <df1706540708092335h1c8ad61dq6ed8f11e01d0190e@mail.gmail.com>
---------- Forwarded message ----------
From: md ayyaz <md.ayyaz@gmail.com>
Date: Aug 10, 2007 12:05 PM
Subject: bug in kernel 2.6.20.9 in ipv6 dest opt <help>
To: yoshfuji@linux-ipv6.org
Hi ,
i am working on mobile ipv6 protocol , so what happens whenver i pass
a ipv6 packet with destination option in it , it doesnt parse it
correctly in extension header parsing for dest option and hence
returns -1 as an error back so packet gets dropped in ip layer , along
with this if i send ipv6-ipv6 tunnel packet it shows slab corruption
in logs ,( i had put some debug messages)
please reply as soon as possible i will be greatly thankfull for the help
Aug 1 16:18:12 localhost kernel: Recived IPv6 packet with next hdr as 17 from
3ffe:0300:0068:0218:f3ff:fed9:8914:f521600001
Aug 1 16:18:12 localhost kernel: packet Len : 173 nxt Hdr : 17 skb:213
Aug 1 16:18:13 localhost kernel: Recived IPv6 packet with next hdr as 17 from
3ffe:0300:0068:0218:f3ff:fed9:8914:f521600001
Aug 1 16:18:13 localhost kernel: packet Len : 173 nxt Hdr : 17 skb:213
Aug 1 16:18:14 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:14 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:16 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:16 localhost kernel: packet Len : 24 nxt Hdr : 58 skb:64
Aug 1 16:18:18 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:18 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:21 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:21 localhost kernel: packet Len : 32 nxt Hdr : 58 skb:72
Aug 1 16:18:24 localhost kernel: Recived IPv6 packet with next hdr as 41 from
3ffe:0300:0068:020c:29ff:fea2:b14c:f521600001
Aug 1 16:18:24 localhost kernel: packet Len : 140 nxt Hdr : 41 skb:180
Aug 1 16:18:24 localhost kernel: Slab corruption: start=f50b1dac, len=176
Aug 1 16:18:24 localhost kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Aug 1 16:18:24 localhost kernel: Last user:
[<c055d930>](kfree_skbmem+0x63/0x66)
Aug 1 16:18:24 localhost kernel: 090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6a 6b 6b 6b
Aug 1 16:18:24 localhost kernel: Single bit error detected. Probably bad
RAM.
Aug 1 16:18:24 localhost kernel: Run memtest86+ or a similar memory test
tool.
Aug 1 16:18:24 localhost kernel: Prev obj: start=f50b1cf0, len=176
Aug 1 16:18:24 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:24 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:24 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:24 localhost kernel: 010: 00 00 00 00 00 60 21 f5 00 00 00 00
00 00 00 00
Aug 1 16:18:24 localhost kernel: Next obj: start=f50b1e68, len=176
Aug 1 16:18:24 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:24 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:24 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:24 localhost kernel: 010: 00 00 00 00 00 60 21 f5 00 00 00 00
00 00 00 00
Aug 1 16:18:26 localhost kernel: Recived IPv6 packet with next hdr as 58
from fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:26 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:35 localhost kernel: Recived IPv6 packet with next hdr as 58
from fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:35 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:37 localhost kernel: Recived IPv6 packet with next hdr as 41
from 3ffe:0300:0068:020c:29ff:fea2:b14c:f521600001
Aug 1 16:18:37 localhost kernel: packet Len : 140 nxt Hdr : 41 skb:180
Aug 1 16:18:37 localhost kernel: Slab corruption: start=f50ba4dc, len=176
Aug 1 16:18:37 localhost kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Aug 1 16:18:37 localhost kernel: Last user:
[<c055d930>](kfree_skbmem+0x63/0x66)
Aug 1 16:18:37 localhost kernel: 090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6a 6b 6b 6b
Aug 1 16:18:37 localhost kernel: Single bit error detected. Probably bad
RAM.
Aug 1 16:18:37 localhost kernel: Run memtest86+ or a similar memory test
tool.
Aug 1 16:18:37 localhost kernel: Prev obj: start=f50ba420, len=176
Aug 1 16:18:37 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:37 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:37 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:37 localhost kernel: 010: 00 00 00 00 00 60 21 f5 00 00 00 00
00 00 00 00
Aug 1 16:18:37 localhost kernel: Next obj: start=f50ba598, len=176
Aug 1 16:18:37 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:37 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:37 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:37 localhost kernel: 010: 00 00 00 00 00 00 f6 f7 00 00 00 00
00 00 00 00
^ permalink raw reply
* Re: [patch (testing)] Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-10 7:10 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Ingo Molnar, Thomas Gleixner, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <4bacf17f0708092333n17e0ba19jf2c769531610868d@mail.gmail.com>
On Fri, Aug 10, 2007 at 08:33:27AM +0200, Marcin Ślusarz wrote:
> 2007/8/9, Jarek Poplawski <jarkao2@o2.pl>:
...
> > diff -Nurp 2.6.23-rc1-/kernel/irq/chip.c 2.6.23-rc1/kernel/irq/chip.c
> > --- 2.6.23-rc1-/kernel/irq/chip.c 2007-07-09 01:32:17.000000000 +0200
> > +++ 2.6.23-rc1/kernel/irq/chip.c 2007-08-08 20:49:07.000000000 +0200
> > @@ -389,12 +389,19 @@ handle_fasteoi_irq(unsigned int irq, str
> > unsigned int cpu = smp_processor_id();
> > struct irqaction *action;
> > irqreturn_t action_ret;
> > + int edge = 0;
> >
...
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=351.
> eth0: Resetting the 8390 t=4295229000...<6>NETDEV WATCHDOG: eth0:
> transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=718.
> eth0: Resetting the 8390 t=4295230000...<6>NETDEV WATCHDOG: eth0:
> transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=874.
> etc...
So, we still have to wait for the exact explanation...
Thanks very much Marcin!
I think, there is this one possible for your testing yet?:
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
Date: Wed, 8 Aug 2007 13:00:37 +0200
If it's not a great problem it would be interesting to try this with
different CONFIG_HZ too e.g. you could start with 100 (I guess, you
tested very similar thing in 2.6.23-rc2 with 1000(?) already).
Jean-Baptiste: you can skip/break testing of this 'experimental'
patch, too.
Regards,
Jarek P.
^ permalink raw reply
* Re: 2.6.23-rc2-mm2: possible irq lock inversion dependency detected
From: Mariusz Kozlowski @ 2007-08-10 7:59 UTC (permalink / raw)
To: Andrew Morton, netdev, Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20070809224254.11f42716.akpm@linux-foundation.org>
Hello,
Have fun :)
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.23-rc2-mm2 #1
---------------------------------------------------------
depscan.sh/5928 just changed the state of lock:
(_xmit_ETHER){-+..}, at: [<c03cb669>] dev_watchdog+0x17/0xcc
but this lock took another, soft-irq-unsafe lock in the past:
(&tp->lock){--..}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
no locks held by depscan.sh/5928.
the first lock's dependencies:
-> (_xmit_ETHER){-+..} ops: 27 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c045282a>] _spin_lock_bh+0x3a/0x47
[<c03bc0a6>] dev_set_rx_mode+0x14/0x3b
[<c03bc5af>] dev_change_flags+0x68/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c03cb669>] dev_watchdog+0x17/0xcc
[<c01224b7>] run_timer_softirq+0x14b/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c01393d0>] __lock_acquire+0x73e/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c045282a>] _spin_lock_bh+0x3a/0x47
[<c03bc0a6>] dev_set_rx_mode+0x14/0x3b
[<c03bc5af>] dev_change_flags+0x68/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<c087e9e8>] netdev_xmit_lock_key+0x8/0x1c0
-> (&tp->lock){--..} ops: 44 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c0148b92>] request_irq+0xba/0x108
[<de84e52d>] rtl8139_open+0x2f/0x1e2 [8139too]
[<c03be80d>] dev_open+0x37/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
softirq-on-W at:
[<c01393f9>] __lock_acquire+0x767/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c01393d0>] __lock_acquire+0x73e/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<de852190>] __key.19796+0x0/0xffffd3c9 [8139too]
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<de84d275>] rtl8139_set_rx_mode+0x1e/0x166 [8139too]
[<c03bbe72>] __dev_set_rx_mode+0x24/0x85
[<c03bc0b8>] dev_set_rx_mode+0x26/0x3b
[<c03be830>] dev_open+0x5a/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
-> (&priv->lock){++..} ops: 113 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04529cc>] _spin_lock_irq+0x3b/0x48
[<ded03256>] orinoco_init+0x8f5/0xbbd [orinoco]
[<c03bdbde>] register_netdevice+0x13a/0x3f8
[<c03bdece>] register_netdev+0x32/0x3f
[<ded2c4bb>] orinoco_cs_probe+0x368/0x3df [orinoco_cs]
[<ded378d9>] pcmcia_device_probe+0xc9/0x14c [pcmcia]
[<c02f324f>] driver_probe_device+0xa6/0x198
[<c02f3492>] __driver_attach+0xa2/0xa4
[<c02f271a>] bus_for_each_dev+0x43/0x61
[<c02f30d1>] driver_attach+0x19/0x1b
[<c02f2a89>] bus_add_driver+0x7e/0x1a5
[<c02f363f>] driver_register+0x45/0x75
[<ded38560>] pcmcia_register_driver+0xdb/0x12f [pcmcia]
[<de84b024>] 0xde84b024
[<c0140a47>] sys_init_module+0xc4/0x1622
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<ded03bb4>] orinoco_interrupt+0x3f/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ded06a99>] orinoco_get_wireless_stats+0xeb/0x140 [orinoco]
[<c042b2ba>] get_wireless_stats+0x1a/0x21
[<c042bf69>] wireless_seq_show+0x20/0x143
[<c0187357>] seq_read+0x1af/0x2b8
[<c01a1ed2>] proc_reg_read+0x57/0x78
[<c016d781>] vfs_read+0xaa/0x147
[<c016dba6>] sys_read+0x3d/0x7b
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<ded03bb4>] orinoco_interrupt+0x3f/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ded06a99>] orinoco_get_wireless_stats+0xeb/0x140 [orinoco]
[<c042b2ba>] get_wireless_stats+0x1a/0x21
[<c042bf69>] wireless_seq_show+0x20/0x143
[<c0187357>] seq_read+0x1af/0x2b8
[<c01a1ed2>] proc_reg_read+0x57/0x78
[<c016d781>] vfs_read+0xaa/0x147
[<c016dba6>] sys_read+0x3d/0x7b
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<ded0a298>] __key.20430+0x0/0xffffc9cd [orinoco]
-> (lweventlist_lock){+...} ops: 8 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03c78db>] linkwatch_add_event+0x10/0x31
[<c03c79ba>] linkwatch_fire_event+0x35/0x37
[<c03cb36a>] netif_carrier_off+0x19/0x20
[<ded023b5>] alloc_orinocodev+0x181/0x19c [orinoco]
[<ded2c170>] orinoco_cs_probe+0x1d/0x3df [orinoco_cs]
[<ded378d9>] pcmcia_device_probe+0xc9/0x14c [pcmcia]
[<c02f324f>] driver_probe_device+0xa6/0x198
[<c02f3492>] __driver_attach+0xa2/0xa4
[<c02f271a>] bus_for_each_dev+0x43/0x61
[<c02f30d1>] driver_attach+0x19/0x1b
[<c02f2a89>] bus_add_driver+0x7e/0x1a5
[<c02f363f>] driver_register+0x45/0x75
[<ded38560>] pcmcia_register_driver+0xdb/0x12f [pcmcia]
[<de84b024>] 0xde84b024
[<c0140a47>] sys_init_module+0xc4/0x1622
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03c78db>] linkwatch_add_event+0x10/0x31
[<c03c79ba>] linkwatch_fire_event+0x35/0x37
[<c03cb39a>] netif_carrier_on+0x29/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c05e4990>] lweventlist_lock+0x10/0x20
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03c78db>] linkwatch_add_event+0x10/0x31
[<c03c79ba>] linkwatch_fire_event+0x35/0x37
[<c03cb39a>] netif_carrier_on+0x29/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
-> (&cwq->lock){++..} ops: 4593 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c0128714>] call_usermodehelper_exec+0xce/0xe1
[<c0265385>] kobject_uevent_env+0x34d/0x449
[<c026548b>] kobject_uevent+0xa/0xf
[<c0264b69>] kset_register+0x32/0x38
[<c0264b77>] subsystem_register+0x8/0xa
[<c02f2c9a>] bus_register+0x65/0x1f3
[<c0611db6>] platform_bus_init+0x23/0x38
[<c0611e0c>] driver_init+0x1c/0x31
[<c05fc68d>] kernel_init+0x5d/0x26b
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c029239a>] acpi_os_execute+0xae/0xcb
[<c02aa226>] acpi_ec_gpe_handler+0x4d/0x5e
[<c0297f51>] acpi_ev_gpe_dispatch+0x4b/0x115
[<c0298253>] acpi_ev_gpe_detect+0x9a/0xe1
[<c0296989>] acpi_ev_sci_xrupt_handler+0x15/0x1d
[<c0291aae>] acpi_irq+0xe/0x18
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c0129044>] delayed_work_timer_fn+0x24/0x28
[<c01224b7>] run_timer_softirq+0x14b/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c0128b00>] run_workqueue+0xe8/0x1f3
[<c0129648>] worker_thread+0x9a/0xf2
[<c012c04e>] kthread+0x36/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
}
... key at: [<c0657ae8>] __key.11148+0x0/0x8
-> (&q->lock){++..} ops: 74830 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04529cc>] _spin_lock_irq+0x3b/0x48
[<c044fcf5>] wait_for_completion+0x24/0xb5
[<c012c1d1>] kthread_create+0x69/0xa8
[<c0606fcc>] cpu_callback+0x48/0xa3
[<c0607043>] spawn_ksoftirqd+0x1c/0x4e
[<c05fc66c>] kernel_init+0x3c/0x26b
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0113d3b>] __wake_up+0x15/0x42
[<c02aa1ff>] acpi_ec_gpe_handler+0x26/0x5e
[<c0297f51>] acpi_ev_gpe_dispatch+0x4b/0x115
[<c0298253>] acpi_ev_gpe_detect+0x9a/0xe1
[<c0296989>] acpi_ev_sci_xrupt_handler+0x15/0x1d
[<c0291aae>] acpi_irq+0xe/0x18
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0113c7c>] complete+0x15/0x4b
[<c0129ebe>] wakeme_after_rcu+0xb/0xd
[<c012a013>] __rcu_process_callbacks+0x69/0x1cf
[<c012a18b>] rcu_process_callbacks+0x12/0x23
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0657f30>] __key.11466+0x0/0x8
-> (&rq->rq_lock_key){++..} ops: 216798 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c060664a>] init_idle+0x40/0x6d
[<c06067e0>] sched_init+0x169/0x17c
[<c05fc970>] start_kernel+0xd5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c01157f3>] scheduler_tick+0x20/0x192
[<c0122c31>] update_process_times+0x43/0x62
[<c0134325>] tick_periodic+0x24/0x75
[<c013438e>] tick_handle_periodic+0x18/0x7a
[<c01064ae>] timer_interrupt+0xe/0x15
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c014890a>] setup_irq+0xf2/0x20d
[<c060656f>] time_init_hook+0x19/0x1b
[<c05ffcc8>] hpet_time_init+0xd/0x15
[<c05fca70>] start_kernel+0x1d5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150d1>] default_wake_function+0xb/0xd
[<c011284b>] __wake_up_common+0x39/0x59
[<c0113ca1>] complete+0x3a/0x4b
[<c0129ebe>] wakeme_after_rcu+0xb/0xd
[<c012a013>] __rcu_process_callbacks+0x69/0x1cf
[<c012a18b>] rcu_process_callbacks+0x12/0x23
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0635d28>] per_cpu__runqueues+0x468/0x470
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150d1>] default_wake_function+0xb/0xd
[<c011284b>] __wake_up_common+0x39/0x59
[<c0113ca1>] complete+0x3a/0x4b
[<c012c037>] kthread+0x1f/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0113d3b>] __wake_up+0x15/0x42
[<c0128c6b>] insert_work+0x60/0x75
[<c0129012>] __queue_work+0x1f/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c0128714>] call_usermodehelper_exec+0xce/0xe1
[<c0265385>] kobject_uevent_env+0x34d/0x449
[<c026548b>] kobject_uevent+0xa/0xf
[<c0264b69>] kset_register+0x32/0x38
[<c0264b77>] subsystem_register+0x8/0xa
[<c02f2c9a>] bus_register+0x65/0x1f3
[<c0611db6>] platform_bus_init+0x23/0x38
[<c0611e0c>] driver_init+0x1c/0x31
[<c05fc68d>] kernel_init+0x5d/0x26b
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c01294af>] queue_delayed_work+0x27/0x48
[<c01294f2>] schedule_delayed_work+0x22/0x26
[<c03c793c>] linkwatch_schedule_work+0x40/0x89
[<c03c79a9>] linkwatch_fire_event+0x24/0x37
[<c03cb39a>] netif_carrier_on+0x29/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
-> (base_lock_keys + cpu){++..} ops: 69219 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c01229f6>] lock_timer_base+0x41/0x66
[<c0122ab8>] __mod_timer+0x3b/0xc5
[<c0122bea>] mod_timer+0x47/0x4b
[<c0611091>] con_init+0x24b/0x27e
[<c061075a>] console_init+0x20/0x2e
[<c05fca30>] start_kernel+0x195/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c01229f6>] lock_timer_base+0x41/0x66
[<c0122a47>] del_timer+0x2c/0x62
[<c0302a8b>] ide_intr+0x72/0x1f0
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04529cc>] _spin_lock_irq+0x3b/0x48
[<c0122395>] run_timer_softirq+0x29/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c014890a>] setup_irq+0xf2/0x20d
[<c060656f>] time_init_hook+0x19/0x1b
[<c05ffcc8>] hpet_time_init+0xd/0x15
[<c05fca70>] start_kernel+0x1d5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0657a96>] base_lock_keys+0x0/0xa
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c01229f6>] lock_timer_base+0x41/0x66
[<c0122ab8>] __mod_timer+0x3b/0xc5
[<c0122bea>] mod_timer+0x47/0x4b
[<c03cae67>] __netdev_watchdog_up+0x37/0x50
[<c03cb390>] netif_carrier_on+0x1f/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
-> (&list->lock#2){.+..} ops: 12 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03b70bb>] skb_queue_tail+0x14/0x33
[<c042b67b>] wireless_send_event+0x348/0x369
[<c042b9b9>] ioctl_standard_call+0x1b2/0x34d
[<c042beae>] wext_handle_ioctl+0x35a/0x3e4
[<c03be765>] dev_ioctl+0x31e/0x325
[<c03b153c>] sock_ioctl+0xb7/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03b716c>] skb_dequeue+0x12/0x50
[<c042b32d>] wireless_nlevent_process+0x2d/0x33
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ded028e3>] orinoco_ioctl_commit+0x8e/0x10c [orinoco]
[<c042b2f0>] call_commit_handler+0x2f/0x3f
[<c042b9d2>] ioctl_standard_call+0x1cb/0x34d
[<c042beae>] wext_handle_ioctl+0x35a/0x3e4
[<c03be765>] dev_ioctl+0x31e/0x325
[<c03b153c>] sock_ioctl+0xb7/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<c0884a80>] __key.13323+0x0/0x20
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03b70bb>] skb_queue_tail+0x14/0x33
[<c042b67b>] wireless_send_event+0x348/0x369
[<ded03b69>] orinoco_send_wevents+0x9a/0xa6 [orinoco]
[<c0128b28>] run_workqueue+0x110/0x1f3
[<c0129648>] worker_thread+0x9a/0xf2
[<c012c04e>] kthread+0x36/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
-> (&rq->rq_lock_key){++..} ops: 216798 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c060664a>] init_idle+0x40/0x6d
[<c06067e0>] sched_init+0x169/0x17c
[<c05fc970>] start_kernel+0xd5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c01157f3>] scheduler_tick+0x20/0x192
[<c0122c31>] update_process_times+0x43/0x62
[<c0134325>] tick_periodic+0x24/0x75
[<c013438e>] tick_handle_periodic+0x18/0x7a
[<c01064ae>] timer_interrupt+0xe/0x15
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c014890a>] setup_irq+0xf2/0x20d
[<c060656f>] time_init_hook+0x19/0x1b
[<c05ffcc8>] hpet_time_init+0xd/0x15
[<c05fca70>] start_kernel+0x1d5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150d1>] default_wake_function+0xb/0xd
[<c011284b>] __wake_up_common+0x39/0x59
[<c0113ca1>] complete+0x3a/0x4b
[<c0129ebe>] wakeme_after_rcu+0xb/0xd
[<c012a013>] __rcu_process_callbacks+0x69/0x1cf
[<c012a18b>] rcu_process_callbacks+0x12/0x23
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0635d28>] per_cpu__runqueues+0x468/0x470
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150ee>] wake_up_process+0xf/0x11
[<c011f5cc>] __tasklet_schedule+0x6d/0x6f
[<c042b697>] wireless_send_event+0x364/0x369
[<ded03b69>] orinoco_send_wevents+0x9a/0xa6 [orinoco]
[<c0128b28>] run_workqueue+0x110/0x1f3
[<c0129648>] worker_thread+0x9a/0xf2
[<c012c04e>] kthread+0x36/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<ded03598>] orinoco_set_multicast_list+0x1b/0x5f [orinoco]
[<c03bbe72>] __dev_set_rx_mode+0x24/0x85
[<c03bc0b8>] dev_set_rx_mode+0x26/0x3b
[<c03be830>] dev_open+0x5a/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
the second lock's dependencies:
-> (&tp->lock){--..} ops: 44 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c0148b92>] request_irq+0xba/0x108
[<de84e52d>] rtl8139_open+0x2f/0x1e2 [8139too]
[<c03be80d>] dev_open+0x37/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
softirq-on-W at:
[<c01393f9>] __lock_acquire+0x767/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c01393d0>] __lock_acquire+0x73e/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<de852190>] __key.19796+0x0/0xffffd3c9 [8139too]
stack backtrace:
[<c0104899>] show_trace_log_lvl+0x1a/0x30
[<c0105296>] show_trace+0x12/0x14
[<c01053fe>] dump_stack+0x15/0x17
[<c0137462>] print_irq_inversion_bug+0x101/0x123
[<c0137db1>] check_usage_forwards+0x3e/0x45
[<c0137f67>] mark_lock+0x1af/0x70c
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c03cb669>] dev_watchdog+0x17/0xcc
[<c01224b7>] run_timer_softirq+0x14b/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
=======================
Clocksource tsc unstable (delta = 9372868714 ns)
Regards,
Mariusz
^ permalink raw reply
* Re: 2.6.23-rc2: WARNING: at kernel/irq/resend.c:70 check_irq_resend()
From: Thomas Gleixner @ 2007-08-10 8:05 UTC (permalink / raw)
To: Jarek Poplawski
Cc: John Stoffel, linux-kernel, shemminger, vignaud, marcin.slusarz,
mingo, torvalds, akpm, alan, linux-net, netdev
In-Reply-To: <20070809155445.GA5161@ff.dom.local>
On Thu, 2007-08-09 at 17:54 +0200, Jarek Poplawski wrote:
> I'm not sure I don't miss anything (a little in hurry now), but this
> warning's aim was purely diagnostical and nothing wrong is meant!
> Unless there is something wrong... Then please try to be more explicit.
>
> If you prefer to not see this, there is my patch proposal somewhere
> in this older thread:
> Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
> Date: Wed, 8 Aug 2007 13:00:37 +0200
>
> On the other hand, if it works OK, it would be better to let it be
> tested more like this...
Hmm. This solution is still just pampering over the real problem. The
delayed disable just re-sends level interrupts unnecessarily. I have a
fix (needs some testing) for this, which I send out tomorrow, when I'm
really back from vacation.
But suppressing the resend is not fixing the driver problem. The problem
can show up with spurious interrupts and with interrupts on a shared PCI
interrupt line at any time. It just might take weeks instead of minutes.
Alan,
is there anything which can be done on the driver level ?
tglx
^ permalink raw reply
* Add 3c59x maintainer
From: Steffen Klassert @ 2007-08-10 8:14 UTC (permalink / raw)
To: Andrew Morton, Jeff Garzik; +Cc: netdev
Add 3c59x maintainer.
Signed-off-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
--- linux-2.6.23-rc2.orig/MAINTAINERS
+++ linux-2.6.23-rc2/MAINTAINERS
@@ -97,6 +97,12 @@ M: philb@gnu.org
L: netdev@vger.kernel.org
S: Maintained
+3C59X NETWORK DRIVER
+P: Steffen Klassert
+M: klassert@mathematik.tu-chemnitz.de
+L: netdev@vger.kernel.org
+S: Maintained
+
3CR990 NETWORK DRIVER
P: David Dillow
M: dave@thedillows.org
^ permalink raw reply
* Re: [patch (testing)] Re: 2.6.20->2.6.21 - networking dies after random time
From: Jean-Baptiste Vignaud @ 2007-08-10 8:15 UTC (permalink / raw)
To: jarkao2
Cc: marcin.slusarz, mingo, tglx, torvalds, linux-kernel, shemminger,
linux-net, netdev, akpm, alan
> So, we still have to wait for the exact explanation...
>
> Thanks very much Marcin!
>
> I think, there is this one possible for your testing yet?:
> Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
> Date: Wed, 8 Aug 2007 13:00:37 +0200
>
> If it's not a great problem it would be interesting to try this with
> different CONFIG_HZ too e.g. you could start with 100 (I guess, you
> tested very similar thing in 2.6.23-rc2 with 1000(?) already).
>
> Jean-Baptiste: you can skip/break testing of this 'experimental'
ok
I was still testing on -rc2:
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
Date: Wed, 8 Aug 2007 13:00:37 +0200
For me after 1day 20hours, the network is still up, with more than 1To
of network traffic. HZ was 1000, i restart with HZ=100.
Jb
^ 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