Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Thu, Jan 04, 2007 at 07:29:30PM +1100, Herbert Xu wrote: On Thu, Jan 04, 2007 at 09:03:51AM +0100, Jarek Poplawski wrote: I doubt this is the right solution. It certainly could fix this particular situation but my main point was packets shouldn't get into kernel receive queues with skb-dev not IFF_UP. I think you misunderstood. The device certainly is IFF_UP. What happens is that the multicast spin locks are set up too late: Could you explain? I can see some inet_rtm_newaddr interrupted. For me it could be e.g.: after vconfig add eth0 9 ip addr add dev eth0.9 ... before ip link set dev eth0.9 up Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fib6: Fix fn-leaf == NULL race when inserting new nodes in fib6 tree
When inserting new nodes into a fib6 tree, the leaf pointer
is first to NULL and later corrected when the key gets
assigned. However, the tree is not locked for this period
of time, therefore nodes with an invalid leaf pointer
are accessible. Lookups that occur during this period of time
expect a valid leaf pointer and thus crash.
This patch sets the leaf pointer to ip6_null_entry during
this critical period of time.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/ipv6/ip6_fib.c
===
--- net-2.6.orig/net/ipv6/ip6_fib.c 2007-01-04 10:01:43.0 +0100
+++ net-2.6/net/ipv6/ip6_fib.c 2007-01-04 10:17:05.0 +0100
@@ -150,9 +150,19 @@ static __inline__ struct fib6_node * nod
{
struct fib6_node *fn;
- if ((fn = kmem_cache_alloc(fib6_node_kmem, GFP_ATOMIC)) != NULL)
+ if ((fn = kmem_cache_alloc(fib6_node_kmem, GFP_ATOMIC)) != NULL) {
memset(fn, 0, sizeof(struct fib6_node));
+ /*
+* leaf is set to ip6_null_entry to provide a valid leaf
+* during the time period between inserting the node into
+* the tree and assigning the key. This is necessary because
+* the node is accessible during this period of time.
+*/
+ fn-leaf = ip6_null_entry;
+ fn-fn_flags |= RTN_TEMP_LEAF;
+ }
+
return fn;
}
@@ -551,6 +561,7 @@ insert_above:
in-parent = pn;
in-leaf = fn-leaf;
atomic_inc(in-leaf-rt6i_ref);
+ in-fn_flags = ~RTN_TEMP_LEAF;
in-fn_sernum = sernum;
@@ -620,6 +631,12 @@ static int fib6_add_rt2node(struct fib6_
ins = fn-leaf;
+ /* Avoid duplicate checks for temporary leafs */
+ if (fn-fn_flags RTN_TEMP_LEAF) {
+ fn-fn_flags = ~RTN_TEMP_LEAF;
+ goto out;
+ }
+
if (fn-fn_flagsRTN_TL_ROOT
fn-leaf == ip6_null_entry
!(rt-rt6i_flags (RTF_DEFAULT | RTF_ADDRCONF)) ){
Index: net-2.6/include/net/ip6_fib.h
===
--- net-2.6.orig/include/net/ip6_fib.h 2007-01-04 10:07:05.0 +0100
+++ net-2.6/include/net/ip6_fib.h 2007-01-04 10:09:04.0 +0100
@@ -135,6 +135,7 @@ struct rt6_statistics {
#define RTN_TL_ROOT0x0001
#define RTN_ROOT 0x0002 /* tree root node */
#define RTN_RTINFO 0x0004 /* node with valid routing info */
+#define RTN_TEMP_LEAF 0x0008 /* leaf is temporary*/
/*
* priority levels (or metrics)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
egress path understanding
Hi all,
(sorry for newbie question)
I'm trying to learn the networking code of an ancient 2.4.18 vanilla kernel.
I understand that the egress path of network packet (socket buffer) as
general behaviour, goes through the method hard_start_xmit() within of
the driver layer. This method is the responsible of putting the
network packet into the output buffers of the network device. When the
physical transmmission is completed the device raises an interrupt and
the interrupt handler of the device is called.
The typical interrupt handler is a function running in interrupt
context, so needs to be as quick as possible, and because this
function has to free the skb buffer (to deallocate the sk_buff
structure associated with sucessfully transmitted buffer), the task is
delegated to softirq (NET_TX_SOFTIRQ) by means of function
dev_kfree_skb_irq():
static inline void dev_kfree_skb_irq(struct sk_buff *skb)
{
if (atomic_dec_and_test(skb-users)) {
int cpu =smp_processor_id();
unsigned long flags;
#ifdef CONFIG_PROC_FS
softirq_stats.raise_from_kfree_skb_cont++;
#endif
local_irq_save(flags);
skb-next = softnet_data[cpu].completion_queue;
softnet_data[cpu].completion_queue = skb;
cpu_raise_softirq(cpu, NET_TX_SOFTIRQ);
local_irq_restore(flags);
}
}
When do_softirq() is called the funcion associated with
NET_TX_SOFTIRQ, net_tx_action() is called:
static void net_tx_action(struct softirq_action *h)
{
int cpu = smp_processor_id();
if (softnet_data[cpu].completion_queue) {
struct sk_buff *clist;
local_irq_disable();
clist = softnet_data[cpu].completion_queue;
softnet_data[cpu].completion_queue = NULL;
local_irq_enable();
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist-next;
#ifdef CONFIG_PROC_FS
softirq_stats.tx_completion_cont++;
#endif
BUG_TRAP(atomic_read(skb-users) == 0);
__kfree_skb(skb);
}
}
. [snip]
}
How you can see, I have put some counters in order to trace the
execution of networking code by means of the file:
/proc/net/softirq_stat. The oputput of this file is the following when
I test the kernel:
# cat /proc/net/softirq_stat
raise_from_netif_cont: 0
raise_from_kfree_skb_cont: 0
(qdisc_restart) hard_start_xmit_cont: 5869
(qdisc_restart) xmit_lock_grabbed_cont: 0
tx_completion_cont: 5869
tx_output_cont: 142
OK, the important fields of this output are tx_completion_cont and
raise_from_kfree_skb_cont. We can see that every packet passed to
hard_start_xmit_cont (in qdisc_restart) is freed with net_tx_action,
so the counter hard_start_xmit_cont and tx_completion_cont show the
same values. But I cannot understand why the counter
raise_from_kfree_skb_cont is zero!!!
I guess the code path must pass through of dev_kfree_skb_irq() in
order to raise the softirq with cpu_raise_softirq(cpu,
NET_TX_SOFTIRQ), so it's possible to execute net_tx_action() later.
I don't know if I don't understand the therory or I have an error in
the code. Please can anybody advice me about this behaviour?
Thanks a lot, and sorry for my english.
--
Javi Roman
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: removing gotos considered harmful...
| previous code had the form (this is copied from 2.6.17-mm1 original):
|
| size = 0;
| sk_for_each(sk2, node, list)
| if (++size = best_size_so_far)
| goto next;
| best_size_so_far = size;
| best = result;
| next:;
|
| | and this got converted into:
| |
| | sk_for_each(sk2, node, head)
| | if (++size best_size_so_far) {
| | best_size_so_far = size;
| | best = result;
| | }
| |
| | Which does something very very different from the original.
|
| === Sorry, I fail to see where the two differ. They have the same
postcondition
|upon loop exit; sk2, node, size, and head are not referenced anywhere
in the
|code that follows.
|
|
| Please go buy a pair of glasses then :-)
|
| They are not at all the same. Consider in what circumstances the two
| variables best_size_so_far and best get updated in the two cases,
| it's massively different.
|
| You _ALWAYS_ update those two variables in your version if the loop
| executes at least once, that's wrong and that's not what the original
| code was trying to do.
|
| It ONLY wants to update those two variables when we walk
| a complete hash chain which is smaller than best_size_so_far.
|
| The fact that you continue to try and defend your version shows
| that you really had no idea what you were doing when you made this
| change.
|
| You added an exploitable hole to our UDP protocol implementation
| because you didn't understand this snippet of code and wanted to
| 'clean up the logic'.
|
|
You are right, I made a stupid error by considering a single construct out of
context.
I only understood fully what you were saying above after doing a lengthy
paper-and-pencil
analysis of the entire algorithm: the exploit is in the assignment of `best', I
was arguing
about `best_size_so_far', which is of no consequence here.
I apologise for the regression that this caused - in future submissions I make
sure that I
do the paper and pencil analysis before. Thanks for patience with the
explanation.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
Could you explain? I can see some inet_rtm_newaddr
interrupted. For me it could be e.g.:
after
vconfig add eth0 9
ip addr add dev eth0.9 ...
Whether eth0.9 is up or not does not affect this at all. The spin
locks are initialised (and used) when the first IPv4 address is added,
not when the device comes up.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote: On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote: Could you explain? I can see some inet_rtm_newaddr interrupted. For me it could be e.g.: after vconfig add eth0 9 ip addr add dev eth0.9 ... Whether eth0.9 is up or not does not affect this at all. The spin locks are initialised (and used) when the first IPv4 address is added, not when the device comes up. I understand this. I consider IFF_UP as a sign all initialisations (open functions including) are completed and there is permission for working (so logically, if I would do eth0.9 down all traffic should be stopped, what probably isn't true now). Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Wed, 3 Jan 2007 15:46:31 -0500, Paul Moore wrote: This makes me believe that Ingo's patch (which I see is now in Linus' and Andrew's trees) is the way to go and not the lock re-order approach in Adam's patch. I'm going to continue to look into this, almost more for my own education than anything else, but I thought I would mention this lock dependency message as it seemed relevant to the discussion. Both Ingo's patch and mine preserved the lock order, in a sense: take the read_read_lock first, and avoid locking the socket if possible. Ingo's patch avoided unlocking and relocking by using some facilities that I must admit my prior ignorance of. So, I agree that if both patches are correct, then Ingo's is better. I have been running Ingo's patch for the past ~1.5 days, and as far as I can tell it seems to be no worse than mine. The reason for such a guarded description as no worse than mine is that I have been experiencing occasoinal system hangs that started in 2.6.20-rc1 without any patch, which I have observed in 2.6.20-rc3 with my patch, and also 2.6.20-rc3 with Ingo's patch. These hangs may be completly unrelated to this selinux issue though and it may be days before get around to studying it more carefully, so I'm happy to see Ingo's patch integrated now. Adam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 00/10] Transparent proxying patches version 4
Hi, On Wednesday 03 January 2007 20:33, Lennert Buytenhek wrote: I'd also love to see the old tproxy API go away entirely. It was always a bit of a pain to use. It's gone with these patches: all you need is to bind() to foreign addresses, like in the Linux 2.2 days. -- Regards, Krisztian Kovacs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 00/10] Transparent proxying patches version 4
On Thu, Jan 04, 2007 at 01:13:27PM +0100, KOVACS Krisztian wrote: I'd also love to see the old tproxy API go away entirely. It was always a bit of a pain to use. It's gone with these patches: all you need is to bind() to foreign addresses, like in the Linux 2.2 days. That's how I understood it. Great. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] tcp: fix ambiguity in the `before' relation
| With the implementation now, the output of before(x,y) is reliable: it returns true | if (and only if) x is indeed `before' y. | | Sorry but I don't think you've answered my question. | | Let y = (x + 2^31) % 2^32, how is making | | before(x, y) == before(y, x) == 0 | | any better than | | before(x, y) == before(y, x) == 1 | | For an unambiguous before, we must have before(x, y) != before(y, x) | if x != y. I now see where you are coming from. This requirement * is fulfilled in both definitions as long as y != (x + 2^31) % 2^32 * does not hold in both definitions when y == (x + 2^31) % 2^32 The reason is in the underlying principle: due to sequence number wrapping, we are dealing with circular arithmetic, and in circular arithmetic the mid of the range is ambiguous (example: clock minute hands - 30 is as much `after' as it is `before'). This problematic case has been discussed before: RFC 1982 provides some background, and we had quite some discussion about similar issues (48 bit sequence numbers) on [EMAIL PROTECTED] So the short answer is - this kind of unambiguous `before' can not be implemented (see in particular also the notes in sec. 3.2 of RFC 1982). The key point where the new definition differs from the old is that _the relation_ before(x,y) is unambiguous: the case before(x,y) before(y,x) will no longer occur. | For a more concrete example, look at the code in tcp_ack: | | /* If the ack is newer than sent or older than previous acks | * then we can probably ignore it. | */ | if (after(ack, tp-snd_nxt)) | goto uninteresting_ack; | | if (before(ack, prior_snd_una)) | goto old_ack; | | Here we have two checks that weed out cases that we do not wish to | process. When all data have been acknowledged, we have | | snd_nxt == snd_una | | At this point, we only want the value of ack == snd_nxt == snd_una | to pass this check. With your change, the value snd_nxt + 2^31 can | also pass this check, which may have security implications. This is true: with the old definition it is at this point certain that ack == snd_nxt. The reason is that the code implicitly relies on the way `before' is defined. That has been the reason why this has been sent as an `RFC' patch: I am sure that the new definition is is in itself better, but was not sure how it would work with the existing code. With DCCP the case is different: it is a new protocol and an unambiguous `before' relation is beneficial, since this can increase the accuracy of detecting loss. Since there is likely more code which implicitly relies on the old definition, I will send a patch shortly. Many thanks, Gerrit - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tcp: revert to old definition of `before'
Hi Dave,
as per earlier email, can you please revert the definition of the
TCP `before' relation: there is code which implicitly depends on it.
Furthermore, this definition appears in textbooks such as Stevens
and therefore, even if the newer definition may have nicer properties,
it is safer to stick with the old one.
Patch -
[TCP]: Use old definition of before
This reverts the new (unambiguous) definition of the TCP `before'
relation. As pointed out in an example by Herbert Xu, there is
existing code which implicitly requires the old definition in order
to work correctly.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
diff --git a/include/net/tcp.h b/include/net/tcp.h
index b7d8317..cd8fa0c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -242,7 +242,7 @@ extern int tcp_memory_pressure;
static inline int before(__u32 seq1, __u32 seq2)
{
-return (__s32)(seq2-seq1) 0;
+return (__s32)(seq1-seq2) 0;
}
#define after(seq2, seq1) before(seq1, seq2)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] netfilter: ipt_MASQUERADE: NULL check in device_cmp [BUG] panic 2.6.20-rc3 in nf_conntrack
Hello, Below I attach a patch proposal. Regards, Jarek P. --- On 02-01-2007 06:40, Andrew Morton wrote: Begin forwarded message: Date: Mon, 1 Jan 2007 17:53:04 +0100 From: Malte Schröder [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Subject: [BUG] panic 2.6.20-rc3 in nf_conntrack Hello, I tried 2.6.20-rc3 with the new nf_nat stuff on my gateway machine with pppoe (ADSL) access to the internet. When I shut down my ppp0 interface the kernel panics. Config and dmesg are attached. This kernel had the ipp2p patch from patch-o-matic-ng applied, but the problem also happens without, so I didn't capture the panic without the patch. The machine is an athlon-xp with 512MiB ram. For iptables setup I use shorewall. Regards --- Malte Schröder [EMAIL PROTECTED] ICQ# 68121508 --- ... == ifdown ppp0 [ 330.789466] netconsole: network logging started [ 336.467373] BUG: unable to handle kernel NULL pointer dereference at virtual address 001c [ 336.467513] printing eip: [ 336.467566] dff1605f [ 336.467624] *pde = [ 336.467687] Oops: [#1] [ 336.467740] Modules linked in: netconsole rpcsec_gss_krb5 auth_rpcgss nfs xfrm_user xfrm4_tunnel tunnel4 ipcomp esp4 ah4 nfsd exportfs lockd nfs_acl sunrpc autofs4 button ac battery capi capifs nf_conntrack_ipv6 ip6table_filter ip6_tables xt_mark sch_sfq act_police cls_u32 sch_ingress sch_htb ipt_ECN ipt_MASQUERADE ipt_ULOG ipt_LOG xt_state ipt_TCPMSS xt_tcpudp xt_pkttype iptable_raw xt_CLASSIFY xt_CONNMARK xt_MARK ipt_REJECT xt_length ipt_ipp2p xt_connmark ipt_owner ipt_recent ipt_iprange xt_physdev xt_policy xt_multiport xt_conntrack iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink sit iptable_filter ip_tables x_tables af_packet ipv6 deflate twofish twofish_common serpent blowfish des cbc aes xcbc sha256 md5 crypto_null hmac crypto_hash af_key ext3 jbd mbcache dm_snapshot dm_mirror dm_mod lp sha1 arc4 ecb blkcipher cryptomgr crypto_algapi ppp_mppe ppp_defla te zlib_deflate capidrv isdn tun pppoe pppox ppp_generic slhc tcp_cubic snd_ac97_codec ac! 97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd parport_pc parport soundcore b1pci b1dma b1 kernelcapi floppy pcspkr reiserfs via_rhine ehci_hcd ide_disk uhci_hcd usbcore sata_via libata scsi_mod 3c59x mii thermal processor fan unix via82cxxx ide_core [ 336.476053] CPU:0 [ 336.476055] EIP:0060:[dff1605f]Not tainted VLI [ 336.476057] EFLAGS: 00010206 (2.6.20-rc3 #0) [ 336.476284] EIP is at device_cmp+0x1b/0x2e [ipt_MASQUERADE] [ 336.476344] eax: de6d4000 ebx: ecx: d944b7a0 edx: dd664d48 [ 336.476404] esi: 0004 edi: 1f58 ebp: 03eb esp: de6d4e90 [ 336.476464] ds: 007b es: 007b ss: 0068 [ 336.476520] Process pppd (pid: 3846, ti=de6d4000 task=deda4a90 task.ti=de6d4000) [ 336.476580] Stack: dd664c7c dd664c84 dfe8990d 0004 dff16044 dff16b18 c164b000 [ 336.477024]0002 dff16041 c011c79f c164b000 10d0 1091 c01ea41a [ 336.477527]c164b000 c01e99d5 d98b49e0 d98b4a0c ddc100c0 c022200b c164b000 [ 336.478030] Call Trace: [ 336.478132] [dfe8990d] nf_ct_iterate_cleanup+0x62/0xda [nf_conntrack] [ 336.478259] [dff16044] device_cmp+0x0/0x2e [ipt_MASQUERADE] [ 336.478366] [dff16041] masq_device_event+0x12/0x15 [ipt_MASQUERADE] [ 336.478468] [c011c79f] notifier_call_chain+0x19/0x29 [ 336.478576] [c01ea41a] dev_close+0x5c/0x60 [ 336.478678] [c01e99d5] dev_change_flags+0x47/0xe4 [ 336.478845] [c022200b] devinet_ioctl+0x251/0x56e [ 336.478946] [c01eaa6e] dev_ifsioc+0x113/0x3e1 [ 336.479046] [c018c505] copy_to_user+0x2d/0x44 [ 336.479176] [c01e12ec] sock_ioctl+0x18e/0x1ad [ 336.479281] [c01e115e] sock_ioctl+0x0/0x1ad [ 336.479381] [c0151011] do_ioctl+0x19/0x4d [ 336.479482] [c010f0ee] do_page_fault+0x277/0x511 [ 336.479589] [c0151244] vfs_ioctl+0x1ff/0x216 [ 336.479758] [c015128e] sys_ioctl+0x33/0x4d [ 336.479861] [c0102ab2] sysenter_past_esp+0x5f/0x85 [ 336.479980] === [ 336.480033] Code: 8b 51 40 b8 44 60 f1 df e8 6a 38 f7 ff 31 c0 c3 56 89 d6 8d 90 cc 00 00 00 53 31 db f6 80 8c 00 00 00 02 0f 45 da e8 4a 0a 20 e0 39 73 1c 0f 94 c0 0f b6 d8 e8 7a 08 20 e0 89 d8 5b 5e c3 55 31 [ 336.483030] EIP: [dff1605f] device_cmp+0x1b/0x2e [ipt_MASQUERADE] SS:ESP 0068:de6d4e90 [ 336.483183] 0Kernel panic - not syncing: Fatal exception in interrupt --- Subject: [PATCH] netfilter: ipt_MASQUERADE: NULL check in device_cmp nfct_nat can return NULL so check is needed in device_cmp. Signed-off-by: Jarek Poplawski [EMAIL PROTECTED] --- diff -Nurp linux-2.6.20-rc3-/net/ipv4/netfilter/ipt_MASQUERADE.c
Re: [PATCH] SMSC LAN911x and LAN921x vendor driver
Steve Glendinning wrote: Attached is a driver for SMSC's LAN911x and LAN921x families of embedded ethernet controllers. There is an existing smc911x driver in the tree; this is intended to replace it. This driver contains workarounds for all known hardware issues, and has been tested on all flavours of the chip on multiple architectures. Dustin McIntire (the author of the smc911x driver) has expressed his support for switching to this driver. Signed-off-by: Steve Glendinning [EMAIL PROTECTED] This patch has just been tested on my Freescale mx31 board, with a smsc9117, and Linux version 2.6.16.19. I agree to include it in mainstream. old smc911x is restricted to one architecture (PXA) and one chip (9118). Acked-by: Pierre Tardy [EMAIL PROTECTED] -- Pierre Tardy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] natsemi cable length woes
Here's a proposed patch that addresses a problem with natsemi
NICs and long cables we've been chasing (*sigh*).
I'm interested in feedback on how to fix this sanely.
Olaf
--
From: Olaf Kirch [EMAIL PROTECTED]
Subject: natsemi: make cable length magic configurable
We had a customer report concerning problems with a Natsemi DP83815-D
and long cables. With 100m cables, the network would be essentially dead,
not a single packet would get through either way. We had to apply the
patch below to make it work.
The patch adds a module parameter named no_cable_magic that does
two things:
- Unconditionally set the DSPCFG register to the
fixed value. Without this change, the chip apparently
never completes autonegotiation in the tested configuration.
This has been an unconditional assignment for a long time,
until this was changed in 2.6.11 (there's an interesting
explanation in the ChangeLog, bk commit is
5871b81bf2b5cf188deab0d414dce104fcb69ca6)
- skip the bit banging in {,un}do_cable_magic. It seems that
if we write the DSPCFG register as above, a rev D chip will report
all cables as short cables, which do_cable_magic detects, and
trying to be helpful it will fix the attenuation coefficient.
I admit the use of a module parameter is ugly, but I didn't find a sane
way to fix this - especially since the magic registers we're changing
are kind of underdocumented.
Signed-off-by: Olaf Kirch [EMAIL PROTECTED]
drivers/net/natsemi.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
Index: linux-2.6.19/drivers/net/natsemi.c
===
--- linux-2.6.19.orig/drivers/net/natsemi.c
+++ linux-2.6.19/drivers/net/natsemi.c
@@ -72,6 +72,7 @@
static int debug = -1;
static int mtu;
+static int no_cable_magic;
/* Maximum number of multicast addresses to filter (vs. rx-all-multicast).
This chip uses a 512 element hash table based on the Ethernet CRC. */
@@ -139,6 +140,7 @@ MODULE_LICENSE(GPL);
module_param(mtu, int, 0);
module_param(debug, int, 0);
module_param(rx_copybreak, int, 0);
+module_param(no_cable_magic, int, 0);
module_param_array(options, int, NULL, 0);
module_param_array(full_duplex, int, NULL, 0);
MODULE_PARM_DESC(mtu, DP8381x MTU (all boards));
@@ -148,6 +150,9 @@ MODULE_PARM_DESC(rx_copybreak,
MODULE_PARM_DESC(options,
DP8381x: Bits 0-3: media type, bit 17: full duplex);
MODULE_PARM_DESC(full_duplex, DP8381x full duplex setting(s) (1));
+MODULE_PARM_DESC(no_cable_magic,
+ DP8381x: set no_cable_magic=1 to disable magic workaround for short
cables
+ (may help with long cables:-));
/*
Theory of Operation
@@ -1147,7 +1152,7 @@ static void init_phy_fixup(struct net_de
writew(1, ioaddr + PGSEL);
writew(PMDCSR_VAL, ioaddr + PMDCSR);
writew(TSTDAT_VAL, ioaddr + TSTDAT);
- np-dspcfg = (np-srr = SRR_DP83815_C)?
+ np-dspcfg = (np-srr = SRR_DP83815_C || no_cable_magic)?
DSPCFG_VAL : (DSPCFG_COEF | readw(ioaddr + DSPCFG));
writew(np-dspcfg, ioaddr + DSPCFG);
writew(SDCFG_VAL, ioaddr + SDCFG);
@@ -1511,7 +1516,7 @@ static void do_cable_magic(struct net_de
if (dev-if_port != PORT_TP)
return;
- if (np-srr = SRR_DP83816_A5)
+ if (np-srr = SRR_DP83816_A5 || no_cable_magic)
return;
/*
@@ -1556,7 +1561,7 @@ static void undo_cable_magic(struct net_
if (dev-if_port != PORT_TP)
return;
- if (np-srr = SRR_DP83816_A5)
+ if (np-srr = SRR_DP83816_A5 || no_cable_magic)
return;
writew(1, ioaddr + PGSEL);
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] problem with BPF in PF_PACKET sockets, introduced in linux-2.6.19
Hello, I believe I have found a bug in PF_PACKET socket filtering (introduced in linux-2.6.19). If BPF returns values larger than 0x8000u, run_filter in af_packet.c considers that as error instead of simply accepting packet in its full length. sk_filter does not have this problem. Raivis Bucis Index: linux-2.6.19/net/packet/af_packet.c === --- linux-2.6.19/net/packet/af_packet.c +++ linux-2.6.19/net/packet/af_packet.c @@ -447,6 +447,8 @@ err = -EPERM; else if (*snaplen err) *snaplen = err; + else + err = *snaplen; } rcu_read_unlock_bh(); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
Jarek Poplawski wrote: On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote: On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote: Could you explain? I can see some inet_rtm_newaddr interrupted. For me it could be e.g.: after vconfig add eth0 9 ip addr add dev eth0.9 ... Whether eth0.9 is up or not does not affect this at all. The spin locks are initialised (and used) when the first IPv4 address is added, not when the device comes up. I understand this. I consider IFF_UP as a sign all initialisations (open functions including) are completed and there is permission for working (so logically, if I would do eth0.9 down all traffic should be stopped, what probably isn't true now). It is certainly valid for an interface to be IF_UP, but have no IP address. My application does bring the network device up before it assigns the IP, for instance. There may be other issues with IF_UP, but that could be handled with a different investigation. If you have a particular test case that fails with 802.1Q VLANs, then I will be happy to work on it... Thanks, Ben Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7770] New: Network connection randomly drops
On Thu, 4 Jan 2007 08:49:49 -0800 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7770 Summary: Network connection randomly drops Kernel Version: 2.6.19 onward Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.19-rc4 Distribution: ubuntu 6.10, 64 bit Hardware Environment: ASUS M2N-E (MCP55), AMD X2 4200+ Software Environment: normal linux distro with a custom kernel Problem Description: It started when I compiled the stable 2.6.19 kernel (first after rc4). The network connection to the router just dropped and I can find no reason why it is so. I have to revive the connection via /etc/init.d/networking restart command and the connection is there again. At first I was doing remote connection (tsclient in ubuntu) on another ubuntu dapper machine. The connection would randomly terminate. I assumed it was the program, but then I did a further test. I used mc (midnight commander) to copy some large files (a couple ubuntu iso-s) to this machine (which acts as a file server) via NFS (and via router) and back. The connection would drop! The event is more frequent if I transfer the files from that computer than vice versa. I then rerun linux with 2.6.19-rc4 kernel and transfers were stable without a single connection drop. I then assumed it should be the newer forcedeth driver to blame but apparently it isn't. I put the 0.57 driver into the 2.6.20-rc3 and the problem persists. I even tried this patch from the bug #7684 but this didn't help either. Steps to reproduce: Hopefully with this hardware I mentioned, plain ubuntu 6.10 64 bit installation with a kernel higher than 2.6.19-rc4. Config and other status files are in the attachment. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fixes for d80211 hwmode API change
These attached patches are a simplified version of Michael Buesch's original
hwmode API patches to adm8211, p54, and zd1211rw-d80211. These will be
necessary once you pull up2 from Jiri Benc's tree.
Thanks,
-Michael Wu
adm8211: Fix compilation for d80211 hwmode API change
From: Michael Wu [EMAIL PROTECTED]
This fixes compilation for the d80211 hwmode API change.
Based on a patch by Michael Buesch [EMAIL PROTECTED].
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c |8 ++--
drivers/net/wireless/d80211/adm8211/adm8211.h |2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c b/drivers/net/wireless/d80211/adm8211/adm8211.c
index d7fb484..3bdcec3 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2035,8 +2035,6 @@ static int __devinit adm8211_probe(struc
dev-channel_change_time = 1000;
dev-maxssi = ADM8211_RX_MAX_SSI;// FIXME - This is an approximation
- dev-num_modes = 1;
- dev-modes = priv-modes;
priv-modes[0].mode = MODE_IEEE80211B;
/* channel info filled in by adm8211_read_eeprom */
memcpy(priv-rates, adm8211_rates, sizeof(adm8211_rates));
@@ -2069,6 +2067,12 @@ static int __devinit adm8211_probe(struc
priv-channel = priv-modes[0].channels[0].chan;
+ err = ieee80211_register_hwmode(dev, priv-modes[0]);
+ if (err) {
+ printk(KERN_ERR %s (adm8211): Cannot register hwmode\n, pci_name(pdev));
+ goto err_free_desc;
+ }
+
err = ieee80211_register_hw(dev);
if (err) {
printk(KERN_ERR %s (adm8211): Cannot register hardware\n, pci_name(pdev));
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.h b/drivers/net/wireless/d80211/adm8211/adm8211.h
index 06c54bc..dc7902f 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.h
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.h
@@ -532,7 +532,7 @@ struct adm8211_priv {
unsigned cur_tx, dirty_tx, cur_rx;
struct ieee80211_low_level_stats stats;
- struct ieee80211_hw_modes modes[1];
+ struct ieee80211_hw_mode modes[1];
struct ieee80211_rate rates[ARRAY_SIZE(adm8211_rates)];
int mode;
p54: Fix compilation for d80211 hwmode API change
From: Michael Wu [EMAIL PROTECTED]
This fixes compilation for the d80211 hwmode API change.
Based on a patch by Michael Buesch [EMAIL PROTECTED].
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/p54/prism54.h |2 +-
drivers/net/wireless/d80211/p54/prism54common.c | 11 ---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/d80211/p54/prism54.h b/drivers/net/wireless/d80211/p54/prism54.h
index 5e4f331..de8197e 100644
--- a/drivers/net/wireless/d80211/p54/prism54.h
+++ b/drivers/net/wireless/d80211/p54/prism54.h
@@ -63,7 +63,7 @@ struct p54_common {
/* FIXME: this channels/modes/rates stuff sucks */
struct ieee80211_channel channels[14];
struct ieee80211_rate rates[12];
- struct ieee80211_hw_modes modes[2];
+ struct ieee80211_hw_mode modes[2];
};
int p54_rx(struct ieee80211_hw *dev, struct sk_buff *skb);
diff --git a/drivers/net/wireless/d80211/p54/prism54common.c b/drivers/net/wireless/d80211/p54/prism54common.c
index 185cd53..2e19bf4 100644
--- a/drivers/net/wireless/d80211/p54/prism54common.c
+++ b/drivers/net/wireless/d80211/p54/prism54common.c
@@ -745,6 +745,7 @@ struct ieee80211_hw *p54_init_common(siz
{
struct ieee80211_hw *dev;
struct p54_common *priv;
+ int i;
dev = ieee80211_alloc_hw(priv_data_len, p54_ops);
if (!dev)
@@ -774,13 +775,17 @@ struct ieee80211_hw *p54_init_common(siz
dev-channel_change_time = 1000; /* TODO: find actual value */
dev-maxssi = 100; // just to avoid dividing by zero
- dev-num_modes = 2;
- dev-modes = priv-modes;
-
dev-queues = 1;
dev-extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
sizeof(struct p54_tx_control_allocdata);
+ for (i = 0; i 2; i++) {
+ if (ieee80211_register_hwmode(dev, priv-modes[i])) {
+ ieee80211_free_hw(dev);
+ return NULL;
+ }
+ }
+
return dev;
}
EXPORT_SYMBOL_GPL(p54_init_common);
zd1211rw-d80211: Fix compilation for d80211 hwmode API change
From: Michael Wu [EMAIL PROTECTED]
This fixes compilation for the d80211 hwmode API change.
Based on a patch by Michael Buesch [EMAIL PROTECTED].
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/zd1211rw/zd_mac.c | 12 +---
drivers/net/wireless/d80211/zd1211rw/zd_mac.h |2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
index 6ee650f..35c90fb 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
@@ -574,6 +574,7 @@ struct ieee80211_hw *zd_mac_alloc(struct
{
struct zd_mac *mac;
struct ieee80211_hw *dev;
+ int i;
dev = ieee80211_alloc_hw(sizeof(struct zd_mac),
Re: [PATCH] fib6: Fix fn-leaf == NULL race when inserting new nodes in fib6 tree
* Thomas Graf [EMAIL PROTECTED] 2007-01-04 10:39 When inserting new nodes into a fib6 tree, the leaf pointer is first to NULL and later corrected when the key gets assigned. However, the tree is not locked for this period of time, therefore nodes with an invalid leaf pointer are accessible. Lookups that occur during this period of time expect a valid leaf pointer and thus crash. This patch sets the leaf pointer to ip6_null_entry during this critical period of time. Ignore this patch for now, the description is certainly inaccurate even though it seems to fix the issue. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sungem: PHY updates pause fixes
On 1/4/07, David Miller [EMAIL PROTECTED] wrote: I've applied that patch, thanks. David, I suppose you've applied the locking patch as well... -- Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fib6: Fix fn-leaf == NULL race when inserting new nodes in fib6 tree
From: Thomas Graf [EMAIL PROTECTED] Date: Thu, 4 Jan 2007 20:21:47 +0100 * Thomas Graf [EMAIL PROTECTED] 2007-01-04 10:39 When inserting new nodes into a fib6 tree, the leaf pointer is first to NULL and later corrected when the key gets assigned. However, the tree is not locked for this period of time, therefore nodes with an invalid leaf pointer are accessible. Lookups that occur during this period of time expect a valid leaf pointer and thus crash. This patch sets the leaf pointer to ip6_null_entry during this critical period of time. Ignore this patch for now, the description is certainly inaccurate even though it seems to fix the issue. Ok, no problem. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcp: revert to old definition of `before'
From: Gerrit Renker [EMAIL PROTECTED] Date: Thu, 4 Jan 2007 12:54:54 + Hi Dave, as per earlier email, can you please revert the definition of the TCP `before' relation: there is code which implicitly depends on it. Furthermore, this definition appears in textbooks such as Stevens and therefore, even if the newer definition may have nicer properties, it is safer to stick with the old one. No problem, patch applied, thanks Gerrit. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sungem: PHY updates pause fixes
From: Eric Lemoine [EMAIL PROTECTED] Date: Thu, 4 Jan 2007 21:06:48 +0100 On 1/4/07, David Miller [EMAIL PROTECTED] wrote: I've applied that patch, thanks. David, I suppose you've applied the locking patch as well... No, not yet. Your locking patches are definitely 2.6.21 material, but Ben's changes fix PAUSE handling bugs so I want to put his patch into 2.6.20 I'll put your locking bits into 2.6.21, don't worry :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
From: Herbert Xu [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 17:26:27 +1100
David Stevens [EMAIL PROTECTED] wrote:
You're right, I don't know whether it'll fix the problem Ben saw
or not, but it looks like the original code can do a receive before the
in_device is fully initialized, and that, of course, is bad.
If the device for ip_rcv() is not the same one we were
initializing when the receive interrupted, then the patch should have
no effect either way -- I don't think it'll hide other problems.
If it's hard to reproduce (which I guess is true), then you're
right, no soft lockup doesn't really tell us if it's fixed or not.
Actually I missed your point that the multicast locks aren't even
initialised at that point. So this does explain the soft lock-up
and therefore your patch is clearly the correct solution.
I agree too, therefore I've added David's patch as below.
I'll push this to the -stable branches as well. This fix is
correct even if it does not entirely clear up the soft lockup
bug being discussed in this thread, but I think it will :-)
commit 30c4cf577fb5b68c16e5750d6bdbd7072e42b279
Author: David L Stevens [EMAIL PROTECTED]
Date: Thu Jan 4 12:31:14 2007 -0800
[IPV4/IPV6]: Fix inet{,6} device initialization order.
It is important that we only assign dev-ip{,6}_ptr
only after all portions of the inet{,6} are setup.
Otherwise we can receive packets before the multicast
spinlocks et al. are initialized.
Signed-off-by: David L Stevens [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 84bed40..25c8a42 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -165,9 +165,8 @@ struct in_device *inetdev_init(struct net_device *dev)
NET_IPV4_NEIGH, ipv4, NULL, NULL);
#endif
- /* Account for reference dev-ip_ptr */
+ /* Account for reference dev-ip_ptr (below) */
in_dev_hold(in_dev);
- rcu_assign_pointer(dev-ip_ptr, in_dev);
#ifdef CONFIG_SYSCTL
devinet_sysctl_register(in_dev, in_dev-cnf);
@@ -176,6 +175,8 @@ struct in_device *inetdev_init(struct net_device *dev)
if (dev-flags IFF_UP)
ip_mc_up(in_dev);
out:
+ /* we can receive as soon as ip_ptr is set -- do this last */
+ rcu_assign_pointer(dev-ip_ptr, in_dev);
return in_dev;
out_kfree:
kfree(in_dev);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 9b0a906..171e5b5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -413,8 +413,6 @@ static struct inet6_dev * ipv6_add_dev(struct net_device
*dev)
if (netif_carrier_ok(dev))
ndev-if_flags |= IF_READY;
- /* protected by rtnl_lock */
- rcu_assign_pointer(dev-ip6_ptr, ndev);
ipv6_mc_init_dev(ndev);
ndev-tstamp = jiffies;
@@ -425,6 +423,8 @@ static struct inet6_dev * ipv6_add_dev(struct net_device
*dev)
NULL);
addrconf_sysctl_register(ndev, ndev-cnf);
#endif
+ /* protected by rtnl_lock */
+ rcu_assign_pointer(dev-ip6_ptr, ndev);
return ndev;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sungem: PHY updates pause fixes
On 1/4/07, David Miller [EMAIL PROTECTED] wrote: From: Eric Lemoine [EMAIL PROTECTED] Date: Thu, 4 Jan 2007 21:06:48 +0100 On 1/4/07, David Miller [EMAIL PROTECTED] wrote: I've applied that patch, thanks. David, I suppose you've applied the locking patch as well... No, not yet. Your locking patches are definitely 2.6.21 material, but Ben's changes fix PAUSE handling bugs so I want to put his patch into 2.6.20 I'll put your locking bits into 2.6.21, don't worry :-) I'm relieved now :-) I was asking because Ben said his patch applied on top of mine. -- Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sungem: PHY updates pause fixes
On Thu, 2007-01-04 at 21:57 +0100, Eric Lemoine wrote: On 1/4/07, David Miller [EMAIL PROTECTED] wrote: From: Eric Lemoine [EMAIL PROTECTED] Date: Thu, 4 Jan 2007 21:06:48 +0100 On 1/4/07, David Miller [EMAIL PROTECTED] wrote: I've applied that patch, thanks. David, I suppose you've applied the locking patch as well... No, not yet. Your locking patches are definitely 2.6.21 material, but Ben's changes fix PAUSE handling bugs so I want to put his patch into 2.6.20 I'll put your locking bits into 2.6.21, don't worry :-) I'm relieved now :-) I was asking because Ben said his patch applied on top of mine. Well, I did it with yours applied already but it seems like they don't really conflict so they can be applied pretty much in any order. Ben. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Davicom Ethernet (onboard) with many Tx timeouts...
On Wed, 3 Jan 2007 22:33:08 -0200 Dâniel Fraga [EMAIL PROTECTED] wrote: Jan 3 22:10:13 belforts vmunix: eth0: Tx timeout - resetting Solved by forcing 10Mbps full duplex, using options dmfe mode=4 in /etc/modprobe.conf. -- http://u-br.net Linux 2.6.19: Avast! A bilge rat! Sao Paulo - SP - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] INET: fix incorrect inet_sock-is_icsk assignment
From: Paul Moore [EMAIL PROTECTED] Date: Thu, 04 Jan 2007 15:04:31 -0500 From: Paul Moore [EMAIL PROTECTED] The inet_create() and inet6_create() functions incorrectly set the inet_sock-is_icsk field. Both functions assume that the is_icsk field is large enough to hold at least a INET_PROTOSW_ICSK value when it is actually only a single bit. This patch corrects the assignment by doing a boolean comparison whose result will safely fit into a single bit field. Signed-off-by: Paul Moore [EMAIL PROTECTED] Applied, thanks a lot Paul. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] INET: fix incorrect inet_sock-is_icsk assignment
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Paul Moore [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 15:04:31 -0500
From: Paul Moore [EMAIL PROTECTED]
The inet_create() and inet6_create() functions incorrectly set the
inet_sock-is_icsk field. Both functions assume that the is_icsk field is
large enough to hold at least a INET_PROTOSW_ICSK value when it is actually
only a single bit. This patch corrects the assignment by doing a boolean
comparison whose result will safely fit into a single bit field.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Applied, thanks a lot Paul.
Well spotted, gcc let me down on this one:
[EMAIL PROTECTED] ~]$ cat a.c
#include stdio.h
struct foo { int a_bit:1; };
int main(void) {
int trickme = 0x04;
struct foo oof;
oof.a_bit = trickme 4;
printf(%u\n, oof.a_bit);
}
[EMAIL PROTECTED] ~]$ make a
cc a.c -o a
[EMAIL PROTECTED] ~]$ ./a
0
[EMAIL PROTECTED] ~]$
But...
[EMAIL PROTECTED] ~]$ cat a.c
#include stdio.h
struct foo { int a_bit:1; };
int main(void) {
struct foo oof;
oof.a_bit = 0x04;
printf(%u\n, oof.a_bit);
}
[EMAIL PROTECTED] ~]$ make a
cc a.c -o a
a.c: In function 'main':
a.c:8: warning: overflow in implicit constant conversion
[EMAIL PROTECTED] ~]$
I expected a warning since the and operation clearly could yield a
value that would overflow, just like in the constant case...
Anyway, thanks a lot Paul!
- Arnaldo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] tcp: fix ambiguity in the `before' relation
On Thu, Jan 04, 2007 at 12:49:02PM +, Gerrit Renker wrote:
The key point where the new definition differs from the old is that _the
relation_
before(x,y) is unambiguous: the case before(x,y) before(y,x) will no
longer occur.
This is highly dependent on how the before macro is used in actual code.
There is nothing to suggest that this change won't create new security
holes in DCCP or any other protocol that uses this macro. The only
way to be sure is to audit every single use.
So I think we need to do one of two things:
1) Audit every single before/after check to ensure that it works
correctly with the new definition.
2) Change before/after such that before(x, x+2^31) == !before(x+2^31, x).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] INET: fix incorrect inet_sock-is_icsk assignment
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED] Date: Fri, 5 Jan 2007 00:32:31 -0200 I expected a warning since the and operation clearly could yield a value that would overflow, just like in the constant case... It sounds stupid, but once you introduce variables and not everything is constance, GCC currently can't make the analysis. It's an interesting class of bugs to detect automatically, for sure :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
egress path understanding
Hi all,
(sorry for newbie question)
I'm trying to learn the networking code of an ancient 2.4.18 vanilla kernel.
I understand that the egress path of network packet (socket buffer) as
general behaviour, goes through the method hard_start_xmit() within of
the driver layer. This method is the responsible of putting the
network packet into the output buffers of the network device. When the
physical transmmission is completed the device raises an interrupt and
the interrupt handler of the device is called.
The typical interrupt handler is a function running in interrupt
context, so needs to be as quick as possible, and because this
function has to free the skb buffer (to deallocate the sk_buff
structure associated with sucessfully transmitted buffer), the task is
delegated to softirq (NET_TX_SOFTIRQ) by means of function
dev_kfree_skb_irq():
static inline void dev_kfree_skb_irq(struct sk_buff *skb)
{
if (atomic_dec_and_test(skb-users)) {
int cpu =smp_processor_id();
unsigned long flags;
#ifdef CONFIG_PROC_FS
softirq_stats.raise_from_kfree_skb_cont++;
#endif
local_irq_save(flags);
skb-next = softnet_data[cpu].completion_queue;
softnet_data[cpu].completion_queue = skb;
cpu_raise_softirq(cpu, NET_TX_SOFTIRQ);
local_irq_restore(flags);
}
}
When do_softirq() is called the funcion associated with
NET_TX_SOFTIRQ, net_tx_action() is called:
static void net_tx_action(struct softirq_action *h)
{
int cpu = smp_processor_id();
if (softnet_data[cpu].completion_queue) {
struct sk_buff *clist;
local_irq_disable();
clist = softnet_data[cpu].completion_queue;
softnet_data[cpu].completion_queue = NULL;
local_irq_enable();
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist-next;
#ifdef CONFIG_PROC_FS
softirq_stats.tx_completion_cont++;
#endif
BUG_TRAP(atomic_read(skb-users) == 0);
__kfree_skb(skb);
}
}
. [snip]
}
How you can see, I have put some counters in order to trace the
execution of networking code by means of the file:
/proc/net/softirq_stat. The oputput of this file is the following when
I test the kernel:
# cat /proc/net/softirq_stat
raise_from_netif_cont: 0
raise_from_kfree_skb_cont: 0
(qdisc_restart) hard_start_xmit_cont: 5869
(qdisc_restart) xmit_lock_grabbed_cont: 0
tx_completion_cont: 5869
tx_output_cont: 142
OK, the important fields of this output are tx_completion_cont and
raise_from_kfree_skb_cont. We can see that every packet passed to
hard_start_xmit_cont (in qdisc_restart) is freed with net_tx_action,
so the counter hard_start_xmit_cont and tx_completion_cont show the
same values. But I cannot understand why the counter
raise_from_kfree_skb_cont is zero!!!
I guess the code path must pass through of dev_kfree_skb_irq() in
order to raise the softirq with cpu_raise_softirq(cpu,
NET_TX_SOFTIRQ), so it's possible to execute net_tx_action() later.
I don't know if I don't understand the therory or I have an error in
the code. Please can anybody advice me about this behaviour?
Thanks a lot, and sorry for my english.
--
Javi Roman
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: soft lockup detected on CPU#0! (2.6.18.2 plus hacks)
On Thu, Jan 04, 2007 at 12:33:33PM -0800, David Miller wrote: From: Herbert Xu [EMAIL PROTECTED] Date: Thu, 04 Jan 2007 17:26:27 +1100 David Stevens [EMAIL PROTECTED] wrote: You're right, I don't know whether it'll fix the problem Ben saw or not, but it looks like the original code can do a receive before the in_device is fully initialized, and that, of course, is bad. If the device for ip_rcv() is not the same one we were initializing when the receive interrupted, then the patch should have no effect either way -- I don't think it'll hide other problems. If it's hard to reproduce (which I guess is true), then you're right, no soft lockup doesn't really tell us if it's fixed or not. Actually I missed your point that the multicast locks aren't even initialised at that point. So this does explain the soft lock-up and therefore your patch is clearly the correct solution. I agree too, therefore I've added David's patch as below. I'll push this to the -stable branches as well. This fix is correct even if it does not entirely clear up the soft lockup bug being discussed in this thread, but I think it will :-) After rethinking I came to similar conclusion. I've thought the changes are done only to fix this particular bug but now I see the previous order wasn't right particularly considering RCU. So, I apologize to David L Stevens for my harsh words. I'd only suggest to change goto out; to return NULL; at the end of inetdev_init because now RCU is engaged unnecessarily. Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] X.25: Trivial, SOCK_DEBUG's in x25_facilities missing newlines
On Thu, 04 Jan 2007 15:39:24 +1100 ahendry [EMAIL PROTECTED] wrote: Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation. Signed-off-by: Andrew Hendry [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.19 1/2] X.25: Adds call forwarding to X.25
+ struct sk_buff *skbn; + skbn = skb_clone(skb, GFP_ATOMIC); + If this fails then you starting passing NULL around. I'm also a bit confused as to where you free the copy in all the error cases ? Is there any reason for creating skbn here rather than in skb_forward_call ? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Wed, Jan 03, 2007 at 04:53:58PM +, Sid Boyce wrote: ... It seems =2.6.19 and the SuSEfirewall are incompatible. Actually, many programs could be incomapatible with newer kernel versions, so sometimes upgrades or at least recompilations are needed. ... There is still the problem where the ethernet doesn't get configured with acpi=off which I shall post to the acpi devel list, but this is not a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS: I don't know acpi enough but as far as I know some mainboards can't work properly with acpi off, so it's probably not a bug. Cheers, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
Hi, I made a patch below. With this patch, the ftp-transfer-stop problem does not happen. Therefore, I think this is not a problem of vsftpd. Mr.YOSHIFUJI san, why did you set TCPOLEN_TSTAMP_ALIGNED to iov_len? --- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig 2007-01-03 11:50:04.0 +0900 +++ linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c2007-01-03 15:30:44.0 +0900 @@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_t TCPOLEN_TIMESTAMP); rep.opt[1] = htonl(tcp_time_stamp); rep.opt[2] = htonl(ts); - arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED; + arg.iov[0].iov_len = sizeof(rep); } /* Swap the send and the receive. */ Best Regards Komuro - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC
On Wed, Jan 03, 2007 at 11:16:59PM +, Jon Maloy wrote: See my comments below. Regards ///jon Jarek Poplawski wrote: .. Maybe I misinterpret this but, IMHO lockdep complains about locks acquired in different order: tipc_ref_acquire() gets ref_table_lock and then tipc_ret_table.entries[index]-lock, but tipc_deleteport() inversely (with: tipc_port_lock() and tipc_ref_discard()). I hope maintainers will decide the correct order. This order is correct. There can never be parallel access to the same _instance_ of tipc_ret_table.entries[index]-lock from the two functions you mention. Note that tipc_deleteport() takes as argument the reference (=index) returned from tipc_ref_acquire(), so it can not be (and is not) called until and unless the latter function has returned a valid reference. As a parallel, you can't do free() on a memory chunk until malloc() has given you a pointer to it. I'm happy the order is correct! But the warning probably will be back. I know lockdep is sometimes too careful but nevertheless some change is needed to fix a real bug or give additional information to lockdep. Btw. there is a problem with tipc_ref_discard(): it should be called with tipc_port_lock, but how to discard a ref if this lock can't be acquired? Is it OK to call it without the lock like in subscr_named_msg_event()? I suspect you are mixing up things here. We are handling two different reference entries and two different locks in this function. One reference entry points to a subscription instance, and its reference (index) is obtainable from subscriber-ref. So, we could easily lock the entry if needed. However, in this particular case it is unnecessary, since there is no chance that anybody else could have obtained the new reference, and hence no risk for race conditions. The other reference entry was intended to point to a new port, but, since we didn't obtain any reference in the first place, there is no port to delete and no reference to discard. I admit I don't know this program and I hope I didn't mislead anybody with my message. I only tried to point at some doubts and maybe this function could be better commented about when the lock is needed. Thanks for explanations best regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/13] Linux RDMA Core Changes
On Thu, 2007-01-04 at 07:07 +0200, Michael S. Tsirkin wrote: If you think I should not add the udata parameter to the req_notify_cq() provider verb, then I can rework the chelsio driver: 1) at cq creation time, pass the virtual address of the u32 used by the library to track the current cq index. That way the chelsio kernel driver can save the address in its kernel cq context for later use. 2) change chelsio's req_notify_cq() to copy in the current cq index value directly for rearming. This puts all the burden on the chelsio driver, which is apparently the only one that needs this functionality. Good thinking, I haven't thought of this approach. This way there won't be any API/core changes and no changes to other low level drivers, correct? And for chelsio, there's no overhead as compared to code you posted. Sounds good. I still want to hear from Roland on this before I go to the effort of reworking all this... Steve. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC
Regards ///jon Jarek Poplawski wrote: I know lockdep is sometimes too careful but nevertheless some change is needed to fix a real bug or give additional information to lockdep. I don't know lockdep well enough yet, but I will try to find out if that is possible. Btw. there is a problem with tipc_ref_discard(): it should be called with tipc_port_lock, but how to discard a ref if this lock can't be acquired? Is it OK to call it without the lock like in subscr_named_msg_event()? I suspect you are mixing up things here. We are handling two different reference entries and two different locks in this function. One reference entry points to a subscription instance, and its reference (index) is obtainable from subscriber-ref. So, we could easily lock the entry if needed. However, in this particular case it is unnecessary, since there is no chance that anybody else could have obtained the new reference, and hence no risk for race conditions. The other reference entry was intended to point to a new port, but, since we didn't obtain any reference in the first place, there is no port to delete and no reference to discard. I admit I don't know this program and I hope I didn't mislead anybody with my message. I only tried to point at some doubts and maybe this function could be better commented about when the lock is needed. Agreed. Thanks for explanations best regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC: 2.6 patch] remove the broken OAKNET driver
The OAKNET driver:
- has been marked as BROKEN for more than two years and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
present in the older kernel releases.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/Kconfig | 10
drivers/net/Makefile |2
drivers/net/oaknet.c | 666 ---
3 files changed, 678 deletions(-)
--- linux-2.6.20-rc2-mm1/drivers/net/Kconfig.old2007-01-04
17:59:09.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/net/Kconfig2007-01-04 17:59:21.0
+0100
@@ -235,16 +235,6 @@
To compile this driver as a module, choose M here: the module
will be called bmac.
-config OAKNET
- tristate National DP83902AV (Oak ethernet) support
- depends on NET_ETHERNET PPC BROKEN
- select CRC32
- help
- Say Y if your machine has this type of Ethernet network card.
-
- To compile this driver as a module, choose M here: the module
- will be called oaknet.
-
config ARIADNE
tristate Ariadne support
depends on NET_ETHERNET ZORRO
--- linux-2.6.20-rc2-mm1/drivers/net/Makefile.old 2007-01-04
17:59:30.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/net/Makefile 2007-01-04 17:59:35.0
+0100
@@ -37,8 +37,6 @@
obj-$(CONFIG_MACE) += mace.o
obj-$(CONFIG_BMAC) += bmac.o
-obj-$(CONFIG_OAKNET) += oaknet.o 8390.o
-
obj-$(CONFIG_DGRS) += dgrs.o
obj-$(CONFIG_VORTEX) += 3c59x.o
obj-$(CONFIG_TYPHOON) += typhoon.o
--- linux-2.6.20-rc2-mm1/drivers/net/oaknet.c 2006-11-29 22:57:37.0
+0100
+++ /dev/null 2006-09-19 00:45:31.0 +0200
@@ -1,666 +0,0 @@
-/*
- *
- *Copyright (c) 1999-2000 Grant Erickson [EMAIL PROTECTED]
- *
- *Module name: oaknet.c
- *
- *Description:
- * Driver for the National Semiconductor DP83902AV Ethernet controller
- * on-board the IBM PowerPC Oak evaluation board. Adapted from the
- * various other 8390 drivers written by Donald Becker and Paul Gortmaker.
- *
- * Additional inspiration from the tcd8390.c driver from TiVo, Inc.
- * and enetLib.c from IBM.
- *
- */
-
-#include linux/module.h
-#include linux/errno.h
-#include linux/delay.h
-#include linux/netdevice.h
-#include linux/etherdevice.h
-#include linux/init.h
-#include linux/jiffies.h
-
-#include asm/board.h
-#include asm/io.h
-
-#include 8390.h
-
-
-/* Preprocessor Defines */
-
-#if !defined(TRUE) || TRUE != 1
-#defineTRUE1
-#endif
-
-#if !defined(FALSE) || FALSE != 0
-#defineFALSE 0
-#endif
-
-#defineOAKNET_START_PG 0x20/* First page of TX buffer */
-#defineOAKNET_STOP_PG 0x40/* Last pagge +1 of RX ring */
-
-#defineOAKNET_WAIT (2 * HZ / 100) /* 20 ms */
-
-/* Experimenting with some fixes for a broken driver... */
-
-#defineOAKNET_DISINT
-#defineOAKNET_HEADCHECK
-#defineOAKNET_RWFIX
-
-
-/* Global Variables */
-
-static const char *name = National DP83902AV;
-
-static struct net_device *oaknet_devs;
-
-
-/* Function Prototypes */
-
-static int oaknet_open(struct net_device *dev);
-static int oaknet_close(struct net_device *dev);
-
-static void oaknet_reset_8390(struct net_device *dev);
-static void oaknet_get_8390_hdr(struct net_device *dev,
-struct e8390_pkt_hdr *hdr, int ring_page);
-static void oaknet_block_input(struct net_device *dev, int count,
- struct sk_buff *skb, int ring_offset);
-static void oaknet_block_output(struct net_device *dev, int count,
-const unsigned char *buf, int start_page);
-
-static void oaknet_dma_error(struct net_device *dev, const char *name);
-
-
-/*
- * int oaknet_init()
- *
- * Description:
- * This routine performs all the necessary platform-specific initiali-
- * zation and set-up for the IBM Oak evaluation board's National
- * Semiconductor DP83902AV ST-NIC Ethernet controller.
- *
- * Input(s):
- * N/A
- *
- * Output(s):
- * N/A
- *
- * Returns:
- * 0 if OK, otherwise system error number on error.
- *
- */
-static int __init oaknet_init(void)
-{
- register int i;
- int reg0, regd;
- int ret = -ENOMEM;
- struct net_device *dev;
-#if 0
- unsigned long ioaddr = OAKNET_IO_BASE;
-#else
- unsigned long ioaddr = ioremap(OAKNET_IO_BASE, OAKNET_IO_SIZE);
-#endif
- bd_t *bip = (bd_t *)__res;
-
- if (!ioaddr)
- return -ENOMEM;
-
- dev = alloc_ei_netdev();
- if (!dev)
- goto out_unmap;
-
- ret = -EBUSY;
- if (!request_region(OAKNET_IO_BASE, OAKNET_IO_SIZE, name))
- goto out_dev;
-
- /* Quick register check to see if the device is really there.
Re: [openib-general] [PATCH v4 01/13] Linux RDMA Core Changes
OK, I'm back from vacation today. Anyway I don't have a definitive statement on this right now. I guess I agree that I don't like having an extra parameter to a function that should be pretty fast (although req notify isn't quite as hot as something like posting a send request or polling a cq), given that it adds measurable overhead. (And I am surprised that the overhead is measurable, since 3 arguments still fit in registers, but OK). I also agree that adding an extra entry point just to pass in the user data is ugly, and also racy. Giving the kernel driver a pointer it can read seems OK I guess, although it's a little ugly to have a backdoor channel like that. I'm somewhat surprised the driver has to go into the kernel to rearm a CQ -- what makes the operation need kernel privileges? (Sorry for not reading the code) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [openib-general] [PATCH v4 01/13] Linux RDMA Core Changes
On Thu, 2007-01-04 at 13:34 -0800, Roland Dreier wrote: OK, I'm back from vacation today. Anyway I don't have a definitive statement on this right now. I guess I agree that I don't like having an extra parameter to a function that should be pretty fast (although req notify isn't quite as hot as something like posting a send request or polling a cq), given that it adds measurable overhead. (And I am surprised that the overhead is measurable, since 3 arguments still fit in registers, but OK). I also agree that adding an extra entry point just to pass in the user data is ugly, and also racy. Giving the kernel driver a pointer it can read seems OK I guess, although it's a little ugly to have a backdoor channel like that. I'm somewhat surprised the driver has to go into the kernel to rearm a CQ -- what makes the operation need kernel privileges? (Sorry for not reading the code) - Rearming the CQ requires reading and writing to a global adapter register that is shared and thus needs to be protected. They didn't architect the rearm to be a direct user operation. Steve. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] OOPS with nf_conntrack_ipv6, probably fragmented UDPv6
On Thu, 04 Jan 2007 17:58:23 +0100 Bernhard Schmidt [EMAIL PROTECTED] wrote: Hi, I've hit another kernel oops with 2.6.20-rc3 on i386 platform. It is reproducible, as soon as I load nf_conntrack_ipv6 and try to send something large (scp or so) inside an OpenVPN tunnel on my client (patched with UDPv6 transport) the router (another box) OOPSes. tcpdump suggests the problem appears as soon as my client sends fragmented UDPv6 packets towards the destination. It does not happen when nf_conntrack_ipv6 is not loaded. This is the OOPS as dumped from the serial console: heimdall login: Oops: [#1] Modules linked in: sit sch_red sch_htb pppoe pppox ppp_generic slhc xt_CLASSIFY ipt_TOS xt_length ipt_tos ipt_TCPMSS xt_tcpudp ipt_MASQUERADE xt_state iptable_mangle iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 ip_tables x_tables nf_conntrack_ipv6 nf_conntrack nfnetlink CPU:0 EIP:0060:[0001]Not tainted VLI EFLAGS: 00010246 (2.6.20-rc3 #2) EIP is at 0x1 eax: cd215bc0 ebx: cd1f3160 ecx: cc59002a edx: cd215bc0 esi: cd215bc0 edi: cd215bc0 ebp: esp: c030bd3c ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, ti=c030a000 task=c02e93a0 task.ti=c030a000) Stack: c0212cc4 0004 cc83f160 cd2130c0 cd215bc0 cd2130c0 cd215bc0 c021734b c030bdb4 c0307a60 000a cceee800 cceee800 cd215bc0 cd1f3160 c021896b c0307a60 cd215bc0 cd215bc0 cceee800 cd1f3160 c025f1c6 Call Trace: [c0212cc4] __kfree_skb+0x84/0xe0 [c021734b] dev_hard_start_xmit+0x1bb/0x1d0 [c021896b] dev_queue_xmit+0x11b/0x1b0 [c025f1c6] ip6_output2+0x276/0x2b0 [c025ed30] ip6_output_finish+0x0/0xf0 [c025fc0a] ip6_output+0x90a/0x940 [c013e9e5] cache_alloc_refill+0x2c5/0x3f0 [c0212eed] pskb_expand_head+0xdd/0x130 [c02608d5] ip6_forward+0x465/0x4b0 [c02618c6] ip6_rcv_finish+0x16/0x30 [ce81a056] nf_ct_frag6_output+0x86/0xb0 [nf_conntrack_ipv6] [c02618b0] ip6_rcv_finish+0x0/0x30 [ce81911b] ipv6_defrag+0x3b/0x50 [nf_conntrack_ipv6] [c02618b0] ip6_rcv_finish+0x0/0x30 [c022c618] nf_iterate+0x38/0x70 [c02618b0] ip6_rcv_finish+0x0/0x30 [c022c75d] nf_hook_slow+0x4d/0xc0 [c02618b0] ip6_rcv_finish+0x0/0x30 [c0261ac0] ipv6_rcv+0x1e0/0x250 [c02618b0] ip6_rcv_finish+0x0/0x30 [c0217068] netif_receive_skb+0x1a8/0x200 [c021868e] process_backlog+0x6e/0xe0 [c0218752] net_rx_action+0x52/0xd0 [c0113885] __do_softirq+0x35/0x80 [c01138f2] do_softirq+0x22/0x30 [c010453e] do_IRQ+0x5e/0x70 [c0102b33] common_interrupt+0x23/0x30 [c0101820] default_idle+0x0/0x40 [c0101847] default_idle+0x27/0x40 [c0101017] cpu_idle+0x37/0x50 [c030c676] start_kernel+0x266/0x270 [c030c200] unknown_bootoption+0x0/0x210 === Code: Bad EIP value. EIP: [0001] 0x1 SS:ESP 0068:c030bd3c 0Kernel panic - not syncing: Fatal exception in interrupt 0Rebooting in 20 seconds..4atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. At a guess I'd say that skb-nfct-destroy has value 0x0001. Not a good function address. Presumably it is suppsoed to be zero... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] X.25: Trivial, SOCK_DEBUG's in x25_facilities missing newlines
From: ahendry [EMAIL PROTECTED] Date: Thu, 04 Jan 2007 15:39:24 +1100 Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation. Signed-off-by: Andrew Hendry [EMAIL PROTECTED] Applied, thanks Andrew. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC
On Thu, Jan 04, 2007 at 04:16:20PM +, Jon Maloy wrote:
Regards
///jon
Jarek Poplawski wrote:
I know lockdep is sometimes
too careful but nevertheless some change is needed
to fix a real bug or give additional information
to lockdep.
I don't know lockdep well enough yet, but I will try to find out if that
is possible.
If you are sure there is no circular locking possible
between these two functions and this entry-lock here
isn't endangered by other functions, you could try to
make lockdep silent like this:
write_lock_bh(ref_table_lock);
if (tipc_ref_table.first_free) {
index = tipc_ref_table.first_free;
entry = (tipc_ref_table.entries[index]);
index_mask = tipc_ref_table.index_mask;
/* take lock in case a previous user of entry still holds it */
-spin_lock_bh(entry-lock, );
+ local_bh_disable();
+ spin_lock_nested(entry-lock, SINGLE_DEPTH_NESTING);
next_plus_upper = entry-data.next_plus_upper;
tipc_ref_table.first_free = next_plus_upper index_mask;
reference = (next_plus_upper ~index_mask) + index;
entry-data.reference = reference;
entry-object = object;
if (lock != 0)
*lock = entry-lock;
/* may stay as is or: */
-spin_unlock_bh(entry-lock);
+ spin_unlock(entry-lock);
+ local_bh_enable();
}
write_unlock_bh(ref_table_lock);
Cheers,
Jarek P.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc3: known unfixed regressions (v3)
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl [EMAIL PROTECTED]
Damien Wyart [EMAIL PROTECTED]
Aaron Sethman [EMAIL PROTECTED]
Status : unknown
Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel [EMAIL PROTECTED]
Status : unknown
Subject: USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha [EMAIL PROTECTED]
Status : unknown
Subject: SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?)
References : http://lkml.org/lkml/2006/12/13/181
http://lkml.org/lkml/2007/01/04/75
Submitter : Horst H. von Brand [EMAIL PROTECTED]
Status : unknown
Subject: ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro [EMAIL PROTECTED]
Caused-By : YOSHIFUJI Hideaki [EMAIL PROTECTED]
commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki [EMAIL PROTECTED]
Status : problem is being debugged
Subject: x86_64 boot failure: IO-APIC + timer doesn't work
References : http://lkml.org/lkml/2006/12/16/101
http://lkml.org/lkml/2007/1/3/9
Submitter : Tobias Diedrich [EMAIL PROTECTED]
Caused-By : Andi Kleen [EMAIL PROTECTED]
commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu [EMAIL PROTECTED]
Eric W. Biederman [EMAIL PROTECTED]
Status : patches are being discussed
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
