_machine removal breaks kexec?

_machine removal breaks kexec?

[Anton Blanchard]

Hi,

It looks like the _machine removal broke kexec:

 # kexec -l vmlinux
 /proc/device-tree/chosen/linux,platform: No such file or directory

The kexec tools seem to want the linux,platform property:

        /* if LPAR, no need to read any more from /chosen */
        if (platform != PLATFORM_PSERIES) {
                closedir(cdir);
                continue;
        }

Anton

Re: _machine removal breaks kexec?

[Benjamin Herrenschmidt]

On Mon, 2006-04-03 at 11:40 +1000, Anton Blanchard wrote:
> Hi,
> 
> It looks like the _machine removal broke kexec:
> 
>  # kexec -l vmlinux
>  /proc/device-tree/chosen/linux,platform: No such file or directory
> 
> The kexec tools seem to want the linux,platform property:
> 
>         /* if LPAR, no need to read any more from /chosen */
>         if (platform != PLATFORM_PSERIES) {
>                 closedir(cdir);
>                 continue;
>         }

Damn.... the platform numbers are gone, we need to fix that. (And nobody
complained when I posted the patch twice over the past couple of monthes
btw).

I suppose kexec needs to look for /rtas/hypertas or such ..

Ben.

Re: _machine removal breaks kexec?

[Kumar Gala]

On Apr 3, 2006, at 11:16 AM, Benjamin Herrenschmidt wrote:

> On Mon, 2006-04-03 at 11:40 +1000, Anton Blanchard wrote:
>> Hi,
>>
>> It looks like the _machine removal broke kexec:
>>
>>  # kexec -l vmlinux
>>  /proc/device-tree/chosen/linux,platform: No such file or directory
>>
>> The kexec tools seem to want the linux,platform property:
>>
>>         /* if LPAR, no need to read any more from /chosen */
>>         if (platform != PLATFORM_PSERIES) {
>>                 closedir(cdir);
>>                 continue;
>>         }
>
> Damn.... the platform numbers are gone, we need to fix that. (And  
> nobody
> complained when I posted the patch twice over the past couple of  
> monthes
> btw).
>
> I suppose kexec needs to look for /rtas/hypertas or such ..

uugh, can we make kexec not depend on something that embedded systems  
would also have.

- k

Re: _machine removal breaks kexec?

[Haren Myneni]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Kumar Gala wrote:

>On Apr 3, 2006, at 11:16 AM, Benjamin Herrenschmidt wrote:
>
>  
>
>>On Mon, 2006-04-03 at 11:40 +1000, Anton Blanchard wrote:
>>    
>>
>>>Hi,
>>>
>>>It looks like the _machine removal broke kexec:
>>>
>>> # kexec -l vmlinux
>>> /proc/device-tree/chosen/linux,platform: No such file or directory
>>>
>>>The kexec tools seem to want the linux,platform property:
>>>
>>>        /* if LPAR, no need to read any more from /chosen */
>>>        if (platform != PLATFORM_PSERIES) {
>>>                closedir(cdir);
>>>                continue;
>>>        }
>>>      
>>>
>>Damn.... the platform numbers are gone, we need to fix that. (And  
>>nobody
>>complained when I posted the patch twice over the past couple of  
>>monthes
>>btw).
>>
>>I suppose kexec needs to look for /rtas/hypertas or such ..
>>    
>>
>
>uugh, can we make kexec not depend on something that embedded systems  
>would also have.
>  
>
Basically, kexec-tools looks the platform property to determine whether 
to read tce-base, tce-size and htab-* properties. The attached patch 
find out the platform info based on /proc/device-tree/chosen/htab-base 
property. Not tested yet.
Kumar,  kexec-tools completely depends on device-tree.  Not sure whether 
the embedded system exports the device-tree.

Thanks
Haren

>- k
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>  
>


[-- Attachment #2: ppc64-kexec-tools-rm-platform-fix.patch --]
[-- Type: text/x-patch, Size: 1621 bytes --]

--- ./kexec-tools-1.101/kexec/arch/ppc64/kexec-ppc64.c.orig	2006-04-07 17:39:08.000000000 -0700
+++ ./kexec-tools-1.101/kexec/arch/ppc64/kexec-ppc64.c	2006-04-07 17:36:34.000000000 -0700
@@ -40,7 +40,7 @@
 
 static struct exclude_range exclude_range[MAX_MEMORY_RANGES];
 static unsigned long long rmo_top;
-static unsigned int platform;
+static unsigned int platform = PLATFORM_PSERIES_LPAR;
 static struct memory_range memory_range[MAX_MEMORY_RANGES];
 static struct memory_range base_memory_range[MAX_MEMORY_RANGES];
 unsigned long long memory_max = 0;
@@ -179,8 +179,13 @@ static int get_devtree_details(unsigned 
 	DIR *dir, *cdir;
 	FILE *file;
 	struct dirent *dentry;
+	struct stat sbuf;
+
 	int n, i = 0;
 
+	if (!stat("/proc/device-tree/chosen/linux,htab-base", &sbuf))
+		platform = PLATFORM_PSERIES;
+
 	if ((dir = opendir(device_tree)) == NULL) {
 		perror(device_tree);
 		return -1;
@@ -201,26 +206,6 @@ static int get_devtree_details(unsigned 
 		}
 
 		if (strncmp(dentry->d_name, "chosen", 6) == 0) {
-			/* get platform details from /chosen node */
-			strcat(fname, "/linux,platform");
-			if ((file = fopen(fname, "r")) == NULL) {
-				perror(fname);
-				closedir(cdir);
-				closedir(dir);
-				return -1;
-			}
-			if (fread(&platform, sizeof(int), 1, file) != 1) {
-				perror(fname);
-				fclose(file);
-				closedir(cdir);
-				closedir(dir);
-				return -1;
-			}
-			fclose(file);
-
-			memset(fname, 0, sizeof(fname));
-			strcpy(fname, device_tree);
-			strcat(fname, dentry->d_name);
 			strcat(fname, "/linux,kernel-end");
 			if ((file = fopen(fname, "r")) == NULL) {
 				perror(fname);

Re: _machine removal breaks kexec?

[Michael Ellerman]

On Mon, 2006-04-03 at 11:18 -0700, Haren Myneni wrote:
> Basically, kexec-tools looks the platform property to determine whether 
> to read tce-base, tce-size and htab-* properties. The attached patch 
> find out the platform info based on /proc/device-tree/chosen/htab-base 
> property. Not tested yet.

Why don't we get rid of the platform variable entirely in kexec-ppc64.c,
if the tce-* and htab-* properties are there, then we read them, if not
we don't.

There's also:

if (platform == PLATFORM_PSERIES) {
        if (rmo_top > 0x30000000UL)
                rmo_top = 0x30000000UL;
}

I'm not sure where that number comes from, perhaps we need to export the
RMO value like we do for the htab?

While we're there that code could use a function to read
a /proc/device-tree file and do error handling, there's a lot of
duplicate code at the moment.

cheers

-- 
Michael Ellerman
IBM OzLabs

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

Re: _machine removal breaks kexec?

[Haren Myneni]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

linuxppc-dev-bounces+hbabu=us.ibm.com@ozlabs.org wrote on 04/03/2006 
10:40:48 PM:

> On Mon, 2006-04-03 at 11:18 -0700, Haren Myneni wrote:
> > Basically, kexec-tools looks the platform property to determine 
whether 
> > to read tce-base, tce-size and htab-* properties. The attached patch 
> > find out the platform info based on /proc/device-tree/chosen/htab-base 

> > property. Not tested yet.
> 
> Why don't we get rid of the platform variable entirely in kexec-ppc64.c,
> if the tce-* and htab-* properties are there, then we read them, if not
> we don't.

> 
> There's also:
> 
> if (platform == PLATFORM_PSERIES) {
>         if (rmo_top > 0x30000000UL)
>                 rmo_top = 0x30000000UL;
> }
> 
> I'm not sure where that number comes from, perhaps we need to export the
> RMO value like we do for the htab?

Yes, we can remove this PLATFORM_* and read these properties if exists. I 
believe, this large number is copied from prom_init.c. I am not sure 
whether exporting rmo_top is needed since it is always the size of first 
memory node unless the size is greater than 0x30000000UL. PLATFORM_PSERIES 
is not needed anyway for this comparison.


> 
> While we're there that code could use a function to read
> a /proc/device-tree file and do error handling, there's a lot of
> duplicate code at the moment.
> 
Yes, there is some cleanup needed in kexec-tools.

Thanks
Haren

> cheers
> 
> -- 
> Michael Ellerman
> IBM OzLabs
> 
> 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
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

[-- Attachment #2: Type: text/html, Size: 2432 bytes --]

Re: _machine removal breaks kexec?

[Benjamin Herrenschmidt]

> Basically, kexec-tools looks the platform property to determine whether 
> to read tce-base, tce-size and htab-* properties. The attached patch 
> find out the platform info based on /proc/device-tree/chosen/htab-base 
> property. Not tested yet.

You should just test if the properties exist ...

> Kumar,  kexec-tools completely depends on device-tree.  Not sure whether 
> the embedded system exports the device-tree.

With arch=powerpc, they do

Re: _machine removal breaks kexec?

[Segher Boessenkool]

>> I suppose kexec needs to look for /rtas/hypertas or such ..
>
> uugh, can we make kexec not depend on something that embedded systems
> would also have.

You have embedded systems with a hypervisor?  And, a /hypertas node
even?


Segher

Re: _machine removal breaks kexec?

[Kumar Gala]

On Apr 3, 2006, at 6:16 PM, Segher Boessenkool wrote:

>>> I suppose kexec needs to look for /rtas/hypertas or such ..
>>
>> uugh, can we make kexec not depend on something that embedded systems
>> would also have.
>
> You have embedded systems with a hypervisor?  And, a /hypertas node
> even?

no and no.  However, I dont see any reason kexec should be available  
on embedded PPCs.

- k

Re: _machine removal breaks kexec?

[Benjamin Herrenschmidt]

> uugh, can we make kexec not depend on something that embedded systems  
> would also have.

Embedded systems will have hypertas ? ugh ..

Ben.