* [PATCH] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 2:43 UTC (permalink / raw)
To: davem; +Cc: netdev
Use phys_addr_t data type for pci resource address
instead of unsigned long. This fixes mapping of
pci resources where resource addresses can be larger
than word size (e.g. PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..194b3e3 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ phys_addr_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* [PATCH -mm] connector: Passing required parameter for function cn_add_callback.
From: Rakib Mullick @ 2009-10-12 2:44 UTC (permalink / raw)
To: netdev; +Cc: Andrew Morton, zbr, LKML
We need to pass struct netlink_skb_parms as parameter for
cn_proc_mcast_ctl, which
is a callback function supposed to take two parameter. Fixes the
following warning and
a kernel-doc notation of the function.
CC drivers/connector/cn_proc.o
drivers/connector/cn_proc.c: In function `cn_proc_init':
drivers/connector/cn_proc.c:263: warning: passing arg 3 of
`cn_add_callback' from incompatible pointer type
----
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
--- linus/drivers/connector/cn_proc.c 2009-10-09 17:38:22.000000000 +0600
+++ rakib/drivers/connector/cn_proc.c 2009-10-12 09:45:33.000000000 +0600
@@ -225,9 +225,10 @@ static void cn_proc_ack(int err, int rcv
/**
* cn_proc_mcast_ctl
- * @data: message sent from userspace via the connector
+ * @msg: message sent from userspace via the connector
+ * @nsp: remains unused but we need it to keep it
*/
-static void cn_proc_mcast_ctl(struct cn_msg *msg)
+static void cn_proc_mcast_ctl(struct cn_msg *msg, struct
netlink_skb_parms *nsp)
{
enum proc_cn_mcast_op *mc_op = NULL;
int err = 0;
^ permalink raw reply
* Re: Occasional crashes with sky2
From: Bernd Schmidt @ 2009-10-12 3:48 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Stephen Hemminger, shemminger
In-Reply-To: <392fb48f0910111606x7bb70e6u1c805ce00b78ce12@mail.gmail.com>
Mike McCormack wrote:
>
> 2009/10/11 Bernd Schmidt <bernds_cb1@t-online.de
> <mailto:bernds_cb1@t-online.de>>
>
> For a few months now, I've been seeing occasional kernel panics that
> would happen every few weeks. I'm not exactly sure when they started,
> but I definitely see them in 2.6.29 and 2.6.30, and never saw them in
> 2.6.25 and earlier. They happen with 32 bit and 64 bit kernels.
>
>
> Does this happen with 2.6.31 or 2.6.32-rcX?
No idea. So far I've avoided 2.6.31. I'd have to run the kernel for a
few weeks and even if there were no crashes it wouldn't really prove
that the problem is fixed.
Bernd
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Greg KH @ 2009-10-12 3:00 UTC (permalink / raw)
To: Rob Townley
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <7e84ed60910111410g52ffd52bjec62576570d4b460@mail.gmail.com>
On Sun, Oct 11, 2009 at 04:10:03PM -0500, Rob Townley wrote:
> So when an add-in PCI NIC has a lower MAC than the motherboard NICs,
> the add-in cards will come before the motherboard NICs. i don't like it.
Huh? Have you used the MAC persistant rules? If you add a new card,
what does it pick for it?
> But please whatever is done, make sure ping and tracert still works when
> telling it to use a ethX source interface:
>
> eth0 = 4.3.2.8, the default gateway is thru eth1.
> ping -I eth0 208.67.222.222 FAILS
> ping -I 4.3.2.8 208.67.222.222 WORKS
> tracert -i eth0 -I 208.67.222.222 FAILS
> tracert -s 4.3.2.8 -I 208.67.222.222 WORKS
> tracert -i eth0 208.67.222.222 FAILS
> tracert -s 4.3.2.8 208.67.222.222 WORKS
Again, is what we currently have broken? I am confused as to what this
is referring to.
greg k-h
^ permalink raw reply
* Re: [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v4)
From: Eric Dumazet @ 2009-10-12 4:38 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, davem, socketcan
In-Reply-To: <20091010123522.GA24193@localhost.localdomain>
Neil Horman a écrit :
> Version 4
>
> Change Notes:
>
> 1) Remove the superfolous put_cmsg that I missed in the last version
>
> =======================================================================
>
> Create a new socket level option to report number of queue overflows
>
> Recently I augmented the AF_PACKET protocol to report the number of frames lost
> on the socket receive queue between any two enqueued frames. This value was
> exported via a SOL_PACKET level cmsg. AFter I completed that work it was
> requested that this feature be generalized so that any datagram oriented socket
> could make use of this option. As such I've created this patch, It creates a
> new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a
> SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue
> overflowed between any two given frames. It also augments the AF_PACKET
> protocol to take advantage of this new feature (as it previously did not touch
> sk->sk_drops, which this patch uses to record the overflow count). Tested
> successfully by me.
>
> Notes:
>
> 1) Unlike my previous patch, this patch simply records the sk_drops value, which
> is not a number of drops between packets, but rather a total number of drops.
> Deltas must be computed in user space.
>
> 2) While this patch currently works with datagram oriented protocols, it will
> also be accepted by non-datagram oriented protocols. I'm not sure if thats
> agreeable to everyone, but my argument in favor of doing so is that, for those
> protocols which aren't applicable to this option, sk_drops will always be zero,
> and reporting no drops on a receive queue that isn't used for those
> non-participating protocols seems reasonable to me. This also saves us having
> to code in a per-protocol opt in mechanism.
>
> 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>
^ permalink raw reply
* Re: [PATCH -mm] connector: Passing required parameter for function cn_add_callback.
From: David Miller @ 2009-10-12 5:35 UTC (permalink / raw)
To: rakib.mullick; +Cc: netdev, akpm, zbr, linux-kernel
In-Reply-To: <b9df5fa10910111944s274207aica39c0e646c10f7a@mail.gmail.com>
From: Rakib Mullick <rakib.mullick@gmail.com>
Date: Mon, 12 Oct 2009 08:44:33 +0600
> */
> -static void cn_proc_mcast_ctl(struct cn_msg *msg)
> +static void cn_proc_mcast_ctl(struct cn_msg *msg, struct
> netlink_skb_parms *nsp)
Your patches are unusable because your email client corrupts the
patch, here you can see it is splitting up long lines.
Please fix this up and resubmit.
^ permalink raw reply
* Re: [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v4)
From: Oliver Hartkopp @ 2009-10-12 5:48 UTC (permalink / raw)
To: Eric Dumazet, Neil Horman; +Cc: netdev, davem
In-Reply-To: <4AD2B2BF.8040706@gmail.com>
Eric Dumazet wrote:
> Neil Horman a écrit :
>>
>> (..)
>>
>> =======================================================================
>>
>> Create a new socket level option to report number of queue overflows
>>
>> (..)
>>
>> 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>
Thanks for this nice solution to both of you!
I'm very happy to be able to use this generalized socket option with can-raw
sockets now and that it has been possible to find an efficient and clear patch
for that.
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH] pkt_sched: pedit use proper struct
From: David Miller @ 2009-10-12 6:04 UTC (permalink / raw)
To: hadi; +Cc: netdev
In-Reply-To: <1255270898.5406.6.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Sun, 11 Oct 2009 10:21:38 -0400
> This probably deserves to go into -stable.
Applied, thanks Jamal, I'll queue this up for -stable.
^ permalink raw reply
* Re: [PATCH] netxen: fix pci bar mapping
From: David Miller @ 2009-10-12 6:06 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255315402-1578-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 19:43:22 -0700
> Use phys_addr_t data type for pci resource address
> instead of unsigned long. This fixes mapping of
> pci resources where resource addresses can be larger
> than word size (e.g. PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
The correct type to use is 'resource_size_t' not 'phys_addr_t'.
Look at the "struct resource" member types in linux/ioport.h, that's
what these pci_resource_start() et al. routines return.
Please fix this up and resubmit.
^ permalink raw reply
* Re: [PATCH] net: Fix struct sock bitfield annotation
From: David Miller @ 2009-10-12 6:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: vegard.nossum, netdev, mingo
In-Reply-To: <4ACEF951.7030104@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Oct 2009 10:50:25 +0200
> [PATCH] net: Fix struct sock bitfield annotation
>
> Since commit a98b65a3 (net: annotate struct sock bitfield), we lost
> 8 bytes in struct sock on 64bit arches because of
> kmemcheck_bitfield_end(flags) misplacement.
>
> Fix this by putting together sk_shutdown, sk_no_check, sk_userlocks,
> sk_protocol and sk_type in the 'flags' 32bits bitfield
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-12 6:07 UTC (permalink / raw)
To: eric.dumazet
Cc: tomasw, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky,
tomas.winkler, joe
In-Reply-To: <4AD18C06.8040002@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 11 Oct 2009 09:40:54 +0200
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e1da925..18244ad 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3654,6 +3654,7 @@ NETWORKING [GENERAL]
> M: "David S. Miller" <davem@davemloft.net>
> L: netdev@vger.kernel.org
> W: http://www.linuxfoundation.org/en/Net
> +W: http://patchwork.ozlabs.org/project/netdev/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> S: Maintained
> F: net/
I've applied this, thanks Eric.
^ permalink raw reply
* Re: [net-next PATCH 1/8] qlge: Remove explicit setting of PCI Dev CTL reg.
From: David Miller @ 2009-10-12 6:10 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, root
In-Reply-To: <1255203310-18114-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:03 -0700
> From: root <root@localhost.localdomain>
Ron I'm fixing this up by hand as I go through these qlge patches, but
please fix your config to emit a correct From: line in your patches.
Thanks.
^ permalink raw reply
* Re: [PATCH] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.230656.245420067.davem@davemloft.net>
Ok, I am resending the patch.
Thanks,
Dhananjay
David Miller wrote:
> From: Dhananjay Phadke <dhananjay@netxen.com>
> Date: Sun, 11 Oct 2009 19:43:22 -0700
>
>> Use phys_addr_t data type for pci resource address
>> instead of unsigned long. This fixes mapping of
>> pci resources where resource addresses can be larger
>> than word size (e.g. PAE).
>>
>> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
>
> The correct type to use is 'resource_size_t' not 'phys_addr_t'.
>
> Look at the "struct resource" member types in linux/ioport.h, that's
> what these pci_resource_start() et al. routines return.
>
> Please fix this up and resubmit.
^ permalink raw reply
* [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:13 UTC (permalink / raw)
To: davem; +Cc: netdev
Use phys_addr_t data type for pci resource address
instead of unsigned long. This fixes mapping of
pci resources where resource addresses can be larger
than word size (e.g. PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..7fc15e9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ resource_size_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* Re: PATCH: Network Device Naming mechanism and policy
From: Bryan Kadzban @ 2009-10-12 6:21 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <20091010211352.GC1927@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Greg KH wrote:
> On Sat, Oct 10, 2009 at 10:34:16AM -0700, Bryan Kadzban wrote:
>> Greg KH wrote:
>>> On Sat, Oct 10, 2009 at 07:47:32AM -0500, Matt Domsch wrote:
>>>> On Fri, Oct 09, 2009 at 10:23:08PM -0700, Greg KH wrote:
>>>>> On Fri, Oct 09, 2009 at 11:40:57PM -0500, Matt Domsch wrote:
>>>>>> The fundamental roadblock to this is that enumeration !=
>>>>>> naming, except that it is for network devices, and we keep
>>>>>> changing the enumeration order.
>>>>> No, the hardware changes the enumeration order, it places
>>>>> _no_ guarantees on what order stuff will be found in. So
>>>>> this is not the kernel changing, just to be clear.
>>>> Over time the kernel has changed its enumeration mechanisms,
>>>> and introduced parallelism into the process (which is a good
>>>> thing), which, from a user perspective, makes names
>>>> nondeterministic. Yes, fixing this up by hard-coding MAC
>>>> addresses after install has been the traditional mechanism to
>>>> address this. I think there's a better way.
>>> Ok, but that way can be done in userspace, without the need for
>>> this char device, right?
>> For the record -- when I tried to send a patch that did exactly
>> this (provided an option to use by-path persistence for network
>> drivers), it was rejected because "that doesn't work for USB".
>>
>> True, it doesn't. But by-mac (what we have today) doesn't work for
>> replacing motherboards in a random home system (that can't override
>> the MAC address in the BIOS), either.
>
> If you replace a motherboard, you honestly expect no configuration to
> be needed to be changed? If so, then don't use the MAC naming scheme
> for your systems.
What else is there? biosdevname doesn't work with this BIOS. It looks
like at least path_id has been updated to work with NICs now, so that
might work, with a bit of custom rule hacking.
Or at least, it won't work any more poorly than for disks, which seem to
work pretty well... :-)
>>> But this code is not a requirement to "solve" the fact that
>>> network devices can show up in different order, that problem can
>>> be solved as long as the user picks a single way to name the
>>> devices, using tools that are already present today in distros.
>> This code is not a requirement, no. But -- as you say -- it does
>> provide a halfway-decent way to assign multiple names to a NIC.
>> And that provides admins the choice to use a couple different
>> persistence schemes, depending on how they expect their hardware to
>> work.
>
> But the names need to then be resolved back to a "real" kernel name
> in order to do anything with that network connection, as the char
> devices are not real ones. So that adds an additional layer of
> complexity on all of the system configuration tools.
Yes, that is true -- and no, this change isn't perfect. But it lets me
have multiple "names" per interface, and have "names" that are longer
than IFNAMSIZ, though, which is why I like it.
(Now, if open() would return effectively a netlink socket bound to that
ifindex already, such that the program didn't need to fill in the
various ifindex fields for e.g. rtnetlink... but it's probably really
hard to do that, so this isn't a serious suggestion.)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: David Miller @ 2009-10-12 6:22 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255328031-17189-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 23:13:51 -0700
> Use phys_addr_t data type for pci resource address
> instead of unsigned long. This fixes mapping of
> pci resources where resource addresses can be larger
> than word size (e.g. PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Lazy, you didn't update the commit log message to match the
change you made to the patch.
I think I'll just ignore your patches for a while until
you start to be a little bit less careless.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH 0/8] qlge: Cleanup and additions for qlge.
From: David Miller @ 2009-10-12 6:26 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1255203310-18114-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:02 -0700
>
> Cleanup and a couple of small performance tweeks for qlge.
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.232203.41690616.davem@davemloft.net>
Huh, okay I was impatient. I will make one more attempt to pass the test.
Thanks.
David Miller wrote:
> I think I'll just ignore your patches for a while until
> you start to be a little bit less careless.
>
> Thanks.
>
^ permalink raw reply
* [PATCHv3] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:39 UTC (permalink / raw)
To: davem; +Cc: netdev
Use resource_size_t for PCI resource remapping instead
of unsigned long. Physical addresses can exceed range of
long data type (e.g with PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..7fc15e9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ resource_size_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* Re: PATCH: Network Device Naming mechanism and policy
From: Kurt Van Dijck @ 2009-10-12 7:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matt Domsch, netdev, linux-hotplug, Narendra_K, jordan_hargrave
In-Reply-To: <20091010113219.3136fb8b@s6510>
On Sat, Oct 10, 2009 at 11:32:19AM -0700, Stephen Hemminger wrote:
> > On Fri, Oct 09, 2009 at 07:44:01PM -0700, Stephen Hemminger wrote:
[...]
>
> Why isn't the available through sysfs enough, if not why not
> add the necessary attributes there.
True. If sysfs is not sufficient, what exact naming scheme could be
applied that the chardev based naming could use?
>
[...]
Kurt
^ 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: Eric Dumazet @ 2009-10-12 7:32 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: davem, netdev
In-Reply-To: <4AD1E169.6090705@linux-ipv6.org>
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.
^ permalink raw reply
* 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
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