* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-16 20:54 UTC (permalink / raw)
To: Jean Delvare; +Cc: LinuxPPC-dev, i2c
In-Reply-To: <20080216103123.50a0128b@hyperion.delvare>
Jean Delvare wrote:
> Hi Sean,
>
> On Fri, 15 Feb 2008 23:11:12 -0500, Sean MacLennan wrote:
>
>> Here is the of platform patch. I removed the retries and removed the spaces used for spacing.
>>
>> Cheers,
>> Sean
>>
>> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>>
>
> First of all: please run scripts/checkpatch.pl on your patch and fix
> the reported errors. It tells me:
> total: 10 errors, 5 warnings, 222 lines checked
> which is definitely too much.
>
Many of the errors/warnings are from the cut and paste of the original
code. I realize this doesn't justify my new code, but does beg the
question; should I also cleanup the original code? And how much? I am
tempted to cleanup all but the #ifdef CONFIG_IBM_OCP part.
A few comments, everything else I agree with.
>> + return -ENOMEM;
>> + }
>> +
>> + /* This assumes we don't mix index and non-index entries. */
>> + indexp = of_get_property(np, "index", NULL);
>> + dev->idx = indexp ? *indexp : index++;
>>
>
> I don't like this static index thing much. Can't you just make the
> "index" OF property mandatory? Mixing ways to number things can become
> very confusing. In particular as you are using dev->idx later to call
> i2c_add_numbered_adapter(), the caller is really supposed to know what
> they are doing with the bus numbers.
>
I also don't really like mixing the two methods, hence the comment. I
did this so existing dts files, which don't currently have an index,
would work as is. Maybe it would be better to add the index?
Without my patch, or one like it, you cannot currently use the IBM IIC
in the arch/powerpc branch, so maybe now *is* the time to enforce an index?
So if nobody responds with a good reason not to, I will change the code
to require the index to be set. Less testing for me ;)
>> + adap->timeout = 1;
>> + adap->nr = dev->idx;
>>
>
> Looks to me like the block above has much in common with the original
> probe function, maybe it would be worth sharing the code to make future
> maintenance easier?
>
It is my understanding the the arch/ppc branch is going away in the
middle of the year. So I kept the of platform code separate and clean
expecting the CONFIG_IBM_OCP block to be removed in the near future. So
future maintenance should not be an issue.
> Note that I cannot test the code so I am relying on the linuxppc-dev
> folks to test it
I can test the of platform code and the common code. I am not setup to
test the OCP code, which is why I am loath to change it. I use the IBM
IIC for access to an ad7414 thermal chip (currently not in the kernel,
I am working on that too) and for reading an eeprom.
Cheers,
Sean
^ permalink raw reply
* Re: Frustrated question with insmod
From: Bruce_Leonard @ 2008-02-17 8:03 UTC (permalink / raw)
To: Magnus Hjorth; +Cc: linuxppc-embedded
In-Reply-To: <1203136939.5231.0.camel@magnus-desktop>
>
> 'cat /proc/modules' perhaps?
I tried that, but it gives me an odd address (at least I think it's an odd
address): 0xE1188000. I use that address in GDB for adding the symbol
table (i.e., add-symbol-file mymodule 0xE1188000), but then the BDI
reports "*** MMU: address translation for 0xE118822C failed" when I try to
set a breakpoint in the probe function. Admittedly I'm new to driver
writing, but shouldn't the address be somewhere in the 0xC0xxxxxx range?
>
> //Magnus
>
>
> On Fri, 2008-02-15 at 17:06 -0800, Bruce_Leonard@selinc.com wrote:
> > Sorry if this is the wrong place to post this question. I'm
developing a
> > NAND flash driver and I need to do some detailed dubugging using GDB
with
> > a BDI2K. According to the Denx web site, to find out the address that
the
> > module is loading at you load it using the -m parameter to insmod
(i.e.,
> > "insmod -m mymodule"). However, every version of insmod I've tried
> > doesn't recognize ANY options much less -m. Can anyone please point
me in
> > the right direction, or give me another way of knowing what the load
> > address of my module is?
> >
> > Thanks.
> >
> > Bruce
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: APU FPU in Virtex ppc405
From: Thomas Werne @ 2008-02-17 7:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47B02CB0.8040002@gmail.com>
A. Nolson <alohanono <at> gmail.com> writes:
>
> I have been checking and it seems that the APU FPU patches will give
> some headaches now, so I will probably wait until they merge them with
> the official GCC release. In any case, it seems that the FPU restricts
> the PowerPC and bus frequencies to a max of 200/100.
>
> Anyway, thanks for the info. I will try to keep track of this in case of
> an update.
>
Hi -
You can get the FPU to work with the 2.6.24rc3 Linux (I got it to work just
yesterday). There are a couple of small changes you have to make to kernel
config files and to one of the .h files, plus you need to compile with the
-fshort-double flag to convert all doubles into floats. Let me know if you're
still interested and I can post details and/or patches.
Thomas
--
Thomas Werne
NASA Jet Propulsion Laboratory
All personal and professional opinions presented herein are my
own and do not, in any way, represent the opinion or policy of JPL.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Geert Uytterhoeven @ 2008-02-17 9:44 UTC (permalink / raw)
To: avorontsov, linux-fbdev-devel
Cc: linuxppc-dev, Andrew Morton, linux-kernel, adaplas
In-Reply-To: <20080215164542.GB16810@localhost.localdomain>
On Fri, 15 Feb 2008, Anton Vorontsov wrote:
> On Thu, Feb 14, 2008 at 10:49:42PM -0800, Andrew Morton wrote:
> > On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > > This patch adds support for the framebuffers with non-native
> > > endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
> > > be used by the drivers. Depending on the host endianness this flag
> > > will be overwritten by FBINFO_BE_MATH internal flag, or cleared.
> > >
> > > Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
> >
> > That's a pretty large patch to fbdev core,
>
> Yes, but changes are mostly trivial. No insurance of typos and thinkos
> though. OTOH, it survived my tests.
>
> > and Tony appears to have gone
> > offline again and you didn't cc the fbdev mailing list.
>
> FRAMEBUFFER LAYER
> P: Antonino Daplas
> M: adaplas@gmail.com
> L: linux-fbdev-devel@lists.sourceforge.net (subscribers-only)
>
> I'm lazy to subscribe on occasional patches. Yup, this is hardly
> an excuse...
While linux-fbdev is subscribers-only, non-subscribers are not plainly
rejected, but moderated, so the casual patch/comment/question comes
through.
I'll cook up a patch for MAINTAINERS to clarify.
> > Actually... should CONFIG_FB_FOREIGN_ENDIAN exist, or should this feature
> > be permanently enabled?
>
> It should not. Because with CONFIG_FB_FOREIGN_ENDIAN enabled, drawing
> might be a little bit slower, because of external checks for endianness
> (I didn't noticed any slowdown, but I guess it's still measurable if we
> find some fb benchmark).
> > I'd like to at least queue a patch in -mm so that CONFIG_FB_FOREIGN_ENDIAN
> > is forced-on, so the code gets some runtime testing. Will that break
> > anything?
>
> Nope, it should not break anything, just possible fbconsole/tux drawing
> slowdown.
Tux drawing speed doesn't really matter, as it's done once only.
Console text drawing is different.
`time cat MAINTAINERS' is a good test. Of course, is most time is spent
in scrolling, you won't see much difference.
So probably we need a test file that contains lines of text interspersed
with `HOME' escape sequences, so we don't scroll?
> Thinking about it a little bit more, I believe we want to add a choice,
> which exactly foreign endianness we want to compile-in. Then, if we're
> pretty confident that particular BE machine uses only LE framebuffer,
> gcc can optimize away endianness checks.
>
> Patch on top of previous inlined here. With that patch, slowdown is
> possible with CONFIG_FB_BOTH_ENDIAN option only, which is still
> default if FOREIGN_ENDIAN is selected.
> With this patch FB_FOREIGN_ENDIAN converted to menuconfig with the
> choice inside: which type of foreign endianness we want to compile-in.
>
The notion of `FOREIGN_ENDIAN' is relative, as it depends on the
architecture you're compiling for.
Suppose you have a PCI graphics card with a frame buffer that's always
big endian. When compiling for a big endian platform, the driver won't
depend on FB_FOREIGN_ENDIAN. When compiling for a little endian
platform, it will.
Shouldn't we add LITTLE_ENDIAN and BIG_ENDIAN Kconfig vars first, just
like we have 64BIT?
> As a bonus, now fb subsystem will refuse to register framebuffer with
> unsupported endianness, and will suggest a way to solve the problem.
I'd like to handle this in Kconfig (cfr. above).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 1/3] Fix Unlikely(x) == y
From: Andrew Pinski @ 2008-02-17 9:45 UTC (permalink / raw)
To: Willy Tarreau
Cc: linuxppc-dev, Roel Kluin, cbe-oss-dev, lkml, Arjan van de Ven
In-Reply-To: <20080216175849.GA25636@1wt.eu>
On Feb 16, 2008 9:58 AM, Willy Tarreau <w@1wt.eu> wrote:
> Last but not least, gcc 4 tends to emit stupid checks, to the point that I
> have replaced unlikely(x) with (x) in my code when gcc >= 4 is detected. What
> I observe is that the following code :
>
> if (unlikely(p == NULL)) ...
>
> often gets coded like this :
>
> reg1 = (p == NULL)
> if (reg1 != 0) ...
>
> ... which clobbers reg1 for nothing and performs a double test.
This really only can happen in GCC 4.0.x and 4.1.x and cannot happen
for 4.2 or 4.3 really because of the way __builtin_expect is handled
for those two.
-- Pinski
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 1/3] Fix Unlikely(x) == y
From: Willy Tarreau @ 2008-02-17 10:08 UTC (permalink / raw)
To: Andrew Pinski
Cc: linuxppc-dev, Roel Kluin, cbe-oss-dev, lkml, Arjan van de Ven
In-Reply-To: <de8d50360802170145u4bd60f76x9662b66c63bdf41d@mail.gmail.com>
On Sun, Feb 17, 2008 at 01:45:23AM -0800, Andrew Pinski wrote:
> On Feb 16, 2008 9:58 AM, Willy Tarreau <w@1wt.eu> wrote:
> > Last but not least, gcc 4 tends to emit stupid checks, to the point that I
> > have replaced unlikely(x) with (x) in my code when gcc >= 4 is detected. What
> > I observe is that the following code :
> >
> > if (unlikely(p == NULL)) ...
> >
> > often gets coded like this :
> >
> > reg1 = (p == NULL)
> > if (reg1 != 0) ...
> >
> > ... which clobbers reg1 for nothing and performs a double test.
>
> This really only can happen in GCC 4.0.x and 4.1.x and cannot happen
> for 4.2 or 4.3 really because of the way __builtin_expect is handled
> for those two.
Happy to know that, thanks for the info Andrew!
Willy
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Woodhouse @ 2008-02-17 10:22 UTC (permalink / raw)
To: Scott Wood; +Cc: LinuxPPC-dev, Sean MacLennan
In-Reply-To: <47B1EF39.5000703@freescale.com>
On Tue, 2008-02-12 at 13:10 -0600, Scott Wood wrote:
> Hmm? All I meant was that it'd be nice if there were an option in the
> Linux mtd code to disable the "look for another chip and cause a machine
> check if it isn't there" functionality. It was an aside from the
> dts-variant issue.
Yeah, maybe -- although the probe code is hairy enough already; I'm not
massively keen on adding to it. Or even looking at it hard, if the truth
be told.
Alternatively, perhaps we should catch the machine check and recover
(like we do for failing I/O accesses on ppc32).
--
dwmw2
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Jean Delvare @ 2008-02-17 10:52 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev, i2c
In-Reply-To: <47B74D76.1000708@pikatech.com>
Hi Sean,
On Sat, 16 Feb 2008 15:54:14 -0500, Sean MacLennan wrote:
> Jean Delvare wrote:
> > Hi Sean,
> >
> > On Fri, 15 Feb 2008 23:11:12 -0500, Sean MacLennan wrote:
> >
> >> Here is the of platform patch. I removed the retries and removed the spaces used for spacing.
> >>
> >> Cheers,
> >> Sean
> >>
> >> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> >>
> >
> > First of all: please run scripts/checkpatch.pl on your patch and fix
> > the reported errors. It tells me:
> > total: 10 errors, 5 warnings, 222 lines checked
> > which is definitely too much.
> >
> Many of the errors/warnings are from the cut and paste of the original
> code. I realize this doesn't justify my new code, but does beg the
> question; should I also cleanup the original code? And how much? I am
> tempted to cleanup all but the #ifdef CONFIG_IBM_OCP part.
Just take care of the code you are adding. The old code will go away
soon anyway as I understand it, so don't bother cleaning it up.
>
> A few comments, everything else I agree with.
>
> >> + return -ENOMEM;
> >> + }
> >> +
> >> + /* This assumes we don't mix index and non-index entries. */
> >> + indexp = of_get_property(np, "index", NULL);
> >> + dev->idx = indexp ? *indexp : index++;
> >>
> >
> > I don't like this static index thing much. Can't you just make the
> > "index" OF property mandatory? Mixing ways to number things can become
> > very confusing. In particular as you are using dev->idx later to call
> > i2c_add_numbered_adapter(), the caller is really supposed to know what
> > they are doing with the bus numbers.
> >
> I also don't really like mixing the two methods, hence the comment. I
> did this so existing dts files, which don't currently have an index,
> would work as is. Maybe it would be better to add the index?
>
> Without my patch, or one like it, you cannot currently use the IBM IIC
> in the arch/powerpc branch, so maybe now *is* the time to enforce an index?
>
> So if nobody responds with a good reason not to, I will change the code
> to require the index to be set. Less testing for me ;)
Yes, I think this is the right time to enforce the index.
> >> + adap->timeout = 1;
> >> + adap->nr = dev->idx;
> >>
> >
> > Looks to me like the block above has much in common with the original
> > probe function, maybe it would be worth sharing the code to make future
> > maintenance easier?
> >
> It is my understanding the the arch/ppc branch is going away in the
> middle of the year. So I kept the of platform code separate and clean
> expecting the CONFIG_IBM_OCP block to be removed in the near future. So
> future maintenance should not be an issue.
OK, fine with me then.
> > Note that I cannot test the code so I am relying on the linuxppc-dev
> > folks to test it
> I can test the of platform code and the common code. I am not setup to
> test the OCP code, which is why I am loath to change it. I use the IBM
> IIC for access to an ad7414 thermal chip (currently not in the kernel,
> I am working on that too) and for reading an eeprom.
Note that Frank Edelhaeuser has submitted a driver for this chip
recently:
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-February/022478.html
I didn't have time to review this patch yet, maybe you will want to do
it yourself.
--
Jean Delvare
^ permalink raw reply
* Sequoia NAND
From: Steve Heflin @ 2008-02-17 11:39 UTC (permalink / raw)
To: linuxppc-embedded
I don't see where the new powerpc architecture and drivers/mtd/nand
contains support for the NAND chip on the Sequoia platform. We have
a Linux 2.6.14 kit where Montavista has a driver in "sequoia_nand.c"
which interfaces with the NAND device via NAND Flash Control registers:
struct ppc440ep_ndfc_regs *sequoia_ndfc;
where:
struct ppc440ep_ndfc_regs {
uint cmd;
uint addr;
uint data;
uint reserved1;
uint ecc0;
uint ecc1;
uint ecc2;
uint ecc3;
uint ecc4;
uint ecc5;
uint ecc6;
uint ecc7;
uint b0cr;
uint b1cr;
uint b2cr;
uint b3cr;
uint cr;
uint sr;
uint hwctl;
uint reserved2;
uint revid;
};
Is the Sequoia's NAND Flash Controller supported in the current Linux-2.6.25?
thanks,
Steve
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Michael Ellerman @ 2008-02-17 11:50 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Roel Kluin, lkml, Willy Tarreau, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20080216103927.2a02352b@laptopd505.fenrus.org>
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
> > >> > you found a great set of bugs..
> > >> > but to be honest... I suspect it's just best to remove unlikely
> > >> > altogether for these cases; unlikely() is almost a
> > >> > go-faster-stripes thing, and if you don't know how to use it you
> > >> > shouldn't be using it... so just removing it for all wrong cases
> > >> > is actually the best thing to do imo.
Hi Arjan,
In general I agree with you that unlikely() is overused, and often in
inappropriate places.
> for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> than the coder in general. Same for most other architectures.
>
> unlikely() creates bigger code as well.
>
> Now... we're talking about your super duper hotpath function here right?
> One where you care about 0.5 cycle speed improvement? (less on modern
> systems ;)
The first patch was to platforms/ps3 code, which runs on the Cell, in
particular the PPE ... which is not an x86 :)
eg:
[michael@schoenaich ~]$ cat branch.c
#include <stdio.h>
int main(void)
{
int i, j;
for (i = 0, j = 0; i < 1000000000; i++)
if (i % 4 == 0)
j++;
printf("j = %d\n", j);
return 0;
}
[michael@schoenaich ~]$ ppu-gcc -Wall -O3 -o branch branch.c
[michael@schoenaich ~]$ time ./branch
real 0m5.172s
[michael@schoenaich ~]$ cat branch.c
..
for (i = 0, j = 0; i < 1000000000; i++)
if (__builtin_expect(i % 4 == 0, 0))
j++;
..
[michael@schoenaich ~]$ ppu-gcc -Wall -O3 -o branch branch.c
[michael@schoenaich ~]$ time ./branch
real 0m3.762s
Which looks as though unlikely() is helping. Admittedly we don't have a
lot of kernel code that looks like that, but at least unlikely is doing
what we want it to.
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: Frustrated question with insmod
From: Magnus Hjorth @ 2008-02-17 12:04 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OFE029FE92.B8F9D4B0-ON882573F2.002B93E9-882573F2.002C385D@selinc.com>
On Sun, 2008-02-17 at 00:03 -0800, Bruce_Leonard@selinc.com wrote:
> >
> > 'cat /proc/modules' perhaps?
>
> I tried that, but it gives me an odd address (at least I think it's an odd
> address): 0xE1188000. I use that address in GDB for adding the symbol
> table (i.e., add-symbol-file mymodule 0xE1188000), but then the BDI
> reports "*** MMU: address translation for 0xE118822C failed" when I try to
> set a breakpoint in the probe function. Admittedly I'm new to driver
> writing, but shouldn't the address be somewhere in the 0xC0xxxxxx range?
I believe the modules live in the kernel's dynamically allocated memory
area in the 0xExxxxxxx range..
Can you set breakpoints anywhere in the kernel? Try picking a function address from System.map and set a breakpoint there.
I have little experience with what you're doing, but my guess is that you're setting the breakpoint in the wrong context, probably standing in userspace..
>
> >
> > //Magnus
> >
> >
> > On Fri, 2008-02-15 at 17:06 -0800, Bruce_Leonard@selinc.com wrote:
> > > Sorry if this is the wrong place to post this question. I'm
> developing a
> > > NAND flash driver and I need to do some detailed dubugging using GDB
> with
> > > a BDI2K. According to the Denx web site, to find out the address that
> the
> > > module is loading at you load it using the -m parameter to insmod
> (i.e.,
> > > "insmod -m mymodule"). However, every version of insmod I've tried
> > > doesn't recognize ANY options much less -m. Can anyone please point
> me in
> > > the right direction, or give me another way of knowing what the load
> > > address of my module is?
> > >
> > > Thanks.
> > >
> > > Bruce
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
^ permalink raw reply
* Re: Frustrated question with insmod
From: Wolfgang Grandegger @ 2008-02-17 12:28 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OF994170A6.977C29F1-ON882573F1.0005A6C7-882573F1.00060311@selinc.com>
Bruce_Leonard@selinc.com wrote:
> Sorry if this is the wrong place to post this question. I'm developing a
> NAND flash driver and I need to do some detailed dubugging using GDB with
> a BDI2K. According to the Denx web site, to find out the address that the
> module is loading at you load it using the -m parameter to insmod (i.e.,
> "insmod -m mymodule"). However, every version of insmod I've tried
> doesn't recognize ANY options much less -m. Can anyone please point me in
> the right direction, or give me another way of knowing what the load
> address of my module is?
# cat /sys/module/<name>/sections/.text
Do not forget to enable CONFIG_KALLSYMS.
Wolfgang.
^ permalink raw reply
* "extra-aflags-y"??
From: Robert P. J. Day @ 2008-02-17 10:47 UTC (permalink / raw)
To: Linux PPC Mailing List
something about this doesn't look right:
$ grep -rw extra-aflags-y *
arch/ppc/boot/simple/Makefile:EXTRA_AFLAGS := $(extra-aflags-y)
$
AFAIK, there is no supported "extra-aflags-y" variable. and
EXTRA_AFLAGS is deprecated in favour of asflags-y anyway, no?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply
* Re: Sequoia NAND
From: Josh Boyer @ 2008-02-17 13:18 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080217113932.02EBDDE127@ozlabs.org>
On Sun, 17 Feb 2008 06:39:43 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> I don't see where the new powerpc architecture and drivers/mtd/nand
> contains support for the NAND chip on the Sequoia platform. We have
It's not.
> Is the Sequoia's NAND Flash Controller supported in the current Linux-2.6.25?
No.
There are a couple different patches floating around for it, all of
which need work. The driver is drivers/mtd/nand/ndfc.c and work needs
to be done to parse a device tree and present the proper platform
devices so that driver will work. Stefan has something like this
somewhere, I've just been lax in getting it into my tree.
Too late for .25, but I have 4 boards that use this now so I'll be a
bit more interested in getting it into .26.
josh
^ permalink raw reply
* Re: Sequoia NAND - others missing?
From: Steve Heflin @ 2008-02-17 15:27 UTC (permalink / raw)
To: linuxppc-embedded, Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080217071851.0edbf07f@vader.jdub.homelinux.org>
Are there other devices (beside the NAND Flash Controller) that exist
on the AMCC-440EPx chip and are not supported by the current
Linux-2.6.25 ARCH=powerpc?
thanks for your help,
Steve
At 08:18 AM 2/17/2008, Josh Boyer wrote:
>On Sun, 17 Feb 2008 06:39:43 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > I don't see where the new powerpc architecture and drivers/mtd/nand
> > contains support for the NAND chip on the Sequoia platform. We have
>
>It's not.
>
> > Is the Sequoia's NAND Flash Controller supported in the current
> Linux-2.6.25?
>
>No.
>
>There are a couple different patches floating around for it, all of
>which need work. The driver is drivers/mtd/nand/ndfc.c and work needs
>to be done to parse a device tree and present the proper platform
>devices so that driver will work. Stefan has something like this
>somewhere, I've just been lax in getting it into my tree.
>
>Too late for .25, but I have 4 boards that use this now so I'll be a
>bit more interested in getting it into .26.
>
>josh
^ permalink raw reply
* Re: Sequoia NAND - others missing?
From: Steve Heflin @ 2008-02-17 15:27 UTC (permalink / raw)
To: linuxppc-embedded, Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080217071851.0edbf07f@vader.jdub.homelinux.org>
Are there other devices (beside the NAND Flash Controller) that exist
on the AMCC-440EPx chip and are not supported by the current
Linux-2.6.25 ARCH=powerpc?
thanks for your help,
Steve
At 08:18 AM 2/17/2008, Josh Boyer wrote:
>On Sun, 17 Feb 2008 06:39:43 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > I don't see where the new powerpc architecture and drivers/mtd/nand
> > contains support for the NAND chip on the Sequoia platform. We have
>
>It's not.
>
> > Is the Sequoia's NAND Flash Controller supported in the current
> Linux-2.6.25?
>
>No.
>
>There are a couple different patches floating around for it, all of
>which need work. The driver is drivers/mtd/nand/ndfc.c and work needs
>to be done to parse a device tree and present the proper platform
>devices so that driver will work. Stefan has something like this
>somewhere, I've just been lax in getting it into my tree.
>
>Too late for .25, but I have 4 boards that use this now so I'll be a
>bit more interested in getting it into .26.
>
>josh
^ permalink raw reply
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Jens Axboe @ 2008-02-17 19:29 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Dhaval Giani, Linux Kernel Mailing List, Srivatsa Vaddagiri,
linuxppc-dev, Ingo Molnar, Balbir Singh
In-Reply-To: <47B67E5E.4010001@linux.vnet.ibm.com>
On Sat, Feb 16 2008, Kamalesh Babulal wrote:
> Hi,
>
> The softlockup is seen from 2.6.25-rc1-git{1,3} and is visible in the 2.6.24-rc2 kernel,
> While booting up with the 2.6.25-rc1-git{1,3} and 2.6.25-rc2 kernel(s) on the powerbox
>
> Loading st.ko module
> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:379]
> NIP: c0000000001b0620 LR: c0000000001a5dcc CTR: 0000000000000040
> REGS: c00000077caab8a0 TRAP: 0901 Not tainted (2.6.25-rc2-autotest)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 84004088 XER: 20000000
> TASK = c00000077cb450a0[379] 'insmod' THREAD: c00000077caa8000 CPU: 1
> GPR00: c00000077c9d4000 c00000077caabb20 c000000000538a40 000000000000000b
> GPR04: ffc0000000000000 c00000077e0c0000 0000000000000036 000000000000000a
> GPR08: 0040000000000000 c00000077c9d4250 c000000000000000 0000000000000000
> GPR12: c00000077c9d4230 c000000000481d00
> NIP [c0000000001b0620] .radix_tree_gang_lookup+0x100/0x1e4
> LR [c0000000001a5dcc] .call_for_each_cic+0x50/0x10c
> Call Trace:
> [c00000077caabb20] [c0000000001a5e2c] .call_for_each_cic+0xb0/0x10c (unreliable)
> [c00000077caabc60] [c00000000019dba4] .exit_io_context+0xf0/0x110
> [c00000077caabcf0] [c000000000061e38] .do_exit+0x820/0x850
> [c00000077caabda0] [c000000000061f34] .do_group_exit+0xcc/0xe8
> [c00000077caabe30] [c00000000000872c] syscall_exit+0x0/0x40
> Instruction dump:
> 7d296214 39290018 e8090000 7caa2038 39290008 2fa00000 409e0018 7caa4215
> 396b0001 418200cc 424000b8 4bffffdc <79691f24> 7d296214 e9690018 2fab0000
It's odd stuff. Could you perhaps try and add some printks to
block/cfq-iosched.c:call_for_each_cic(), like dumping the 'nr' return
from radix_tree_gang_lookup() and the pointer value of cics[i] in the
for() loop after the lookup?
How many SCSI devices are online?
--
Jens Axboe
^ permalink raw reply
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Rafael J. Wysocki @ 2008-02-17 20:08 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Dhaval Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Jens Axboe, Ingo Molnar, Balbir Singh
In-Reply-To: <47B67E5E.4010001@linux.vnet.ibm.com>
On Saturday, 16 of February 2008, Kamalesh Babulal wrote:
> Hi,
Hi,
> The softlockup is seen from 2.6.25-rc1-git{1,3} and is visible in the 2.6.24-rc2 kernel,
> While booting up with the 2.6.25-rc1-git{1,3} and 2.6.25-rc2 kernel(s) on the powerbox
Can you update the Bugzilla entry at:
http://bugzilla.kernel.org/show_bug.cgi?id=9948
with the above information, please?
Rafael
> Loading st.ko module
> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:379]
> NIP: c0000000001b0620 LR: c0000000001a5dcc CTR: 0000000000000040
> REGS: c00000077caab8a0 TRAP: 0901 Not tainted (2.6.25-rc2-autotest)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 84004088 XER: 20000000
> TASK = c00000077cb450a0[379] 'insmod' THREAD: c00000077caa8000 CPU: 1
> GPR00: c00000077c9d4000 c00000077caabb20 c000000000538a40 000000000000000b
> GPR04: ffc0000000000000 c00000077e0c0000 0000000000000036 000000000000000a
> GPR08: 0040000000000000 c00000077c9d4250 c000000000000000 0000000000000000
> GPR12: c00000077c9d4230 c000000000481d00
> NIP [c0000000001b0620] .radix_tree_gang_lookup+0x100/0x1e4
> LR [c0000000001a5dcc] .call_for_each_cic+0x50/0x10c
> Call Trace:
> [c00000077caabb20] [c0000000001a5e2c] .call_for_each_cic+0xb0/0x10c (unreliable)
> [c00000077caabc60] [c00000000019dba4] .exit_io_context+0xf0/0x110
> [c00000077caabcf0] [c000000000061e38] .do_exit+0x820/0x850
> [c00000077caabda0] [c000000000061f34] .do_group_exit+0xcc/0xe8
> [c00000077caabe30] [c00000000000872c] syscall_exit+0x0/0x40
> Instruction dump:
> 7d296214 39290018 e8090000 7caa2038 39290008 2fa00000 409e0018 7caa4215
> 396b0001 418200cc 424000b8 4bffffdc <79691f24> 7d296214 e9690018 2fab0000
> INFO: task insmod:387 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> insmod D 000000001000e144 12144 387 1
> Call Trace:
> [c00000077cb97600] [c0000000008fae80] 0xc0000000008fae80 (unreliable)
> [c00000077cb977d0] [c000000000010c7c] .__switch_to+0x11c/0x154
> [c00000077cb97860] [c000000000344498] .schedule+0x5d0/0x6b0
> [c00000077cb97950] [c0000000003447d8] .schedule_timeout+0x3c/0xe8
> [c00000077cb97a20] [c000000000343d34] .wait_for_common+0x150/0x22c
> [c00000077cb97ae0] [c00000000008ef00] .__stop_machine_run+0xbc/0xf0
> [c00000077cb97bb0] [c00000000008ef70] .stop_machine_run+0x3c/0x80
> [c00000077cb97c50] [c0000000000891f0] .sys_init_module+0x14e4/0x1af4
> [c00000077cb97e30] [c00000000000872c] syscall_exit+0x0/0x40
> -- 0:conmux-control -- time-stamp -- Feb/15/08 16:04:12 --
> INFO: task insmod:387 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> insmod D 000000001000e144 12144 387 1
> Call Trace:
> [c00000077cb97600] [c0000000008fae80] 0xc0000000008fae80 (unreliable)
> [c00000077cb977d0] [c000000000010c7c] .__switch_to+0x11c/0x154
> [c00000077cb97860] [c000000000344498] .schedule+0x5d0/0x6b0
> [c00000077cb97950] [c0000000003447d8] .schedule_timeout+0x3c/0xe8
> [c00000077cb97a20] [c000000000343d34] .wait_for_common+0x150/0x22c
> [c00000077cb97ae0] [c00000000008ef00] .__stop_machine_run+0xbc/0xf0
> [c00000077cb97bb0] [c00000000008ef70] .stop_machine_run+0x3c/0x80
> [c00000077cb97c50] [c0000000000891f0] .sys_init_module+0x14e4/0x1af4
> [c00000077cb97e30] [c00000000000872c] syscall_exit+0x0/0x40
> -- 0:conmux-control -- time-stamp -- Feb/15/08 16:06:21 --
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply
* Re: Sequoia NAND - others missing?
From: Josh Boyer @ 2008-02-17 20:56 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <47b8524c.1286460a.1307.7530SMTPIN_ADDED@mx.google.com>
On Sun, 17 Feb 2008 10:27:22 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> Are there other devices (beside the NAND Flash Controller) that exist
> on the AMCC-440EPx chip and are not supported by the current
> Linux-2.6.25 ARCH=powerpc?
i2c, GPIO, the security stuff (if your version has that), and GPT.
Thought GPT has never really been supported in any kernel that I
remember.
Patches for i2c and GPIO are floating around somewhere I think. Just
need to get them polished up and device-tree compliant.
josh
^ permalink raw reply
* Does anyone have a simple UIO driver that uses an interrupt handler?
From: Nick Droogh @ 2008-02-17 23:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]
Hi everyone,
I am looking for a driver example for a user space driver utilizing an
interrupt handler. I am having trouble registering a handler in my
driver attempt and would like to see an example of a working UIO driver.
Thanks,
Nick
[-- Attachment #2: ndroogh.vcf --]
[-- Type: text/x-vcard, Size: 220 bytes --]
begin:vcard
fn:Nick Droogh
n:Droogh;Nick
org:CADlink Technology
adr:Suite 100;;2440 Don Reid Drive;Ottawa;Ontario;K1H 1E1;Canada
email;internet:ndroogh@cadlink.com
title:Senior Technical Architect
version:2.1
end:vcard
^ permalink raw reply
* [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
From: Manish Ahuja @ 2008-02-18 4:53 UTC (permalink / raw)
To: ppc-dev, paulus, Linas Vepstas
The following series of patches implement a basic framework
for hypervisor-assisted dump. The very first patch provides
documentation explaining what this is :-) . Yes, its supposed
to be an improvement over kdump.
A list of open issues / todo list is included in the documentation.
It also appears that the not-yet-released firmware versions this was tested
on are still, ahem, incomplete; this work is also pending.
I have included most of the changes requested. Although, I did find
one or two, fixed in a later patch file rather than the first location
they appeared at.
Also it now does not block any memory on machines other than power6 boxes
which have the requisite firmware. This is from a power5 box.
from jal-lp6 a power5 machine.
.........
Phyp-dump not supported on this hardware
Using pSeries machine description
console [udbg-1] enabled
.......
I think I incorporated everyones comments so far.
-- Manish & Linas.
^ permalink raw reply
* libfdt: More tests of NOP handling behaviour
From: David Gibson @ 2008-02-18 5:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In light of the recently discovered bug with NOP handling, this adds
some more testcases for NOP handling. Specifically, it adds a helper
program which will add a NOP tag after every existing tag in a dtb,
and runs the standard battery of tests over trees mangled in this way.
For now, this does not add a NOP at the very beginning of the
structure block. This causes problems for libfdt at present, because
we assume in many places that the root node's BEGIN_NODE tag is at
offset 0. I'm still contemplating what to do about this (with one
option being simply to declare such dtbs invalid).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/nopulate.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/nopulate.c 2008-02-14 17:01:10.000000000 +1100
@@ -0,0 +1,107 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase/tool for rearranging blocks of a dtb
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <limits.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int nopulate_struct(char *buf, const void *fdt)
+{
+ int offset, nextoffset = 0;
+ uint32_t tag;
+ char *p;
+
+ p = buf;
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ memcpy(p, fdt + fdt_off_dt_struct(fdt) + offset,
+ nextoffset - offset);
+ p += nextoffset - offset;
+
+ *((uint32_t *)p) = cpu_to_fdt32(FDT_NOP);
+ p += FDT_TAGSIZE;
+
+ } while (tag != FDT_END);
+
+ return p - buf;
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt, *fdt2;
+ void *buf;
+ int newsize, struct_start, struct_end_old, struct_end_new, delta;
+ const char *inname;
+ char outname[PATH_MAX];
+
+ test_init(argc, argv);
+ if (argc != 2)
+ CONFIG("Usage: %s <dtb file>", argv[0]);
+
+ inname = argv[1];
+ fdt = load_blob(argv[1]);
+ sprintf(outname, "noppy.%s", inname);
+
+ if (fdt_version(fdt) < 17)
+ FAIL("Can't deal with version <17");
+
+ buf = xmalloc(2 * fdt_size_dt_struct(fdt));
+
+ newsize = nopulate_struct(buf, fdt);
+
+ verbose_printf("Nopulated structure block has new size %d\n", newsize);
+
+ /* Replace old strcutre block with the new */
+
+ fdt2 = xmalloc(fdt_totalsize(fdt) + newsize);
+
+ struct_start = fdt_off_dt_struct(fdt);
+ delta = newsize - fdt_size_dt_struct(fdt);
+ struct_end_old = struct_start + fdt_size_dt_struct(fdt);
+ struct_end_new = struct_start + newsize;
+
+ memcpy(fdt2, fdt, struct_start);
+ memcpy(fdt2 + struct_start, buf, newsize);
+ memcpy(fdt2 + struct_end_new, fdt + struct_end_old,
+ fdt_totalsize(fdt) - struct_end_old);
+
+ fdt_set_totalsize(fdt2, fdt_totalsize(fdt) + delta);
+ fdt_set_size_dt_struct(fdt2, newsize);
+
+ if (fdt_off_mem_rsvmap(fdt) > struct_start)
+ fdt_set_off_mem_rsvmap(fdt2, fdt_off_mem_rsvmap(fdt) + delta);
+ if (fdt_off_dt_strings(fdt) > struct_start)
+ fdt_set_off_dt_strings(fdt2, fdt_off_dt_strings(fdt) + delta);
+
+ save_blob(outname, fdt2);
+
+ PASS();
+}
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2008-02-14 16:49:55.000000000 +1100
+++ dtc/tests/Makefile.tests 2008-02-14 17:01:10.000000000 +1100
@@ -7,7 +7,7 @@
notfound \
setprop_inplace nop_property nop_node \
sw_tree1 \
- move_and_save mangle-layout \
+ move_and_save mangle-layout nopulate \
open_pack rw_tree1 set_name setprop del_property del_node \
string_escapes references path-references \
dtbs_equal_ordered \
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2008-02-14 16:49:55.000000000 +1100
+++ dtc/tests/run_tests.sh 2008-02-14 17:01:10.000000000 +1100
@@ -126,6 +126,13 @@
tree1_tests rw_tree1.test.dtb
tree1_tests_rw rw_tree1.test.dtb
+ for basetree in test_tree1.dtb sw_tree1.test.dtb rw_tree1.test.dtb; do
+ run_test nopulate $basetree
+ run_test dtbs_equal_ordered $basetree noppy.$basetree
+ tree1_tests noppy.$basetree
+ tree1_tests_rw noppy.$basetree
+ done
+
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
--
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 1/8] pseries: phyp dump: Documentation
From: Manish Ahuja @ 2008-02-18 5:34 UTC (permalink / raw)
To: ppc-dev, paulus, Linas Vepstas; +Cc: mahuja
In-Reply-To: <47B90F55.2080606@austin.ibm.com>
Basic documentation for hypervisor-assisted dump.
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
----
Documentation/powerpc/phyp-assisted-dump.txt | 127 +++++++++++++++++++++++++++
1 file changed, 127 insertions(+)
Index: 2.6.25-rc1/Documentation/powerpc/phyp-assisted-dump.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6.25-rc1/Documentation/powerpc/phyp-assisted-dump.txt 2008-02-18 03:22:33.000000000 -0600
@@ -0,0 +1,127 @@
+
+ Hypervisor-Assisted Dump
+ ------------------------
+ November 2007
+
+The goal of hypervisor-assisted dump is to enable the dump of
+a crashed system, and to do so from a fully-reset system, and
+to minimize the total elapsed time until the system is back
+in production use.
+
+As compared to kdump or other strategies, hypervisor-assisted
+dump offers several strong, practical advantages:
+
+-- Unlike kdump, the system has been reset, and loaded
+ with a fresh copy of the kernel. In particular,
+ PCI and I/O devices have been reinitialized and are
+ in a clean, consistent state.
+-- As the dump is performed, the dumped memory becomes
+ immediately available to the system for normal use.
+-- After the dump is completed, no further reboots are
+ required; the system will be fully usable, and running
+ in it's normal, production mode on it normal kernel.
+
+The above can only be accomplished by coordination with,
+and assistance from the hypervisor. The procedure is
+as follows:
+
+-- When a system crashes, the hypervisor will save
+ the low 256MB of RAM to a previously registered
+ save region. It will also save system state, system
+ registers, and hardware PTE's.
+
+-- After the low 256MB area has been saved, the
+ hypervisor will reset PCI and other hardware state.
+ It will *not* clear RAM. It will then launch the
+ bootloader, as normal.
+
+-- The freshly booted kernel will notice that there
+ is a new node (ibm,dump-kernel) in the device tree,
+ indicating that there is crash data available from
+ a previous boot. It will boot into only 256MB of RAM,
+ reserving the rest of system memory.
+
+-- Userspace tools will parse /sys/kernel/release_region
+ and read /proc/vmcore to obtain the contents of memory,
+ which holds the previous crashed kernel. The userspace
+ tools may copy this info to disk, or network, nas, san,
+ iscsi, etc. as desired.
+
+ For Example: the values in /sys/kernel/release-region
+ would look something like this (address-range pairs).
+ CPU:0x177fee000-0x10000: HPTE:0x177ffe020-0x1000: /
+ DUMP:0x177fff020-0x10000000, 0x10000000-0x16F1D370A
+
+-- As the userspace tools complete saving a portion of
+ dump, they echo an offset and size to
+ /sys/kernel/release_region to release the reserved
+ memory back to general use.
+
+ An example of this is:
+ "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
+ which will release 256MB at the 1GB boundary.
+
+Please note that the hypervisor-assisted dump feature
+is only available on Power6-based systems with recent
+firmware versions.
+
+Implementation details:
+----------------------
+
+During boot, a check is made to see if firmware supports
+this feature on this particular machine. If it does, then
+we check to see if a active dump is waiting for us. If yes
+then everything but 256 MB of RAM is reserved during early
+boot. This area is released once we collect a dump from user
+land scripts that are run. If there is dump data, then
+the /sys/kernel/release_region file is created, and
+the reserved memory is held.
+
+If there is no waiting dump data, then only the highest
+256MB of the ram is reserved as a scratch area. This area
+is *not* be released: this region will be kept permanently
+reserved, so that it can act as a receptacle for a copy
+of the low 256MB in the case a crash does occur. See,
+however, "open issues" below, as to whether
+such a reserved region is really needed.
+
+Currently the dump will be copied from /proc/vmcore to a
+a new file upon user intervention. The starting address
+to be read and the range for each data point in provided
+in /sys/kernel/release_region.
+
+The tools to examine the dump will be same as the ones
+used for kdump.
+
+General notes:
+--------------
+Security: please note that there are potential security issues
+with any sort of dump mechanism. In particular, plaintext
+(unencrypted) data, and possibly passwords, may be present in
+the dump data. Userspace tools must take adequate precautions to
+preserve security.
+
+Open issues/ToDo:
+------------
+ o The various code paths that tell the hypervisor that a crash
+ occurred, vs. it simply being a normal reboot, should be
+ reviewed, and possibly clarified/fixed.
+
+ o Instead of using /sys/kernel, should there be a /sys/dump
+ instead? There is a dump_subsys being created by the s390 code,
+ perhaps the pseries code should use a similar layout as well.
+
+ o Is reserving a 256MB region really required? The goal of
+ reserving a 256MB scratch area is to make sure that no
+ important crash data is clobbered when the hypervisor
+ save low mem to the scratch area. But, if one could assure
+ that nothing important is located in some 256MB area, then
+ it would not need to be reserved. Something that can be
+ improved in subsequent versions.
+
+ o Still working the kdump team to integrate this with kdump,
+ some work remains but this would not affect the current
+ patches.
+
+ o Still need to write a shell script, to copy the dump away.
+ Currently I am parsing it manually.
^ permalink raw reply
* [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Manish Ahuja @ 2008-02-18 5:36 UTC (permalink / raw)
To: ppc-dev, paulus, Linas Vepstas; +Cc: mahuja
In-Reply-To: <47B90F55.2080606@austin.ibm.com>
Initial patch for reserving memory in early boot, and freeing it later.
If the previous boot had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
----
arch/powerpc/kernel/prom.c | 49 ++++++++++++++++++++
arch/powerpc/kernel/rtas.c | 34 +++++++++++++
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/phyp_dump.c | 71 +++++++++++++++++++++++++++++
include/asm-powerpc/phyp_dump.h | 38 +++++++++++++++
include/asm-powerpc/rtas.h | 3 +
6 files changed, 196 insertions(+)
Index: 2.6.25-rc1/include/asm-powerpc/phyp_dump.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6.25-rc1/include/asm-powerpc/phyp_dump.h 2008-02-18 04:30:28.000000000 -0600
@@ -0,0 +1,38 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2008
+ * Copyright 2008 IBM Corp.
+ *
+ * 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 of the License, or (at your option) any later version.
+ */
+
+#ifndef _PPC64_PHYP_DUMP_H
+#define _PPC64_PHYP_DUMP_H
+
+#ifdef CONFIG_PHYP_DUMP
+
+/* The RMR region will be saved for later dumping
+ * whenever the kernel crashes. Set this to 256MB. */
+#define PHYP_DUMP_RMR_START 0x0
+#define PHYP_DUMP_RMR_END (1UL<<28)
+
+struct phyp_dump {
+ /* Memory that is reserved during very early boot. */
+ unsigned long init_reserve_start;
+ unsigned long init_reserve_size;
+ /* Check status during boot if dump supported, active & present*/
+ unsigned long phyp_dump_configured;
+ unsigned long phyp_dump_is_active;
+ /* store cpu & hpte size */
+ unsigned long cpu_state_size;
+ unsigned long hpte_region_size;
+};
+
+extern struct phyp_dump *phyp_dump_info;
+
+#endif /* CONFIG_PHYP_DUMP */
+#endif /* _PPC64_PHYP_DUMP_H */
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-18 04:32:17.000000000 -0600
@@ -0,0 +1,71 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2008
+ * Copyright 2008 IBM Corp.
+ *
+ * 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 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/pfn.h>
+#include <linux/swap.h>
+
+#include <asm/page.h>
+#include <asm/phyp_dump.h>
+#include <asm/machdep.h>
+
+/* Global, used to communicate data between early boot and late boot */
+static struct phyp_dump phyp_dump_global;
+struct phyp_dump *phyp_dump_info = &phyp_dump_global;
+
+/**
+ * release_memory_range -- release memory previously lmb_reserved
+ * @start_pfn: starting physical frame number
+ * @nr_pages: number of pages to free.
+ *
+ * This routine will release memory that had been previously
+ * lmb_reserved in early boot. The released memory becomes
+ * available for genreal use.
+ */
+static void
+release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+{
+ struct page *rpage;
+ unsigned long end_pfn;
+ long i;
+
+ end_pfn = start_pfn + nr_pages;
+
+ for (i = start_pfn; i <= end_pfn; i++) {
+ rpage = pfn_to_page(i);
+ if (PageReserved(rpage)) {
+ ClearPageReserved(rpage);
+ init_page_count(rpage);
+ __free_page(rpage);
+ totalram_pages++;
+ }
+ }
+}
+
+static int __init phyp_dump_setup(void)
+{
+ unsigned long start_pfn, nr_pages;
+
+ /* If no memory was reserved in early boot, there is nothing to do */
+ if (phyp_dump_info->init_reserve_size == 0)
+ return 0;
+
+ /* Release memory that was reserved in early boot */
+ start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
+ nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
+ release_memory_range(start_pfn, nr_pages);
+
+ return 0;
+}
+machine_subsys_initcall(pseries, phyp_dump_setup);
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/Makefile 2008-02-18 03:22:06.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/Makefile 2008-02-18 03:23:47.000000000 -0600
@@ -18,3 +18,4 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
+obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
Index: 2.6.25-rc1/arch/powerpc/kernel/prom.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/kernel/prom.c 2008-02-18 03:22:06.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/kernel/prom.c 2008-02-18 03:23:47.000000000 -0600
@@ -51,6 +51,7 @@
#include <asm/machdep.h>
#include <asm/pSeries_reconfig.h>
#include <asm/pci-bridge.h>
+#include <asm/phyp_dump.h>
#include <asm/kexec.h>
#ifdef DEBUG
@@ -1039,6 +1040,51 @@ static void __init early_reserve_mem(voi
#endif
}
+#ifdef CONFIG_PHYP_DUMP
+/**
+ * reserve_crashed_mem() - reserve all not-yet-dumped mmemory
+ *
+ * This routine may reserve memory regions in the kernel only
+ * if the system is supported and a dump was taken in last
+ * boot instance or if the hardware is supported and the
+ * scratch area needs to be setup. In other instances it returns
+ * without reserving anything. The memory in case of dump being
+ * active is freed when the dump is collected (by userland tools).
+ */
+static void __init reserve_crashed_mem(void)
+{
+ unsigned long base, size;
+ if (!phyp_dump_info->phyp_dump_configured) {
+ printk(KERN_ERR "Phyp-dump not supported on this hardware\n");
+ return;
+ }
+
+ if (phyp_dump_info->phyp_dump_is_active) {
+ /* Reserve *everything* above RMR.Area freed by userland tools*/
+ base = PHYP_DUMP_RMR_END;
+ size = lmb_end_of_DRAM() - base;
+
+ /* XXX crashed_ram_end is wrong, since it may be beyond
+ * the memory_limit, it will need to be adjusted. */
+ lmb_reserve(base, size);
+
+ phyp_dump_info->init_reserve_start = base;
+ phyp_dump_info->init_reserve_size = size;
+ } else {
+ size = phyp_dump_info->cpu_state_size +
+ phyp_dump_info->hpte_region_size +
+ PHYP_DUMP_RMR_END;
+ base = lmb_end_of_DRAM() - size;
+ lmb_reserve(base, size);
+ phyp_dump_info->init_reserve_start = base;
+ phyp_dump_info->init_reserve_size = size;
+ }
+}
+#else
+static inline void __init reserve_crashed_mem(void) {}
+#endif /* CONFIG_PHYP_DUMP */
+
+
void __init early_init_devtree(void *params)
{
DBG(" -> early_init_devtree(%p)\n", params);
@@ -1050,6 +1096,8 @@ void __init early_init_devtree(void *par
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
#endif
+ /* scan tree to see if dump occured during last boot */
+ of_scan_flat_dt(early_init_dt_scan_phyp_dump, NULL);
/* Retrieve various informations from the /chosen node of the
* device-tree, including the platform type, initrd location and
@@ -1071,6 +1119,7 @@ void __init early_init_devtree(void *par
reserve_kdump_trampoline();
reserve_crashkernel();
early_reserve_mem();
+ reserve_crashed_mem();
lmb_enforce_memory_limit(memory_limit);
lmb_analyze();
Index: 2.6.25-rc1/arch/powerpc/kernel/rtas.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/kernel/rtas.c 2008-02-18 03:22:06.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/kernel/rtas.c 2008-02-18 03:23:47.000000000 -0600
@@ -39,6 +39,7 @@
#include <asm/syscalls.h>
#include <asm/smp.h>
#include <asm/atomic.h>
+#include <asm/phyp_dump.h>
struct rtas_t rtas = {
.lock = SPIN_LOCK_UNLOCKED
@@ -883,6 +884,39 @@ void __init rtas_initialize(void)
#endif
}
+int __init early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+#ifdef CONFIG_PHYP_DUMP
+ const unsigned int *sizes;
+
+ phyp_dump_info->phyp_dump_configured = 0;
+ phyp_dump_info->phyp_dump_is_active = 0;
+
+ if (depth != 1 || strcmp(uname, "rtas") != 0)
+ return 0;
+
+ if (of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL))
+ phyp_dump_info->phyp_dump_configured++;
+
+ if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
+ phyp_dump_info->phyp_dump_is_active++;
+
+ sizes = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
+ NULL);
+ if (!sizes)
+ return 0;
+
+ if (sizes[0] == 1)
+ phyp_dump_info->cpu_state_size = *((unsigned long *)&sizes[1]);
+
+ if (sizes[3] == 2)
+ phyp_dump_info->hpte_region_size =
+ *((unsigned long *)&sizes[4]);
+#endif
+ return 1;
+}
+
int __init early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data)
{
Index: 2.6.25-rc1/include/asm-powerpc/rtas.h
===================================================================
--- 2.6.25-rc1.orig/include/asm-powerpc/rtas.h 2008-02-18 03:22:06.000000000 -0600
+++ 2.6.25-rc1/include/asm-powerpc/rtas.h 2008-02-18 03:23:47.000000000 -0600
@@ -183,6 +183,9 @@ extern unsigned int rtas_busy_delay(int
extern int early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data);
+int early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data);
+
extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
^ permalink raw reply
* [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Manish Ahuja @ 2008-02-18 5:38 UTC (permalink / raw)
To: ppc-dev, paulus, Linas Vepstas; +Cc: mahuja
In-Reply-To: <47B90F55.2080606@austin.ibm.com>
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x40000000 0x10000000" > /sys/kernel/release_region
will release 256MB starting at the 1GB. The released memory
becomes free for general use.
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
------
arch/powerpc/platforms/pseries/phyp_dump.c | 81 +++++++++++++++++++++++++++--
1 file changed, 76 insertions(+), 5 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-18 03:23:47.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-18 04:32:13.000000000 -0600
@@ -12,18 +12,23 @@
*/
#include <linux/init.h>
+#include <linux/kobject.h>
#include <linux/mm.h>
+#include <linux/of.h>
#include <linux/pfn.h>
#include <linux/swap.h>
+#include <linux/sysfs.h>
#include <asm/page.h>
#include <asm/phyp_dump.h>
#include <asm/machdep.h>
+#include <asm/rtas.h>
/* Global, used to communicate data between early boot and late boot */
static struct phyp_dump phyp_dump_global;
struct phyp_dump *phyp_dump_info = &phyp_dump_global;
+/* ------------------------------------------------- */
/**
* release_memory_range -- release memory previously lmb_reserved
* @start_pfn: starting physical frame number
@@ -53,18 +58,84 @@ release_memory_range(unsigned long start
}
}
-static int __init phyp_dump_setup(void)
+/* ------------------------------------------------- */
+/**
+ * sysfs_release_region -- sysfs interface to release memory range.
+ *
+ * Usage:
+ * "echo <start addr> <length> > /sys/kernel/release_region"
+ *
+ * Example:
+ * "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
+ *
+ * will release 256MB starting at 1GB.
+ */
+static ssize_t store_release_region(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
+ unsigned long start_addr, length, end_addr;
unsigned long start_pfn, nr_pages;
+ ssize_t ret;
+
+ ret = sscanf(buf, "%lx %lx", &start_addr, &length);
+ if (ret != 2)
+ return -EINVAL;
+
+ /* Range-check - don't free any reserved memory that
+ * wasn't reserved for phyp-dump */
+ if (start_addr < phyp_dump_info->init_reserve_start)
+ start_addr = phyp_dump_info->init_reserve_start;
+
+ end_addr = phyp_dump_info->init_reserve_start +
+ phyp_dump_info->init_reserve_size;
+ if (start_addr+length > end_addr)
+ length = end_addr - start_addr;
+
+ /* Release the region of memory assed in by user */
+ start_pfn = PFN_DOWN(start_addr);
+ nr_pages = PFN_DOWN(length);
+ release_memory_range(start_pfn, nr_pages);
+
+ return count;
+}
+
+static struct kobj_attribute rr = __ATTR(release_region, 0600,
+ NULL, store_release_region);
+
+static int __init phyp_dump_setup(void)
+{
+ struct device_node *rtas;
+ const int *dump_header = NULL;
+ int header_len = 0;
+ int rc;
/* If no memory was reserved in early boot, there is nothing to do */
if (phyp_dump_info->init_reserve_size == 0)
return 0;
- /* Release memory that was reserved in early boot */
- start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
- nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
- release_memory_range(start_pfn, nr_pages);
+ /* Return if phyp dump not supported */
+ if (!phyp_dump_info->phyp_dump_configured)
+ return -ENOSYS;
+
+ /* Is there dump data waiting for us? */
+ rtas = of_find_node_by_path("/rtas");
+ if (rtas) {
+ dump_header = of_get_property(rtas, "ibm,kernel-dump",
+ &header_len);
+ of_node_put(rtas);
+ }
+
+ if (dump_header == NULL)
+ return 0;
+
+ /* Should we create a dump_subsys, analogous to s390/ipl.c ? */
+ rc = sysfs_create_file(kernel_kobj, &rr.attr);
+ if (rc) {
+ printk(KERN_ERR "phyp-dump: unable to create sysfs file (%d)\n",
+ rc);
+ return 0;
+ }
return 0;
}
^ 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