* [PATCH] Fix pSeries identification in prom_init.c
From: Benjamin Herrenschmidt @ 2006-05-15 5:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The OF trampoline code prom_init.c still needs to identify IBM pSeries
(PAPR) machines in order to run some platform specific code on them like
instanciating the TCE tables. The code doing that detection was changed
recently in 2.6.17 early stages but was done slightly incorrectly. It
should be testing for an exact match of "chrp" and it currently tests
for anything that begins with "chrp". That means it will incorrectly
match with platforms using Maple-like device-trees and have open
firmware. This fixes it by using strcmp instead of strncmp to match what
the actual platform detection code does.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Paul, if you are happy with that, please send upsteam ASAP.
Index: linux-work/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-05-02 10:51:33.000000000 +1000
+++ linux-work/arch/powerpc/kernel/prom_init.c 2006-05-15 15:37:03.000000000 +1000
@@ -1636,7 +1636,7 @@
compat, sizeof(compat)-1);
if (len <= 0)
return PLATFORM_GENERIC;
- if (strncmp(compat, RELOC("chrp"), 4))
+ if (strcmp(compat, RELOC("chrp")))
return PLATFORM_GENERIC;
/* Default to pSeries. We need to know if we are running LPAR */
^ permalink raw reply
* Re: [PATCH] Fix pSeries identification in prom_init.c
From: Benjamin Herrenschmidt @ 2006-05-15 5:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Michael Neuling
In-Reply-To: <1147671963.21291.91.camel@localhost.localdomain>
On Mon, 2006-05-15 at 15:46 +1000, Benjamin Herrenschmidt wrote:
> The OF trampoline code prom_init.c still needs to identify IBM pSeries
> (PAPR) machines in order to run some platform specific code on them like
> instanciating the TCE tables. The code doing that detection was changed
> recently in 2.6.17 early stages but was done slightly incorrectly. It
> should be testing for an exact match of "chrp" and it currently tests
> for anything that begins with "chrp". That means it will incorrectly
> match with platforms using Maple-like device-trees and have open
> firmware. This fixes it by using strcmp instead of strncmp to match what
> the actual platform detection code does.
Michael, I noticed you changed strcmp to strncmp, any reason why you did
that ?
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Paul, if you are happy with that, please send upsteam ASAP.
>
> Index: linux-work/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-05-02 10:51:33.000000000 +1000
> +++ linux-work/arch/powerpc/kernel/prom_init.c 2006-05-15 15:37:03.000000000 +1000
> @@ -1636,7 +1636,7 @@
> compat, sizeof(compat)-1);
> if (len <= 0)
> return PLATFORM_GENERIC;
> - if (strncmp(compat, RELOC("chrp"), 4))
> + if (strcmp(compat, RELOC("chrp")))
> return PLATFORM_GENERIC;
>
> /* Default to pSeries. We need to know if we are running LPAR */
>
^ permalink raw reply
* Re: Load average 1.0 on idle machine
From: Dan Malek @ 2006-05-15 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Brian D. Carlstrom
In-Reply-To: <1147657558.21291.65.camel@localhost.localdomain>
On May 14, 2006, at 9:45 PM, Benjamin Herrenschmidt wrote:
> .... For now, consider
> the load avergage value bogus :)
It's not bogus :-) If you happen to schedule periodic
tasks that are sampled with load average computes,
or sleep them "uninterrupible", they are counted in
the load average.
-- Dan
^ permalink raw reply
* Re: Load average 1.0 on idle machine
From: Benjamin Herrenschmidt @ 2006-05-15 6:23 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Brian D. Carlstrom
In-Reply-To: <D0930F4F-DF46-47FF-B33C-0BE313CC81DB@embeddedalley.com>
On Mon, 2006-05-15 at 02:08 -0400, Dan Malek wrote:
> On May 14, 2006, at 9:45 PM, Benjamin Herrenschmidt wrote:
>
> > .... For now, consider
> > the load avergage value bogus :)
>
> It's not bogus :-) If you happen to schedule periodic
> tasks that are sampled with load average computes,
> or sleep them "uninterrupible", they are counted in
> the load average.
The thermal control runs every second and sleeps with "interruptible"...
so it should not have such a laod average imho :) Now it's possible that
what it does during that "second" is long enough to end up not sleeping
that much (though it's also sleeping while doing i2c accesses, but that
is uninterruptible for obvious reasons at the i2c driver level).
Ben
^ permalink raw reply
* Re: Bigphysarea vs. kernel 2.4.32 and PPC405GPr
From: Arno Geissel @ 2006-05-15 6:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e435rv$62q$1@sea.gmane.org>
Try
rc = remap_page_range(vma->vm_start,
virt_to_phys(heap_map_base),
npages*PAGE_SIZE,
vma->vm_page_prot);
Arno
> I'm trying to use the bigphysarea patch to help me allocate big
> physical chunks of memory for use by some custom embedded devices.
> I've applied the bigphysarea-2.4.20 patch and built, no trouble,
> and I've got it to config for my PPC. I can see at boot time that
> the bigphysarea is getting its pages.
>
> I'm trying to use a mmap call to the driver to map a chunk of this
> memory into the process. The mmap for the driver has this:
>
> pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
> vma->vm_flags |= VM_RESERVED;
>
> npages = (vma->vm_end - vma->vm_start) / PAGE_SIZE;
> heap_map_base = bigphysarea_alloc_pages(npages, 1, GFP_KERNEL);
>
> printk("XXXX Map base=%p, %ld pages\n", heap_map_base, npages);
>
> rc = remap_page_range(vma->vm_start,
> (unsigned long)heap_map_base,
> npages*PAGE_SIZE,
> vma->vm_page_prot);
>
> The mmap returns without an error, but any access to the mapped
> region gets me an immediate "Oops: machine check, sig: 7". I don't
> see it. Where is the stupid mistake that I'm invariably making?
^ permalink raw reply
* [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-15 6:58 UTC (permalink / raw)
To: Paul Mackerras
Cc: Bartlomiej Zolnierkiewicz, Andrew Morton, linuxppc-dev list
It looks like the generic ide code now wants ide_init_hwif_ports() to
set the parent struct device into the ide_hw structure (new field ?).
Without this, the mac ide code can cause the ide probing code to explode
in flames in sysfs registration due to what looks like a stale pointer
in there (happens when removing/re-inserting one of the hotswap media
bays on some laptops).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Andew: That's a 2.6.17 candidate
Index: linux-work/drivers/ide/ppc/pmac.c
===================================================================
--- linux-work.orig/drivers/ide/ppc/pmac.c 2006-04-19 15:04:47.000000000 +1000
+++ linux-work/drivers/ide/ppc/pmac.c 2006-05-15 16:43:20.000000000 +1000
@@ -553,6 +553,8 @@
if (irq != NULL)
*irq = pmac_ide[ix].irq;
+
+ hw->dev = &pmac_ide[ix].mdev->ofdev.dev;
}
#define PMAC_IDE_REG(x) ((void __iomem *)(IDE_DATA_REG+(x)))
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Andrew Morton @ 2006-05-15 7:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: B.Zolnierkiewicz, linuxppc-dev, paulus, Pete Popov, Alan Cox
In-Reply-To: <1147676318.21291.105.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> It looks like the generic ide code now wants ide_init_hwif_ports() to
> set the parent struct device into the ide_hw structure (new field ?).
> Without this, the mac ide code can cause the ide probing code to explode
> in flames in sysfs registration due to what looks like a stale pointer
> in there (happens when removing/re-inserting one of the hotswap media
> bays on some laptops).
>
You don't sound very confident.
> ---
>
> Andew: That's a 2.6.17 candidate
>
> Index: linux-work/drivers/ide/ppc/pmac.c
> ===================================================================
> --- linux-work.orig/drivers/ide/ppc/pmac.c 2006-04-19 15:04:47.000000000 +1000
> +++ linux-work/drivers/ide/ppc/pmac.c 2006-05-15 16:43:20.000000000 +1000
> @@ -553,6 +553,8 @@
>
> if (irq != NULL)
> *irq = pmac_ide[ix].irq;
> +
> + hw->dev = &pmac_ide[ix].mdev->ofdev.dev;
> }
>
> #define PMAC_IDE_REG(x) ((void __iomem *)(IDE_DATA_REG+(x)))
>
afaict things went bad in October last year. hw_regs_t.dev was added here:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=26a940e21752e0de8f068f77dad606a7d1986937
but that only converted one driver to initialse ->dev.
How come things didn't break then? Did some later change cause the
problems?
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-15 7:23 UTC (permalink / raw)
To: Andrew Morton
Cc: B.Zolnierkiewicz, linuxppc-dev, paulus, Pete Popov, Alan Cox
In-Reply-To: <20060515000810.487b834e.akpm@osdl.org>
On Mon, 2006-05-15 at 00:08 -0700, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > It looks like the generic ide code now wants ide_init_hwif_ports() to
> > set the parent struct device into the ide_hw structure (new field ?).
> > Without this, the mac ide code can cause the ide probing code to explode
> > in flames in sysfs registration due to what looks like a stale pointer
> > in there (happens when removing/re-inserting one of the hotswap media
> > bays on some laptops).
> >
>
> You don't sound very confident.
Well, the problem is fixed with my change, I'd like to have Bart
confirmation that's its the right approach. It looks like it is but that
code is fairly intricated :)
> afaict things went bad in October last year. hw_regs_t.dev was added here:
>
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=26a940e21752e0de8f068f77dad606a7d1986937
>
> but that only converted one driver to initialse ->dev.
>
> How come things didn't break then? Did some later change cause the
> problems?
Well, for one, very few drivers cause ide_unregister nor rely on those
old mecanism... it seems that the way I initialize things at boot works
fine, it's when I unregister/re-register via the hotswap bay that things
go bunk.
It's possible that it got broken back then and not noticed since ... or
another change actually made _use_ of that field... not sure, Bart might
confirm. The Mac laptops with those hotswap bays are fairly old and I
haven't tested for some time. I just did after getting user reports, and
users of old machines like that tend to use stable distro kernels which
tend to be fairly old...
Ben.
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-15 8:21 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linuxppc-dev, Mel Gorman, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <20060514203158.216a966e.akpm@osdl.org>
Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>
>>Size zones and holes in an architecture independent manner for ia64.
>>
>
>
> This one makes my ia64 die very early in boot. The trace is pretty useless.
>
> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>
> EFI v1.10 by INTEL: SALsystab=0x3fe4c8c0 ACPI=0x3ff84000 ACPI 2.0=0x3ff83000 MP0
> Early serial console at I/O port 0x2f8 (options '9600n8')
> SAL 3.1: Intel Corp SR870BN4 vers0
> SAL Platform features: BusLock IRQ_Redirection
> SAL: AP wakeup using external interrupt vector 0xf0
> No logical to physical processor mapping available
> iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
> ACPI: Local APIC address c0000000fee00000
> PLATFORM int CPEI (0x3): GSI 22 (level, low) -> CPU 0 (0xc618) vector 30
> register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
> 4 CPUs available, 4 CPUs total
> MCA related initialization done
> node 0 zone DMA missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> node 0 zone DMA32 missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> node 0 zone Normal missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> node 0 zone HighMem missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> SMP: Allowing 4 CPUs, 0 hotplug CPUs
> Built 1 zonelists
> Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.17-rc4-mm1 root=/o
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 6, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 5, 524288 bytes)
> Placing software IO TLB between 0x4a30000 - 0x8a30000
> Unable to handle kernel NULL pointer dereference (address 0000000000000008)
> swapper[0]: Oops 8813272891392 [1]
> Modules linked in:
>
> Pid: 0, CPU 0, comm: swapper
> psr : 00001010084a6010 ifs : 800000000000060f ip : [<a0000001000e6750>] Notd
> ip is at __free_pages_ok+0x190/0x3c0
> unat: 0000000000000000 pfs : 000000000000060f rsc : 0000000000000003
> rnat: 0000000000ffffff bsps: 00000000000002f9 pr : 80000000afb5956b
> ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
> csd : 0930ffff00090000 ssd : 0930ffff00090000
> b0 : a0000001000e6660 b6 : e00000003fe52940 b7 : a000000100790120
> f6 : 1003e6db6db6db6db6db7 f7 : 1003e000000000006dec0
> f8 : 1003e000000000000fb80 f9 : 1003e000000000006e080
> f10 : 1003e000000000000fb40 f11 : 1003e000000000006dec0
> r1 : a000000100af2db0 r2 : 0000000000000001 r3 : 0000000000000000
> r8 : a0000001008f3d38 r9 : 0000000000004000 r10 : 0000000000370400
> r11 : 0000000000004000 r12 : a0000001007b7e10 r13 : a0000001007b0000
> r14 : 0000000000000001 r15 : 0000000100000001 r16 : 0000000100000001
> r17 : 0000000100000001 r18 : 0000000000001041 r19 : 0000000000000000
> r20 : e00000000149df00 r21 : 0000000100000000 r22 : 0000000055555155
> r23 : 00000000ffffffff r24 : e00000000149df08 r25 : 1555555555555155
> r26 : 0000000000000032 r27 : 0000000000000000 r28 : 0000000000000008
> r29 : 0000000000001041 r30 : 0000000000001041 r31 : 0000000000000001
> Unable to handle kernel NULL pointer dereference (address 0000000000000000)
> swapper[0]: Oops 8813272891392 [2]
> Modules linked in:
>
> Pid: 0, CPU 0, comm: swapper
> psr : 0000101008022018 ifs : 8000000000000287 ip : [<a0000001001236c0>] Notd
> ip is at kmem_cache_alloc+0x40/0x100
> unat: 0000000000000000 pfs : 0000000000000712 rsc : 0000000000000003
> rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000afb59967
> ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
> csd : 0930ffff00090000 ssd : 0930ffff00090000
> b0 : a00000010003e450 b6 : a000000100001b50 b7 : a00000010003f320
> f6 : 1003e9e3779b97f4a7c16 f7 : 0ffdb8000000000000000
> f8 : 1003e000000000000007f f9 : 1003e0000000000000379
> f10 : 1003e6db6db6db6db6db7 f11 : 1003e000000000000007f
> r1 : a000000100af2db0 r2 : 0000000000000000 r3 : 0000000000000000
> r8 : 0000000000000000 r9 : 0000000000000000 r10 : a0000001007b0f24
> r11 : 0000000000000000 r12 : a0000001007b7280 r13 : a0000001007b0000
> r14 : 0000000000000000 r15 : 0000000000000000 r16 : a0000001007b7310
> r17 : 0000000000000000 r18 : a0000001007b7478 r19 : 0000000000000000
> r20 : 0000000000000000 r21 : 0000000000000018 r22 : 0000000000000000
> r23 : 0000000000000000 r24 : 0000000000000000 r25 : a0000001007b7308
> r26 : 000000007fffffff r27 : a000000100825520 r28 : a0000001008f3c40
> r29 : a000000100816ca8 r30 : 0000000000000018 r31 : 0000000000000018
>
>
>
> (gdb) l *0xa0000001000e6750
> 0xa0000001000e6750 is in __free_pages_ok (mm.h:324).
> 319 extern void FASTCALL(__page_cache_release(struct page *));
> 320
> 321 static inline int page_count(struct page *page)
> 322 {
> 323 if (unlikely(PageCompound(page)))
> 324 page = (struct page *)page_private(page);
> 325 return atomic_read(&page->_count);
> 326 }
> 327
> 328 static inline void get_page(struct page *page)
>
>
> Note the misaligned pfns.
>
> Andy's (misspelled) CONFIG_UNALIGNED_ZONE_BOUNDRIES patch didn't actually
> include an update to any Kconfig files. But hacking that in by hand didn't
> help.
Interesting. You are correct there was no config component, at the time
I didn't have direct evidence that any architecture needed it, only that
we had an unchecked requirement on zones, a requirement that had only
recently arrived with the changes to free buddy detection. I note that
MAX_ORDER is 17 for ia64 so that probabally accounts for the
missalignment. It is clear that the reporting is slightly over-zelous
as I am reporting zero-sized zones. I'll get that fixed and patch to
you. I'll also have a look at the patch as added to -mm and try and get
the rest of the spelling sorted :-/.
I'll go see if we currently have a machine to test this config on.
-apw
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Gabriel Paubert @ 2006-05-15 8:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Pete Popov, B.Zolnierkiewicz, linuxppc-dev, paulus,
Alan Cox
In-Reply-To: <1147677830.21291.114.camel@localhost.localdomain>
On Mon, May 15, 2006 at 05:23:50PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2006-05-15 at 00:08 -0700, Andrew Morton wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > >
> > > It looks like the generic ide code now wants ide_init_hwif_ports() to
> > > set the parent struct device into the ide_hw structure (new field ?).
> > > Without this, the mac ide code can cause the ide probing code to explode
> > > in flames in sysfs registration due to what looks like a stale pointer
> > > in there (happens when removing/re-inserting one of the hotswap media
> > > bays on some laptops).
> > >
> >
> > You don't sound very confident.
>
> Well, the problem is fixed with my change, I'd like to have Bart
> confirmation that's its the right approach. It looks like it is but that
> code is fairly intricated :)
>
> > afaict things went bad in October last year. hw_regs_t.dev was added here:
> >
> > http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=26a940e21752e0de8f068f77dad606a7d1986937
> >
> > but that only converted one driver to initialse ->dev.
> >
> > How come things didn't break then? Did some later change cause the
> > problems?
>
> Well, for one, very few drivers cause ide_unregister nor rely on those
> old mecanism... it seems that the way I initialize things at boot works
> fine, it's when I unregister/re-register via the hotswap bay that things
> go bunk.
>
> It's possible that it got broken back then and not noticed since ... or
> another change actually made _use_ of that field... not sure, Bart might
> confirm. The Mac laptops with those hotswap bays are fairly old and I
> haven't tested for some time. I just did after getting user reports, and
> users of old machines like that tend to use stable distro kernels which
> tend to be fairly old...
Actually I have one of these, and regularly use it and update
the kernel to the latest git once or twice per month, but I
typically have two batteries and have not swapped in the
media bay under Linux for a long time.
If you are interested, I could test the patch when I find
some time (not today: my 8 year old son went to the hospital
for an emergency last Thursday, he is cured now and should
come out today).
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-15 8:52 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Andrew Morton, Pete Popov, B.Zolnierkiewicz, linuxppc-dev, paulus,
Alan Cox
In-Reply-To: <20060515083847.GA5229@iram.es>
> Actually I have one of these, and regularly use it and update
> the kernel to the latest git once or twice per month, but I
> typically have two batteries and have not swapped in the
> media bay under Linux for a long time.
>
> If you are interested, I could test the patch when I find
> some time (not today: my 8 year old son went to the hospital
> for an emergency last Thursday, he is cured now and should
> come out today).
Any test is welcome, glad to know your son is well !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Fix pSeries identification in prom_init.c
From: segher @ 2006-05-15 9:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147671963.21291.91.camel@localhost.localdomain>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Paul, if you are happy with that, please send upsteam ASAP.
>
> Index: linux-work/arch/powerpc/kernel/prom_init.c
> =================================================================== ---
> linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-05-02
> 10:51:33.000000000 +1000 +++
> linux-work/arch/powerpc/kernel/prom_init.c 2006-05-15 15:37:03.000000000
> +1000 @@ -1636,7 +1636,7 @@
> compat, sizeof(compat)-1);
> if (len <= 0)
> return PLATFORM_GENERIC;
> - if (strncmp(compat, RELOC("chrp"), 4))
> + if (strcmp(compat, RELOC("chrp")))
> return PLATFORM_GENERIC;
>
> /* Default to pSeries. We need to know if we are running LPAR */
Confirmed it works correctly on affected systems. Thanks Ben.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Nick Piggin @ 2006-05-15 10:00 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Andrew Morton, davej, tony.luck, linuxppc-dev, Mel Gorman,
linux-kernel, bob.picco, ak, linux-mm
In-Reply-To: <44683A09.2060404@shadowen.org>
Andy Whitcroft wrote:
> Interesting. You are correct there was no config component, at the time
> I didn't have direct evidence that any architecture needed it, only that
> we had an unchecked requirement on zones, a requirement that had only
> recently arrived with the changes to free buddy detection. I note that
Recently arrived? Over a year ago with the no-buddy-bitmap patches,
right? Just checking because I that's what I'm assuming broke it...
> MAX_ORDER is 17 for ia64 so that probabally accounts for the
> missalignment. It is clear that the reporting is slightly over-zelous
> as I am reporting zero-sized zones. I'll get that fixed and patch to
> you. I'll also have a look at the patch as added to -mm and try and get
> the rest of the spelling sorted :-/.
>
> I'll go see if we currently have a machine to test this config on.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: how to mount /dev/ram0 to /
From: tony @ 2006-05-15 9:45 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
SSByZWJ1aWxkIHRoZSBidXp5Ym94LGFuZCBhZGRlZCBzb21lIHRvb2xzKGxpa2UgZG9zMnVuaXgs
c3R0eSx1bml4MmRvcyxkYyxsb2Fka21wKSAsdGhlbiBpdCB3b3Jrcyhtb3VudCAvZGV2L3JhbTAg
YXV0b21hdGljYWxseSksbWF5YmUgaXQncyBzb21ldGhpbmcgYWJvdXQgdGhlIHRvb2xzIGFib3Zl
Lg0KDQp0aGFuayBXb2xmZ2FuZyBEZW5rIGFuZCBhbGwuLg0KDQqhoaGhoaGhoaGhoaGhoaGhdG9u
eQ0KoaGhoaGhoaGhoaGhoaGhoWhhbmd0b29AMTYzLmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEy
MDA2LTA1LTE1DQo=
^ permalink raw reply
* Page fault when debugging a 2.6.16 kernel on MPC8248
From: Laurent Pinchart @ 2006-05-15 10:10 UTC (permalink / raw)
To: linuxppc-embedded
Hello everybody,
I'm trying to bring up Linux on a custom MPC8248 board.
I've been able to setup U-Boot correctly up to the point where I boot the
Linux kernel using bootm. The kernel doesn't print anything on the serial
console and hangs.
Thanks to a BDI2000, I've been able to get the following backtrace.
#0 cpm_uart_console_write (co=0xd,
s=0xc0203e4b "x version 2.6.16-dirty (laurent@pclaurent) (gcc version
3.4.1) #422 Thu May 11 13:30:44 CEST 2006\n<6>Technotrade S.A.",
count=1) at drivers/serial/cpm_uart/cpm_uart_core.c:1023
#1 0xc0014144 in __call_console_drivers (start=3, end=105) at
kernel/printk.c:368
#2 0xc00144f4 in release_console_sem () at kernel/printk.c:430
#3 0xc0014ce4 in register_console (console=0xc01c2e60) at kernel/printk.c:946
#4 0xc01f7308 in cpm_uart_console_init () at
drivers/serial/cpm_uart/cpm_uart_core.c:1149
#5 0xc01f673c in console_init () at drivers/char/tty_io.c:3181
#6 0xc01e85b8 in start_kernel () at init/main.c:495
#7 0x00000000 in ?? ()
At that point, all the memory read with the BDI2000 (internal memory, SDRAM,
SRAM, flash, ...) reads as 0.
Knowing that something was wrong with the memory, I tried to execute the
kernel step by step. Unfortunately, after breaking in start_kernel, the first
gdb "next" command to step over the call to printk(KERN_NOTICE) hung. Hitting
Ctrl-C in gdb returned the following backtrace.
#0 0xc0005f4c in __delay ()
#1 0xc0013b18 in panic (fmt=0x487ab0 <Address 0x487ab0 out of bounds>) at
include/asm/delay.h:42
#2 0xc001679c in do_exit (code=11) at kernel/exit.c:809
#3 0x2400c022 in ?? ()
#4 0xc0004b8c in die (str=0x3ff <Address 0x3ff out of bounds>, fp=0xc01e7c60,
err=11) at arch/ppc/kernel/traps.c:101
#5 0xc000bf3c in bad_page_fault (regs=0xc01e7c60, address=0, sig=11) at
arch/ppc/mm/fault.c:336
#6 0xc00046d0 in handle_page_fault ()
#7 0xc00046d0 in handle_page_fault ()
I'm lost here. Why does Linux page faults when executed step by step (or
rather using "next") but doesn't when running normally ? I suspect that this
could be related to the memory reading as 0 in cpm_uart_console_write.
Thanks in advance for all the help you can provide.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-15 10:19 UTC (permalink / raw)
To: Nick Piggin
Cc: Andrew Morton, davej, tony.luck, linuxppc-dev, Mel Gorman,
linux-kernel, bob.picco, ak, linux-mm
In-Reply-To: <44685123.7040501@yahoo.com.au>
Nick Piggin wrote:
> Andy Whitcroft wrote:
>
>> Interesting. You are correct there was no config component, at the time
>> I didn't have direct evidence that any architecture needed it, only that
>> we had an unchecked requirement on zones, a requirement that had only
>> recently arrived with the changes to free buddy detection. I note that
>
>
> Recently arrived? Over a year ago with the no-buddy-bitmap patches,
> right? Just checking because I that's what I'm assuming broke it...
Yep, sorry I forget I was out of the game for 6 months! And yes that
was when the requirements were altered.
-apw
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: KAMEZAWA Hiroyuki @ 2006-05-15 10:29 UTC (permalink / raw)
To: Andy Whitcroft
Cc: akpm, nickpiggin, tony.luck, davej, mel, linux-kernel, bob.picco,
ak, linuxppc-dev, linux-mm
In-Reply-To: <446855AF.1090100@shadowen.org>
On Mon, 15 May 2006 11:19:27 +0100
Andy Whitcroft <apw@shadowen.org> wrote:
> Nick Piggin wrote:
> > Andy Whitcroft wrote:
> >
> >> Interesting. You are correct there was no config component, at the time
> >> I didn't have direct evidence that any architecture needed it, only that
> >> we had an unchecked requirement on zones, a requirement that had only
> >> recently arrived with the changes to free buddy detection. I note that
> >
> >
> > Recently arrived? Over a year ago with the no-buddy-bitmap patches,
> > right? Just checking because I that's what I'm assuming broke it...
>
> Yep, sorry I forget I was out of the game for 6 months! And yes that
> was when the requirements were altered.
>
When no-bitmap-buddy patches was included,
1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
==
static int bad_range(struct zone *zone, struct page *page)
{
if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
return 1;
if (page_to_pfn(page) < zone->zone_start_pfn)
return 1;
==
And , this code
==
buddy = __page_find_buddy(page, page_idx, order);
if (bad_range(zone, buddy))
break;
==
checked whether buddy is in zone and guarantees it to have page struct.
But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
Sorry for misses these things.
-Kame
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: KAMEZAWA Hiroyuki @ 2006-05-15 10:47 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: akpm, nickpiggin, tony.luck, davej, mel, linux-kernel, bob.picco,
ak, linuxppc-dev, linux-mm
In-Reply-To: <20060515192918.c3e2e895.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, 15 May 2006 19:29:18 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Mon, 15 May 2006 11:19:27 +0100
> Andy Whitcroft <apw@shadowen.org> wrote:
>
> > Nick Piggin wrote:
> > > Andy Whitcroft wrote:
> > >
> > >> Interesting. You are correct there was no config component, at the time
> > >> I didn't have direct evidence that any architecture needed it, only that
> > >> we had an unchecked requirement on zones, a requirement that had only
> > >> recently arrived with the changes to free buddy detection. I note that
> > >
> > >
> > > Recently arrived? Over a year ago with the no-buddy-bitmap patches,
> > > right? Just checking because I that's what I'm assuming broke it...
> >
> > Yep, sorry I forget I was out of the game for 6 months! And yes that
> > was when the requirements were altered.
> >
> When no-bitmap-buddy patches was included,
>
> 1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
> ==
> static int bad_range(struct zone *zone, struct page *page)
> {
> if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
> return 1;
> if (page_to_pfn(page) < zone->zone_start_pfn)
> return 1;
> ==
> And , this code
> ==
> buddy = __page_find_buddy(page, page_idx, order);
>
> if (bad_range(zone, buddy))
> break;
> ==
>
> checked whether buddy is in zone and guarantees it to have page struct.
>
>
> But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
> Sorry for misses these things.
>
One more point
When above no-bitmap patches was included, the user of not-aligned zones
are only ia64, I think. Because ia64 used virtual mem_map, page_to_pfn(page)
on CONFIG_DISCONTIG_MEM doesn't access page struct itself.
#define page_to_pfn(page) (page - vmemmap)
So, it didn't panic. ia64/vmemmap was safe.
If other archs used not-aligned zone + CONFIG_DISCONTIGMEM,
not-aligned-zones problem would come out earlier.
-Kame
^ permalink raw reply
* booting linux on IBM750 evaluation board
From: sharath kumar @ 2006-05-15 10:41 UTC (permalink / raw)
To: linuxppc-embedded
HI
i am working on IBM750 evaluation baord from IBM. It
has Marvel chipset.
I only have pibs running on this board.
I want to boot linux on this baord.
can anyone tell the procedure
Thanks and Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-15 11:02 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: akpm, nickpiggin, tony.luck, davej, mel, linux-kernel, bob.picco,
ak, linuxppc-dev, linux-mm
In-Reply-To: <20060515192918.c3e2e895.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
> On Mon, 15 May 2006 11:19:27 +0100
> Andy Whitcroft <apw@shadowen.org> wrote:
>
>
>>Nick Piggin wrote:
>>
>>>Andy Whitcroft wrote:
>>>
>>>
>>>>Interesting. You are correct there was no config component, at the time
>>>>I didn't have direct evidence that any architecture needed it, only that
>>>>we had an unchecked requirement on zones, a requirement that had only
>>>>recently arrived with the changes to free buddy detection. I note that
>>>
>>>
>>>Recently arrived? Over a year ago with the no-buddy-bitmap patches,
>>>right? Just checking because I that's what I'm assuming broke it...
>>
>>Yep, sorry I forget I was out of the game for 6 months! And yes that
>>was when the requirements were altered.
>>
>
> When no-bitmap-buddy patches was included,
>
> 1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
> ==
> static int bad_range(struct zone *zone, struct page *page)
> {
> if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
> return 1;
> if (page_to_pfn(page) < zone->zone_start_pfn)
> return 1;
> ==
> And , this code
> ==
> buddy = __page_find_buddy(page, page_idx, order);
>
> if (bad_range(zone, buddy))
> break;
> ==
>
> checked whether buddy is in zone and guarantees it to have page struct.
>
>
> But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
> Sorry for misses these things.
Heh, sorry to make it sound like it was you who was responsible.
-apw
^ permalink raw reply
* Re: windfarm for PM72/PM73/RM31
From: Étienne Bersac @ 2006-05-15 11:39 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20060515035151.GB25086@curie-int.vc.shawcable.net>
Ok,
Let me wish you a good recovering :)
Étienne.
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-15 12:27 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
linux-mm
In-Reply-To: <20060514203158.216a966e.akpm@osdl.org>
On (14/05/06 20:31), Andrew Morton didst pronounce:
> Mel Gorman <mel@csn.ul.ie> wrote:
> >
> > Size zones and holes in an architecture independent manner for ia64.
> >
>
> This one makes my ia64 die very early in boot. The trace is pretty useless.
>
> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>
> <log snipped>
Curses. When I tried to reproduce this, the machine booted with my default
config but died before initialising the console with your config. The machine
is far away so I can't see the screen or restart the machine remotely so
I can only assume it is dying for the same reasons yours did.
> Note the misaligned pfns.
>
> Andy's (misspelled) CONFIG_UNALIGNED_ZONE_BOUNDRIES patch didn't actually
> include an update to any Kconfig files. But hacking that in by hand didn't
> help.
It would not have helped in this case because the zone boundaries would still
be in the wrong place for ia64. Below is a patch that aligns the zones on
all architectures that use CONFIG_ARCH_POPULATES_NODE_MAP . That is currently
i386, x86_64, powerpc, ppc and ia64. It does *not* align pgdat->node_start_pfn
but I don't believe that it is necessary.
I can't test it on ia64 until I get someone to restart the machine. The patch
compiles and is currently boot-testing on a range of other machines. I hope
to know within 5-6 hours if everything is ok.
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc4-mm4-clean/mm/page_alloc.c linux-2.6.17-rc4-mm4-ia64_force_alignment/mm/page_alloc.c
--- linux-2.6.17-rc4-mm4-clean/mm/page_alloc.c 2006-05-15 10:37:55.000000000 +0100
+++ linux-2.6.17-rc4-mm4-ia64_force_alignment/mm/page_alloc.c 2006-05-15 13:10:42.000000000 +0100
@@ -2640,14 +2640,20 @@ void __init free_area_init_nodes(unsigne
{
unsigned long nid;
int zone_index;
+ unsigned long lowest_pfn = find_min_pfn_with_active_regions();
+
+ lowest_pfn = zone_boundary_align_pfn(lowest_pfn);
+ arch_max_dma_pfn = zone_boundary_align_pfn(arch_max_dma_pfn);
+ arch_max_dma32_pfn = zone_boundary_align_pfn(arch_max_dma32_pfn);
+ arch_max_low_pfn = zone_boundary_align_pfn(arch_max_low_pfn);
+ arch_max_high_pfn = zone_boundary_align_pfn(arch_max_high_pfn);
/* Record where the zone boundaries are */
memset(arch_zone_lowest_possible_pfn, 0,
sizeof(arch_zone_lowest_possible_pfn));
memset(arch_zone_highest_possible_pfn, 0,
sizeof(arch_zone_highest_possible_pfn));
- arch_zone_lowest_possible_pfn[ZONE_DMA] =
- find_min_pfn_with_active_regions();
+ arch_zone_lowest_possible_pfn[ZONE_DMA] = lowest_pfn;
arch_zone_highest_possible_pfn[ZONE_DMA] = arch_max_dma_pfn;
arch_zone_highest_possible_pfn[ZONE_DMA32] = arch_max_dma32_pfn;
arch_zone_highest_possible_pfn[ZONE_NORMAL] = arch_max_low_pfn;
^ permalink raw reply
* [PATCH] Create /proc/rtas,/proc/ppc64/rtas if RTAS exists.
From: mostrows @ 2006-05-15 12:51 UTC (permalink / raw)
To: paulus, benh, linuxppc-dev
Use the existence of RTAS device tree node to determine if
/proc/rtas. /proc/ppc64/rtas are to be created. Using machine type
is not reliable (i.e. Maple-like machines may have RTAS).
--
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
arch/powerpc/kernel/proc_ppc64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d8054b07bbf12e0178ec5ad7ce6a750a3af53064
diff --git a/arch/powerpc/kernel/proc_ppc64.c b/arch/powerpc/kernel/proc_ppc64.c
index 3c2cf66..2b87f82 100644
--- a/arch/powerpc/kernel/proc_ppc64.c
+++ b/arch/powerpc/kernel/proc_ppc64.c
@@ -52,7 +52,7 @@ static int __init proc_ppc64_create(void
if (!root)
return 1;
- if (!machine_is(pseries) && !machine_is(cell))
+ if (!of_find_node_by_path("/rtas"))
return 0;
if (!proc_mkdir("rtas", root))
--
1.1.4.g0b63-dirty
^ permalink raw reply related
* [dtc][PATCH] Fix ftdump data walking
From: Jimi Xenidis @ 2006-05-15 15:47 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes a pointer addition bug in ftdump and handles endian
issue.
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
---
diff --git a/ftdump.c b/ftdump.c
index 4d4354b..7e643c8 100644
--- a/ftdump.c
+++ b/ftdump.c
@@ -67,7 +67,8 @@ static void print_data(const void *data,
} else if ((len % 4) == 0) {
printf(" = <");
for (i = 0; i < len; i += 4)
- printf("%08x%s", *((uint32_t *)data + i),
+ printf("%08x%s",
+ be32_to_cpu(*((uint32_t *)((ulong)data + i))),
i < (len - 4) ? " " : "");
printf(">");
} else {
^ permalink raw reply related
* Re: [PATCH] Fix pSeries identification in prom_init.c
From: Michael Neuling @ 2006-05-15 16:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras, segher
In-Reply-To: <1147672282.21291.92.camel@localhost.localdomain>
> > The OF trampoline code prom_init.c still needs to identify IBM
> > pSeries (PAPR) machines in order to run some platform specific code
> > on them like instanciating the TCE tables. The code doing that
> > detection was changed recently in 2.6.17 early stages but was done
> > slightly incorrectly. It should be testing for an exact match of
> > "chrp" and it currently tests for anything that begins with
> > "chrp". That means it will incorrectly match with platforms using
> > Maple-like device-trees and have open firmware. This fixes it by
> > using strcmp instead of strncmp to match what the actual platform
> > detection code does.
>
> Michael, I noticed you changed strcmp to strncmp, any reason why you
> did that ?
To be safe if we are returned a non terminated string. I'd not realised
the case you've mentioned.
How much we should trust firmware? With strcpy, should we explicitly
terminate the string first (I removed one of these originally)? Patch
below, compiled not run.
-
The OF trampoline code prom_init.c still needs to identify IBM pSeries
(PAPR) machines in order to run some platform specific code on them like
instantiating the TCE tables. The code doing that detection was changed
recently in 2.6.17 early stages but was done slightly incorrectly. It
should be testing for an exact match of "chrp" and it currently tests
for anything that begins with "chrp". That means it will incorrectly
match with platforms using Maple-like device-trees and have open
firmware. This fixes it by using strcmp instead of strncmp to match what
the actual platform detection code does.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/prom_init.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6-powerpc/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6-powerpc/arch/powerpc/kernel/prom_init.c
@@ -1636,7 +1636,8 @@ static int __init prom_find_machine_type
compat, sizeof(compat)-1);
if (len <= 0)
return PLATFORM_GENERIC;
- if (strncmp(compat, RELOC("chrp"), 4))
+ compat[len] = 0;
+ if (strcmp(compat, RELOC("chrp")))
return PLATFORM_GENERIC;
/* Default to pSeries. We need to know if we are running LPAR */
^ 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