* Re: Jetway JAD3RTLANG, Daughter Board, 3x GigaBit LAN does not work correctly
From: Markus Feldmann @ 2011-03-04 12:43 UTC (permalink / raw)
To: netdev
In-Reply-To: <ikovkn$bn8$1@dough.gmane.org>
Here is the dmesg:
http://pastebin.com/PVJdq5hE
^ permalink raw reply
* Re: [PATCH] sctp: do not mark chunk abandoned if peer has no PRSCTP capable
From: Vlad Yasevich @ 2011-03-04 13:08 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev@vger.kernel.org, lksctp, David Miller
In-Reply-To: <4D707442.1090903@cn.fujitsu.com>
On Fri, 2011-03-04 at 13:10 +0800, Wei Yongjun wrote:
> > On 03/02/2011 11:20 PM, Wei Yongjun wrote:
> >> Chunk is marked abandoned if the chunk is expires, and it not be
> >> retransmited even if the peer has no PRSCTP capable, but the peer
> >> will still wait for retransmit it to update CTSN.
> >> This patch disable mark chunk abandoned if peer has no PRSCTP
> >> capable.
> >>
> >> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> >> ---
> >> net/sctp/chunk.c | 3 +++
> >> 1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> >> index 6c85564..0d4832d 100644
> >> --- a/net/sctp/chunk.c
> >> +++ b/net/sctp/chunk.c
> >> @@ -347,6 +347,9 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
> >> {
> >> struct sctp_datamsg *msg = chunk->msg;
> >>
> >> + if (!chunk->asoc->peer.prsctp_capable)
> >> + return 0;
> >> +
> >> if (!msg->can_abandon)
> >> return 0;
> >>
> > The trouble is that timetolive can be set on a message independent of Partial Reliability.
> > The difference in behavior is that when PR can't be used, a chunk can only be abandoned
> > if it has not yet been transmitted. With PR enabled, the chunk can be abandoned at any time.
> >
> > So, you can't blindly disallow abandonment.
>
> But, how can we do PR if peer has no PRSCTP capable?
That's already taken care of. We report the message as unsent. When
PRSCTP is disabled, you may only abandon messages/chunks that have not
been transmitted (assigned a TSN).
> Return error to application in sendmsg()? If so, how we check this if there is no asoc?
How would you have data without an association?
-vlad
>
>
> > -vlad
> > --
> > 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
> >
>
^ permalink raw reply
* Re: Jetway JAD3RTLANG, Daughter Board, 3x GigaBit LAN does not work correctly
From: Markus Feldmann @ 2011-03-04 13:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <ikqmod$hul$1@dough.gmane.org>
Yesterday my daughterboard made trouble, today it works. I can change
the ethernet port or connect two clients at the same time. The dmesg
from today is showing the working state. I will post a dmesg when it
does not work.
regards Markus
^ permalink raw reply
* Re: [PATCH] sctp: fix the fast retransmit limit
From: Vlad Yasevich @ 2011-03-04 14:09 UTC (permalink / raw)
To: Wei Yongjun
Cc: David Miller, netdev@vger.kernel.org, lksctp, Mingyuan Zhu,
Neil Horman
In-Reply-To: <4D707CB6.8020502@cn.fujitsu.com>
On Fri, 2011-03-04 at 13:46 +0800, Wei Yongjun wrote:
> > On 03/03/2011 04:29 AM, Wei Yongjun wrote:
> >> If chunk is still lost after fast retransmit, SCTP stack will
> >> never allow the second fast retransmit of this chunk, even if
> >> the peer need we do this. This chunk will be retransmit until
> >> the rtx timeout. This limit is introduce by the following patch:
> >> sctp: reduce memory footprint of sctp_chunk structure
> >> (c226ef9b83694311327f3ab0036c6de9c22e9daf)
> >>
> >> This patch revert this limit and removed useless SCTP_DONT_FRTX.
> > NACK. Please read the spec and how fast recovery is specified.
>
>
> RFC 7.2.4. Fast Retransmit on Gap Reports said:
> 5) Mark the DATA chunk(s) as being fast retransmitted and thus
> ineligible for a subsequent Fast Retransmit. Those TSNs marked
> for retransmission due to the Fast-Retransmit algorithm that did
> not fit in the sent datagram carrying K other TSNs are also
> marked as ineligible for a subsequent Fast Retransmit. However,
> as they are marked for retransmission they will be retransmitted
> later on as soon as cwnd allows.
>
> So we can treat this chunk can be Fast Retransmit again if not in
> fast recovery?
Right, but you are in Fast Recovery until Cumulative TSN moves
past fast recovery exit point. In other words, you can't exit
fast recovery until the missing chunk has been acknowledged.
The algorithm states that you can Fast Retransmit a chunk once.
If the Fast RTX chunk is lost, you revert to time-outs for that chunk.
Now, there are some improvements to this algorithm that have been
researched, but not standardized. One such improvement is to allow
subsequent FAST-RTXs once the New TSN in SACK reaches the fast recovery
exit point (meaning, that all in-flight data has been SACKed, but the
chunk is still missing). Once that happens, you can start counting
misses again and FAST-RTX when 3 more misses occur. This will improve
the performance of FAST-RTX.
The reason we don't automatically allow additional miss indications to
count is because you may have a lot of chunks in flight. That means
that you end up doing FAST-RTX too often. The idea is to allow the
retransmitted chunk to get there.
-vlad
>
> > -vlad
> >
> >> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> >> ---
> >> include/net/sctp/structs.h | 1 -
> >> net/sctp/outqueue.c | 4 ++--
> >> 2 files changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> >> index cc9185c..82a0f84 100644
> >> --- a/include/net/sctp/structs.h
> >> +++ b/include/net/sctp/structs.h
> >> @@ -751,7 +751,6 @@ struct sctp_chunk {
> >>
> >> #define SCTP_CAN_FRTX 0x0
> >> #define SCTP_NEED_FRTX 0x1
> >> -#define SCTP_DONT_FRTX 0x2
> >> __u16 rtt_in_progress:1, /* This chunk used for RTT calc? */
> >> has_tsn:1, /* Does this chunk have a TSN yet? */
> >> has_ssn:1, /* Does this chunk have a SSN yet? */
> >> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> >> index 8c6d379..7ed5862 100644
> >> --- a/net/sctp/outqueue.c
> >> +++ b/net/sctp/outqueue.c
> >> @@ -657,7 +657,7 @@ redo:
> >> * after it is retransmitted.
> >> */
> >> if (chunk->fast_retransmit == SCTP_NEED_FRTX)
> >> - chunk->fast_retransmit = SCTP_DONT_FRTX;
> >> + chunk->fast_retransmit = SCTP_CAN_FRTX;
> >>
> >> q->empty = 0;
> >> break;
> >> @@ -679,7 +679,7 @@ redo:
> >> if (rtx_timeout || fast_rtx) {
> >> list_for_each_entry(chunk1, lqueue, transmitted_list) {
> >> if (chunk1->fast_retransmit == SCTP_NEED_FRTX)
> >> - chunk1->fast_retransmit = SCTP_DONT_FRTX;
> >> + chunk1->fast_retransmit = SCTP_CAN_FRTX;
> >> }
> >> }
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
^ permalink raw reply
* [PATCH net-next-2.6] inetpeer: seqlock optimization
From: Eric Dumazet @ 2011-03-04 15:09 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, netdev
In-Reply-To: <20110303.003229.229764095.davem@davemloft.net>
Le jeudi 03 mars 2011 à 00:32 -0800, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 03 Mar 2011 08:39:37 +0100
>
> > Le mercredi 02 mars 2011 à 22:42 -0800, David Miller a écrit :
> >> Actually, back to the original topic, I wonder how bad it is to simply
> >> elide the recheck in the create==0 case anyways. Except for the ipv4
> >> fragmentation wraparound protection values, perfect inetpeer finding
> >> is not necessary for correctness. And IPv4 fragmentation always calls
> >> inetpeer with create!=0.
> >
> > We could use a seqlock, to detect that a writer might have changed
> > things while we did our RCU lookup ?
>
> That would certainly work.
Here is a patch to implement this idea.
Thanks !
[PATCH net-next-2.6] inetpeer: seqlock optimization
David noticed :
------------------
Eric, I was profiling the non-routing-cache case and something that
stuck out is the case of calling inet_getpeer() with create==0.
If an entry is not found, we have to redo the lookup under a spinlock
to make certain that a concurrent writer rebalancing the tree does
not "hide" an existing entry from us.
This makes the case of a create==0 lookup for a not-present entry
really expensive. It is on the order of 600 cpu cycles on my
Niagara2.
I added a hack to not do the relookup under the lock when create==0
and it now costs less than 300 cycles.
This is now a pretty common operation with the way we handle COW'd
metrics, so I think it's definitely worth optimizing.
-----------------
One solution is to use a seqlock instead of a spinlock to protect struct
inet_peer_base.
After a failed avl tree lookup, we can easily detect if a writer did
some changes during our lookup. Taking the lock and redo the lookup is
only necessary in this case.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/inetpeer.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 48f8d45..7fd9fab 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -81,19 +81,19 @@ static const struct inet_peer peer_fake_node = {
struct inet_peer_base {
struct inet_peer __rcu *root;
- spinlock_t lock;
+ seqlock_t lock;
int total;
};
static struct inet_peer_base v4_peers = {
.root = peer_avl_empty_rcu,
- .lock = __SPIN_LOCK_UNLOCKED(v4_peers.lock),
+ .lock = __SEQLOCK_UNLOCKED(v4_peers.lock),
.total = 0,
};
static struct inet_peer_base v6_peers = {
.root = peer_avl_empty_rcu,
- .lock = __SPIN_LOCK_UNLOCKED(v6_peers.lock),
+ .lock = __SEQLOCK_UNLOCKED(v6_peers.lock),
.total = 0,
};
@@ -372,7 +372,7 @@ static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base *base)
do_free = 0;
- spin_lock_bh(&base->lock);
+ write_seqlock_bh(&base->lock);
/* Check the reference counter. It was artificially incremented by 1
* in cleanup() function to prevent sudden disappearing. If we can
* atomically (because of lockless readers) take this last reference,
@@ -409,7 +409,7 @@ static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base *base)
base->total--;
do_free = 1;
}
- spin_unlock_bh(&base->lock);
+ write_sequnlock_bh(&base->lock);
if (do_free)
call_rcu_bh(&p->rcu, inetpeer_free_rcu);
@@ -477,12 +477,16 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr *daddr, int create)
struct inet_peer __rcu **stack[PEER_MAXDEPTH], ***stackptr;
struct inet_peer_base *base = family_to_base(daddr->family);
struct inet_peer *p;
+ unsigned int sequence;
+ int invalidated;
/* Look up for the address quickly, lockless.
* Because of a concurrent writer, we might not find an existing entry.
*/
rcu_read_lock_bh();
+ sequence = read_seqbegin(&base->lock);
p = lookup_rcu_bh(daddr, base);
+ invalidated = read_seqretry(&base->lock, sequence);
rcu_read_unlock_bh();
if (p) {
@@ -493,14 +497,18 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr *daddr, int create)
return p;
}
+ /* If no writer did a change during our lookup, we can return early. */
+ if (!create && !invalidated)
+ return NULL;
+
/* retry an exact lookup, taking the lock before.
* At least, nodes should be hot in our cache.
*/
- spin_lock_bh(&base->lock);
+ write_seqlock_bh(&base->lock);
p = lookup(daddr, stack, base);
if (p != peer_avl_empty) {
atomic_inc(&p->refcnt);
- spin_unlock_bh(&base->lock);
+ write_sequnlock_bh(&base->lock);
/* Remove the entry from unused list if it was there. */
unlink_from_unused(p);
return p;
@@ -524,7 +532,7 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr *daddr, int create)
link_to_pool(p, base);
base->total++;
}
- spin_unlock_bh(&base->lock);
+ write_sequnlock_bh(&base->lock);
if (base->total >= inet_peer_threshold)
/* Remove one less-recently-used entry. */
^ permalink raw reply related
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-03-04 16:28 UTC (permalink / raw)
To: linux-pci, linux-hotplug
Cc: netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave,
Shyam_Iyer, sfr
In-Reply-To: <20110302172508.GA2794@fedora14-r610.oslab.blr.amer.dell.com>
On Wed, Mar 02, 2011 at 10:34:17PM +0530, K, Narendra wrote:
> On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
> > Hello,
> >
> > This patch exports ACPI _DSM provided firmware instance number and
> > string name to sysfs.
> >
> > V1 -> V2:
> > The attribute 'index' is changed to 'acpi_index' as the semantics of
> > SMBIOS provided device type instance and ACPI _DSM provided firmware
> > instance number are different.
> >
> > V2 -> V3:
> > Matthew Garrett pointed out that 'sysfs_create_groups' does return an
> > error when there are no ACPI _DSM attributes available and because of
> > that the fallback to SMBIOS will not happen. As a result SMBIOS provided
> > attributes are not created. This version of the patch addresses the issue.
> >
>
> V3 -> V4:
> Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
> breakage from an 'allmodconfig'
>
> Matthew,
> Thanks for the suggestion.
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Export ACPI _DSM provided firmware instance number and string to sysfs
>
Hi Jesse,
Does Version 4 of the patch look good for inclusion ? Please let us know
if there are any concerns.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] net: Enter net/ipv6/ even if CONFIG_IPV6=n
From: Randy Dunlap @ 2011-03-04 17:01 UTC (permalink / raw)
To: davem, Patrick McHardy, Stephen Rothwell, netdev, linux-next
In-Reply-To: <20110304093507.GG10761@canuck.infradead.org>
On 03/04/11 01:35, Thomas Graf wrote:
> exthdrs_core.c and addrconf_core.c in net/ipv6/ contain bits which
> must be made available even if IPv6 is disabled.
>
> net/ipv6/Makefile already correctly includes them if CONFIG_IPV6=n
> but net/Makefile prevents entering the subdirectory.
>
> Signed-off-by: Thomas Graf <tgraf@infradead.org>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
>
> diff --git a/net/Makefile b/net/Makefile
> index a3330eb..a51d946 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -19,9 +19,7 @@ obj-$(CONFIG_NETFILTER) += netfilter/
> obj-$(CONFIG_INET) += ipv4/
> obj-$(CONFIG_XFRM) += xfrm/
> obj-$(CONFIG_UNIX) += unix/
> -ifneq ($(CONFIG_IPV6),)
> -obj-y += ipv6/
> -endif
> +obj-$(CONFIG_NET) += ipv6/
> obj-$(CONFIG_PACKET) += packet/
> obj-$(CONFIG_NET_KEY) += key/
> obj-$(CONFIG_BRIDGE) += bridge/
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v4)
From: Stephen Hemminger @ 2011-03-04 17:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <1299221426.2547.47.camel@edumazet-laptop>
On Fri, 04 Mar 2011 07:50:26 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 03 mars 2011 à 16:30 -0800, Stephen Hemminger a écrit :
> > This is an implementation of the Quick Fair Queue scheduler developed
> > by Fabio Checconi. The same algorithm is already implemented in ipfw
> > in FreeBSD. Fabio had an earlier version developed on Linux, I just
> > cleaned it up. Thanks to Eric Dumazet for doing the testing and
> > finding bugs.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > ---
> > v4 - change slots[] to hlist from simple linked list
> >
> > include/linux/pkt_sched.h | 15
> > net/sched/Kconfig | 11
> > net/sched/Makefile | 1
> > net/sched/sch_qfq.c | 1133 ++++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 1160 insertions(+)
>
> Thanks
>
> Still crashing hard here in qfq_reset_qdisc(), when packets are present
> in queues.
>
> Probably hlist_for_each_entry_safe() is needed, since
> qfq_deactivate_class() is called ...
>
> Also rename cl->next to cl->hnode so that following is clearer ?
>
> - hlist_for_each_entry(cl, n, &grp->slots[j], next) {
> + hlist_for_each_entry_safe(cl, n, next, &grp->slots[j], hnode) {
>
> Fabio, any idea why everything is blocked after a few packets for me ?
>
> Here is script to reproduce the problem :
>
> # cat qfq_setup.sh
> modprobe dummy
>
> ifconfig dummy0 10.2.2.254 netmask 255.255.255.0 up
>
> for i in `seq 1 16`
> do
> arp -H ether -i dummy0 -s 10.2.2.$i 00:00:0c:07:ac:$(printf %02x $i)
> done
>
> DEV=dummy0
> RATE="rate 40Mbit"
> TNETS="10.2.2.0/25"
> ALLOT="allot 20000"
>
> tc qdisc del dev dummy0 root 2>/dev/null
>
> tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 rate 1000Mbit \
> bandwidth 1000Mbit
> tc class add dev $DEV parent 1: classid 1:1 \
> est 1sec 8sec cbq allot 10000 mpu 64 \
> rate 1000Mbit prio 1 avpkt 1500 bounded
>
> # output to test nets : 40 Mbit limit
> tc class add dev $DEV parent 1:1 classid 1:11 \
> est 1sec 8sec cbq $ALLOT mpu 64 \
> $RATE prio 2 avpkt 1400 bounded
>
> tc qdisc add dev $DEV parent 1:11 handle 11: \
> est 1sec 8sec qfq
>
> tc filter add dev $DEV protocol ip parent 11: handle 3 \
> flow hash keys rxhash divisor 8
>
> for i in `seq 1 8`
> do
> classid=11:$(printf %x $i)
> tc class add dev $DEV classid $classid qfq
> tc qdisc add dev $DEV parent $classid pfifo limit 30
> done
>
>
> for privnet in $TNETS
> do
> tc filter add dev $DEV parent 1: protocol ip prio 100 u32 \
> match ip dst $privnet flowid 1:11
> done
>
> tc filter add dev $DEV parent 1: protocol ip prio 100 u32 \
> match ip protocol 0 0x00 flowid 1:1
>
>
> iperf -u -c 10.2.2.1 -P 32 -l 50
>
>
> ------------------------------------------------------------------------------
>
> After a run I get only 5 packets sent, 240 queued in backlog, and all
> other packets dropped.
>
> # tc -s -d qdisc show dev dummy0
> qdisc cbq 1: root refcnt 2 rate 1000Mbit cell 8b (bounded,isolated) prio
> no-transmit/8 weight 1000Mbit allot 1514b
> level 2 ewma 5 avpkt 1000b maxidle 0us
> Sent 460 bytes 5 pkt (dropped 198800, overlimits 199043 requeues 0)
> backlog 0b 240p requeues 0
> borrowed 0 overactions 0 avgidle 125 undertime 0
> qdisc qfq 11: parent 1:11
> Sent 460 bytes 5 pkt (dropped 198800, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 240p requeues 0
> qdisc pfifo 8011: parent 11:1 limit 30p
> Sent 0 bytes 0 pkt (dropped 6178, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8012: parent 11:2 limit 30p
> Sent 92 bytes 1 pkt (dropped 37048, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8013: parent 11:3 limit 30p
> Sent 0 bytes 0 pkt (dropped 24856, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8014: parent 11:4 limit 30p
> Sent 276 bytes 3 pkt (dropped 37358, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8015: parent 11:5 limit 30p
> Sent 0 bytes 0 pkt (dropped 24934, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8016: parent 11:6 limit 30p
> Sent 0 bytes 0 pkt (dropped 24882, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8017: parent 11:7 limit 30p
> Sent 0 bytes 0 pkt (dropped 12328, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> qdisc pfifo 8018: parent 11:8 limit 30p
> Sent 92 bytes 1 pkt (dropped 31216, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
>
>
> and :
>
> # tc -s -d class show dev dummy0
> class cbq 1:11 parent 1:1 leaf 11: rate 40000Kbit cell 128b mpu 64b
> (bounded) prio 2/2 weight 40000Kbit allot 20000b
> level 0 ewma 5 avpkt 1400b maxidle 0us
> Sent 460 bytes 5 pkt (dropped 198800, overlimits 15 requeues 0)
> rate 0bit 0pps backlog 0b 240p requeues 0
> borrowed 0 overactions 3 avgidle -225 undertime -6.46702e+07
> class cbq 1: root rate 1000Mbit cell 8b (bounded,isolated) prio
> no-transmit/8 weight 1000Mbit allot 1514b
> level 2 ewma 5 avpkt 1000b maxidle 0us
> Sent 460 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> borrowed 0 overactions 0 avgidle 125 undertime 0
> class cbq 1:1 parent 1: rate 1000Mbit cell 64b mpu 64b (bounded) prio
> 1/1 weight 1000Mbit allot 10000b
> level 1 ewma 5 avpkt 1500b maxidle 0us
> Sent 460 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> borrowed 0 overactions 0 avgidle 125 undertime 0
> class qfq 11:1 root leaf 8011: weight 1 maxpkt 2048
> Sent 2760 bytes 30 pkt (dropped 6178, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:2 root leaf 8012: weight 1 maxpkt 2048
> Sent 2852 bytes 31 pkt (dropped 37048, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:3 root leaf 8013: weight 1 maxpkt 2048
> Sent 2760 bytes 30 pkt (dropped 24856, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:4 root leaf 8014: weight 1 maxpkt 2048
> Sent 3036 bytes 33 pkt (dropped 37358, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:5 root leaf 8015: weight 1 maxpkt 2048
> Sent 2760 bytes 30 pkt (dropped 24934, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:6 root leaf 8016: weight 1 maxpkt 2048
> Sent 2760 bytes 30 pkt (dropped 24882, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:7 root leaf 8017: weight 1 maxpkt 2048
> Sent 2760 bytes 30 pkt (dropped 12328, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
> class qfq 11:8 root leaf 8018: weight 1 maxpkt 2048
> Sent 2852 bytes 31 pkt (dropped 31216, overlimits 0 requeues 0)
> backlog 2760b 30p requeues 0
>
>
>
>
> Then this crashes :
>
> # tc qdisc del dev dummy0 root
hlist_for_each_entry_safe fixes that.
Can you reproduce without putting cbq on the root?
--
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v4)
From: Stephen Hemminger @ 2011-03-04 17:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <1299221426.2547.47.camel@edumazet-laptop>
On Fri, 04 Mar 2011 07:50:26 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 03 mars 2011 à 16:30 -0800, Stephen Hemminger a écrit :
> > This is an implementation of the Quick Fair Queue scheduler developed
> > by Fabio Checconi. The same algorithm is already implemented in ipfw
> > in FreeBSD. Fabio had an earlier version developed on Linux, I just
> > cleaned it up. Thanks to Eric Dumazet for doing the testing and
> > finding bugs.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > ---
> > v4 - change slots[] to hlist from simple linked list
> >
> > include/linux/pkt_sched.h | 15
> > net/sched/Kconfig | 11
> > net/sched/Makefile | 1
> > net/sched/sch_qfq.c | 1133 ++++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 1160 insertions(+)
>
> Thanks
>
> Still crashing hard here in qfq_reset_qdisc(), when packets are present
> in queues.
>
> Probably hlist_for_each_entry_safe() is needed, since
> qfq_deactivate_class() is called ...
>
> Also rename cl->next to cl->hnode so that following is clearer ?
>
> - hlist_for_each_entry(cl, n, &grp->slots[j], next) {
> + hlist_for_each_entry_safe(cl, n, next, &grp->slots[j], hnode) {
>
> Fabio, any idea why everything is blocked after a few packets for me ?
>
> Here is script to reproduce the problem :
>
> # cat qfq_setup.sh
> modprobe dummy
>
> ifconfig dummy0 10.2.2.254 netmask 255.255.255.0 up
>
> for i in `seq 1 16`
> do
> arp -H ether -i dummy0 -s 10.2.2.$i 00:00:0c:07:ac:$(printf %02x $i)
> done
>
> DEV=dummy0
> RATE="rate 40Mbit"
> TNETS="10.2.2.0/25"
> ALLOT="allot 20000"
>
> tc qdisc del dev dummy0 root 2>/dev/null
>
> tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 rate 1000Mbit \
> bandwidth 1000Mbit
QFQ is non work conserving, it may choose to send a smaller packet
ahead of a larger packet in other flow...
--
^ permalink raw reply
* QFQ debugfs
From: Stephen Hemminger @ 2011-03-04 17:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <1299221426.2547.47.camel@edumazet-laptop>
This is quick hack to put a debugfs hook on:
debug/qfq/<device>
dumps internal state
---
net/sched/sch_qfq.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
--- a/net/sched/sch_qfq.c 2011-03-04 08:24:39.138728524 -0800
+++ b/net/sched/sch_qfq.c 2011-03-04 08:44:10.889972934 -0800
@@ -14,6 +14,7 @@
#include <linux/errno.h>
#include <linux/netdevice.h>
#include <linux/pkt_sched.h>
+#include <linux/debugfs.h>
#include <net/sch_generic.h>
#include <net/pkt_sched.h>
#include <net/pkt_cls.h>
@@ -144,6 +145,7 @@ struct qfq_group {
struct qfq_sched {
struct tcf_proto *filter_list;
struct Qdisc_class_hash clhash;
+ struct dentry *debugfs;
u64 V; /* Precise virtual time. */
u32 wsum; /* weight sum */
@@ -1025,6 +1027,55 @@ static unsigned int qfq_drop(struct Qdis
return 0;
}
+static struct dentry *qfq_debug;
+
+static int qfq_debug_show(struct seq_file *seq, void *v)
+{
+ struct Qdisc *sch = seq->private;
+ const struct qfq_sched *q = qdisc_priv(sch);
+ unsigned int i, j;
+
+ seq_printf(seq, "V=%llu wsum=%u\n", q->V, q->wsum);
+ for (i = 0; i < QFQ_MAX_STATE; i++)
+ seq_printf(seq, "%lx%c", q->bitmaps[i],
+ (i & 3) == 3 ? '\n' : ' ');
+
+ for (i = 0; i <= QFQ_MAX_INDEX; i++) {
+ const struct qfq_group *grp = &q->groups[i];
+ seq_printf(seq, "%d: S=%llu F=%llu shift=%u index=%u front=%u full=%#lx\n",
+ i, (unsigned long long)grp->S,
+ (unsigned long long)grp->F,
+ grp->slot_shift, grp->index,
+ grp->front, grp->full_slots);
+
+ for (j = 0; j < QFQ_MAX_SLOTS; j++) {
+ const struct qfq_class *cl;
+ struct hlist_node *n;
+
+ hlist_for_each_entry(cl, n, &grp->slots[j], next) {
+ seq_printf(seq, " %d: S=%llu F=%llu inv_w=%u lmax=%u\n",
+ j, cl->S, cl->F,
+ cl->inv_w, cl->lmax);
+ }
+ }
+ }
+ return 0;
+}
+
+static int qfq_debug_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, qfq_debug_show, inode->i_private);
+}
+
+static const struct file_operations qfq_debug_fops = {
+ .owner = THIS_MODULE,
+ .open = qfq_debug_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+
static int qfq_init_qdisc(struct Qdisc *sch, struct nlattr *opt)
{
struct qfq_sched *q = qdisc_priv(sch);
@@ -1042,6 +1093,9 @@ static int qfq_init_qdisc(struct Qdisc *
INIT_HLIST_HEAD(&grp->slots[j]);
}
+ q->debugfs = debugfs_create_file(sch->dev_queue->dev->name,
+ S_IRUGO, qfq_debug, sch,
+ &qfq_debug_fops);
return 0;
}
@@ -1121,11 +1175,16 @@ static struct Qdisc_ops qfq_qdisc_ops __
static int __init qfq_init(void)
{
+ qfq_debug = debugfs_create_dir("qfq", NULL);
+
return register_qdisc(&qfq_qdisc_ops);
}
static void __exit qfq_exit(void)
{
+ if (qfq_debug)
+ debugfs_remove(qfq_debug);
+
unregister_qdisc(&qfq_qdisc_ops);
}
^ permalink raw reply
* mii_bus->read return checking in phy_device.c
From: Florian Fainelli @ 2011-03-04 17:25 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Andy Fleming
Hello Andy,
While debugging a PHY probing issue with the au1000_eth, I stumbled upon this
in drivers/net/phy/phy_device.c:
phy_reg = bus->read(bus, addr, MII_PHYSID1);
if (phy_reg < 0)
return -EIO;
most drivers implement phylib's mdio_read callback by simply returning the
contents of their MDIO register after a readl, ioread ... which is unsigned.
Would not it rather make sense to check for phy_reg <= 0 instead?
This can lead for instance to believing that a PHY is present at a wrong
address because the MDIO read function returns 0 for that particular register,
which is logical because no PHY is present at that address.
I am asking in case I just miss something.
Thank you.
--
Florian
^ permalink raw reply
* Re: [PATCH 1/2 net-next][v2] bonding: fix incorrect transmit queue offset
From: Jay Vosburgh @ 2011-03-04 17:37 UTC (permalink / raw)
To: Phil Oester; +Cc: Andy Gospodarek, David Miller, bhutchings, netdev
In-Reply-To: <20110302014009.GA2045@linuxace.com>
Phil Oester <kernel@linuxace.com> wrote:
>On Tue, Mar 01, 2011 at 10:31:36AM -0500, Andy Gospodarek wrote:
>> > The patch works as expected. Do we have any agreement on a final version?
>> >
>>
>> Thanks for the testing, Phil.
>>
>> I'm in favor of this patch as it does alert the admin that bonding may
>> not have enough default queues, but it is not as verbose (backtrace et
>> al) and likely to create bug reports as a message from WARN_ON.
>> + if (net_ratelimit())
>> + pr_warning("%s selects invalid tx queue %d. Consider"
>> + " setting module option tx_queues > %d.",
>> + dev->name, txq, dev->real_num_tx_queues);
>
>It is unclear why we need to alert the admin to this situation (repeatedly).
>Say the incoming nic has 32 queues, and is headed out a bond (with 16).
>With your patch, we will log 50% of the time, no? What benefit is this
>log spew?
>
>While WARN_ONCE may be a bit extreme due to the backtrace, perhaps we
>should at least throw a 'static bool warned' variable in there to lessen
>the nuisance?
I'm also concerned that the log messages will be excessive.
Should we instead create a bonding driver-private ethtool
statistics and count these events that way?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [Patch] ariadne: fix possible null dereference
From: j223yang @ 2011-03-04 17:46 UTC (permalink / raw)
To: davem, netdev; +Cc: linux-kernel
This patch fixes bugzilla #13853:
https://bugzilla.kernel.org/show_bug.cgi?id=13853
The patch removes dereference of 'dev' after testing for NULL.
The source code ariadne.c uses spaces instead of tabs, so the patch
uses spaces too.
Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
---
drivers/net/ariadne.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ariadne.c b/drivers/net/ariadne.c
--- a/drivers/net/ariadne.c
+++ b/drivers/net/ariadne.c
@@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
static irqreturn_t ariadne_interrupt(int irq, void *data)
{
struct net_device *dev = (struct net_device *)data;
- volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
+ volatile struct Am79C960 *lance;
struct ariadne_private *priv;
int csr0, boguscnt;
int handled = 0;
@@ -430,6 +430,7 @@ static irqreturn_t ariadne_interrupt(int
return IRQ_NONE;
}
+ lance = (struct Am79C960 *)dev->base_addr;
lance->RAP = CSR0; /* PCnet-ISA Controller Status */
if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
^ permalink raw reply
* Re: [RFC] Keep track of interrupt URB status and resubmit in bh if necessary
From: Paul Stewart @ 2011-03-04 18:01 UTC (permalink / raw)
To: Indrek Peri; +Cc: netdev@vger.kernel.org, David Brownell
In-Reply-To: <4D70C699.8000606@Ericsson.com>
Thanks for helping clear this up a bit. I'm still a little foggy on
the details, especially when it comes to selective suspend (although I
currently don't work with a system that is actively using it, so I
might not see these issues).
On Fri, Mar 4, 2011 at 3:01 AM, Indrek Peri <Indrek.Peri@ericsson.com> wrote:
>
> To my understanding usbnet has design questions, like EVENT_DEV_ASLEEP,
> device states and events. In struct "flags" member holds an event to
> execute deferred work. Actually, in usbnet_bh, EVENT_DEV_ASLEEP is
> really needed in if-statement. Without that, in selective suspend
> case driver crashes.
>
> Another problem was that "suspend" removed interrupt URB. I tought in
> the same way as Paul, I added insertion of interrupt URB. Paul added
> it in usbnet_bh and I in "resume". I do not see a problem to add
> interrupt URB in "resume". My patch had a typo, in "resume" we
> should use GFP_ATOMIC in usb_submit_urb. Now is the question is
> this good design? My interpretation of David is that driver needs
> "resume driver" transition where RX and INT URBs are activated.
My interpretation of his statement "shouldn't this be just another
part of the "resume driver" action, like refilling the RX urb queue?"
was implicitly asking "shouldn't you move this to usbnet_bh, which is
where the RX urb queue is refilled?" This is why I moved things
there. Hopefully David can shed some light on it (now that I think
I've typed in his email address correctly. :-)
Now, I am also seeing what appear to be RX stalls with some
probability after suspend/resume, so it seems even with the current bh
there is still work to be done...
> I guess that usbnet needs a redesign and rewriting.
> usbnet is used by many USB-Ethernet devices that actually do not
> use selective suspend.
>
> BR, Indrek
>
>
>
> On 03/03/2011 06:45 AM, Paul Stewart wrote:
>> It appears that a patch from Indrek Peri similar to the one below
>> without resolution. I'm new to this problem (suspend-resume causing
>> interrupt URBs to stop delivering) and am curious about what the correct
>> solution would should like. Before becoming aware of this thread, I
>> just added a "usb_submit_urb" of "dev->interrupt" into "usbnet_resume()"
>> and that worked to solve the issue I was having. Apparently this isn't
>> the correct solution though, from David's response to Indrek. So, I'm
>> curious about what the right code should be.
>>
>> I'll note is that submitting the interrupt URB seems fairly benign. If
>> we are in a situation where we should not have sent an URB (e.g, the
>> netif wasn't running) intr_complete correctly handles this case and does
>> not re-submit the URB, so at most we get one "rogue" interrupt URB after
>> resume-from-suspend. The only nasty thing is that this URB should
>> probably not be submitted from interrupt, which the resume function
>> almost certainly is. I'm guessing this is part of why David NAKed
>> Indrek's patch. Am I correct?
>>
>> Does something like the patch below seem like a resonable solution?
>>
>> Cc: David Brownell <dbrownell@users.sourceforge.org>
>> Cc: Indrek Peri <Indrek.Peri@Ericsson.com>
>> Signed-off-by: Paul Stewart <pstew@google.com>
>> ---
>> drivers/net/usb/usbnet.c | 21 +++++++++++++++++++--
>> include/linux/usb/usbnet.h | 1 +
>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>> index 02d25c7..bc6a8e0 100644
>> --- a/drivers/net/usb/usbnet.c
>> +++ b/drivers/net/usb/usbnet.c
>> @@ -471,6 +471,8 @@ static void intr_complete (struct urb *urb)
>> struct usbnet *dev = urb->context;
>> int status = urb->status;
>>
>> + dev->interrupt_urb_running = 0;
>> +
>> switch (status) {
>> /* success */
>> case 0:
>> @@ -497,7 +499,9 @@ static void intr_complete (struct urb *urb)
>>
>> memset(urb->transfer_buffer, 0, urb->transfer_buffer_length);
>> status = usb_submit_urb (urb, GFP_ATOMIC);
>> - if (status != 0 && netif_msg_timer (dev))
>> + if (status == 0)
>> + dev->interrupt_urb_running = 1;
>> + else if (netif_msg_timer (dev))
>> deverr(dev, "intr resubmit --> %d", status);
>> }
>>
>> @@ -580,6 +584,7 @@ static int usbnet_stop (struct net_device *net)
>> remove_wait_queue (&unlink_wakeup, &wait);
>>
>> usb_kill_urb(dev->interrupt);
>> + dev->interrupt_urb_running = 0;
>>
>> /* deferred work (task, timer, softirq) must also stop.
>> * can't flush_scheduled_work() until we drop rtnl (later),
>> @@ -640,7 +645,8 @@ static int usbnet_open (struct net_device *net)
>> if (netif_msg_ifup (dev))
>> deverr (dev, "intr submit %d", retval);
>> goto done;
>> - }
>> + } else
>> + dev->interrupt_urb_running = 1;
>> }
>>
>> netif_start_queue (net);
>> @@ -1065,6 +1071,17 @@ static void usbnet_bh (unsigned long param)
>> if (dev->txq.qlen < TX_QLEN (dev))
>> netif_wake_queue (dev->net);
>> }
>> +
>> + // Do we need to re-enable interrupt URBs?
>> + if (netif_running (dev->net) &&
>> + netif_device_present (dev->net) &&
>> + dev->interrupt_urb_running == 0) {
>> + usb_submit_urb (dev->interrupt, GFP_KERNEL);
>> +
>> + /* Unconditionally mark as running so we don't retry */
>> + dev->interrupt_urb_running = 1;
>> + }
>> +
>> }
>>
>>
>> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
>> index ba09fe8..1b8ed8a 100644
>> --- a/include/linux/usb/usbnet.h
>> +++ b/include/linux/usb/usbnet.h
>> @@ -49,6 +49,7 @@ struct usbnet {
>> u32 hard_mtu; /* count any extra framing */
>> size_t rx_urb_size; /* size for rx urbs */
>> struct mii_if_info mii;
>> + int interrupt_urb_running;
>>
>> /* various kinds of pending driver work */
>> struct sk_buff_head rxq;
>
>
^ permalink raw reply
* Re: [PATCH] e1000: power off PHY after reset when interface is down
From: Prasanna Panchamukhi @ 2011-03-04 18:03 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Allan, Bruce W, Pieper, Jeffrey E,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org
In-Reply-To: <AANLkTim-T99r+npYWCLH8ry+hbtCNBOM4WUev8soaoM6@mail.gmail.com>
On 03/04/2011 12:19 AM, Jeff Kirsher wrote:
> On Wed, Feb 23, 2011 at 16:02, Jeff Kirsher<jeffrey.t.kirsher@intel.com> wrote:
>> On Tue, 2011-02-22 at 17:25 -0800, prasanna.panchamukhi@riverbed.com
>> wrote:
>>> From: Prasanna S. Panchamukhi<prasanna.panchamukhi@riverbed.com>
>>>
>>> Some Phys supported by the e1000 driver do not remain powered off
>>> across
>>> a reset of the device when the interface is down, e.g. on 82546.
>>> This patch powers down (only when WoL is disabled) the PHY after reset
>>> if
>>> the interface is down and ethtool diagnostics are not currently
>>> running.
>>>
>>> Similar problem was see on 82571 controller and was fixed in e1000e
>>> driver
>>> by Bruce Allan.
>>> Please refer commit 31dbe5b4ac6fca72dec946e4d0fa7f0913f1d9b1 for
>>> details.
>>>
>>> Signed-off-by: Prasanna S. Panchamukhi
>>> <prasanna.panchamukhi@riverbed.com>
>>> ---
>>> drivers/net/e1000/e1000_ethtool.c | 27 +++++++++++++++++++--------
>>> drivers/net/e1000/e1000_main.c | 7 +++++++
>>> 2 files changed, 26 insertions(+), 8 deletions(-)
>> Thanks Prasanna! I have added the patch to my queue of e1000 patches.
>>
> Prasanna-
> Here is what we found during validating your patch:
>
> The behavior of 82546 device(s) seems to be identical with/without this patch
> applied. 82546GB (LOM), dev_id 1079 powers down (with wol disabled) after
> ifdown, but powers back up after approx. 10 seconds. 82546EB (NIC), dev_id
> 1010 powers down (with wol disabled) after ifdown. Both of the above
> behaviors are the same with and without the patch applied. Also, if this patch
> DID work as expected, it should print a message after a reset, such as "Cannot
> restart autonegotiation: Resource temporarily unavailable", which would mirror
> the behavior of e1000e.
>
Hi Jeff,
Below is the test case we run verify this fix:
$ ethtool -s eth0 wol d
$ ifconfig eth0 up
$ mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok
$ ifconfig eth0 down
$ mii-tool eth0
eth0: no link
$ ethtool -s eth0 autoneg on (doesn't really matter what we do here)
$ mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok (this should be: eth0: no link)
I will re-run the test& check if does not fix this.
Thanks
Prasanna
^ permalink raw reply
* Re: mii_bus->read return checking in phy_device.c
From: Fleming Andy-AFLEMING @ 2011-03-04 18:06 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev@vger.kernel.org, David Miller
In-Reply-To: <201103041825.48765.florian@openwrt.org>
On Mar 4, 2011, at 11:24, "Florian Fainelli" <florian@openwrt.org> wrote:
> Hello Andy,
>
> While debugging a PHY probing issue with the au1000_eth, I stumbled upon this
> in drivers/net/phy/phy_device.c:
>
> phy_reg = bus->read(bus, addr, MII_PHYSID1);
>
> if (phy_reg < 0)
> return -EIO;
>
> most drivers implement phylib's mdio_read callback by simply returning the
> contents of their MDIO register after a readl, ioread ... which is unsigned.
> Would not it rather make sense to check for phy_reg <= 0 instead?
That isn't a check for a non-existent PHY. PHY registers are unsigned 16-bit quantities. The negative 32-bit return value would be the result of something going wrong in the bus transaction.
Notice that later the code actually checks to see if the read value was mostly 1s...
>
> This can lead for instance to believing that a PHY is present at a wrong
> address because the MDIO read function returns 0 for that particular register,
> which is logical because no PHY is present at that address.
>
> I am asking in case I just miss something.
>
> Thank you.
> --
> Florian
>
^ permalink raw reply
* Re: mii_bus->read return checking in phy_device.c
From: Florian Fainelli @ 2011-03-04 18:12 UTC (permalink / raw)
To: Fleming Andy-AFLEMING; +Cc: netdev@vger.kernel.org, David Miller
In-Reply-To: <1FBC63C1-A8CE-4EFA-8864-62E12C0CFCB3@freescale.com>
On Friday 04 March 2011 19:06:20 Fleming Andy-AFLEMING wrote:
> On Mar 4, 2011, at 11:24, "Florian Fainelli" <florian@openwrt.org> wrote:
> > Hello Andy,
> >
> > While debugging a PHY probing issue with the au1000_eth, I stumbled upon
> > this
> >
> > in drivers/net/phy/phy_device.c:
> > phy_reg = bus->read(bus, addr, MII_PHYSID1);
> >
> > if (phy_reg < 0)
> >
> > return -EIO;
> >
> > most drivers implement phylib's mdio_read callback by simply returning
> > the contents of their MDIO register after a readl, ioread ... which is
> > unsigned. Would not it rather make sense to check for phy_reg <= 0
> > instead?
>
> That isn't a check for a non-existent PHY. PHY registers are unsigned
> 16-bit quantities. The negative 32-bit return value would be the result
> of something going wrong in the bus transaction.
Ok, but 0 is not an acceptable value either for both ID1 and ID2.
>
> Notice that later the code actually checks to see if the read value was
> mostly 1s...
What if the MDIO bus returns 0 instead of 1? Should that be fixed to return
0xffff instead in the driver?
>
> > This can lead for instance to believing that a PHY is present at a wrong
> > address because the MDIO read function returns 0 for that particular
> > register, which is logical because no PHY is present at that address.
> >
> > I am asking in case I just miss something.
> >
> > Thank you.
> > --
> > Florian
>
> --
> 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
^ permalink raw reply
* Re: [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode
From: Jay Vosburgh @ 2011-03-04 18:18 UTC (permalink / raw)
To: Harsha R02
Cc: Brian Haley, Andrew Morton, bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <E351E450E8B9F54684A699D42DC5ADF2103267E5@MPBAGVEX02.corp.mphasis.com>
Harsha R02 <Harsha.R02@mphasis.com> wrote:
>We found that the patch that is presented here has some issues and we
>cannot go with this solution.
>
>In function "bond_ab_arp_probe" in addition to sending arp probes for
>the currently active slave we should also
>be sending arp probes for the primary_slave if the link status of the
>primary slave is up correct ?
>
>I have made changes as below :
>
>static void bond_ab_arp_probe(struct bonding *bond)
>{
> struct slave *slave;
> int i;
>
> read_lock(&bond->curr_slave_lock);
>
> if (bond->current_arp_slave && bond->curr_active_slave)
> pr_info(DRV_NAME "PROBE: c_arp %s && cas %s BAD\n",
> bond->current_arp_slave->dev->name,
> bond->curr_active_slave->dev->name);
>
> if (bond->curr_active_slave) {
>+ if((bond->curr_active_slave != bond->primary_slave) &&
>+ (IS_UP(bond->primary_slave->dev))) {
>+ bond_arp_send_all(bond, bond->primary_slave);
>+ }
> bond_arp_send_all(bond, bond->curr_active_slave);
> read_unlock(&bond->curr_slave_lock);
No, we can't do this; if we send ARP probes out from an inactive
slave (which the primary would be at this point) it will confuse
switches that snoop traffic to determine the switch port's MAC addresses
(the switches will believe that the "primary" slave is the port to use
to reach the bond's MAC address).
I think your problem is that your configuration (two systems,
back to back, no switch) is not a configuration the ARP monitor is
designed to work with.
The ARP monitor determines the availability of backup slaves
based on traffic received by the backup slaves. The usual source of
this traffic is the ARP broadcast requests being sent out the active
slave and then forwarded by the switch to all switch ports, including
the backup slave's port. I'm guessing that your system isn't forwarding
these packets like a switch would, and so the primary slave isn't seeing
any incoming packets at all.
If your primary slave (which is an inactive slave at the moment)
is not receiving traffic, bonding will never believe it is available.
I've never experimented with using the ARP monitor in a
back-to-back confguration; I'm thinking through how the ARP monitor
functions, and I'm not sure it can be reliable when set up like this.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: mii_bus->read return checking in phy_device.c
From: Fleming Andy-AFLEMING @ 2011-03-04 18:19 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev@vger.kernel.org, David Miller
In-Reply-To: <201103041912.10252.florian@openwrt.org>
On Mar 4, 2011, at 12:10, "Florian Fainelli" <florian@openwrt.org> wrote:
> On Friday 04 March 2011 19:06:20 Fleming Andy-AFLEMING wrote:
>> On Mar 4, 2011, at 11:24, "Florian Fainelli" <florian@openwrt.org> wrote:
>>> Hello Andy,
>>>
>>> While debugging a PHY probing issue with the au1000_eth, I stumbled upon
>>> this
>>>
>>> in drivers/net/phy/phy_device.c:
>>> phy_reg = bus->read(bus, addr, MII_PHYSID1);
>>>
>>> if (phy_reg < 0)
>>>
>>> return -EIO;
>>>
>>> most drivers implement phylib's mdio_read callback by simply returning
>>> the contents of their MDIO register after a readl, ioread ... which is
>>> unsigned. Would not it rather make sense to check for phy_reg <= 0
>>> instead?
>>
>> That isn't a check for a non-existent PHY. PHY registers are unsigned
>> 16-bit quantities. The negative 32-bit return value would be the result
>> of something going wrong in the bus transaction.
>
> Ok, but 0 is not an acceptable value either for both ID1 and ID2.
I don't remember the exact details, but i recall we had a discussion about this several years ago, and decided that 0 should not be interpreted as a non-existent PHY. I know I have a part that has an internal PHY which doesnt have anything in the ID registers. If your driver is aware that it did not get a response from the PHY, it should return 0xffff. Otherwise, you can return 0, and just be aware that the PHY subsystem will believe there's a PHY there.
>
>>
>> Notice that later the code actually checks to see if the read value was
>> mostly 1s...
>
> What if the MDIO bus returns 0 instead of 1? Should that be fixed to return
> 0xffff instead in the driver?
>
>>
>>> This can lead for instance to believing that a PHY is present at a wrong
>>> address because the MDIO read function returns 0 for that particular
>>> register, which is logical because no PHY is present at that address.
>>>
>>> I am asking in case I just miss something.
>>>
>>> Thank you.
>>> --
>>> Florian
>>
>> --
>> 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
>
^ permalink raw reply
* Re: [Patch] ariadne: fix possible null dereference
From: Randy Dunlap @ 2011-03-04 18:31 UTC (permalink / raw)
To: j223yang; +Cc: davem, netdev, linux-kernel
In-Reply-To: <20110304174625.GA31042@asset.uwaterloo.ca>
On Fri, 4 Mar 2011 12:46:26 -0500 j223yang@asset.uwaterloo.ca wrote:
> This patch fixes bugzilla #13853:
> https://bugzilla.kernel.org/show_bug.cgi?id=13853
>
> The patch removes dereference of 'dev' after testing for NULL.
> The source code ariadne.c uses spaces instead of tabs, so the patch
> uses spaces too.
Sorry for the confusion here, but (while I agree with the fix in this
patch), this patch still does not apply cleanly.
If a line in the source code file uses spaces, then use spaces.
If a line in the source code file uses tabs, then use tabs.
You cannot exchange one for the other in your generated patch.
Using 'diff' creates the patch correctly, so I guess that your patch
generation tool still needs some work.
Please take your patch and test applying it:
> cd linux-2.6.38-rc7
> patch -p1 --dry-run < ~/tmp/ariadne.patch
patching file drivers/net/ariadne.c
Hunk #2 FAILED at 430.
1 out of 2 hunks FAILED -- saving rejects to file drivers/net/ariadne.c.rej
> Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
> ---
> drivers/net/ariadne.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ariadne.c b/drivers/net/ariadne.c
> --- a/drivers/net/ariadne.c
> +++ b/drivers/net/ariadne.c
> @@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
> static irqreturn_t ariadne_interrupt(int irq, void *data)
> {
> struct net_device *dev = (struct net_device *)data;
> - volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
> + volatile struct Am79C960 *lance;
> struct ariadne_private *priv;
> int csr0, boguscnt;
> int handled = 0;
> @@ -430,6 +430,7 @@ static irqreturn_t ariadne_interrupt(int
> return IRQ_NONE;
> }
>
> + lance = (struct Am79C960 *)dev->base_addr;
> lance->RAP = CSR0; /* PCnet-ISA Controller Status */
>
> if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
>
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Jesse Barnes @ 2011-03-04 18:38 UTC (permalink / raw)
To: Narendra_K
Cc: linux-pci, linux-hotplug, netdev, mjg, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Shyam_Iyer, sfr
In-Reply-To: <20110304164957.GA2913@fedora14-r610.oslab.blr.amer.dell.com>
On Fri, 4 Mar 2011 08:28:59 -0800
<Narendra_K@Dell.com> wrote:
> On Wed, Mar 02, 2011 at 10:34:17PM +0530, K, Narendra wrote:
> > On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
> > > Hello,
> > >
> > > This patch exports ACPI _DSM provided firmware instance number and
> > > string name to sysfs.
> > >
> > > V1 -> V2:
> > > The attribute 'index' is changed to 'acpi_index' as the semantics of
> > > SMBIOS provided device type instance and ACPI _DSM provided firmware
> > > instance number are different.
> > >
> > > V2 -> V3:
> > > Matthew Garrett pointed out that 'sysfs_create_groups' does return an
> > > error when there are no ACPI _DSM attributes available and because of
> > > that the fallback to SMBIOS will not happen. As a result SMBIOS provided
> > > attributes are not created. This version of the patch addresses the issue.
> > >
> >
> > V3 -> V4:
> > Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
> > breakage from an 'allmodconfig'
> >
> > Matthew,
> > Thanks for the suggestion.
> >
> > From: Narendra K <narendra_k@dell.com>
> > Subject: [PATCH] Export ACPI _DSM provided firmware instance number and string to sysfs
> >
>
> Hi Jesse,
>
> Does Version 4 of the patch look good for inclusion ? Please let us know
> if there are any concerns.
Oh sorry, I was looking in the wrong mailbox, I'll pull this one in now.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-02-22
From: John W. Linville @ 2011-03-04 18:40 UTC (permalink / raw)
To: Shan Wei
Cc: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D706C2E.40307-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Fri, Mar 04, 2011 at 12:35:58PM +0800, Shan Wei wrote:
> John W. Linville wrote, at 02/23/2011 05:52 AM:
> > Please let me know if there are problems!
>
> Fail to compile with attached config under net-next tree.
>
> ======Error Begin================================================================
> drivers/net/wireless/rtlwifi/rtl8192cu/built-in.o: In function `rtl92c_phy_sw_chnl':
> /data2/net-next-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/../rtl8192c/phy_common.c:803: multiple definition of `rtl92c_phy_sw_chnl'
> drivers/net/wireless/rtlwifi/rtl8192ce/built-in.o:/data2/net-next-2.6/drivers/net/wireless/rtlwifi/rtl8192ce/../rtl8192c/phy_common.c:803: first defined here
> drivers/net/wireless/rtlwifi/rtl8192cu/built-in.o: In function `rtl92c_fill_h2c_cmd':
This is already fixed in wireless-next-2.6:
commit 1472d3a87586eb7529d1d85f7c888055650b7208
Author: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date: Wed Feb 23 10:24:58 2011 -0600
rtlwifi: rtl8192ce: rtl8192cu: Fix multiple def errors for allyesconfig buil
As noted by Stephan Rothwell, an allyesconfig build fails since rtl8192cu
was merged with failures such as:
drivers/net/wireless/rtlwifi/rtl8192cu/built-in.o: In function `rtl92c_phy_s
(.opd+0xf30): multiple definition of `rtl92c_phy_sw_chnl'
drivers/net/wireless/rtlwifi/rtl8192ce/built-in.o:(.opd+0xb70): first define
drivers/net/wireless/rtlwifi/rtl8192cu/built-in.o: In function `rtl92c_fill_
(.opd+0x288): multiple definition of `rtl92c_fill_h2c_cmd'
drivers/net/wireless/rtlwifi/rtl8192ce/built-in.o:(.opd+0x288): first define
These are caused because the code shared between rtl8192ce and rtl8192cu
is included in both drivers. This has been fixed by creating a new modue tha
contains the shared code.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
It will be in my next pull request to Dave.
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Jesse Barnes @ 2011-03-04 18:43 UTC (permalink / raw)
To: Narendra_K
Cc: linux-pci, linux-hotplug, netdev, mjg, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Shyam_Iyer, sfr
In-Reply-To: <20110302172508.GA2794@fedora14-r610.oslab.blr.amer.dell.com>
On Wed, 2 Mar 2011 22:34:17 +0530
<Narendra_K@Dell.com> wrote:
> On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
> > Hello,
> >
> > This patch exports ACPI _DSM provided firmware instance number and
> > string name to sysfs.
> >
> > V1 -> V2:
> > The attribute 'index' is changed to 'acpi_index' as the semantics of
> > SMBIOS provided device type instance and ACPI _DSM provided firmware
> > instance number are different.
> >
> > V2 -> V3:
> > Matthew Garrett pointed out that 'sysfs_create_groups' does return an
> > error when there are no ACPI _DSM attributes available and because of
> > that the fallback to SMBIOS will not happen. As a result SMBIOS provided
> > attributes are not created. This version of the patch addresses the issue.
> >
>
> V3 -> V4:
> Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
> breakage from an 'allmodconfig'
Applied, fingers crossed this time. :)
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [ethtool PATCH 2/2] Add RX packet classification interface
From: Alexander Duyck @ 2011-03-04 19:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Santwona Behera, netdev@vger.kernel.org
In-Reply-To: <1298939712.2569.43.camel@bwh-desktop>
On 2/28/2011 4:35 PM, Ben Hutchings wrote:
> On Tue, 2011-02-22 at 12:52 -0800, Alexander Duyck wrote:
[...]
>>>> } else
>>>> show_usage(1);
>>>> break;
>>>
>>> I don't think the same options (-n, -N) should be used both for flow
>>> hashing and n-tuple flow steering/filtering. This command-line
>>> interface and the structure used in the ethtool API just seem to reflect
>>> the implementation in the niu driver.
>>>
>>> (In fact I would much prefer it if the -u and -U options could be used
>>> for both the rxnfc and rxntuple interfaces. But I haven't thought about
>>> how the differences in functionality would be exposed to or hidden from
>>> the user.)
>>
>> I was kind of thinking about merging the two interfaces too, but I was
>> looking at it more from the perspective of moving away from ntuple more
>> towards this newer interface. My main motivation being that the filter
>> display option is so badly broken for ntuple that it would be easier to
>> make ntuple a subset of the flow classifier instead of the other way around.
>>
>> What would you think of using the "flow-type" keyword to indicate legacy
>> ntuple support, and then adding something like "class-rule-add", and
>> "class-rule-del" to add support for the network flow classifier calls?
>
> I really don't want to introduce different syntax for functionality that
> is common between the two command sets. The user should not have to
> know that driver A implements interface I and driver B implements
> interface J, except that since version 2.6.y driver A implements
> interface J too.
>
> Surely it is possible to try one interface, then the other, when the
> requested filter can be implemented either way?
The problem is that the interfaces are different in the way they
implement their masks. N-tuple defines the mask as 0s mean inclusion,
1s, mean exclusion. The network flow classifier filters are the exact
opposite. As such we really need to know which type of filter we are
dealing with before we start setting up values. In addition there are
options such as location which exist in network flow classifier rules,
but not in ntuple rules.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net-next-2.6] inetpeer: seqlock optimization
From: David Miller @ 2011-03-04 19:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, netdev
In-Reply-To: <1299251348.2676.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 04 Mar 2011 16:09:08 +0100
> Here is a patch to implement this idea.
Applied, thanks Eric!
^ 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