Re: [PATCH 4/5] powerpc: Make the 64-bit kernel as a position-independent executable
Hi Paul,
This patch breaks my build with the following error:
/u1/rmachet/projects/c2k/linux-powerpc-git $ make cuImage.c2k modules
ARCH=powerpc V=1
...
powerpc-linux-gnu-ld -m elf32ppc -Bstatic -o .tmp_vmlinux1 -T
arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o
arch/powerpc/kernel/fpu.o init/built-in.o --start-group usr/built-in.o
arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
arch/powerpc/platforms/built-in.o kernel/built-in.o mm/built-in.o
fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o
sound/built-in.o firmware/built-in.o net/built-in.o --end-group
powerpc-linux-gnu-ld: BFD 2.16.1 internal error, aborting at
/u1/rmachet/project/crosstool/crosstool-0.43/build/powerpc-linux-gnu/gcc-4.1.1-glibc-2.3.6/binutils-2.16.1/bfd/elflink.c
line 6419 in elf_link_output_extsym
powerpc-linux-gnu-ld: Please report this bug.
I isolated the problem to line 202 in arch/powerpc/kernel/vmlinux.lds.S: If I
remove that
line then the kernel builds and run fine on my board (a PowerPC 32bits c2k).
For reference the line is:
.rela.dyn : AT(ADDR(.rela.dyn) - LOAD_OFFSET)
{
202-> __rela_dyn_start = .;
*(.rela*)
}
Any idea of what cause this crash? I strongly suspect this is a binutils 2.16.1
bug
that was fixed later but since it may affect other people I just wanted to let
you and
the list know.
Remi
On Sat, 2008-08-30 at 11:43 +1000, Paul Mackerras wrote:
> This implements CONFIG_RELOCATABLE for 64-bit by making the kernel as
> a position-independent executable (PIE) when it is set. This involves
> processing the dynamic relocations in the image in the early stages of
> booting, even if the kernel is being run at the address it is linked at,
> since the linker does not necessarily fill in words in the image for
> which there are dynamic relocations. (In fact the linker does fill in
> such words for 64-bit executables, though not for 32-bit executables,
> so in principle we could avoid calling relocate() entirely when we're
> running a 64-bit kernel at the linked address.)
>
> The dynamic relocations are processed by a new function relocate(addr),
> where the addr parameter is the virtual address where the image will be
> run. In fact we call it twice; once before calling prom_init, and again
> when starting the main kernel. This means that reloc_offset() returns
> 0 in prom_init (since it has been relocated to the address it is running
> at), which necessitated a few adjustments.
>
> This also changes __va and __pa to use an equivalent definition that is
> simpler. With the relocatable kernel, PAGE_OFFSET and MEMORY_START are
> constants (for 64-bit) whereas PHYSICAL_START is a variable (and
> KERNELBASE ideally should be too, but isn't yet).
>
> With this, relocatable kernels still copy themselves down to physical
> address 0 and run there.
>
> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
> ---
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 587da5e..17c988b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -806,6 +806,19 @@ config PIN_TLB
> endmenu
>
> if PPC64
> +config RELOCATABLE
> + bool "Build a relocatable kernel"
> + help
> + This builds a kernel image that is capable of running anywhere
> + in the RMA (real memory area) at any 16k-aligned base address.
> + The kernel is linked as a position-independent executable (PIE)
> + and contains dynamic relocations which are processed early
> + in the bootup process.
> +
> + One use is for the kexec on panic case where the recovery kernel
> + must live at a different physical address than the primary
> + kernel.
> +
> config PAGE_OFFSET
> hex
> default "0xc000"
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 9155c93..14c86fe 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -63,7 +63,9 @@ override CC += -m$(CONFIG_WORD_SIZE)
> override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
> endif
>
> -LDFLAGS_vmlinux := -Bstatic
> +LDFLAGS_vmlinux-yy := -Bstatic
> +LDFLAGS_vmlinux-$(CONFIG_PPC64)$(CONFIG_RELOCATABLE) := -pie
> +LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-yy)
>
> CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none
> -mcall-aixdesc
> CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 14174aa..9109e1f 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -310,8 +310,11 @@ $(obj)/dtbImage.%: vmlinux $(wrapperbits) $(obj)/%.dtb
> $(obj)/vmlinux.strip: vmlinux
> $(STRIP) -s -R .comment $< -o $@
>
> +# The iseries hypervisor won't take an ET_DYN executable, so this
> +# changes the type (byte 1
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hello Benjamin, Benjamin Herrenschmidt wrote: [snip] diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h index fce2df9..4f802df 100644 --- a/arch/powerpc/kernel/head_booke.h +++ b/arch/powerpc/kernel/head_booke.h @@ -20,7 +20,9 @@ beq 1f; \ mfspr r1,SPRN_SPRG3; /* if from user, start at top of */\ lwz r1,THREAD_INFO-THREAD(r1); /* this thread's kernel stack */\ - addir1,r1,THREAD_SIZE; \ + lis r11,[EMAIL PROTECTED]; \ + ori r11,r11,[EMAIL PROTECTED]; \ + add r1,r1,r11; \ It would be nice if we could avoid the extra instruction here when the page sizes isn't big enough to require it. As a matter of fact, I don't see why THREAD_SIZE should ever need that, there is no reason to change the kernel stack size. Well, this was introduced because of that: kernel/fork.c [179]: max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE); With THREAD_SIZE=8K we will get mempages divided by zero if PAGE_SIZE is bigger than 64K. (Well, another reason not to use >64K pages). Not sure this is the right way to fix it. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hello David, David Gibson wrote: I don't see any reason to have a separate set of config options for 32 and 64-bit. Just make the once choice, but only have the individual pagesize options enabled on machines that support them. Well. I can see some. First, on PPC64 kernel emulates 64K pages on hardware that can't do it and we are not going to do such an emulation on PPC32 now. Then CONFIG_PPC_64K_PAGES selects PPC_HAS_HASH_64K and our code has nothing to do with it. And last but not least, we don't use PPC64 kernels for now so we just tried not to break something we can't test. But if everybody thinks that having a single option is a good idea I'll do it that way. I don't think you should need a real_pte_t type for the 32-bit implementation. It's just there because of how we implement 64k granularity page allocation on hardware that only does 4k translations. You are right. Thanks. diff --git a/arch/powerpc/include/asm/page_32.h b/arch/powerpc/include/asm/page_32.h index ebfae53..d176270 100644 --- a/arch/powerpc/include/asm/page_32.h +++ b/arch/powerpc/include/asm/page_32.h @@ -20,7 +20,11 @@ */ #ifdef CONFIG_PTE_64BIT typedef unsigned long long pte_basic_t; +#ifdef CONFIG_PPC32_256K_PAGES +#define PTE_SHIFT (PAGE_SHIFT - 7) This doesn't look right. You should be eliding one of the levels of page table if you don't need it, rather than leaving the bottom level PTE page largely empty. Hm... We have only two levels really so if we elide one there will be only one left. Don't sure if kernel can work with this... +#if (PAGE_SHIFT == 12) +/* + * PAGE_SIZE 4K + * PAGE_SHIFT 12 + * PTE_SHIFT 9 + * PMD_SHIFT 21 + */ +#define PPC44x_TLBE_SIZE PPC44x_TLB_4K +#define PPC44x_PGD_OFF_SH 13 /*(32 - PMD_SHIFT + 2)*/ +#define PPC44x_PGD_OFF_M1 19 /*(PMD_SHIFT - 2)*/ +#define PPC44x_PTE_ADD_SH 23 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/ +#define PPC44x_PTE_ADD_M1 20 /*32 - 3 - PTE_SHIFT*/ +#define PPC44x_RPN_M2 19 /*31 - PAGE_SHIFT*/ Uh.. you have the formulae for these things right there in the comments, so why aren't you using those and avoiding this nasty multiway ifdef... We need to get PMD_SHIFT and friends out of #ifndef __ASSEMBLY__ for that. And some of them are under include/asm-generic so patch becomes not powerpc-specific... diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h index 9665a26..4e7cd1f 100644 --- a/arch/powerpc/include/asm/thread_info.h +++ b/arch/powerpc/include/asm/thread_info.h @@ -15,8 +15,12 @@ #ifdef CONFIG_PPC64 #define THREAD_SHIFT 14 #else +#if defined(CONFIG_PPC32_256K_PAGES) +#define THREAD_SHIFT 15 Hrm.. more peculiar special cases for 256K pages. I think it might be clearer if you split the patch into one which supports page sizes up to 64k, then another that does the extra hacks for 256k pages. Agreed. diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h index fce2df9..4f802df 100644 --- a/arch/powerpc/kernel/head_booke.h +++ b/arch/powerpc/kernel/head_booke.h @@ -20,7 +20,9 @@ beq 1f; \ mfspr r1,SPRN_SPRG3; /* if from user, start at top of */\ lwz r1,THREAD_INFO-THREAD(r1); /* this thread's kernel stack */\ - addir1,r1,THREAD_SIZE; \ + lis r11,[EMAIL PROTECTED]; \ + ori r11,r11,[EMAIL PROTECTED]; \ + add r1,r1,r11; \ It would be nice if we could avoid the extra instruction here when the page sizes isn't big enough to require it. Ok. This is going to go to 256K-dirty-hacks.patch anyway. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down
From: Johannes Berg <[EMAIL PROTECTED]> Subject: powerpc: fix shutdown I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out to be due to the system_state being SYSTEM_POWER_OFF, which this code doesn't take as a valid state for shutting off CPUs in. This has never made sense to me, but when I added hotplug code to implement hibernate I only "made it work" and did not question the need to check the system_state. Thomas Gleixner helped me dig, but the only thing we found is that it was added with the original commit that added CPU hotplug support. Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> Cc: Thomas Gleixner <[EMAIL PROTECTED]> Cc: Joel Schopp <[EMAIL PROTECTED]> Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Tested this patch on a Power6 partition with cpu hotplug online/offline and some shutdown and reboot cycles. Didn't see any ill effects. Acked-by: Joel Schopp <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix conflict with Elo DMA driver in MPC8610 device tree
The Freescale Elo DMA driver binds to all DMA channels in the device tree that
are compatible with "fsl,eloplus-dma-channel". This conflicts with the sound
drivers for the MPC8610. To avoid the conflict, change the compatible property
for the DMA channels needed by the sound drivers to "fsl,ssi-dma-channel".
This works because the sound drivers don't actually check the compatible
property when it grabs DMA channels.
Also update dma.txt and ssi.txt with this information.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/fsl/dma.txt | 13 +++--
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 12 ++--
arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++--
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt
b/Documentation/powerpc/dts-bindings/fsl/dma.txt
index 86826df..cc45311 100644
--- a/Documentation/powerpc/dts-bindings/fsl/dma.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt
@@ -20,7 +20,7 @@ Required properties:
- compatible: compatible list, contains 2 entries, first is
"fsl,CHIP-dma-channel", where CHIP is the processor
(mpc8349, mpc8350, etc.) and the second is
-"fsl,elo-dma-channel"
+"fsl,elo-dma-channel". However, see note below.
- reg :
- cell-index: dma channel index starts at 0.
@@ -82,7 +82,7 @@ Required properties:
- compatible: compatible list, contains 2 entries, first is
"fsl,CHIP-dma-channel", where CHIP is the processor
(mpc8540, mpc8560, etc.) and the second is
-"fsl,eloplus-dma-channel"
+"fsl,eloplus-dma-channel". However, see note below.
- cell-index: dma channel index starts at 0.
- reg :
- interrupts:
@@ -125,3 +125,12 @@ Example:
interrupts = <17 2>;
};
};
+
+Note on DMA channel compatible properties: The compatible property must say
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
+driver (fsldma). Any DMA channel used by fsldma cannot be used by another
+DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA
+channel that should be used for another driver should not use
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel". For the SSI drivers, for
+example, the compatible property should be "fsl,ssi-dma-channel". See ssi.txt
+for more information.
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index 5d98413..f11ec34 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -24,10 +24,10 @@ Required properties:
"rj-master" - r.j., SSI is clock master
"ac97-slave" - AC97 mode, SSI is clock slave
"ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: phandle to a DMA node for the DMA channel to use for
+- fsl,playback-dma: phandle to a node for the DMA channel to use for
playback of audio. This is typically dictated by SOC
design. See the notes below.
-- fsl,capture-dma: phandle to a DMA node for the DMA channel to use for
+- fsl,capture-dma: phandle to a node for the DMA channel to use for
capture (recording) of audio. This is typically dictated
by SOC design. See the notes below.
@@ -51,3 +51,11 @@ playback and DMA channel 1 for capture. SSI2 must use DMA
channel 2 for
playback and DMA channel 3 for capture. The developer can choose which
DMA controller to use, but the channels themselves are hard-wired. The
purpose of these two properties is to represent this hardware design.
+
+The device tree nodes for the DMA channels that are referenced by
+"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
+"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g.
+"fsl,mpc8610-dma-channel") can remain. If these nodes are left as
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
+drivers (fsldma) will attempt to use them, and it will conflict with the
+sound drivers.
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 855f70c..f724d72 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -237,7 +237,7 @@
dma00: [EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,eloplus-dma-channel";
+ "fsl,ssi-dma-channel";
cell-index = <
[PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
The Kconfig files for PowerPC CHRP and PMAC support had "default=y" for some Kconfig options, and this caused support for CHRP and PMAC platforms to be enabled incorrectly for several platforms. Fix the Kconfigs and the affected defconfigs. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- This patch is for 2.6.28. Ben, please review and make sure I'm not being to conservative or too aggressive. I don't know enough about CHRP and PMAC to be sure I'm doing this right. arch/powerpc/configs/83xx/asp8347_defconfig |2 -- arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 -- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |2 -- arch/powerpc/configs/83xx/mpc832x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |2 -- arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 -- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |2 -- arch/powerpc/configs/83xx/mpc834x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc836x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |2 -- arch/powerpc/configs/83xx/mpc837x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |2 -- arch/powerpc/configs/83xx/sbc834x_defconfig |2 -- arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |2 -- arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig |2 -- arch/powerpc/configs/86xx/sbc8641d_defconfig |2 -- arch/powerpc/configs/ep8248e_defconfig|2 -- arch/powerpc/configs/mpc8272_ads_defconfig|2 -- arch/powerpc/configs/mpc83xx_defconfig|2 -- arch/powerpc/configs/pq2fads_defconfig|2 -- arch/powerpc/platforms/chrp/Kconfig |1 - arch/powerpc/platforms/powermac/Kconfig |4 22 files changed, 0 insertions(+), 45 deletions(-) diff --git a/arch/powerpc/configs/83xx/asp8347_defconfig b/arch/powerpc/configs/83xx/asp8347_defconfig index 5e6780a..6638f5a 100644 --- a/arch/powerpc/configs/83xx/asp8347_defconfig +++ b/arch/powerpc/configs/83xx/asp8347_defconfig @@ -164,11 +164,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig index 2028337..df125f3 100644 --- a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig index dd80eb0..6e0e08c 100644 --- a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig index bdf50c8..d6e204a 100644 --- a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig index 4eef8c9..1f3d343 100644 --- a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig index 8d65139..4686c21 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig +++ b/arch/powerpc/configs/83xx/mpc834x_
Re: [RFC/PATCH] powerpc: Cleanup 32/64 bit syscall int sign ext.
On Thu, Sep 25, 2008 at 05:01:36PM +1000, Benjamin Herrenschmidt wrote: >I noticed that our ABI says callers are responsible for sign extending. >That means that all int, long or similarly signed arguments to syscalls >must be explicitly sign-extended. > >We already have wrappers to do that for -some- syscalls in arch code. >Those are in C and pretty ugly, copy/pasting a bunch of identically >useless comments all over, and are missing a lot of potential >candidates. > >sparc64 uses a nicer macro system to generate trampolines in asm. It >also has a more complete list. But it's also missing some :-) > >Now, there is a good point to be made that we don't absolutely need to >always sign extend. In many cases, the called function will just do a >cmplw for example, or an and to test bits in flags, and so it looks like >sign extension is not necessary. One could say that sign extending file >descriptors for example isn't terribly useful > >But that sounds like a fragile approach to me. We don't know for sure >what new tricks the compiler will learn for example. In fact, when >taking the sparc64 list, I noticed that in some cases it -did- already >sign extend file descriptors and flags .. and in some cases not. > >So I've spent a few hours combing through all of syscalls.h (and one >more that seems to be missing from this file, ie, pipe2, there may be >others) for anything using int, long or pid_t (which is signed, at least >on our 32-bit platforms). You might want to look at functions that take clockid_t as well. It's also a signed int. We recently ran into a case of this for clock_getres on ppc64 using a 32-bit glibc. Albiet, on a quite old kernel but looking at it briefly it seems to still be an issue, so probably worth fixing. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Thu, 25 Sep 2008 18:40:28 -0500 "Milton Miller" <[EMAIL PROTECTED]> wrote: > (I trimmed the cc list for the implementation discussion). Yep, good thing. > > > > Whoops, my bad, in the non threaded case, there's no > > mask at all, only an unmask+eoi at the end, maybe that's > > an oversight! > > No, not an oversight. The point is, don't mask/unmask > between ack/eoi while handling the interrupt. For many > irq controllers, the eoi must be done from the same cpu, > hence the mask and eoi before actually handling the > interrupt in the general case. Its a feature of xics > that we don't have to play that game, but can do the > cpu and device eoi separately. Ok, will try to play with this a bit more. > > > That may be, but I'm only looking at the code (read no > > specifications at hand) and it looks like a black box to > > me. > > "PowerPC External Interrupt Architecture" is defined in > appendix A of "Power.org™ Standard for > Power Architecture™ Platform Requirements > (Workstation, Server)", available to Power.org members. > "The developer-level membership in Power.org is free." > (see www.power.org). I already have that one and started to dig into the interrupt stuff, but as with all normative stuff it's boring to the extreme and not always without flaws. Looks like I know what I'll be reading this WE. > > That said, it likely won't mention the eHEA in enough > detail to note that the interrupt gets cleared on > unmask. > > On the other hand, I have actually seen the source > to implementations of the xics logic, so I have a > very good understanding of it (and know of a few > implementation "features", shall we say). Good to know. > > > > > The path lengh for mask and unmask is always VERY slow > > > and single threaded global lock and single context in > > > xics. It is designed and tuned to run at driver > > > startup and shutdown (and adapter reset and reinitalize > > > during pci error processing), not during normal irq > > > processing. > > > > Now, that is quite interesting then. Those mask() and > > unmask() should then be called shutdown() and startup() > > and not at each interrupt or am I misunderstanding you. > > Basically, yes. but linux likes to let drivers mask at > other times, and that is the facility we have. Darn, do those drivers really need that heavywheight masking at the source or something simpler could be accomplished by fiddling with the processor priority in mask and unmask? > > > > The XICS hardware implicitly masks the specific source > > > as part of interrupt ack (get_irq), and implicitly > > > undoes this mask at eoi. In addition, it helps to > > > manage the cpu priority by supplying the previous > > priority as part of the get_irq process and providing for > > > the priority to be restored (lowered only) as part of > > > the eoi. The hardware does support setting the cpu > > priority independently. > > > > This confirms, then, that the mask and unmask methods > > should be empty for the xics. > > > > > > > > We should only be using this implicit masking for xics, > > > and not the explicit masking for any normal interrupt > > > processing. > > > > OK > > > > > I don't know if > > > this means making the mask/unmask setting a bit in > > > software, > > > > Used by whom? > > The thought here was if we can't change the caller, then > maybe we could try to figure out what the caller was > trying to accomplish and defer what was requested based > on context. Obviously, we are better off changing the > caller. That will not be so easy as we'll change behaviour for every user of the genirq layer. > > > > > > and the > > > enable/disable to actually call what we do now on > > > mask/unmask, or if it means we need a new flow type on > > real time. > > > > Maybe a new flow type is not necessary considering what > > you said. > > Maybe not, but I think it would be preferred ... we do have > the source to both sides. That's straightforward to do in the non threaded case, however, in the threaded case the xics code would have to also manage the hardirq thread as we would not be able to reuse the generic one (because of the unmask it does at the very end). > > > I think the flows we want on xics are: > > > > > > (non-threaded) > > > getirq (implicit source specific mask until eoi) > > > handle interrupt > > > eoi (implicit cpu priority restore) > > > > Yep > > > > > > > > (threaded) > > > getirq (implicit source specific mask until eoi) > > > explicit cpu priority restore > > ^ > > How do you go about doing that? Still not clear to me. > > xics_set_cpu_priority(0xff) OK > > of course, there needs to be some kind of > struct irq_chip method to call it. Yep, excepted that it's currently not provided by irq_chip. > > > > handle interrupt > > > eoi (implicit cpu priority restore to same as > > > explicit level) > > > W
Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
I certainly have no objection in principle. I doubt that any x86 userland apps expect certain si_code values for SIGTRAP now, since the existing values are not of any real use. (Signal handlers get the thread.trap_no and thread.error_code values from hardware to guess from, and debuggers via ptrace get the hardware %db6 value to guess from.) I do have a few comments. If you're doing it, I think you should do the do_int3 case too, so every machine-generated SIGTRAP has a meaningful si_code value. The only use of send_sigtrap is for do_debug (and for faking that do_debug happened in the syscall_trace_leave case). You should consolidate all the uses in both 32 and 64 to use send_sigtrap uniformly, change its signature as needed. I'm inclined to consolidate the si_code logic there, and just pass it the hardware bits or let it get them from the thread_struct (trap_nr, error_code, debugreg6). About that si_code logic based on %db6. There are some funny "sticky" properties to how that register gets set in hardware. Even reading the hardware manuals doesn't always make it plain what to expect. I wouldn't want to testify that the patch's logic is correct in distinguishing which event really just happened. (I'm not sure, but I think it may also be possible to have a single do_debug trap for both a single-step trap and a hardware breakpoint trap generated by the same instruction.) I know that Alan Stern figured out a lot of the magic empirically a while back. That deserves a careful double-checking if we are now trying to make si_code tell a clear and reliable story. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: take in count O_NONBLOCK flag for rtas log
At Thu, 25 Sep 2008 22:13:05 +0100, David Howells wrote:
> > + if (!logging_enabled) {
> > + spin_unlock_irqrestore(&rtasd_log_lock, s);
> > + error = -ENODATA;
> > + goto out;
> > + } else
> > + nvram_clear_error_log();
>
> The 'else' here is unnecessary. It's preceded inside the curlies by a goto.
Right...
Signed-off-by: Vitaly Mayatskikh <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/pseries/rtasd.c
b/arch/powerpc/platforms/pseries/rtasd.c
index c9ffd8c..4f76e3b 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -295,19 +295,29 @@ static ssize_t rtas_log_read(struct file * file, char
__user * buf,
if (!tmp)
return -ENOMEM;
-
spin_lock_irqsave(&rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 && logging_enabled)
- nvram_clear_error_log();
- spin_unlock_irqrestore(&rtasd_log_lock, s);
+ while (rtas_log_size == 0) {
+ if (file->f_flags & O_NONBLOCK) {
+ spin_unlock_irqrestore(&rtasd_log_lock, s);
+ error = -EAGAIN;
+ goto out;
+ }
+ if (!logging_enabled) {
+ spin_unlock_irqrestore(&rtasd_log_lock, s);
+ error = -ENODATA;
+ goto out;
+ }
+ nvram_clear_error_log();
- error = wait_event_interruptible(rtas_log_wait, rtas_log_size);
- if (error)
- goto out;
+ spin_unlock_irqrestore(&rtasd_log_lock, s);
+ error = wait_event_interruptible(rtas_log_wait, rtas_log_size);
+ if (error)
+ goto out;
+ spin_lock_irqsave(&rtasd_log_lock, s);
+ }
- spin_lock_irqsave(&rtasd_log_lock, s);
offset = rtas_error_log_buffer_max * (rtas_log_start & LOG_NUMBER_MASK);
memcpy(tmp, &rtas_log_buf[offset], count);
--
wbr, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc52xx_uart and rs485
Hello, On Wed, Sep 24, 2008 at 08:20:16AM -0600, Grant Likely wrote: > > Hi Wolfgang and others, > > below is patch for mpc52xx_usrt.c which add software rs485 support to > > this driver. > > It has worked for me and if you think it is good enough it might be > > useful for someone else. > > Thanks for the patch. I've made a number of comments below and it > appears that your mail client has damaged the patch. Can you please > respin after addressing the comments. When you repost, please include a > technical description of what you have done and why. And please add linux-serial as cc then. I recently read some criticism about software RS485 (http://article.gmane.org/gmane.linux.serial/2573). I don't know if these apply to this patch, but it would be nice to have it sorted out IMHO. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
