* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-12 18:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <47B1BEE7.4050808@freescale.com>
On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
> Arnd Bergmann wrote:
>
> > On Tuesday 12 February 2008, David Gibson wrote:
> >> Or to expand. It's relatively easy now to just include multiple nodes
> >> in the tree and either delete or nop some of them out conditionally
> >> using libfdt.
>
> Yes, but what better place to store the conditions than in the device tree
> itself? How would libfdt know where the conditions are? Do you want to have
> two binary blobs?
The transient state of the dts before it is handed to the kernel
proper is almost irrelevant. It is totally reasonable to add in
whatever properties/nodes that are needed to *eventually* describe the
hardware correctly. Heck, we already do this will all dts files that
go through u-boot is a simple sense. We put placeholder properties
for mac addresses and bus frequencies, but u-boot fills them in.
However, if a designer does write a device tree containing more nodes
than is needed, then it is also the responsibility of that designer to
make sure the boot loader can use that tree to generate a real
description of hardware. This requires coordination and
documentation, but id does not requires special formatting or
versioning of the device tree blob.
The dtb is a data structure, not a programming language. I think it
is a slippery slope to try and encode conditionals into the structure;
but it is entirely reasonable to encode *data* into the dt that helps
make those conditional decisions.
> >> But the conditional logic should be in the manipulating
> >> agent (u-boot or bootwrapper or whatever), there's no way we're going
> >> to require a conditional expression parser to interpret the device
> >> tree blob itself.
>
> I think it's a great feature that solves a lot of problems, and it does so in an
> elegant and efficient manner. I look forward to trying to change your mind when
> I get around to implementing it.
I agree with David here; logic belongs in the agent code, not the data
structure.
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
>
> The problem with this is that if you use a version of libfdt that does not
> understand "linux,conditional-node", then your device tree will be wrong,
> because it could contain nodes that don't belong. We would need a new,
> incompatible version number for the device tree to make sure that this doesn't
> happen, even though nothing has changed in the binary layout of the tree.
We've already got that issue. If you pass the device tree for the
wrong board it will still validate correctly, but the board is not
going to boot. The device tree must match what the bootloader
expects. Changing the version number will do nothing to help this.
The version number ensures that the tree is parsable. It does not
ensure that it is correct.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Manish Ahuja @ 2008-02-12 16:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080212210818.7b9099a4.sfr@canb.auug.org.au>
As noted, its fixed in patch 4.
If its okay for this time, I will prefer to leave it there.
-Manish
Stephen Rothwell wrote:
> Hi Manish,
>
> Just a small comment.
>
> On Tue, 12 Feb 2008 01:11:58 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>> + /* Is there dump data waiting for us? */
>> + rtas = of_find_node_by_path("/rtas");
>> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
>
> You need an of_node_put(rtas) here.
>
>> + if (dump_header == NULL) {
>> + release_all();
>> + return 0;
>> + }
>
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Scott Wood @ 2008-02-12 18:52 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47B0EB23.9040101@pikatech.com>
On Mon, Feb 11, 2008 at 07:41:07PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > Err.. now I'm doubly confused. Initially I thought you'd need to
> > change the size part of reg somewhere, but your description above just
> > convinced me you didn't (because you were essentially just shifting a
> > 4M map up into the high rather than low 4M of the 64M space). Now
> > you're saying you do..
> >
> If you tell the mtd driver that the flash is 64M, when it is really 4M,
> it goes oops. So you do have to get the size right in the reg field.
It'd be nice if we could pass in a flag to tell it not to try to find
additional consecutive chips in the mapping... It's a shame to have
probable chips, and still have to know how big they are anyway.
-Scott
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Scott Wood @ 2008-02-12 18:51 UTC (permalink / raw)
To: Arnd Bergmann, Timur Tabi, linuxppc-dev
In-Reply-To: <20080212003633.GF18348@localhost.localdomain>
On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
> On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
> > On Tuesday 12 February 2008, David Gibson wrote:
> > > Or to expand. It's relatively easy now to just include multiple nodes
> > > in the tree and either delete or nop some of them out conditionally
> > > using libfdt. But the conditional logic should be in the manipulating
> > > agent (u-boot or bootwrapper or whatever), there's no way we're going
> > > to require a conditional expression parser to interpret the device
> > > tree blob itself.
> >
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
> > In Sean's example, you can have linux,conditional-node="Rev.A" in
> > some nodes and linux,conditional-node="Rev.B" in others, then
> > knock out all devices that have a non-matching linux,conditional-node
> > property, and finally remove the properties themselves before starting
> > the kernel.
>
> Well, that's basically a u-boot issue. If they want to do their input
> trees that way, and have helper functions that deal with it...
The actual mechanism that we originially discussed, which Timur later
morphed into conditions-on-nodes, was to have a separate hwoptions node,
under which would be described various hwoptions (jumpers and such) whose
state could be either detected by u-boot or set by environment variable.
Each hwoption setting would contain a device tree fragment to be merged into
the main device tree.
-Scott
^ permalink raw reply
* Re: DTS question - MPC5200b
From: Grant Likely @ 2008-02-12 18:28 UTC (permalink / raw)
To: Nick; +Cc: linuxppc-dev
In-Reply-To: <47B1D943.6020708@rogers.com>
On Feb 12, 2008 10:37 AM, Nick <ndroogh@rogers.com> wrote:
> Hi,
>
> I need some help. I am trying to access timer 7 on the MPC5200B
> processor. I have the DTS file setup like this
>
> gpt@670 { // General Purpose Timer
> device_type = "gpt";
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <7>;
> reg = <670 10>;
> interrupts = <1 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> I have timers 0 to 6 defined the same way except the cell-index reflects
> the timer number.
>
> In my platform file where I am doing my board setup, I tried the following.
>
> timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");
Don't use find_and_map; it was a stupid API that I never should have written.
Instead, use for_each_compatible_node() or for_each_matching_node() to
iterate over them until you find the one with the correct reg address.
Then you can use of_iomap() to map the device registers.
> How do I specify the timer based on the cell-index?
Match on the reg property instead of cell-index; I'll probably be
dropping the cell-index property from future 5200 device trees because
it just ends up duplicating information already provided by reg.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-12 18:04 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
In-Reply-To: <200802111724.12416.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
>
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.net/lists/netdev/msg54484.html
This driver is broken pretty horribly. It won't even compile for a
plain ppc64 kernel:
http://sr71.net/~dave/linux/ehea-is-broken.config
I know it's used for very specific hardware, but this is the symptom of
it not using the proper abstracted interfaces to the VM.
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
CC drivers/net/mii.o
make[4]: *** [drivers/net/ehea/ehea_main.o] Error 1
make[4]: *** Waiting for unfinished jobs....
CC drivers/net/ixgb/ixgb_param.o
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:32:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: 'NR_MEM_SECTIONS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: (Each undeclared identifier is reported only once
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: for each function it appears in.)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:575: error: implicit declaration of function 'valid_section_nr'
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_map_vaddr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:606: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_reg_kernel_mr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:655: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
-- Dave
^ permalink raw reply
* Re: [PATCH 4/8] pseries: phyp dump: register dump area.
From: Manish Ahuja @ 2008-02-12 16:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080212211154.f641abac.sfr@canb.auug.org.au>
For now, if we can leave this patch as is, that will be great. That move requires me
to work all remaining patches as they apply uncleanly after that.
I will bunch those two together functionally next time onwards.
Thanks,
Manish
Stephen Rothwell wrote:
> Hi Manish,
>
>> - /* Is there dump data waiting for us? */
>> + /* Is there dump data waiting for us? If there isn't,
>> + * then register a new dump area, and release all of
>> + * the rest of the reserved ram.
>> + *
>> + * The /rtas/ibm,kernel-dump rtas node is present only
>> + * if there is dump data waiting for us.
>> + */
>> rtas = of_find_node_by_path("/rtas");
>> dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
>> + of_node_put(rtas);
>
> Oh, here is the of_node_put() - you should move that to patch 3.
>
^ permalink raw reply
* DTS question - MPC5200b
From: Nick @ 2008-02-12 17:37 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I need some help. I am trying to access timer 7 on the MPC5200B
processor. I have the DTS file setup like this
gpt@670 { // General Purpose Timer
device_type = "gpt";
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <7>;
reg = <670 10>;
interrupts = <1 10 0>;
interrupt-parent = <&mpc5200_pic>;
};
I have timers 0 to 6 defined the same way except the cell-index reflects
the timer number.
In my platform file where I am doing my board setup, I tried the following.
timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");
How do I specify the timer based on the cell-index?
Thanks
Nick
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 15:44 UTC (permalink / raw)
To: Arnd Bergmann, David Gibson; +Cc: linuxppc-dev
In-Reply-To: <200802120121.45349.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 12 February 2008, David Gibson wrote:
>> Or to expand. It's relatively easy now to just include multiple nodes
>> in the tree and either delete or nop some of them out conditionally
>> using libfdt.
Yes, but what better place to store the conditions than in the device tree
itself? How would libfdt know where the conditions are? Do you want to have
two binary blobs?
>> But the conditional logic should be in the manipulating
>> agent (u-boot or bootwrapper or whatever), there's no way we're going
>> to require a conditional expression parser to interpret the device
>> tree blob itself.
I think it's a great feature that solves a lot of problems, and it does so in an
elegant and efficient manner. I look forward to trying to change your mind when
I get around to implementing it.
> How about making the logic to nop out nodes a little more generic
> without changes to the binary format?
> E.g. you could have a "linux,conditional-node" property in the device
> tree whose value is compared to a HW configuration specific string.
The problem with this is that if you use a version of libfdt that does not
understand "linux,conditional-node", then your device tree will be wrong,
because it could contain nodes that don't belong. We would need a new,
incompatible version number for the device tree to make sure that this doesn't
happen, even though nothing has changed in the binary layout of the tree.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* RE: [Virtex 4 PPC] Problem mountin rootfs via NFS
From: IngoM @ 2008-02-12 15:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <EE63F03D9E04774997AEBCD21FC77F25190363@ccomm-ex1.ccomm.com>
Hi,
Sugathan, Rupesh wrote:
>
> <snip>
>
> Do you have a 'console' device file set up in your NFS rootfilesystem?
>
> Thanks
> --
> Rupesh Sugathan
>
you are right.
I'm adding the device and can login via console.
But some trouble is left:
connected the board via a swich to the PC I loss packets, connectet directly
there are no packets lost.
Any hints?
Best Regards,
Ingo
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Problem-mountin-rootfs-via-NFS-tp15355858p15434487.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: libfdt: Add and use a node iteration helper function.
From: Jon Loeliger @ 2008-02-12 15:15 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080212005831.GH18348@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds an fdt_next_node() function which can be used to
> iterate through nodes of the tree while keeping track of depth. This
> function is used to simplify the iteration code in a lot of other
> functions, and is also exported for use by library users.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> ---
>
> I think we're ready to go with this one. I'm still thinking about
> suitable for_each_* macros, but in the mean time I'm happy with the
> exported interface here, and it's a code-reducing patch.
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: Writing drivers for external IP cores
From: Grant Likely @ 2008-02-12 14:56 UTC (permalink / raw)
To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47B188F5.60607@gmail.com>
On Feb 12, 2008 4:54 AM, A. Nolson <alohanono@gmail.com> wrote:
> Hi ,
>
> I am going to start developing some IP cores for my virtex fx12 (ML403)
> and I need to control them through my embedded Linux ( it is already
> working in the ppc405 ). I am a bit lost and I need some references for
> developing drivers. In principle, I will start with something like a
> GPIO. I think an example like a driver for controlling the push buttons
> of my Ml403 will be enough. An example IP core for that will also be
> also very helpful.
After you've got through the examples in Linux Device Drivers v3, you
can take a look at drivers/video/xilinxfb.c for an example of a driver
that works with an FPGA ip core. Unfortunately there isn't a simple
xilinx GPIO driver in the mainline kernel at the moment, otherwise I'd
point you there.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: populate_rootfs fail
From: Marco Stornelli @ 2008-02-12 12:46 UTC (permalink / raw)
To: jay_chen; +Cc: linuxppc-embedded
In-Reply-To: <OF66FDCEB1.DBBF4F1E-ON482573ED.0030E325@alphanetworks.com>
jay_chen ha scritto:
> Hello all:
>
> I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
> When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
> (I pass mem=2048M to kernel in uboot now)
>
> It always dies in exec sys_write( ) in populate_rootfs( ).
> I did more tests about this and I found that sys_write( ) could write only
> about 4MB in 2G ram case.
> (My initrd is about 19MB, initrd_start : 0xCE7C7000, initrd_end :
> 0xCFAAF289, initrd_end - initrd_start : 0x012E8289 ==> about 19MB)
> Could anybody give me some hints?
> Is this issue related to the location of "/initrd.image"? Could I control
> it?
> Is there any size limit in ppc arch about ramdisk/initrd?
>
> Thanks for help.
>
> Jay...
>
> void __init populate_rootfs(void)
> {
> char *err;
> ...
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> ...
> printk("it isn't (%s); looks like an initrd\n", err);
> fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
> if (fd >= 0) {
> sys_write(fd, (char *)initrd_start,
> initrd_end - initrd_start);
> sys_close(fd);
> free_initrd();
> }
> }
> #endif
> }
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I think can be a problem with the u-boot initrd_high option. Have you
been enabled the highmem support to use 2G of ram, right? You can try to
set this option to 0x30000000.
Marco
^ permalink raw reply
* Re: Writing drivers for external IP cores
From: Marco Stornelli @ 2008-02-12 12:35 UTC (permalink / raw)
To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47B188F5.60607@gmail.com>
A. Nolson ha scritto:
> Hi ,
>
> I am going to start developing some IP cores for my virtex fx12 (ML403)
> and I need to control them through my embedded Linux ( it is already
> working in the ppc405 ). I am a bit lost and I need some references for
> developing drivers. In principle, I will start with something like a
> GPIO. I think an example like a driver for controlling the push buttons
> of my Ml403 will be enough. An example IP core for that will also be
> also very helpful.
>
> Any suggestion?
>
> Thanks in advance
>
> /A
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
A good book to write device drivers is "Linux device drivers" 3rd
edition, it's free and you can download it freely from Internet
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Gabriel Paubert @ 2008-02-12 12:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212114905.GA9940@iram.es>
On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote:
> On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> > >
> > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> >
> > Interesting... I was thinking about doing a full remove of the device at
> > a higher level instead but I suppose what you propose is easier.
>
> Well, I have serious problem on a Pegasos which appeared some time
> between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of
>
> hdb: empty DMA table?
>
> I'm trying to bisect it right now.
Argh, the first bisect point ended up with timeouts on hdb...
Flagged as bad, to try to see when the problems started, but
I suspect that there are several.
Gabriel
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Gabriel Paubert @ 2008-02-12 11:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <1202460043.7079.157.camel@pasglop>
On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > - couple of fixes and preparatory patches
> >
> > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
>
> Interesting... I was thinking about doing a full remove of the device at
> a higher level instead but I suppose what you propose is easier.
Well, I have serious problem on a Pegasos which appeared some time
between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of
hdb: empty DMA table?
I'm trying to bisect it right now.
Gabriel
>
> I'll have a look & test next week hopefully.
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Writing drivers for external IP cores
From: A. Nolson @ 2008-02-12 11:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
I am going to start developing some IP cores for my virtex fx12 (ML403)
and I need to control them through my embedded Linux ( it is already
working in the ppc405 ). I am a bit lost and I need some references for
developing drivers. In principle, I will start with something like a
GPIO. I think an example like a driver for controlling the push buttons
of my Ml403 will be enough. An example IP core for that will also be
also very helpful.
Any suggestion?
Thanks in advance
/A
^ permalink raw reply
* Re: [PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
From: Stephen Rothwell @ 2008-02-12 10:18 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B1483E.8040303@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hi Manish,
On Tue, 12 Feb 2008 01:18:22 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> -static void
> -release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +static
> +void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
Cosmetic changes like this should normally be put in separate patch as
they just distract from a real review (which this isn't :-))
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] pseries: phyp dump: register dump area.
From: Stephen Rothwell @ 2008-02-12 10:11 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B14760.2030001@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Hi Manish,
> - /* Is there dump data waiting for us? */
> + /* Is there dump data waiting for us? If there isn't,
> + * then register a new dump area, and release all of
> + * the rest of the reserved ram.
> + *
> + * The /rtas/ibm,kernel-dump rtas node is present only
> + * if there is dump data waiting for us.
> + */
> rtas = of_find_node_by_path("/rtas");
> dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
> + of_node_put(rtas);
Oh, here is the of_node_put() - you should move that to patch 3.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Stephen Rothwell @ 2008-02-12 10:08 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B146BE.5010807@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
Hi Manish,
Just a small comment.
On Tue, 12 Feb 2008 01:11:58 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> + /* Is there dump data waiting for us? */
> + rtas = of_find_node_by_path("/rtas");
> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
You need an of_node_put(rtas) here.
> + if (dump_header == NULL) {
> + release_all();
> + return 0;
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [Spam Mail] populate_rootfs fail (This message should be blocked: ctfkl59804)
From: jay_chen @ 2008-02-12 9:36 UTC (permalink / raw)
To: linuxppc-embedded-bounces+jay_chen=alphanetworks.com,
linuxppc-embedded
In-Reply-To: <OF66FDCEB1.DBBF4F1E-ON482573ED.0030E325@alphanetworks.com>
One more thing:
I had changed default ramdisk size to about 80MB in kernel config.
(CONFIG_BLK_DEV_RAM_SIZE)
I am so curious about the size limit and location in ram of "/initrd.image".
Which c file/document should I read?
Jay...
-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org]
Sent: Tuesday, February 12, 2008 4:54 PM
To: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] populate_rootfs fail (This message should be blocked:
ctfkl59804)
Hello all:
I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
(I pass mem=2048M to kernel in uboot now)
It always dies in exec sys_write( ) in populate_rootfs( ).
I did more tests about this and I found that sys_write( ) could write only
about 4MB in 2G ram case.
(My initrd is about 19MB, initrd_start : 0xCE7C7000, initrd_end :
0xCFAAF289, initrd_end - initrd_start : 0x012E8289 ==> about 19MB) Could
anybody give me some hints?
Is this issue related to the location of "/initrd.image"? Could I control
it?
Is there any size limit in ppc arch about ramdisk/initrd?
Thanks for help.
Jay...
void __init populate_rootfs(void)
{
char *err;
...
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start) {
...
printk("it isn't (%s); looks like an initrd\n", err);
fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
if (fd >= 0) {
sys_write(fd, (char *)initrd_start,
initrd_end - initrd_start);
sys_close(fd);
free_initrd();
}
}
#endif
}
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* populate_rootfs fail
From: jay_chen @ 2008-02-12 8:53 UTC (permalink / raw)
To: linuxppc-embedded
Hello all:
I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
(I pass mem=2048M to kernel in uboot now)
It always dies in exec sys_write( ) in populate_rootfs( ).
I did more tests about this and I found that sys_write( ) could write only
about 4MB in 2G ram case.
(My initrd is about 19MB, initrd_start : 0xCE7C7000, initrd_end :
0xCFAAF289, initrd_end - initrd_start : 0x012E8289 ==> about 19MB)
Could anybody give me some hints?
Is this issue related to the location of "/initrd.image"? Could I control
it?
Is there any size limit in ppc arch about ramdisk/initrd?
Thanks for help.
Jay...
void __init populate_rootfs(void)
{
char *err;
...
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start) {
...
printk("it isn't (%s); looks like an initrd\n", err);
fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
if (fd >= 0) {
sys_write(fd, (char *)initrd_start,
initrd_end - initrd_start);
sys_close(fd);
free_initrd();
}
}
#endif
}
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-02-12 8:48 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B145E9.9020907@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
On Tue, 2008-02-12 at 01:08 -0600, Manish Ahuja wrote:
> 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 <linas@austin.ibm.com>
>
> ----
> arch/powerpc/kernel/prom.c | 50 ++++++++++++++++++++
> arch/powerpc/kernel/rtas.c | 32 +++++++++++++
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/phyp_dump.c | 71 +++++++++++++++++++++++++++++
> include/asm-powerpc/phyp_dump.h | 38 +++++++++++++++
> include/asm/rtas.h | 3 +
^^^^^^^^^^^^^^^^^^
asm/rtas.h doesn't exist. You need to clean your tree, and patch
asm-powerpc/rtas.h instead.
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: [BUG] 2.6.25-rc1-git1 softlockup while bootup on powerpc
From: Ingo Molnar @ 2008-02-12 7:58 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Dhaval Giani, Jens Axboe, Srivatsa Vaddagiri, LKML, linuxppc-dev,
Balbir Singh
In-Reply-To: <47B1463E.1070809@linux.vnet.ibm.com>
* Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> While booting with the 2.6.25-rc1-git1 kernel on the powerbox the
> softlockup is seen, with following trace.
> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:377]
> TASK = c00000077cb2f0e0[377] 'insmod' THREAD: c00000077cb28000 CPU: 1
> NIP [c0000000001b172c] .radix_tree_gang_lookup+0xdc/0x1e4
> LR [c0000000001a6f00] .call_for_each_cic+0x50/0x10c
> Call Trace:
> [c00000077cb2bb20] [c0000000001a6f60] .call_for_each_cic+0xb0/0x10c (unreliable)
> [c00000077cb2bc60] [c00000000019ecd8] .exit_io_context+0xf0/0x110
> [c00000077cb2bcf0] [c00000000006254c] .do_exit+0x820/0x850
> [c00000077cb2bda0] [c000000000062648] .do_group_exit+0xcc/0xe8
> [c00000077cb2be30] [c00000000000872c] syscall_exit+0x0/0x40
this call_for_each_cic/radix_tree_gang_lookup locked up, and all other
CPUs deadlocked in stopmachine, due to this one.
call_for_each_cic is in ./block/cfq-iosched.c uses RCU, but you've got
classic-RCU:
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set
so it's not related to the preempt-RCU changes either.
It is this part that locks up:
do {
...
nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
index, CIC_GANG_NR);
...
} while (nr == CIC_GANG_NR);
...
it seems the radix tree will yield new entries again and again. Either
it got corrupted, or some other CPU is filling it faster than we can
deplete it [unlikely i think].
Ingo
^ permalink raw reply
* [PATCH 8/8] pseries: phyp dump: config file
From: Manish Ahuja @ 2008-02-12 7:21 UTC (permalink / raw)
To: linuxppc-dev, paulus; +Cc: mahuja, linasvepstas, lkessler, strosake
In-Reply-To: <47B13D2E.1070001@austin.ibm.com>
Add hypervisor-assisted dump to kernel config
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
-----
arch/powerpc/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: 2.6.24-rc5/arch/powerpc/Kconfig
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/Kconfig 2008-02-12 06:12:08.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/Kconfig 2008-02-12 06:13:24.000000000 -0600
@@ -266,6 +266,17 @@ config CRASH_DUMP
Don't change this unless you know what you are doing.
+config PHYP_DUMP
+ bool "Hypervisor-assisted dump (EXPERIMENTAL)"
+ depends on PPC_PSERIES && EXPERIMENTAL
+ default y
+ help
+ Hypervisor-assisted dump is meant to be a kdump replacement
+ offering robustness and speed not possible without system
+ hypervisor assistence.
+
+ If unsure, say "Y"
+
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
default y if PPC_PREP
^ 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