[Bug 225450] 11.1-* panics on AMD Opteron 2k due to EARLY_AP_STARTUP

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225450

--- Comment #14 from Pablo Ruiz  ---
I've tried moving the while loop a bit down at mp_x86, and I got a db prompt
too:

diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
index 3cca61ca72e..1c257d87e58 100644
--- a/sys/x86/x86/mp_x86.c
+++ b/sys/x86/x86/mp_x86.c
@@ -925,7 +925,6 @@ init_secondary_tail(void)

CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid);
printf("SMP: AP CPU #%d Launched!\n", cpuid);
-while(1);

/* Determine if we are a logical CPU. */
if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread)
@@ -951,6 +950,7 @@ while(1);
load_es(_udatasel);
load_fs(_ufssel);
 #endif
+while(1);

mtx_unlock_spin(_boot_mtx);

This is the relevant boot output:

[...]
cpu0 BSP:
 ID: 0x   VER: 0x80050010 LDR: 0x DFR: 0x
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
  timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
   AMD ext features: 0x00010003
   AMD elvt0: 0x0001
SMP: AP CPU #1 Launched!
cpu1 AP:

Fa
kFernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x441
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ffb704
stack pointer   = 0x28:0xfe001b979d00
frame pointer   = 0x28:0xfe001b979d10
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu2)
[ thread pid 11 tid 15 ]
Stopped at  spinlock_exit+0x14: movq0x440(%rbx),%rax
db> bt
Tracing pid 11 tid 15 td 0xf8000332c000
spinlock_exit() at spinlock_exit+0x14/frame 0xfe001b979d10
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b979d80
i8254_delay() at i8254_delay+0x143/frame 0xfe001b979dc0
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b979e30
i8254_delay() at i8254_delay+0x143/frame 0xfe001b979e70
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b979ee0
i8254_delay() at i8254_delay+0x143/frame 0xfe001b979f20
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b979f90
i8254_delay() at i8254_delay+0x143/frame 0xfe001b979fd0
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b97a040
i8254_delay() at i8254_delay+0x143/frame 0xfe001b97a080
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b97a0f0
i8254_delay() at i8254_delay+0x143/frame 0xfe001b97a130
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xa5/frame 0xfe001b97a1a0
i8254_delay() at i8254_delay+0x143/frame 0xfe001b97a1e0
[... repeates quite a lot ]
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x14a/frame 0xfe001b97cb90
i8254_delay() at i8254_delay+0x3a/frame 0xfe001b97cbd0
ns8250_putc() at ns8250_putc+0x2a/frame 0xfe001b97cc00
uart_cnputc() at uart_cnputc+0x47/frame 0xfe001b97cc20
cnputc() at cnputc+0x7d/frame 0xfe001b97cc50
cnputs() at cnputs+0x68/frame 0xfe001b97cc70
putchar() at putchar+0x14d/frame 0xfe001b97ccf0
kvprintf() at kvprintf+0x103d/frame 0xfe001b97cde0
vprintf() at vprintf+0x87/frame 0xfe001b97ceb0
printf() at printf+0x43/frame 0xfe001b97cf10
dblfault_handler() at dblfault_handler+0x26/frame 0xfe001b97cf30
Xdblfault() at Xdblfault+0xac/frame 0xfe001b97cf30
--- trap 0x17, rip = 0x81159ea5, rsp = 0xfe001b978000, rbp =
0xfe001b978030 ---
i8254_delay() at i8254_delay+0x35/frame 0xfe001b978030
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x14a/frame 0xfe001b9780a0
i8254_delay() at i8254_delay+0x3a/frame 0xfe001b9780e0
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x14a/frame 0xfe001b978150
[... more similar calls repeating omitted ...]
spinlock_exit() at spinlock_exit+0x14/frame 0xfe001b9785d0
[... more _mtx_lock_spin_cookie calls ...]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 222215] r323389 breaks the kernel build when WITHOUT_ZFS is defined in src.conf

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kevans
Date: Sun Feb 11 02:27:52 UTC 2018
New revision: 329114
URL: https://svnweb.freebsd.org/changeset/base/329114

Log:
  MFC Loader Fixes 2017q3: r320547,r320553,r321621,r321844,r321969,r321991,
  r322037,r322038,r322039,r322040,r322056,r322074,r322542,r322592,r322593,
  r322896,r322923,r323671,r322930,r322931,r322932,r322933,r322934,r322935,
  r322936,r322937,r322938,r322939,r322941,r323062,r323063,r323064,r323065,
  r323100,r323131,r323174,r323258,r323261,r323272,r323367,r323379,r323389,
  r323407,r323428,r323436,r323494,r323496,r323497,r323541,r323554,r323589,
  r323707,r323867,r323885,r323886,r323895,r323896,r323897,r323905,r323906,
  r323907,r323908,r323909,r323952,r323991,r324099,r324558,r326445,r326609,
  r326610

  This batch includes a special kludge to fix powerpc loader build; 
  was included after  there, causing problems with DEBUG_MALLOC bits.
  Include  a little bit earlier to fix the build with the intention
  of removing this when eventually libsa silently replaces stdlib.h with
  stand.h.

  r320547: Link EFI/uboot loaders with -znotext

  r320553: Integer underflow in efipart_realstrategy when I/O starts after end
  of disk

  r321621: Always set the receive mask in loader.efi.

  r321844: Clean up style in print_state(..) and pager_printf(..)

  r321969: Fix the return types for printf and putchar to match their libc

  r321991: Revert r321969

  r322037: Add stpcpy and stpncpy to libstand

  r322038: Add definitions and utilities for EFI drivers

  r322039: Move EFI ZFS functions to libefi

  r322040: Add EFI utility functions to libefi

  r322056: Move EFI fmtdev functionality to libefi

  r322074: libefi/time.c cstyle cleanup

  r322542: loader.efi: repace XXX with real comments in trap.c

  r322592: Remove unused defines.

  r322593: Define proposed GUID for FreeBSD boot loader variables.

  r322896: Make spinconsole platform independent and hook it up into EFI
  loader

  r322923: Hide length of geli passphrase during boot.

  r323671: Fix language used in the r322923.

  r322930: Move efi_main into efi/loader

  r322931: Cleanup efi_main return type

  r322932: Use the loader.efi conventions for the various EFI tables.

  r322933: No need for MK_ZFS around these: they are by their nature only
  active when MK_ZFS is true.

  r322934: _STAND is sometimes defined on the command line. Make the define
  here match.

  r322935: Fix warnings due to type mismatch.

  r322936: Remove useless 'static' for an enum definition.

  r322937: Forward declare struct dsk to avoid warnings when building libi386.

  r322938: Link in libefi for boot1

  r322939: Use efi_devpath_str for debug path info.

  r322941: Eliminate redunant device path matching.

  r323062: Make efichar.c routines available to libefi.

  r323063: boot1.efi: print more info about where boot1.efi is loaded from

  r323064: Exit rather than panic for most errors.

  r323065: Save where we're booted from

  r323100: libstand: nfs_readlink() should return proper return code

  r323131: Revert r322941: Eliminate redundant device matching functions

  r323174: Fix loader bug causing too many pages allocation when bootloader
  is U-Boot

  r323258: ucs2len

  r323261: Fix armv6 build

  r323272: Be consistent and do return (1);

  r323367: Mark init_chroot and init_script variables as deprecated.

  r323379: It's been pointed out that init_script at least is useful w/o

  r323389: loader.efi: chain loader should provide proper device handle

  r323407: boot1 generate-fat: generate all templates at once

  r323428: r323389 breaks the kernel build when WITHOUT_ZFS is defined in
  src.conf

  r323436: boot1: remove BOOT1_MAXSIZE default value

  r323494: loader should support large_dnode

  r323496: libstand: tftp_open() can leak pkt on error

  r323497: libefi: efipart_open should check the status from disk_open

  r323541: libefi: efipart_realstrategy rsize pointer may be NULL

  r323554: Increase EFI boot file size frok 128k to 384k

  r323589: loader: biosmem.c cstyle cleanup

  r323707: loader: biosmem allocate heap just below 4GB

  r323867: libefi: devicename.c cleanups

  r323885: libefi: efi_devpath_match() should return bool

  r323886: libefi: efipart.c should use calloc()

  r323895: libefi: efi_devpath_match local len should be unsigned

  r323896: r323885 did miss efilib.h update

  r323897: efilib.h: typo in structure member description

  r323905: libefi: pdinfo_t pd_unit and pd_open should be unsigned

  r323906: libefi: efipart_strategy() should return ENXIO when there is no
  media

  r323907: libefi: efipart.c cstyle fix for efipart_print_common()

  r323908: libefi: efipart_hdinfo_add_filepath should check strtol result

  r323909: libefi: define EISA PNP constants

  r323952: After the r317886 support for TFTP and NFS can be enable
  simultaneously.

  r323991: 

[Bug 219000] [patch] Integer underflow in efipart_realstrategy when I/O starts after end of disk

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219000

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kevans
Date: Sun Feb 11 02:27:52 UTC 2018
New revision: 329114
URL: https://svnweb.freebsd.org/changeset/base/329114

Log:
  MFC Loader Fixes 2017q3: r320547,r320553,r321621,r321844,r321969,r321991,
  r322037,r322038,r322039,r322040,r322056,r322074,r322542,r322592,r322593,
  r322896,r322923,r323671,r322930,r322931,r322932,r322933,r322934,r322935,
  r322936,r322937,r322938,r322939,r322941,r323062,r323063,r323064,r323065,
  r323100,r323131,r323174,r323258,r323261,r323272,r323367,r323379,r323389,
  r323407,r323428,r323436,r323494,r323496,r323497,r323541,r323554,r323589,
  r323707,r323867,r323885,r323886,r323895,r323896,r323897,r323905,r323906,
  r323907,r323908,r323909,r323952,r323991,r324099,r324558,r326445,r326609,
  r326610

  This batch includes a special kludge to fix powerpc loader build; 
  was included after  there, causing problems with DEBUG_MALLOC bits.
  Include  a little bit earlier to fix the build with the intention
  of removing this when eventually libsa silently replaces stdlib.h with
  stand.h.

  r320547: Link EFI/uboot loaders with -znotext

  r320553: Integer underflow in efipart_realstrategy when I/O starts after end
  of disk

  r321621: Always set the receive mask in loader.efi.

  r321844: Clean up style in print_state(..) and pager_printf(..)

  r321969: Fix the return types for printf and putchar to match their libc

  r321991: Revert r321969

  r322037: Add stpcpy and stpncpy to libstand

  r322038: Add definitions and utilities for EFI drivers

  r322039: Move EFI ZFS functions to libefi

  r322040: Add EFI utility functions to libefi

  r322056: Move EFI fmtdev functionality to libefi

  r322074: libefi/time.c cstyle cleanup

  r322542: loader.efi: repace XXX with real comments in trap.c

  r322592: Remove unused defines.

  r322593: Define proposed GUID for FreeBSD boot loader variables.

  r322896: Make spinconsole platform independent and hook it up into EFI
  loader

  r322923: Hide length of geli passphrase during boot.

  r323671: Fix language used in the r322923.

  r322930: Move efi_main into efi/loader

  r322931: Cleanup efi_main return type

  r322932: Use the loader.efi conventions for the various EFI tables.

  r322933: No need for MK_ZFS around these: they are by their nature only
  active when MK_ZFS is true.

  r322934: _STAND is sometimes defined on the command line. Make the define
  here match.

  r322935: Fix warnings due to type mismatch.

  r322936: Remove useless 'static' for an enum definition.

  r322937: Forward declare struct dsk to avoid warnings when building libi386.

  r322938: Link in libefi for boot1

  r322939: Use efi_devpath_str for debug path info.

  r322941: Eliminate redunant device path matching.

  r323062: Make efichar.c routines available to libefi.

  r323063: boot1.efi: print more info about where boot1.efi is loaded from

  r323064: Exit rather than panic for most errors.

  r323065: Save where we're booted from

  r323100: libstand: nfs_readlink() should return proper return code

  r323131: Revert r322941: Eliminate redundant device matching functions

  r323174: Fix loader bug causing too many pages allocation when bootloader
  is U-Boot

  r323258: ucs2len

  r323261: Fix armv6 build

  r323272: Be consistent and do return (1);

  r323367: Mark init_chroot and init_script variables as deprecated.

  r323379: It's been pointed out that init_script at least is useful w/o

  r323389: loader.efi: chain loader should provide proper device handle

  r323407: boot1 generate-fat: generate all templates at once

  r323428: r323389 breaks the kernel build when WITHOUT_ZFS is defined in
  src.conf

  r323436: boot1: remove BOOT1_MAXSIZE default value

  r323494: loader should support large_dnode

  r323496: libstand: tftp_open() can leak pkt on error

  r323497: libefi: efipart_open should check the status from disk_open

  r323541: libefi: efipart_realstrategy rsize pointer may be NULL

  r323554: Increase EFI boot file size frok 128k to 384k

  r323589: loader: biosmem.c cstyle cleanup

  r323707: loader: biosmem allocate heap just below 4GB

  r323867: libefi: devicename.c cleanups

  r323885: libefi: efi_devpath_match() should return bool

  r323886: libefi: efipart.c should use calloc()

  r323895: libefi: efi_devpath_match local len should be unsigned

  r323896: r323885 did miss efilib.h update

  r323897: efilib.h: typo in structure member description

  r323905: libefi: pdinfo_t pd_unit and pd_open should be unsigned

  r323906: libefi: efipart_strategy() should return ENXIO when there is no
  media

  r323907: libefi: efipart.c cstyle fix for efipart_print_common()

  r323908: libefi: efipart_hdinfo_add_filepath should check strtol result

  r323909: libefi: define EISA PNP constants

  r323952: After the r317886 support for TFTP and NFS can be enable
  simultaneously.

  r323991: 

[Bug 207910] [uart] [patch] fix for Intel Atom Cherryview SOC HSUART not recognized

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207910

--- Comment #4 from commit-h...@freebsd.org ---
A commit references this bug:

Author: eadler
Date: Sun Feb 11 07:04:48 UTC 2018
New revision: 329121
URL: https://svnweb.freebsd.org/changeset/base/329121

Log:
  MFC r308926:

  Add Intel Atom Cherryview SOC HSUART support

  PR:   207910
  Submitted by: johan...@brilliantservice.co.jp

Changes:
_U  stable/11/
  stable/11/sys/dev/uart/uart_bus_pci.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #83 from m...@sentex.net ---
Created attachment 190490
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190490=edit
process that is hung in usem state

with libc path and python linked to debug libs

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225813] [geom][patch] gpart does not recognise Apple APFS partition type

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225813

Conrad Meyer  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 207910] [uart] [patch] fix for Intel Atom Cherryview SOC HSUART not recognized

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207910

Eitan Adler  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #84 from Konstantin Belousov  ---
(In reply to mike from comment #83)
It is yet another (different) lock leakage.  Please switch to the Thread 4 (LWP
101503) and from the frame 1 do "print *mtx".

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225450] 11.1-* panics on AMD Opteron 2k due to EARLY_AP_STARTUP

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225450

--- Comment #13 from Pablo Ruiz  ---
Hi again,

Adding the following patch:

diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
index 7cc02d663bf..3cca61ca72e 100644
--- a/sys/x86/x86/mp_x86.c
+++ b/sys/x86/x86/mp_x86.c
@@ -925,6 +925,7 @@ init_secondary_tail(void)

CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid);
printf("SMP: AP CPU #%d Launched!\n", cpuid);
+while(1);

/* Determine if we are a logical CPU. */
if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread)

I get into db while crashing:

[...]
cpu0 BSP:
 ID: 0x   VER: 0x80050010 LDR: 0x DFR: 0x
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
  timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
   AMD ext features: 0x00010003
   AMD elvt0: 0x0001
SMP: AP CPU #1 Launched!
kkkerneel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x80bb739d
stack pointer   = 0x28:0xfe001b9835b0
frame pointer   = 0x28:0xfe001b983620
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu2)
[ thread pid 11 tid 15 ]
Stopped at  putchar+0x15d:  movb$0,(%rax)
db> bt
Tracing pid 11 tid 15 td 0xf8000332c000
putchar() at putchar+0x15d/frame 0xfe001b983620
db> show all procs
  pid  ppid  pgrp   uid   state   wmesg wchancmd
   11 0 0 0  RL  (threaded)  [idle]
13   CanRun  [idle: cpu0]
14   CanRun  [idle: cpu1]
15   CanRun  [idle: cpu2]
16   CanRun  [idle: cpu3]
1 0 0 0  ?L  [kernel]
   10 0 0 0  RL  [audit]
0 0 0 0  RLs CPU 0   [swapper]
db> show all pcpu
Current CPU: 2

cpuid= 0
dynamic pcpu = 0x682000
curthread= 0x82883640: pid 0 "swapper"
curpcb   = 0x82c0ecc0
fpcurthread  = none
idlethread   = 0xf8000332d000: tid 13 "idle: cpu0"
curpmap  = 0x828af188
tssp = 0x828ad510
commontssp   = 0x828ad510
rsp0 = 0x82c0ecc0
gs32p= 0x828ad708
ldt  = 0x828ad748
tss  = 0x828ad738

cpuid= 1
dynamic pcpu = 0xfe00993f1000
curthread= 0xf8000332c580: pid 11 "idle: cpu1"
curpcb   = 0
fpcurthread  = none
idlethread   = 0xf8000332c580: tid 14 "idle: cpu1"
curpmap  = 0x828af188
tssp = 0x828ad578
commontssp   = 0x828ad578
rsp0 = 0x0
gs32p= 0x828ad770
ldt  = 0x828ad7b0
tss  = 0x828ad7a0

cpuid= 2
dynamic pcpu = 0xfe00993f9000
curthread= 0xf8000332c000: pid 11 "idle: cpu2"
curpcb   = 0
fpcurthread  = none
idlethread   = 0xf8000332c000: tid 15 "idle: cpu2"
curpmap  = 0x828af188
tssp = 0x828ad5e0
commontssp   = 0x828ad5e0
rsp0 = 0x0
gs32p= 0x828ad7d8
ldt  = 0x828ad818
tss  = 0x828ad808

cpuid= 3
dynamic pcpu = 0xfe0099401000
curthread= 0xf8000332b580: pid 11 "idle: cpu3"
curpcb   = 0
fpcurthread  = none
idlethread   = 0xf8000332b580: tid 16 "idle: cpu3"
curpmap  = 0x828af188
tssp = 0x828ad648
commontssp   = 0x828ad648
rsp0 = 0x0
gs32p= 0x828ad840
ldt  = 0x828ad880
tss  = 0x828ad870
db> show all trace

Tracing command idle pid 11 tid 13 td 0xf8000332d000
fork_trampoline() at fork_trampoline

Tracing command idle pid 11 tid 14 td 0xf8000332c580
fork_trampoline() at fork_trampoline

Tracing command idle pid 11 tid 15 td 0xf8000332c000
putchar() at putchar+0x15d/frame 0xfe001b983620

Tracing command idle pid 11 tid 16 td 0xf8000332b580
fork_trampoline() at fork_trampoline

Tracing command kernel pid 1 tid 12 td 0xf8000332d580
fork_trampoline() at fork_trampoline

Tracing command audit pid 10 tid 11 td 0xf8000332e000
fork_trampoline() at fork_trampoline

Tracing command kernel pid 0 tid 10 td 0x82883640
KDB: reentering
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001b982cc0
kdb_reenter() at kdb_reenter+0x2f/frame 0xfe001b982cd0
trap() at trap+0x4d/frame 

[Bug 225813] [geom][patch] gpart does not recognise Apple APFS partition type

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225813

Conrad Meyer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

commit-h...@freebsd.org changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|Closed  |New

--- Comment #2 from Conrad Meyer  ---
Thank you for submitting the patch.  I added a blurb to gpart.8 manual page as
well.

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: cem
Date: Sun Feb 11 06:57:21 UTC 2018
New revision: 329119
URL: https://svnweb.freebsd.org/changeset/base/329119

Log:
  Add GUID and alias for Apple APFS partition

  PR:   225813
  Submitted by: James Wright 

Changes:
  head/sbin/geom/class/part/gpart.8
  head/sys/geom/part/g_part.c
  head/sys/geom/part/g_part.h
  head/sys/geom/part/g_part_gpt.c
  head/sys/sys/disk/gpt.h

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225813] [geom][patch] gpart does not recognise Apple APFS partition type

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225813

Conrad Meyer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #2 from Conrad Meyer  ---
Thank you for submitting the patch.  I added a blurb to gpart.8 manual page as
well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #85 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #84)

(gdb) thread 4
[Switching to thread 4 (LWP 101503 of process 43500)]
#0  _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
37  RSYSCALL_ERR(_umtx_op)
(gdb) frame 1
#1  0x000800654024 in __thr_umutex_lock (mtx=0x8006640a8, id=101503) at
/usr/src/lib/libthr/thread/thr_umtx.c:82
82  _umtx_op_err(mtx, UMTX_OP_MUTEX_WAIT, 0, 0, 0);
(gdb) list
77  return (EOWNERDEAD);
78  if (owner == UMUTEX_RB_NOTRECOV)
79  return (ENOTRECOVERABLE);
80
81  /* wait in kernel */
82  _umtx_op_err(mtx, UMTX_OP_MUTEX_WAIT, 0, 0, 0);
83  }
84  }
85
86  #define SPINLOOPS 1000
(gdb) print *mtx
$1 = {m_owner = -2147382146, m_flags = 0, m_ceilings = {0, 0}, m_rb_lnk = 0,
m_spare = {0, 0}}
(gdb)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225450] 11.1-* panics on AMD Opteron 2k due to EARLY_AP_STARTUP

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225450

--- Comment #11 from John Baldwin  ---
Hmm, I don't know why the previous simple lock didn't help.  One other possible
thing to try is placing 'while (1);' infinite loop in the init_secondary_tail()
function in sys/x86/x86/mp_x86.c and moving it around in the function to narrow
down when the APs are triggering the double fault (which is a stack overflow). 
If you put the while(1) before the smp_cpus++; the failure mode you should see
if the AP doesn't fault is a 'panic AP #x failed to start'.  After the
smp_cpus++ line you should at least no longer get the double fault panic if you
haven't hit the double fault yet.

Another thought is that it might be there is a missing MFC in 11 related to one
or more kthreads starting too early.  You could perhaps build a kernel with:

options KTR_COMPILE=KTR_PROC
options KTR_MASK=KTR_PROC
options KTR_VERBOSE

And see what messages are logged before the crash (to see if the APs are
starting to run other kthreads besides the idle thread).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225450] 11.1-* panics on AMD Opteron 2k due to EARLY_AP_STARTUP

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225450

--- Comment #15 from Pablo Ruiz  ---
And, finally if I move the while(1) just after the mtx_unlock_spin call, like
this:

diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
index 1c257d87e58..04975dd8a2e 100644
--- a/sys/x86/x86/mp_x86.c
+++ b/sys/x86/x86/mp_x86.c
@@ -950,9 +950,9 @@ init_secondary_tail(void)
load_es(_udatasel);
load_fs(_ufssel);
 #endif
-while(1);

mtx_unlock_spin(_boot_mtx);
+while(1);

/* Wait until all the AP's are up. */
while (atomic_load_acq_int(_started) == 0)

We arrive to the original behaviour of no 'db' prompt, and somewhat garbaged
crash:

[...]
cpu0 BSP:
 ID: 0x   VER: 0x80050010 LDR: 0x DFR: 0x
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
  timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
   AMD ext features: 0x00010003
   AMD elvt0: 0x0001
SMP: AP CPU #1 Launched!
cpu1 AP:

Fa
Fa

FFa
Fa
Fa
Fa
Fata

.

I hope this helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225813] [geom][patch] gpart does not recognise Apple APFS partition type

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225813

Bug ID: 225813
   Summary: [geom][patch] gpart does not recognise Apple APFS
partition type
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: james.wri...@jigsawdezign.com
  Keywords: patch

Created attachment 190494
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190494=edit
Patch for adding Apple APFS as a known GPT partition type

Apple APFS partition type is not recognised by gpart, e.g.

james macbook ~ % gpart show
=>   34  977104993  ada0  GPT  (466G)
 34  6- free -  (3.0K)
 40 409600 1  efi  (200M)
 409640  546875000 2  !7c3457ef--11aa-aa11-00306543ecac  (261G)
...

I have included a patch to add the Apple APFS magic guid to the known types,
recompiled and tested with the following results;

james macbook ~ % gpart show
=>   34  977104993  ada0  GPT  (466G)
 34  6- free -  (3.0K)
 40 409600 1  efi  (200M)
 409640  546875000 2  apple-apfs  (261G)

Please could someone review and test the patch for me?

Thanks,
James

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225813] [geom][patch] gpart does not recognise Apple APFS partition type

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225813

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org

--- Comment #1 from Conrad Meyer  ---
Patch looks fine to me modulo gratuitously changed lines in gpt.h and possible
ABI break by inserting at the front of 'enum g_part_alias'.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #78 from Konstantin Belousov  ---
(In reply to Ed Maste from comment #77)
Ok.  It could be a consequence of the discovered issue occuring in other code
fragment, it can be something else.

So I can wait for some AMD comments.  Or you can independently provide me with
the threads backtraces.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #79 from Konstantin Belousov  ---
BTW, if using the patch from the comment 59, is the hang reproducible ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #81 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #79)

> BTW, if using the patch from the comment 59, is the hang reproducible ?

I got it to hang on RELENG_11 just now.  Perhaps its some combo of the CPU
feature patch and removing optimizations from libthr ? When debugging you had
me compile it with -g and -O0

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212318

w.schwarzenf...@utanet.at changed:

   What|Removed |Added

 CC||w.schwarzenf...@utanet.at

--- Comment #12 from w.schwarzenf...@utanet.at ---
Any news here?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212318

--- Comment #13 from Ben RUBSON  ---
Can't your fuse program simply use fuse_unmount(mountpoint, NULL) instead of
fuse_unmount_compat22(mountpoint) ?
(as we did here : https://github.com/vgough/encfs/pull/293)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #82 from Konstantin Belousov  ---
(In reply to mike from comment #81)
I can't say anything without debug info.  Start with the backtraces, as usual.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 57045] trpt(8) option -t was disabled on -current

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=57045

fernando.apesteg...@gmail.com changed:

   What|Removed |Added

 CC||fernando.apesteguia@gmail.c
   ||om

--- Comment #3 from fernando.apesteg...@gmail.com ---
Created attachment 190486
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190486=edit
patch to usr.sbin/trpt/

The relevant code was commented out in r50680.

The attached patch removes it completely, including the relevant flag and the
documentation. After applying the patch:

$ ./trpt -t
trpt: illegal option -- t
usage: trpt [-afjst] [-p hex-address] [system [core]]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 225584] Various compile process hang on Ryzen, but not on Intel

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584

--- Comment #80 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #79)

re: patch 59
I will apply it by itself and try again

 patch -p1 < p.59
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|--- a/lib/libc/stdio/_flock_stub.c
|+++ b/lib/libc/stdio/_flock_stub.c
--
Patching file lib/libc/stdio/_flock_stub.c using Plan A...
Hunk #1 succeeded at 37 with fuzz 2 (offset -2 lines).
Hunk #2 succeeded at 114 (offset -2 lines).
Hunk #3 succeeded at 143 (offset -2 lines).
done

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 114468] [patch] [request] add -d option to umount(8) to detach md(4) device

2018-02-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=114468

Jamie Landeg-Jones  changed:

   What|Removed |Added

 CC||ja...@catflap.org

--- Comment #3 from Jamie Landeg-Jones  ---
This could be useful.. I've been thinking about a more generic "close on
unmount" flag settable on md mounts as a "proper" fix to some other problems
I'm having with autofs and md disks...

But I'm still working on some ideas and code which I will eventually send for
review.

Only really commenting here now in case others are interested too...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"