Re: Fw: x86 build issue with software suspend code

Re: Fw: x86 build issue with software suspend code

[Pavel Machek]

Hi!

> >I can't find anything about nosave section in cpu.c... Can you quote
> it?
> 
> Ah, I see. This is the only piece I didn't double-check against the
> 2.6.8.1 sources (I found the problem originally in the SuSE 2.6.5
> derivate, where the kernel.org version didn't have swsusp_pg_dir at all,
> yet), and indeed in the kernel.org version swsusp_pg_dir lives in
> arch/i386/mm/init.c (one might argue which of the placements is the
> better one).
> 
> Still, to prevent issues in the future as well as such like seen with
> SuSE, the patch seems necessary to me.

Yes, the patch is okay. Can you send it to andrew for inclusion?
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Fw: x86 build issue with software suspend code

[Jan Beulich]

>> A piece of code most like "copy-and-paste"d from x86_64 to i386
caused
>> the section named .data.nosave in arch/i386/power/swsusp.S to
become
>> named .data.nosave.1 in arch/i386/power/built-in.o (due to an
attribute
>> collision with an identically named section from
>> arch/i386/power/cpu.c),
>
>I can't find anything about nosave section in cpu.c... Can you quote
it?

Ah, I see. This is the only piece I didn't double-check against the
2.6.8.1 sources (I found the problem originally in the SuSE 2.6.5
derivate, where the kernel.org version didn't have swsusp_pg_dir at all,
yet), and indeed in the kernel.org version swsusp_pg_dir lives in
arch/i386/mm/init.c (one might argue which of the placements is the
better one).

Still, to prevent issues in the future as well as such like seen with
SuSE, the patch seems necessary to me.

Thanks, Jan

Re: Fw: x86 build issue with software suspend code

[Pavel Machek]

Hi!
> 
> A piece of code most like "copy-and-paste"d from x86_64 to i386 caused
> the section named .data.nosave in arch/i386/power/swsusp.S to become
> named .data.nosave.1 in arch/i386/power/built-in.o (due to an attribute
> collision with an identically named section from
> arch/i386/power/cpu.c),

I can't find anything about nosave section in cpu.c... Can you quote it?

> which finally ends up in no-where land (because it doesn't have even the
> alloc bit set, and the linker script doesn't know about such a section
> either), resulting in the two variables being accessed at (absolute)
> addresses 0 and 8 (which shouldn't normally be accessible at all, but
> perhaps are mapped for whatever reason at the point execution gets
> there, since otherwise problems with this code path should have been
> observed much earlier).
> 
> The below (also attached for the inline variant most certainly getting
> incorrectly line wrapped) patch changes the attributes of the section to
> match those of other instances of the section, so the renaming doesn't
> happen anymore. It also adds alignment, decreases the fields from 8 to 4
> bytes and applies these additional changes also to the appearant
> original x86_64 code.

I do not know that much about linker, but patch looks okay.
								Pavel

> diff -Napru linux-2.6.8.1/arch/i386/power/swsusp.S
> 2.6.8.1/arch/i386/power/swsusp.S
> --- linux-2.6.8.1/arch/i386/power/swsusp.S	2004-08-14
> 12:55:19.000000000 +0200
> +++ 2.6.8.1/arch/i386/power/swsusp.S	2004-08-26 15:54:35.420154440
> +0200
> @@ -89,9 +89,10 @@ copy_done:
>  	popl %ebx
>  	ret
>  
> -       .section .data.nosave
> +       .section .data.nosave, "aw"
> +       .align 4
>  loop:
> -       .quad 0
> +       .long 0
>  loop2:
> -       .quad 0
> +       .long 0
>         .previous
> diff -Napru linux-2.6.8.1/arch/x86_64/kernel/suspend_asm.S
> 2.6.8.1/arch/x86_64/kernel/suspend_asm.S
> --- linux-2.6.8.1/arch/x86_64/kernel/suspend_asm.S	2004-08-14
> 12:56:22.000000000 +0200
> +++ 2.6.8.1/arch/x86_64/kernel/suspend_asm.S	2004-08-26
> 15:54:56.446957880 +0200
> @@ -117,7 +117,8 @@ ENTRY(do_magic)
>  	addq	$8, %rsp
>  	jmp	do_magic_resume_2
>  
> -	.section .data.nosave
> +	.section .data.nosave, "aw"
> +	.align 8
>  loop:
>  	.quad 0
>  loop2:	
> 
> 



-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!