Re: snapshot of april 12th wont boot at all

[Shawn Webb]

On Tue, Apr 17, 2018 at 10:52:40PM +, Beeblebrox wrote:
> My proposed plan did not work anyway, as both MINIMAL and GENERIC fail to 
> build.
> I'll have to clone the FreeBSD repo unless Shawn has something to comment on 
> this.

Due to our changing of certain kernel structures, GENERIC likely won't
build anymore. FreeBSD's kernel source code contains compile-time
assertions that detect when offsets of values within certain key
structures are different than expected (example commit
f9f820f2e418f9b68f9d94631171135bfb79989f in hardened/current/master).

I'm unsure why PTI causes issues in these cases. I would love to
attempt to make an effort to debug it myself, but I would need some
way to replicate the issue on my end.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: snapshot of april 12th wont boot at all

[Beeblebrox]

My proposed plan did not work anyway, as both MINIMAL and GENERIC fail to build.
I'll have to clone the FreeBSD repo unless Shawn has something to comment on 
this.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[wes wroten]

I am sorry i sent a blank email, I didn't know better so i changed it to text 
only.

the problem i have is during the boot from the cd-rom is I just get a big black 
screen with a cursor
and that's all, not even an attempt to install, nothing

my machine is running freebsd 11.1-STABLE currently but i want to switch to 
12-CURRENT to help
out with the project in ANY way I can. 

i have an amd64 
4gb ram (but 12g swap)

any other machine questions? ill happily answer if i know how

~wes
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

[John Baldwin]

On Tuesday, April 17, 2018 10:15:53 PM Vitalij Satanivskij wrote:
> Dear John
> 
> I'm try patch with no success
> 
> http://hell.ukr.net/panic/recorder_patch165.webm
> 
> Also I'm enable verbose boot and record boot process (hpet was disabled so 
> crash in another driver atach)
> http://hell.ukr.net/panic/recorder_patch_verbose.webm
> 
> root@test:/usr/src # svnlite diff
> Index: sys/x86/x86/msi.c
> ===
> --- sys/x86/x86/msi.c   (revision 332650)
> +++ sys/x86/x86/msi.c   (working copy)
> @@ -404,7 +404,7 @@
> /* Do we need to create some new sources? */
> if (cnt < count) {
> /* If we would exceed the max, give up. */
> -   if (i + (count - cnt) > FIRST_MSI_INT + NUM_MSI_INTS) {
> +   if (i + (count - cnt) >= FIRST_MSI_INT + NUM_MSI_INTS) {
> mtx_unlock(_lock);
> free(mirqs, M_MSI);
> return (ENXIO);
> @@ -645,7 +645,7 @@
> /* Do we need to create a new source? */
> if (msi == NULL) {
> /* If we would exceed the max, give up. */
> -   if (i + 1 > FIRST_MSI_INT + NUM_MSI_INTS) {
> +   if (i + 1 >= FIRST_MSI_INT + NUM_MSI_INTS) {
> mtx_unlock(_lock);
> return (ENXIO);
> }
> root@test:/usr/src
> 
> If you need any aditional information please tell me about. 

Can you perhaps turn off the stack trace on boot to not lose the panic messages
(remove KDB_TRACE from kernel config) and maybe modify the panic message to
include the IRQ number passed to nexus_add_irq?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[Beeblebrox]

Hello Ed.

> If this is reproducible on stock FreeBSD can you submit a PR with CPU details?
I don't have a cloned repo of FreeBSD, but AFAIK it's the "options PAX_*" 
related knobs in the kernel that, if eliminated, would revert the system to a 
FreeBSD one for all intents and purposes? I can just build MINIMAL or GENERIC 
and try if that's the case.

Separate finding I have for this CPU is that with an unlocked 4th core (gets 
detected as Phenom II X4 B60 instead of Athlon II X3) observable oddities are:
* Some ports have runaway builds under poudriere, end up filling swap and fail. 
www/webkit-gtk2 is an example. This could also be due to separate src.conf 
settings used to build the poudriere jail world.
* Xorg desktop becomes jittery, mouse control is difficult.
Mentioning these to ask whether you prefer them to be included in PR?

Regards.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

[Vitalij Satanivskij]

Dear John

I'm try patch with no success

http://hell.ukr.net/panic/recorder_patch165.webm

Also I'm enable verbose boot and record boot process (hpet was disabled so 
crash in another driver atach)
http://hell.ukr.net/panic/recorder_patch_verbose.webm

root@test:/usr/src # svnlite diff
Index: sys/x86/x86/msi.c
===
--- sys/x86/x86/msi.c   (revision 332650)
+++ sys/x86/x86/msi.c   (working copy)
@@ -404,7 +404,7 @@
/* Do we need to create some new sources? */
if (cnt < count) {
/* If we would exceed the max, give up. */
-   if (i + (count - cnt) > FIRST_MSI_INT + NUM_MSI_INTS) {
+   if (i + (count - cnt) >= FIRST_MSI_INT + NUM_MSI_INTS) {
mtx_unlock(_lock);
free(mirqs, M_MSI);
return (ENXIO);
@@ -645,7 +645,7 @@
/* Do we need to create a new source? */
if (msi == NULL) {
/* If we would exceed the max, give up. */
-   if (i + 1 > FIRST_MSI_INT + NUM_MSI_INTS) {
+   if (i + 1 >= FIRST_MSI_INT + NUM_MSI_INTS) {
mtx_unlock(_lock);
return (ENXIO);
}
root@test:/usr/src

If you need any aditional information please tell me about. 



JB> > If one of this parameters not set as described system not boot ^( 
JB> 
JB> Please try the patch from here https://reviews.freebsd.org/P165
JB> 
JB> -- 
JB> John Baldwin
JB> ___
JB> freebsd-hack...@freebsd.org mailing list
JB> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
JB> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[Ed Maste]

On 17 April 2018 at 11:17, Shawn Webb  wrote:
>
> HardenedBSD enables PTI regardless of underlying CPU by default. We've
> found that some older AMD CPUs have issues with PTI as currently
> implemented.

The oldest AMD CPU I have is a FX-6100, and FreeBSD-CURRENT works fine
there with PTI enabled. If this is reproducible on stock FreeBSD can
you submit a PR with CPU details?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: VM object not locked in vm_page_ps_test()

[Mark Johnston]

On Tue, Apr 17, 2018 at 10:03:55AM -0700, John Baldwin wrote:
> On Tuesday, April 17, 2018 10:01:41 AM John Baldwin wrote:
> > My laptop running recent head panicked this morning, apparently from hitting
> > a key to stop the screensaver (at which point xscreensaver prompts for a
> > password to unlock).
> 
> (Sorry, buggy mail client sent this early)
> 
> panic: Lock vm object not locked @ /usr/src/sys/vm/vm_page.c:4135
> 
> #4  0x805e4893 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:764
> #5  0x805dff22 in __rw_assert (c=, 
> what=, file=, line=)
> at /usr/src/sys/kern/kern_rwlock.c:1397
> #6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
> skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
> #7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
> prot=, fault_type=, 
> fault_flags=, wired=0, fs=, 
> m_hold=) at /usr/src/sys/vm/vm_fault.c:307
> #8  vm_fault_hold (map=0xf8000832a000, vaddr=, 
> fault_type=, fault_flags=, m_hold=0x0)
> at /usr/src/sys/vm/vm_fault.c:610
> #9  0x80866cf5 in vm_fault (map=0xf8000832a000, 
> vaddr=, fault_type=2 '\002', fault_flags=0)
> at /usr/src/sys/vm/vm_fault.c:514
> #10 0x808bc64c in trap_pfault (frame=0xfe008b1dbac0, usermode=1)
> at /usr/src/sys/amd64/amd64/trap.c:728
> #11 0x808bbe1e in trap (frame=0xfe008b1dbac0)
> #12 
> #13 0x000805b51556 in ?? ()
> 
> (kgdb) frame 6
> #6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
> skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
> (kgdb) l
> 4130{
> 4131vm_object_t object;
> 4132int i, npages;
> 4133
> 4134object = m->object;
> 4135VM_OBJECT_ASSERT_LOCKED(object);
> 4136npages = atop(pagesizes[m->psind]);
> 4137
> 4138/*
> 4139 * The physically contiguous pages that make up a superpage, 
> i.e., a
> (kgdb) p m->object
> $1 = (vm_object_t) 0xf80190785900
> (kgdb) p pagesizes[m->psind]
> $3 = 2097152
> (kgdb) up
> #7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
> prot=, fault_type=, 
> fault_flags=, wired=0, fs=, 
> m_hold=) at /usr/src/sys/vm/vm_fault.c:307
> 307 if (vm_page_ps_test(m_super, flags, m)) {
> (kgdb) p m->object
> $4 = (vm_object_t) 0xf80190116a00
> (kgdb) p/x m->flags
> $5 = 0x0
> 
> So 'm' (original page fault page) and 'm_super' are from different VM
> objects.  Why are they part of the same reservation?
> 
> (kgdb) p m->phys_addr >> (9 + 12)
> $7 = 4514
> (kgdb) p vm_reserv_array[$7]
> $8 = {lock = {lock_object = {lo_name = 0x8099112c "vm reserv", 
>   lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, 
>   partpopq = {tqe_next = 0x0, tqe_prev = 0xf80423656680}, objq = {
> le_next = 0xf8042365b0c0, le_prev = 0xf80190116ab8}, 
>   object = 0xf80190116a00, pindex = 1760, pages = 0xf80431c2e980, 
>   domain = 0, popcnt = 512, inpartpopq = 0 '\000', popmap = {
> 18446744073709551615, 18446744073709551615, 18446744073709551615, 
> 18446744073709551615, 18446744073709551615, 18446744073709551615, 
> 18446744073709551615, 18446744073709551615}}
> (kgdb) set $rv = vm_reserv_array[$7]
> (kgdb) p $rv.object
> $9 = (vm_object_t) 0xf80190116a00
> 
> So rv->object matches m->object ($4) but not m_super->object ($1).
> Double-checking:
> 
> (kgdb) p m_super->object
> $10 = (vm_object_t) 0xf80190785900
> 
> Other conditions in vm_reserv_to_superpage() are true:
> 
> (kgdb) p $rv.pages
> $11 = (vm_page_t) 0xf80431c2e980
> (kgdb) p m_super
> $12 = (vm_page_t) 0xf80431c2e980
> (kgdb) p $rv.popcnt
> $13 = 512
> 
> Both objects are OBJT_DEFAULT objects:
> 
> (kgdb) p *m->object
> $14 = {lock = {lock_object = {lo_name = 0x8095e7ce "vm object", 
>   lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 41}, 
>   object_list = {tqe_next = 0xf80190116b00, 
> tqe_prev = 0xf80190116920}, shadow_head = {lh_first = 0x0}, 
>   shadow_list = {le_next = 0x0, le_prev = 0xf80190785930}, memq = {
> tqh_first = 0xf80431ddf878, tqh_last = 0xf80431e2a900}, rtree = {
> rt_root = 18446735284333515328}, size = 2829, domain = {dr_policy = 0x0, 
> dr_iterator = 0}, generation = 1, ref_count = 3, shadow_count = 0, 
>   memattr = 6 '\006', type = 0 '\000', flags = 12352, pg_color = 1824, 
>   paging_in_progress = 1, resident_page_count = 1024, 
>   backing_object = 0xf80190785900, backing_object_offset = 0, 
>   pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
> lh_first = 0xf80423659540}, handle = 0x0, un_pager = {vnp = {
>   vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {
> tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = {
>   sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 
> 0x0, 
>   swp_blks = 

panic: VM object not locked in vm_page_ps_test()

[John Baldwin]

My laptop running recent head panicked this morning, apparently from hitting
a key to stop the screensaver (at which point xscreensaver prompts for a
password to unlock).


-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Problem compiling rust

[Filippo Moretti]

I have the folloing error while compiling rust on i386 current of April the 9th


rust_error
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: VM object not locked in vm_page_ps_test()

[John Baldwin]

On Tuesday, April 17, 2018 10:01:41 AM John Baldwin wrote:
> My laptop running recent head panicked this morning, apparently from hitting
> a key to stop the screensaver (at which point xscreensaver prompts for a
> password to unlock).

(Sorry, buggy mail client sent this early)

panic: Lock vm object not locked @ /usr/src/sys/vm/vm_page.c:4135

#4  0x805e4893 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:764
#5  0x805dff22 in __rw_assert (c=, 
what=, file=, line=)
at /usr/src/sys/kern/kern_rwlock.c:1397
#6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
#7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
prot=, fault_type=, 
fault_flags=, wired=0, fs=, 
m_hold=) at /usr/src/sys/vm/vm_fault.c:307
#8  vm_fault_hold (map=0xf8000832a000, vaddr=, 
fault_type=, fault_flags=, m_hold=0x0)
at /usr/src/sys/vm/vm_fault.c:610
#9  0x80866cf5 in vm_fault (map=0xf8000832a000, 
vaddr=, fault_type=2 '\002', fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:514
#10 0x808bc64c in trap_pfault (frame=0xfe008b1dbac0, usermode=1)
at /usr/src/sys/amd64/amd64/trap.c:728
#11 0x808bbe1e in trap (frame=0xfe008b1dbac0)
#12 
#13 0x000805b51556 in ?? ()

(kgdb) frame 6
#6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
(kgdb) l
4130{
4131vm_object_t object;
4132int i, npages;
4133
4134object = m->object;
4135VM_OBJECT_ASSERT_LOCKED(object);
4136npages = atop(pagesizes[m->psind]);
4137
4138/*
4139 * The physically contiguous pages that make up a superpage, 
i.e., a
(kgdb) p m->object
$1 = (vm_object_t) 0xf80190785900
(kgdb) p pagesizes[m->psind]
$3 = 2097152
(kgdb) up
#7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
prot=, fault_type=, 
fault_flags=, wired=0, fs=, 
m_hold=) at /usr/src/sys/vm/vm_fault.c:307
307 if (vm_page_ps_test(m_super, flags, m)) {
(kgdb) p m->object
$4 = (vm_object_t) 0xf80190116a00
(kgdb) p/x m->flags
$5 = 0x0

So 'm' (original page fault page) and 'm_super' are from different VM
objects.  Why are they part of the same reservation?

(kgdb) p m->phys_addr >> (9 + 12)
$7 = 4514
(kgdb) p vm_reserv_array[$7]
$8 = {lock = {lock_object = {lo_name = 0x8099112c "vm reserv", 
  lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, 
  partpopq = {tqe_next = 0x0, tqe_prev = 0xf80423656680}, objq = {
le_next = 0xf8042365b0c0, le_prev = 0xf80190116ab8}, 
  object = 0xf80190116a00, pindex = 1760, pages = 0xf80431c2e980, 
  domain = 0, popcnt = 512, inpartpopq = 0 '\000', popmap = {
18446744073709551615, 18446744073709551615, 18446744073709551615, 
18446744073709551615, 18446744073709551615, 18446744073709551615, 
18446744073709551615, 18446744073709551615}}
(kgdb) set $rv = vm_reserv_array[$7]
(kgdb) p $rv.object
$9 = (vm_object_t) 0xf80190116a00

So rv->object matches m->object ($4) but not m_super->object ($1).
Double-checking:

(kgdb) p m_super->object
$10 = (vm_object_t) 0xf80190785900

Other conditions in vm_reserv_to_superpage() are true:

(kgdb) p $rv.pages
$11 = (vm_page_t) 0xf80431c2e980
(kgdb) p m_super
$12 = (vm_page_t) 0xf80431c2e980
(kgdb) p $rv.popcnt
$13 = 512

Both objects are OBJT_DEFAULT objects:

(kgdb) p *m->object
$14 = {lock = {lock_object = {lo_name = 0x8095e7ce "vm object", 
  lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 41}, 
  object_list = {tqe_next = 0xf80190116b00, 
tqe_prev = 0xf80190116920}, shadow_head = {lh_first = 0x0}, 
  shadow_list = {le_next = 0x0, le_prev = 0xf80190785930}, memq = {
tqh_first = 0xf80431ddf878, tqh_last = 0xf80431e2a900}, rtree = {
rt_root = 18446735284333515328}, size = 2829, domain = {dr_policy = 0x0, 
dr_iterator = 0}, generation = 1, ref_count = 3, shadow_count = 0, 
  memattr = 6 '\006', type = 0 '\000', flags = 12352, pg_color = 1824, 
  paging_in_progress = 1, resident_page_count = 1024, 
  backing_object = 0xf80190785900, backing_object_offset = 0, 
  pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
lh_first = 0xf80423659540}, handle = 0x0, un_pager = {vnp = {
  vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {
tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = {
  sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 0x0, 
  swp_blks = {pt_root = 0}}}, cred = 0xf80008d99500, 
  charge = 11587584, umtx_data = 0x0}
(kgdb) p *m_super->object
$15 = {lock = {lock_object = {lo_name = 0x8095e7ce "vm object", 
  lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, 
  object_list = {tqe_next = 

Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed)

[John Baldwin]

On Monday, April 16, 2018 10:12:13 PM Vitalij Satanivskij wrote:
> 
> igb0@pci0:1:0:0:class=0x02 card=0x152115d9 chip=0x15218086 
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'I350 Gigabit Network Connection'
> class  = network
> subclass   = ethernet
> cap 01[40] = powerspec 3  supports D0 D3  current D0
> cap 05[50] = MSI supports 1 message, 64 bit, vector masks
> cap 11[70] = MSI-X supports 10 messages
>  Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
> cap 10[a0] = PCI-Express 2 endpoint max data 512(512) FLR RO NS
>  link x4(x4) speed 5.0(5.0) ASPM L1(L0s/L1)
> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
> ecap 0003[140] = Serial 1 ac1f6b620e0c
> ecap 000e[150] = ARI 1
> ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI 
> disabled
>  0 VFs configured out of 8 supported
>  First VF RID Offset 0x0180, VF RID Stride 0x0004
>  VF Device ID 0x1520
>  Page Sizes: 4096 (enabled), 8192, 65536, 262144, 
> 1048576, 4194304
> ecap 0017[1a0] = TPH Requester 1
> ecap 0018[1c0] = LTR 1
> ecap 000d[1d0] = ACS 1
> 
> It's info from system booted with HPET disabled and 
> hw.pci.enable_msix: 0
> hw.pci.enable_msi: 0
> 
> If one of this parameters not set as described system not boot ^( 

Please try the patch from here https://reviews.freebsd.org/P165

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[Shawn Webb]

On Tue, Apr 17, 2018 at 11:13:51AM -0400, Beeblebrox wrote:
> Hey Shawn,
> 
> > What happens when you set vm.pmap.pti=0 at the loader prompt?
> Yep, that fixed it. Booted into MYKERN without problem.
> Assuming Page Table Isolation still a bit buggy?
> 
> FreeBSD 12.0-CURRENT #3 5b8586c22aa(hardened/current/master):
> Tue Apr 17 08:11:53 EDT 2018

HardenedBSD enables PTI regardless of underlying CPU by default. We've
found that some older AMD CPUs have issues with PTI as currently
implemented.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: snapshot of april 12th wont boot at all

[Beeblebrox]

Hey Shawn,

> What happens when you set vm.pmap.pti=0 at the loader prompt?
Yep, that fixed it. Booted into MYKERN without problem.
Assuming Page Table Isolation still a bit buggy?

FreeBSD 12.0-CURRENT #3 5b8586c22aa(hardened/current/master):
Tue Apr 17 08:11:53 EDT 2018

Regards.

-- 
HardenedBSD_amd64_12-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[Kyle Evans]

On Tue, Apr 17, 2018 at 9:47 AM, Beeblebrox  wrote:
> I have (possibly) similar problem, running kernel from March 29 as
> fall-back (older kernel, latest world).
>
> * OS: HardenedBSD-12 on amd64 Athlon II X3 460
> * Kernels built yesterday: MYKERN & HARDENEDBSD (GENERIC with Debug).
>   Both kernels fail. No errors encountered during buildworld/kernel.
>   World installs normally.
> * Boot process: Grub -> /boot/loader -> Kernel Selection. No EFI (MBR).
>   Grub has own partition (ext2fs), /boot/loader on ZFS.
> * zpool: Striped on 2 HDD's, scrub returns clean pool.
>
> FAILURE POINT: System freeze, completely unresponsive, requires hard
> reset.
> * Initially seems like failure is at "Mount Root from zpool/ROOT/bsd".
>   Further inspection of dmesg shows garbled text at services stage
>   (start reading /etc/rc.conf)
> * /etc/rc.conf: Everything disabled for bug hunting. Cause does not
>   seem related to linux / radeonkms either.
> * Selecting "Safe Mode" (kern.smp.disabled ?) gets me to single-user
>   mode, and later multi-user but system freezes as soon as I login.
>   Not 100% sure about this behaviour though, as I have been at it since
>   early morning yesterday.
> * Have not tried with ACPI disabled. Dmesg: Firmware Warning (ACPI):
>   32/64X length mismatch in FADT/Gpe0Block: 64/32 (20180313/tbfadt-748)
>
> There was a recent bug involving databases failing to start due to
> "limits: NO: No such file or directory". I have Mariadb-Server-100
> installed with the new patch for this bug. I wonder whether these two
> could be related?
>

I can't speak much to the rest of your e-mail, but as far as this last
bit goes: the bug you're referencing would've just failed to start the
database server because `limits` was passed an invalid argument. If
you have filesystem access, you can confirm this by setting
mariadb_limits="" in your rc.conf(5)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[Shawn Webb]

On Tue, Apr 17, 2018 at 10:47:00AM -0400, Beeblebrox wrote:
> I have (possibly) similar problem, running kernel from March 29 as
> fall-back (older kernel, latest world).
> 
> * OS: HardenedBSD-12 on amd64 Athlon II X3 460
> * Kernels built yesterday: MYKERN & HARDENEDBSD (GENERIC with Debug).
>   Both kernels fail. No errors encountered during buildworld/kernel.
>   World installs normally.
> * Boot process: Grub -> /boot/loader -> Kernel Selection. No EFI (MBR).
>   Grub has own partition (ext2fs), /boot/loader on ZFS.
> * zpool: Striped on 2 HDD's, scrub returns clean pool.
> 
> FAILURE POINT: System freeze, completely unresponsive, requires hard
> reset.
> * Initially seems like failure is at "Mount Root from zpool/ROOT/bsd".
>   Further inspection of dmesg shows garbled text at services stage
>   (start reading /etc/rc.conf)
> * /etc/rc.conf: Everything disabled for bug hunting. Cause does not
>   seem related to linux / radeonkms either.
> * Selecting "Safe Mode" (kern.smp.disabled ?) gets me to single-user
>   mode, and later multi-user but system freezes as soon as I login.
>   Not 100% sure about this behaviour though, as I have been at it since
>   early morning yesterday.
> * Have not tried with ACPI disabled. Dmesg: Firmware Warning (ACPI):
>   32/64X length mismatch in FADT/Gpe0Block: 64/32 (20180313/tbfadt-748)
> 
> There was a recent bug involving databases failing to start due to
> "limits: NO: No such file or directory". I have Mariadb-Server-100
> installed with the new patch for this bug. I wonder whether these two
> could be related?
> 
> Would prefer not posting my verbose boot log dmesg file here, can email
> it (or download link) to developers (at FreeBSD.org) if needed though.

What happens when you set vm.pmap.pti=0 at the loader prompt?

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

snapshot of april 12th wont boot at all

[Beeblebrox]

I have (possibly) similar problem, running kernel from March 29 as
fall-back (older kernel, latest world).

* OS: HardenedBSD-12 on amd64 Athlon II X3 460
* Kernels built yesterday: MYKERN & HARDENEDBSD (GENERIC with Debug).
  Both kernels fail. No errors encountered during buildworld/kernel.
  World installs normally.
* Boot process: Grub -> /boot/loader -> Kernel Selection. No EFI (MBR).
  Grub has own partition (ext2fs), /boot/loader on ZFS.
* zpool: Striped on 2 HDD's, scrub returns clean pool.

FAILURE POINT: System freeze, completely unresponsive, requires hard
reset.
* Initially seems like failure is at "Mount Root from zpool/ROOT/bsd".
  Further inspection of dmesg shows garbled text at services stage
  (start reading /etc/rc.conf)
* /etc/rc.conf: Everything disabled for bug hunting. Cause does not
  seem related to linux / radeonkms either.
* Selecting "Safe Mode" (kern.smp.disabled ?) gets me to single-user
  mode, and later multi-user but system freezes as soon as I login.
  Not 100% sure about this behaviour though, as I have been at it since
  early morning yesterday.
* Have not tried with ACPI disabled. Dmesg: Firmware Warning (ACPI):
  32/64X length mismatch in FADT/Gpe0Block: 64/32 (20180313/tbfadt-748)

There was a recent bug involving databases failing to start due to
"limits: NO: No such file or directory". I have Mariadb-Server-100
installed with the new patch for this bug. I wonder whether these two
could be related?

Would prefer not posting my verbose boot log dmesg file here, can email
it (or download link) to developers (at FreeBSD.org) if needed though.

Regards.

-- 
HardenedBSD_amd64_12-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: snapshot of april 12th wont boot at all

[Dave Cottlehuber]

On Tue, 17 Apr 2018, at 02:17, Wes wrote nothing.

Wes,

Can you share some info?

Which architecture
boot method uefi mbr …
Which iso / img specifically 
Fresh install or upgrade?
Relevant loader.conf settings
Your dmesg on a prior snapshot 
Expand on won’t boot - start at system POST and explain from there
Any variants you tried
Do you just get a black screen?

Good hunting!
Dave


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"