Re: CVS commit: src/sys/arch/amd64

2019-12-26 Thread Masanobu SAITOH
On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
 After this change, amd64 kernel does not boot on my HP Spectre x360
 13-inch ae019TU laptop with pure UEFI boot mode.
>>  I have a UEFI boot machine and it also doesn't boot well.
> 
> Please try the attached patch.
> 
> It adds the -n flag to ld, which disable auto-alignment of sections
> in the file. I undestand alignement is highly desirable for userland
> programs that may be mapped from file, but useless for the kernel,
> which is just readen once by the bootloader.
> 
> Without auto-alignement, the .text segment starts right after the
> ELF headers. This means the multiboot header can go in .text and
> stay below 32k (as required by the multiboot specification). There
> is no need for a multiboot section for that, and therefore no 
> need to modify the linker script.
> 
> A side effect is that the kernel file shrinks of 2 MB, because there
> is not an alignement hole between ELF headers and the .text section
> anymore.
> 
> My patch also enable the MULTIBOOT option so that we can check
> nothing gets broken with it. You can also try with the option
> disabled, of course.
> 

Both with and without MULTIBOOT works fine. No any hangup/panic.

 Thanks.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)


Re: CVS commit: src/sys/arch/amd64

2019-12-26 Thread Emmanuel Dreyfus
On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> >> After this change, amd64 kernel does not boot on my HP Spectre x360
> >> 13-inch ae019TU laptop with pure UEFI boot mode.
>  I have a UEFI boot machine and it also doesn't boot well.

Please try the attached patch.

It adds the -n flag to ld, which disable auto-alignment of sections
in the file. I undestand alignement is highly desirable for userland
programs that may be mapped from file, but useless for the kernel,
which is just readen once by the bootloader.

Without auto-alignement, the .text segment starts right after the
ELF headers. This means the multiboot header can go in .text and
stay below 32k (as required by the multiboot specification). There
is no need for a multiboot section for that, and therefore no 
need to modify the linker script.

A side effect is that the kernel file shrinks of 2 MB, because there
is not an alignement hole between ELF headers and the .text section
anymore.

My patch also enable the MULTIBOOT option so that we can check
nothing gets broken with it. You can also try with the option
disabled, of course.

-- 
Emmanuel Dreyfus
m...@netbsd.org
? sys/arch/amd64/compile/obj
? sys/arch/amd64/stand/prekern/obj
Index: sys/arch/amd64/amd64/locore.S
===
RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v
retrieving revision 1.195
diff -U4 -r1.195 locore.S
--- sys/arch/amd64/amd64/locore.S   15 Dec 2019 02:58:21 -  1.195
+++ sys/arch/amd64/amd64/locore.S   26 Dec 2019 16:44:10 -
@@ -431,51 +431,8 @@
.size   tmpstk, tmpstk - .
.space  512
 tmpstk:
 
-.section multiboot,"a"
-#if defined(MULTIBOOT)
-   .align  8
-   .globl  Multiboot2_Header
-_C_LABEL(Multiboot2_Header):
-   .intMULTIBOOT2_HEADER_MAGIC
-   .intMULTIBOOT2_ARCHITECTURE_I386
-   .intMultiboot2_Header_end - Multiboot2_Header
-   .int-(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 \
-   + (Multiboot2_Header_end - Multiboot2_Header))
-
-   .int1   /* MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST */
-   .int12  /* sizeof(multiboot_header_tag_information_request) */
-   /* + sizeof(uint32_t) * requests */
-   .int4   /* MULTIBOOT_TAG_TYPE_BASIC_MEMINFO */
-   .align  8
-
-   .int3   /* MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS */
-   .int16  /* sizeof(struct multiboot_tag_efi64) */
-   .quad   (multiboot2_entry - KERNBASE)
-   .align  8
-
-   .int9   /* MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64 */
-   .int16  /* sizeof(struct multiboot_tag_efi64) */
-   .quad   (multiboot2_entry - KERNBASE)
-   .align  8
-
-#if notyet
-   /*
-* Could be used to get an early console for debug,
-* but this is broken.
-*/
-   .int7   /* MULTIBOOT_HEADER_TAG_EFI_BS */
-   .int8   /* sizeof(struct multiboot_tag) */
-   .align  8
-#endif
-
-   .int0   /* MULTIBOOT_HEADER_TAG_END */
-   .int8   /* sizeof(struct multiboot_tag) */
-   .align  8
-   .globl  Multiboot2_Header_end
-_C_LABEL(Multiboot2_Header_end):
-#endif /* MULTIBOOT */
 
 /*
  * Some hackage to deal with 64bit symbols in 32 bit mode.
  * This may not be needed if things are cleaned up a little.
@@ -2179,8 +2136,50 @@
 SYSCALL_ENTRY  syscall,is_svs=0
 
TEXT_USER_BEGIN
 
+#if defined(MULTIBOOT)
+   .align  8
+   .globl  Multiboot2_Header
+_C_LABEL(Multiboot2_Header):
+   .intMULTIBOOT2_HEADER_MAGIC
+   .intMULTIBOOT2_ARCHITECTURE_I386
+   .intMultiboot2_Header_end - Multiboot2_Header
+   .int-(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 \
+   + (Multiboot2_Header_end - Multiboot2_Header))
+
+   .int1   /* MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST */
+   .int12  /* sizeof(multiboot_header_tag_information_request) */
+   /* + sizeof(uint32_t) * requests */
+   .int4   /* MULTIBOOT_TAG_TYPE_BASIC_MEMINFO */
+   .align  8
+
+   .int3   /* MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS */
+   .int16  /* sizeof(struct multiboot_tag_efi64) */
+   .quad   (multiboot2_entry - KERNBASE)
+   .align  8
+
+   .int9   /* MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64 */
+   .int16  /* sizeof(struct multiboot_tag_efi64) */
+   .quad   (multiboot2_entry - KERNBASE)
+   .align  8
+
+#if notyet
+   /*
+* Could be used to get an early console for debug,
+* but this is broken.
+*/
+   .int7   /* MULTIBOOT_HEADER_TAG_EFI_BS */
+   .int8   /* sizeof(struct multiboot_tag) */
+   .align  8
+#endif
+
+   .int0   /* MULTIBOOT_HEADER_TAG_END */
+   .int8   /* sizeof(struct multiboot_tag) */
+   .align  8
+   .globl  

Re: CVS commit: src/sys/arch/amd64

2019-12-26 Thread Emmanuel Dreyfus
On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
>  - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
>The possibility is about 65%

What is the backtace? Does it goes through svs_init?

-- 
Emmanuel Dreyfus
m...@netbsd.org


sys_ptrace_lwpstatus.c (Was: CVS commit: src/sys)

2019-12-26 Thread Valery Ushakov
On Thu, Dec 26, 2019 at 08:52:39 +, Kamil Rytarowski wrote:

> Module Name:  src
> Committed By: kamil
> Date: Thu Dec 26 08:52:39 UTC 2019
> 
> Modified Files:
>   src/sys/kern: files.kern sys_ptrace_common.c
>   src/sys/sys: ptrace.h
> Added Files:
>   src/sys/kern: sys_ptrace_lwpstatus.c
> 
> Log Message:
> Put ptrace_read_lwpstatus() and process_read_lwpstatus() to a new file
> 
> Fixes "no PTRACE" kernel build, in particular zaurus kernel=INSTALL_C700.

This is counterintuitive when a sys_ptrace* file with ptrace_*
functions does not depend on options ptrace.  That seems to be a
strong indication the functions and the file are misnamed.

filekern/sys_ptrace.c   ptrace
filekern/sys_ptrace_common.cptrace
filekern/sys_ptrace_lwpstatus.c kern

-uwe