* Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
From: John Kacur @ 2009-10-21 21:33 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Arnd Bergmann, Jonathan Corbet, LKML, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, Alan Cox
In-Reply-To: <20091021212137.GB4880@nowhere>
On Wed, 21 Oct 2009, Frederic Weisbecker wrote:
> On Wed, Oct 21, 2009 at 11:07:18PM +0200, John Kacur wrote:
> > From 0c2b412cdccf73bdeb19bb866bfe556942eaeca2 Mon Sep 17 00:00:00 2001
> > From: John Kacur <jkacur@redhat.com>
> > Date: Wed, 21 Oct 2009 23:01:12 +0200
> > Subject: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
> >
> > Now that we've removed the BKL here, let's explicitly set lleek to no_llseek
> >
> > Signed-off-by: John Kacur <jkacur@redhat.com>
> > ---
> > drivers/macintosh/ans-lcd.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
> > index 4ae8ec9..a1a1bde 100644
> > --- a/drivers/macintosh/ans-lcd.c
> > +++ b/drivers/macintosh/ans-lcd.c
> > @@ -137,6 +137,7 @@ const struct file_operations anslcd_fops = {
> > .write = anslcd_write,
> > .unlocked_ioctl = anslcd_ioctl,
> > .open = anslcd_open,
> > + .llseedk = no_llseek,
>
>
> llseedk? :)
>
>
> Should we better pushdown default_llseek to every to every
> file operations that don't implement llseek?
> I don't know how many of them don't implement llseek() though.
>
> That said we can't continue anymore with this default attribution
> of default_llseek() on new fops.
>
If you don't explicitly set it to no_llseek, you automatically get the
default_llseek, which uses the BKL. So if your driver doesn't need it, it
is best to explicitly set it to no_llseek.
There is also a generic_file_llseek_unlocked, somewhat analogous to the
unlocked_ioctls that you can use if you don't need to provide a full
llseek yourself.
^ permalink raw reply
* Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
From: Frederic Weisbecker @ 2009-10-21 21:45 UTC (permalink / raw)
To: John Kacur
Cc: Arnd Bergmann, Jonathan Corbet, LKML, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, Alan Cox
In-Reply-To: <alpine.LFD.2.00.0910212327160.3526@localhost.localdomain>
On Wed, Oct 21, 2009 at 11:33:17PM +0200, John Kacur wrote:
> > Should we better pushdown default_llseek to every to every
> > file operations that don't implement llseek?
> > I don't know how many of them don't implement llseek() though.
> >
> > That said we can't continue anymore with this default attribution
> > of default_llseek() on new fops.
> >
>
> If you don't explicitly set it to no_llseek, you automatically get the
> default_llseek, which uses the BKL. So if your driver doesn't need it, it
> is best to explicitly set it to no_llseek.
Sure, that's the right thing to do.
> There is also a generic_file_llseek_unlocked, somewhat analogous to the
> unlocked_ioctls that you can use if you don't need to provide a full
> llseek yourself.
No problem with that. Setting no_llseek or generic_file_llseek_unlocked,
depending on the context is the right thing to do.
What I'm wondering about concerns the future code that will have
no llsek() implemented in their fops.
We can't continue to use default_llseek() for future code unless we
want to continue these post reviews and fixes forever.
^ permalink raw reply
* Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
From: John Kacur @ 2009-10-21 21:53 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Arnd Bergmann, Jonathan Corbet, LKML, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, Alan Cox
In-Reply-To: <20091021214537.GD4880@nowhere>
On Wed, 21 Oct 2009, Frederic Weisbecker wrote:
> On Wed, Oct 21, 2009 at 11:33:17PM +0200, John Kacur wrote:
> > > Should we better pushdown default_llseek to every to every
> > > file operations that don't implement llseek?
> > > I don't know how many of them don't implement llseek() though.
> > >
> > > That said we can't continue anymore with this default attribution
> > > of default_llseek() on new fops.
> > >
> >
> > If you don't explicitly set it to no_llseek, you automatically get the
> > default_llseek, which uses the BKL. So if your driver doesn't need it, it
> > is best to explicitly set it to no_llseek.
>
>
> Sure, that's the right thing to do.
>
>
> > There is also a generic_file_llseek_unlocked, somewhat analogous to the
> > unlocked_ioctls that you can use if you don't need to provide a full
> > llseek yourself.
>
>
> No problem with that. Setting no_llseek or generic_file_llseek_unlocked,
> depending on the context is the right thing to do.
>
> What I'm wondering about concerns the future code that will have
> no llsek() implemented in their fops.
>
> We can't continue to use default_llseek() for future code unless we
> want to continue these post reviews and fixes forever.
>
I'm thinking that the simplier approach, would be to make the
default_llseek the unlocked one. Then you only have to audit the drivers
that have the BKL - ie the ones we are auditing anyway, and explicitly set
them to the bkl locked llseek.
There might be a hidden interaction though between the non-unlocked
variety of ioctls and default llseek though.
^ permalink raw reply
* Re: Device Tree Corrupted after unflatten_device_tree()
From: David Gibson @ 2009-10-21 22:10 UTC (permalink / raw)
To: Lixin Yao; +Cc: linuxppc-dev
In-Reply-To: <03D77CA4AC7F4D48A6AB5DA3F1001B3FB5BB8B@exchtxus2.HSTX.global.vpn>
On Wed, Oct 21, 2009 at 10:43:55AM -0700, Lixin Yao wrote:
> When corrupted, curtain blocks of 64 bytes are messed up.
> This is a screen dump of a good unflattened device at beginning:
[snip]
> When corrupted, it becomes following, note the 64 bock at 0x03ffdf00
> is messed up. And this kind of corruptions occur several times
[snip]
> 03ffdf00 : ffffffff ffff000c db055be0 08060001 ..........[.....
> 03ffdf10 : 08000604 0001000c db055be0 ac141001 ..........[.....
> 03ffdf20 : 00000000 0000ac14 10530000 10530000 .........S...S..
> 03ffdf30 : 08000604 0001000c 36681bfe f874c01e ........6h...t..
Uh, oh. That looks like a broadcast ethernet packet (ARP,
specifically). Looks like a network device used by the firmware
hasn't been quiesced properly before booting the kernel and is DMAing
stuff straight on top of kernel memory. You'll probably need a hook
in the bootwrapper to shut down the ethernet.
There are some examples of this in arch/powerpc/boot already - look
for ibm4xx_quiesce_eth().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
From: Frederic Weisbecker @ 2009-10-21 22:16 UTC (permalink / raw)
To: John Kacur
Cc: Arnd Bergmann, Jonathan Corbet, LKML, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, Alan Cox
In-Reply-To: <alpine.LFD.2.00.0910212350210.3526@localhost.localdomain>
On Wed, Oct 21, 2009 at 11:53:21PM +0200, John Kacur wrote:
> > No problem with that. Setting no_llseek or generic_file_llseek_unlocked,
> > depending on the context is the right thing to do.
> >
> > What I'm wondering about concerns the future code that will have
> > no llsek() implemented in their fops.
> >
> > We can't continue to use default_llseek() for future code unless we
> > want to continue these post reviews and fixes forever.
> >
>
> I'm thinking that the simplier approach, would be to make the
> default_llseek the unlocked one. Then you only have to audit the drivers
> that have the BKL - ie the ones we are auditing anyway, and explicitly set
> them to the bkl locked llseek.
>
> There might be a hidden interaction though between the non-unlocked
> variety of ioctls and default llseek though.
I fear that won't work because the bkl in default_llseek() does not
only synchronizes with others uses of the bkl in a driver, it also
synchronizes lseek() itself.
As an example offset change is not atomic. This is a long long, so
updating its value is not atomic in 32 bits archs.
^ permalink raw reply
* Serial console under current qemu: bisected.
From: Rob Landley @ 2009-10-21 22:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alan
Last week I reported a bug:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html
I managed to drill past the unrelated breakage and bisect it back to the
relevant commit: It was introduced leading up to 2.6.29, by commit
f751928e0ddf54ea4fe5546f35e99efc5b5d9938 written by Alan Cox.
It seems to make the kernel panic as soon as IRQs are enabled in the presence
of CONFIG_SERIAL_PMACZILOG=y. It's trivially reproducible under current qemu-
git. Kernels before that boot to a shell prompt, kernels after that panic as
soon as init launches. (They work fine when you're not using a serial
console.)
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* RE: [PATCH v3 2/3] powerpc/fsl: 85xx: document cache-sram
From: Mahajan Vivek-B08308 @ 2009-10-22 5:42 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Gala Kumar-B11780
In-Reply-To: <20091021175012.ED29819F73@gemini.denx.de>
Wolfgang Denk Sent: Wednesday, October 21, 2009 11:20 PM
> > * How to enable it from a low level driver
> > * How to set its size
> ...
> > +The size of the above cache SRAM memory window is passed via the=20
> > +kernel command line as <cache-sram-size=3D....>
>=20
> Would it not make more sense to configure this property=20
> through the device tree?=20
Since this parameter needs to be passed run time to the kernel=20
and it was not preconfigured by u-boot; so it landed in the=20
cmdline instead of the device tree.
>=20
> Best regards,
>=20
> Wolfgang Denk
>=20
Thanks,
Vivek
^ permalink raw reply
* [PATCH] powerpc: Fix potential compile error irqs_disabled_flags
From: Michael Neuling @ 2009-10-22 5:58 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, kumar.gala
irqs_disabled_flags is #defined in linux/irqflags.h when
CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled.
This fixes the case when someone needs to include both linux/irqflags.h
and asm/hw_irq.h.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
I'm not sure if this is the right fix. We could just remove
irqs_disabled_flags but I think that has the possibility of breaking
32bit.
arch/powerpc/include/asm/hw_irq.h | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/hw_irq.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/hw_irq.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/hw_irq.h
@@ -64,10 +64,12 @@ extern void iseries_handle_interrupts(vo
get_paca()->hard_enabled = 0; \
} while(0)
+#ifndef CONFIG_TRACE_IRQFLAGS_SUPPORT
static inline int irqs_disabled_flags(unsigned long flags)
{
return flags == 0;
}
+#endif
#else
^ permalink raw reply
* Re: [PATCH] powerpc: Fix potential compile error irqs_disabled_flags
From: Kumar Gala @ 2009-10-22 6:03 UTC (permalink / raw)
To: Michael Neuling; +Cc: linux-ppc list
In-Reply-To: <6797.1256191115@neuling.org>
On Oct 22, 2009, at 12:58 AM, Michael Neuling wrote:
> irqs_disabled_flags is #defined in linux/irqflags.h when
> CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled.
>
> This fixes the case when someone needs to include both linux/
> irqflags.h
> and asm/hw_irq.h.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> I'm not sure if this is the right fix. We could just remove
> irqs_disabled_flags but I think that has the possibility of breaking
> 32bit.
>
> arch/powerpc/include/asm/hw_irq.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6-ozlabs/arch/powerpc/include/asm/hw_irq.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/hw_irq.h
> +++ linux-2.6-ozlabs/arch/powerpc/include/asm/hw_irq.h
> @@ -64,10 +64,12 @@ extern void iseries_handle_interrupts(vo
> get_paca()->hard_enabled = 0; \
> } while(0)
>
> +#ifndef CONFIG_TRACE_IRQFLAGS_SUPPORT
> static inline int irqs_disabled_flags(unsigned long flags)
> {
> return flags == 0;
> }
> +#endif
I think you can just remove irqs_disabled_flags as we always have
CONFIG_TRACE_IRQFLAGS_SUPPORT (for both 32 and 64).
- k
^ permalink raw reply
* [PATCH] powerpc: Fix potential compile error irqs_disabled_flags
From: Michael Neuling @ 2009-10-22 6:15 UTC (permalink / raw)
To: Kumar Gala, benh; +Cc: linux-ppc list
In-Reply-To: <58391C58-B57E-47A8-ACE3-0272C3CF223F@freescale.com>
irqs_disabled_flags is #defined in linux/irqflags.h when
CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled. 64 and 32 bit always have
CONFIG_TRACE_IRQFLAGS_SUPPORT enabled so just remove
irqs_disabled_flags.
This fixes the case when someone needs to include both linux/irqflags.h
and asm/hw_irq.h.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
> I think you can just remove irqs_disabled_flags as we always have
> CONFIG_TRACE_IRQFLAGS_SUPPORT (for both 32 and 64).
Ok, thanks kumar.
arch/powerpc/include/asm/hw_irq.h | 5 -----
1 file changed, 5 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/hw_irq.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/hw_irq.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/hw_irq.h
@@ -64,11 +64,6 @@ extern void iseries_handle_interrupts(vo
get_paca()->hard_enabled = 0; \
} while(0)
-static inline int irqs_disabled_flags(unsigned long flags)
-{
- return flags == 0;
-}
-
#else
#if defined(CONFIG_BOOKE)
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-22 8:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <20091016153128.GA11838@loki.buserror.net>
Hi, Scott
Scott Wood wrote:
> On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote:
>
>> Thanks for confirmation. So the real problem is eLBC ?
>> What happens if I access other devices on eLBC (e.g. FPGA)
>> simultaneously with NAND or NOR ?
>>
>
> AFAICT, the problem is NAND being accessed simultaneously with anything else
> on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the
> memory-like transaction until the NAND special operation has completed, it
> seems to just abort the NAND operation.
>
> eLBC can't really tell the difference whether you've got NOR or FPGA hooked
> up to a GPCM chip select, so the problem should still apply.
>
Are you aware of Freescale plans to fix the problem in new silicon
revisions ?
Also, can you please tell what CPUs are affected by this, except 8536
and 8572.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: [PATCH] powerpc: Move ehea hcall definitions into hvcall.h
From: Thomas Klein @ 2009-10-22 8:48 UTC (permalink / raw)
To: Anton Blanchard
Cc: Thomas Klein, Christoph Raisch, linuxppc-dev, Jan-Bernd Themann
In-Reply-To: <20091021060621.GV4808@kryten>
Anton Blanchard wrote:
> Move ehea hcall definitions into hvcall.h.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Thomas Klein <tklein@de.ibm.com>
> ---
>
> Index: linux.trees.git/arch/powerpc/include/asm/hvcall.h
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/include/asm/hvcall.h 2009-10-19 17:59:42.000000000 +1100
> +++ linux.trees.git/arch/powerpc/include/asm/hvcall.h 2009-10-19 18:03:18.000000000 +1100
> @@ -212,6 +212,19 @@
> #define H_QUERY_INT_STATE 0x1E4
> #define H_POLL_PENDING 0x1D8
> #define H_ILLAN_ATTRIBUTES 0x244
> +#define H_MODIFY_HEA_QP 0x250
> +#define H_QUERY_HEA_QP 0x254
> +#define H_QUERY_HEA 0x258
> +#define H_QUERY_HEA_PORT 0x25C
> +#define H_MODIFY_HEA_PORT 0x260
> +#define H_REG_BCMC 0x264
> +#define H_DEREG_BCMC 0x268
> +#define H_REGISTER_HEA_RPAGES 0x26C
> +#define H_DISABLE_AND_GET_HEA 0x270
> +#define H_GET_HEA_INFO 0x274
> +#define H_ALLOC_HEA_RESOURCE 0x278
> +#define H_ADD_CONN 0x284
> +#define H_DEL_CONN 0x288
> #define H_JOIN 0x298
> #define H_VASI_STATE 0x2A4
> #define H_ENABLE_CRQ 0x2B0
> Index: linux.trees.git/drivers/net/ehea/ehea_phyp.h
> ===================================================================
> --- linux.trees.git.orig/drivers/net/ehea/ehea_phyp.h 2009-10-19 18:03:48.000000000 +1100
> +++ linux.trees.git/drivers/net/ehea/ehea_phyp.h 2009-10-19 18:03:56.000000000 +1100
> @@ -33,7 +33,6 @@
> #include <asm/hvcall.h>
> #include "ehea.h"
> #include "ehea_hw.h"
> -#include "ehea_hcall.h"
>
> /* Some abbreviations used here:
> *
> Index: linux.trees.git/drivers/net/ehea/ehea_hcall.h
> ===================================================================
> --- linux.trees.git.orig/drivers/net/ehea/ehea_hcall.h 2009-10-19 17:59:31.000000000 +1100
> +++ /dev/null 1970-01-01 00:00:00.000000000 +0000
> @@ -1,51 +0,0 @@
> -/*
> - * linux/drivers/net/ehea/ehea_hcall.h
> - *
> - * eHEA ethernet device driver for IBM eServer System p
> - *
> - * (C) Copyright IBM Corp. 2006
> - *
> - * Authors:
> - * Christoph Raisch <raisch@de.ibm.com>
> - * Jan-Bernd Themann <themann@de.ibm.com>
> - * Thomas Klein <tklein@de.ibm.com>
> - *
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2, or (at your option)
> - * any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> - */
> -
> -#ifndef __EHEA_HCALL_H__
> -#define __EHEA_HCALL_H__
> -
> -/**
> - * This file contains HCALL defines that are to be included in the appropriate
> - * kernel files later
> - */
> -
> -#define H_ALLOC_HEA_RESOURCE 0x278
> -#define H_MODIFY_HEA_QP 0x250
> -#define H_QUERY_HEA_QP 0x254
> -#define H_QUERY_HEA 0x258
> -#define H_QUERY_HEA_PORT 0x25C
> -#define H_MODIFY_HEA_PORT 0x260
> -#define H_REG_BCMC 0x264
> -#define H_DEREG_BCMC 0x268
> -#define H_REGISTER_HEA_RPAGES 0x26C
> -#define H_DISABLE_AND_GET_HEA 0x270
> -#define H_GET_HEA_INFO 0x274
> -#define H_ADD_CONN 0x284
> -#define H_DEL_CONN 0x288
> -
> -#endif /* __EHEA_HCALL_H__ */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Execute In Place (XIP) support for PPC440x5
From: Mohit Mewada @ 2009-10-22 10:10 UTC (permalink / raw)
To: linuxppc-dev, Linuxppc-embedded
Hi List,
I am trying to port a board with PPC440x5 on linux-2.6.31. My board
has 64MB of flash and 256KB of RAM. Since with this much RAM it is not
possible to copy the kernel image to RAM and boot it from there. I was
trying to figure-out option in the kernel which will allow me to
execute it from flash itself.
I refered to http://www.denx.de/wiki/publish/DULG/to-delete/ConfigureLinuxForXIP.html;
but the flags mentioned here are not present for PPC architecture. I
found these flag only for ARM architecture.
So can anyone please tell me whether it is possible to have kernel
executing from flash for PPC?
If yes, then please let me know about any patch or something that will
allow me to do this?
--
Thanks and Regards,
Mohit Mewada
^ permalink raw reply
* Query: Does Linux kernel 2.6.31 support read/write/erase on ST make M29W128GH Flash memory chip?
From: prakash bedge @ 2009-10-22 11:18 UTC (permalink / raw)
To: linuxppc-dev, Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
Hi All,
I am searching for M29W128GH support in Linux kernel 2.6.31.
On internet I am seeing that there is some patch work for fixup on write
buffer coomand on M29W128GH. This shows that Linux kernel 2.6.31 supports
the M29W128GH.
But I am not seeing any memory mapping for M29W128GH.
Can anyone please tell me that whether Linux kernel 2.6.31 support the
read/write/erase on M29W128GH? If yes how I can check that?
Which of below files I should use for communicating with ST M29W128GH flash
chip?
cfi_cmdset_0001.c
cfi_cmdset_0002.c
cfi_cmdset_0020.c -- Looks like I shall use this but not confirm.
cfi_probe.c
I am novice to flash driver in kernel so might be not getting the exact
details on M29W128GH.
Expecting a help from seniors in this field.
Thanks in advance.
Thanks & Regards,
Aakash
[-- Attachment #2: Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* How to mount rootfs though harddisk when booting?
From: wilbur.chan @ 2009-10-22 14:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: chelly wilbur
mpc85xx with sata harddisk,which has a rootfs on sda3.
I ' ve tried to use freescale's kernel image , which is togehther
with the mpc85xx board, to successfully mount the sda3 filesystem when
booting,
But when I used my own kernle, it failed:
I am using kernel 2.6.21.7 to mount the harddisk as the rootfs.
However, it failed in booting and print:
VFS: Cannot open root device "sda3" or unknown-block(0,0)
My kernel's bootargs are as followed:
root=/dev/sda3 rw console=ttyS0,115200 console=tty0
I guess there were some incorrect configs when doing kernel
menuconfig, I' ve set "ext2,ext3", and some "sata" ,"scsi" configs,
but that might be not enough.
May anyone please give me some suggestions?
THX in advance.
^ permalink raw reply
* Re: How to mount rootfs though harddisk when booting?
From: Kumar Gala @ 2009-10-22 14:22 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420910220708i63b85ca1n256f332ddc6819c1@mail.gmail.com>
On Oct 22, 2009, at 9:08 AM, wilbur.chan wrote:
> mpc85xx with sata harddisk,which has a rootfs on sda3.
>
> I ' ve tried to use freescale's kernel image , which is togehther
> with the mpc85xx board, to successfully mount the sda3 filesystem when
> booting,
>
>
> But when I used my own kernle, it failed:
>
>
>
> I am using kernel 2.6.21.7 to mount the harddisk as the rootfs.
>
> However, it failed in booting and print:
>
>
> VFS: Cannot open root device "sda3" or unknown-block(0,0)
>
> My kernel's bootargs are as followed:
>
>
> root=/dev/sda3 rw console=ttyS0,115200 console=tty0
>
>
> I guess there were some incorrect configs when doing kernel
> menuconfig, I' ve set "ext2,ext3", and some "sata" ,"scsi" configs,
>
> but that might be not enough.
>
>
> May anyone please give me some suggestions?
>
> THX in advance.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Post the full kernel boot log.
- k
^ permalink raw reply
* Re: [PATCH 3/5 v4] Export memory_sysdev_class
From: Nathan Fontenot @ 2009-10-22 15:31 UTC (permalink / raw)
To: Dave Hansen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1256141009.23737.22.camel@nimitz>
Dave Hansen wrote:
> On Wed, 2009-10-21 at 09:44 -0500, Nathan Fontenot wrote:
>> Export the memory_sysdev_class structure. This is needed so we can create
>> a 'release' file in sysfs in addition to the existing 'probe' file in
>> order to support DLPAR removal of memory on the powerpc/pseries platform.
>> The new 'release' file will be powerpc/pseries only.
>
> Please do it in generic code. You may only need it on ppc today, but
> somebody else is going to want the same thing tomorrow on another arch.
I thought about this but wasn't sure if having the probe/release sysfs files
for memory and cpu be in generic code would be accepted.
Would it be acceptable to put the new release file for memory under the
ARCH_MEMORY_PROBE config option? This would reduce the number of arch'es
that would require stubs as it appears only powerpc and x86 define this.
I could do the same thing for the cpu probe/release files and a new
ARCH_CPU_PROBE config option which would eliminate the required stubs
in arch'es other than powerpc right now.
-Nathan Fontenot
>
> It's also nice to keep all of the stuff doing the actual sysfs munging
> in one place. I know it'll cost a few stubs for calling in and out of
> arch code, but it should save some work down the road for somebody else.
>
> -- Dave
>
^ permalink raw reply
* Re: [PATCH 3/5 v4] Export memory_sysdev_class
From: Dave Hansen @ 2009-10-22 15:56 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AE07AB7.2070901@austin.ibm.com>
On Thu, 2009-10-22 at 10:31 -0500, Nathan Fontenot wrote:
> Dave Hansen wrote:
> > On Wed, 2009-10-21 at 09:44 -0500, Nathan Fontenot wrote:
> >> Export the memory_sysdev_class structure. This is needed so we can create
> >> a 'release' file in sysfs in addition to the existing 'probe' file in
> >> order to support DLPAR removal of memory on the powerpc/pseries platform.
> >> The new 'release' file will be powerpc/pseries only.
> >
> > Please do it in generic code. You may only need it on ppc today, but
> > somebody else is going to want the same thing tomorrow on another arch.
>
> I thought about this but wasn't sure if having the probe/release sysfs files
> for memory and cpu be in generic code would be accepted.
Although we don't want to pollute the generic code with lots of per-arch
cruft, this still looks pretty generic to me. It is also really nice to
have all of the sysfs files for one directory be in a single place in
the source.
> Would it be acceptable to put the new release file for memory under the
> ARCH_MEMORY_PROBE config option?
That sounds fine to me. It may need a slightly tuned name if you can
think of anything better. I can't off the top of my head.
x86's is really only there for testing reasons. I would use mem= to
shrink a machine's memory at boot then use the probe file to re-add it
later. I did that before I had hardware that could do real hotplug.
> This would reduce the number of arch'es
> that would require stubs as it appears only powerpc and x86 define this.
Yeah, that'd be a nice side-effect I guess.
-- Dave
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Scott Wood @ 2009-10-22 16:07 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4AE015DD.1010009@embedded-sol.com>
Felix Radensky wrote:
> Are you aware of Freescale plans to fix the problem in new silicon
> revisions ?
I don't know anything yet -- still trying to get in touch with the
relevant hardware people.
> Also, can you please tell what CPUs are affected by this, except 8536
> and 8572.
I suppose anything with an eLBC could be affected.
-Scott
^ permalink raw reply
* RE: Device Tree Corrupted after unflatten_device_tree()
From: Lixin Yao @ 2009-10-22 18:14 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20091021221033.GB12560@yookeroo.seuss>
Hi, David/Michael,
Great great finding! I added halting FEC (the Ethernet controller in
MPC866)=20
in platforms_fixups() and the problem disappears.
Thank you very much!
Lixin
-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]=20
Sent: Wednesday, October 21, 2009 6:11 PM
To: Lixin Yao
Cc: michael@ellerman.id.au; linuxppc-dev@lists.ozlabs.org
Subject: Re: Device Tree Corrupted after unflatten_device_tree()
On Wed, Oct 21, 2009 at 10:43:55AM -0700, Lixin Yao wrote:
> When corrupted, curtain blocks of 64 bytes are messed up.
> This is a screen dump of a good unflattened device at beginning:
[snip]
> When corrupted, it becomes following, note the 64 bock at 0x03ffdf00
> is messed up. And this kind of corruptions occur several times
[snip]
> 03ffdf00 : ffffffff ffff000c db055be0 08060001 ..........[.....
> 03ffdf10 : 08000604 0001000c db055be0 ac141001 ..........[.....
> 03ffdf20 : 00000000 0000ac14 10530000 10530000 .........S...S..
> 03ffdf30 : 08000604 0001000c 36681bfe f874c01e ........6h...t..
Uh, oh. That looks like a broadcast ethernet packet (ARP,
specifically). Looks like a network device used by the firmware
hasn't been quiesced properly before booting the kernel and is DMAing
stuff straight on top of kernel memory. You'll probably need a hook
in the bootwrapper to shut down the ethernet.
There are some examples of this in arch/powerpc/boot already - look
for ibm4xx_quiesce_eth().
--=20
David Gibson | I'll have my music baroque, and my
code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_
_other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 2/2][v5] powerpc: Make the CMM memory hotplug aware
From: Robert Jennings @ 2009-10-22 18:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Andrew Morton, Mel Gorman, Ingo Molnar,
Badari Pulavarty, Brian King, Robert Jennings, Paul Mackerras,
Martin Schwidefsky, Gerald Schaefer, linux-kernel, linux-mm,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <20091012194907.GC30941@austin.ibm.com>
The Collaborative Memory Manager (CMM) module allocates individual pages
over time that are not migratable. On a long running system this can
severely impact the ability to find enough pages to support a hotplug
memory remove operation.
This patch adds a memory isolation notifier and a memory hotplug notifier.
The memory isolation notifier will return the number of pages found
in the range specified. This is used to determine if all of the used
pages in a pageblock are owned by the balloon (or other entities in
the notifier chain). The hotplug notifier will free pages in the range
which is to be removed. The priority of this hotplug notifier is low
so that it will be called near last, this helps avoids removing loaned
pages in operations that fail due to other handlers.
CMM activity will be halted when hotplug remove operations are active
and resume activity after a delay period to allow the hypervisor time
to adjust.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
Changes since v4:
* The structures for recording loaned pages are not allocated as MOVABLE
* The structures for recording loaned pages are removed from sections
being taken offline by moving their contents to a newly allocated page.
Changes since v3:
* Changed from atomic to mutex for hotplug state tracking.
* Clarified documentation for the new module parameter description.
Changes since v2:
* None, resent with parent patch to keep them together.
arch/powerpc/platforms/pseries/cmm.c | 254 ++++++++++++++++++++++++++++++++++-
1 file changed, 248 insertions(+), 6 deletions(-)
Index: b/arch/powerpc/platforms/pseries/cmm.c
===================================================================
--- a/arch/powerpc/platforms/pseries/cmm.c
+++ b/arch/powerpc/platforms/pseries/cmm.c
@@ -38,19 +38,28 @@
#include <asm/mmu.h>
#include <asm/pgalloc.h>
#include <asm/uaccess.h>
+#include <linux/memory.h>
#include "plpar_wrappers.h"
#define CMM_DRIVER_VERSION "1.0.0"
#define CMM_DEFAULT_DELAY 1
+#define CMM_HOTPLUG_DELAY 5
#define CMM_DEBUG 0
#define CMM_DISABLE 0
#define CMM_OOM_KB 1024
#define CMM_MIN_MEM_MB 256
#define KB2PAGES(_p) ((_p)>>(PAGE_SHIFT-10))
#define PAGES2KB(_p) ((_p)<<(PAGE_SHIFT-10))
+/*
+ * The priority level tries to ensure that this notifier is called as
+ * late as possible to reduce thrashing in the shared memory pool.
+ */
+#define CMM_MEM_HOTPLUG_PRI 1
+#define CMM_MEM_ISOLATE_PRI 15
static unsigned int delay = CMM_DEFAULT_DELAY;
+static unsigned int hotplug_delay = CMM_HOTPLUG_DELAY;
static unsigned int oom_kb = CMM_OOM_KB;
static unsigned int cmm_debug = CMM_DEBUG;
static unsigned int cmm_disabled = CMM_DISABLE;
@@ -65,6 +74,10 @@ MODULE_VERSION(CMM_DRIVER_VERSION);
module_param_named(delay, delay, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(delay, "Delay (in seconds) between polls to query hypervisor paging requests. "
"[Default=" __stringify(CMM_DEFAULT_DELAY) "]");
+module_param_named(hotplug_delay, hotplug_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(delay, "Delay (in seconds) after memory hotplug remove "
+ "before loaning resumes. "
+ "[Default=" __stringify(CMM_HOTPLUG_DELAY) "]");
module_param_named(oom_kb, oom_kb, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(oom_kb, "Amount of memory in kb to free on OOM. "
"[Default=" __stringify(CMM_OOM_KB) "]");
@@ -92,6 +105,9 @@ static unsigned long oom_freed_pages;
static struct cmm_page_array *cmm_page_list;
static DEFINE_SPINLOCK(cmm_lock);
+static DEFINE_MUTEX(hotplug_mutex);
+static int hotplug_occurred; /* protected by the hotplug mutex */
+
static struct task_struct *cmm_thread_ptr;
/**
@@ -110,6 +126,17 @@ static long cmm_alloc_pages(long nr)
cmm_dbg("Begin request for %ld pages\n", nr);
while (nr) {
+ /* Exit if a hotplug operation is in progress or occurred */
+ if (mutex_trylock(&hotplug_mutex)) {
+ if (hotplug_occurred) {
+ mutex_unlock(&hotplug_mutex);
+ break;
+ }
+ mutex_unlock(&hotplug_mutex);
+ } else {
+ break;
+ }
+
addr = __get_free_page(GFP_NOIO | __GFP_NOWARN |
__GFP_NORETRY | __GFP_NOMEMALLOC);
if (!addr)
@@ -119,8 +146,9 @@ static long cmm_alloc_pages(long nr)
if (!pa || pa->index >= CMM_NR_PAGES) {
/* Need a new page for the page list. */
spin_unlock(&cmm_lock);
- npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO | __GFP_NOWARN |
- __GFP_NORETRY | __GFP_NOMEMALLOC);
+ npa = (struct cmm_page_array *)__get_free_page(
+ GFP_NOIO | __GFP_NOWARN |
+ __GFP_NORETRY | __GFP_NOMEMALLOC);
if (!npa) {
pr_info("%s: Can not allocate new page list\n", __func__);
free_page(addr);
@@ -273,9 +301,28 @@ static int cmm_thread(void *dummy)
while (1) {
timeleft = msleep_interruptible(delay * 1000);
- if (kthread_should_stop() || timeleft) {
- loaned_pages_target = loaned_pages;
+ if (kthread_should_stop() || timeleft)
break;
+
+ if (mutex_trylock(&hotplug_mutex)) {
+ if (hotplug_occurred) {
+ hotplug_occurred = 0;
+ mutex_unlock(&hotplug_mutex);
+ cmm_dbg("Hotplug operation has occurred, "
+ "loaning activity suspended "
+ "for %d seconds.\n",
+ hotplug_delay);
+ timeleft = msleep_interruptible(hotplug_delay *
+ 1000);
+ if (kthread_should_stop() || timeleft)
+ break;
+ continue;
+ }
+ mutex_unlock(&hotplug_mutex);
+ } else {
+ cmm_dbg("Hotplug operation in progress, activity "
+ "suspended\n");
+ continue;
}
cmm_get_mpp();
@@ -405,6 +452,193 @@ static struct notifier_block cmm_reboot_
};
/**
+ * cmm_count_pages - Count the number of pages loaned in a particular range.
+ *
+ * @arg: memory_isolate_notify structure with address range and count
+ *
+ * Return value:
+ * 0 on success
+ **/
+static unsigned long cmm_count_pages(void *arg)
+{
+ struct memory_isolate_notify *marg = arg;
+ struct cmm_page_array *pa;
+ unsigned long start = (unsigned long)pfn_to_kaddr(marg->start_pfn);
+ unsigned long end = start + (marg->nr_pages << PAGE_SHIFT);
+ unsigned long idx;
+
+ spin_lock(&cmm_lock);
+ pa = cmm_page_list;
+ while (pa) {
+ if ((unsigned long)pa >= start && (unsigned long)pa < end)
+ marg->pages_found++;
+ for (idx = 0; idx < pa->index; idx++)
+ if (pa->page[idx] >= start && pa->page[idx] < end)
+ marg->pages_found++;
+ pa = pa->next;
+ }
+ spin_unlock(&cmm_lock);
+ return 0;
+}
+
+/**
+ * cmm_memory_isolate_cb - Handle memory isolation notifier calls
+ * @self: notifier block struct
+ * @action: action to take
+ * @arg: struct memory_isolate_notify data for handler
+ *
+ * Return value:
+ * NOTIFY_OK or notifier error based on subfunction return value
+ **/
+static int cmm_memory_isolate_cb(struct notifier_block *self,
+ unsigned long action, void *arg)
+{
+ int ret = 0;
+
+ if (action == MEM_ISOLATE_COUNT)
+ ret = cmm_count_pages(arg);
+
+ if (ret)
+ ret = notifier_from_errno(ret);
+ else
+ ret = NOTIFY_OK;
+
+ return ret;
+}
+
+static struct notifier_block cmm_mem_isolate_nb = {
+ .notifier_call = cmm_memory_isolate_cb,
+ .priority = CMM_MEM_ISOLATE_PRI
+};
+
+/**
+ * cmm_mem_going_offline - Unloan pages where memory is to be removed
+ * @arg: memory_notify structure with page range to be offlined
+ *
+ * Return value:
+ * 0 on success
+ **/
+static int cmm_mem_going_offline(void *arg)
+{
+ struct memory_notify *marg = arg;
+ unsigned long start_page = (unsigned long)pfn_to_kaddr(marg->start_pfn);
+ unsigned long end_page = start_page + (marg->nr_pages << PAGE_SHIFT);
+ struct cmm_page_array *pa_curr, *pa_last, *npa;
+ unsigned long idx;
+ unsigned long freed = 0;
+
+ cmm_dbg("Memory going offline, searching 0x%lx (%ld pages).\n",
+ start_page, marg->nr_pages);
+ spin_lock(&cmm_lock);
+
+ /* Search the page list for pages in the range to be offlined */
+ pa_last = pa_curr = cmm_page_list;
+ while (pa_curr) {
+ for (idx = (pa_curr->index - 1); (idx + 1) > 0; idx--) {
+ if ((pa_curr->page[idx] < start_page) ||
+ (pa_curr->page[idx] >= end_page))
+ continue;
+
+ plpar_page_set_active(__pa(pa_curr->page[idx]));
+ free_page(pa_curr->page[idx]);
+ freed++;
+ loaned_pages--;
+ totalram_pages++;
+ pa_curr->page[idx] = pa_last->page[--pa_last->index];
+ if (pa_last->index == 0) {
+ if (pa_curr == pa_last)
+ pa_curr = pa_last->next;
+ pa_last = pa_last->next;
+ free_page((unsigned long)cmm_page_list);
+ cmm_page_list = pa_last;
+ continue;
+ }
+ }
+ pa_curr = pa_curr->next;
+ }
+
+ /* Search for page list structures in the range to be offlined */
+ pa_last = NULL;
+ pa_curr = cmm_page_list;
+ while (pa_curr) {
+ if (((unsigned long)pa_curr >= start_page) &&
+ ((unsigned long)pa_curr < end_page)) {
+ npa = (struct cmm_page_array *)__get_free_page(
+ GFP_NOIO | __GFP_NOWARN |
+ __GFP_NORETRY | __GFP_NOMEMALLOC);
+ if (!npa) {
+ spin_unlock(&cmm_lock);
+ cmm_dbg("Failed to allocate memory for list "
+ "management. Memory hotplug "
+ "failed.\n");
+ return ENOMEM;
+ }
+ memcpy(npa, pa_curr, PAGE_SIZE);
+ if (pa_curr == cmm_page_list)
+ cmm_page_list = npa;
+ if (pa_last)
+ pa_last->next = npa;
+ free_page((unsigned long) pa_curr);
+ freed++;
+ pa_curr = npa;
+ }
+
+ pa_last = pa_curr;
+ pa_curr = pa_curr->next;
+ }
+
+ spin_unlock(&cmm_lock);
+ cmm_dbg("Released %ld pages in the search range.\n", freed);
+
+ return 0;
+}
+
+/**
+ * cmm_memory_cb - Handle memory hotplug notifier calls
+ * @self: notifier block struct
+ * @action: action to take
+ * @arg: struct memory_notify data for handler
+ *
+ * Return value:
+ * NOTIFY_OK or notifier error based on subfunction return value
+ *
+ **/
+static int cmm_memory_cb(struct notifier_block *self,
+ unsigned long action, void *arg)
+{
+ int ret = 0;
+
+ switch (action) {
+ case MEM_GOING_OFFLINE:
+ mutex_lock(&hotplug_mutex);
+ hotplug_occurred = 1;
+ ret = cmm_mem_going_offline(arg);
+ break;
+ case MEM_OFFLINE:
+ case MEM_CANCEL_OFFLINE:
+ mutex_unlock(&hotplug_mutex);
+ cmm_dbg("Memory offline operation complete.\n");
+ break;
+ case MEM_GOING_ONLINE:
+ case MEM_ONLINE:
+ case MEM_CANCEL_ONLINE:
+ break;
+ }
+
+ if (ret)
+ ret = notifier_from_errno(ret);
+ else
+ ret = NOTIFY_OK;
+
+ return ret;
+}
+
+static struct notifier_block cmm_mem_nb = {
+ .notifier_call = cmm_memory_cb,
+ .priority = CMM_MEM_HOTPLUG_PRI
+};
+
+/**
* cmm_init - Module initialization
*
* Return value:
@@ -426,18 +660,24 @@ static int cmm_init(void)
if ((rc = cmm_sysfs_register(&cmm_sysdev)))
goto out_reboot_notifier;
+ if (register_memory_notifier(&cmm_mem_nb) ||
+ register_memory_isolate_notifier(&cmm_mem_isolate_nb))
+ goto out_unregister_notifier;
+
if (cmm_disabled)
return rc;
cmm_thread_ptr = kthread_run(cmm_thread, NULL, "cmmthread");
if (IS_ERR(cmm_thread_ptr)) {
rc = PTR_ERR(cmm_thread_ptr);
- goto out_unregister_sysfs;
+ goto out_unregister_notifier;
}
return rc;
-out_unregister_sysfs:
+out_unregister_notifier:
+ unregister_memory_notifier(&cmm_mem_nb);
+ unregister_memory_isolate_notifier(&cmm_mem_isolate_nb);
cmm_unregister_sysfs(&cmm_sysdev);
out_reboot_notifier:
unregister_reboot_notifier(&cmm_reboot_nb);
@@ -458,6 +698,8 @@ static void cmm_exit(void)
kthread_stop(cmm_thread_ptr);
unregister_oom_notifier(&cmm_oom_nb);
unregister_reboot_notifier(&cmm_reboot_nb);
+ unregister_memory_notifier(&cmm_mem_nb);
+ unregister_memory_isolate_notifier(&cmm_mem_isolate_nb);
cmm_free_pages(loaned_pages);
cmm_unregister_sysfs(&cmm_sysdev);
}
^ permalink raw reply
* Page map BUG on program exit
From: Jonathan Haws @ 2009-10-22 20:57 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I am using a 405EX CPU on a custom board. The layout and hardware is very =
similar to the AMCC Kilauea board. Here is the output of uname -a:
Linux (none) 2.6.30.3-wolverine-dirty #3 PREEMPT Thu Sep 10 11:41:37 MDT 20=
09 ppc unknown
I am getting the following BUG output when my program exits:
BUG: Bad page map in process main pte:980005d7 pmd:0d840400
addr:48000000 vm_flags:400844fb anon_vma:(null) mapping:cd8454f8 index:9800=
0
vma->vm_file->f_op->mmap: fpga_mmap+0x0/0x178 [fpgaDriver]
Call Trace:
[cd84dc40] [c0006f0c] show_stack+0x44/0x16c (unreliable)
[cd84dc80] [c00ba314] print_bad_pte+0x140/0x1d0
[cd84dcb0] [c00ba3ec] vm_normal_page+0x48/0x50
[cd84dcc0] [c00bb2ec] unmap_vmas+0x214/0x614
[cd84dd40] [c00bffe0] exit_mmap+0xd0/0x1b4
[cd84dd70] [c0031e40] mmput+0x50/0x134
[cd84dd80] [c0036470] exit_mm+0x114/0x13c
[cd84ddb0] [c0037d80] do_exit+0xc0/0x68c
[cd84de00] [c0038390] do_group_exit+0x44/0xd8
[cd84de10] [c0044468] get_signal_to_deliver+0x1f8/0x430
[cd84de70] [c0008224] do_signal+0x54/0x29c
[cd84df40] [c0010d5c] do_user_signal+0x74/0xc4
I have an FPGA on the PCIe bus that I am mapping BAR0 to user space with a =
call to mmap(). The mapping works just fine and I can access all the regis=
ters in the BAR without a problem. However, on exit this comes up.
A Google search showed tons of people with similar problems in standard dis=
tributions (Ubuntu primarily), but no resolutions.
Has anyone seen this crop up before and know what the issue is? I include =
any source code, if that is required.
Thanks!
Jonathan
^ permalink raw reply
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases
From: Hollis Blanchard @ 2009-10-22 21:04 UTC (permalink / raw)
To: Rusty Russell
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <200910201415.34361.rusty@rustcorp.com.au>
On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote:
> BUILD_BUG_ON used to use the optimizer to do code elimination or fail
> at link time; it was changed to first the size of a negative array (a
> nicer compile time error), then (in
> 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>
> bitfields: needs a literal constant at parse time, and can't be put under
> "if (__builtin_constant_p(x))" for example.
> negative array: can handle anything, but if the compiler can't tell it's
> a constant, silently has no effect.
> link time: breaks link if the compiler can't determine the value, but the
> linker output is not usually as informative as a compiler error.
>
> If we use the negative-array-size method *and* the link time trick,
> we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
> branches, and maximal ability for the compiler to detect errors at
> build time.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks Rusty, this indeed fixes the problem.
Acked-by: Hollis Blanchard <hollisb@us.ibm.com>
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Guarded load and bus error
From: Micha Nelissen @ 2009-10-22 20:40 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm working on a MPC8548 processor, using its RapidIO bus. I have two
kernel trees ported for a board, a linux 2.6.24-ppc, and a linux-2.6.31
(powerpc) kernel. I don't think this bus behaviour is RapidIO specific
though, as also the PCI bus and local bus must handle malfunctioning
devices. The HID1[RFXE] bit is enabled.
To test bus error behaviour, I'm doing reads from mapped (RapidIO) I/O
memory (mapped cache-inhibited, guarded). 32 bit aligned accesses are
working fine, so the setup is good. A RapidIO error handler is installed
(error/port-write interrupt) which printks some error bits from the
RapidIO error registers and resets them. Now I'm provoking bus errors by:
1) reading from a RapidIO device that does not exist: a timeout is asserted
2) reading from an unaligned address
The MPC8548ERM mentions that interrupt latency is indeterminate for
guarded loads. From this I conclude that the processor stalls until it
receives data from the bus: it is not interruptable (machine check,
interrupts or critical interrupts). However the following behaviour is seen:
Linux 2.6.24 ppc:
For 1) my application gets a SIGBUS, after this, the error interrupt is
run reporting a packet timeout: good.
For 2) the kernel OOPSes while running do_IRQ, getting irq number. The
kernel is not interrupt mode though: my application is killed and I may
continue.
Linux 2.6.31 powerpc:
For 1) first some interrupt runs (apparantly), the machine check handler
prints a stack trace showing do_IRQ and retrieving the irq number. The
kernel in this instance detects it's running an interrupt and panic's
and resets immediately.
For 2) things are even worse ;-).
The case 1) may be "solved" by disabling my own RapidIO error interrupt
handling (I think that's the IRQ about to be executed, but the kernel
hasn't gotten far enough to read the proper registers to tell me). If
the error interrupt is disabled, then the application is killed.
Behaviour seems proper; except I can't print my (diagnostic) errors.
With this "fix" though, the case 2) proceeds as follows: the kernel
OOPSes in the machine check handler with the stack trace showing it's
executing instructions in the softirq handler. The softirq process is
killed (I assume). After this my application may continue, and I think
it retries the I/O read because (after timeout) the machine check OOPSes
again, this time showing a timer interrupt in progress (which is trying
to wake the softirq process), thereby panic'ing and resetting the board.
If I "mangle" the machine check handler to print RapidIO error registers
and return immediately always, then the behaviour is that I keep getting
machine checks printing 'packet timeout' and/or 'illegal field in
packet' ... apparantly the I/O operation is retried again and again. Not
particularly nice for a so called "guarded load".
To verify the "guarded load" being really guarded, I set the timeout to
maximum (~5 seconds), and tried to read from a non-existing device.
Under these circumstances, the board is not pingable anymore, and telnet
sessions to it are dead. These come back to life when the timeout has
passed and a SIGBUS has killed the test application.
So, the guarded load does really seem to block external interrupts (at
least timer and ethernet), but on the other hand I'm seeing inconsistent
stack traces during the machine check handling (as the last instruction
was in user space, I shouldn't be seeing stack traces down the kernel,
softirq or where else).
The HID0 and HID1 registers are equal in the two kernels (except the
2.6.31 sets DOZE mode, but disabling that had no effect).
How is it possible that behaviour differs between these two kernels?
How can I get my desired behaviour that my application is killed with a
SIGBUS, and the rest of the kernel keeps running properly?
Thanks in advance for any insight,
Micha Nelissen
^ permalink raw reply
* i2c/janitoral: drop NO_IRQ from the subsystem
From: Wolfram Sang @ 2009-10-22 21:11 UTC (permalink / raw)
To: linux-i2c; +Cc: linuxppc-dev
Hello,
after having to deal with NO_IRQ confusion more than once, I decided to start a
bit of janitorial work and remove it from the i2c-subsystem. Detail for better
using 0 as "no irq" can be found here: http://lkml.org/lkml/2005/11/21/221
Regards,
Wolfram
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox