* [PATCH] powerpc/mm: Lockless get_user_pages_fast() for 64-bit (v3)
From: Benjamin Herrenschmidt @ 2008-07-30 5:23 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Nick Piggin
From: Nick Piggin <npiggin@suse.de>
Implement lockless get_user_pages_fast for 64-bit powerpc.
Page table existence is guaranteed with RCU, and speculative page references
are used to take a reference to the pages without having a prior existence
guarantee on them.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
v3.
Fix compile without hugetlbfs
v2.
Fix makefile to only build gup.o on 64 bits and fix a bug with
huge pages where we would oops (null dereference) if
huge_pte_offset() returns NULL (ie, not populated yet).
v1.
I'm going to merge this, sending it to the list for reference, it was
in -mm , minus some changes/fixes I did to solve conflicts with the
new multiple huge page sizes.
Index: linux-work/arch/powerpc/Kconfig
===================================================================
--- linux-work.orig/arch/powerpc/Kconfig 2008-07-30 13:17:06.000000000 +1000
+++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.000000000 +1000
@@ -42,6 +42,9 @@ config GENERIC_HARDIRQS
bool
default y
+config HAVE_GET_USER_PAGES_FAST
+ def_bool PPC64
+
config HAVE_SETUP_PER_CPU_AREA
def_bool PPC64
Index: linux-work/arch/powerpc/mm/Makefile
===================================================================
--- linux-work.orig/arch/powerpc/mm/Makefile 2008-07-30 13:17:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/Makefile 2008-07-30 13:42:42.000000000 +1000
@@ -12,7 +12,8 @@ obj-y := fault.o mem.o \
mmu_context_$(CONFIG_WORD_SIZE).o
hash-$(CONFIG_PPC_NATIVE) := hash_native_64.o
obj-$(CONFIG_PPC64) += hash_utils_64.o \
- slb_low.o slb.o stab.o mmap.o $(hash-y)
+ slb_low.o slb.o stab.o \
+ gup.o mmap.o $(hash-y)
obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o
obj-$(CONFIG_PPC_STD_MMU) += hash_low_$(CONFIG_WORD_SIZE).o \
tlb_$(CONFIG_WORD_SIZE).o
Index: linux-work/arch/powerpc/mm/gup.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/mm/gup.c 2008-07-30 15:17:03.000000000 +1000
@@ -0,0 +1,280 @@
+/*
+ * Lockless get_user_pages_fast for powerpc
+ *
+ * Copyright (C) 2008 Nick Piggin
+ * Copyright (C) 2008 Novell Inc.
+ */
+#undef DEBUG
+
+#include <linux/sched.h>
+#include <linux/mm.h>
+#include <linux/hugetlb.h>
+#include <linux/vmstat.h>
+#include <linux/pagemap.h>
+#include <linux/rwsem.h>
+#include <asm/pgtable.h>
+
+/*
+ * The performance critical leaf functions are made noinline otherwise gcc
+ * inlines everything into a single function which results in too much
+ * register pressure.
+ */
+static noinline int gup_pte_range(pmd_t pmd, unsigned long addr,
+ unsigned long end, int write, struct page **pages, int *nr)
+{
+ unsigned long mask, result;
+ pte_t *ptep;
+
+ result = _PAGE_PRESENT|_PAGE_USER;
+ if (write)
+ result |= _PAGE_RW;
+ mask = result | _PAGE_SPECIAL;
+
+ ptep = pte_offset_kernel(&pmd, addr);
+ do {
+ pte_t pte = *ptep;
+ struct page *page;
+
+ if ((pte_val(pte) & mask) != result)
+ return 0;
+ VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
+ page = pte_page(pte);
+ if (!page_cache_get_speculative(page))
+ return 0;
+ if (unlikely(pte != *ptep)) {
+ put_page(page);
+ return 0;
+ }
+ pages[*nr] = page;
+ (*nr)++;
+
+ } while (ptep++, addr += PAGE_SIZE, addr != end);
+
+ return 1;
+}
+
+#ifdef CONFIG_HUGETLB_PAGE
+static noinline int gup_huge_pte(pte_t *ptep, struct hstate *hstate,
+ unsigned long *addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long mask;
+ unsigned long pte_end;
+ struct page *head, *page;
+ pte_t pte;
+ int refs;
+
+ pte_end = (*addr + huge_page_size(hstate)) & huge_page_mask(hstate);
+ if (pte_end < end)
+ end = pte_end;
+
+ pte = *ptep;
+ mask = _PAGE_PRESENT|_PAGE_USER;
+ if (write)
+ mask |= _PAGE_RW;
+ if ((pte_val(pte) & mask) != mask)
+ return 0;
+ /* hugepages are never "special" */
+ VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
+
+ refs = 0;
+ head = pte_page(pte);
+ page = head + ((*addr & ~huge_page_mask(hstate)) >> PAGE_SHIFT);
+ do {
+ VM_BUG_ON(compound_head(page) != head);
+ pages[*nr] = page;
+ (*nr)++;
+ page++;
+ refs++;
+ } while (*addr += PAGE_SIZE, *addr != end);
+
+ if (!page_cache_add_speculative(head, refs)) {
+ *nr -= refs;
+ return 0;
+ }
+ if (unlikely(pte != *ptep)) {
+ /* Could be optimized better */
+ while (*nr) {
+ put_page(page);
+ (*nr)--;
+ }
+ }
+
+ return 1;
+}
+#endif /* CONFIG_HUGETLB_PAGE */
+
+static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long next;
+ pmd_t *pmdp;
+
+ pmdp = pmd_offset(&pud, addr);
+ do {
+ pmd_t pmd = *pmdp;
+
+ next = pmd_addr_end(addr, end);
+ if (pmd_none(pmd))
+ return 0;
+ if (!gup_pte_range(pmd, addr, next, write, pages, nr))
+ return 0;
+ } while (pmdp++, addr = next, addr != end);
+
+ return 1;
+}
+
+static int gup_pud_range(pgd_t pgd, unsigned long addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long next;
+ pud_t *pudp;
+
+ pudp = pud_offset(&pgd, addr);
+ do {
+ pud_t pud = *pudp;
+
+ next = pud_addr_end(addr, end);
+ if (pud_none(pud))
+ return 0;
+ if (!gup_pmd_range(pud, addr, next, write, pages, nr))
+ return 0;
+ } while (pudp++, addr = next, addr != end);
+
+ return 1;
+}
+
+int get_user_pages_fast(unsigned long start, int nr_pages, int write,
+ struct page **pages)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned long addr, len, end;
+ unsigned long next;
+ pgd_t *pgdp;
+ int psize, nr = 0;
+ unsigned int shift;
+
+ pr_debug("%s(%lx,%x,%s)\n", __func__, start, nr_pages, write ? "write" : "read");
+
+ start &= PAGE_MASK;
+ addr = start;
+ len = (unsigned long) nr_pages << PAGE_SHIFT;
+ end = start + len;
+
+ if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
+ start, len)))
+ goto slow_irqon;
+
+ pr_debug(" aligned: %lx .. %lx\n", start, end);
+
+#ifdef CONFIG_HUGETLB_PAGE
+ /* We bail out on slice boundary crossing when hugetlb is
+ * enabled in order to not have to deal with two different
+ * page table formats
+ */
+ if (addr < SLICE_LOW_TOP) {
+ if (end > SLICE_LOW_TOP)
+ goto slow_irqon;
+
+ if (unlikely(GET_LOW_SLICE_INDEX(addr) !=
+ GET_LOW_SLICE_INDEX(end - 1)))
+ goto slow_irqon;
+ } else {
+ if (unlikely(GET_HIGH_SLICE_INDEX(addr) !=
+ GET_HIGH_SLICE_INDEX(end - 1)))
+ goto slow_irqon;
+ }
+#endif /* CONFIG_HUGETLB_PAGE */
+
+ /*
+ * XXX: batch / limit 'nr', to avoid large irq off latency
+ * needs some instrumenting to determine the common sizes used by
+ * important workloads (eg. DB2), and whether limiting the batch size
+ * will decrease performance.
+ *
+ * It seems like we're in the clear for the moment. Direct-IO is
+ * the main guy that batches up lots of get_user_pages, and even
+ * they are limited to 64-at-a-time which is not so many.
+ */
+ /*
+ * This doesn't prevent pagetable teardown, but does prevent
+ * the pagetables from being freed on powerpc.
+ *
+ * So long as we atomically load page table pointers versus teardown,
+ * we can follow the address down to the the page and take a ref on it.
+ */
+ local_irq_disable();
+
+ psize = get_slice_psize(mm, addr);
+ shift = mmu_psize_defs[psize].shift;
+
+#ifdef CONFIG_HUGETLB_PAGE
+ if (unlikely(mmu_huge_psizes[psize])) {
+ pte_t *ptep;
+ unsigned long a = addr;
+ unsigned long sz = ((1UL) << shift);
+ struct hstate *hstate = size_to_hstate(sz);
+
+ BUG_ON(!hstate);
+ /*
+ * XXX: could be optimized to avoid hstate
+ * lookup entirely (just use shift)
+ */
+
+ do {
+ VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm, a)].shift);
+ ptep = huge_pte_offset(mm, a);
+ pr_debug(" %016lx: huge ptep %p\n", a, ptep);
+ if (!ptep || !gup_huge_pte(ptep, hstate, &a, end, write, pages,
+ &nr))
+ goto slow;
+ } while (a != end);
+ } else
+#endif /* CONFIG_HUGETLB_PAGE */
+ {
+ pgdp = pgd_offset(mm, addr);
+ do {
+ pgd_t pgd = *pgdp;
+
+ VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm, addr)].shift);
+ pr_debug(" %016lx: normal pgd %p\n", addr, (void *)pgd);
+ next = pgd_addr_end(addr, end);
+ if (pgd_none(pgd))
+ goto slow;
+ if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
+ goto slow;
+ } while (pgdp++, addr = next, addr != end);
+ }
+ local_irq_enable();
+
+ VM_BUG_ON(nr != (end - start) >> PAGE_SHIFT);
+ return nr;
+
+ {
+ int ret;
+
+slow:
+ local_irq_enable();
+slow_irqon:
+ pr_debug(" slow path ! nr = %d\n", nr);
+
+ /* Try to get the remaining pages with get_user_pages */
+ start += nr << PAGE_SHIFT;
+ pages += nr;
+
+ down_read(&mm->mmap_sem);
+ ret = get_user_pages(current, mm, start,
+ (end - start) >> PAGE_SHIFT, write, 0, pages, NULL);
+ up_read(&mm->mmap_sem);
+
+ /* Have to be a bit careful with return values */
+ if (nr > 0) {
+ if (ret < 0)
+ ret = nr;
+ else
+ ret += nr;
+ }
+
+ return ret;
+ }
+}
Index: linux-work/include/asm-powerpc/pgtable-ppc64.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pgtable-ppc64.h 2008-07-30 13:17:06.000000000 +1000
+++ linux-work/include/asm-powerpc/pgtable-ppc64.h 2008-07-30 13:27:40.000000000 +1000
@@ -461,6 +461,8 @@ void pgtable_cache_init(void);
return pt;
}
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long address);
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
Index: linux-work/include/linux/pagemap.h
===================================================================
--- linux-work.orig/include/linux/pagemap.h 2008-07-30 13:17:06.000000000 +1000
+++ linux-work/include/linux/pagemap.h 2008-07-30 13:27:40.000000000 +1000
@@ -142,6 +142,29 @@ static inline int page_cache_get_specula
return 1;
}
+/*
+ * Same as above, but add instead of inc (could just be merged)
+ */
+static inline int page_cache_add_speculative(struct page *page, int count)
+{
+ VM_BUG_ON(in_interrupt());
+
+#if !defined(CONFIG_SMP) && defined(CONFIG_CLASSIC_RCU)
+# ifdef CONFIG_PREEMPT
+ VM_BUG_ON(!in_atomic());
+# endif
+ VM_BUG_ON(page_count(page) == 0);
+ atomic_add(count, &page->_count);
+
+#else
+ if (unlikely(!atomic_add_unless(&page->_count, count, 0)))
+ return 0;
+#endif
+ VM_BUG_ON(PageCompound(page) && page != compound_head(page));
+
+ return 1;
+}
+
static inline int page_freeze_refs(struct page *page, int count)
{
return likely(atomic_cmpxchg(&page->_count, count, 0) == count);
^ permalink raw reply
* Re: [PATCH] powerpc/lpar - defer prefered console setup
From: Bastian Blank @ 2008-07-30 6:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1217385291.10646.2.camel@localhost>
On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
> On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
> * add_preferred_console - add a device to the list of preferred consoles.
> ...
> * The last preferred console added will be used for kernel messages
> * and stdin/out/err for init.
>
> The last console will be added by the console= parsing, and so that will
> be used. The console we add in the pseries setup is only used if nothing
> is specified on the command line.
Okay, then there is a completely different problem. In the case of
"console=hvc0 console=hvc1" it uses the _first_ add stdin/out bla and
ignores the second one completely.
Bastian
--
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-30 6:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel list
Hi Linus !
Hopefully this one won't be busted... I'll hand back the hat
to paulus for the rest of 2.6.27, but before that, here's a last
pull request.
It brings the powerpc variant of the lockless get_user_pages_fast()
which took some time because I took it out of -mm and had to adjust a
few things, mostly conflicts with other hugetlb stuff that went in.
The diffstat will show a change to drivers/ipmi from Stephen. This
fixes a powerpc specific bit in there and the maintainer hasn't
responded to Stephen so far so we decided to merge it ourselves.
The drivers/serial changes are freescale specific drivers and the
drivers/ide change is a powermac specific driver and has Bart's ack.
Some of the freescale changes look like they aren't purely fixes,
Kumar asked me to pull them as this delay is to blame apparently
on the relevant people doing whatever people do at OLS which doesn't
involve merging patches :-)
So please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Documentation/powerpc/00-INDEX | 2
Documentation/powerpc/SBC8260_memory_mapping.txt | 197 --------------
.../powerpc/dts-bindings/fsl/cpm_qe/serial.txt | 11 +
arch/powerpc/Kconfig | 3
arch/powerpc/boot/dts/mpc832x_mds.dts | 1
arch/powerpc/boot/dts/mpc832x_rdb.dts | 1
arch/powerpc/boot/dts/mpc8349emitx.dts | 1
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 1
arch/powerpc/boot/dts/mpc836x_mds.dts | 1
arch/powerpc/boot/dts/mpc836x_rdk.dts | 16 -
arch/powerpc/boot/dts/mpc8377_mds.dts | 1
arch/powerpc/boot/dts/mpc8378_mds.dts | 1
arch/powerpc/boot/dts/mpc8379_mds.dts | 1
arch/powerpc/boot/dts/mpc8536ds.dts | 1
arch/powerpc/boot/dts/mpc8540ads.dts | 1
arch/powerpc/boot/dts/mpc8541cds.dts | 1
arch/powerpc/boot/dts/mpc8544ds.dts | 1
arch/powerpc/boot/dts/mpc8548cds.dts | 1
arch/powerpc/boot/dts/mpc8555cds.dts | 1
arch/powerpc/boot/dts/mpc8560ads.dts | 1
arch/powerpc/boot/dts/mpc8568mds.dts | 1
arch/powerpc/boot/dts/mpc8572ds.dts | 1
arch/powerpc/kernel/lparcfg.c | 4
arch/powerpc/kernel/ptrace.c | 10 -
arch/powerpc/kernel/ptrace32.c | 2
arch/powerpc/mm/Makefile | 3
arch/powerpc/mm/gup.c | 280 ++++++++++++++++++++
arch/powerpc/platforms/83xx/mpc832x_mds.c | 1
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 1
arch/powerpc/platforms/83xx/mpc834x_itx.c | 1
arch/powerpc/platforms/83xx/mpc834x_mds.c | 1
arch/powerpc/platforms/83xx/mpc836x_mds.c | 1
arch/powerpc/platforms/83xx/sbc834x.c | 1
arch/powerpc/platforms/85xx/ksi8560.c | 1
arch/powerpc/platforms/85xx/mpc8536_ds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 1
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1
arch/powerpc/platforms/85xx/sbc8560.c | 1
arch/powerpc/platforms/8xx/Kconfig | 10 +
arch/powerpc/platforms/Kconfig | 3
arch/powerpc/sysdev/cpm1.c | 267 +++++++++++++++++++
arch/powerpc/sysdev/cpm2.c | 45 +--
arch/powerpc/sysdev/cpm_common.c | 123 +++++++++
arch/powerpc/sysdev/rtc_cmos_setup.c | 23 +-
drivers/char/ipmi/ipmi_si_intf.c | 4
drivers/ide/ppc/pmac.c | 13 +
drivers/serial/cpm_uart/cpm_uart.h | 11 +
drivers/serial/cpm_uart/cpm_uart_core.c | 66 ++++-
include/asm-powerpc/cpm.h | 3
include/asm-powerpc/cpm2.h | 46 ++-
include/asm-powerpc/pgtable-ppc64.h | 2
include/linux/pagemap.h | 23 ++
54 files changed, 907 insertions(+), 290 deletions(-)
delete mode 100644 Documentation/powerpc/SBC8260_memory_mapping.txt
create mode 100644 arch/powerpc/mm/gup.c
Anton Vorontsov (1):
powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC
Benjamin Herrenschmidt (1):
ide/powermac: Fix use of uninitialized pointer on media-bay
Jochen Friedrich (1):
powerpc: implement GPIO LIB API on CPM1 Freescale SoC.
Kim Phillips (1):
powerpc/fsl: proliferate simple-bus compatibility to soc nodes
Kumar Gala (2):
powerpc: clean up the Book-E HW watchpoint support
powerpc: Fix 8xx build failure
Laurent Pinchart (4):
cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
cpm_uart: Modem control lines support
cpm_uart: Add generic clock API support to set baudrates
cpm2: Rework baud rate generators configuration to support external clocks.
Michael Neuling (3):
powerpc: Correctly hookup PTRACE_GET/SETVSRREGS for 32 bit processes
powerpc: Fix ptrace buffer size for VSX
powerpc: Don't use the wrong thread_struct for ptrace get/set VSX regs
Nathan Fontenot (1):
powerpc: Allow non-hcall return values for lparcfg writes
Nick Piggin (1):
powerpc/mm: Lockless get_user_pages_fast() for 64-bit (v3)
Paul Gortmaker (1):
Documentation: remove old sbc8260 board specific information
Stephen Rothwell (1):
ipmi/powerpc: Use linux/of_{device,platform}.h instead of asm
^ permalink raw reply
* Re: [PATCH] powerpc/lpar - defer prefered console setup
From: Bastian Blank @ 2008-07-30 6:29 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080730062313.GA26044@wavehammer.waldi.eu.org>
On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
> On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
> > On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
> > * add_preferred_console - add a device to the list of preferred consoles.
> > ...
> > * The last preferred console added will be used for kernel messages
> > * and stdin/out/err for init.
> >
> > The last console will be added by the console= parsing, and so that will
> > be used. The console we add in the pseries setup is only used if nothing
> > is specified on the command line.
>
> Okay, then there is a completely different problem. In the case of
> "console=hvc0 console=hvc1" it uses the _first_ add stdin/out bla and
> ignores the second one completely.
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
Bastian
--
Intuition, however illogical, is recognized as a command prerogative.
-- Kirk, "Obsession", stardate 3620.7
^ permalink raw reply
* Re: ide pmac breakage
From: Benjamin Herrenschmidt @ 2008-07-30 6:57 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <200807292126.12238.bzolnier@gmail.com>
On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:
> I WON!!!
Only half...
It goes further and then blows up again. First problem is, this
unregister interface doesn't quite convey the fact that the HW is gone
and the IDE code seems to take it's sweet time figuring it out after
trying some requests. Maybe something smarter can be done here ? ie,
ide_set_interface_dead() :-)
mediabay0: switching to 7
mediabay0: powering down
media bay 0 is empty
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
Then after this couple of failed attempts at sending commands, it
crashes with the backtrace below. Another NULL dereference apparently,
though the DAR value (the faulting address) has been slightly different
between consecutive tests so it may be a use-after-free too.
Note that there shouldn't be anything fundamentally different from
ide-pmac here vs. something like pcmcia IDE cards... do you have one of
these to test with ?
Vector: 300 (Data Access) at [c59dfdc0]
pc: c0211f78: ide_device_put+0x18/0x58
lr: c0223c34: ide_cd_put+0x40/0x5c
sp: c59dfe70
msr: 9032
dar: 10
dsisr: 40000000
current = 0xc58a9880
pid = 843, comm = media-bay
enter ? for help
[c59dfe80] c0223c34 ide_cd_put+0x40/0x5c
[c59dfea0] c02114d4 generic_ide_remove+0x28/0x3c
[c59dfeb0] c01ea108 __device_release_driver+0x78/0xb4
[c59dfec0] c01ea218 device_release_driver+0x28/0x44
[c59dfee0] c01e9350 bus_remove_device+0xac/0xd8
[c59dff00] c01e77f8 device_del+0x104/0x198
[c59dff20] c01e78a4 device_unregister+0x18/0x30
[c59dff40] c0212598 __ide_port_unregister_devices+0x6c/0x88
[c59dff60] c021276c ide_port_unregister_devices+0x38/0x80
[c59dff80] c0209078 media_bay_step+0x1cc/0x5c0
[c59dffb0] c02094f8 media_bay_task+0x8c/0xcc
[c59dffd0] c0048640 kthread+0x48/0x84
[c59dfff0] c0011b38 kernel_thread+0x44/0x60
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
From: Nick Piggin @ 2008-07-30 7:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1217394520.11188.298.camel@pasglop>
On Wed, Jul 30, 2008 at 03:08:40PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2008-07-30 at 15:06 +1000, Michael Ellerman wrote:
> > > +
> > > +/*
> > > + * The performance critical leaf functions are made noinline otherwise gcc
> > > + * inlines everything into a single function which results in too much
> > > + * register pressure.
> > > + */
> >
> > This strikes me as something that is liable to change for compiler
> > version n+1, or n with -fsomething - and might leave us shooting
> > ourselves in the foot, just a thought.
> >
>
> Not that much I'd say... In fact, I wouldn't be too worried on powerpc,
> I wonder if that comment is stale from the x86 variant :-) Nick ?
Right... gcc is really poor at over pressuing registers when inlining,
and when I checked I don't think it even allocated registers to the
inner-most variables in cases such as this.
I thought I checked powerpc and sound some spilling there too, but it
was quite a long time ago (and yes it was brought over from x86). Should
double check.
^ permalink raw reply
* [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
From: Bastian Blank @ 2008-07-30 7:34 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Benjamin Herrenschmidt; +Cc: linux-kernel
In-Reply-To: <20080730062919.GA27281@wavehammer.waldi.eu.org>
On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
> Okay, so hvc_console is the culprit. It don't register a preferred
> console if it knows it is not the first in the list.
The patch registers all available hvc consoles. It adds one "struct
console" for all possible hvc consoles.
Signed-off-by: Bastian Blank <waldi@debian.org>
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 44160d5..143a4b2 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -137,15 +137,36 @@ static struct hvc_struct *hvc_get_by_index(int index)
}
+static void hvc_console_print(struct console *co, const char *b,
+ unsigned count);
+static struct tty_driver *hvc_console_device(struct console *c, int *index);
+static int __init hvc_console_setup(struct console *co, char *options);
+
/*
* Initial console vtermnos for console API usage prior to full console
* initialization. Any vty adapter outside this range will not have usable
* console interfaces but can still be used as a tty device. This has to be
* static because kmalloc will not work during early console init.
*/
-static struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
-static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
- {[0 ... MAX_NR_HVC_CONSOLES - 1] = -1};
+struct hvc_console
+{
+ uint32_t vtermno;
+ struct hv_ops *ops;
+ struct console console;
+};
+static struct hvc_console consoles[MAX_NR_HVC_CONSOLES] = {
+ [0 ... MAX_NR_HVC_CONSOLES - 1] = {
+ .vtermno = -1,
+ .console = {
+ .name = "hvc",
+ .write = hvc_console_print,
+ .device = hvc_console_device,
+ .setup = hvc_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ },
+ }
+};
/*
* Console APIs, NOT TTY. These APIs are available immediately when
@@ -164,7 +185,7 @@ static void hvc_console_print(struct console *co, const char *b,
return;
/* This console adapter was removed so it is not usable. */
- if (vtermnos[index] < 0)
+ if (consoles[index].vtermno < 0)
return;
while (count > 0 || i > 0) {
@@ -178,7 +199,7 @@ static void hvc_console_print(struct console *co, const char *b,
--count;
}
} else {
- r = cons_ops[index]->put_chars(vtermnos[index], c, i);
+ r = consoles[index].ops->put_chars(consoles[index].vtermno, c, i);
if (r < 0) {
/* throw away chars on error */
i = 0;
@@ -193,7 +214,7 @@ static void hvc_console_print(struct console *co, const char *b,
static struct tty_driver *hvc_console_device(struct console *c, int *index)
{
- if (vtermnos[c->index] == -1)
+ if (consoles[c->index].vtermno == -1)
return NULL;
*index = c->index;
@@ -205,43 +226,12 @@ static int __init hvc_console_setup(struct console *co, char *options)
if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES)
return -ENODEV;
- if (vtermnos[co->index] == -1)
+ if (consoles[co->index].vtermno == -1)
return -ENODEV;
return 0;
}
-static struct console hvc_con_driver = {
- .name = "hvc",
- .write = hvc_console_print,
- .device = hvc_console_device,
- .setup = hvc_console_setup,
- .flags = CON_PRINTBUFFER,
- .index = -1,
-};
-
-/*
- * Early console initialization. Precedes driver initialization.
- *
- * (1) we are first, and the user specified another driver
- * -- index will remain -1
- * (2) we are first and the user specified no driver
- * -- index will be set to 0, then we will fail setup.
- * (3) we are first and the user specified our driver
- * -- index will be set to user specified driver, and we will fail
- * (4) we are after driver, and this initcall will register us
- * -- if the user didn't specify a driver then the console will match
- *
- * Note that for cases 2 and 3, we will match later when the io driver
- * calls hvc_instantiate() and call register again.
- */
-static int __init hvc_console_init(void)
-{
- register_console(&hvc_con_driver);
- return 0;
-}
-console_initcall(hvc_console_init);
-
/* callback when the kboject ref count reaches zero. */
static void destroy_hvc_struct(struct kref *kref)
{
@@ -267,12 +257,13 @@ static void destroy_hvc_struct(struct kref *kref)
*/
int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops)
{
+ struct hvc_console *hc;
struct hvc_struct *hp;
if (index < 0 || index >= MAX_NR_HVC_CONSOLES)
return -1;
- if (vtermnos[index] != -1)
+ if (consoles[index].vtermno != -1)
return -1;
/* make sure no no tty has been registered in this index */
@@ -282,19 +273,17 @@ int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops)
return -1;
}
- vtermnos[index] = vtermno;
- cons_ops[index] = ops;
+ hc = &consoles[index];
+
+ hc->vtermno = vtermno;
+ hc->ops = ops;
+ hc->console.index = index;
/* reserve all indices up to and including this index */
if (last_hvc < index)
last_hvc = index;
- /* if this index is what the user requested, then register
- * now (setup won't fail at this point). It's ok to just
- * call register again if previously .setup failed.
- */
- if (index == hvc_con_driver.index)
- register_console(&hvc_con_driver);
+ register_console(&hc->console);
return 0;
}
@@ -637,7 +626,7 @@ static int hvc_poll(struct hvc_struct *hp)
}
for (i = 0; i < n; ++i) {
#ifdef CONFIG_MAGIC_SYSRQ
- if (hp->index == hvc_con_driver.index) {
+ if (consoles[hp->index].console.flags & CON_CONSDEV) {
/* Handle the SysRq Hack */
/* XXX should support a sequence */
if (buf[i] == '\x0f') { /* ^O */
@@ -775,8 +764,8 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int irq,
* see if this vterm id matches one registered for console.
*/
for (i=0; i < MAX_NR_HVC_CONSOLES; i++)
- if (vtermnos[i] == hp->vtermno &&
- cons_ops[i] == hp->ops)
+ if (consoles[i].vtermno == hp->vtermno &&
+ consoles[i].ops == hp->ops)
break;
/* no matching slot, just use a counter */
@@ -800,7 +789,7 @@ int __devexit hvc_remove(struct hvc_struct *hp)
tty = hp->tty;
if (hp->index < MAX_NR_HVC_CONSOLES)
- vtermnos[hp->index] = -1;
+ consoles[hp->index].vtermno = -1;
/* Don't whack hp->irq because tty_hangup() will need to free the irq. */
@@ -881,13 +870,16 @@ out:
*/
static void __exit hvc_exit(void)
{
+ int i;
+
if (hvc_driver) {
kthread_stop(hvc_task);
tty_unregister_driver(hvc_driver);
/* return tty_struct instances allocated in hvc_init(). */
put_tty_driver(hvc_driver);
- unregister_console(&hvc_con_driver);
+ for (i = 0; i < MAX_NR_HVC_CONSOLES; i++)
+ unregister_console(&consoles->console);
}
}
module_exit(hvc_exit);
--
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
^ permalink raw reply related
* Board is not booting - Please Help me
From: Naresh Bhat @ 2008-07-30 7:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 1563 bytes --]
Hi Guys
I have ML507 board. By using "ml507_bsb_design_ppc440.zip"
I have created the "Base System Builder" project and also
I am able to create the following files sucessfully.
1. My own "DTS" file (attached with the mail)
2. My own "download.bit" file
3. My own ACE file. (Used the Montavista Pro 5.0 kernel., Kernel is compiled
with ARCH=powerpc, CROSS_COMPILE=ppc_440-, used the ml507_defconfig)
*My problem is:*
The ML507 board Booting and nothing will be displayed after device flat
tree(see the below Logs).
please help me on this what could be the problem?.
*LOGS:*
=======================================
* Welcome to the Xilinx Virtex-5 ML507 Evaluation Platform Bootloader Menu!
Please choose a demo by typing in the number of the demo you want to use
Or select a demo using the directional buttons (C,W,S,E,N)
(Then press the center (C) button to start the selected demo)
1. Virtex-5 Slide Show
2. Web Server Demo
3. Simon Game
4. Board Diagnostics (XROM)
5. USB Demo
6. My own ACE file
7. Ring Tone Player
Rebooting to System ACE Configuration Address 6...
booting virtex
memstart=0x10
memsize=0xf
zImage starting: loaded at 0x00400000 (sp: 0x00851eb8)
Allocating 0x33770c bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x00580d73)...done 0x312590 bytes
Attached initrd image at 0x00581000-0x00850e21
initrd head: 0x1f8b0808
Linux/PowerPC load: console=ttyS0,9600 ip=off root=/dev/ram rw
Finalizing device tree... flat tree at 0x85e300*
======================================================================
--
Naresh Bhat
[-- Attachment #1.2: Type: text/html, Size: 3633 bytes --]
[-- Attachment #2: fdt.dts --]
[-- Type: application/octet-stream, Size: 8669 bytes --]
/*
* (C) Copyright 2007-2008 Xilinx, Inc.
* (C) Copyright 2007-2008 Michal Simek
*
* Michal SIMEK <monstr@monstr.eu>
*
* 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
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 10.1.02 EDK_K_SP2.5
*/
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,virtex";
dcr-parent = <&ppc440_0>;
model = "testing";
DDR2_SDRAM: memory@0 {
device_type = "memory";
reg = < 0 10000000 >;
} ;
chosen {
bootargs = "console=ttyS0,9600 root=/dev/nfs rw";
} ;
cpus {
#address-cells = <1>;
#cpus = <1>;
#size-cells = <0>;
ppc440_0: cpu@0 {
#address-cells = <1>;
#size-cells = <1>;
clock-frequency = "";
compatible = "PowerPC,440", "ibm,ppc440";
d-cache-line-size = <20>;
d-cache-size = <8000>;
dcr-access-method = "native";
dcr-controller ;
device_type = "cpu";
i-cache-line-size = <20>;
i-cache-size = <8000>;
model = "PowerPC,440";
reg = <0>;
timebase-frequency = "";
xlnx,apu-control = <2000>;
xlnx,apu-udi-0 = <0>;
xlnx,apu-udi-1 = <0>;
xlnx,apu-udi-10 = <0>;
xlnx,apu-udi-11 = <0>;
xlnx,apu-udi-12 = <0>;
xlnx,apu-udi-13 = <0>;
xlnx,apu-udi-14 = <0>;
xlnx,apu-udi-15 = <0>;
xlnx,apu-udi-2 = <0>;
xlnx,apu-udi-3 = <0>;
xlnx,apu-udi-4 = <0>;
xlnx,apu-udi-5 = <0>;
xlnx,apu-udi-6 = <0>;
xlnx,apu-udi-7 = <0>;
xlnx,apu-udi-8 = <0>;
xlnx,apu-udi-9 = <0>;
xlnx,dcr-autolock-enable = <1>;
xlnx,dcu-rd-ld-cache-plb-prio = <0>;
xlnx,dcu-rd-noncache-plb-prio = <0>;
xlnx,dcu-rd-touch-plb-prio = <0>;
xlnx,dcu-rd-urgent-plb-prio = <0>;
xlnx,dcu-wr-flush-plb-prio = <0>;
xlnx,dcu-wr-store-plb-prio = <0>;
xlnx,dcu-wr-urgent-plb-prio = <0>;
xlnx,dma0-control = <0>;
xlnx,dma0-plb-prio = <0>;
xlnx,dma0-rxchannelctrl = <1010000>;
xlnx,dma0-rxirqtimer = <3ff>;
xlnx,dma0-txchannelctrl = <1010000>;
xlnx,dma0-txirqtimer = <3ff>;
xlnx,dma1-control = <0>;
xlnx,dma1-plb-prio = <0>;
xlnx,dma1-rxchannelctrl = <1010000>;
xlnx,dma1-rxirqtimer = <3ff>;
xlnx,dma1-txchannelctrl = <1010000>;
xlnx,dma1-txirqtimer = <3ff>;
xlnx,dma2-control = <0>;
xlnx,dma2-plb-prio = <0>;
xlnx,dma2-rxchannelctrl = <1010000>;
xlnx,dma2-rxirqtimer = <3ff>;
xlnx,dma2-txchannelctrl = <1010000>;
xlnx,dma2-txirqtimer = <3ff>;
xlnx,dma3-control = <0>;
xlnx,dma3-plb-prio = <0>;
xlnx,dma3-rxchannelctrl = <1010000>;
xlnx,dma3-rxirqtimer = <3ff>;
xlnx,dma3-txchannelctrl = <1010000>;
xlnx,dma3-txirqtimer = <3ff>;
xlnx,endian-reset = <0>;
xlnx,generate-plb-timespecs = <1>;
xlnx,icu-rd-fetch-plb-prio = <0>;
xlnx,icu-rd-spec-plb-prio = <0>;
xlnx,icu-rd-touch-plb-prio = <0>;
xlnx,interconnect-imask = <ffffffff>;
xlnx,mplb-allow-lock-xfer = <1>;
xlnx,mplb-arb-mode = <0>;
xlnx,mplb-awidth = <20>;
xlnx,mplb-counter = <500>;
xlnx,mplb-dwidth = <80>;
xlnx,mplb-max-burst = <8>;
xlnx,mplb-native-dwidth = <80>;
xlnx,mplb-p2p = <0>;
xlnx,mplb-prio-dcur = <2>;
xlnx,mplb-prio-dcuw = <3>;
xlnx,mplb-prio-icu = <4>;
xlnx,mplb-prio-splb0 = <1>;
xlnx,mplb-prio-splb1 = <0>;
xlnx,mplb-read-pipe-enable = <1>;
xlnx,mplb-sync-tattribute = <0>;
xlnx,mplb-wdog-enable = <1>;
xlnx,mplb-write-pipe-enable = <1>;
xlnx,mplb-write-post-enable = <1>;
xlnx,num-dma = <0>;
xlnx,pir = <f>;
xlnx,ppc440mc-addr-base = <0>;
xlnx,ppc440mc-addr-high = <fffffff>;
xlnx,ppc440mc-arb-mode = <0>;
xlnx,ppc440mc-bank-conflict-mask = <c00000>;
xlnx,ppc440mc-control = <f810008f>;
xlnx,ppc440mc-max-burst = <8>;
xlnx,ppc440mc-prio-dcur = <2>;
xlnx,ppc440mc-prio-dcuw = <3>;
xlnx,ppc440mc-prio-icu = <4>;
xlnx,ppc440mc-prio-splb0 = <1>;
xlnx,ppc440mc-prio-splb1 = <0>;
xlnx,ppc440mc-row-conflict-mask = <3ffe00>;
xlnx,ppcdm-asyncmode = <0>;
xlnx,ppcds-asyncmode = <0>;
xlnx,user-reset = <0>;
} ;
} ;
plb_v46_0: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.03.a", "simple-bus";
ranges ;
DIP_Switches_8Bit: gpio@81460000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 81460000 10000 >;
xlnx,all-inputs = <1>;
xlnx,all-inputs-2 = <0>;
xlnx,dout-default = <0>;
xlnx,dout-default-2 = <0>;
xlnx,family = "virtex5";
xlnx,gpio-width = <8>;
xlnx,interrupt-present = <0>;
xlnx,is-bidir = <1>;
xlnx,is-bidir-2 = <1>;
xlnx,is-dual = <0>;
xlnx,tri-default = <ffffffff>;
xlnx,tri-default-2 = <ffffffff>;
} ;
IIC_EEPROM: i2c@81600000 {
compatible = "xlnx,xps-iic-2.00.a";
interrupt-parent = <&xps_intc_0>;
interrupts = < 1 2 >;
reg = < 81600000 10000 >;
xlnx,clk-freq = <5f5e100>;
xlnx,family = "virtex5";
xlnx,gpo-width = <1>;
xlnx,iic-freq = <186a0>;
xlnx,scl-inertial-delay = <0>;
xlnx,sda-inertial-delay = <0>;
xlnx,ten-bit-adr = <0>;
} ;
LEDs_8Bit: gpio@81400000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 81400000 10000 >;
xlnx,all-inputs = <0>;
xlnx,all-inputs-2 = <0>;
xlnx,dout-default = <0>;
xlnx,dout-default-2 = <0>;
xlnx,family = "virtex5";
xlnx,gpio-width = <8>;
xlnx,interrupt-present = <0>;
xlnx,is-bidir = <1>;
xlnx,is-bidir-2 = <1>;
xlnx,is-dual = <0>;
xlnx,tri-default = <ffffffff>;
xlnx,tri-default-2 = <ffffffff>;
} ;
LEDs_Positions: gpio@81420000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 81420000 10000 >;
xlnx,all-inputs = <0>;
xlnx,all-inputs-2 = <0>;
xlnx,dout-default = <0>;
xlnx,dout-default-2 = <0>;
xlnx,family = "virtex5";
xlnx,gpio-width = <5>;
xlnx,interrupt-present = <0>;
xlnx,is-bidir = <1>;
xlnx,is-bidir-2 = <1>;
xlnx,is-dual = <0>;
xlnx,tri-default = <ffffffff>;
xlnx,tri-default-2 = <ffffffff>;
} ;
Push_Buttons_5Bit: gpio@81440000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 81440000 10000 >;
xlnx,all-inputs = <1>;
xlnx,all-inputs-2 = <0>;
xlnx,dout-default = <0>;
xlnx,dout-default-2 = <0>;
xlnx,family = "virtex5";
xlnx,gpio-width = <5>;
xlnx,interrupt-present = <0>;
xlnx,is-bidir = <1>;
xlnx,is-bidir-2 = <1>;
xlnx,is-dual = <0>;
xlnx,tri-default = <ffffffff>;
xlnx,tri-default-2 = <ffffffff>;
} ;
RS232_Uart_1: serial@83e00000 {
clock-frequency = <5f5e100>;
compatible = "xlnx,xps-uart16550-2.00.a", "ns16550";
current-speed = <2580>;
device_type = "serial";
interrupt-parent = <&xps_intc_0>;
interrupts = < 3 2 >;
reg = < 83e00000 10000 >;
reg-offset = <3>;
reg-shift = <2>;
xlnx,family = "virtex5";
xlnx,has-external-rclk = <0>;
xlnx,has-external-xin = <0>;
xlnx,is-a-16550 = <1>;
} ;
RS232_Uart_2: serial@83e20000 {
clock-frequency = <5f5e100>;
compatible = "xlnx,xps-uart16550-2.00.a", "ns16550";
current-speed = <2580>;
device_type = "serial";
interrupt-parent = <&xps_intc_0>;
interrupts = < 2 2 >;
reg = < 83e20000 10000 >;
reg-offset = <3>;
reg-shift = <2>;
xlnx,family = "virtex5";
xlnx,has-external-rclk = <0>;
xlnx,has-external-xin = <0>;
xlnx,is-a-16550 = <1>;
} ;
SysACE_CompactFlash: sysace@83600000 {
compatible = "xlnx,xps-sysace-1.00.a";
interrupt-parent = <&xps_intc_0>;
interrupts = < 0 2 >;
reg = < 83600000 10000 >;
xlnx,family = "virtex5";
xlnx,mem-width = <10>;
} ;
xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffff0000 {
compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
reg = < ffff0000 10000 >;
xlnx,family = "virtex5";
} ;
xps_intc_0: interrupt-controller@81800000 {
#interrupt-cells = <2>;
compatible = "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg = < 81800000 10000 >;
xlnx,num-intr-inputs = <4>;
} ;
} ;
} ;
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Andrew Morton @ 2008-07-30 8:41 UTC (permalink / raw)
To: Eric Munson; +Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev
In-Reply-To: <cover.1216928613.git.ebmunson@us.ibm.com>
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <ebmunson@us.ibm.com> wrote:
> Certain workloads benefit if their data or text segments are backed by
> huge pages. The stack is no exception to this rule but there is no
> mechanism currently that allows the backing of a stack reliably with
> huge pages. Doing this from userspace is excessively messy and has some
> awkward restrictions. Particularly on POWER where 256MB of address space
> gets wasted if the stack is setup there.
>
> This patch stack introduces a personality flag that indicates the kernel
> should setup the stack as a hugetlbfs-backed region. A userspace utility
> may set this flag then exec a process whose stack is to be backed by
> hugetlb pages.
>
> Eric Munson (5):
> Align stack boundaries based on personality
> Add shared and reservation control to hugetlb_file_setup
> Split boundary checking from body of do_munmap
> Build hugetlb backed process stacks
> [PPC] Setup stack memory segment for hugetlb pages
>
> arch/powerpc/mm/hugetlbpage.c | 6 +
> arch/powerpc/mm/slice.c | 11 ++
> fs/exec.c | 209 ++++++++++++++++++++++++++++++++++++++---
> fs/hugetlbfs/inode.c | 52 +++++++----
> include/asm-powerpc/hugetlb.h | 3 +
> include/linux/hugetlb.h | 22 ++++-
> include/linux/mm.h | 1 +
> include/linux/personality.h | 3 +
> ipc/shm.c | 2 +-
> mm/mmap.c | 11 ++-
> 10 files changed, 284 insertions(+), 36 deletions(-)
That all looks surprisingly straightforward.
Might there exist an x86 port which people can play with?
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Andrew Morton @ 2008-07-30 8:43 UTC (permalink / raw)
To: Eric Munson; +Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev
In-Reply-To: <cover.1216928613.git.ebmunson@us.ibm.com>
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <ebmunson@us.ibm.com> wrote:
> Certain workloads benefit if their data or text segments are backed by
> huge pages.
oh. As this is a performance patch, it would be much better if its
description contained some performance measurement results! Please.
^ permalink raw reply
* initrd : no cpio magic
From: Fabien Oriede @ 2008-07-30 9:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]
Hi all,
I'm working with a custom board (MPC860T, 8MB FLASH, 4MB SDRAM, serial port on SCC1). U-Boot (version 1.3.2) works fine. Now I'm trying to put an initrd image to boot the kernel (version 2.6.24). I have followed this topic : http://www.denx.de/wiki/view/DULG/LinuxRamdiskRoot. I have downloaded pRamdisk from ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_8xx/?cf0A21F201=2217AE7A!VDAwMjgxMTg6bGRhcDqY+Fsd/NseZr/2SQTpUyuD to test with a correct initrd. Now my uImage is at address 0xFFA00000 and the initrd image is at 0xFFC00000. When I use the command "bootm FFA00000 FFC00000", I have the following log on my terminal :
bootm ffa00000 ffc00000
## Booting image at ffa00000 ...
Image Name: Linux-2.6.24
Created: 2011-02-14 15:42:10 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 631621 Bytes = 616.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x003B8D78 => set upper limit to 0x003B8570
## cmdline at 0x003B8470 ... 0x003B8493
bd address = 0x003B8FC4
memstart = 0x00000000
memsize = 0x00400000
flashstart = 0xFF800000
flashsize = 0x00800000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xFFE00000
bootflags = 0x00000001
intfreq = 40 MHz
busfreq = 40 MHz
ethaddr = 00:00:00:00:00:00
IP addr = 0.0.0.0
baudrate = 38400 bps
Not skipping initrd
## Loading RAMDisk Image at ffc00000 ...
Image Name: Simple Embedded Linux Framework
Created: 2002-10-24 4:56:06 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1459535 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0xFFC00040 ... 0xFFD6458E (len=1459535=0x16454F)
Loading Ramdisk to 00253000, end 003b754f ... OK
## Transferring control to Linux (at address 00000000) ...
Linux version 2.6.24 (root@localhost.localdomain) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #5 Mon Feb 14 16:42:09 CET 2011
Zone PFN ranges:
DMA 0 -> 1024
Normal 1024 -> 1024
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 1024
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 1016
Kernel command line: console=ttyCPM0,38400 root=/dev/ram
PID hash table entries: 16 (order: 4, 64 bytes)
Decrementer Frequency = 150000000/60
Console: colour dummy device 80x25
cpm_uart: console: compat mode
console [ttyCPM0] enabled
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 1192k available (1088k kernel code, 260k data, 68k init, 0k highmem)
SLUB: Genslabs=11, HWalign=16, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
Unpacking initramfs...<0>Kernel panic - not syncing: no cpio magic
Rebooting in 180 seconds..
It seems that it recognize the initrd, but there is an error on cpio magic, may be the inirtd was not made with cpio. Can I add the cpio part in the header of the initrd ? (if I'm not wrong of course)
I have seen a lot of topics, tutorials on the web, but they don't explain much which files I need to put in my initrd. That's why I have downloaded this pRamdisk to test.
Someone can help me with my problem please ?
Thanks.
Fabien.
_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
[-- Attachment #2: Type: text/html, Size: 4967 bytes --]
^ permalink raw reply
* Warning: Uable to open an inital console
From: Vijay Nikam @ 2008-07-30 9:14 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 6893 bytes --]
Hello all,
I have mpc8313erdb board and trying boot the kernel from NAND flash ...
The kernel is booting fine but it hangs at the following message;
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
Following is the log of the kernel booting ...
########################################## LOG START
########################################
NAND SPL - U-Boot 1.1.6 (Jul 28 2008 - 21:40:02) MPC83XX
Loading from NAND : ........................
U-Boot 1.1.6 (Jul 28 2008 - 21:39:41) MPC83XX
Clock configuration:
Coherent System Bus: 166 MHz
Core: 333 MHz
Local Bus Controller: 166 MHz
Local Bus: 41 MHz
DDR: 333 MHz
SEC: 55 MHz
I2C1: 166 MHz
I2C2: 166 MHz
TSEC1: 166 MHz
TSEC2: 166 MHz
USB MPH: 0 MHz
USB DR: 55 MHz
CPU: MPC8313E, Rev: 10 at 333.333 MHz
Board: Freescale MPC8313ERDB
I2C: ready
DRAM: Initializing
DDR RAM: 128 MB
FLASH: 8 MB
NAND: 32 MiB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
Hit any key to stop autoboot: 0
Loading from NAND 32MiB 3,3V 8-bit, offset 0x100000
Image Name: Linux-2.6.20
Created: 2008-07-28 16:15:15 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1716719 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
## Booting image at 00200000 ...
Image Name: Linux-2.6.20
Created: 2008-07-28 16:15:15 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1716719 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
setup_arch: bootmem
mpc8313_rdb_setup_arch()
arch: exit
Using MPC8313 RDB machine description
Linux version 2.6.20 (vijay@localhost.localdomain) (gcc version 4.0.2
20060628 (Wasabi)) #8 Mon Jul 28 21:45:12 IST 2008
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number:
0->0
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists. Total pages: 32512
Kernel command line: root=/dev/mtdblock3 rootfstype=jffs2 rw
console=ttyS0,115200
mtdparts=nand0:1M(u-boot),3M(kernel),256K(devtb),-(jffs)
IPIC (128 IRQ sources) at fdefa700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126164k/131072k available (2988k kernel code, 4764k reserved, 464k
data, 96k bss, 144k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (25 seconds)
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.4, 00:04:9f:ef:23:33
eth0: MTU = 1500 (frame size=1540,truesize=2296)
eth0: Running with NAPI enabled
eth0: 64/64 RX/TX BD ring size
eth0: Socket buffer recycling mode enabled
eth1: Gianfar Ethernet Controller Version 1.4, 00:e0:0c:00:7e:21
eth1: MTU = 1500 (frame size=1540,truesize=2296)
eth1: Running with NAPI enabled
eth1: 64/64 RX/TX BD ring size
eth1: Socket buffer recycling mode enabled
SKB Handler initialized(max=64)
Marvell 88E1101: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
MPC8313ERDB Ethernet Switch: Registered new driver
MPC8313RDB flash device: 800000 at fe000000 Partition number 4
MPC8313RDB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
MPC8313RDB Flash Map Info: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 4 MTD partitions on "MPC8313RDB Flash Map Info":
0x00000000-0x00100000 : "U-Boot"
0x00100000-0x00300000 : "Kernel"
0x00300000-0x00700000 : "JFFS2"
0x00700000-0x00800000 : "dtb"
MPC8313RDB flash device (MPC8313RDB Flash Map Info) initialized
Freescale eLBC NAND Driver (C) 2006 Freescale
NAND device: Manufacturer ID: 0xec, Chip ID: 0x75 (Samsung NAND 32MiB 3,3V
8-bit)
Scanning device for bad blocks
4 cmdlinepart partitions found on MTD device nand0
Creating 4 MTD partitions on "nand0":
0x00000000-0x00100000 : "u-boot"
0x00100000-0x00400000 : "kernel"
0x00400000-0x00440000 : "devtb"
0x00440000-0x02000000 : "jffs"
usbmon: debugfs is not available
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Freescale High-Speed USB SOC Device Controller driver (Feb 5, 2007)
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 144k init
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
<0>Rebooting in 180 seconds..
########################################################## LOG END
#########################################################
Can anyone suggest someway to proceed ... thanks ...
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
[-- Attachment #2: Type: text/html, Size: 9166 bytes --]
^ permalink raw reply
* Re: [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
From: Milton Miller @ 2008-07-30 9:13 UTC (permalink / raw)
To: Bastian Blank; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080730073438.GA29700@wavehammer.waldi.eu.org>
On Wed Jul 30 at 17:34:38 EST in 2008, Bastian Blank wrote:
> On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
>> Okay, so hvc_console is the culprit. It don't register a preferred
>> console if it knows it is not the first in the list.
>
> The patch registers all available hvc consoles. It adds one "struct
> console" for all possible hvc consoles.
[ a 6 page patch adding forward declartions, arrays of console
structs, moving lots of code and creating N struct console in the
hvc_driver shell]
After previously having written:
> On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
>> On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
>>> On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
>>> * add_preferred_console - add a device to the list of preferred consoles.
>>> ...
>>> * The last preferred console added will be used for kernel messages
>>> * and stdin/out/err for init.
>>>
>>> The last console will be added by the console= parsing, and so that will
>>> be used. The console we add in the pseries setup is only used if nothing
>>> is specified on the command line.
>>
>> Okay, then there is a completely different problem. In the case of
>> "console=hvc0 console=hvc1" it uses the _first_ add stdin/out bla and
>> ignores the second one completely.
>
> Okay, so hvc_console is the culprit. It don't register a preferred
> console if it knows it is not the first in the list.
>
> Bastian
[ back to the patch ]
> -/*
> - * Early console initialization. Precedes driver initialization.
> - *
> - * (1) we are first, and the user specified another driver
> - * -- index will remain -1
> - * (2) we are first and the user specified no driver
> - * -- index will be set to 0, then we will fail setup.
> - * (3) we are first and the user specified our driver
> - * -- index will be set to user specified driver, and we will fail
> - * (4) we are after driver, and this initcall will register us
> - * -- if the user didn't specify a driver then the console will match
> - *
> - * Note that for cases 2 and 3, we will match later when the io driver
> - * calls hvc_instantiate() and call register again.
> - */
> -static int __init hvc_console_init(void)
> -{
> - register_console(&hvc_con_driver);
> - return 0;
>
Please explain how the reasoning you removed breaks down.
What is your usage case?
More importantly , how is this different than, say, drivers/serial/8250.c,
which also registers just one struct console?
would not console=ttyS0 console=ttyS1 have the same problem?
Please instrument the calls to register_console and add_preferred_console
and give a detailed description of the problem you are encountering.
Perhaps the real fix should be scan the command line for console= at
console_init time? How does that compare to __setup that is called now?
> for (i = 0; i < n; ++i) {
> #ifdef CONFIG_MAGIC_SYSRQ
> - if (hp->index == hvc_con_driver.index) {
> + if (consoles[hp->index].console.flags & CON_CONSDEV) {
> /* Handle the SysRq Hack */
> /* XXX should support a sequence */
> if (buf[i] == '\x0f') { /* ^O */
> @@ -775,8 +764,8 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int irq,
> * see if this vterm id matches one registered for console.
> */
> for (i=0; i < MAX_NR_HVC_CONSOLES; i++)
> - if (vtermnos[i] == hp->vtermno &&
> - cons_ops[i] == hp->ops)
> + if (consoles[i].vtermno == hp->vtermno &&
> + consoles[i].ops == hp->ops)
> break;
>
NACK
you broke this assertion:
> /*
> * Initial console vtermnos for console API usage prior to full console
> * initialization. Any vty adapter outside this range will not have usable
> * console interfaces but can still be used as a tty device. This has to be
> * static because kmalloc will not work during early console init.
> */
The idea is you might want serial port to 250 other partitions, but only
need to have your choice of console be on the first 8 or so.
milton
^ permalink raw reply
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Matvejchikov Ilya @ 2008-07-30 9:37 UTC (permalink / raw)
To: Scott Wood; +Cc: Ben Gardiner, linuxppc-embedded
In-Reply-To: <20080729193901.GC8051@ld0162-tx32.am.freescale.net>
> Did you use CONFIG_PPC_CPM_NEW_BINDING in 2.6.25? It became mandatory in
> 2.6.26. Also, try commenting out cpm_setbrg() calls in case the
> frequency is not being set properly.
Yes, this option was enabled. Nothing changed with empty cpm_setbrg()
function :(
> 2.6.26 introduced the allocation of the CPM2 SMC parameter RAM area; what
> did your device node look like in 2.6.25? What happens if you use that
> device tree with 2.6.26?
The cpm node for the 2.6.25.4 kernel was the following:
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8280-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
muram {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data-only@0 {
compatible = "fsl,cpm-muram-data";
reg = <100 1f00 9800 800>;
};
};
brg@119f0 {
compatible = "fsl,cpm-brg", "fsl,cpm2-brg";
reg = <119f0 10 115f0 10>;
};
smc1: serial@11a80 {
device_type = "serial";
compatible = "fsl,cpm2-smc-uart";
reg = <11a80 20 0 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d000000>;
};
};
(muram node for 2.6.25 is differs from muram node for the 2.6.26)
With this device tree I have a warning message from cpm_uart driver
tells that the dts file needs to be updated.
Ilya.
^ permalink raw reply
* Re: [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
From: Bastian Blank @ 2008-07-30 10:07 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200807300913.m6U9DluI040346@sullivan.realtime.net>
On Wed, Jul 30, 2008 at 04:13:47AM -0500, Milton Miller wrote:
> On Wed Jul 30 at 17:34:38 EST in 2008, Bastian Blank wrote:
> > On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
> >> Okay, so hvc_console is the culprit. It don't register a preferred
> >> console if it knows it is not the first in the list.
> >
> > The patch registers all available hvc consoles. It adds one "struct
> > console" for all possible hvc consoles.
>
> [ a 6 page patch adding forward declartions, arrays of console
> structs, moving lots of code and creating N struct console in the
> hvc_driver shell]
>
> After previously having written:
> > On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
> >> On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
> >>> On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
> >>> * add_preferred_console - add a device to the list of preferred consoles.
> >>> ...
> >>> * The last preferred console added will be used for kernel messages
> >>> * and stdin/out/err for init.
> >>>
> >>> The last console will be added by the console= parsing, and so that will
> >>> be used. The console we add in the pseries setup is only used if nothing
> >>> is specified on the command line.
> >>
> >> Okay, then there is a completely different problem. In the case of
> >> "console=hvc0 console=hvc1" it uses the _first_ add stdin/out bla and
> >> ignores the second one completely.
> >
> > Okay, so hvc_console is the culprit. It don't register a preferred
> > console if it knows it is not the first in the list.
> >
> > Bastian
>
>
> [ back to the patch ]
> > -/*
> > - * Early console initialization. Precedes driver initialization.
> > - *
> > - * (1) we are first, and the user specified another driver
> > - * -- index will remain -1
> > - * (2) we are first and the user specified no driver
> > - * -- index will be set to 0, then we will fail setup.
> > - * (3) we are first and the user specified our driver
> > - * -- index will be set to user specified driver, and we will fail
> > - * (4) we are after driver, and this initcall will register us
> > - * -- if the user didn't specify a driver then the console will match
> > - *
> > - * Note that for cases 2 and 3, we will match later when the io driver
> > - * calls hvc_instantiate() and call register again.
> > - */
> > -static int __init hvc_console_init(void)
> > -{
> > - register_console(&hvc_con_driver);
> > - return 0;
> >
>
>
> Please explain how the reasoning you removed breaks down.
> What is your usage case?
I have several hvc consoles on a Power hypervisor.
> More importantly , how is this different than, say, drivers/serial/8250.c,
> which also registers just one struct console?
> would not console=ttyS0 console=ttyS1 have the same problem?
Yes, it have the same problem. Only one of the two (I think the first)
will get enabled as console.
> Please instrument the calls to register_console and add_preferred_console
> and give a detailed description of the problem you are encountering.
| add_preferred_console("hvc", 4, NULL)
This call was added recently by the Power LPAR code.
| add_preferred_console("hvc", 1, NULL)
This comes from the command line ("console=hvc1").
| hvc_config_driver.index == -1
| register_console(&hvc_con_driver)
| hvc_config_driver.index == 4
This call is used to detect the id of the to be enabled hvc device. See
the comment of hvc_console_init. register_console sets it to the
_first_ id it finds, in this case 4. There is no other call to
register_console because there is no hvc console with id 4 registered
and hvc_instantiate checks this.
The list of consoles looks like:
- hvc, 4
- hvc, 1
The boot console (udbg0) is destructed later without a real console
remaining.
> Perhaps the real fix should be scan the command line for console= at
> console_init time? How does that compare to __setup that is called now?
This was removed because it break different things. See
5faae2e5d1f53df9dce482032c8486bc3a1feffc.
> > for (i = 0; i < n; ++i) {
> > #ifdef CONFIG_MAGIC_SYSRQ
> > - if (hp->index == hvc_con_driver.index) {
> > + if (consoles[hp->index].console.flags & CON_CONSDEV) {
> > /* Handle the SysRq Hack */
> > /* XXX should support a sequence */
> > if (buf[i] == '\x0f') { /* ^O */
> > @@ -775,8 +764,8 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int irq,
> > * see if this vterm id matches one registered for console.
> > */
> > for (i=0; i < MAX_NR_HVC_CONSOLES; i++)
> > - if (vtermnos[i] == hp->vtermno &&
> > - cons_ops[i] == hp->ops)
> > + if (consoles[i].vtermno == hp->vtermno &&
> > + consoles[i].ops == hp->ops)
> > break;
> >
>
>
> NACK
> you broke this assertion:
> > /*
> > * Initial console vtermnos for console API usage prior to full console
> > * initialization. Any vty adapter outside this range will not have usable
> > * console interfaces but can still be used as a tty device. This has to be
> > * static because kmalloc will not work during early console init.
> > */
Well. It speaks about "range", but in fact it was exactly one.
> The idea is you might want serial port to 250 other partitions, but only
> need to have your choice of console be on the first 8 or so.
hvc is limited to 16 devices.
Bastian
--
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7
^ permalink raw reply
* Re: I2C node in device tree breaks old-style drivers
From: Jochen Friedrich @ 2008-07-30 10:54 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <488F72C8.8010909@freescale.com>
Hi Timur,
> So my conclusion is that specifying an I2C node in the device tree *requires*
> that the driver be new-style. Is there any way we can fix this? I'm not going
> to have time to update the CS4270 driver to a new-style interface before the
> 2.6.27 window closes.
This conclusion is correct. One possible way to fix this is to add support for
blacklisting to drivers/of/base.c (untested):
[RFC] of: Support blacklisting and blacklist cs4270.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/of/base.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..8c53b2c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -404,13 +404,16 @@ EXPORT_SYMBOL(of_find_matching_node);
* assumed that the data size is small and that the compatible values
* should already be distinct enough to differentiate between SPI, I2C
* and other devices.
+ *
+ * Blacklisting devices is supported by using NULL as modalias.
*/
struct of_modalias_table {
char *of_device;
char *modalias;
};
static struct of_modalias_table of_modalias_table[] = {
- /* Empty for now; add entries as needed */
+ /* Blacklisting cs4270 as this driver is currently old-style. */
+ { "cirrus,cs4270", NULL }
};
/**
@@ -441,6 +444,9 @@ int of_modalias_node(struct device_node *node, char *modalias, int len)
compatible = of_modalias_table[i].of_device;
if (!of_device_is_compatible(node, compatible))
continue;
+ /* Check for blacklisting */
+ if (!of_modalias_table[i].modalias)
+ return -ENODEV;
strlcpy(modalias, of_modalias_table[i].modalias, len);
return 0;
}
--
1.5.6.3
^ permalink raw reply related
* Re: Warning: Uable to open an inital console
From: Geert Uytterhoeven @ 2008-07-30 12:00 UTC (permalink / raw)
To: Vijay Nikam; +Cc: linuxppc-dev
In-Reply-To: <f234e2140807300214v60a2ddf3s59c1c9c47af30c9b@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 928 bytes --]
On Wed, 30 Jul 2008, Vijay Nikam wrote:
> I have mpc8313erdb board and trying boot the kernel from NAND flash ...
> The kernel is booting fine but it hangs at the following message;
>
> Warning: unable to open an initial console.
Your root file system doesn't have /dev/console, which should look like:
| crw------- 1 root dialout 5, 1 2008-07-30 10:21 /dev/console
> Kernel panic - not syncing: No init found. Try passing init= option to
> kernel.
Your root file system doesn't have init (/sbin/init, /init, ...).
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@eu.sony.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
From: Kumar Gala @ 2008-07-30 12:33 UTC (permalink / raw)
To: benh; +Cc: Nick Piggin, linuxppc-dev list
In-Reply-To: <1217389038.11188.285.camel@pasglop>
On Jul 29, 2008, at 10:37 PM, Benjamin Herrenschmidt wrote:
> From: Nick Piggin <npiggin@suse.de>
>
> Implement lockless get_user_pages_fast for powerpc. Page table
> existence
> is guaranteed with RCU, and speculative page references are used to
> take a
> reference to the pages without having a prior existence guarantee on
> them.
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Hugh Dickins <hugh@veritas.com>
> Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> I'm going to merge this, sending it to the list for reference, it was
> in -mm for some time , minus some changes/fixes I did to solve
> conflicts
> with the new multiple huge page sizes.
>
> Index: linux-work/arch/powerpc/Kconfig
> ===================================================================
> --- linux-work.orig/arch/powerpc/Kconfig 2008-07-30
> 13:17:06.000000000 +1000
> +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.000000000
> +1000
> @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS
> bool
> default y
>
> +config HAVE_GET_USER_PAGES_FAST
> + def_bool PPC64
> +
> config HAVE_SETUP_PER_CPU_AREA
> def_bool PPC64
what's ppc64 specific here?
- k
^ permalink raw reply
* Re: I2C node in device tree breaks old-style drivers
From: Timur Tabi @ 2008-07-30 13:00 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <48904863.7050902@scram.de>
On Wed, Jul 30, 2008 at 5:54 AM, Jochen Friedrich <jochen@scram.de> wrote:
> Hi Timur,
>
>> So my conclusion is that specifying an I2C node in the device tree *requires*
>> that the driver be new-style. Is there any way we can fix this? I'm not going
>> to have time to update the CS4270 driver to a new-style interface before the
>> 2.6.27 window closes.
>
> This conclusion is correct. One possible way to fix this is to add support for
> blacklisting to drivers/of/base.c (untested):
No need. I posted a patch to alsa-devel that makes the CS4270 a
new-style I2C driver. I'd hate to think that my driver is the only
I2C driver used on PowerPC systems that was outdated. :-)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
From: Nick Piggin @ 2008-07-30 13:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <C8EC8414-A033-46FE-AFEC-8C2A6AB5B4F7@kernel.crashing.org>
On Wed, Jul 30, 2008 at 07:33:26AM -0500, Kumar Gala wrote:
>
> On Jul 29, 2008, at 10:37 PM, Benjamin Herrenschmidt wrote:
>
> >From: Nick Piggin <npiggin@suse.de>
> >
> >Implement lockless get_user_pages_fast for powerpc. Page table
> >existence
> >is guaranteed with RCU, and speculative page references are used to
> >take a
> >reference to the pages without having a prior existence guarantee on
> >them.
> >
> >Signed-off-by: Nick Piggin <npiggin@suse.de>
> >Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> >Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >Cc: Paul Mackerras <paulus@samba.org>
> >Cc: Hugh Dickins <hugh@veritas.com>
> >Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
> >Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >---
> >
> >I'm going to merge this, sending it to the list for reference, it was
> >in -mm for some time , minus some changes/fixes I did to solve
> >conflicts
> >with the new multiple huge page sizes.
> >
> >Index: linux-work/arch/powerpc/Kconfig
> >===================================================================
> >--- linux-work.orig/arch/powerpc/Kconfig 2008-07-30
> >13:17:06.000000000 +1000
> >+++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.000000000
> >+1000
> >@@ -42,6 +42,9 @@ config GENERIC_HARDIRQS
> > bool
> > default y
> >
> >+config HAVE_GET_USER_PAGES_FAST
> >+ def_bool PPC64
> >+
> >config HAVE_SETUP_PER_CPU_AREA
> > def_bool PPC64
>
> what's ppc64 specific here?
I didn't look how 32-bit powerpc does its TLB shootdown and page table
walking, so I don't know if it will work...
^ permalink raw reply
* 4xx USB drivers
From: - Reyneke @ 2008-07-30 13:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi=2C
Does anyone know what the state is of the ppc 44x USB host drivers in the p=
owerpc kernel branch (v2.6.25)?
The EHCI and OHCI all seem to be there and OF aware=2C but we can't quite g=
et it to work.
Regards
Jan
_________________________________________________________________
Find the best and worst places on the planet
http://clk.atdmt.com/UKM/go/101719807/direct/01/=
^ permalink raw reply
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Ben Gardiner @ 2008-07-30 13:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080729193630.GB8051@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> On Tue, Jul 29, 2008 at 11:33:47AM -0400, Ben Gardiner wrote:
>> CPU clock-frequency <- 0x3f940aa (67MHz)
>> CPU timebase-frequency <- 0x1fce17 (2MHz)
>> CPU bus-frequency <- 0x1fce170 (33MHz)
>>
>
> Try commenting out calls to cpm_setbrg(), to see if the frequency is bad.
>
> -Scott
>
Thank you, Scott. You spotted it: my bootloader (an old uboot) is
passing not only the wrong clock freq (66.7 instead of 66 MHz) but
because 66.7 > 66.0 it is also passing the clock freq / 2 as the bus
freq. I got that last leap from the commit message of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=50530378161fa8d7837243119ed9140ee65e55d4.
Thanks to cuboot I had an obvious place to do the fixup of the
clock-freq but I hadn't realized that the bus-freq was wrong.
As you suggested, commenting out the call to cpm_setbrg() did the trick
for me:
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.h
b/drivers/serial/cpm_uart/cpm_uart_cpm1.h
index ddf46d3..c14a5f1 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.h
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.h
@@ -24,7 +24,7 @@ #endif
static inline void cpm_set_brg(int brg, int baud)
{
- cpm_setbrg(brg, baud);
+ //cpm_setbrg(brg, baud);
}
Of course I won't run with that patch. We are using cuboot, so I put
some fixup code in our copy of cuboot-8xx.c, cuboot-nmx-taurus.c:
diff --git a/arch/powerpc/boot/cuboot-nmx-taurusc
b/arch/powerpc/boot/cuboot-nmx-taurus.c
index c202c88..5ab2ff3 100644
--- a/arch/powerpc/boot/cuboot-nmx-taurus.c
+++ b/arch/powerpc/boot/cuboot-nmx-taurus.c
@@ -26,6 +26,12 @@ static void platform_fixups(void)
dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ /* NMX workaround: fix board reporting wrong freq */
+ if(bd.bi_intfreq == 66700000) {
+ bd.bi_intfreq = 66666666UL;
+ bd.bi_busfreq = bd.bi_intfreq;
+ }
+ /* end NMX workaround.*/
dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 16,
bd.bi_busfreq);
node = finddevice("/soc/cpm");
NB: I realize 66666666 may be wrong. It is what was set in our 2.4
kernel so I'm going to leave it as is for now. If I can show that it is
causing clock drift or someone can give me a reason why it should be
66000000 I'll change it then.
Which fixes up the values passed by Uboot:
<snip console>
...
CPU clock-frequency <- 0x3f940aa (67MHz)
CPU timebase-frequency <- 0x3f940a (4MHz)
CPU bus-frequency <- 0x3f940aa (67MHz)
...
<snip>
Thanks for your help and for cuboot.
I'm sorry to have confused this issue. It appears that Matvejchikov and
I are having a different problem.
,Ben
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
From: Kumar Gala @ 2008-07-30 13:39 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev list
In-Reply-To: <20080730131739.GA28814@wotan.suse.de>
On Jul 30, 2008, at 8:17 AM, Nick Piggin wrote:
> On Wed, Jul 30, 2008 at 07:33:26AM -0500, Kumar Gala wrote:
>>
>> On Jul 29, 2008, at 10:37 PM, Benjamin Herrenschmidt wrote:
>>
>>> From: Nick Piggin <npiggin@suse.de>
>>>
>>> Implement lockless get_user_pages_fast for powerpc. Page table
>>> existence
>>> is guaranteed with RCU, and speculative page references are used to
>>> take a
>>> reference to the pages without having a prior existence guarantee on
>>> them.
>>>
>>> Signed-off-by: Nick Piggin <npiggin@suse.de>
>>> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
>>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: Hugh Dickins <hugh@veritas.com>
>>> Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
>>> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>> ---
>>>
>>> I'm going to merge this, sending it to the list for reference, it
>>> was
>>> in -mm for some time , minus some changes/fixes I did to solve
>>> conflicts
>>> with the new multiple huge page sizes.
>>>
>>> Index: linux-work/arch/powerpc/Kconfig
>>> ===================================================================
>>> --- linux-work.orig/arch/powerpc/Kconfig 2008-07-30
>>> 13:17:06.000000000 +1000
>>> +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.000000000
>>> +1000
>>> @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS
>>> bool
>>> default y
>>>
>>> +config HAVE_GET_USER_PAGES_FAST
>>> + def_bool PPC64
>>> +
>>> config HAVE_SETUP_PER_CPU_AREA
>>> def_bool PPC64
>>
>> what's ppc64 specific here?
>
> I didn't look how 32-bit powerpc does its TLB shootdown and page table
> walking, so I don't know if it will work...
I haven't glanced at your code but we have two cases. Either SW
managed TLBs w/no HW walk or a full HW walk that should be similar to
ppc64 (just no SLBs).
- k
^ permalink raw reply
* Re: [PATCH 2/6] kvmppc: add hypercall infrastructure - host part
From: Geert Uytterhoeven @ 2008-07-30 13:41 UTC (permalink / raw)
To: Tony Breeds; +Cc: embedded-hypervisor, kvm-ppc, hollisb, linuxppc-dev
In-Reply-To: <20080724014352.GI20457@bakeyournoodle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1229 bytes --]
On Thu, 24 Jul 2008, Tony Breeds wrote:
> On Wed, Jul 23, 2008 at 10:36:43AM +0200, ehrhardt@linux.vnet.ibm.com wrote:
> > From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> > diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> > --- a/arch/powerpc/kvm/emulate.c
> > +++ b/arch/powerpc/kvm/emulate.c
> > @@ -203,6 +203,24 @@
> > kvmppc_set_msr(vcpu, vcpu->arch.srr1);
> > }
> >
> > +static int kvmppc_do_hypercall(struct kvm_vcpu *vcpu)
> > +{
> > + int ret = 0;
> > +
> > + switch (vcpu->arch.gpr[0]) {
> > + default:
> > + printk(KERN_ERR"unknown hypercall %d\n", vcpu->arch.gpr[0]);
>
> I think the preffered style is printk(KERN_ERR "...) You've made the
> same style mistake in most of you printk()'s in your other patches
> aswell.
Note that these days people use pr_err() instead.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@eu.sony.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* RE: mpc744x, Marvell mv6446x kernel guidance please
From: Stephen Horton @ 2008-07-30 13:56 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20080728165108.GA22621@mag.az.mvista.com>
Hello Mark,
Thanks for your kind encouragement. I now have a mostly booting kernel.
I have just a few remaining issues to resolve; perhaps you (or others)
can give me some tips regarding these:
1. In your prpmc2800 .dts configuration, in the PCI bus configuration
section, you lay-out the IRQ mappings like this:
interrupt-map =3D <
/* IDSEL 0x0a */
5000 0 0 1 &/mv64x60/pic 50
5000 0 0 2 &/mv64x60/pic 51
I've read the Open Firmware document on Interrupt Mapping, but I still
don't really understand the first 3 columns (5000 0 0), especially where
the first column comes from. Is this just some arbitrarily selected
offset address for that device on the pci bus?
2. I've also grabbed some of the recent katana750i .dts examples that
you were working on from one of the git trees (as well as Remi Machet's
GEFanuc C2k board .dts code which is also based on your prpmc2800). Like
your katana750i example, my board also has 2 PMC sites. In your
cuboot-katana.c file, where you are setting up the PCI devices in
'katana750i_bridge_setup', I'm having trouble understanding how you
selected the bitmask values to Disable and Enable cpu->pci windows?
enables =3D in_le32((u32 *)(bridge_base +
MV64x60_CPU_BAR_ENABLE));
enables |=3D 0x0007fe00; /* Disable all cpu->pci windows */
out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE),
enables);
and here:
enables &=3D ~0x0000c000; /* Enable cpu->pci1 i/o, cpu->pci1 mem0
*/
out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE),
enables);
Can you point me in the right direction to understand this? I have
MPC7450 processor family docs for my processor as well as access to
Marvell docs.
3. My Marvell chip is a MV64462. Unlike the MV64460, it only has a
single Gig Ethernet interface, which on my board connects to an 8-port
Broadcom BCM5388 Ethernet Switch. This switch additionally has 2 Gig E
interfaces for each PMC site, 2 PICMG 2.16 connected interfaces, and 1
faceplate connected port. I am successful in getting the Marvell to
setup a Mac-to-Mac connection to the switch via its connected port, but
I'm unsure how to tell Linux about the other ports on the switch,
primarily the 2 PICMG 2.16 ports and the faceplate port. I have access
to the switch in my platform .c file, where I am configuring and
verifying that I have the mac-mac connection setup. Can you speculate
on how I can get the other interfaces to configure? Do I need to a
section in my .dts for the Broadcom switch? My .dts currently only has 1
ethernet and 1 PHY defined... Or, should I setup multiple Ethernet
sections all on the same PHY, or something like that? Or, should I just
do something in my platform file to get Linux to add the other
interfaces?
I appreciate any other addition thoughts you can give,
Regards,
Stephen
-----Original Message-----
From: Mark A. Greer [mailto:mgreer@mvista.com]=20
Sent: Monday, July 28, 2008 11:51 AM
To: Stephen Horton
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: mpc744x, Marvell mv6446x kernel guidance please
On Thu, Jul 10, 2008 at 10:46:49PM -0500, Stephen Horton wrote:
> Hello folks,
>=20
> In a current work project, I have inherited a compactPCI board that
has
> an mpc7447/7448 powerpc processor as well as a Marvell system
> controller, model mv64462 (stripped down mv64460). The board has a
> somewhat working Gentoo Linux port running on it from long ago and a
> company far far away (kernel version 2.6.9 built using arch/ppc). To
> prepare for an upcoming deployment, I would like to bring the OS
> up-to-date on this board with a newer kernel (targeting Gentoo 2008),
> but I am unsure of the approach to take. I am a software developer,
but
> normally do not work on kernel porting / board integration. I have
> researched the arch/ppc to arch/powerpc migration, but I'm a bit
> intimidated by the 'new' device tree symantics and other changes to
the
> stream. Here are some questions:
>=20
> 1. Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
> arch/ppc for this platform architecture? I've tried to get this to
> compile, but am having trouble with files from arch/powerpc getting
> pulled in; then I read some comments (from I believe this forum) that
> indicated that arch/ppc is not longer supposed to compile
arch/ppc is gone now. You should spend you effort working in
arch/powerpc.
> 2. Does anyone have example code for this platform architecture?
> Any freebees I could use for creating my device tree?
You can use prpmc2800 as an example.
> 3. Any advice of any kind?
Its not as bad as it looks. Just dig into it and don't give up.
Mark
^ 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