Re: beadm vs bectl

[Pete Wright]

On 8/27/18 3:22 PM, Allan Jude wrote:

On 2018-08-27 14:50, Pete Wright wrote:

hi there - i have a zfs based system where /boot is on its own pool.
beadm seems happy enough with this setup but bectl errors out like so:

$ sudo bectl list
/ and /boot not on same device, quitting
$

$ beadm list
BE Active Mountpoint  Space Created
default    NR /   47.6G 2018-03-02 20:30
snapshot_02262018  -  -    1.5G 2018-03-03 14:38
badresume_05122018 -  -    4.4G 2018-05-12 19:45
11_2_beta  -  -    2.6G 2018-05-13 18:26
resume_works   -  -   12.6G 2018-06-01 16:45
$

reading the manpage for bectl it doesn't mention this being an issue.
so i guess i have two questions:
1) is it a bad thing(tm) to have /boot on its own pool?
2) assuming that having /boot on its  own pool, why does bectl not work
with this configuration?

thanks!
-pete


Your /boot being on a separate pool can never work, since you can't take
a consistent snapshot of / and have it include your kernel (which is
under /boot/kernel which is a separate pool)

Do you know why you have 2 separate pools? If it was for GELI support,
FreeBSD 12.0 will not require two separate pools anymore, and there will
be migration instructions shortly.



thanks Allan!  that is precisely why i have a separate /boot IIRC - i 
use GELI to encrypt zroot.  i'll keep my eyes open for migration 
instructions which i'll be sure to test out and provide feedback on.


thanks!
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

[Ian FREISLICH]

I moved the #ifdef down one line and its compiling.

Ian

-- 
Ian Freislich

On 08/29/2018 07:40 PM, John Baldwin wrote:
> On 8/29/18 4:20 PM, Ian FREISLICH wrote:
>> Hi
>>
>> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP
>> at line 84.  My system is UP  so I'm not compiling an SMP kernel.
>>
>> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared
>> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
>>     interrupt_sorted = mallocarray(num_io_irqs,
>> sizeof(*interrupt_sorted),
>>     ^~~~
>>     interrupt_sources
>> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources'
>> declared here
>> static struct intsrc **interrupt_sources;
>>    ^
>> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared
>> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
>>     interrupt_sorted = mallocarray(num_io_irqs,
>> sizeof(*interrupt_sorted),
> Probably just needs #ifdef SMP around the mallocarray().  I'll test locallyon 
> a UP kernel config.
>


-- 

___
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: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

[John Baldwin]

On 8/29/18 4:20 PM, Ian FREISLICH wrote:
> Hi
> 
> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP
> at line 84.  My system is UP  so I'm not compiling an SMP kernel.
> 
> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared
> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
>     interrupt_sorted = mallocarray(num_io_irqs,
> sizeof(*interrupt_sorted),
>     ^~~~
>     interrupt_sources
> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources'
> declared here
> static struct intsrc **interrupt_sources;
>    ^
> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared
> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
>     interrupt_sorted = mallocarray(num_io_irqs,
> sizeof(*interrupt_sorted),

Probably just needs #ifdef SMP around the mallocarray().  I'll test locallyon a 
UP kernel config.

-- 
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"

intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

[Ian FREISLICH]

Hi

I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP
at line 84.  My system is UP  so I'm not compiling an SMP kernel.

/usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared
identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
    interrupt_sorted = mallocarray(num_io_irqs,
sizeof(*interrupt_sorted),
    ^~~~
    interrupt_sources
/usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources'
declared here
static struct intsrc **interrupt_sources;
   ^
/usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared
identifier 'interrupt_sorted'; did you mean 'interrupt_sources'?
    interrupt_sorted = mallocarray(num_io_irqs,
sizeof(*interrupt_sorted),
    ^~~~
   
interrupt_sources
/usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources'
declared here
static struct intsrc **interrupt_sources;
   ^
2 errors generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BRANE
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

-- 
Ian Freislich


-- 

___
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: r336921 broke booting on MBP 2017, EFIRT related

[Gleb Popov]

I met similar panic on my ASUS ROG GL553VE:

module_register_init: MOD_LOAD (vesa, 0x80a9dd30, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 07
fault virtual address   = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x7b3cede8
stack pointer= 0x28:0x81edb7e8
frame pointer= 0x28:0x0
code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 0 (swapper)
[ thread pid 0 tid 10 ]
Stopped at 0x7b3cede8:cmpq%r10,(%r8,%rdx,8)

It then hanged, so I could'nt even get a backtrace. However, removing
"option EFIRT" from the config fixed it.
___
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: old top and new -current: missing arcstat sysctl

[Allan Jude]

On 2018-08-29 11:18, Mark Johnston wrote:
> On Wed, Aug 29, 2018 at 07:44:31AM +0200, Alexander Leidinger wrote:
>>
>> Quoting Mark Johnston  (from Tue, 28 Aug 2018  
>> 10:48:42 -0400):
>>
>>> On Tue, Aug 28, 2018 at 10:25:39AM -0400, Allan Jude wrote:
 On 2018-08-28 02:40, Alexander Leidinger wrote:
> Hi,
>
> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> 12.0-alpha3 with a top from an old-ish -current.
>
> Is/will this be handled via a compat-11 sysctl (my kernel is without
> compat-xx), or did this slip through?
>>
 That is not something that a compat-xx package can handle.
>>>
>>> s/package/kernel option/?
>>
>> Sorry, the COMPAT_FREEBSDx kernel options was what I had in mind when  
>> I wrote this.
>>
 That arcstat was broken up into 3 individual stats, which the
 12.0-alpha3 version of top will sum together for you.

 I don't think we've had compat shims like this for previous versions of
 top, I recall having similar issues when the 'laundry' counter was
 introduced.
>>>
>>> IIRC that would have been the inverted case of running a newer top(1)
>>> with an older kernel lacking the v_laundry_pages sysctl.  In general I'd
>>> expect us to support running an older top(1) with newer kernels if we
>>> don't have to bend over backwards to provide compatibility.
>>
>> If the new top is summing the 3 up anyway, it sounds like we could  
>> provide the old one as backwards compatibility, even if it is  
>> redundant. I rather have an redundant counter and an old top working  
>> (in the generic case of what we promise to our users; in this specific  
>> case for me I just need to get around to update the jails on the  
>> corresponding systems), than bailing out without displaying anything.
> 
> I'm inclined to agree, especially since this (running older top(1)s) has
> come up before when I removed some VM sysctls:
> https://reviews.freebsd.org/D16943
> ___
> 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"
> 

I misunderstood previously (COMPAT_FREEBSDxx vs the compat-xx package).
I am in agreement with Mark about fixing this for 12.0

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Wed, Aug 29, 2018 at 07:17:07PM +0300, Yuri Pankov wrote:
> Konstantin Belousov wrote:
> > On Wed, Aug 29, 2018 at 09:12:37AM -0500, Kyle Evans wrote:
> >> I guess this patch might do it:
> >> https://people.freebsd.org/~kevans/efi-bootmap.diff
> >>
> >> Linux commit messages depict a tale in which they used to also only
> >> map RUNTIME entries, but they were effectively forced to back down on
> >> that because of buggy firmware that does exactly what you've described
> >> and they later reintroduced the restrictive mapping for i386-only
> >> where they'd not found such bugs.
> > 
> > Orthogonal to the loader patch, please try the following.  Even better,
> > try this with the stock loader.
> > 
> > You need to remove efirt from the kernel config for now, instead load
> > efirt.ko, perhaps after the system booted into single user.  I am interested
> > if the panic goes away.  You should see some interesting message from
> > kernel about EFI realtime clock.
> > 
> > If you have any binary modules like nvidia or vbox, do not load them
> > with the patched kernel.
> 
> Done, getting exactly the same fault without any new messages printed 
> (made sure I'm using the updated efirt using `nm | grep efirt_fault`).

Can you show me exact fault messages ?
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Yuri Pankov]

Konstantin Belousov wrote:

On Wed, Aug 29, 2018 at 09:12:37AM -0500, Kyle Evans wrote:

I guess this patch might do it:
https://people.freebsd.org/~kevans/efi-bootmap.diff

Linux commit messages depict a tale in which they used to also only
map RUNTIME entries, but they were effectively forced to back down on
that because of buggy firmware that does exactly what you've described
and they later reintroduced the restrictive mapping for i386-only
where they'd not found such bugs.


Orthogonal to the loader patch, please try the following.  Even better,
try this with the stock loader.

You need to remove efirt from the kernel config for now, instead load
efirt.ko, perhaps after the system booted into single user.  I am interested
if the panic goes away.  You should see some interesting message from
kernel about EFI realtime clock.

If you have any binary modules like nvidia or vbox, do not load them
with the patched kernel.


Done, getting exactly the same fault without any new messages printed 
(made sure I'm using the updated efirt using `nm | grep efirt_fault`).

___
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: old top and new -current: missing arcstat sysctl

[Mark Johnston]

On Wed, Aug 29, 2018 at 07:44:31AM +0200, Alexander Leidinger wrote:
> 
> Quoting Mark Johnston  (from Tue, 28 Aug 2018  
> 10:48:42 -0400):
> 
> > On Tue, Aug 28, 2018 at 10:25:39AM -0400, Allan Jude wrote:
> >> On 2018-08-28 02:40, Alexander Leidinger wrote:
> >> > Hi,
> >> >
> >> > top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> >> > 12.0-alpha3 with a top from an old-ish -current.
> >> >
> >> > Is/will this be handled via a compat-11 sysctl (my kernel is without
> >> > compat-xx), or did this slip through?
> 
> >> That is not something that a compat-xx package can handle.
> >
> > s/package/kernel option/?
> 
> Sorry, the COMPAT_FREEBSDx kernel options was what I had in mind when  
> I wrote this.
> 
> >> That arcstat was broken up into 3 individual stats, which the
> >> 12.0-alpha3 version of top will sum together for you.
> >>
> >> I don't think we've had compat shims like this for previous versions of
> >> top, I recall having similar issues when the 'laundry' counter was
> >> introduced.
> >
> > IIRC that would have been the inverted case of running a newer top(1)
> > with an older kernel lacking the v_laundry_pages sysctl.  In general I'd
> > expect us to support running an older top(1) with newer kernels if we
> > don't have to bend over backwards to provide compatibility.
> 
> If the new top is summing the 3 up anyway, it sounds like we could  
> provide the old one as backwards compatibility, even if it is  
> redundant. I rather have an redundant counter and an old top working  
> (in the generic case of what we promise to our users; in this specific  
> case for me I just need to get around to update the jails on the  
> corresponding systems), than bailing out without displaying anything.

I'm inclined to agree, especially since this (running older top(1)s) has
come up before when I removed some VM sysctls:
https://reviews.freebsd.org/D16943
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Wed, Aug 29, 2018 at 09:12:37AM -0500, Kyle Evans wrote:
> I guess this patch might do it:
> https://people.freebsd.org/~kevans/efi-bootmap.diff
> 
> Linux commit messages depict a tale in which they used to also only
> map RUNTIME entries, but they were effectively forced to back down on
> that because of buggy firmware that does exactly what you've described
> and they later reintroduced the restrictive mapping for i386-only
> where they'd not found such bugs.

Orthogonal to the loader patch, please try the following.  Even better,
try this with the stock loader.

You need to remove efirt from the kernel config for now, instead load
efirt.ko, perhaps after the system booted into single user.  I am interested
if the panic goes away.  You should see some interesting message from
kernel about EFI realtime clock.

If you have any binary modules like nvidia or vbox, do not load them
with the patched kernel.

diff --git a/sys/amd64/amd64/efirt_support.S b/sys/amd64/amd64/efirt_support.S
new file mode 100644
index 000..82e5646e645
--- /dev/null
+++ b/sys/amd64/amd64/efirt_support.S
@@ -0,0 +1,105 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2018 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Konstantin Belousov 
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#include 
+
+#include "assym.inc"
+
+   .text
+ENTRY(efirt_arch_call)
+   pushq   %rbp
+   movq%rsp, %rbp
+
+   movq%rbx, EC_STATE+TF_RBX(%rdi)
+   movq%rsp, EC_STATE+TF_RSP(%rdi)
+   movq%rbp, EC_STATE+TF_RBP(%rdi)
+   movq%r12, EC_STATE+TF_R12(%rdi)
+   movq%r13, EC_STATE+TF_R13(%rdi)
+   movq%r14, EC_STATE+TF_R14(%rdi)
+   movq%r15, EC_STATE+TF_R15(%rdi)
+   movqPCPU(CURTHREAD), %rax
+   movq%rdi, TD_MD+MD_EFIRT_TMP(%rax)
+
+   movqPCPU(CURPCB), %rsi
+   movq$efirt_fault, PCB_ONFAULT(%rsi)
+
+   movlEC_ARGCNT(%rdi), %ecx
+   movl%ecx, %ebx
+   shll$3, %ecx
+   subq%rcx, %rsp
+
+   cmpl$0, %ebx
+   jz  1f
+   movqEC_ARG1(%rdi), %rcx
+   decl%ebx
+   jz  1f
+   movqEC_ARG2(%rdi), %rdx
+   decl%ebx
+   jz  1f
+   movqEC_ARG3(%rdi), %r8
+   decl%ebx
+   jz  1f
+   movqEC_ARG4(%rdi), %r9
+   /* XXX on-stack regs */
+1: movqEC_FPTR(%rdi), %rax
+   callq   *%rax
+
+   movqPCPU(CURTHREAD), %rbx
+   movqTD_MD+MD_EFIRT_TMP(%rbx), %rdi
+   movq%rax, EC_STATE(%rdi)
+   movqPCPU(CURPCB), %rsi
+   xorl%eax, %eax
+   movq%rax, PCB_ONFAULT(%rsi)
+
+efirt_arch_call_tail:
+   movqEC_STATE+TF_R15(%rdi), %r15
+   movqEC_STATE+TF_R14(%rdi), %r14
+   movqEC_STATE+TF_R13(%rdi), %r13
+   movqEC_STATE+TF_R12(%rdi), %r12
+   movqEC_STATE+TF_RBP(%rdi), %rbp
+   movqEC_STATE+TF_RSP(%rdi), %rsp
+   movqEC_STATE+TF_RBX(%rdi), %rbx
+
+   popq%rbp
+   ret
+END(efirt_arch_call)
+
+ENTRY(efirt_fault)
+   xorl%eax, %eax
+   movqPCPU(CURPCB), %rsi
+   movq%rax, PCB_ONFAULT(%rsi)
+   movl$EFAULT, %eax
+   movqPCPU(CURTHREAD), %rbx
+   movqTD_MD+MD_EFIRT_TMP(%rbx), %rdi
+   jmp efirt_arch_call_tail
+END(efirt_fault)
diff --git a/sys/amd64/amd64/genassym.c b/sys/amd64/amd64/genassym.c
index d61b5c7bb6d..c38a596089a 100644
--- a/sys/amd64/amd64/genassym.c
+++ b/sys/amd64/amd64/genassym.c
@@ -77,12 +77,15 @@ ASSYM(P_MD, offsetof(struct proc, p_md));
 ASSYM(MD_LDT, offsetof(struct 

Re: r336921 broke booting on MBP 2017, EFIRT related

[Kyle Evans]

On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov  wrote:
>
> Yuri Pankov wrote:
> > Konstantin Belousov wrote:
> >> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
> >>> Hi,
> >>>
> >>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> >>> 20180802) fail to boot on MBP 2017:
> >>>
> >>> kbd0 at kbdmux0
> >>> netmap: loaded module
> >>> nexus0
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 2: apic id = 02
> >>> fault virtual address  = 0x74c64a50
> >>> fault code = supervisor read data, page not present
> >>> instruction pointer= 0x20: 0x7abece31
> >>> stack pointer  = 0x28: 0x82b2f7c0
> >>> frame pointer  = 0x28: 0x82b2f810
> >>> code segment   = base 0x0, limit 0xf, type 0x1b
> >>>  = DPL 0, pres 1, long 1, def32 0, gran 1
> >>> processor eflags   = interrupt enabled, resume, IOPL = 0
> >>> current process= 0 (swapper)
> >>> [ thread pid 0 tid 10 ]
> >>> Stopped at  0x7abece31:calll   *0x18(%rax)
> >>> db>
> >>>
> >>> Sadly, there's no support for internal keyboard yet (it's connected via
> >>> SPI), and external USB one stops working.
> >>>
> >>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> >>>
> >>> Some questions here:
> >>> - is this something that can/should be fixed?
> >>> - can we print some "enabling EFIRT" message to the console to make
> >>> guesses about the problem source a bit easier?
> >>
> >> It is not in 'enabling'.  Looking at the faulting VA, I believe that
> >> it occurs inside the BIOS code.
> >>
> >> Disable efirt by removing the kernel option, then try to load the module
> >> at runtime.  Does it still fault ?  Also, get the efi mem map for the
> >> machine and look at which region the faulting address and the faulting
> >> instruction belong.
> >
> > kldload'ing the efirt module gets the same fault.  Several top lines of
> > backtrace:
> >
> > kernphys() at 0x7abece31
> > efi_get_time() at efi_get_time+0xd9
> > efirtc_probe() at efirtc_probe+0x17
>
> For the efi mem map, if I'm understanding it correctly, there's the
> following:
>
> ...
> BootServicesData 7421d000  0a8b UC WC WT WB
> ...
> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
> ...
>

Hi,

I guess this patch might do it:
https://people.freebsd.org/~kevans/efi-bootmap.diff

Linux commit messages depict a tale in which they used to also only
map RUNTIME entries, but they were effectively forced to back down on
that because of buggy firmware that does exactly what you've described
and they later reintroduced the restrictive mapping for i386-only
where they'd not found such bugs.

Thanks,

Kyle Evans
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 15:25 schrieb Kyle Evans:
> On Wed, Aug 29, 2018 at 8:20 AM Rainer Hurling  wrote:
>>
>> Am 29.08.18 um 11:37 schrieb Yuri Pankov:
>>> Hi,
>>>
>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
>>> 20180802) fail to boot on MBP 2017:
>>>
>>> kbd0 at kbdmux0
>>> netmap: loaded module
>>> nexus0
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2: apic id = 02
>>> fault virtual address  = 0x74c64a50
>>> fault code = supervisor read data, page not present
>>> instruction pointer= 0x20: 0x7abece31
>>> stack pointer  = 0x28: 0x82b2f7c0
>>> frame pointer  = 0x28: 0x82b2f810
>>> code segment   = base 0x0, limit 0xf, type 0x1b
>>>= DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags   = interrupt enabled, resume, IOPL = 0
>>> current process= 0 (swapper)
>>> [ thread pid 0 tid 10 ]
>>> Stopped at  0x7abece31:calll   *0x18(%rax)
>>> db>
>>>
>>> Sadly, there's no support for internal keyboard yet (it's connected via
>>> SPI), and external USB one stops working.
>>>
>>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
>>>
>>> Some questions here:
>>> - is this something that can/should be fixed?
>>> - can we print some "enabling EFIRT" message to the console to make
>>>   guesses about the problem source a bit easier?
>>
>>
>> I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.
> 
> Hmm... that's a good data point. I might have a nearby Dell on-hand
> with same firmware to reproduce with, then.
> 
>> Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
>> via efi.rt.disabled=1 in /boot/loader.conf, it works for me.
>>
>> An oddity is, that the spelling of the loader tuneable has to be
>> efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
>> underscore!). The one with the underscore, as mentioned in UPDATING,
>> does not work for me. Isn't this a typo somewhere in the code?
>>
> 
> The UPDATING entry was later amended to reflect the new spelling
> ("efi.rt.disabled")

Oops, I must have missed it. Thanks for the update.

> 
> Thanks,
> 
> Kyle Evans
> 

___
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: r336921 broke booting on MBP 2017, EFIRT related

[Kyle Evans]

On Wed, Aug 29, 2018 at 8:20 AM Rainer Hurling  wrote:
>
> Am 29.08.18 um 11:37 schrieb Yuri Pankov:
> > Hi,
> >
> > I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> > 20180802) fail to boot on MBP 2017:
> >
> > kbd0 at kbdmux0
> > netmap: loaded module
> > nexus0
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2: apic id = 02
> > fault virtual address  = 0x74c64a50
> > fault code = supervisor read data, page not present
> > instruction pointer= 0x20: 0x7abece31
> > stack pointer  = 0x28: 0x82b2f7c0
> > frame pointer  = 0x28: 0x82b2f810
> > code segment   = base 0x0, limit 0xf, type 0x1b
> >= DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags   = interrupt enabled, resume, IOPL = 0
> > current process= 0 (swapper)
> > [ thread pid 0 tid 10 ]
> > Stopped at  0x7abece31:calll   *0x18(%rax)
> > db>
> >
> > Sadly, there's no support for internal keyboard yet (it's connected via
> > SPI), and external USB one stops working.
> >
> > A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> >
> > Some questions here:
> > - is this something that can/should be fixed?
> > - can we print some "enabling EFIRT" message to the console to make
> >   guesses about the problem source a bit easier?
>
>
> I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.

Hmm... that's a good data point. I might have a nearby Dell on-hand
with same firmware to reproduce with, then.

> Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
> via efi.rt.disabled=1 in /boot/loader.conf, it works for me.
>
> An oddity is, that the spelling of the loader tuneable has to be
> efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
> underscore!). The one with the underscore, as mentioned in UPDATING,
> does not work for me. Isn't this a typo somewhere in the code?
>

The UPDATING entry was later amended to reflect the new spelling
("efi.rt.disabled")

Thanks,

Kyle Evans
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 11:37 schrieb Yuri Pankov:
> Hi,
> 
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> 20180802) fail to boot on MBP 2017:
> 
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic id = 02
> fault virtual address  = 0x74c64a50
> fault code = supervisor read data, page not present
> instruction pointer    = 0x20: 0x7abece31
> stack pointer  = 0x28: 0x82b2f7c0
> frame pointer  = 0x28: 0x82b2f810
> code segment   = base 0x0, limit 0xf, type 0x1b
>    = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags   = interrupt enabled, resume, IOPL = 0
> current process    = 0 (swapper)
> [ thread pid 0 tid 10 ]
> Stopped at  0x7abece31:    calll   *0x18(%rax)
> db>
> 
> Sadly, there's no support for internal keyboard yet (it's connected via
> SPI), and external USB one stops working.
> 
> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> 
> Some questions here:
> - is this something that can/should be fixed?
> - can we print some "enabling EFIRT" message to the console to make
>   guesses about the problem source a bit easier?


I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.

Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
via efi.rt.disabled=1 in /boot/loader.conf, it works for me.

An oddity is, that the spelling of the loader tuneable has to be
efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
underscore!). The one with the underscore, as mentioned in UPDATING,
does not work for me. Isn't this a typo somewhere in the code?

Regards,
Rainer Hurling
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Toomas Soome]

> On 29 Aug 2018, at 14:53, Yuri Pankov  wrote:
> 
> Yuri Pankov wrote:
>> Konstantin Belousov wrote:
>>> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
 Hi,
 
 I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
 20180802) fail to boot on MBP 2017:
 
 kbd0 at kbdmux0
 netmap: loaded module
 nexus0
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 2: apic id = 02
 fault virtual address  = 0x74c64a50
 fault code = supervisor read data, page not present
 instruction pointer= 0x20: 0x7abece31
 stack pointer  = 0x28: 0x82b2f7c0
 frame pointer  = 0x28: 0x82b2f810
 code segment   = base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags   = interrupt enabled, resume, IOPL = 0
 current process= 0 (swapper)
 [ thread pid 0 tid 10 ]
 Stopped at  0x7abece31:calll   *0x18(%rax)
 db>
 
 Sadly, there's no support for internal keyboard yet (it's connected via
 SPI), and external USB one stops working.
 
 A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
 
 Some questions here:
 - is this something that can/should be fixed?
 - can we print some "enabling EFIRT" message to the console to make
 guesses about the problem source a bit easier?
>>> 
>>> It is not in 'enabling'.  Looking at the faulting VA, I believe that
>>> it occurs inside the BIOS code.
>>> 
>>> Disable efirt by removing the kernel option, then try to load the module
>>> at runtime.  Does it still fault ?  Also, get the efi mem map for the
>>> machine and look at which region the faulting address and the faulting
>>> instruction belong.
>> kldload'ing the efirt module gets the same fault.  Several top lines of 
>> backtrace:
>> kernphys() at 0x7abece31
>> efi_get_time() at efi_get_time+0xd9
>> efirtc_probe() at efirtc_probe+0x17
> 
> For the efi mem map, if I'm understanding it correctly, there's the following:
> 
> ...
>   BootServicesData 7421d000  0a8b UC WC WT WB
> ...
> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
> …

if my math is correct, this RTS code area will end at 0x7abe5000 and if 
0x7abece31 is fault location, its just after that RTS code area, that 
is, 7 pages after… meaning you would need to get the next entry:)

rgds,
toomas

___
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: r336921 broke booting on MBP 2017, EFIRT related

[Toomas Soome]

> On 29 Aug 2018, at 15:05, Toomas Soome  wrote:
> 
> 
> 
>> On 29 Aug 2018, at 14:53, Yuri Pankov > > wrote:
>> 
>> Yuri Pankov wrote:
>>> Konstantin Belousov wrote:
 On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
> Hi,
> 
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> 20180802) fail to boot on MBP 2017:
> 
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic id = 02
> fault virtual address  = 0x74c64a50
> fault code = supervisor read data, page not present
> instruction pointer= 0x20: 0x7abece31
> stack pointer  = 0x28: 0x82b2f7c0
> frame pointer  = 0x28: 0x82b2f810
> code segment   = base 0x0, limit 0xf, type 0x1b
>  = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags   = interrupt enabled, resume, IOPL = 0
> current process= 0 (swapper)
> [ thread pid 0 tid 10 ]
> Stopped at  0x7abece31:calll   *0x18(%rax)
> db>
> 
> Sadly, there's no support for internal keyboard yet (it's connected via
> SPI), and external USB one stops working.
> 
> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> 
> Some questions here:
> - is this something that can/should be fixed?
> - can we print some "enabling EFIRT" message to the console to make
> guesses about the problem source a bit easier?
 
 It is not in 'enabling'.  Looking at the faulting VA, I believe that
 it occurs inside the BIOS code.
 
 Disable efirt by removing the kernel option, then try to load the module
 at runtime.  Does it still fault ?  Also, get the efi mem map for the
 machine and look at which region the faulting address and the faulting
 instruction belong.
>>> kldload'ing the efirt module gets the same fault.  Several top lines of 
>>> backtrace:
>>> kernphys() at 0x7abece31
>>> efi_get_time() at efi_get_time+0xd9
>>> efirtc_probe() at efirtc_probe+0x17
>> 
>> For the efi mem map, if I'm understanding it correctly, there's the 
>> following:
>> 
>> ...
>>   BootServicesData 7421d000  0a8b UC WC WT WB
>> ...
>> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
>> …
> 
> if my math is correct, this RTS code area will end at 0x7abe5000 and 
> if 0x7abece31 is fault location, its just after that RTS code area, 
> that is, 7 pages after… meaning you would need to get the next entry:)
> 

ya well, my math does suck because its 0x70 pages, not 70:D

rgds,
toomas

___
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: r336921 broke booting on MBP 2017, EFIRT related

[Yuri Pankov]

Yuri Pankov wrote:

Konstantin Belousov wrote:

On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:

Hi,

I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
20180802) fail to boot on MBP 2017:

kbd0 at kbdmux0
netmap: loaded module
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 2: apic id = 02
fault virtual address  = 0x74c64a50
fault code = supervisor read data, page not present
instruction pointer    = 0x20: 0x7abece31
stack pointer  = 0x28: 0x82b2f7c0
frame pointer  = 0x28: 0x82b2f810
code segment   = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process    = 0 (swapper)
[ thread pid 0 tid 10 ]
Stopped at  0x7abece31:    calll   *0x18(%rax)
db>

Sadly, there's no support for internal keyboard yet (it's connected via
SPI), and external USB one stops working.

A (not so quick) bisect is pointing at r336921, which enabled EFIRT.

Some questions here:
- is this something that can/should be fixed?
- can we print some "enabling EFIRT" message to the console to make
    guesses about the problem source a bit easier?


It is not in 'enabling'.  Looking at the faulting VA, I believe that
it occurs inside the BIOS code.

Disable efirt by removing the kernel option, then try to load the module
at runtime.  Does it still fault ?  Also, get the efi mem map for the
machine and look at which region the faulting address and the faulting
instruction belong.


kldload'ing the efirt module gets the same fault.  Several top lines of 
backtrace:


kernphys() at 0x7abece31
efi_get_time() at efi_get_time+0xd9
efirtc_probe() at efirtc_probe+0x17


For the efi mem map, if I'm understanding it correctly, there's the 
following:


...
   BootServicesData 7421d000  0a8b UC WC WT WB
...
RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
...
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Yuri Pankov]

Konstantin Belousov wrote:

On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:

Hi,

I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
20180802) fail to boot on MBP 2017:

kbd0 at kbdmux0
netmap: loaded module
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 2: apic id = 02
fault virtual address  = 0x74c64a50
fault code = supervisor read data, page not present
instruction pointer= 0x20: 0x7abece31
stack pointer  = 0x28: 0x82b2f7c0
frame pointer  = 0x28: 0x82b2f810
code segment   = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 0 (swapper)
[ thread pid 0 tid 10 ]
Stopped at  0x7abece31:calll   *0x18(%rax)
db>

Sadly, there's no support for internal keyboard yet (it's connected via
SPI), and external USB one stops working.

A (not so quick) bisect is pointing at r336921, which enabled EFIRT.

Some questions here:
- is this something that can/should be fixed?
- can we print some "enabling EFIRT" message to the console to make
guesses about the problem source a bit easier?


It is not in 'enabling'.  Looking at the faulting VA, I believe that
it occurs inside the BIOS code.

Disable efirt by removing the kernel option, then try to load the module
at runtime.  Does it still fault ?  Also, get the efi mem map for the
machine and look at which region the faulting address and the faulting
instruction belong.


kldload'ing the efirt module gets the same fault.  Several top lines of 
backtrace:


kernphys() at 0x7abece31
efi_get_time() at efi_get_time+0xd9
efirtc_probe() at efirtc_probe+0x17
___
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 and nvidia-driver again

[Alex V. Petrov]

For me it did not solve the problem.

29.08.2018 1:03, tech-lists пишет:
> On 28/08/2018 10:14, Alex V. Petrov wrote:
>> /usr/src Revision: 338342
>>
>>
>> ===>  Building for nvidia-driver-390.77
> 
> Hi,
> 
> Have you tried applying the patch at
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230780 ? Update your
> ports tree first.
> 
> Apply it in /usr/ports
> 
> It worked for me on r338323
> 

-- 
-
Alex.
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Konstantin Belousov]

On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
> Hi,
> 
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1, 
> 20180802) fail to boot on MBP 2017:
> 
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic id = 02
> fault virtual address  = 0x74c64a50
> fault code = supervisor read data, page not present
> instruction pointer= 0x20: 0x7abece31
> stack pointer  = 0x28: 0x82b2f7c0
> frame pointer  = 0x28: 0x82b2f810
> code segment   = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags   = interrupt enabled, resume, IOPL = 0
> current process= 0 (swapper)
> [ thread pid 0 tid 10 ]
> Stopped at  0x7abece31:calll   *0x18(%rax)
> db>
> 
> Sadly, there's no support for internal keyboard yet (it's connected via 
> SPI), and external USB one stops working.
> 
> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> 
> Some questions here:
> - is this something that can/should be fixed?
> - can we print some "enabling EFIRT" message to the console to make
>guesses about the problem source a bit easier?

It is not in 'enabling'.  Looking at the faulting VA, I believe that
it occurs inside the BIOS code.

Disable efirt by removing the kernel option, then try to load the module
at runtime.  Does it still fault ?  Also, get the efi mem map for the
machine and look at which region the faulting address and the faulting
instruction belong.
___
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"

r336921 broke booting on MBP 2017, EFIRT related

[Yuri Pankov]

Hi,

I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1, 
20180802) fail to boot on MBP 2017:


kbd0 at kbdmux0
netmap: loaded module
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 2: apic id = 02
fault virtual address  = 0x74c64a50
fault code = supervisor read data, page not present
instruction pointer= 0x20: 0x7abece31
stack pointer  = 0x28: 0x82b2f7c0
frame pointer  = 0x28: 0x82b2f810
code segment   = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 0 (swapper)
[ thread pid 0 tid 10 ]
Stopped at  0x7abece31:calll   *0x18(%rax)
db>

Sadly, there's no support for internal keyboard yet (it's connected via 
SPI), and external USB one stops working.


A (not so quick) bisect is pointing at r336921, which enabled EFIRT.

Some questions here:
- is this something that can/should be fixed?
- can we print some "enabling EFIRT" message to the console to make
  guesses about the problem source a bit easier?
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Wed, 29 Aug 2018 11:21:05 +0200
Michael Gmelin  wrote:

> On Sun, 26 Aug 2018 16:04:35 +0300
> Konstantin Belousov  wrote:
> 
> > On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:  
> > > Now, with the patch applied correctly, the machine actually boots.
> > > 
> > > Before calling init_ops.mp_bootaddress in
> > > getmemsize (machdep.c), physmap looks like this:
> > > 
> > > physmap_idx: 8
> > > i mem atop
> > > 0 0x0 0x0
> > > 1 0x3 0x30
> > > 2 0x4 0x40
> > > 3 0x9e400 0x9e
> > > 4 0x10 0x100
> > > 5 0xf0 0xf00
> > > 6 0x100 0x1000
> > > 7 0x7bf7a000 0x7bf7a
> > > 8 0x1 0x10
> > > 9 0x10060 0x100600
> > > 10 0x0 0x0
> > > 
> > > With your patch, it looks like this now
> > > (after calling getmemsize)
> > > 
> > > 0 0x0 0x0
> > > 1 0x3 0x30
> > > 2 0x4 0x40
> > > 3 0x9e400 0x9e
> > > 4 0x10 0x100
> > > 5 0xf0 0xf00
> > > 6 0x100 0x1000
> > > 7 0x7bf77000 0x7bf77
> > > 8 0x1 0x10
> > > 9 0x10060 0x100600
> > > 10 0x0 0x0
> > > PAGETABLES is 0x7bf77000
> > > 
> > > So I guess this means that the gap is now at the last three pages
> > > of [0x1000, 0x7bf7a[.
> > > 
> > > If this is what was intended, I guess it's good, as the machine
> > > boots okay now.
> > 
> > It triggered the new code to chomp at the end of the suitable range,
> > instead of the start. Anyway, to do that, it must evaluated the
> > start of the range as intersecting with the kernel text, which I
> > interpret as success.
> > 
> > I put a review with the change at D16907.
> >   
> > > 
> > > Sorry again for the extra roundtrip, the patched file was simply
> > > in the wrong path.
> > 
> > No problem.  
> 
> Just to close the loop on this: This was fixed in r338858, thanks to
> kib@ for analyzing the problem and creating a patch and to jhb@ for
> reviewing it.
> 

The actual revision this was fixed in is r338356
(https://svnweb.freebsd.org/base?view=revision=338356), I
tested r338358 (world+kernel) to verify the fix.

Best,
Michael

-- 
Michael Gmelin
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 26 Aug 2018 16:04:35 +0300
Konstantin Belousov  wrote:

> On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:
> > Now, with the patch applied correctly, the machine actually boots.
> > 
> > Before calling init_ops.mp_bootaddress in
> > getmemsize (machdep.c), physmap looks like this:
> > 
> > physmap_idx: 8
> > i mem atop
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x4 0x40
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf7a000 0x7bf7a
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > 
> > With your patch, it looks like this now
> > (after calling getmemsize)
> > 
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x4 0x40
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf77000 0x7bf77
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > PAGETABLES is 0x7bf77000
> > 
> > So I guess this means that the gap is now at the last three pages
> > of [0x1000, 0x7bf7a[.
> > 
> > If this is what was intended, I guess it's good, as the machine
> > boots okay now.  
> 
> It triggered the new code to chomp at the end of the suitable range,
> instead of the start. Anyway, to do that, it must evaluated the start
> of the range as intersecting with the kernel text, which I interpret
> as success.
> 
> I put a review with the change at D16907.
> 
> > 
> > Sorry again for the extra roundtrip, the patched file was simply in
> > the wrong path.  
> 
> No problem.

Just to close the loop on this: This was fixed in r338858, thanks to
kib@ for analyzing the problem and creating a patch and to jhb@ for
reviewing it.

Yours,
Michael

-- 
Michael Gmelin
___
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: old top and new -current: missing arcstat sysctl

[Alexander Leidinger]

Quoting Eitan Adler  (from Tue, 28 Aug 2018  
22:54:04 -0700):



On Tue, 28 Aug 2018 at 22:46, Alexander Leidinger
 wrote:

>
> IIRC that would have been the inverted case of running a newer top(1)
> with an older kernel lacking the v_laundry_pages sysctl.  In general I'd
> expect us to support running an older top(1) with newer kernels if we
> don't have to bend over backwards to provide compatibility.

If the new top is summing the 3 up anyway, it sounds like we could
provide the old one as backwards compatibility, even if it is
redundant. I rather have an redundant counter and an old top working
(in the generic case of what we promise to our users; in this specific
case for me I just need to get around to update the jails on the
corresponding systems), than bailing out without displaying anything.


I'd support this but don't feel like it justifies breaking the freeze.
After the 12.x freeze is over I'll implement this.


I would rather say this justifies breaking the freeze. Think about an  
user updating to 12.0... and having a 11.x jail inside (maybe as a  
first step before updating the jail itself, or not at all because of a  
bug in a 12.0 library he haven't found but is hitting the user). We  
want him to be able to have top working, don't we?


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
___
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: r336876 breaks sysutils/acpi_call

[Theron]

On 8/25/18 11:51 PM, Theron wrote:
A recent change in CURRENT has sysutils/acpi_call reliably cause a 
kernel panic


The problem is with the port itself, not with CURRENT.  A bug is filed 
accordingly.

___
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"