Re: [PATCH] pci: remove redundant function calls in pci_reassigndev_resource_alignment()
On Thu, Dec 27, 2012 at 11:31 PM, Lin Feng wrote:
> pci_reassigndev_resource_alignment() potentially calls
> pci_specified_resource_alignment() twice, which is redundant.
>
> pci_is_reassigndev() is only called in pci_reassigndev_resource_alignment(),
> and from sematic/functionality aspects pci_specified_resource_alignment() is
> sufficient to substitute, so also make some cleanup.
>
> Signed-off-by: Lin Feng
> Cc: Yinghai Lu
> ---
> drivers/pci/pci.c | 16 ++--
> 1 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 5cb5820..789f401 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3766,18 +3766,6 @@ resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev)
> return align;
> }
>
> -/**
> - * pci_is_reassigndev - check if specified PCI is target device to reassign
> - * @dev: the PCI device to check
> - *
> - * RETURNS: non-zero for PCI device is a target device to reassign,
> - * or zero is not.
> - */
> -int pci_is_reassigndev(struct pci_dev *dev)
> -{
> - return (pci_specified_resource_alignment(dev) != 0);
> -}
> -
> /*
> * This function disables memory decoding and releases memory resources
> * of the device specified by kernel's boot parameter
> 'pci=resource_alignment='.
> @@ -3792,7 +3780,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev
> *dev)
> resource_size_t align, size;
> u16 command;
>
> - if (!pci_is_reassigndev(dev))
> + align = pci_specified_resource_alignment(dev);
> + if (!align)
> return;
>
> if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
> @@ -3808,7 +3797,6 @@ void pci_reassigndev_resource_alignment(struct pci_dev
> *dev)
> command &= ~PCI_COMMAND_MEMORY;
> pci_write_config_word(dev, PCI_COMMAND, command);
>
> - align = pci_specified_resource_alignment(dev);
> for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
> r = >resource[i];
> if (!(r->flags & IORESOURCE_MEM))
> --
> 1.7.1
>
looks the same as the one that i posted 6 months ago.
http://copilotco.com/mail-archives/linux-kernel.2012/msg18498.html
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to look for source code in kernel
anish singh writes: > On Fri, Dec 28, 2012 at 10:42 AM, amit mehta wrote: > On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: > > can anybody tell me how to look into source code, as most are hidden in > > kernel. > > You can find the Linux source code at http://kernel.org/ . >>> for browsing the code unfortunately there is no good tool as in windows we >>> have source insight.We can use wine in linux but that sucks. >> Funny you say that! >> Never heard of cscope, ctags ? > It is not as convenient as source insight or is it? I took a look and source insite seems to have a whole lot of inconvinient mousing around. A setup where you get to stay on your home keys seems much more convinient to me. But then I am probably peculiar keeping an index of the source code in my head. When I need to look for something and I don't know where to find it I do. git-ls-files | xargs fgrep 'struct f2fs_inode' That returns instantly and tells me where to look. If you can do an instant brute force search what is the point of an index? My experience with gui editors is that they always hide something I need to see, or my code is just strange enough (say having asm file, or supporting multiple architectures) that the tools get horribly confused. So I suspect source insight would be terribly inconvinient to the point of uselessness to me. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pci: remove redundant function calls in pci_reassigndev_resource_alignment()
pci_reassigndev_resource_alignment() potentially calls
pci_specified_resource_alignment() twice, which is redundant.
pci_is_reassigndev() is only called in pci_reassigndev_resource_alignment(),
and from sematic/functionality aspects pci_specified_resource_alignment() is
sufficient to substitute, so also make some cleanup.
Signed-off-by: Lin Feng
Cc: Yinghai Lu
---
drivers/pci/pci.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 5cb5820..789f401 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3766,18 +3766,6 @@ resource_size_t pci_specified_resource_alignment(struct
pci_dev *dev)
return align;
}
-/**
- * pci_is_reassigndev - check if specified PCI is target device to reassign
- * @dev: the PCI device to check
- *
- * RETURNS: non-zero for PCI device is a target device to reassign,
- * or zero is not.
- */
-int pci_is_reassigndev(struct pci_dev *dev)
-{
- return (pci_specified_resource_alignment(dev) != 0);
-}
-
/*
* This function disables memory decoding and releases memory resources
* of the device specified by kernel's boot parameter
'pci=resource_alignment='.
@@ -3792,7 +3780,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
resource_size_t align, size;
u16 command;
- if (!pci_is_reassigndev(dev))
+ align = pci_specified_resource_alignment(dev);
+ if (!align)
return;
if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
@@ -3808,7 +3797,6 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
- align = pci_specified_resource_alignment(dev);
for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
r = >resource[i];
if (!(r->flags & IORESOURCE_MEM))
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf symbol: Include elf.h header regardless LIBELF_SUPPORT
From: Namhyung Kim The elf.h header file is used for NO_LIBELF build too so it should be included anyway. Also remove duplicated include of the header file in symbol-*.c. This patch fixes following build error on NO_LIBELF build: CC tests/hists_link.o tests/hists_link.c: In function ‘setup_fake_machine’: tests/hists_link.c:132:8: error: ‘STB_GLOBAL’ undeclared (first use in this function) tests/hists_link.c:132:8: note: each undeclared identifier is reported only once for each function it appears in Cc: Jiri Olsa Cc: David Ahern Signed-off-by: Namhyung Kim --- tools/perf/util/symbol-elf.c | 3 --- tools/perf/util/symbol-minimal.c | 1 - tools/perf/util/symbol.h | 2 +- 3 files changed, 1 insertion(+), 5 deletions(-) diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index f63557b59c06..54efcb5659ac 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -1,6 +1,3 @@ -#include -#include -#include #include #include #include diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c index 259f8f2ea9c9..a7390cde63bc 100644 --- a/tools/perf/util/symbol-minimal.c +++ b/tools/perf/util/symbol-minimal.c @@ -1,6 +1,5 @@ #include "symbol.h" -#include #include #include #include diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h index ec7b2405c377..d97377ac2f16 100644 --- a/tools/perf/util/symbol.h +++ b/tools/perf/util/symbol.h @@ -16,8 +16,8 @@ #ifdef LIBELF_SUPPORT #include #include -#include #endif +#include #include "dso.h" -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ppoll() stuck on POLLIN while TCP peer is sending
Eric Wong wrote: > I'm finding ppoll() unexpectedly stuck when waiting for POLLIN on a > local TCP socket. The isolated code below can reproduces the issue > after many minutes (<1 hour). It might be easier to reproduce on > a busy system while disk I/O is happening. Ugh, I can't seem to reproduce this anymore... Will try something else tomorrow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c: exynos5: add High Speed I2C controller driver
Hello Balbi,
On 28 December 2012 04:27, Felipe Balbi wrote:
> Hi,
>
> On Tue, Dec 25, 2012 at 04:55:54PM +0530, Naveen Krishna Chatradhi wrote:
>> Adds support for High Speed I2C driver found in Exynos5 and later
>> SoCs from Samsung. This driver currently supports Auto mode.
>>
>> Driver only supports Device Tree method.
>>
>> Signed-off-by: Taekgyun Ko
>> Signed-off-by: Naveen Krishna Chatradhi
>> ---
>> Changes since v1:
>> Fixed the comments from Felipe Balbi and Thomas Abraham.
>>
>> drivers/i2c/busses/Kconfig |7 +
>> drivers/i2c/busses/Makefile |1 +
>> drivers/i2c/busses/i2c-exynos5.c | 652
>> ++
>> drivers/i2c/busses/i2c-exynos5.h | 102 ++
>> 4 files changed, 762 insertions(+)
>> create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>> create mode 100644 drivers/i2c/busses/i2c-exynos5.h
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index bdca511..4caea76 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -618,6 +618,13 @@ config I2C_S3C2410
>> Say Y here to include support for I2C controller in the
>> Samsung SoCs.
>>
>> +config I2C_EXYNOS5
>> + tristate "Exynos5 high-speed I2C driver"
>> + depends on ARCH_EXYNOS5
>> + help
>> + Say Y here to include support for High-speed I2C controller in the
>> + Exynos5 based Samsung SoCs.
>> +
>> config I2C_S6000
>> tristate "S6000 I2C support"
>> depends on XTENSA_VARIANT_S6000
>> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
>> index 6181f3f..4b1548c 100644
>> --- a/drivers/i2c/busses/Makefile
>> +++ b/drivers/i2c/busses/Makefile
>> @@ -61,6 +61,7 @@ obj-$(CONFIG_I2C_PUV3) += i2c-puv3.o
>> obj-$(CONFIG_I2C_PXA)+= i2c-pxa.o
>> obj-$(CONFIG_I2C_PXA_PCI)+= i2c-pxa-pci.o
>> obj-$(CONFIG_I2C_S3C2410)+= i2c-s3c2410.o
>> +obj-$(CONFIG_I2C_EXYNOS5)+= i2c-exynos5.o
>> obj-$(CONFIG_I2C_S6000) += i2c-s6000.o
>> obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
>> obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c
>> b/drivers/i2c/busses/i2c-exynos5.c
>> new file mode 100644
>> index 000..7614f60
>> --- /dev/null
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -0,0 +1,652 @@
>> +/* linux/drivers/i2c/busses/i2c-exynos5.c
>
> no need for the full path. Generally this would look like:
>
> * i2c-exynos5.c - Samsung Exynos 5 I2C Controller Driver
>
> no strong feelings however.
>
>> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>> + *
>> + * High speed I2C controller driver
>> + * for Exynos5 and later SoCs from Samsung.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "i2c-exynos5.h"
>
> it doesn't look like this header is even needed. All those macros could
> be defined here in the C-source file which is the only user.
>
>> +#define EXYNOS5_I2C_TIMEOUT (msecs_to_jiffies(1000))
>> +
>> +/* timeout for pm runtime autosuspend */
>> +#define EXYNOS5_I2C_PM_TIMEOUT 1000/* ms */
>> +
>> +struct exynos5_i2c {
>> + struct i2c_adapter adap;
>> + unsigned intsuspended:1;
>> +
>> + struct i2c_msg *msg;
>> + unsigned intmsg_idx;
>> + struct completion msg_complete;
>> + unsigned intmsg_ptr;
>> +
>> + unsigned intirq;
>> +
>> + void __iomem*regs;
>> + struct clk *clk;
>> + struct device *dev;
>> + int gpios[2];
>> +
>> + int bus_num;
>> + int speed_mode;
>> +};
>> +
>> +static const struct of_device_id exynos5_i2c_match[] = {
>> + { .compatible = "samsung,exynos5-hsi2c" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
>> +
>> +/* TODO: Should go to debugfs */
>> +static inline void dump_i2c_register(struct exynos5_i2c *i2c)
>> +{
>> + dev_vdbg(i2c->dev, "Register dump(%d) :\n %x\n %x\n %x\n %x\n"
>> + " %x\n %x\n %x\n %x\n %x\n"
>> + " %x\n %x\n %x\n %x\n %x\n"
>> + " %x\n %x\n %x\n %x\n %x\n"
>> + " %x\n %x\n %x\n %x\n %x\n",
>> + i2c->suspended,
>> + readl(i2c->regs + HSI2C_CTL),
>> + readl(i2c->regs + HSI2C_FIFO_CTL),
>> + readl(i2c->regs + HSI2C_TRAILIG_CTL),
>> + readl(i2c->regs + HSI2C_CLK_CTL),
>> + readl(i2c->regs + HSI2C_CLK_SLOT),
>> +
Re: how to look for source code in kernel
On Fri, 28 Dec 2012, anish singh wrote: have source insight.We can use wine in linux but that sucks. Funny you say that! Never heard of cscope, ctags ? It is not as convenient as source insight or is it? There is also LXR. If it's not good enough for you, then don't look at it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: echo 1 > /proc/sys/vm/compact_memory -> sh: write error: Bad address
>-Original Message-
>From: David Rientjes [mailto:rient...@google.com]
>Sent: Friday, December 28, 2012 6:39 AM
>To: Liu Hui-R64343
>Cc: Mel Gorman; linux-kernel@vger.kernel.org
>Subject: Re: echo 1 > /proc/sys/vm/compact_memory -> sh: write error: Bad
>address
>
>On Thu, 27 Dec 2012, Liu Hui-R64343 wrote:
>
>> diff --git a/mm/compaction.c b/mm/compaction.c index c4bc5ac..d3cb27f
>> 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -732,8 +732,10 @@ int sysctl_compact_memory; int
>> sysctl_compaction_handler(struct ctl_table *table, int write,
>> void __user *buffer, size_t *length, loff_t
>> *ppos) {
>> - if (write)
>> - return compact_nodes();
>> + if (write) {
>> + compact_nodes();
>> + return *length;
>> + }
>>
>> return 0;
>> }
>
>No need to return the length at all, simply change compact_nodes() to return
>void, remove the return value, and do
>
> if (write)
> compact_nodes();
> return 0;
>
>and it should be fixed.
Yes, this works. Thanks,
> Could you write a changelog that shows the before
>and after behavior (not necessarily the implementation), sign-off the patch
>as described in Documentation/SubmittingPatches, running
>scripts/get_maintainer.pl on your new patch file, and sending it to all
>addresses that are listed?
OK, I will send out the patch as you suggested.
Happy holiday.
Jason Liu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to look for source code in kernel
于 2012年12月28日 13:12, amit mehta 写道: On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: > can anybody tell me how to look into source code, as most are hidden in > kernel. You can find the Linux source code at http://kernel.org/ . >> for browsing the code unfortunately there is no good tool as in windows we >> have source insight.We can use wine in linux but that sucks. > Funny you say that! > Never heard of cscope, ctags ? at least for me: vi (or vim) with another command line tools (grep, wc...) are enough. for reading or editing source code: grasp one editor is enough. I originally work under Windows OS using VC IDE and source insight for many years (at least 6 years). but I never feel they are better than vi, and neither less than vi. each editor has its own efficiency using ways, what we need do is to grasp it. when you grasp the editor (no matter what it is), it will be enough for you. > > -Amit > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Flying Transformer <>
Re: how to look for source code in kernel
于 2012年12月28日 13:12, amit mehta 写道: On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: > can anybody tell me how to look into source code, as most are hidden in > kernel. You can find the Linux source code at http://kernel.org/ . >> for browsing the code unfortunately there is no good tool as in windows we >> have source insight.We can use wine in linux but that sucks. > Funny you say that! > Never heard of cscope, ctags ? at least for me: vi (or vim) with another command line tools (grep, wc...) are enough. for reading or editing source code: grasp one editor is enough. I originally work under Windows OS, using VC IDE and source insight for many years (at least 6 years). but I never feel they are better than vi, and neither less than vi. each editor has its own efficiency using ways, what we need do is to grasp it. when you grasp the editor (no matter what it is), it will be enough for you. > -Amit > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Flying Transformer <>
Re: Bad magic number and
Hi, On Fri, Dec 28, 2012 at 10:57 AM, Manish Katiyar wrote: > > > On Thu, Dec 27, 2012 at 8:29 PM, sham pavman > wrote: >> >> I've tried that as well.. and the result is the same. >> I've little idea on how to start debugging. >> If you can provide some info it would be great. Check your mkfs and mount commands. You have specified the whole disk instead of partition. It should be... mkfs -t ext4 /dev/sdb1 mount -t ext4 /dev/sdb1 /mnt/test Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] vhost_net: correct error hanlding in vhost_net_set_backend()
On 12/27/2012 09:14 PM, Michael S. Tsirkin wrote:
> On Thu, Dec 27, 2012 at 02:39:19PM +0800, Jason Wang wrote:
>> Fix the leaking of oldubufs and fd refcnt when fail to initialized used ring.
>>
>> Signed-off-by: Jason Wang
>> ---
>> drivers/vhost/net.c | 14 +++---
>> 1 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index ebd08b2..629d6b5 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -834,8 +834,10 @@ static long vhost_net_set_backend(struct vhost_net *n,
>> unsigned index, int fd)
>> vhost_net_enable_vq(n, vq);
>>
>> r = vhost_init_used(vq);
>> -if (r)
>> -goto err_vq;
>> +if (r) {
>> +sock = NULL;
>> +goto err_used;
>> +}
>>
>> n->tx_packets = 0;
>> n->tx_zcopy_err = 0;
>> @@ -859,8 +861,14 @@ static long vhost_net_set_backend(struct vhost_net *n,
>> unsigned index, int fd)
>> mutex_unlock(>dev.mutex);
>> return 0;
>>
>> +err_used:
>> +if (oldubufs)
>> +vhost_ubuf_put_and_wait(oldubufs);
>> +if (oldsock)
>> +fput(oldsock->file);
>> err_ubufs:
>> -fput(sock->file);
>> +if (sock)
>> +fput(sock->file);
>> err_vq:
>> mutex_unlock(>mutex);
>> err:
> I think it's a real bug, but I don't see how the fix
> makes sense.
> We are returning an error, so we ideally
> revert to the state before the faulty
> operation. So this should put sock and ubufs,
> not oldsock/oldubufs.
Agree.
>
> The best way is probably to change
> vhost_init_used so that it gets private data
> pointer as a parameter.
>
> We can then call it before ubuf alloc.
> You can then add err_used right after err_ubufs
> with no extra logic.
>
Make more sense, thanks.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to look for source code in kernel
On Fri, Dec 28, 2012 at 10:42 AM, amit mehta wrote: On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: > can anybody tell me how to look into source code, as most are hidden in > kernel. You can find the Linux source code at http://kernel.org/ . >> for browsing the code unfortunately there is no good tool as in windows we >> have source insight.We can use wine in linux but that sucks. > Funny you say that! > Never heard of cscope, ctags ? It is not as convenient as source insight or is it? > > -Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/14] xen: netback: Remove redundant check on unsigned variable
On 11/16/2012 02:46 PM, Ian Campbell wrote: > On Fri, 2012-11-16 at 06:50 +, Tushar Behera wrote: >> No need to check whether unsigned variable is less than 0. >> >> CC: Ian Campbell >> CC: xen-de...@lists.xensource.com >> CC: net...@vger.kernel.org >> Signed-off-by: Tushar Behera > > Acked-by: Ian Campbell > > Thanks. > This patch was not picked up for 3.8-rc1. Any idea, who should pick this up? >> --- >> drivers/net/xen-netback/netback.c |4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/xen-netback/netback.c >> b/drivers/net/xen-netback/netback.c >> index aab8677..515e10c 100644 >> --- a/drivers/net/xen-netback/netback.c >> +++ b/drivers/net/xen-netback/netback.c >> @@ -190,14 +190,14 @@ static int get_page_ext(struct page *pg, >> >> group = ext.e.group - 1; >> >> -if (group < 0 || group >= xen_netbk_group_nr) >> +if (group >= xen_netbk_group_nr) >> return 0; >> >> netbk = _netbk[group]; >> >> idx = ext.e.idx; >> >> -if ((idx < 0) || (idx >= MAX_PENDING_REQS)) >> +if (idx >= MAX_PENDING_REQS) >> return 0; >> >> if (netbk->mmap_pages[idx] != pg) > > -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to look for source code in kernel
>>> On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: >>> > can anybody tell me how to look into source code, as most are hidden in >>> > kernel. >>> >>> You can find the Linux source code at http://kernel.org/ . > for browsing the code unfortunately there is no good tool as in windows we > have source insight.We can use wine in linux but that sucks. Funny you say that! Never heard of cscope, ctags ? -Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/14] atm: Removed redundant check on unsigned variable
Ping.
On 11/16/2012 12:20 PM, Tushar Behera wrote:
> No need to check whether unsigned variable is less than 0.
>
> CC: Chas Williams
> CC: linux-atm-gene...@lists.sourceforge.net
> CC: net...@vger.kernel.org
> Signed-off-by: Tushar Behera
> ---
> drivers/atm/fore200e.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
> index 361f5ae..fdd3fe7 100644
> --- a/drivers/atm/fore200e.c
> +++ b/drivers/atm/fore200e.c
> @@ -972,7 +972,7 @@ int bsq_audit(int where, struct host_bsq* bsq, int
> scheme, int magn)
> where, scheme, magn, buffer->index, buffer->scheme);
> }
>
> - if ((buffer->index < 0) || (buffer->index >= fore200e_rx_buf_nbr[
> scheme ][ magn ])) {
> + if (buffer->index >= fore200e_rx_buf_nbr[ scheme ][ magn ]) {
> printk(FORE200E "bsq_audit(%d): queue %d.%d, out of range buffer
> index = %ld !\n",
> where, scheme, magn, buffer->index);
> }
>
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] vhost_net: correct error hanlding in vhost_net_set_backend()
On 12/27/2012 09:03 PM, Michael S. Tsirkin wrote:
> On Thu, Dec 27, 2012 at 02:39:20PM +0800, Jason Wang wrote:
>> Currently, polling error were ignored in vhost. This may lead some issues
>> (e.g
>> kenrel crash when passing a tap fd to vhost before calling TUNSETIFF). Fix
>> this
>> by:
>>
>> - extend the idea of vhost_net_poll_state to all vhost_polls
>> - change the state only when polling is succeed
>> - make vhost_poll_start() report errors to the caller, which could be used
>> caller or userspace.
> Maybe it could but this patch just ignores these errors.
> And it's not clear how would userspace handle these errors.
Not all were ignored, one example is vhost_net_enable_vq(), this could
be used to let userspace know the fd were not setup correctly.
> Also, since we have a reference on the fd, it would seem
> that once poll succeeds it can't fail in the future.
Right.
>
> So two other options would make more sense to me:
> - if vhost is bound to tun without SETIFF, fail this immediately
> - if vhost is bound to tun without SETIFF, defer polling
> until SETIFF
>
> Option 1 would seem much easier to implement, I think it's
> preferable.
Option 1 seems better, since userspace may also disable a queue in the
meantime. Will add a vq_err() and break out of the loop when fails to
start the polling.
>> Signed-off-by: Jason Wang
>> ---
>> drivers/vhost/net.c | 75
>> +
>> drivers/vhost/vhost.c | 16 +-
>> drivers/vhost/vhost.h | 11 ++-
>> 3 files changed, 50 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 629d6b5..56e7f5a 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -64,20 +64,10 @@ enum {
>> VHOST_NET_VQ_MAX = 2,
>> };
>>
>> -enum vhost_net_poll_state {
>> -VHOST_NET_POLL_DISABLED = 0,
>> -VHOST_NET_POLL_STARTED = 1,
>> -VHOST_NET_POLL_STOPPED = 2,
>> -};
>> -
>> struct vhost_net {
>> struct vhost_dev dev;
>> struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
>> struct vhost_poll poll[VHOST_NET_VQ_MAX];
>> -/* Tells us whether we are polling a socket for TX.
>> - * We only do this when socket buffer fills up.
>> - * Protected by tx vq lock. */
>> -enum vhost_net_poll_state tx_poll_state;
>> /* Number of TX recently submitted.
>> * Protected by tx vq lock. */
>> unsigned tx_packets;
>> @@ -155,24 +145,6 @@ static void copy_iovec_hdr(const struct iovec *from,
>> struct iovec *to,
>> }
>> }
>>
>> -/* Caller must have TX VQ lock */
>> -static void tx_poll_stop(struct vhost_net *net)
>> -{
>> -if (likely(net->tx_poll_state != VHOST_NET_POLL_STARTED))
>> -return;
>> -vhost_poll_stop(net->poll + VHOST_NET_VQ_TX);
>> -net->tx_poll_state = VHOST_NET_POLL_STOPPED;
>> -}
>> -
>> -/* Caller must have TX VQ lock */
>> -static void tx_poll_start(struct vhost_net *net, struct socket *sock)
>> -{
>> -if (unlikely(net->tx_poll_state != VHOST_NET_POLL_STOPPED))
>> -return;
>> -vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
>> -net->tx_poll_state = VHOST_NET_POLL_STARTED;
>> -}
>> -
>> /* In case of DMA done not in order in lower device driver for some reason.
>> * upend_idx is used to track end of used idx, done_idx is used to track
>> head
>> * of used idx. Once lower device DMA done contiguously, we will signal KVM
>> @@ -252,7 +224,7 @@ static void handle_tx(struct vhost_net *net)
>> wmem = atomic_read(>sk->sk_wmem_alloc);
>> if (wmem >= sock->sk->sk_sndbuf) {
>> mutex_lock(>mutex);
>> -tx_poll_start(net, sock);
>> +vhost_poll_start(net->poll + VHOST_NET_VQ_TX, sock->file);
>> mutex_unlock(>mutex);
>> return;
>> }
>> @@ -261,7 +233,7 @@ static void handle_tx(struct vhost_net *net)
>> vhost_disable_notify(>dev, vq);
>>
>> if (wmem < sock->sk->sk_sndbuf / 2)
>> -tx_poll_stop(net);
>> +vhost_poll_stop(net->poll + VHOST_NET_VQ_TX);
>> hdr_size = vq->vhost_hlen;
>> zcopy = vq->ubufs;
>>
>> @@ -283,7 +255,8 @@ static void handle_tx(struct vhost_net *net)
>>
>> wmem = atomic_read(>sk->sk_wmem_alloc);
>> if (wmem >= sock->sk->sk_sndbuf * 3 / 4) {
>> -tx_poll_start(net, sock);
>> +vhost_poll_start(net->poll + VHOST_NET_VQ_TX,
>> + sock->file);
>> set_bit(SOCK_ASYNC_NOSPACE, >flags);
>> break;
>> }
>> @@ -294,7 +267,8 @@ static void handle_tx(struct vhost_net *net)
>> (vq->upend_idx - vq->done_idx) :
>> (vq->upend_idx + UIO_MAXIOV - vq->done_idx);
>> if (unlikely(num_pends > VHOST_MAX_PEND)) {
>> -
Re: how to look for source code in kernel
On Fri, Dec 28, 2012 at 1:23 AM, Henrique Rodrigues wrote: > http://lxr.linux.no/ is a really good linux cross referencing website for > code reference. > > On Thu, Dec 27, 2012 at 10:40 AM, Jonathan Neuschäfer > wrote: >> >> On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: >> > can anybody tell me how to look into source code, as most are hidden in >> > kernel. >> >> You can find the Linux source code at http://kernel.org/ . for browsing the code unfortunately there is no good tool as in windows we have source insight.We can use wine in linux but that sucks. >> >> HTH, >> Jonathan Neuschäfer >> >> ___ >> Kernelnewbies mailing list >> kernelnewb...@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > -- > Henrique Rodrigues > http://www.dcc.ufmg.br/~hsr > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] lib: cpu_rmap: avoid flushing all workqueues
On Thu, Dec 27, 2012 at 11:24:34AM -0800, David Decotigny wrote:
> In some cases, free_irq_cpu_rmap() is called while holding a lock
> (eg. rtnl). This can lead to deadlocks, because it invokes
> flush_scheduled_work() which ends up waiting for whole system
> workqueue to flush, but some pending works might try to acquire the
> lock we are already holding.
>
> This commit uses reference-counting to replace
> irq_run_affinity_notifiers(). It also removes
> irq_run_affinity_notifiers() altogether.
>
> Signed-off-by: David Decotigny
A couple of comments below; with those addressed,
Reviewed-by: Josh Triplett
> include/linux/cpu_rmap.h | 13
> include/linux/interrupt.h |5 -
> lib/cpu_rmap.c| 48
> +++--
> 3 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/cpu_rmap.h b/include/linux/cpu_rmap.h
> index ac3bbb5..3be2813 100644
> --- a/include/linux/cpu_rmap.h
> +++ b/include/linux/cpu_rmap.h
> @@ -13,9 +13,11 @@
> #include
> #include
> #include
> +#include
>
> /**
> * struct cpu_rmap - CPU affinity reverse-map
> + * @refcount: kref for object
> * @size: Number of objects to be reverse-mapped
> * @used: Number of objects added
> * @obj: Pointer to array of object pointers
> @@ -23,6 +25,7 @@
> * based on affinity masks
> */
> struct cpu_rmap {
> + struct kref refcount;
> u16 size, used;
> void**obj;
> struct {
> @@ -33,15 +36,7 @@ struct cpu_rmap {
> #define CPU_RMAP_DIST_INF 0x
>
> extern struct cpu_rmap *alloc_cpu_rmap(unsigned int size, gfp_t flags);
> -
> -/**
> - * free_cpu_rmap - free CPU affinity reverse-map
> - * @rmap: Reverse-map allocated with alloc_cpu_rmap(), or %NULL
> - */
> -static inline void free_cpu_rmap(struct cpu_rmap *rmap)
> -{
> - kfree(rmap);
> -}
> +extern void free_cpu_rmap(struct cpu_rmap *rmap);
>
> extern int cpu_rmap_add(struct cpu_rmap *rmap, void *obj);
> extern int cpu_rmap_update(struct cpu_rmap *rmap, u16 index,
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 5e4e617..5fa5afe 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -268,11 +268,6 @@ struct irq_affinity_notify {
> extern int
> irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify
> *notify);
>
> -static inline void irq_run_affinity_notifiers(void)
> -{
> - flush_scheduled_work();
> -}
> -
> #else /* CONFIG_SMP */
>
> static inline int irq_set_affinity(unsigned int irq, const struct cpumask *m)
> diff --git a/lib/cpu_rmap.c b/lib/cpu_rmap.c
> index 145dec5..295cbf8 100644
> --- a/lib/cpu_rmap.c
> +++ b/lib/cpu_rmap.c
> @@ -45,6 +45,7 @@ struct cpu_rmap *alloc_cpu_rmap(unsigned int size, gfp_t
> flags)
> if (!rmap)
> return NULL;
>
> + kref_init(>refcount);
> rmap->obj = (void **)((char *)rmap + obj_offset);
>
> /* Initially assign CPUs to objects on a rota, since we have
> @@ -63,6 +64,26 @@ struct cpu_rmap *alloc_cpu_rmap(unsigned int size, gfp_t
> flags)
> }
> EXPORT_SYMBOL(alloc_cpu_rmap);
>
> +/**
> + * reclaim_cpu_rmap - internal reclaiming helper called from kref_put
> + * @ref: kref to struct cpu_rmap
> + */
> +static void reclaim_cpu_rmap(struct kref *ref)
> +{
> + struct cpu_rmap *rmap = container_of(ref, struct cpu_rmap, refcount);
> + kfree(rmap);
> +}
> +
> +/**
> + * free_cpu_rmap - free CPU affinity reverse-map
> + * @rmap: Reverse-map allocated with alloc_cpu_rmap(), or %NULL
> + */
> +void free_cpu_rmap(struct cpu_rmap *rmap)
> +{
> + kref_put(>refcount, reclaim_cpu_rmap);
> +}
> +EXPORT_SYMBOL(free_cpu_rmap);
> +
> /* Reevaluate nearest object for given CPU, comparing with the given
> * neighbours at the given distance.
> */
> @@ -197,8 +218,7 @@ struct irq_glue {
> * free_irq_cpu_rmap - free a CPU affinity reverse-map used for IRQs
> * @rmap: Reverse-map allocated with alloc_irq_cpu_map(), or %NULL
> *
> - * Must be called in process context, before freeing the IRQs, and
> - * without holding any locks required by global workqueue items.
> + * Must be called in process context, before freeing the IRQs.
> */
> void free_irq_cpu_rmap(struct cpu_rmap *rmap)
> {
> @@ -212,12 +232,18 @@ void free_irq_cpu_rmap(struct cpu_rmap *rmap)
> glue = rmap->obj[index];
> irq_set_affinity_notifier(glue->notify.irq, NULL);
> }
> - irq_run_affinity_notifiers();
>
> - kfree(rmap);
> + kref_put(>refcount, reclaim_cpu_rmap);
This should call free_cpu_rmap, rather than duplicating its body.
> }
> EXPORT_SYMBOL(free_irq_cpu_rmap);
>
> +/**
> + * irq_cpu_rmap_notify - callback for IRQ subsystem when IRQ affinity updated
> + * @notify: struct irq_affinity_notify passed by irq/manage.c
> + * @mask: cpu mask for new SMP affinity
> + *
> + * This is executed in workqueue context.
> + */
> static void
>
Re: [PATCH 2/2] vhost: handle polling failure
On 12/27/2012 06:01 PM, Wanlong Gao wrote: > On 12/27/2012 02:39 PM, Jason Wang wrote: >> > Currently, polling error were ignored in vhost. This may lead some issues >> > (e.g >> > kenrel crash when passing a tap fd to vhost before calling TUNSETIFF). Fix >> > this >> > by: > Can this kernel crash be reproduced by hand? > > Thanks, > Wanlong Gao > >> > Yes, it could be simply reproduced by: open a tap fd but does not cal TUNSETIFF, then pass it to qemu and enable vhost. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bnx2x: use ARRAY_SIZE where possible
From: "Eilon Greenstein" Date: Sun, 23 Dec 2012 10:49:27 +0200 > On Thu, 2012-12-20 at 14:11 -0500, Sasha Levin wrote: >> Signed-off-by: Sasha Levin > > Acked-by Eilon Greenstein Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minimum toolchain requirements?
On 12/27/2012 02:09:33 PM, Shaun Ruffell wrote: Hi Rob, On Fri, Dec 14, 2012 at 04:25:10PM -0600, Rob Landley wrote: > Although the README and Documentation/Changes both say the kernel > builds with gcc 3.2, this is no loner the case. In reality the new > 3.7 kernel no longer builds under unpatched gcc 4.2.1 (the last > GPLv2 release). > > Building for i686 breaks with > "arch/x86/kernel/cpu/perf_event_p6.c:22: error: > p6_hw_cache_event_ids causes a section type conflict" (trivial > workaround: patch kernel so CONFIG_BROKEN_RODATA defaults to y). I came across your email while searching for a solution to the above build error. In addition to setting CONFIG_BROKEN_RODATA=y, Jan Beulich sent a patch [1] to LKML that also fixes this build problem for me. [1] https://lkml.org/lkml/2012/11/23/308 It doesn't appear to have hit Linus' tree yet though, but with luck someone will pick it up before 3.8 final. Cheers, Shaun Having it in 3.7.x would be nice too. Copying stable. Thanks, Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic when running /etc/init.d/iptables restart
Hi all As discussed above,if the host machine create several linux containers, there will be several net namespaces.Resources with "nf conntrack" are registered or unregistered on the first net namespace(init_net),But init_net is not unregistered lastly,so cleanuping other net namespaces will triger painic. If net namespaces are created with the order of 1,2,...n,they should be cleaned with the order of n,...2,1,so in this case init_net will be unregistered lastly. I fixed it up (see below) diff -r 6a1a258923f5 -r 2667e89e6f50 net/core/net_namespace.c --- a/net/core/net_namespace.c Fri Dec 28 11:01:17 2012 +0800 +++ b/net/core/net_namespace.c Fri Dec 28 11:05:12 2012 +0800 @@ -450,7 +450,7 @@ list_del(>list); for_each_net(net) - list_add_tail(>exit_list, _exit_list); + list_add(>exit_list, _exit_list); ops_exit_list(ops, _exit_list); ops_free_list(ops, _exit_list); } 2012/12/25 Gao feng : > On 2012/12/25 15:25, canqun zhang wrote: >> Hi Gao feng >> The stack information is as follows. The kenel will panic because the >> nf_ct_destroy is NULL. >> >> Reproduction: >> (1) starting a lxc container >> (2) iptables -t nat -A POSTROUTING -s 10.48.254.18 -o eth1 -j >> MASQUERADE (run it on host machine) >> (3) /etc/ini.d/iptables save (run it on host machine) >> (4)/etc/init.d/iptables restart (run it on host machine) >> > > Thanks! > It seems that nf_conntrack_l[3,4]proto_unregister doesn't make sure > nf_conns of the proto being destroyed. > > If I'm right, there is another problem even your fix this panic problem. > the l3,14proto will be unregistered before all of it's nf_conns being > destroyed. > So even nf_ct_destroy is not NULL,in destroy_conntrack we are not able to > find the right l4proto,the l4proto->destroy will be incorrect.resources will > not be released correctly. > > So I think the root problem is we do register/unregister, set/unset both on > the > first net (init_net), Maybe it's better to do register set on the first net, > and > do unregister unset on the last net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modpost: Ignore ARC specific non-alloc sections
On Friday 28 December 2012 02:18 AM, Sam Ravnborg wrote: > On Thu, Dec 27, 2012 at 04:17:20PM +0530, Vineet Gupta wrote: >> ARC relocatable object files contain one/more .gnu.linkonce.arcextmap.* >> sections (collated by kernel/vmlinux.lds into .arcextmap in final link). >> This section is used by debuggers to display the extension instructions >> and need-not be loaded by target (hence !SHF_ALLOC) >> >> The final kernel binary only needs .arcextmap entry in modpost's ignore >> list (section_white_list[]). However when building modules, modpost scans >> each object file individually, hence tripping on non-aggregated >> .gnu.linkonce.arcextmap.* entries as well. > > The list exist for this particular purpose. > So acked. > >> >> Thus need for the 2 entires ! >> >> Signed-off-by: Vineet Gupta > Acked-by: Sam Ravnborg > > > Sam > Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic when running /etc/init.d/iptables restart
Hi all As discussed above,if the host machine create several linux containers, there will be several net namespaces.Resources with "nf conntrack" are registered or unregistered on the first net namespace(init_net),But init_net is not unregistered lastly,so cleanuping other net namespaces will triger painic. If net namespaces are created with the order of 1,2,...n,they should be cleaned with the order of n,...2,1,so in this case init_net will be unregistered lastly. I fixed it up (see below) diff -r 6a1a258923f5 -r 2667e89e6f50 net/core/net_namespace.c --- a/net/core/net_namespace.c Fri Dec 28 11:01:17 2012 +0800 +++ b/net/core/net_namespace.c Fri Dec 28 11:05:12 2012 +0800 @@ -450,7 +450,7 @@ list_del(>list); for_each_net(net) - list_add_tail(>exit_list, _exit_list); + list_add(>exit_list, _exit_list); ops_exit_list(ops, _exit_list); ops_free_list(ops, _exit_list); } 2012/12/25 canqun zhang : > Thanks for your suggestion,i will modify this patch and take tests. > > 2012/12/25 Gao feng : >> On 2012/12/25 15:25, canqun zhang wrote: >>> Hi Gao feng >>> The stack information is as follows. The kenel will panic because the >>> nf_ct_destroy is NULL. >>> >>> Reproduction: >>> (1) starting a lxc container >>> (2) iptables -t nat -A POSTROUTING -s 10.48.254.18 -o eth1 -j >>> MASQUERADE (run it on host machine) >>> (3) /etc/ini.d/iptables save (run it on host machine) >>> (4)/etc/init.d/iptables restart (run it on host machine) >>> >> >> Thanks! >> It seems that nf_conntrack_l[3,4]proto_unregister doesn't make sure >> nf_conns of the proto being destroyed. >> >> If I'm right, there is another problem even your fix this panic problem. >> the l3,14proto will be unregistered before all of it's nf_conns being >> destroyed. >> So even nf_ct_destroy is not NULL,in destroy_conntrack we are not able to >> find the right l4proto,the l4proto->destroy will be incorrect.resources will >> not be released correctly. >> >> So I think the root problem is we do register/unregister, set/unset both on >> the >> first net (init_net), Maybe it's better to do register set on the first net, >> and >> do unregister unset on the last net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.8-rc1 (mei driver BROKEN)
On Fri, Dec 28, 2012 at 02:04:23AM +0100, Sedat Dilek wrote: > Hi Linus, > > I am not sure if Greg is on holidays as his char-misc GIT tree didn't > get updated the last days. Yes, I'm supposed to be on vacation until the 7th. > The MEI driver causes here a serious regression requiring a hard cold > start of the machine I am working on. > A fix "mei: fix mismatch in mutex unlock-lock in mei_amthif_read()" > was already sent to LKML [1] and fixes the issue for me. > > Can you push that a bit? These patches are in my "to-apply" queue, which I will get to Linus in time for 3.8-final, so there's no rush on your end needed. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] forcedeth: Fix WARNINGS that result when DMA mapping is not checked
With 3.8-rc1, the first call of pci_map_single() that is not checked
with a corresponding pci_dma_mapping_error() call results in a warning
with a splat as follows:
WARNING: at lib/dma-debug.c:933 check_unmap+0x480/0x950()
Hardware name: HP Pavilion dv2700 Notebook PC
forcedeth :00:0a.0: DMA-API: device driver failed to check
map error[device address=0xb176e002] [size=90 bytes] [mapped as single]
Reviewed-by: Eric Dumazet
Signed-off-by: Larry Finger
---
V1 => V2: Replaced dev_kfree_skb_any() calls with kfree_skb() in RX
Changed TX mapping errors to drop packet, update drop count
and return NETDEV_TX_OK
---
drivers/net/ethernet/nvidia/forcedeth.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c
b/drivers/net/ethernet/nvidia/forcedeth.c
index 653487d..87fa591 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -1821,6 +1821,11 @@ static int nv_alloc_rx(struct net_device *dev)
skb->data,
skb_tailroom(skb),
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(np->pci_dev,
+ np->put_rx_ctx->dma)) {
+ kfree_skb(skb);
+ goto packet_dropped;
+ }
np->put_rx_ctx->dma_len = skb_tailroom(skb);
np->put_rx.orig->buf = cpu_to_le32(np->put_rx_ctx->dma);
wmb();
@@ -1830,6 +1835,7 @@ static int nv_alloc_rx(struct net_device *dev)
if (unlikely(np->put_rx_ctx++ == np->last_rx_ctx))
np->put_rx_ctx = np->first_rx_ctx;
} else {
+packet_dropped:
u64_stats_update_begin(>swstats_rx_syncp);
np->stat_rx_dropped++;
u64_stats_update_end(>swstats_rx_syncp);
@@ -1856,6 +1862,11 @@ static int nv_alloc_rx_optimized(struct net_device *dev)
skb->data,
skb_tailroom(skb),
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(np->pci_dev,
+ np->put_rx_ctx->dma)) {
+ kfree_skb(skb);
+ goto packet_dropped;
+ }
np->put_rx_ctx->dma_len = skb_tailroom(skb);
np->put_rx.ex->bufhigh =
cpu_to_le32(dma_high(np->put_rx_ctx->dma));
np->put_rx.ex->buflow =
cpu_to_le32(dma_low(np->put_rx_ctx->dma));
@@ -1866,6 +1877,7 @@ static int nv_alloc_rx_optimized(struct net_device *dev)
if (unlikely(np->put_rx_ctx++ == np->last_rx_ctx))
np->put_rx_ctx = np->first_rx_ctx;
} else {
+packet_dropped:
u64_stats_update_begin(>swstats_rx_syncp);
np->stat_rx_dropped++;
u64_stats_update_end(>swstats_rx_syncp);
@@ -2217,6 +2229,15 @@ static netdev_tx_t nv_start_xmit(struct sk_buff *skb,
struct net_device *dev)
bcnt = (size > NV_TX2_TSO_MAX_SIZE) ? NV_TX2_TSO_MAX_SIZE :
size;
np->put_tx_ctx->dma = pci_map_single(np->pci_dev, skb->data +
offset, bcnt,
PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(np->pci_dev,
+ np->put_tx_ctx->dma)) {
+ /* on DMA mapping error - drop the packet */
+ kfree_skb(skb);
+ u64_stats_update_begin(>swstats_tx_syncp);
+ np->stat_tx_dropped++;
+ u64_stats_update_end(>swstats_tx_syncp);
+ return NETDEV_TX_OK;
+ }
np->put_tx_ctx->dma_len = bcnt;
np->put_tx_ctx->dma_single = 1;
put_tx->buf = cpu_to_le32(np->put_tx_ctx->dma);
@@ -2337,6 +2358,15 @@ static netdev_tx_t nv_start_xmit_optimized(struct
sk_buff *skb,
bcnt = (size > NV_TX2_TSO_MAX_SIZE) ? NV_TX2_TSO_MAX_SIZE :
size;
np->put_tx_ctx->dma = pci_map_single(np->pci_dev, skb->data +
offset, bcnt,
PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(np->pci_dev,
+ np->put_tx_ctx->dma)) {
+ /* on DMA mapping error - drop the packet */
+ kfree_skb(skb);
+
Re: [PATCH v3 06/11] x86/xen: Add i386 kexec/kdump implementation
"H. Peter Anvin" writes: > On 12/27/2012 03:23 PM, Daniel Kiper wrote: >>> On 12/26/2012 06:18 PM, Daniel Kiper wrote: Add i386 kexec/kdump implementation. v2 - suggestions/fixes: - allocate transition page table pages below 4 GiB (suggested by Jan Beulich). >>> >>> Why? >> >> Sadly all addresses are passed via unsigned long >> variable to kexec hypercall. >> > > So can you unf*ck your broken interface before imposing it on anyone > else? Hasn't 32bit dom0 been retired? Untill the kexec firmware pass through and the normal kexec code paths are separated I can't make sense out of this code. The normal kexec code path should be doable without any special constraints on the kernel. Just leaning on some xen paravirt calls. The kexec pass through probably should not even touch x86 arch code. Certainly the same patch should not have code for both the xen kexec pass through and the paravirt arch code for the normal kexec path. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/11] kexec: introduce kexec firmware support
Daniel Kiper writes: >> Daniel Kiper writes: >> >> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default >> > Linux infrastructure and require some support from firmware and/or >> > hypervisor. >> > To cope with that problem kexec firmware infrastructure was introduced. >> > It allows a developer to use all kexec/kdump features of given firmware >> > or hypervisor. >> >> As this stands this patch is wrong. >> >> You need to pass an additional flag from userspace through /sbin/kexec >> that says load the kexec image in the firmware. A global variable here >> is not ok. >> >> As I understand it you are loading a kexec on xen panic image. Which >> is semantically different from a kexec on linux panic image. It is not >> ok to do have a silly global variable kexec_use_firmware. > > Earlier we agreed that /sbin/kexec should call kexec syscall with > special flag. However, during work on Xen kexec/kdump v3 patch > I stated that this is insufficient because e.g. crash_kexec() > should execute different code in case of use of firmware support too. That implies you have the wrong model of userspace. Very simply there is: linux kexec pass through to xen kexec. And linux kexec (ultimately pv kexec because the pv machine is a slightly different architecture). > Sadly syscall does not save this flag anywhere. > Additionally, I stated > that kernel itself has the best knowledge which code path should be > used (firmware or plain Linux). If this decision will be left to userspace > then simple kexec syscall could crash system at worst case (e.g. when > plain Linux kexec will be used in case when firmware kaxec should be > used). And that path selection bit is strongly non-sense. You are advocating hardcoding unnecessary policy in the kernel. If for dom0 you need crash_kexec to do something different from domU you should be able to load a small piece of code via kexec that makes the hypervisor calls you need. > However, if you wish I could add this flag to syscall. I do wish. We need to distinguish between the kexec firmware pass through, and normal kexec. > Additionally, I could > add function which enables firmware support and then kexec_use_firmware > variable will be global only in kexec.c module. No. kexec_use_firmware is the wrong mental model. Do not mix the kexec pass through and the normal kexec case. We most definitely need to call different code in the kexec firmware pass through case. For normal kexec we just need to use a paravirt aware version of machine_kexec and machine_kexec_shutdown. >> Furthermore it is not ok to have a conditional >> code outside of header files. > > I agree but how to dispatch execution e.g. in crash_kexec() > if we would like (I suppose) compile kexec firmware > support conditionally? The classic pattern is to have the #ifdefs in the header and have an noop function that is inlined when the functionality is compiled out. This allows all of the logic to always be compiled. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On 12/28/2012 10:45 AM, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say it maybe don't fix the issue completely.
run the reproducer[1] on two machine, one machine has 2 numa nodes(8Gb RAM),
another one has 4 numa nodes(8Gb RAM), then the system hung all the time, such
as the dmesg log:
[ 713.066937] Killed process 6085 (oom01) total-vm:18880768kB,
anon-rss:7915612kB, file-rss:4kB
[ 959.555269] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 959.562144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1079.382018] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1079.388872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1199.209709] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1199.216562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1319.036939] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1319.043794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1438.864797] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1438.871649] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1558.691611] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1558.698466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
..
I'm not sure whether it's your patch triggering the hung task or not, but
reverted cda73a10eb3,
the reproducer(oom01) can PASS without both 'NULL pointer dereference at
0500' and hung task issues.
but some time, it's possible that the reproducer(oom01) cause hung task on a
box with large RAM(100Gb+), so I can't judge it...
sorry, I forgot to link the reproducer.
oom01 in LTP test suite:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/oom/oom01.c
from my site, it can 100% reproduce the bug using oom01 test case.
Thanks,
Zhouping
Thanks,
Zhouping
Thanks,
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 23291b9..e55ce55 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2564,6 +2564,7 @@ static bool prepare_kswapd_sleep(pg_data_t
*pgdat, int order, long remaining,
static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
int *classzone_idx)
{
+ bool pgdat_is_balanced = false;
struct zone *unbalanced_zone;
int i;
int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */
@@ -2638,8 +2639,11 @@ loop_again:
zone_clear_flag(zone, ZONE_CONGESTED);
}
}
- if (i < 0)
+
+ if (i < 0) {
+ pgdat_is_balanced = true;
goto out;
+ }
for (i = 0; i <= end_zone; i++) {
struct zone *zone = pgdat->node_zones + i;
@@ -2766,8 +2770,11 @@ loop_again:
pfmemalloc_watermark_ok(pgdat))
wake_up(>pfmemalloc_wait);
- if (pgdat_balanced(pgdat, order, *classzone_idx))
+ if (pgdat_balanced(pgdat, order, *classzone_idx)) {
+ pgdat_is_balanced = true;
break; /* kswapd: all done */
+ }
+
/*
* OK, kswapd is getting into trouble. Take a nap, then take
* another pass across the zones.
@@ -2775,7 +2782,7 @@ loop_again:
if (total_scanned && (sc.priority < DEF_PRIORITY - 2)) {
if (has_under_min_watermark_zone)
count_vm_event(KSWAPD_SKIP_CONGESTION_WAIT);
- else
+ else if (unbalanced_zone)
wait_iff_congested(unbalanced_zone,
BLK_RW_ASYNC, HZ/10);
}
@@ -2788,9 +2795,9 @@ loop_again:
if (sc.nr_reclaimed >= SWAP_CLUSTER_MAX)
break;
} while (--sc.priority >= 0);
-out:
- if (!pgdat_balanced(pgdat, order, *classzone_idx)) {
+out:
+ if (!pgdat_is_balanced) {
cond_resched();
try_to_freeze();
--
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix null pointer dereference in wait_iff_congested()
Hello Zlatko,
On Fri, Dec 28, 2012 at 03:16:38AM +0100, Zlatko Calusic wrote:
> From: Zlatko Calusic
>
> The unintended consequence of commit 4ae0a48b is that
> wait_iff_congested() can now be called with NULL struct zone*
> producing kernel oops like this:
For good description, it would be better to write simple pseudo code
flow to show how NULL-zone pass into wait_iff_congested because
kswapd code flow is too complex.
As I see the code, we have following line above wait_iff_congested.
if (!unbalanced_zone || blah blah)
break;
How can NULL unbalanced_zone reach wait_iff_congested?
>
> BUG: unable to handle kernel NULL pointer dereference
> IP: [] wait_iff_congested+0x59/0x140
>
> This trivial patch fixes it.
>
> Reported-by: Zhouping Liu
> Reported-and-tested-by: Sedat Dilek
> Cc: Andrew Morton
> Cc: Mel Gorman
> Cc: Hugh Dickins
> Signed-off-by: Zlatko Calusic
> ---
> mm/vmscan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 02bcfa3..e55ce55 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2782,7 +2782,7 @@ loop_again:
> if (total_scanned && (sc.priority < DEF_PRIORITY - 2)) {
> if (has_under_min_watermark_zone)
> count_vm_event(KSWAPD_SKIP_CONGESTION_WAIT);
> - else
> + else if (unbalanced_zone)
> wait_iff_congested(unbalanced_zone,
> BLK_RW_ASYNC, HZ/10);
> }
>
> --
> 1.8.1.rc3
>
> --
> Zlatko
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL v2] f2fs fixes for 3.8-rc2
Hi Linus, Sorry for the noise. I've resolved the S-O-B issue in v1 tree. Here is the pull request v2. Thanks, -- Jaegeuk Kim Samsung The following changes since commit 637704cbc95c02d18741b4a6e7a5d2397f8b28ce: Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux (2012-12-23 09:48:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git tags/for-linus for you to fetch changes up to 9836b8b9499cb25ea32cad9fff640eef874c5431: f2fs: unify string length declarations and usage (2012-12-28 11:27:53 +0900) f2fs: bug fixes for 3.8-rc2 This patch-set includes two major bug fixes: - incorrect IUsed provided by *df -i*, and - lookup failure of parent inodes in corner cases. [Other Bug Fixes] - Fix error handling routines - Trigger recovery process correctly - Resolve build failures due to missing header files [Etc] - Add a MAINTAINERS entry for f2fs - Fix and clean up variables, functions, and equations - Avoid warnings during compilation Geert Uytterhoeven (1): f2fs: add missing #include Jaegeuk Kim (11): f2fs: remove set_page_dirty for atomic f2fs_end_io_write f2fs: fix wrong calculation on f_files in statfs f2fs: fix handling errors got by f2fs_write_inode f2fs: should recover orphan and fsync data f2fs: do f2fs_balance_fs in front of dir operations f2fs: invalidate the node page if allocation is failed f2fs: return a default value for non-void function f2fs: add MAINTAINERS entry f2fs: fix equation of has_not_enough_free_secs() f2fs: clean up the start_bidx_of_node function f2fs: clean up unused variables and return values Leon Romanovsky (1): f2fs: unify string length declarations and usage Namjae Jeon (5): f2fs: fix up f2fs_get_parent issue to retrieve correct parent inode number f2fs: handle error from f2fs_iget_nowait f2fs: remove unneeded initialization of nr_dirty in dirty_seglist_info f2fs: fix fsync_inode list addition logic and avoid invalid access to memory f2fs: remove unneeded variable from f2fs_sync_fs MAINTAINERS| 10 ++ fs/f2fs/data.c | 1 + fs/f2fs/dir.c | 16 +--- fs/f2fs/f2fs.h | 2 +- fs/f2fs/file.c | 10 ++ fs/f2fs/gc.c | 34 +++--- fs/f2fs/hash.c | 18 +++--- fs/f2fs/inode.c| 1 + fs/f2fs/namei.c| 34 +- fs/f2fs/node.c | 37 ++--- fs/f2fs/recovery.c | 10 +++--- fs/f2fs/segment.c | 46 ++ fs/f2fs/segment.h | 15 ++- fs/f2fs/super.c| 15 ++- fs/f2fs/xattr.c| 5 +++-- 15 files changed, 117 insertions(+), 137 deletions(-) signature.asc Description: This is a digitally signed message part
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
>
> Thank you for the report Zhouping!
>
> Would you be so kind to test the following patch and report results?
> Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say it maybe don't fix the issue completely.
run the reproducer[1] on two machine, one machine has 2 numa nodes(8Gb RAM),
another one has 4 numa nodes(8Gb RAM), then the system hung all the time, such
as the dmesg log:
[ 713.066937] Killed process 6085 (oom01) total-vm:18880768kB,
anon-rss:7915612kB, file-rss:4kB
[ 959.555269] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 959.562144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1079.382018] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1079.388872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1199.209709] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1199.216562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1319.036939] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1319.043794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1438.864797] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1438.871649] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1558.691611] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
[ 1558.698466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
..
I'm not sure whether it's your patch triggering the hung task or not, but
reverted cda73a10eb3,
the reproducer(oom01) can PASS without both 'NULL pointer dereference at
0500' and hung task issues.
but some time, it's possible that the reproducer(oom01) cause hung task on a
box with large RAM(100Gb+), so I can't judge it...
Thanks,
Zhouping
>
> Thanks,
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 23291b9..e55ce55 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2564,6 +2564,7 @@ static bool prepare_kswapd_sleep(pg_data_t
> *pgdat, int order, long remaining,
> static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
> int *classzone_idx)
> {
> + bool pgdat_is_balanced = false;
> struct zone *unbalanced_zone;
> int i;
> int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */
> @@ -2638,8 +2639,11 @@ loop_again:
> zone_clear_flag(zone, ZONE_CONGESTED);
> }
> }
> - if (i < 0)
> +
> + if (i < 0) {
> + pgdat_is_balanced = true;
> goto out;
> + }
>
> for (i = 0; i <= end_zone; i++) {
> struct zone *zone = pgdat->node_zones + i;
> @@ -2766,8 +2770,11 @@ loop_again:
> pfmemalloc_watermark_ok(pgdat))
> wake_up(>pfmemalloc_wait);
>
> - if (pgdat_balanced(pgdat, order, *classzone_idx))
> + if (pgdat_balanced(pgdat, order, *classzone_idx)) {
> + pgdat_is_balanced = true;
> break; /* kswapd: all done */
> + }
> +
> /*
>* OK, kswapd is getting into trouble. Take a nap, then take
>* another pass across the zones.
> @@ -2775,7 +2782,7 @@ loop_again:
> if (total_scanned && (sc.priority < DEF_PRIORITY - 2)) {
> if (has_under_min_watermark_zone)
> count_vm_event(KSWAPD_SKIP_CONGESTION_WAIT);
> - else
> + else if (unbalanced_zone)
> wait_iff_congested(unbalanced_zone,
> BLK_RW_ASYNC, HZ/10);
> }
>
> @@ -2788,9 +2795,9 @@ loop_again:
> if (sc.nr_reclaimed >= SWAP_CLUSTER_MAX)
> break;
> } while (--sc.priority >= 0);
> -out:
>
> - if (!pgdat_balanced(pgdat, order, *classzone_idx)) {
> +out:
> + if (!pgdat_is_balanced) {
> cond_resched();
>
> try_to_freeze();
>
> --
> Zlatko
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>
--
Thanks,
Zhouping
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/8] MFD:rtsx: Fix typo in comment
From: Wei WANG Fix a misspelling word in comment Signed-off-by: Wei WANG --- include/linux/mfd/rtsx_pci.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 060b721..bebe9f9 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -452,7 +452,7 @@ #defineSD_RSP_TYPE_R6 0x01 #defineSD_RSP_TYPE_R7 0x01 -/* SD_CONFIURE3 */ +/* SD_CONFIGURE3 */ #defineSD_RSP_80CLK_TIMEOUT_EN 0x01 /* Card Transfer Reset Register */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 8/8] MFD:rtsx: Use macro defines to replace some variables
From: Wei WANG
In function rtsx_pci_switch_clock, some variables, such as min_n, max_n,
and max_div, are not necessary. And those assigned values look very
obscure for others. It's more proper to use macro definitions here to
replace these variables.
Signed-off-by: Wei WANG
Acked-by: Borislav Petkov
---
drivers/mfd/rtsx_pcr.c | 13 -
drivers/mfd/rtsx_pcr.h |3 +++
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 7632e7f..431a74c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -590,8 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
{
int err, clk;
- u8 n, min_n, max_n, clk_divider;
- u8 mcu_cnt, div, max_div;
+ u8 n, clk_divider, mcu_cnt, div;
u8 depth[] = {
[RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
[RTSX_SSC_DEPTH_2M] = SSC_DEPTH_2M,
@@ -615,10 +614,6 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
card_clock /= 100;
dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
- min_n = 80;
- max_n = 208;
- max_div = CLK_DIV_8;
-
clk = card_clock;
if (!initial_mode && double_clk)
clk = card_clock * 2;
@@ -633,16 +628,16 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
n = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
else
n = (u8)(clk - 2);
- if ((clk <= 2) || (n > max_n))
+ if ((clk <= 2) || (n > MAX_DIV_N_PCR))
return -EINVAL;
mcu_cnt = (u8)(125/clk + 3);
if (mcu_cnt > 15)
mcu_cnt = 15;
- /* Make sure that the SSC clock div_n is equal or greater than min_n */
+ /* Make sure that the SSC clock div_n is not less than MIN_DIV_N_PCR */
div = CLK_DIV_1;
- while ((n < min_n) && (div < max_div)) {
+ while ((n < MIN_DIV_N_PCR) && (div < CLK_DIV_8)) {
if (pcr->ops->conv_clk_and_div_n) {
int dbl_clk = pcr->ops->conv_clk_and_div_n(n,
DIV_N_TO_CLK) * 2;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 12462c1..33c210b 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -25,6 +25,9 @@
#include
+#define MIN_DIV_N_PCR 80
+#define MAX_DIV_N_PCR 208
+
void rts5209_init_params(struct rtsx_pcr *pcr);
void rts5229_init_params(struct rtsx_pcr *pcr);
void rtl8411_init_params(struct rtsx_pcr *pcr);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/8] MFD:rtsx: Add callback function conv_clk_and_div_n
From: Wei WANG
Add callback function conv_clk_and_div_n to convert between SSC clock
and its divider N.
For rtl8411, the formula to calculate SSC clock divider N is different
with the other card reader models.
Signed-off-by: Wei WANG
---
drivers/mfd/rtl8411.c | 13 +
drivers/mfd/rts5209.c |1 +
drivers/mfd/rts5229.c |1 +
drivers/mfd/rtsx_pcr.c | 14 --
include/linux/mfd/rtsx_common.h |3 +++
include/linux/mfd/rtsx_pci.h|1 +
6 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 5058ba8..3d3b4ad 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -178,6 +178,18 @@ static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr
*pcr)
return card_exist;
}
+static int rtl8411_conv_clk_and_div_n(int input, int dir)
+{
+ int output;
+
+ if (dir == CLK_TO_DIV_N)
+ output = input * 4 / 5 - 2;
+ else
+ output = (input + 2) * 5 / 4;
+
+ return output;
+}
+
static const struct pcr_ops rtl8411_pcr_ops = {
.extra_init_hw = rtl8411_extra_init_hw,
.optimize_phy = NULL,
@@ -189,6 +201,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.card_power_off = rtl8411_card_power_off,
.switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
+ .conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
};
/* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index ba74de8..98fe0f3 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -174,6 +174,7 @@ static const struct pcr_ops rts5209_pcr_ops = {
.card_power_off = rts5209_card_power_off,
.switch_output_voltage = rts5209_switch_output_voltage,
.cd_deglitch = NULL,
+ .conv_clk_and_div_n = NULL,
};
/* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index ec1747a..29d889c 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -144,6 +144,7 @@ static const struct pcr_ops rts5229_pcr_ops = {
.card_power_off = rts5229_card_power_off,
.switch_output_voltage = rts5229_switch_output_voltage,
.cd_deglitch = NULL,
+ .conv_clk_and_div_n = NULL,
};
/* SD Pull Control Enable:
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 99e12b8..958b738 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -629,7 +629,10 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
if (clk == pcr->cur_clock)
return 0;
- N = (u8)(clk - 2);
+ if (pcr->ops->conv_clk_and_div_n)
+ N = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
+ else
+ N = (u8)(clk - 2);
if ((clk <= 2) || (N > max_N))
return -EINVAL;
@@ -640,7 +643,14 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
/* Make sure that the SSC clock div_n is equal or greater than min_N */
div = CLK_DIV_1;
while ((N < min_N) && (div < max_div)) {
- N = (N + 2) * 2 - 2;
+ if (pcr->ops->conv_clk_and_div_n) {
+ int dbl_clk = pcr->ops->conv_clk_and_div_n(N,
+ DIV_N_TO_CLK) * 2;
+ N = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
+ CLK_TO_DIV_N);
+ } else {
+ N = (N + 2) * 2 - 2;
+ }
div++;
}
dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", N, div);
diff --git a/include/linux/mfd/rtsx_common.h b/include/linux/mfd/rtsx_common.h
index a8d393e..2b13970 100644
--- a/include/linux/mfd/rtsx_common.h
+++ b/include/linux/mfd/rtsx_common.h
@@ -38,6 +38,9 @@
#define RTSX_SD_CARD 0
#define RTSX_MS_CARD 1
+#define CLK_TO_DIV_N 0
+#define DIV_N_TO_CLK 1
+
struct platform_device;
struct rtsx_slot {
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 2e3e2e0..3f2bf26 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -704,6 +704,7 @@ struct pcr_ops {
int (*switch_output_voltage)(struct rtsx_pcr *pcr,
u8 voltage);
unsigned int(*cd_deglitch)(struct rtsx_pcr *pcr);
+ int (*conv_clk_and_div_n)(int clk, int dir);
};
enum PDEV_STAT {PDEV_STAT_IDLE, PDEV_STAT_RUN};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/8] MFD:rtsx: Fix checkpatch warning
From: Wei WANG
WARNING: Avoid CamelCase:
+ u8 N, min_N, max_N, clk_divider;
WARNING: Avoid CamelCase:
+ u8 N, min_N, max_N, clk_divider;
Signed-off-by: Wei WANG
---
drivers/mfd/rtsx_pcr.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 958b738..7632e7f 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -590,7 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
{
int err, clk;
- u8 N, min_N, max_N, clk_divider;
+ u8 n, min_n, max_n, clk_divider;
u8 mcu_cnt, div, max_div;
u8 depth[] = {
[RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
@@ -615,8 +615,8 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
card_clock /= 100;
dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
- min_N = 80;
- max_N = 208;
+ min_n = 80;
+ max_n = 208;
max_div = CLK_DIV_8;
clk = card_clock;
@@ -630,30 +630,30 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
return 0;
if (pcr->ops->conv_clk_and_div_n)
- N = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
+ n = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
else
- N = (u8)(clk - 2);
- if ((clk <= 2) || (N > max_N))
+ n = (u8)(clk - 2);
+ if ((clk <= 2) || (n > max_n))
return -EINVAL;
mcu_cnt = (u8)(125/clk + 3);
if (mcu_cnt > 15)
mcu_cnt = 15;
- /* Make sure that the SSC clock div_n is equal or greater than min_N */
+ /* Make sure that the SSC clock div_n is equal or greater than min_n */
div = CLK_DIV_1;
- while ((N < min_N) && (div < max_div)) {
+ while ((n < min_n) && (div < max_div)) {
if (pcr->ops->conv_clk_and_div_n) {
- int dbl_clk = pcr->ops->conv_clk_and_div_n(N,
+ int dbl_clk = pcr->ops->conv_clk_and_div_n(n,
DIV_N_TO_CLK) * 2;
- N = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
+ n = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
CLK_TO_DIV_N);
} else {
- N = (N + 2) * 2 - 2;
+ n = (n + 2) * 2 - 2;
}
div++;
}
- dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", N, div);
+ dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", n, div);
ssc_depth = depth[ssc_depth];
if (double_clk)
@@ -670,7 +670,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL1, SSC_RSTB, 0);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL2,
SSC_DEPTH_MASK, ssc_depth);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_DIV_N_0, 0xFF, N);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_DIV_N_0, 0xFF, n);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL1, SSC_RSTB, SSC_RSTB);
if (vpclk) {
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_VPCLK0_CTL,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/8] MFD:rtsx: Add callback function switch_output_voltage
From: Wei WANG
Different card reader has different method to switch output voltage,
add this callback to let the card reader implement its individual switch
function.
Signed-off-by: Wei WANG
---
drivers/mfd/rtl8411.c| 16
drivers/mfd/rts5209.c| 20
drivers/mfd/rts5229.c| 20
drivers/mfd/rtsx_pcr.c |9 +
include/linux/mfd/rtsx_pci.h | 24
5 files changed, 85 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 89f046c..5058ba8 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -112,6 +112,21 @@ static int rtl8411_card_power_off(struct rtsx_pcr *pcr,
int card)
BPP_LDO_POWB, BPP_LDO_SUSPEND);
}
+static int rtl8411_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ u8 mask, val;
+
+ mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_MASK;
+ if (voltage == OUTPUT_3V3)
+ val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_3V3;
+ else if (voltage == OUTPUT_1V8)
+ val = (BPP_ASIC_1V8 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_1V8;
+ else
+ return -EINVAL;
+
+ return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
+}
+
static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr *pcr)
{
unsigned int card_exist;
@@ -172,6 +187,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.disable_auto_blink = rtl8411_disable_auto_blink,
.card_power_on = rtl8411_card_power_on,
.card_power_off = rtl8411_card_power_off,
+ .switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
};
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 283a4f1..ba74de8 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -144,6 +144,25 @@ static int rts5209_card_power_off(struct rtsx_pcr *pcr,
int card)
return rtsx_pci_send_cmd(pcr, 100);
}
+static int rts5209_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ int err;
+
+ if (voltage == OUTPUT_3V3) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
+ if (err < 0)
+ return err;
+ } else if (voltage == OUTPUT_1V8) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
+ if (err < 0)
+ return err;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct pcr_ops rts5209_pcr_ops = {
.extra_init_hw = rts5209_extra_init_hw,
.optimize_phy = rts5209_optimize_phy,
@@ -153,6 +172,7 @@ static const struct pcr_ops rts5209_pcr_ops = {
.disable_auto_blink = rts5209_disable_auto_blink,
.card_power_on = rts5209_card_power_on,
.card_power_off = rts5209_card_power_off,
+ .switch_output_voltage = rts5209_switch_output_voltage,
.cd_deglitch = NULL,
};
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index b9dbab2..ec1747a 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -114,6 +114,25 @@ static int rts5229_card_power_off(struct rtsx_pcr *pcr,
int card)
return rtsx_pci_send_cmd(pcr, 100);
}
+static int rts5229_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ int err;
+
+ if (voltage == OUTPUT_3V3) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
+ if (err < 0)
+ return err;
+ } else if (voltage == OUTPUT_1V8) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
+ if (err < 0)
+ return err;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct pcr_ops rts5229_pcr_ops = {
.extra_init_hw = rts5229_extra_init_hw,
.optimize_phy = rts5229_optimize_phy,
@@ -123,6 +142,7 @@ static const struct pcr_ops rts5229_pcr_ops = {
.disable_auto_blink = rts5229_disable_auto_blink,
.card_power_on = rts5229_card_power_on,
.card_power_off = rts5229_card_power_off,
+ .switch_output_voltage = rts5229_switch_output_voltage,
.cd_deglitch = NULL,
};
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 1dc64bb..99e12b8 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -702,6 +702,15 @@ int rtsx_pci_card_power_off(struct rtsx_pcr *pcr, int card)
}
EXPORT_SYMBOL_GPL(rtsx_pci_card_power_off);
+int rtsx_pci_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ if (pcr->ops->switch_output_voltage)
+ return pcr->ops->switch_output_voltage(pcr, voltage);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_switch_output_voltage);
+
unsigned int rtsx_pci_card_exist(struct rtsx_pcr *pcr)
{
unsigned
[PATCH v3 5/8] MMC:rtsx: Using callback function to switch output voltage
From: Wei WANG
Different card reader has different method to switch output voltage, so
we have to use the callback function provided by MFD driver to switch
output pad voltage.
Signed-off-by: Wei WANG
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 571915d..f74b5ad 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1060,26 +1060,6 @@ static int sd_wait_voltage_stable_2(struct
realtek_pci_sdmmc *host)
return 0;
}
-static int sd_change_bank_voltage(struct realtek_pci_sdmmc *host, u8 voltage)
-{
- struct rtsx_pcr *pcr = host->pcr;
- int err;
-
- if (voltage == SD_IO_3V3) {
- err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
- if (err < 0)
- return err;
- } else if (voltage == SD_IO_1V8) {
- err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
- if (err < 0)
- return err;
- } else {
- return -EINVAL;
- }
-
- return 0;
-}
-
static int sdmmc_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct realtek_pci_sdmmc *host = mmc_priv(mmc);
@@ -1098,11 +1078,11 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
rtsx_pci_start_run(pcr);
if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330)
- voltage = SD_IO_3V3;
+ voltage = OUTPUT_3V3;
else
- voltage = SD_IO_1V8;
+ voltage = OUTPUT_1V8;
- if (voltage == SD_IO_1V8) {
+ if (voltage == OUTPUT_1V8) {
err = rtsx_pci_write_register(pcr,
SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
if (err < 0)
@@ -1113,11 +1093,11 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
goto out;
}
- err = sd_change_bank_voltage(host, voltage);
+ err = rtsx_pci_switch_output_voltage(pcr, voltage);
if (err < 0)
goto out;
- if (voltage == SD_IO_1V8) {
+ if (voltage == OUTPUT_1V8) {
err = sd_wait_voltage_stable_2(host);
if (err < 0)
goto out;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/8] MFD:rtsx: Declare that the DMA address limitation is 32bit explicitly
From: Wei WANG Realtek PCIe card reader only supports 32bit DMA Signed-off-by: Wei WANG --- drivers/mfd/rtsx_pcr.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index fa2c2bc..1dc64bb 100644 --- a/drivers/mfd/rtsx_pcr.c +++ b/drivers/mfd/rtsx_pcr.c @@ -1010,6 +1010,10 @@ static int __devinit rtsx_pci_probe(struct pci_dev *pcidev, pci_name(pcidev), (int)pcidev->vendor, (int)pcidev->device, (int)pcidev->revision); + ret = pci_set_dma_mask(pcidev, DMA_BIT_MASK(32)); + if (ret < 0) + return ret; + ret = pci_enable_device(pcidev); if (ret) return ret; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/8] MFD:rtsx: Remove redundant code
From: Wei WANG In function rtsx_pci_add_sg_tbl, the statement "ptr++" is useless. Signed-off-by: Wei WANG Acked-by: Borislav Petkov --- drivers/mfd/rtsx_pcr.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index 3a44efa..fa2c2bc 100644 --- a/drivers/mfd/rtsx_pcr.c +++ b/drivers/mfd/rtsx_pcr.c @@ -325,7 +325,6 @@ static void rtsx_pci_add_sg_tbl(struct rtsx_pcr *pcr, val = ((u64)addr << 32) | ((u64)len << 12) | option; put_unaligned_le64(val, ptr); - ptr++; pcr->sgi++; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/8] rtsx patchset for MFD and MMC tree
From: Wei WANG Wei WANG (8): MFD:rtsx: Fix typo in comment MFD:rtsx: Remove redundant code MFD:rtsx: Declare that the DMA address limitation is 32bit explicitly MFD:rtsx: Add callback function switch_output_voltage MMC:rtsx: Using callback function to switch output voltage MFD:rtsx: Add callback function conv_clk_and_div_n MFD:rtsx: Fix checkpatch warning MFD:rtsx: Use macro defines to replace some variables drivers/mfd/rtl8411.c | 29 drivers/mfd/rts5209.c | 21 + drivers/mfd/rts5229.c | 21 + drivers/mfd/rtsx_pcr.c| 45 + drivers/mfd/rtsx_pcr.h|3 +++ drivers/mmc/host/rtsx_pci_sdmmc.c | 30 + include/linux/mfd/rtsx_common.h |3 +++ include/linux/mfd/rtsx_pci.h | 27 +- 8 files changed, 135 insertions(+), 44 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] f2fs fixes for 3.8-rc2
2012-12-28 (금), 03:00 +0100, Sedat Dilek: > Looks like you didn't S-o-b-ed all patches in your tree (see Leon's or > Geert's patch). I've fixed all the patches. Thank you. :) > > - Sedat - > > On Fri, Dec 28, 2012 at 2:54 AM, Jaegeuk Kim wrote: > > Hi Linus, > > > > Please pull the following patches for bug fixes on the f2fs file system. > > Thank you very much. > > > > -- > > Jaegeuk Kim > > Samsung > > > > The following changes since commit > > 637704cbc95c02d18741b4a6e7a5d2397f8b28ce: > > > > Merge branch 'i2c-embedded/for-next' of > > git://git.pengutronix.de/git/wsa/linux (2012-12-23 09:48:33 -0800) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > > tags/for-linus > > > > for you to fetch changes up to 782c92d129775840cf9c1ad334f0722df9c76dc0: > > > > f2fs: unify string length declarations and usage (2012-12-28 09:57:55 > > +0900) > > > > > > f2fs: bug fixes for 3.8-rc2 > > > > This patch-set includes two major bug fixes: > > - incorrect IUsed provided by *df -i*, and > > - lookup failure of parent inodes in corner cases. > > > > [Other Bug Fixes] > > - Fix error handling routines > > - Trigger recovery process correctly > > - Resolve build failures due to missing header files > > > > [Etc] > > - Add a MAINTAINERS entry for f2fs > > - Fix and clean up variables, functions, and equations > > - Avoid warnings during compilation > > > > > > Geert Uytterhoeven (1): > > f2fs: add missing #include > > > > Jaegeuk Kim (11): > > f2fs: remove set_page_dirty for atomic f2fs_end_io_write > > f2fs: fix wrong calculation on f_files in statfs > > f2fs: fix handling errors got by f2fs_write_inode > > f2fs: should recover orphan and fsync data > > f2fs: do f2fs_balance_fs in front of dir operations > > f2fs: invalidate the node page if allocation is failed > > f2fs: return a default value for non-void function > > f2fs: add MAINTAINERS entry > > f2fs: fix equation of has_not_enough_free_secs() > > f2fs: clean up the start_bidx_of_node function > > f2fs: clean up unused variables and return values > > > > Leon Romanovsky (1): > > f2fs: unify string length declarations and usage > > > > Namjae Jeon (5): > > f2fs: fix up f2fs_get_parent issue to retrieve correct parent > > inode number > > f2fs: handle error from f2fs_iget_nowait > > f2fs: remove unneeded initialization of nr_dirty in > > dirty_seglist_info > > f2fs: fix fsync_inode list addition logic and avoid invalid access > > to memory > > f2fs: remove unneeded variable from f2fs_sync_fs > > > > MAINTAINERS| 10 ++ > > fs/f2fs/data.c | 1 + > > fs/f2fs/dir.c | 16 +--- > > fs/f2fs/f2fs.h | 2 +- > > fs/f2fs/file.c | 10 ++ > > fs/f2fs/gc.c | 34 +++--- > > fs/f2fs/hash.c | 18 +++--- > > fs/f2fs/inode.c| 1 + > > fs/f2fs/namei.c| 34 +- > > fs/f2fs/node.c | 37 ++--- > > fs/f2fs/recovery.c | 10 +++--- > > fs/f2fs/segment.c | 46 ++ > > fs/f2fs/segment.h | 15 ++- > > fs/f2fs/super.c| 15 ++- > > fs/f2fs/xattr.c| 5 +++-- > > 15 files changed, 117 insertions(+), 137 deletions(-) > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jaegeuk Kim Samsung signature.asc Description: This is a digitally signed message part
[PATCH] mm: fix null pointer dereference in wait_iff_congested()
From: Zlatko Calusic
The unintended consequence of commit 4ae0a48b is that
wait_iff_congested() can now be called with NULL struct zone*
producing kernel oops like this:
BUG: unable to handle kernel NULL pointer dereference
IP: [] wait_iff_congested+0x59/0x140
This trivial patch fixes it.
Reported-by: Zhouping Liu
Reported-and-tested-by: Sedat Dilek
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Hugh Dickins
Signed-off-by: Zlatko Calusic
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 02bcfa3..e55ce55 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2782,7 +2782,7 @@ loop_again:
if (total_scanned && (sc.priority < DEF_PRIORITY - 2)) {
if (has_under_min_watermark_zone)
count_vm_event(KSWAPD_SKIP_CONGESTION_WAIT);
- else
+ else if (unbalanced_zone)
wait_iff_congested(unbalanced_zone,
BLK_RW_ASYNC, HZ/10);
}
--
1.8.1.rc3
--
Zlatko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] f2fs fixes for 3.8-rc2
Looks like you didn't S-o-b-ed all patches in your tree (see Leon's or Geert's patch). - Sedat - On Fri, Dec 28, 2012 at 2:54 AM, Jaegeuk Kim wrote: > Hi Linus, > > Please pull the following patches for bug fixes on the f2fs file system. > Thank you very much. > > -- > Jaegeuk Kim > Samsung > > The following changes since commit > 637704cbc95c02d18741b4a6e7a5d2397f8b28ce: > > Merge branch 'i2c-embedded/for-next' of > git://git.pengutronix.de/git/wsa/linux (2012-12-23 09:48:33 -0800) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > tags/for-linus > > for you to fetch changes up to 782c92d129775840cf9c1ad334f0722df9c76dc0: > > f2fs: unify string length declarations and usage (2012-12-28 09:57:55 > +0900) > > > f2fs: bug fixes for 3.8-rc2 > > This patch-set includes two major bug fixes: > - incorrect IUsed provided by *df -i*, and > - lookup failure of parent inodes in corner cases. > > [Other Bug Fixes] > - Fix error handling routines > - Trigger recovery process correctly > - Resolve build failures due to missing header files > > [Etc] > - Add a MAINTAINERS entry for f2fs > - Fix and clean up variables, functions, and equations > - Avoid warnings during compilation > > > Geert Uytterhoeven (1): > f2fs: add missing #include > > Jaegeuk Kim (11): > f2fs: remove set_page_dirty for atomic f2fs_end_io_write > f2fs: fix wrong calculation on f_files in statfs > f2fs: fix handling errors got by f2fs_write_inode > f2fs: should recover orphan and fsync data > f2fs: do f2fs_balance_fs in front of dir operations > f2fs: invalidate the node page if allocation is failed > f2fs: return a default value for non-void function > f2fs: add MAINTAINERS entry > f2fs: fix equation of has_not_enough_free_secs() > f2fs: clean up the start_bidx_of_node function > f2fs: clean up unused variables and return values > > Leon Romanovsky (1): > f2fs: unify string length declarations and usage > > Namjae Jeon (5): > f2fs: fix up f2fs_get_parent issue to retrieve correct parent > inode number > f2fs: handle error from f2fs_iget_nowait > f2fs: remove unneeded initialization of nr_dirty in > dirty_seglist_info > f2fs: fix fsync_inode list addition logic and avoid invalid access > to memory > f2fs: remove unneeded variable from f2fs_sync_fs > > MAINTAINERS| 10 ++ > fs/f2fs/data.c | 1 + > fs/f2fs/dir.c | 16 +--- > fs/f2fs/f2fs.h | 2 +- > fs/f2fs/file.c | 10 ++ > fs/f2fs/gc.c | 34 +++--- > fs/f2fs/hash.c | 18 +++--- > fs/f2fs/inode.c| 1 + > fs/f2fs/namei.c| 34 +- > fs/f2fs/node.c | 37 ++--- > fs/f2fs/recovery.c | 10 +++--- > fs/f2fs/segment.c | 46 ++ > fs/f2fs/segment.h | 15 ++- > fs/f2fs/super.c| 15 ++- > fs/f2fs/xattr.c| 5 +++-- > 15 files changed, 117 insertions(+), 137 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] f2fs fixes for 3.8-rc2
Hi Linus, Please pull the following patches for bug fixes on the f2fs file system. Thank you very much. -- Jaegeuk Kim Samsung The following changes since commit 637704cbc95c02d18741b4a6e7a5d2397f8b28ce: Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux (2012-12-23 09:48:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git tags/for-linus for you to fetch changes up to 782c92d129775840cf9c1ad334f0722df9c76dc0: f2fs: unify string length declarations and usage (2012-12-28 09:57:55 +0900) f2fs: bug fixes for 3.8-rc2 This patch-set includes two major bug fixes: - incorrect IUsed provided by *df -i*, and - lookup failure of parent inodes in corner cases. [Other Bug Fixes] - Fix error handling routines - Trigger recovery process correctly - Resolve build failures due to missing header files [Etc] - Add a MAINTAINERS entry for f2fs - Fix and clean up variables, functions, and equations - Avoid warnings during compilation Geert Uytterhoeven (1): f2fs: add missing #include Jaegeuk Kim (11): f2fs: remove set_page_dirty for atomic f2fs_end_io_write f2fs: fix wrong calculation on f_files in statfs f2fs: fix handling errors got by f2fs_write_inode f2fs: should recover orphan and fsync data f2fs: do f2fs_balance_fs in front of dir operations f2fs: invalidate the node page if allocation is failed f2fs: return a default value for non-void function f2fs: add MAINTAINERS entry f2fs: fix equation of has_not_enough_free_secs() f2fs: clean up the start_bidx_of_node function f2fs: clean up unused variables and return values Leon Romanovsky (1): f2fs: unify string length declarations and usage Namjae Jeon (5): f2fs: fix up f2fs_get_parent issue to retrieve correct parent inode number f2fs: handle error from f2fs_iget_nowait f2fs: remove unneeded initialization of nr_dirty in dirty_seglist_info f2fs: fix fsync_inode list addition logic and avoid invalid access to memory f2fs: remove unneeded variable from f2fs_sync_fs MAINTAINERS| 10 ++ fs/f2fs/data.c | 1 + fs/f2fs/dir.c | 16 +--- fs/f2fs/f2fs.h | 2 +- fs/f2fs/file.c | 10 ++ fs/f2fs/gc.c | 34 +++--- fs/f2fs/hash.c | 18 +++--- fs/f2fs/inode.c| 1 + fs/f2fs/namei.c| 34 +- fs/f2fs/node.c | 37 ++--- fs/f2fs/recovery.c | 10 +++--- fs/f2fs/segment.c | 46 ++ fs/f2fs/segment.h | 15 ++- fs/f2fs/super.c| 15 ++- fs/f2fs/xattr.c| 5 +++-- 15 files changed, 117 insertions(+), 137 deletions(-) signature.asc Description: This is a digitally signed message part
Re: [PATCH V3 7/8] memcg: disable memcg page stat accounting code when not in use
(2012/12/26 2:27), Sha Zhengju wrote:
> From: Sha Zhengju
>
> It's inspired by a similar optimization from Glauber Costa
> (memcg: make it suck faster; https://lkml.org/lkml/2012/9/25/154).
> Here we use jump label to patch the memcg page stat accounting code
> in or out when not used. when the first non-root memcg comes to
> life the code is patching in otherwise it is out.
>
> Signed-off-by: Sha Zhengju
> ---
> include/linux/memcontrol.h |9 +
> mm/memcontrol.c|8
> 2 files changed, 17 insertions(+)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 1d22b81..3c4430c 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -56,6 +56,9 @@ struct mem_cgroup_reclaim_cookie {
> };
>
> #ifdef CONFIG_MEMCG
> +
> +extern struct static_key memcg_in_use_key;
> +
> /*
>* All "charge" functions with gfp_mask should use GFP_KERNEL or
>* (gfp_mask & GFP_RECLAIM_MASK). In current implementatin, memcg doesn't
> @@ -158,6 +161,9 @@ extern atomic_t memcg_moving;
> static inline void mem_cgroup_begin_update_page_stat(struct page *page,
> bool *locked, unsigned long *flags)
> {
> + if (!static_key_false(_in_use_key))
> + return;
> +
> if (mem_cgroup_disabled())
> return;
> rcu_read_lock();
> @@ -171,6 +177,9 @@ void __mem_cgroup_end_update_page_stat(struct page *page,
> static inline void mem_cgroup_end_update_page_stat(struct page *page,
> bool *locked, unsigned long *flags)
> {
> + if (!static_key_false(_in_use_key))
> + return;
> +
> if (mem_cgroup_disabled())
> return;
> if (*locked)
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 0cb5187..a2f73d7 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -531,6 +531,8 @@ enum res_type {
> #define MEM_CGROUP_RECLAIM_SHRINK_BIT 0x1
> #define MEM_CGROUP_RECLAIM_SHRINK (1 << MEM_CGROUP_RECLAIM_SHRINK_BIT)
>
> +struct static_key memcg_in_use_key;
> +
> static void mem_cgroup_get(struct mem_cgroup *memcg);
> static void mem_cgroup_put(struct mem_cgroup *memcg);
>
> @@ -2226,6 +2228,9 @@ void mem_cgroup_update_page_stat(struct page *page,
> struct page_cgroup *pc = lookup_page_cgroup(page);
> unsigned long uninitialized_var(flags);
>
> + if (!static_key_false(_in_use_key))
> + return;
> +
> if (mem_cgroup_disabled())
> return;
>
> @@ -6340,6 +6345,8 @@ mem_cgroup_css_alloc(struct cgroup *cont)
> parent = mem_cgroup_from_cont(cont->parent);
> memcg->use_hierarchy = parent->use_hierarchy;
> memcg->oom_kill_disable = parent->oom_kill_disable;
> +
> + static_key_slow_inc(_in_use_key);
> }
>
> if (parent && parent->use_hierarchy) {
> @@ -6407,6 +6414,7 @@ static void mem_cgroup_css_free(struct cgroup *cont)
> kmem_cgroup_destroy(memcg);
>
> memcg_dangling_add(memcg);
> + static_key_slow_dec(_in_use_key);
Hmm. I think this part should be folded into disarm_static_keys().
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ppoll() stuck on POLLIN while TCP peer is sending
I'm finding ppoll() unexpectedly stuck when waiting for POLLIN on a
local TCP socket. The isolated code below can reproduces the issue
after many minutes (<1 hour). It might be easier to reproduce on
a busy system while disk I/O is happening.
This may also be related to an epoll-related issue reported
by Andreas Voellmy:
http://thread.gmane.org/gmane.linux.kernel/1408782/
My example involves a 3 thread data flow between two pairs
of (4) sockets:
send_loop -> recv_loop(recv_send) -> recv_loop(recv_only)
pair_a[1] -> (pair_a[0] -> pair_b[1]) -> pair_b[0]
At least 3.7 and 3.7.1 are affected.
I have tcp_low_latency=1 set, I will try 0 later
The last progress message I got was after receiving 2942052597760
bytes on fd=7 (out of 64-bit ULONG_MAX / 2)
strace:
3644 sendto(4,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384,
0, NULL, 0
3643 sendto(6,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384,
0, NULL, 0
3642 ppoll([{fd=7, events=POLLIN}], 1, NULL, NULL, 8
3641 futex(0x7f23ed8129d0, FUTEX_WAIT, 3644, NULL
The first and last lines of the strace are expected:
+ 3644 sendto(4) is blocked because 3643 is blocked on sendto(fd=6)
and not able to call recv().
+ 3641 is the main thread calling pthread_join
What is unexpected is the tid=3643 and tid=3642 interaction. As confirmed
by lsof below, fd=6 is sending to wake up fd=7, but ppoll(fd=7) seems
to not be waking up.
lsof:
toosleepy 3641 ew4u IPv4 12405 0t0 TCP
localhost:55904->localhost:33249 (ESTABLISHED)
toosleepy 3641 ew5u IPv4 12406 0t0 TCP
localhost:33249->localhost:55904 (ESTABLISHED)
toosleepy 3641 ew6u IPv4 12408 0t0 TCP
localhost:48777->localhost:33348 (ESTABLISHED)
toosleepy 3641 ew7u IPv4 12409 0t0 TCP
localhost:33348->localhost:48777 (ESTABLISHED)
System info: Linux 3.7.1 x86_64 SMP PREEMPT
AMD Phenom(tm) II X4 945 Processor (4 cores)
Nothing interesting in dmesg, iptables rules are empty.
I have not yet been able to reproduce the issue using UNIX sockets,
only TCP, but you can run:
./toosleepy unix
...to test with UNIX sockets intead of TCP.
The following code is also available via git://bogomips.org/toosleepy
gcc -o toosleepy -O2 -Wall -lpthread toosleepy.c
8<
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct receiver {
int rfd;
int sfd;
};
/* blocking sender */
static void * send_loop(void *fdp)
{
int fd = *(int *)fdp;
char buf[16384];
ssize_t s;
size_t sent = 0;
size_t max = (size_t)ULONG_MAX / 2;
while (sent < max) {
s = send(fd, buf, sizeof(buf), 0);
if (s > 0)
sent += s;
if (s == -1)
assert(errno == EINTR);
}
dprintf(2, "%d done sending: %zu\n", fd, sent);
close(fd);
return NULL;
}
/* non-blocking receiver, using ppoll */
static void * recv_loop(void *p)
{
const struct receiver *rcvr = p;
char buf[16384];
nfds_t nfds = 1;
struct pollfd fds;
int rc;
ssize_t r, s;
size_t received = 0;
size_t sent = 0;
for (;;) {
r = recv(rcvr->rfd, buf, sizeof(buf), 0);
if (r == 0) {
break;
} else if (r == -1) {
assert(errno == EAGAIN);
fds.fd = rcvr->rfd;
fds.events = POLLIN;
errno = 0;
rc = ppoll(, nfds, NULL, NULL);
assert(rc == 1);
} else {
assert(r > 0);
received += r;
if (rcvr->sfd >= 0) {
s = send(rcvr->sfd, buf, sizeof(buf), 0);
if (s > 0)
sent += s;
if (s == -1)
assert(errno == EINTR);
} else {
/* just burn some cycles */
write(-1, buf, sizeof(buf));
}
}
if ((received % (sizeof(buf) * sizeof(buf) * 16) == 0))
dprintf(2, " %d progress: %zu\n",
rcvr->rfd, received);
}
dprintf(2, "%d got: %zu\n", rcvr->rfd, received);
if (rcvr->sfd >= 0) {
dprintf(2, "%d sent: %zu\n", rcvr->sfd, sent);
close(rcvr->sfd);
}
return NULL;
}
static void tcp_socketpair(int sv[2], int
[PATCH v7 1/2] KSM: numa awareness sysfs knob
Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
which control merging pages across different numa nodes.
When it is set to zero only pages from the same node are merged,
otherwise pages from all nodes can be merged together (default behavior).
Typical use-case could be a lot of KVM guests on NUMA machine
and cpus from more distant nodes would have significant increase
of access latency to the merged ksm page. Sysfs knob was choosen
for higher variability when some users still prefers higher amount
of saved physical memory regardless of access latency.
Every numa node has its own stable & unstable trees because of faster
searching and inserting. Changing of merge_across_nodes value is possible
only when there are not any ksm shared pages in system.
I've tested this patch on numa machines with 2, 4 and 8 nodes and
measured speed of memory access inside of KVM guests with memory pinned
to one of nodes with this benchmark:
http://pholasek.fedorapeople.org/alloc_pg.c
Population standard deviations of access times in percentage of average
were following:
merge_across_nodes=1
2 nodes 1.4%
4 nodes 1.6%
8 nodes 1.7%
merge_across_nodes=0
2 nodes 1%
4 nodes 0.32%
8 nodes 0.018%
RFC: https://lkml.org/lkml/2011/11/30/91
v1: https://lkml.org/lkml/2012/1/23/46
v2: https://lkml.org/lkml/2012/6/29/105
v3: https://lkml.org/lkml/2012/9/14/550
v4: https://lkml.org/lkml/2012/9/23/137
v5: https://lkml.org/lkml/2012/12/10/540
v6: https://lkml.org/lkml/2012/12/23/154
Changelog:
v2: Andrew's objections were reflected:
- value of merge_nodes can't be changed while there are some ksm
pages in system
- merge_nodes sysfs entry appearance depends on CONFIG_NUMA
- more verbose documentation
- added some performance testing results
v3: - more verbose documentation
- fixed race in merge_nodes store function
- introduced share_all debugging knob proposed by Andrew
- minor cleanups
v4: - merge_nodes was renamed to merge_across_nodes
- share_all debug knob was dropped
- get_kpfn_nid helper
- fixed page migration behaviour
v5: - unstable node's nid presence depends on CONFIG_NUMA
- fixed oops appearing when stable nodes were removed from tree
- roots of stable trees are initialized properly
- fixed unstable page migration issue
v6: - fixed oops caused by stable_nodes appended to wrong tree
- KSM_RUN_MERGE test removed
v7: - added sysfs ABI documentation for KSM
Signed-off-by: Petr Holasek
Signed-off-by: Hugh Dickins
Acked-by: Rik van Riel
---
Documentation/vm/ksm.txt | 7 +++
mm/ksm.c | 151 +--
2 files changed, 139 insertions(+), 19 deletions(-)
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index b392e49..25cc89b 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -58,6 +58,13 @@ sleep_millisecs - how many milliseconds ksmd should sleep
before next scan
e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
Default: 20 (chosen for demonstration purposes)
+merge_across_nodes - specifies if pages from different numa nodes can be
merged.
+ When set to 0, ksm merges only pages which physically
+ reside in the memory area of same NUMA node. It brings
+ lower latency to access to shared page. Value can be
+ changed only when there is no ksm shared pages in system.
+ Default: 1
+
run - set 0 to stop ksmd from running but keep merged pages,
set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
set 2 to stop ksmd and unmerge all pages currently merged,
diff --git a/mm/ksm.c b/mm/ksm.c
index 5157385..d1e1041 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -139,6 +140,9 @@ struct rmap_item {
struct mm_struct *mm;
unsigned long address; /* + low bits used for flags below */
unsigned int oldchecksum; /* when unstable */
+#ifdef CONFIG_NUMA
+ unsigned int nid;
+#endif
union {
struct rb_node node;/* when node of unstable tree */
struct {/* when listed from stable tree */
@@ -153,8 +157,8 @@ struct rmap_item {
#define STABLE_FLAG0x200 /* is listed from the stable tree */
/* The stable and unstable tree heads */
-static struct rb_root root_stable_tree = RB_ROOT;
-static struct rb_root root_unstable_tree = RB_ROOT;
+static struct rb_root root_unstable_tree[MAX_NUMNODES];
+static struct rb_root root_stable_tree[MAX_NUMNODES];
#define MM_SLOTS_HASH_SHIFT 10
#define MM_SLOTS_HASH_HEADS (1 << MM_SLOTS_HASH_SHIFT)
@@ -189,6 +193,9 @@ static unsigned int ksm_thread_pages_to_scan = 100;
/*
[PATCH v7 2/2] Documentation: add sysfs ABI documentation for ksm
This patch adds sysfs documentation for Kernel Samepage Merging (KSM) including new merge_across_nodes knob. Signed-off-by: Petr Holasek --- Documentation/ABI/testing/sysfs-kernel-mm-ksm | 51 +++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-ksm diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm new file mode 100644 index 000..44384ae --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-ksm @@ -0,0 +1,51 @@ +What: /sys/kernel/mm/ksm +Date: September 2009 +Contact: Linux memory management mailing list +Description: /sys/kernel/mm/ksm contains interface of Kernel Samepage + Merging (KSM) + +What: /sys/kernel/mm/ksm/full_scans +What: /sys/kernel/mm/ksm/pages_shared +What: /sys/kernel/mm/ksm/pages_sharing +What: /sys/kernel/mm/ksm/pages_to_scan +What: /sys/kernel/mm/ksm/pages_unshared +What: /sys/kernel/mm/ksm/pages_volatile +What: /sys/kernel/mm/ksm/run +What: /sys/kernel/mm/ksm/sleep_millisecs +Date: September 2009 +Contact: Linux memory management mailing list +Description: Kernel Samepage Merging daemon sysfs interface + + full_scans: how many times all mergeable areas have been + scanned. + + pages_shared: how many shared pages are being used. + + pages_sharing: how many more sites are sharing them i.e. how + much saved. + + pages_to_scan: how many present pages to scan before ksmd goes + to sleep. + + pages_unshared: how many pages unique but repeatedly checked + for merging. + + pages_volatile: how many pages changing too fast to be placed + in a tree. + + run: write 0 to disable ksm, read 0 while ksm is disabled. + write 1 to run ksm, read 1 while ksm is running. + write 2 to disable ksm and unmerge all its pages. + + sleep_millisecs: how many milliseconds ksm should sleep between + scans. + + See Documentation/vm/ksm.txt for more information. + +What: /sys/kernel/mm/ksm/merge_across_nodes +Date: December 2012 +Contact: Linux memory management mailing list +Description: Control merging pages across different NUMA nodes. + + When it is set to 0 only pages from the same node are merged, + otherwise pages from all nodes can be merged together (default). -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: vt8500: Add support for Wondermedia I2C master-mode
This patch adds support for the I2C controller found on Wondermedia
SoCs.
Due to the lack of pinmux support, GPIO pin alternate functions are
configured by machine's compatible property, as are pullups.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/i2c/i2c-vt8500.txt | 24 +
drivers/i2c/busses/Kconfig |7 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-wmt.c | 636
4 files changed, 668 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
create mode 100644 drivers/i2c/busses/i2c-wmt.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
new file mode 100644
index 000..94a425e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
@@ -0,0 +1,24 @@
+* Wondermedia I2C Controller
+
+Required properties :
+
+ - compatible : should be "wm,wm8505-i2c"
+ - reg : Offset and length of the register set for the device
+ - interrupts : where IRQ is the interrupt number
+ - clocks : phandle to the I2C clock source
+
+Optional properties :
+
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+ Valid values are 10 and 40.
+ Default to 10 if not specified, or invalid value.
+
+Example :
+
+ i2c_0: i2c@d828 {
+ compatible = "wm,wm8505-i2c";
+ reg = <0xd828 0x1000>;
+ interrupts = <19>;
+ clocks = <>;
+ clock-frequency = <40>;
+ };
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index bdca511..41270fa 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -700,6 +700,13 @@ config I2C_VERSATILE
This driver can also be built as a module. If so, the module
will be called i2c-versatile.
+config I2C_WMT
+ tristate "Wondermedia I2C Controller support"
+ depends on ARCH_VT8500
+ help
+ If you say yes to this option, support will be included for the
+ I2C controllers found in Wondermedia SoCs.
+
config I2C_OCTEON
tristate "Cavium OCTEON I2C bus support"
depends on CPU_CAVIUM_OCTEON
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 6181f3f..dce6299 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_I2C_SIRF)+= i2c-sirf.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
+obj-$(CONFIG_I2C_WMT) += i2c-wmt.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
obj-$(CONFIG_I2C_XILINX) += i2c-xiic.o
obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
diff --git a/drivers/i2c/busses/i2c-wmt.c b/drivers/i2c/busses/i2c-wmt.c
new file mode 100644
index 000..07d86e3
--- /dev/null
+++ b/drivers/i2c/busses/i2c-wmt.c
@@ -0,0 +1,636 @@
+/*
+ * Wondermedia I2C Master Mode Driver
+ *
+ * Copyright (C) 2012 Tony Prisk
+ *
+ * Derived from GPL licensed source:
+ * - Copyright (C) 2008 WonderMedia Technologies, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_CR 0x00
+#define REG_TCR0x02
+#define REG_CSR0x04
+#define REG_ISR0x06
+#define REG_IMR0x08
+#define REG_CDR0x0A
+#define REG_TR 0x0C
+#define REG_MCR0x0E
+#define REG_SLAVE_CR 0x10
+#define REG_SLAVE_SR 0x12
+#define REG_SLAVE_ISR 0x14
+#define REG_SLAVE_IMR 0x16
+#define REG_SLAVE_DR 0x18
+#define REG_SLAVE_TR 0x1A
+
+/* REG_CR Bit fields */
+#define CR_TX_NEXT_ACK 0x
+#define CR_ENABLE 0x0001
+#define CR_TX_NEXT_NO_ACK 0x0002
+#define CR_TX_END 0x0004
+#define CR_CPU_RDY 0x0008
+#define SLAV_MODE_SEL 0x8000
+
+/* REG_TCR Bit fields */
+#define TCR_STANDARD_MODE 0x
+#define TCR_MASTER_WRITE 0x
+#define TCR_HS_MODE0x2000
+#define TCR_MASTER_READ0x4000
+#define TCR_FAST_MODE 0x8000
+#define TCR_SLAVE_ADDR_MASK0x007F
+
+/* REG_ISR Bit fields */
+#define ISR_NACK_ADDR 0x0001
+#define ISR_BYTE_END 0x0002
+#define ISR_SCL_TIMEOUT0x0004
+#define ISR_WRITE_ALL 0x0007
+
+/* REG_IMR Bit fields */
+#define IMR_ENABLE_ALL 0x0007
+
+/* REG_CSR Bit fields */
+#define CSR_RCV_NOT_ACK0x0001
+#define CSR_RCV_ACK_MASK 0x0001
+#define CSR_READY_MASK 0x0002
+
+#define I2C_MODE_STANDARD
[PATCH] clk: vt8500: Add support for WM8750/WM8850 PLL clocks
This patch adds support for the new PLL module found in WM8750 and
WM8850 SoCs.
Signed-off-by: Tony Prisk
---
drivers/clk/clk-vt8500.c | 102 +-
1 file changed, 100 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index fe25570..d3fefa4 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -41,6 +41,7 @@ struct clk_device {
#define PLL_TYPE_VT85000
#define PLL_TYPE_WM86501
+#define PLL_TYPE_WM87502
struct clk_pll {
struct clk_hw hw;
@@ -298,6 +299,16 @@ static __init void vtwm_device_clk_init(struct device_node
*node)
#define WM8650_BITS_TO_VAL(m, d1, d2) \
((d2 << 13) | (d1 << 10) | (m & 0x3FF))
+/* Helper macros for PLL_WM8750 */
+#define WM8750_PLL_MUL(x) (((x >> 16) & 0xFF) + 1)
+#define WM8750_PLL_DIV(x) x >> 8) & 1) + 1) * (1 << (x & 7)))
+
+#define WM8750_BITS_TO_FREQ(r, m, d1, d2) \
+ (r * (m+1) / ((d1+1) * (1 << d2)))
+
+#define WM8750_BITS_TO_VAL(f, m, d1, d2) \
+ ((f << 24) | ((m - 1) << 16) | ((d1 - 1) << 8) | d2)
+
static void vt8500_find_pll_bits(unsigned long rate, unsigned long parent_rate,
u32 *multiplier, u32 *prediv)
@@ -366,11 +377,82 @@ static void wm8650_find_pll_bits(unsigned long rate,
unsigned long parent_rate,
*divisor2 = div2;
}
+static u32 wm8750_get_filter(u32 parent_rate, u32 divisor1)
+{
+ /* calculate frequency (MHz) after pre-divisor */
+ u32 freq = (parent_rate / 100) / (divisor1 + 1);
+
+ if ((freq < 10) || (freq > 200))
+ pr_warn("%s: PLL recommended input frequency 10..200Mhz
(requested %d Mhz)\n",
+ __func__, freq);
+
+ if (freq >= 166)
+ return 7;
+ else if (freq >= 104)
+ return 6;
+ else if (freq >= 65)
+ return 5;
+ else if (freq >= 42)
+ return 4;
+ else if (freq >= 26)
+ return 3;
+ else if (freq >= 16)
+ return 2;
+ else if (freq >= 10)
+ return 1;
+
+ return 0;
+}
+
+static void wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
+ u32 *filter, u32 *multiplier, u32 *divisor1,
u32 *divisor2)
+{
+ u32 mul, div1, div2;
+ u32 best_mul, best_div1, best_div2;
+ unsigned long tclk, rate_err, best_err;
+
+ best_err = (unsigned long)-1;
+
+ /* Find the closest match (lower or equal to requested) */
+ for (div1 = 1; div1 >= 0; div1--)
+ for (div2 = 7; div2 >= 0; div2--)
+ for (mul = 0; mul <= 255; mul++) {
+ tclk = parent_rate * (mul + 1) / ((div1 + 1) *
(1 << div2));
+ if (tclk > rate)
+ continue;
+ /* error will always be +ve */
+ rate_err = rate - tclk;
+ if (rate_err == 0) {
+ *filter =
wm8750_get_filter(parent_rate, div1);
+ *multiplier = mul;
+ *divisor1 = div1;
+ *divisor2 = div2;
+ return;
+ }
+
+ if (rate_err < best_err) {
+ best_err = rate_err;
+ best_mul = mul;
+ best_div1 = div1;
+ best_div2 = div2;
+ }
+ }
+
+ /* if we got here, it wasn't an exact match */
+ pr_warn("%s: requested rate %lu, found rate %lu\n", __func__, rate,
+ rate - best_err);
+
+ *filter = wm8750_get_filter(parent_rate, best_div1);
+ *multiplier = best_mul;
+ *divisor1 = best_div1;
+ *divisor2 = best_div2;
+}
+
static int vtwm_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct clk_pll *pll = to_clk_pll(hw);
- u32 mul, div1, div2;
+ u32 filter, mul, div1, div2;
u32 pll_val;
unsigned long flags = 0;
@@ -385,6 +467,9 @@ static int vtwm_pll_set_rate(struct clk_hw *hw, unsigned
long rate,
wm8650_find_pll_bits(rate, parent_rate, , , );
pll_val = WM8650_BITS_TO_VAL(mul, div1, div2);
break;
+ case PLL_TYPE_WM8750:
+ wm8750_find_pll_bits(rate, parent_rate, , , ,
);
+
Re: [PATCH V3 8/8] memcg: Document cgroup dirty/writeback memory statistics
(2012/12/26 2:28), Sha Zhengju wrote: > From: Sha Zhengju > > Signed-off-by: Sha Zhengju I don't think your words are bad but it may be better to sync with meminfo's text. > --- > Documentation/cgroups/memory.txt |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/cgroups/memory.txt > b/Documentation/cgroups/memory.txt > index addb1f1..2828164 100644 > --- a/Documentation/cgroups/memory.txt > +++ b/Documentation/cgroups/memory.txt > @@ -487,6 +487,8 @@ pgpgin- # of charging events to the memory > cgroup. The charging > pgpgout - # of uncharging events to the memory cgroup. The > uncharging > event happens each time a page is unaccounted from the cgroup. > swap- # of bytes of swap usage > +dirty - # of bytes of file cache that are not in sync with the disk > copy. > +writeback - # of bytes of file/anon cache that are queued for syncing > to disk. > inactive_anon - # of bytes of anonymous memory and swap cache memory > on > LRU list. > active_anon - # of bytes of anonymous and swap cache memory on active > Documentation/filesystems/proc.txt Dirty: Memory which is waiting to get written back to the disk Writeback: Memory which is actively being written back to the disk even if others are not ;( Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, realmode: set real_mode permissions early
Seems ok. Yinghai Lu wrote: >On Thu, Dec 27, 2012 at 4:01 PM, H. Peter Anvin wrote: >> On 12/27/2012 03:56 PM, Yinghai Lu wrote: I'm looking at this patch in the -v8 branch: you need to update the comment above that function to say that trampoline code needs to be marked X now earlier. >>> >>> >>> Not sure if we really need to add such comment in the code. >>> >>> Peter, what is your idea about this? >>> >> >> It would be good to note why the early_initcall is the right phase. >> > >How about: > >--- >Trampoline will be executed by APs with SMP, >So we need to set it EXEC in do_pre_smp_initcalls and it is >early_initcall. >--- -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad magic number and
Hi... On Wed, Dec 26, 2012 at 12:19 PM, sham pavman wrote: > > mkfs -t ext4 /dev/sdb > mke2fs 1.42 (29-Nov-2011) try using mkfs.ext4 instead -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 7/8] memcg: disable memcg page stat accounting code when not in use
(2012/12/26 2:27), Sha Zhengju wrote: > From: Sha Zhengju > > It's inspired by a similar optimization from Glauber Costa > (memcg: make it suck faster; https://lkml.org/lkml/2012/9/25/154). > Here we use jump label to patch the memcg page stat accounting code > in or out when not used. when the first non-root memcg comes to > life the code is patching in otherwise it is out. > > Signed-off-by: Sha Zhengju Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.8-rc1 (mei driver BROKEN)
Hi Linus, I am not sure if Greg is on holidays as his char-misc GIT tree didn't get updated the last days. The MEI driver causes here a serious regression requiring a hard cold start of the machine I am working on. A fix "mei: fix mismatch in mutex unlock-lock in mei_amthif_read()" was already sent to LKML [1] and fixes the issue for me. Can you push that a bit? Feel free to add any credits. Regards, - Sedat - [1] https://patchwork.kernel.org/patch/1904801/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 6/8] memcg: Don't account root_mem_cgroup page statistics
(2012/12/26 2:27), Sha Zhengju wrote: > From: Sha Zhengju > > If memcg is enabled and no non-root memcg exists, all allocated pages > belongs to root_mem_cgroup and go through root memcg statistics routines > which brings some overheads. So for the sake of performance, we can give > up accounting stats of root memcg for MEM_CGROUP_STAT_FILE_MAPPED/FILE_DIRTY > /WRITEBACK and instead we pay special attention while showing root > memcg numbers in memcg_stat_show(): as we don't account root memcg stats > anymore, the root_mem_cgroup->stat numbers are actually 0. But because of > hierachy, figures of root_mem_cgroup may just represent numbers of pages > used by its own tasks(not belonging to any other child cgroup). So here we > fake these root numbers by using stats of global state and all other memcg. > That is for root memcg: > nr(MEM_CGROUP_STAT_FILE_MAPPED) = global_page_state(NR_FILE_MAPPED) - >sum_of_all_memcg(MEM_CGROUP_STAT_FILE_MAPPED); > Dirty/Writeback pages accounting are in the similar way. > > Signed-off-by: Sha Zhengju isn't it better to use mem_cgroup_is_root() call rather than direct comparison (memcg == root_mem_cgroup) ? Anyway, Ack to this approach. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, realmode: set real_mode permissions early
On Thu, Dec 27, 2012 at 4:01 PM, H. Peter Anvin wrote: > On 12/27/2012 03:56 PM, Yinghai Lu wrote: >>> >>> >>> I'm looking at this patch in the -v8 branch: you need to update the >>> comment above that function to say that trampoline code needs to be >>> marked X now earlier. >> >> >> Not sure if we really need to add such comment in the code. >> >> Peter, what is your idea about this? >> > > It would be good to note why the early_initcall is the right phase. > How about: --- Trampoline will be executed by APs with SMP, So we need to set it EXEC in do_pre_smp_initcalls and it is early_initcall. --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On Fri, Dec 28, 2012 at 1:42 AM, Zlatko Calusic wrote: > On 28.12.2012 01:37, Sedat Dilek wrote: >> >> On Fri, Dec 28, 2012 at 1:33 AM, Zlatko Calusic >> wrote: >>> >>> On 28.12.2012 01:24, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic wrote: > > > On 28.12.2012 00:42, Sedat Dilek wrote: >> >> >> >> On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic >> wrote: >>> >>> >>> >>> On 28.12.2012 00:30, Sedat Dilek wrote: Hi Zlatko, I am not sure if I hit the same problem as described in this thread. Under heavy load, while building a customized toolchain for the Freetz router project I got a BUG || NULL pointer derefence || kswapd || zone_balanced || pgdat_balanced() etc. (details see my screenshot). I will try your patch from [1] ***only*** on top of my last Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). >>> >>> Yes, that's the same bug. It should be fixed with my latest patch, so >>> I'd >>> appreciate you testing it, to be on the safe side this time. There >>> should >>> be >>> no difference if you apply it to anything newer than 3.8-rc1, so go >>> for >>> it. >>> Thanks! >>> >> >> Not sure how I can really reproduce this bug as one build worked fine >> within my last v3.8-rc1 kernel. >> I increased the parallel-make-jobs-number from "4" to "8" to stress a >> bit harder. >> Just building right now... and will report. >> >> If you have any test-case (script or whatever), please let me/us know. >> > > Unfortunately not, I haven't reproduced it yet on my machines. But it > seems > that bug will hit only under heavy memory pressure. When close to OOM, > or > possibly with lots of writing to disk. It's also possible that > fragmentation > of memory zones could provoke it, that means testing it for a longer > time. > I tested successfully by doing simultaneously... - building Freetz with 8 parallel make-jobs - building Linux GIT with 1 make-job - 9 tabs open in firefox - In one tab I ran YouTube music video - etc. I am reading [1] and [2] where another user reports success by reverting this... commit cda73a10eb3f493871ed39f468db50a65ebeddce "mm: do not sleep in balance_pgdat if there's no i/o congestion" BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64). Feel free to add a "Reported-by/Tested-by" if you think this is a positive report. >>> >>> Thanks for the testing! And keep running it in case something interesting >>> pops up. ;) >>> >>> No need to revert cda73a10eb because it fixes another bug. And the patch >>> you're now running fixes the new bug I introduced with a combination of >>> my >>> latest 2 patches. Nah, it gets complicated... :) >>> >>> But, at least I found the culprit and as soon as Linus applies the fix, >>> everything will be hunky dory again, at least on this front. :P >>> >> >> I am not subscribed to LKML and linux-mm,,, >> Do you have a patch with a proper subject and descriptive text? URL? >> > > Soon to follow. I'd appreciate Zhouping Liu testing it too, though. I understand, but I want to push your patch with a proper subject-line as a pending patch with reference to patchwork, so... - Sedat - > -- > Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On 28.12.2012 01:37, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 1:33 AM, Zlatko Calusic wrote: On 28.12.2012 01:24, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic wrote: On 28.12.2012 00:42, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic wrote: On 28.12.2012 00:30, Sedat Dilek wrote: Hi Zlatko, I am not sure if I hit the same problem as described in this thread. Under heavy load, while building a customized toolchain for the Freetz router project I got a BUG || NULL pointer derefence || kswapd || zone_balanced || pgdat_balanced() etc. (details see my screenshot). I will try your patch from [1] ***only*** on top of my last Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). Yes, that's the same bug. It should be fixed with my latest patch, so I'd appreciate you testing it, to be on the safe side this time. There should be no difference if you apply it to anything newer than 3.8-rc1, so go for it. Thanks! Not sure how I can really reproduce this bug as one build worked fine within my last v3.8-rc1 kernel. I increased the parallel-make-jobs-number from "4" to "8" to stress a bit harder. Just building right now... and will report. If you have any test-case (script or whatever), please let me/us know. Unfortunately not, I haven't reproduced it yet on my machines. But it seems that bug will hit only under heavy memory pressure. When close to OOM, or possibly with lots of writing to disk. It's also possible that fragmentation of memory zones could provoke it, that means testing it for a longer time. I tested successfully by doing simultaneously... - building Freetz with 8 parallel make-jobs - building Linux GIT with 1 make-job - 9 tabs open in firefox - In one tab I ran YouTube music video - etc. I am reading [1] and [2] where another user reports success by reverting this... commit cda73a10eb3f493871ed39f468db50a65ebeddce "mm: do not sleep in balance_pgdat if there's no i/o congestion" BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64). Feel free to add a "Reported-by/Tested-by" if you think this is a positive report. Thanks for the testing! And keep running it in case something interesting pops up. ;) No need to revert cda73a10eb because it fixes another bug. And the patch you're now running fixes the new bug I introduced with a combination of my latest 2 patches. Nah, it gets complicated... :) But, at least I found the culprit and as soon as Linus applies the fix, everything will be hunky dory again, at least on this front. :P I am not subscribed to LKML and linux-mm,,, Do you have a patch with a proper subject and descriptive text? URL? Soon to follow. I'd appreciate Zhouping Liu testing it too, though. -- Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/11] xen: Initial kexec/kdump implementation
> Andrew Cooper writes: > > > On 27/12/2012 07:53, Eric W. Biederman wrote: > >> The syscall ABI still has the wrong semantics. > >> > >> Aka totally unmaintainable and umergeable. > >> > >> The concept of domU support is also strange. What does domU support even > >> mean, when the dom0 > support is loading a kernel to pick up Xen when Xen > >> falls over. > > > > There are two requirements pulling at this patch series, but I agree > > that we need to clarify them. > > It probably make sense to split them apart a little even. > > > When dom0 loads a crash kernel, it is loading one for Xen to use. As a > > dom0 crash causes a Xen crash, having dom0 set up a kdump kernel for > > itself is completely useless. This ability is present in "classic Xen > > dom0" kernels, but the feature is currently missing in PVOPS. > > > Many cloud customers and service providers want the ability for a VM > > administrator to be able to load a kdump/kexec kernel within a > > domain[1]. This allows the VM administrator to take more proactive > > steps to isolate the cause of a crash, the state of which is most likely > > discarded while tearing down the domain. The result being that as far > > as Xen is concerned, the domain is still alive, while the kdump > > kernel/environment can work its usual magic. I am not aware of any > > feature like this existing in the past. > > Which makes domU support semantically just the normal kexec/kdump > support. Got it. To some extent. It is true on HVM and PVonHVM guests. However, PV guests requires a bit different kexec/kdump implementation than plain kexec/kdump. Proposed firmware support has almost all required features. PV guest specific features (a few) will be added later (after agreeing generic firmware support which is sufficient at least for dom0). It looks that I should replace domU by PV guest in patch description. > The point of implementing domU is for those times when the hypervisor > admin and the kernel admin are different. Right. > For domU support modifying or adding alternate versions of > machine_kexec.c and relocate_kernel.S to add paravirtualization support > make sense. It is not sufficient. Please look above. > There is the practical argument that for implementation efficiency of > crash dumps it would be better if that support came from the hypervisor > or the hypervisor environment. But this gets into the practical reality I am thinking about that. > that the hypervisor environment does not do that today. Furthermore > kexec all by itself working in a paravirtualized environment under Xen > makes sense. > > domU support is what Peter was worrying about for cleanliness, and > we need some x86 backend ops there, and generally to be careful. As I know we do not need any additional pv_ops stuff if we place all needed things in kexec firmware support. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 5/8] memcg: add per cgroup writeback pages accounting
(2012/12/26 2:26), Sha Zhengju wrote: > From: Sha Zhengju > > Similar to dirty page, we add per cgroup writeback pages accounting. The lock > rule still is: > mem_cgroup_begin_update_page_stat() > modify page WRITEBACK stat > mem_cgroup_update_page_stat() > mem_cgroup_end_update_page_stat() > > There're two writeback interface to modify: test_clear/set_page_writeback. > > Signed-off-by: Sha Zhengju Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] f2fs: add missing pretech.h include
2012-12-27 (목), 15:34 +0100, Heiko Carstens: > On Thu, Dec 27, 2012 at 03:30:32PM +0100, Heiko Carstens wrote: > > From aa027f06dfb5b2fd27d6f92391d8340df671e82b Mon Sep 17 00:00:00 2001 > > From: Heiko Carstens > > Date: Thu, 27 Dec 2012 15:22:27 +0100 > > Subject: [PATCH] f2fs: add missing pretech.h include > > That should have been "prefetch.h", obviously... > At least the patch is correct. Hi, This was fixed by Geert Uytterhoeven before. I'm supposed to push other bug fixes with this to linus today. Anyway, thank you very much. :) -- Jaegeuk Kim Samsung signature.asc Description: This is a digitally signed message part
[ANNOUNCE] Git v1.8.0.3
The latest maintenance release Git v1.8.0.3 is now available at the usual places. This is primarily to down-merge documentation updates that have been accumulating to the 'master' front for the upcoming 1.8.1 to the maintenance series. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: b1695f28448c00e61e110b3c7bcd66c8047ef176 git-1.8.0.3.tar.gz 83c46b62e0c3979c5ef77a407ca41507658b5726 git-htmldocs-1.8.0.3.tar.gz 63df55f90b9c6c11dd827ce1880b5b5fdf79c1c1 git-manpages-1.8.0.3.tar.gz Also the following public repositories all have a copy of the v1.8.0.3 tag and the maint branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.0.3 Release Notes == Fixes since v1.8.0.2 * "git log -p -S" did not apply the textconv filter while looking for the . * In the documentation, some invalid example e-mail addresses were formatted into mailto: links. Also contains many documentation updates backported from the 'master' branch that is preparing for the upcoming 1.8.1 release. Changes since v1.8.0.2 are as follows: Adam Spiers (2): SubmittingPatches: add convention of prefixing commit messages Documentation: move support for old compilers to CodingGuidelines Anders Kaseorg (1): git-prompt: Document GIT_PS1_DESCRIBE_STYLE Chris Rorvick (2): Documentation/git-checkout.txt: clarify usage Documentation/git-checkout.txt: document 70c9ac2 behavior Gunnlaugur Þór Briem (1): Document git-svn fetch --log-window-size parameter Jeff King (7): pickaxe: hoist empty needle check pickaxe: use textconv for -S counting .mailmap: match up some obvious names/emails .mailmap: fix broken entry for Martin Langhoff .mailmap: normalize emails for Jeff King .mailmap: normalize emails for Linus Torvalds contrib: update stats/mailmap script John Keeping (1): Documentation: don't link to example mail addresses Junio C Hamano (6): fetch --tags: clarify documentation README: it does not matter who the current maintainer is t7004: do not create unneeded gpghome/gpg.conf when GPG is not used Documentation: Describe "git diff " separately git(1): show link to contributor summary page Git 1.8.0.3 Krzysztof Mazur (1): doc: git-reset: make "" optional Manlio Perillo (1): git.txt: add missing info about --git-dir command-line option Matthew Daley (1): Fix sizeof usage in get_permutations Max Horn (1): git-remote-helpers.txt: document invocation before input format Nguyễn Thái Ngọc Duy (1): index-format.txt: clarify what is "invalid" Ramkumar Ramachandra (1): Documentation: move diff.wordRegex from config.txt to diff-config.txt Sebastian Leske (4): git-svn: Document branches with at-sign(@). git-svn: Recommend use of structure options. git-svn: Expand documentation for --follow-parent git-svn: Note about tags. Sitaram Chamarty (1): clarify -M without % symbol in diff-options Stefano Lattarini (1): README: Git is released under the GPLv2, not just "the GPL" Thomas Ackermann (8): Split over-long synopsis in git-fetch-pack.txt into several lines Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1 Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt Documentation/technical: convert plain text files to asciidoc Documentation/howto: convert plain text files to asciidoc Documentation: build html for all files in technical and howto Remove misleading date from api-index-skel.txt Sort howto documents in howto-index.txt Tom Jones (1): Add -S, --gpg-sign option to manpage of "git commit" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/8] use vfs __set_page_dirty interface instead of doing it inside filesystem
(2012/12/26 2:24), Sha Zhengju wrote: > From: Sha Zhengju > > Following we will treat SetPageDirty and dirty page accounting as an > integrated > operation. Filesystems had better use vfs interface directly to avoid those > details. > > Signed-off-by: Sha Zhengju > Acked-by: Sage Weil Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/8] Make TestSetPageDirty and dirty page accounting in one func
(2012/12/26 2:22), Sha Zhengju wrote: > From: Sha Zhengju > > Commit a8e7d49a(Fix race in create_empty_buffers() vs > __set_page_dirty_buffers()) > extracts TestSetPageDirty from __set_page_dirty and is far away from > account_page_dirtied. But it's better to make the two operations in one single > function to keep modular. So in order to avoid the potential race mentioned in > commit a8e7d49a, we can hold private_lock until __set_page_dirty completes. > There's no deadlock between ->private_lock and ->tree_lock after confirmation. > It's a prepare patch for following memcg dirty page accounting patches. > > > Here is some test numbers that before/after this patch: > Test steps(Mem-4g, ext4): > drop_cache; sync > fio > (ioengine=sync/write/buffered/bs=4k/size=1g/numjobs=2/group_reporting/thread) > > We test it for 10 times and get the average numbers: > Before: > write: io=2048.0MB, bw=254117KB/s, iops=63528.9 , runt= 8279msec > lat (usec): min=1 , max=742361 , avg=30.918, stdev=1601.02 > After: > write: io=2048.0MB, bw=254044KB/s, iops=63510.3 , runt= 8274.4msec > lat (usec): min=1 , max=856333 , avg=31.043, stdev=1769.32 > > Note that the impact is little(<1%). > > > Signed-off-by: Sha Zhengju > Reviewed-by: Michal Hocko Acked-by: KAMEZAWA Hiroyuki Hmm,..this change should be double-checked by vfs, I/O guys... increasing hold time of mapping->private_lock doesn't affect performance ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On Fri, Dec 28, 2012 at 1:33 AM, Zlatko Calusic wrote: > On 28.12.2012 01:24, Sedat Dilek wrote: >> >> On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic >> wrote: >>> >>> On 28.12.2012 00:42, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic wrote: > > > On 28.12.2012 00:30, Sedat Dilek wrote: >> >> >> >> Hi Zlatko, >> >> I am not sure if I hit the same problem as described in this thread. >> >> Under heavy load, while building a customized toolchain for the Freetz >> router project I got a BUG || NULL pointer derefence || kswapd || >> zone_balanced || pgdat_balanced() etc. (details see my screenshot). >> >> I will try your patch from [1] ***only*** on top of my last >> Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). >> > > Yes, that's the same bug. It should be fixed with my latest patch, so > I'd > appreciate you testing it, to be on the safe side this time. There > should > be > no difference if you apply it to anything newer than 3.8-rc1, so go for > it. > Thanks! > Not sure how I can really reproduce this bug as one build worked fine within my last v3.8-rc1 kernel. I increased the parallel-make-jobs-number from "4" to "8" to stress a bit harder. Just building right now... and will report. If you have any test-case (script or whatever), please let me/us know. >>> >>> Unfortunately not, I haven't reproduced it yet on my machines. But it >>> seems >>> that bug will hit only under heavy memory pressure. When close to OOM, or >>> possibly with lots of writing to disk. It's also possible that >>> fragmentation >>> of memory zones could provoke it, that means testing it for a longer >>> time. >>> >> >> I tested successfully by doing simultaneously... >> - building Freetz with 8 parallel make-jobs >> - building Linux GIT with 1 make-job >> - 9 tabs open in firefox >> - In one tab I ran YouTube music video >> - etc. >> >> I am reading [1] and [2] where another user reports success by reverting >> this... >> >> commit cda73a10eb3f493871ed39f468db50a65ebeddce >> "mm: do not sleep in balance_pgdat if there's no i/o congestion" >> >> BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64). >> >> Feel free to add a "Reported-by/Tested-by" if you think this is a >> positive report. >> > > Thanks for the testing! And keep running it in case something interesting > pops up. ;) > > No need to revert cda73a10eb because it fixes another bug. And the patch > you're now running fixes the new bug I introduced with a combination of my > latest 2 patches. Nah, it gets complicated... :) > > But, at least I found the culprit and as soon as Linus applies the fix, > everything will be hunky dory again, at least on this front. :P > I am not subscribed to LKML and linux-mm,,, Do you have a patch with a proper subject and descriptive text? URL? - Sedat - > Thanks, > -- > Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, mm: add generic kernel/ident mapping helper
On Thu, Dec 27, 2012 at 10:51 AM, Borislav Petkov wrote:
>> +struct mapping_info {
>> + void *(*alloc)(void *);
>
> alloc_page
alloc_page make me feel that it will return struct page *.
>
>> + void *data;
>> + unsigned long flag;
>
> page_flags;
will change to pmd_flags
>
>> + bool kernel;
>
> kernel_space?
that is used to tell: if it is kernel mapping or ident mapping.
will change to is_kernel_mapping or kernel_mapping instead
>
> In general, all those members could use more meaningful names and some
> commenting explaining what they are, instead of people having to deduce
> what they mean from their usage in the code.
>
> Also, struct name 'mapping_info' is too generic. Maybe
> ident_mapping_info?
do you like to name it with kernel_ident_mapping_info ?
looks too long.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On 28.12.2012 01:24, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic wrote: On 28.12.2012 00:42, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic wrote: On 28.12.2012 00:30, Sedat Dilek wrote: Hi Zlatko, I am not sure if I hit the same problem as described in this thread. Under heavy load, while building a customized toolchain for the Freetz router project I got a BUG || NULL pointer derefence || kswapd || zone_balanced || pgdat_balanced() etc. (details see my screenshot). I will try your patch from [1] ***only*** on top of my last Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). Yes, that's the same bug. It should be fixed with my latest patch, so I'd appreciate you testing it, to be on the safe side this time. There should be no difference if you apply it to anything newer than 3.8-rc1, so go for it. Thanks! Not sure how I can really reproduce this bug as one build worked fine within my last v3.8-rc1 kernel. I increased the parallel-make-jobs-number from "4" to "8" to stress a bit harder. Just building right now... and will report. If you have any test-case (script or whatever), please let me/us know. Unfortunately not, I haven't reproduced it yet on my machines. But it seems that bug will hit only under heavy memory pressure. When close to OOM, or possibly with lots of writing to disk. It's also possible that fragmentation of memory zones could provoke it, that means testing it for a longer time. I tested successfully by doing simultaneously... - building Freetz with 8 parallel make-jobs - building Linux GIT with 1 make-job - 9 tabs open in firefox - In one tab I ran YouTube music video - etc. I am reading [1] and [2] where another user reports success by reverting this... commit cda73a10eb3f493871ed39f468db50a65ebeddce "mm: do not sleep in balance_pgdat if there's no i/o congestion" BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64). Feel free to add a "Reported-by/Tested-by" if you think this is a positive report. Thanks for the testing! And keep running it in case something interesting pops up. ;) No need to revert cda73a10eb because it fixes another bug. And the patch you're now running fixes the new bug I introduced with a combination of my latest 2 patches. Nah, it gets complicated... :) But, at least I found the culprit and as soon as Linus applies the fix, everything will be hunky dory again, at least on this front. :P Thanks, -- Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined
(2012/12/27 21:16), Wen Congyang wrote: > At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote: >> (2012/12/24 21:09), Tang Chen wrote: >>> From: Wen Congyang >>> >>> We call hotadd_new_pgdat() to allocate memory to store node_data. So we >>> should free it when removing a node. >>> >>> Signed-off-by: Wen Congyang >> >> I'm sorry but is it safe to remove pgdat ? All zone cache and zonelists are >> properly cleared/rebuilded in synchronous way ? and No threads are visinting >> zone in vmscan.c ? > > We have rebuilt zonelists when a zone has no memory after offlining some > pages. > How do you guarantee that the address of pgdat/zone is not on stack of any kernel threads or other kernel objects without reference counting or other syncing method ? Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v4 0/3] Support volatile for anonymous range
(2012/12/26 12:46), Minchan Kim wrote: Hi Kame, What are you doing these holiday season? :) I can't believe you sit down in front of computer. Honestly, my holiday starts tomorrow ;) (but until 1/5 in the next year.) Hm, by the way, the user need to attach pages to the process by causing page-fault (as you do by memset()) before calling mvolatile() ? For effectiveness, Yes. Isn't it better to make page-fault by get_user_pages() in mvolatile() ? Calling page fault in userland seems just to increase burden of apps. I think your approach is interesting, anyway. Thanks for your interest, Kame. あけましておめでとう. A happy new year. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
Hi, NOTE to everyone debugging this: reproduced quickly with X + firefox + youtube (adobe flash plugin) > Would you be so kind to test the following patch and report results? > Apply the patch to the latest mainline. I've had probably the same problem (dmesg below) and currently am trying your patch applied to current mainline (101e5c7470eb7f). so far it looks very good. (before: bug after 5-30 minutes, right now 1h and counting) thanks! [ 105.164610] [ cut here ] [ 105.164614] kernel BUG at mm/huge_memory.c:1798! [ 105.164617] invalid opcode: [#1] PREEMPT SMP [ 105.164621] Modules linked in: fuse sha256_generic xt_owner xt_LOG xt_limit xt_recent xt_conntrack xt_multiport iptable_mangle xt_DSCP iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack fbcon font bitblit softcursor fb fbdev hwmon_vid btrfs zlib_deflate zlib_inflate xfs libcrc32c snd_usb_audio uvcvideo snd_usbmidi_lib videobuf2_core snd_rawmidi videobuf2_vmalloc videobuf2_memops hid_kensington iTCO_wdt joydev gpio_ich iTCO_vendor_support raid1 fglrx(PO) coretemp kvm_intel kvm skge acpi_cpufreq lpc_ich serio_raw asus_atk0110 snd_hda_codec_hdmi intel_agp snd_hda_intel mperf intel_gtt processor snd_hda_codec sky2 agpgart snd_hwdep [last unloaded: iTCO_wdt] [ 105.164672] CPU 1 [ 105.164677] Pid: 4091, comm: XPCOM CC Tainted: P O 3.8.0-rc1+ #43 System manufacturer System Product Name/P5B-Deluxe [ 105.164679] RIP: 0010:[] [] __split_huge_page+0x216/0x240 [ 105.164688] RSP: 0018:880091511c48 EFLAGS: 00010297 [ 105.164690] RAX: 0001 RBX: 8800a210c000 RCX: 0042 [ 105.164692] RDX: 00cb RSI: 0046 RDI: 81b28a20 [ 105.164694] RBP: 880091511ca8 R08: R09: [ 105.164696] R10: 043d R11: 0001 R12: 8800a2295c60 [ 105.164698] R13: ea00021e R14: R15: 0007f5134600 [ 105.164701] FS: 7f514991e700() GS:8800bfc8() knlGS: [ 105.164703] CS: 0010 DS: ES: CR0: 8005003b [ 105.164705] CR2: 7f5123bff000 CR3: 9531b000 CR4: 07e0 [ 105.164707] DR0: DR1: DR2: [ 105.164709] DR3: DR6: 0ff0 DR7: 0400 [ 105.164712] Process XPCOM CC (pid: 4091, threadinfo 88009151, task 8800953616b0) [ 105.164713] Stack: [ 105.164715] 8800 8800b9c834b0 7f513480 8158c4a5 [ 105.164719] 8800a210c064 7f513460 880091511ca8 ea00021e [ 105.164723] 8800b9c83480 8800a210c000 88009fdc1d18 8800a210c064 [ 105.164727] Call Trace: [ 105.164732] [] split_huge_page+0x68/0xb0 [ 105.164736] [] __split_huge_page_pmd+0x1a8/0x220 [ 105.164740] [] unmap_page_range+0x1b6/0x2d0 [ 105.164744] [] unmap_single_vma+0x5b/0xe0 [ 105.164747] [] zap_page_range+0xbc/0x120 [ 105.164752] [] ? futex_wake+0x116/0x130 [ 105.164756] [] ? pick_next_task_fair+0x36/0xb0 [ 105.164760] [] madvise_vma+0xf7/0x140 [ 105.164764] [] ? find_vma_prev+0x12/0x60 [ 105.164767] [] sys_madvise+0x23d/0x330 [ 105.164772] [] system_call_fastpath+0x16/0x1b [ 105.164774] Code: 48 89 df e8 ed 10 ff ff e9 ab fe ff ff 0f 0b 41 8b 55 18 8b 75 bc ff c2 48 c7 c7 38 0e 7d 81 31 c0 e8 13 9b 46 00 e9 15 ff ff ff <0f> 0b 41 8b 4d 18 89 da ff c1 8b 75 bc 48 c7 c7 58 0e 7d 81 31 [ 105.164814] RIP [] __split_huge_page+0x216/0x240 [ 105.164818] RSP [ 105.164823] ---[ end trace 00c060fd7d17a3d4 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic wrote: > On 28.12.2012 00:42, Sedat Dilek wrote: >> >> On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic >> wrote: >>> >>> On 28.12.2012 00:30, Sedat Dilek wrote: Hi Zlatko, I am not sure if I hit the same problem as described in this thread. Under heavy load, while building a customized toolchain for the Freetz router project I got a BUG || NULL pointer derefence || kswapd || zone_balanced || pgdat_balanced() etc. (details see my screenshot). I will try your patch from [1] ***only*** on top of my last Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). >>> >>> Yes, that's the same bug. It should be fixed with my latest patch, so I'd >>> appreciate you testing it, to be on the safe side this time. There should >>> be >>> no difference if you apply it to anything newer than 3.8-rc1, so go for >>> it. >>> Thanks! >>> >> >> Not sure how I can really reproduce this bug as one build worked fine >> within my last v3.8-rc1 kernel. >> I increased the parallel-make-jobs-number from "4" to "8" to stress a >> bit harder. >> Just building right now... and will report. >> >> If you have any test-case (script or whatever), please let me/us know. >> > > Unfortunately not, I haven't reproduced it yet on my machines. But it seems > that bug will hit only under heavy memory pressure. When close to OOM, or > possibly with lots of writing to disk. It's also possible that fragmentation > of memory zones could provoke it, that means testing it for a longer time. > I tested successfully by doing simultaneously... - building Freetz with 8 parallel make-jobs - building Linux GIT with 1 make-job - 9 tabs open in firefox - In one tab I ran YouTube music video - etc. I am reading [1] and [2] where another user reports success by reverting this... commit cda73a10eb3f493871ed39f468db50a65ebeddce "mm: do not sleep in balance_pgdat if there's no i/o congestion" BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64). Feel free to add a "Reported-by/Tested-by" if you think this is a positive report. - Sedat - [1] http://marc.info/?l=linux-mm=135652835931174=2 [2] http://marc.info/?l=linux-mm=135653399800655=2 > -- > Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] regulator: lp3972: Convert to get_voltage_sel
regulator_list_voltage_table() returns -EINVAL if selector >= n_voltages.
Thus we don't need to check if reg is greater than LP3972_BUCK_VOL_MAX_IDX in
lp3972_[ldo|dcdc]_get_voltage_sel.
LP3972_BUCK_VOL_MIN_IDX and LP3972_BUCK_VOL_MAX_IDX are not used, remove them.
Signed-off-by: Axel Lin
---
Hi Mark,
This patch was sent on https://lkml.org/lkml/2012/12/10/283 ,
and you replied it's applied.
But it seems not (yet) in regulator tree, so I resend it.
Axel
drivers/regulator/lp3972.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/regulator/lp3972.c b/drivers/regulator/lp3972.c
index 69c42c3..0baabcf 100644
--- a/drivers/regulator/lp3972.c
+++ b/drivers/regulator/lp3972.c
@@ -165,8 +165,6 @@ static const int buck_base_addr[] = {
#define LP3972_BUCK_VOL_ENABLE_REG(x) (buck_vol_enable_addr[x])
#define LP3972_BUCK_VOL1_REG(x) (buck_base_addr[x])
#define LP3972_BUCK_VOL_MASK 0x1f
-#define LP3972_BUCK_VOL_MIN_IDX(x) ((x) ? 0x01 : 0x00)
-#define LP3972_BUCK_VOL_MAX_IDX(x) ((x) ? 0x19 : 0x1f)
static int lp3972_i2c_read(struct i2c_client *i2c, char reg, int count,
u16 *dest)
@@ -257,7 +255,7 @@ static int lp3972_ldo_disable(struct regulator_dev *dev)
mask, 0);
}
-static int lp3972_ldo_get_voltage(struct regulator_dev *dev)
+static int lp3972_ldo_get_voltage_sel(struct regulator_dev *dev)
{
struct lp3972 *lp3972 = rdev_get_drvdata(dev);
int ldo = rdev_get_id(dev) - LP3972_LDO1;
@@ -267,7 +265,7 @@ static int lp3972_ldo_get_voltage(struct regulator_dev *dev)
reg = lp3972_reg_read(lp3972, LP3972_LDO_VOL_CONTR_REG(ldo));
val = (reg >> LP3972_LDO_VOL_CONTR_SHIFT(ldo)) & mask;
- return dev->desc->volt_table[val];
+ return val;
}
static int lp3972_ldo_set_voltage_sel(struct regulator_dev *dev,
@@ -314,7 +312,7 @@ static struct regulator_ops lp3972_ldo_ops = {
.is_enabled = lp3972_ldo_is_enabled,
.enable = lp3972_ldo_enable,
.disable = lp3972_ldo_disable,
- .get_voltage = lp3972_ldo_get_voltage,
+ .get_voltage_sel = lp3972_ldo_get_voltage_sel,
.set_voltage_sel = lp3972_ldo_set_voltage_sel,
};
@@ -353,24 +351,16 @@ static int lp3972_dcdc_disable(struct regulator_dev *dev)
return val;
}
-static int lp3972_dcdc_get_voltage(struct regulator_dev *dev)
+static int lp3972_dcdc_get_voltage_sel(struct regulator_dev *dev)
{
struct lp3972 *lp3972 = rdev_get_drvdata(dev);
int buck = rdev_get_id(dev) - LP3972_DCDC1;
u16 reg;
- int val;
reg = lp3972_reg_read(lp3972, LP3972_BUCK_VOL1_REG(buck));
reg &= LP3972_BUCK_VOL_MASK;
- if (reg <= LP3972_BUCK_VOL_MAX_IDX(buck))
- val = dev->desc->volt_table[reg];
- else {
- val = 0;
- dev_warn(>dev, "chip reported incorrect voltage value."
- " reg = %d\n", reg);
- }
- return val;
+ return reg;
}
static int lp3972_dcdc_set_voltage_sel(struct regulator_dev *dev,
@@ -402,7 +392,7 @@ static struct regulator_ops lp3972_dcdc_ops = {
.is_enabled = lp3972_dcdc_is_enabled,
.enable = lp3972_dcdc_enable,
.disable = lp3972_dcdc_disable,
- .get_voltage = lp3972_dcdc_get_voltage,
+ .get_voltage_sel = lp3972_dcdc_get_voltage_sel,
.set_voltage_sel = lp3972_dcdc_set_voltage_sel,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/11] kexec: introduce kexec firmware support
> Daniel Kiper writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or > > hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware > > or hypervisor. > > As this stands this patch is wrong. > > You need to pass an additional flag from userspace through /sbin/kexec > that says load the kexec image in the firmware. A global variable here > is not ok. > > As I understand it you are loading a kexec on xen panic image. Which > is semantically different from a kexec on linux panic image. It is not > ok to do have a silly global variable kexec_use_firmware. Earlier we agreed that /sbin/kexec should call kexec syscall with special flag. However, during work on Xen kexec/kdump v3 patch I stated that this is insufficient because e.g. crash_kexec() should execute different code in case of use of firmware support too. Sadly syscall does not save this flag anywhere. Additionally, I stated that kernel itself has the best knowledge which code path should be used (firmware or plain Linux). If this decision will be left to userspace then simple kexec syscall could crash system at worst case (e.g. when plain Linux kexec will be used in case when firmware kaxec should be used). However, if you wish I could add this flag to syscall. Additionally, I could add function which enables firmware support and then kexec_use_firmware variable will be global only in kexec.c module. > Furthermore it is not ok to have a conditional > code outside of header files. I agree but how to dispatch execution e.g. in crash_kexec() if we would like (I suppose) compile kexec firmware support conditionally? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/23] uvc: Replace memcpy with struct assignment
Em Thu, 27 Dec 2012 18:12:46 -0300 Ezequiel Garcia escreveu: > Mauro, > > On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia > wrote: > > This kind of memcpy() is error-prone. Its replacement with a struct > > assignment is prefered because it's type-safe and much easier to read. > > > > Found by coccinelle. Hand patched and reviewed. > > Tested by compilation only. > > > > A simplified version of the semantic match that finds this problem is as > > follows: (http://coccinelle.lip6.fr/) > > > > // > > @@ > > identifier struct_name; > > struct struct_name to; > > struct struct_name from; > > expression E; > > @@ > > -memcpy(&(to), &(from), E); > > +to = from; > > // > > > > Cc: Laurent Pinchart > > Signed-off-by: Peter Senna Tschudin > > Signed-off-by: Ezequiel Garcia > > --- > > drivers/media/usb/uvc/uvc_v4l2.c |6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c > > b/drivers/media/usb/uvc/uvc_v4l2.c > > index f00db30..4fc8737 100644 > > --- a/drivers/media/usb/uvc/uvc_v4l2.c > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c > > @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming > > *stream, > > goto done; > > } > > > > - memcpy(>ctrl, , sizeof probe); > > + stream->ctrl = probe; > > stream->cur_format = format; > > stream->cur_frame = frame; > > > > @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming > > *stream, > > return -EBUSY; > > } > > > > - memcpy(, >ctrl, sizeof probe); > > + probe = stream->ctrl; > > probe.dwFrameInterval = > > uvc_try_frame_interval(stream->cur_frame, interval); > > > > @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming > > *stream, > > return ret; > > } > > > > - memcpy(>ctrl, , sizeof probe); > > + stream->ctrl = probe; > > mutex_unlock(>mutex); > > > > /* Return the actual frame period. */ > > -- > > 1.7.4.4 > > > > It seems you've marked this one as "Changes requested" [1]. > However, Laurent didn't request any change, > but just pointed out we missed one memcpy replacement candidate. > > I believe it's safe to apply the patch (together with the other 20 patches) > and we can fix the missing spot in another patch. The other patches got applied already. Well just do whatever Laurent asked you and re-submit this one ;) Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On 28.12.2012 00:55, David R. Piegdon wrote: Hi, NOTE to everyone debugging this: reproduced quickly with X + firefox + youtube (adobe flash plugin) Would you be so kind to test the following patch and report results? Apply the patch to the latest mainline. I've had probably the same problem (dmesg below) and currently am trying your patch applied to current mainline (101e5c7470eb7f). so far it looks very good. (before: bug after 5-30 minutes, right now 1h and counting) That's good news, except the oops you've attached belongs to another bug, it seems. :P People report good results when applying Hillf Danton suggestion to revert 5a505085f0 and 4fc3f1d66b1. So, if the bug reappears, you could help testing with the same procedure. [Cc: linux-mm list] thanks! [ 105.164610] [ cut here ] [ 105.164614] kernel BUG at mm/huge_memory.c:1798! [ 105.164617] invalid opcode: [#1] PREEMPT SMP [ 105.164621] Modules linked in: fuse sha256_generic xt_owner xt_LOG xt_limit xt_recent xt_conntrack xt_multiport iptable_mangle xt_DSCP iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack fbcon font bitblit softcursor fb fbdev hwmon_vid btrfs zlib_deflate zlib_inflate xfs libcrc32c snd_usb_audio uvcvideo snd_usbmidi_lib videobuf2_core snd_rawmidi videobuf2_vmalloc videobuf2_memops hid_kensington iTCO_wdt joydev gpio_ich iTCO_vendor_support raid1 fglrx(PO) coretemp kvm_intel kvm skge acpi_cpufreq lpc_ich serio_raw asus_atk0110 snd_hda_codec_hdmi intel_agp snd_hda_intel mperf intel_gtt processor snd_hda_codec sky2 agpgart snd_hwdep [last unloaded: iTCO_wdt] [ 105.164672] CPU 1 [ 105.164677] Pid: 4091, comm: XPCOM CC Tainted: P O 3.8.0-rc1+ #43 System manufacturer System Product Name/P5B-Deluxe [ 105.164679] RIP: 0010:[] [] __split_huge_page+0x216/0x240 [ 105.164688] RSP: 0018:880091511c48 EFLAGS: 00010297 [ 105.164690] RAX: 0001 RBX: 8800a210c000 RCX: 0042 [ 105.164692] RDX: 00cb RSI: 0046 RDI: 81b28a20 [ 105.164694] RBP: 880091511ca8 R08: R09: [ 105.164696] R10: 043d R11: 0001 R12: 8800a2295c60 [ 105.164698] R13: ea00021e R14: R15: 0007f5134600 [ 105.164701] FS: 7f514991e700() GS:8800bfc8() knlGS: [ 105.164703] CS: 0010 DS: ES: CR0: 8005003b [ 105.164705] CR2: 7f5123bff000 CR3: 9531b000 CR4: 07e0 [ 105.164707] DR0: DR1: DR2: [ 105.164709] DR3: DR6: 0ff0 DR7: 0400 [ 105.164712] Process XPCOM CC (pid: 4091, threadinfo 88009151, task 8800953616b0) [ 105.164713] Stack: [ 105.164715] 8800 8800b9c834b0 7f513480 8158c4a5 [ 105.164719] 8800a210c064 7f513460 880091511ca8 ea00021e [ 105.164723] 8800b9c83480 8800a210c000 88009fdc1d18 8800a210c064 [ 105.164727] Call Trace: [ 105.164732] [] split_huge_page+0x68/0xb0 [ 105.164736] [] __split_huge_page_pmd+0x1a8/0x220 [ 105.164740] [] unmap_page_range+0x1b6/0x2d0 [ 105.164744] [] unmap_single_vma+0x5b/0xe0 [ 105.164747] [] zap_page_range+0xbc/0x120 [ 105.164752] [] ? futex_wake+0x116/0x130 [ 105.164756] [] ? pick_next_task_fair+0x36/0xb0 [ 105.164760] [] madvise_vma+0xf7/0x140 [ 105.164764] [] ? find_vma_prev+0x12/0x60 [ 105.164767] [] sys_madvise+0x23d/0x330 [ 105.164772] [] system_call_fastpath+0x16/0x1b [ 105.164774] Code: 48 89 df e8 ed 10 ff ff e9 ab fe ff ff 0f 0b 41 8b 55 18 8b 75 bc ff c2 48 c7 c7 38 0e 7d 81 31 c0 e8 13 9b 46 00 e9 15 ff ff ff <0f> 0b 41 8b 4d 18 89 da ff c1 8b 75 bc 48 c7 c7 58 0e 7d 81 31 [ 105.164814] RIP [] __split_huge_page+0x216/0x240 [ 105.164818] RSP [ 105.164823] ---[ end trace 00c060fd7d17a3d4 ]--- -- Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, realmode: set real_mode permissions early
On 12/27/2012 03:56 PM, Yinghai Lu wrote: I'm looking at this patch in the -v8 branch: you need to update the comment above that function to say that trampoline code needs to be marked X now earlier. Not sure if we really need to add such comment in the code. Peter, what is your idea about this? It would be good to note why the early_initcall is the right phase. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, mm: add generic kernel/ident mapping helper
On Thu, Dec 27, 2012 at 11:03 AM, Borislav Petkov wrote: > On Thu, Dec 27, 2012 at 07:51:26PM +0100, Borislav Petkov wrote: >> > commit bb3cda32f9586e13c5d3dde6c83a914bb2d7f87f >> > Author: Yinghai Lu >> > Date: Mon Dec 24 18:00:21 2012 -0800 >> > >> > x86, mm: add generic kernel/ident mapping helper >> > >> > It is simple version for kernel_physical_mapping_init. >> > it will work to build one page table that will be put effectiv later. > > Forgot to ask: what does "put effectiv later" mean? * we will switch to using it later -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, realmode: set real_mode permissions early
On Thu, Dec 27, 2012 at 10:22 AM, Borislav Petkov wrote: >> commit 77e277cb85290a183bbc1995a1cd839b1c216f25 >> Subject: [PATCH] x86, realmode: set real_mode permissions early >> Author: Yinghai Lu >> Date: Mon Dec 24 18:00:21 2012 -0800 >> >> x86, realmode: set real_mode permissions early >> >> We need to set trampoline code to EXEC early before we do smp >> AP bootings. >> >> Found the problem after switching to #PF handler set page table, >> and we do not set initial kernel low mapping with EXEC anymore. >> >> Change to use early_initcall instead that will make sure tramopline >> will have EXEC set. >> >> Signed-off-by: Yinghai Lu >> >> diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c >> index 80450261215c..0b7e840ad4d4 100644 >> --- a/arch/x86/realmode/init.c >> +++ b/arch/x86/realmode/init.c >> @@ -111,5 +111,4 @@ static int __init set_real_mode_permissions(void) >> >> return 0; >> } >> - >> -arch_initcall(set_real_mode_permissions); >> +early_initcall(set_real_mode_permissions); > > I'm looking at this patch in the -v8 branch: you need to update the > comment above that function to say that trampoline code needs to be > marked X now earlier. Not sure if we really need to add such comment in the code. Peter, what is your idea about this? Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On 28.12.2012 00:42, Sedat Dilek wrote: On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic wrote: On 28.12.2012 00:30, Sedat Dilek wrote: Hi Zlatko, I am not sure if I hit the same problem as described in this thread. Under heavy load, while building a customized toolchain for the Freetz router project I got a BUG || NULL pointer derefence || kswapd || zone_balanced || pgdat_balanced() etc. (details see my screenshot). I will try your patch from [1] ***only*** on top of my last Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). Yes, that's the same bug. It should be fixed with my latest patch, so I'd appreciate you testing it, to be on the safe side this time. There should be no difference if you apply it to anything newer than 3.8-rc1, so go for it. Thanks! Not sure how I can really reproduce this bug as one build worked fine within my last v3.8-rc1 kernel. I increased the parallel-make-jobs-number from "4" to "8" to stress a bit harder. Just building right now... and will report. If you have any test-case (script or whatever), please let me/us know. Unfortunately not, I haven't reproduced it yet on my machines. But it seems that bug will hit only under heavy memory pressure. When close to OOM, or possibly with lots of writing to disk. It's also possible that fragmentation of memory zones could provoke it, that means testing it for a longer time. -- Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic wrote: > On 28.12.2012 00:30, Sedat Dilek wrote: >> >> Hi Zlatko, >> >> I am not sure if I hit the same problem as described in this thread. >> >> Under heavy load, while building a customized toolchain for the Freetz >> router project I got a BUG || NULL pointer derefence || kswapd || >> zone_balanced || pgdat_balanced() etc. (details see my screenshot). >> >> I will try your patch from [1] ***only*** on top of my last >> Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). >> > > Yes, that's the same bug. It should be fixed with my latest patch, so I'd > appreciate you testing it, to be on the safe side this time. There should be > no difference if you apply it to anything newer than 3.8-rc1, so go for it. > Thanks! > Not sure how I can really reproduce this bug as one build worked fine within my last v3.8-rc1 kernel. I increased the parallel-make-jobs-number from "4" to "8" to stress a bit harder. Just building right now... and will report. If you have any test-case (script or whatever), please let me/us know. Thanks. - Sedat - > Regards, > -- > Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/11] xen: Initial kexec/kdump implementation
> On 12/26/2012 06:18 PM, Daniel Kiper wrote: > > Hi, > > > > This set of patches contains initial kexec/kdump implementation for Xen v3. > > Currently only dom0 is supported, however, almost all infrustructure > > required for domU support is ready. > > > > Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 > > code. > > This could simplify and reduce a bit size of kernel code. However, this > > solution > > requires some changes in baremetal x86 code. First of all code which > > establishes > > transition page table should be moved back from machine_kexec_$(BITS).c to > > relocate_kernel_$(BITS).S. Another important thing which should be changed > > in that > > case is format of page_list array. Xen kexec hypercall requires to > > alternate physical > > addresses with virtual ones. These and other required stuff have not been > > done in that > > version because I am not sure that solution will be accepted by kexec/kdump > > maintainers. > > I hope that this email spark discussion about that topic. > > I want a detailed list of the constraints that this assumes and > therefore imposes on the native implementation as a result of this. We > have had way too many patches where Xen PV hacks effectively nailgun > arbitrary, and sometimes poor, design decisions in place and now we > can't fix them. OK but now I think that we should leave this discussion until all details regarding kexec/kdump generic code will be agreed. Sorry for that. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages
On 12/27/2012 05:18 PM, Alan Stern wrote: On Thu, 27 Dec 2012, Larry Finger wrote: I could not do exactly the experiment that you wanted, as ehci-hcd was loaded even though it was blacklisted. Rather than solve that problem, I generated a kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as a module. This one generated the errors, but they stopped when ehci-hcd loaded. I also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd as a module. No errors for that one. Your hypothesis looks correct. I hope there is some way to force ehci-pci to load as soon as ehci-hcd is loaded, and before ohci-hcd loads, but if there is not, I know how to prevent the errors on my system even though this solution won't help the users of distro kernels. At least this time the errors stop once all 3 modules are loaded, and the number of error outputs is limited. This is now a userspace issue. Perhaps a change to a udev rule will prevent ohci-hcd from loading until ehci-pci is in place. Or a change to a startup script in your initramfs. However the problem gets solved, there doesn't seem to be much the kernel can do about it. Thanks for looking at this. At the moment, there are no udev rules on my system that mention "ehci" or "ohci". Perhaps a suitable one can be prepared. In addition, I still need to look at the startup scripts to see if there is a possible fix there. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
On 28.12.2012 00:30, Sedat Dilek wrote: Hi Zlatko, I am not sure if I hit the same problem as described in this thread. Under heavy load, while building a customized toolchain for the Freetz router project I got a BUG || NULL pointer derefence || kswapd || zone_balanced || pgdat_balanced() etc. (details see my screenshot). I will try your patch from [1] ***only*** on top of my last Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes). Yes, that's the same bug. It should be fixed with my latest patch, so I'd appreciate you testing it, to be on the safe side this time. There should be no difference if you apply it to anything newer than 3.8-rc1, so go for it. Thanks! Regards, -- Zlatko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/11] x86/xen: Add i386 kexec/kdump implementation
On 12/27/2012 03:23 PM, Daniel Kiper wrote: On 12/26/2012 06:18 PM, Daniel Kiper wrote: Add i386 kexec/kdump implementation. v2 - suggestions/fixes: - allocate transition page table pages below 4 GiB (suggested by Jan Beulich). Why? Sadly all addresses are passed via unsigned long variable to kexec hypercall. So can you unf*ck your broken interface before imposing it on anyone else? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/11] x86/xen: Add i386 kexec/kdump implementation
> On 12/26/2012 06:18 PM, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > > > v2 - suggestions/fixes: > > - allocate transition page table pages below 4 GiB > > (suggested by Jan Beulich). > > Why? Sadly all addresses are passed via unsigned long variable to kexec hypercall. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] arm: vt8500: Convert debug-macro.S to be multiplatform friendly
This patch moves debug-macro.S from arm/mach-vt8500/include/mach to arm/include/debug/vt8500.S to provide multiplatform support. Minor style changes in code for readability. Signed-off-by: Tony Prisk --- arch/arm/Kconfig.debug |8 ++ arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 --- 2 files changed, 8 insertions(+), 31 deletions(-) delete mode 100644 arch/arm/mach-vt8500/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 661030d..bbb0a67 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -412,6 +412,13 @@ choice of the tiles using the RS1 memory map, including all new A-class core tiles, FPGA-based SMMs and software models. + config DEBUG_VT8500_UART0 + bool "Use UART0 on VIA/Wondermedia SoCs" + depends on ARCH_VT8500 + help + This option selects UART0 on VIA/Wondermedia System-on-a-chip + devices, including VT8500, WM8505, WM8650 and WM8850. + config DEBUG_LL_UART_NONE bool "No low-level debugging UART" depends on !ARCH_MULTIPLATFORM @@ -506,6 +513,7 @@ config DEBUG_LL_INCLUDE default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1 default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \ DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 + default "debug/vt8500.S" if DEBUG_VT8500_UART0 default "debug/tegra.S" if DEBUG_TEGRA_UART default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1 default "mach/debug-macro.S" diff --git a/arch/arm/mach-vt8500/include/mach/debug-macro.S b/arch/arm/mach-vt8500/include/mach/debug-macro.S deleted file mode 100644 index ca292f2..000 --- a/arch/arm/mach-vt8500/include/mach/debug-macro.S +++ /dev/null @@ -1,31 +0,0 @@ -/* - * arch/arm/mach-vt8500/include/mach/debug-macro.S - * - * Copyright (C) 2010 Alexey Charkov - * - * Debugging macro include header - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * -*/ - - .macro addruart, rp, rv, tmp - mov \rp, #0x0020 - orr \rv, \rp, #0xf800 - orr \rp, \rp, #0xd800 - .endm - - .macro senduart,rd,rx - strb\rd, [\rx, #0] - .endm - - .macro busyuart,rd,rx -1001: ldr \rd, [\rx, #0x1c] - ands\rd, \rd, #0x2 - bne 1001b - .endm - - .macro waituart,rd,rx - .endm -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
This patch adds support for the WM8750 (ARMv6) and WM8850 (ARMv7).
Common features across all SoCs are split into ARCH_VT8500 and
unique features are specified by each SoC option.
Signed-off-by: Tony Prisk
---
Documentation/devicetree/bindings/arm/vt8500.txt |8 ++
arch/arm/Kconfig | 17 +++
arch/arm/mach-vt8500/Kconfig | 33 --
arch/arm/mach-vt8500/vt8500.c|2 ++
4 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt
b/Documentation/devicetree/bindings/arm/vt8500.txt
index d657832..87dc1dd 100644
--- a/Documentation/devicetree/bindings/arm/vt8500.txt
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -12,3 +12,11 @@ compatible = "wm,wm8505";
Boards with the Wondermedia WM8650 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8650";
+
+Boards with the Wondermedia WM8750 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8750";
+
+Boards with the Wondermedia WM8850 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8850";
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f95ba14..fbb9492 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -952,20 +952,25 @@ config ARCH_OMAP
config ARCH_VT8500_SINGLE
bool "VIA/WonderMedia 85xx"
- select ARCH_HAS_CPUFREQ
- select ARCH_REQUIRE_GPIOLIB
- select CLKDEV_LOOKUP
+ select ARCH_VT8500
select COMMON_CLK
select CPU_ARM926T
- select GENERIC_CLOCKEVENTS
- select GENERIC_GPIO
- select HAVE_CLK
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select USE_OF
help
Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
+config ARCH_WM8750_SINGLE
+ bool "WonderMedia WM8750/WM8850"
+ select ARCH_VT8500
+ select COMMON_CLK
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
+ select USE_OF
+ help
+ Support for WonderMedia WM8750/WM8850 System-on-Chip.
+
endchoice
menu "Multiple platform selection"
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index 2ed0b7d..d67c7fa 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -1,12 +1,39 @@
config ARCH_VT8500
- bool "VIA/WonderMedia 85xx" if ARCH_MULTI_V5
- default ARCH_VT8500_SINGLE
+ bool
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
select CLKDEV_LOOKUP
- select CPU_ARM926T
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+
+config ARCH_WM8505
+ bool "VIA/WonderMedia 85xx" if !ARCH_VT8500_SINGLE
+ depends on ARCH_MULTI_V5
+ default ARCH_VT8500_SINGLE
+ select ARCH_VT8500
+ select CPU_ARM926T
help
Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
+
+config ARCH_WM8750
+ bool "WonderMedia WM8750"
+ depends on ARCH_MULTI_V6 || ARCH_WM8750_SINGLE
+ select ARCH_VT8500
+ select CPU_V6
+ help
+ Support for WonderMedia WM8750 System-on-Chip.
+
+config ARCH_WM8850
+ bool "WonderMedia WM8850"
+ depends on ARCH_MULTI_V7 || ARCH_WM8750_SINGLE
+ select ARCH_VT8500
+ select CPU_V7
+ help
+ Support for WonderMedia WM8850 System-on-Chip.
+
+# ensure that ARCH_WM8850 is on if ARCH_WM8750 is off
+config ARCH_WM8850_AUTO
+ def_bool y
+ depends on ARCH_WM8750_SINGLE && !ARCH_WM8750
+ select ARCH_WM8850
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 3c66d48..55162ab 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -183,6 +183,8 @@ static const char * const vt8500_dt_compat[] = {
"via,vt8500",
"wm,wm8650",
"wm,wm8505",
+ "wm,wm8750",
+ "wm,wm8850",
};
DT_MACHINE_START(WMT_DT, "VIA/Wondermedia SoC (Device Tree Support)")
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] arm: vt8500: Remove remaining mach includes
Remove the last two mach-vt8500/include/mach headers as they are
no longer required with multiplatform-only configuration.
Signed-off-by: Tony Prisk
---
arch/arm/mach-vt8500/include/mach/timex.h | 26 -
arch/arm/mach-vt8500/include/mach/uncompress.h | 37
2 files changed, 63 deletions(-)
delete mode 100644 arch/arm/mach-vt8500/include/mach/timex.h
delete mode 100644 arch/arm/mach-vt8500/include/mach/uncompress.h
diff --git a/arch/arm/mach-vt8500/include/mach/timex.h
b/arch/arm/mach-vt8500/include/mach/timex.h
deleted file mode 100644
index 8487e4c..000
--- a/arch/arm/mach-vt8500/include/mach/timex.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * arch/arm/mach-vt8500/include/mach/timex.h
- *
- * Copyright (C) 2010 Alexey Charkov
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#ifndef MACH_TIMEX_H
-#define MACH_TIMEX_H
-
-#define CLOCK_TICK_RATE(300)
-
-#endif /* MACH_TIMEX_H */
diff --git a/arch/arm/mach-vt8500/include/mach/uncompress.h
b/arch/arm/mach-vt8500/include/mach/uncompress.h
deleted file mode 100644
index e6e81fd..000
--- a/arch/arm/mach-vt8500/include/mach/uncompress.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/* arch/arm/mach-vt8500/include/mach/uncompress.h
- *
- * Copyright (C) 2010 Alexey Charkov
- *
- * Based on arch/arm/mach-dove/include/mach/uncompress.h
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#define UART0_PHYS 0xd820
-#define UART0_ADDR(x) *(volatile unsigned char *)(UART0_PHYS + x)
-
-static void putc(const char c)
-{
- while (UART0_ADDR(0x1c) & 0x2)
- /* Tx busy, wait and poll */;
-
- UART0_ADDR(0) = c;
-}
-
-static void flush(void)
-{
-}
-
-/*
- * nothing to do
- */
-#define arch_decomp_setup()
-#define arch_decomp_wdog()
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] arm: vt8500: Add new models and remove single-platform.
Hi Arnd/Olaf, These patches should be pretty self explanatory. #1 - Adds support for WM8750 and WM8850. #2 - Remove the single-platform Kconfig options. #3 - Move the early debug code so it can be used for multiplatform. #4 - Cleanup the unused headers in arch/arm/mach-vt8500/include. Tony Prisk (4): arm: vt8500: Add support for Wondermedia WM8750/WM8850 arm: vt8500: Remove single platform Kconfig options arm: vt8500: Convert debug-macro.S to be multiplatform friendly arm: vt8500: Remove remaining mach includes Documentation/devicetree/bindings/arm/vt8500.txt |8 + arch/arm/Kconfig | 16 -- arch/arm/Kconfig.debug |8 + arch/arm/mach-vt8500/Kconfig | 26 +-- arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 -- arch/arm/mach-vt8500/include/mach/timex.h| 26 --- arch/arm/mach-vt8500/include/mach/uncompress.h | 37 -- arch/arm/mach-vt8500/vt8500.c|2 ++ 8 files changed, 41 insertions(+), 113 deletions(-) delete mode 100644 arch/arm/mach-vt8500/include/mach/debug-macro.S delete mode 100644 arch/arm/mach-vt8500/include/mach/timex.h delete mode 100644 arch/arm/mach-vt8500/include/mach/uncompress.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] arm: vt8500: Remove single platform Kconfig options
This patch completes the move of arch-vt8500 to multiplatform only. The remaining single-image Kconfig options are removed from arch/arm/Kconfig and the options in arch/arm/mach-vt8500/Kconfig are updated. Signed-off-by: Tony Prisk --- arch/arm/Kconfig | 21 - arch/arm/mach-vt8500/Kconfig | 13 +++-- 2 files changed, 3 insertions(+), 31 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index fbb9492..76efd43 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -950,27 +950,6 @@ config ARCH_OMAP help Support for TI's OMAP platform (OMAP1/2/3/4). -config ARCH_VT8500_SINGLE - bool "VIA/WonderMedia 85xx" - select ARCH_VT8500 - select COMMON_CLK - select CPU_ARM926T - select MULTI_IRQ_HANDLER - select SPARSE_IRQ - select USE_OF - help - Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip. - -config ARCH_WM8750_SINGLE - bool "WonderMedia WM8750/WM8850" - select ARCH_VT8500 - select COMMON_CLK - select MULTI_IRQ_HANDLER - select SPARSE_IRQ - select USE_OF - help - Support for WonderMedia WM8750/WM8850 System-on-Chip. - endchoice menu "Multiple platform selection" diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig index d67c7fa..f466b58 100644 --- a/arch/arm/mach-vt8500/Kconfig +++ b/arch/arm/mach-vt8500/Kconfig @@ -8,9 +8,8 @@ config ARCH_VT8500 select HAVE_CLK config ARCH_WM8505 - bool "VIA/WonderMedia 85xx" if !ARCH_VT8500_SINGLE + bool "VIA/WonderMedia 85xx" depends on ARCH_MULTI_V5 - default ARCH_VT8500_SINGLE select ARCH_VT8500 select CPU_ARM926T help @@ -18,7 +17,7 @@ config ARCH_WM8505 config ARCH_WM8750 bool "WonderMedia WM8750" - depends on ARCH_MULTI_V6 || ARCH_WM8750_SINGLE + depends on ARCH_MULTI_V6 select ARCH_VT8500 select CPU_V6 help @@ -26,14 +25,8 @@ config ARCH_WM8750 config ARCH_WM8850 bool "WonderMedia WM8850" - depends on ARCH_MULTI_V7 || ARCH_WM8750_SINGLE + depends on ARCH_MULTI_V7 select ARCH_VT8500 select CPU_V7 help Support for WonderMedia WM8850 System-on-Chip. - -# ensure that ARCH_WM8850 is on if ARCH_WM8750 is off -config ARCH_WM8850_AUTO - def_bool y - depends on ARCH_WM8750_SINGLE && !ARCH_WM8750 - select ARCH_WM8850 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
> Hmm... this code is being redone at the moment... this might conflict. Is this available somewhere? May I have a look at it? Daniel PS I am on holiday until 02/01/2013 and I could not have access to my email box. Please be patient. At worst case I will send reply when I will be back at office. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages
On Thu, 27 Dec 2012, Larry Finger wrote: > I could not do exactly the experiment that you wanted, as ehci-hcd was loaded > even though it was blacklisted. Rather than solve that problem, I generated a > kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as > a > module. This one generated the errors, but they stopped when ehci-hcd loaded. > I > also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd > as > a module. No errors for that one. Your hypothesis looks correct. > > I hope there is some way to force ehci-pci to load as soon as ehci-hcd is > loaded, and before ohci-hcd loads, but if there is not, I know how to prevent > the errors on my system even though this solution won't help the users of > distro > kernels. At least this time the errors stop once all 3 modules are loaded, > and > the number of error outputs is limited. This is now a userspace issue. Perhaps a change to a udev rule will prevent ohci-hcd from loading until ehci-pci is in place. Or a change to a startup script in your initramfs. However the problem gets solved, there doesn't seem to be much the kernel can do about it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mm, bootmem: panic in bootmem alloc functions even if slab is available
On 12/27/2012 06:04 PM, David Rientjes wrote: > On Thu, 27 Dec 2012, Sasha Levin wrote: > >> That's exactly what happens with the patch. Note that in the current upstream >> version there are several slab checks scattered all over. >> >> In this case for example, I'm removing it from __alloc_bootmem_node(), but >> the >> first code line of__alloc_bootmem_node_nopanic() is: >> >> if (WARN_ON_ONCE(slab_is_available())) >> return kzalloc(size, GFP_NOWAIT); >> > > You're only talking about mm/bootmem.c and not mm/nobootmem.c, and notice > that __alloc_bootmem_node() does not call __alloc_bootmem_node_nopanic(), > it calls ___alloc_bootmem_node_nopanic(). Holy cow, this is an underscore hell. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mm, bootmem: panic in bootmem alloc functions even if slab is available
On Thu, 27 Dec 2012, Sasha Levin wrote: > That's exactly what happens with the patch. Note that in the current upstream > version there are several slab checks scattered all over. > > In this case for example, I'm removing it from __alloc_bootmem_node(), but the > first code line of__alloc_bootmem_node_nopanic() is: > > if (WARN_ON_ONCE(slab_is_available())) > return kzalloc(size, GFP_NOWAIT); > You're only talking about mm/bootmem.c and not mm/nobootmem.c, and notice that __alloc_bootmem_node() does not call __alloc_bootmem_node_nopanic(), it calls ___alloc_bootmem_node_nopanic(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c-exynos5: add debugfs support for registers
On Tue, Dec 25, 2012 at 04:55:55PM +0530, Naveen Krishna Chatradhi wrote:
> This patch replaces the dev_vdbg with debugfs function calls
> in i2c-exynos5.c driver.
>
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> Changes since v1:
> The debugfs implementation is a suggestion by Felipe Balbi.
> Its not tested, Implemented only for review purpose..
>
> drivers/i2c/busses/i2c-exynos5.c | 140
> +-
> 1 file changed, 109 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> index 7614f60..2d2da22 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -12,6 +12,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -55,6 +56,7 @@ struct exynos5_i2c {
>
> int bus_num;
> int speed_mode;
> + struct dentry *debugfs_root;
> };
>
> static const struct of_device_id exynos5_i2c_match[] = {
> @@ -63,39 +65,112 @@ static const struct of_device_id exynos5_i2c_match[] = {
> };
> MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
>
> -/* TODO: Should go to debugfs */
> -static inline void dump_i2c_register(struct exynos5_i2c *i2c)
> +static int exynos5_i2c_regs_show(struct seq_file *s, void *data)
> {
> - dev_vdbg(i2c->dev, "Register dump(%d) :\n %x\n %x\n %x\n %x\n"
> - " %x\n %x\n %x\n %x\n %x\n"
> - " %x\n %x\n %x\n %x\n %x\n"
> - " %x\n %x\n %x\n %x\n %x\n"
> - " %x\n %x\n %x\n %x\n %x\n",
> - i2c->suspended,
> - readl(i2c->regs + HSI2C_CTL),
> - readl(i2c->regs + HSI2C_FIFO_CTL),
> - readl(i2c->regs + HSI2C_TRAILIG_CTL),
> - readl(i2c->regs + HSI2C_CLK_CTL),
> - readl(i2c->regs + HSI2C_CLK_SLOT),
> - readl(i2c->regs + HSI2C_INT_ENABLE),
> - readl(i2c->regs + HSI2C_INT_STATUS),
> - readl(i2c->regs + HSI2C_ERR_STATUS),
> - readl(i2c->regs + HSI2C_FIFO_STATUS),
> - readl(i2c->regs + HSI2C_TX_DATA),
> - readl(i2c->regs + HSI2C_RX_DATA),
> - readl(i2c->regs + HSI2C_CONF),
> - readl(i2c->regs + HSI2C_AUTO_CONF),
> - readl(i2c->regs + HSI2C_TIMEOUT),
> - readl(i2c->regs + HSI2C_MANUAL_CMD),
> - readl(i2c->regs + HSI2C_TRANS_STATUS),
> - readl(i2c->regs + HSI2C_TIMING_HS1),
> - readl(i2c->regs + HSI2C_TIMING_HS2),
> - readl(i2c->regs + HSI2C_TIMING_HS3),
> - readl(i2c->regs + HSI2C_TIMING_FS1),
> - readl(i2c->regs + HSI2C_TIMING_FS2),
> - readl(i2c->regs + HSI2C_TIMING_FS3),
> - readl(i2c->regs + HSI2C_TIMING_SLA),
> + struct exynos5_i2c *i2c = (struct exynos5_i2c *)s->private;
> +
> + if (i2c->suspended) {
> + seq_printf(s, "i2c suspended, can't read registers\n");
> + return 0;
> + }
> +
> + pm_runtime_get_sync(i2c->dev);
> +
> + seq_printf(s, "CTL:\t\t0x%08x\n",
> + readl(i2c->regs + HSI2C_CTL));
BTW, there is a generic regdump debugfs interface nowadays, please use
that instead (look for debugfs_create_regset32)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/2] i2c-exynos5: add debugfs support for registers
On Tue, Dec 25, 2012 at 04:55:55PM +0530, Naveen Krishna Chatradhi wrote: > This patch replaces the dev_vdbg with debugfs function calls > in i2c-exynos5.c driver. > > Signed-off-by: Naveen Krishna Chatradhi merge with previous -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c: exynos5: add High Speed I2C controller driver
Hi,
On Tue, Dec 25, 2012 at 04:55:54PM +0530, Naveen Krishna Chatradhi wrote:
> Adds support for High Speed I2C driver found in Exynos5 and later
> SoCs from Samsung. This driver currently supports Auto mode.
>
> Driver only supports Device Tree method.
>
> Signed-off-by: Taekgyun Ko
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> Changes since v1:
> Fixed the comments from Felipe Balbi and Thomas Abraham.
>
> drivers/i2c/busses/Kconfig |7 +
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-exynos5.c | 652
> ++
> drivers/i2c/busses/i2c-exynos5.h | 102 ++
> 4 files changed, 762 insertions(+)
> create mode 100644 drivers/i2c/busses/i2c-exynos5.c
> create mode 100644 drivers/i2c/busses/i2c-exynos5.h
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index bdca511..4caea76 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -618,6 +618,13 @@ config I2C_S3C2410
> Say Y here to include support for I2C controller in the
> Samsung SoCs.
>
> +config I2C_EXYNOS5
> + tristate "Exynos5 high-speed I2C driver"
> + depends on ARCH_EXYNOS5
> + help
> + Say Y here to include support for High-speed I2C controller in the
> + Exynos5 based Samsung SoCs.
> +
> config I2C_S6000
> tristate "S6000 I2C support"
> depends on XTENSA_VARIANT_S6000
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 6181f3f..4b1548c 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_I2C_PUV3) += i2c-puv3.o
> obj-$(CONFIG_I2C_PXA)+= i2c-pxa.o
> obj-$(CONFIG_I2C_PXA_PCI)+= i2c-pxa-pci.o
> obj-$(CONFIG_I2C_S3C2410)+= i2c-s3c2410.o
> +obj-$(CONFIG_I2C_EXYNOS5)+= i2c-exynos5.o
> obj-$(CONFIG_I2C_S6000) += i2c-s6000.o
> obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
> obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> new file mode 100644
> index 000..7614f60
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -0,0 +1,652 @@
> +/* linux/drivers/i2c/busses/i2c-exynos5.c
no need for the full path. Generally this would look like:
* i2c-exynos5.c - Samsung Exynos 5 I2C Controller Driver
no strong feelings however.
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + *
> + * High speed I2C controller driver
> + * for Exynos5 and later SoCs from Samsung.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "i2c-exynos5.h"
it doesn't look like this header is even needed. All those macros could
be defined here in the C-source file which is the only user.
> +#define EXYNOS5_I2C_TIMEOUT (msecs_to_jiffies(1000))
> +
> +/* timeout for pm runtime autosuspend */
> +#define EXYNOS5_I2C_PM_TIMEOUT 1000/* ms */
> +
> +struct exynos5_i2c {
> + struct i2c_adapter adap;
> + unsigned intsuspended:1;
> +
> + struct i2c_msg *msg;
> + unsigned intmsg_idx;
> + struct completion msg_complete;
> + unsigned intmsg_ptr;
> +
> + unsigned intirq;
> +
> + void __iomem*regs;
> + struct clk *clk;
> + struct device *dev;
> + int gpios[2];
> +
> + int bus_num;
> + int speed_mode;
> +};
> +
> +static const struct of_device_id exynos5_i2c_match[] = {
> + { .compatible = "samsung,exynos5-hsi2c" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
> +
> +/* TODO: Should go to debugfs */
> +static inline void dump_i2c_register(struct exynos5_i2c *i2c)
> +{
> + dev_vdbg(i2c->dev, "Register dump(%d) :\n %x\n %x\n %x\n %x\n"
> + " %x\n %x\n %x\n %x\n %x\n"
> + " %x\n %x\n %x\n %x\n %x\n"
> + " %x\n %x\n %x\n %x\n %x\n"
> + " %x\n %x\n %x\n %x\n %x\n",
> + i2c->suspended,
> + readl(i2c->regs + HSI2C_CTL),
> + readl(i2c->regs + HSI2C_FIFO_CTL),
> + readl(i2c->regs + HSI2C_TRAILIG_CTL),
> + readl(i2c->regs + HSI2C_CLK_CTL),
> + readl(i2c->regs + HSI2C_CLK_SLOT),
> + readl(i2c->regs + HSI2C_INT_ENABLE),
> + readl(i2c->regs + HSI2C_INT_STATUS),
> + readl(i2c->regs + HSI2C_ERR_STATUS),
> + readl(i2c->regs + HSI2C_FIFO_STATUS),
> +
