* [PATCH 1/4] ipg: balance locking in irq handler
From: Francois Romieu @ 2008-01-10 23:35 UTC (permalink / raw)
To: David Miller; +Cc: linux, jeff, Andrew Morton, netdev
In-Reply-To: <20080110233508.GA13315@electric-eye.fr.zoreil.com>
Spotted-by: <linux@horizon.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/ipg.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..cd1650e 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1630,6 +1630,8 @@ static irqreturn_t ipg_interrupt_handler(int irq, void *dev_inst)
#ifdef JUMBO_FRAME
ipg_nic_rxrestore(dev);
#endif
+ spin_lock(&sp->lock);
+
/* Get interrupt source information, and acknowledge
* some (i.e. TxDMAComplete, RxDMAComplete, RxEarly,
* IntRequested, MacControlFrame, LinkEvent) interrupts
@@ -1647,9 +1649,7 @@ static irqreturn_t ipg_interrupt_handler(int irq, void *dev_inst)
handled = 1;
if (unlikely(!netif_running(dev)))
- goto out;
-
- spin_lock(&sp->lock);
+ goto out_unlock;
/* If RFDListEnd interrupt, restore all used RFDs. */
if (status & IPG_IS_RFD_LIST_END) {
@@ -1733,9 +1733,9 @@ out_enable:
ipg_w16(IPG_IE_TX_DMA_COMPLETE | IPG_IE_RX_DMA_COMPLETE |
IPG_IE_HOST_ERROR | IPG_IE_INT_REQUESTED | IPG_IE_TX_COMPLETE |
IPG_IE_LINK_EVENT | IPG_IE_UPDATE_STATS, INT_ENABLE);
-
+out_unlock:
spin_unlock(&sp->lock);
-out:
+
return IRQ_RETVAL(handled);
}
--
1.5.3.3
^ permalink raw reply related
* Re: [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
From: Jarek Poplawski @ 2008-01-10 23:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Herbert Xu, Paul E. McKenney, davem, dipankar, netdev
In-Reply-To: <20080109113727.50eae500.dada1@cosmosbay.com>
Eric Dumazet wrote, On 01/09/2008 11:37 AM:
...
> [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
...
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index d337706..28484f3 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -283,12 +283,12 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
> break;
> rcu_read_unlock_bh();
> }
> - return r;
> + return rcu_dereference(r);
> }
>
> static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
> {
> - struct rt_cache_iter_state *st = rcu_dereference(seq->private);
> + struct rt_cache_iter_state *st = seq->private;
>
> r = r->u.dst.rt_next;
> while (!r) {
> @@ -298,7 +298,7 @@ static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
> rcu_read_lock_bh();
> r = rt_hash_table[st->bucket].chain;
> }
> - return r;
> + return rcu_dereference(r);
> }
It seems this optimization could've a side effect: if during such a
loop updates are done, and r is seen !NULL during while() check, but
NULL after rcu_dereference(), the listing/counting could stop too
soon. So, IMHO, probably the first version of this patch is more
reliable. (Or alternatively additional check is needed before return.)
Regards,
Jarek P.
^ permalink raw reply
* Re : Re : Re : Re : Re : Bonding : Monitoring of 4965 wireless card
From: patnel972-linux @ 2008-01-10 23:01 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
I try arp monitoring but it doesn't work! Test an ip, the interface must have an address, and the dhcpcd is launch by ifplugd if bond0 is linked ... so it goes around in circles.
So i return to miimon, and i figured out that bond detect when wlan0 is associated and set it active interface. But when i switch rf_kill it don't react. So i try to deassociate and magic it detect interface off!! I presume it is a bug of the wlan driver which not re-initialise the info on the wlan. So i made a small script in acpi to provide that behavior.
----- Message d'origine ----
De : Jay Vosburgh <fubar@us.ibm.com>
À : patnel972-linux@yahoo.fr
Cc : netdev@vger.kernel.org
Envoyé le : Jeudi, 10 Janvier 2008, 21h59mn 20s
Objet : Re: Re : Re : Re : Re : Bonding : Monitoring of 4965 wireless card
patnel972-linux@yahoo.fr wrote:
>Yes it's what i'm looking for. I don't understand how to change the
arp_ip_target with the gateway, arp_ip_target is a module option.
If you're running a relatively recent bonding driver (version
3.0.0 or later), the arp_ip_targets can be changed on the fly via
sysfs,
e.g.,
echo +10.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
echo -20.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
You can check out Documentation/networking/bonding.txt (in the
kernel source code) for more details.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>----- Message d'origine ----
>De : Jay Vosburgh <fubar@us.ibm.com>
>À : patnel972-linux@yahoo.fr
>Cc : netdev@vger.kernel.org
>Envoyé le : Jeudi, 10 Janvier 2008, 0h26mn 38s
>Objet : Re: Re : Re : Re : Bonding : Monitoring of 4965 wireless card
>
>patnel972-linux@yahoo.fr wrote:
>
>>I mean that instead of arp test an ip in lan or else, i want it to
> test 127.0.0.1 but in order to do this it must go out and re-enter
and
> then use wlan0 to go out.
>
> In other words, what I think you're saying (and I'm not entirely
>sure here) is that you want probes to go to a remote node on the
>network, and back, without having to actually know the identity of the
>remote node (because, presumably, on a roaming type of wireless
>configuration, your gateway and whatnot can change from time to time).
>
> Is that what you're looking for?
>
> That isn't available now, but might be straightforward to plug
>into the address update system to keep the arp_ip_target up to date as
>the current gateway as the gateway changes. I haven't looked into the
>details of doing that, but in theory it sounds straightforward.
>
> -J
>
>---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Alan Cox @ 2008-01-10 22:36 UTC (permalink / raw)
To: Brent Casavant; +Cc: Herbert Xu, penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <alpine.BSF.1.00.0801101554100.52456@pkunk.americas.sgi.com>
> and the parallel portions/comments in unix_dgram_recvmsg(),
> it looks like there's been a lot of uncertainty as to how
> file descriptor passing should be handled durning MSG_PEEK
> operations. To quote:
The specs basically don't answer the question. What is critical is that
the behaviour does not change compared with older Linux releases.
^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Brent Casavant @ 2008-01-10 22:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <alpine.BSF.1.00.0801092031290.35527@pkunk.americas.sgi.com>
Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
file descriptor passing should be handled durning MSG_PEEK
operations. To quote:
/* It is questionable: on PEEK we could:
- do not return fds - good, but too simple 8)
- return fds, and do not return them on read (old strategy,
apparently wrong)
- clone fds (I chose it for now, it is the most universal
solution)
POSIX 1003.1g does not actually define this clearly
at all. POSIX 1003.1g doesn't define a lot of things
clearly however!
*/
With this patch, passed file descriptors are ignored during MSG_PEEK.
This is essentially the first case in the comment above. What I
can't seem to figure out is why this is incorrect. I suspect there's
some history here that I can't find via Google, mailing list archives,
or revision logs.
So, that said, here's a cleaner patch. It's still not ready for
application until the file descriptor passing is better understood.
Thanks,
Brent
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 060bba4..6d6cdb4 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1750,6 +1750,8 @@ static int unix_stream_recvmsg(struct ki
int target;
int err = 0;
long timeo;
+ struct sk_buff *skb;
+ struct sk_buff_head peek_stack;
err = -EINVAL;
if (sk->sk_state != TCP_ESTABLISHED)
@@ -1759,6 +1761,9 @@ static int unix_stream_recvmsg(struct ki
if (flags&MSG_OOB)
goto out;
+ if (flags & MSG_PEEK)
+ skb_queue_head_init(&peek_stack);
+
target = sock_rcvlowat(sk, flags&MSG_WAITALL, size);
timeo = sock_rcvtimeo(sk, flags&MSG_DONTWAIT);
@@ -1778,7 +1783,6 @@ static int unix_stream_recvmsg(struct ki
do
{
int chunk;
- struct sk_buff *skb;
unix_state_lock(sk);
skb = skb_dequeue(&sk->sk_receive_queue);
@@ -1864,19 +1868,14 @@ static int unix_stream_recvmsg(struct ki
if (siocb->scm->fp)
break;
- }
- else
- {
- /* It is questionable, see note in unix_dgram_recvmsg.
- */
- if (UNIXCB(skb).fp)
- siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
+ } else
+ __skb_queue_head(&peek_stack, skb);
+ } while (size);
- /* put message back and return */
+ /* Push all peeked skbs back onto receive queue */
+ if (flags & MSG_PEEK)
+ while ((skb = __skb_dequeue(&peek_stack)))
skb_queue_head(&sk->sk_receive_queue, skb);
- break;
- }
- } while (size);
mutex_unlock(&u->readlock);
scm_recv(sock, msg, siocb->scm, flags);
^ permalink raw reply related
* Re: [PATCH 2.6.23+] ingress classify to [nf]mark
From: jamal @ 2008-01-10 21:39 UTC (permalink / raw)
To: mahatma; +Cc: netdev
In-Reply-To: <47866C69.3080904@bspu.unibel.by>
On Thu, 2008-10-01 at 17:05 -0200, Dzianis Kahanovich wrote:
> To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y", etc).
>
> --- linux-2.6.23-gentoo-r2/net/sched/Kconfig
> +++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig
> @@ -222,6 +222,16 @@
[..]
> skb->tc_index = TC_H_MIN(res.classid);
> +#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK
> + skb->mark = (skb->mark&(res.classid>>16))|TC_H_MIN(res.classid);
> +#endif
> default:
Please either use ipt action and netfilter fwmarker for this activity or
create a new action.
If you choose the later (example because you want to dynamically compute
the mark), look at net/sched/act_simple.c to start from and i can help
you if you have any questions.
If you want to use ipt action, the syntax would be something like:
---
tc qdisc add dev XXX ingress
tc filter add dev XXX parent ffff: protocol ip prio 5 \
u32 blah bleh \
flowid 1:12 action ipt -j mark --set-mark 13
-----
cheers,
jamal
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6 (use this one)
From: John W. Linville @ 2008-01-10 21:30 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
[2nd try -- turns-out the Mattis Nissler patch needed an extra tweak.
It will probably also cause build breakage when you rebase since
rt2x00lib_txdone(...) becomes rt2x00pci_txdone(rt2x00dev,...) in 2.6.25,
so FYI... :-)
This also includes another patch (the "4 byte boundary" one) which
is already in your upstream branch. So, beware of that one too. :-)]
Jeff,
Three more fixes for 2.6.24. The one from Mattias Nissler is already
in your upstream tree...FYI.
Let me know if there are problems!
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit 3ce54450461bad18bbe1f9f5aa3ecd2f8e8d1235:
Linus Torvalds (1):
Linux 2.6.24-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Ivo van Doorn (2):
rt2x00: Corectly initialize rt2500usb MAC
rt2x00: Put 802.11 data on 4 byte boundary
Mattias Nissler (1):
rt2x00: Allow rt61 to catch up after a missing tx report
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 20 ++++++++++++++++----
drivers/net/wireless/rt2x00/rt2x00usb.c | 17 +++++++++++++++--
drivers/net/wireless/rt2x00/rt61pci.c | 12 ++++++++++++
4 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 50775f9..18b1f91 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -257,7 +257,7 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
static void rt2500usb_config_mac_addr(struct rt2x00_dev *rt2x00dev,
__le32 *mac)
{
- rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, &mac,
+ rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, mac,
(3 * sizeof(__le16)));
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 2780df0..6d5d9ab 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -124,7 +124,10 @@ void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
struct data_entry *entry;
struct data_desc *rxd;
struct sk_buff *skb;
+ struct ieee80211_hdr *hdr;
struct rxdata_entry_desc desc;
+ int header_size;
+ int align;
u32 word;
while (1) {
@@ -138,17 +141,26 @@ void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
memset(&desc, 0x00, sizeof(desc));
rt2x00dev->ops->lib->fill_rxdone(entry, &desc);
+ hdr = (struct ieee80211_hdr *)entry->data_addr;
+ header_size =
+ ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
+
+ /*
+ * The data behind the ieee80211 header must be
+ * aligned on a 4 byte boundary.
+ */
+ align = NET_IP_ALIGN + (2 * (header_size % 4 == 0));
+
/*
* Allocate the sk_buffer, initialize it and copy
* all data into it.
*/
- skb = dev_alloc_skb(desc.size + NET_IP_ALIGN);
+ skb = dev_alloc_skb(desc.size + align);
if (!skb)
return;
- skb_reserve(skb, NET_IP_ALIGN);
- skb_put(skb, desc.size);
- memcpy(skb->data, entry->data_addr, desc.size);
+ skb_reserve(skb, align);
+ memcpy(skb_put(skb, desc.size), entry->data_addr, desc.size);
/*
* Send the frame to rt2x00lib for further processing.
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 1f5675d..ab4797e 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -221,7 +221,9 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
struct data_ring *ring = entry->ring;
struct rt2x00_dev *rt2x00dev = ring->rt2x00dev;
struct sk_buff *skb;
+ struct ieee80211_hdr *hdr;
struct rxdata_entry_desc desc;
+ int header_size;
int frame_size;
if (!test_bit(DEVICE_ENABLED_RADIO, &rt2x00dev->flags) ||
@@ -253,9 +255,20 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
skb_put(skb, frame_size);
/*
- * Trim the skb_buffer to only contain the valid
- * frame data (so ignore the device's descriptor).
+ * The data behind the ieee80211 header must be
+ * aligned on a 4 byte boundary.
+ * After that trim the entire buffer down to only
+ * contain the valid frame data excluding the device
+ * descriptor.
*/
+ hdr = (struct ieee80211_hdr *)entry->skb->data;
+ header_size =
+ ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
+
+ if (header_size % 4 == 0) {
+ skb_push(entry->skb, 2);
+ memmove(entry->skb->data, entry->skb->data + 2, skb->len - 2);
+ }
skb_trim(entry->skb, desc.size);
/*
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 01dbef1..ecae968 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -1738,6 +1738,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
{
struct data_ring *ring;
struct data_entry *entry;
+ struct data_entry *entry_done;
struct data_desc *txd;
u32 word;
u32 reg;
@@ -1791,6 +1792,17 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
!rt2x00_get_field32(word, TXD_W0_VALID))
return;
+ entry_done = rt2x00_get_data_entry_done(ring);
+ while (entry != entry_done) {
+ /* Catch up. Just report any entries we missed as
+ * failed. */
+ WARNING(rt2x00dev,
+ "TX status report missed for entry %p\n",
+ entry_done);
+ rt2x00lib_txdone(entry_done, TX_FAIL_OTHER, 0);
+ entry_done = rt2x00_get_data_entry_done(ring);
+ }
+
/*
* Obtain the status about this packet.
*/
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Re: questions on NAPI processing latency and dropped network packets
From: Chris Friesen @ 2008-01-10 21:29 UTC (permalink / raw)
To: James Chapman; +Cc: netdev, linux-kernel
In-Reply-To: <47866327.8090905@katalix.com>
James Chapman wrote:
> What's changed in your application? Any real-time threads in there?
>
>>From the top output below, looks like SigtranServices is consuming all
> your CPU...
There are two cpus, and SigtranServices is multithreaded with many
threads. Most of these threads are affined to cpu0, a couple to cpu1.
None of the threads are realtime.
Top is showing 37% idle on cpu0, and 6% idle on cpu1, so not all the cpu
is being consumed. However, I'm wondering if we're hitting bursty bits
and we're just running out of time.
I'm going to try a system with MAX_SOFTIRQ_RESTART bumped up a bit, and
also enable profiling.
Chris
^ permalink raw reply
* Re: [PATCH take2] Re: Nested VLAN causes recursive locking error
From: Jarek Poplawski @ 2008-01-10 21:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Benny Amorsen, Chuck Ebbert, netdev
In-Reply-To: <20080110210816.GA3064@ami.dom.local>
On Thu, Jan 10, 2008 at 10:08:16PM +0100, Jarek Poplawski wrote:
...
> But still some 'quirks' are possible there: removing and adding
> devices 'properly' would often require resetting of many subclasses,
...Hmm, probably they are always removed from/with the children, then no
problem! (I know, I could've checked...)
Jarek P.
^ permalink raw reply
* RE: e1000 performance issue in 4 simultaneous links
From: Brandeburg, Jesse @ 2008-01-10 20:52 UTC (permalink / raw)
To: Breno Leitao; +Cc: netdev, Brandeburg, Jesse
In-Reply-To: <1199981839.8931.35.camel@cafe>
Breno Leitao wrote:
> When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
> of transfer rate. If I run 4 netperf against 4 different interfaces, I
> get around 720 * 10^6 bits/sec.
This is actually a known issue that we have worked with your company
before on. It comes down to your system's default behavior of round
robining interrupts (see cat /proc/interrupts while running the test)
combined with e1000's way of exiting / rescheduling NAPI.
The default round robin behavior of the interrupts on your system is the
root cause of this issue, and here is what happens:
4 interfaces start generating interrupts, if you're lucky the round
robin balancer has them all on different cpus.
As the e1000 driver goes into and out of polling mode, the round robin
balancer keeps moving the interrupt to the next cpu.
Eventually 2 or more driver instances end up on the same CPU, which
causes both driver instances to stay in NAPI polling mode, due to the
amount of work being done, and that there are always more than
"netdev->weight" packets to do for each instance. This keeps *hardware*
interrupts for each interface *disabled*.
Staying in NAPI polling mode causes higher cpu utilization on that one
processor, which guarantees that when the hardware round robin balancer
moves any other network interrupt onto that CPU, it too will join the
NAPI polling mode chain.
So no matter how many processors you have, with this round robin style
of hardware interrupts, it guarantees you that if there is a lot of work
to do (more than weight) at each softirq, then, all network interfaces
will end up on the same cpu eventually (the busiest one)
Your performance becomes the same as if you had booted with maxcpus=1
I hope this explanation makes sense, but what it comes down to is that
combining hardware round robin balancing with NAPI is a BAD IDEA. In
general the behavior of hardware round robin balancing is bad and I'm
sure it is causing all sorts of other performance issues that you may
not even be aware of.
I'm sure your problem will go away if you run e1000 in interrupt mode.
(use make CFLAGS_EXTRA=-DE1000_NO_NAPI)
> If I run the same test against 2 interfaces I get a 940 * 10^6
> bits/sec transfer rate also, and if I run it against 3 interfaces I
> get around 850 * 10^6 bits/sec performance.
>
> I got this results using the upstream netdev-2.6 branch kernel plus
> David Miller's 7 NAPI patches set[1]. In the kernel 2.6.23.12 the
> result is a bit worse, and the the transfer rate was around 600 * 10^6
> bits/sec.
Thank you for testing the latest kernel.org kernel.
Hope this helps.
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Andy Gospodarek @ 2008-01-10 21:03 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Herbert Xu, Andy Gospodarek, Krzysztof Oledzki, netdev,
Jeff Garzik, David Miller
In-Reply-To: <25832.1199998246@death>
On Thu, Jan 10, 2008 at 12:50:46PM -0800, Jay Vosburgh wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> >On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
> >>
> >> That wasn't the only purpose, Herbert. Making sure that calls to
> >> dev_set_mac_address were called from process context was important at
> >> the time of the coding as well since at least the tg3 driver took locks
> >> that could not be taken reliably in soft-irq context. Michael Chan
> >> fixed this here:
> >
> >Sure, but where do you call that function while holding the bond lock?
>
> If I recall correctly, the problem was that tg3, et al, did
> things that might sleep, and bonding was calling from a timer context,
> which couldn't sleep. It wasn't about the lock.
>
Exactly, I was just about to post the same.
^ permalink raw reply
* Re: [PATCH take2] Re: Nested VLAN causes recursive locking error
From: Jarek Poplawski @ 2008-01-10 21:08 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Benny Amorsen, Chuck Ebbert, netdev
In-Reply-To: <47863A4A.6070303@trash.net>
On Thu, Jan 10, 2008 at 04:31:22PM +0100, Patrick McHardy wrote:
...
> No, this seems fine, thanks. Even better would be a way to get
> the last lockdep subclass through lockdep somehow, but I couldn't
> find a clean way for this. So I've applied your patch and also
> fixed macvlan.
As a matter of fact this simplified version was done mainly to remove
this bad looking effect of a never decreased global. Of course, your
proposal with using parent's subclass + 1 would be better, if deeper
nestings are required: so, I could try to enhance this (probably with
such additional lockdep macro) after some hint.
But still some 'quirks' are possible there: removing and adding
devices 'properly' would often require resetting of many subclasses,
so quite a lot of activities if more devices. And probably not very
common if not requested until now...
Thanks,
Jarek P.
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Herbert Xu @ 2008-01-10 21:05 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jay Vosburgh, Krzysztof Oledzki, netdev, Jeff Garzik,
David Miller
In-Reply-To: <20080110210353.GI8728@gospo.usersys.redhat.com>
On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
>
> > >Sure, but where do you call that function while holding the bond lock?
> >
> > If I recall correctly, the problem was that tg3, et al, did
> > things that might sleep, and bonding was calling from a timer context,
> > which couldn't sleep. It wasn't about the lock.
>
> Exactly, I was just about to post the same.
In other words, changing read_lock on bond->lock to read_lock_bh doesn't
affect this one bit.
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
* Re: Re : Re : Re : Re : Bonding : Monitoring of 4965 wireless card
From: Jay Vosburgh @ 2008-01-10 20:59 UTC (permalink / raw)
To: patnel972-linux; +Cc: netdev
In-Reply-To: <722263.85774.qm@web25703.mail.ukl.yahoo.com>
patnel972-linux@yahoo.fr wrote:
>Yes it's what i'm looking for. I don't understand how to change the arp_ip_target with the gateway, arp_ip_target is a module option.
If you're running a relatively recent bonding driver (version
3.0.0 or later), the arp_ip_targets can be changed on the fly via sysfs,
e.g.,
echo +10.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
echo -20.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
You can check out Documentation/networking/bonding.txt (in the
kernel source code) for more details.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>----- Message d'origine ----
>De : Jay Vosburgh <fubar@us.ibm.com>
>À : patnel972-linux@yahoo.fr
>Cc : netdev@vger.kernel.org
>Envoyé le : Jeudi, 10 Janvier 2008, 0h26mn 38s
>Objet : Re: Re : Re : Re : Bonding : Monitoring of 4965 wireless card
>
>patnel972-linux@yahoo.fr wrote:
>
>>I mean that instead of arp test an ip in lan or else, i want it to
> test 127.0.0.1 but in order to do this it must go out and re-enter and
> then use wlan0 to go out.
>
> In other words, what I think you're saying (and I'm not entirely
>sure here) is that you want probes to go to a remote node on the
>network, and back, without having to actually know the identity of the
>remote node (because, presumably, on a roaming type of wireless
>configuration, your gateway and whatnot can change from time to time).
>
> Is that what you're looking for?
>
> That isn't available now, but might be straightforward to plug
>into the address update system to keep the arp_ip_target up to date as
>the current gateway as the gateway changes. I haven't looked into the
>details of doing that, but in theory it sounds straightforward.
>
> -J
>
>---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2008-01-10 20:57 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080110194922.GF3109-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Thu, Jan 10, 2008 at 02:49:22PM -0500, John W. Linville wrote:
> Jeff,
>
> A couple more fixes for 2.6.24. The one from Mattias Nissler is already
> in your upstream tree...FYI.
>
> Let me know if there are problems!
Please disregard this request. The 'upstream-jgarzik-2' request is still valid.
Thanks,
John
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-10 20:50 UTC (permalink / raw)
To: Herbert Xu
Cc: Andy Gospodarek, Krzysztof Oledzki, netdev, Jeff Garzik,
David Miller
In-Reply-To: <20080110203604.GB16621@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
>On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
>>
>> That wasn't the only purpose, Herbert. Making sure that calls to
>> dev_set_mac_address were called from process context was important at
>> the time of the coding as well since at least the tg3 driver took locks
>> that could not be taken reliably in soft-irq context. Michael Chan
>> fixed this here:
>
>Sure, but where do you call that function while holding the bond lock?
If I recall correctly, the problem was that tg3, et al, did
things that might sleep, and bonding was calling from a timer context,
which couldn't sleep. It wasn't about the lock.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-10 20:45 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Herbert Xu, Krzysztof Oledzki, netdev, Jeff Garzik, David Miller
In-Reply-To: <20080110145144.GH8728@gospo.usersys.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
[...]
>That wasn't the only purpose, Herbert. Making sure that calls to
>dev_set_mac_address were called from process context was important at
>the time of the coding as well since at least the tg3 driver took locks
>that could not be taken reliably in soft-irq context. Michael Chan
>fixed this here:
>
>commit 986e0aeb9ae09127b401c3baa66f15b7a31f354c
>Author: Michael Chan <mchan@broadcom.com>
>Date: Sat May 5 12:10:20 2007 -0700
>
> [TG3]: Remove reset during MAC address changes.
>
>so if wasn't as much of an issue after that, but moving as much of the
>code to process context was important for that as well (hence the move
>to not continue to try to not use bh-locks everywhere).
Well, not for tg3 perhaps, but other network device drivers do
the same thing (if memory serves, any USB ethernet adapter will have
issues there). Also, I believe the netlink notifier callback,
rtnetlink_event, which every dev_set_whatever calls, does a
possibly-sleeping memory allocation (rtmsg_ifinfo -> nlmsg_new ->
alloc_skb(GFP_KERNEL)); so we don't really want to hold extra locks for
that, either.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Herbert Xu @ 2008-01-10 20:36 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jay Vosburgh, Krzysztof Oledzki, netdev, Jeff Garzik,
David Miller
In-Reply-To: <20080110145144.GH8728@gospo.usersys.redhat.com>
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
>
> That wasn't the only purpose, Herbert. Making sure that calls to
> dev_set_mac_address were called from process context was important at
> the time of the coding as well since at least the tg3 driver took locks
> that could not be taken reliably in soft-irq context. Michael Chan
> fixed this here:
Sure, but where do you call that function while holding the bond lock?
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
* iproute2: make max rounds in ip {neigh,addr} flush configurable.
From: Andreas Henriksson @ 2008-01-10 20:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080110195423.GA26373@scream.fatal.se>
On tor, 2008-01-10 at 20:54 +0100, Andreas Henriksson wrote:
> An additional patch will be provided in a followup mail (not available in
> Debian) that was created by request from Patrick McHardy. This one makes max
> rounds configurable (and 0 means try to infinity, so you can restore old
> behaviour).
In my opinion 10 tries should be enough for anyone, but here's the patch anyway.
This one is on top of the patches in the previous mail.
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index ff9e318..232fd64 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -67,6 +67,7 @@ static void usage(void)
fprintf(stderr, " ip addr del IFADDR dev STRING\n");
fprintf(stderr, " ip addr {show|flush} [ dev STRING ] [ scope SCOPE-ID ]\n");
fprintf(stderr, " [ to PREFIX ] [ FLAG-LIST ] [ label PATTERN ]\n");
+ fprintf(stderr, " [ maxrounds N ]\n");
fprintf(stderr, "IFADDR := PREFIX | ADDR peer PREFIX\n");
fprintf(stderr, " [ broadcast ADDR ] [ anycast ADDR ]\n");
fprintf(stderr, " [ label STRING ] [ scope SCOPE-ID ]\n");
@@ -566,6 +567,7 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
struct nlmsg_list *l, *n;
char *filter_dev = NULL;
int no_link = 0;
+ unsigned maxrounds = MAX_ROUNDS;
ipaddr_reset_filter(oneline);
filter.showqueue = 1;
@@ -630,6 +632,10 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
} else if (strcmp(*argv, "label") == 0) {
NEXT_ARG();
filter.label = *argv;
+ } else if (strcmp(*argv, "maxrounds") == 0) {
+ NEXT_ARG();
+ if (get_unsigned(&maxrounds, *argv, 0))
+ invarg("maxrounds must be 0 (infinite) or higher", "maxrounds");
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
@@ -669,7 +675,7 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
filter.flushp = 0;
filter.flushe = sizeof(flushb);
- while (round < MAX_ROUNDS) {
+ while (maxrounds == 0 || round < maxrounds) {
if (rtnl_wilddump_request(&rth, filter.family, RTM_GETADDR) < 0) {
perror("Cannot send dump request");
exit(1);
@@ -696,7 +702,10 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
fflush(stdout);
}
}
- fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", MAX_ROUNDS); fflush(stderr);
+ fprintf(stderr,
+ "*** Flush remains incomplete after %u rounds. ***\n",
+ maxrounds);
+ fflush(stderr);
return 1;
}
diff --git a/ip/ipneigh.c b/ip/ipneigh.c
index db684f5..61fac66 100644
--- a/ip/ipneigh.c
+++ b/ip/ipneigh.c
@@ -53,6 +53,7 @@ static void usage(void)
" [ nud { permanent | noarp | stale | reachable } ]\n"
" | proxy ADDR } [ dev DEV ]\n");
fprintf(stderr, " ip neigh {show|flush} [ to PREFIX ] [ dev DEV ] [ nud STATE ]\n");
+ fprintf(stderr, " [ maxrounds N ]\n");
exit(-1);
}
@@ -321,6 +322,7 @@ int do_show_or_flush(int argc, char **argv, int flush)
{
char *filter_dev = NULL;
int state_given = 0;
+ unsigned maxrounds = MAX_ROUNDS;
ipneigh_reset_filter();
@@ -361,6 +363,10 @@ int do_show_or_flush(int argc, char **argv, int flush)
if (state == 0)
state = 0x100;
filter.state |= state;
+ } else if (strcmp(*argv, "maxrounds") == 0) {
+ NEXT_ARG();
+ if (get_unsigned(&maxrounds, *argv, 0))
+ invarg("maxrounds must be 0 (infinite) or higher", "maxrounds");
} else {
if (strcmp(*argv, "to") == 0) {
NEXT_ARG();
@@ -392,7 +398,7 @@ int do_show_or_flush(int argc, char **argv, int flush)
filter.flushe = sizeof(flushb);
filter.state &= ~NUD_FAILED;
- while (round < MAX_ROUNDS) {
+ while (maxrounds == 0 || round < maxrounds) {
if (rtnl_wilddump_request(&rth, filter.family, RTM_GETNEIGH) < 0) {
perror("Cannot send dump request");
exit(1);
@@ -418,8 +424,10 @@ int do_show_or_flush(int argc, char **argv, int flush)
fflush(stdout);
}
}
- printf("*** Flush not complete bailing out after %d rounds\n",
- MAX_ROUNDS);
+ fprintf(stderr,
+ "*** Flush remains incomplete after %u rounds. ***\n",
+ maxrounds);
+ fflush(stderr);
return 1;
}
--
Regards,
Andreas Henriksson
^ permalink raw reply related
* Please pull 'upstream-jgarzik-2' branch of wireless-2.6
From: John W. Linville @ 2008-01-10 19:48 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
In-Reply-To: <20080109032009.GC3048@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]
Jeff,
This is additive on top of the pull request posted on Tuesday evening:
http://marc.info/?l=linux-wireless&m=119985065704687&w=2
If you pull this one, you will get that one as well.
Please let me know if there are any problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik-2/
---
The following changes since commit deb27641a93290475f6c66b99d2fceabbc28d6fb:
Michael Buesch (1):
zd1211rw: fix alignment for QOS and WDS frames
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik-2
John W. Linville (2):
b43: finish removal of pio support
iwlwifi: fix-up damage from rebase of namespace separation patches
Michael Buesch (3):
b43: Add N-PHY register definitions
b43: Fix PHY register routing
b43: Remove the PHY spinlock
Pavel Roskin (1):
hostap_cs: don't match revisions in presense of the MAC chip name
drivers/net/wireless/b43/Makefile | 1 +
drivers/net/wireless/b43/b43.h | 17 +-
drivers/net/wireless/b43/debugfs.c | 6 +-
drivers/net/wireless/b43/lo.c | 64 ++--
drivers/net/wireless/b43/main.c | 4 -
drivers/net/wireless/b43/nphy.c | 34 ++
drivers/net/wireless/b43/nphy.h | 706 +++++++++++++++++++++++++++
drivers/net/wireless/b43/phy.c | 235 +++++----
drivers/net/wireless/b43/phy.h | 57 +--
drivers/net/wireless/b43/pio.c | 652 -------------------------
drivers/net/wireless/b43/pio.h | 153 ------
drivers/net/wireless/hostap/hostap_cs.c | 15 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 9 +-
drivers/net/wireless/iwlwifi/iwl4965-base.c | 9 +-
14 files changed, 949 insertions(+), 1013 deletions(-)
create mode 100644 drivers/net/wireless/b43/nphy.c
create mode 100644 drivers/net/wireless/b43/nphy.h
delete mode 100644 drivers/net/wireless/b43/pio.c
delete mode 100644 drivers/net/wireless/b43/pio.h
Omnibus patch attached as upstream-jgarzik-2.patch.bz2
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: upstream-jgarzik-2.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 21165 bytes --]
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2008-01-10 19:49 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
Jeff,
A couple more fixes for 2.6.24. The one from Mattias Nissler is already
in your upstream tree...FYI.
Let me know if there are problems!
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit 3ce54450461bad18bbe1f9f5aa3ecd2f8e8d1235:
Linus Torvalds (1):
Linux 2.6.24-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Ivo van Doorn (1):
rt2x00: Corectly initialize rt2500usb MAC
Mattias Nissler (1):
rt2x00: Allow rt61 to catch up after a missing tx report
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/rt2x00/rt61pci.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 50775f9..18b1f91 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -257,7 +257,7 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
static void rt2500usb_config_mac_addr(struct rt2x00_dev *rt2x00dev,
__le32 *mac)
{
- rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, &mac,
+ rt2500usb_register_multiwrite(rt2x00dev, MAC_CSR2, mac,
(3 * sizeof(__le16)));
}
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 01dbef1..0d9436d 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -1738,6 +1738,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
{
struct data_ring *ring;
struct data_entry *entry;
+ struct data_entry *entry_done;
struct data_desc *txd;
u32 word;
u32 reg;
@@ -1791,6 +1792,18 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
!rt2x00_get_field32(word, TXD_W0_VALID))
return;
+ entry_done = rt2x00_get_data_entry_done(ring);
+ while (entry != entry_done) {
+ /* Catch up. Just report any entries we missed as
+ * failed. */
+ WARNING(rt2x00dev,
+ "TX status report missed for entry %p\n",
+ entry_done);
+ rt2x00pci_txdone(rt2x00dev, entry_done, TX_FAIL_OTHER,
+ 0);
+ entry_done = rt2x00_get_data_entry_done(ring);
+ }
+
/*
* Obtain the status about this packet.
*/
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* debian iproute2 patches branch rebased.
From: Andreas Henriksson @ 2008-01-10 19:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hello Stephen!
I've rebased the patches branch we carry in debian on top of the new
080108 release of iproute2.
See patches branch of git://git.debian.org/git/collab-maint/pkg-iproute
I've dropped one of the patches you picked up[1], so there's now one of the
old ones left and a new manpage for routel/routef.
(Any reason you didn't pull the actual commit we served you with git?)
The old remaining patch fixes the infinite loop in ip route flush exactly the
same way you fixed the same problem in ip neigh flush[2].
An additional patch will be provided in a followup mail (not available in
Debian) that was created by request from Patrick McHardy. This one makes max
rounds configurable (and 0 means try to infinity, so you can restore old
behaviour).
Patrick and me disagrees on what the default should be[3]. He thinks the 'ip
route flush' aka 'loop forever' behaviour should stay, while I vote for the
'ip neigh flush' behaviour of bailing out after N attempts.
IMNSHO looping infinitely is an *insane* default. Specially since this is a
tool used in bootup scripts....
[1]: See commit ea5dd59c03b36fe2acec8f03a8d7a2f7b7036b04
[2]: See commit 660818498d0f5a3f52c05355a3e82c23f670fcc1
Where the comment seems to be wrong about "Limit ip route flush...",
since it's actually "ip neigh flush" that's being modified.
[3]: Read thread from here on:
http://www.spinics.net/lists/netdev/msg44920.html
commit 1eef590948f81b5c84e8450d5c95dd73744b4278
Author: Andreas Henriksson <andreas@fatal.se>
Date: Thu Jan 3 16:48:56 2008 +0100
Add routel and routef man page.
diff --git a/Makefile b/Makefile
index de04176..723eb5d 100644
--- a/Makefile
+++ b/Makefile
@@ -56,6 +56,7 @@ install: all
ln -sf lnstat.8 $(DESTDIR)$(MANDIR)/man8/rtstat.8
ln -sf lnstat.8 $(DESTDIR)$(MANDIR)/man8/ctstat.8
ln -sf rtacct.8 $(DESTDIR)$(MANDIR)/man8/nstat.8
+ ln -sf routel.8 $(DESTDIR)$(MANDIR)/man8/routef.8
install -m 0755 -d $(DESTDIR)$(MANDIR)/man3
install -m 0644 $(shell find man/man3 -maxdepth 1 -type f) $(DESTDIR)$(MANDIR)/man3
diff --git a/man/man8/routel.8 b/man/man8/routel.8
new file mode 100644
index 0000000..cdf8f55
--- /dev/null
+++ b/man/man8/routel.8
@@ -0,0 +1,32 @@
+.TH "ROUTEL" "8" "3 Jan, 2008" "iproute2" "Linux"
+.SH "NAME"
+.LP
+routel \- list routes with pretty output format
+.br
+routef \- flush routes
+.SH "SYNTAX"
+.LP
+routel [\fItablenr\fP [\fIraw ip args...\fP]]
+.br
+routef
+.SH "DESCRIPTION"
+.LP
+These programs are a set of helper scripts you can use instead of raw iproute2 commands.
+.br
+The routel script will list routes in a format that some might consider easier to interpret then the ip route list equivalent.
+.br
+The routef script does not take any arguments and will simply flush the routing table down the drain. Beware! This means deleting all routes which will make your network unusable!
+
+.SH "FILES"
+.LP
+\fI/usr/bin/routef\fP
+.br
+\fI/usr/bin/routel\fP
+.SH "AUTHORS"
+.LP
+The routel script was written by Stephen R. van den Berg <srb@cuci.nl>, 1999/04/18 and donated to the public domain.
+.br
+This manual page was written by Andreas Henriksson <andreas@fatal.se>, for the Debian GNU/Linux system.
+.SH "SEE ALSO"
+.LP
+ip(8)
commit 1d1dab5826d1a9091e0bb2cf832f0785dc2add63
Author: Daniel Silverstone <daniel.silverstone@ubuntu.com>
Date: Fri Oct 19 13:32:24 2007 +0200
Avoid infinite loop in ip addr flush.
Fix "ip addr flush" the same way "ip neigh flush" was previously fixed,
by bailing out if the flush hasn't completed after MAX_ROUNDS (10) tries.
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index d1c6620..34379d0 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -34,6 +34,8 @@
#include "ll_map.h"
#include "ip_common.h"
+#define MAX_ROUNDS 10
+
static struct
{
int ifindex;
@@ -667,7 +669,7 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
filter.flushp = 0;
filter.flushe = sizeof(flushb);
- for (;;) {
+ while (round < MAX_ROUNDS) {
if (rtnl_wilddump_request(&rth, filter.family, RTM_GETADDR) < 0) {
perror("Cannot send dump request");
exit(1);
@@ -694,6 +696,8 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
fflush(stdout);
}
}
+ fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", MAX_ROUNDS); fflush(stderr);
+ return 1;
}
if (filter.family != AF_PACKET) {
--
Regards,
Andreas Henriksson
^ permalink raw reply related
* Re: RFC: igb: Intel 82575 gigabit ethernet driver (take #2)
From: Kok, Auke @ 2008-01-10 19:57 UTC (permalink / raw)
To: Jeff Garzik
Cc: Kok, Auke, NetDev, Arjan van de Ven, Jesse Brandeburg,
Ronciak, John
In-Reply-To: <47684AA9.9050409@pobox.com>
Jeff Garzik wrote:
> Looks pretty decent. Main comments (style mostly, driver operation path
> seems sound):
thanks again for the comments. I am about to send an updated patch just before my
vacation and before I do let me just quickly touch on your comments below:
> * kill the bitfields and unions [in descriptor structs]. they are not
> endian-safe as presented, generate poor code, and are otherwise
> undesirable.
that bitfield was unused and so I removed the code. I don't see any more bitfields
at all now in this driver.
> * the basic operations are too verbose: E1000_READ_REG(hw, REGISTER) is
> far more readable as ER32(REGISTER), following the style of other
> drivers. Furthermore, the "E1000_" prefix, in addition to being overly
> redundant (used in each register read/write), it is also incorrect,
> because this is not E1000...
partially I agree, and I refined the register writes to remove the need for the
"hw" part.
However the hardware *is* e1000, we ended up making a new driver since it just
does not make sense to add all of this infrastructure for older chipsets anymore.
renaming everything (from e1000_ to igb_) would just make life for us really hard
looking up historical diffs, history etc. and most importantly compare with
e1000/e1000e when we encounter an issue that might affect the other drivers. For
now it is easier to just leave these alone.
I however do not rule out that we change this at a later stage ...
> * in general, rename everything with "e1000_" prefix. this will
> eliminate plenty of human confusion in the long run.
I'm doing this for all functions, which solves the namespace collisions. The
"e1000" specific static structs (which are the same in igb as they are in e1000,
e1000e) as well as the registers (ditto) I'll keep unchanged for now.
> * API: unless you have chips in the lab that will require an API hook,
> don't create one. For example, a direct call to
> e1000_acquire_nvm_82575() should replace all ->acquire_nvm() hooks....
> if there are no chips in pipeline GUARANTEED to have a different
> ->acquire_nvm() feature.
Noted
Note also that there are already many less hooks as there are in e1000e. We did
already make an effort to scrub as many as we can.
Cheers,
Auke
^ permalink raw reply
* Re: [PROCFS] [NETNS] issue with /proc/net entries
From: Eric W. Biederman @ 2008-01-10 19:55 UTC (permalink / raw)
To: Benjamin Thery; +Cc: netdev, linux-kernel
In-Reply-To: <478654E1.5050501@bull.net>
Benjamin Thery <benjamin.thery@bull.net> writes:
> Hi Eric,
>
> While testing the current network namespace stuff merged in net-2.6.25,
> I bumped into the following problem with the /proc/net/ entries.
> It doesn't always display the actual data of the current namespace,
> but sometime displays data from other namespaces.
>
> I bisected the problem to the commit:
> "proc: remove/Fix proc generic d_revalidate"
> 3790ee4bd86396558eedd86faac1052cb782e4e1
>
> The problem: If a process in a particular network namespace changes
> current directory to /proc/net, then processes in other network
> namespaces trying to look at /proc/net entries will see data from the
> first namespace (the one with CWD /proc/net). (See test case below).
>
> As you comments in the commit suggest, you seem to be aware of some
> issues when CONFIG_NET_NS=y. Is it one of these corner cases you
> identified? Any idea on how we can fix it?
Yes. It isn't especially hard. I have most of it in my queue
I just need to get the silly patches out of there.
Essentially we need to fix the caching of proc_generic entries,
So that we can have a proper d_revalidate implementation.
To get d_revalidate and the caching correct for /proc/net will take
just a bit more work. We need to make /proc/net a symlink
to something like /proc/self/net so that we don't get excess
revalidates when switching between different processes.
Or else we can't properly implement the case you have described.
Where being in the directory causes the wrong version of /proc/net
to show up. Changing the contents of the dentry for /proc/net
should only happen during unshare. Not when we switch between
processes or else we get into the d_revalidate leaks mount points
problem again.
We also need the check to see if something is mounted on top of
us before we call drop the dentry. But if we don't even try until
we know the dentry is invalid it should not be too bad.
Eric
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: supersud501 @ 2008-01-10 19:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Andrew Morton, netdev, linux-acpi
In-Reply-To: <20080109205210.1f8a83bb@deepthought>
Stephen Hemminger schrieb:
> On Wed, 9 Jan 2008 16:03:00 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
>> bugme-daemon@bugzilla.kernel.org wrote:
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>>>
>>> Summary: wake on lan fails with sky2 module
>>> Product: ACPI
>>> Version: 2.5
>>> KernelVersion: 2.6.24-rc7
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: normal
>>> Priority: P1
>>> Component: Power-Sleep-Wake
>>> AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
>>> ReportedBy: supersud501@yahoo.de
>> This post-2.6.23 regression was assigned to ACPI but is quite possibly a
>> net driver problem?
>>
>>> Latest working kernel version: 2.6.23.12
>>> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
>>> 2.6.24-rc7 still failing)
>>> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
>>> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
>>> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
>>> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
>>> Software Environment:
>>> Problem Description:
>>>
>>> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
>>> status:
>>>
>>> 21:56:29 ~ # sudo ethtool eth0
>>> Settings for eth0:
>>> Supported ports: [ TP ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Half 1000baseT/Full
>>> Supports auto-negotiation: Yes
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Half 1000baseT/Full
>>> Advertised auto-negotiation: Yes
>>> Speed: 100Mb/s
>>> Duplex: Full
>>> Port: Twisted Pair
>>> PHYAD: 0
>>> Transceiver: internal
>>> Auto-negotiation: on
>>> Supports Wake-on: pg
>>> Wake-on: g <---- wol enabled
>>> Current message level: 0x000000ff (255)
>>> Link detected: yes
>>>
>>> but after shutting down the pc doesn't wake up when magic packet is sent.
>>>
>>> the status lights of the network card are still on (so the card seems to be
>>> online).
>>>
>>> same system with only changed kernel to 2.6.23.12 and same procedure like
>>> above: wake on lan works.
>>>
>>> Steps to reproduce: enable wol on your network card using SKY2 module and it
>>> doesn't work too?
>>>
>>> if you need more information, just tell me, it's my first bug report.
>>> regards
>>>
>
>
> Wake from power off works on 2.6.24-rc7 for me.
> Wake from suspend doesn't because Network Manager, HAL, or some other
> user space tool gets confused.
>
> I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055).
> There many variations of this chip, and it maybe chip specific problem
> or ACPI/BIOS issues. If you don't enable Wake on Lan in BIOS, the
> driver can't do it for you. Also, check how you are shutting down.
>
> Also since the device has to restart the PHY, it could be a switch
> issue if you have some fancy pants switch doing intrusion detection
> or something, but I doubt that.
>
> Is it a clean or fast shutdown, most distributions mark network
> devices as down on shutdown, but if the distribution does something
> stupid like remove the driver module, then the driver is unable to setup Wake On Lan.
> The wake on lan setup is done in one place in the driver, add
> a printk to see if it is ever called.
>
>
I only tried wake from shutdown (poweroff), and like i wrote, on the
same system with kernel 2.6.23.12 (nothing changed but vmlinuz and
initrd, with the same kernel config on 2.6.24-rc6/7 (make oldconfig,
default answer to all questions)), it works. so it seems to me like a
problem in the kernel.
every wake-up setting (wake up by pci-device, rtc-alarm, modem ...) in
bios is also enabled, otherwise it couldn't work in 2.6.23.12 (and windows).
if you say your sky2-card works, it might be a acpi-problem not related
to sky2 like i thought - when i am at home i'll try to start my pc with
a timer (--> /proc/acpi/alarm) from kernel 2.6.24-rc7 to check if
acpi-wakeup works and report back (if it is any help in finding the
source of my problem).
and regarding "printk" i'll try to find out what you mean (my first
steps into kernel debugging :) - i think you mean adding a line in the
source to print out something when the function is called)
regards
^ 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