RE: [PATCH][v2] driver/FSL SATA:Fix wrong Device Error Register usage
Case when ffs return will never arise.This scenario is
already been discussed
on linuxppc-dev@lists.ozlabs.org. Please see below explanation:
sata_fsl_error_intr() is called during device error.The
mentioned scenario
will never comes. It can be observed via code:-
if (cereg) { -- cereg is set on command error.
Means there is at least 1 device present.
This all relies on the hardware working properly, and
nothing else accidentally clearing the device 'error'
bit mask.
Being slightly defensive when the out of range value
causes an array subscript error seems sensible.
It isn't as though the code size or execution time
matters here.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mpc8315erdb openvpn segmentation fault
On Mon, 7 Mar 2011 20:28:32 -0800 Vasanth Ragavendran ragavendra...@yahoo.co.in wrote: Thanks a ton Scott. Actually i was working with the same version of the kernel on both the boards. it was 2.6.29.6. neither i changed the u-boot. it was the same in both. however i recompiled the kernel and i installed on both the boards and it worked fine! :) thanks again for responding. however i've another question. my filesystem in the board is non-persistent i.e. the files i create are erased after i reboot i know the files are getting stored in RAM and i wish to make them persistent. what do i need to do for this? should i create a separate partition in the flash and load certain files into that partition? or how should i make it persistent so that files stay beyond reboot! thanks again! eagerly awaiting your response. Yes, you should create a filesystem (e.g. jffs2) on a flash partition. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
On Thu, Mar 3, 2011 at 03:30, Ingo Molnar mi...@elte.hu wrote:
This is how specific GAS functionality is tested in arch/powerpc:
@if ! /bin/echo dssall | $(AS) -many -o $(TOUT) /dev/null 21 ; then
\
echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build
' ; \
echo 'correctly with old versions of binutils.' ; \
echo '*** Please upgrade your binutils to 2.12.1 or newer' ; \
false ; \
fi
This would also be a 'constructive' (and safest) way of blacklisting
binutils: we'd
really only exclude binutils that is truly buggy.
Hrm... well... actually...
It's funny that you brought up this particular case. While I agree
that it's good in general, it's causing problems for me building a
kernel using a recent e500 gcc/binutils (triplet
powerpc-linux-gnuspe).
Specifically the e500 doesn't have a normal PowerPC FPU, it has a
custom FPU built using extended integer registers instead, and it
happens to borrow the AltiVec opcode range to do it.
When trying to port Debian to the platform we were getting SIGILL's
all over the place until binutils got updated to reject all of the
unsupported opcodes on this particular platform. Now of course we get
build errors, but that's a lot easier to debug and fix. :-D
Basically, binutils no longer supports -many (because too many
opcodes conflict), and the test itself would fail anyways (because
dssall is not valid on any PowerPC).
So while I think that it is entirely reasonable to add a similar test
for buggy x86 binutils, I'm actually about to send a patch to remove
that particular check from the powerpc Makefile. Since the required
binutils 2.12.1 was released in May 2002 (almost 9 years ago) it's
probably not even worth testing for anymore.
Cheers,
Kyle Moffett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
On Tue, 2011-03-08 at 14:57 -0500, Kyle Moffett wrote: Specifically the e500 doesn't have a normal PowerPC FPU, it has a custom FPU built using extended integer registers instead, and it happens to borrow the AltiVec opcode range to do it. When trying to port Debian to the platform we were getting SIGILL's all over the place until binutils got updated to reject all of the unsupported opcodes on this particular platform. Now of course we get build errors, but that's a lot easier to debug and fix. :-D Basically, binutils no longer supports -many (because too many opcodes conflict), and the test itself would fail anyways (because dssall is not valid on any PowerPC). Note that this freescale SPE fiasco is just that ... a fiasco :-) I don't think there's that many cases of opcode overlap outside of it. Now regarding the kernel, the best is probably for nasty cases like that to use hand coded opcodes (see ppc-opcodes.h) and stick to a more generic setting for binutils, since it should be possible to build kernels that support multiple types of BookE CPUs with different floating point units. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
On Tue, Mar 8, 2011 at 16:28, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2011-03-08 at 14:57 -0500, Kyle Moffett wrote: Specifically the e500 doesn't have a normal PowerPC FPU, it has a custom FPU built using extended integer registers instead, and it happens to borrow the AltiVec opcode range to do it. When trying to port Debian to the platform we were getting SIGILL's all over the place until binutils got updated to reject all of the unsupported opcodes on this particular platform. Now of course we get build errors, but that's a lot easier to debug and fix. :-D Basically, binutils no longer supports -many (because too many opcodes conflict), and the test itself would fail anyways (because dssall is not valid on any PowerPC). Note that this freescale SPE fiasco is just that ... a fiasco :-) I don't think there's that many cases of opcode overlap outside of it. I absolutely agree on the fiasco part, although I'm pretty sure that there's a large number of incompatible ARM variants (even 16-bit vs. 32-bit opcodes). Unfortunately there's a lot of shipped hardware to be supported and maintained... Now regarding the kernel, the best is probably for nasty cases like that to use hand coded opcodes (see ppc-opcodes.h) and stick to a more generic setting for binutils, since it should be possible to build kernels that support multiple types of BookE CPUs with different floating point units. The problem is not with the kernel compile itself, but with the 2.12 dssall binutils test. Basically, recent binutils treats e500 as effectively a separate architecture that happens to share *most* of the opcodes with regular PowerPC. Any opcode which is not understood by the e500 chip is either convert to an equivalent opcode which is understood (IE: lwsync = sync), or failed with an error. This means that the kernel compile aborts early telling me to upgrade to a newer version of binutils. This was *critical* for getting an actual Debian distribution bootstrapped on the e500 cores, because so much software assumes PowerPC == altivec (ffmpeg), hardcodes 'asm(lwsync)' for memory barriers (80+ packages in Debian), or includes hand-coded floating-point ASM instructions (libffi). Noisy build errors are better than silent runtime failures any day of the week. At the very least that test needs to be turned off if CONFIG_ALTIVEC=n, because the kernel builds and runs fine otherwise. Cheers, Kyle Moffett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
On Wed, 9 Mar 2011 08:28:36 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2011-03-08 at 14:57 -0500, Kyle Moffett wrote: Specifically the e500 doesn't have a normal PowerPC FPU, it has a custom FPU built using extended integer registers instead, and it happens to borrow the AltiVec opcode range to do it. When trying to port Debian to the platform we were getting SIGILL's all over the place until binutils got updated to reject all of the unsupported opcodes on this particular platform. Now of course we get build errors, but that's a lot easier to debug and fix. :-D Basically, binutils no longer supports -many (because too many opcodes conflict), and the test itself would fail anyways (because dssall is not valid on any PowerPC). Note that this freescale SPE fiasco is just that ... a fiasco :-) I don't think there's that many cases of opcode overlap outside of it. Now regarding the kernel, the best is probably for nasty cases like that to use hand coded opcodes (see ppc-opcodes.h) and stick to a more generic setting for binutils, since it should be possible to build kernels that support multiple types of BookE CPUs with different floating point units. Combined kernels between e500v1/2 and e500mc are currently not supported for other reasons (current kconfig doesn't prohibit it, but it doesn't work), such as a cache line size difference (a hardcoded L1_CACHE_BYTES is used in various places for loops), an inability to enable SPE when e500mc is enabled, etc. Kumar recently internally said we're not going to bother making it work. I'm inclined to agree, given you can't even run the same userspace (unless you don't use hard floating point at all). It's one thing to not want to require a separate kernel for each board, but there's a point of diminishing returns. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
On Tue, 2011-03-08 at 16:59 -0500, Kyle Moffett wrote: The problem is not with the kernel compile itself, but with the 2.12 dssall binutils test. Basically, recent binutils treats e500 as effectively a separate architecture that happens to share *most* of the opcodes with regular PowerPC. This is bogus. Newer e500 don't have that SPE crap afaik and BookI and II of the architecture have been converged. In fact, Scott, don't newer FSL chips also support real lwsync ? Any opcode which is not understood by the e500 chip is either convert to an equivalent opcode which is understood (IE: lwsync = sync), or failed with an error. This means that the kernel compile aborts early telling me to upgrade to a newer version of binutils. This is more bogosity in binutils. lwsync is designed to fallback as sync if not supported in -HW-, binutils shouldn't silently swallow it. Or is it that FSL failed on the original e500 and make lwsync actually trap ? This was *critical* for getting an actual Debian distribution bootstrapped on the e500 cores, because so much software assumes PowerPC == altivec (ffmpeg), hardcodes 'asm(lwsync)' for memory barriers (80+ packages in Debian), or includes hand-coded floating-point ASM instructions (libffi). Noisy build errors are better than silent runtime failures any day of the week. At the very least that test needs to be turned off if CONFIG_ALTIVEC=n, because the kernel builds and runs fine otherwise. I think the right thing is to keep that as e500-legacy or something, because afaik, newer e500's don't have most of these issues and could be treated as normal powerpc again. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
On Tue, Mar 8, 2011 at 18:13, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2011-03-08 at 16:59 -0500, Kyle Moffett wrote: The problem is not with the kernel compile itself, but with the 2.12 dssall binutils test. Basically, recent binutils treats e500 as effectively a separate architecture that happens to share *most* of the opcodes with regular PowerPC. This is bogus. Newer e500 don't have that SPE crap afaik and BookI and II of the architecture have been converged. In fact, Scott, don't newer FSL chips also support real lwsync ? When I'm talking about e500 I'm specifically referring to the SPE stuff. The e500mc cores are a whole different beast with a regular FPU, but those have their own Kconfig option: PPC_E500MC. Actually, looking at it again, the PPC_E500MC depends on E500, it should select PPC_FSL_BOOK3E instead. There are probably bugs lurking here. There really is fundamentally no good way to build a single system image that supports both E500 (spe-based) and E500MC (classic FPU). You can sort-of run classic FPU emulation on the E500, but the performance is terrifyingly bad. The naming confusion really is really bad too, IMO. Any opcode which is not understood by the e500 chip is either convert to an equivalent opcode which is understood (IE: lwsync = sync), or failed with an error. This means that the kernel compile aborts early telling me to upgrade to a newer version of binutils. This is more bogosity in binutils. lwsync is designed to fallback as sync if not supported in -HW-, binutils shouldn't silently swallow it. Or is it that FSL failed on the original e500 and make lwsync actually trap ? Yeah... for some reason FreeScale made the lwsync operation trap on e500 (again, only talking about e500 with SPE, not e500mc). Unfortunately it's used frequently enough that there's a very noticeable performance gain (~5% for some programs) by substituting it in binutils, so that's what happens. This was *critical* for getting an actual Debian distribution bootstrapped on the e500 cores, because so much software assumes PowerPC == altivec (ffmpeg), hardcodes 'asm(lwsync)' for memory barriers (80+ packages in Debian), or includes hand-coded floating-point ASM instructions (libffi). Noisy build errors are better than silent runtime failures any day of the week. At the very least that test needs to be turned off if CONFIG_ALTIVEC=n, because the kernel builds and runs fine otherwise. I think the right thing is to keep that as e500-legacy or something, because afaik, newer e500's don't have most of these issues and could be treated as normal powerpc again. There is a separate -me500mc option for GAS that does the right thing, but the kernel currently does not seem to use it. arch/powerpc/Makefile has this: cpu-as-$(CONFIG_4xx) += -Wa,-m405 cpu-as-$(CONFIG_6xx) += -Wa,-maltivec cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec cpu-as-$(CONFIG_E500) += -Wa,-me500 cpu-as-$(CONFIG_E200) += -Wa,-me200 As it is, I strongly suspect that the kernel is broken for CONFIG_E500MC with current development releases of binutils. The real solution is that e500 needs to be treated as an almost entirely different architecture from all other powerpc (including e500mc). Userspace is only ABI-compatible if you use -msoft-float on both sides. I've been dealing with it for a while now, it really is a fiasco all around... After a month of wrestling with the official Debian powerpc port we gave up and created a new port powerpcspe specifically for the e500 SPE-based chips. Then we tripped over 3 relatively major GCC bugs which had been lurking since e500 support was initially added. See http://wiki.debian.org/PowerPCSPEPort for a very out-of-date status on that whole thing. Cheers, Kyle Moffett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] RTC driver(Linux) for PT7C4338 chip.
On Wed, 2 Mar 2011 09:42:30 +0530
Priyanka Jain priyanka.j...@freescale.com wrote:
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
PT7C4338 RTC driver is verified on Freescale P1010RDB.
Please pick this patch for 2.6.39
drivers/rtc/Kconfig|9 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-pt7c4338.c | 215
3 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-pt7c4338.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 10ba12c..6ff0901 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -324,6 +324,15 @@ config RTC_DRV_RX8025
This driver can also be built as a module. If so, the module
will be called rtc-rx8025.
+config RTC_DRV_PT7C4338
+ tristate Pericom Technology Inc. PT7C4338 RTC
+ help
+ If you say yes here you get support for the Pericom Technology
+ Inc. PT7C4338 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-pt7c4338.
+
This means that the driver is available on all architectures, not just
powerpc.
This is a good thing and a bad thing. Bad because it makes non-ppc
people possibly build and install a driver which they will never use
(correct?). And good because it means that more people do compilation
test coverage.
Speaking of which:
From: Andrew Morton a...@linux-foundation.org
include slab.h, remove unused local
drivers/rtc/rtc-pt7c4338.c: In function 'pt7c4338_probe':
drivers/rtc/rtc-pt7c4338.c:159: error: implicit declaration of function
'kzalloc'
drivers/rtc/rtc-pt7c4338.c:159: warning: assignment makes pointer from integer
without a cast
drivers/rtc/rtc-pt7c4338.c:176: error: implicit declaration of function 'kfree'
drivers/rtc/rtc-pt7c4338.c:156: warning: unused variable 'adapter'
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Kumar Gala ga...@gate.crashing.org
Cc: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/rtc/rtc-pt7c4338.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/rtc/Kconfig~rtc-driver-for-pt7c4338-chip-fix
drivers/rtc/Kconfig
diff -puN drivers/rtc/Makefile~rtc-driver-for-pt7c4338-chip-fix
drivers/rtc/Makefile
diff -puN drivers/rtc/rtc-pt7c4338.c~rtc-driver-for-pt7c4338-chip-fix
drivers/rtc/rtc-pt7c4338.c
--- a/drivers/rtc/rtc-pt7c4338.c~rtc-driver-for-pt7c4338-chip-fix
+++ a/drivers/rtc/rtc-pt7c4338.c
@@ -35,6 +35,7 @@
*/
#include linux/kernel.h
+#include linux/slab.h
#include linux/module.h
#include linux/i2c.h
#include linux/rtc.h
@@ -153,7 +154,6 @@ static int pt7c4338_probe(struct i2c_cli
const struct i2c_device_id *id)
{
struct pt7c4338 *pt7c4338;
- struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
int ret;
pt7c4338 = kzalloc(sizeof(struct pt7c4338), GFP_KERNEL);
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
Morally, the question of whether an address lies in a gate vma should be asked with respect to an mm, not a particular task. Practically, dropping the dependency on task_struct will help make current and future operations on mm's more flexible and convenient. In particular, it allows some code paths to avoid the need to hold task_lock. The only architecture this change impacts in any significant way is x86_64. The principle change on that architecture is to mirror TIF_IA32 via a new flag in mm_context_t. This is the first of a two part series that implements safe writes to /proc/pid/mem. I will be posting the second series to lkml shortly. These patches are based on v2.6.38-rc8. The general approach used here was suggested to me by Alexander Viro, but any mistakes present in these patches are entirely my own. -- steve Stephen Wilson (5): x86: add context tag to mark mm when running a task in 32-bit compatibility mode x86: mark associated mm when running a task in 32 bit compatibility mode mm: arch: make get_gate_vma take an mm_struct instead of a task_struct mm: arch: make in_gate_area take an mm_struct instead of a task_struct mm: arch: rename in_gate_area_no_task to in_gate_area_no_mm arch/powerpc/kernel/vdso.c |6 +++--- arch/s390/kernel/vdso.c|6 +++--- arch/sh/kernel/vsyscall/vsyscall.c |6 +++--- arch/x86/ia32/ia32_aout.c |1 + arch/x86/include/asm/mmu.h |6 ++ arch/x86/kernel/process_64.c |8 arch/x86/mm/init_64.c | 16 arch/x86/vdso/vdso32-setup.c | 15 --- fs/binfmt_elf.c|2 +- fs/proc/task_mmu.c |8 +--- include/linux/mm.h | 10 +- kernel/kallsyms.c |4 ++-- mm/memory.c|8 mm/mlock.c |4 ++-- mm/nommu.c |2 +- 15 files changed, 61 insertions(+), 42 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5] x86: mark associated mm when running a task in 32 bit compatibility mode
This patch simply follows the same practice as for setting the TIF_IA32 flag. In particular, an mm is marked as holding 32-bit tasks when a 32-bit binary is exec'ed. Both ELF and a.out formats are updated. Signed-off-by: Stephen Wilson wils...@start.ca --- arch/x86/ia32/ia32_aout.c|1 + arch/x86/kernel/process_64.c |8 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c index 2d93bdb..95cde43 100644 --- a/arch/x86/ia32/ia32_aout.c +++ b/arch/x86/ia32/ia32_aout.c @@ -298,6 +298,7 @@ static int load_aout_binary(struct linux_binprm *bprm, struct pt_regs *regs) /* OK, This is the point of no return */ set_personality(PER_LINUX); set_thread_flag(TIF_IA32); + current-mm-context.compat = 1; setup_new_exec(bprm); diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index bd387e8..35f1221 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -501,6 +501,10 @@ void set_personality_64bit(void) /* Make sure to be in 64bit mode */ clear_thread_flag(TIF_IA32); + /* Ensure the corresponding mm is not marked. */ + if (current-mm) + current-mm-context.compat = 0; + /* TBD: overwrites user setup. Should have two bits. But 64bit processes have always behaved this way, so it's not too bad. The main problem is just that @@ -516,6 +520,10 @@ void set_personality_ia32(void) set_thread_flag(TIF_IA32); current-personality |= force_personality32; + /* Mark the associated mm as containing 32-bit tasks. */ + if (current-mm) + current-mm-context.compat = 1; + /* Prepare the first return to user space */ current_thread_info()-status |= TS_COMPAT; } -- 1.7.3.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] x86: add context tag to mark mm when running a task in 32-bit compatibility mode
This tag is intended to mirror the thread info TIF_IA32 flag. Will be used to
identify mm's which support 32 bit tasks running in compatibility mode without
requiring a reference to the task itself.
Signed-off-by: Stephen Wilson wils...@start.ca
---
arch/x86/include/asm/mmu.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 80a1dee..8a2e5b4 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -13,6 +13,12 @@ typedef struct {
int size;
struct mutex lock;
void *vdso;
+
+#ifdef CONFIG_X86_64
+ /* True if mm supports a task running in 32 bit compatibility mode. */
+ unsigned short compat;
+#endif
+
} mm_context_t;
#ifdef CONFIG_SMP
--
1.7.3.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] mm: arch: make get_gate_vma take an mm_struct instead of a task_struct
Morally, the presence of a gate vma is more an attribute of a particular mm than
a particular task. Moreover, dropping the dependency on task_struct will help
make both existing and future operations on mm's more flexible and convenient.
Signed-off-by: Stephen Wilson wils...@start.ca
---
arch/powerpc/kernel/vdso.c |2 +-
arch/s390/kernel/vdso.c|2 +-
arch/sh/kernel/vsyscall/vsyscall.c |2 +-
arch/x86/mm/init_64.c |6 +++---
arch/x86/vdso/vdso32-setup.c | 11 ++-
fs/binfmt_elf.c|2 +-
fs/proc/task_mmu.c |8 +---
include/linux/mm.h |2 +-
mm/memory.c|4 ++--
mm/mlock.c |4 ++--
10 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index fd87287..6169f17 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -830,7 +830,7 @@ int in_gate_area(struct task_struct *task, unsigned long
addr)
return 0;
}
-struct vm_area_struct *get_gate_vma(struct task_struct *tsk)
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
{
return NULL;
}
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index f438d74..d19f305 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -347,7 +347,7 @@ int in_gate_area(struct task_struct *task, unsigned long
addr)
return 0;
}
-struct vm_area_struct *get_gate_vma(struct task_struct *tsk)
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
{
return NULL;
}
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c
b/arch/sh/kernel/vsyscall/vsyscall.c
index 242117c..3f9b6f4 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -94,7 +94,7 @@ const char *arch_vma_name(struct vm_area_struct *vma)
return NULL;
}
-struct vm_area_struct *get_gate_vma(struct task_struct *task)
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
{
return NULL;
}
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 71a5929..2c1799f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -870,10 +870,10 @@ static struct vm_area_struct gate_vma = {
.vm_flags = VM_READ | VM_EXEC
};
-struct vm_area_struct *get_gate_vma(struct task_struct *tsk)
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
{
#ifdef CONFIG_IA32_EMULATION
- if (test_tsk_thread_flag(tsk, TIF_IA32))
+ if (!mm || mm-context.compat)
return NULL;
#endif
return gate_vma;
@@ -881,7 +881,7 @@ struct vm_area_struct *get_gate_vma(struct task_struct *tsk)
int in_gate_area(struct task_struct *task, unsigned long addr)
{
- struct vm_area_struct *vma = get_gate_vma(task);
+ struct vm_area_struct *vma = get_gate_vma(task-mm);
if (!vma)
return 0;
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 36df991..1f651f6 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -417,11 +417,12 @@ const char *arch_vma_name(struct vm_area_struct *vma)
return NULL;
}
-struct vm_area_struct *get_gate_vma(struct task_struct *tsk)
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
{
- struct mm_struct *mm = tsk-mm;
-
- /* Check to see if this task was created in compat vdso mode */
+ /*
+* Check to see if the corresponding task was created in compat vdso
+* mode.
+*/
if (mm mm-context.vdso == (void *)VDSO_HIGH_BASE)
return gate_vma;
return NULL;
@@ -429,7 +430,7 @@ struct vm_area_struct *get_gate_vma(struct task_struct *tsk)
int in_gate_area(struct task_struct *task, unsigned long addr)
{
- const struct vm_area_struct *vma = get_gate_vma(task);
+ const struct vm_area_struct *vma = get_gate_vma(task-mm);
return vma addr = vma-vm_start addr vma-vm_end;
}
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d5b640b..bbabdcc 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1906,7 +1906,7 @@ static int elf_core_dump(struct coredump_params *cprm)
segs = current-mm-map_count;
segs += elf_core_extra_phdrs();
- gate_vma = get_gate_vma(current);
+ gate_vma = get_gate_vma(current-mm);
if (gate_vma != NULL)
segs++;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 60b9148..bb548d4 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -126,7 +126,7 @@ static void *m_start(struct seq_file *m, loff_t *pos)
return NULL;
down_read(mm-mmap_sem);
- tail_vma = get_gate_vma(priv-task);
+ tail_vma = get_gate_vma(priv-task-mm);
priv-tail_vma = tail_vma;
/* Start with last addr hint */
@@ -277,7 +277,8 @@ static int show_map(struct seq_file *m, void *v)
[PATCH 4/5] mm: arch: make in_gate_area take an mm_struct instead of a task_struct
Morally, the question of whether an address lies in a gate vma should be asked
with respect to an mm, not a particular task. Moreover, dropping the dependency
on task_struct will help make existing and future operations on mm's more
flexible and convenient.
Signed-off-by: Stephen Wilson wils...@start.ca
---
arch/powerpc/kernel/vdso.c |2 +-
arch/s390/kernel/vdso.c|2 +-
arch/sh/kernel/vsyscall/vsyscall.c |2 +-
arch/x86/mm/init_64.c |4 ++--
arch/x86/vdso/vdso32-setup.c |4 ++--
include/linux/mm.h |4 ++--
mm/memory.c|2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 6169f17..467aa9e 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -825,7 +825,7 @@ int in_gate_area_no_task(unsigned long addr)
return 0;
}
-int in_gate_area(struct task_struct *task, unsigned long addr)
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
{
return 0;
}
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index d19f305..9006e96 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -342,7 +342,7 @@ int in_gate_area_no_task(unsigned long addr)
return 0;
}
-int in_gate_area(struct task_struct *task, unsigned long addr)
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
{
return 0;
}
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c
b/arch/sh/kernel/vsyscall/vsyscall.c
index 3f9b6f4..62c36a8 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -99,7 +99,7 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
return NULL;
}
-int in_gate_area(struct task_struct *task, unsigned long address)
+int in_gate_area(struct mm_struct *mm, unsigned long address)
{
return 0;
}
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 2c1799f..3af0da3 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -879,9 +879,9 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
return gate_vma;
}
-int in_gate_area(struct task_struct *task, unsigned long addr)
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
{
- struct vm_area_struct *vma = get_gate_vma(task-mm);
+ struct vm_area_struct *vma = get_gate_vma(mm);
if (!vma)
return 0;
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 1f651f6..f849bb2 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -428,9 +428,9 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
return NULL;
}
-int in_gate_area(struct task_struct *task, unsigned long addr)
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
{
- const struct vm_area_struct *vma = get_gate_vma(task-mm);
+ const struct vm_area_struct *vma = get_gate_vma(mm);
return vma addr = vma-vm_start addr vma-vm_end;
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b571921..c700bbb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1571,10 +1571,10 @@ static inline bool kernel_page_present(struct page
*page) { return true; }
extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm);
#ifdef __HAVE_ARCH_GATE_AREA
int in_gate_area_no_task(unsigned long addr);
-int in_gate_area(struct task_struct *task, unsigned long addr);
+int in_gate_area(struct mm_struct *mm, unsigned long addr);
#else
int in_gate_area_no_task(unsigned long addr);
-#define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
+#define in_gate_area(mm, addr) ({(void)mm; in_gate_area_no_task(addr);})
#endif /* __HAVE_ARCH_GATE_AREA */
int drop_caches_sysctl_handler(struct ctl_table *, int,
diff --git a/mm/memory.c b/mm/memory.c
index aec7cbd..d1347ac 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1437,7 +1437,7 @@ int __get_user_pages(struct task_struct *tsk, struct
mm_struct *mm,
struct vm_area_struct *vma;
vma = find_extend_vma(mm, start);
- if (!vma in_gate_area(tsk, start)) {
+ if (!vma in_gate_area(tsk-mm, start)) {
unsigned long pg = start PAGE_MASK;
struct vm_area_struct *gate_vma = get_gate_vma(tsk-mm);
pgd_t *pgd;
--
1.7.3.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/5] mm: arch: rename in_gate_area_no_task to in_gate_area_no_mm
Now that gate vma's are referenced with respect to a particular mm and not a
particular task it only makes sense to propagate the change to this predicate as
well.
Signed-off-by: Stephen Wilson wils...@start.ca
---
arch/powerpc/kernel/vdso.c |2 +-
arch/s390/kernel/vdso.c|2 +-
arch/sh/kernel/vsyscall/vsyscall.c |2 +-
arch/x86/mm/init_64.c |8
arch/x86/vdso/vdso32-setup.c |2 +-
include/linux/mm.h |6 +++---
kernel/kallsyms.c |4 ++--
mm/memory.c|2 +-
mm/nommu.c |2 +-
9 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 467aa9e..142ab10 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -820,7 +820,7 @@ static int __init vdso_init(void)
}
arch_initcall(vdso_init);
-int in_gate_area_no_task(unsigned long addr)
+int in_gate_area_no_mm(unsigned long addr)
{
return 0;
}
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index 9006e96..d73630b 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -337,7 +337,7 @@ static int __init vdso_init(void)
}
arch_initcall(vdso_init);
-int in_gate_area_no_task(unsigned long addr)
+int in_gate_area_no_mm(unsigned long addr)
{
return 0;
}
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c
b/arch/sh/kernel/vsyscall/vsyscall.c
index 62c36a8..1d6d51a 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -104,7 +104,7 @@ int in_gate_area(struct mm_struct *mm, unsigned long
address)
return 0;
}
-int in_gate_area_no_task(unsigned long address)
+int in_gate_area_no_mm(unsigned long address)
{
return 0;
}
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 3af0da3..d3b5e2c 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -890,11 +890,11 @@ int in_gate_area(struct mm_struct *mm, unsigned long addr)
}
/*
- * Use this when you have no reliable task/vma, typically from interrupt
- * context. It is less reliable than using the task's vma and may give
- * false positives:
+ * Use this when you have no reliable mm, typically from interrupt
+ * context. It is less reliable than using a task's mm and may give
+ * false positives.
*/
-int in_gate_area_no_task(unsigned long addr)
+int in_gate_area_no_mm(unsigned long addr)
{
return (addr = VSYSCALL_START) (addr VSYSCALL_END);
}
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index f849bb2..468d591 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -435,7 +435,7 @@ int in_gate_area(struct mm_struct *mm, unsigned long addr)
return vma addr = vma-vm_start addr vma-vm_end;
}
-int in_gate_area_no_task(unsigned long addr)
+int in_gate_area_no_mm(unsigned long addr)
{
return 0;
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c700bbb..694512d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1570,11 +1570,11 @@ static inline bool kernel_page_present(struct page
*page) { return true; }
extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm);
#ifdef __HAVE_ARCH_GATE_AREA
-int in_gate_area_no_task(unsigned long addr);
+int in_gate_area_no_mm(unsigned long addr);
int in_gate_area(struct mm_struct *mm, unsigned long addr);
#else
-int in_gate_area_no_task(unsigned long addr);
-#define in_gate_area(mm, addr) ({(void)mm; in_gate_area_no_task(addr);})
+int in_gate_area_no_mm(unsigned long addr);
+#define in_gate_area(mm, addr) ({(void)mm; in_gate_area_no_mm(addr);})
#endif /* __HAVE_ARCH_GATE_AREA */
int drop_caches_sysctl_handler(struct ctl_table *, int,
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 6f6d091..b9d0fd1 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -64,14 +64,14 @@ static inline int is_kernel_text(unsigned long addr)
if ((addr = (unsigned long)_stext addr = (unsigned long)_etext) ||
arch_is_kernel_text(addr))
return 1;
- return in_gate_area_no_task(addr);
+ return in_gate_area_no_mm(addr);
}
static inline int is_kernel(unsigned long addr)
{
if (addr = (unsigned long)_stext addr = (unsigned long)_end)
return 1;
- return in_gate_area_no_task(addr);
+ return in_gate_area_no_mm(addr);
}
static int is_ksym_addr(unsigned long addr)
diff --git a/mm/memory.c b/mm/memory.c
index d1347ac..3863e86 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3448,7 +3448,7 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
#endif
}
-int in_gate_area_no_task(unsigned long addr)
+int in_gate_area_no_mm(unsigned long addr)
{
#ifdef AT_SYSINFO_EHDR
if ((addr = FIXADDR_USER_START) (addr FIXADDR_USER_END))
diff --git a/mm/nommu.c b/mm/nommu.c
index f59e142..e629143 100644
--- a/mm/nommu.c
+++
Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
On Thu, 3 Mar 2011 10:22:39 +0100 Wolfram Sang w.s...@pengutronix.de wrote: Hi, +/* + * This file provides Date Time support (no alarms) for PT7C4338 chip. + * + * This file is based on drivers/rtc/rtc-ds1307.c Please explain why you can't use rtc-ds1307 directly (or with slight modifications). I might have missed something but the register-set looks identical to me? Was there an answer to this question? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mpc8315erdb openvpn segmentation fault
Thanks again Scott. That was really helpful. Actually i forgot to mention that i had created an ext2 ramdisk file system and it was non-persistent. and then i changed the file system to jffs2 and it is persistent. so my question is why is that the ext2 ramdisk is non-persistent? and what needs to be changed in order to make it persistent. thanks again for prompt response.. Scott Wood-2 wrote: On Mon, 7 Mar 2011 20:28:32 -0800 Vasanth Ragavendran ragavendra...@yahoo.co.in wrote: Thanks a ton Scott. Actually i was working with the same version of the kernel on both the boards. it was 2.6.29.6. neither i changed the u-boot. it was the same in both. however i recompiled the kernel and i installed on both the boards and it worked fine! :) thanks again for responding. however i've another question. my filesystem in the board is non-persistent i.e. the files i create are erased after i reboot i know the files are getting stored in RAM and i wish to make them persistent. what do i need to do for this? should i create a separate partition in the flash and load certain files into that partition? or how should i make it persistent so that files stay beyond reboot! thanks again! eagerly awaiting your response. Yes, you should create a filesystem (e.g. jffs2) on a flash partition. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- View this message in context: http://old.nabble.com/Mpc8315erdb-openvpn-segmentation-fault-tp31086738p31102807.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[BUG] rebuild_sched_domains considered dangerous
So I've been experiencing hangs shortly after boot with recent kernels on a Power7 machine. I was testing with PREEMPT HZ=1024 which might increase the frequency of the problem but I don't think they are necessary to expose it. From what I've figured out, when the machine hangs, it's essentially looping forever in update_sd_lb_stats(), due to a corrupted sd-groups list (in my cases, the list contains a loop that doesn't loop back the the first element). It appears that this corresponds to one CPU deciding to rebuild the sched domains. There's various reasons why that can happen, the typical one in our case is the new VPNH feature where the hypervisor informs us of a change in node affinity of our virtual processors. s390 has a similar feature and should be affected as well. I suspect the problem could be reproduced on x86 by hammering the sysfs file that can be used to trigger a rebuild as well on a sufficently large machine. From what I can tell, there's some missing locking here between rebuilding the domains and find_busiest_group. I haven't quite got my head around how that -should- be done, though, as I an really not very familiar with that code. For example, I don't quite get when domains are attached to an rq, and whether code like build_numa_sched_groups() which allocates groups and attach them to sched domains sd-groups does it on a live domain or not (in that case, there's a problem since it kmalloc and attaches the uninitialized result immediately). I don't believe I understand enough of the scheduler to fix that quickly and I'm really bogged down with some other urgent stuff, so I would very much appreciate if you could provide some assistance here, even if it's just in the form of suggestions/hints. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: perf: Handle events that raise an exception without overflowing
Events on POWER7 can roll back if a speculative event doesn't
eventually complete. Unfortunately in some rare cases they will
raise a performance monitor exception. We need to catch this to
ensure we reset the PMC. In all cases the PMC will be 256 or less
cycles from overflow.
Signed-off-by: Anton Blanchard an...@samba.org
Cc: sta...@kernel.org
---
I would prefer not to add the PVR check, but I think we want to limit
this workaround to POWER7. Would a cpu feature be preferable?
Index: linux-2.6/arch/powerpc/kernel/perf_event.c
===
--- linux-2.6.orig/arch/powerpc/kernel/perf_event.c 2011-03-08
20:11:38.029800971 +1100
+++ linux-2.6/arch/powerpc/kernel/perf_event.c 2011-03-09 14:19:18.756143799
+1100
@@ -1269,6 +1269,28 @@ unsigned long perf_instruction_pointer(s
return ip;
}
+static bool pmc_overflow(unsigned long val)
+{
+ if ((int)val 0)
+ return true;
+
+ /*
+* Events on POWER7 can roll back if a speculative event doesn't
+* eventually complete. Unfortunately in some rare cases they will
+* raise a performance monitor exception. We need to catch this to
+* ensure we reset the PMC. In all cases the PMC will be 256 or less
+* cycles from overflow.
+*
+* We only do this if the first pass fails to find any overflowing
+* PMCs because a user might set a period of less than 256 and we
+* don't want to mistakenly reset them.
+*/
+ if (__is_processor(PV_POWER7) ((0x8000 - val) = 256))
+ return true;
+
+ return false;
+}
+
/*
* Performance monitor interrupt stuff
*/
@@ -1316,7 +1338,7 @@ static void perf_event_interrupt(struct
if (is_limited_pmc(i + 1))
continue;
val = read_pmc(i + 1);
- if ((int)val 0)
+ if (pmc_overflow(val))
write_pmc(i + 1, 0);
}
}
Index: linux-2.6/arch/powerpc/include/asm/reg.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/reg.h 2011-03-08
20:11:38.019800609 +1100
+++ linux-2.6/arch/powerpc/include/asm/reg.h2011-03-09 14:13:56.674461835
+1100
@@ -880,6 +880,7 @@
#define PV_970 0x0039
#define PV_POWER5 0x003A
#define PV_POWER5p 0x003B
+#define PV_POWER7 0x003F
#define PV_970FX 0x003C
#define PV_630 0x0040
#define PV_630p0x0041
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/28] powerpc: mpic irq_data conversion.
On Tue, 2011-03-08 at 00:59 +0100, Lennert Buytenhek wrote:
-static void mpic_unmask_ht_irq(unsigned int irq)
+static void mpic_unmask_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(irq);
- unsigned int src = mpic_irq_to_hw(irq);
+ struct mpic *mpic = mpic_from_irq(d-irq);
+ unsigned int src = mpic_irq_to_hw(d-irq);
It's a bit sad to have a pointerm turn it back to a irq number, look it
up just to get back the chip data in there :-)
Either we should create an mpic_from_irqdata() which itself uses
irq_data_get_irq_chip_data() or just change mpic_from_irq() if we decide
we can always call it with data instead of irq
- mpic_unmask_irq(irq);
+ mpic_unmask_irq(d);
- if (irq_to_desc(irq)-status IRQ_LEVEL)
+ if (irq_to_desc(d-irq)-status IRQ_LEVEL)
mpic_ht_end_irq(mpic, src);
}
Do we really need that gymnastic to get to desc-status from irq_data ?
Again, we're going back to a number and then looking it up again... bad.
I don't see off hand a data - desc accessor, but it also looks like it
should be trivial to add. Thomas, what do you reckon ?
-static unsigned int mpic_startup_ht_irq(unsigned int irq)
+static unsigned int mpic_startup_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(irq);
- unsigned int src = mpic_irq_to_hw(irq);
+ struct mpic *mpic = mpic_from_irq(d-irq);
+ unsigned int src = mpic_irq_to_hw(d-irq);
- mpic_unmask_irq(irq);
- mpic_startup_ht_interrupt(mpic, src, irq_to_desc(irq)-status);
+ mpic_unmask_irq(d);
+ mpic_startup_ht_interrupt(mpic, src, irq_to_desc(d-irq)-status);
return 0;
}
Similar.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: x86: kill binutils 2.16.x?
The problem is not with the kernel compile itself, but with the 2.12 dssall binutils test. Basically, recent binutils treats e500 as effectively a separate architecture that happens to share *most* of the opcodes with regular PowerPC. Any opcode which is not understood by the e500 chip is either convert to an equivalent opcode which is understood (IE: lwsync = sync), or failed with an error. This means that the kernel compile aborts early telling me to upgrade to a newer version of binutils. $ echo dssall | powerpc-linux-as -many -me500 $ powerpc-linux-objdump -d a.out | grep 0: 0: 7e 00 06 6c dssall $ powerpc-linux-as --version | head -1 GNU assembler (GNU Binutils) 2.21.51.20110309 What version of binutils does not work? (I also checked with -me500x2, -me500mc, -mspe, and various combinations. lwsync is indeed converted to a regular sync (well, msync) for e500 and e500x2). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc/e500: binutils tests [Was: RFC: x86: kill binutils 2.16.x?]
On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool seg...@kernel.crashing.org wrote: The problem is not with the kernel compile itself, but with the 2.12 dssall binutils test. Basically, recent binutils treats e500 as effectively a separate architecture that happens to share *most* of the opcodes with regular PowerPC. Any opcode which is not understood by the e500 chip is either convert to an equivalent opcode which is understood (IE: lwsync = sync), or failed with an error. This means that the kernel compile aborts early telling me to upgrade to a newer version of binutils. $ echo dssall | powerpc-linux-as -many -me500 $ powerpc-linux-objdump -d a.out | grep 0: 0: 7e 00 06 6c dssall $ powerpc-linux-as --version | head -1 GNU assembler (GNU Binutils) 2.21.51.20110309 What version of binutils does not work? (I also checked with -me500x2, -me500mc, -mspe, and various combinations. lwsync is indeed converted to a regular sync (well, msync) for e500 and e500x2). Hmm, something's fishy here. Just going based on this changeset, the floating point and AltiVec opcodes are *supposed* to generate hard errors: http://sourceware.org/ml/binutils-cvs/2010-06/msg00070.html Oh... that patch only disables the opcodes if -many is not specified. Aha! The native compiler on my Debian e500 boxes right now is hidden behind a small wrapper script which removes -many and -Wa,-many and generates errors for anything else that isn't -me500. My GCC also excludes the -many option when calling the linker directly. So I think this is only a local problem right now, actually, sorry for the noise and confusion. If I log into that system and run echo dssall | as, I get the expected hard error, and due to the wrapper scripts in place I get the same error from echo dssall | as -me500x2 -many Unfortunately I still need to have the assembler generate hard errors when someone tries to natively compile code with AltiVec or classic-FPU instructions, otherwise I have no way of detecting unported software at build-time. Would a patch to make the Altivec dssall test conditional on CONFIG_ALTIVEC be acceptable? That really is the only test that causes the kernel compile to fail with the strict wrappers. Cheers, Kyle Moffett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
On 08/25/2010 06:07 AM, Eric W. Biederman wrote: Anton Blanchard an...@samba.org writes: On ppc64 the crashkernel region almost always overlaps an area of firmware. This works fine except when using the sysfs interface to reduce the kdump region. If we free the firmware area we are guaranteed to crash. That is ppc64 bug. firmware should not be in the reserved region. Any random kernel like thing can be put in to that region at any valid address and the fact that shrinking the region frees your firmware means that using that region could also stomp your firmware (which I assume would be a bad thing). The issue only happens while shrinking the region using sysfs interface. We already have checks in kexec for not to stomp over on the firmware overlap area while loading capture kernel. Currently we do a top-down allocation for the firmware region which means it sits at the top of the RMO, right in the middle of the crashdump region. We can not move the crashkernel region beyond firmware region because kernel needs its some of memory in RMO region. So please fix the ppc64 reservation. Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
On Tue, Mar 08, 2011 at 04:55:31PM -0800, Andrew Morton wrote: On Thu, 3 Mar 2011 10:22:39 +0100 Wolfram Sang w.s...@pengutronix.de wrote: Hi, +/* + * This file provides Date Time support (no alarms) for PT7C4338 chip. + * + * This file is based on drivers/rtc/rtc-ds1307.c Please explain why you can't use rtc-ds1307 directly (or with slight modifications). I might have missed something but the register-set looks identical to me? Was there an answer to this question? I didn't get one. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mpc8315erdb openvpn segmentation fault
Thanks again Scott. That was really helpful. Actually i forgot to mention that i had created an ext2 ramdisk file system and it was non-persistent (the mount point was /dev/ram for this ext2 ramdisk filesystem). and then i changed the file system to jffs2 and it is persistent (and the mount point was /dev/mtdblock1 for jffs2 file system). so my question is why is that the ext2 ramdisk is non-persistent? is it because of the mount point /dev/ram and what needs to be changed in order to make it persistent. thanks again for prompt response.. Scott Wood-2 wrote: On Mon, 7 Mar 2011 20:28:32 -0800 Vasanth Ragavendran ragavendra...@yahoo.co.in wrote: Thanks a ton Scott. Actually i was working with the same version of the kernel on both the boards. it was 2.6.29.6. neither i changed the u-boot. it was the same in both. however i recompiled the kernel and i installed on both the boards and it worked fine! :) thanks again for responding. however i've another question. my filesystem in the board is non-persistent i.e. the files i create are erased after i reboot i know the files are getting stored in RAM and i wish to make them persistent. what do i need to do for this? should i create a separate partition in the flash and load certain files into that partition? or how should i make it persistent so that files stay beyond reboot! thanks again! eagerly awaiting your response. Yes, you should create a filesystem (e.g. jffs2) on a flash partition. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- View this message in context: http://old.nabble.com/Mpc8315erdb-openvpn-segmentation-fault-tp31086738p31103965.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v3] driver/FSL SATA:Fix wrong Device Error Register usage
When a single device error is detected, the device under the error is indicated
by the error bit set in the DER. There is a one to one mapping between register
bit and devices on Port multiplier(PMP) i.e. bit 0 represents PMP device 0 and
bit 1 represents PMP device 1 etc.
Current implementation treats Device error register value as device number not
set of bits representing multiple device on PMP. It is changed to consider bit
level.
No need to check for each set bit as all command is going to be aborted.
Signed-off-by: Ashish Kalra b00...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch
master)
This patch is already gone through review of linuxppc-dev mail list.
Making CC linuxppc-dev@lists.ozlabs.org
Changes for v2: Incorporated Sergei Shtylyov's comment
- Put space after -
- added a line
Changes for v3: Incorporated David Laight's comment
- Condition check for dereg 0 for hardware error
drivers/ata/sata_fsl.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index b0214d0..ad84ddc 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1040,12 +1040,15 @@ static void sata_fsl_error_intr(struct ata_port *ap)
/* find out the offending link and qc */
if (ap-nr_pmp_links) {
+ unsigned int dev_num;
+
dereg = ioread32(hcr_base + DE);
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
- if (dereg ap-nr_pmp_links) {
- link = ap-pmp_link[dereg];
+ dev_num = ffs(dereg) - 1;
+ if (dev_num ap-nr_pmp_links dereg != 0) {
+ link = ap-pmp_link[dev_num];
ehi = link-eh_info;
qc = ata_qc_from_tag(ap, link-active_tag);
/*
--
1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/28] powerpc: mpic irq_data conversion.
On Wed, Mar 09, 2011 at 02:22:55PM +1100, Benjamin Herrenschmidt wrote:
-static void mpic_unmask_ht_irq(unsigned int irq)
+static void mpic_unmask_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(irq);
- unsigned int src = mpic_irq_to_hw(irq);
+ struct mpic *mpic = mpic_from_irq(d-irq);
+ unsigned int src = mpic_irq_to_hw(d-irq);
It's a bit sad to have a pointerm turn it back to a irq number,
look it up just to get back the chip data in there :-)
ACK, how about the below?
Either we should create an mpic_from_irqdata() which itself uses
irq_data_get_irq_chip_data() or just change mpic_from_irq() if we
decide we can always call it with data instead of irq
There's one site left that needs to go from virq to mpic, so I've
done the former.
- mpic_unmask_irq(irq);
+ mpic_unmask_irq(d);
- if (irq_to_desc(irq)-status IRQ_LEVEL)
+ if (irq_to_desc(d-irq)-status IRQ_LEVEL)
mpic_ht_end_irq(mpic, src);
}
Do we really need that gymnastic to get to desc-status from irq_data ?
Again, we're going back to a number and then looking it up again... bad.
I don't see off hand a data - desc accessor, but it also looks like it
should be trivial to add. Thomas, what do you reckon ?
It really shouldn't be looking at the desc at all.
This should help, as we only look at IRQ_LEVEL here:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=876dbd4cc1b35c1a4cb96a2be1d43ea0eabce3b4
cheers,
Lennert
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 95712f6..eb70218 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -648,6 +648,12 @@ static inline struct mpic * mpic_from_irq(unsigned int irq)
return get_irq_chip_data(irq);
}
+/* Get the mpic structure from the irq data */
+static inline struct mpic * mpic_from_irq_data(struct irq_data *d)
+{
+ return irq_data_get_irq_chip_data(d);
+}
+
/* Send an EOI */
static inline void mpic_eoi(struct mpic *mpic)
{
@@ -663,7 +669,7 @@ static inline void mpic_eoi(struct mpic *mpic)
void mpic_unmask_irq(struct irq_data *d)
{
unsigned int loops = 10;
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
DBG(%p: %s: enable_irq: %d (src %d)\n, mpic, mpic-name, d-irq, src);
@@ -684,7 +690,7 @@ void mpic_unmask_irq(struct irq_data *d)
void mpic_mask_irq(struct irq_data *d)
{
unsigned int loops = 10;
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
DBG(%s: disable_irq: %d (src %d)\n, mpic-name, d-irq, src);
@@ -705,7 +711,7 @@ void mpic_mask_irq(struct irq_data *d)
void mpic_end_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
#ifdef DEBUG_IRQ
DBG(%s: end_irq: %d\n, mpic-name, d-irq);
@@ -722,7 +728,7 @@ void mpic_end_irq(struct irq_data *d)
static void mpic_unmask_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
mpic_unmask_irq(d);
@@ -733,7 +739,7 @@ static void mpic_unmask_ht_irq(struct irq_data *d)
static unsigned int mpic_startup_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
mpic_unmask_irq(d);
@@ -744,7 +750,7 @@ static unsigned int mpic_startup_ht_irq(struct irq_data *d)
static void mpic_shutdown_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
mpic_shutdown_ht_interrupt(mpic, src, irq_to_desc(d-irq)-status);
@@ -753,7 +759,7 @@ static void mpic_shutdown_ht_irq(struct irq_data *d)
static void mpic_end_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
#ifdef DEBUG_IRQ
@@ -805,7 +811,7 @@ static void mpic_end_ipi(struct irq_data *d)
int mpic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
bool force)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic = mpic_from_irq_data(d);
unsigned int src = mpic_irq_to_hw(d-irq);
if (mpic-flags MPIC_SINGLE_DEST_CPU) {
@@ -851,7 +857,7 @@ static unsigned int mpic_type_to_vecpri(struct mpic *mpic,
unsigned int type)
int mpic_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- struct mpic *mpic = mpic_from_irq(d-irq);
+ struct mpic *mpic =
Re: [PATCH 01/28] powerpc: mpic irq_data conversion.
On Wed, 2011-03-09 at 08:33 +0100, Lennert Buytenhek wrote:
-static void mpic_unmask_ht_irq(unsigned int irq)
+static void mpic_unmask_ht_irq(struct irq_data *d)
{
- struct mpic *mpic = mpic_from_irq(irq);
- unsigned int src = mpic_irq_to_hw(irq);
+ struct mpic *mpic = mpic_from_irq(d-irq);
+ unsigned int src = mpic_irq_to_hw(d-irq);
It's a bit sad to have a pointerm turn it back to a irq number,
look it up just to get back the chip data in there :-)
ACK, how about the below?
Much better. Do you want to fold it in and re-post only the affected
patch (es) ?
Either we should create an mpic_from_irqdata() which itself uses
irq_data_get_irq_chip_data() or just change mpic_from_irq() if we
decide we can always call it with data instead of irq
There's one site left that needs to go from virq to mpic, so I've
done the former.
Ok.
should be trivial to add. Thomas, what do you reckon ?
It really shouldn't be looking at the desc at all.
This should help, as we only look at IRQ_LEVEL here:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=876dbd4cc1b35c1a4cb96a2be1d43ea0eabce3b4
Ah yes, indeed. The trigger is all we care about. We can do that in
second phase after Thomas stuff goes in.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/e500: binutils tests [Was: RFC: x86: kill binutils 2.16.x?]
* Kyle Moffett | 2011-03-09 00:22:11 [-0500]: On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool seg...@kernel.crashing.org wrote: The problem is not with the kernel compile itself, but with the 2.12 dssall binutils test. ??Basically, recent binutils treats e500 as effectively a separate architecture that happens to share *most* of the opcodes with regular PowerPC. ??Any opcode which is not understood by the e500 chip is either convert to an equivalent opcode which is understood (IE: lwsync = sync), or failed with an error. ??This means that the kernel compile aborts early telling me to upgrade to a newer version of binutils. $ echo dssall | powerpc-linux-as -many -me500 $ powerpc-linux-objdump -d a.out | grep 0: ?? 0: ?? 7e 00 06 6c ?? ?? dssall $ powerpc-linux-as --version | head -1 GNU assembler (GNU Binutils) 2.21.51.20110309 What version of binutils does not work? ??(I also checked with -me500x2, -me500mc, -mspe, and various combinations. ??lwsync is indeed converted to a regular sync (well, msync) for e500 and e500x2). Hmm, something's fishy here. Did I break anything? Not sure if mc and x2 are the same thing. One of those e500 thingy has a the classic FPU if I remember correctly. Anyway, -me500 enables a certain range of opcodes -many enables all of them (or the remaining few). So without -many this test will fail. The auto conversion of lwsync = sync or msync should be performed due to -me500. Just going based on this changeset, the floating point and AltiVec opcodes are *supposed* to generate hard errors: http://sourceware.org/ml/binutils-cvs/2010-06/msg00070.html Oh... that patch only disables the opcodes if -many is not specified. To some degree yes. If you specify -me500 -maltivec you can still use AltiVec opcodes because you enabled them. So for that reason there are scripts on buildds to prevent passing mcpu to gcc among other things :) Cheers, Kyle Moffett Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
