* Re: jffs2 file system on MPC8272ADS
From: Nethra @ 2007-10-03 4:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBD7FE.6050500@freescale.com>
Scott,
>Most common is making a jffs2 filesystem with the wrong block size. It
>could also be an incorrect flash mapping.
In our case erase block size and flash mapping seems to be correct.
> Was it the physmap driver or the pq2fads driver that found the flash?
>
> Flash is cfi compatible.
>>That's not what I meant... you have two mapping drivers enabled, and
>>the pq2fads driver might be doing something other that what you
>>specified to physmap. I'd just disable it.
I think if flash is cfi compatible then it uses default driver.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/jffs2-file-system-on-MPC8272ADS-tf4513571.html#a13012850
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Use cache-inhibited large page bit from firmware
From: Paul Mackerras @ 2007-10-03 4:41 UTC (permalink / raw)
To: linuxppc-dev
Discussions with firmware architects have confirmed that the bit in
the ibm,pa-features property that indicates support for
cache-inhibited large (>= 64kB) page mappings does in fact mean that
the hypervisor allows 64kB mappings to I/O devices.
Thus we can now enable the code that tests that bit and sets our
CPU_FTR_CI_LARGE_PAGE feature bit.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 172dcc3..9f329a8 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -531,10 +531,7 @@ static struct ibm_pa_feature {
{CPU_FTR_CTRL, 0, 0, 3, 0},
{CPU_FTR_NOEXECUTE, 0, 0, 6, 0},
{CPU_FTR_NODSISRALIGN, 0, 1, 1, 1},
-#if 0
- /* put this back once we know how to test if firmware does 64k IO */
{CPU_FTR_CI_LARGE_PAGE, 0, 1, 2, 0},
-#endif
{CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
};
^ permalink raw reply related
* Re: [PATCH v3 2/4] Implement generic time of day clocksource for powerpc machines.
From: Thomas Gleixner @ 2007-10-03 4:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, John Stultz, Realtime Kernel, Stephen Rothwell
In-Reply-To: <18178.59123.511480.956928@cargo.ozlabs.ibm.com>
On Wed, 3 Oct 2007, Paul Mackerras wrote:
> Tony Breeds writes:
>
> > @@ -982,6 +906,10 @@ void __init time_init(void)
> >
> > write_sequnlock_irqrestore(&xtime_lock, flags);
> >
> > + /* Register the clocksource, if we're not running on iSeries */
> > + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> > + clocksource_init();
>
> This breaks the 32-bit compile.
>
> Is it possible to adjust the frequency of a clocksource after it has
> been registered? Or could the timebase clocksource be unregistered
> and reregistered in iSeries_tb_recal?
There is no unregister interface right now. But we need some mechanism to
tell the core code that you changed it. I have a look if John does not
beat me.
tglx
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Benjamin Herrenschmidt @ 2007-10-03 4:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710022118r170ab652mdd65c216304b3330@mail.gmail.com>
On Tue, 2007-10-02 at 22:18 -0600, Grant Likely wrote:
> For many drivers, I think that is already the case. USB OHCI is a
> prime example where there are both PCI and platform_bus bindings among
> others. It seems to me that the bus binding effectively translates
> down to "where do I go to get the needed information". I think it
> results in less of a maintenance burden to explicitly separate bus
> binding from device setup as opposed to adding constructor code.
I think nobody consider the mess that is USB in that are to be something
we want to reproduce.
> > The important thing however, with the constructor approach is to try as
> > much as possible to keep the proper tree structure, and thus, try to
> > find a way to instanciate the devices with proper parent/child
> > relationship so that ordering for things like suspend/resume operations
> > is maintained.
>
> I'm not sure I follow. Example?
Well, make sure that if 2 platform devices repreesnt respectively a bus
and a device on that bus, they properly get instanciated as parent &
child in sysfs as well.
Ben.
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Grant Likely @ 2007-10-03 4:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191365012.22572.33.camel@pasglop>
On 10/2/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > My opinion is that since it is driver-specific code anyway, then it
> > belongs with the driver. Plus a driver writer for ARM doesn't need to
> > write them. It's the powerpc or microblaze developer who will do it.
> > If the driver maintainer doesn't want the binding in the main driver
> > .c file, then the binding can easily be in an additional .c file
> > without needing to add a constructor. (Kind of like how many USB host
> > controllers are managed)
>
> The main advantage is that it keeps the OF specific code localized to a
> single function, whether that function lives in the driver or the arch
> code, it makes it self contained and easier to deal with by the driver
> author.
>
> Having multiple device types on which the driver can attach is a pain
> from a driver standpoint. It needs multiple
> probe/remove/suspend/resume/shutdown hooks etc... it's a bigger
> maintainance burden in the long run.
For many drivers, I think that is already the case. USB OHCI is a
prime example where there are both PCI and platform_bus bindings among
others. It seems to me that the bus binding effectively translates
down to "where do I go to get the needed information". I think it
results in less of a maintenance burden to explicitly separate bus
binding from device setup as opposed to adding constructor code.
> The important thing however, with the constructor approach is to try as
> much as possible to keep the proper tree structure, and thus, try to
> find a way to instanciate the devices with proper parent/child
> relationship so that ordering for things like suspend/resume operations
> is maintained.
I'm not sure I follow. Example?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Michael Ellerman @ 2007-10-03 4:09 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003011909.GG9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
On Wed, 2007-10-03 at 11:19 +1000, Tony Breeds wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
Better .. but .. :D
> diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
> index 30925d2..73401c8 100644
> --- a/arch/powerpc/platforms/pseries/rtasd.c
> +++ b/arch/powerpc/platforms/pseries/rtasd.c
> @@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
> static int full_rtas_msgs = 0;
>
> /* Stop logging to nvram after first fatal error */
> -static int no_more_logging;
> -
> +static int logging_enabled; /* Until we initialize everything,
> + * make sure we don't try logging
> + * anything */
Until we initialise what exactly?
> static int error_log_cnt;
>
> /*
> @@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
> }
>
> /* Write error to NVRAM */
> - if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
> + if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
> nvram_write_error_log(buf, len, err_type, error_log_cnt);
>
> /*
> @@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
> printk_log_rtas(buf, len);
>
> /* Check to see if we need to or have stopped logging */
> - if (fatal || no_more_logging) {
> - no_more_logging = 1;
> + if (fatal || !logging_enabled) {
> + logging_enabled = 0;
> spin_unlock_irqrestore(&rtasd_log_lock, s);
> return;
> }
Hmmm, this routine has 4 separate lock-dropping exit paths ..
> @@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
>
> spin_lock_irqsave(&rtasd_log_lock, s);
> /* if it's 0, then we know we got the last one (the one in NVRAM) */
> - if (rtas_log_size == 0 && !no_more_logging)
> + if (rtas_log_size == 0 && logging_enabled)
> nvram_clear_error_log();
> spin_unlock_irqrestore(&rtasd_log_lock, s);
>
> @@ -414,6 +415,8 @@ static int rtasd(void *unused)
> memset(logdata, 0, rtas_error_log_max);
> rc = nvram_read_error_log(logdata, rtas_error_log_max,
> &err_type, &error_log_cnt);
> + /* We can use rtas_log_buf now */
> + logging_enabled = 1;
>
> if (!rc) {
> if (err_type != ERR_FLAG_ALREADY_LOGGED) {
What exactly happens that allows us to do logging? I don't see any
ordering between anything else and the setting of the flag, and AFAICT
we're not inside a spinlock or anything here.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Olof Johansson @ 2007-10-03 3:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <18179.1934.821688.836972@cargo.ozlabs.ibm.com>
On Wed, Oct 03, 2007 at 01:07:58PM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > > This makes the kernel use 1TB segments for all kernel mappings and for
> > > user addresses of 1TB and above, on machines which support them
> > > (currently POWER5+ and POWER6).
> >
> > PA6T supports them as well :)
>
> In the patch, we don't actually hard-code the CPU_FTR_1T_SEGMENT bit
> in the cputable entry for any processor; instead we look in the
> ibm,processor-segment-sizes property in the cpu node(s) in the device
> tree.
Yep, I see that. I just wanted to clarify it for the (future) commit
message.
> Do you want us to add the CPU_FTR_1T_SEGMENT bit to the
> cputable entry for the PA6T, or will your firmware gives the
> ibm,processor-segment-sizes property in the device tree?
Thanks, but we've already got the properties there so it just works.
> > Wouldn't it be possible to stick with 1TB segments for the low range
> > for 64-bit processes as well, and have them allocate their hugepages
> > at >1TB?
>
> You mean, forbid hugepages below 1TB? That would be a user-visible
> ABI change. There are linker scripts for generating executables whose
> text and/or data can go in hugepages, and I believe they put the
> text/data below 1TB.
Hm, good point. Bummer.
-Olof
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Paul Mackerras @ 2007-10-03 3:13 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev, Jon Tollefson
In-Reply-To: <1191350274.18159.279.camel@farscape.rchland.ibm.com>
Will Schmidt writes:
> I still need to test this code for performance issues, and this version
> could still use some cosmetic touchups, so I dont think we want this to
> go into a tree yet. I am reposting this primarily to indicate the prior
> version isnt quite right, and so Jon can rebase to this version. :-)
The way we scan the ibm,processor-segment-sizes property could be
nicer. Where there any other cosmetic touchups you were thinking of,
and if so what were they? I didn't notice any leftover debugging
printks or anything else that obviously needed cleaning up.
Paul.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Paul Mackerras @ 2007-10-03 3:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <20071003021105.GA6553@lixom.net>
Olof Johansson writes:
> > This makes the kernel use 1TB segments for all kernel mappings and for
> > user addresses of 1TB and above, on machines which support them
> > (currently POWER5+ and POWER6).
>
> PA6T supports them as well :)
In the patch, we don't actually hard-code the CPU_FTR_1T_SEGMENT bit
in the cputable entry for any processor; instead we look in the
ibm,processor-segment-sizes property in the cpu node(s) in the device
tree. Do you want us to add the CPU_FTR_1T_SEGMENT bit to the
cputable entry for the PA6T, or will your firmware gives the
ibm,processor-segment-sizes property in the device tree?
> Wouldn't it be possible to stick with 1TB segments for the low range
> for 64-bit processes as well, and have them allocate their hugepages
> at >1TB?
You mean, forbid hugepages below 1TB? That would be a user-visible
ABI change. There are linker scripts for generating executables whose
text and/or data can go in hugepages, and I believe they put the
text/data below 1TB.
Paul.
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Paul Mackerras @ 2007-10-03 2:51 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Klein, Arnd Bergmann, Jan-Bernd Themann, Paul Mackerras,
LKML, LinuxPPC-Dev, Christoph Raisch, Stefan Roscher
In-Reply-To: <200709261145.51926.fenkes@de.ibm.com>
Joachim Fenkes writes:
> Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
> and struct of_platform_driver, respectively. Match the external ibmebus
> interface and drivers using it.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> drivers/infiniband/hw/ehca/ehca_classes.h | 2 +-
> drivers/net/ehea/ehea.h | 2 +-
> include/asm-powerpc/ibmebus.h | 38 +++------------
> arch/powerpc/kernel/ibmebus.c | 28 ++++++-----
> drivers/infiniband/hw/ehca/ehca_eq.c | 6 +-
> drivers/infiniband/hw/ehca/ehca_main.c | 32 ++++++------
> drivers/net/ehea/ehea_main.c | 72 ++++++++++++++--------------
This is somewhat difficult as this patch touches files that are the
responsibility of three different maintainers. Is it possible to
split the patch into three, one for each maintainer (possibly by
keeping both old and new interfaces around for a little while)?
If not, then you need to get an Acked-by and an agreement that this
change can go via the powerpc.git tree from Roland Dreier and Jeff
Garzik.
Paul.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Olof Johansson @ 2007-10-03 2:11 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, Jon Tollefson, Paul Mackerras
In-Reply-To: <1191350274.18159.279.camel@farscape.rchland.ibm.com>
Hi,
On Tue, Oct 02, 2007 at 01:37:54PM -0500, Will Schmidt wrote:
> [RFC v2] 1TB Segment size support
>
> From: <>
>
> 1TB Segment size support
>
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6).
PA6T supports them as well :)
> We don't currently use 1TB segments
> for user addresses < 1T, since that would effectively prevent 32-bit
> processes from using huge pages unless we also had a way to revert to
> using 256MB segments.
Wouldn't it be possible to stick with 1TB segments for the low range
for 64-bit processes as well, and have them allocate their hugepages
at >1TB?
-Olof
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: KAMEZAWA Hiroyuki @ 2007-10-03 1:19 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <1191366653.6106.68.camel@dyn9047017100.beaverton.ibm.com>
On Tue, 02 Oct 2007 16:10:53 -0700
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > > code to be able to do this.
> >
> > Isn't it just a matter of abstracting the test for a valid range of
> > memory? If it's really hard to abstract that, then I guess we can put
> > RAM in iomem_resource, but I'd rather not.
> >
>
> Sure. I will work on it and see how ugly it looks.
>
> KAME, are you okay with abstracting the find_next_system_ram() and
> let arch provide whatever implementation they want ? (since current
> code doesn't work for x86-64 also ?).
>
Hmm, registering /proc/iomem is complicated ? If too complicated, adding config
like
CONFIG_ARCH_SUPPORT_IORESOURCE_RAM or something can do good work.
you can define your own "check_pages_isolated" (you can rename this to
arch_check_apges_isolated().)
BTW, I shoudl ask people how to describe conventional memory
A. #define IORESOURCE_RAM IORESOURCE_MEM (ia64)
B. #define IORESOURCE_RAM IORESOURCE_MEM | IORESOUCE_BUSY (i386, x86_64)
Sad to say, memory hot-add registers new memory just as IORESOURCE_MEM.
Thanks,
-Kame
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Tony Breeds @ 2007-10-03 1:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <1191371416.8073.1.camel@concordia>
On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
> I realise it'll make the patch bigger, but this doesn't seem like a
> particularly good name for the variable anymore.
Sure, what about?
Clarify when RTAS logging is enabled.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/rtasd.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..73401c8 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
-
+static int logging_enabled; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
static int error_log_cnt;
/*
@@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
}
/* Write error to NVRAM */
- if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
+ if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
nvram_write_error_log(buf, len, err_type, error_log_cnt);
/*
@@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
printk_log_rtas(buf, len);
/* Check to see if we need to or have stopped logging */
- if (fatal || no_more_logging) {
- no_more_logging = 1;
+ if (fatal || !logging_enabled) {
+ logging_enabled = 0;
spin_unlock_irqrestore(&rtasd_log_lock, s);
return;
}
@@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
spin_lock_irqsave(&rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 && !no_more_logging)
+ if (rtas_log_size == 0 && logging_enabled)
nvram_clear_error_log();
spin_unlock_irqrestore(&rtasd_log_lock, s);
@@ -414,6 +415,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ logging_enabled = 1;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Remove unnecessary memset from physmap_of driver
From: Josh Boyer @ 2007-10-03 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18178.55231.813138.369480@cargo.ozlabs.ibm.com>
On Wed, 2007-10-03 at 09:43 +1000, Paul Mackerras wrote:
> Valentine Barshak writes:
>
> > No need for memset to zero memory here, since we use kzalloc.
> >
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > ---
> > drivers/mtd/maps/physmap_of.c | 1 -
>
> Please cc the mtd list (linux-mtd@lists.infradead.org) and/or David
> Woodhouse on MTD patches. Posting them to linuxppc-dev isn't going to
> get them upstream.
Except when I screw up and pull them into my tree. Which won't happen
again.
josh
^ permalink raw reply
* Re: [PATCH v3 2/4] Implement generic time of day clocksource for powerpc machines.
From: Paul Mackerras @ 2007-10-03 0:48 UTC (permalink / raw)
To: Tony Breeds
Cc: Stephen Rothwell, Thomas Gleixner, Realtime Kernel, linuxppc-dev
In-Reply-To: <20070921213552.GD9814@bakeyournoodle.com>
Tony Breeds writes:
> @@ -982,6 +906,10 @@ void __init time_init(void)
>
> write_sequnlock_irqrestore(&xtime_lock, flags);
>
> + /* Register the clocksource, if we're not running on iSeries */
> + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> + clocksource_init();
This breaks the 32-bit compile.
Is it possible to adjust the frequency of a clocksource after it has
been registered? Or could the timebase clocksource be unregistered
and reregistered in iSeries_tb_recal?
Paul.
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Michael Ellerman @ 2007-10-03 0:30 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003002646.GD9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
On Wed, 2007-10-03 at 10:26 +1000, Tony Breeds wrote:
> On Tue, Oct 02, 2007 at 06:28:19PM -0500, Linas Vepstas wrote:
> > On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> > > Seeing the following from an older power LPAR, pretty sure we had
> > > this in the previous -mm also:
> >
> > I haven't forgetten about this ... and am looking at it now.
> > Seems that whenever I go to reserve the machine pSeries-102,
> > someone else is using it :-)
>
> This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
> (79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
> branch. It looks to me that we have logging enabled too early now.
>
> I think the following is a reasonable fix?
>
> ---
> Explicitly enable RTAS error logging, when it should be ready.
>
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> ---
>
> arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
> index 30925d2..0df5d0d 100644
> --- a/arch/powerpc/platforms/pseries/rtasd.c
> +++ b/arch/powerpc/platforms/pseries/rtasd.c
> @@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
> static int full_rtas_msgs = 0;
>
> /* Stop logging to nvram after first fatal error */
> -static int no_more_logging;
> +static int no_more_logging = 1; /* Until we initialize everything,
> + * make sure we don't try logging
> + * anything */
> +
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Tony Breeds @ 2007-10-03 0:26 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071002232819.GN4338@austin.ibm.com>
On Tue, Oct 02, 2007 at 06:28:19PM -0500, Linas Vepstas wrote:
> On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> > Seeing the following from an older power LPAR, pretty sure we had
> > this in the previous -mm also:
>
> I haven't forgetten about this ... and am looking at it now.
> Seems that whenever I go to reserve the machine pSeries-102,
> someone else is using it :-)
This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
(79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
branch. It looks to me that we have logging enabled too early now.
I think the following is a reasonable fix?
---
Explicitly enable RTAS error logging, when it should be ready.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..0df5d0d 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
+static int no_more_logging = 1; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
+
static int error_log_cnt;
@@ -414,6 +417,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ no_more_logging = 0;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Remove unnecessary memset from physmap_of driver
From: Paul Mackerras @ 2007-10-02 23:43 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071002155328.GA3574@ru.mvista.com>
Valentine Barshak writes:
> No need for memset to zero memory here, since we use kzalloc.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> drivers/mtd/maps/physmap_of.c | 1 -
Please cc the mtd list (linux-mtd@lists.infradead.org) and/or David
Woodhouse on MTD patches. Posting them to linuxppc-dev isn't going to
get them upstream.
Paul.
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Linas Vepstas @ 2007-10-02 23:28 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20070924123531.GC30855@shadowen.org>
On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> Seeing the following from an older power LPAR, pretty sure we had
> this in the previous -mm also:
I haven't forgetten about this ... and am looking at it now.
Seems that whenever I go to reserve the machine pSeries-102,
someone else is using it :-)
--linas
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: Badari Pulavarty @ 2007-10-02 23:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
In-Reply-To: <18178.52359.953289.638736@cargo.ozlabs.ibm.com>
On Wed, 2007-10-03 at 08:56 +1000, Paul Mackerras wrote:
> Badari Pulavarty writes:
>
> > I am trying to get hotplug memory remove working on ppc64.
> > In order to verify a given memory region, if its valid or not -
> > current hotplug-memory patches used /proc/iomem. On IA64 and
> > x86-64 /proc/iomem shows all memory regions.
> >
> > I am wondering, if its acceptable to do the same on ppc64 also ?
>
> I am a bit hesitant to do that, since /proc/iomem is user visible and
> is therefore part of the user/kernel ABI. Also it feels a bit weird
> to have system RAM in something whose name suggests it's about MMIO.
Yes. That was my first reaction. Until last week, I never realized
that /proc/iomem contains entire memory layout on i386/x86-64 :(
Since i386, x86-64 and ia64 are all doing same thing, I thought breakage
would be minimal (if any) if we do the same on ppc64.
> > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > code to be able to do this.
>
> Isn't it just a matter of abstracting the test for a valid range of
> memory? If it's really hard to abstract that, then I guess we can put
> RAM in iomem_resource, but I'd rather not.
>
Sure. I will work on it and see how ugly it looks.
KAME, are you okay with abstracting the find_next_system_ram() and
let arch provide whatever implementation they want ? (since current
code doesn't work for x86-64 also ?).
Thanks,
Badari
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: Paul Mackerras @ 2007-10-02 22:56 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
In-Reply-To: <1191346196.6106.20.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty writes:
> I am trying to get hotplug memory remove working on ppc64.
> In order to verify a given memory region, if its valid or not -
> current hotplug-memory patches used /proc/iomem. On IA64 and
> x86-64 /proc/iomem shows all memory regions.
>
> I am wondering, if its acceptable to do the same on ppc64 also ?
I am a bit hesitant to do that, since /proc/iomem is user visible and
is therefore part of the user/kernel ABI. Also it feels a bit weird
to have system RAM in something whose name suggests it's about MMIO.
> Otherwise, we need to add arch-specific hooks in hotplug-remove
> code to be able to do this.
Isn't it just a matter of abstracting the test for a valid range of
memory? If it's really hard to abstract that, then I guess we can put
RAM in iomem_resource, but I'd rather not.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Benjamin Herrenschmidt @ 2007-10-02 22:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710020910u3a679ea2m15b005d0ba5fb054@mail.gmail.com>
> My opinion is that since it is driver-specific code anyway, then it
> belongs with the driver. Plus a driver writer for ARM doesn't need to
> write them. It's the powerpc or microblaze developer who will do it.
> If the driver maintainer doesn't want the binding in the main driver
> .c file, then the binding can easily be in an additional .c file
> without needing to add a constructor. (Kind of like how many USB host
> controllers are managed)
The main advantage is that it keeps the OF specific code localized to a
single function, whether that function lives in the driver or the arch
code, it makes it self contained and easier to deal with by the driver
author.
Having multiple device types on which the driver can attach is a pain
from a driver standpoint. It needs multiple
probe/remove/suspend/resume/shutdown hooks etc... it's a bigger
maintainance burden in the long run.
The important thing however, with the constructor approach is to try as
much as possible to keep the proper tree structure, and thus, try to
find a way to instanciate the devices with proper parent/child
relationship so that ordering for things like suspend/resume operations
is maintained.
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-02 22:03 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071002123849.242670@gmx.net>
On Tue, 2007-10-02 at 14:38 +0200, Gerhard Pircher wrote:
> I know that it's ugly, but the problem is how to distinguish the
> boards.
> The only real difference I know of is the PCI interrupt mapping. The
> northbridges chip revision for example is always the same, but CPU
> type,
> amount of memory and PCI devices can appear in all possible
> combinations.
> The firmware doesn't tell me, which board the kernel is runnning on,
> so I
> would like to rely on this fall back here until I get the chance to
> update the firmware (which is beyond my control).
And how does the firmware know ? There must be a strap somewhere...
Ben.
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
From: Benjamin Herrenschmidt @ 2007-10-02 22:02 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071002122005.GA6425@localhost.localdomain>
>
> Exactly, this is what that patch is trying to do. QEIC cascade handler is
> calling mpic's eoi() (end() actually, as it's flow level, but end == eoi.
> Is it main objection? Ok, I can get rid of it, and use chip level eoi()
> directly).
Yes, use eoi() directly, don't add end()
> Yup, exactly. Actually, QEIC's cascade handlers do not really know
> what needs to be done, but they're good at guessing (if (chip->eoi)).
>
> Sure, I can place board-specific QEIC handlers in the board file, but
> that will be quite big code duplication for all machines using QEIC.
Maybe you can provide a set of common ones, and then just pick the one
you want from the board file ?
Or have some board code call into a QEIC init routine specifying the
type of cascade handler to use ... or whatevre you like here.
Just don't add end() where it doesn't belong.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-10-02 21:59 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20071002012730.GO12049@parisc-linux.org>
On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote:
>
> Fine by me. Do you have the ability to produce failures on a whim on
> your platforms?
Yes, although it is very platform specific -- there are actually
transistors in the pci bridge chip, which actually short out lines,
and so, from the point of view of the rest of the chip, it did
actually see a "real" error. Its supposed to be a very realistic
test.
> I've been vaguely musing a PCI device failure patch for
> x86, just so people can test driver failure paths.
That would be good ... I've recently agreed to accept a fedex
to test someone elses card for them, which is outside my usual
activities.
There's also supposed to be some PCI-X riser card out there,
(never seen one) which has the ability to inject actual pci
errors. Its the Agilent PCI BestX card; I got the impression
they might not sell it anymore; dunno.
One guy in the lab used to brush a grounding strap across
the pins; this usually got a rise out of the audience.
--linas
^ 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