* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-08-05 14:40 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110805140047.GA19758@colin.search.kasperd.net>
On 05/08/11 16.08, Kasper Dupont wrote:
> At that point it did not itterate through the loop again
> and it did not leave the interrupt handler either. I'll
> power cycle the machine and take a closer look on the
> source to see what could possible be happening at that
> point.
I looked at the source around the place where that lockup
happened. There was absolutely no I/O or loops happening
between the two printk calls. It seemed the only real
candidate for a culprit responsible for that lockup was
the printk calls themselves.
Is it plausible that in 2.6.32.43 it is not safe to call
printk from within an interrupt handler?
I added some more printk statements in an attempt to find
out how it was possible for the code to lock up between
the end of the loop and the exit from the interrupt handler.
I wasn't able to reproduce the lockup in the same spot, but
instead I saw a lockup inside the loop in the branch where
it does netif_stop_queue.
Right now I suspect those builds where I added printk
statements lockup due to the printk statements. But does
the plain 2.6.32.43 kernel then also lockup due to printk
statements in the interrupt handler, or is it something
else?
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 14:37 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805123136.GF1928@minipsycho.orion>
Fri, Aug 05, 2011 at 02:31:37PM CEST, jpirko@redhat.com wrote:
>Fri, Aug 05, 2011 at 02:18:55PM CEST, mingo@elte.hu wrote:
>>
>>* Jiri Pirko <jpirko@redhat.com> wrote:
>>
>>> >> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>>> >
>>> >How do i tell that without hacking the driver?
>>>
>>> look in dmesg for line like:
>>> "forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
>>> desc-v3"
>>>
>>> if "vlan" is there, DEV_HAS_VLAN is set
>>
>>[ 3.534489] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
>>
>>Note, this is a pretty old system with an old nvidia chipset and
>>on-board ethernet:
>>
>>00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
>> Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0 (250ns min, 5000ns max)
>> Interrupt: pin A routed to IRQ 11
>> Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
>> Region 1: I/O ports at d000 [size=8]
>> Capabilities: [44] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
>
>Please do lspci -nn
>
>There are two CK804 chips:
>0x10DE, 0x0056
>0x10DE, 0x0057
>
>I have only the second one handy - Getting the machine as we speak.
I'm unable to see problems you are referring to on my machine.
Would you please try following patch if it fixes your issue? It's
in fact returning everything back to the original state (for your card).
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e55df30..d7d43d4 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2763,18 +2763,18 @@ static int nv_rx_process_optimized(struct net_device *dev, int limit)
skb->protocol = eth_type_trans(skb, dev);
prefetch(skb->data);
- vlanflags = le32_to_cpu(np->get_rx.ex->buflow);
-
/*
* There's need to check for NETIF_F_HW_VLAN_RX here.
* Even if vlan rx accel is disabled,
* NV_RX3_VLAN_TAG_PRESENT is pseudo randomly set.
*/
- if (dev->features & NETIF_F_HW_VLAN_RX &&
- vlanflags & NV_RX3_VLAN_TAG_PRESENT) {
- u16 vid = vlanflags & NV_RX3_VLAN_TAG_MASK;
+ if (dev->features & NETIF_F_HW_VLAN_RX) {
+ vlanflags = le32_to_cpu(np->get_rx.ex->buflow);
+ if (vlanflags & NV_RX3_VLAN_TAG_PRESENT) {
+ u16 vid = vlanflags & NV_RX3_VLAN_TAG_MASK;
- __vlan_hwaccel_put_tag(skb, vid);
+ __vlan_hwaccel_put_tag(skb, vid);
+ }
}
napi_gro_receive(&np->napi, skb);
@@ -5615,7 +5615,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
goto out_error;
}
- nv_vlan_mode(dev, dev->features);
+ //nv_vlan_mode(dev, dev->features);
netif_carrier_off(dev);
^ permalink raw reply related
* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-08-05 14:08 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728210112.GA25953@colin.search.kasperd.net>
I did a bit more of experiments. I took the unmodified
2.6.32.43 kernel and added printk statements to see when
it entered the interrupt handler and when it left it.
That way I was able to confirm that the system locked
up inside the interrupt handler.
Next I added printk statements to see how many times the
loop in the interrupt handler was run. It seemed that
when it locked up inside the handler it would run the
loop just two times and then lock up before leaving the
handler.
I added more printk statements to see which branches were
taken inside the loop. Unfortunately those printk
statements changed the timing enough that the crashes
were no longer as reproducable.
I saw a pattern repeating. It would do the stop queue
thing, then leave the handler and while not inside this
interrupt handler there would be a message about the
interface coming up again. Seems like it was doing stop
queue calls much more frequently than it should be.
After a few attempts I managed to get it to lock up again
with all the printk statements in place. What I found was
that in the beginning of the loop status was 0x85. It
would then call the napi event code. At the end of the
first itteration of the loop status was 0.
At that point it did not itterate through the loop again
and it did not leave the interrupt handler either. I'll
power cycle the machine and take a closer look on the
source to see what could possible be happening at that
point.
I also did a bit of testing with the patches that causes
it to drop the network instead of crashing. On those I
am able to bring up the second interface and get data off
the machine for debugging, so if there is any debug info
you think would be useful in those cases, let me know.
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* Re: [RFC 4/4] [flexcan] Add support for FLEXCAN_DEBUG
From: Robin Holt @ 2011-08-05 14:01 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <4E3B98B6.4040003-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Aug 05, 2011 at 09:16:06AM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 04:06 AM, Robin Holt wrote:
> > Add a wrapper function for a register dump when a developer defines
> > FLEXCAN_DEBUG
>
> Comments inline..however I'm not sure if we need this patch.
I really do like the ability to dump the registers. It has come in handy
a couple of times while bringing up the board. I do not know how hard
I would push for them, but I do not see them as having much down side
and I do know they have proven useful for me.
At this point, I have interpretted both your's and Wolfgang's comment as
a suggestion. I do not know how this group of developers works and if
I should be taking that suggestion as a dope-slap indicating I should
drop this right now because I am an idiot or if the patch just leaves
a bad taste in your mouth. Would either or both of you please clarify.
> > +#if defined(FLEXCAN_DEBUG)
> > +void _flexcan_reg_dump(struct net_device *dev, const char *file, int line,
> > + const char *func)
> > +{
> > + const struct flexcan_priv *priv = netdev_priv(dev);
> > + struct flexcan_regs __iomem *regs = priv->base;
> > +
> > + printk(KERN_INFO "flexcan_reg_dump:%s:%d:%s()\n", file, line, func);
>
> Use netdev_$LEVEL, please.
> If you use dbg, you can remove the ifdef altogether.
I assume you mean netdev_dbg. If that were the case, then setting
CONFIG_CAN_DEBUG_DEVICES would bring these printks back and that was
explicitly stated as undesirable. Am I understanding this wrong?
If not, I am going to fall back to netdev_info instead and leave the
#ifdef FLEXCAN_DEBUG. Will that work?
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH 1/5] Define the function to write sock's security context to seq_file.
From: Stephen Smalley @ 2011-08-05 13:56 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, lsm
In-Reply-To: <1312534686-4099-2-git-send-email-rongqing.li@windriver.com>
On Fri, 2011-08-05 at 16:58 +0800, rongqing.li@windriver.com wrote:
> From: Roy.Li <rongqing.li@windriver.com>
>
> This function will write the sock's security context to a seq_file
> and return the error code, and the number of characters successfully
> written is written in int pointers parameter.
>
> This function will be called when export socket information to proc.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> include/net/sock.h | 1 +
> net/core/sock.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
> diff --git a/net/core/sock.c b/net/core/sock.c
> index bc745d0..1126a49 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2254,6 +2254,32 @@ void sk_common_release(struct sock *sk)
> }
> EXPORT_SYMBOL(sk_common_release);
>
> +int sock_write_secctx(struct sock *sk, struct seq_file *seq, int *len)
> +{
> + struct flowi fl;
> + char *ctx = NULL;
> + u32 ctxlen;
> + int res = 0;
> +
> + *len = 0;
> +
> + if (sk == NULL)
> + return -EINVAL;
Is this ever possible?
> + res = security_socket_getsockname(sk->sk_socket);
> + if (res)
> + return res;
I'm not sure it is a good idea to output nothing if permission is denied
to the socket, as opposed to some well-defined string indicating that
condition. Particularly if someone later adds another field to
the /proc files after the context; we don't want the contents of that
field to be interpreted as the context if permission was denied.
> +
> + security_sk_classify_flow(sk, &fl);
> +
> + res = security_secid_to_secctx(fl.flowi_secid, &ctx, &ctxlen);
> + if (res)
> + return res;
Likewise, if we couldn't map the secid to a secctx for some reason, we
likely ought to output some well-defined string indicating that
condition.
> +
> + seq_printf(seq, " %s%n", ctx, len);
> + security_release_secctx(ctx, ctxlen);
> + return res;
> +}
> +
> static DEFINE_RWLOCK(proto_list_lock);
> static LIST_HEAD(proto_list);
>
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [PATCH 2/5] Export the raw sock's security context to proc.
From: Stephen Smalley @ 2011-08-05 13:51 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, lsm
In-Reply-To: <1312534686-4099-3-git-send-email-rongqing.li@windriver.com>
On Fri, 2011-08-05 at 16:58 +0800, rongqing.li@windriver.com wrote:
> From: Roy.Li <rongqing.li@windriver.com>
>
> The element sk_security of struct sock represents the socket
> security context ID, which is inheriting from the process when
> creates this socket on most of the time.
>
> but when SELinux type_transition rule is applied to socket, or
> application sets /proc/xxx/attr/createsock, the socket security
> context would be different from the creating process. on this
> condition, the "netstat -Z" will return wrong value, since
> "netstat -Z" only returns the process security context as socket
> process security.
>
> Export the raw sock's security context to proc, so that "netstat -Z"
> could be fixed by reading procfs.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> net/ipv4/raw.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
> index 1457acb..645d373 100644
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@ -972,6 +972,7 @@ EXPORT_SYMBOL_GPL(raw_seq_stop);
>
> static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
> {
> + int sclen;
> struct inet_sock *inet = inet_sk(sp);
> __be32 dest = inet->inet_daddr,
> src = inet->inet_rcv_saddr;
> @@ -979,12 +980,15 @@ static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
> srcp = inet->inet_num;
>
> seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
> - " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d\n",
> + " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d",
> i, src, srcp, dest, destp, sp->sk_state,
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
> +
> + sock_write_secctx(sp, seq, &sclen);
You don't seem to use the return value or the sclen. If that's
intentional, then why does sclen exist and why isn't the function void?
> + seq_putc(seq, '\n');
> }
>
> static int raw_seq_show(struct seq_file *seq, void *v)
> @@ -992,7 +996,8 @@ static int raw_seq_show(struct seq_file *seq, void *v)
> if (v == SEQ_START_TOKEN)
> seq_printf(seq, " sl local_address rem_address st tx_queue "
> "rx_queue tr tm->when retrnsmt uid timeout "
> - "inode ref pointer drops\n");
> + "inode ref pointer drops %s",
> + (selinux_is_enabled() ? " scontext\n" : "\n"));
The rest of your code isn't SELinux-specific and should work for other
security modules, so there is no reason to make this SELinux-specific
either. The audit system may provide a useful example. I'd just always
include the field header (otherwise how can we add any further fields
unambiguously?), and make it something more general, like "seclabel".
> else
> raw_sock_seq_show(seq, v, raw_seq_private(seq)->bucket);
> return 0;
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:37 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Ve9Y4v9CWCrbGsR+7C79AyoiWncVSVbeqApDuKaPm_jA@mail.gmail.com>
On Fri, Aug 5, 2011 at 6:30 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
>> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>>
>>> Hello,
>>>
>>> On Thu, 4 Aug 2011, Tom London wrote:
>>>
>>>> So, my router is just giving my wired NIC different addresses....
>>>>
>>>> More I can provide?
>>>
>>> Thanks! Can you check in dmesg or in another log
>>> about the first IP address in such line:
>>>
>>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>>
>>> Is it now 192.168.2.6 ?
>>>
>>> Regards
>>>
>>> --
>>> Julian Anastasov <ja@ssi.bg>
>>>
>>
>> Sorry, don't see those messages. I guess I'll have to reboot with
>> 'debug' to see that.
>>
>> Before I do that, I booted this time with the RFKILL switch set to
>> kill the radio (both BT and WIFI), and reran the above tests.
>>
>> Here is what 'ip monitor' said:
>>
>> [root@tlondon ~]# ip monitor
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> ff02::fb via ff02::fb dev eth0 metric 0
>> cache
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>>
>> Here is what 'inotail -f /var/log/messages' said:
>>
>>
>> Aug 5 06:12:21 tlondon kernel: [ 536.727187] usb 3-1: new full speed
>> USB device number 2 using uhci_hcd
>> Aug 5 06:12:21 tlondon kernel: [ 537.315296] usb 3-1: New USB device
>> found, idVendor=04b8, idProduct=010a
>> Aug 5 06:12:21 tlondon kernel: [ 537.315308] usb 3-1: New USB device
>> strings: Mfr=1, Product=2, SerialNumber=0
>> Aug 5 06:12:21 tlondon kernel: [ 537.315317] usb 3-1: Product: Perfection1640
>> Aug 5 06:12:21 tlondon kernel: [ 537.315323] usb 3-1: Manufacturer: EPSON
>> Aug 5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
>> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
>> Aug 5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>>
>> So, no WARN_ON messages.
>>
>> I'd like to conclude that this is due to UDP casting on the wlan.
>> I'll reboot with the radio on and in debug mode to see what happens.
>>
>> tom
>> --
>> Tom London
>>
>
> Hmmm, first attempt at recreating in debug mode didn't actually
> produce any WARN_ON reports.
>
> 'ip monitor' did say:
>
> [root@tlondon ~]# ip monitor
> 239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
> link/ether
> ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
> ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
> ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
> link/ether
>
> Will try one more time.
>
> tom
>
> --
> Tom London
>
Can't seem to reproduce this when I boot with 'debug' on the boot line.
Here is what 'ip monitor' says:
[root@tlondon ~]# ip monitor
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
tom
--
Tom London
^ permalink raw reply
* Re: [PATCH 1/5] Define the function to write sock's security context to seq_file.
From: Stephen Smalley @ 2011-08-05 13:32 UTC (permalink / raw)
To: rongqing.li-CWA4WttNNZF54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, selinux-+05T5uksL2qpZYMLLGbcSA,
lsm
In-Reply-To: <1312534686-4099-2-git-send-email-rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
On Fri, 2011-08-05 at 16:58 +0800, rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org wrote:
> From: Roy.Li <rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
>
> This function will write the sock's security context to a seq_file
> and return the error code, and the number of characters successfully
> written is written in int pointers parameter.
>
> This function will be called when export socket information to proc.
>
> Signed-off-by: Roy.Li <rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
> ---
> include/net/sock.h | 1 +
> net/core/sock.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index bc745d0..1126a49 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2254,6 +2254,32 @@ void sk_common_release(struct sock *sk)
> }
> EXPORT_SYMBOL(sk_common_release);
>
> +int sock_write_secctx(struct sock *sk, struct seq_file *seq, int *len)
> +{
> + struct flowi fl;
> + char *ctx = NULL;
> + u32 ctxlen;
> + int res = 0;
> +
> + *len = 0;
> +
> + if (sk == NULL)
> + return -EINVAL;
> + res = security_socket_getsockname(sk->sk_socket);
> + if (res)
> + return res;
> +
> + security_sk_classify_flow(sk, &fl);
Rather than using a fake flowi, just define and use
security_sk_getsecid(). There is already a security_ops->sk_getsecid()
hook, so you just need the wrapper function.
> +
> + res = security_secid_to_secctx(fl.flowi_secid, &ctx, &ctxlen);
> + if (res)
> + return res;
> +
> + seq_printf(seq, " %s%n", ctx, len);
> + security_release_secctx(ctx, ctxlen);
> + return res;
> +}
> +
> static DEFINE_RWLOCK(proto_list_lock);
> static LIST_HEAD(proto_list);
>
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:30 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Wmv_FEx2ZX3qZt0tAr-QVQD_javX1gbRWujr9xyf7nbQ@mail.gmail.com>
On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>> Hello,
>>
>> On Thu, 4 Aug 2011, Tom London wrote:
>>
>>> So, my router is just giving my wired NIC different addresses....
>>>
>>> More I can provide?
>>
>> Thanks! Can you check in dmesg or in another log
>> about the first IP address in such line:
>>
>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>
>> Is it now 192.168.2.6 ?
>>
>> Regards
>>
>> --
>> Julian Anastasov <ja@ssi.bg>
>>
>
> Sorry, don't see those messages. I guess I'll have to reboot with
> 'debug' to see that.
>
> Before I do that, I booted this time with the RFKILL switch set to
> kill the radio (both BT and WIFI), and reran the above tests.
>
> Here is what 'ip monitor' said:
>
> [root@tlondon ~]# ip monitor
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> ff02::fb via ff02::fb dev eth0 metric 0
> cache
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>
> Here is what 'inotail -f /var/log/messages' said:
>
>
> Aug 5 06:12:21 tlondon kernel: [ 536.727187] usb 3-1: new full speed
> USB device number 2 using uhci_hcd
> Aug 5 06:12:21 tlondon kernel: [ 537.315296] usb 3-1: New USB device
> found, idVendor=04b8, idProduct=010a
> Aug 5 06:12:21 tlondon kernel: [ 537.315308] usb 3-1: New USB device
> strings: Mfr=1, Product=2, SerialNumber=0
> Aug 5 06:12:21 tlondon kernel: [ 537.315317] usb 3-1: Product: Perfection1640
> Aug 5 06:12:21 tlondon kernel: [ 537.315323] usb 3-1: Manufacturer: EPSON
> Aug 5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
> Aug 5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>
> So, no WARN_ON messages.
>
> I'd like to conclude that this is due to UDP casting on the wlan.
> I'll reboot with the radio on and in debug mode to see what happens.
>
> tom
> --
> Tom London
>
Hmmm, first attempt at recreating in debug mode didn't actually
produce any WARN_ON reports.
'ip monitor' did say:
[root@tlondon ~]# ip monitor
239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
Will try one more time.
tom
--
Tom London
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:18 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <alpine.LFD.2.00.1108051048160.1494@ja.ssi.bg>
On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Thu, 4 Aug 2011, Tom London wrote:
>
>> So, my router is just giving my wired NIC different addresses....
>>
>> More I can provide?
>
> Thanks! Can you check in dmesg or in another log
> about the first IP address in such line:
>
> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>
> Is it now 192.168.2.6 ?
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
Sorry, don't see those messages. I guess I'll have to reboot with
'debug' to see that.
Before I do that, I booted this time with the RFKILL switch set to
kill the radio (both BT and WIFI), and reran the above tests.
Here is what 'ip monitor' said:
[root@tlondon ~]# ip monitor
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
ff02::fb via ff02::fb dev eth0 metric 0
cache
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
Here is what 'inotail -f /var/log/messages' said:
Aug 5 06:12:21 tlondon kernel: [ 536.727187] usb 3-1: new full speed
USB device number 2 using uhci_hcd
Aug 5 06:12:21 tlondon kernel: [ 537.315296] usb 3-1: New USB device
found, idVendor=04b8, idProduct=010a
Aug 5 06:12:21 tlondon kernel: [ 537.315308] usb 3-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Aug 5 06:12:21 tlondon kernel: [ 537.315317] usb 3-1: Product: Perfection1640
Aug 5 06:12:21 tlondon kernel: [ 537.315323] usb 3-1: Manufacturer: EPSON
Aug 5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
Aug 5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
So, no WARN_ON messages.
I'd like to conclude that this is due to UDP casting on the wlan.
I'll reboot with the radio on and in debug mode to see what happens.
tom
--
Tom London
^ permalink raw reply
* Re: [Bugme-new] [Bug 39742] New: 3.0.0 (2.6.39.3 also) kernel BUG at include/linux/skbuff.h:1189!
From: Rustam Afanasyev @ 2011-08-05 12:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon, Patrick McHardy
In-Reply-To: <20110722144214.577718f0.akpm@linux-foundation.org>
New kernel, with "gre: fix improper error handling" applied - result
same. Please Help! Which new git tree you recommend me to testing?
------------------------------------------------
[ 4081.605966] ------------[ cut here ]------------
[ 4081.609919] kernel BUG at include/linux/skbuff.h:1189!
[ 4081.609919] invalid opcode: 0000 [#1] PREEMPT SMP
[ 4081.609919] CPU 1
[ 4081.609919] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2t
p_netlink l2tp_core pptp pppox ppp_generic slhc gre 8021q garp stp
cls_flow sch_htb ifb ipt_NETFLOW xt_mark nf_conntrack_i
pv4 nf_defrag_ipv4 xt_state xt_TCPMSS ipt_LOG xt_recent xt_NOTRACK
nf_conntrack xt_statistic ts_kmp xt_tcpudp xt_string xt
_multiport xt_set iptable_raw iptable_mangle iptable_filter ip_tables
x_tables ip_set_hash_ip ip_set_hash_net ip_set nfnet
link dm_multipath scsi_dh dm_mod psmouse sr_mod evdev pcspkr rtc_cmos
cdrom sg serio_raw i2c_i801 ehci_hcd tg3 uhci_hcd i2
c_core i3000_edac igb usbcore edac_core dca processor button ext3 jbd
mbcache sd_mod crc_t10dif ide_pci_generic ide_core p
ata_acpi ata_generic ata_piix libata scsi_mod
[ 4081.609919]
[ 4081.609919] Pid: 0, comm: kworker/0:0 Not tainted 3.0.0-un-def-alt2
#1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 4081.609919] RIP: 0010:[<ffffffff8136ca2b>] [<ffffffff8136ca2b>]
skb_pull+0x2b/0x30
[ 4081.609919] RSP: 0018:ffff88011fc83ab0 EFLAGS: 00010283
[ 4081.609919] RAX: 000000000000057e RBX: ffff88011378db80 RCX:
0000000000000179
[ 4081.609919] RDX: 0000000000000179 RSI: 0000000000000002 RDI:
ffff88011378db80
[ 4081.609919] RBP: ffff88011fc83ab0 R08: 0000000000000000 R09:
0000000000000102
[ 4081.609919] R10: 0000000000000000 R11: 0000000000000001 R12:
ffff88010d0a8800
[ 4081.609919] R13: ffff88010dc4186e R14: 000000000000002f R15:
ffffffff8168dd80
[ 4081.609919] FS: 0000000000000000(0000) GS:ffff88011fc80000(0000)
knlGS:0000000000000000
[ 4081.609919] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 4081.609919] CR2: 0000000000fc10fc CR3: 0000000001625000 CR4:
00000000000006e0
[ 4081.609919] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 4081.609919] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 4081.609919] Process kworker/0:0 (pid: 0, threadinfo ffff880118f5c000,
task ffff880118f5a480)
[ 4081.609919] Stack:
[ 4081.609919] ffff88011fc83ae0 ffffffffa03267fa ffff88011fc83ae0
ffff88010d0a8800
[ 4081.609919] ffff88011378db80 ffff88010d0a8850 ffff88011fc83b10
ffffffff8136bddc
[ 4081.609919] ffff88011fc83b40 ffff88011378db80 ffff88010d0a8800
000000008b55000a
[ 4081.609919] Call Trace:
[ 4081.609919] <IRQ>
[ 4081.609919] [<ffffffffa03267fa>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 4081.609919] [<ffffffff8136bddc>] sk_receive_skb+0x13c/0x160
[ 4081.609919] [<ffffffffa03261be>] pptp_rcv+0x15e/0x1b0 [pptp]
[ 4081.609919] [<ffffffffa03080e3>] gre_rcv+0x73/0xa0 [gre]
[ 4081.609919] [<ffffffff813af10d>] ip_local_deliver_finish+0xed/0x2c0
[ 4081.609919] [<ffffffff813af360>] ip_local_deliver+0x80/0x90
[ 4081.609919] [<ffffffff813ae959>] ip_rcv_finish+0x119/0x3b0
[ 4081.609919] [<ffffffff813aef4d>] ip_rcv+0x21d/0x2f0
[ 4081.609919] [<ffffffff8137cffc>] __netif_receive_skb+0x20c/0x6c0
[ 4081.609919] [<ffffffff8137dbcd>] netif_receive_skb+0xbd/0xd0
[ 4081.609919] [<ffffffff8125fcfc>] ? is_swiotlb_buffer+0x3c/0x50
[ 4081.609919] [<ffffffff8137dd30>] napi_skb_finish+0x50/0x70
[ 4081.609919] [<ffffffff8137e315>] napi_gro_receive+0xc5/0xd0
[ 4081.609919] [<ffffffffa01dbe0f>] igb_poll+0x6cf/0xb50 [igb]
[ 4081.609919] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4081.609919] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4081.609919] [<ffffffff8137f0d4>] net_rx_action+0x164/0x340
[ 4081.609919] [<ffffffff810684b5>] __do_softirq+0xd5/0x270
[ 4081.609919] [<ffffffff8143c89c>] call_softirq+0x1c/0x30
[ 4081.609919] [<ffffffff8100e6c5>] do_softirq+0x95/0xe0
[ 4081.609919] [<ffffffff81068305>] irq_exit+0xd5/0xf0
[ 4081.609919] [<ffffffff8100dec1>] do_IRQ+0x61/0xd0
[ 4081.609919] [<ffffffff81434753>] common_interrupt+0x13/0x13
[ 4081.609919] <EOI>
[ 4081.609919] [<ffffffff8108af60>] ? sched_clock_cpu+0xd0/0x140
[ 4081.609919] [<ffffffff81015936>] ? mwait_idle+0xe6/0x2b0
[ 4081.609919] [<ffffffff8101589a>] ? mwait_idle+0x4a/0x2b0
[ 4081.609919] [<ffffffff8100bb76>] cpu_idle+0x66/0xd0
[ 4081.609919] [<ffffffff8142c8f9>] start_secondary+0x1bf/0x1c4
[ 4081.609919] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e0
00 00 00 c9 c3 31 c0 c9 c3 <0f> 0b eb fe 90 55 39 77 68 48 89 e5 76 1c
8b 47 6c 85 c0 75 17
[ 4081.609919] RIP [<ffffffff8136ca2b>] skb_pull+0x2b/0x30
[ 4081.609919] RSP <ffff88011fc83ab0>
[ 4082.825070] ---[ end trace d6baf8611ae0f359 ]---
[ 4082.838992] Kernel panic - not syncing: Fatal exception in interrupt
[ 4082.858102] Pid: 0, comm: kworker/0:0 Tainted: G D
3.0.0-un-def-alt2 #1
[ 4082.881241] Call Trace:
[ 4082.888651] <IRQ> [<ffffffff81430b2a>] panic+0x96/0x1bb
[ 4082.904981] [<ffffffff8143577a>] oops_end+0x10a/0x120
[ 4082.920451] [<ffffffff8100fbf6>] die+0x56/0x90
[ 4082.934102] [<ffffffff81434e64>] do_trap+0xc4/0x170
[ 4082.949051] [<ffffffff8100d801>] do_invalid_op+0xa1/0xb0
[ 4082.965301] [<ffffffff8136ca2b>] ? skb_pull+0x2b/0x30
[ 4082.980772] [<ffffffff8106837c>] ? local_bh_enable+0x5c/0xc0
[ 4082.998067] [<ffffffffa026935a>] ? ipt_do_table+0x22a/0x640 [ip_tables]
[ 4083.018212] [<ffffffff8143c61b>] invalid_op+0x1b/0x20
[ 4083.033683] [<ffffffff8136ca2b>] ? skb_pull+0x2b/0x30
[ 4083.049153] [<ffffffffa03267fa>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 4083.067742] [<ffffffff8136bddc>] sk_receive_skb+0x13c/0x160
[ 4083.084774] [<ffffffffa03261be>] pptp_rcv+0x15e/0x1b0 [pptp]
[ 4083.102064] [<ffffffffa03080e3>] gre_rcv+0x73/0xa0 [gre]
[ 4083.118314] [<ffffffff813af10d>] ip_local_deliver_finish+0xed/0x2c0
[ 4083.137425] [<ffffffff813af360>] ip_local_deliver+0x80/0x90
[ 4083.154453] [<ffffffff813ae959>] ip_rcv_finish+0x119/0x3b0
[ 4083.171223] [<ffffffff813aef4d>] ip_rcv+0x21d/0x2f0
[ 4083.186174] [<ffffffff8137cffc>] __netif_receive_skb+0x20c/0x6c0
[ 4083.204504] [<ffffffff8137dbcd>] netif_receive_skb+0xbd/0xd0
[ 4083.221795] [<ffffffff8125fcfc>] ? is_swiotlb_buffer+0x3c/0x50
[ 4083.239605] [<ffffffff8137dd30>] napi_skb_finish+0x50/0x70
[ 4083.256374] [<ffffffff8137e315>] napi_gro_receive+0xc5/0xd0
[ 4083.273412] [<ffffffffa01dbe0f>] igb_poll+0x6cf/0xb50 [igb]
[ 4083.290436] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4083.309286] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4083.328136] [<ffffffff8137f0d4>] net_rx_action+0x164/0x340
[ 4083.344906] [<ffffffff810684b5>] __do_softirq+0xd5/0x270
[ 4083.361157] [<ffffffff8143c89c>] call_softirq+0x1c/0x30
[ 4083.377147] [<ffffffff8100e6c5>] do_softirq+0x95/0xe0
[ 4083.392618] [<ffffffff81068305>] irq_exit+0xd5/0xf0
[ 4083.407565] [<ffffffff8100dec1>] do_IRQ+0x61/0xd0
[ 4083.421998] [<ffffffff81434753>] common_interrupt+0x13/0x13
[ 4083.439027] <EOI> [<ffffffff8108af60>] ? sched_clock_cpu+0xd0/0x140
[ 4083.458477] [<ffffffff81015936>] ? mwait_idle+0xe6/0x2b0
[ 4083.474725] [<ffffffff8101589a>] ? mwait_idle+0x4a/0x2b0
[ 4083.490976] [<ffffffff8100bb76>] cpu_idle+0x66/0xd0
[ 4083.505927] [<ffffffff8142c8f9>] start_secondary+0x1bf/0x1c4
[ 4083.523225] Rebooting in 30 seconds..
------------------------------------------------
^ permalink raw reply
* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Robin Holt @ 2011-08-05 12:44 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
Wolfgang Grandegger
In-Reply-To: <4E3BE23A.5080706-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Aug 05, 2011 at 02:29:46PM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 01:36 PM, Robin Holt wrote:
> > I implemented the coding style changes below (Sorry I missed the two
> > the first time).
>
> np :)
>
> > As for a better implementation, I guess I would need to understand what
> > is being attempted here. I only marginally understand the flexcan
> > hardware on the Freescale P1010 and certainly am clueless about arm
> > implementations of flexcan. I just skimmed over freescale's site
>
> The arm side is working already :)
> However we just support the busclock on ARM [1]. For the first shot
> stick to that clock, too.
>
> [1] (http://lxr.linux.no/linux+v3.0/drivers/net/can/flexcan.c#L857)
>
> > and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
> > and i.MX53 family of processors. I will attempt to find some useful
> > documentation of those and look at the kernel sources for what the clk_*
> > functions are trying to accomplish.
> >
> > I _THINK_ I understand. It looks like I could implement this as a powerpc
> > p1010 specific thing and get the same effect without impacting flexcan.c.
> > I also think I understand that the i.MX25 family of processors do
> > essentially the same thing the p1010 is doing for determining the
> > clock rate.
>
> It seems that arch/powerpc/platforms/512x/clock.c implements a clock
> interface. I think the p1010 should implement something similar. (Note:
> I'm not a ppc guy :)
>
> I'm looking forward for new patches.
I agree. I think I will have that implemented shortly after I get to the
office (about an hour for drive, etc). I think I am going to implement
a simple match on the dev_id of flexcan.0 or flexcan.1 and otherwise
return failure.
I also looked at implementing the CLOCKDEV_LOOKUP but think that is
going to drive me to drink.
Thanks,
Robin
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 12:31 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805121855.GC13055@elte.hu>
Fri, Aug 05, 2011 at 02:18:55PM CEST, mingo@elte.hu wrote:
>
>* Jiri Pirko <jpirko@redhat.com> wrote:
>
>> >> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>> >
>> >How do i tell that without hacking the driver?
>>
>> look in dmesg for line like:
>> "forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
>> desc-v3"
>>
>> if "vlan" is there, DEV_HAS_VLAN is set
>
>[ 3.534489] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
>
>Note, this is a pretty old system with an old nvidia chipset and
>on-board ethernet:
>
>00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
> Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (250ns min, 5000ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
> Region 1: I/O ports at d000 [size=8]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
Please do lspci -nn
There are two CK804 chips:
0x10DE, 0x0056
0x10DE, 0x0057
I have only the second one handy - Getting the machine as we speak.
Jirka
>
>Thanks,
>
> Ingo
^ permalink raw reply
* [PATCH] Bridge: Always send NETDEV_CHANGEADDR up on br MAC change.
From: Andrei Warkentin @ 2011-08-05 1:55 UTC (permalink / raw)
To: netdev; +Cc: Andrei Warkentin, Stephen Hemminger
In-Reply-To: <1312509349-23363-1-git-send-email-andreiw@motorola.com>
This ensures the neighbor entries associated with the bridge
dev are flushed, also invalidating the associated cached L2 headers.
This means we br_add_if/br_del_if ports to implement hand-over and
not wind up with bridge packets going out with stale MAC.
This means we can also change MAC of port device and also not wind
up with bridge packets going out with stale MAC.
This builds on Stephen Hemminger's patch, also handling the br_del_if
case, port MAC change case, and bridge MAC manual assignment case.
Change-Id: I6039ba021006f854e0e7e83dd1c4261c500aeab7
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
---
net/bridge/br_device.c | 1 +
net/bridge/br_if.c | 6 +++++-
net/bridge/br_notify.c | 2 ++
net/bridge/br_stp_if.c | 2 +-
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index cf09fe5..ef18070 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -162,6 +162,7 @@ static int br_set_mac_address(struct net_device *dev, void *p)
br->flags |= BR_SET_MAC_ADDR;
spin_unlock_bh(&br->lock);
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
return 0;
}
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 204e542..36ad887 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -481,6 +481,7 @@ put_back:
int br_del_if(struct net_bridge *br, struct net_device *dev)
{
struct net_bridge_port *p;
+ bool changed_addr;
if (!br_port_exists(dev))
return -EINVAL;
@@ -492,10 +493,13 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
del_nbp(p);
spin_lock_bh(&br->lock);
- br_stp_recalculate_bridge_id(br);
+ changed_addr = br_stp_recalculate_bridge_id(br);
br_features_recompute(br);
spin_unlock_bh(&br->lock);
+ if (changed_addr)
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
+
return 0;
}
diff --git a/net/bridge/br_notify.c b/net/bridge/br_notify.c
index 404d4e1..c7160b1 100644
--- a/net/bridge/br_notify.c
+++ b/net/bridge/br_notify.c
@@ -53,6 +53,8 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
br_fdb_changeaddr(p, dev->dev_addr);
br_stp_recalculate_bridge_id(br);
spin_unlock_bh(&br->lock);
+
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
break;
case NETDEV_CHANGE:
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index c0990ba..4528e9a 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -213,7 +213,7 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
/* user has chosen a value so keep it */
if (br->flags & BR_SET_MAC_ADDR)
- return;
+ return false;
list_for_each_entry(p, &br->port_list, list) {
if (addr == br_mac_zero ||
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Marc Kleine-Budde @ 2011-08-05 12:29 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
Wolfgang Grandegger
In-Reply-To: <20110805113638.GF4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]
On 08/05/2011 01:36 PM, Robin Holt wrote:
> I implemented the coding style changes below (Sorry I missed the two
> the first time).
np :)
> As for a better implementation, I guess I would need to understand what
> is being attempted here. I only marginally understand the flexcan
> hardware on the Freescale P1010 and certainly am clueless about arm
> implementations of flexcan. I just skimmed over freescale's site
The arm side is working already :)
However we just support the busclock on ARM [1]. For the first shot
stick to that clock, too.
[1] (http://lxr.linux.no/linux+v3.0/drivers/net/can/flexcan.c#L857)
> and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
> and i.MX53 family of processors. I will attempt to find some useful
> documentation of those and look at the kernel sources for what the clk_*
> functions are trying to accomplish.
>
> I _THINK_ I understand. It looks like I could implement this as a powerpc
> p1010 specific thing and get the same effect without impacting flexcan.c.
> I also think I understand that the i.MX25 family of processors do
> essentially the same thing the p1010 is doing for determining the
> clock rate.
It seems that arch/powerpc/platforms/512x/clock.c implements a clock
interface. I think the p1010 should implement something similar. (Note:
I'm not a ppc guy :)
I'm looking forward for new patches.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH] ATM: Delete no use FILL_RX_POOLS_IN_BH marco
From: Wang Shaoyan @ 2011-08-05 12:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <1310130103-4847-1-git-send-email-wangshaoyan.pt@taobao.com>
applied
2011/7/8 <stufever@gmail.com>:
> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>
> The macro FILL_RX_POOLS_IN_BH is never been used, in order to avoid
> the compiler reports error because of the usage of function INIT_WORK,
> we just delete the marco.
>
> Cc: Chas Williams <chas@cmf.nrl.navy.mil>
> Cc: linux-atm-general@lists.sourceforge.net
> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
> ---
> drivers/atm/ambassador.c | 11 +----------
> drivers/atm/ambassador.h | 4 ----
> 2 files changed, 1 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c
> index a5fcb1e..bb3b016 100644
> --- a/drivers/atm/ambassador.c
> +++ b/drivers/atm/ambassador.c
> @@ -813,7 +813,7 @@ static void fill_rx_pool (amb_dev * dev, unsigned char pool,
> return;
> }
>
> -// top up all RX pools (can also be called as a bottom half)
> +// top up all RX pools
> static void fill_rx_pools (amb_dev * dev) {
> unsigned char pool;
>
> @@ -872,11 +872,7 @@ static irqreturn_t interrupt_handler(int irq, void *dev_id) {
> ++irq_work;
>
> if (irq_work) {
> -#ifdef FILL_RX_POOLS_IN_BH
> - schedule_work (&dev->bh);
> -#else
> fill_rx_pools (dev);
> -#endif
>
> PRINTD (DBG_IRQ, "work done: %u", irq_work);
> } else {
> @@ -2154,11 +2150,6 @@ static void setup_dev(amb_dev *dev, struct pci_dev *pci_dev)
> dev->tx_avail = ATM_OC3_PCR;
> dev->rx_avail = ATM_OC3_PCR;
>
> -#ifdef FILL_RX_POOLS_IN_BH
> - // initialise bottom half
> - INIT_WORK(&dev->bh, (void (*)(void *)) fill_rx_pools, dev);
> -#endif
> -
> // semaphore for txer/rxer modifications - we cannot use a
> // spinlock as the critical region needs to switch processes
> mutex_init(&dev->vcc_sf);
> diff --git a/drivers/atm/ambassador.h b/drivers/atm/ambassador.h
> index bd1c46a..aa97105 100644
> --- a/drivers/atm/ambassador.h
> +++ b/drivers/atm/ambassador.h
> @@ -630,10 +630,6 @@ struct amb_dev {
> u32 iobase;
> u32 * membase;
>
> -#ifdef FILL_RX_POOLS_IN_BH
> - struct work_struct bh;
> -#endif
> -
> amb_cq cq;
> amb_txq txq;
> amb_rxq rxq[NUM_RX_POOLS];
> --
> 1.7.4.1
>
>
--
Wang Shaoyan
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Ingo Molnar @ 2011-08-05 12:18 UTC (permalink / raw)
To: Jiri Pirko; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805112557.GD1928@minipsycho.orion>
* Jiri Pirko <jpirko@redhat.com> wrote:
> >> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
> >
> >How do i tell that without hacking the driver?
>
> look in dmesg for line like:
> "forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
> desc-v3"
>
> if "vlan" is there, DEV_HAS_VLAN is set
[ 3.534489] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
Note, this is a pretty old system with an old nvidia chipset and
on-board ethernet:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d000 [size=8]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
Thanks,
Ingo
^ permalink raw reply
* RE: [PATCHv2 NEXT 1/1] netxen: add vlan accel support
From: Amit Salecha @ 2011-08-05 12:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ameen Rahman, Rajesh Borundia
In-Reply-To: <20110805.042755.2121843538632981106.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, August 05, 2011 4:58 PM
>
> From: Amit Salecha <amit.salecha@qlogic.com>
> Date: Fri, 5 Aug 2011 06:04:10 -0500
>
> > This is true, but problem is after fw recovery. So flow is
> > 1) vlan device added
> > 2) Driver program ip address of vlan device (through inet events)
> > 3) Fw recovery
> > 4) After fw recovery driver need to program ip addresses again which
> were already programmed.
> > After fw recovery there won't be any inet/netdev event.
> >
> > Simple solution is to maintain those ip addresses in driver.
>
> When you program the device, in response to inet events, maintain a
> software list in the driver that remembers the IP address state.
>
> Then on FW recovery, walk the special list to reprogram the device.
Make sense. Will repost patch with above logic
-Thanks.
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 11:44 UTC (permalink / raw)
To: Neil Horman
Cc: Ingo Molnar, David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805111231.GA29466@hmsreliant.think-freely.org>
Fri, Aug 05, 2011 at 01:12:31PM CEST, nhorman@tuxdriver.com wrote:
>On Fri, Aug 05, 2011 at 12:29:03PM +0200, Ingo Molnar wrote:
>>
>> * Jiri Pirko <jpirko@redhat.com> wrote:
>>
>> > Thu, Aug 04, 2011 at 11:53:54PM CEST, mingo@elte.hu wrote:
>> > >
>> > >* Ingo Molnar <mingo@elte.hu> wrote:
>> > >
>> > >> 0891b0e08937: forcedeth: fix vlans
>> > >
>> > >Hm, forcedeth is still giving me trouble even on latest -git that has
>> > >the above fix included.
>> > >
>> > >The symptom is a stuck interface, no packets in. There's a frame
>> > >error RX packet:
>> > >
>> > > [root@mercury ~]# ifconfig eth0
>> > > eth0 Link encap:Ethernet HWaddr 00:13:D4:DC:41:12
>> > > inet addr:10.0.1.13 Bcast:10.0.1.255 Mask:255.255.255.0
>> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > > RX packets:0 errors:1 dropped:0 overruns:0 frame:1
>> > > TX packets:531 errors:0 dropped:0 overruns:0 carrier:0
>> > > collisions:0 txqueuelen:1000
>> > > RX bytes:0 (0.0 b) TX bytes:34112 (33.3 KiB)
>> > > Interrupt:35
>> > >
>> > >Weirdly enough a defconfig x86 bootup works just fine - it's certain
>> > >.config combinations that trigger the bug. I've attached such a
>> > >config.
>> > >
>> > >Note that at least once i've observed a seemingly good kernel going
>> > >'bad' after a couple of minutes uptime. I've also observed
>> > >intermittent behavior - apparent lost packets and a laggy network.
>> > >
>> > >I have done 3 failed attempts to bisect it any further - i got to the
>> > >commit that got fixed by:
>> > >
>> > > 0891b0e08937: forcedeth: fix vlans
>> > >
>> > >... but that's something we already knew.
>> > >
>> > >Let me know if there's any data i can provide to help debug this
>> > >problem.
>> > >
>> > >Thanks,
>> > >
>> > > Ingo
>> >
>> > Interesting.
>> >
>> > Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>>
>Looks like you can match it to pci id. Device ids 0x0372 and 0x0373 look to
>have the flag set
>
>> How do i tell that without hacking the driver?
>>
>> > If so, would you try to disable both rx an tx vlan accel using
>> > ethtool and see if it helps?
>>
>> Should i do that when the device is in a stuck state and see whether
>> it recovers?
>>
>> Also, please provide the exact ethtool command sequences i should
>> try, this makes it easier for me to test exactly what you want me to
>> test.
>>
>should be:
>ethtool -K ethX rxvlan off txvlan off
>
>I'm just poking about, but If I had to guess it looks like the card you have
>ingo is an older forcedeth and uses the older format ring descriptor (I base
>this on the fact that the rx error count noted above only gets incremented ni
>nv_rx_process, but not nv_rx_process_optimized. Both paths should support hw
>vlan acceleration though and Jiris fixes for vlan hw rx acceleration were only
>applied to the optimized path.
Well hw accel was not implemented in nv_rx_process before so I did not
see any reason to do so during vlan conversion. Anyway, since this path
was touched, I do not see reason why regression might happen there. Only
change is that now hw accel is enabled by default (before, it got
enabled only when vid was added). So if turning off hw accel fixes the
problem for Ingo, I would tend fix this by simply disabling vlan hw
accel for non-optimized path, by patch like this:
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e55df30..3f1b24b 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5341,7 +5341,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
}
np->vlanctl_bits = 0;
- if (id->driver_data & DEV_HAS_VLAN) {
+ if (id->driver_data & DEV_HAS_VLAN && nv_optimized(np)) {
np->vlanctl_bits = NVREG_VLANCONTROL_ENABLE;
dev->hw_features |= NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_TX;
}
Strange kind of hw this is ....
>
>Neil
>
>> Thanks,
>>
>> Ingo
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply related
* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Robin Holt @ 2011-08-05 11:36 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Robin Holt, Wolfgang Grandegger, socketcan-core, netdev
In-Reply-To: <4E3BAB03.4040803@pengutronix.de>
I implemented the coding style changes below (Sorry I missed the two
the first time).
As for a better implementation, I guess I would need to understand what
is being attempted here. I only marginally understand the flexcan
hardware on the Freescale P1010 and certainly am clueless about arm
implementations of flexcan. I just skimmed over freescale's site
and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
and i.MX53 family of processors. I will attempt to find some useful
documentation of those and look at the kernel sources for what the clk_*
functions are trying to accomplish.
I _THINK_ I understand. It looks like I could implement this as a powerpc
p1010 specific thing and get the same effect without impacting flexcan.c.
I also think I understand that the i.MX25 family of processors do
essentially the same thing the p1010 is doing for determining the
clock rate.
Thanks,
Robin
On Fri, Aug 05, 2011 at 10:34:11AM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 04:06 AM, Robin Holt wrote:
> > The freescale P1010RDB board does not have a
> > clk_{get,put,get_rate,enable,disable} set of functions. Wrap these with a
> > flexcan_ #define for arm, and implement a more complete function for ppc.
>
> Some codingstyle nitpicks inline. I hope we'll find a cleaner solution
> than this patch.
>
> Marc
>
> > Signed-off-by: Robin Holt <holt@sgi.com>
> > To: Marc Kleine-Budde <mkl@pengutronix.de>
> > To: Wolfgang Grandegger <wg@grandegger.com>
> > Cc: socketcan-core@lists.berlios.de
> > Cc: netdev@vger.kernel.org
> > ---
> > drivers/net/can/flexcan.c | 114 +++++++++++++++++++++++++++++++++++++++++----
> > 1 files changed, 105 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> > index 74b1706..3417d0b 100644
> > --- a/drivers/net/can/flexcan.c
> > +++ b/drivers/net/can/flexcan.c
> > @@ -220,6 +220,102 @@ static inline void flexcan_write(u32 val, void __iomem *addr)
> > }
> > #endif
> >
> > +#if defined(__powerpc__)
> > +struct flexcan_clk {
> > + unsigned long rate;
> > + void *data;
> > +};
> > +
> > +static struct clk *flexcan_clk_get(struct device *dev, const char *id)
> > +{
> > + struct flexcan_clk *clock;
> > + u32 *clock_freq;
> > + u32 *clock_divider;
> > + int err;
> > +
> > + clock = kmalloc(sizeof(struct flexcan_clk), GFP_KERNEL);
> > + if (!clock) {
> > + dev_err(dev, "Cannot allocate memory\n");
> > + err = -ENOMEM;
> > + goto failed_clock;
> > + }
> > + clock_freq = (u32 *)of_get_property(dev->of_node, "clock_freq", NULL);
> > + if (!clock_freq) {
> > + dev_err(dev, "Cannot find clock_freq property\n");
> > + err = -EINVAL;
> > + goto failed_clock;
> > + }
> > +
> > + clock_divider = (u32 *) of_get_property(dev->of_node,
> ^
>
> remove this space, please
> > + "fsl,flexcan-clock-divider", NULL);
> > + if (clock_divider == NULL) {
>
> !clock_divider
>
> > + dev_err(dev, "Cannot find fsl,flexcan-clock-divider property\n");
> > + err = -EINVAL;
> > + goto failed_clock;
> > + }
> > +
> > + clock->rate = DIV_ROUND_CLOSEST(*clock_freq / *clock_divider, 1000);
> > + clock->rate *= 1000;
> > +
> > + return (struct clk *)clock;
> > +
> > + failed_clock:
> > + kfree(clock);
> > + return ERR_PTR(err);
> > +}
> > +
> > +static inline void flexcan_clk_put(struct clk *_clk)
> > +{
> > + struct flexcan_clk *clk = (struct flexcan_clk *)_clk;
>
> that cast is not needed.
>
> > +
> > + kfree(clk);
> > +}
> > +
> > +static inline int flexcan_clk_enable(struct clk *clk)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void flexcan_clk_disable(struct clk *clk)
> > +{
> > + return;
> > +}
> > +
> > +static inline unsigned long flexcan_clk_get_rate(struct clk *_clk)
> > +{
> > + struct flexcan_clk *clk = (struct flexcan_clk *)_clk;
> > +
> > + return clk->rate;
> > +}
> > +
> > +#else
> > +static inline struct clk *flexcan_clk_get(struct device *dev, const char *id)
> > +{
> > + return clk_get(dev, id);
> > +}
> > +
> > +static inline void flexcan_clk_put(struct clk *clk)
> > +{
> > + clk_put(clk);
> > +}
> > +
> > +static inline int flexcan_clk_enable(struct clk *clk)
> > +{
> > + return clk_enable(clk);
> > +}
> > +
> > +static inline void flexcan_clk_disable(struct clk *clk)
> > +{
> > + clk_disable(clk);
> > +}
> > +
> > +static inline unsigned long flexcan_clk_get_rate(struct clk *clk)
> > +{
> > + return clk_get_rate(clk);
> > +}
> > +
> > +#endif
> > +
> > /*
> > * Swtich transceiver on or off
> > */
> > @@ -807,7 +903,7 @@ static int flexcan_open(struct net_device *dev)
> > struct flexcan_priv *priv = netdev_priv(dev);
> > int err;
> >
> > - clk_enable(priv->clk);
> > + flexcan_clk_enable(priv->clk);
> >
> > err = open_candev(dev);
> > if (err)
> > @@ -829,7 +925,7 @@ static int flexcan_open(struct net_device *dev)
> > out_close:
> > close_candev(dev);
> > out:
> > - clk_disable(priv->clk);
> > + flexcan_clk_disable(priv->clk);
> >
> > return err;
> > }
> > @@ -843,7 +939,7 @@ static int flexcan_close(struct net_device *dev)
> > flexcan_chip_stop(dev);
> >
> > free_irq(dev->irq, dev);
> > - clk_disable(priv->clk);
> > + flexcan_clk_disable(priv->clk);
> >
> > close_candev(dev);
> >
> > @@ -882,7 +978,7 @@ static int __devinit register_flexcandev(struct net_device *dev)
> > struct flexcan_regs __iomem *regs = priv->base;
> > u32 reg, err;
> >
> > - clk_enable(priv->clk);
> > + flexcan_clk_enable(priv->clk);
> >
> > /* select "bus clock", chip must be disabled */
> > flexcan_chip_disable(priv);
> > @@ -916,7 +1012,7 @@ static int __devinit register_flexcandev(struct net_device *dev)
> > out:
> > /* disable core and turn off clocks */
> > flexcan_chip_disable(priv);
> > - clk_disable(priv->clk);
> > + flexcan_clk_disable(priv->clk);
> >
> > return err;
> > }
> > @@ -936,7 +1032,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
> > resource_size_t mem_size;
> > int err, irq;
> >
> > - clk = clk_get(&pdev->dev, NULL);
> > + clk = flexcan_clk_get(&pdev->dev, NULL);
> > if (IS_ERR(clk)) {
> > dev_err(&pdev->dev, "no clock defined\n");
> > err = PTR_ERR(clk);
> > @@ -973,7 +1069,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
> > dev->flags |= IFF_ECHO; /* we support local echo in hardware */
> >
> > priv = netdev_priv(dev);
> > - priv->can.clock.freq = clk_get_rate(clk);
> > + priv->can.clock.freq = flexcan_clk_get_rate(clk);
> > priv->can.bittiming_const = &flexcan_bittiming_const;
> > priv->can.do_set_mode = flexcan_set_mode;
> > priv->can.do_get_berr_counter = flexcan_get_berr_counter;
> > @@ -1008,7 +1104,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
> > failed_map:
> > release_mem_region(mem->start, mem_size);
> > failed_get:
> > - clk_put(clk);
> > + flexcan_clk_put(clk);
> > failed_clock:
> > return err;
> > }
> > @@ -1026,7 +1122,7 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
> > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > release_mem_region(mem->start, resource_size(mem));
> >
> > - clk_put(priv->clk);
> > + flexcan_clk_put(priv->clk);
> >
> > free_candev(dev);
> >
>
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
^ permalink raw reply
* Re: [PATCHv2 NEXT 1/1] netxen: add vlan accel support
From: David Miller @ 2011-08-05 11:27 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, rajesh.borundia
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FE464EF99@MNEXMB2.qlogic.org>
From: Amit Salecha <amit.salecha@qlogic.com>
Date: Fri, 5 Aug 2011 06:04:10 -0500
> This is true, but problem is after fw recovery. So flow is
> 1) vlan device added
> 2) Driver program ip address of vlan device (through inet events)
> 3) Fw recovery
> 4) After fw recovery driver need to program ip addresses again which were already programmed.
> After fw recovery there won't be any inet/netdev event.
>
> Simple solution is to maintain those ip addresses in driver.
When you program the device, in response to inet events, maintain a
software list in the driver that remembers the IP address state.
Then on FW recovery, walk the special list to reprogram the device.
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 11:25 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805102903.GF2420@elte.hu>
Fri, Aug 05, 2011 at 12:29:03PM CEST, mingo@elte.hu wrote:
>
>* Jiri Pirko <jpirko@redhat.com> wrote:
>
>> Thu, Aug 04, 2011 at 11:53:54PM CEST, mingo@elte.hu wrote:
>> >
>> >* Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> >> 0891b0e08937: forcedeth: fix vlans
>> >
>> >Hm, forcedeth is still giving me trouble even on latest -git that has
>> >the above fix included.
>> >
>> >The symptom is a stuck interface, no packets in. There's a frame
>> >error RX packet:
>> >
>> > [root@mercury ~]# ifconfig eth0
>> > eth0 Link encap:Ethernet HWaddr 00:13:D4:DC:41:12
>> > inet addr:10.0.1.13 Bcast:10.0.1.255 Mask:255.255.255.0
>> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > RX packets:0 errors:1 dropped:0 overruns:0 frame:1
>> > TX packets:531 errors:0 dropped:0 overruns:0 carrier:0
>> > collisions:0 txqueuelen:1000
>> > RX bytes:0 (0.0 b) TX bytes:34112 (33.3 KiB)
>> > Interrupt:35
>> >
>> >Weirdly enough a defconfig x86 bootup works just fine - it's certain
>> >.config combinations that trigger the bug. I've attached such a
>> >config.
>> >
>> >Note that at least once i've observed a seemingly good kernel going
>> >'bad' after a couple of minutes uptime. I've also observed
>> >intermittent behavior - apparent lost packets and a laggy network.
>> >
>> >I have done 3 failed attempts to bisect it any further - i got to the
>> >commit that got fixed by:
>> >
>> > 0891b0e08937: forcedeth: fix vlans
>> >
>> >... but that's something we already knew.
>> >
>> >Let me know if there's any data i can provide to help debug this
>> >problem.
>> >
>> >Thanks,
>> >
>> > Ingo
>>
>> Interesting.
>>
>> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>
>How do i tell that without hacking the driver?
look in dmesg for line like:
"forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
desc-v3"
if "vlan" is there, DEV_HAS_VLAN is set
>
>> If so, would you try to disable both rx an tx vlan accel using
>> ethtool and see if it helps?
>
>Should i do that when the device is in a stuck state and see whether
>it recovers?
Yes.
>
>Also, please provide the exact ethtool command sequences i should
>try, this makes it easier for me to test exactly what you want me to
>test.
ethtool -K eth0 txvlan off rxvlan off
>
>Thanks,
>
> Ingo
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-08-05 11:20 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
The only serious regression that I know of which is still
pending is that forcedeth issue Ingo reported and I'm hoping
Jiri can resolve that quickly, otherwise we'll revert all the
VLAN changes as per Ingo's revert patch.
1) Fix sendmmsg() regressions, particularly wrt. certain LSMs which
need to validate the sockaddr of every sendmsg call. From
Tetsuo Handa and Anton Blanchard.
2) Fix truncard ATM packets over br2864, from Chas Williams.
3) sfq_enqueue() corrupts queue state due to missing checks and
call to qdisc_tree_decrease_qlen(), from Eric Dumazet.
4) Paul Moore contact info update.
5) Fix accidental TX restart during NIC unload in bnx2x driver, from
Vladislav Zolotarov.
6) Fix setting MAC address on 8168e-vl chips, from Francois
Romieu.
7) dst->neighbour accesses need RCU handling now, since these days
we can change it on a live object, fix from Eric Dumazet.
8) Two MLX4 bug fixes from Yevgeny Petrilin based upon reports by
Roland Dreier.
9) Fix lost "wrap" bit in TX ring of macb driver during TX underrun
recovery, from Tord Andersson.
10) Fix endianness problems in cdc_ncm driver, from Giuseppe Scrivano.
11) IPV4 multicast code uses wrong variable to index array, from Julia
Lawall.
12) Similar array indexing problem in NIU driver, also from Julia Lawall.
13) Fix sunrpc kerneldoc warning, from Randy Dunlap.
14) Fix ->real_parent access race in proc connector, from Oleg Nesterov.
15) Add device ID for DLINK 530T rev C1 to R8169 driver, from Lennart
Sorensen.
16) sis190 needs private ->ndo_set_mac_address handler so it can update
it's RX filter properly. From Klement Fish.
17) Fix key lengths for rfc3686(ctr(aes)) IPSEC algorithm entry, from
Tushar Gohad.
18) IPVS needs to unregister notifier on module unload, from Hans
Schillstrom and Simon Horman.
19) Fix off-by-one in nl80211_trigger_scan(), from Dan Carpenter.
20) Fix rtlwifi OOPS on ARM, from Larry Finger.
21) Fix accidental bzero() of 'skb' instead of skb data area in rt2x00
driver, oops, fix from Stanislaw Gruszka.
22) Fix regression causing iwlagn to not set driver private properly,
from Emmanuel Grumbach.
23) Do not use power save idle mode on iwl 5000 series chips, from
Wey-Yi Guy.
24) Wake on Lan doesn't work on second port of i350 IGB devices, fix
from Carolyn Wyborny.
25) Fix suspend/resume on ath9k when ASM is disabled, from Stanislaw
Gruszka.
Please pull, thanks a lot!
The following changes since commit 140d0b2108faebc77c6523296e211e509cb9f5f9:
Do 'shm_init_ns()' in an early pure_initcall (2011-08-04 19:35:59 -1000)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net.git master
Anton Blanchard (2):
net: sendmmsg should only return an error if no messages were sent
net: Cap number of elements for sendmmsg
Bruce Allan (2):
e1000e: remove unnecessary check for NULL pointer
e1000e: minor re-order of #include files
Carolyn Wyborny (1):
igb: fix WOL on second port of i350 device
Chas Williams (1):
atm: br2864: sent packets truncated in VC routed mode
Dan Carpenter (1):
cfg80211: off by one in nl80211_trigger_scan()
David S. Miller (4):
Merge branch 'master' of git://git.kernel.org/.../horms/ipvs-2.6
MAINTAINERS: Remove Pekka Savola from ipv6.
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Merge branch 'master' of master.kernel.org:/.../jkirsher/net
Don Skidmore (1):
ixgbe: fix __ixgbe_notify_dca() bail out code
Emil Tantilov (1):
ixgbe: fix PHY link setup for 82599
Emmanuel Grumbach (1):
iwlagn: sysfs couldn't find the priv pointer
Eric Dumazet (3):
sch_sfq: fix sfq_enqueue()
net: add kerneldoc to skb_copy_bits()
net: fix NULL dereferences in check_peer_redir()
Felix Fietkau (1):
ath9k: initialize tx chainmask before testing channel tx power values
Giuseppe Scrivano (1):
cdc_ncm: fix endianness problem.
Helmut Schaa (1):
rt2x00: Fix compilation without CONFIG_RT2X00_LIB_CRYPTO
Jesper Juhl (1):
Documentation/bonding.txt: Update to 3.x version numbers
Jesse Brandeburg (1):
intel drivers: repair missing flush operations
Joe Perches (1):
MAINTAINERS: orphan FrameRelay DLCI
John W. Linville (1):
Merge git://git.kernel.org/.../linville/wireless-next into for-davem
Jon Mason (1):
irda: use PCI_VENDOR_ID_*
Julia Lawall (2):
net: adjust array index
drivers/net/niu.c: adjust array index
Klement Fish (1):
sis190: Rx filter init is needed for MAC address change.
Larry Finger (1):
rtlwifi: Fix kernel oops on ARM SOC
Lennart Sorensen (1):
r8169: Add support for D-Link 530T rev C1 (Kernel Bug 38862)
Max Matveev (1):
ipv6: check for IPv4 mapped addresses when connecting IPv6 sockets
Oleg Nesterov (1):
proc_fork_connector: a lockless ->real_parent usage is not safe
Paul Moore (2):
doc: Update the MAINTAINERS info for Paul Moore
doc: Update the email address for Paul Moore in various source files
Randy Dunlap (1):
net: fix new sunrpc kernel-doc warning
Simon Horman (1):
IPVS: Free resources on module removal
Stanislaw Gruszka (4):
iwlegacy: set tx power after rxon_assoc
ath9k: skip ->config_pci_powersave() if PCIe port has ASPM disabled
rt2x00: rt2800: fix zeroing skb structure
rt2x00: fix usage of NULL queue
Tetsuo Handa (1):
net: Fix security_socket_sendmsg() bypass problem.
Tord Andersson (1):
macb: restore wrap bit when performing underrun cleanup
Tushar Gohad (1):
xfrm: Fix key lengths for rfc3686(ctr(aes))
Vladislav Zolotarov (1):
bnx2x: Prevent restarting Tx during bnx2x_nic_unload
Wey-Yi Guy (1):
iwlagn: 5000 do not support idle mode
Yaniv Rosner (10):
bnx2x: Fix missing pause on for 578xx
bnx2x: Fix chip hanging due to TX pipe stall.
bnx2x: Fix remote fault handling
bnx2x: Fix BCM578xx-B0 MDIO access
bnx2x: Fix LED behavior
bnx2x: Fix link issue with DAC over 578xx
bnx2x: Fix BCM84833 link
bnx2x: Fix BCM54618se invalid link indication
bnx2x: Fix BCM578xx MAC test
bnx2x: Clear MDIO access warning during first driver load
Yevgeny Petrilin (2):
mlx4: Fixing Ethernet unicast packet steering
mlx4: decreasing ref count when removing mac
françois romieu (1):
r8169 : MAC address change fix for the 8168e-vl.
Documentation/networking/bonding.txt | 2 +-
MAINTAINERS | 10 +-
drivers/connector/cn_proc.c | 8 +-
drivers/net/bnx2x/bnx2x_cmn.c | 10 +-
drivers/net/bnx2x/bnx2x_hsi.h | 2 +
drivers/net/bnx2x/bnx2x_link.c | 218 +++++++++++++++++++---------
drivers/net/bnx2x/bnx2x_link.h | 3 +-
drivers/net/bnx2x/bnx2x_reg.h | 6 +-
drivers/net/e1000/e1000_ethtool.c | 6 +
drivers/net/e1000/e1000_hw.c | 3 +
drivers/net/e1000e/es2lan.c | 2 +
drivers/net/e1000e/ethtool.c | 11 ++-
drivers/net/e1000e/ich8lan.c | 7 +-
drivers/net/e1000e/lib.c | 1 +
drivers/net/e1000e/netdev.c | 2 +-
drivers/net/e1000e/phy.c | 2 +
drivers/net/igb/e1000_nvm.c | 1 +
drivers/net/igb/igb_ethtool.c | 5 +
drivers/net/igb/igb_main.c | 4 +-
drivers/net/igbvf/netdev.c | 2 +
drivers/net/irda/smsc-ircc2.c | 18 +--
drivers/net/ixgb/ixgb_ee.c | 9 +
drivers/net/ixgb/ixgb_hw.c | 2 +
drivers/net/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ixgbe/ixgbe_common.c | 1 +
drivers/net/ixgbe/ixgbe_ethtool.c | 5 +
drivers/net/ixgbe/ixgbe_main.c | 3 +-
drivers/net/ixgbe/ixgbe_phy.c | 3 +
drivers/net/ixgbe/ixgbe_x540.c | 1 +
drivers/net/macb.c | 3 +
drivers/net/mlx4/en_port.c | 2 +-
drivers/net/mlx4/main.c | 2 +
drivers/net/mlx4/port.c | 9 +-
drivers/net/niu.c | 4 +-
drivers/net/r8169.c | 28 ++++
drivers/net/sis190.c | 12 ++-
drivers/net/usb/cdc_ncm.c | 156 +++++++-------------
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 6 +-
drivers/net/wireless/ath/ath9k/hw.c | 11 +-
drivers/net/wireless/ath/ath9k/hw.h | 3 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +
drivers/net/wireless/ath/ath9k/pci.c | 27 ++++
drivers/net/wireless/iwlegacy/iwl-3945.c | 6 +-
drivers/net/wireless/iwlegacy/iwl-4965.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 1 +
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +
drivers/net/wireless/iwlwifi/iwl-pci.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 3 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 3 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 5 +-
drivers/net/wireless/rtlwifi/pci.c | 20 ++-
include/net/cipso_ipv4.h | 2 +-
include/net/dst.h | 17 ++-
include/net/netlabel.h | 2 +-
net/atm/br2684.c | 2 -
net/core/skbuff.c | 17 ++-
net/ipv4/igmp.c | 2 +-
net/ipv4/ip_output.c | 10 +-
net/ipv4/route.c | 14 +-
net/ipv6/addrconf.c | 2 +-
net/ipv6/datagram.c | 11 +-
net/ipv6/ip6_fib.c | 2 +-
net/ipv6/ip6_output.c | 13 ++-
net/ipv6/route.c | 35 +++--
net/netfilter/ipvs/ip_vs_ctl.c | 1 +
net/netlabel/Makefile | 2 -
net/netlabel/netlabel_addrlist.c | 2 +-
net/netlabel/netlabel_addrlist.h | 2 +-
net/netlabel/netlabel_cipso_v4.c | 2 +-
net/netlabel/netlabel_cipso_v4.h | 2 +-
net/netlabel/netlabel_domainhash.c | 2 +-
net/netlabel/netlabel_domainhash.h | 2 +-
net/netlabel/netlabel_kapi.c | 2 +-
net/netlabel/netlabel_mgmt.c | 2 +-
net/netlabel/netlabel_mgmt.h | 2 +-
net/netlabel/netlabel_unlabeled.c | 2 +-
net/netlabel/netlabel_unlabeled.h | 2 +-
net/netlabel/netlabel_user.c | 2 +-
net/netlabel/netlabel_user.h | 2 +-
net/sched/sch_sfq.c | 7 +-
net/socket.c | 73 +++++----
net/sunrpc/xprt.c | 1 +
net/wireless/nl80211.c | 2 +-
net/xfrm/xfrm_algo.c | 4 +-
security/selinux/hooks.c | 2 +-
security/selinux/include/netif.h | 2 +-
security/selinux/include/netlabel.h | 2 +-
security/selinux/include/netnode.h | 2 +-
security/selinux/include/netport.h | 2 +-
security/selinux/netif.c | 2 +-
security/selinux/netlabel.c | 2 +-
security/selinux/netnode.c | 2 +-
security/selinux/netport.c | 2 +-
security/selinux/selinuxfs.c | 2 +-
security/selinux/ss/ebitmap.c | 2 +-
security/selinux/ss/mls.c | 2 +-
security/selinux/ss/mls.h | 2 +-
security/selinux/ss/policydb.c | 2 +-
security/selinux/ss/services.c | 2 +-
security/smack/smack_lsm.c | 2 +-
102 files changed, 615 insertions(+), 350 deletions(-)
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Neil Horman @ 2011-08-05 11:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jiri Pirko, David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805102903.GF2420@elte.hu>
On Fri, Aug 05, 2011 at 12:29:03PM +0200, Ingo Molnar wrote:
>
> * Jiri Pirko <jpirko@redhat.com> wrote:
>
> > Thu, Aug 04, 2011 at 11:53:54PM CEST, mingo@elte.hu wrote:
> > >
> > >* Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > >> 0891b0e08937: forcedeth: fix vlans
> > >
> > >Hm, forcedeth is still giving me trouble even on latest -git that has
> > >the above fix included.
> > >
> > >The symptom is a stuck interface, no packets in. There's a frame
> > >error RX packet:
> > >
> > > [root@mercury ~]# ifconfig eth0
> > > eth0 Link encap:Ethernet HWaddr 00:13:D4:DC:41:12
> > > inet addr:10.0.1.13 Bcast:10.0.1.255 Mask:255.255.255.0
> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > RX packets:0 errors:1 dropped:0 overruns:0 frame:1
> > > TX packets:531 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:1000
> > > RX bytes:0 (0.0 b) TX bytes:34112 (33.3 KiB)
> > > Interrupt:35
> > >
> > >Weirdly enough a defconfig x86 bootup works just fine - it's certain
> > >.config combinations that trigger the bug. I've attached such a
> > >config.
> > >
> > >Note that at least once i've observed a seemingly good kernel going
> > >'bad' after a couple of minutes uptime. I've also observed
> > >intermittent behavior - apparent lost packets and a laggy network.
> > >
> > >I have done 3 failed attempts to bisect it any further - i got to the
> > >commit that got fixed by:
> > >
> > > 0891b0e08937: forcedeth: fix vlans
> > >
> > >... but that's something we already knew.
> > >
> > >Let me know if there's any data i can provide to help debug this
> > >problem.
> > >
> > >Thanks,
> > >
> > > Ingo
> >
> > Interesting.
> >
> > Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>
Looks like you can match it to pci id. Device ids 0x0372 and 0x0373 look to
have the flag set
> How do i tell that without hacking the driver?
>
> > If so, would you try to disable both rx an tx vlan accel using
> > ethtool and see if it helps?
>
> Should i do that when the device is in a stuck state and see whether
> it recovers?
>
> Also, please provide the exact ethtool command sequences i should
> try, this makes it easier for me to test exactly what you want me to
> test.
>
should be:
ethtool -K ethX rxvlan off txvlan off
I'm just poking about, but If I had to guess it looks like the card you have
ingo is an older forcedeth and uses the older format ring descriptor (I base
this on the fact that the rx error count noted above only gets incremented ni
nv_rx_process, but not nv_rx_process_optimized. Both paths should support hw
vlan acceleration though and Jiris fixes for vlan hw rx acceleration were only
applied to the optimized path.
Neil
> Thanks,
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE: [PATCHv2 NEXT 1/1] netxen: add vlan accel support
From: Amit Salecha @ 2011-08-05 11:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ameen Rahman, Rajesh Borundia
In-Reply-To: <20110805.032606.1214964517719657458.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, August 05, 2011 3:56 PM
>
> From: Amit Salecha <amit.salecha@qlogic.com>
> Date: Fri, 5 Aug 2011 05:12:37 -0500
>
> > After fw recovery we don't get vlan devices by any kernel api, so we
> > are adding NETIF_VLAN_ACC support. Earlier kernel had vlan group
> > support, through that we get vlan devices and then their ip
> > addresses.
>
> Every time an IP address is added or removed there is a notification
> generated on the "inetaddr_chain", and you seem to be properly using
> this.
>
> You have the VLAN device expansion in there as well.
>
> Why doesn't this work?
>
> The IP addresses cannot be added or removed from the VLAN device
> until it is attached to your device. So you should see any IP
> address manipulation that occurs for VLANs stacked on top of
> your device.
>
This is true, but problem is after fw recovery. So flow is
1) vlan device added
2) Driver program ip address of vlan device (through inet events)
3) Fw recovery
4) After fw recovery driver need to program ip addresses again which were already programmed.
After fw recovery there won't be any inet/netdev event.
Simple solution is to maintain those ip addresses in driver.
It can be more easier, if we can get vlan ip addresses(or vlan device) by some kernel api.
-Amit
^ 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