* Re: linux-next: build failure after merge of the tree (nfs tree related)
From: Bryan Schumaker @ 2010-09-27 14:02 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <1285588055.19362.7.camel@heimdal.trondhjem.org>
On 09/27/2010 07:47 AM, Trond Myklebust wrote:
> Agreed: fs/nfs/dir.c needs to #include <vmalloc.h> in order to use those
> functions. Bryan, can you please fix that up?
No problem. An updated patch is pasted below.
-Bryan
We can use vmapped pages to read more information from the network at once.
This will reduce the number of calls needed to complete a readdir.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index e734072..9e2fcc8 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -901,8 +901,8 @@ static void nfs_server_set_fsinfo(struct nfs_server *server, struct nfs_fsinfo *
server->wtmult = nfs_block_bits(fsinfo->wtmult, NULL);
server->dtsize = nfs_block_size(fsinfo->dtpref, NULL);
- if (server->dtsize > PAGE_CACHE_SIZE)
- server->dtsize = PAGE_CACHE_SIZE;
+ if (server->dtsize > PAGE_CACHE_SIZE * NFS_MAX_READDIR_PAGES)
+ server->dtsize = PAGE_CACHE_SIZE * NFS_MAX_READDIR_PAGES;
if (server->dtsize > server->rsize)
server->dtsize = server->rsize;
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 8a54a07..207cc47 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -33,6 +33,7 @@
#include <linux/namei.h>
#include <linux/mount.h>
#include <linux/sched.h>
+#include <linux/vmalloc.h>
#include "nfs4_fs.h"
#include "delegation.h"
@@ -326,7 +327,7 @@ out:
/* Fill a page with xdr information before transferring to the cache page */
static
-int nfs_readdir_xdr_filler(struct page *xdr_page, nfs_readdir_descriptor_t *desc,
+int nfs_readdir_xdr_filler(struct page **pages, nfs_readdir_descriptor_t *desc,
struct nfs_entry *entry, struct file *file, struct inode *inode)
{
struct rpc_cred *cred = nfs_file_cred(file);
@@ -336,7 +337,7 @@ int nfs_readdir_xdr_filler(struct page *xdr_page, nfs_readdir_descriptor_t *desc
again:
timestamp = jiffies;
gencount = nfs_inc_attr_generation_counter();
- error = NFS_PROTO(inode)->readdir(file->f_path.dentry, cred, entry->cookie, xdr_page,
+ error = NFS_PROTO(inode)->readdir(file->f_path.dentry, cred, entry->cookie, pages,
NFS_SERVER(inode)->dtsize, desc->plus);
if (error < 0) {
/* We requested READDIRPLUS, but the server doesn't grok it */
@@ -437,22 +438,63 @@ out:
/* Perform conversion from xdr to cache array */
static
void nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc, struct nfs_entry *entry,
- struct page *xdr_page, struct page *page)
+ void *xdr_page, struct page *page)
{
- __be32 *ptr = kmap(xdr_page);
+ __be32 *ptr = xdr_page;
while (xdr_decode(desc, entry, &ptr) == 0) {
if (nfs_readdir_add_to_array(entry, page) == -1)
break;
if (desc->plus == 1)
nfs_prime_dcache(desc->file->f_path.dentry, entry);
}
- kunmap(xdr_page);
+}
+
+static
+void nfs_readdir_free_pagearray(struct page **pages, unsigned int npages)
+{
+ unsigned int i;
+ for (i = 0; i < npages; i++)
+ put_page(pages[i]);
+}
+
+static
+void nfs_readdir_free_large_page(void *ptr, struct page **pages,
+ unsigned int npages)
+{
+ vm_unmap_ram(ptr, npages);
+ nfs_readdir_free_pagearray(pages, npages);
+}
+
+/*
+ * nfs_readdir_large_page will allocate pages that must be freed with a call
+ * to nfs_readdir_free_large_page
+ */
+static
+void *nfs_readdir_large_page(struct page **pages, unsigned int npages)
+{
+ void *ptr;
+ unsigned int i;
+
+ for (i = 0; i < npages; i++) {
+ struct page *page = alloc_page(GFP_KERNEL);
+ if (page == NULL)
+ goto out_freepages;
+ pages[i] = page;
+ }
+
+ ptr = vm_map_ram(pages, NFS_MAX_READDIR_PAGES, 0, PAGE_KERNEL);
+ if (!IS_ERR_OR_NULL(ptr))
+ return ptr;
+out_freepages:
+ nfs_readdir_free_pagearray(pages, i);
+ return NULL;
}
static
int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page, struct inode *inode)
{
- struct page *xdr_page;
+ struct page *pages[NFS_MAX_READDIR_PAGES];
+ void *pages_ptr = NULL;
struct nfs_entry entry;
struct file *file = desc->file;
struct nfs_cache_array *array;
@@ -470,17 +512,17 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
memset(array, 0, sizeof(struct nfs_cache_array));
array->eof_index = -1;
- xdr_page = alloc_page(GFP_KERNEL);
- if (!xdr_page)
+ pages_ptr = nfs_readdir_large_page(pages, ARRAY_SIZE(pages));
+ if (!pages_ptr)
goto out_release_array;
do {
- status = nfs_readdir_xdr_filler(xdr_page, desc, &entry, file, inode);
+ status = nfs_readdir_xdr_filler(pages, desc, &entry, file, inode);
if (status < 0)
break;
- nfs_readdir_page_filler(desc, &entry, xdr_page, page);
+ nfs_readdir_page_filler(desc, &entry, pages_ptr, page);
} while (array->eof_index < 0 && array->size < MAX_READDIR_ARRAY);
- put_page(xdr_page);
+ nfs_readdir_free_large_page(pages_ptr, pages, ARRAY_SIZE(pages));
out_release_array:
nfs_readdir_release_array(page);
out:
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index c961bc9..f64382c 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -63,6 +63,12 @@ struct nfs_clone_mount {
#define NFS_UNSPEC_PORT (-1)
/*
+ * Maximum number of pages that readdir can use for creating
+ * a vmapped array of pages.
+ */
+#define NFS_MAX_READDIR_PAGES 8
+
+/*
* In-kernel mount arguments
*/
struct nfs_parsed_mount_data {
diff --git a/fs/nfs/nfs3proc.c b/fs/nfs/nfs3proc.c
index fabb4f2..033ed04 100644
--- a/fs/nfs/nfs3proc.c
+++ b/fs/nfs/nfs3proc.c
@@ -611,7 +611,7 @@ out:
*/
static int
nfs3_proc_readdir(struct dentry *dentry, struct rpc_cred *cred,
- u64 cookie, struct page *page, unsigned int count, int plus)
+ u64 cookie, struct page **pages, unsigned int count, int plus)
{
struct inode *dir = dentry->d_inode;
__be32 *verf = NFS_COOKIEVERF(dir);
@@ -621,7 +621,7 @@ nfs3_proc_readdir(struct dentry *dentry, struct rpc_cred *cred,
.verf = {verf[0], verf[1]},
.plus = plus,
.count = count,
- .pages = &page
+ .pages = pages
};
struct nfs3_readdirres res = {
.verf = verf,
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 089da5b..479f422 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2896,12 +2896,12 @@ static int nfs4_proc_mkdir(struct inode *dir, struct dentry *dentry,
}
static int _nfs4_proc_readdir(struct dentry *dentry, struct rpc_cred *cred,
- u64 cookie, struct page *page, unsigned int count, int plus)
+ u64 cookie, struct page **pages, unsigned int count, int plus)
{
struct inode *dir = dentry->d_inode;
struct nfs4_readdir_arg args = {
.fh = NFS_FH(dir),
- .pages = &page,
+ .pages = pages,
.pgbase = 0,
.count = count,
.bitmask = NFS_SERVER(dentry->d_inode)->attr_bitmask,
@@ -2932,14 +2932,14 @@ static int _nfs4_proc_readdir(struct dentry *dentry, struct rpc_cred *cred,
}
static int nfs4_proc_readdir(struct dentry *dentry, struct rpc_cred *cred,
- u64 cookie, struct page *page, unsigned int count, int plus)
+ u64 cookie, struct page **pages, unsigned int count, int plus)
{
struct nfs4_exception exception = { };
int err;
do {
err = nfs4_handle_exception(NFS_SERVER(dentry->d_inode),
_nfs4_proc_readdir(dentry, cred, cookie,
- page, count, plus),
+ pages, count, plus),
&exception);
} while (exception.retry);
return err;
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 08ef912..f2e2f97 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -4225,7 +4225,7 @@ static int decode_readdir(struct xdr_stream *xdr, struct rpc_rqst *req, struct n
pglen = recvd;
xdr_read_pages(xdr, pglen);
- BUG_ON(pglen + readdir->pgbase > PAGE_CACHE_SIZE);
+ BUG_ON(pglen + readdir->pgbase > PAGE_CACHE_SIZE * NFS_MAX_READDIR_PAGES);
kaddr = p = kmap_atomic(page, KM_USER0);
end = p + ((pglen + readdir->pgbase) >> 2);
entry = p;
diff --git a/fs/nfs/proc.c b/fs/nfs/proc.c
index 611bec2..3f1c181 100644
--- a/fs/nfs/proc.c
+++ b/fs/nfs/proc.c
@@ -519,14 +519,14 @@ nfs_proc_rmdir(struct inode *dir, struct qstr *name)
*/
static int
nfs_proc_readdir(struct dentry *dentry, struct rpc_cred *cred,
- u64 cookie, struct page *page, unsigned int count, int plus)
+ u64 cookie, struct page **pages, unsigned int count, int plus)
{
struct inode *dir = dentry->d_inode;
struct nfs_readdirargs arg = {
.fh = NFS_FH(dir),
.cookie = cookie,
.count = count,
- .pages = &page,
+ .pages = pages,
};
struct rpc_message msg = {
.rpc_proc = &nfs_procedures[NFSPROC_READDIR],
diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
index fc46192..7d8cafa 100644
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -1044,7 +1044,7 @@ struct nfs_rpc_ops {
int (*mkdir) (struct inode *, struct dentry *, struct iattr *);
int (*rmdir) (struct inode *, struct qstr *);
int (*readdir) (struct dentry *, struct rpc_cred *,
- u64, struct page *, unsigned int, int);
+ u64, struct page **, unsigned int, int);
int (*mknod) (struct inode *, struct dentry *, struct iattr *,
dev_t);
int (*statfs) (struct nfs_server *, struct nfs_fh *,
^ permalink raw reply related
* Re: linux-next: build warnings in Linus' tree
From: Stephen Rothwell @ 2010-09-27 13:31 UTC (permalink / raw)
To: Len Brown
Cc: Zhang Rui, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Linus
In-Reply-To: <20100917142630.b968977c.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
Hi Len,
On Fri, 17 Sep 2010 14:26:30 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 30 Aug 2010 14:08:02 +0800 Zhang Rui <rui.zhang@intel.com> wrote:
> >
> > On Mon, 2010-08-30 at 09:42 +0800, Stephen Rothwell wrote:
> > > Hi Len,
> > >
> > > On Tue, 17 Aug 2010 11:24:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> > > >
> > > > drivers/acpi/sysfs.c:152: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> > > > include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
>
> [several more elided]
>
> > > > Introduced by commit 1c8fce27e275fd7c6b75bc6455745f02d3903ee6 ("ACPI:
> > > > introduce drivers/acpi/sysfs.c") interacting with commit
> > > > 9bbb9e5a33109b2832e2e63dcc7a132924ab374b ("param: use ops in struct
> > > > kernel_param, rather than get and set fns directly").
> > >
> > > Can we have this fixed, please?
> > patch attached. :)
> >
> > Use module_param_cb instead of the obsoleted module_param_call to fix a build warning.
> >
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>
> Now that this has been in linux-next since Sep 6, can you please send it
> to Linus. It removes quite a few warnings that were introduced during
> this merge window - and I think we already have too many warnings.
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the tree (nfs tree related)
From: Trond Myklebust @ 2010-09-27 11:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Bryan Schumaker
In-Reply-To: <20100927152304.a6463447.sfr@canb.auug.org.au>
On Mon, 2010-09-27 at 15:23 +1000, Stephen Rothwell wrote:
> Hi Trond,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/nfs/dir.c: In function 'nfs_readdir_free_large_page':
> fs/nfs/dir.c:464: error: implicit declaration of function 'vm_unmap_ram'
> fs/nfs/dir.c: In function 'nfs_readdir_large_page':
> fs/nfs/dir.c:485: error: implicit declaration of function 'vm_map_ram'
> fs/nfs/dir.c:485: warning: assignment makes pointer from integer without a cast
>
> Caused by commit 2af4eb9746092aab7811b5b581d004049c068a02 ("NFS: readdir
> with vmapped pages").
>
> I have reverted that commit for today.
Agreed: fs/nfs/dir.c needs to #include <vmalloc.h> in order to use those
functions. Bryan, can you please fix that up?
Thanks Stephen!
Trond
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: David Miller @ 2010-09-27 8:17 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, ohad, linville
In-Reply-To: <20100927154408.55a28127.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Sep 2010 15:44:08 +1000
> After merging the final tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> Assembler messages:
> Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
>
> Presumably caused by commit 61ee7007a5d61aa066076da578e8e8084e122d7d
> ("wl12xx: add platform data passing support").
>
> I do my builds with a separate object directory (which may be a reason
> you don't see this).
John, please get this fixed, thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the bkl-trivial tree with the block tree
From: Arnd Bergmann @ 2010-09-27 7:05 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Vivek Goyal, Jens Axboe
In-Reply-To: <20100927144519.25cd3afa.sfr@canb.auug.org.au>
On Monday 27 September 2010 06:45:19 Stephen Rothwell wrote:
>
> #undef DEBUG
>
> + static DEFINE_MUTEX(ataflop_mutex);
> -static struct request_queue *floppy_queue;
> static struct request *fd_request;
> +static int fdc_queue;
>
> /* Disk types: DD, HD, ED */
> static struct atari_disk_type {
Looks good, thanks!
Vivek, since you are touching that file with other patches, are you interested
in taking the floppy part of my automated block driver BKL removal patch
as well?
I suspect it's possible to come up with a better solution than mine if you
know the code.
Arnd
^ permalink raw reply
* Re: linux-next: build warning after merge of the final tree (hwpoison tree related)
From: Andi Kleen @ 2010-09-27 7:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andi Kleen, linux-next, linux-kernel, Naoya Horiguchi,
Wu Fengguang
In-Reply-To: <20100927152804.57c2d66e.sfr@canb.auug.org.au>
On Mon, Sep 27, 2010 at 03:28:04PM +1000, Stephen Rothwell wrote:
> Hi Andi,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> mm/hugetlb.c:2950: warning: 'is_hugepage_on_freelist' defined but not used
>
> Introduced by commit 19b31e29073e272e49a3d38972c132c49383d5d4 ("HWPOISON,
> hugetlb: add free check to dequeue_hwpoison_huge_page()").
Fixed now. Thanks for the report.
-Andi
^ permalink raw reply
* Re: linux-next: build warning after merge of the final tree (hwpoison tree related)
From: Wu Fengguang @ 2010-09-27 6:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andi Kleen, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Naoya Horiguchi
In-Reply-To: <20100927152804.57c2d66e.sfr@canb.auug.org.au>
Hi Stephen,
On Mon, Sep 27, 2010 at 01:28:04PM +0800, Stephen Rothwell wrote:
> Hi Andi,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> mm/hugetlb.c:2950: warning: 'is_hugepage_on_freelist' defined but not used
>
> Introduced by commit 19b31e29073e272e49a3d38972c132c49383d5d4 ("HWPOISON,
> hugetlb: add free check to dequeue_hwpoison_huge_page()").
Maybe ppc64_defconfig does not enable CONFIG_MEMORY_FAILURE.
Try this trivial patch :)
Thanks,
Fengguang
---
hugetlb: fix is_hugepage_on_freelist() build warning
mm/hugetlb.c:2950: warning: 'is_hugepage_on_freelist' defined but not used
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/hugetlb.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- linux-next.orig/mm/hugetlb.c 2010-09-27 14:51:19.000000000 +0800
+++ linux-next/mm/hugetlb.c 2010-09-27 14:52:56.000000000 +0800
@@ -2876,8 +2876,8 @@ void hugetlb_unreserve_pages(struct inod
hugetlb_acct_memory(h, -(chg - freed));
}
-/* Should be called in hugetlb_lock */
-static int is_hugepage_on_freelist(struct page *hpage)
+#ifdef CONFIG_MEMORY_FAILURE
+static int __is_hugepage_on_freelist(struct page *hpage)
{
struct page *page;
struct page *tmp;
@@ -2890,7 +2890,6 @@ static int is_hugepage_on_freelist(struc
return 0;
}
-#ifdef CONFIG_MEMORY_FAILURE
/*
* This function is called from memory failure code.
* Assume the caller holds page lock of the head page.
@@ -2902,7 +2901,7 @@ int dequeue_hwpoisoned_huge_page(struct
int ret = -EBUSY;
spin_lock(&hugetlb_lock);
- if (is_hugepage_on_freelist(hpage)) {
+ if (__is_hugepage_on_freelist(hpage)) {
list_del(&hpage->lru);
h->free_huge_pages--;
h->free_huge_pages_node[nid]--;
^ permalink raw reply
* linux-next: Tree for September 27
From: Stephen Rothwell @ 2010-09-27 6:21 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 11425 bytes --]
Hi all,
Changes since 20100924:
The arm tree gained a conflict against the arm-current tree.
The samsung tree lost its conflicts.
The nfs tree gained a build failure for which I reverted a commit.
The net tree gained a conflict against the omap tree and a build failure
for which I reverted 3 commits.
The crypto tree gained a conflict against the omap tree.
The kgdb tree lost its build failure.
The trivial tree lost its conflict.
The hwpoison tree gained a build failure for which I reverted the merge
of that tree.
The bkl-trivial tree gained a conflict against the block tree.
The bkl-llseek tree lost its conflicts.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 174 trees (counting Linus' and 22 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/rc-fixes
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging gcl-current/merge
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
CONFLICT (content): Merge conflict in arch/powerpc/platforms/85xx/mpc85xx_mds.c
Merging s390/features
Merging sh/master
Merging genesis/master
Merging sparc/master
Merging tile/master
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
CONFLICT (content): Merge conflict in MAINTAINERS
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in drivers/media/IR/ir-keytable.c
CONFLICT (content): Merge conflict in drivers/media/IR/ir-lirc-codec.c
CONFLICT (content): Merge conflict in drivers/media/IR/ir-raw-event.c
CONFLICT (add/add): Merge conflict in drivers/media/IR/streamzap.c
CONFLICT (content): Merge conflict in drivers/media/dvb/siano/smscoreapi.c
CONFLICT (add/add): Merge conflict in drivers/media/video/s5p-fimc/fimc-core.c
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
Merging dlm/next
Merging swiotlb/master
Merging swiotlb-xen/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom-peripherals.c
CONFLICT (content): Merge conflict in drivers/net/pcmcia/pcnet_cs.c
CONFLICT (content): Merge conflict in drivers/net/qlcnic/qlcnic_init.c
CONFLICT (content): Merge conflict in net/ipv4/ip_output.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c
Merging sound-asoc/for-next
CONFLICT (content): Merge conflict in drivers/video/sh_mobile_hdmi.c
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
CONFLICT (content): Merge conflict in drivers/input/keyboard/Kconfig
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/ext4/mballoc.c
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
CONFLICT (content): Merge conflict in drivers/net/pcmcia/smc91c92_cs.c
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/mfd/sh_mobile_sdhi.c
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/atombios_crtc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_legacy_crtc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_mode.h
Merging viafb/viafb-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
CONFLICT (content): Merge conflict in drivers/net/irda/irda-usb.c
Merging catalin/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/smp_plat.h
CONFLICT (content): Merge conflict in arch/arm/kernel/Makefile
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
Merging i7core_edac/linux_next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging i7300_edac/linux_next
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging omap_dss2/for-next
Merging xen/upstream/xen
Merging rcu/rcu/next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in net/core/dev.c
Merging lost-spurious-irq/lost-spurious-irq
CONFLICT (content): Merge conflict in drivers/ata/libata-core.c
CONFLICT (content): Merge conflict in include/linux/libata.h
Merging edac-amd/for-next
Merging oprofile/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in mm/percpu.c
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/misc/Makefile
Merging quilt/tty
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/rndis.c
Merging staging-next/staging-next
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/hard-interface.c
CONFLICT (delete/modify): drivers/staging/mrst-touchscreen/Makefile deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/mrst-touchscreen/Makefile left in tree.
CONFLICT (delete/modify): drivers/staging/mrst-touchscreen/intel-mid-touch.c deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/mrst-touchscreen/intel-mid-touch.c left in tree.
CONFLICT (delete/modify): drivers/staging/ti-st/st.h deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/tiResolved 'drivers/staging/Makefile' using previous resolution.
CONFLICT (delete/modify): drivers/staging/ti-st/st_core.h deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/ti-st/st_core.h left in tree.
CONFLICT (content): Merge conflict in drivers/staging/ti-st/st_kim.c
$ git rm -f drivers/staging/mrst-touchscreen/Makefile drivers/staging/mrst-touchscreen/intel-mid-touch.c
$ git rm -f drivers/staging/ti-st/st.h drivers/staging/ti-st/st_core.h
Merging slabh/slabh
Merging bkl-trivial/trivial
CONFLICT (content): Merge conflict in drivers/block/ataflop.c
CONFLICT (content): Merge conflict in drivers/char/pcmcia/cm4000_cs.c
CONFLICT (content): Merge conflict in drivers/char/pcmcia/cm4040_cs.c
CONFLICT (content): Merge conflict in drivers/mmc/card/block.c
Merging bkl-llseek/llseek
Merging bkl-vfs/vfs
CONFLICT (content): Merge conflict in fs/cifs/cifsfs.c
CONFLICT (content): Merge conflict in fs/nilfs2/super.c
Merging bkl-config/config
Merging irqflags/master
Merging scsi-post-merge/merge-base:master
[master c035f43] Revert "NFS: readdir with vmapped pages"
[master 7e24616] Revert "wl12xx: add platform data passing support"
[master 807cb7e] Revert "wl1271: make ref_clock configurable by board"
[master a4dbdfe] Revert "wl1271: take irq info from private board data"
[master e0742cc] Revert "Merge remote branch 'hwpoison/hwpoison'"
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
From: Yinghai Lu @ 2010-09-27 5:58 UTC (permalink / raw)
To: caiqian-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-next, kexec, H. Peter Anvin
In-Reply-To: <870873343.2003871285555329846.JavaMail.root-k5qu2F3t005+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
Please check this one on top of tip or next.
Thanks
Yinghai
[PATCH] x86, memblock: Fix crashkernel allocation
Cai Qian found that crashkernel is broken with x86 memblock changes
1. crashkernel=128M@32M always reported that range is used, even first kernel is small
no one use that range
2. always get following report when using "kexec -p"
Could not find a free area of memory of a000 bytes...
locate_hole failed
The root cause is that generic memblock_find_in_range() will try to get range from top_down.
But crashkernel do need from low and specified range.
Let's limit the target range with rash_base + crash_size to make sure that
We get range from bottom.
Reported-and-Bisected-by: CAI Qian <caiqian-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/x86/kernel/setup.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -516,19 +516,28 @@ static void __init reserve_crashkernel(v
/* 0 means: find the address automatically */
if (crash_base <= 0) {
+ unsigned long long start = 0;
const unsigned long long alignment = 16<<20; /* 16M */
- crash_base = memblock_find_in_range(alignment, ULONG_MAX, crash_size,
- alignment);
- if (crash_base == MEMBLOCK_ERROR) {
+ crash_base = alignment;
+ while (crash_base < 0xffffffff) {
+ start = memblock_find_in_range(crash_base,
+ crash_base + crash_size, crash_size, alignment);
+
+ if (start == crash_base)
+ break;
+
+ crash_base += alignment;
+ }
+ if (start != crash_base) {
pr_info("crashkernel reservation failed - No suitable area found.\n");
return;
}
} else {
unsigned long long start;
- start = memblock_find_in_range(crash_base, ULONG_MAX, crash_size,
- 1<<20);
+ start = memblock_find_in_range(crash_base,
+ crash_base + crash_size, crash_size, 1<<20);
if (start != crash_base) {
pr_info("crashkernel reservation failed - memory is in use.\n");
return;
^ permalink raw reply
* linux-next: build failure after merge of the final tree (hwpoison tree related)
From: Stephen Rothwell @ 2010-09-27 5:55 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-next, linux-kernel, Naoya Horiguchi, Jun'ichi Nomura
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hi Andi,
After merging the final tree, today's linux-next build (powerpc allnoconfig)
failed like this:
mm/mprotect.o: In function `migrate_huge_page_move_mapping':
mprotect.c:(.text+0x0): multiple definition of `migrate_huge_page_move_mapping'
mm/shmem.o:shmem.c:(.text+0x0): first defined here
mm/rmap.o: In function `migrate_huge_page_move_mapping':
rmap.c:(.text+0x0): multiple definition of `migrate_huge_page_move_mapping'
mm/shmem.o:shmem.c:(.text+0x0): first defined here
Caused by commit 7b217c52ce7f33379beb27aa7685109fa74ed6bf ("hugetlb:
hugepage migration core").
This function is declared as "extern int ..." with a body in
include/linux/migrate.h for the non CONFIG_MIGRATION case.
I reverted the whole hwpoison tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the final tree (net tree related)
From: Stephen Rothwell @ 2010-09-27 5:44 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Ohad Ben-Cohen, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
Hi all,
After merging the final tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Assembler messages:
Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
Presumably caused by commit 61ee7007a5d61aa066076da578e8e8084e122d7d
("wl12xx: add platform data passing support").
I do my builds with a separate object directory (which may be a reason
you don't see this).
I have reverted that commit for today (and commits
09cecc340b3b4d9960b039c0f576548bbf857f5a ("wl1271: take irq info from
private board data") and 15cea99306ae14ce5f7c3d3989bcc17202e2b0be
("wl1271: make ref_clock configurable by board") which follow it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build warning after merge of the final tree (tty tree related)
From: Stephen Rothwell @ 2010-09-27 5:31 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Hi Greg,
After merging the final tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/char/nozomi.c: In function 'ntty_ioctl':
drivers/char/nozomi.c:1831: warning: unused variable 'argp'
Introduced by commit dd612b1a8edb7fb3a117c388bfb520476e04ed18 ("tty:
icount changeover for other main devices").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build warning after merge of the final tree (hwpoison tree related)
From: Stephen Rothwell @ 2010-09-27 5:28 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-next, linux-kernel, Naoya Horiguchi, Wu Fengguang
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi Andi,
After merging the final tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
mm/hugetlb.c:2950: warning: 'is_hugepage_on_freelist' defined but not used
Introduced by commit 19b31e29073e272e49a3d38972c132c49383d5d4 ("HWPOISON,
hugetlb: add free check to dequeue_hwpoison_huge_page()").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the tree (nfs tree related)
From: Stephen Rothwell @ 2010-09-27 5:23 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-next, linux-kernel, Bryan Schumaker
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
Hi Trond,
After merging the final tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/nfs/dir.c: In function 'nfs_readdir_free_large_page':
fs/nfs/dir.c:464: error: implicit declaration of function 'vm_unmap_ram'
fs/nfs/dir.c: In function 'nfs_readdir_large_page':
fs/nfs/dir.c:485: error: implicit declaration of function 'vm_map_ram'
fs/nfs/dir.c:485: warning: assignment makes pointer from integer without a cast
Caused by commit 2af4eb9746092aab7811b5b581d004049c068a02 ("NFS: readdir
with vmapped pages").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the bkl-trivial tree with the block tree
From: Stephen Rothwell @ 2010-09-27 4:45 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-next, linux-kernel, Vivek Goyal, Jens Axboe
Hi Arnd,
Today's linux-next merge of the bkl-trivial tree got a conflict in
drivers/block/ataflop.c between commit
639e2f2aa76eefaf22078dccbbf2f3483f587aa7 ("atari floppy: Stop sharing
request queue across multiple gendisks") from the block tree and commit
5778067afcfd8b718ffc3744c25fdd194fc886a1 ("block: autoconvert trivial BKL
users to private mutex") from the bkl-trivial tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/block/ataflop.c
index 0f4eec4,8c021bb..0000000
--- a/drivers/block/ataflop.c
+++ b/drivers/block/ataflop.c
@@@ -79,8 -79,9 +79,9 @@@
#undef DEBUG
+ static DEFINE_MUTEX(ataflop_mutex);
-static struct request_queue *floppy_queue;
static struct request *fd_request;
+static int fdc_queue;
/* Disk types: DD, HD, ED */
static struct atari_disk_type {
^ permalink raw reply
* Re: linux-next: manual merge of the crypto tree with the omap tree
From: Herbert Xu @ 2010-09-27 4:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Dmitry Kasatkin, Tony Lindgren,
linux-omap
In-Reply-To: <20100927143300.9fa73063.sfr@canb.auug.org.au>
On Mon, Sep 27, 2010 at 02:33:00PM +1000, Stephen Rothwell wrote:
> Hi Herbert,
>
> Today's linux-next merge of the crypto tree got a conflict in
> arch/arm/mach-omap2/devices.c between commit
> 5d14f2792f9d63c5d25903bd048017c4b53c7d9a ("omap: crypto: updates to
> enable omap aes") from the omap tree and commit
> b744c679f62b368cb94c21c1dcd4618e42d88d63 ("crypto: updates to enable omap
> aes") from the crypto tree.
>
> Two versions of the same patch. The version in the omap tree has been
> updated, so I used that.
Thanks for the note Stephen.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* linux-next: manual merge of the crypto tree with the omap tree
From: Stephen Rothwell @ 2010-09-27 4:33 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-next, linux-kernel, Dmitry Kasatkin, Tony Lindgren,
linux-omap
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in
arch/arm/mach-omap2/devices.c between commit
5d14f2792f9d63c5d25903bd048017c4b53c7d9a ("omap: crypto: updates to
enable omap aes") from the omap tree and commit
b744c679f62b368cb94c21c1dcd4618e42d88d63 ("crypto: updates to enable omap
aes") from the crypto tree.
Two versions of the same patch. The version in the omap tree has been
updated, so I used that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net tree with the omap tree
From: Stephen Rothwell @ 2010-09-27 4:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Sukumar Ghorai, Tony Lindgren,
linux-omap, Ohad Ben-Cohen, John W. Linville
Hi all,
Today's linux-next merge of the net tree got a conflict in
arch/arm/mach-omap2/board-zoom-peripherals.c between commit
6db649c505ddc6665176807c16745b9e01cf5031 ("omap: mmc: extended to pass
host capabilities from board file") from the omap tree and commits
b642fde7f137566c993991fd2e7bf6b8274bf625 ("omap: zoom: add fixed
regulator device for wlan") and 80b517f362605f2b6a6cfe086604534290aab2de
("omap: zoom: add mmc3/wl1271 device support") from the net tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-zoom-peripherals.c
index e5eac46,6aa0728..0000000
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@@ -16,7 -16,8 +16,9 @@@
#include <linux/gpio.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/mmc/host.h>
+ #include <linux/regulator/fixed.h>
+ #include <linux/wl12xx.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
^ permalink raw reply
* linux-next: manual merge of the arm tree with the arm-current tree
From: Stephen Rothwell @ 2010-09-27 4:21 UTC (permalink / raw)
To: Russell King; +Cc: linux-next, linux-kernel, Santosh Shilimkar
Hi Russell,
Today's linux-next merge of the arm tree got a conflict in
arch/arm/mm/mmu.c between commit f1a2481c0ad3aebd94d11b317c488deaadc25002
("ARM: 6407/1: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries")
from the arm-current tree and commit
dc966984f44f16b8bb6b0644e501c7c2163ead69 ("ARM: Allow SMP kernels to boot
on UP systems") from the arm tree.
I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mm/mmu.c
index 6a3a2d0,a789320..0000000
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@@ -436,22 -423,21 +433,23 @@@ static void __init build_mem_type_table
mem_types[MT_MINICLEAN].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
- #ifdef CONFIG_SMP
- /*
- * Mark memory with the "shared" attribute for SMP systems
- */
- user_pgprot |= L_PTE_SHARED;
- kern_pgprot |= L_PTE_SHARED;
- vecs_pgprot |= L_PTE_SHARED;
- mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
- mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
- mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
- mem_types[MT_MEMORY].prot_pte |= L_PTE_SHARED;
- mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
- mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
- #endif
+ if (is_smp()) {
+ /*
+ * Mark memory with the "shared" attribute
+ * for SMP systems
+ */
+ user_pgprot |= L_PTE_SHARED;
+ kern_pgprot |= L_PTE_SHARED;
+ vecs_pgprot |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
++ mem_types[MT_MEMORY].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
++ mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
+ }
}
/*
^ permalink raw reply
* Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
From: caiqian @ 2010-09-27 2:42 UTC (permalink / raw)
To: Yinghai Lu; +Cc: linux-next, kexec, H. Peter Anvin
In-Reply-To: <1346740216.2003261285553562018.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
----- "Yinghai Lu" <yinghai@kernel.org> wrote:
> On 09/26/2010 07:47 AM, caiqian@redhat.com wrote:
> >
> > ----- "Yinghai Lu" <yinghai@kernel.org> wrote:
> >
> >> On 09/25/2010 11:55 PM, CAI Qian wrote:
> >>>>
> >>>> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> >>> No, both kernels were the same version. I am sorry the above logs
> >> were misleading that were copy-and-pasted from different kernel
> >> versions.
> >>
> >> can you check tip instead of next tree?
> > No dice,
> > # /sbin/kexec -p '--command-line=ro
> root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root
> rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM
> LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us
> rhgb quiet console=tty0 console=ttyS0,115200 crashkernel=128M irqpoll
> maxcpus=1 reset_devices cgroup_disable=memory '
> --initrd=/boot/initrd-2.6.36-rc5-tip+kdump.img
> /boot/vmlinuz-2.6.36-rc5-tip+
> > Could not find a free area of memory of a000 bytes...
> > locate_hole failed
>
> looks like you need to update your kexec-tools package.
Same results using the latest kexec-tools git version.
>
> please run following scripts in first kernel.
>
> cd /sys/firmware/memmap
> for dir in * ; do
> start=$(cat $dir/start)
> end=$(cat $dir/end)
> type=$(cat $dir/type)
> printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
> done
0000000000000000-000000000009f400 (System RAM)
000000000009f400-00000000000a0000 (reserved)
00000000000f0000-0000000000100000 (reserved)
0000000000100000-00000000dfffb000 (System RAM)
00000000dfffb000-00000000e0000000 (reserved)
00000000fffbc000-0000000100000000 (reserved)
0000000100000000-0000000ca0000000 (System RAM)
>
> also enable kexec debug to see what memmap kexec parse.
-d did not help here.
# /sbin/kexec -p -d '--command-line=ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet console=tty0 console=ttyS0,115200 crashkernel=128M irqpoll maxcpus=1 reset_devices cgroup_disable=memory ' --initrd=/boot/initrd-2.6.36-rc5-tip+kdump.img /boot/vmlinuz-2.6.36-rc5-tip+
Could not find a free area of memory of a000 bytes...
locate_hole failed
>
> >
> > After reverted the whole memblock commits, it was working again,
> > 7950c407c0288b223a200c1bba8198941599ca37
> > fb74fb6db91abc3c1ceeb9d2c17b44866a12c63e
> > f88eff74aa848e58b1ea49768c0bbb874b31357f
> > 27de794365786b4cdc3461ed4e23af2a33f40612
> > 9dc5d569c133819c1ce069ebb1d771c62de32580
> > 4d5cf86ce187c0d3a4cdf233ab0cc6526ccbe01f
> > 88ba088c18457caaf8d2e5f8d36becc731a3d4f6
> > edbe7d23b4482e7f33179290bcff3b1feae1c5f3
> > 6bcc8176d07f108da3b1af17fb2c0e82c80e948e
> > b52c17ce854125700c4e19d4427d39bf2504ff63
> > e82d42be24bd5d75bf6f81045636e6ca95ab55f2
> > 301ff3e88ef9ff4bdb92f36a3e6170fce4c9dd34
> > 72d7c3b33c980843e756681fb4867dc1efd62a76
> > a9ce6bc15100023b411f8117e53a016d61889800
> > a587d2daebcd2bc159d4348b6a7b028950a6d803
> > 6f2a75369e7561e800d86927ecd83c970996b21f
> >
> > If used crashkernel=128M, the /proc/iomem looks like this. It used a
> huge offset.
> > 00000000-00000fff : reserved
> > 00001000-0009f3ff : System RAM
> > 0009f400-0009ffff : reserved
> > 000f0000-000fffff : reserved
> > 00100000-dfffafff : System RAM
> > 01000000-0149a733 : Kernel code
> > 0149a734-01afc46f : Kernel data
> > 01d9c000-022b18f7 : Kernel bss
> > dfffb000-dfffffff : reserved
> > f0000000-f1ffffff : 0000:00:02.0
> > f2000000-f2000fff : 0000:00:02.0
> > f2010000-f201ffff : 0000:00:02.0
> > f2020000-f20200ff : 0000:00:03.0
> > f2020000-f20200ff : 8139cp
> > f2030000-f203ffff : 0000:00:03.0
> > fec00000-fec003ff : IOAPIC 0
> > fee00000-fee00fff : Local APIC
> > fffbc000-ffffffff : reserved
> > 100000000-c9fffffff : System RAM
> > c98000000-c9fffffff : Crash kernel
> >
> > On kernels that are working, it automatically found the offset at
> 32M.
> > 00000000-0000ffff : reserved
> > 00010000-0009f3ff : System RAM
> > 0009f400-0009ffff : reserved
> > 000f0000-000fffff : reserved
> > 00100000-dfffafff : System RAM
> > 01000000-014250bf : Kernel code
> > 014250c0-018aca8f : Kernel data
> > 01b1f000-01ff7c07 : Kernel bss
> > 02000000-09ffffff : Crash kernel
> > dfffb000-dfffffff : reserved
> > f0000000-f1ffffff : 0000:00:02.0
> > f2000000-f2000fff : 0000:00:02.0
> > f2010000-f201ffff : 0000:00:02.0
> > f2020000-f20200ff : 0000:00:03.0
> > f2020000-f20200ff : 8139cp
> > f2030000-f203ffff : 0000:00:03.0
> > fec00000-fec003ff : IOAPIC 0
> > fee00000-fee00fff : Local APIC
> > fffbc000-ffffffff : reserved
> > 100000000-c9fffffff : System RAM
> >
> > If specified a fixed offset like crashkernel=128M@32M, it failed
> reservation.
> > initial memory mapped : 0 - 20000000
> > init_memory_mapping: 0000000000000000-00000000dfffb000
> > 0000000000 - 00dfe00000 page 2M
> > 00dfe00000 - 00dfffb000 page 4k
> > kernel direct mapping tables up to dfffb000 @ 1fffa000-20000000
> > init_memory_mapping: 0000000100000000-0000000ca0000000
> > 0100000000 - 0ca0000000 page 2M
> > kernel direct mapping tables up to ca0000000 @ dffc7000-dfffb000
> > RAMDISK: 37599000 - 37ff0000
> > crashkernel reservation failed - memory is in use.
> >
> > After reverted those commits, it looks like this,
> > init_memory_mapping: 0000000000000000-00000000dfffb000
> > 0000000000 - 00dfe00000 page 2M
> > 00dfe00000 - 00dfffb000 page 4k
> > kernel direct mapping tables up to dfffb000 @ 16000-1c000
> > init_memory_mapping: 0000000100000000-0000000ca0000000
> > 0100000000 - 0ca0000000 page 2M
> > kernel direct mapping tables up to ca0000000 @ 1a000-4e000
> > RAMDISK: 375c9000 - 37ff0000
> > Reserving 128MB of memory at 32MB for crashkernel (System RAM:
> 51712MB)
>
> yes, default memblock find_range is top_down.
>
> old early_res is from bottom_up.
>
> during the convecting, we do have one x86 find_range from bottom_up,
> but later
> it seems top_down was working on all test cases. ( 32bit etc)
>
> Subject: [PATCH] x86, memblock: Add x86 version of
> memblock_find_in_range()
Yes, this patch did help.
Reserving 128MB of memory at 32MB for crashkernel (System RAM: 51712MB)
>
> Generic version is going from high to low, and it seems it can not
> find
> right area compact enough.
>
> the x86 version will go from goal to limit and just like the way We
> used
> for early_res
>
> use ARCH_FIND_MEMBLOCK_AREA to select from them.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> ---
> arch/x86/Kconfig | 8 +++++++
> arch/x86/mm/memblock.c | 54
> +++++++++++++++++++++++++++++++++++++++++++++++++
> mm/memblock.c | 2 -
> 3 files changed, 63 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/arch/x86/mm/memblock.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/mm/memblock.c
> +++ linux-2.6/arch/x86/mm/memblock.c
> @@ -352,3 +352,57 @@ u64 __init memblock_x86_hole_size(u64 st
>
> return end - start - ((u64)ram << PAGE_SHIFT);
> }
> +
> +#ifdef CONFIG_ARCH_MEMBLOCK_FIND_AREA
> +/* Check for already reserved areas */
> +static inline bool __init check_with_memblock_reserved(u64 *addrp,
> u64 size, u64 align)
> +{
> + u64 addr = *addrp;
> + bool changed = false;
> + struct memblock_region *r;
> +again:
> + for_each_memblock(reserved, r) {
> + if ((addr + size) > r->base && addr < (r->base + r->size)) {
> + addr = round_up(r->base + r->size, align);
> + changed = true;
> + goto again;
> + }
> + }
> +
> + if (changed)
> + *addrp = addr;
> +
> + return changed;
> +}
> +
> +/*
> + * Find a free area with specified alignment in a specific range.
> + */
> +u64 __init memblock_find_in_range(u64 start, u64 end, u64 size, u64
> align)
> +{
> + struct memblock_region *r;
> +
> + for_each_memblock(memory, r) {
> + u64 ei_start = r->base;
> + u64 ei_last = ei_start + r->size;
> + u64 addr, last;
> +
> + addr = round_up(ei_start, align);
> + if (addr < start)
> + addr = round_up(start, align);
> + if (addr >= ei_last)
> + continue;
> + while (check_with_memblock_reserved(&addr, size, align) &&
> addr+size <= ei_last)
> + ;
> + last = addr + size;
> + if (last > ei_last)
> + continue;
> + if (last > end)
> + continue;
> +
> + return addr;
> + }
> +
> + return MEMBLOCK_ERROR;
> +}
> +#endif
> Index: linux-2.6/arch/x86/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/x86/Kconfig
> +++ linux-2.6/arch/x86/Kconfig
> @@ -569,6 +569,14 @@ config PARAVIRT_DEBUG
> Enable to debug paravirt_ops internals. Specifically, BUG if
> a paravirt_op is missing when it is called.
>
> +config ARCH_MEMBLOCK_FIND_AREA
> + default y
> + bool "Use x86 own memblock_find_in_range()"
> + ---help---
> + Use memblock_find_in_range() version instead of generic version,
> it get free
> + area up from low.
> + Generic one try to get free area down from limit.
> +
> config NO_BOOTMEM
> def_bool y
>
> Index: linux-2.6/mm/memblock.c
> ===================================================================
> --- linux-2.6.orig/mm/memblock.c
> +++ linux-2.6/mm/memblock.c
> @@ -165,7 +165,7 @@ static phys_addr_t __init_memblock membl
> /*
> * Find a free area with specified alignment in a specific range.
> */
> -u64 __init_memblock memblock_find_in_range(u64 start, u64 end, u64
> size, u64 align)
> +u64 __init_memblock __weak memblock_find_in_range(u64 start, u64 end,
> u64 size, u64 align)
> {
> return memblock_find_base(size, align, start, end);
> }
>
>
> >
> > I can't tell where the memory at 32MB was used, but after reverted
> those commits I can see those early reservations information,
> > Subtract (76 early reservations)
> > #1 [0001000000 - 0001ff7c08] TEXT DATA BSS
> > #2 [00375c9000 - 0037ff0000] RAMDISK
> > #3 [0001ff8000 - 0001ff8079] BRK
> > #4 [000009f400 - 00000f7fb0] BIOS reserved
> > #5 [00000f7fb0 - 00000f7fc0] MP-table mpf
> > #6 [00000f822c - 0000100000] BIOS reserved
> > #7 [00000f7fc0 - 00000f822c] MP-table mpc
> > #8 [0000010000 - 0000012000] TRAMPOLINE
> > #9 [0000012000 - 0000016000] ACPI WAKEUP
> > #10 [0000016000 - 000001a000] PGTABLE
> > #11 [000001a000 - 0000049000] PGTABLE
> > #12 [0002000000 - 000a000000] CRASH KERNEL
> >
> > But after those commits, those information was gone.
>
> memblock could merge reserved area, so can not keep tags with it.
>
> I have local patchset that could print those name tags...
> please check
Looks like so.
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-2.6-yinghai.git
> memblock
>
> Yinghai
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
From: Yinghai Lu @ 2010-09-26 19:42 UTC (permalink / raw)
To: caiqian-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-next, kexec, H. Peter Anvin
In-Reply-To: <1087857734.1996121285512457425.JavaMail.root-k5qu2F3t005+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
On 09/26/2010 07:47 AM, caiqian-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:
>
> ----- "Yinghai Lu" <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>> On 09/25/2010 11:55 PM, CAI Qian wrote:
>>>>
>>>> are you kexec from 2.6.35+ to 2.6.36-rc3+?
>>> No, both kernels were the same version. I am sorry the above logs
>> were misleading that were copy-and-pasted from different kernel
>> versions.
>>
>> can you check tip instead of next tree?
> No dice,
> # /sbin/kexec -p '--command-line=ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet console=tty0 console=ttyS0,115200 crashkernel=128M irqpoll maxcpus=1 reset_devices cgroup_disable=memory ' --initrd=/boot/initrd-2.6.36-rc5-tip+kdump.img /boot/vmlinuz-2.6.36-rc5-tip+
> Could not find a free area of memory of a000 bytes...
> locate_hole failed
looks like you need to update your kexec-tools package.
please run following scripts in first kernel.
cd /sys/firmware/memmap
for dir in * ; do
start=$(cat $dir/start)
end=$(cat $dir/end)
type=$(cat $dir/type)
printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
done
also enable kexec debug to see what memmap kexec parse.
>
> After reverted the whole memblock commits, it was working again,
> 7950c407c0288b223a200c1bba8198941599ca37
> fb74fb6db91abc3c1ceeb9d2c17b44866a12c63e
> f88eff74aa848e58b1ea49768c0bbb874b31357f
> 27de794365786b4cdc3461ed4e23af2a33f40612
> 9dc5d569c133819c1ce069ebb1d771c62de32580
> 4d5cf86ce187c0d3a4cdf233ab0cc6526ccbe01f
> 88ba088c18457caaf8d2e5f8d36becc731a3d4f6
> edbe7d23b4482e7f33179290bcff3b1feae1c5f3
> 6bcc8176d07f108da3b1af17fb2c0e82c80e948e
> b52c17ce854125700c4e19d4427d39bf2504ff63
> e82d42be24bd5d75bf6f81045636e6ca95ab55f2
> 301ff3e88ef9ff4bdb92f36a3e6170fce4c9dd34
> 72d7c3b33c980843e756681fb4867dc1efd62a76
> a9ce6bc15100023b411f8117e53a016d61889800
> a587d2daebcd2bc159d4348b6a7b028950a6d803
> 6f2a75369e7561e800d86927ecd83c970996b21f
>
> If used crashkernel=128M, the /proc/iomem looks like this. It used a huge offset.
> 00000000-00000fff : reserved
> 00001000-0009f3ff : System RAM
> 0009f400-0009ffff : reserved
> 000f0000-000fffff : reserved
> 00100000-dfffafff : System RAM
> 01000000-0149a733 : Kernel code
> 0149a734-01afc46f : Kernel data
> 01d9c000-022b18f7 : Kernel bss
> dfffb000-dfffffff : reserved
> f0000000-f1ffffff : 0000:00:02.0
> f2000000-f2000fff : 0000:00:02.0
> f2010000-f201ffff : 0000:00:02.0
> f2020000-f20200ff : 0000:00:03.0
> f2020000-f20200ff : 8139cp
> f2030000-f203ffff : 0000:00:03.0
> fec00000-fec003ff : IOAPIC 0
> fee00000-fee00fff : Local APIC
> fffbc000-ffffffff : reserved
> 100000000-c9fffffff : System RAM
> c98000000-c9fffffff : Crash kernel
>
> On kernels that are working, it automatically found the offset at 32M.
> 00000000-0000ffff : reserved
> 00010000-0009f3ff : System RAM
> 0009f400-0009ffff : reserved
> 000f0000-000fffff : reserved
> 00100000-dfffafff : System RAM
> 01000000-014250bf : Kernel code
> 014250c0-018aca8f : Kernel data
> 01b1f000-01ff7c07 : Kernel bss
> 02000000-09ffffff : Crash kernel
> dfffb000-dfffffff : reserved
> f0000000-f1ffffff : 0000:00:02.0
> f2000000-f2000fff : 0000:00:02.0
> f2010000-f201ffff : 0000:00:02.0
> f2020000-f20200ff : 0000:00:03.0
> f2020000-f20200ff : 8139cp
> f2030000-f203ffff : 0000:00:03.0
> fec00000-fec003ff : IOAPIC 0
> fee00000-fee00fff : Local APIC
> fffbc000-ffffffff : reserved
> 100000000-c9fffffff : System RAM
>
> If specified a fixed offset like crashkernel=128M@32M, it failed reservation.
> initial memory mapped : 0 - 20000000
> init_memory_mapping: 0000000000000000-00000000dfffb000
> 0000000000 - 00dfe00000 page 2M
> 00dfe00000 - 00dfffb000 page 4k
> kernel direct mapping tables up to dfffb000 @ 1fffa000-20000000
> init_memory_mapping: 0000000100000000-0000000ca0000000
> 0100000000 - 0ca0000000 page 2M
> kernel direct mapping tables up to ca0000000 @ dffc7000-dfffb000
> RAMDISK: 37599000 - 37ff0000
> crashkernel reservation failed - memory is in use.
>
> After reverted those commits, it looks like this,
> init_memory_mapping: 0000000000000000-00000000dfffb000
> 0000000000 - 00dfe00000 page 2M
> 00dfe00000 - 00dfffb000 page 4k
> kernel direct mapping tables up to dfffb000 @ 16000-1c000
> init_memory_mapping: 0000000100000000-0000000ca0000000
> 0100000000 - 0ca0000000 page 2M
> kernel direct mapping tables up to ca0000000 @ 1a000-4e000
> RAMDISK: 375c9000 - 37ff0000
> Reserving 128MB of memory at 32MB for crashkernel (System RAM: 51712MB)
yes, default memblock find_range is top_down.
old early_res is from bottom_up.
during the convecting, we do have one x86 find_range from bottom_up, but later
it seems top_down was working on all test cases. ( 32bit etc)
Subject: [PATCH] x86, memblock: Add x86 version of memblock_find_in_range()
Generic version is going from high to low, and it seems it can not find
right area compact enough.
the x86 version will go from goal to limit and just like the way We used
for early_res
use ARCH_FIND_MEMBLOCK_AREA to select from them.
Signed-off-by: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/x86/Kconfig | 8 +++++++
arch/x86/mm/memblock.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
mm/memblock.c | 2 -
3 files changed, 63 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/mm/memblock.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/memblock.c
+++ linux-2.6/arch/x86/mm/memblock.c
@@ -352,3 +352,57 @@ u64 __init memblock_x86_hole_size(u64 st
return end - start - ((u64)ram << PAGE_SHIFT);
}
+
+#ifdef CONFIG_ARCH_MEMBLOCK_FIND_AREA
+/* Check for already reserved areas */
+static inline bool __init check_with_memblock_reserved(u64 *addrp, u64 size, u64 align)
+{
+ u64 addr = *addrp;
+ bool changed = false;
+ struct memblock_region *r;
+again:
+ for_each_memblock(reserved, r) {
+ if ((addr + size) > r->base && addr < (r->base + r->size)) {
+ addr = round_up(r->base + r->size, align);
+ changed = true;
+ goto again;
+ }
+ }
+
+ if (changed)
+ *addrp = addr;
+
+ return changed;
+}
+
+/*
+ * Find a free area with specified alignment in a specific range.
+ */
+u64 __init memblock_find_in_range(u64 start, u64 end, u64 size, u64 align)
+{
+ struct memblock_region *r;
+
+ for_each_memblock(memory, r) {
+ u64 ei_start = r->base;
+ u64 ei_last = ei_start + r->size;
+ u64 addr, last;
+
+ addr = round_up(ei_start, align);
+ if (addr < start)
+ addr = round_up(start, align);
+ if (addr >= ei_last)
+ continue;
+ while (check_with_memblock_reserved(&addr, size, align) && addr+size <= ei_last)
+ ;
+ last = addr + size;
+ if (last > ei_last)
+ continue;
+ if (last > end)
+ continue;
+
+ return addr;
+ }
+
+ return MEMBLOCK_ERROR;
+}
+#endif
Index: linux-2.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -569,6 +569,14 @@ config PARAVIRT_DEBUG
Enable to debug paravirt_ops internals. Specifically, BUG if
a paravirt_op is missing when it is called.
+config ARCH_MEMBLOCK_FIND_AREA
+ default y
+ bool "Use x86 own memblock_find_in_range()"
+ ---help---
+ Use memblock_find_in_range() version instead of generic version, it get free
+ area up from low.
+ Generic one try to get free area down from limit.
+
config NO_BOOTMEM
def_bool y
Index: linux-2.6/mm/memblock.c
===================================================================
--- linux-2.6.orig/mm/memblock.c
+++ linux-2.6/mm/memblock.c
@@ -165,7 +165,7 @@ static phys_addr_t __init_memblock membl
/*
* Find a free area with specified alignment in a specific range.
*/
-u64 __init_memblock memblock_find_in_range(u64 start, u64 end, u64 size, u64 align)
+u64 __init_memblock __weak memblock_find_in_range(u64 start, u64 end, u64 size, u64 align)
{
return memblock_find_base(size, align, start, end);
}
>
> I can't tell where the memory at 32MB was used, but after reverted those commits I can see those early reservations information,
> Subtract (76 early reservations)
> #1 [0001000000 - 0001ff7c08] TEXT DATA BSS
> #2 [00375c9000 - 0037ff0000] RAMDISK
> #3 [0001ff8000 - 0001ff8079] BRK
> #4 [000009f400 - 00000f7fb0] BIOS reserved
> #5 [00000f7fb0 - 00000f7fc0] MP-table mpf
> #6 [00000f822c - 0000100000] BIOS reserved
> #7 [00000f7fc0 - 00000f822c] MP-table mpc
> #8 [0000010000 - 0000012000] TRAMPOLINE
> #9 [0000012000 - 0000016000] ACPI WAKEUP
> #10 [0000016000 - 000001a000] PGTABLE
> #11 [000001a000 - 0000049000] PGTABLE
> #12 [0002000000 - 000a000000] CRASH KERNEL
>
> But after those commits, those information was gone.
memblock could merge reserved area, so can not keep tags with it.
I have local patchset that could print those name tags...
please check
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-2.6-yinghai.git memblock
Yinghai
^ permalink raw reply
* Re: linux-next: manual merge of the bkl-llseek tree with the rr tree
From: Arnd Bergmann @ 2010-09-26 14:52 UTC (permalink / raw)
To: Amit Shah; +Cc: Stephen Rothwell, linux-next, linux-kernel, Rusty Russell
In-Reply-To: <20100916085608.GB8159@amit-laptop.redhat.com>
On Thursday 16 September 2010 10:56:08 Amit Shah wrote:
> On (Thu) Sep 16 2010 [10:20:01], Arnd Bergmann wrote:
> > On Thursday 16 September 2010 08:54:39 Amit Shah wrote:
> > > Arnd, the device is supposed to be non-seekable so I'll add a
> > > nonseekable_open() to the open() call.
> > >
> > > So I guess the llseek operation should ne no_llseek instead of
> > > noop_llseek. Will you change that in your patchset? Should I do that
> > > in the patch I'll queue up?
> >
> > Yes, I think it's best if you just do both changes in your patch, I'll
> > drop this file from my series then.
>
> Great, I'll queue that up.
I don't see this change in linux-next yet. What happened?
Arnd
^ permalink raw reply
* Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
From: caiqian @ 2010-09-26 14:47 UTC (permalink / raw)
To: Yinghai Lu; +Cc: linux-next, kexec, H. Peter Anvin
In-Reply-To: <1834151968.1996101285512089968.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
----- "Yinghai Lu" <yinghai@kernel.org> wrote:
> On 09/25/2010 11:55 PM, CAI Qian wrote:
> >>
> >> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> > No, both kernels were the same version. I am sorry the above logs
> were misleading that were copy-and-pasted from different kernel
> versions.
>
> can you check tip instead of next tree?
No dice,
# /sbin/kexec -p '--command-line=ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet console=tty0 console=ttyS0,115200 crashkernel=128M irqpoll maxcpus=1 reset_devices cgroup_disable=memory ' --initrd=/boot/initrd-2.6.36-rc5-tip+kdump.img /boot/vmlinuz-2.6.36-rc5-tip+
Could not find a free area of memory of a000 bytes...
locate_hole failed
After reverted the whole memblock commits, it was working again,
7950c407c0288b223a200c1bba8198941599ca37
fb74fb6db91abc3c1ceeb9d2c17b44866a12c63e
f88eff74aa848e58b1ea49768c0bbb874b31357f
27de794365786b4cdc3461ed4e23af2a33f40612
9dc5d569c133819c1ce069ebb1d771c62de32580
4d5cf86ce187c0d3a4cdf233ab0cc6526ccbe01f
88ba088c18457caaf8d2e5f8d36becc731a3d4f6
edbe7d23b4482e7f33179290bcff3b1feae1c5f3
6bcc8176d07f108da3b1af17fb2c0e82c80e948e
b52c17ce854125700c4e19d4427d39bf2504ff63
e82d42be24bd5d75bf6f81045636e6ca95ab55f2
301ff3e88ef9ff4bdb92f36a3e6170fce4c9dd34
72d7c3b33c980843e756681fb4867dc1efd62a76
a9ce6bc15100023b411f8117e53a016d61889800
a587d2daebcd2bc159d4348b6a7b028950a6d803
6f2a75369e7561e800d86927ecd83c970996b21f
If used crashkernel=128M, the /proc/iomem looks like this. It used a huge offset.
00000000-00000fff : reserved
00001000-0009f3ff : System RAM
0009f400-0009ffff : reserved
000f0000-000fffff : reserved
00100000-dfffafff : System RAM
01000000-0149a733 : Kernel code
0149a734-01afc46f : Kernel data
01d9c000-022b18f7 : Kernel bss
dfffb000-dfffffff : reserved
f0000000-f1ffffff : 0000:00:02.0
f2000000-f2000fff : 0000:00:02.0
f2010000-f201ffff : 0000:00:02.0
f2020000-f20200ff : 0000:00:03.0
f2020000-f20200ff : 8139cp
f2030000-f203ffff : 0000:00:03.0
fec00000-fec003ff : IOAPIC 0
fee00000-fee00fff : Local APIC
fffbc000-ffffffff : reserved
100000000-c9fffffff : System RAM
c98000000-c9fffffff : Crash kernel
On kernels that are working, it automatically found the offset at 32M.
00000000-0000ffff : reserved
00010000-0009f3ff : System RAM
0009f400-0009ffff : reserved
000f0000-000fffff : reserved
00100000-dfffafff : System RAM
01000000-014250bf : Kernel code
014250c0-018aca8f : Kernel data
01b1f000-01ff7c07 : Kernel bss
02000000-09ffffff : Crash kernel
dfffb000-dfffffff : reserved
f0000000-f1ffffff : 0000:00:02.0
f2000000-f2000fff : 0000:00:02.0
f2010000-f201ffff : 0000:00:02.0
f2020000-f20200ff : 0000:00:03.0
f2020000-f20200ff : 8139cp
f2030000-f203ffff : 0000:00:03.0
fec00000-fec003ff : IOAPIC 0
fee00000-fee00fff : Local APIC
fffbc000-ffffffff : reserved
100000000-c9fffffff : System RAM
If specified a fixed offset like crashkernel=128M@32M, it failed reservation.
initial memory mapped : 0 - 20000000
init_memory_mapping: 0000000000000000-00000000dfffb000
0000000000 - 00dfe00000 page 2M
00dfe00000 - 00dfffb000 page 4k
kernel direct mapping tables up to dfffb000 @ 1fffa000-20000000
init_memory_mapping: 0000000100000000-0000000ca0000000
0100000000 - 0ca0000000 page 2M
kernel direct mapping tables up to ca0000000 @ dffc7000-dfffb000
RAMDISK: 37599000 - 37ff0000
crashkernel reservation failed - memory is in use.
After reverted those commits, it looks like this,
init_memory_mapping: 0000000000000000-00000000dfffb000
0000000000 - 00dfe00000 page 2M
00dfe00000 - 00dfffb000 page 4k
kernel direct mapping tables up to dfffb000 @ 16000-1c000
init_memory_mapping: 0000000100000000-0000000ca0000000
0100000000 - 0ca0000000 page 2M
kernel direct mapping tables up to ca0000000 @ 1a000-4e000
RAMDISK: 375c9000 - 37ff0000
Reserving 128MB of memory at 32MB for crashkernel (System RAM: 51712MB)
I can't tell where the memory at 32MB was used, but after reverted those commits I can see those early reservations information,
Subtract (76 early reservations)
#1 [0001000000 - 0001ff7c08] TEXT DATA BSS
#2 [00375c9000 - 0037ff0000] RAMDISK
#3 [0001ff8000 - 0001ff8079] BRK
#4 [000009f400 - 00000f7fb0] BIOS reserved
#5 [00000f7fb0 - 00000f7fc0] MP-table mpf
#6 [00000f822c - 0000100000] BIOS reserved
#7 [00000f7fc0 - 00000f822c] MP-table mpc
#8 [0000010000 - 0000012000] TRAMPOLINE
#9 [0000012000 - 0000016000] ACPI WAKEUP
#10 [0000016000 - 000001a000] PGTABLE
#11 [000001a000 - 0000049000] PGTABLE
#12 [0002000000 - 000a000000] CRASH KERNEL
But after those commits, those information was gone.
^ permalink raw reply
* Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
From: CAI Qian @ 2010-09-26 10:37 UTC (permalink / raw)
To: Yinghai Lu; +Cc: linux-next, kexec, H. Peter Anvin
In-Reply-To: <4C9EEE98.7020906@kernel.org>
----- "Yinghai Lu" <yinghai@kernel.org> wrote:
> On 09/25/2010 11:55 PM, CAI Qian wrote:
> >>
> >> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> > No, both kernels were the same version. I am sorry the above logs
> were misleading that were copy-and-pasted from different kernel
> versions.
>
> can you check tip instead of next tree?
I am wondering which patches there do you think would make the regression go away?
>
> Yinghai
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
From: Yinghai Lu @ 2010-09-26 6:56 UTC (permalink / raw)
To: CAI Qian; +Cc: linux-next, kexec, H. Peter Anvin
In-Reply-To: <637638372.1993021285484132309.JavaMail.root-k5qu2F3t005+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
On 09/25/2010 11:55 PM, CAI Qian wrote:
>>
>> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> No, both kernels were the same version. I am sorry the above logs were misleading that were copy-and-pasted from different kernel versions.
can you check tip instead of next tree?
Yinghai
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox