* Re: bisect results of MSI-X related panic (help!)
From: Tejun Heo @ 2009-10-12 7:52 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Frans Pop, Jesse Brandeburg, linux-kernel, netdev, Ingo Molnar,
hpa
In-Reply-To: <4807377b0910091724k2a332e90i9941971f6032663c@mail.gmail.com>
Jesse Brandeburg wrote:
> Kernel stack is corrupted in: ffffffff810b5b31
>
> I've built with a full debug kernel before this crash, so I did:
>
> (gdb) l *0xffffffff810b5b31
> 0xffffffff810b5b31 is in move_native_irq (kernel/irq/migration.c:67).
> 62 return;
> 63
> 64 desc->chip->mask(irq);
> 65 move_masked_irq(irq);
> 66 desc->chip->unmask(irq);
>>>> 67 }
> 68
> (gdb) l move_native_irq
> 54 void move_native_irq(int irq)
> 55 {
> 56 struct irq_desc *desc = irq_to_desc(irq);
> 57
> 58 if (likely(!(desc->status & IRQ_MOVE_PENDING)))
> 59 return;
> 60
> 61 if (unlikely(desc->status & IRQ_DISABLED))
> 62 return;
> 63
> 64 desc->chip->mask(irq);
> 65 move_masked_irq(irq);
> 66 desc->chip->unmask(irq);
> 67 }
>
> So, this seems very related to my panic, as it is likely that
> irqbalance or something else might try to move my interrupt from one
> core to another and this seems likely related, and the original issue
> as well as this one reproduce with LOTS of MSI-X vectors active.
>
> - I tried connecting after the panic with kgdboc, no connection
> - I tried kdump, but the same kernel I am using panics/hangs during
> boot right after udev during the kexec() kernel boot (should I try
> harder to get this working given it got so far?)
> - I have ftrace function tracer running but no way to get at the log
> post panic (wouldn't it be great if the kernel just dumped the ftrace
> log on __stack_chk_fail?)
>
> any other debugging tricks/ideas?
Hmm... stackprotector adds considerable amount of stack usage and it
could be you're seeing stack overflow which would also explain the
random crashes you've been seeing. Do you have DEBUG_STACKOVERFLOW
turned on? This is on x86_64, right?
--
tejun
^ permalink raw reply
* Re: [PATCH] [CAIF-RFC 1/8-v2] CAIF Protocol Stack
From: Stefano Babic @ 2009-10-12 8:08 UTC (permalink / raw)
To: sjur.brandeland
Cc: netdev, kim.xx.lilliestierna, christian.bejram, daniel.martensson
In-Reply-To: <1255095571-6501-2-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com wrote:
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Change-Id: I305056f116a11c31265f65ac0fe285e2b655dd54
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
> ---
> include/linux/caif/caif_config.h | 203 ++++++++++++++++++++++++++++++++++++++
> include/linux/caif/caif_ioctl.h | 113 +++++++++++++++++++++
> 2 files changed, 316 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/caif/caif_config.h
> create mode 100644 include/linux/caif/caif_ioctl.h
>
> diff --git a/include/linux/caif/caif_config.h b/include/linux/caif/caif_config.h
> new file mode 100644
> index 0000000..6ea934b
> --- /dev/null
> +++ b/include/linux/caif/caif_config.h
> @@ -0,0 +1,203 @@
> +/*
> + * Copyright (C) ST-Ericsson AB 2009
> + *
> + * CAIF Channel Configuration definitions.
> + *
> + * Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
> + *
> + * License terms: GNU General Public License (GPL), version 2.
In the majority of linux drivers we find the following statements to set
up the license terms :
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
> + * \b Documentation see STE Doc No: 155 19-CRH 109 913.
Probably you should remove this line as you already did in other places.
> diff --git a/include/linux/caif/caif_ioctl.h b/include/linux/caif/caif_ioctl.h
> +/* Use 'g' as magic number. 'g' is the first free letter in
> + * Documentation/ioctl-number.txt*/
The file is Documentation/ioctl/ioctl-number.txt
Stefano
--
stefano <stefano.babic@babic.homelinux.org>
GPG Key: 0x55814DDE
Fingerprint 4E85 2A66 4CBA 497A 2A7B D3BF 5973 F216 5581 4DDE
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: David Miller @ 2009-10-12 8:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: yoshfuji, netdev
In-Reply-To: <4AD2DB99.3070208@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 12 Oct 2009 09:32:41 +0200
> Sorry I dont get it
>
> u32 val = any_value ;
> u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
>
> If not, something is broken and should be fixed.
Indeed, it's "x >> 32" which is undefined and has to be done as
something like "(x >> 31) >> 1" when performed on a u32 object.
Yoshfuji is this patch really necessary?
^ permalink raw reply
* Re: [PATCH] [CAIF-RFC 1/8-v2] CAIF Protocol Stack
From: David Miller @ 2009-10-12 8:20 UTC (permalink / raw)
To: stefano.babic
Cc: sjur.brandeland, netdev, kim.xx.lilliestierna, christian.bejram,
daniel.martensson
In-Reply-To: <4AD2E404.80704@babic.homelinux.org>
From: Stefano Babic <stefano.babic@babic.homelinux.org>
Date: Mon, 12 Oct 2009 10:08:36 +0200
> sjur.brandeland@stericsson.com wrote:
>> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>> @@ -0,0 +1,203 @@
>> +/*
>> + * Copyright (C) ST-Ericsson AB 2009
>> + *
>> + * CAIF Channel Configuration definitions.
>> + *
>> + * Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
>> + *
>> + * License terms: GNU General Public License (GPL), version 2.
>
> In the majority of linux drivers we find the following statements to set
> up the license terms :
>
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
But Linus has stated explicitly that Linux itself falls under
GPL v2 and only v2.
See COPYING at the top level of the kernel sources.
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Tilman Schmidt @ 2009-10-12 8:28 UTC (permalink / raw)
To: Johannes Berg
Cc: Dave Young, linux-kernel, tglx, linux-wireless, David S. Miller,
linux-ppp, netdev, Paul Mackerras
In-Reply-To: <1255261251.4095.143.camel@johannes.local>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[CCing PPP people]
Am 11.10.2009 13:40 schrieb Johannes Berg:
> On Sun, 2009-10-11 at 13:18 +0200, Tilman Schmidt wrote:
>
>> Can you explain a bit more what that message is about?
>> I am encountering it in a completely different context
>> (PPP over ISDN) [...]
>
> Basically, calling netif_rx() with softirqs enabled.
AFAICS that would have to be the netif_rx() call in
ppp_receive_nonmp_frame() [drivers/net/ppp_generic.c#L1791],
called (via others) from the tasklet work function
ppp_sync_process() [drivers/net/ppp_synctty.c#L545].
Should that be changed to the
"if (in_interrupt()) netif_rx(skb) else netif_rx_ni(skb)"
stanza from the linux.kernel.wireless.general thread then?
Thanks,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFK0ujIQ3+did9BuFsRAtGBAJ9rj2pyQZ75ZKTipLhpICqA3ZvTdQCdHQs/
RmdeOT3TuPZykXJxcHLJCzU=
=87DI
-----END PGP SIGNATURE-----
^ permalink raw reply
* kernel mode pppoe ppp if + ifb + mirred redirect, ethernet packets in ifb?!
From: Denys Fedoryschenko @ 2009-10-12 8:43 UTC (permalink / raw)
To: netdev, hadi
Hi
I am using kernel mode pppoe, and while using mirred on ppp interfaces (to
shape users upstream) noticed very strange behaviour (and IMHO wrong)
$2 - ppp interface
tc filter add dev $2 parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0"
If i do tcpdump on ppp interface i can see normal ip traffic
PPPoE_146 ~ # tcpdump -ni ppp6 -c 100
tcpdump: WARNING:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp6, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
11:36:16.541742 IP 172.16.131.221.2182 > 64.4.50.51.443: Flags [F.], seq
2636760792, ack 2812561777, win 64963, length 0
If i do tcpdump on ifb0 i will see PPPoE incapsulated traffic!
PPPoE_146 ~ # tcpdump -ni ifb0 -c 100
tcpdump: WARNING: ifb0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes
11:36:58.949727 PPPoE [ses 0x15] IP 172.16.98.22.2081 > 94.75.218.20.80:
Flags [S], seq 3205622298, win 65535, options [mss 1440,nop,nop,sackOK],
length 0
11:36:58.531473 PPPoE [ses 0xd] IP 172.16.98.14.16526 > 128.16.130.164.445:
Flags [S], seq 98566173, win 65535, options [mss 1440,nop,nop,sackOK], length
0
Is it expected that redirecting ppp interface, that supposed to be clean IP
traffic is becoming eth encapsulated traffic?
Probably some bad interaction with kernel mode pppoe?
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: YOSHIFUJI Hideaki @ 2009-10-12 8:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <4AD2DB99.3070208@gmail.com>
Eric Dumazet wrote:
> YOSHIFUJI Hideaki a écrit :
> > ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
> >
> > Do not use bit-shift if relay_prefixlen == 0;
> > relay_prefix << 32 does not result in 0.
> >
> > Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > ---
> > net/ipv6/sit.c | 9 ++++++---
> > 1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> > index 193d0c6..510d31f 100644
> > --- a/net/ipv6/sit.c
> > +++ b/net/ipv6/sit.c
> > @@ -1014,9 +1014,12 @@ ipip6_tunnel_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd)
> > ip6rd.prefixlen);
> > if (!ipv6_addr_equal(&prefix, &ip6rd.prefix))
> > goto done;
> > - relay_prefix = ip6rd.relay_prefix &
> > - htonl(0xffffffffUL <<
> > - (32 - ip6rd.relay_prefixlen));
> > + if (ip6rd.relay_prefixlen)
> > + relay_prefix = ip6rd.relay_prefix &
> > + htonl(0xffffffffUL <<
> > + (32 - ip6rd.relay_prefixlen));
> > + else
> > + relay_prefix = 0;
> > if (relay_prefix != ip6rd.relay_prefix)
> > goto done;
> >
>
>
> Sorry I dont get it
>
> u32 val = any_value ;
> u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
>
> If not, something is broken and should be fixed.
Unfortunately, on x86 architecture (80286 and later at least),
lower 5 bits (& 0x1f) are used for shift operation.
Thus, 0xffffffffUL << 32 gives 0xffffffffUL.
--yoshfuji
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: YOSHIFUJI Hideaki @ 2009-10-12 9:03 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20091012.011802.119775755.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 12 Oct 2009 09:32:41 +0200
>
> > Sorry I dont get it
> >
> > u32 val = any_value ;
> > u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
> >
> > If not, something is broken and should be fixed.
>
> Indeed, it's "x >> 32" which is undefined and has to be done as
> something like "(x >> 31) >> 1" when performed on a u32 object.
>
> Yoshfuji is this patch really necessary?
Well, yes.
6rd allows 32 bit suffix (0 bit prefix).
--yoshfuji
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: eric.dumazet, netdev
In-Reply-To: <1255337454.2878.7.camel@cirrhata.linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Mon, 12 Oct 2009 17:50:54 +0900
> Unfortunately, on x86 architecture (80286 and later at least),
> lower 5 bits (& 0x1f) are used for shift operation.
> Thus, 0xffffffffUL << 32 gives 0xffffffffUL.
Indeed, thanks for the explanation, I thought only right
shift mattered for this case of "shift count larger than
type".
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ipv6 sit: Ensure to initialize 6rd parameters.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <4AD1DE36.8070500@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 11 Oct 2009 22:31:34 +0900
> ipv6 sit: Ensure to initialize 6rd parameters.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [RESED PATCH net-next-2.6 2/3] ipv6 sit: Fix 6rd relay address.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <4AD1E14D.6030903@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 11 Oct 2009 22:44:45 +0900
> ipv6 sit: Fix 6rd relay address.
>
> Relay's address should be extracted from real IPv6 address
> instead of configured prefix.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <4AD1E169.6090705@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 11 Oct 2009 22:45:13 +0900
> ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
>
> Do not use bit-shift if relay_prefixlen == 0;
> relay_prefix << 32 does not result in 0.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/7] bnx2x: Refactor bnx2x_sp_post().
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: mchan; +Cc: netdev, michaelc, shmulikr, eilong
In-Reply-To: <1255218419-17320-1-git-send-email-mchan@broadcom.com>
All 7 patches applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH] [CAIF-RFC 2/8-v2] CAIF Protocol Stack
From: Stefano Babic @ 2009-10-12 9:28 UTC (permalink / raw)
To: sjur.brandeland
Cc: netdev, kim.xx.lilliestierna, christian.bejram, daniel.martensson
In-Reply-To: <1255095571-6501-3-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com wrote:
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
Hi Sjur,
> diff --git a/include/net/caif/generic/cfcnfg.h b/include/net/caif/generic/cfcnfg.h
> +/** Types of Physical Layers defined in CAIF Stack */
> +typedef enum _cfcnfg_phy_type_t {
> + CFPHYTYPE_UNKNOWN = 0,
> + CFPHYTYPE_SERIAL = 1, /*!< Serial Physical Interface */
> + CFPHYTYPE_SPI = 2, /*!< SPI Physical Interface */
> + CFPHYTYPE_MSL = 3, /*!< MSL Physical Interface */
> + CFPHYTYPE_SHM = 4, /*!< Shared Memory Physical Interface */
You actually removed the shared memory driver. Do you plan to insert it
again ?
> +/**
> + * Adds a Adaptation Layer to the CAIF Stack.
> + * The Adaptation Layer is where the interface to application or higher-level
> + * driver functionality is implemented.
> + * \image html AddVeiCaifConfig.jpg "Add an Adaptation layer to CAIF Stack."
There are references to pictures that are not provided.
> diff --git a/include/net/caif/generic/cfglue.h b/include/net/caif/generic/cfglue.h
[snip]
> +/* ASSERT */
> +#define cfglu_assert(exp) BUG_ON(!(exp))
I do not why, but even GENERIC_BUG is not defined for all architectures.
This means that BUG_ON is simply removed by the compiler and we get no
track if the assert fails.
It should be better to add at least an internal trace (adding for
example a CFLOG_FATAL call).
> diff --git a/include/net/caif/generic/cfshml.h b/include/net/caif/generic/cfshml.h
Is thif file probably obsolete ?
> diff --git a/include/net/caif/generic/cfspil.h b/include/net/caif/generic/cfspil.h
> +/** @page SPI PHY Layer description.
> + *
> + * SPI Physical layer is not implemented in GenCaif. The SPI PHY Layer
> + * is HW dependent. But the CFSPIL (Caif SPI Layer) provides support for
> + * implementing the SPI Layer Protocol.
Not sure I have understood. There is an abstraction layer for SPI in
kernel and some generic purpose functions are provided (spy_sync,
spi_async, etc.) that are HW independent. I know they provide only the
methods for the data transfer, but I have imagined that we need at this
point some kind of "caif_spi_device" that is able to talk with the caif
stack on one side and uses the functions in the SPI framework. In any
case, HW independent. Have I missed something ?
Stefano
--
stefano <stefano.babic@babic.homelinux.org>
GPG Key: 0x55814DDE
Fingerprint 4E85 2A66 4CBA 497A 2A7B D3BF 5973 F216 5581 4DDE
^ permalink raw reply
* Re: [PATCH] [CAIF-RFC 0/8-v2] CAIF Protocol Stack
From: David Miller @ 2009-10-12 9:41 UTC (permalink / raw)
To: sjur.brandeland
Cc: netdev, stefano.babic, randy.dunlap, kim.xx.lilliestierna,
christian.bejram, daniel.martensson
In-Reply-To: <1255095571-6501-1-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Fri, 09 Oct 2009 15:39:23 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> This is the second version of the CAIF patch set.
> The patch set is compiled on 386 for 2.6.31.
> All feedback is apreciated.
There is a lot of coding style issues here I'd like you to
address in your next submission.
Comments are formatted in several places like this:
/*
*
*
*/
It should be:
/*
*
*
*/
Also often there are tons of extraneous empty lines in the source
files. Particularly right after the comment at the top of the
source file. For example include/net/caif/generic/cfcnfg.h
there is the top comment (which needs to be fixed as described
above) and then 8 empty lines before the #ifndef CFCNFG_H_
That's rediculious, just have one empty line there seperating things.
Seriously, you should be able to just scan over your patch and see all
of these oddities. They jumped right out at me. Please clean them
up.
Thank you.
^ permalink raw reply
* Re: Ping Is Broken
From: Jarek Poplawski @ 2009-10-12 9:47 UTC (permalink / raw)
To: CentOS mailing list
Cc: public-netdev-u79uwXL29TY76Z2rM5mHXA, Omaha Linux User Group
In-Reply-To: <7e84ed60910090944q5c66ea0w63ed55a72482bf2f@mail.gmail.com>
On 09-10-2009 18:44, Rob Townley wrote:
> ping -I is broken
>
> The following deals with bug in ping that made it very difficult to set up a
> system with two gateways.
>
> Demonstration that *ping -I is broken*. When specifying the source
> interface using -I with an *ethX* alias and that interface is not the
> default gateway
> interface, then ping fails. When specifying the interface as an ip address,
> ping works. Search for "Destination Host Unreachable" to find the bug.
>
>
> eth*0* = 4.3.2.8 and the default gateway is accessed through a different
> interface eth*1*.
> eth*1* = 192.168.168.155 is used as the device to get to the default
> gateway.
> *FAILS *: ping *-I eth0* 208.67.222.222
> *WORKS*: ping *-I 4.3.2.8* 208.67.222.222
> *WORKS*: ping *-I eth1* 208.67.222.222
> *WORKS*: ping *-I 192.168.168.155* 208.67.222.222
...
> man ping:
> -I interface address
> Set source address to specified interface address.
> Argument may be *numeric IP address or name of device*.
> When pinging IPv6 link-local address this option is required.
It seems this description might be misleading that IP address and name
of device are equivalent here, while they are treated a bit different.
The device name is additionally used in a sendmsg message, probably to
guarantee the device is really used (not its address only), so it
looks like intended.
> ping -V returns the latest available on CentOS and Fedora and the
> maintainers website:
> ping utility, iputils-ss020927
I guess the patch below could do what you expect in this case, but
rather "man" should be fixed...
Jarek P.
---
--- ping.c.orig 2002-09-20 15:08:11.000000000 +0000
+++ ping.c 2009-10-12 08:51:25.000000000 +0000
@@ -323,7 +323,7 @@ main(int argc, char **argv)
perror("ping: icmp open socket");
exit(2);
}
-
+#if 0
if (device) {
struct ifreq ifr;
@@ -336,7 +336,7 @@ main(int argc, char **argv)
cmsg.ipi.ipi_ifindex = ifr.ifr_ifindex;
cmsg_len = sizeof(cmsg);
}
-
+#endif
if (broadcast_pings || IN_MULTICAST(ntohl(whereto.sin_addr.s_addr))) {
if (uid) {
if (interval < 1000) {
^ permalink raw reply
* Re: [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v4)
From: David Miller @ 2009-10-12 10:01 UTC (permalink / raw)
To: eric.dumazet; +Cc: nhorman, netdev, socketcan
In-Reply-To: <4AD2B2BF.8040706@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 12 Oct 2009 06:38:23 +0200
> Neil Horman a écrit :
>> 3) This applies cleanly to net-next assuming that commit
>> 977750076d98c7ff6cbda51858bb5a5894a9d9ab (my af packet cmsg patch) is reverted
>>
>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Thanks Neil
>
> I found no obvious error in this v4, except two long lines.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I reverted the AF_PACKET commit and applied this patch,
thanks!
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: David Miller @ 2009-10-12 10:32 UTC (permalink / raw)
To: tilman
Cc: johannes, hidave.darkstar, linux-kernel, tglx, linux-wireless,
linux-ppp, netdev, paulus
In-Reply-To: <4AD2E8C8.4060205@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Mon, 12 Oct 2009 10:28:56 +0200
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [CCing PPP people]
>
> Am 11.10.2009 13:40 schrieb Johannes Berg:
>> On Sun, 2009-10-11 at 13:18 +0200, Tilman Schmidt wrote:
>>
>>> Can you explain a bit more what that message is about?
>>> I am encountering it in a completely different context
>>> (PPP over ISDN) [...]
>>
>> Basically, calling netif_rx() with softirqs enabled.
>
> AFAICS that would have to be the netif_rx() call in
> ppp_receive_nonmp_frame() [drivers/net/ppp_generic.c#L1791],
> called (via others) from the tasklet work function
> ppp_sync_process() [drivers/net/ppp_synctty.c#L545].
> Should that be changed to the
> "if (in_interrupt()) netif_rx(skb) else netif_rx_ni(skb)"
> stanza from the linux.kernel.wireless.general thread then?
The PPP receive paths in ppp_generic.c do a local_bh_disable()/
local_bh_enable() around packet receiving (via ppp_recv_lock()/
ppp_recv_unlock() in ppp_do_recv).
So at least that part is perfectly fine.
ppp_input(), as called from ppp_sync_process(), also disables BH's
around ppp_do_recv() calls (via read_lock_bh()/read_unlock_bh()).
So that's fine too.
Do you have a bug report or are you just scanning around looking
for trouble? :-)
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Scott James Remnant @ 2009-10-12 10:41 UTC (permalink / raw)
To: Matt Domsch; +Cc: Narendra K, netdev, linux-hotplug, jordan_hargrave
In-Reply-To: <20091009145137.GD19218@mock.linuxdev.us.dell.com>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Fri, 2009-10-09 at 09:51 -0500, Matt Domsch wrote:
> As has been noted here, MAC addresses are not necessarily unique to an
> interface. As such, we are not proposing a net/by-mac/* symlink to
> /dev/netdev/*.
>
On the other hand, they *tend* to be unique for a wide range of systems.
This makes them pretty comparable to LABELs on disks, and we have
a /dev/disk/by-label
Remember that udev already supports symlink stacking, and priorities and
such.
I don't think there's any danger of supporting a /dev/netdev/by-mac by
default, it'll be a benefit to most and those who don't have unique MACs
will just ignore it.
Scott
--
Scott James Remnant
scott@ubuntu.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Bug #14252] WARNING: at include/linux/skbuff.h:1382 w/ e1000
From: David Miller @ 2009-10-12 10:49 UTC (permalink / raw)
To: rjw
Cc: linux-kernel, kernel-testers, skraw, netdev, jeffrey.t.kirsher,
jesse.brandeburg, peter.p.waskiewicz.jr
In-Reply-To: <L6tb-VyKHZK.A.9UD.zzl0KB@chimera>
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Mon, 12 Oct 2009 01:01:06 +0200 (CEST)
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.30 and 2.6.31.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14252
> Subject : WARNING: at include/linux/skbuff.h:1382 w/ e1000
> Submitter : Stephan von Krawczynski <skraw@ithnet.com>
> Date : 2009-09-20 11:26 (22 days old)
> References : http://marc.info/?l=linux-kernel&m=125344599006033&w=4
Hmmm... e1000 calls skb_trim() on both jumbo and non-jumbo ring
buffers which get recycled.
At least for the Jumbo case, that's illegal as you cannot call
skb_trim() on an SKB with paged data.
But this assertion is triggering for the non-jumbo ring where
only linear packets should be present as far as I can tell.
Some Intel folks need to take a look, CC:'d, and people need
to CC: their networking bug reports to netdev@vger.kernel.org
so that the proper folks see it.
Thanks.
^ permalink raw reply
* Re: [Bug #14265] ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100
From: David Miller @ 2009-10-12 11:05 UTC (permalink / raw)
To: rjw; +Cc: linux-kernel, kernel-testers, karol.k.lewandowski, mel, netdev
In-Reply-To: <L6tb-VyKHZK.A.YoC.lzl0KB@chimera>
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Mon, 12 Oct 2009 01:01:08 +0200 (CEST)
[ Netdev CC:'d ]
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14265
> Subject : ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100
> Submitter : Karol Lewandowski <karol.k.lewandowski@gmail.com>
> Date : 2009-09-15 12:05 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=125301636509517&w=4
A 128K memory allocation fails after resume, film at 11.
That e100 driver code has been that way forever, so likely it's
something in the page allocator or similar that is making this happen
more likely now. Perhaps it's related to the iwlagn allocation
failures being tracked down in another thread.
It's a shame that pci_alloc_consistent() has to always use GFP_ATOMIC
for compatability.
As far as I can tell, these code paths can sleep. So maybe the
following hack would fix this for now. Could someone test this?
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 679965c..c71729f 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1780,9 +1780,9 @@ static void e100_clean_cbs(struct nic *nic)
nic->cb_to_clean = nic->cb_to_clean->next;
nic->cbs_avail++;
}
- pci_free_consistent(nic->pdev,
- sizeof(struct cb) * nic->params.cbs.count,
- nic->cbs, nic->cbs_dma_addr);
+ dma_free_coherent(&nic->pdev->dev,
+ sizeof(struct cb) * nic->params.cbs.count,
+ nic->cbs, nic->cbs_dma_addr);
nic->cbs = NULL;
nic->cbs_avail = 0;
}
@@ -1800,8 +1800,10 @@ static int e100_alloc_cbs(struct nic *nic)
nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL;
nic->cbs_avail = 0;
- nic->cbs = pci_alloc_consistent(nic->pdev,
- sizeof(struct cb) * count, &nic->cbs_dma_addr);
+ nic->cbs = dma_alloc_coherent(&nic->pdev->dev,
+ sizeof(struct cb) * count,
+ &nic->cbs_dma_addr,
+ GFP_KERNEL);
if (!nic->cbs)
return -ENOMEM;
@@ -2655,16 +2657,16 @@ static int e100_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
static int e100_alloc(struct nic *nic)
{
- nic->mem = pci_alloc_consistent(nic->pdev, sizeof(struct mem),
- &nic->dma_addr);
+ nic->mem = dma_alloc_coherent(&nic->pdev->dev, sizeof(struct mem),
+ &nic->dma_addr, GFP_KERNEL);
return nic->mem ? 0 : -ENOMEM;
}
static void e100_free(struct nic *nic)
{
if (nic->mem) {
- pci_free_consistent(nic->pdev, sizeof(struct mem),
- nic->mem, nic->dma_addr);
+ dma_free_coherent(&nic->pdev->dev, sizeof(struct mem),
+ nic->mem, nic->dma_addr);
nic->mem = NULL;
}
}
^ permalink raw reply related
* Re: [PATCH] acenic: Pass up error code from ace_load_firmware()
From: David Miller @ 2009-10-12 11:19 UTC (permalink / raw)
To: ben; +Cc: jes, linux-acenic, netdev
In-Reply-To: <1255311286.2488.11.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 12 Oct 2009 02:34:46 +0100
> If ace_load_firmware() fails, ace_init() cleans up but still returns
> 0, leading to an oops as seen in <http://bugs.debian.org/521383>.
> It should pass the error code up.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied, and I'll queue this up for -stable, thanks!
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:patch to implement ethtool get_phys_id function.
From: David Miller @ 2009-10-12 11:24 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20091009131306.GA32311@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Fri, 9 Oct 2009 18:43:16 +0530
> please accept patch, implements port beacon functionality for be2net driver.
>
> Signed-off-by: sarveshwarb <sarveshwarb@serverengines.com>
Applied, but please use your real name as it appears in your
From: email field in signoffs. Like this:
Signed-off-by: Sarveshwar Bandi <sarveshwarb@serverengines.com>
I fixed that up when applying this.
Thanks.
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Tilman Schmidt @ 2009-10-12 11:25 UTC (permalink / raw)
To: David Miller
Cc: tilman, johannes, hidave.darkstar, linux-kernel, tglx,
linux-wireless, linux-ppp, netdev, paulus
In-Reply-To: <20091012.033246.56701176.davem@davemloft.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 12 Oct 2009 03:32:46 -0700 (PDT), David Miller wrote:
> The PPP receive paths in ppp_generic.c do a local_bh_disable()/
> local_bh_enable() around packet receiving (via ppp_recv_lock()/
> ppp_recv_unlock() in ppp_do_recv).
>
> So at least that part is perfectly fine.
>
> ppp_input(), as called from ppp_sync_process(), also disables BH's
> around ppp_do_recv() calls (via read_lock_bh()/read_unlock_bh()).
>
> So that's fine too.
>
> Do you have a bug report or are you just scanning around looking
> for trouble? :-)
I have encountered the message in the subject during a test of
the Gigaset CAPI driver, and would like to determine whether
it's a bug in the driver, a bug somewhere else, or no bug at
all. The test scenario was PPP over ISDN with pppd+capiplugin.
In an alternative scenario, also PPP over ISDN but with
smpppd+capidrv, the message did not occur.
Johannes' answer pointed me to the netif_rx() function.
The Gigaset driver itself doesn't call that function at all.
In the scenario where I saw the message, it was the SYNC_PPP
line discipline that did. But from your explanation I gather
that the cause cannot lie there.
So now I'm looking for other possible causes of that message.
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFK0xITQ3+did9BuFsRAmXGAKCIiqJffUnuKw9rPjxHwbj9AnXOigCdGgS9
MpxRNGs0A4GTydYJaylbjyo=
=LFxi
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] pasemi_mac: ethtool set settings support
From: David Miller @ 2009-10-12 11:25 UTC (permalink / raw)
To: olof; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20091006161123.GC29195@lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Tue, 6 Oct 2009 11:11:23 -0500
> On Mon, Oct 05, 2009 at 05:31:24PM +0400, Valentine Barshak wrote:
>> Add ethtool set settings to pasemi_mac_ethtool.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>
> Acked-by: Olof Johansson <olof@lixom.net>
Applied to net-next-2.6, thanks.
^ 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