* Re: [PATCH] tg3: Dont dump registers if interface not ready.
From: Xiao Jiang @ 2011-09-29 6:50 UTC (permalink / raw)
To: Joe Jin
Cc: Matt Carlson, Michael Chan, Guru Anbalagane, Gurudas Pai, netdev,
linux-kernel@vger.kernel.org, Greg Marsden
In-Reply-To: <4E83D3B3.7090508@oracle.com>
Joe Jin wrote:
> When bootup the server with BCM5704 Gigabit Ethernet get below warning:
>
> tg3 0000:03:01.0: eth0: DMA Status error. Resetting chip.
> <Registers state of device>
> tg3 0000:03:01.0: eth0: 0: Host status block [00000007:00000002:(0000:0000:0000):(0000:0000)]
> tg3 0000:03:01.0: eth0: 0: NAPI info [00000001:00000002:(0000:0000:01ff):0000:(00c8:0000:0000:0000)]
> tg3 0000:03:01.0: eth0: Link is up at 1000 Mbps, full duplex
> tg3 0000:03:01.0: eth0: Flow control is on for TX and on for RX
> tg3 0000:03:01.0: tg3_stop_block timed out, ofs=4800 enable_bit=2
> tg3 0000:03:01.0: eth0: Link is down
> tg3 0000:03:01.0: eth0: Link is up at 1000 Mbps, full duplex
> tg3 0000:03:01.0: eth0: Flow control is on for TX and on for RX
>
> If device not ready, then would not dump registers info.
>
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Signed-off-by: Guru Anbalagane <guru.anbalagane@oracle.com>
> Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
> Cc: Matt Carlson <mcarlson@broadcom.com>
> Cc: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/tg3.c | 11 +++++++++--
>
Maybe this one should based on net-next tree too, the tg3.c
is lived below ./drivers/net/ethernet/broadcom/ in that tree.
Thanks,
Xiao Jiang
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 4a1374d..d79d344 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -5475,10 +5475,15 @@ static void tg3_process_error(struct tg3 *tp)
> {
> u32 val;
> bool real_error = false;
> + bool dump = true;
>
> if (tg3_flag(tp, ERROR_PROCESSED))
> return;
>
> + /* If interface not ready then dont dump error */
> + if (!netif_carrier_ok(tp->dev))
> + dump = false;
> +
> /* Check Flow Attention register */
> val = tr32(HOSTCC_FLOW_ATTN);
> if (val & ~HOSTCC_FLOW_ATTN_MBUF_LWM) {
> @@ -5492,14 +5497,16 @@ static void tg3_process_error(struct tg3 *tp)
> }
>
> if (tr32(RDMAC_STATUS) || tr32(WDMAC_STATUS)) {
> - netdev_err(tp->dev, "DMA Status error. Resetting chip.\n");
> + if (dump)
> + netdev_err(tp->dev, "DMA Status error. Resetting chip.\n");
> real_error = true;
> }
>
> if (!real_error)
> return;
>
> - tg3_dump_state(tp);
> + if (dump)
> + tg3_dump_state(tp);
>
> tg3_flag_set(tp, ERROR_PROCESSED);
> schedule_work(&tp->reset_task);
>
^ permalink raw reply
* [RFC] IPVS: secure_tcp does provide alternate state timeouts
From: Simon Horman @ 2011-09-29 7:25 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, netdev, netfilter-devel, Simon Horman
* Also reword the test to make it read more easily (to me)
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Julian, I don't see that IPVS currently implements alternate
timeouts for secure_tcp. Am I missing something?
---
Documentation/networking/ipvs-sysctl.txt | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 1dcdd49..13610e3 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
secure_tcp - INTEGER
0 - disabled (default)
- The secure_tcp defense is to use a more complicated state
- transition table and some possible short timeouts of each
- state. In the VS/NAT, it delays the entering the ESTABLISHED
- until the real server starts to send data and ACK packet
- (after 3-way handshake).
+ The secure_tcp defense is to use a more complicated TCP state
+ transition table. For VS/NAT, it also delays entering the
+ TCP ESTABLISHED state until the three way handshake is completed.
- The value definition is the same as that of drop_entry or
+ The value definition is the same as that of drop_entry and
drop_packet.
sync_threshold - INTEGER
--
1.7.5.4
^ permalink raw reply related
* [RFC] IPVS: Enhance grammar used to refer to Kconfig options
From: Simon Horman @ 2011-09-29 7:29 UTC (permalink / raw)
To: Julian Anastasov
Cc: lvs-devel, netdev, netfilter-devel, Randy Dunlap, Simon Horman
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Documentation/networking/ipvs-sysctl.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 13610e3..f2a2488 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -30,7 +30,7 @@ conntrack - BOOLEAN
Connections handled by the IPVS FTP application module
will have connection tracking entries regardless of this setting.
- Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT
+ Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
cache_bypass - BOOLEAN
0 - disabled (default)
@@ -56,7 +56,7 @@ debug_level - INTEGER
11 - IPVS packet handling (ip_vs_in/ip_vs_out)
12 or more - packet traversal
- Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG
+ Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled.
Higher debugging levels include the messages for lower debugging
levels, so setting debug level 2, includes level 0, 1 and 2
--
1.7.5.4
^ permalink raw reply related
* [PATCH] Ipv6: Delete rcu_read_lock
From: rongqing.li @ 2011-09-29 7:46 UTC (permalink / raw)
To: netdev
From: Roy.Li <rongqing.li@windriver.com>
Delete rcu_read_lock, it is redundant.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv6/ndisc.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 9da6e02..dd633ff 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -370,17 +370,14 @@ static int ndisc_constructor(struct neighbour *neigh)
struct neigh_parms *parms;
int is_multicast = ipv6_addr_is_multicast(addr);
- rcu_read_lock();
in6_dev = in6_dev_get(dev);
if (in6_dev == NULL) {
- rcu_read_unlock();
return -EINVAL;
}
parms = in6_dev->nd_parms;
__neigh_parms_put(neigh->parms);
neigh->parms = neigh_parms_clone(parms);
- rcu_read_unlock();
neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
if (!dev->header_ops) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net/stable] can bcm: fix tx_setup off-by-one errors
From: Oliver Hartkopp @ 2011-09-29 7:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stable, nautsch
In-Reply-To: <20110929.003317.223715542181691202.davem@davemloft.net>
On 09/29/11 06:33, David Miller wrote:
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> Date: Fri, 23 Sep 2011 20:23:47 +0200
>
>> This patch fixes two off-by-one errors that canceled each other out.
>> Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
>> the count of frames to be sent by one. This did not show up the first time
>> tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
>> Invoking a second tx_setup on the same item led to a reduced (by 1) number of
>> sent frames.
>>
>> Reported-by: Andre Naujoks <nautsch@gmail.com>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Applied, and queued up for -stable.
Hello Dave,
when backporting the patch to an older kernel we discovered a problem this
patch is introducing - which causes a new regression :-(
Could you please revert this patch and dequeue it from stable?
We'll send a new patch for net-next as this fix changes/repairs the behaviour
of the count variable. Therefore it's probably better to have a fixed Kernel
version where the fix emerges. Or should we better not fix it at all and
document it in 'know bugs' ?
Sorry for that noise ...
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH net/stable] can bcm: fix tx_setup off-by-one errors
From: David Miller @ 2011-09-29 7:58 UTC (permalink / raw)
To: socketcan; +Cc: netdev, stable, nautsch
In-Reply-To: <4E842266.9090407@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 09:46:46 +0200
> when backporting the patch to an older kernel we discovered a problem this
> patch is introducing - which causes a new regression :-(
>
> Could you please revert this patch and dequeue it from stable?
It's already pushed out to the net GIT tree, I can't delete history so
now the only thing I can do is add a butt-ugly revert commit this late
in the -rcX which is terrible.
This patch was sitting out there for review for 6 days, which should
have been more than enough time to audit it for problems.
^ permalink raw reply
* Re: [PATCH net/stable] can bcm: fix tx_setup off-by-one errors
From: Oliver Hartkopp @ 2011-09-29 8:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stable, nautsch
In-Reply-To: <20110929.035809.1014076114218537552.davem@davemloft.net>
On 09/29/11 09:58, David Miller wrote:
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> Date: Thu, 29 Sep 2011 09:46:46 +0200
>
>> when backporting the patch to an older kernel we discovered a problem this
>> patch is introducing - which causes a new regression :-(
>>
>> Could you please revert this patch and dequeue it from stable?
>
> It's already pushed out to the net GIT tree, I can't delete history so
> now the only thing I can do is add a butt-ugly revert commit this late
> in the -rcX which is terrible.
>
> This patch was sitting out there for review for 6 days, which should
> have been more than enough time to audit it for problems.
Yeah, i'm really sorry about that.
As Linus didn't pull the latest changes, what would be your favorite then to
not revert the patch?
Sending a new fix that fixes the broken fix?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Yan, Zheng @ 2011-09-29 8:16 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1317282414-13368-1-git-send-email-rongqing.li@windriver.com>
On Thu, Sep 29, 2011 at 3:46 PM, <rongqing.li@windriver.com> wrote:
> From: Roy.Li <rongqing.li@windriver.com>
>
> Delete rcu_read_lock, it is redundant.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> net/ipv6/ndisc.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 9da6e02..dd633ff 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -370,17 +370,14 @@ static int ndisc_constructor(struct neighbour *neigh)
> struct neigh_parms *parms;
> int is_multicast = ipv6_addr_is_multicast(addr);
>
> - rcu_read_lock();
> in6_dev = in6_dev_get(dev);
> if (in6_dev == NULL) {
> - rcu_read_unlock();
> return -EINVAL;
> }
>
> parms = in6_dev->nd_parms;
> __neigh_parms_put(neigh->parms);
> neigh->parms = neigh_parms_clone(parms);
> - rcu_read_unlock();
>
> neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
> if (!dev->header_ops) {
> --
I think the rcu_read_lock protects in6_dev->nd_parms.
Yan, Zheng
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Rongqing Li @ 2011-09-29 8:25 UTC (permalink / raw)
To: Yan, Zheng ; +Cc: netdev
In-Reply-To: <CAAM7YAnE4w4y6YWWxk0QGOX8Y6AZQHHQBuVMoRuSm=GtALAx=Q@mail.gmail.com>
On 09/29/2011 04:16 PM, Yan, Zheng wrote:
> I think the rcu_read_lock protects in6_dev->nd_parms.
>
It can not protect in6_dev->nd_parms.
rcu_read_lock protects the data which is accessed by rcu_XXX,
-Roy
> Yan, Zheng
--
Best Reagrds,
Roy | RongQing Li
^ permalink raw reply
* Re: [PATCH net/stable] can bcm: fix tx_setup off-by-one errors
From: David Miller @ 2011-09-29 8:24 UTC (permalink / raw)
To: socketcan; +Cc: netdev, stable, nautsch
In-Reply-To: <4E842698.8090107@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 10:04:40 +0200
> Sending a new fix that fixes the broken fix?
Yes, please do that.
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Eric Dumazet @ 2011-09-29 8:44 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1317282414-13368-1-git-send-email-rongqing.li@windriver.com>
Le jeudi 29 septembre 2011 à 15:46 +0800, rongqing.li@windriver.com a
écrit :
> From: Roy.Li <rongqing.li@windriver.com>
>
> Delete rcu_read_lock, it is redundant.
>
A good changelog and patch title are required.
Something like :
[PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor
in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need rcu
locking in ndisc_constructor()
-----
Or, you could try to really use RCU and not take a reference (ie, use
__in6_dev_get() instead of in6_dev_get(dev).
Untested patch :
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 9da6e02..a4f4472 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -371,7 +371,7 @@ static int ndisc_constructor(struct neighbour *neigh)
int is_multicast = ipv6_addr_is_multicast(addr);
rcu_read_lock();
- in6_dev = in6_dev_get(dev);
+ in6_dev = __in6_dev_get(dev);
if (in6_dev == NULL) {
rcu_read_unlock();
return -EINVAL;
@@ -380,7 +380,6 @@ static int ndisc_constructor(struct neighbour *neigh)
parms = in6_dev->nd_parms;
__neigh_parms_put(neigh->parms);
neigh->parms = neigh_parms_clone(parms);
- rcu_read_unlock();
neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
if (!dev->header_ops) {
@@ -409,7 +408,7 @@ static int ndisc_constructor(struct neighbour *neigh)
else
neigh->output = neigh->ops->output;
}
- in6_dev_put(in6_dev);
+ rcu_read_unlock();
return 0;
}
^ permalink raw reply related
* Re: [RFC] IPVS: secure_tcp does provide alternate state timeouts
From: Julian Anastasov @ 2011-09-29 8:47 UTC (permalink / raw)
To: Simon Horman; +Cc: lvs-devel, netdev, netfilter-devel
In-Reply-To: <1317281111-23985-1-git-send-email-horms@verge.net.au>
Hello,
On Thu, 29 Sep 2011, Simon Horman wrote:
> * Also reword the test to make it read more easily (to me)
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> Julian, I don't see that IPVS currently implements alternate
> timeouts for secure_tcp. Am I missing something?
Yes, only states are changed. What is missing is a
libipvs support to modify per-protocol timeouts because they
are not exported to /proc anymore. As the states have name,
may be we can implement timeout to be set as follows:
ipvsadm --set-state-timeout -p TCP SYN 10
Using 2 timeout tables just for secure_tcp is
complicated and with the above control it is not needed.
> ---
> Documentation/networking/ipvs-sysctl.txt | 10 ++++------
> 1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
> index 1dcdd49..13610e3 100644
> --- a/Documentation/networking/ipvs-sysctl.txt
> +++ b/Documentation/networking/ipvs-sysctl.txt
> @@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
> secure_tcp - INTEGER
> 0 - disabled (default)
>
> - The secure_tcp defense is to use a more complicated state
> - transition table and some possible short timeouts of each
> - state. In the VS/NAT, it delays the entering the ESTABLISHED
> - until the real server starts to send data and ACK packet
> - (after 3-way handshake).
> + The secure_tcp defense is to use a more complicated TCP state
> + transition table. For VS/NAT, it also delays entering the
> + TCP ESTABLISHED state until the three way handshake is completed.
>
> - The value definition is the same as that of drop_entry or
> + The value definition is the same as that of drop_entry and
> drop_packet.
>
> sync_threshold - INTEGER
> --
> 1.7.5.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Rongqing Li @ 2011-09-29 8:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1317285859.2855.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 09/29/2011 04:44 PM, Eric Dumazet wrote:
> A good changelog and patch title are required.
>
> Something like :
>
> [PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor
>
> in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need rcu
> locking in ndisc_constructor()
>
>
Thank you, I will resend it.
-Roy
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Yan, Zheng @ 2011-09-29 8:52 UTC (permalink / raw)
To: Rongqing Li; +Cc: netdev
In-Reply-To: <4E842B93.3010203@windriver.com>
On Thu, Sep 29, 2011 at 4:25 PM, Rongqing Li <rongqing.li@windriver.com> wrote:
> On 09/29/2011 04:16 PM, Yan, Zheng wrote:
>>
>> I think the rcu_read_lock protects in6_dev->nd_parms.
>>
> It can not protect in6_dev->nd_parms.
>
> rcu_read_lock protects the data which is accessed by rcu_XXX,
>
I'm confused, why does neigh_parms_release() use call_rcu() to release nd_parms.
^ permalink raw reply
* Re: [RFC] IPVS: secure_tcp does provide alternate state timeouts
From: Simon Horman @ 2011-09-29 9:01 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, netdev, netfilter-devel
In-Reply-To: <alpine.LFD.2.00.1109291119420.1696@ja.ssi.bg>
On Thu, Sep 29, 2011 at 11:47:10AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 29 Sep 2011, Simon Horman wrote:
>
> > * Also reword the test to make it read more easily (to me)
> >
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > ---
> >
> > Julian, I don't see that IPVS currently implements alternate
> > timeouts for secure_tcp. Am I missing something?
>
> Yes, only states are changed. What is missing is a
> libipvs support to modify per-protocol timeouts because they
> are not exported to /proc anymore. As the states have name,
> may be we can implement timeout to be set as follows:
>
> ipvsadm --set-state-timeout -p TCP SYN 10
>
> Using 2 timeout tables just for secure_tcp is
> complicated and with the above control it is not needed.
Yes, I agree there is room for improvement.
I guess the best way forward is to use netlink
to allow per-state per-protocol timeout adjustment.
In the mean time, I'll queue this patch up as I think
its good that the documentation reflects the implementation.
>
> > ---
> > Documentation/networking/ipvs-sysctl.txt | 10 ++++------
> > 1 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
> > index 1dcdd49..13610e3 100644
> > --- a/Documentation/networking/ipvs-sysctl.txt
> > +++ b/Documentation/networking/ipvs-sysctl.txt
> > @@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
> > secure_tcp - INTEGER
> > 0 - disabled (default)
> >
> > - The secure_tcp defense is to use a more complicated state
> > - transition table and some possible short timeouts of each
> > - state. In the VS/NAT, it delays the entering the ESTABLISHED
> > - until the real server starts to send data and ACK packet
> > - (after 3-way handshake).
> > + The secure_tcp defense is to use a more complicated TCP state
> > + transition table. For VS/NAT, it also delays entering the
> > + TCP ESTABLISHED state until the three way handshake is completed.
> >
> > - The value definition is the same as that of drop_entry or
> > + The value definition is the same as that of drop_entry and
> > drop_packet.
> >
> > sync_threshold - INTEGER
> > --
> > 1.7.5.4
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Rongqing Li @ 2011-09-29 9:10 UTC (permalink / raw)
To: Yan, Zheng ; +Cc: netdev
In-Reply-To: <CAAM7YAmwXyORpFWhthX4iSEkBp7OANnZ8tHruEyN62Z3mnOdLw@mail.gmail.com>
On 09/29/2011 04:52 PM, Yan, Zheng wrote:
> On Thu, Sep 29, 2011 at 4:25 PM, Rongqing Li<rongqing.li@windriver.com> wrote:
>> On 09/29/2011 04:16 PM, Yan, Zheng wrote:
>>>
>>> I think the rcu_read_lock protects in6_dev->nd_parms.
>>>
>> It can not protect in6_dev->nd_parms.
>>
>> rcu_read_lock protects the data which is accessed by rcu_XXX,
>>
>
> I'm confused, why does neigh_parms_release() use call_rcu() to release nd_parms.
>
Same as idev, there is a reference on struct neigh_parms
which protects them
-Roy
^ permalink raw reply
* Re: about bmac/mace/macmace/mac89x0/cs89x0: Move the Macintosh (Apple) drivers
From: Jeff Kirsher @ 2011-09-29 9:12 UTC (permalink / raw)
To: Sascha Hauer
Cc: Paul Mackerras, Russell Nelson, netdev, davem, Jaccon Bastiaansen
In-Reply-To: <20110928070439.GV31404@pengutronix.de>
On Wed, Sep 28, 2011 at 00:04, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi,
>
>> commit 8fb6b0908176704a3ea22005e8a9fa3ebf35b5be
>> Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Mon May 16 01:39:01 2011 -0700
>>
>> bmac/mace/macmace/mac89x0/cs89x0: Move the Macintosh (Apple) drivers
>>
>> Move the Apple drivers into driver/net/ethernet/apple/ and make the
>> necessary Kconfig and Makefile changes.
>
> This commit moves drivers/net/cs89x0.[ch] to drivers/net/ethernet/apple/.
>
> This is wrong. The cs89x0 driver is a general ISA driver and is also
> used on some embedded boards. This patch should only move drivers/net/mac89x0.c
> which basically is a driver for the same device but used on Macintosh.
>
> I think it should go to drivers/net/ethernet/cirrus instead.
>
> Sascha
>
Thanks Sasha, I am looking into the past emails on this to see if
there was a suggested reason that in be where it is at. I do agree
with you that it looks like it should be in
/drivers/net/ethernet/cirrus/, before making a patch to move it, I
want to double check all the previous emails I received to ensure that
there was a logic reason for placing it where it is.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Thomas Wiedemann @ 2011-09-29 9:21 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linux, Netdev, Oliver Hartkopp, SocketCAN Core Mailing List
In-Reply-To: <4E6F0891.8030600@grandegger.com>
I got access to another system with a 4 channel card and tested your patch
(v1) within the Berlios socket-can SVN tree: it worked :)
Thanks!
Thomas
Wolfgang Grandegger <wg@grandegger.com> schrieb am 13.09.2011 09:38:57:
> Hi Oliver,
>
> On 09/12/2011 05:49 PM, Oliver Hartkopp wrote:
> > On 09/09/11 17:20, Wolfgang Grandegger wrote:
> >
> >
> >>
> >>> I'll also test your driver on Monday.
> >>
> >> Thanks,
> >
> >
> > Hi Wolfgang,
> >
> > even if i only had my hardware-patched PEAK PCI ExpressCard hardware
here
> > (which is to be removed in the supported PCI device list due to the
missing
> > I2C initialization), i successfully tested your driver.
> >
> > Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Thanks, I have just sent v2.
>
> > So let's wait for some feedback from Thomas, when he's back to the
office ;-)
>
> Yep, some testing on a 4 channel card would be nice.
>
> Wolfgang.
>
^ permalink raw reply
* COCA COLA AWARD!!
From: Diana Yicel Jimenez Agudelo @ 2011-09-29 10:02 UTC (permalink / raw)
Your Email-ID Has won Ј1,000,000.00 GBP from the Coca Cola Anniversary Award for claims send your details to email cocadpt2011@live.co.uk
^ permalink raw reply
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-29 10:39 UTC (permalink / raw)
To: Thomas Wiedemann
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Oliver Hartkopp
In-Reply-To: <OFA1D2B7AC.618D2DB3-ONC125791A.0032F517-C125791A.00335871-Npw8gZsewqCELgA04lAiVw@public.gmane.org>
Hi Thomas,
On 09/29/2011 11:21 AM, Thomas Wiedemann wrote:
> I got access to another system with a 4 channel card and tested your patch
> (v1) within the Berlios socket-can SVN tree: it worked :)
Hm, did the patch apply to the SVN tree? Any chance to test with David
Miller's net-next-2.6 tree. Anyway, I'm quite sure now that the patch
works fine on 4-channel cards as well.
Thanks for your effort.
Wolfgang.
^ permalink raw reply
* Antwort: Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Thomas Wiedemann @ 2011-09-29 11:46 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Oliver Hartkopp
In-Reply-To: <4E844AFB.3020201-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hi Wolfgang,
i just replaced peak_pci.c.
The net-next-2.6 branch? Is that the one in the latest linux kernels? I'll
try to find some time to test a new kernel.
Thomas
Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> schrieb am 29.09.2011 12:39:55:
> Hi Thomas,
>
> On 09/29/2011 11:21 AM, Thomas Wiedemann wrote:
> > I got access to another system with a 4 channel card and tested your
patch
> > (v1) within the Berlios socket-can SVN tree: it worked :)
>
> Hm, did the patch apply to the SVN tree? Any chance to test with David
> Miller's net-next-2.6 tree. Anyway, I'm quite sure now that the patch
> works fine on 4-channel cards as well.
>
> Thanks for your effort.
>
> Wolfgang.
^ permalink raw reply
* Re: Antwort: Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-29 11:54 UTC (permalink / raw)
To: Thomas Wiedemann
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Oliver Hartkopp
In-Reply-To: <OF72B7C0BE.EE4FAB88-ONC125791A.004029CC-C125791A.004097EF-Npw8gZsewqCELgA04lAiVw@public.gmane.org>
Hi Thomas,
On 09/29/2011 01:46 PM, Thomas Wiedemann wrote:
> Hi Wolfgang,
> i just replaced peak_pci.c.
> The net-next-2.6 branch? Is that the one in the latest linux kernels? I'll
> try to find some time to test a new kernel.
Temporarily (kernel.org is still down) you can get the "net-next-2.6" as
shown below:
$ git clone git://github.com/davem330/net-next.git
The tree is maintained by David Miller and will show up mainline with
the next kernel release.
Thanks,
Wolfgang.
^ permalink raw reply
* [PATCH v2 1/2] net/fec: replace hardcoded irq num with macro
From: jgq516 @ 2011-09-29 12:15 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, jgq516
From: Xiao Jiang <jgq516@gmail.com>
Don't use hardcoded irq num and replace it with
FEC_IRQ_NUM macro.
Signed-off-by: Xiao Jiang <jgq516@gmail.com>
---
The two patches are based on git://github.com/davem330/net-next.git
pls correct me if I still used wrong tree.
Thanks,
Xiao Jiang
drivers/net/ethernet/freescale/fec.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index cce78ce..1794ea4 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -177,6 +177,8 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#define PKT_MINBUF_SIZE 64
#define PKT_MAXBLR_SIZE 1520
+/* This device has up to three irqs on some platforms */
+#define FEC_IRQ_NUM 3
/*
* The 5270/5271/5280/5282/532x RX control register also contains maximum frame
@@ -1540,8 +1542,7 @@ fec_probe(struct platform_device *pdev)
fec_reset_phy(pdev);
- /* This device has up to three irqs on some platforms */
- for (i = 0; i < 3; i++) {
+ for (i = 0; i < FEC_IRQ_NUM; i++) {
irq = platform_get_irq(pdev, i);
if (i && irq < 0)
break;
@@ -1586,7 +1587,7 @@ failed_init:
clk_disable(fep->clk);
clk_put(fep->clk);
failed_clk:
- for (i = 0; i < 3; i++) {
+ for (i = 0; i < FEC_IRQ_NUM; i++) {
irq = platform_get_irq(pdev, i);
if (irq > 0)
free_irq(irq, ndev);
--
1.7.6.1
^ permalink raw reply related
* [PATCH v2 2/2] net/fec: add poll controller function for fec nic
From: jgq516 @ 2011-09-29 12:15 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, jgq516
In-Reply-To: <1317298557-2878-1-git-send-email-jgq516@gmail.com>
From: Xiao Jiang <jgq516@gmail.com>
Add poll controller function for fec nic.
Signed-off-by: Xiao Jiang <jgq516@gmail.com>
---
drivers/net/ethernet/freescale/fec.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 1794ea4..1124ce0 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -242,6 +242,7 @@ struct fec_enet_private {
int link;
int full_duplex;
struct completion mdio_done;
+ int irq[FEC_IRQ_NUM];
};
/* FEC MII MMFR bits definition */
@@ -1363,6 +1364,29 @@ fec_set_mac_address(struct net_device *ndev, void *p)
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * fec_poll_controller: FEC Poll controller function
+ * @dev: The FEC network adapter
+ *
+ * Polled functionality used by netconsole and others in non interrupt mode
+ *
+ */
+void fec_poll_controller(struct net_device *dev)
+{
+ int i;
+ struct fec_enet_private *fep = netdev_priv(dev);
+
+ for (i = 0; i < FEC_IRQ_NUM; i++) {
+ if (fep->irq[i] > 0) {
+ disable_irq(fep->irq[i]);
+ fec_enet_interrupt(fep->irq[i], dev);
+ enable_irq(fep->irq[i]);
+ }
+ }
+}
+#endif
+
static const struct net_device_ops fec_netdev_ops = {
.ndo_open = fec_enet_open,
.ndo_stop = fec_enet_close,
@@ -1373,6 +1397,9 @@ static const struct net_device_ops fec_netdev_ops = {
.ndo_tx_timeout = fec_timeout,
.ndo_set_mac_address = fec_set_mac_address,
.ndo_do_ioctl = fec_enet_ioctl,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = fec_poll_controller,
+#endif
};
/*
--
1.7.6.1
^ permalink raw reply related
* Network problem with bridge and virtualbox
From: William Thompson @ 2011-09-29 12:49 UTC (permalink / raw)
To: netdev
Please keep me in the CC as I am not subscribed.
I'm using a 64-bit kernel 3.0.0 and virtualbox 4.1.2.
My problem is that I cannot ping the host from a virtual machine.
My bridge is configured as follows:
# brctl addbr br0
# brctl setfd br0 0
# brctl stp br0 off
# ifconfig br0 10.2.3.1 netmask 255.255.255.0
In the virtual machine, it is set to use br0 as it's interface (bridge mode)
and it's IP is 10.2.3.10.
The host gets packets from the vm, but the vm does not receive packets back.
I have this same setup working on a 32-bit kernel 2.6.38.6 on another
machine with virtualbox 4.0.4.
I had a thought that the bridge on the host wasn't responding due to having
no ports configured so I added one of my spare ethernet cards to it as
follows:
# brctl addif br0 eth1
# ifconfig eth1 up
The card was plugged into a switch. After doing this, the vm still could not
talk to the host. I added a physical machine to the switch that eth1 was
connected to and configured it to 10.2.3.2. I was able to ping 10.2.3.2 but
not 10.2.3.1
^ 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