* Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?
From: Matti Aarnio @ 2008-02-04 15:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-hams, netdev
In-Reply-To: <p731w7s4wic.fsf@bingen.suse.de>
On Mon, Feb 04, 2008 at 03:38:35PM +0100, Andi Kleen wrote:
> Matti Aarnio <matti.aarnio@zmailer.org> writes:
>
> > .. 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.
>
> It's not only ifconfig, a lot of programs use SIOCGIFCONF
> to query ip addresses.
So ? My codes do too, and filter away things they are not
interested in. (When they specifically look for IP addresses.)
Of course I may be in minority by expecting the unexpected,
and handling such "weird" multiprotocol systems...
I found original explanation for that mandatoryness finally.
It was in order to silence bug reports in certain cases when
real fix would have been to really find all interfaces instead
of complaining.
In the end I used same trick that ifconfig tool uses to find
all interfaces, and filter away those that AX.25 subsystems
are not interested in - end of "SIOCGIFCONF problems".
netdev:ish developemnt thing would be, that we ( = myself probably )
make SIOCGIFCONF to return those devices that have addresses
in the protocol family that the socket used for the query has.
For PF_INET we might return also PF_INET6 values to lessen
the spanish-inquisition -impact...
.. or do you know any who looks up interface IP addresses with
PF_FILE ( = AF_UNIX ) socket ?
What do the competitor systems B, S, and W do ?
> -Andi
/Matti Aarnio
^ permalink raw reply
* Re: Slow OOM in netif_RX function
From: Ivan Dichev @ 2008-02-04 14:54 UTC (permalink / raw)
Cc: Eric Dumazet, Arnaldo Carvalho de Melo, Andi Kleen, netdev
In-Reply-To: <47A33D02.8050503@obs.bg>
Hi,
Thanks again for your help...
Here's more debug info (long email !):
We installed crash, compiled a kernel with debug symbols, dumped all the
allocated size-2048 slabs, waited some time, and re-dumped them. Then we
compared both dumps: we assumed that slab dumps which were not modified
could be considered as leaks (see end of mail for commands we used).
>From the 3c59x driver source, boomerang_rx() has only a "struct
net_device" as argument, so the idea was to take a dumped slab that
looked like a leak, remove any offset, and "apply" a struct net_device
to the dumped slab data. Then we could have a clue on which interface
the problem happens, and dig deeper to find - say - the packet ip header.
Result: none of the "leaked" slabs seem to match struct net_device.
"Valid" slabs are found in the dumps though, but not in the leaked one.
Example:
a valid slab hexdump:
c0 88 56 63 c5 56 41 d8 00 00 00 00 00 00 00 00 |..Vc.VA.........|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
65 74 68 32 00 00 00 00 00 00 00 00 00 00 00 00 |eth2............|
00 00 00 00 28 6f 37 c0 00 00 00 00 00 00 00 00 |....(o7.........|
00 20 82 d0 0c 00 00 00 08 00 00 00 06 00 00 00 |. ..............|
[...]
There seems to be a 32 byts slab header, then struct net_device which
begins with a 16 bytes interface name (here eth2). If we "apply" a
struct net_device, we can also find the irq, in this case 12, which is
the correct value on our machine.
Now, with a "leaked" slab:
c0 88 56 63 c5 56 41 d8 5a 5a 5a 5a 5a 5a 5a 5a |..Vc.VA.ZZZZZZZZ|
5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 00 0a 5e 5d cf 88 |ZZZZZZZZZZ..^]..|
00 11 20 da 91 01 08 00 45 20 05 d8 5e de 00 00 |.. .....E ..^...|
38 32 00 00 d5 5b 97 c2 55 5f 42 32 61 14 cd 3b |82...[..U_B2a..;|
[...]
Nothing that looks like a struct net_device. All the dumped leaked slab
look the same until "45 20 05 d8" (the ascii 'E' on the 3rd line).
It took quite a bit of time to dig that far (for non kernel experts like
us!), and we're now out of ideas. Is it possible to have something else
than a struct net_device for boomerang_rx() ? Any idea ? Writing a patch
with the ideas mentioned before in this thread is above my level...
Things are also quite weird since we don't seem to have this problem on
two other similar machines (one 100% identical with less traffic, and
another one with the same distro/soft but different hardware).
Also note that all the machines use the out-of-tree openswan ipsec.ko
module, but it doesn't seem to be the problem since the other 2 machines
don't leak, and we didn't find any correlation between plotted IKE
packets / VPN traffic against slab leaks.
Another weird fact is that the leak increase is somewhat correlated to
network traffic - it grows slowly - but there are huge steps (ie. 1000+
more slabs in a few minutes) that are not bound to any traffic peak; if
needed, I can upload the graphs somewhere.
Some other things that might be useful: when we switched from 2.6.16.x
to 2.6.23.14, we began to have "eth1: Too much work in interrupt, status
8401" messages. Playing with 3c59x driver option "max_interrupt_work"
didn't help.
When doing tests with a kernel with slub instead of slab and misc
changes - I think we tried tickless, but not sure - we also got the
following oopses (once):
swapper: page allocation failure. order:1, mode:0x4020
[<c0136e1a>] __alloc_pages+0x295/0x2a4
[<c0149a77>] allocate_slab+0x59/0x96
[<c0149b05>] new_slab+0x32/0x126
[<c014982a>] alloc_debug_processing+0xcf/0x10c
[<c0149eee>] __slab_alloc+0x80/0xdb
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c014ada5>] __kmalloc_track_caller+0x44/0x91
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c021ee94>] __alloc_skb+0x46/0xef
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d0886b0d>] boomerang_interrupt+0x11e/0x324 [3c59x]
[<c011295b>] profile_tick+0x38/0x52
[<c0131c31>] handle_IRQ_event+0x1a/0x3f
[<c0132782>] handle_level_irq+0x0/0x85
[<c01327d2>] handle_level_irq+0x50/0x85
[<c010356e>] do_IRQ+0x7d/0xa3
[<c010cc7e>] update_stats_wait_end+0xa5/0xc2
[<c0102547>] common_interrupt+0x23/0x28
[<c010083c>] default_idle+0x0/0x39
[<c0100863>] default_idle+0x27/0x39
[<c01008bc>] cpu_idle+0x44/0x60
[<c031c7b5>] start_kernel+0x1cd/0x1d1
[<c031c33f>] unknown_bootoption+0x0/0x139
swapper: page allocation failure. order:1, mode:0x4020
[<c0136e1a>] __alloc_pages+0x295/0x2a4
[<c0149a77>] allocate_slab+0x59/0x96
[<c0149b05>] new_slab+0x32/0x126
[<c014982a>] alloc_debug_processing+0xcf/0x10c
[<c0149eee>] __slab_alloc+0x80/0xdb
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c014ada5>] __kmalloc_track_caller+0x44/0x91
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c021ee94>] __alloc_skb+0x46/0xef
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d0886b0d>] boomerang_interrupt+0x11e/0x324 [3c59x]
[<c0131c31>] handle_IRQ_event+0x1a/0x3f
[<c01327d2>] handle_level_irq+0x50/0x85
[<c0103579>] do_IRQ+0x88/0xa3
[<c0102547>] common_interrupt+0x23/0x28
[<c0131c2d>] handle_IRQ_event+0x16/0x3f
[<c01327d2>] handle_level_irq+0x50/0x85
[<c0103579>] do_IRQ+0x88/0xa3
[<c0102547>] common_interrupt+0x23/0x28
[<c0131c2d>] handle_IRQ_event+0x16/0x3f
[<c01327d2>] handle_level_irq+0x50/0x85
[<c0103579>] do_IRQ+0x88/0xa3
[<c0149a77>] allocate_slab+0x59/0x96
[<c0102547>] common_interrupt+0x23/0x28
[<c014adb7>] __kmalloc_track_caller+0x56/0x91
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c021ee94>] __alloc_skb+0x46/0xef
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d0886b0d>] boomerang_interrupt+0x11e/0x324 [3c59x]
[<c011295b>] profile_tick+0x38/0x52
[<c0131c31>] handle_IRQ_event+0x1a/0x3f
[<c0132782>] handle_level_irq+0x0/0x85
[<c01327d2>] handle_level_irq+0x50/0x85
[<c010356e>] do_IRQ+0x7d/0xa3
[<c010cc7e>] update_stats_wait_end+0xa5/0xc2
[<c0102547>] common_interrupt+0x23/0x28
[<c010083c>] default_idle+0x0/0x39
[<c0100863>] default_idle+0x27/0x39
[<c01008bc>] cpu_idle+0x44/0x60
[<c031c7b5>] start_kernel+0x1cd/0x1d1
[<c031c33f>] unknown_bootoption+0x0/0x139
swapper: page allocation failure. order:1, mode:0x4020
[<c0136e1a>] __alloc_pages+0x295/0x2a4
[<c0149a77>] allocate_slab+0x59/0x96
[<c0149b05>] new_slab+0x32/0x126
[<c014982a>] alloc_debug_processing+0xcf/0x10c
[<c0149eee>] __slab_alloc+0x80/0xdb
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c014ada5>] __kmalloc_track_caller+0x44/0x91
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<c021ee94>] __alloc_skb+0x46/0xef
[<d088731f>] boomerang_rx+0x30d/0x40d [3c59x]
[<d0886b0d>] boomerang_interrupt+0x11e/0x324 [3c59x]
[<c011295b>] profile_tick+0x38/0x52
[<c0131c31>] handle_IRQ_event+0x1a/0x3f
[<c0132782>] handle_level_irq+0x0/0x85
[<c01327d2>] handle_level_irq+0x50/0x85
[<c010356e>] do_IRQ+0x7d/0xa3
[<c010cc7e>] update_stats_wait_end+0xa5/0xc2
[<c0102547>] common_interrupt+0x23/0x28
[<c010083c>] default_idle+0x0/0x39
[<c0100863>] default_idle+0x27/0x39
[<c01008bc>] cpu_idle+0x44/0x60
[<c031c7b5>] start_kernel+0x1cd/0x1d1
[<c031c33f>] unknown_bootoption+0x0/0x139
(I'm wondering what's the unknown_bootoption; ours are "ro root=/dev/md1
nousb panic=10").
Slab dump commands:
# in crash:
kmem -S size-2048 > kmem_S
# in another shell:
awk -f extract_slabs.awk kmem_S > dump_cmds
# in crash:
source dump_cmds
then redo a dump later and find the same slabs; these should be leaks:
for i in $(ls memdump/); do
[ -f memdump1/$i ] || continue
cmp -s memdump/$i memdump1/$i || continue
echo $i
done > same_slabs
extract_slabs.awk:
/ *\[[a-f0-9]+\] */ {
beg_hex = strtonum(gensub(/ *\[([a-f0-9]+)\] */, "0x\\1", "g",
$1));
printf("dump memory /home/slab_analysis/memdump/memdump-%x 0x%x
0x%x\n", beg_hex, beg_hex, beg_hex + 2072);
}
Ivan Dichev
^ permalink raw reply
* Re: [PATCH 2/2] ehea: add memory remove hotplug support
From: Michael Ellerman @ 2008-02-04 14:46 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jeff Garzik, Thomas Klein, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <200802041404.49960.ossthema@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> 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
> @@ -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");
You don't do anything except print a message if the registration fails.
What happens when someone tries to remove memory but the memory notifier
wasn't registered properly? Bang?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?
From: Andi Kleen @ 2008-02-04 14:38 UTC (permalink / raw)
To: Matti Aarnio; +Cc: linux-hams, netdev
In-Reply-To: <20080204130252.GA2537@mea-ext.zmailer.org>
Matti Aarnio <matti.aarnio@zmailer.org> writes:
> .. 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.
It's not only ifconfig, a lot of programs use SIOCGIFCONF
to query ip addresses.
-Andi
^ permalink raw reply
* [PATCH][RFC] race in generic address resolution
From: Blaschka @ 2008-02-04 14:27 UTC (permalink / raw)
To: netdev, davem
I'm running a SMP maschine (2 CPUs) configured as a router. During heavy
traffic kernel dies with following message:
<2>kernel BUG at /home/autobuild/BUILD/linux-2.6.23-20080125/net/core/skbuff.c:648!
<4>illegal operation: 0001 [#1] PREEMPT SMP
<4>Modules linked in: dm_multipath sunrpc dm_mod qeth_l3 vmur vmcp qeth_l2 qeth ccwgroup
<4>CPU: 1 Not tainted 2.6.23-26.x.20080125-s390xdefault #1
<4>Process swapper (pid: 0, task: 000000001ff80bb8, ksp: 000000001ff8dd98)
<4>Krnl PSW : 0704100180000000 000000000034877e (pskb_expand_head+0x3a/0x210)
<4> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
<4>Krnl GPRS: 0000000000000000 0000000000000100 000000001b2b9200 0000000000000000
<4> 00000000000022be 0000000000000020 000000001acc0301 00000000000022e0
<4> 00000000000022e0 0000000000000001 0000000000000000 000000001b2b9200
<4> 000000001b2b9200 0000000000444e08 000000001ff5fa38 000000001ff5f9e8
<4>Krnl Code: 0000000000348770: d503d01020cc clc 16(4,%r13),204(%r2)
<4> 0000000000348776: a7840004 brc 8,34877e
<4> 000000000034877a: a7f40001 brc 15,34877c
<4> >000000000034877e: 18b1 lr %r11,%r1
<4> 0000000000348780: 1aba ar %r11,%r10
<4> 0000000000348782: 1ab4 ar %r11,%r4
<4> 0000000000348784: a7ba00ff ahi %r11,255
<4> 0000000000348788: a5b7ff00 nill %r11,65280
<4>Call Trace:
<4>([<070000001fb96000>] 0x70000001fb96000)
<4> [<0000000000348c08>] __pskb_pull_tail+0x2b4/0x38c
<4> [<0000000000352e62>] dev_queue_xmit+0x1a6/0x310
<4> [<0000000000357b98>] neigh_update+0x314/0x524
<4> [<00000000003a11d6>] arp_process+0x2be/0x6f8
<4> [<00000000003a1708>] arp_rcv+0xf8/0x184
<4> [<000000000034f840>] netif_receive_skb+0x244/0x338
<4> [<0000000000352296>] process_backlog+0xc2/0x1a8
<4> [<0000000000352416>] net_rx_action+0x9a/0x154
<4> [<0000000000136ba4>] __do_softirq+0x98/0x12c
<4> [<00000000001106b0>] do_softirq+0xac/0xb0
<4> [<0000000000136d94>] irq_exit+0x8c/0x90
<4> [<00000000002e62dc>] do_IRQ+0x108/0x18c
<4> [<0000000000113f10>] io_return+0x0/0x10
<4> [<000000000010a6f0>] cpu_idle+0x21c/0x23c
<4>([<000000000010a6a4>] cpu_idle+0x1d0/0x23c)
<4> [<00000000001168e6>] start_secondary+0x9e/0xac
<4> [<0000000000000000>] 0x0
<4> [<0000000000000000>] 0x0
<4>
<4> <0>Kernel panic - not syncing: Fatal exception in interrupt
<4>
Following patch fixes the problem but I do not know if it is a good sollution.
From: Frank Blaschka <frank.blaschka@de.ibm.com>
neigh_update sends skb from neigh->arp_queue while
neigh_timer_handler has increased skbs refcount and calls
solicit with the skb. Do not send neighbour skbs
marked for solicit (skb_shared).
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
net/core/neighbour.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: git_linus/net/core/neighbour.c
===================================================================
--- git_linus.orig/net/core/neighbour.c 2008-01-31 12:59:57.000000000 +0100
+++ git_linus/net/core/neighbour.c 2008-01-31 13:00:25.000000000 +0100
@@ -1060,7 +1060,8 @@
/* On shaper/eql skb->dst->neighbour != neigh :( */
if (skb->dst && skb->dst->neighbour)
n1 = skb->dst->neighbour;
- n1->output(skb);
+ if (!skb_shared(skb))
+ n1->output(skb);
write_lock_bh(&neigh->lock);
}
skb_queue_purge(&neigh->arp_queue);
^ permalink raw reply
* [Wireless, ath5k] 2.6.24-git13 9135f1901ee6449dfe338adf6e40e9c2025b8150
From: Oliver Pinter (Pintér Olivér) @ 2008-02-04 14:00 UTC (permalink / raw)
To: John W. Linville, Bruno Randolf, netdev
Cc: Andrew Morton, Linus Torvalds, Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
git top: 9135f1901ee6449dfe338adf6e40e9c2025b8150
[ 399.582185] wpa_supplicant[4383]: segfault at 30 ip 080697ca sp
bf87a690 error 4 in wpa_supplicant[8048000+4c000]
[ 406.277199] wpa_supplicant[4384]: segfault at 30 ip 080697ca sp
bfc13a30 error 4 in wpa_supplicant[8048000+4c000]
[ 407.586375] wpa_supplicant[4385]: segfault at 30 ip 080697ca sp
bf9ed000 error 4 in wpa_supplicant[8048000+4c000]
[ 411.671037] wpa_supplicant[4386]: segfault at 30 ip 080697ca sp
bf8f3710 error 4 in wpa_supplicant[8048000+4c000]
[ 412.569843] wpa_supplicant[4387]: segfault at 30 ip 080697ca sp
bfc19a30 error 4 in wpa_supplicant[8048000+4c000]
[ 413.118874] wpa_supplicant[4388]: segfault at 30 ip 080697ca sp
bfc9cab0 error 4 in wpa_supplicant[8048000+4c000]
home:~# wpa_supplicant -Dwext -iath0 -c /etc/wpa_supplicant/wpa_supplicant.conf
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 4 value 0x0 - bind(PF_UNIX): Address already in use
ctrl_iface exists and seems to be in use - cannot override it
Delete '/var/run/wpa_supplicant/ath0' manually if it is not used anymore
Failed to initialize control interface '/var/run/wpa_supplicant'.
You may have another wpa_supplicant process already running or the file was
left by an unclean termination of wpa_supplicant in which case you will need
to manually remove this file before starting wpa_supplicant again.
Szegmens hiba
--
Thanks,
Oliver
[-- Attachment #2: clog26250home1.bz2 --]
[-- Type: application/x-bzip2, Size: 16010 bytes --]
[-- Attachment #3: dmesg-pre2.6.25.bz2 --]
[-- Type: application/x-bzip2, Size: 8573 bytes --]
[-- Attachment #4: dotconfig.bz2 --]
[-- Type: application/x-bzip2, Size: 10096 bytes --]
[-- Attachment #5: wpa_supplicant-pre2.6.25.bz2 --]
[-- Type: application/x-bzip2, Size: 429 bytes --]
^ 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
* 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
* 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
* 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
* [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
* [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 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
* 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
* 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 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: [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
* 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
* 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
* 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
* 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
* [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
* [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
* 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
* 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
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