* Re: FW: r8169 auto-negotiation problem
From: Francois Romieu @ 2008-02-03 18:45 UTC (permalink / raw)
To: fgnijuhhu guduggurehug; +Cc: netdev
In-Reply-To: <BAY107-W4033FF1A4417D61C5177FD5310@phx.gbl>
fgnijuhhu guduggurehug <jsmiths1234@live.com> :
[...]
> I already posted my problem and what I did to solve it on
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
Have you tried anything more recent than a 2.6.18 based kernel ?
--
Ueimor
^ permalink raw reply
* FW: [Patch 2.6.24 1/3]S2io: Support for vlan_rx_kill_vid entry point
From: Ramkrishna Vepa @ 2008-02-03 21:03 UTC (permalink / raw)
To: David Miller; +Cc: Jeff Garzik, Sreenivasa Honnur, netdev
The patches failed because they were applied on the 2.6.25 branch, while
they were meant for the 2.6.24 branch (upstream-linus).
Ram
> -----Original Message-----
> From: Ramkrishna Vepa
> Sent: Friday, February 01, 2008 11:01 AM
> To: 'Jeff Garzik'; Sreenivasa Honnur
> Cc: support
> Subject: RE: [Patch 2.6.24 1/3]S2io: Support for vlan_rx_kill_vid
entry
> point
>
> > Sreenivasa Honnur wrote:
> > > - Added s2io_vlan_rx_kill_vid entry point function for
unregistering
> > vlan.
> > > - Fix to aggregate vlan packets. IP offset is incremented by
> > > 4 bytes if the packet contains vlan header.
> > >
> > > Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
> > > Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
> >
> > applied 1-2, patch #3 failed to apply
> [Ram] This sequence of patches were meant for 2.6.24 (upstream-linus)
and
> patch #3 was only a version update -
> -#define DRV_VERSION "2.0.26.17"
> +#define DRV_VERSION "2.0.26.18"
> I just checked upstream-linus and the version is still 2.0.26.17. Any
idea
> why the patch failed?
>
> Thanks,
> Ram
^ permalink raw reply
* Re: xfrm_input() and ->seq oddities
From: Herbert Xu @ 2008-02-03 22:00 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev
In-Reply-To: <20080203110444.GR27894@ZenIV.linux.org.uk>
On Sun, Feb 03, 2008 at 11:04:44AM +0000, Al Viro wrote:
>
> So what you are saying is
> * callers of xfrm_input_resume() are in callbacks that couldn't
> have been set other than from esp_input()/esp6_input()
> * these two could have only been called via ->type->input()
> * ->type->input() is called from xfrm_input(), immediately after
> having set ->seq.input, *or* from xfrm6_input_addr(). The former is safe.
> * xfrm6_input_addr() calls ->type->input() of object it gets from
> xfrm_state_lookup_byaddr(). The protocol number passed to the latter comes
> from xfrm6_input_addr() argument.
> * the protocol numbers given to xfrm6_input_addr() by its callers
> are IPPROTO_DSTOPTS and IPPROTO_ROUTING resp; ->input() instances in their
> xfrm_type do *not* set callbacks that could lead to xfrm_input_resume(),
> so we are safe.
This doesn't look so bad if you take out the xfrm6_input_addr call.
And you can't blame that one on me :)
The xfrm6_input_addr function is really a parallel universe which has
nothing to do with IPsec. It's used by Mobile IPv6 just because it
happened to fit in the same schema.
In other words, IPsec transforms such as ESP cannot be called from
xfrm6_input_addr and as such async resumption never occurs with
xfrm6_input_addr.
> IMO that at least deserves a comment near xfrm_input()...
Sure. There is already a comment about encap_type < 0 in there, but
I think you'll probably be able to explain it much better than I can
looking in from the outside so if you have a patch... :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 7/8] kernel-doc: fix network header warnings
From: Randy.Dunlap @ 2008-02-03 23:06 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Add missing structure kernel-doc descriptions to sock.h & skbuff.h
to fix kernel-doc warnings.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/linux/skbuff.h | 2 ++
include/net/sock.h | 1 +
2 files changed, 3 insertions(+)
--- linux-2.6.24-git12.orig/include/linux/skbuff.h
+++ linux-2.6.24-git12/include/linux/skbuff.h
@@ -232,6 +232,8 @@ typedef unsigned char *sk_buff_data_t;
* @mark: Generic packet mark
* @nfct: Associated connection, if any
* @ipvs_property: skbuff is owned by ipvs
+ * @peeked: this packet has been seen already, so stats have been
+ * done for it, don't do them again
* @nf_trace: netfilter packet trace flag
* @nfctinfo: Relationship of this skb to the connection
* @nfct_reasm: netfilter conntrack re-assembly pointer
--- linux-2.6.24-git12.orig/include/net/sock.h
+++ linux-2.6.24-git12/include/net/sock.h
@@ -180,6 +180,7 @@ struct sock_common {
* @sk_sndmsg_off: cached offset for sendmsg
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
+ * @sk_mark: generic packet mark
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
^ permalink raw reply
* [PATCH 8/8] kernel-doc: fix sunrpc warnings
From: Randy.Dunlap @ 2008-02-03 23:07 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Use updated file list for docbook files and
fix kernel-doc warnings in sunrpc:
Warning(linux-2.6.24-git12//net/sunrpc/rpc_pipe.c:689): No description found for parameter 'rpc_client'
Warning(linux-2.6.24-git12//net/sunrpc/rpc_pipe.c:765): No description found for parameter 'flags'
Warning(linux-2.6.24-git12//net/sunrpc/clnt.c:584): No description found for parameter 'tk_ops'
Warning(linux-2.6.24-git12//net/sunrpc/clnt.c:618): No description found for parameter 'bufsize'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Documentation/DocBook/kernel-api.tmpl | 8 +++++++-
net/sunrpc/clnt.c | 10 +++++-----
net/sunrpc/rpc_pipe.c | 3 ++-
net/sunrpc/xprt.c | 2 +-
4 files changed, 15 insertions(+), 8 deletions(-)
--- linux-2.6.24-git12.orig/Documentation/DocBook/kernel-api.tmpl
+++ linux-2.6.24-git12/Documentation/DocBook/kernel-api.tmpl
@@ -230,8 +230,14 @@ X!Ilib/string.c
!Dnet/sunrpc/sunrpc_syms.c
-->
!Enet/sunrpc/xdr.c
-!Enet/sunrpc/svcsock.c
+!Enet/sunrpc/svc_xprt.c
+!Enet/sunrpc/xprt.c
!Enet/sunrpc/sched.c
+!Enet/sunrpc/socklib.c
+!Enet/sunrpc/stats.c
+!Enet/sunrpc/rpc_pipe.c
+!Enet/sunrpc/rpcb_clnt.c
+!Enet/sunrpc/clnt.c
</sect1>
</chapter>
--- linux-2.6.24-git12.orig/net/sunrpc/clnt.c
+++ linux-2.6.24-git12/net/sunrpc/clnt.c
@@ -464,9 +464,9 @@ rpc_release_client(struct rpc_clnt *clnt
/**
* rpc_bind_new_program - bind a new RPC program to an existing client
- * @old - old rpc_client
- * @program - rpc program to set
- * @vers - rpc program version
+ * @old: old rpc_client
+ * @program: rpc program to set
+ * @vers: rpc program version
*
* Clones the rpc client and sets up a new RPC program. This is mainly
* of use for enabling different RPC programs to share the same transport.
@@ -575,7 +575,7 @@ EXPORT_SYMBOL_GPL(rpc_call_sync);
* @clnt: pointer to RPC client
* @msg: RPC call parameters
* @flags: RPC call flags
- * @ops: RPC call ops
+ * @tk_ops: RPC call ops
* @data: user call data
*/
int
@@ -610,7 +610,7 @@ EXPORT_SYMBOL_GPL(rpc_call_start);
* rpc_peeraddr - extract remote peer address from clnt's xprt
* @clnt: RPC client structure
* @buf: target buffer
- * @size: length of target buffer
+ * @bufsize: length of target buffer
*
* Returns the number of bytes that are actually in the stored address.
*/
--- linux-2.6.24-git12.orig/net/sunrpc/xprt.c
+++ linux-2.6.24-git12/net/sunrpc/xprt.c
@@ -124,7 +124,7 @@ EXPORT_SYMBOL_GPL(xprt_register_transpor
/**
* xprt_unregister_transport - unregister a transport implementation
- * transport: transport to unregister
+ * @transport: transport to unregister
*
* Returns:
* 0: transport successfully unregistered
--- linux-2.6.24-git12.orig/net/sunrpc/rpc_pipe.c
+++ linux-2.6.24-git12/net/sunrpc/rpc_pipe.c
@@ -677,7 +677,7 @@ rpc_lookup_negative(char *path, struct n
/**
* rpc_mkdir - Create a new directory in rpc_pipefs
* @path: path from the rpc_pipefs root to the new directory
- * @rpc_clnt: rpc client to associate with this directory
+ * @rpc_client: rpc client to associate with this directory
*
* This creates a directory at the given @path associated with
* @rpc_clnt, which will contain a file named "info" with some basic
@@ -748,6 +748,7 @@ rpc_rmdir(struct dentry *dentry)
* @private: private data to associate with the pipe, for the caller's use
* @ops: operations defining the behavior of the pipe: upcall, downcall,
* release_pipe, and destroy_msg.
+ * @flags: rpc_inode flags
*
* Data is made available for userspace to read by calls to
* rpc_queue_upcall(). The actual reads will result in calls to
^ permalink raw reply
* Re: locking api self-test hanging
From: Andrew Morton @ 2008-02-03 23:07 UTC (permalink / raw)
To: netdev; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <20080203150246.50647fa4.akpm@linux-foundation.org>
On Sun, 3 Feb 2008 15:02:46 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> With current mainline I'm getting intermittent hangs here:
>
> http://userweb.kernel.org/~akpm/p2033590.jpg
>
> with this config:
>
> http://userweb.kernel.org/~akpm/config-sony.txt
>
> on the Vaio. Sometimes it boots (then hits another different hang),
> sometimes it gets stuck there.
>
The second hang is in kobject_uevent_init(). All that function does is call
netlink_kernel_create().
These things make bisecting all the other bugs rather hard.
^ permalink raw reply
* Re: [PATCH] request_irq() always returns -EINVAL with a NULL handler.
From: Rusty Russell @ 2008-02-04 5:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeff Garzik, netdev, linux-kernel
In-Reply-To: <20080202221502.76d48ead.akpm@linux-foundation.org>
On Sunday 03 February 2008 17:15:02 Andrew Morton wrote:
> On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <rusty@rustcorp.com.au>
wrote:
> > I assume that these ancient network drivers were trying to find out if
> > an irq is available. eepro.c expecting +EBUSY was doubly wrong.
> >
> > I'm not sure that can_request_irq() is the right thing, but these drivers
> > are definitely wrong.
> >
> > request_irq should BUG() on bad input, and these would have been found
> > earlier.
>
> This breaks non-CONFIG_GENERIC_HARDIRQS architectures.
>
> alpha:
>
> drivers/net/3c503.c: In function 'el2_open':
> drivers/net/3c503.c:382: error: implicit declaration of function
> 'can_request_irq'
Since this code was non-functional before, should we just be removing
the "check if irq is free" check altogether?
This is Jeff's call, I think.
Rusty.
^ permalink raw reply
* radvd 1.1 released
From: Pekka Savola @ 2008-02-04 6:55 UTC (permalink / raw)
To: netdev, radvd-announce-l; +Cc: radvd-devel-l
Hi,
A new version of radvd has been released. There have been a couple of
new features.
Interfaces must now be RUNNING, not just UP, to be considered by
default radvd configuration. This is because nowadays kernels no
longer generate v6 link-local addresses if the interface is just UP,
in contrast to e.g., what earlier kernels did.
I'd like issue special thanks to Jim Paris for all the patches he has
sent :-).
Get it at: http://www.litech.org/radvd/
Changes since 1.0:
* Implement privilege separation on Linux: a master root process
(which is able to reconfigure interfaces) and the main process. There
is '-s' toggle to keep old behaviour.
* Fix Linux retrans_timer on old kernels (newer ones have
retrans_timer_ms)
* Fix stderr+syslog (default) logging on non-i386 platforms.
* Require that interface must be RUNNING instead of just UP. Note:
this could break deployments with very old kernels.
* Implement automatic interface address advertising with special
prefix ::/64.
* Relax interface naming (e.g. with VLANs) requirements.
* Fix ordering of route, prefix and RDNSS options (only matters
with RDNSS)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* [NET]: Remove further references to net-modules.txt
From: Johann Felix Soden @ 2008-02-04 7:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, trivial
From: Johann Felix Soden <johfel@users.sourceforge.net>
The Kconfig of igb and enc28j60 contains references to
obsolet Documentation/networking/net-modules.txt.
Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net>
---
drivers/net/Kconfig | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 389980f..87f503b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -919,8 +919,7 @@ config ENC28J60
---help---
Support for the Microchip EN28J60 ethernet chip.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
+ To compile this driver as a module, choose M here. The module will be
called enc28j60.
config ENC28J60_WRITEVERIFY
@@ -2040,8 +2039,7 @@ config IGB
More specific information on configuring the driver is in
<file:Documentation/networking/e1000.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called igb.
source "drivers/net/ixp2000/Kconfig"
--
1.5.4
^ permalink raw reply related
* [PATCH][INET]: Fix accidentally broken inet(6)_hash_connect's port offset calculations.
From: Pavel Emelyanov @ 2008-02-04 8:10 UTC (permalink / raw)
To: David Miller; +Cc: Adrian Bunk, Linux Netdev List, devel
The port offset calculations depend on the protocol family, but,
as Adrian noticed, I broke this logic with the commit
5ee31fc1ecdcbc234c8c56dcacef87c8e09909d8
[INET]: Consolidate inet(6)_hash_connect.
Return this logic back, by passing the port offset directly into
the consolidated function.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Noticed-by: Adrian Bunk <bunk@kernel.org>
---
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 48ac620..97dc35a 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -389,7 +389,7 @@ static inline struct sock *inet_lookup(struct net *net,
}
extern int __inet_hash_connect(struct inet_timewait_death_row *death_row,
- struct sock *sk,
+ struct sock *sk, u32 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
struct sock *, __u16, struct inet_timewait_sock **),
void (*hash)(struct sock *sk));
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 90f422c..9cac6c0 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -398,7 +398,7 @@ out:
EXPORT_SYMBOL_GPL(inet_unhash);
int __inet_hash_connect(struct inet_timewait_death_row *death_row,
- struct sock *sk,
+ struct sock *sk, u32 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
struct sock *, __u16, struct inet_timewait_sock **),
void (*hash)(struct sock *sk))
@@ -413,7 +413,7 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row,
if (!snum) {
int i, remaining, low, high, port;
static u32 hint;
- u32 offset = hint + inet_sk_port_offset(sk);
+ u32 offset = hint + port_offset;
struct hlist_node *node;
struct inet_timewait_sock *tw = NULL;
@@ -502,7 +502,7 @@ EXPORT_SYMBOL_GPL(__inet_hash_connect);
int inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk)
{
- return __inet_hash_connect(death_row, sk,
+ return __inet_hash_connect(death_row, sk, inet_sk_port_offset(sk),
__inet_check_established, __inet_hash_nolisten);
}
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 43f3993..99fd25f 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -236,7 +236,7 @@ static inline u32 inet6_sk_port_offset(const struct sock *sk)
int inet6_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk)
{
- return __inet_hash_connect(death_row, sk,
+ return __inet_hash_connect(death_row, sk, inet6_sk_port_offset(sk),
__inet6_check_established, __inet6_hash);
}
^ permalink raw reply related
* Re: LRO ip_summed
From: Jan-Bernd Themann @ 2008-02-04 9:14 UTC (permalink / raw)
To: Kostya B; +Cc: netdev
In-Reply-To: <BAY121-W366A043ECDC160494B1EFAB6320@phx.gbl>
On Sunday 03 February 2008 10:48, Kostya B wrote:
>
> Hi,
>
> The mail is related to the way LRO manipulates the ip_summed value. Could anybody (author) explain why to overwrite the original value of skb->ip_summed, when it's processing by __lro_proc_skb ?
> E.g. in out: label
>
> Why not to preserve the coherency of csum status of each incoming to LRO packet, the same way the IP defragmentation does? That means - all skb in descriptor have the same value of ip_summed.
>
Hi,
I'm not sure if I understand your proposal correctly.
Currently the driver decides via the struct net_lro_mgr
a) which ip_summed value will be used for all aggregated packets
b) which one to use for those packets that can not be aggregated
to a) this one should always be the same. The driver knows whether its HW is
capable of performing ip checksum checking for this kind of traffic (TCP)
There are two modes: aggregating SKBs or aggregating fragments.
When fragments are aggregated, there is no SKB with a filled ip_summed available.
Please outline which parts of which mode you suggest to change.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: oops with ipcomp
From: Beschorner Daniel @ 2008-02-04 9:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20080202044254.GA27792@gondor.apana.org.au>
>> Unable to handle kernel paging request at ffffc200000fb000 RIP:
>> [<ffffffff8031b8f0>] deflate_slow+0x40/0x400
> I'm not able to get much information out of this crash dump. Nor
> can I reproduce this bug on my 32-bit machines and I'm currently
> away from my 64-bit machines.
> How long have you been using IPComp in the past and what was the
> last kernel version which was stable with IPComp?
I've never seen this with kernels < 2.6.24 after many years of
ipsec/ipcomp usage.
I got it 18 hours after boot, since the oops it runs stable for further
72 hours.
But I cross the fingers that it was an unique issue, I'll report if it
oopses again.
Daniel
^ permalink raw reply
* include/linux/pcounter.h
From: Andrew Morton @ 2008-02-04 9:44 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: netdev, linux-kernel
e7d0362dd41e760f340c1b500646cc92522bd9d5 should have been folded into
de4d1db369785c29d68915edfee0cb70e8199f4c prior to merging. We now and for
ever have a window of breakage which screws up git bisection. Which I
just hit. Which is the only reason I discovered the file's existence.
Please do not merge pieces of generic kernel infrastructure while keeping
it all secret on the netdev list. Ever. That code has a number of deficiencies
which I and probably others would have noted had it been offered to us
for review.
^ permalink raw reply
* oops with ipcomp
From: Beschorner Daniel @ 2008-02-04 10:39 UTC (permalink / raw)
To: netdev; +Cc: Herbert Xu
Nope! Right now it happened again, something must have changed with
2.6.24.
Unable to handle kernel paging request at ffffc200000fb000 RIP:
[<ffffffff8031b8f0>] deflate_slow+0x40/0x400
PGD 7f845067 PUD 7f846067 PMD 7f847067 PTE 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in:
Pid: 11055, comm: httpd Not tainted 2.6.24 #2
RIP: 0010:[<ffffffff8031b8f0>] [<ffffffff8031b8f0>]
deflate_slow+0x40/0x400
RSP: 0018:ffff810039525938 EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffffc200000b9000 RCX: 00000000000408d8
RDX: ffffc200000ba728 RSI: 0000000000000000 RDI: 0000000000006aa3
RBP: 00000000000008d4 R08: 0000000000003c8b R09: 0000000000001800
R10: 0000000000000010 R11: ffffc200000b94bc R12: 000000000000007d
R13: 0000000000000005 R14: 0000000000000000 R15: ffffc20000097000
FS: 00002b16cc187190(0000) GS:ffffffff805a8000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc200000fb000 CR3: 000000007c69a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process httpd (pid: 11055, threadinfo ffff810039524000, task
ffff81007f8e6140)
Stack: ffff81007c4aae10 ffff81007ead4400 0000000000000005
ffffc200000b9000
ffff81006c186000 ffffffff8031c25d 0000000000000000 ffff81007ead4400
ffff81007ead43c0 ffff81006c1860a8 0000000000000109 ffffffff802ff351
Call Trace:
[<ffffffff8031c25d>] zlib_deflate+0x10d/0x330
[<ffffffff802ff351>] deflate_compress+0x91/0xb0
[<ffffffff804771b8>] ipcomp_output+0x98/0x1e0
[<ffffffff80489ef6>] xfrm_output+0x116/0x1e0
[<ffffffff80482dc4>] xfrm4_output_finish2+0x44/0x1e0
[<ffffffff80483075>] xfrm4_output+0x55/0x60
[<ffffffff80445989>] ip_queue_xmit+0x209/0x450
[<ffffffff8049b0d0>] thread_return+0x3d/0x54d
[<ffffffff8023b094>] lock_timer_base+0x34/0x70
[<ffffffff80456dcf>] tcp_transmit_skb+0x40f/0x7c0
[<ffffffff80458aae>] __tcp_push_pending_frames+0x11e/0x940
[<ffffffff8044cb8e>] tcp_sendmsg+0x81e/0xc40
[<ffffffff80291e3f>] dput+0x1f/0x130
[<ffffffff80410b01>] sock_aio_write+0x111/0x120
[<ffffffff804109f0>] sock_aio_write+0x0/0x120
[<ffffffff8027f95b>] do_sync_readv_writev+0xcb/0x110
[<ffffffff80246850>] autoremove_wake_function+0x0/0x30
[<ffffffff8027fb99>] do_sync_read+0xd9/0x120
[<ffffffff80287941>] permission+0x61/0x100
[<ffffffff8027f7bd>] rw_copy_check_uvector+0x9d/0x130
[<ffffffff802800a2>] do_readv_writev+0xe2/0x210
[<ffffffff8027e1ba>] do_filp_open+0x3a/0x50
[<ffffffff802806e3>] sys_writev+0x53/0x90
[<ffffffff8020bb3e>] system_call+0x7e/0x83
Code: 0f b6 14 0a 31 d0 23 43 74 48 8b 53 60 89 43 68 89 c0 0f b7
RIP [<ffffffff8031b8f0>] deflate_slow+0x40/0x400
RSP <ffff810039525938>
CR2: ffffc200000fb000
---[ end trace 0ff90cd2723f4b1e ]---
^ permalink raw reply
* Re: [PATCH][NET_SCHED] sch_tree_lock in cbq_put, hfsc_put_class and htb_put
From: Jarek Poplawski @ 2008-02-04 11:57 UTC (permalink / raw)
To: David Miller; +Cc: Stephen Hemminger, jamal, Patrick McHardy, netdev
In-Reply-To: <20080203145234.GA3170@ami.dom.local>
This patch is wrong - don't apply, please!
Sorry,
Jarek P.
On 03-02-2008 15:52, Jarek Poplawski wrote:
> [NET_SCHED] sch_tree_lock in cbq_put, hfsc_put_class and htb_put
>
> Qdisc_class_ops ->put() "methods" call xxx_destroy_class() functions
> without sch_tree_lock(), which is needed at least for qdisc_destroy()
> of a subqueue, but also for deactivating and list/rb_tree updates in
> case of HTB. (Since errors caused by such a bug could be very hard to
> reproduce the effectiveness of this patch wasn't confirmed by tests,
> but IMHO the need of this lock is quite obvious here.)
>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
...
^ permalink raw reply
* Re: locking api self-test hanging
From: Andrew Morton @ 2008-02-04 12:43 UTC (permalink / raw)
To: netdev, Ingo Molnar, linux-kernel; +Cc: Stephen Hemminger
In-Reply-To: <20080203150744.cf7d0415.akpm@linux-foundation.org>
On Sun, 3 Feb 2008 15:07:44 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 3 Feb 2008 15:02:46 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> >
> > With current mainline I'm getting intermittent hangs here:
> >
> > http://userweb.kernel.org/~akpm/p2033590.jpg
> >
> > with this config:
> >
> > http://userweb.kernel.org/~akpm/config-sony.txt
> >
> > on the Vaio. Sometimes it boots (then hits another different hang),
> > sometimes it gets stuck there.
CONFIG_DEBUG_LOCKING_API_SELFTESTS=n fixed that up.
>
> The second hang is in kobject_uevent_init(). All that function does is call
> netlink_kernel_create().
And I've fully bisected this hang twice and both times came up with
commit 33f807ba0d9259e7c75c7a2ce8bd2787e5b540c7
Author: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon Nov 19 19:24:52 2007 -0800
[NETPOLL]: Kill NETPOLL_RX_DROP, set but never tested.
which is stupid because that patch doesn't do anything.
However I am using netconsole-over-e100 and the hang does go away when I
disable netconsole on the kernel boot command line.
I'd say it's some timing thing in netpoll/netconsole/napi/etc.
^ permalink raw reply
* Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?
From: Matti Aarnio @ 2008-02-04 13:02 UTC (permalink / raw)
To: linux-hams; +Cc: netdev
In-Reply-To: <20080203202819.GX2537@mea-ext.zmailer.org>
.. the original reason was apparently that _ifconfig_ blew up
when it saw protocols that it didn't understand on network
interfaces. Possibly when there was no IP protocol on an
interface.
This happened on DECNET, and apparently on others too.
Thus the SIOCGIFCONF ioctl is not returning much else
than interfaces with IP addresses on them, and to get
_all_ interfaces, one must read thru /proc/net/dev file.
Some reason like that is possibly behind the reason why
SIOCGIFCONF does not find anything but PF_INET sockets
even when it is run on PF_AX25 type socket..
The "fun" part is that ifconfig does look for all devices
in /proc/net/dev. Perhaps we should just make all devices
findable with SIOCGIFCONF regardless of what protocols
they may support ? And if the ifconfig blows up, the
bug is in ifconfig tool, not kernel.
Alternatively one could iterate all network devices of
protocol family X being enabled when ioctl() is called
on socket with PF_x (like PF_AX25.)
Can anyone recall any real reason why this would not be
acceptable ?
/Matti Aarnio
^ permalink raw reply
* Re: locking api self-test hanging
From: Andrew Morton @ 2008-02-04 13:04 UTC (permalink / raw)
To: netdev, Ingo Molnar, linux-kernel, Stephen Hemminger,
Bernhard Walle
In-Reply-To: <20080204044304.d244e761.akpm@linux-foundation.org>
On Mon, 4 Feb 2008 04:43:04 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 3 Feb 2008 15:07:44 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Sun, 3 Feb 2008 15:02:46 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > >
> > > With current mainline I'm getting intermittent hangs here:
> > >
> > > http://userweb.kernel.org/~akpm/p2033590.jpg
> > >
> > > with this config:
> > >
> > > http://userweb.kernel.org/~akpm/config-sony.txt
> > >
> > > on the Vaio. Sometimes it boots (then hits another different hang),
> > > sometimes it gets stuck there.
>
> CONFIG_DEBUG_LOCKING_API_SELFTESTS=n fixed that up.
>
> >
> > The second hang is in kobject_uevent_init(). All that function does is call
> > netlink_kernel_create().
>
> And I've fully bisected this hang twice and both times came up with
>
> commit 33f807ba0d9259e7c75c7a2ce8bd2787e5b540c7
> Author: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon Nov 19 19:24:52 2007 -0800
>
> [NETPOLL]: Kill NETPOLL_RX_DROP, set but never tested.
>
> which is stupid because that patch doesn't do anything.
>
> However I am using netconsole-over-e100 and the hang does go away when I
> disable netconsole on the kernel boot command line.
>
After disabling both CONFIG_DEBUG_LOCKING_API_SELFTESTS and netconsole
(using current mainline) I get a login prompt, and also...
[ 5.181668] SELinux: policy loaded with handle_unknown=deny
[ 5.183315] type=1403 audit(1202100038.157:3): policy loaded auid=4294967295 ses=4294967295
[ 5.822073] SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
[ 7.819146] ------------[ cut here ]------------
[ 7.819146] WARNING: at kernel/lockdep.c:2033 trace_hardirqs_on+0x9b/0x10d()
[ 7.819146] Modules linked in: generic ext3 jbd ide_disk ide_core
[ 7.819146] Pid: 399, comm: hwclock Not tainted 2.6.24 #4
[ 7.819146] [<c011d140>] warn_on_slowpath+0x41/0x51
[ 7.819146] [<c01364a9>] ? lock_release_holdtime+0x50/0x56
[ 7.819146] [<c013770c>] ? check_usage_forwards+0x19/0x3b
[ 7.819146] [<c01390c4>] ? __lock_acquire+0xac3/0xb0b
[ 7.819146] [<c0108c98>] ? native_sched_clock+0x8b/0x9f
[ 7.819146] [<c01364a9>] ? lock_release_holdtime+0x50/0x56
[ 7.819146] [<c030ca6c>] ? _spin_unlock_irq+0x22/0x42
[ 7.819146] [<c013848b>] trace_hardirqs_on+0x9b/0x10d
[ 7.819146] [<c030ca6c>] _spin_unlock_irq+0x22/0x42
[ 7.819146] [<c011481e>] hpet_rtc_interrupt+0xdf/0x290
[ 7.819146] [<c014ea90>] handle_IRQ_event+0x1a/0x46
[ 7.819146] [<c014f8ea>] handle_edge_irq+0xbe/0xff
[ 7.819146] [<c0106e08>] do_IRQ+0x6d/0x84
[ 7.819146] [<c0105596>] common_interrupt+0x2e/0x34
[ 7.819146] [<c013007b>] ? ktime_get_ts+0x8/0x3f
[ 7.819146] [<c0139420>] ? lock_release+0x167/0x16f
[ 7.819146] [<c017974a>] ? core_sys_select+0x2c/0x327
[ 7.819146] [<c0179792>] core_sys_select+0x74/0x327
[ 7.819146] [<c0108c98>] ? native_sched_clock+0x8b/0x9f
[ 7.819146] [<c01364a9>] ? lock_release_holdtime+0x50/0x56
[ 7.819146] [<c030ca6c>] ? _spin_unlock_irq+0x22/0x42
[ 7.819146] [<c01384d6>] ? trace_hardirqs_on+0xe6/0x10d
[ 7.819146] [<c030ca77>] ? _spin_unlock_irq+0x2d/0x42
[ 7.819146] [<c023b437>] ? rtc_do_ioctl+0x11b/0x677
[ 7.819146] [<c01c487e>] ? inode_has_perm+0x5e/0x68
[ 7.819146] [<c01364a9>] ? lock_release_holdtime+0x50/0x56
[ 7.819146] [<c0108c98>] ? native_sched_clock+0x8b/0x9f
[ 7.819146] [<c01c490b>] ? file_has_perm+0x83/0x8c
[ 7.819146] [<c023ba08>] ? rtc_ioctl+0xf/0x11
[ 7.819146] [<c017898d>] ? do_ioctl+0x55/0x67
[ 7.819146] [<c0179d15>] sys_select+0x93/0x163
[ 7.819146] [<c0104b39>] ? sysenter_past_esp+0x9a/0xa5
[ 7.819146] [<c0104afe>] sysenter_past_esp+0x5f/0xa5
[ 7.819146] =======================
[ 7.819146] ---[ end trace 96540ca301ffb84c ]---
[ 7.819210] rtc: lost 6 interrupts
[ 7.870668] type=1400 audit(1202128840.794:4): avc: denied { audit_write } for pid=399 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
[ 9.538866] input: PC Speaker as /class/input/input5
Because hpet_rtc_interrupt()'s call to get_rtc_time() ends up
resolving to include/asm-generic/rtc.h's (hilariously inlined)
get_rtc_time(), which does spin_unlock_irq() from hard IRQ context.
That warning in lockdep.c should have a comment explaining to readers under
which circumstances it will trigger, and what they did wrong. In fact if
I've interpreted it correctly I don't see why it's a DEBUG_LOCKS_WARN_ON
thing at all? It should be a first-class lockdep warning?
The obvious patch fixes it:
--- a/include/asm-generic/rtc.h~a
+++ a/include/asm-generic/rtc.h
@@ -35,10 +35,11 @@
static inline unsigned char rtc_is_updating(void)
{
unsigned char uip;
+ unsigned long flags;
- spin_lock_irq(&rtc_lock);
+ spin_lock_irqsave(&rtc_lock, flags);
uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
- spin_unlock_irq(&rtc_lock);
+ spin_unlock_irqrestore(&rtc_lock, flags);
return uip;
}
@@ -46,6 +47,8 @@ static inline unsigned int get_rtc_time(
{
unsigned long uip_watchdog = jiffies;
unsigned char ctrl;
+ unsigned long flags;
+
#ifdef CONFIG_MACH_DECSTATION
unsigned int real_year;
#endif
@@ -72,7 +75,7 @@ static inline unsigned int get_rtc_time(
* RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
* by the RTC when initially set to a non-zero value.
*/
- spin_lock_irq(&rtc_lock);
+ spin_lock_irqsave(&rtc_lock, flags);
time->tm_sec = CMOS_READ(RTC_SECONDS);
time->tm_min = CMOS_READ(RTC_MINUTES);
time->tm_hour = CMOS_READ(RTC_HOURS);
@@ -83,7 +86,7 @@ static inline unsigned int get_rtc_time(
real_year = CMOS_READ(RTC_DEC_YEAR);
#endif
ctrl = CMOS_READ(RTC_CONTROL);
- spin_unlock_irq(&rtc_lock);
+ spin_unlock_irqrestore(&rtc_lock, flags);
if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
{
_
but that code really needs help.
Bernhard, I believe the checklist items in Documentation/SubmitChecklist
would have prevented this at the source.
ObProcessObservation: afacit the offending commit went mailing list ->
git-x86 -> mainline in about three days flat, a week after the merge
window had opened.
^ permalink raw reply
* [PATCH 0/2] ehea: kdump & memory remove support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: netdev, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, Thomas Klein
This patch set adds support for kdump and hotplug memory remove
to the eHEA driver.
The "memory remove" patch depends on the following patch that
has been posted a few days ago. That patch exports the symbols
- register_memory_notifier()
- unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
Regards,
Jan-Bernd
^ permalink raw reply
* [PATCH 1/2] ehea: kdump support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: netdev, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, Thomas Klein
This patch adds kdump support to the ehea driver. As the firmware doesn't free
resource handles automatically, the driver has to run an as simple as possible
free resource function in case of a crash shutdown. The function iterates over
two arrays freeing all resource handles which are stored there. The arrays are
kept up-to-date during normal runtime. The crash handler fn is triggered by the
recently introduced PPC crash shutdown reg/unreg functions.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 34 +++++-
drivers/net/ehea/ehea_main.c | 281 ++++++++++++++++++++++++++++++++++++++----
2 files changed, 290 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 88fb53e..7c4ead3 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0083"
+#define DRV_VERSION "EHEA_0087"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -386,6 +386,13 @@ struct ehea_port_res {
#define EHEA_MAX_PORTS 16
+
+#define EHEA_NUM_PORTRES_FW_HANDLES 6 /* QP handle, SendCQ handle,
+ RecvCQ handle, EQ handle,
+ SendMR handle, RecvMR handle */
+#define EHEA_NUM_PORT_FW_HANDLES 1 /* EQ handle */
+#define EHEA_NUM_ADAPTER_FW_HANDLES 2 /* MR handle, NEQ handle */
+
struct ehea_adapter {
u64 handle;
struct of_device *ofdev;
@@ -405,6 +412,31 @@ struct ehea_mc_list {
u64 macaddr;
};
+/* kdump support */
+struct ehea_fw_handle_entry {
+ u64 adh; /* Adapter Handle */
+ u64 fwh; /* Firmware Handle */
+};
+
+struct ehea_fw_handle_array {
+ struct ehea_fw_handle_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
+struct ehea_bcmc_reg_entry {
+ u64 adh; /* Adapter Handle */
+ u32 port_id; /* Logical Port Id */
+ u8 reg_type; /* Registration Type */
+ u64 macaddr;
+};
+
+struct ehea_bcmc_reg_array {
+ struct ehea_bcmc_reg_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
#define EHEA_PHY_LINK_UP 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c051c7e..21af674 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <asm/kexec.h>
#include <net/ip.h>
@@ -98,8 +99,10 @@ static int port_name_cnt;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags;
struct work_struct ehea_rereg_mr_task;
-
struct semaphore dlpar_mem_lock;
+struct ehea_fw_handle_array ehea_fw_handles;
+struct ehea_bcmc_reg_array ehea_bcmc_regs;
+
static int __devinit ehea_probe_adapter(struct of_device *dev,
const struct of_device_id *id);
@@ -132,6 +135,160 @@ void ehea_dump(void *adr, int len, char *msg)
}
}
+static void ehea_update_firmware_handles(void)
+{
+ struct ehea_fw_handle_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ int num_adapters = 0;
+ int num_ports = 0;
+ int num_portres = 0;
+ int i = 0;
+ int num_fw_handles, k, l;
+
+ /* Determine number of handles */
+ list_for_each_entry(adapter, &adapter_list, list) {
+ num_adapters++;
+
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_ports++;
+ num_portres += port->num_def_qps + port->num_add_tx_qps;
+ }
+ }
+
+ num_fw_handles = num_adapters * EHEA_NUM_ADAPTER_FW_HANDLES +
+ num_ports * EHEA_NUM_PORT_FW_HANDLES +
+ num_portres * EHEA_NUM_PORTRES_FW_HANDLES;
+
+ if (num_fw_handles) {
+ arr = kzalloc(num_fw_handles * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ for (l = 0;
+ l < port->num_def_qps + port->num_add_tx_qps;
+ l++) {
+ struct ehea_port_res *pr = &port->port_res[l];
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->qp->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->eq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_mr.handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_mr.handle;
+ }
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = port->qp_eq->fw_handle;
+ }
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->neq->fw_handle;
+
+ if (adapter->mr.handle) {
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->mr.handle;
+ }
+ }
+
+out_update:
+ kfree(ehea_fw_handles.arr);
+ ehea_fw_handles.arr = arr;
+ ehea_fw_handles.num_entries = i;
+}
+
+static void ehea_update_bcmc_registrations(void)
+{
+ struct ehea_bcmc_reg_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ struct ehea_mc_list *mc_entry;
+ int num_registrations = 0;
+ int i = 0;
+ int k;
+
+ /* Determine number of registrations */
+ list_for_each_entry(adapter, &adapter_list, list)
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_registrations += 2; /* Broadcast registrations */
+
+ list_for_each_entry(mc_entry, &port->mc_list->list,list)
+ num_registrations += 2;
+ }
+
+ if (num_registrations) {
+ arr = kzalloc(num_registrations * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = port->mac_addr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = port->mac_addr;
+
+ list_for_each_entry(mc_entry,
+ &port->mc_list->list, list) {
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = mc_entry->macaddr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = mc_entry->macaddr;
+ }
+ }
+ }
+
+out_update:
+ kfree(ehea_bcmc_regs.arr);
+ ehea_bcmc_regs.arr = arr;
+ ehea_bcmc_regs.num_entries = i;
+}
+
static struct net_device_stats *ehea_get_stats(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
@@ -1601,19 +1758,25 @@ static int ehea_set_mac_addr(struct net_device *dev, void *sa)
memcpy(dev->dev_addr, mac_addr->sa_data, dev->addr_len);
+ down(&ehea_bcmc_regs.lock);
+
/* Deregister old MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
port->mac_addr = cb0->port_mac_addr << 16;
/* Register new MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
ret = 0;
+
+out_upregs:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
out_free:
kfree(cb0);
out:
@@ -1775,9 +1938,11 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
ehea_promiscuous(dev, 0);
+ down(&ehea_bcmc_regs.lock);
+
if (dev->flags & IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
- return;
+ goto out;
}
ehea_allmulti(dev, 0);
@@ -1803,6 +1968,8 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
out:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
return;
}
@@ -2285,6 +2452,8 @@ static int ehea_up(struct net_device *dev)
if (port->state == EHEA_PORT_UP)
return 0;
+ down(&ehea_fw_handles.lock);
+
ret = ehea_port_res_setup(port, port->num_def_qps,
port->num_add_tx_qps);
if (ret) {
@@ -2321,8 +2490,17 @@ static int ehea_up(struct net_device *dev)
}
}
- ret = 0;
+ down(&ehea_bcmc_regs.lock);
+
+ ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
+ if (ret) {
+ ret = -EIO;
+ goto out_free_irqs;
+ }
+
port->state = EHEA_PORT_UP;
+
+ ret = 0;
goto out;
out_free_irqs:
@@ -2334,6 +2512,12 @@ out:
if (ret)
ehea_info("Failed starting %s. ret=%i", dev->name, ret);
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2382,16 +2566,27 @@ static int ehea_down(struct net_device *dev)
if (port->state == EHEA_PORT_DOWN)
return 0;
+ down(&ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
+ ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
+
ehea_free_interrupts(dev);
+ down(&ehea_fw_handles.lock);
+
port->state = EHEA_PORT_DOWN;
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
ret = ehea_clean_all_portres(port);
if (ret)
ehea_info("Failed freeing resources for %s. ret=%i",
dev->name, ret);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2920,19 +3115,12 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
INIT_WORK(&port->reset_task, ehea_reset_port);
-
- ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
- if (ret) {
- ret = -EIO;
- goto out_unreg_port;
- }
-
ehea_set_ethtool_ops(dev);
ret = register_netdev(dev);
if (ret) {
ehea_error("register_netdev failed. ret=%d", ret);
- goto out_dereg_bc;
+ goto out_unreg_port;
}
port->lro_max_aggr = lro_max_aggr;
@@ -2949,9 +3137,6 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
return port;
-out_dereg_bc:
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
-
out_unreg_port:
ehea_unregister_port(port);
@@ -2971,7 +3156,6 @@ static void ehea_shutdown_single_port(struct ehea_port *port)
{
unregister_netdev(port->netdev);
ehea_unregister_port(port);
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
kfree(port->mc_list);
free_netdev(port->netdev);
port->adapter->active_ports--;
@@ -3014,7 +3198,6 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
i++;
};
-
return 0;
}
@@ -3159,6 +3342,7 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
+ down(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3239,7 +3423,10 @@ out_kill_eq:
out_free_ad:
kfree(adapter);
+
out:
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
return ret;
}
@@ -3258,18 +3445,41 @@ static int __devexit ehea_remove(struct of_device *dev)
flush_scheduled_work();
+ down(&ehea_fw_handles.lock);
+
ibmebus_free_irq(adapter->neq->attr.ist1, adapter);
tasklet_kill(&adapter->neq_tasklet);
ehea_destroy_eq(adapter->neq);
ehea_remove_adapter_mr(adapter);
list_del(&adapter->list);
-
kfree(adapter);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return 0;
}
+void ehea_crash_handler(void)
+{
+ int i;
+
+ if (ehea_fw_handles.arr)
+ for (i = 0; i < ehea_fw_handles.num_entries; i++)
+ ehea_h_free_resource(ehea_fw_handles.arr[i].adh,
+ ehea_fw_handles.arr[i].fwh,
+ FORCE_FREE);
+
+ if (ehea_bcmc_regs.arr)
+ for (i = 0; i < ehea_bcmc_regs.num_entries; i++)
+ ehea_h_reg_dereg_bcmc(ehea_bcmc_regs.arr[i].adh,
+ ehea_bcmc_regs.arr[i].port_id,
+ ehea_bcmc_regs.arr[i].reg_type,
+ ehea_bcmc_regs.arr[i].macaddr,
+ 0, H_DEREG_BCMC);
+}
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3330,7 +3540,12 @@ int __init ehea_module_init(void)
INIT_WORK(&ehea_rereg_mr_task, ehea_rereg_mrs);
+ memset(&ehea_fw_handles, 0, sizeof(ehea_fw_handles));
+ memset(&ehea_bcmc_regs, 0, sizeof(ehea_bcmc_regs));
+
sema_init(&dlpar_mem_lock, 1);
+ sema_init(&ehea_fw_handles.lock, 1);
+ sema_init(&ehea_bcmc_regs.lock, 1);
ret = check_module_parm();
if (ret)
@@ -3340,12 +3555,18 @@ int __init ehea_module_init(void)
if (ret)
goto out;
- register_reboot_notifier(&ehea_reboot_nb);
+ ret = register_reboot_notifier(&ehea_reboot_nb);
+ if (ret)
+ ehea_info("failed registering reboot notifier");
+
+ ret = crash_shutdown_register(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed registering crash handler");
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
ehea_error("failed registering eHEA device driver on ebus");
- goto out;
+ goto out2;
}
ret = driver_create_file(&ehea_driver.driver,
@@ -3353,21 +3574,33 @@ int __init ehea_module_init(void)
if (ret) {
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
- unregister_reboot_notifier(&ehea_reboot_nb);
- ibmebus_unregister_driver(&ehea_driver);
- goto out;
+ goto out3;
}
+ return ret;
+
+out3:
+ ibmebus_unregister_driver(&ehea_driver);
+out2:
+ unregister_reboot_notifier(&ehea_reboot_nb);
+ crash_shutdown_unregister(&ehea_crash_handler);
out:
return ret;
}
static void __exit ehea_module_exit(void)
{
+ int ret;
+
flush_scheduled_work();
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ret = crash_shutdown_unregister(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed unregistering crash handler");
+ kfree(ehea_fw_handles.arr);
+ kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* [PATCH 2/2] ehea: add memory remove hotplug support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: netdev, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, Thomas Klein
Add memory remove hotplug support
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Comment: This patch depends on the following patch that
exports the symbols
register_memory_notifier()
unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
drivers/net/ehea/ehea_main.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 21af674..b75afcc 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <linux/memory.h>
#include <asm/kexec.h>
#include <net/ip.h>
@@ -3480,6 +3481,24 @@ void ehea_crash_handler(void)
0, H_DEREG_BCMC);
}
+static int ehea_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ switch (action) {
+ case MEM_OFFLINE:
+ ehea_info("memory has been removed");
+ ehea_rereg_mrs(NULL);
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ehea_mem_nb = {
+ .notifier_call = ehea_mem_notifier,
+};
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
if (ret)
ehea_info("failed registering reboot notifier");
+ ret = register_memory_notifier(&ehea_mem_nb);
+ if (ret)
+ ehea_info("failed registering memory remove notifier");
+
ret = crash_shutdown_register(&ehea_crash_handler);
if (ret)
ehea_info("failed registering crash handler");
@@ -3582,6 +3605,7 @@ int __init ehea_module_init(void)
out3:
ibmebus_unregister_driver(&ehea_driver);
out2:
+ unregister_memory_notifier(&ehea_mem_nb);
unregister_reboot_notifier(&ehea_reboot_nb);
crash_shutdown_unregister(&ehea_crash_handler);
out:
@@ -3599,6 +3623,7 @@ static void __exit ehea_module_exit(void)
ret = crash_shutdown_unregister(&ehea_crash_handler);
if (ret)
ehea_info("failed unregistering crash handler");
+ unregister_memory_notifier(&ehea_mem_nb);
kfree(ehea_fw_handles.arr);
kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
--
1.5.2
^ permalink raw reply related
* Re: locking api self-test hanging
From: Peter Zijlstra @ 2008-02-04 13:14 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, Ingo Molnar, linux-kernel, Stephen Hemminger,
Bernhard Walle
In-Reply-To: <20080204050421.0febc754.akpm@linux-foundation.org>
On Mon, 2008-02-04 at 05:04 -0800, Andrew Morton wrote:
> After disabling both CONFIG_DEBUG_LOCKING_API_SELFTESTS and netconsole
> (using current mainline) I get a login prompt, and also...
> [ 7.819146] WARNING: at kernel/lockdep.c:2033 trace_hardirqs_on+0x9b/0x10d()
> That warning in lockdep.c should have a comment explaining to readers under
> which circumstances it will trigger, and what they did wrong. In fact if
> I've interpreted it correctly I don't see why it's a DEBUG_LOCKS_WARN_ON
> thing at all? It should be a first-class lockdep warning?
Agreed, I'll make lockdep print a nice error.
^ permalink raw reply
* Re: locking api self-test hanging
From: Andrew Morton @ 2008-02-04 13:18 UTC (permalink / raw)
To: netdev, Ingo Molnar, linux-kernel, Stephen Hemminger
In-Reply-To: <20080204044304.d244e761.akpm@linux-foundation.org>
On Mon, 4 Feb 2008 04:43:04 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 3 Feb 2008 15:07:44 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Sun, 3 Feb 2008 15:02:46 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > >
> > > With current mainline I'm getting intermittent hangs here:
> > >
> > > http://userweb.kernel.org/~akpm/p2033590.jpg
> > >
> > > with this config:
> > >
> > > http://userweb.kernel.org/~akpm/config-sony.txt
> > >
> > > on the Vaio. Sometimes it boots (then hits another different hang),
> > > sometimes it gets stuck there.
>
> CONFIG_DEBUG_LOCKING_API_SELFTESTS=n fixed that up.
>
> >
> > The second hang is in kobject_uevent_init(). All that function does is call
> > netlink_kernel_create().
>
> And I've fully bisected this hang twice and both times came up with
>
> commit 33f807ba0d9259e7c75c7a2ce8bd2787e5b540c7
> Author: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon Nov 19 19:24:52 2007 -0800
>
> [NETPOLL]: Kill NETPOLL_RX_DROP, set but never tested.
>
> which is stupid because that patch doesn't do anything.
>
> However I am using netconsole-over-e100 and the hang does go away when I
> disable netconsole on the kernel boot command line.
>
> I'd say it's some timing thing in netpoll/netconsole/napi/etc.
>
I expect the locking API self-tests are innocent - the netconsole lockup
happened to strike during the locking API tests and fooled me. When I
disabled those tests, the netconsole lockup struck later on.
^ permalink raw reply
* patches "using mii-bitbang on different processor ports"
From: Sergej Stepanov @ 2008-02-04 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
Hello!
I am about this two patches.
http://www.spinics.net/lists/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
They was not applied. Could they be picked?
Thank you
Sergej.
^ permalink raw reply
* No IPv6 addresses after resume (No buffer space available)
From: Adrian Knoth @ 2008-02-04 13:16 UTC (permalink / raw)
To: netdev
Hi!
I use suspend-to-RAM on my HP nx6325 laptop. I have three main
locations:
- place A: IPv4 + IPv6
- place B: IPv4 + IPv6
- place C: IPv4 only
Suspending in place A and travelling to place B is no problem, I'm
always getting the local RAs, the right addresses a.s.o.
But once I've been in place C (no IPv6 there at this site), resuming in
A or B doesn't give me IPv6, I don't even get a link local address. Only
the loopback interface is left functional:
adi@chopin:~$ ls /proc/sys/net/ipv6/conf/
all default eth1 lo
chopin:/home/adi# ip -6 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
eth0 is missing, also in /proc/sys/net/ipv6/conf (as shown above).
When I try to assign my link local address, it fails:
chopin:/home/adi# ip -6 a a fe80::0217:a4ff:fed7:a23e/64 scope link dev eth0
RTNETLINK answers: No buffer space available
It doesn't help to cycle the interface down and up. My current
workaround is to unload the NIC driver (tg3) and modprobe it again:
[rmmod tg3 ; modprobe tg3]
chopin:/home/adi# ip -6 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
15: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::217:a4ff:fed7:a23e/64 scope link
valid_lft forever preferred_lft forever
[and a few moments later]
chopin:/home/adi# ip -6 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
15: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:638:906:2:217:a4ff:fed7:a23e/64 scope global dynamic
valid_lft 2591987sec preferred_lft 604787sec
inet6 fe80::217:a4ff:fed7:a23e/64 scope link
valid_lft forever preferred_lft forever
Hope you can identify the culprit.
TIA,
Cheerio
--
mail: adi@thur.de http://adi.thur.de PGP/GPG: key via keyserver
^ 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