Searched hist:0 (Results 1 - 25 of 17849) sorted by relevance
| /freebsd-11-stable/contrib/unbound/contrib/ | ||
| H A D | metrics.awk | 368693 Wed Dec 16 09:30:47 MST 2020 cy MFC r368478: MFV r368464: Update unbound from 1.12.0 to 1.13.0 Security: CVE-2020-28935 368693 Wed Dec 16 09:30:47 MST 2020 cy MFC r368478: MFV r368464: Update unbound from 1.12.0 to 1.13.0 Security: CVE-2020-28935 |
| /freebsd-11-stable/contrib/unbound/dnstap/ | ||
| H A D | dtstream.c | diff 368693 Wed Dec 16 09:30:47 MST 2020 cy MFC r368478: MFV r368464: Update unbound from 1.12.0 to 1.13.0 Security: CVE-2020-28935 diff 368693 Wed Dec 16 09:30:47 MST 2020 cy MFC r368478: MFV r368464: Update unbound from 1.12.0 to 1.13.0 Security: CVE-2020-28935 diff 368129 Sat Nov 28 18:20:11 MST 2020 cy MFC r367094: MFV r367082: Update unbound 1.11.0 --> 1.12.0. diff 368129 Sat Nov 28 18:20:11 MST 2020 cy MFC r367094: MFV r367082: Update unbound 1.11.0 --> 1.12.0. 366095 Wed Sep 23 22:43:56 MDT 2020 cy MFC r364721-r364722 r364721: MFV 364468: Update unbound 1.10.1 --> 1.11.0. r364722: Update unbound version number. |
| H A D | dtstream.h | diff 368129 Sat Nov 28 18:20:11 MST 2020 cy MFC r367094: MFV r367082: Update unbound 1.11.0 --> 1.12.0. diff 368129 Sat Nov 28 18:20:11 MST 2020 cy MFC r367094: MFV r367082: Update unbound 1.11.0 --> 1.12.0. 366095 Wed Sep 23 22:43:56 MDT 2020 cy MFC r364721-r364722 r364721: MFV 364468: Update unbound 1.10.1 --> 1.11.0. r364722: Update unbound version number. |
| /freebsd-11-stable/sys/conf/ | ||
| H A D | ldscript.amd64 | diff 324510 Wed Oct 11 00:33:47 MDT 2017 emaste MFC r309151: Use explicit 0x200000 for the amd64 kernel physaddr (instead of MAXPAGESIZE) MAXPAGESIZE is not well defined by the GNU ld documentation. Different linkers, and different versions of the same linker, use different MAXPAGESIZE values. Current versions of GNU gold and LLVM's lld use 4K. When set to 4K the kernel panics at boot due to an issue with x86bios. Here we want the kernel physaddr to be the amd64 superpage size, so use that value (2MB) explicitly. With this change GNU gold and LLVM lld can link a working amd64 kernel. PR: 214718 (x86bios) Sponsored by: The FreeBSD Foundation diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 diff 284870 Fri Jun 26 05:12:52 MDT 2015 royger amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783 |
| /freebsd-11-stable/contrib/tcpdump/ | ||
| H A D | netdissect.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | print-medsa.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | print-vxlan-gpe.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | strtoaddr.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | print-nsh.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | print.h | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | print-lisp.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | ascii_strcasecmp.c | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | ascii_strcasecmp.h | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | addrtostr.h | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | timeval-operations.h | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| H A D | strtoaddr.h | 313537 Fri Feb 10 07:23:11 MST 2017 glebius Merge r309649, r313048, r313083, r313104: tcpdump 4.9.0 |
| /freebsd-11-stable/sys/dev/fb/ | ||
| H A D | vesa.c | 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) 303807 Sat Aug 06 21:59:33 MDT 2016 jhb MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) |
| /freebsd-11-stable/share/dtrace/ | ||
| H A D | Makefile | diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com diff 288644 Sat Oct 03 22:54:42 MDT 2015 pjd Add a little, but very useful script for use with programs that work using an event loop and should sleep only when waiting for events (eg. via kevent(2)). When a program is going to sleep in the kernel, the script will show its name, PID, kernel stack trace and userland stack trace. Sleeping in kevent(2) is ignored as it is expected to be valid. Sample output: # ./blocking lynxd lynxd(15042) is blocking... kernel`_cv_wait_sig+0x124 kernel`seltdwait+0xae kernel`sys_poll+0x3a3 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`poll+0xa lynxd`pqSocketCheck+0xa2 lynxd`pqWaitTimed+0x29 lynxd`connectDBComplete+0xd7 lynxd`PQsetdbLogin+0x2ec lynxd`db_connect+0x3c lynxd`main+0x198 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dmu_buf_hold_array_by_dnode+0x1dc zfs.ko`dmu_read+0xcb zfs.ko`zfs_freebsd_getpages+0x37b kernel`VOP_GETPAGES_APV+0xa7 kernel`vnode_pager_getpages+0x9a kernel`vm_fault_hold+0x885 kernel`vm_fault+0x77 kernel`trap_pfault+0x211 kernel`trap+0x506 kernel`0xffffffff806c76c2 lynxd`EVP_add_cipher+0x13 lynxd`SSL_library_init+0x11 lynxd`main+0x94 lynxd`_start+0x16f 0x2 lynxd(1925) is blocking... kernel`_cv_wait+0x125 zfs.ko`zio_wait+0x5b zfs.ko`dbuf_read+0x791 zfs.ko`dbuf_findbp+0x12f zfs.ko`dbuf_hold_impl+0xa2 zfs.ko`dbuf_hold+0x1b zfs.ko`dmu_buf_hold_array_by_dnode+0x153 zfs.ko`dmu_read_uio+0x66 zfs.ko`zfs_freebsd_read+0x3a3 kernel`VOP_READ_APV+0xa1 kernel`vn_read+0x13a kernel`vn_io_fault+0x10b kernel`dofileread+0x95 kernel`kern_readv+0x68 kernel`sys_read+0x63 kernel`amd64_syscall+0x343 kernel`0xffffffff806c79ab lynxd`_read+0xa lynxd`__srefill+0x122 lynxd`fgets+0x78 lynxd`file_gets+0x1d lynxd`BIO_gets+0x64 lynxd`PEM_read_bio+0xf5 lynxd`PEM_X509_INFO_read_bio+0x90 lynxd`X509_load_cert_crl_file+0x47 lynxd`by_file_ctrl+0x2e lynxd`X509_STORE_load_locations+0x4a lynxd`sslctx_init+0x255 lynxd`main+0x215 lynxd`_start+0x16f 0x2 Requested by: gnn Obtained from: Wheel Systems http://wheelsystems.com |
| /freebsd-11-stable/contrib/llvm-project/llvm/lib/Target/Hexagon/MCTargetDesc/ | ||
| H A D | HexagonMCCodeEmitter.cpp | diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 341825 Tue Dec 11 19:08:38 MST 2018 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html> PR: 230240, 230355 Relnotes: yes MFC after: 2 months diff 341825 Tue Dec 11 19:08:38 MST 2018 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html> PR: 230240, 230355 Relnotes: yes MFC after: 2 months diff 341825 Tue Dec 11 19:08:38 MST 2018 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html> PR: 230240, 230355 Relnotes: yes MFC after: 2 months diff 341825 Tue Dec 11 19:08:38 MST 2018 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html> PR: 230240, 230355 Relnotes: yes MFC after: 2 months |
| /freebsd-11-stable/contrib/llvm-project/compiler-rt/lib/tsan/rtl/ | ||
| H A D | tsan_interceptors.h | diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month |
| /freebsd-11-stable/contrib/llvm-project/llvm/lib/Target/AMDGPU/ | ||
| H A D | AMDGPUTargetMachine.h | diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month |
| /freebsd-11-stable/contrib/llvm-project/llvm/lib/Target/AMDGPU/MCTargetDesc/ | ||
| H A D | AMDGPUTargetStreamer.h | diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 353358 Wed Oct 09 17:09:14 MDT 2019 dim Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month diff 344779 Mon Mar 04 19:43:49 MST 2019 dim Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC after: 1 month |
| /freebsd-11-stable/usr.bin/indent/tests/ | ||
| H A D | struct.0.stdout | diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 |
| H A D | offsetof.0.stdout | diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 |
| H A D | label.0.stdout | diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. diff 330634 Thu Mar 08 07:21:33 MST 2018 eadler MFC r313544: indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 313544 Fri Feb 10 09:33:12 MST 2017 pstef indent(1): add regression test cases These examples show expected behavior of indent(1). They are meant to be used together with a regression test mechanism, either Kyua, a Makefile or perhaps something else. The mechanism should in essence do this: indent -P${test}.pro < ${test}.0 > ${test}.0.run and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit status isn't 0, the test failed. * ${test}.pro is an indent(1) profile: a list of options passed through a file. The program doesn't complain if the file doesn't exist. * ${test}.0 is a C source file which acts as input for indent(1). It doesn't have to have any particular formatting, since it's the output that matters. * ${test}.0.stdout contains expected output. It doesn't have to be formatted in Kernel Normal Form as the point of the tests is to check for regressions in the program and not to check that it always produces KNF. Reviewed by: ngie Approved by: pfg (mentor) Differential Revision: https://reviews.freebsd.org/D9007 |
Completed in 438 milliseconds