* Re: System crash on boot_e500.S on 2.4Kernel
From: Andy Fleming @ 2007-08-15 22:06 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-embedded
In-Reply-To: <5c9cd53b0708151412v2f5feb74v9e0b49d114b83021@mail.gmail.com>
On Aug 15, 2007, at 16:12, mike zheng wrote:
> Here is the PC value before the rfi:
>
> cds8458>halt
> Target CPU: : MPC85xx (e500v2 rev.1)
> Target state : halted
> Debug entry cause : instruction breakpoint
> Current PC : 0x0000015c
> Current CR : 0x24024022
> Current MSR : 0x00012100
> Current LR :0x00000148
> Current CCSRBAR :0x0_e000000
>
> After the rfi:
>
> #step timeout defected
> cds8458>halt
> Target CPU: : MPC85xx (e500v2 rev.1)
> Target state : halted
> Debug entry cause : COP halt
> Current PC : 0xfff81300
> Current CR : 0x24024022
> Current MSR : 0x00001000
> Current LR :0x00000148
> Current CCSRBAR :0x0_e000000
Ok, I'm sure your problem isn't that SRR0 isn't getting updated
properly. I suspect something is going wrong during the rfi.
Possibly something in your TLBs. However, what is happening is most
likely that you have hit an exception, and SRR0 and SRR1 have been
updated. I'm a little confused by the addresses where you first
invoke "halt". It looks like you're in the middle of flash, which is
an odd place in u-boot to be.
And if you look at your PC, it doesn't seem like you step. It looks
like something goes wrong with the debugging. My suggestion is to
check your TLB setup and your IVOR setup. Find out if the IVORs are
pointing at an exception at fff81300.
Andy
^ permalink raw reply
* [PATCH] [POWERPC] Invalid semicolon after if statement
From: Ilpo Järvinen @ 2007-08-15 22:03 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1030 bytes --]
A similar fix to netfilter from Eric Dumazet inspired me to
look around a bit by using some grep/sed stuff as looking for
this kind of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
...Since I'm not familiar with these parts of the kernel, you might know
better than I do if this is stuff is valid...
arch/powerpc/mm/hash_utils_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f178957..a47151e 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -795,7 +795,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
#ifdef CONFIG_PPC_MM_SLICES
/* We only prefault standard pages for now */
- if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize));
+ if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize))
return;
#endif
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH] powerpc: fix i2c device string format
From: Guennadi Liakhovetski @ 2007-08-15 22:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46C3701E.3090205@freescale.com>
On Wed, 15 Aug 2007, Scott Wood wrote:
> BTW, is there any reason this stuff is fsl_soc specific? I'd think
> prom_parse.c (or better yet, drivers/of/ or drivers/i2c/, now that some OF
> calls have been factored out) would be a better place.
Minimal intrusion:-) Initially in your patch you added the
of_register_i2c_devices() function to prom_parse.c, of_find_i2c_driver()
is just an abstracted out search function, that is practically inlined in
the former one. I moved of_register_i2c_devices() into fsl_soc.c because
that's where its only (ATM) caller fsl_i2c_of_init() is. So, this way it's
all nicely inlined by the compiler, and we don't need any external
functions... If we get another user of this function, sure, we can move it
out. So far no other i2c bus driver is trying to parse OF i2c tree.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: System crash on boot_e500.S on 2.4Kernel
From: mike zheng @ 2007-08-15 22:46 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <DF88391F-F3B9-4DDB-8A27-F610E931AFB7@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]
Hi Andy,
Here is BDI output of the register value after line 212. The value of R6, R7
is 0x20, 0x160. However the value of SRR0(SPR26), SRR1(SPR27) is 0xfff81300
and 0x00001000. Why are they different from r7 and r6? We just did the
mtspr, the value should be the same. The rfi jump to 0xfff81300 is because
of the value in SRR0.
211 mtspr SRR0, r7
212 mtspr SRR1, r6
213 rfi
214
215 /*4. Clear out PIDs & Search info */
216 li r6, 0
BDI output:
cds8548>bi 0x0000015c
Breakpoint identification is 0
cds8548>go
- TARGET: stopped
cds8548>rd
GPR00: 00000000 0ffabd20 00000200 00000008
GPR04: 00000000 00000001 00000020 00000160
GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
GPR12: 00000006 764deddb 10000300 007fff00
GPR16: 00000001 ffffffff 007fff25 0ffff9d8
GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
GPR24: 00000000 00000003 02000040 007fff25
GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
CR : 24024022 MSR: 00021200
cds8548>rdspr 26
SPR 26 : 0xfff81300 - 519424
cds8548>rdspr 27
SPR 27 : 0x00001000 4096
cds8548>
On 8/15/07, Andy Fleming <afleming@freescale.com> wrote:
>
>
> On Aug 15, 2007, at 16:12, mike zheng wrote:
>
> > Here is the PC value before the rfi:
> >
> > cds8458>halt
> > Target CPU: : MPC85xx (e500v2 rev.1)
> > Target state : halted
> > Debug entry cause : instruction breakpoint
> > Current PC : 0x0000015c
> > Current CR : 0x24024022
> > Current MSR : 0x00012100
> > Current LR :0x00000148
> > Current CCSRBAR :0x0_e000000
> >
> > After the rfi:
> >
> > #step timeout defected
> > cds8458>halt
> > Target CPU: : MPC85xx (e500v2 rev.1)
> > Target state : halted
> > Debug entry cause : COP halt
> > Current PC : 0xfff81300
> > Current CR : 0x24024022
> > Current MSR : 0x00001000
> > Current LR :0x00000148
> > Current CCSRBAR :0x0_e000000
>
> Ok, I'm sure your problem isn't that SRR0 isn't getting updated
> properly. I suspect something is going wrong during the rfi.
> Possibly something in your TLBs. However, what is happening is most
> likely that you have hit an exception, and SRR0 and SRR1 have been
> updated. I'm a little confused by the addresses where you first
> invoke "halt". It looks like you're in the middle of flash, which is
> an odd place in u-boot to be.
The first halt is at 0x0000015c, which is the break point I set after line
212. It is in the memory, not flash.
And if you look at your PC, it doesn't seem like you step. It looks
> like something goes wrong with the debugging. My suggestion is to
> check your TLB setup and your IVOR setup. Find out if the IVORs are
> pointing at an exception at fff81300.
All the TLB and IVOR setup is from Uboot, the kernel haven't touched them
yet.
Andy
>
[-- Attachment #2: Type: text/html, Size: 5917 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix i2c device string format
From: Stephen Rothwell @ 2007-08-16 0:36 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0708152106090.10160@poirot.grange>
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
On Wed, 15 Aug 2007 21:15:03 +0200 (CEST) Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
>
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
> index 727453d..c0d66df 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -320,21 +320,26 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
> {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
> };
>
> -static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
> +static int __init of_find_i2c_driver(struct device_node *node,
> + struct i2c_board_info *info)
Please don't do unrelated formatting changes in a patch.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: System crash on boot_e500.S on 2.4Kernel
From: Andy Fleming @ 2007-08-16 1:16 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-embedded
In-Reply-To: <5c9cd53b0708151546y18714a46i785cdb5f23ef1536@mail.gmail.com>
On Aug 15, 2007, at 17:46, mike zheng wrote:
> Hi Andy,
>
> Here is BDI output of the register value after line 212. The value
> of R6, R7 is 0x20, 0x160. However the value of SRR0(SPR26), SRR1
> (SPR27) is 0xfff81300 and 0x00001000. Why are they different from
> r7 and r6? We just did the mtspr, the value should be the same. The
> rfi jump to 0xfff81300 is because of the value in SRR0.
Yes, it's very strange. But it's also pretty much impossible for the
mtspr to just fail like that. A more likely scenario is that the BDI
is getting bad information. Could you take a look at your IVORs?
I'm very curious to see if fff81300 is an interrupt vector.
Andy
^ permalink raw reply
* [PATCH] [POWERPC] Remove some duplicate declarations from pmac.h
From: Stephen Rothwell @ 2007-08-16 1:19 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/powermac/pmac.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/powermac/pmac.h b/arch/powerpc/platforms/powermac/pmac.h
index 6e090a7..fcde070 100644
--- a/arch/powerpc/platforms/powermac/pmac.h
+++ b/arch/powerpc/platforms/powermac/pmac.h
@@ -22,9 +22,6 @@ extern void pmac_read_rtc_time(void);
extern void pmac_calibrate_decr(void);
extern void pmac_pci_irq_fixup(struct pci_dev *);
extern void pmac_pci_init(void);
-extern unsigned long pmac_ide_get_base(int index);
-extern void pmac_ide_init_hwif_ports(hw_regs_t *hw,
- unsigned long data_port, unsigned long ctrl_port, int *irq);
extern void pmac_nvram_update(void);
extern unsigned char pmac_nvram_read_byte(int addr);
@@ -33,7 +30,6 @@ extern int pmac_pci_enable_device_hook(struct pci_dev *dev, int initial);
extern void pmac_pcibios_after_init(void);
extern int of_show_percpuinfo(struct seq_file *m, int i);
-extern void pmac_pci_init(void);
extern void pmac_setup_pci_dma(void);
extern void pmac_check_ht_link(void);
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH v2] powerpc: add setmaskedbits macros
From: Kumar Gala @ 2007-08-16 3:22 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, paulus
In-Reply-To: <11872134502476-git-send-email-timur@freescale.com>
On Aug 15, 2007, at 4:30 PM, Timur Tabi wrote:
> This patch adds the setmaskedbits_xxx() macros, which are used to
> set a
> multiple-bit bit pattern in a register. The macros include a mask,
> which
> zeros the respective bits before applying the value via a bitwise-OR.
> There are big-endian and little-endian versions for 8, 16, 32, and
> 64 bits.
>
> These new macros are useful because the setbits macros can only be
> used
> to set single-bit fields. For example, if you have a 32-bit register
> where bits 17-20 need to be set to 0100, you would do
> setmaskedbits_be32(p, 4 << 11, 0xF << 11).
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Updated the changelog to include a reason why you'd want these macros.
> I have a number of new SOC device drivers coming up that will use
> these
> macros, if this patch is accepted.
Can you post a driver that uses this. I'm interested in seeing what
the readability is really like using these macros.
- k
^ permalink raw reply
* Re: patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: David Gibson @ 2007-08-16 3:53 UTC (permalink / raw)
To: gregkh, benh, linuxppc-dev, paulus, stable-commits
In-Reply-To: <20070814074833.GG8791@localhost.localdomain>
[snip]
> I have written a new test for the handling of misaligned addresses,
> lengths and offsets for libhugetlbfs. With it I've verified that this
> patch does correct a serious problem with length handling - without
> the patch this new testcase causes an oops for me. It's simpler than
> the 'misaligned_offset' testcase in which the misaligned mapping was
> just a step to triggering a different and much more subtle kernel bug
> (where the misaligned mapping failed, but corrupted some pagetables in
> the process).
>
> But the testcase still fails because a mapping with misaligned offset
> still succeeds. Still don't know if this is related to the same slice
> changes or not. Need to do a bisect, but I'm putting it off because I
> have some other bugs to chase.
Ok, I've identified the cause of the problems with misaligned offset.
It's not with the slice code per se, but it did come in with BenH's
series of get_unmapped_area() reworks leading up to commit
4b1d89290b62bb2db476c94c82cf7442aab440c8.
Prior to that, checking that the pgoff was hugepage aligned was the
responsibility of prepare_hugepage_range(). But after that batch of
patches, prepare_hugepage_range() is only called for non-MAP_FIXED
mappings, hence the bug.
I'm not immediately sure how best to fix this:
- Replace the prepare_hugepage_range() call for non-FIXED
mappings. That will mean two different paths making calls to
prepare_hugepage_range(), which is a bit ugly. Especially since the
call for the non-FIXED case will be for an area that is already
hugepage prepared (on powerpc, the only arch with non-trivial
"preparation" necessary) so we'll just be relying on the fact that
prepare_hugepage_range() is idempotent.
- Remove the test from prepare_hugepage_range() and instead
put it in each of the hugepage get_unmapped_area() variants. Removes
the ugliness above, traps the problem reasonably early, keeps the test
for pgoff alignment close to the test for address and length
alignment, but means making the check in each of a half-dozen or so
arch versions of hugetlb_get_unmapped_area()
- Remove the test from prepare_hugepage_range() and instead
but it in the hugetlbfs ->mmap() callback. Means the fix goes in one
place only, but it's far removed from the similar tests for address
and length alignment. Also, the mmap() gets quite a long way in
before we catch the misalignment, and we have to roll-back creating
the vma and so forth.
Thoughts?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] fix non HUGETLB_PAGE build warning
From: David Gibson @ 2007-08-16 3:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070815163355.061a8e6d.sfr@canb.auug.org.au>
On Wed, Aug 15, 2007 at 04:33:55PM +1000, Stephen Rothwell wrote:
> arch/powerpc/mm/mmu_context_64.c: In function 'init_new_context':
> arch/powerpc/mm/mmu_context_64.c:31: warning: unused variable 'new_context'
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v2] powerpc: add setmaskedbits macros
From: Michael Ellerman @ 2007-08-16 3:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, paulus
In-Reply-To: <11872134502476-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]
On Wed, 2007-08-15 at 16:30 -0500, Timur Tabi wrote:
> This patch adds the setmaskedbits_xxx() macros, which are used to set a
> multiple-bit bit pattern in a register. The macros include a mask, which
> zeros the respective bits before applying the value via a bitwise-OR.
> There are big-endian and little-endian versions for 8, 16, 32, and 64 bits.
>
> These new macros are useful because the setbits macros can only be used
> to set single-bit fields. For example, if you have a 32-bit register
> where bits 17-20 need to be set to 0100, you would do
> setmaskedbits_be32(p, 4 << 11, 0xF << 11).
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Updated the changelog to include a reason why you'd want these macros.
> I have a number of new SOC device drivers coming up that will use these
> macros, if this patch is accepted.
>
> include/asm-powerpc/io.h | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
> index bb8d965..ac3defb 100644
> --- a/include/asm-powerpc/io.h
> +++ b/include/asm-powerpc/io.h
> @@ -734,6 +734,19 @@ static inline void * bus_to_virt(unsigned long address)
> #define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) | (_v))
> #define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
>
> +#ifdef __powerpc64__
> +#define setmaskedbits_be64(a, v, m) out_be64((a), (in_be64(a) & ~(m)) | (v))
> +#define setmaskedbits_le64(a, v, m) out_le64((a), (in_le64(a) & ~(m)) | (v))
> +#endif
> +
> +#define setmaskedbits_be32(a, v, m) out_be32((a), (in_be32(a) & ~(m)) | (v))
> +#define setmaskedbits_be16(a, v, m) out_be16((a), (in_be16(a) & ~(m)) | (v))
> +
> +#define setmaskedbits_le32(a, v, m) out_le32((a), (in_le32(a) & ~(m)) | (v))
> +#define setmaskedbits_le16(a, v, m) out_le16((a), (in_le16(a) & ~(m)) | (v))
> +
> +#define setmaskedbits_8(a, v, m) out_8((a), (in_8(a) & ~(m)) | (v))
Can you extract the masking logic, rather than repeating it 7 times:
#define maskbits(a, v, m) ((a) & ~(m) | (v))
And if you're going to the trouble of making a macro, why not make it a
bit more useful and have it check that the value and the mask match, ie:
(v & ~m == 0)
Final random thought, you could make the size/endian an argument:
#define setmaskedbits(a, v, m, s) out_##s((a), (in_##s(a) & ~(m) | (v))
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] tidy up CONFIG_PPC_MM_SLICES code
From: David Gibson @ 2007-08-16 3:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070815165118.ee72d00c.sfr@canb.auug.org.au>
On Wed, Aug 15, 2007 at 04:51:18PM +1000, Stephen Rothwell wrote:
> This removes some of the #ifdefs from .c files.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] [POWERPC] Fix section mismatch in pci code
From: Stephen Rothwell @ 2007-08-16 4:26 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, cbe-oss-dev
Create a helper function (alloc_maybe_bootmem) that is marked __init_refok
to limit the chances of mistakenly refferring to other __init routines.
WARNING: vmlinux.o(.text+0x2a9c4): Section mismatch: reference to .init.text:.__alloc_bootmem (between '.update_dn_pci_info' and '.pci_dn_reconfig_notifier')
WARNING: vmlinux.o(.text+0x36430): Section mismatch: reference to .init.text:.__alloc_bootmem (between '.mpic_msi_init_allocator' and '.find_ht_magic_addr')
WARNING: vmlinux.o(.text+0x5e804): Section mismatch: reference to .init.text:.__alloc_bootmem (between '.celleb_setup_phb' and '.celleb_fake_pci_write_config')
WARNING: vmlinux.o(.text+0x5e8e8): Section mismatch: reference to .init.text:.__alloc_bootmem (between '.celleb_setup_phb' and '.celleb_fake_pci_write_config')
WARNING: vmlinux.o(.text+0x5e968): Section mismatch: reference to .init.text:.__alloc_bootmem (between '.celleb_setup_phb' and '.celleb_fake_pci_write_config')
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci_dn.c | 7 +------
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/alloc.c | 14 ++++++++++++++
arch/powerpc/platforms/celleb/pci.c | 19 +++++--------------
arch/powerpc/sysdev/mpic_msi.c | 6 +-----
include/asm-powerpc/system.h | 2 ++
6 files changed, 24 insertions(+), 26 deletions(-)
create mode 100644 arch/powerpc/lib/alloc.c
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
index d7d36df..b483903 100644
--- a/arch/powerpc/kernel/pci_dn.c
+++ b/arch/powerpc/kernel/pci_dn.c
@@ -23,8 +23,6 @@
#include <linux/pci.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/slab.h>
-#include <linux/bootmem.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -45,10 +43,7 @@ static void * __devinit update_dn_pci_info(struct device_node *dn, void *data)
const u32 *regs;
struct pci_dn *pdn;
- if (mem_init_done)
- pdn = kmalloc(sizeof(*pdn), GFP_KERNEL);
- else
- pdn = alloc_bootmem(sizeof(*pdn));
+ pdn = alloc_maybe_bootmem(sizeof(*pdn), GFP_KERNEL);
if (pdn == NULL)
return NULL;
memset(pdn, 0, sizeof(*pdn));
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 0a486d4..23bbb1e 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -7,7 +7,7 @@ EXTRA_CFLAGS += -mno-minimal-toc
endif
ifeq ($(CONFIG_PPC_MERGE),y)
-obj-y := string.o
+obj-y := string.o alloc.o
obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
endif
diff --git a/arch/powerpc/lib/alloc.c b/arch/powerpc/lib/alloc.c
new file mode 100644
index 0000000..e58c805
--- /dev/null
+++ b/arch/powerpc/lib/alloc.c
@@ -0,0 +1,14 @@
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/bootmem.h>
+
+#include <asm/system.h>
+
+void * __init_refok alloc_maybe_bootmem(size_t size, gfp_t mask)
+{
+ if (mem_init_done)
+ return kmalloc(size, mask);
+ else
+ return alloc_bootmem(size);
+}
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index e9ac19c..f847c32 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -327,10 +327,7 @@ static int __devinit celleb_setup_fake_pci_device(struct device_node *node,
size = 256;
config = &private->fake_config[devno][fn];
- if (mem_init_done)
- *config = kzalloc(size, GFP_KERNEL);
- else
- *config = alloc_bootmem(size);
+ *config = alloc_maybe_bootmem(size, GFP_KERNEL);
if (*config == NULL) {
printk(KERN_ERR "PCI: "
"not enough memory for fake configuration space\n");
@@ -341,10 +338,7 @@ static int __devinit celleb_setup_fake_pci_device(struct device_node *node,
size = sizeof(struct celleb_pci_resource);
res = &private->res[devno][fn];
- if (mem_init_done)
- *res = kzalloc(size, GFP_KERNEL);
- else
- *res = alloc_bootmem(size);
+ *res = alloc_maybe_bootmem(size, GFP_KERNEL);
if (*res == NULL) {
printk(KERN_ERR
"PCI: not enough memory for resource data space\n");
@@ -436,12 +430,9 @@ static int __devinit phb_set_bus_ranges(struct device_node *dev,
static void __devinit celleb_alloc_private_mem(struct pci_controller *hose)
{
- if (mem_init_done)
- hose->private_data =
- kzalloc(sizeof(struct celleb_pci_private), GFP_KERNEL);
- else
- hose->private_data =
- alloc_bootmem(sizeof(struct celleb_pci_private));
+ hose->private_data =
+ alloc_maybe_bootmem(sizeof(struct celleb_pci_private),
+ GFP_KERNEL);
}
int __devinit celleb_setup_phb(struct pci_controller *phb)
diff --git a/arch/powerpc/sysdev/mpic_msi.c b/arch/powerpc/sysdev/mpic_msi.c
index b076793..53fa9f5 100644
--- a/arch/powerpc/sysdev/mpic_msi.c
+++ b/arch/powerpc/sysdev/mpic_msi.c
@@ -9,7 +9,6 @@
*/
#include <linux/irq.h>
-#include <linux/bootmem.h>
#include <linux/bitmap.h>
#include <linux/msi.h>
#include <asm/mpic.h>
@@ -151,10 +150,7 @@ int mpic_msi_init_allocator(struct mpic *mpic)
size = BITS_TO_LONGS(mpic->irq_count) * sizeof(long);
pr_debug("mpic: allocator bitmap size is 0x%x bytes\n", size);
- if (mem_init_done)
- mpic->hwirq_bitmap = kmalloc(size, GFP_KERNEL);
- else
- mpic->hwirq_bitmap = alloc_bootmem(size);
+ mpic->hwirq_bitmap = alloc_maybe_bootmem(size, GFP_KERNEL);
if (!mpic->hwirq_bitmap) {
pr_debug("mpic: ENOMEM allocating allocator bitmap!\n");
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index f9e2a04..06b0d88 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -181,6 +181,8 @@ extern int mem_init_done; /* set on boot once kmalloc can be called */
extern unsigned long memory_limit;
extern unsigned long klimit;
+extern void *alloc_maybe_bootmem(size_t size, gfp_t mask);
+
extern int powersave_nap; /* set if nap mode can be used in idle loop */
/*
--
1.5.2.4
^ permalink raw reply related
* Re: [Documentation] Page Table Layout diagrams
From: David Gibson @ 2007-08-16 5:12 UTC (permalink / raw)
To: Adam Litke; +Cc: linux-mm, linux-kernel, linuxppc-dev
In-Reply-To: <1186598865.23817.76.camel@localhost.localdomain>
On Wed, Aug 08, 2007 at 01:47:45PM -0500, Adam Litke wrote:
> Hello all. In an effort to understand how the page tables are laid out
> across various architectures I put together some diagrams. I have
> posted them on the linux-mm wiki: http://linux-mm.org/PageTableStructure
> and I hope they will be useful to others.
>
> Just to make sure I am not spreading misinformation, could a few of you
> experts take a quick look at the three diagrams I've got finished so far
> and point out any errors I have made? Thanks.
Nice. Didn't spot any innaccuracies.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC 440EPx: Sequoia bootwrapper
From: David Gibson @ 2007-08-16 5:51 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46C2F022.8070106@ru.mvista.com>
On Wed, Aug 15, 2007 at 04:22:58PM +0400, Valentine Barshak wrote:
> David Gibson wrote:
> > On Tue, Aug 14, 2007 at 10:53:55PM +0400, Valentine Barshak wrote:
> >> Bootwrapper code for AMCC 440EPx Sequoia board.
> >> The DDR2 Denali controller support has been moved to
> >> arch/powerpc/boot/4xx.c
> >> The code also uses 440EP clocking fixups
> >> initially provided for 440EP Bamboo.
> >>
> >> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> >
> > [snip]
> >> diff -ruN linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c linux-2.6/arch/powerpc/boot/cuboot-sequoia.c
> >> --- linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 1970-01-01 03:00:00.000000000 +0300
> >> +++ linux-2.6/arch/powerpc/boot/cuboot-sequoia.c 2007-08-14 17:25:37.000000000 +0400
> >> @@ -0,0 +1,31 @@
> >> +/*
> >> + * Old U-boot compatibility for Sequoia
> >> + *
> >> + * Based on Ebony code by David Gibson <david@gibson.dropbear.id.au>
> >> + *
> >> + * Copyright 2007 David Gibson, IBM Corporatio.
> >> + * Based on cuboot-83xx.c, which is:
> >> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General Public License version 2 as published
> >> + * by the Free Software Foundation.
> >> + */
> >> +
> >> +#include "ops.h"
> >> +#include "stdio.h"
> >> +#include "44x.h"
> >> +#include "cuboot.h"
> >> +
> >> +#define TARGET_4xx
> >> +#define TARGET_44x
> >
> > Surely you need to be more specific than that to select the correct
> > bd_t structure?
>
> Both TARGET_4xx and TARGET_44x should be selected for 44x. Otherwise I
> get wrong bd_t structure (wrong offsets to the eth0/eth1 MAC addresses).
> In the older arch/ppc code it used to be CONFIG_4xx and it was selected
> for CONFIG_40x and CONFIG_44x as well.
Yes, I'm not objecting to those TARGET macros, but I'd be very
surprised if you don't need more to really get the correct bd_t
structure.
[snip]
> >> diff -ruN linux-2.6.orig/arch/powerpc/boot/sequoia.c linux-2.6/arch/powerpc/boot/sequoia.c
> >> --- linux-2.6.orig/arch/powerpc/boot/sequoia.c 1970-01-01 03:00:00.000000000 +0300
> >> +++ linux-2.6/arch/powerpc/boot/sequoia.c 2007-08-14 20:52:10.000000000 +0400
> >
> > Unless another bootloader is expected to come along for Sequoia,
> > there's no reason to separate sequoia.c from cuboot-sequoia.c
>
> The previous version of Sequoia series had treeboot-sequoia.c, but I've
> removed it since only u-boot is used now.
> I'm not sure if there are any other bootloaders expected, but is it OK
> if I leave 2 separate files just in case? :)
Not unless you have a particular reason to expect another bootloader
will come along, which doesn't seem that likely to me. Or rather the
only likely future bootloader I'd see is newer versions of u-boot
which are device tree aware and handled separately anyway.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 4/4] PowerPC 440EPx: Sequoia board support
From: David Gibson @ 2007-08-16 5:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070815134309.169dffe8@zod.rchland.ibm.com>
On Wed, Aug 15, 2007 at 01:43:09PM -0500, Josh Boyer wrote:
> On Wed, 15 Aug 2007 17:53:00 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > David Gibson wrote:
> > >> diff -ruN linux-2.6.orig/arch/powerpc/kernel/head_44x.S linux-2.6/arch/powerpc/kernel/head_44x.S
> > >> --- linux-2.6.orig/arch/powerpc/kernel/head_44x.S 2007-08-14 17:11:19.000000000 +0400
> > >> +++ linux-2.6/arch/powerpc/kernel/head_44x.S 2007-08-14 17:18:43.000000000 +0400
> > >> @@ -217,7 +217,7 @@
> > >> lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
> > >> mtspr SPRN_IVPR,r4
> > >>
> > >> -#ifdef CONFIG_440EP
> > >> +#if defined(CONFIG_440EP) || defined(CONFIG_440EPX)
> > >
> > > Since we should now be able to support both 440GP and 440EP boards in
> > > the same kernel, this probably needs to become a feature section.
> > >
> >
> > Thanks for pointing that out.
> > Talking about this, there appears to be more stuff that would need to
> > become feature sections. There're lots of other ifdefs in
> > arch/powerpc/kernel/head_44x.S, like ifdef CONFIG_PPC_FPU or ifdef
> > CONFIG_440A
> > Looks like all these things have to be detected dynamically and
> > configured properly at runtime since we tend to support more than one
> > CPU in the same kernel.
>
> Yes, definitely. It's on my TODO list. The "multiplatformness" of 44x
> at the moment needs work.
True. Note that not all of them necessarily need to change to feature
sections, though most of them probably do: if the code inside is
harmless, just useless for other platforms it can remain an #ifdef -
the code will run on any kernel with the relevant platform configured.
> > I think this should come as a separate patch, that replaces all these
> > ifdefs with the FTR_SECTION stuff.
>
> I agree. I'd like to do this as a separate patch later rather than hold
> up Sequoia at the moment.
Fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 1/2] Add scaled time to taskstats based process accounting
From: Michael Neuling @ 2007-08-16 7:09 UTC (permalink / raw)
To: Paul Mackerras, Andrew Morton, linuxppc-dev, linux-kernel
Cc: Michael Neuling, Balbir Singh
This adds two items to the taststats struct to account for user and
system time based on scaling the CPU frequency and instruction issue
rates.
Adds account_(user|system)_time_scaled callbacks which architectures
can use to account for time using this mechanism.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
include/linux/kernel_stat.h | 2 ++
include/linux/sched.h | 2 +-
include/linux/taskstats.h | 6 +++++-
kernel/fork.c | 2 ++
kernel/sched.c | 21 +++++++++++++++++++++
kernel/timer.c | 7 +++++--
kernel/tsacct.c | 4 ++++
7 files changed, 40 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/include/linux/kernel_stat.h
===================================================================
--- linux-2.6-ozlabs.orig/include/linux/kernel_stat.h
+++ linux-2.6-ozlabs/include/linux/kernel_stat.h
@@ -52,7 +52,9 @@ static inline int kstat_irqs(int irq)
}
extern void account_user_time(struct task_struct *, cputime_t);
+extern void account_user_time_scaled(struct task_struct *, cputime_t);
extern void account_system_time(struct task_struct *, int, cputime_t);
+extern void account_system_time_scaled(struct task_struct *, cputime_t);
extern void account_steal_time(struct task_struct *, cputime_t);
#endif /* _LINUX_KERNEL_STAT_H */
Index: linux-2.6-ozlabs/include/linux/sched.h
===================================================================
--- linux-2.6-ozlabs.orig/include/linux/sched.h
+++ linux-2.6-ozlabs/include/linux/sched.h
@@ -1020,7 +1020,7 @@ struct task_struct {
int __user *clear_child_tid; /* CLONE_CHILD_CLEARTID */
unsigned int rt_priority;
- cputime_t utime, stime;
+ cputime_t utime, stime, utimescaled, stimescaled;
unsigned long nvcsw, nivcsw; /* context switch counts */
struct timespec start_time; /* monotonic time */
struct timespec real_start_time; /* boot based time */
Index: linux-2.6-ozlabs/include/linux/taskstats.h
===================================================================
--- linux-2.6-ozlabs.orig/include/linux/taskstats.h
+++ linux-2.6-ozlabs/include/linux/taskstats.h
@@ -31,7 +31,7 @@
*/
-#define TASKSTATS_VERSION 5
+#define TASKSTATS_VERSION 6
#define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN
* in linux/sched.h */
@@ -142,6 +142,10 @@ struct taskstats {
__u64 write_char; /* bytes written */
__u64 read_syscalls; /* read syscalls */
__u64 write_syscalls; /* write syscalls */
+
+ /* time accounting for SMT machines */
+ __u64 ac_utimescaled; /* utime scaled on frequency etc */
+ __u64 ac_stimescaled; /* stime scaled on frequency etc */
/* Extended accounting fields end */
#define TASKSTATS_HAS_IO_ACCOUNTING
Index: linux-2.6-ozlabs/kernel/fork.c
===================================================================
--- linux-2.6-ozlabs.orig/kernel/fork.c
+++ linux-2.6-ozlabs/kernel/fork.c
@@ -1045,6 +1045,8 @@ static struct task_struct *copy_process(
p->utime = cputime_zero;
p->stime = cputime_zero;
+ p->utimescaled = cputime_zero;
+ p->stimescaled = cputime_zero;
#ifdef CONFIG_TASK_XACCT
p->rchar = 0; /* I/O counter: bytes read */
Index: linux-2.6-ozlabs/kernel/sched.c
===================================================================
--- linux-2.6-ozlabs.orig/kernel/sched.c
+++ linux-2.6-ozlabs/kernel/sched.c
@@ -3249,6 +3249,16 @@ void account_user_time(struct task_struc
}
/*
+ * Account scaled user cpu time to a process.
+ * @p: the process that the cpu time gets accounted to
+ * @cputime: the cpu time spent in user space since the last update
+ */
+void account_user_time_scaled(struct task_struct *p, cputime_t cputime)
+{
+ p->utimescaled = cputime_add(p->utimescaled, cputime);
+}
+
+/*
* Account system cpu time to a process.
* @p: the process that the cpu time gets accounted to
* @hardirq_offset: the offset to subtract from hardirq_count()
@@ -3280,6 +3290,17 @@ void account_system_time(struct task_str
}
/*
+ * Account scaled system cpu time to a process.
+ * @p: the process that the cpu time gets accounted to
+ * @hardirq_offset: the offset to subtract from hardirq_count()
+ * @cputime: the cpu time spent in kernel space since the last update
+ */
+void account_system_time_scaled(struct task_struct *p, cputime_t cputime)
+{
+ p->stimescaled = cputime_add(p->stimescaled, cputime);
+}
+
+/*
* Account for involuntary wait time.
* @p: the process from which the cpu time has been stolen
* @steal: the cpu time spent in involuntary wait
Index: linux-2.6-ozlabs/kernel/timer.c
===================================================================
--- linux-2.6-ozlabs.orig/kernel/timer.c
+++ linux-2.6-ozlabs/kernel/timer.c
@@ -826,10 +826,13 @@ void update_process_times(int user_tick)
int cpu = smp_processor_id();
/* Note: this timer irq context must be accounted for as well. */
- if (user_tick)
+ if (user_tick) {
account_user_time(p, jiffies_to_cputime(1));
- else
+ account_user_time_scaled(p, jiffies_to_cputime(1));
+ } else {
account_system_time(p, HARDIRQ_OFFSET, jiffies_to_cputime(1));
+ account_system_time_scaled(p, jiffies_to_cputime(1));
+ }
run_local_timers();
if (rcu_pending(cpu))
rcu_check_callbacks(cpu, user_tick);
Index: linux-2.6-ozlabs/kernel/tsacct.c
===================================================================
--- linux-2.6-ozlabs.orig/kernel/tsacct.c
+++ linux-2.6-ozlabs/kernel/tsacct.c
@@ -62,6 +62,10 @@ void bacct_add_tsk(struct taskstats *sta
rcu_read_unlock();
stats->ac_utime = cputime_to_msecs(tsk->utime) * USEC_PER_MSEC;
stats->ac_stime = cputime_to_msecs(tsk->stime) * USEC_PER_MSEC;
+ stats->ac_utimescaled =
+ cputime_to_msecs(tsk->utimescaled) * USEC_PER_MSEC;
+ stats->ac_stimescaled =
+ cputime_to_msecs(tsk->stimescaled) * USEC_PER_MSEC;
stats->ac_minflt = tsk->min_flt;
stats->ac_majflt = tsk->maj_flt;
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Add scaled time accounting
From: Michael Neuling @ 2007-08-16 7:09 UTC (permalink / raw)
To: Paul Mackerras, Andrew Morton, linuxppc-dev, linux-kernel
Cc: Michael Neuling, Balbir Singh
This adds POWERPC specific hooks for scaled time accounting.
POWER6 includes a SPURR register. The SPURR is based off the PURR
register but is scaled based on CPU frequency and issue rates. This
gives a more accurate account of the instructions used per task. The
PURR and timebase will be constant relative to the wall clock,
irrespective of the CPU frequency.
This implementation reads the SPURR register in account_system_vtime
which is only call called on context witch and hard and soft irq entry
and exit. The percentage of user and system time is then estimated
using the ratio of these accounted by the PURR. If the SPURR is not
present, the PURR read.
An earlier implementation of this patch read the SPURR whenever the
PURR was read, which included the system call entry and exit path.
Unfortunately this showed a performance regression on lmbench runs, so
was re-implemented.
I've included the lmbench results here when run bare metal on POWER6.
1st column is the unpatch results. 2nd column is the results using the
below patch and the 3rd is the % diff of these results from the base.
4th and 5th columns are the results and % differnce from the base
using the older patch (SPURR read in syscall entry/exit path).
Base Scaled-Acct SPURR-in-syscall
Result Result % diff Result % diff
Simple syscall: 0.3086 0.3086 0.0000 0.3452 11.8600
Simple read: 0.4591 0.4671 1.7425 0.5044 9.86713
Simple write: 0.4364 0.4366 0.0458 0.4731 8.40971
Simple stat: 2.0055 2.0295 1.1967 2.0669 3.06158
Simple fstat: 0.5962 0.5876 -1.442 0.6368 6.80979
Simple open/close: 3.1283 3.1009 -0.875 3.2088 2.57328
Select on 10 fd's: 0.8554 0.8457 -1.133 0.8667 1.32101
Select on 100 fd's: 3.5292 3.6329 2.9383 3.6664 3.88756
Select on 250 fd's: 7.9097 8.1881 3.5197 8.2242 3.97613
Select on 500 fd's: 15.2659 15.836 3.7357 15.873 3.97814
Select on 10 tcp fd's: 0.9576 0.9416 -1.670 0.9752 1.83792
Select on 100 tcp fd's: 7.248 7.2254 -0.311 7.2685 0.28283
Select on 250 tcp fd's: 17.7742 17.707 -0.375 17.749 -0.1406
Select on 500 tcp fd's: 35.4258 35.25 -0.496 35.286 -0.3929
Signal handler installation: 0.6131 0.6075 -0.913 0.647 5.52927
Signal handler overhead: 2.0919 2.1078 0.7600 2.1831 4.35967
Protection fault: 0.7345 0.7478 1.8107 0.8031 9.33968
Pipe latency: 33.006 16.398 -50.31 33.475 1.42368
AF_UNIX sock stream latency: 14.5093 30.910 113.03 30.715 111.692
Process fork+exit: 219.8 222.8 1.3648 229.37 4.35623
Process fork+execve: 876.14 873.28 -0.32 868.66 -0.8533
Process fork+/bin/sh -c: 2830 2876.5 1.6431 2958 4.52296
File /var/tmp/XXX write bw: 1193497 1195536 0.1708 118657 -0.5799
Pagefaults on /var/tmp/XXX: 3.1272 3.2117 2.7020 3.2521 3.99398
Also, kernel compile times show no difference with this patch applied.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/time.c | 32 ++++++++++++++++++++++++++++++--
include/asm-powerpc/paca.h | 3 +++
3 files changed, 34 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/asm-offsets.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
@@ -141,6 +141,7 @@ int main(void)
DEFINE(PACALPPACAPTR, offsetof(struct paca_struct, lppaca_ptr));
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACA_STARTPURR, offsetof(struct paca_struct, startpurr));
+ DEFINE(PACA_STARTSPURR, offsetof(struct paca_struct, startspurr));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -168,23 +168,44 @@ static u64 read_purr(void)
}
/*
+ * Read the SPURR on systems that have it, otherwise the purr
+ */
+static u64 read_spurr(void)
+{
+ if (cpu_has_feature(CPU_FTR_SPURR))
+ return mfspr(SPRN_SPURR);
+ return read_purr();
+}
+
+/*
* Account time for a transition between system, hard irq
* or soft irq state.
*/
void account_system_vtime(struct task_struct *tsk)
{
- u64 now, delta;
+ u64 now, nowscaled, delta, deltascaled;
unsigned long flags;
local_irq_save(flags);
now = read_purr();
delta = now - get_paca()->startpurr;
get_paca()->startpurr = now;
+ nowscaled = read_spurr();
+ deltascaled = nowscaled - get_paca()->startspurr;
+ get_paca()->startspurr = nowscaled;
if (!in_interrupt()) {
+ /* deltascaled includes both user and system time.
+ * Hence scale it based on the purr ratio to estimate
+ * the system time */
+ deltascaled = deltascaled * get_paca()->system_time /
+ (get_paca()->system_time + get_paca()->user_time);
delta += get_paca()->system_time;
get_paca()->system_time = 0;
}
account_system_time(tsk, 0, delta);
+ get_paca()->purrdelta = delta;
+ account_system_time_scaled(tsk, deltascaled);
+ get_paca()->spurrdelta = deltascaled;
local_irq_restore(flags);
}
@@ -196,11 +217,17 @@ void account_system_vtime(struct task_st
*/
void account_process_vtime(struct task_struct *tsk)
{
- cputime_t utime;
+ cputime_t utime, utimescaled;
utime = get_paca()->user_time;
get_paca()->user_time = 0;
account_user_time(tsk, utime);
+
+ /* Estimate the scaled utime by scaling the real utime based
+ * on the last spurr to purr ratio */
+ utimescaled = utime * get_paca()->spurrdelta / get_paca()->purrdelta;
+ get_paca()->spurrdelta = get_paca()->purrdelta = 0;
+ account_user_time_scaled(tsk, utimescaled);
}
static void account_process_time(struct pt_regs *regs)
@@ -222,6 +249,7 @@ struct cpu_purr_data {
int initialized; /* thread is running */
u64 tb; /* last TB value read */
u64 purr; /* last PURR value read */
+ u64 spurr; /* last SPURR value read */
};
/*
Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
@@ -103,6 +103,9 @@ struct paca_struct {
u64 user_time; /* accumulated usermode TB ticks */
u64 system_time; /* accumulated system TB ticks */
u64 startpurr; /* PURR/TB value snapshot */
+ u64 startspurr; /* SPURR value snapshot */
+ u64 purrdelta; /* FIXME: document */
+ u64 spurrdelta; /* FIXME: document */
};
extern struct paca_struct paca[];
^ permalink raw reply
* Re: System crash on boot_e500.S
From: Geert Uytterhoeven @ 2007-08-16 7:15 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <5c9cd53b0708151423r1c9748e5jbd460cd72585020c@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1496 bytes --]
On Wed, 15 Aug 2007, mike zheng wrote:
> On 8/15/07, Scott Wood <scottwood@freescale.com> wrote:
> > mike zheng wrote:
> > > Unfortunately, all the applications are running on 2.4 kernel. I can not
> > > just throw the 2.4 kernel.
> >
> > And in what way does 2.6 break these applications?
>
> All the device drivers are based on 2.4 kernel. We plan to upgrade to 2.6 in
^^^^^^^^
derived from?
> the middle of next year.
> > Any suggest or comment is welcome, I am struggling with this issue for
> > > almost one week...... :-(
> >
> > How long would you have struggled with getting your applications running
> > on a more recent kernel instead?
>
>
> Don't know, maybe 16 weeks. That is out of my control. I only deal with the
> kernel.....:-)
Ah, good, so the device drivers are in user space.
What in user space has changed completely between 2.4 and 2.6?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center 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@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH v2] powerpc: add setmaskedbits macros
From: Geert Uytterhoeven @ 2007-08-16 7:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus, Timur Tabi
In-Reply-To: <1187236548.8375.13.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1282 bytes --]
On Thu, 16 Aug 2007, Michael Ellerman wrote:
> Can you extract the masking logic, rather than repeating it 7 times:
>
> #define maskbits(a, v, m) ((a) & ~(m) | (v))
>
> And if you're going to the trouble of making a macro, why not make it a
> bit more useful and have it check that the value and the mask match, ie:
>
> (v & ~m == 0)
>
> Final random thought, you could make the size/endian an argument:
>
> #define setmaskedbits(a, v, m, s) out_##s((a), (in_##s(a) & ~(m) | (v))
For readability, you can change the parameter names `v' and `m' to e.g. `set'
and `clear' (or `clr'), so people don't have to look through the actual
definitions to know which one comes first?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center 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@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] [POWERPC] Invalid semicolon after if statement
From: Geert Uytterhoeven @ 2007-08-16 7:22 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.64.0708151644090.15670@kivilampi-30.cs.helsinki.fi>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1810 bytes --]
On Thu, 16 Aug 2007, [ISO-8859-1] Ilpo Järvinen wrote:
> A similar fix to netfilter from Eric Dumazet inspired me to
> look around a bit by using some grep/sed stuff as looking for
> this kind of bugs seemed easy to automate. This is one of them
> I found where it looks like this semicolon is not valid.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> ---
>
> ...Since I'm not familiar with these parts of the kernel, you might know
> better than I do if this is stuff is valid...
>
> arch/powerpc/mm/hash_utils_64.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index f178957..a47151e 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -795,7 +795,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
>
> #ifdef CONFIG_PPC_MM_SLICES
> /* We only prefault standard pages for now */
> - if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize));
> + if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize))
> return;
> #endif
Interestingly the test has `unlikely'. So the bug showed up in the `likely'
case...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center 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@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 1/2] Add scaled time to taskstats based process accounting
From: Balbir Singh @ 2007-08-16 7:26 UTC (permalink / raw)
To: Michael Neuling; +Cc: Andrew Morton, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20070816070922.37B5370074@localhost.localdomain>
Hi, Michael,
Thanks for doing this, this is really useful.
Michael Neuling wrote:
> This adds two items to the taststats struct to account for user and
> system time based on scaling the CPU frequency and instruction issue
> rates.
>
> Adds account_(user|system)_time_scaled callbacks which architectures
> can use to account for time using this mechanism.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
>
> ---
>
> include/linux/kernel_stat.h | 2 ++
> include/linux/sched.h | 2 +-
> include/linux/taskstats.h | 6 +++++-
> kernel/fork.c | 2 ++
> kernel/sched.c | 21 +++++++++++++++++++++
> kernel/timer.c | 7 +++++--
> kernel/tsacct.c | 4 ++++
> 7 files changed, 40 insertions(+), 4 deletions(-)
>
> Index: linux-2.6-ozlabs/include/linux/kernel_stat.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/linux/kernel_stat.h
> +++ linux-2.6-ozlabs/include/linux/kernel_stat.h
> @@ -52,7 +52,9 @@ static inline int kstat_irqs(int irq)
> }
>
> extern void account_user_time(struct task_struct *, cputime_t);
> +extern void account_user_time_scaled(struct task_struct *, cputime_t);
> extern void account_system_time(struct task_struct *, int, cputime_t);
> +extern void account_system_time_scaled(struct task_struct *, cputime_t);
> extern void account_steal_time(struct task_struct *, cputime_t);
>
> #endif /* _LINUX_KERNEL_STAT_H */
> Index: linux-2.6-ozlabs/include/linux/sched.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/linux/sched.h
> +++ linux-2.6-ozlabs/include/linux/sched.h
> @@ -1020,7 +1020,7 @@ struct task_struct {
> int __user *clear_child_tid; /* CLONE_CHILD_CLEARTID */
>
> unsigned int rt_priority;
> - cputime_t utime, stime;
> + cputime_t utime, stime, utimescaled, stimescaled;
> unsigned long nvcsw, nivcsw; /* context switch counts */
> struct timespec start_time; /* monotonic time */
> struct timespec real_start_time; /* boot based time */
> Index: linux-2.6-ozlabs/include/linux/taskstats.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/linux/taskstats.h
> +++ linux-2.6-ozlabs/include/linux/taskstats.h
> @@ -31,7 +31,7 @@
> */
>
>
> -#define TASKSTATS_VERSION 5
> +#define TASKSTATS_VERSION 6
> #define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN
> * in linux/sched.h */
>
> @@ -142,6 +142,10 @@ struct taskstats {
> __u64 write_char; /* bytes written */
> __u64 read_syscalls; /* read syscalls */
> __u64 write_syscalls; /* write syscalls */
> +
> + /* time accounting for SMT machines */
> + __u64 ac_utimescaled; /* utime scaled on frequency etc */
> + __u64 ac_stimescaled; /* stime scaled on frequency etc */
> /* Extended accounting fields end */
>
I'd also request for you to add a cpu_scaled_run_real_total for use
by delay accounting. cpu_scaled_run_real_total should be similar in
functionality to cpu_run_real_total.
> #define TASKSTATS_HAS_IO_ACCOUNTING
> Index: linux-2.6-ozlabs/kernel/fork.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/kernel/fork.c
> +++ linux-2.6-ozlabs/kernel/fork.c
> @@ -1045,6 +1045,8 @@ static struct task_struct *copy_process(
>
> p->utime = cputime_zero;
> p->stime = cputime_zero;
> + p->utimescaled = cputime_zero;
> + p->stimescaled = cputime_zero;
>
> #ifdef CONFIG_TASK_XACCT
> p->rchar = 0; /* I/O counter: bytes read */
> Index: linux-2.6-ozlabs/kernel/sched.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/kernel/sched.c
> +++ linux-2.6-ozlabs/kernel/sched.c
> @@ -3249,6 +3249,16 @@ void account_user_time(struct task_struc
> }
>
> /*
> + * Account scaled user cpu time to a process.
> + * @p: the process that the cpu time gets accounted to
> + * @cputime: the cpu time spent in user space since the last update
> + */
> +void account_user_time_scaled(struct task_struct *p, cputime_t cputime)
> +{
> + p->utimescaled = cputime_add(p->utimescaled, cputime);
> +}
> +
> +/*
> * Account system cpu time to a process.
> * @p: the process that the cpu time gets accounted to
> * @hardirq_offset: the offset to subtract from hardirq_count()
> @@ -3280,6 +3290,17 @@ void account_system_time(struct task_str
> }
>
> /*
> + * Account scaled system cpu time to a process.
> + * @p: the process that the cpu time gets accounted to
> + * @hardirq_offset: the offset to subtract from hardirq_count()
> + * @cputime: the cpu time spent in kernel space since the last update
> + */
> +void account_system_time_scaled(struct task_struct *p, cputime_t cputime)
> +{
> + p->stimescaled = cputime_add(p->stimescaled, cputime);
> +}
> +
> +/*
> * Account for involuntary wait time.
> * @p: the process from which the cpu time has been stolen
> * @steal: the cpu time spent in involuntary wait
> Index: linux-2.6-ozlabs/kernel/timer.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/kernel/timer.c
> +++ linux-2.6-ozlabs/kernel/timer.c
> @@ -826,10 +826,13 @@ void update_process_times(int user_tick)
> int cpu = smp_processor_id();
>
> /* Note: this timer irq context must be accounted for as well. */
> - if (user_tick)
> + if (user_tick) {
> account_user_time(p, jiffies_to_cputime(1));
> - else
> + account_user_time_scaled(p, jiffies_to_cputime(1));
> + } else {
> account_system_time(p, HARDIRQ_OFFSET, jiffies_to_cputime(1));
> + account_system_time_scaled(p, jiffies_to_cputime(1));
> + }
I am a little confused here, scaled accounting and regular accounting
go hand in hand?
> run_local_timers();
> if (rcu_pending(cpu))
> rcu_check_callbacks(cpu, user_tick);
> Index: linux-2.6-ozlabs/kernel/tsacct.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/kernel/tsacct.c
> +++ linux-2.6-ozlabs/kernel/tsacct.c
> @@ -62,6 +62,10 @@ void bacct_add_tsk(struct taskstats *sta
> rcu_read_unlock();
> stats->ac_utime = cputime_to_msecs(tsk->utime) * USEC_PER_MSEC;
> stats->ac_stime = cputime_to_msecs(tsk->stime) * USEC_PER_MSEC;
> + stats->ac_utimescaled =
> + cputime_to_msecs(tsk->utimescaled) * USEC_PER_MSEC;
> + stats->ac_stimescaled =
> + cputime_to_msecs(tsk->stimescaled) * USEC_PER_MSEC;
> stats->ac_minflt = tsk->min_flt;
> stats->ac_majflt = tsk->maj_flt;
>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Problem getting a webserver running
From: Johan Borkhuis @ 2007-08-16 8:01 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to get a webserver on my embedded target box (an MVME3100
PPC board, running ELDK 4.1 with kernel 2.6.14). I can start httpd, but
when I try to connect I do not get any data. The connection is
established (using telnet localhost 80), but I do not get any data back
from the server. I also do not see any entries in the logfile.
Also, when I use appWeb or GoAhead webserver, I see the same problem.
What could be causing this?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Re: PS3 improved video mode autodetection for HDMI/DVI
From: Stefan Assmann @ 2007-08-16 8:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development,
Ben Collins
In-Reply-To: <Pine.LNX.4.62.0707121029320.12797@pademelon.sonytel.be>
Geert Uytterhoeven schrieb:
> If it fails, please add `#define DEBUG' to drivers/ps3/ps3av.c, send me the
> `Monitor Info' output in the kernel log (dmesg), and tell me which of the
> PS3 video modes (1-13) work and which don't. ps3av has a quirk database for
> monitors that advertise non-working modes, so it can probably be fixed.
> (BTW, even if autodetect works fine, I always welcome this information)
>
Samsung SyncMaster 226BW
The autodetection leaves me with an unsupported resolution. I tried
adding the monitor to the quirk list. Works fine now. Using 720p as
default resolution might be worth a thought. This should work on all HD
screen.
GOOD: 2,3,5,7,8,10,11,12,13
BAD: 1,4,6,9
Monitor Info: size 96
avport: 00
monitor_id: 4c 2d 7f 02 32 32 45 4d 0d 11
monitor_type: 02
monitor_name: SyncMaster
resolution_60: bits: 0000000d native: 00000000
resolution_50: bits: 00000000 native: 00000000
resolution_other: bits: 00000000 native: 00000000
resolution_vesa: bits: 00000001 native: 00000000
color space rgb: 01
color space yuv444: 00
color space yuv422: 00
color info red: X 0293 Y 0155
color info green: X 0125 Y 0269
color info blue: X 009c Y 0051
color info white: X 0141 Y 0151
color info gamma: 000000dc
supported_AI: 00
speaker_info: 00
num of audio: 00
ps3av_hdmi_get_id: Using supported mode 4
btw, I get the following message while booting:
PS3AV_CID_AV_VIDEO_DISABLE_SIG: failed 2 port 10
does this ring a bell? I'm using kernel 2.6.22 with ps3 patches
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] Invalid semicolon after if statement
From: Michael Ellerman @ 2007-08-16 8:08 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.64.0708151644090.15670@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On Thu, 2007-08-16 at 01:03 +0300, Ilpo Järvinen wrote:
> A similar fix to netfilter from Eric Dumazet inspired me to
> look around a bit by using some grep/sed stuff as looking for
> this kind of bugs seemed easy to automate. This is one of them
> I found where it looks like this semicolon is not valid.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> ---
>
> ...Since I'm not familiar with these parts of the kernel, you might know
> better than I do if this is stuff is valid...
>
> arch/powerpc/mm/hash_utils_64.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index f178957..a47151e 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -795,7 +795,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
>
> #ifdef CONFIG_PPC_MM_SLICES
> /* We only prefault standard pages for now */
> - if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize));
> + if (unlikely(get_slice_psize(mm, ea) != mm->context.user_psize))
> return;
> #endif
Er yeah that's bad. On kernels with MM_SLICES set we never prefault
anything .. oops ..
And testing confirms that's what's happening, with the semicolon gone we
do prefault somethings.
Thanks to the frickin compiler for warning us, not.
This should probably go to stable for 22 IMHO.
Nice catch Ilpo, perhaps someone should hack sparse to check for that
sort of thing.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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