* 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
* Re: [PATCH 3/5] netdev: bfin_mac: drop unused Mac data
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-3-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:31 -0500
> We don't use this local "Mac" data anywhere (since we rely on the
> netdev's storage), so punt it.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/5] netdev: bfin_mac: let boards set vlan masks
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-4-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:32 -0500
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 5/5] netdev: bfin_mac: disable hardware checksum if writeback cache is enabled
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1294664073-1950-5-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:33 -0500
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> With writeback caches, corrupted RX packets will be sent up the stack
> without any error markings.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] qlcnic: fix flash fw version read
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294654523-3085-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:21 -0800
> Driver is reading flash fw version from defined address, this address
> may be invalid. Indeed Driver should read address for fw version through
> flash layout table. Flash layout table has defined region and address for
> fw version address should be read from fw image region.
>
> Driver has check for old firmware, this bug can cause driver load fail.
> This patch will try to read fw version from flash image region, if that fails,
> read from defined address.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] qlcnic: fix ethtool diagnostics test
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1294654523-3085-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:22 -0800
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> IRQ diag test was getting executed only when both register test
> and link test passed. The test should get executed if ETH_TEST_FL_OFFLINE
> flag is set.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] qlcnic: change module parameter permissions
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294654523-3085-4-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:23 -0800
> o Updating module parameter after driver load is not supported
> except auto_fw_reset parameter. Changing these parameter after
> driver load, can have weird result.
>
> o Update driver version to 5.0.15.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
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