> 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 (
On Mon, 7 Mar 2011 20:28:32 -0800
Vasanth Ragavendran 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 bot
On Thu, Mar 3, 2011 at 03:30, Ingo Molnar wrote:
> This is how specific GAS functionality is tested in arch/powerpc:
>
> @if ! /bin/echo dssall | $(AS) -many -o $(TOUT) >/dev/null 2>&1 ; then
> \
> echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build
> ' ; \
>
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
On Tue, Mar 8, 2011 at 16:28, Benjamin Herrenschmidt
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 ran
On Wed, 9 Mar 2011 08:28:36 +1100
Benjamin Herrenschmidt 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 AltiV
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 Powe
On Tue, Mar 8, 2011 at 18:13, Benjamin Herrenschmidt
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 architectu
On Wed, 2 Mar 2011 09:42:30 +0530
Priyanka Jain 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: Pri
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 p
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
---
arch/x86/ia32/ia32_aout.c|1 +
arch/x86/kernel/
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
---
arch/x86/include/asm/mmu.h |6 ++
1 files changed, 6 i
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
---
arch/powerpc/kernel/vds
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
---
arc
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
---
arch/powerpc/kernel/vdso.c |2 +-
arch/s390/kernel/vdso.c|2 +-
arch/s
On Thu, 3 Mar 2011 10:22:39 +0100
Wolfram Sang 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
> modificat
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
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 essentiall
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: Anto
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 = mpi
> 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 chi
On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool
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 P
On 08/25/2010 06:07 AM, Eric W. Biederman wrote:
> Anton Blanchard 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 cra
On Tue, Mar 08, 2011 at 04:55:31PM -0800, Andrew Morton wrote:
> On Thu, 3 Mar 2011 10:22:39 +0100
> Wolfram Sang wrote:
>
> > Hi,
> >
> > > +/*
> > > + * This file provides Date & Time support (no alarms) for PT7C4338 chip.
> > > + *
> > > + * This file is based on drivers/rtc/rtc-ds1307.c
> >
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
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 t
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);
> > + struc
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
* Kyle Moffett | 2011-03-09 00:22:11 [-0500]:
>On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool
> 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 hap
29 matches
Mail list logo
