* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 14:40 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Jan 10, 2011 at 03:05:57PM +0100, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> > On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
Good point.
I will add in Kconfig:
config CAN_SOFTING_CS
tristate "Softing CAN pcmcia cards"
depends on PCMCIA
+ select CAN_SOFTING
---help---
Thanks,
Kurt
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Randy Dunlap @ 2011-01-10 15:50 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <201101101244.24932.christoph.paasch@uclouvain.be>
On Mon, 10 Jan 2011 12:44:24 +0100 Christoph Paasch wrote:
>
> On Monday, January 10, 2011 wrote Alexey Dobriyan:
> > >> linux/percpu_counter.h (needed for percpu_counter_sum_positive)
> > >
> > > Yes.
> >
> > Currently code compiles fine, so necessary headers are in place,
> > so simply adding new headers doesn't help anything.
>
> I totally agree with you.
> However we need a consistent coding style.
>
> Or we just include the minimum necessary headers (as originally proposed by
> me).
> Or we include every header whose structs/functions are referenced.
>
> In my opinion the current "mixed" state is not ok, because some includes are
> there because there *are* references (even if these includes could be omitted,
> e.g., linux/list.h).
> Other includes (like linux/percpu_counter.h) are not there, because they are
> indirectly included by another header and thus the code compiles. Even if
> there are references.
> And there are no rules/guidelines to identify the headers that should be
> included and those that should not.
Documentation/SubmitChecklist, #1:
1: If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Christoph Paasch @ 2011-01-10 16:24 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <20110110075032.e38955ef.rdunlap@xenotime.net>
On Monday, January 10, 2011 wrote Randy Dunlap:
> Documentation/SubmitChecklist, #1:
>
> 1: If you use a facility then #include the file that defines/declares
> that facility. Don't depend on other header files pulling in ones
> that you use.
Ok, great. That was the answer I was looking for.
So, there is a clear rule that defines the #include-policy.
Now, should the missing #include's be added, or not?
Alexey Dobriyan is against it, as he says in one of his previous mails.
And, I'm nearly sure that the rule is not respected in plenty of other files
of the Linux Kernel.
Cheers,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Randy Dunlap @ 2011-01-10 16:30 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <201101101724.46023.christoph.paasch@uclouvain.be>
On Mon, 10 Jan 2011 17:24:45 +0100 Christoph Paasch wrote:
>
> On Monday, January 10, 2011 wrote Randy Dunlap:
> > Documentation/SubmitChecklist, #1:
> >
> > 1: If you use a facility then #include the file that defines/declares
> > that facility. Don't depend on other header files pulling in ones
> > that you use.
> Ok, great. That was the answer I was looking for.
>
> So, there is a clear rule that defines the #include-policy.
>
> Now, should the missing #include's be added, or not?
>
> Alexey Dobriyan is against it, as he says in one of his previous mails.
> And, I'm nearly sure that the rule is not respected in plenty of other files
> of the Linux Kernel.
If a build fails on any $architecture due to a missing header file, then
the header file should be added.
If you just want to fix source files that are missing header files, then
the patches should be accepted, even if they are not "needed" in some
strong sense of that word.
Adding the header files adds documentation that some interface from that
header file is being used and it prevents failures that would happen
if an indirect #include were removed, so it's a good practice, but sure,
there are plenty of places that miss this. It was added as Rule #1
(explicity as Rule __#1__) due to so many build errors due to this
that were occurring in linux-next trees.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 0/3] iproute2: ip link: add support for network device groups
From: Stephen Hemminger @ 2011-01-10 16:47 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev, jamal, Octavian Purdila
In-Reply-To: <1294659559-22648-1-git-send-email-ddvlad@rosedu.org>
On Mon, 10 Jan 2011 13:39:16 +0200
Vlad Dogaru <ddvlad@rosedu.org> wrote:
> This patch series adds userspace support for network device groups.
> There is support for setting device groups, listing only interfaces of a
> specific group, and setting basic device parameters for all interfaces
> in a group.
>
> The patches use the IFLA_GROUP and IFLA_FILTERGROUP messages, for which
> I posted pathes in a different set.
>
>
> Vlad Dogaru (3):
> ip link: add support for setting device groups
> ip link: support listing devices by group
> ip link: support setting device parameters by group
>
> include/linux/if_link.h | 3 ++
> include/linux/netdevice.h | 2 +-
> include/utils.h | 3 +-
> ip/ipaddress.c | 14 +++++++++++
> ip/iplink.c | 54 +++++++++++++++++++++++++++++++++++++++++++-
> ip/link_veth.c | 3 +-
> 6 files changed, 74 insertions(+), 5 deletions(-)
I like the idea, but I wonder if we should take it farther?
Should it be hierarchal tree of groups?
Should slave devices (ppp, vlan, etc) be automatically assigned
to group of parent?
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 16:49 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <AANLkTikigXGSACF6R6kfNHyKZ7GFWrUrCMxygvL3fUC6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2011-01-10 at 06:07 +0900, Kuwahara,T. wrote:
> On Sun, Jan 9, 2011 at 2:50 AM, Richard Cochran
> <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > we want to be able to jump the clock arbitrarily.
>
> Another problem remains: How do you deal with leap seconds? I mean,
> given that 1 minute is not always 60 seconds, then what time was it
> XXXXX seconds ago? Maybe some kind of lookup table is necessary, but
> in such case, isn't it a better choice just to use the
> clock_settime/settimeofday syscall?
Leapsecond processing is done via an absolute hrtimer. Thus when the
time offset is set, the hrtimers that should have expired will fire
(just like with settimeofday) and the adjustment will then be made.
thanks
-john
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Alexey Dobriyan @ 2011-01-10 17:02 UTC (permalink / raw)
To: Randy Dunlap; +Cc: christoph.paasch, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <20110110083024.ab3bad25.rdunlap@xenotime.net>
On Mon, Jan 10, 2011 at 6:30 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> If you just want to fix source files that are missing header files, then
> the patches should be accepted, even if they are not "needed" in some
> strong sense of that word.
This will create a lot of noise. As if we haven't seen enough before.
^ permalink raw reply
* Re: [PATCH] Move an assert under DEBUG_KERNEL. (attempt 2)
From: Randy Dunlap @ 2011-01-10 17:19 UTC (permalink / raw)
To: Rob Landley; +Cc: Andrew Morton, trivial, linux-kernel, linux-embedded, netdev
In-Reply-To: <4D2AC4D5.5070503@parallels.com>
On Mon, 10 Jan 2011 02:35:33 -0600 Rob Landley wrote:
> On 01/06/2011 05:41 PM, Andrew Morton wrote:
> > Probably a worthwhile thing to do, IMO. If there's some net-specific
> > CONFIG_DEBUG_ setting then that wold be a better thing to use.
> >
> > However the patch was a) wordwrapped, b) space-stuffed and c) not cc'ed
> > to the networking list. So its prospects are dim.
>
> Ok, either I've beaten thunderbird into submission, or I'll be submitting a patch to Documentation/email-clients.txt. (Whether or not I need to find a different smtp server to send this through remains an open question.)
>
> (Confirming: I looked for a more specific DEBUG symbol, but couldn't find one. I can add one, but this seems a bit small to have its own symbol, and DEBUG_KERNEL is already used in a few *.c files.)
>
> From: Rob Landley <rlandley@parallels.com>
>
> Move an assert under DEBUG_KERNEL. (Minor cleanup to save a few bytes.)
>
> Signed-off-by: Rob Landley <rlandley@parallels.com>
> ---
>
> include/linux/rtnetlink.h | 4 ++++
> 1 file changed, 4 insertions(+)
Hm, cc to linux-net should be to netdev instead (so I changed it).
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index bbad657..28c4025 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -782,6 +782,7 @@ extern struct netdev_queue *dev_ingress_queue_create(struct net_device *dev);
> extern void rtnetlink_init(void);
> extern void __rtnl_unlock(void);
>
> +#ifdef CONFIG_DEBUG_KERNEL
> #define ASSERT_RTNL() do { \
> if (unlikely(!rtnl_is_locked())) { \
> printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \
> @@ -789,6 +790,9 @@ extern void __rtnl_unlock(void);
> dump_stack(); \
> } \
> } while(0)
> +#else
> +#define ASSERT_RTNL()
> +#endif
Empty macros in Linux usually take the (preferred) form of this one from kernel.h:
#define might_resched() do { } while (0)
although it's up to DaveM in this case.
>
> static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
> {
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Stephen Hemminger @ 2011-01-10 17:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294667210.3491.7.camel@edumazet-laptop>
On Mon, 10 Jan 2011 14:46:50 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
>
> >
> > The problem is that large tables of pointers in kernel require either
> > contiguous allocation or some indirect table algorithm.
> >
>
> Here is a v3 version with an array based queue for O(1) peek_random
> complexity.
>
> Could you send the iproute2 patch so that I can test it ?
>
> Thanks !
>
>
> diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
> index e69de29..ea9db00 100644
> --- a/net/sched/sch_choke.c
> +++ b/net/sched/sch_choke.c
> @@ -0,0 +1,388 @@
> +/*
> + * net/sched/sch_choke.c CHOKE scheduler
> + *
> + * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
> + * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/skbuff.h>
> +#include <linux/reciprocal_div.h>
> +#include <net/pkt_sched.h>
> +#include <net/inet_ecn.h>
> +#include <net/red.h>
> +
> +/* CHOKe stateless AQM for fair bandwidth allocation
> + =================================================
> +
> + CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
> + unresponsive flows) is a variant of RED that penalizes misbehaving flows but
> + maintains no flow state. The difference from RED is an additional step
> + during the enqueuing process. If average queue size is over the
> + low threshold (qmin), a packet is chosen at random from the queue.
> + If both the new and chosen packet are from the same flow, both
> + are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
> + needs to access packets in queue randomly.
> +
> + Source:
> + R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
> + Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
> + IEEE INFOCOM, 2000.
> +
> + A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
> + Characteristics", IEEE/ACM Transactions on Networking, 2004
> +
> + */
> +
> +struct choke_sched_data {
> + u32 limit;
> + unsigned char flags;
> +
> + struct red_parms parms;
> + struct red_stats stats;
> +
> + unsigned int head;
> + unsigned int tail;
> + unsigned int holes;
> + unsigned int tab_mask; /* size - 1 */
> + struct sk_buff **tab;
> +};
> +
> +static inline unsigned int choke_len(const struct choke_sched_data *q)
> +{
> + return (q->tail - q->head) & q->tab_mask;
> +}
> +
> +/* deliver a random number between 0 and N - 1 */
> +static inline u32 random_N(unsigned int N)
> +{
> + return reciprocal_divide(random32(), N);
> +}
> +
> +/* Select a packet at random from the queue in O(1) */
> +static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
> +{
> + *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
> + return q->tab[*pidx];
> +}
I don't think this works right. The choke_peek_random could find a hole.
Either the data structure has to change, or the peek_random has to retry,
or if quick peek fails then compress the slot with memmove and retry.
--
^ permalink raw reply
* [PATCH v1] TCPCT sysctl API update to draft -02
From: William Allen Simpson @ 2011-01-10 17:48 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: Eric W. Biederman, Stephen Hemminger, Andi Kleen
In-Reply-To: <4D28D8EF.5010008@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
Circa 15 months ago, my first submitted patch was a sysctl, and there was a
conflict that appeared in a later merge of trees. Experts, am I in the right
ballpark this time around?
Later, I'll submit the manpage patch to linux-man@vger.kernel.org too.
===
Use most recently specified symbols of RFC-to-be-6013.
Allows different global s_data limits for SYN and SYN_ACK.
Signed-off-by: William.Allen.Simpson@gmail.com
---
include/net/tcp.h | 2 ++
net/ipv4/sysctl_net_ipv4.c | 25 ++++++++++++++++++++++++-
net/ipv4/tcp_output.c | 19 +++++++++++++++++--
3 files changed, 43 insertions(+), 3 deletions(-)
[-- Attachment #2: TCPCT+API-02u1+2.6.37.patch --]
[-- Type: text/plain, Size: 3327 bytes --]
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 38509f0..3ac2bca 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -241,6 +241,8 @@ extern int sysctl_tcp_workaround_signed_windows;
extern int sysctl_tcp_slow_start_after_idle;
extern int sysctl_tcp_max_ssthresh;
extern int sysctl_tcp_cookie_size;
+extern int sysctl_tcp_syn_data_limit;
+extern int sysctl_tcp_syn_ack_data_limit;
extern int sysctl_tcp_thin_linear_timeouts;
extern int sysctl_tcp_thin_dupack;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 1a45665..629f90b 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -30,6 +30,9 @@ static int tcp_adv_win_scale_min = -31;
static int tcp_adv_win_scale_max = 31;
static int ip_ttl_min = 1;
static int ip_ttl_max = 255;
+static int tcp_cookie_max = TCP_COOKIE_MAX;
+static int tcp_syn_data_max = TCP_MSS_DEFAULT - 40;
+static int tcp_syn_ack_data_max = TCP_MSS_DESIRED;
/* Update system visible IP port range */
static void set_local_port_range(int range[2])
@@ -588,7 +591,27 @@ static struct ctl_table ipv4_table[] = {
.data = &sysctl_tcp_cookie_size,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &tcp_cookie_max,
+ },
+ {
+ .procname = "tcp_syn_data_limit",
+ .data = &sysctl_tcp_syn_data_limit,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &tcp_syn_data_max,
+ },
+ {
+ .procname = "tcp_syn_ack_data_limit",
+ .data = &sysctl_tcp_syn_ack_data_limit,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &tcp_syn_ack_data_max,
},
{
.procname = "tcp_thin_linear_timeouts",
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index dc7c096..3bd3da5 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -63,6 +63,15 @@ int sysctl_tcp_slow_start_after_idle __read_mostly = 1;
int sysctl_tcp_cookie_size __read_mostly = 0; /* TCP_COOKIE_MAX */
EXPORT_SYMBOL_GPL(sysctl_tcp_cookie_size);
+int sysctl_tcp_syn_data_limit __read_mostly = TCP_MSS_DEFAULT - 40;
+EXPORT_SYMBOL_GPL(sysctl_tcp_syn_data_limit);
+
+/* As a matter of security policy, keep the initial setting small for most
+ * client systems to avoid their use in amplification DoS attacks.
+ */
+int sysctl_tcp_syn_ack_data_limit __read_mostly = 80; /* TCP_MSS_DESIRED */
+EXPORT_SYMBOL_GPL(sysctl_tcp_syn_ack_data_limit);
+
/* Account for new data that has been sent to the network. */
static void tcp_event_new_data_sent(struct sock *sk, struct sk_buff *skb)
@@ -2418,10 +2427,16 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
struct tcp_md5sig_key *md5;
int tcp_header_size;
int mss;
- int s_data_desired = 0;
+ int s_data_desired;
- if (cvp != NULL && cvp->s_data_constant && cvp->s_data_desired)
+ if (cvp != NULL &&
+ cvp->s_data_constant &&
+ cvp->s_data_desired > 0 &&
+ cvp->s_data_desired <= sysctl_tcp_syn_ack_data_limit)
s_data_desired = cvp->s_data_desired;
+ else
+ s_data_desired = 0;
+
skb = sock_wmalloc(sk, MAX_TCP_HEADER + 15 + s_data_desired, 1, GFP_ATOMIC);
if (skb == NULL)
return NULL;
--
1.7.1
^ permalink raw reply related
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-10 17:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110110093123.5431b368@nehalam>
Le lundi 10 janvier 2011 à 09:31 -0800, Stephen Hemminger a écrit :
> On Mon, 10 Jan 2011 14:46:50 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
> >
> > >
> > > The problem is that large tables of pointers in kernel require either
> > > contiguous allocation or some indirect table algorithm.
> > >
> >
> > Here is a v3 version with an array based queue for O(1) peek_random
> > complexity.
> >
> > Could you send the iproute2 patch so that I can test it ?
> >
> > Thanks !
> >
> >
> > diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
> > index e69de29..ea9db00 100644
> > --- a/net/sched/sch_choke.c
> > +++ b/net/sched/sch_choke.c
> > @@ -0,0 +1,388 @@
> > +/*
> > + * net/sched/sch_choke.c CHOKE scheduler
> > + *
> > + * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
> > + * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/kernel.h>
> > +#include <linux/skbuff.h>
> > +#include <linux/reciprocal_div.h>
> > +#include <net/pkt_sched.h>
> > +#include <net/inet_ecn.h>
> > +#include <net/red.h>
> > +
> > +/* CHOKe stateless AQM for fair bandwidth allocation
> > + =================================================
> > +
> > + CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
> > + unresponsive flows) is a variant of RED that penalizes misbehaving flows but
> > + maintains no flow state. The difference from RED is an additional step
> > + during the enqueuing process. If average queue size is over the
> > + low threshold (qmin), a packet is chosen at random from the queue.
> > + If both the new and chosen packet are from the same flow, both
> > + are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
> > + needs to access packets in queue randomly.
> > +
> > + Source:
> > + R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
> > + Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
> > + IEEE INFOCOM, 2000.
> > +
> > + A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
> > + Characteristics", IEEE/ACM Transactions on Networking, 2004
> > +
> > + */
> > +
> > +struct choke_sched_data {
> > + u32 limit;
> > + unsigned char flags;
> > +
> > + struct red_parms parms;
> > + struct red_stats stats;
> > +
> > + unsigned int head;
> > + unsigned int tail;
> > + unsigned int holes;
> > + unsigned int tab_mask; /* size - 1 */
> > + struct sk_buff **tab;
> > +};
> > +
> > +static inline unsigned int choke_len(const struct choke_sched_data *q)
> > +{
> > + return (q->tail - q->head) & q->tab_mask;
> > +}
> > +
> > +/* deliver a random number between 0 and N - 1 */
> > +static inline u32 random_N(unsigned int N)
> > +{
> > + return reciprocal_divide(random32(), N);
> > +}
> > +
> > +/* Select a packet at random from the queue in O(1) */
> > +static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
> > +{
> > + *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
> > + return q->tab[*pidx];
> > +}
>
> I don't think this works right. The choke_peek_random could find a hole.
> Either the data structure has to change, or the peek_random has to retry,
> or if quick peek fails then compress the slot with memmove and retry.
>
>
Yes, this "compress only if peek_random() finds a hole seems good, I'll
try this.
As number of holes is known, we could have :
if (holes_proportion_is_less_than_20_percent())
try another random number X times
else
compress table to remove holes.
^ permalink raw reply
* RE: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-01-10 18:48 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110107142750.21ea39f0@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Saturday, January 08, 2011 3:58 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Thu, 23 Dec 2010 11:24:36 -0800
> <Narendra_K@Dell.com> wrote:
>
> > On Thu, Dec 23, 2010 at 08:02:03PM +0530, Domsch, Matt wrote:
> > > On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com
> wrote:
> > > > Hello,
> > > >
> > > > This patch exports ACPI _DSM provided firmware instance number
> and
> > > > string name to sysfs.
> > > >
> > > > Please review -
> > >
> > > There are now two different meanings for the 'index' file:
> > >
> > > 1) SMBIOS-provided "type instance" value, which I've only seen in
> > > range [1..N] for N devices, monotonically stepwise increasing.
> > >
> > > 2) ACPI-provided "index" value, which per spec only needs to be a
> > > "sort key", not starting at 0 or 1, and while monotonically
> > > increasing, not necessarily stepwise. It's perfectly valid for
> the
> > > values to be (12, 16, 27, 29) if that's convenient for BIOS to
> > > generate.
> > >
> > > Therefore, a consumer of this value (such as biosdevname) must know
> > > which of the two it's dealing with, and either accept the value as-
> is,
> > > or sort the value list. While I suppose it could sort the value
> list
> > > in either case, I'd prefer the ACPI value to be exposed in its own
> > > file, perhaps 'acpi_index', to make this explicit rather than
> > > implicit.
> > >
> > > 'label' is fine for either case, with ACPI taking priority over
> > > SMBIOS if both happen to be present.
> > >
>
> Applied, thanks.
Jesse,
Thank you.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Jesse Barnes @ 2011-01-10 19:13 UTC (permalink / raw)
To: Narendra_K
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <E31FB011129F30488D5861F3839049151D10F8EF9D@BLRX7MCDC201.AMER.DELL.COM>
On Mon, 10 Jan 2011 10:48:26 -0800
<Narendra_K@Dell.com> wrote:
> > > > 'label' is fine for either case, with ACPI taking priority over
> > > > SMBIOS if both happen to be present.
> > > >
> >
> > Applied, thanks.
>
> Jesse,
>
> Thank you.
Not sure if you saw it yet, but the patch caused a build breakage. Can
you send me a replacement patch with a fix asap?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: panic in tg3 driver
From: Matt Carlson @ 2011-01-10 19:22 UTC (permalink / raw)
To: Stephen Clark
Cc: Linux Kernel Network Developers, Michael Chan, Matthew Carlson
In-Reply-To: <4D2A371A.40103@earthlink.net>
On Sun, Jan 09, 2011 at 02:30:50PM -0800, Stephen Clark wrote:
> On 01/04/2011 09:54 AM, Stephen Clark wrote:
> > Hello,
> >
> >
> > The hardware is an Acrosser AR-M0898B micro box.
> > lspci
> > 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
> > 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
> > 00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 Serial ATA
> > Controller (rev
> > 20)
> > 00:0f.1 IDE interface: VIA Technologies, Inc.
> > VT82C586A/B/VT82C686/A/B/VT823x/A/
> > C PIPC Bus Master IDE (rev 07)
> > 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
> > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
> > 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
> > 00:13.0 Host bridge: VIA Technologies, Inc. VT8251 Host Bridge
> > 00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
> > 02:08.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
> > (rev 02)
> > 02:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
> > (rev 02)
> > 80:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
> > 80:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
> > 81:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
> > Fast Ethernet
> > PCI Express (rev 02)
> > 82:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
> > Fast Ethernet
> > PCI Express (rev 02)
> >
> > Kernel 2.6.36-2.el5.elrepo on an i686
> >
> > When I try to ifconfig either of the BCM5906M ports the system panics.
> >
> > Ideas, fixes ?
> >
> > [root@Z1010 ~]# modprobe tg3
> > [root@Z1010 ~]# ifconfig eth2 2.2.2.2/24
> > ------------[ cut here ]------------
> > kernel BUG at drivers/net/tg3.c:4365!
> > invalid opcode: 0000 [#1] PREEMPT SMP
> > last sysfs file: /sys/class/net/eth3/address
> > Modules linked in: tg3 xt_tcpudp ipt_LOG xt_limit xt_state
> > iptable_mangle af_ke]
> >
> > Pid: 20303, comm: kworker/0:2 Not tainted 2.6.36-2.el5.elrepo #1
> > CN700-8251/
> > EIP: 0060:[<e1c62f19>] EFLAGS: 00010202 CPU: 0
> > EIP is at tg3_tx_recover+0x1e/0x53 [tg3]
> > EAX: deece4c0 EBX: dfa9c000 ECX: deece4c0 EDX: ffffffff
> > ESI: deece4c0 EDI: deece500 EBP: c1801f38 ESP: c1801f30
> > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > Process kworker/0:2 (pid: 20303, ti=c1801000 task=df0105d0
> > task.ti=dee62000)
> > Stack:
> > dfa9c000 00000000 c1801f6c e1c630be c1801f6c deece4c0 00000840 00000000
> > <0> df251cc0 00000005 00000000 df979800 deece500 deece4c0 00000040
> > c1801f94
> > <0> e1c661e5 00000000 00000040 c1801f88 e09df1d2 00000000 deece500
> > dfab4000
> > Call Trace:
> > [<e1c630be>] ? tg3_tx+0x157/0x1a2 [tg3]
> > [<e1c661e5>] ? tg3_poll_work+0x2b/0x10b [tg3]
> > [<e09df1d2>] ? ssb_write32+0x11/0x14 [b44]
> > [<e1c662f9>] ? tg3_poll+0x34/0x9a [tg3]
> > [<c0674058>] ? net_rx_action+0x7e/0x11c
> > [<c04409c9>] ? __do_softirq+0x85/0x10c
> > [<c0440944>] ? __do_softirq+0x0/0x10c
> > <IRQ>
> > [<c04404ef>] ? _local_bh_enable_ip+0x68/0x87
> > [<c044051b>] ? local_bh_enable_ip+0xd/0xf
> > [<c046593b>] ? __raw_spin_unlock_bh+0x1c/0x1e
> > [<c06fa4f2>] ? _raw_spin_unlock_bh+0xd/0xf
> > [<e1c6281f>] ? spin_unlock_bh+0xd/0xf [tg3]
> > [<e1c62cbe>] ? tg3_full_unlock+0x10/0x12 [tg3]
> > [<e1c664c7>] ? tg3_reset_task+0xd7/0xe3 [tg3]
> > [<c044ec37>] ? process_one_work+0x10b/0x1bc
> > [<e1c663f0>] ? tg3_reset_task+0x0/0xe3 [tg3]
> > [<c044fd41>] ? worker_thread+0x77/0xf9
> > [<c0453048>] ? kthread+0x60/0x65
> > [<c044fcca>] ? worker_thread+0x0/0xf9
> > [<c0452fe8>] ? kthread+0x0/0x65
> > [<c040337e>] ? kernel_thread_helper+0x6/0x10
> > Code: f0 e8 88 ff ff ff 8d 65 f8 5b 5e 5d c3 55 89 e5 56 53 0f 1f 44
> > 00 00 f6 8
> > EIP: [<e1c62f19>] tg3_tx_recover+0x1e/0x53 [tg3] SS:ESP 0068:c1801f30
> > ---[ end trace 82381e9b93e397ad ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Pid: 20303, comm: kworker/0:2 Tainted: G D
> > 2.6.36-2.el5.elrepo #1
> > Call Trace:
> > [<c043b3cd>] panic+0x62/0x15d
> > [<c06fb7d1>] oops_end+0x99/0xa8
> > [<e1c62f19>] ? tg3_tx_recover+0x1e/0x53 [tg3]
> > [<c0405a62>] die+0x58/0x5e
> >
> > Thanks,
> > Steve
> >
> Additonal info I compiled the latest kernel 2.6.37-rc8+ and still have the problem.
> Also boot with noapic I see this in the dmesg log and interrupts are increasing
> like crazy:
> tg3.c:v3.115 (October 14, 2010)
> tg3 0000:81:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
> tg3 0000:81:00.0: setting latency timer to 64
> tg3 0000:81:00.0: PCI: Disallowing DAC for device
> tg3 0000:81:00.0: eth2: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
> ress 00:02:b6:36:d1:39
> tg3 0000:81:00.0: eth2: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
> [0])
> tg3 0000:81:00.0: eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> tg3 0000:81:00.0: eth2: dma_rwctrl[76180000] dma_mask[32-bit]
> tg3 0000:82:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
> tg3 0000:82:00.0: setting latency timer to 64
> tg3 0000:82:00.0: PCI: Disallowing DAC for device
> tg3 0000:82:00.0: eth3: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
> ress 00:02:b6:36:d1:3a
> tg3 0000:82:00.0: eth3: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
> [0])
> tg3 0000:82:00.0: eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> tg3 0000:82:00.0: eth3: dma_rwctrl[76180000] dma_mask[32-bit]
> tg3 0000:81:00.0: irq 40 for MSI/MSI-X
> tg3 0000:81:00.0: eth2: No interrupt was generated using MSI. Switching to INTx
> mode. Please report this failure to the PCI maintainer and include system chipse
> t information
> ADDRCONF(NETDEV_UP): eth2: link is not ready
> [root@Z1010 ~]# cat /proc/interrupts
> CPU0
> 0: 162 XT-PIC-XT-PIC timer
> 1: 2 XT-PIC-XT-PIC i8042
> 2: 0 XT-PIC-XT-PIC cascade
> 3: 1 XT-PIC-XT-PIC
> 4: 4863 XT-PIC-XT-PIC serial
> 6: 2 XT-PIC-XT-PIC floppy
> 7: 5 XT-PIC-XT-PIC ehci_hcd:usb1, uhci_hcd:usb3
> 8: 0 XT-PIC-XT-PIC rtc0
> 9: 0 XT-PIC-XT-PIC acpi
> 10: 2334234 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>
> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
> 10: 18388914 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
> 10: 18901627 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>
> --
>
> "They that give up essential liberty to obtain temporary safety,
> deserve neither liberty nor safety." (Ben Franklin)
>
> "The course of history shows that as a government grows, liberty
> decreases." (Thomas Jefferson)
I think drivers/net/tg3.c:4365 is at the line that reads
"spin_lock(&tp->lock);" in tg3_tx_recover. Can you verify?
^ permalink raw reply
* RE: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-01-10 19:35 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110110111300.58e6bbea@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Tuesday, January 11, 2011 12:43 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Mon, 10 Jan 2011 10:48:26 -0800
> <Narendra_K@Dell.com> wrote:
> > > > > 'label' is fine for either case, with ACPI taking priority over
> > > > > SMBIOS if both happen to be present.
> > > > >
> > >
> > > Applied, thanks.
> >
> > Jesse,
> >
> > Thank you.
>
> Not sure if you saw it yet, but the patch caused a build breakage. Can
> you send me a replacement patch with a fix asap?
>
> Thanks,
Just saw it now. Sorry for the inconvenience. I took the patch against linux-2.6 where I did not see the failure. I am pulling the linux-next now, will get this resolved first thing tomorrow.
With regards,
Narendra K
^ permalink raw reply
* [Bug 24592] Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2011-01-10 20:09 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <20110110.000813.173856001.davem@davemloft.net>
On Monday, January 10, 2011, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> > Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> > Date : 2010-12-08 21:09 (22 days old)
>
> This bug is intended to be fixed by:
>
> commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
> Author: David S. Miller <davem@davemloft.net>
> Date: Wed Jan 5 15:38:53 2011 -0800
>
> af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
>
> unix_release() can asynchornously set socket->sk to NULL, and
> it does so without holding the unix_state_lock() on "other"
> during stream connects.
>
> However, the reverse mapping, sk->sk_socket, is only transitioned
> to NULL under the unix_state_lock().
>
> Therefore make the security hooks follow the reverse mapping instead
> of the forward mapping.
>
> Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2011-01-10 20:11 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <20110110.000813.173856001.davem@davemloft.net>
On Monday, January 10, 2011, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> > Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> > Date : 2010-12-08 21:09 (22 days old)
> > Message-ID : <4CFFF3F3.90100@goop.org>
> > References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
>
> This bug is intended to be fixed by:
>
> commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
> Author: David S. Miller <davem@davemloft.net>
> Date: Wed Jan 5 15:38:53 2011 -0800
>
> af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
>
> unix_release() can asynchornously set socket->sk to NULL, and
> it does so without holding the unix_state_lock() on "other"
> during stream connects.
>
> However, the reverse mapping, sk->sk_socket, is only transitioned
> to NULL under the unix_state_lock().
>
> Therefore make the security hooks follow the reverse mapping instead
> of the forward mapping.
>
> Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
OK, thanks for the info, closing.
Rafael
^ permalink raw reply
* Re: [PATCH V8 12/13] ptp: Added a clock driver for the IXP46x.
From: Krzysztof Halasa @ 2011-01-10 20:24 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20110107170752.GB8666-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> But before that, I have a big favor to ask you. Can you please look at
> the TODO in my patch and give me a hint? I don't know how to relate
> the port instance (NPE A,B,C) to the two time stamping channels.
I assume you mean this:
+ * PHYSICAL_ID(p->id) ?
+ * TODO - Figure out correct mapping.
Unfortunately I can's find this information in the devel manual. I think
there are 3 channels (not two), each for one Ethernet port. IXP465 can
have a port on each NPE.
PHYSICAL_ID etc. are described at the start of the file:
* logical port 0x00 0x10 0x20
* NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
* physical PortId 2 0 1
This means the first port (usually "eth0") is connected to NPE-B, the
second port to NPE-C, and the third port to NPE-A (not available on
IXP42x).
Also, the manual says NPE-B can serve 3 additional Ethernet ports
(6 total).
I only have access to IXP425 (and 421) hardware. I think someone with
the actual IXP465 has to check the details.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: Kuwahara,T. @ 2011-01-10 20:45 UTC (permalink / raw)
To: john stultz
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <1294678145.3068.6.camel@work-vm>
On Tue, Jan 11, 2011 at 1:49 AM, john stultz <johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> Leapsecond processing is done via an absolute hrtimer. Thus when the
> time offset is set, the hrtimers that should have expired will fire
> (just like with settimeofday) and the adjustment will then be made.
How do you convert relative time to absolute time? It's not trivial
because TAI offset is also a variable.
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: Kuwahara,T. @ 2011-01-10 20:47 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <20110110071759.GA4864-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
On Mon, Jan 10, 2011 at 4:17 PM, Richard Cochran
<richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> the PTP Hardware Clocks for which this whole patch
> set was created in the first place will keep their time as TAI.
Are you sure of that? I don't have the standard handy (it's non-free,
right?) but it seems that the Annex B states differently. But that's
not the point anyway. My concern is that your patch not only adds the
useless (and broken) feature to the existing syscall but also makes a
permanent change to the public interface for your own use. That's
what I'm against. So if you stop touching the struct timex, I won't
complain anymore.
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 21:06 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <AANLkTikdg4Pb5c4wcCU3d3Eku=mpiW_TEkBz0A2VPdVp-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2011-01-11 at 05:45 +0900, Kuwahara,T. wrote:
> On Tue, Jan 11, 2011 at 1:49 AM, john stultz <johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> > Leapsecond processing is done via an absolute hrtimer. Thus when the
> > time offset is set, the hrtimers that should have expired will fire
> > (just like with settimeofday) and the adjustment will then be made.
>
> How do you convert relative time to absolute time? It's not trivial
> because TAI offset is also a variable.
I don't believe I understand what you're getting at.
The proposed interface is almost identical in functionality to a
userland application doing the following:
offset = my_calculate_offset();
clock_gettime(CLOCK_REALTIME, &now);
newtime = my_add_ts(now, offset);
settimeofday(&newtime, 0);
The only difference is that you avoid the error from the delay between
the gettime call and the settime call. It just adds the offset directly
to the CLOCK_REALTIME.
thanks
-john
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 21:11 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel, linux-api, netdev, Alan Cox,
Arnd Bergmann, Christoph Lameter, David Miller, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <AANLkTimS0-ih=WZ_GvPi9NFjbYMT4OctWV943ri4GuTD@mail.gmail.com>
On Tue, 2011-01-11 at 05:47 +0900, Kuwahara,T. wrote:
> On Mon, Jan 10, 2011 at 4:17 PM, Richard Cochran
> <richardcochran@gmail.com> wrote:
> > the PTP Hardware Clocks for which this whole patch
> > set was created in the first place will keep their time as TAI.
>
> Are you sure of that? I don't have the standard handy (it's non-free,
> right?) but it seems that the Annex B states differently. But that's
> not the point anyway. My concern is that your patch not only adds the
> useless (and broken) feature to the existing syscall but also makes a
> permanent change to the public interface for your own use. That's
> what I'm against. So if you stop touching the struct timex, I won't
> complain anymore.
You still haven't explained *why* you're so protective of the timex and
adjtimex interfaces. While I do want to keep compatible the
functionality where possible, I don't see why Linux should be limited by
what other OSes do.
Injecting an offset to the system time seems like a reasonable thing for
adjtimex to do (rather then adding a new syscall). Further utilizing a
new mode bit for this functionality seems reasonable and cleaner then
your suggestions for utilizing existing mode bits in combined with other
magic bits. If there is a compelling reason why not to do this, do
please let us know! We might just agree with you after hearing it. :)
thanks
-john
^ permalink raw reply
* Re: panic in tg3 driver
From: Stephen Clark @ 2011-01-10 20:04 UTC (permalink / raw)
To: Matt Carlson; +Cc: Linux Kernel Network Developers, Michael Chan
In-Reply-To: <20110110192216.GA23741@mcarlson.broadcom.com>
On 01/10/2011 02:22 PM, Matt Carlson wrote:
> On Sun, Jan 09, 2011 at 02:30:50PM -0800, Stephen Clark wrote:
>
>> On 01/04/2011 09:54 AM, Stephen Clark wrote:
>>
>>> Hello,
>>>
>>>
>>> The hardware is an Acrosser AR-M0898B micro box.
>>> lspci
>>> 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
>>> 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
>>> 00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 Serial ATA
>>> Controller (rev
>>> 20)
>>> 00:0f.1 IDE interface: VIA Technologies, Inc.
>>> VT82C586A/B/VT82C686/A/B/VT823x/A/
>>> C PIPC Bus Master IDE (rev 07)
>>> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
>>> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
>>> 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
>>> 00:13.0 Host bridge: VIA Technologies, Inc. VT8251 Host Bridge
>>> 00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
>>> 02:08.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
>>> (rev 02)
>>> 02:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
>>> (rev 02)
>>> 80:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
>>> 80:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
>>> 81:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
>>> Fast Ethernet
>>> PCI Express (rev 02)
>>> 82:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
>>> Fast Ethernet
>>> PCI Express (rev 02)
>>>
>>> Kernel 2.6.36-2.el5.elrepo on an i686
>>>
>>> When I try to ifconfig either of the BCM5906M ports the system panics.
>>>
>>> Ideas, fixes ?
>>>
>>> [root@Z1010 ~]# modprobe tg3
>>> [root@Z1010 ~]# ifconfig eth2 2.2.2.2/24
>>> ------------[ cut here ]------------
>>> kernel BUG at drivers/net/tg3.c:4365!
>>> invalid opcode: 0000 [#1] PREEMPT SMP
>>> last sysfs file: /sys/class/net/eth3/address
>>> Modules linked in: tg3 xt_tcpudp ipt_LOG xt_limit xt_state
>>> iptable_mangle af_ke]
>>>
>>> Pid: 20303, comm: kworker/0:2 Not tainted 2.6.36-2.el5.elrepo #1
>>> CN700-8251/
>>> EIP: 0060:[<e1c62f19>] EFLAGS: 00010202 CPU: 0
>>> EIP is at tg3_tx_recover+0x1e/0x53 [tg3]
>>> EAX: deece4c0 EBX: dfa9c000 ECX: deece4c0 EDX: ffffffff
>>> ESI: deece4c0 EDI: deece500 EBP: c1801f38 ESP: c1801f30
>>> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>>> Process kworker/0:2 (pid: 20303, ti=c1801000 task=df0105d0
>>> task.ti=dee62000)
>>> Stack:
>>> dfa9c000 00000000 c1801f6c e1c630be c1801f6c deece4c0 00000840 00000000
>>> <0> df251cc0 00000005 00000000 df979800 deece500 deece4c0 00000040
>>> c1801f94
>>> <0> e1c661e5 00000000 00000040 c1801f88 e09df1d2 00000000 deece500
>>> dfab4000
>>> Call Trace:
>>> [<e1c630be>] ? tg3_tx+0x157/0x1a2 [tg3]
>>> [<e1c661e5>] ? tg3_poll_work+0x2b/0x10b [tg3]
>>> [<e09df1d2>] ? ssb_write32+0x11/0x14 [b44]
>>> [<e1c662f9>] ? tg3_poll+0x34/0x9a [tg3]
>>> [<c0674058>] ? net_rx_action+0x7e/0x11c
>>> [<c04409c9>] ? __do_softirq+0x85/0x10c
>>> [<c0440944>] ? __do_softirq+0x0/0x10c
>>> <IRQ>
>>> [<c04404ef>] ? _local_bh_enable_ip+0x68/0x87
>>> [<c044051b>] ? local_bh_enable_ip+0xd/0xf
>>> [<c046593b>] ? __raw_spin_unlock_bh+0x1c/0x1e
>>> [<c06fa4f2>] ? _raw_spin_unlock_bh+0xd/0xf
>>> [<e1c6281f>] ? spin_unlock_bh+0xd/0xf [tg3]
>>> [<e1c62cbe>] ? tg3_full_unlock+0x10/0x12 [tg3]
>>> [<e1c664c7>] ? tg3_reset_task+0xd7/0xe3 [tg3]
>>> [<c044ec37>] ? process_one_work+0x10b/0x1bc
>>> [<e1c663f0>] ? tg3_reset_task+0x0/0xe3 [tg3]
>>> [<c044fd41>] ? worker_thread+0x77/0xf9
>>> [<c0453048>] ? kthread+0x60/0x65
>>> [<c044fcca>] ? worker_thread+0x0/0xf9
>>> [<c0452fe8>] ? kthread+0x0/0x65
>>> [<c040337e>] ? kernel_thread_helper+0x6/0x10
>>> Code: f0 e8 88 ff ff ff 8d 65 f8 5b 5e 5d c3 55 89 e5 56 53 0f 1f 44
>>> 00 00 f6 8
>>> EIP: [<e1c62f19>] tg3_tx_recover+0x1e/0x53 [tg3] SS:ESP 0068:c1801f30
>>> ---[ end trace 82381e9b93e397ad ]---
>>> Kernel panic - not syncing: Fatal exception in interrupt
>>> Pid: 20303, comm: kworker/0:2 Tainted: G D
>>> 2.6.36-2.el5.elrepo #1
>>> Call Trace:
>>> [<c043b3cd>] panic+0x62/0x15d
>>> [<c06fb7d1>] oops_end+0x99/0xa8
>>> [<e1c62f19>] ? tg3_tx_recover+0x1e/0x53 [tg3]
>>> [<c0405a62>] die+0x58/0x5e
>>>
>>> Thanks,
>>> Steve
>>>
>>>
>> Additonal info I compiled the latest kernel 2.6.37-rc8+ and still have the problem.
>> Also boot with noapic I see this in the dmesg log and interrupts are increasing
>> like crazy:
>> tg3.c:v3.115 (October 14, 2010)
>> tg3 0000:81:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
>> tg3 0000:81:00.0: setting latency timer to 64
>> tg3 0000:81:00.0: PCI: Disallowing DAC for device
>> tg3 0000:81:00.0: eth2: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
>> ress 00:02:b6:36:d1:39
>> tg3 0000:81:00.0: eth2: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
>> [0])
>> tg3 0000:81:00.0: eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> tg3 0000:81:00.0: eth2: dma_rwctrl[76180000] dma_mask[32-bit]
>> tg3 0000:82:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
>> tg3 0000:82:00.0: setting latency timer to 64
>> tg3 0000:82:00.0: PCI: Disallowing DAC for device
>> tg3 0000:82:00.0: eth3: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
>> ress 00:02:b6:36:d1:3a
>> tg3 0000:82:00.0: eth3: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
>> [0])
>> tg3 0000:82:00.0: eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> tg3 0000:82:00.0: eth3: dma_rwctrl[76180000] dma_mask[32-bit]
>> tg3 0000:81:00.0: irq 40 for MSI/MSI-X
>> tg3 0000:81:00.0: eth2: No interrupt was generated using MSI. Switching to INTx
>> mode. Please report this failure to the PCI maintainer and include system chipse
>> t information
>> ADDRCONF(NETDEV_UP): eth2: link is not ready
>> [root@Z1010 ~]# cat /proc/interrupts
>> CPU0
>> 0: 162 XT-PIC-XT-PIC timer
>> 1: 2 XT-PIC-XT-PIC i8042
>> 2: 0 XT-PIC-XT-PIC cascade
>> 3: 1 XT-PIC-XT-PIC
>> 4: 4863 XT-PIC-XT-PIC serial
>> 6: 2 XT-PIC-XT-PIC floppy
>> 7: 5 XT-PIC-XT-PIC ehci_hcd:usb1, uhci_hcd:usb3
>> 8: 0 XT-PIC-XT-PIC rtc0
>> 9: 0 XT-PIC-XT-PIC acpi
>> 10: 2334234 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>>
>> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
>> 10: 18388914 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
>> 10: 18901627 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>>
>> --
>>
>> "They that give up essential liberty to obtain temporary safety,
>> deserve neither liberty nor safety." (Ben Franklin)
>>
>> "The course of history shows that as a government grows, liberty
>> decreases." (Thomas Jefferson)
>>
> I think drivers/net/tg3.c:4365 is at the line that reads
> "spin_lock(&tp->lock);" in tg3_tx_recover. Can you verify?
>
>
tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &phy2);
in static void tg3_serdes_parallel_detect(struct tg3 *tp)
The driver version is:
#define DRV_MODULE_NAME "tg3"
#define TG3_MAJ_NUM 3
#define TG3_MIN_NUM 115
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [PATCH 1/5] netdev: bfin_mac: clean up printk messages
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:29 -0500
> Use netdev_* and pr_* helper funcs for output rather than printk.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/5] netdev: bfin_mac: mark setup_system_regs as static
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-2-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:30 -0500
> No need for this to be exported since it is only used in this driver.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ 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