Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

[Rainer Hurling]

Am 09.01.24 um 21:40 schrieb Gleb Smirnoff:

   Rainer,

On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote:
R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very
R> recent commit. The build and install went fine. After booting with new
R> base, I got a page fault with the following error:

Sorry for that, my fault. Can you please test this patch?



Hi Gleb,

Thanks for the very fast response.

I tried your patch and it seems to work as expected. I have a running 
system, with WireGuard on, at commit main-n267469-0013741108bc-dirty.


Many thanks again and best wishes,
Rainer

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

[Gleb Smirnoff]

  Rainer,

On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote:
R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very
R> recent commit. The build and install went fine. After booting with new
R> base, I got a page fault with the following error:

Sorry for that, my fault. Can you please test this patch?

-- 
Gleb Smirnoff
diff --git a/sys/netlink/netlink_domain.c b/sys/netlink/netlink_domain.c
index 7660dcada103..4790845d1d31 100644
--- a/sys/netlink/netlink_domain.c
+++ b/sys/netlink/netlink_domain.c
@@ -233,7 +233,7 @@ nl_send_group(struct nl_writer *nw)
 copy = nl_buf_copy(nb);
 if (copy != NULL) {
 	nw->buf = copy;
-	(void)nl_send_one(nw);
+	(void)nl_send(nw, nlp_last);
 } else {
 	NLP_LOCK(nlp_last);
 	if (nlp_last->nl_socket != NULL)
@@ -246,7 +246,7 @@ nl_send_group(struct nl_writer *nw)
 	}
 	if (nlp_last != NULL) {
 		nw->buf = nb;
-		(void)nl_send_one(nw);
+		(void)nl_send(nw, nlp_last);
 	} else
 		nl_buf_free(nb);
 
diff --git a/sys/netlink/netlink_io.c b/sys/netlink/netlink_io.c
index fb8e0a46e8dd..5f50c40f71d8 100644
--- a/sys/netlink/netlink_io.c
+++ b/sys/netlink/netlink_io.c
@@ -194,9 +194,8 @@ nl_taskqueue_handler(void *_arg, int pending)
  * If no queue overrunes happened, wakes up socket owner.
  */
 bool
-nl_send_one(struct nl_writer *nw)
+nl_send(struct nl_writer *nw, struct nlpcb *nlp)
 {
-	struct nlpcb *nlp = nw->nlp;
 	struct socket *so = nlp->nl_socket;
 	struct sockbuf *sb = &so->so_rcv;
 	struct nl_buf *nb;
diff --git a/sys/netlink/netlink_message_writer.c b/sys/netlink/netlink_message_writer.c
index 0b85378b41b6..50305e3d9d80 100644
--- a/sys/netlink/netlink_message_writer.c
+++ b/sys/netlink/netlink_message_writer.c
@@ -65,6 +65,13 @@ nlmsg_get_buf(struct nl_writer *nw, u_int len, bool waitok)
 	return (true);
 }
 
+static bool
+nl_send_one(struct nl_writer *nw)
+{
+
+	return (nl_send(nw, nw->nlp));
+}
+
 bool
 _nlmsg_get_unicast_writer(struct nl_writer *nw, int size, struct nlpcb *nlp)
 {
diff --git a/sys/netlink/netlink_var.h b/sys/netlink/netlink_var.h
index c8f0d02a0dab..ddf30b373446 100644
--- a/sys/netlink/netlink_var.h
+++ b/sys/netlink/netlink_var.h
@@ -130,9 +130,7 @@ void nl_osd_unregister(void);
 void nl_set_thread_nlp(struct thread *td, struct nlpcb *nlp);
 
 /* netlink_io.c */
-#define	NL_IOF_UNTRANSLATED	0x01
-#define	NL_IOF_IGNORE_LIMIT	0x02
-bool nl_send_one(struct nl_writer *);
+bool nl_send(struct nl_writer *, struct nlpcb *);
 void nlmsg_ack(struct nlpcb *nlp, int error, struct nlmsghdr *nlmsg,
 struct nl_pstate *npt);
 void nl_on_transmit(struct nlpcb *nlp);

kernel: fatal trap 12 on CURRENT, when using WireGuard

[Rainer Hurling]

I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a 
very recent commit. The build and install went fine. After booting with 
new base, I got a page fault with the following error:



Kernel page fault with the following non-sleepable locks held:
shared rm netlink lock (netlink lock) r = 0 (0xf8005fc8ca20) locked 
@ /usr/src/sys/netlink/netlink_domain.c:241
exclusive rw lle (lle) r = 0 (0xf801951dce90) locked @ 
/usr/src/sys/netinet/in.c:1716

stack backtrace:
#0 0x80bc6c45 at witness_debugger+0x65
#1 0x80bc7d89 at witness_warn+0x3e9
#2 0x81056b18 at trap_pfault+0x88
#3 0x81028708 at calltrap+0x8
#4 0x80dbd6a2 at nl_send_group+0x1d2
#5 0x80dc0e27 at _nlmsg_flush+0x37
#6 0x80dc4fdc at rtnl_lle_event+0x10c
#7 0x80d15e32 at arp_mark_lle_reachable+0xd2
#8 0x80d15b43 at arp_check_update_lle+0x293
#9 0x80d151c5 at arpintr+0xa65
#10 0x80caaaed at netisr_dispatch_src+0xad
#11 0x80c8d57a at ether_demux+0x0x17a
#12 0x80c8ec53 at ether_nh_input+0x403
#13 0x80caaaed at netisr_dispatch_src+0xad
#14 0x80c8d9c9 at ether_input+0xd9
#15 0x80ca66ac at iflib_rxeof+0xe4c
#16 0x80ca0b5a at _task_fn_rx+0x7a
#17 0x80ba0118 at gtaskqueue_run_locked+0xa8

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x3
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80dc0a10
stack pointer   = 0x28:0xfe006a3a8760
frame pointer   = 0x28:0xfe006a3a8790
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 (if_io_tqg_0)
rdi: fe006a3a8850 rsi: fe006a3a86f0 rdx: fe006a3a87b0
rcx: f80001f88740  r8: 83210090  r9: 
rax:  rbx: 0003 rbp: fe006a3a8790
r10: 0001 r11:  r12: f8005fc8ca00
r13: f8005fc8ca20 r14: fe006a3a8850 r15: 
trap number = 12
panic: page fault
cpuid = 0
time = 1704824328
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe006a3a8430

vpanic() at vpanic+0x131/frame 0xfe006a3a8560
panic() at panic+0x43/frame 0xfe006a3a85c0
trap_fatal() at trap_fatal+0x40f/frame 0xfe006a3a8620
trap_pfault() at trap_pfault+0xae/frame 0xfe006a3a8690
calltrap() at calltrap+0x8/frame 0xfe006a3a8690
--- trap 0xc, rip = 0x80dc0a10, rsp = 0xfe006a3a8760, rbp = 
0xfe006a3a8790 ---

nl_send_one() at nl_send_one+0x20/frame 0xfe006a3a8790
nl_send_group() at nl_send_group+0x1d2/frame 0xfe006a3a8820
_nlmsg-flush() at _nlmsg_flush+0x37/frame 0xfe006a3a8840
rtnl_lle_event() at rtnl_lle_event+0x10c/frame 0xfe006a3a88e0
arp_mark_lle_reachable() at arp_mark_lle_reachable+0xd2/frame 
0xfe006a3a8930
arp_check_update_lle() at arp_check_update_lle+0x293/frame 
0xfe006a3a8a00

arpintr() at arpintr+0xa65/frame 0xfe006a3a8b60
netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfe006a3a8bc8
ether_demux() at ether_demux+0x17a/frame 0xfe006a4a8bf0
ether_nh_input() at ether_nh_input+0x403/frame 0xfe006a3a8c40
netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfe006a3a8ca0
ether_input() at ehter_input+0xd9/frame 0xfe006a3a8d00
iflib_rxeof() at iflib_rxeof+0xe4c/frame 0xfe006a3a8e00
_task_fn_rx() at _task_fn_rx+0x7a/frame 0xfe006a3a8e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa8/frame 
0xfe006a3a8ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xd3/frame 
0xfe006a3a8ef0

fork_exit() at fork_exit+0x82/frame 0xfe006a3a8f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe006a3a8f30
--- trap 0xf2b9f109, rip = 0x7afef8a176bef8a5, rsp = 0xddc963edd18963e9, 
rbp = 0x61f64fc36db64fc7

KDB: enter: panic
[ thread pid 0 tid 100067 ]
Stopped at  kdb_enter+0x33: movq$0,0xe3a582(%rip)
db>


Since the current process 'if_io_tqg_0' and problems with netlink are 
mentioned, I searched in the area of my network connections. I 
discovered that this page fault only occurs when a connection is 
established with WireGuard (wg-quick up wg0). Without using WireGuard, 
this error does not occur.


I was able to find out at which commit this behavior occurs with my box:
- Up to commit main-n267347-660bd40a598a everything is fine.
- The two following commits n267348-67d9023f07a4 and 
n267349-0ad011ececb9 do not build on my box (module/netlink broken ...).
- From commit n267349-0ad011ececb9 (netlink) onwards this page fault 
occurs when WireGuard is started.


Any help is greatly appreciated.
CC'ed Gleb Smirnoff due to the affected commits.

Regards,
Rainer Hurling

Re: Fatal trap 12: if_io_tqg_11: ~main-n248851-0d55bc8eb2a:

[Oleg Ginzburg]

Please ignore this. updating to the latest revision fixed the problem.

On Sun, Aug 22, 2021 at 11:12 PM Oleg Ginzburg  wrote:

> Hi,
>
> One of my regularly updated hosts on the 14-CURRENT started to reboot
> constantly when initializing the network stack (both IPv4/V6 stacks are
> active), current rev: ( 22997b755013bdde60119fdc781769192ab7e1e0 Sat Aug 7
> 21:25:36 2021 +0100 )
>
> crash info:
> --
> ...
> <118>Starting devd.
> <118>Starting Network: igb1.
> <118>igb1: flags=8822 metric 0 mtu 1500
> <118>
>   
> options=4e507bb
>
> <118>   ether b4:96:91:95:97:ed
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 11; apic id = 0b
> fault virtual address   = 0x128
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80c1effd
> stack pointer   = 0x28:0xfe01159efeb0
> frame pointer   = 0x28:0xfe01159efeb0
> 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 (if_io_tqg_11)
> trap number = 12
> panic: page fault
> cpuid = 11
> time = 1629661329
> Uptime: 1m14s
> Dumping 2158 out of 65309
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>
> __curthread () at /usr/jails/src/src_14/src/sys/amd64/include/pcpu_aux.h:55
>
> 55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(
> struct pcpu,
> (kgdb)
>
> (kgdb) list *0x80c1effd
> 0x80c1effd is in __rw_rlock_int
> (/usr/jails/src/src_14/src/sys/kern/kern_rwlock.c:679).
> 674 KASSERT(rw_wowner(rw) != td,
> 675 ("rw_rlock: wlock already held for %s @ %s:%d",
> 676 rw->lock_object.lo_name, file, line));
> 677 WITNESS_CHECKORDER(&rw->lock_object, LOP_NEWORDER, file,
> line, NULL);
> 678
> 679 v = RW_READ_VALUE(rw);
> 680 if (__predict_false(LOCKSTAT_PROFILE_ENABLED(rw__acquire)
> ||
> 681 !__rw_rlock_try(rw, td, &v, true LOCK_FILE_LINE_ARG)))
> 682 __rw_rlock_hard(rw, td, v LOCK_FILE_LINE_ARG);
> 683 else
>
>
> --
>
>
> I haven’t looked at the details so far, perhaps you have comments on the
> latest changes. Latest revision that works successfully: n246318-163153c2a08
> ( the host is updated approximately once a week )
>
>
>

Fatal trap 12: if_io_tqg_11: ~main-n248851-0d55bc8eb2a:

[Oleg Ginzburg]

Hi,

One of my regularly updated hosts on the 14-CURRENT started to reboot
constantly when initializing the network stack (both IPv4/V6 stacks are
active), current rev: ( 22997b755013bdde60119fdc781769192ab7e1e0 Sat Aug 7
21:25:36 2021 +0100 )

crash info:
--
...
<118>Starting devd.
<118>Starting Network: igb1.
<118>igb1: flags=8822 metric 0 mtu 1500
<118>
  
options=4e507bb

<118>   ether b4:96:91:95:97:ed

Fatal trap 12: page fault while in kernel mode
cpuid = 11; apic id = 0b
fault virtual address   = 0x128
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80c1effd
stack pointer   = 0x28:0xfe01159efeb0
frame pointer   = 0x28:0xfe01159efeb0
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 (if_io_tqg_11)
trap number = 12
panic: page fault
cpuid = 11
time = 1629661329
Uptime: 1m14s
Dumping 2158 out of 65309
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/jails/src/src_14/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb)

(kgdb) list *0x80c1effd
0x80c1effd is in __rw_rlock_int
(/usr/jails/src/src_14/src/sys/kern/kern_rwlock.c:679).
674 KASSERT(rw_wowner(rw) != td,
675 ("rw_rlock: wlock already held for %s @ %s:%d",
676 rw->lock_object.lo_name, file, line));
677 WITNESS_CHECKORDER(&rw->lock_object, LOP_NEWORDER, file,
line, NULL);
678
679 v = RW_READ_VALUE(rw);
680 if (__predict_false(LOCKSTAT_PROFILE_ENABLED(rw__acquire) ||
681 !__rw_rlock_try(rw, td, &v, true LOCK_FILE_LINE_ARG)))
682 __rw_rlock_hard(rw, td, v LOCK_FILE_LINE_ARG);
683 else


--


I haven’t looked at the details so far, perhaps you have comments on the
latest changes. Latest revision that works successfully: n246318-163153c2a08
( the host is updated approximately once a week )

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 19, 2021, at 4:19 PM, Thomas Laus  wrote:
> 
> On 6/19/21 2:21 PM, Bakul Shah wrote:
>> 
>> You may wish to see if Andriy Gapon's method (LOCAL_MODULES_DIR, 
>> LOCAL_MODULES)
>> works better for you.
>> 
>> I trust Makefile* to do the right thing with META_MODE and CCACHE (and if 
>> they
>> don't, it is a bug that would need to be fixed) so I personally don't see the
>> need to "rm -rf /usr/obj/*".
>> 
> I have been performing the rm -rf /usr/obj/* procedure almost weekly
> since FreeBSD 4.1 and has kept me out of trouble for many years.  The PC
> that I use to update Current can build both world and kernel in under an
> hour with a clean object directory.  Performing a 'git up ports' and
> rebuilding the drm module before building world is not a major time
> consumer for me if I remember to do it first.

One final response in this thread!

# cd /usr/src; git pull
Already up to date.
# make -j8 buildworld buildkernel >& err
# grep 'built in' err
>>> World built in 132 seconds, ncpu: 4, make -j8
>>> Kernel(s)  GENERIC built in 459 seconds, ncpu: 4, make -j8
# reboot
...
# uname -v
FreeBSD 14.0-CURRENT #6 main-n247581-0bcd49c13ada: Fri Jun 25 14:45:59 PDT 2021
...

This includes drm-kmod. I had run the same 4 days back. 

This is on a bhyve *virtual machine* (4 cores, 8GB RAM).
Its "disk" is a zfs file (pretending to be NVME) on a
3 year old ryzen box with 8 cores and 64GB RAM. The host
is running 13.0-RELEASE-p1.

Re: drm-kmod kernel crash fatal trap 12

[Thomas Laus]

On 6/19/21 2:21 PM, Bakul Shah wrote:
> 
> You may wish to see if Andriy Gapon's method (LOCAL_MODULES_DIR, 
> LOCAL_MODULES)
> works better for you.
> 
> I trust Makefile* to do the right thing with META_MODE and CCACHE (and if they
> don't, it is a bug that would need to be fixed) so I personally don't see the
> need to "rm -rf /usr/obj/*".
>
I have been performing the rm -rf /usr/obj/* procedure almost weekly
since FreeBSD 4.1 and has kept me out of trouble for many years.  The PC
that I use to update Current can build both world and kernel in under an
hour with a clean object directory.  Performing a 'git up ports' and
rebuilding the drm module before building world is not a major time
consumer for me if I remember to do it first.

Thanks for the suggestions on some alternatives to my world building
exercise.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 18, 2021, at 7:05 AM, Thomas Laus  wrote:
> 
> On 6/10/21 11:13 AM, Bakul Shah wrote:
>> This is what I did:
>> 
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>> 
>> Now it gets compiled every time you do make buildkernel.
>> If things break you can do a git pull in the drm-kmod dir
>> and rebuild.
>> 
> That did not work for me.  The buildkernel operation failed at the
> operation 'cleandir' phase.  The message was 'don't know how to make
> cleandir stop'.

I suspect you are not using WITH_META_MODE=yes. That seems to obviate
the need for running cleandir though I don't how (and I don't have the
patience to wade through the complex logic in /usr/src/Makefile*).
FWIW, my build flags:

$ cat /etc/{make,src,src-env}.conf
MALLOC_PRODUCTION=yes
WITHOUT_CLANG=yes
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/usr/obj/ccache
WITH_META_MODE=yes

If you forget to "kldload filemon" make build{kernel,world} will
remind you!

Re: drm-kmod kernel crash fatal trap 12

[Thomas Laus]

On 6/10/21 11:13 AM, Bakul Shah wrote:
> This is what I did:
> 
> git clone https://github.com/freebsd/drm-kmod
> ln -s $PWD/drm-kmod /usr/local/sys/modules
> 
> Now it gets compiled every time you do make buildkernel.
> If things break you can do a git pull in the drm-kmod dir
> and rebuild.
>
That did not work for me.  The buildkernel operation failed at the
operation 'cleandir' phase.  The message was 'don't know how to make
cleandir stop'.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: drm-kmod kernel crash fatal trap 12

[John Baldwin]

On 6/15/21 11:22 AM, Bakul Shah wrote:

On Jun 15, 2021, at 9:03 AM, John Baldwin  wrote:


On 6/10/21 8:13 AM, Bakul Shah wrote:

On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:

The drm-kmod module is the latest from the pkg server.  It all
worked this past Monday after the recent drm-kmod update.

This is what I did:
git clone https://github.com/freebsd/drm-kmod
ln -s $PWD/drm-kmod /usr/local/sys/modules
Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.


This is what I do now as well.  I think this is probably the
sanest approach to use on HEAD at least.


IIRC I learned this from one of your posts.

The PORTS_MODULES approach results in installing kernel modules
/boot/modules, which doesn't track /boot/kernel*/.


Yes, PORTS_MODULES is not so great when you are building test kernels
from branches that are different points in time and then go back to
booting your "stock" kernel as the module is now built against the
wrong ABI and breaks your "stock" kernel.

This is why I added LOCAL_MODULES and the SRC knob to drm-kmod,
but the source knob is a bit bumpy in practice as you sometimes
need newer source than your current package.  (For example, if your
"stock" kernel only changes every few months, but you pull newer
work trees for test kernels.)  For that case, it has proven simpler
to just do the direct checkout that I can git pull when needed.

--
John Baldwin

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 15, 2021, at 9:03 AM, John Baldwin  wrote:
> 
> On 6/10/21 8:13 AM, Bakul Shah wrote:
>> On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:
>>> The drm-kmod module is the latest from the pkg server.  It all
>>> worked this past Monday after the recent drm-kmod update.
>> This is what I did:
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>> Now it gets compiled every time you do make buildkernel.
>> If things break you can do a git pull in the drm-kmod dir
>> and rebuild.
> 
> This is what I do now as well.  I think this is probably the
> sanest approach to use on HEAD at least.

IIRC I learned this from one of your posts.

The PORTS_MODULES approach results in installing kernel modules
/boot/modules, which doesn't track /boot/kernel*/.

Re: drm-kmod kernel crash fatal trap 12

[John Baldwin]

On 6/10/21 8:13 AM, Bakul Shah wrote:

On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:

The drm-kmod module is the latest from the pkg server.  It all
worked this past Monday after the recent drm-kmod update.


This is what I did:

git clone https://github.com/freebsd/drm-kmod
ln -s $PWD/drm-kmod /usr/local/sys/modules

Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.


This is what I do now as well.  I think this is probably the
sanest approach to use on HEAD at least.

--
John Baldwin

Re: drm-kmod kernel crash fatal trap 12

[Andriy Gapon]

On 10/06/2021 18:13, Bakul Shah wrote:

On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:

The drm-kmod module is the latest from the pkg server.  It all
worked this past Monday after the recent drm-kmod update.


This is what I did:

git clone https://github.com/freebsd/drm-kmod
ln -s $PWD/drm-kmod /usr/local/sys/modules

Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.


I did approximately the same, but instead of a symlink I use LOCAL_MODULES_DIR 
and LOCAL_MODULES.


--
Andriy Gapon

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 10, 2021, at 9:49 AM, Philipp Ost  wrote:
> 
> On 6/10/21 5:13 PM, Bakul Shah wrote:
>> On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:
>>> The drm-kmod module is the latest from the pkg server.  It all
>>> worked this past Monday after the recent drm-kmod update.
>> This is what I did:
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>> Now it gets compiled every time you do make buildkernel.
> 
> Why don't you set PORTS_MODULES in make.conf accordingly?

I used to do that but ran into problems such as doing
pkg upgrade which wanted to overwrite it when the port was
updated.

Re: drm-kmod kernel crash fatal trap 12

[Cy Schubert]

In message <4894bd36-92bd-596e-cc18-cd3e6aafe...@selasky.org>, Hans Petter 
Sela
sky writes:
> On 6/9/21 4:43 PM, Thomas Laus wrote:
> > I updated my system this morning to main-n247260-dc318a4ffab June 9 2012
> > and the first boot after the kernel was loaded I received:
> > 
> > 'fatal trap 12' fault virtual address = 0x0
> > fault code = supervisor write data, page not present
> > instruction pointer = 0x20:0x82fc3d1b
> > stack pointer = 0x28:0xfe011aea3330
> > frame pointer = 0x28:0xfe011aea3370
> > code segment = base 0x0 limit 0x, type 0x1b
> > DPL 0,pres 1, long 1, def 32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process = 1187 (kldload)
> > trap number = 12
> > 
> > I hand copied the screen display since I was not able to generate a
> > crash dump to /var/crash on a zfs file system.
> > 
> > I am rebuilding the GENERIC kernel since the crash was using the NODEBUG
> > version.  This is 100 percent repeatable.
> > 
> > Tom
> > 
>
> Make sure you also re-build the drm-kmod module.

And while you're at it, update your copy of the drm-* port to the latest.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.

Re: drm-kmod kernel crash fatal trap 12

[Philipp Ost]

On 6/10/21 5:13 PM, Bakul Shah wrote:

On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:

The drm-kmod module is the latest from the pkg server.  It all
worked this past Monday after the recent drm-kmod update.


This is what I did:

git clone https://github.com/freebsd/drm-kmod
ln -s $PWD/drm-kmod /usr/local/sys/modules

Now it gets compiled every time you do make buildkernel.


Why don't you set PORTS_MODULES in make.conf accordingly?

Philipp

Re: drm-kmod kernel crash fatal trap 12

[Thomas Laus]

Bakul Shah [ba...@iitbombay.org] wrote:
> 
> This is what I did:
> 
> git clone https://github.com/freebsd/drm-kmod
> ln -s $PWD/drm-kmod /usr/local/sys/modules
> 
> Now it gets compiled every time you do make buildkernel.
> If things break you can do a git pull in the drm-kmod dir
> and rebuild.
>
Great idea and I will make this change.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: drm-kmod kernel crash fatal trap 12

[Thomas Laus]

Hans Petter Selasky [h...@selasky.org] wrote:
> 
> When you use -current, you need to compile this pkg from the latest ports.
> I'm not sure if that happens automatically when you install the binary
> package.
>
I just built drm-current-kmod as a port and things work.  Building
a kernel in the past used to build drm-current-kmod automatically as
part of the process.  It looks like that has been turned off and I will
need to build it each time that the port is updated.

Thanks for the help.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:
> The drm-kmod module is the latest from the pkg server.  It all
> worked this past Monday after the recent drm-kmod update.

This is what I did:

git clone https://github.com/freebsd/drm-kmod
ln -s $PWD/drm-kmod /usr/local/sys/modules

Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.

Re: drm-kmod kernel crash fatal trap 12

[Hans Petter Selasky]

On 6/10/21 4:13 PM, Thomas Laus wrote:

The drm-kmod module is the latest from the pkg server.  It all
worked this past Monday after the recent drm-kmod update.


When you use -current, you need to compile this pkg from the latest 
ports. I'm not sure if that happens automatically when you install the 
binary package.


--HPS

Re: drm-kmod kernel crash fatal trap 12

[Thomas Laus]

Hans Petter Selasky [h...@selasky.org] wrote:
> 
> Make sure you also re-build the drm-kmod module.
>
The drm-kmod module is the latest from the pkg server.  It all
worked this past Monday after the recent drm-kmod update.

Things are good at n247230.  I cleaned my source today and checked
out fresh.  I also performed a rm -rf /usr/obj/* before rebuilding
today.  This panic still exists at main-247280-98597880632.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: drm-kmod kernel crash fatal trap 12

[Hans Petter Selasky]

On 6/9/21 4:43 PM, Thomas Laus wrote:

I updated my system this morning to main-n247260-dc318a4ffab June 9 2012
and the first boot after the kernel was loaded I received:

'fatal trap 12' fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x82fc3d1b
stack pointer = 0x28:0xfe011aea3330
frame pointer = 0x28:0xfe011aea3370
code segment = base 0x0 limit 0x, type 0x1b
DPL 0,pres 1, long 1, def 32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1187 (kldload)
trap number = 12

I hand copied the screen display since I was not able to generate a
crash dump to /var/crash on a zfs file system.

I am rebuilding the GENERIC kernel since the crash was using the NODEBUG
version.  This is 100 percent repeatable.

Tom



Make sure you also re-build the drm-kmod module.

--HPS

drm-kmod kernel crash fatal trap 12

[Thomas Laus]

I updated my system this morning to main-n247260-dc318a4ffab June 9 2012
and the first boot after the kernel was loaded I received:

'fatal trap 12' fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x82fc3d1b
stack pointer = 0x28:0xfe011aea3330
frame pointer = 0x28:0xfe011aea3370
code segment = base 0x0 limit 0x, type 0x1b
   DPL 0,pres 1, long 1, def 32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1187 (kldload)
trap number = 12

I hand copied the screen display since I was not able to generate a
crash dump to /var/crash on a zfs file system.

I am rebuilding the GENERIC kernel since the crash was using the NODEBUG
version.  This is 100 percent repeatable.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

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

[Konstantin Belousov]

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.
___
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 24. Aug 2018, at 22:39, Konstantin Belousov  wrote:
>> 
>> On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote:
>> 
>> 
>>> On 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
>>> Please apply the following debugging patch on top of the previous 'fix'.
>>> You need debug.late_console=0.
>> 
>> Unfortunately debug.late_console=0 doesn???t work on this machine (no more 
>> output on the console), I tried that earlier in this thread - hence the 
>> slightly complicated debugging code I had to add to see the contents of 
>> physmap.
>> 
>> I could run this code after boot (feeding it an identical physmap) to get 
>> debug output, would this make sense?
> Yes, with exactly the same physmap[].
> 
> Really, I do not need exactly the output from my patch, but just make it
> clear why is_kernel_paddr() did not triggered selection from different
> location.

I have to apologize, something went wrong
when I applied your previous fix, so it was never really used when I tested.

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.

Sorry again for the extra roundtrip, the patched file was simply in the wrong 
path.

Yours,
Michael

p.s. Please see below the patched version of
mp_machdep.c I used for testing (should match yours):

...
#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)

externstruct pcpu __pcpu[];

/* Temporary variables for init_secondary()  */
char *doublefault_stack;
char *mce_stack;
char *nmi_stack;
char *dbg_stack;

/*
* Local data and functions.
*/

static intstart_ap(int apic_id);

static bool
is_kernel_paddr(vm_paddr_t pa)
{

 return (pa >= trunc_2mpage(btext - KERNBASE) &&
pa < round_page(_end - KERNBASE));
}

static bool
is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
{

 return (start + AP_BOOTPT_SZ <= GiB(4) &&
 end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
}

/*
* Calculate usable address in base memory for AP trampoline code.
*/
void
mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
{
 vm_paddr_t start, end;
 unsigned int i;
 bool allocated;

 alloc_ap_trampoline(physmap, physmap_idx);

 /*
  * Find a memory region big enough below the 4GB boundary to
  * store the initial page tables.  Region must be mapped by
  * the direct map.
  *
  * Note that it needs to be aligned to a page boundary.
  */
 allocated = false;
 for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
 /*
  * First, try to chomp at the start of the physmap region.
  * Kernel binary might claim it already.
  */
 start = round_page(physmap[i]);
 end = trunc_page(physmap[i + 1]);
 if (is_mpboot_good(start, end) &&
 !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
 allocated = true;
 physmap[i] = start + AP_BOOTPT_SZ;
 break;
 }

 /*
  * Second, try to chomp at the end.  Again, check
  * against kernel.
  */
 end = trunc_page(physmap[i + 1]);
 start = end - AP_BOOTPT_SZ;
 if (start >= physmap[i] && is_mpboot_good(start, end) &&
 !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
 allocated = true;
 physmap[i + 1] = start;
 break;
 }
 }
 if (allocated) {
 mptramp_pagetables = start;
 if (physmap[i] == physmap[i + 1] && *physmap_idx != 0) {
 memmove(&physmap[i], &physmap[i + 2],
 sizeof(*physmap) * (*physmap_idx - i + 2));
 *physmap_idx -= 2;
 }
 } else {
 mptramp_pagetables = trunc_page(boot_address) - AP_BOOTPT_SZ;
 if (bootverbose)
 printf(
"Cannot find enough space for the initial AP page tables, placing them at %#x",
 mptramp_pagetables);
 }
}
...



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

[Konstantin Belousov]

On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote:
> 
> 
> > On 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
> > Please apply the following debugging patch on top of the previous 'fix'.
> > You need debug.late_console=0.
> 
> Unfortunately debug.late_console=0 doesn???t work on this machine (no more 
> output on the console), I tried that earlier in this thread - hence the 
> slightly complicated debugging code I had to add to see the contents of 
> physmap.
> 
> I could run this code after boot (feeding it an identical physmap) to get 
> debug output, would this make sense?
> 
Yes, with exactly the same physmap[].

Really, I do not need exactly the output from my patch, but just make it
clear why is_kernel_paddr() did not triggered selection from different
location.


___
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 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
> 
>> On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
>> 
>> 
 On 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
 
 On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
 
 
>> On 22. Aug 2018, at 17:46, Konstantin Belousov  
>> wrote:
>> 
>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>> 
>> 
 On 20. Aug 2018, at 17:09, Konstantin Belousov  
 wrote:
 
 On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
 
 See here for a screenshot (also including the output of "show pte
 0xf8000100"):
 
 https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
>>> It is too early for ddb routines to register.
>>> Ok can you try the following debugging patch, to verify my guess ?
>>> 
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 18777d23f09..cd05fdb763f 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>>> pd_p = (pd_entry_t *)DMPDkernphys;
>>> for (i = 0; i < (NPDEPG * nkdmpde); i++)
>>> pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
>>> -X86_PG_M | X86_PG_A | pg_nx |
>>> -bootaddr_rwx(i << PDRSHIFT);
>>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>>> for (i = 0; i < nkdmpde; i++)
>>> pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>>> X86_PG_V;
>> 
>> With this change it boots okay (mptramp_pagetables is 0x100, as 
>> expected).
> 
> Can you apply the following on top of the previous debugging patch and 
> show
> me the line printed ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 3d70532b7fd..613fa9f2165 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
>  pmap->pm_pcids[i].pm_gen = 1;
>  }
>  pmap_activate_boot(pmap);
> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, 
> (uintptr_t)etext, (uintptr_t)KERNBASE);
> }
> 
> void
 
 bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
 0x823cf840 brwsection #81a0 etext 0x812041e4 
 KERNBASE 0x8000
 
>>> 
>>> Try this, please.  Revert all debugging pmap.c patches that I provided
>>> before.
>>> 
>>> diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
>>> index 4ca2e07e578..2ee8f862854 100644
>>> --- a/sys/amd64/amd64/mp_machdep.c
>>> +++ b/sys/amd64/amd64/mp_machdep.c
>>> @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
>>> 
>>> #define GiB(v)(v ## ULL << 30)
>>> 
>>> +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
>>> +
>>> externstruct pcpu __pcpu[];
>>> 
>>> /* Temporary variables for init_secondary()  */
>>> @@ -101,45 +103,78 @@ char *dbg_stack;
>>> 
>>> static intstart_ap(int apic_id);
>>> 
>>> +static bool
>>> +is_kernel_paddr(vm_paddr_t pa)
>>> +{
>>> +
>>> +return (pa >= trunc_2mpage(btext - KERNBASE) &&
>>> +   pa < round_page(_end - KERNBASE));
>>> +}
>>> +
>>> +static bool
>>> +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
>>> +{
>>> +
>>> +return (start + AP_BOOTPT_SZ <= GiB(4) &&
>>> +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
>>> +}
>>> +
>>> /*
>>> * Calculate usable address in base memory for AP trampoline code.
>>> */
>>> void
>>> mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
>>> {
>>> +vm_paddr_t start, end;
>>>   unsigned int i;
>>>   bool allocated;
>>> 
>>>   alloc_ap_trampoline(physmap, physmap_idx);
>>> 
>>> +/*
>>> + * Find a memory region big enough below the 4GB boundary to
>>> + * store the initial page tables.  Region must be mapped by
>>> + * the direct map.
>>> + *
>>> + * Note that it needs to be aligned to a page boundary.
>>> + */
>>>   allocated = false;
>>>   for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
>>>   /*
>>> - * Find a memory region big enough below the 4GB
>>> - * boundary to store the initial page tables.  Region
>>> - * must be mapped by the direct map.
>>> - *
>>> - * Note that it needs to be aligned to a page
>>> - * boundary.
>>> + * First, try to chomp at the start of the physmap region.
>>> + * Kernel binary might claim it already.
>>> + */
>>> +start = round_page(physmap[i]);
>>> +end = trunc_page(physmap[i + 1]);
>>> +if (is_mpboot_good(start, end) &&

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
> 
> 
> > On 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
> > 
> >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> >> 
> >> 
>  On 22. Aug 2018, at 17:46, Konstantin Belousov  
>  wrote:
>  
>  On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>  
>  
> >> On 20. Aug 2018, at 17:09, Konstantin Belousov  
> >> wrote:
> >> 
> >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >> 
> >> See here for a screenshot (also including the output of "show pte
> >> 0xf8000100"):
> >> 
> >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> > It is too early for ddb routines to register.
> > Ok can you try the following debugging patch, to verify my guess ?
> > 
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 18777d23f09..cd05fdb763f 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >  pd_p = (pd_entry_t *)DMPDkernphys;
> >  for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >  pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> > -X86_PG_M | X86_PG_A | pg_nx |
> > -bootaddr_rwx(i << PDRSHIFT);
> > +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >  for (i = 0; i < nkdmpde; i++)
> >  pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >  X86_PG_V;
>  
>  With this change it boots okay (mptramp_pagetables is 0x100, as 
>  expected).
> >>> 
> >>> Can you apply the following on top of the previous debugging patch and 
> >>> show
> >>> me the line printed ?
> >>> 
> >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>> index 3d70532b7fd..613fa9f2165 100644
> >>> --- a/sys/amd64/amd64/pmap.c
> >>> +++ b/sys/amd64/amd64/pmap.c
> >>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> >>>   pmap->pm_pcids[i].pm_gen = 1;
> >>>   }
> >>>   pmap_activate_boot(pmap);
> >>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> >>> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> >>> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, 
> >>> (uintptr_t)etext, (uintptr_t)KERNBASE);
> >>> }
> >>> 
> >>> void
> >> 
> >> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
> >> 0x823cf840 brwsection #81a0 etext 0x812041e4 
> >> KERNBASE 0x8000
> >> 
> > 
> > Try this, please.  Revert all debugging pmap.c patches that I provided
> > before.
> > 
> > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> > index 4ca2e07e578..2ee8f862854 100644
> > --- a/sys/amd64/amd64/mp_machdep.c
> > +++ b/sys/amd64/amd64/mp_machdep.c
> > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
> > 
> > #define GiB(v)(v ## ULL << 30)
> > 
> > +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
> > +
> > externstruct pcpu __pcpu[];
> > 
> > /* Temporary variables for init_secondary()  */
> > @@ -101,45 +103,78 @@ char *dbg_stack;
> > 
> > static intstart_ap(int apic_id);
> > 
> > +static bool
> > +is_kernel_paddr(vm_paddr_t pa)
> > +{
> > +
> > +return (pa >= trunc_2mpage(btext - KERNBASE) &&
> > +   pa < round_page(_end - KERNBASE));
> > +}
> > +
> > +static bool
> > +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
> > +{
> > +
> > +return (start + AP_BOOTPT_SZ <= GiB(4) &&
> > +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
> > +}
> > +
> > /*
> >  * Calculate usable address in base memory for AP trampoline code.
> >  */
> > void
> > mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
> > {
> > +vm_paddr_t start, end;
> >unsigned int i;
> >bool allocated;
> > 
> >alloc_ap_trampoline(physmap, physmap_idx);
> > 
> > +/*
> > + * Find a memory region big enough below the 4GB boundary to
> > + * store the initial page tables.  Region must be mapped by
> > + * the direct map.
> > + *
> > + * Note that it needs to be aligned to a page boundary.
> > + */
> >allocated = false;
> >for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
> >/*
> > - * Find a memory region big enough below the 4GB
> > - * boundary to store the initial page tables.  Region
> > - * must be mapped by the direct map.
> > - *
> > - * Note that it needs to be aligned to a page
> > - * boundary.
> > + * First, try to chomp at the start of the physmap region.
> > + * Kernel binary might claim it already.
> > + */
> > +start = round_page(physmap[i]);
> > +end = trunc_page(physmap[i + 1]);
> > +if (is_mpboot_good(start, end) &&
> > +!is_kernel_paddr(start) && !is_kern

Re: Fatal trap 12 when booting with fuse in /boot/loader.conf

[Michael Gmelin]

> On 23. Aug 2018, at 01:02, Per Gunnarsson  wrote:
> 
> Sorry for possibly mentioning this twice.
> 
> FreeBSD konjak 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 r338177: Wed Aug 22
> 08:46:40 CEST 2018
> root@konjak:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> 
> /usr/src Revision: 338177
> 
> /usr/ports Revision: 43
> 
> When I try to boot with the fuse module in /boot/loader.conf I get
> something like this:
> 
> Fatal trap 12:
> 
> ...
> 
> fault virtual address = 0xcd
> instruction pointer = 0x20:0x80eec062
> stack pointer = 0x20:0x8420e580
> frame pointer = 0x20:0x8420e670
> 
> ...
> 
> Then there is a prompt:
> db>
> 
> or something, but it doesn't respond to keyboard input and I have to reboot.
> 
> Somehow I managed to unload all modules from the boot prompt and reboot.
> After that, I rebooted without the fuse module in /boot/loader.conf and
> things work fine.
> 
> I have tried to boot again with fuse in /boot/loader.conf, and the first
> boot I get to a mountroot
> prompt which I am now reading up on.
> 
> Maybe this is the same as Michael Gmelin is working on.

Most likely that’s a different problem. Did you try to reinstall the fuse 
module from ports (make clean deinstall reinstall)? Can you check /boot for 
additional copies of the fuse module (recursively)? Does kldloading the fuse 
module after boot work?

Best,
Michael


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

Fatal trap 12 when booting with fuse in /boot/loader.conf

[Per Gunnarsson]

Sorry for possibly mentioning this twice.

FreeBSD konjak 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 r338177: Wed Aug 22
08:46:40 CEST 2018
root@konjak:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

/usr/src Revision: 338177

/usr/ports Revision: 43

When I try to boot with the fuse module in /boot/loader.conf I get
something like this:

Fatal trap 12:

...

fault virtual address = 0xcd
instruction pointer = 0x20:0x80eec062
stack pointer = 0x20:0x8420e580
frame pointer = 0x20:0x8420e670

...

Then there is a prompt:
db>

or something, but it doesn't respond to keyboard input and I have to reboot.

Somehow I managed to unload all modules from the boot prompt and reboot.
After that, I rebooted without the fuse module in /boot/loader.conf and
things work fine.

I have tried to boot again with fuse in /boot/loader.conf, and the first
boot I get to a mountroot
prompt which I am now reading up on.

Maybe this is the same as Michael Gmelin is working on.

Regards,

Per Gunnarsson

___
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 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
> 
>> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
>> 
>> 
 On 22. Aug 2018, at 17:46, Konstantin Belousov  wrote:
 
 On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
 
 
>> On 20. Aug 2018, at 17:09, Konstantin Belousov  
>> wrote:
>> 
>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>> 
>> See here for a screenshot (also including the output of "show pte
>> 0xf8000100"):
>> 
>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> It is too early for ddb routines to register.
> Ok can you try the following debugging patch, to verify my guess ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 18777d23f09..cd05fdb763f 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>  pd_p = (pd_entry_t *)DMPDkernphys;
>  for (i = 0; i < (NPDEPG * nkdmpde); i++)
>  pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> -X86_PG_M | X86_PG_A | pg_nx |
> -bootaddr_rwx(i << PDRSHIFT);
> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>  for (i = 0; i < nkdmpde; i++)
>  pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>  X86_PG_V;
 
 With this change it boots okay (mptramp_pagetables is 0x100, as 
 expected).
>>> 
>>> Can you apply the following on top of the previous debugging patch and show
>>> me the line printed ?
>>> 
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 3d70532b7fd..613fa9f2165 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
>>>   pmap->pm_pcids[i].pm_gen = 1;
>>>   }
>>>   pmap_activate_boot(pmap);
>>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
>>> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
>>> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
>>> (uintptr_t)KERNBASE);
>>> }
>>> 
>>> void
>> 
>> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
>> 0x823cf840 brwsection #81a0 etext 0x812041e4 
>> KERNBASE 0x8000
>> 
> 
> Try this, please.  Revert all debugging pmap.c patches that I provided
> before.
> 
> diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> index 4ca2e07e578..2ee8f862854 100644
> --- a/sys/amd64/amd64/mp_machdep.c
> +++ b/sys/amd64/amd64/mp_machdep.c
> @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
> 
> #define GiB(v)(v ## ULL << 30)
> 
> +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
> +
> externstruct pcpu __pcpu[];
> 
> /* Temporary variables for init_secondary()  */
> @@ -101,45 +103,78 @@ char *dbg_stack;
> 
> static intstart_ap(int apic_id);
> 
> +static bool
> +is_kernel_paddr(vm_paddr_t pa)
> +{
> +
> +return (pa >= trunc_2mpage(btext - KERNBASE) &&
> +   pa < round_page(_end - KERNBASE));
> +}
> +
> +static bool
> +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
> +{
> +
> +return (start + AP_BOOTPT_SZ <= GiB(4) &&
> +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
> +}
> +
> /*
>  * Calculate usable address in base memory for AP trampoline code.
>  */
> void
> mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
> {
> +vm_paddr_t start, end;
>unsigned int i;
>bool allocated;
> 
>alloc_ap_trampoline(physmap, physmap_idx);
> 
> +/*
> + * Find a memory region big enough below the 4GB boundary to
> + * store the initial page tables.  Region must be mapped by
> + * the direct map.
> + *
> + * Note that it needs to be aligned to a page boundary.
> + */
>allocated = false;
>for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
>/*
> - * Find a memory region big enough below the 4GB
> - * boundary to store the initial page tables.  Region
> - * must be mapped by the direct map.
> - *
> - * Note that it needs to be aligned to a page
> - * boundary.
> + * First, try to chomp at the start of the physmap region.
> + * Kernel binary might claim it already.
> + */
> +start = round_page(physmap[i]);
> +end = trunc_page(physmap[i + 1]);
> +if (is_mpboot_good(start, end) &&
> +!is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
> +allocated = true;
> +physmap[i] = start + AP_BOOTPT_SZ;
> +break;
> +}
> +
> +/*
> + * Second, try to chomp at the end.  Again, check
> + * against kernel.
> */
> -if (physmap[i] >= GiB(4) || physmap[i + 1] -
> -round_page(physmap[i]

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> 
> 
> > On 22. Aug 2018, at 17:46, Konstantin Belousov  wrote:
> > 
> >> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
> >> 
> >> 
>  On 20. Aug 2018, at 17:09, Konstantin Belousov  
>  wrote:
>  
>  On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>  
>  See here for a screenshot (also including the output of "show pte
>  0xf8000100"):
>  
>  https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> >>> It is too early for ddb routines to register.
> >>> Ok can you try the following debugging patch, to verify my guess ?
> >>> 
> >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>> index 18777d23f09..cd05fdb763f 100644
> >>> --- a/sys/amd64/amd64/pmap.c
> >>> +++ b/sys/amd64/amd64/pmap.c
> >>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >>>   pd_p = (pd_entry_t *)DMPDkernphys;
> >>>   for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >>>   pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> >>> -X86_PG_M | X86_PG_A | pg_nx |
> >>> -bootaddr_rwx(i << PDRSHIFT);
> >>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >>>   for (i = 0; i < nkdmpde; i++)
> >>>   pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >>>   X86_PG_V;
> >> 
> >> With this change it boots okay (mptramp_pagetables is 0x100, as 
> >> expected).
> > 
> > Can you apply the following on top of the previous debugging patch and show
> > me the line printed ?
> > 
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 3d70532b7fd..613fa9f2165 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> >pmap->pm_pcids[i].pm_gen = 1;
> >}
> >pmap_activate_boot(pmap);
> > +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> > etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> > (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
> > (uintptr_t)KERNBASE);
> > }
> > 
> > void
> 
> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
> 0x823cf840 brwsection #81a0 etext 0x812041e4 
> KERNBASE 0x8000
> 

Try this, please.  Revert all debugging pmap.c patches that I provided
before.

diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index 4ca2e07e578..2ee8f862854 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
 
 #define GiB(v) (v ## ULL << 30)
 
+#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
+
 extern struct pcpu __pcpu[];
 
 /* Temporary variables for init_secondary()  */
@@ -101,45 +103,78 @@ char *dbg_stack;
 
 static int start_ap(int apic_id);
 
+static bool
+is_kernel_paddr(vm_paddr_t pa)
+{
+
+   return (pa >= trunc_2mpage(btext - KERNBASE) &&
+  pa < round_page(_end - KERNBASE));
+}
+
+static bool
+is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
+{
+
+   return (start + AP_BOOTPT_SZ <= GiB(4) &&
+   end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
+}
+
 /*
  * Calculate usable address in base memory for AP trampoline code.
  */
 void
 mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
 {
+   vm_paddr_t start, end;
unsigned int i;
bool allocated;
 
alloc_ap_trampoline(physmap, physmap_idx);
 
+   /*
+* Find a memory region big enough below the 4GB boundary to
+* store the initial page tables.  Region must be mapped by
+* the direct map.
+*
+* Note that it needs to be aligned to a page boundary.
+*/
allocated = false;
for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
/*
-* Find a memory region big enough below the 4GB
-* boundary to store the initial page tables.  Region
-* must be mapped by the direct map.
-*
-* Note that it needs to be aligned to a page
-* boundary.
+* First, try to chomp at the start of the physmap region.
+* Kernel binary might claim it already.
+*/
+   start = round_page(physmap[i]);
+   end = trunc_page(physmap[i + 1]);
+   if (is_mpboot_good(start, end) &&
+   !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
+   allocated = true;
+   physmap[i] = start + AP_BOOTPT_SZ;
+   break;
+   }
+
+   /*
+* Second, try to chomp at the end.  Again, check
+* against kernel.
 */
-   if (physmap[i] >= GiB(4) || physmap[i + 1] -

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

> On 22. Aug 2018, at 17:46, Konstantin Belousov  wrote:
> 
>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>> 
>> 
 On 20. Aug 2018, at 17:09, Konstantin Belousov  wrote:
 
 On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
 
 See here for a screenshot (also including the output of "show pte
 0xf8000100"):
 
 https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
>>> It is too early for ddb routines to register.
>>> Ok can you try the following debugging patch, to verify my guess ?
>>> 
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 18777d23f09..cd05fdb763f 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>>>   pd_p = (pd_entry_t *)DMPDkernphys;
>>>   for (i = 0; i < (NPDEPG * nkdmpde); i++)
>>>   pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
>>> -X86_PG_M | X86_PG_A | pg_nx |
>>> -bootaddr_rwx(i << PDRSHIFT);
>>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>>>   for (i = 0; i < nkdmpde; i++)
>>>   pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>>>   X86_PG_V;
>> 
>> With this change it boots okay (mptramp_pagetables is 0x100, as 
>> expected).
> 
> Can you apply the following on top of the previous debugging patch and show
> me the line printed ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 3d70532b7fd..613fa9f2165 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
>pmap->pm_pcids[i].pm_gen = 1;
>}
>pmap_activate_boot(pmap);
> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
> (uintptr_t)KERNBASE);
> }
> 
> void

bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 0x823cf840 
brwsection #81a0 etext 0x812041e4 KERNBASE 
0x8000

Best,
Michael




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

[Konstantin Belousov]

On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
> 
> 
> > On 20. Aug 2018, at 17:09, Konstantin Belousov  wrote:
> > 
> >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >> 
> >> See here for a screenshot (also including the output of "show pte
> >> 0xf8000100"):
> >> 
> >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> > It is too early for ddb routines to register.
> > Ok can you try the following debugging patch, to verify my guess ?
> > 
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 18777d23f09..cd05fdb763f 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >pd_p = (pd_entry_t *)DMPDkernphys;
> >for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> > -X86_PG_M | X86_PG_A | pg_nx |
> > -bootaddr_rwx(i << PDRSHIFT);
> > +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >for (i = 0; i < nkdmpde; i++)
> >pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >X86_PG_V;
> 
> With this change it boots okay (mptramp_pagetables is 0x100, as expected).

Can you apply the following on top of the previous debugging patch and show
me the line printed ?

diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 3d70532b7fd..613fa9f2165 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
pmap->pm_pcids[i].pm_gen = 1;
}
pmap_activate_boot(pmap);
+printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx etext 
%#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
(uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
(uintptr_t)KERNBASE);
 }
 
 void
___
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 20. Aug 2018, at 17:09, Konstantin Belousov  wrote:
> 
>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>> 
>> See here for a screenshot (also including the output of "show pte
>> 0xf8000100"):
>> 
>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> It is too early for ddb routines to register.
> Ok can you try the following debugging patch, to verify my guess ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 18777d23f09..cd05fdb763f 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>pd_p = (pd_entry_t *)DMPDkernphys;
>for (i = 0; i < (NPDEPG * nkdmpde); i++)
>pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> -X86_PG_M | X86_PG_A | pg_nx |
> -bootaddr_rwx(i << PDRSHIFT);
> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>for (i = 0; i < nkdmpde; i++)
>pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>X86_PG_V;

With this change it boots okay (mptramp_pagetables is 0x100, as expected).

Best,
Michael


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

[Konstantin Belousov]

On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> 
> See here for a screenshot (also including the output of "show pte
> 0xf8000100"):
> 
> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
It is too early for ddb routines to register.
Ok can you try the following debugging patch, to verify my guess ?

diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 18777d23f09..cd05fdb763f 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
pd_p = (pd_entry_t *)DMPDkernphys;
for (i = 0; i < (NPDEPG * nkdmpde); i++)
pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
-   X86_PG_M | X86_PG_A | pg_nx |
-   bootaddr_rwx(i << PDRSHIFT);
+   X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
for (i = 0; i < nkdmpde; i++)
pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
X86_PG_V;
___
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, 19 Aug 2018 19:16:42 +0300
Konstantin Belousov  wrote:

> On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Fri, 17 Aug 2018 10:02:08 +0100
> > John Baldwin  wrote:
> >   
> > > On 8/17/18 9:54 AM, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > >> On 17. Aug 2018, at 08:17, John Baldwin 
> > > >> wrote: 
> > > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> > > >>>
> > > >>>
> > >  On 15. Aug 2018, at 15:55, Konstantin Belousov
> > >  mailto:kostik...@gmail.com>> wrote:   
> > > > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin
> > > > wrote:
> > > >
> > > >
> > > >>> On 15. Aug 2018, at 15:04, Konstantin Belousov
> > > >>> mailto:kostik...@gmail.com>> wrote:
> > > >>>
> > > >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin
> > > >>> wrote: Reviving this old thread, since I just updated to
> > > >>> r337818 and a similar problem is happening again. Since
> > > >>> the fix in r334799 (review
> > > >>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have
> > > >>> been touched, so maybe this is related
> > > >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> > > >>>
> > > >>> Please see the screenshot of the panic below:
> > > >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> > > >>>
> > > >>> This is me not digging any deeper, hoping that this is
> > > >>> something obvious. Please let me know if you need more
> > > >>> input.
> > > >>
> > > >> I do not see how recent mp_machdep.c changes could affect
> > > >> this. Can you try newest kernel but old loader ?
> > > >
> > > > I will try (but that will take a while). Oh, also, it still
> > > > boots in save mode/with smp disabled.
> > > 
> > >  Right, this is because the access to that address through
> > >  DMAP is only needed when configuring AP startup resources.
> > > 
> > >  Also, I think it is safe to suggest that the bisect is
> > >  needed.
> > > >>>
> > > >>> Using an older loader didn???t help, but I identified the
> > > >>> problem:
> > > >>>
> > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952
> > > >>>
> > > >>> modified the code you introduced in
> > > >>>
> > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799
> > > >>>
> > > >>> By correcting units to pages it also broke booting the
> > > >>> Chromebook as a side effect - so the previous fix just worked
> > > >>> due to a bug it seems.
> > > >>>
> > > >>> Is there an easy way to output the content of physmap at that
> > > >>> point (debug.late_console=0 doesn???t work) - like an existing
> > > >>> buffer I could use, or would this be more elaborate (I did
> > > >>> something complicated last time but didn???t save it, so any
> > > >>> simple solution would be preferred).
> > > >>
> > > >> How about reverting the commit for now so you get a working
> > > >> console and print out the physmap array values along with
> > > >> Maxmem later in the boot (or just use kgdb to examine them
> > > >> once the system is running)?   
> > > > 
> > > > This is before the system has a working console (part of calling
> > > > getmem...), disabling late console makes it hang, physmap
> > > > changes afterwards, so running kgdb later doesn???t help. Last
> > > > time I kept a copy of physmap and logged it later to know the
> > > > original content. I can do that again, I just thought maybe
> > > > there is a simple mechanism I???m not aware of that would save
> > > > me some time.
> > > 
> > > I thought we only modified phys_avail[], but saving a copy of
> > > physmap[] and dumping it from kgdb is probably the simplest thing
> > > to do.
> > >   
> > 
> > Okay, so I had some time to investigate a bit more:
> > 
> > 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
> > Maxmem: 0x10060 0x100600
> > 
> > Without using atop (the "buggy" version that actually boots without
> > crashing), the loop in mp_bootaddress looks like this:
> > 
> > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
> > 8 0x1 0x10060 0x100600 0x100600 
> > 6 0x100 0x7bf7a000 0x7bf7a 0x100600 
> > 4 0x10 0xf0 0xf00 0x100600 
> > 2 0x4 0x9e400 0x9e 0x100600 
> > 
> > And physmap looks like this afterwards:
> > 
> > physmap_idx: 8
> > i mem atop
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x43000 0x43 <-- here
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf7a000 0x7bf7a
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > mptra

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote:
> 
> 
> On Fri, 17 Aug 2018 10:02:08 +0100
> John Baldwin  wrote:
> 
> > On 8/17/18 9:54 AM, Michael Gmelin wrote:
> > > 
> > >   
> > >> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> > >>  
> > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> > >>>
> > >>>  
> >  On 15. Aug 2018, at 15:55, Konstantin Belousov
> >  mailto:kostik...@gmail.com>> wrote: 
> > > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
> > >
> > >  
> > >>> On 15. Aug 2018, at 15:04, Konstantin Belousov
> > >>> mailto:kostik...@gmail.com>> wrote:
> > >>>
> > >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin
> > >>> wrote: Reviving this old thread, since I just updated to
> > >>> r337818 and a similar problem is happening again. Since the
> > >>> fix in r334799 (review https://reviews.freebsd.org/D15675)
> > >>> (mp_)machdep.c have been touched, so maybe this is related
> > >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> > >>>
> > >>> Please see the screenshot of the panic below:
> > >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> > >>>
> > >>> This is me not digging any deeper, hoping that this is
> > >>> something obvious. Please let me know if you need more
> > >>> input.  
> > >>
> > >> I do not see how recent mp_machdep.c changes could affect this.
> > >> Can you try newest kernel but old loader ?  
> > >
> > > I will try (but that will take a while). Oh, also, it still
> > > boots in save mode/with smp disabled.  
> > 
> >  Right, this is because the access to that address through DMAP
> >  is only needed when configuring AP startup resources.
> > 
> >  Also, I think it is safe to suggest that the bisect is needed.  
> > >>>
> > >>> Using an older loader didn???t help, but I identified the problem:
> > >>>
> > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952
> > >>>
> > >>> modified the code you introduced in
> > >>>
> > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799
> > >>>
> > >>> By correcting units to pages it also broke booting the Chromebook
> > >>> as a side effect - so the previous fix just worked due to a bug
> > >>> it seems.
> > >>>
> > >>> Is there an easy way to output the content of physmap at that
> > >>> point (debug.late_console=0 doesn???t work) - like an existing
> > >>> buffer I could use, or would this be more elaborate (I did
> > >>> something complicated last time but didn???t save it, so any simple
> > >>> solution would be preferred).  
> > >>
> > >> How about reverting the commit for now so you get a working console
> > >> and print out the physmap array values along with Maxmem later in
> > >> the boot (or just use kgdb to examine them once the system is
> > >> running)? 
> > > 
> > > This is before the system has a working console (part of calling
> > > getmem...), disabling late console makes it hang, physmap changes
> > > afterwards, so running kgdb later doesn???t help. Last time I kept a
> > > copy of physmap and logged it later to know the original content. I
> > > can do that again, I just thought maybe there is a simple mechanism
> > > I???m not aware of that would save me some time.  
> > 
> > I thought we only modified phys_avail[], but saving a copy of
> > physmap[] and dumping it from kgdb is probably the simplest thing to
> > do.
> > 
> 
> Okay, so I had some time to investigate a bit more:
> 
> 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
> Maxmem: 0x10060 0x100600
> 
> Without using atop (the "buggy" version that actually boots without
> crashing), the loop in mp_bootaddress looks like this:
> 
> i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
> 8 0x1 0x10060 0x100600 0x100600 
> 6 0x100 0x7bf7a000 0x7bf7a 0x100600 
> 4 0x10 0xf0 0xf00 0x100600 
> 2 0x4 0x9e400 0x9e 0x100600 
> 
> And physmap looks like this afterwards:
> 
> physmap_idx: 8
> i mem atop
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x43000 0x43 <-- here
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf7a000 0x7bf7a
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> mptramp_pagetables is 0x4
> 
> So a three page gap was made at 0x4 (atop(idx 2) is now 0x43
> instead of 0x40)
> 
> In the current version (using atop), the loop in mp_bootaddress
> looks like this:
> 
> i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
> 8 0x1 0x10060 0x100600 0x100600 
> 6 0x100 0x7bf7a000 0x7bf7a 0x100600 
> 
> And physmap looks like this afterwards:
>

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Fri, 17 Aug 2018 10:02:08 +0100
John Baldwin  wrote:

> On 8/17/18 9:54 AM, Michael Gmelin wrote:
> > 
> >   
> >> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> >>  
> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> >>>
> >>>  
>  On 15. Aug 2018, at 15:55, Konstantin Belousov
>  mailto:kostik...@gmail.com>> wrote: 
> > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
> >
> >  
> >>> On 15. Aug 2018, at 15:04, Konstantin Belousov
> >>> mailto:kostik...@gmail.com>> wrote:
> >>>
> >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin
> >>> wrote: Reviving this old thread, since I just updated to
> >>> r337818 and a similar problem is happening again. Since the
> >>> fix in r334799 (review https://reviews.freebsd.org/D15675)
> >>> (mp_)machdep.c have been touched, so maybe this is related
> >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> >>>
> >>> Please see the screenshot of the panic below:
> >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> >>>
> >>> This is me not digging any deeper, hoping that this is
> >>> something obvious. Please let me know if you need more
> >>> input.  
> >>
> >> I do not see how recent mp_machdep.c changes could affect this.
> >> Can you try newest kernel but old loader ?  
> >
> > I will try (but that will take a while). Oh, also, it still
> > boots in save mode/with smp disabled.  
> 
>  Right, this is because the access to that address through DMAP
>  is only needed when configuring AP startup resources.
> 
>  Also, I think it is safe to suggest that the bisect is needed.  
> >>>
> >>> Using an older loader didn’t help, but I identified the problem:
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision&revision=334952
> >>>
> >>> modified the code you introduced in
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision&revision=334799
> >>>
> >>> By correcting units to pages it also broke booting the Chromebook
> >>> as a side effect - so the previous fix just worked due to a bug
> >>> it seems.
> >>>
> >>> Is there an easy way to output the content of physmap at that
> >>> point (debug.late_console=0 doesn’t work) - like an existing
> >>> buffer I could use, or would this be more elaborate (I did
> >>> something complicated last time but didn’t save it, so any simple
> >>> solution would be preferred).  
> >>
> >> How about reverting the commit for now so you get a working console
> >> and print out the physmap array values along with Maxmem later in
> >> the boot (or just use kgdb to examine them once the system is
> >> running)? 
> > 
> > This is before the system has a working console (part of calling
> > getmem...), disabling late console makes it hang, physmap changes
> > afterwards, so running kgdb later doesn’t help. Last time I kept a
> > copy of physmap and logged it later to know the original content. I
> > can do that again, I just thought maybe there is a simple mechanism
> > I’m not aware of that would save me some time.  
> 
> I thought we only modified phys_avail[], but saving a copy of
> physmap[] and dumping it from kgdb is probably the simplest thing to
> do.
> 

Okay, so I had some time to investigate a bit more:

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
Maxmem: 0x10060 0x100600

Without using atop (the "buggy" version that actually boots without
crashing), the loop in mp_bootaddress looks like this:

i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
8 0x1 0x10060 0x100600 0x100600 
6 0x100 0x7bf7a000 0x7bf7a 0x100600 
4 0x10 0xf0 0xf00 0x100600 
2 0x4 0x9e400 0x9e 0x100600 

And physmap looks like this afterwards:

physmap_idx: 8
i mem atop
0 0x0 0x0
1 0x3 0x30
2 0x43000 0x43 <-- here
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
mptramp_pagetables is 0x4

So a three page gap was made at 0x4 (atop(idx 2) is now 0x43
instead of 0x40)

In the current version (using atop), the loop in mp_bootaddress
looks like this:

i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
8 0x1 0x10060 0x100600 0x100600 
6 0x100 0x7bf7a000 0x7bf7a 0x100600 

And physmap looks like this afterwards:

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 0x1003000 0x1003 <-- here
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
mptramp_pagetables: 0x100

So a three page gap was made at 0x100 (atop(idx 6) is now
0x1003 instead of 0x1000)

When chan

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

> On 17. Aug 2018, at 12:13, Konstantin Belousov  wrote:
> 
>> On Fri, Aug 17, 2018 at 10:02:08AM +0100, John Baldwin wrote:
>>> On 8/17/18 9:54 AM, Michael Gmelin wrote:
>>> 
>>> 
> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> 
> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> 
> 
>>> On 15. Aug 2018, at 15:55, Konstantin Belousov >> > wrote:
>>> 
>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>>> 
>>> 
> On 15. Aug 2018, at 15:04, Konstantin Belousov  > wrote:
> 
> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> Reviving this old thread, since I just updated to r337818 and a 
> similar
> problem is happening again. Since the fix in r334799 (review
> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
> so maybe this is related
> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> 
> Please see the screenshot of the panic below:
> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> 
> This is me not digging any deeper, hoping that this is something
> obvious. Please let me know if you need more input.
 
 I do not see how recent mp_machdep.c changes could affect this.
 Can you try newest kernel but old loader ?
>>> 
>>> I will try (but that will take a while). Oh, also, it still boots in 
>>> save mode/with smp disabled.
>> 
>> Right, this is because the access to that address through DMAP is only
>> needed when configuring AP startup resources.
>> 
>> Also, I think it is safe to suggest that the bisect is needed.
> 
> Using an older loader didn???t help, but I identified the problem:
> 
> https://svnweb.freebsd.org/base?view=revision&revision=334952
> 
> modified the code you introduced in
> 
> https://svnweb.freebsd.org/base?view=revision&revision=334799
> 
> By correcting units to pages it also broke booting the Chromebook as a 
> side effect - so the previous fix just worked due to a bug it seems.
> 
> Is there an easy way to output the content of physmap at that point 
> (debug.late_console=0 doesn???t work) - like an existing buffer I could 
> use, or would this be more elaborate (I did something complicated last 
> time but didn???t save it, so any simple solution would be preferred).
 
 How about reverting the commit for now so you get a working console
 and print out the physmap array values along with Maxmem later in
 the boot (or just use kgdb to examine them once the system is running)?
 
>>> 
>>> This is before the system has a working console (part of calling 
>>> getmem...), disabling late console makes it hang, physmap changes 
>>> afterwards, so running kgdb later doesn???t help. Last time I kept a copy 
>>> of physmap and logged it later to know the original content. I can do that 
>>> again, I just thought maybe there is a simple mechanism I???m not aware of 
>>> that would save me some time.
>> 
>> I thought we only modified phys_avail[], but saving a copy of physmap[] and
>> dumping it from kgdb is probably the simplest thing to do.
> UP boot works ?
> 

Well, I can boot if I remove atop(...) (reverting the patch). If this is what 
you mean.


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

[Konstantin Belousov]

On Fri, Aug 17, 2018 at 10:02:08AM +0100, John Baldwin wrote:
> On 8/17/18 9:54 AM, Michael Gmelin wrote:
> > 
> > 
> >> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> >>
> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> >>>
> >>>
>  On 15. Aug 2018, at 15:55, Konstantin Belousov   > wrote:
> 
> > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
> >
> >
> >>> On 15. Aug 2018, at 15:04, Konstantin Belousov  >>> > wrote:
> >>>
> >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> >>> Reviving this old thread, since I just updated to r337818 and a 
> >>> similar
> >>> problem is happening again. Since the fix in r334799 (review
> >>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
> >>> so maybe this is related
> >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> >>>
> >>> Please see the screenshot of the panic below:
> >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> >>>
> >>> This is me not digging any deeper, hoping that this is something
> >>> obvious. Please let me know if you need more input.
> >>
> >> I do not see how recent mp_machdep.c changes could affect this.
> >> Can you try newest kernel but old loader ?
> >
> > I will try (but that will take a while). Oh, also, it still boots in 
> > save mode/with smp disabled.
> 
>  Right, this is because the access to that address through DMAP is only
>  needed when configuring AP startup resources.
> 
>  Also, I think it is safe to suggest that the bisect is needed.
> >>>
> >>> Using an older loader didn???t help, but I identified the problem:
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision&revision=334952
> >>>
> >>> modified the code you introduced in
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision&revision=334799
> >>>
> >>> By correcting units to pages it also broke booting the Chromebook as a 
> >>> side effect - so the previous fix just worked due to a bug it seems.
> >>>
> >>> Is there an easy way to output the content of physmap at that point 
> >>> (debug.late_console=0 doesn???t work) - like an existing buffer I could 
> >>> use, or would this be more elaborate (I did something complicated last 
> >>> time but didn???t save it, so any simple solution would be preferred).
> >>
> >> How about reverting the commit for now so you get a working console
> >> and print out the physmap array values along with Maxmem later in
> >> the boot (or just use kgdb to examine them once the system is running)?
> >>
> > 
> > This is before the system has a working console (part of calling 
> > getmem...), disabling late console makes it hang, physmap changes 
> > afterwards, so running kgdb later doesn???t help. Last time I kept a copy 
> > of physmap and logged it later to know the original content. I can do that 
> > again, I just thought maybe there is a simple mechanism I???m not aware of 
> > that would save me some time.
> 
> I thought we only modified phys_avail[], but saving a copy of physmap[] and
> dumping it from kgdb is probably the simplest thing to do.
UP boot works ?

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

[John Baldwin]

On 8/17/18 9:54 AM, Michael Gmelin wrote:
> 
> 
>> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
>>
>>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
>>>
>>>
 On 15. Aug 2018, at 15:55, Konstantin Belousov >>> > wrote:

> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>
>
>>> On 15. Aug 2018, at 15:04, Konstantin Belousov >> > wrote:
>>>
>>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
>>> Reviving this old thread, since I just updated to r337818 and a similar
>>> problem is happening again. Since the fix in r334799 (review
>>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
>>> so maybe this is related
>>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
>>>
>>> Please see the screenshot of the panic below:
>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
>>>
>>> This is me not digging any deeper, hoping that this is something
>>> obvious. Please let me know if you need more input.
>>
>> I do not see how recent mp_machdep.c changes could affect this.
>> Can you try newest kernel but old loader ?
>
> I will try (but that will take a while). Oh, also, it still boots in save 
> mode/with smp disabled.

 Right, this is because the access to that address through DMAP is only
 needed when configuring AP startup resources.

 Also, I think it is safe to suggest that the bisect is needed.
>>>
>>> Using an older loader didn’t help, but I identified the problem:
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=334952
>>>
>>> modified the code you introduced in
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=334799
>>>
>>> By correcting units to pages it also broke booting the Chromebook as a side 
>>> effect - so the previous fix just worked due to a bug it seems.
>>>
>>> Is there an easy way to output the content of physmap at that point 
>>> (debug.late_console=0 doesn’t work) - like an existing buffer I could use, 
>>> or would this be more elaborate (I did something complicated last time but 
>>> didn’t save it, so any simple solution would be preferred).
>>
>> How about reverting the commit for now so you get a working console
>> and print out the physmap array values along with Maxmem later in
>> the boot (or just use kgdb to examine them once the system is running)?
>>
> 
> This is before the system has a working console (part of calling getmem...), 
> disabling late console makes it hang, physmap changes afterwards, so running 
> kgdb later doesn’t help. Last time I kept a copy of physmap and logged it 
> later to know the original content. I can do that again, I just thought maybe 
> there is a simple mechanism I’m not aware of that would save me some time.

I thought we only modified phys_avail[], but saving a copy of physmap[] and
dumping it from kgdb is probably the simplest thing to do.

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

[Michael Gmelin]

> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> 
>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
>> 
>> 
>>> On 15. Aug 2018, at 15:55, Konstantin Belousov >> > wrote:
>>> 
 On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
 
 
>> On 15. Aug 2018, at 15:04, Konstantin Belousov > > wrote:
>> 
>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
>> Reviving this old thread, since I just updated to r337818 and a similar
>> problem is happening again. Since the fix in r334799 (review
>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
>> so maybe this is related
>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
>> 
>> Please see the screenshot of the panic below:
>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
>> 
>> This is me not digging any deeper, hoping that this is something
>> obvious. Please let me know if you need more input.
> 
> I do not see how recent mp_machdep.c changes could affect this.
> Can you try newest kernel but old loader ?
 
 I will try (but that will take a while). Oh, also, it still boots in save 
 mode/with smp disabled.
>>> 
>>> Right, this is because the access to that address through DMAP is only
>>> needed when configuring AP startup resources.
>>> 
>>> Also, I think it is safe to suggest that the bisect is needed.
>> 
>> Using an older loader didn’t help, but I identified the problem:
>> 
>> https://svnweb.freebsd.org/base?view=revision&revision=334952
>> 
>> modified the code you introduced in
>> 
>> https://svnweb.freebsd.org/base?view=revision&revision=334799
>> 
>> By correcting units to pages it also broke booting the Chromebook as a side 
>> effect - so the previous fix just worked due to a bug it seems.
>> 
>> Is there an easy way to output the content of physmap at that point 
>> (debug.late_console=0 doesn’t work) - like an existing buffer I could use, 
>> or would this be more elaborate (I did something complicated last time but 
>> didn’t save it, so any simple solution would be preferred).
> 
> How about reverting the commit for now so you get a working console
> and print out the physmap array values along with Maxmem later in
> the boot (or just use kgdb to examine them once the system is running)?
> 

This is before the system has a working console (part of calling getmem...), 
disabling late console makes it hang, physmap changes afterwards, so running 
kgdb later doesn’t help. Last time I kept a copy of physmap and logged it later 
to know the original content. I can do that again, I just thought maybe there 
is a simple mechanism I’m not aware of that would save me some time.

Thanks,
Michael


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

[John Baldwin]

On 8/16/18 1:58 PM, Michael Gmelin wrote:
> 
> 
> On 15. Aug 2018, at 15:55, Konstantin Belousov  > wrote:
> 
>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>>>
>>>
 On 15. Aug 2018, at 15:04, Konstantin Belousov >>> > wrote:

> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> Reviving this old thread, since I just updated to r337818 and a similar
> problem is happening again. Since the fix in r334799 (review
> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
> so maybe this is related
> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
>
> Please see the screenshot of the panic below:
> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
>
> This is me not digging any deeper, hoping that this is something
> obvious. Please let me know if you need more input.

 I do not see how recent mp_machdep.c changes could affect this.
 Can you try newest kernel but old loader ?
>>>
>>> I will try (but that will take a while). Oh, also, it still boots in save 
>>> mode/with smp disabled.
>>
>> Right, this is because the access to that address through DMAP is only
>> needed when configuring AP startup resources.
>>
>> Also, I think it is safe to suggest that the bisect is needed.
> 
> Using an older loader didn’t help, but I identified the problem:
> 
> https://svnweb.freebsd.org/base?view=revision&revision=334952
> 
> modified the code you introduced in
> 
> https://svnweb.freebsd.org/base?view=revision&revision=334799
> 
> By correcting units to pages it also broke booting the Chromebook as a side 
> effect - so the previous fix just worked due to a bug it seems.
> 
> Is there an easy way to output the content of physmap at that point 
> (debug.late_console=0 doesn’t work) - like an existing buffer I could use, or 
> would this be more elaborate (I did something complicated last time but 
> didn’t save it, so any simple solution would be preferred).

How about reverting the commit for now so you get a working console
and print out the physmap array values along with Maxmem later in
the boot (or just use kgdb to examine them once the system is running)?

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

[Michael Gmelin]

> On 15. Aug 2018, at 15:55, Konstantin Belousov  wrote:
> 
>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>> 
>> 
 On 15. Aug 2018, at 15:04, Konstantin Belousov  wrote:
 
 On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
 Reviving this old thread, since I just updated to r337818 and a similar
 problem is happening again. Since the fix in r334799 (review
 https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
 so maybe this is related
 (https://svnweb.freebsd.org/base?view=revision&revision=334799).
 
 Please see the screenshot of the panic below:
 https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
 
 This is me not digging any deeper, hoping that this is something
 obvious. Please let me know if you need more input.
>>> 
>>> I do not see how recent mp_machdep.c changes could affect this.
>>> Can you try newest kernel but old loader ?
>> 
>> I will try (but that will take a while). Oh, also, it still boots in save 
>> mode/with smp disabled.
> 
> Right, this is because the access to that address through DMAP is only 
> needed when configuring AP startup resources.
> 
> Also, I think it is safe to suggest that the bisect is needed.

Using an older loader didn’t help, but I identified the problem:

https://svnweb.freebsd.org/base?view=revision&revision=334952

modified the code you introduced in

https://svnweb.freebsd.org/base?view=revision&revision=334799

By correcting units to pages it also broke booting the Chromebook as a side 
effect - so the previous fix just worked due to a bug it seems.

Is there an easy way to output the content of physmap at that point 
(debug.late_console=0 doesn’t work) - like an existing buffer I could use, or 
would this be more elaborate (I did something complicated last time but didn’t 
save it, so any simple solution would be preferred).

Thanks,
Michael 

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

[Konstantin Belousov]

On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
> 
> 
> > On 15. Aug 2018, at 15:04, Konstantin Belousov  wrote:
> > 
> >> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> >> Reviving this old thread, since I just updated to r337818 and a similar
> >> problem is happening again. Since the fix in r334799 (review
> >> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
> >> so maybe this is related
> >> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> >> 
> >> Please see the screenshot of the panic below:
> >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> >> 
> >> This is me not digging any deeper, hoping that this is something
> >> obvious. Please let me know if you need more input.
> > 
> > I do not see how recent mp_machdep.c changes could affect this.
> > Can you try newest kernel but old loader ?
> 
> I will try (but that will take a while). Oh, also, it still boots in save 
> mode/with smp disabled.

Right, this is because the access to that address through DMAP is only 
needed when configuring AP startup resources.

Also, I think it is safe to suggest that the bisect is needed.
___
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 15. Aug 2018, at 15:04, Konstantin Belousov  wrote:
> 
>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
>> Reviving this old thread, since I just updated to r337818 and a similar
>> problem is happening again. Since the fix in r334799 (review
>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
>> so maybe this is related
>> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
>> 
>> Please see the screenshot of the panic below:
>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
>> 
>> This is me not digging any deeper, hoping that this is something
>> obvious. Please let me know if you need more input.
> 
> I do not see how recent mp_machdep.c changes could affect this.
> Can you try newest kernel but old loader ?

I will try (but that will take a while). Oh, also, it still boots in save 
mode/with smp disabled.

-m
___
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)

[Konstantin Belousov]

On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
> Reviving this old thread, since I just updated to r337818 and a similar
> problem is happening again. Since the fix in r334799 (review
> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
> so maybe this is related
> (https://svnweb.freebsd.org/base?view=revision&revision=334799).
> 
> Please see the screenshot of the panic below:
> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
> 
> This is me not digging any deeper, hoping that this is something
> obvious. Please let me know if you need more input.

I do not see how recent mp_machdep.c changes could affect this.
Can you try newest kernel but old loader ?
___
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, 6 Jun 2018 01:06:25 +0200
Michael Gmelin  wrote:

> On Tue, 5 Jun 2018 16:11:35 +0300
> Konstantin Belousov  wrote:
> 
> > On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:  
> > > 
> > > 
> > > On Mon, 4 Jun 2018 14:06:55 +0300
> > > Konstantin Belousov  wrote:
> > > 
> > > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin
> > > > wrote:
> > > > > 
> [...]
> > > > > > > > > This machine comes with it by default (my model was
> > > > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2).
> > > > > > > > > So I didn't flash anything (didn't feel like bricking
> > > > > > > > > it). 
> > > > > > > > > >   
> > > > > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > > > > 
> > > > > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > > > > fault code   = supervisor write data,
> > > > > > > > > > > protection violation instruction pointer  =
> > > > > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > > > > 0x28:0x82a79c10 code segment =
> > > > > > > > > > > base Ox0, limit Oxf, type Ox1b = DPL 0, pres
> > > > > > > > > > > 1, long 1, def32 0, gran 1 processor
> > > > > > > > > > > eflags = resume, IOPL = 0 current
> > > > > > > > > > > process  = 0 () [ thread pid 0 tid 0 ]
> > > > > > > > > > > Stopped at  native_start_all_aps+0x08f:
> > > > > > > > > > > movq %rax,(%rsi)
> > > > > > > > > > Look up the source line number for this address.
> > > > > > > > > >   
> > > > > > > > > 
> > > > > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in
> > > > > > > > > rdmsr), called by native_start_all_aps. Any additional
> > > > > > > > > hints how I can track it down?  
> > > > > > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > > > > > native_start_all_aps() does not call rdmsr, second the
> > > > > > > > ddb report clearly indicates that the fault occured
> > > > > > > > acessing DMAP in native_start_all_aps().
> > > > > > > > 
> > > > > > > > Just look up the source line by the address
> > > > > > > > native_start_all_aps+0x08f.
> > > > > > > 
> > > > > > > Okay, according to kgbd this should be here:
> > > > > > > 
> > > > > > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > > > > > > 
> > > > > > > 364
> > > > > > > 365/* Create the initial 1GB replicated page tables */
> > > > > > > 366for (i = 0; i < 512; i++) {
> > > > > > > 367/* Each slot of the level 4 pages points to
> > > > > > > the same level 3 page */ 368pt4[i] =
> > > > > > > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE);
> > > > > > > 369 pt4[i] |= PG_V | PG_RW | PG_U; 370
> > > > > > > 371/* Each slot of the level 3 pages points to
> > > > > > > the same level 2 page */ 372pt3[i] =
> > > > > > > (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 *
> > > > > > > PAGE_SIZE)); 373pt3[i] |= PG_V | PG_RW | PG_U;
> > > > > > > 374 375/* The level 2 page slots are mapped
> > > > > > > with 2MB pages for 1GB. */ 376pt2[i] = i * (2
> > > > > > > * 1024 * 1024); 37

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Tue, 5 Jun 2018 16:11:35 +0300
Konstantin Belousov  wrote:

> On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Mon, 4 Jun 2018 14:06:55 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 23:53:40 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > > > Konstantin Belousov  wrote:
> > > > > >   
> > > > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > > > wrote:  
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > > > Konstantin Belousov  wrote:
> > > > > > > > 
> > > > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael
> > > > > > > > > Gmelin wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > After upgrading CURRENT to r333992 (from something
> > > > > > > > > > at least a year old, quite some changes in
> > > > > > > > > > mp_machdep.c since), this machine crashes on boot:
> > > > > > > > > > 
> > > > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
> > > > > > > > > > 1991, 1992, 1993, 1994 The Regents of the
> > > > > > > > > > University of California. All rights reserved.
> > > > > > > > > > FreeBSD is a registered trademark of The FreeBSD
> > > > > > > > > > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue
> > > > > > > > > > May 22 00:31:04 CEST 2018
> > > > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM
> > > > > > > > > > 6.0.0) WARNING: WITNESS option enabled, expect
> > > > > > > > > > reduced performance. VT(vga): resolution 640x480
> > > > > > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz
> > > > > > > > > > (1396.80-MHz K8-class CPU) Origin="GenuineIntel"
> > > > > > > > > > Id=0x40651 Family=0x6 Model=0x45 Stepping=1
> > > > > > > > > > Features=0xbfebfbff > > > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > > > Features2=0x4ddaebbf > > > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > > > AMD
> > > > > > > > > > Features=0x2c100800
> > > > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > > > Features=0x2603
> > > > > > > > > > XSAVE Features=0x1 VT-x: (disabled in
> > > > > > > > > > BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state
> > > > > > > > > > invariant, performance statistics real memory  =
> > > > > > > > > > 4301258752 (4102 MB) avail memory = 1907572736
> > > > > > > > > > (1819 MB) Event timer "LAPIC" quality 600 ACPI APIC
> > > > > > > > > > Table:  > > > > > > > > > COREBOOT>  
> > > > > > > > > What does this mean ?  Did you flashed
> > > > > > > > > coreboot ?
> > > > > > > > 
> > > > > > > > This machine comes with it by default (my model was
> > > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So
> > > > > > > > I didn&

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:
> 
> 
> On Mon, 4 Jun 2018 14:06:55 +0300
> Konstantin Belousov  wrote:
> 
> > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 23:53:40 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:  
> > > > > 
> > > > > 
> > > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > > Konstantin Belousov  wrote:
> > > > > 
> > > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > > Konstantin Belousov  wrote:
> > > > > > >   
> > > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > > > wrote:  
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > After upgrading CURRENT to r333992 (from something at
> > > > > > > > > least a year old, quite some changes in mp_machdep.c
> > > > > > > > > since), this machine crashes on boot:
> > > > > > > > > 
> > > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > > > trademark of The FreeBSD Foundation. FreeBSD
> > > > > > > > > 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
> > > > > > > > > WARNING: WITNESS option enabled, expect reduced
> > > > > > > > > performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > > > > > Origin="GenuineIntel"  Id=0x40651 Family=0x6
> > > > > > > > > Model=0x45 Stepping=1
> > > > > > > > > Features=0xbfebfbff > > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > > Features2=0x4ddaebbf > > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > > AMD Features=0x2c100800
> > > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > > Features=0x2603
> > > > > > > > > XSAVE Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > > > performance statistics real memory  = 4301258752 (4102
> > > > > > > > > MB) avail memory = 1907572736 (1819 MB) Event timer
> > > > > > > > > "LAPIC" quality 600 ACPI APIC Table:  > > > > > > > > COREBOOT>
> > > > > > > > What does this mean ?  Did you flashed coreboot ?  
> > > > > > > 
> > > > > > > This machine comes with it by default (my model was
> > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So I
> > > > > > > didn't flash anything (didn't feel like bricking it).
> > > > > > >   
> > > > > > > >   
> > > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > > 
> > > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > > fault code   = supervisor write data,

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Mon, 4 Jun 2018 14:06:55 +0300
Konstantin Belousov  wrote:

> On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 23:53:40 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > Konstantin Belousov  wrote:
> > > > > >   
> > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > > wrote:  
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > After upgrading CURRENT to r333992 (from something at
> > > > > > > > least a year old, quite some changes in mp_machdep.c
> > > > > > > > since), this machine crashes on boot:
> > > > > > > > 
> > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > > trademark of The FreeBSD Foundation. FreeBSD
> > > > > > > > 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
> > > > > > > > WARNING: WITNESS option enabled, expect reduced
> > > > > > > > performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > > > > Origin="GenuineIntel"  Id=0x40651 Family=0x6
> > > > > > > > Model=0x45 Stepping=1
> > > > > > > > Features=0xbfebfbff > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > Features2=0x4ddaebbf > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > AMD Features=0x2c100800
> > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > Features=0x2603
> > > > > > > > XSAVE Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > > performance statistics real memory  = 4301258752 (4102
> > > > > > > > MB) avail memory = 1907572736 (1819 MB) Event timer
> > > > > > > > "LAPIC" quality 600 ACPI APIC Table:  > > > > > > > COREBOOT>
> > > > > > > What does this mean ?  Did you flashed coreboot ?  
> > > > > > 
> > > > > > This machine comes with it by default (my model was
> > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So I
> > > > > > didn't flash anything (didn't feel like bricking it).
> > > > > >   
> > > > > > >   
> > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > 
> > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > fault code   = supervisor write data,
> > > > > > > > protection violation instruction pointer  =
> > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > 0x28:0x82a79c10 code segment = base
> > > > > > > > Ox0, limit Oxf

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 23:53:40 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:  
> > > > > 
> > > > > 
> > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > Konstantin Belousov  wrote:
> > > > > 
> > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > After upgrading CURRENT to r333992 (from something at least
> > > > > > > a year old, quite some changes in mp_machdep.c since), this
> > > > > > > machine crashes on boot:
> > > > > > > 
> > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT
> > > > > > > #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled,
> > > > > > > expect reduced performance. VT(vga): resolution 640x480
> > > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz
> > > > > > > K8-class CPU) Origin="GenuineIntel"  Id=0x40651
> > > > > > > Family=0x6  Model=0x45 Stepping=1
> > > > > > > Features=0xbfebfbff > > > > > >   
> > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>  
> > > > > > > Features2=0x4ddaebbf > > > > > >   
> > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > >   
> > > > > > > AMD Features=0x2c100800 AMD
> > > > > > > Features2=0x21 Structured Extended
> > > > > > > Features=0x2603 XSAVE
> > > > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC"
> > > > > > > quality 600 ACPI APIC Table:   
> > > > > > What does this mean ?  Did you flashed coreboot ?
> > > > > 
> > > > > This machine comes with it by default (my model was delivered
> > > > > with SeaBIOS 20131018_145217-build121-m2). So I didn't flash
> > > > > anything (didn't feel like bricking it).
> > > > > 
> > > > > > 
> > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > 
> > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > cpuid = 0; apic id = 00
> > > > > > > fault virtual address= 0xf8000100
> > > > > > > fault code   = supervisor write data, protection
> > > > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > > > stack pointer= 0x28:0x82a79be0
> > > > > > > frame pointer= 0x28:0x82a79c10
> > > > > > > code segment = base Ox0, limit Oxf, type
> > > > > > > Ox1b = DPL 0, pres 1, long 1, def32 0, gran
> > > > > > > 1 processor eflags = resume, IOPL = 0
> > > > > > > current process  = 0 ()
> > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > > %rax,(%rsi)  
> > > > > > L

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 3 Jun 2018 23:53:40 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 18:04:23 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > After upgrading CURRENT to r333992 (from something at least
> > > > > > a year old, quite some changes in mp_machdep.c since), this
> > > > > > machine crashes on boot:
> > > > > > 
> > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT
> > > > > > #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled,
> > > > > > expect reduced performance. VT(vga): resolution 640x480
> > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz
> > > > > > K8-class CPU) Origin="GenuineIntel"  Id=0x40651
> > > > > > Family=0x6  Model=0x45 Stepping=1
> > > > > > Features=0xbfebfbff > > > > >   
> > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>  
> > > > > > Features2=0x4ddaebbf > > > > >   
> > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > >   
> > > > > > AMD Features=0x2c100800 AMD
> > > > > > Features2=0x21 Structured Extended
> > > > > > Features=0x2603 XSAVE
> > > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC"
> > > > > > quality 600 ACPI APIC Table:   
> > > > > What does this mean ?  Did you flashed coreboot ?
> > > > 
> > > > This machine comes with it by default (my model was delivered
> > > > with SeaBIOS 20131018_145217-build121-m2). So I didn't flash
> > > > anything (didn't feel like bricking it).
> > > > 
> > > > > 
> > > > > > kernel trap 12 with interrupts disabled
> > > > > > 
> > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > cpuid = 0; apic id = 00
> > > > > > fault virtual address= 0xf8000100
> > > > > > fault code   = supervisor write data, protection
> > > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > > stack pointer= 0x28:0x82a79be0
> > > > > > frame pointer= 0x28:0x82a79c10
> > > > > > code segment = base Ox0, limit Oxf, type
> > > > > > Ox1b = DPL 0, pres 1, long 1, def32 0, gran
> > > > > > 1 processor eflags = resume, IOPL = 0
> > > > > > current process  = 0 ()
> > > > > > [ thread pid 0 tid 0 ]
> > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > %rax,(%rsi)  
> > > > > Look up the source line number for this address.
> > > > > 
> > > > 
> > > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > > called by native_start_all_aps. Any additional hints how I can
> > > > track it down?
> > > Why did you decided that this is rdmsr_safe() ? First,
> > > native_start_all_aps() does not call rdmsr, second t

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 18:04:23 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:  
> > > > > Hi,
> > > > > 
> > > > > After upgrading CURRENT to r333992 (from something at least a
> > > > > year old, quite some changes in mp_machdep.c since), this
> > > > > machine crashes on boot:
> > > > > 
> > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > > > 1993, 1994 The Regents of the University of California. All
> > > > > rights reserved. FreeBSD is a registered trademark of The
> > > > > FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22
> > > > > 00:31:04 CEST 2018
> > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect
> > > > > reduced performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > > > Stepping=1
> > > > > Features=0xbfebfbff > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > Features2=0x4ddaebbf > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > AMD Features=0x2c100800 AMD
> > > > > Features2=0x21 Structured Extended
> > > > > Features=0x2603 XSAVE
> > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC" quality
> > > > > 600 ACPI APIC Table: 
> > > > What does this mean ?  Did you flashed coreboot ?  
> > > 
> > > This machine comes with it by default (my model was delivered with 
> > > SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> > > (didn't feel like bricking it).
> > >   
> > > >   
> > > > > kernel trap 12 with interrupts disabled
> > > > > 
> > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > cpuid = 0; apic id = 00
> > > > > fault virtual address= 0xf8000100
> > > > > fault code   = supervisor write data, protection
> > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > stack pointer= 0x28:0x82a79be0
> > > > > frame pointer= 0x28:0x82a79c10
> > > > > code segment = base Ox0, limit Oxf, type Ox1b
> > > > >  = DPL 0, pres 1, long 1, def32 0, gran
> > > > > 1 processor eflags = resume, IOPL = 0
> > > > > current process  = 0 ()
> > > > > [ thread pid 0 tid 0 ]
> > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > %rax,(%rsi)
> > > > Look up the source line number for this address.
> > > >   
> > > 
> > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > called by native_start_all_aps. Any additional hints how I can
> > > track it down?  
> > Why did you decided that this is rdmsr_safe() ? First,
> > native_start_all_aps() does not call rdmsr, second the ddb
> > report clearly indicates that the fault occured acessing DMAP in
> > native_start_all_aps().
> > 
> > Just look up the source line by the address
> > native_start_all_aps+0x08f.
> 
> Okay, according to kgbd this should be here:
> 
> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> 
> 364
> 365/* Create the initial 1GB replicated page tables */
> 366for (i = 0; i < 512; i++) {
> 367/* Each slot of the level 4 page

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 3 Jun 2018 18:04:23 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 16:21:10 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:  
> > > > Hi,
> > > > 
> > > > After upgrading CURRENT to r333992 (from something at least a
> > > > year old, quite some changes in mp_machdep.c since), this
> > > > machine crashes on boot:
> > > > 
> > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > > 1993, 1994 The Regents of the University of California. All
> > > > rights reserved. FreeBSD is a registered trademark of The
> > > > FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22
> > > > 00:31:04 CEST 2018
> > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect
> > > > reduced performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > > Stepping=1
> > > > Features=0xbfebfbff > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > Features2=0x4ddaebbf > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > AMD Features=0x2c100800 AMD
> > > > Features2=0x21 Structured Extended
> > > > Features=0x2603 XSAVE
> > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC" quality
> > > > 600 ACPI APIC Table: 
> > > What does this mean ?  Did you flashed coreboot ?  
> > 
> > This machine comes with it by default (my model was delivered with 
> > SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> > (didn't feel like bricking it).
> >   
> > >   
> > > > kernel trap 12 with interrupts disabled
> > > > 
> > > > Fatal trap 12: page fault while in kernel mode 
> > > > cpuid = 0; apic id = 00
> > > > fault virtual address= 0xf8000100
> > > > fault code   = supervisor write data, protection
> > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > stack pointer= 0x28:0x82a79be0
> > > > frame pointer= 0x28:0x82a79c10
> > > > code segment = base Ox0, limit Oxf, type Ox1b
> > > >  = DPL 0, pres 1, long 1, def32 0, gran
> > > > 1 processor eflags = resume, IOPL = 0
> > > > current process  = 0 ()
> > > > [ thread pid 0 tid 0 ]
> > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > %rax,(%rsi)
> > > Look up the source line number for this address.
> > >   
> > 
> > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > called by native_start_all_aps. Any additional hints how I can
> > track it down?  
> Why did you decided that this is rdmsr_safe() ? First,
> native_start_all_aps() does not call rdmsr, second the ddb
> report clearly indicates that the fault occured acessing DMAP in
> native_start_all_aps().
> 
> Just look up the source line by the address
> native_start_all_aps+0x08f.

Okay, according to kgbd this should be here:

https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369

364
365/* Create the initial 1GB replicated page tables */
366for (i = 0; i < 512; i++) {
367/* Each slot of the level 4 pages points to the same
level 3 page */ 368pt4[i] =
(u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
pt4[i] |= PG_V | PG_RW | PG_U; 370
371/* Each slot of the level 3 pages points to the same
level 2 page */ 372pt3[i] =
(u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
373pt3[i] |= PG_V | PG_RW | PG_U; 374
375/* The level 2 page slots are mapped with 2MB pages for
1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
378}

-m

p.s. This machine uses quirks in biosmem.c, see

Type '?' for a list of command, 'help' for more detailed
help.
OK biosmem
bios_basemem: 0x9e400
bios_extmem: 0x3ff0
memtop: 0x3c00
high_heap_base: 0x3c00
high_heap_size: 0x400
bios_quirks: 0x01 BQ_DISTRUST_820_EXTMEM
b_bios_probed: 0x0a B_BASEMEM_12 B_EXTMEM_E801

-- 
Michael Gmelin

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

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 16:21:10 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > After upgrading CURRENT to r333992 (from something at least a year
> > > old, quite some changes in mp_machdep.c since), this machine crashes
> > > on boot:
> > > 
> > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > > 1994 The Regents of the University of California. All rights
> > > reserved. FreeBSD is a registered trademark of The FreeBSD
> > > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04
> > > CEST 2018 root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based
> > > on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced
> > > performance. VT(vga): resolution 640x480
> > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > >   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > Stepping=1
> > > Features=0xbfebfbff > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > Features2=0x4ddaebbf > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > AMD Features=0x2c100800 AMD
> > > Features2=0x21 Structured Extended
> > > Features=0x2603 XSAVE
> > > Features=0x1 VT-x: (disabled in BIOS)
> > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance
> > > statistics real memory  = 4301258752 (4102 MB)
> > > avail memory = 1907572736 (1819 MB)
> > > Event timer "LAPIC" quality 600
> > > ACPI APIC Table:   
> > What does this mean ?  Did you flashed coreboot ?
> 
> This machine comes with it by default (my model was delivered with 
> SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> (didn't feel like bricking it).
> 
> > 
> > > kernel trap 12 with interrupts disabled
> > > 
> > > Fatal trap 12: page fault while in kernel mode 
> > > cpuid = 0; apic id = 00
> > > fault virtual address= 0xf8000100
> > > fault code   = supervisor write data, protection
> > > violation instruction pointer  = 0x20:Ox8102955f
> > > stack pointer= 0x28:0x82a79be0
> > > frame pointer= 0x28:0x82a79c10
> > > code segment = base Ox0, limit Oxf, type Ox1b
> > >  = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags = resume, IOPL = 0
> > > current process  = 0 ()
> > > [ thread pid 0 tid 0 ]
> > > Stopped at  native_start_all_aps+0x08f:  movq
> > > %rax,(%rsi)  
> > Look up the source line number for this address.
> > 
> 
> I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr), called by
> native_start_all_aps. Any additional hints how I can track it down?
Why did you decided that this is rdmsr_safe() ? First,
native_start_all_aps() does not call rdmsr, second the ddb
report clearly indicates that the fault occured acessing DMAP in
native_start_all_aps().

Just look up the source line by the address native_start_all_aps+0x08f.
___
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, 3 Jun 2018 16:21:10 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> > Hi,
> > 
> > After upgrading CURRENT to r333992 (from something at least a year
> > old, quite some changes in mp_machdep.c since), this machine crashes
> > on boot:
> > 
> > Copyright (c) 1992-2018 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > 1994 The Regents of the University of California. All rights
> > reserved. FreeBSD is a registered trademark of The FreeBSD
> > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04
> > CEST 2018 root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based
> > on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced
> > performance. VT(vga): resolution 640x480
> > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > Stepping=1
> > Features=0xbfebfbff > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > Features2=0x4ddaebbf > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > AMD Features=0x2c100800 AMD
> > Features2=0x21 Structured Extended
> > Features=0x2603 XSAVE
> > Features=0x1 VT-x: (disabled in BIOS)
> > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance
> > statistics real memory  = 4301258752 (4102 MB)
> > avail memory = 1907572736 (1819 MB)
> > Event timer "LAPIC" quality 600
> > ACPI APIC Table:   
> What does this mean ?  Did you flashed coreboot ?

This machine comes with it by default (my model was delivered with 
SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
(didn't feel like bricking it).

> 
> > kernel trap 12 with interrupts disabled
> > 
> > Fatal trap 12: page fault while in kernel mode 
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xf8000100
> > fault code   = supervisor write data, protection
> > violation instruction pointer  = 0x20:Ox8102955f
> > stack pointer= 0x28:0x82a79be0
> > frame pointer= 0x28:0x82a79c10
> > code segment = base Ox0, limit Oxf, type Ox1b
> >  = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = resume, IOPL = 0
> > current process  = 0 ()
> > [ thread pid 0 tid 0 ]
> > Stopped at  native_start_all_aps+0x08f:  movq
> > %rax,(%rsi)  
> Look up the source line number for this address.
> 

I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr), called by
native_start_all_aps. Any additional hints how I can track it down?

Thanks,
Michael

> > db>  
> > 
> > Any key press in the debugger will reboot the machine.
> > 
> > Booting with kern.smp.disabled=1 works.
> > 
> > Any ideas?
> > 
> > -m
> > 
> > -- 
> > 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"  
> ___
> 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"



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

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> Hi,
> 
> After upgrading CURRENT to r333992 (from something at least a year
> old, quite some changes in mp_machdep.c since), this machine crashes
> on boot:
> 
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
> 6.0.0)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
>   
> Features=0xbfebfbff CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   
> Features2=0x4ddaebbf xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
>   AMD Features=0x2c100800
>   AMD Features2=0x21
>   Structured Extended Features=0x2603
>   XSAVE Features=0x1
>   VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 4301258752 (4102 MB)
> avail memory = 1907572736 (1819 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
What does this mean ?  Did you flashed coreboot ?

> kernel trap 12 with interrupts disabled
> 
> Fatal trap 12: page fault while in kernel mode 
> cpuid = 0; apic id = 00
> fault virtual address= 0xf8000100
> fault code   = supervisor write data, protection violation
> instruction pointer  = 0x20:Ox8102955f
> stack pointer= 0x28:0x82a79be0
> frame pointer= 0x28:0x82a79c10
> code segment = base Ox0, limit Oxf, type Ox1b
>  = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process  = 0 ()
> [ thread pid 0 tid 0 ]
> Stopped at  native_start_all_aps+0x08f:  movq %rax,(%rsi)
Look up the source line number for this address.

> db>
> 
> Any key press in the debugger will reboot the machine.
> 
> Booting with kern.smp.disabled=1 works.
> 
> Any ideas?
> 
> -m
> 
> -- 
> 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"
___
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"

Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

Hi,

After upgrading CURRENT to r333992 (from something at least a year
old, quite some changes in mp_machdep.c since), this machine crashes
on boot:

Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
  Features=0xbfebfbff
  
Features2=0x4ddaebbf
  AMD Features=0x2c100800
  AMD Features2=0x21
  Structured Extended Features=0x2603
  XSAVE Features=0x1
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 4301258752 (4102 MB)
avail memory = 1907572736 (1819 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode 
cpuid = 0; apic id = 00
fault virtual address= 0xf8000100
fault code   = supervisor write data, protection violation
instruction pointer  = 0x20:Ox8102955f
stack pointer= 0x28:0x82a79be0
frame pointer= 0x28:0x82a79c10
code segment = base Ox0, limit Oxf, type Ox1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process  = 0 ()
[ thread pid 0 tid 0 ]
Stopped at  native_start_all_aps+0x08f:  movq %rax,(%rsi)
db>

Any key press in the debugger will reboot the machine.

Booting with kern.smp.disabled=1 works.

Any ideas?

-m

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

[Manuel Stühn]

On Sat, May 26, 2018 at 01:46:42PM +0200, Manuel Stühn wrote:

Since upgrading my Lenovo T450 from r333740 to r334167 I'm experiencing
several "Fatal traps 12". Before the update i did not have any of those.
In all cases the traps occured some time after resume.



I tried to debug this further by building different kernel versions (all 
GENERIC-NODEBUG). The last working revision is r334117, the first not 
working is r334123. Revisions 334118-334122 of the kernel did not build, 
so i cannot try these.


Any ideas what could cause these issue?

--
Manuel 
___

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

[Manuel Stühn]

On Sat, May 26, 2018 at 08:32:17PM +0800, blubee blubeeme wrote:


  Aren't you the guy using the drm-kmod if yes, your custom complied kernel
  and not the default kernel causing those issues.
  Best,
  Owen


I'm indeed using graphics/drm-stable-kmod, but i do not use a custom 
kernel:

uname -rsmv
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #8 r334167: Thu May 24 
20:06:20 CEST 2018 
root@valinor:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64


The drm-stable-kmod was installed from ports with the corresponding 
src-tree.


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

[blubee blubeeme]

On Sat, May 26, 2018, 19:52 Manuel Stühn  wrote:

> Since upgrading my Lenovo T450 from r333740 to r334167 I'm experiencing
> several "Fatal traps 12". Before the update i did not have any of those.
> In all cases the traps occured some time after resume.
>
> Below there is some output found in /var/crash/core.txt
>
> __curthread () at ./machine/pcpu.h:231
> 231 ./machine/pcpu.h: No such file or directory.
> (kgdb) #0  __curthread () at ./machine/pcpu.h:231
> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
> #2  0x80b9a6f0 in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:446
> #3  0x80b9ab83 in vpanic (fmt=,
> ap=0xfe0056507e50)
> at /usr/src/sys/kern/kern_shutdown.c:863
> #4  0x80b9a973 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:790
> #5  0x80ba5c3b in kdb_switch () at
> /usr/src/sys/kern/kern_synch.c:377
> #6  0x80ba5bb9 in mi_switch (flags=, newtd=0x0)
> at /usr/src/sys/kern/kern_synch.c:406
> #7  0x80bf3f5f in sleepq_timedwait (wchan=,
> pri=) at /usr/src/sys/kern/subr_sleepqueue.c:727
> #8  0x833c7bed in linux_add_to_sleepqueue
> (wchan=0xf8000bf6ad80, task=0xf8000bf6ad80, wmesg= out>, timeout=50, state=)
> at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:70
> #9  0x833c7a58 in linux_wait_event_common (wqh=,
> wq=, timeout=50, state=2, lock=0x0)
> at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:270
> #10 0x83458de6 in ?? ()
> #11 0x00061d026200 in ?? ()
> #12 0x0006 in ?? ()
> #13 0xf8000bf6ad80 in ?? ()
> #14 0x833c7540 in ?? ()
> at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:167
>from /boot/kernel/linuxkpi.ko
> #15 0xf80007804828 in ?? ()
> #16 0xf80007804828 in ?? ()
> #17 0x0030 in ?? ()
> #18 0x in ?? ()
> (kgdb)
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> fault virtual address   = 0x3
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80cc60cb
> stack pointer   = 0x28:0xfe0056508560
> frame pointer   = 0x28:0xfe0056508760
> 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 = 10218 (nextcloud)
> --
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x30011
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80cc60cb
> stack pointer   = 0x28:0xfe005e4d1560
> frame pointer   = 0x28:0xfe005e4d1760
> 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 = 17918 (DNS Resolver #16)
> --
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> fault virtual address   = 0x3
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80cc60cb
> stack pointer   = 0x28:0xfe0056508560
> frame pointer   = 0x28:0xfe0056508760
> 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 = 10218 (nextcloud)
>
> If there is any other information i can provide for solving this, please
> let me know.
>
> --
> Manuel
> ___
> 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"
>
Aren't you the guy using the drm-kmod if yes, your custom complied kernel
and not the default kernel causing those issues.

Best,
Owen

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

Fatal trap 12

[Manuel Stühn]

Since upgrading my Lenovo T450 from r333740 to r334167 I'm experiencing 
several "Fatal traps 12". Before the update i did not have any of those.  
In all cases the traps occured some time after resume.


Below there is some output found in /var/crash/core.txt

__curthread () at ./machine/pcpu.h:231
231 ./machine/pcpu.h: No such file or directory.
(kgdb) #0  __curthread () at ./machine/pcpu.h:231
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x80b9a6f0 in kern_reboot (howto=260)
   at /usr/src/sys/kern/kern_shutdown.c:446
#3  0x80b9ab83 in vpanic (fmt=, 
ap=0xfe0056507e50)

   at /usr/src/sys/kern/kern_shutdown.c:863
#4  0x80b9a973 in panic (fmt=)
   at /usr/src/sys/kern/kern_shutdown.c:790
#5  0x80ba5c3b in kdb_switch () at 
/usr/src/sys/kern/kern_synch.c:377

#6  0x80ba5bb9 in mi_switch (flags=, newtd=0x0)
   at /usr/src/sys/kern/kern_synch.c:406
#7  0x80bf3f5f in sleepq_timedwait (wchan=, 
pri=) at /usr/src/sys/kern/subr_sleepqueue.c:727
#8  0x833c7bed in linux_add_to_sleepqueue 
(wchan=0xf8000bf6ad80, task=0xf8000bf6ad80, wmesg=out>, timeout=50, state=)

   at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:70
#9  0x833c7a58 in linux_wait_event_common (wqh=, 
wq=, timeout=50, state=2, lock=0x0)

   at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:270
#10 0x83458de6 in ?? ()
#11 0x00061d026200 in ?? ()
#12 0x0006 in ?? ()
#13 0xf8000bf6ad80 in ?? ()
#14 0x833c7540 in ?? ()
   at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:167
  from /boot/kernel/linuxkpi.ko
#15 0xf80007804828 in ?? ()
#16 0xf80007804828 in ?? ()
#17 0x0030 in ?? ()
#18 0x in ?? ()
(kgdb) 



Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x3
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80cc60cb
stack pointer   = 0x28:0xfe0056508560
frame pointer   = 0x28:0xfe0056508760
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 = 10218 (nextcloud)
--
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x30011
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80cc60cb
stack pointer   = 0x28:0xfe005e4d1560
frame pointer   = 0x28:0xfe005e4d1760
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 = 17918 (DNS Resolver #16)
--
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x3
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80cc60cb
stack pointer   = 0x28:0xfe0056508560
frame pointer   = 0x28:0xfe0056508760
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 = 10218 (nextcloud)

If there is any other information i can provide for solving this, please 
let me know.


--
Manuel
___
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 booting FreeBSD-CURRENT via isboot kernel module.

[Maurizio Vairani]

2018-02-04 14:40 GMT+01:00 Andriy Gapon :

> On 04/02/2018 11:50, Maurizio Vairani wrote:
> > I have added a socket in the ifioctl() call as in the
> > /usr/src/sys/nfs/bootp_subr.c source.
> > Please let me know if you prefer a patch.
>
> A patch here https://reviews.freebsd.org/ would be the best.
>
> --
> Andriy Gapon
>

Hi,
I have uploaded a patch here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226982
--
Maurizio
___
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 booting FreeBSD-CURRENT via isboot kernel module.

[Maurizio Vairani]

2018-02-07 19:29 GMT+01:00 John Nielsen :

> > On Feb 7, 2018, at 6:07 AM, Maurizio Vairani 
> wrote:
> >
> > 2018-02-06 23:02 GMT+01:00 John Nielsen :
> > > On Feb 6, 2018, at 11:50 AM, Ian Lepore  wrote:
> > >
> > > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> > >>
> > >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> > >> since this commit in 2011:
> > >> https://svnweb.freebsd.org/base?view=revision&revision=218757
> > >>
> > >> So I'm going to add this patch to the port unconditionally once it
> > >> works.
> > >>
> > >> Unfortunately, I can't compile the port with either my patch below or
> > >> your original replacement version of isboot_ifup(). :( Did you make
> > >> other changes? Here's the error I'm getting:
> > >>
> > >> --- isboot.o ---
> > >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> > >> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
> > >>   ~~^
> > >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> > >> thread'
> > >> struct thread;
> > >>^
> > >> 1 error generated.
> > >>
> > >
> > > Try adding #include  if it's not already in the list.  It
> > > may be that that file got included via pollution from some other header
> > > file in the past and maybe now that has changed.
> > >
> > > If you're already including sys/proc.h then I'm clueless.
> >
> > Thanks Ian, that appears to work.
> >
> > Maurizio, can you apply the attached patch to a clean ports tree and see
> if isboot-kmod will build and function properly for you? This is all the
> changes from this thread and the previous one. If you let me know it works
> I'll get the port updated.
> >
> >
> > Hi John, I need some help.
> >
> > I am running:
> >  # uname -a
> > FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25
> 04:48:52 UTC 2018 r...@releng3.nyi.freebsd.org:/
> usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> >
> > after upgrading the ports tree with:
> > # portsnap fetch update
> >
> > I have copied the directory /usr/ports/net/isboot-kmod/ in
> /root/src/isboot-kmod and /root/src/isboot-kmod.orig
> > # ls -l /root/src
> > total 6
> > drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
> > drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
> > -rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt
> >
> > Trying to apply the patch I obtain the error:
> > # cd /root/src
> > # patch -sC < isboot_patch.txt
> > 2 out of 2 hunks failed while patching isboot-kmod/Makefile
> > 5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c
> >
> > What I am missing ?
> > Thanks again for your work.
>
> Not sure but I ran in to similar issues testing here as well. Here's the
> "svn diff" patch which does work for me. Note that this one should be
> applied from within the isboot-kmod directory.
>
>
With this patch I receive this error :
# pwd
/root/src/isboot-kmod
# patch -sC  < ../isboot-kmod-0.2.13_2.diff.txt
2 out of 2 hunks failed while patching Makefile
5 out of 5 hunks failed while patching files/patch-isboot.c
___
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 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 7, 2018, at 6:07 AM, Maurizio Vairani  wrote:
> 
> 2018-02-06 23:02 GMT+01:00 John Nielsen :
> > On Feb 6, 2018, at 11:50 AM, Ian Lepore  wrote:
> >
> > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> >>
> >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> >> since this commit in 2011:
> >> https://svnweb.freebsd.org/base?view=revision&revision=218757
> >>
> >> So I'm going to add this patch to the port unconditionally once it
> >> works.
> >>
> >> Unfortunately, I can't compile the port with either my patch below or
> >> your original replacement version of isboot_ifup(). :( Did you make
> >> other changes? Here's the error I'm getting:
> >>
> >> --- isboot.o ---
> >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> >> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
> >>   ~~^
> >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> >> thread'
> >> struct thread;
> >>^
> >> 1 error generated.
> >>
> >
> > Try adding #include  if it's not already in the list.  It
> > may be that that file got included via pollution from some other header
> > file in the past and maybe now that has changed.
> >
> > If you're already including sys/proc.h then I'm clueless.
> 
> Thanks Ian, that appears to work.
> 
> Maurizio, can you apply the attached patch to a clean ports tree and see if 
> isboot-kmod will build and function properly for you? This is all the changes 
> from this thread and the previous one. If you let me know it works I'll get 
> the port updated.
> 
> 
> Hi John, I need some help.
> 
> I am running:
>  # uname -a
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52 
> UTC 2018 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> 
> after upgrading the ports tree with:
> # portsnap fetch update
> 
> I have copied the directory /usr/ports/net/isboot-kmod/ in  
> /root/src/isboot-kmod and /root/src/isboot-kmod.orig
> # ls -l /root/src
> total 6
> drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
> drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
> -rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt
> 
> Trying to apply the patch I obtain the error:
> # cd /root/src
> # patch -sC < isboot_patch.txt
> 2 out of 2 hunks failed while patching isboot-kmod/Makefile
> 5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c 
> 
> What I am missing ?
> Thanks again for your work.

Not sure but I ran in to similar issues testing here as well. Here's the "svn 
diff" patch which does work for me. Note that this one should be applied from 
within the isboot-kmod directory.

Index: Makefile
===
--- Makefile(revision 461112)
+++ Makefile(working copy)
@@ -2,7 +2,7 @@
 
 PORTNAME=  isboot-kmod
 PORTVERSION=   0.2.13
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=net
 MASTER_SITES=  http://www.peach.ne.jp/archives/isboot/
 DISTNAME=  isboot-${PORTVERSION}
@@ -12,9 +12,7 @@
 
 LICENSE=   BSD2CLAUSE
 
-BROKEN_aarch64=fails to compile: 
/usr/src/sys/sys/bus.h:724:10: fatal error: 'device_if.h' file not found
 BROKEN_armv6=  fails to compile: implicit declaration of function 
'cp15_pmccntr_get' is invalid in C99
-BROKEN_armv7=  fails to compile: /usr/src/sys/sys/bus.h:724:10: fatal 
error: 'device_if.h' file not found
 BROKEN_powerpc64=  fails to compile: pcpu.h: size of array '__assert_0' is 
negative
 
 USES=  kmod uidfix
Index: files/patch-Makefile
===
--- files/patch-Makefile(nonexistent)
+++ files/patch-Makefile(working copy)
@@ -0,0 +1,10 @@
+--- Makefile.orig  2015-09-23 22:33:04.0 -0600
 Makefile   2018-01-29 10:20:10.453188000 -0700
+@@ -6,6 +6,7 @@
+ SRCS= isboot.c ibft.c iscsi.c
+ SRCS+=isboot.h ibft.h iscsi_compat.h
+ SRCS+=opt_cam.h
++SRCS+=device_if.h bus_if.h
+ #CFLAGS+= -DVIMAGE
+ #CFLAGS+= -DIBFT_VERBOSE
+ #CFLAGS+= -DDEBUG

Property changes on: files/patch-Makefile
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: files/patch-isboot.c
===
--- files/patch-isboot.c(revision 461112)
+++ files/patch-isboot.c(working copy)
@@ -1,6 +1,14 @@
 isboot.c.orig  2015-11-05 16:50:51 UTC
-+++ isboot.c
-@@ -347,9 +347,9 @@ isboot_set_v4gw(struct sockaddr_in *gate
+--- isboot.c.orig  2015-11-05 09:50:51.0 -0700
 isboot.c   2018-02-06 14:23:24.479249000 

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[Maurizio Vairani]

2018-02-06 23:02 GMT+01:00 John Nielsen :

> > On Feb 6, 2018, at 11:50 AM, Ian Lepore  wrote:
> >
> > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> >>
> >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> >> since this commit in 2011:
> >> https://svnweb.freebsd.org/base?view=revision&revision=218757
> >>
> >> So I'm going to add this patch to the port unconditionally once it
> >> works.
> >>
> >> Unfortunately, I can't compile the port with either my patch below or
> >> your original replacement version of isboot_ifup(). :( Did you make
> >> other changes? Here's the error I'm getting:
> >>
> >> --- isboot.o ---
> >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> >> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
> >>   ~~^
> >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> >> thread'
> >> struct thread;
> >>^
> >> 1 error generated.
> >>
> >
> > Try adding #include  if it's not already in the list.  It
> > may be that that file got included via pollution from some other header
> > file in the past and maybe now that has changed.
> >
> > If you're already including sys/proc.h then I'm clueless.
>
> Thanks Ian, that appears to work.
>
> Maurizio, can you apply the attached patch to a clean ports tree and see
> if isboot-kmod will build and function properly for you? This is all the
> changes from this thread and the previous one. If you let me know it works
> I'll get the port updated.
>
>
> Hi John, I need some help.

I am running:
 # uname -a
FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
UTC 2018 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

after upgrading the ports tree with:
# portsnap fetch update

I have copied the directory /usr/ports/net/isboot-kmod/ in
/root/src/isboot-kmod and /root/src/isboot-kmod.orig
# ls -l /root/src
total 6
drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
-rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt

Trying to apply the patch I obtain the error:
# cd /root/src
# patch -sC < isboot_patch.txt
2 out of 2 hunks failed while patching isboot-kmod/Makefile
5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c

What I am missing ?
Thanks again for your work.
--
Maurizio
___
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 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 6, 2018, at 11:50 AM, Ian Lepore  wrote:
> 
> On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
>> 
>> Apparently sending a NULL socket pointer to ifioctl hasn't worked
>> since this commit in 2011:
>> https://svnweb.freebsd.org/base?view=revision&revision=218757
>> 
>> So I'm going to add this patch to the port unconditionally once it
>> works.
>> 
>> Unfortunately, I can't compile the port with either my patch below or
>> your original replacement version of isboot_ifup(). :( Did you make
>> other changes? Here's the error I'm getting:
>> 
>> --- isboot.o ---
>> isboot.c:425:53: error: incomplete definition of type 'struct thread'
>> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
>>   ~~^
>> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
>> thread'
>> struct thread;
>>^
>> 1 error generated.
>> 
> 
> Try adding #include  if it's not already in the list.  It
> may be that that file got included via pollution from some other header
> file in the past and maybe now that has changed.
> 
> If you're already including sys/proc.h then I'm clueless.

Thanks Ian, that appears to work.

Maurizio, can you apply the attached patch to a clean ports tree and see if 
isboot-kmod will build and function properly for you? This is all the changes 
from this thread and the previous one. If you let me know it works I'll get the 
port updated.

diff -uPr isboot-kmod.orig/Makefile isboot-kmod/Makefile
--- isboot-kmod.orig/Makefile   2018-01-11 07:18:01.0 -0700
+++ isboot-kmod/Makefile2018-02-06 14:56:23.654737000 -0700
@@ -2,7 +2,7 @@
 
 PORTNAME=  isboot-kmod
 PORTVERSION=   0.2.13
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=net
 MASTER_SITES=  http://www.peach.ne.jp/archives/isboot/
 DISTNAME=  isboot-${PORTVERSION}
@@ -12,9 +12,7 @@
 
 LICENSE=   BSD2CLAUSE
 
-BROKEN_aarch64=fails to compile: 
/usr/src/sys/sys/bus.h:724:10: fatal error: 'device_if.h' file not found
 BROKEN_armv6=  fails to compile: implicit declaration of function 
'cp15_pmccntr_get' is invalid in C99
-BROKEN_armv7=  fails to compile: /usr/src/sys/sys/bus.h:724:10: fatal 
error: 'device_if.h' file not found
 BROKEN_powerpc64=  fails to compile: pcpu.h: size of array '__assert_0' is 
negative
 
 USES=  kmod uidfix
diff -uPr isboot-kmod.orig/files/patch-Makefile isboot-kmod/files/patch-Makefile
--- isboot-kmod.orig/files/patch-Makefile   1969-12-31 17:00:00.0 
-0700
+++ isboot-kmod/files/patch-Makefile2018-01-29 10:24:27.372206000 -0700
@@ -0,0 +1,10 @@
+--- Makefile.orig  2015-09-23 22:33:04.0 -0600
 Makefile   2018-01-29 10:20:10.453188000 -0700
+@@ -6,6 +6,7 @@
+ SRCS= isboot.c ibft.c iscsi.c
+ SRCS+=isboot.h ibft.h iscsi_compat.h
+ SRCS+=opt_cam.h
++SRCS+=device_if.h bus_if.h
+ #CFLAGS+= -DVIMAGE
+ #CFLAGS+= -DIBFT_VERBOSE
+ #CFLAGS+= -DDEBUG
diff -uPr isboot-kmod.orig/files/patch-isboot.c isboot-kmod/files/patch-isboot.c
--- isboot-kmod.orig/files/patch-isboot.c   2016-05-06 08:34:57.0 
-0600
+++ isboot-kmod/files/patch-isboot.c2018-02-06 14:24:47.447244000 -0700
@@ -1,6 +1,14 @@
 isboot.c.orig  2015-11-05 16:50:51 UTC
-+++ isboot.c
-@@ -347,9 +347,9 @@ isboot_set_v4gw(struct sockaddr_in *gate
+--- isboot.c.orig  2015-11-05 09:50:51.0 -0700
 isboot.c   2018-02-06 14:23:24.479249000 -0700
+@@ -38,6 +38,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -347,9 +348,9 @@
netmask.sin_addr.s_addr = htonl(0);
  
/* delete gateway if exists */
@@ -12,7 +20,7 @@
if (error) {
if (error != ESRCH) {
printf("rtrequest RTM_DELETE error %d\n",
-@@ -359,9 +359,9 @@ isboot_set_v4gw(struct sockaddr_in *gate
+@@ -359,9 +360,9 @@
}
  
/* set new default gateway */
@@ -24,7 +32,7 @@
if (error) {
printf("rtrequest RTM_ADD error %d\n", error);
return (error);
-@@ -391,9 +391,9 @@ isboot_set_v6gw(struct sockaddr_in6 *gat
+@@ -391,9 +392,9 @@
memset(&netmask.sin6_addr, 0, 16);
  
/* delete gateway if exists */
@@ -36,7 +44,7 @@
if (error) {
if (error != ESRCH) {
printf("rtrequest RTM_DELETE error %d\n",
-@@ -403,9 +403,9 @@ isboot_set_v6gw(struct sockaddr_in6 *gat
+@@ -403,9 +404,9 @@
}
  
/* set new default gateway */
@@ -48,3 +56,42 @@
if (error) {
printf("rtrequest RTM_ADD error %d\n", error);
return (error);
+@@ -417,28 +418,36 @@
+ isboot_ifup(struct ifnet *ifp)
+ {
+   struct ifreq ifr;
++  struct socket *so;
+   struct thread *td;
+   int error;
+ 
+   memset(&ifr, 0, sizeof(ifr));
+   td = curthread;
+ 
++  error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
++  i

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[Ian Lepore]

On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> > 
> > On Feb 6, 2018, at 10:54 AM, John Nielsen 
> > wrote:
> > 
> > > 
> > > 
> > > On Feb 4, 2018, at 2:50 AM, Maurizio Vairani  > > com> wrote:
> > > 
> > > 2018-01-29 18:38 GMT+01:00 John Nielsen :
> > > [ resending from correct email address ]
> > > 
> > > > 
> > > > On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  > > > il.com> wrote:
> > > > 
> > > > I am running
> > > > # uname
> > > > -a
> > > > 
> > > > FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan
> > > > 25 04:48:52
> > > > UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd6
> > > > 4.amd64/sys/GENERIC
> > > > amd64
> > > > 
> > > > After compiling the kernel module as discussed in this thread :
> > > > https://lists.freebsd.org/pipermail/freebsd-current/2018-Januar
> > > > y/068272.html
> > > > 
> > > > I can boot FreeBSD via iSCSI using iPXE. But when the isboot,
> > > > the iSCSI
> > > > boot driver version 0.2.13, starts I receive a panic:
> > > > https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdU
> > > > A1BorD4
> > > > 
> > > > Any idea?
> > > Bummer! 
> > > 
> > > Aoyama-san-
> > > 
> > > Are you still maintaining isboot? Can you help debug this issue
> > > on FreeBSD 12-CURRENT?
> > > 
> > > Once we get it working I will update the port with whatever is
> > > needed and send you the patches in case you'd like to cut a new
> > > release.
> > > 
> > > Thank you!
> > > 
> > > I have solved the issue changing the function isboot_ifup() in
> > > the source file isboot.c.
> > Here is a patch with some changes to minimize the diff. Except for
> > the printed error messages does that look functionally equivalent?
> > 
> > Now the question is why is this change needed and for what values
> > of __FreeBSD_version is it appropriate?
> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> since this commit in 2011:
> https://svnweb.freebsd.org/base?view=revision&revision=218757
> 
> So I'm going to add this patch to the port unconditionally once it
> works.
> 
> Unfortunately, I can't compile the port with either my patch below or
> your original replacement version of isboot_ifup(). :( Did you make
> other changes? Here's the error I'm getting:
> 
> --- isboot.o ---
> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
>   ~~^
> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> thread'
> struct thread;
>    ^
> 1 error generated.
> 

Try adding #include  if it's not already in the list.  It
may be that that file got included via pollution from some other header
file in the past and maybe now that has changed.

If you're already including sys/proc.h then I'm clueless.

-- Ian

___
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 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 6, 2018, at 10:54 AM, John Nielsen  wrote:
> 
>> 
>> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani  wrote:
>> 
>> 2018-01-29 18:38 GMT+01:00 John Nielsen :
>> [ resending from correct email address ]
>> 
>>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  
>>> wrote:
>>> 
>>> I am running
>>> # uname
>>> -a
>>> 
>>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
>>> UTC 2018 
>>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>>> amd64
>>> 
>>> After compiling the kernel module as discussed in this thread :
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
>>> 
>>> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
>>> boot driver version 0.2.13, starts I receive a panic:
>>> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>>> 
>>> Any idea?
>> 
>> Bummer! 
>> 
>> Aoyama-san-
>> 
>> Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
>> 12-CURRENT?
>> 
>> Once we get it working I will update the port with whatever is needed and 
>> send you the patches in case you'd like to cut a new release.
>> 
>> Thank you!
>> 
>> I have solved the issue changing the function isboot_ifup() in the source 
>> file isboot.c.
> 
> Here is a patch with some changes to minimize the diff. Except for the 
> printed error messages does that look functionally equivalent?
> 
> Now the question is why is this change needed and for what values of 
> __FreeBSD_version is it appropriate?

Apparently sending a NULL socket pointer to ifioctl hasn't worked since this 
commit in 2011:
https://svnweb.freebsd.org/base?view=revision&revision=218757

So I'm going to add this patch to the port unconditionally once it works.

Unfortunately, I can't compile the port with either my patch below or your 
original replacement version of isboot_ifup(). :( Did you make other changes? 
Here's the error I'm getting:

--- isboot.o ---
isboot.c:425:53: error: incomplete definition of type 'struct thread'
error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
  ~~^
/usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct thread'
struct thread;
   ^
1 error generated.


> # diff -u isboot.c.patched1 isboot.c
> --- isboot.c.patched1 2018-02-06 10:35:20.808692000 -0700
> +++ isboot.c  2018-02-06 10:50:05.347663000 -0700
> @@ -417,28 +417,36 @@
> isboot_ifup(struct ifnet *ifp)
> {
>   struct ifreq ifr;
> + struct socket *so;
>   struct thread *td;
>   int error;
> 
>   memset(&ifr, 0, sizeof(ifr));
>   td = curthread;
> 
> + error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
> + if (error) {
> + printf("%s: socreate, error=%d\n", __func__, error);
> + return (error);
> + }
> +
>   /* boot NIC */
>   strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
> 
>   /* set IFF_UP */
> - error = ifioctl(NULL, SIOCGIFFLAGS, (caddr_t)&ifr, td);
> + error = ifioctl(so, SIOCGIFFLAGS, (caddr_t)&ifr, td);
>   if (error) {
>   printf("ifioctl SIOCGIFFLAGS\n");
>   return (error);
>   }
>   ifr.ifr_flags |= IFF_UP;
> - error = ifioctl(NULL, SIOCSIFFLAGS, (caddr_t)&ifr, td);
> + error = ifioctl(so, SIOCSIFFLAGS, (caddr_t)&ifr, td);
>   if (error) {
>   printf("ifioctl SIOCSIFFLAGS\n");
>   return (error);
>   }
> 
> + soclose(so);
>   return (0);
> }
> 
> 
>> static int
>> isboot_ifup(struct ifnet *ifp)
>> {
>>struct socket *so;
>>struct ifreq ifr;
>>struct thread *td;
>>int error;
>> 
>>td = curthread;
>>error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
>>if (error) {
>>printf("%s: socreate, error=%d\n", __func__, error);
>>return (error);
>>}
>> 
>>/* boot NIC */
>>memset(&ifr, 0, sizeof(ifr));
>>strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
>> 
>>/* set IFF_UP */
>>error = ifioctl(so, SIOCGIFFLAGS, (caddr_t)&ifr, td);
>>if (error) {
>>printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
>>return (error);
>>}
>> 
>>ifr.ifr_flags |= IFF_UP;
>>error = ifioctl(so, SIOCSIFFLAGS, (caddr_t)&ifr, td);
>>if (error) {
>>printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
>>return (error);
>>}
>>soclose(so);
>>return (0);
>> }
>> 
>> I have added a socket in the ifioctl() call as in the 
>> /usr/src/sys/nfs/bootp_subr.c source.
>> Please let me know if you prefer a patch.
>> --
>> Regards,
>> Maurizio

___
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 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani  wrote:
> 
> 2018-01-29 18:38 GMT+01:00 John Nielsen :
> [ resending from correct email address ]
> 
>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  wrote:
>> 
>> I am running
>> # uname
>> -a
>> 
>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
>> UTC 2018 
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>> 
>> After compiling the kernel module as discussed in this thread :
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
>> 
>> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
>> boot driver version 0.2.13, starts I receive a panic:
>> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>> 
>> Any idea?
> 
> Bummer! 
> 
> Aoyama-san-
> 
> Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
> 12-CURRENT?
> 
> Once we get it working I will update the port with whatever is needed and 
> send you the patches in case you'd like to cut a new release.
> 
> Thank you!
> 
> I have solved the issue changing the function isboot_ifup() in the source 
> file isboot.c.

Here is a patch with some changes to minimize the diff. Except for the printed 
error messages does that look functionally equivalent?

Now the question is why is this change needed and for what values of 
__FreeBSD_version is it appropriate?

# diff -u isboot.c.patched1 isboot.c
--- isboot.c.patched1   2018-02-06 10:35:20.808692000 -0700
+++ isboot.c2018-02-06 10:50:05.347663000 -0700
@@ -417,28 +417,36 @@
 isboot_ifup(struct ifnet *ifp)
 {
struct ifreq ifr;
+   struct socket *so;
struct thread *td;
int error;
 
memset(&ifr, 0, sizeof(ifr));
td = curthread;
 
+   error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
+   if (error) {
+   printf("%s: socreate, error=%d\n", __func__, error);
+   return (error);
+   }
+
/* boot NIC */
strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
 
/* set IFF_UP */
-   error = ifioctl(NULL, SIOCGIFFLAGS, (caddr_t)&ifr, td);
+   error = ifioctl(so, SIOCGIFFLAGS, (caddr_t)&ifr, td);
if (error) {
printf("ifioctl SIOCGIFFLAGS\n");
return (error);
}
ifr.ifr_flags |= IFF_UP;
-   error = ifioctl(NULL, SIOCSIFFLAGS, (caddr_t)&ifr, td);
+   error = ifioctl(so, SIOCSIFFLAGS, (caddr_t)&ifr, td);
if (error) {
printf("ifioctl SIOCSIFFLAGS\n");
return (error);
}
 
+   soclose(so);
return (0);
 }


> static int
> isboot_ifup(struct ifnet *ifp)
> {
> struct socket *so;
> struct ifreq ifr;
> struct thread *td;
> int error;
> 
> td = curthread;
> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
> if (error) {
> printf("%s: socreate, error=%d\n", __func__, error);
> return (error);
> }
> 
> /* boot NIC */
> memset(&ifr, 0, sizeof(ifr));
> strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
> 
> /* set IFF_UP */
> error = ifioctl(so, SIOCGIFFLAGS, (caddr_t)&ifr, td);
> if (error) {
> printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> 
> ifr.ifr_flags |= IFF_UP;
> error = ifioctl(so, SIOCSIFFLAGS, (caddr_t)&ifr, td);
> if (error) {
> printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> soclose(so);
> return (0);
> }
> 
> I have added a socket in the ifioctl() call as in the 
> /usr/src/sys/nfs/bootp_subr.c source.
> Please let me know if you prefer a patch.
> --
> Regards,
> Maurizio
> 

___
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 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani  wrote:
> 
> 2018-01-29 18:38 GMT+01:00 John Nielsen :
> [ resending from correct email address ]
> 
>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  wrote:
>> 
>> I am running
>> # uname
>> -a
>> 
>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
>> UTC 2018 
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>> 
>> After compiling the kernel module as discussed in this thread :
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
>> 
>> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
>> boot driver version 0.2.13, starts I receive a panic:
>> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>> 
>> Any idea?
> 
> Bummer! 
> 
> Aoyama-san-
> 
> Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
> 12-CURRENT?
> 
> Once we get it working I will update the port with whatever is needed and 
> send you the patches in case you'd like to cut a new release.
> 
> Thank you!
> 
> I have solved the issue changing the function isboot_ifup() in the source 
> file isboot.c.

Nice work, thank you! I'll put the below together with the necessary changes to 
iscsi.c and update the port. If you could re-install from the port at that 
point as a further test/sanity check that would be great.

> static int
> isboot_ifup(struct ifnet *ifp)
> {
> struct socket *so;
> struct ifreq ifr;
> struct thread *td;
> int error;
> 
> td = curthread;
> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
> if (error) {
> printf("%s: socreate, error=%d\n", __func__, error);
> return (error);
> }
> 
> /* boot NIC */
> memset(&ifr, 0, sizeof(ifr));
> strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
> 
> /* set IFF_UP */
> error = ifioctl(so, SIOCGIFFLAGS, (caddr_t)&ifr, td);
> if (error) {
> printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> 
> ifr.ifr_flags |= IFF_UP;
> error = ifioctl(so, SIOCSIFFLAGS, (caddr_t)&ifr, td);
> if (error) {
> printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> soclose(so);
> return (0);
> }
> 
> I have added a socket in the ifioctl() call as in the 
> /usr/src/sys/nfs/bootp_subr.c source.
> Please let me know if you prefer a patch.
> --
> Regards,
> Maurizio

___
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 booting FreeBSD-CURRENT via isboot kernel module.

[Andriy Gapon]

On 04/02/2018 11:50, Maurizio Vairani wrote:
> I have added a socket in the ifioctl() call as in the
> /usr/src/sys/nfs/bootp_subr.c source.
> Please let me know if you prefer a patch.

A patch here https://reviews.freebsd.org/ would be the best.

-- 
Andriy Gapon
___
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 booting FreeBSD-CURRENT via isboot kernel module.

[Maurizio Vairani]

2018-01-29 18:38 GMT+01:00 John Nielsen :

> [ resending from correct email address ]
>
> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani 
> wrote:
>
> I am running
> # uname
> -a
>
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
> UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.
> amd64/sys/GENERIC
> amd64
>
> After compiling the kernel module as discussed in this thread :
> https://lists.freebsd.org/pipermail/freebsd-current/
> 2018-January/068272.html
>
> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
> boot driver version 0.2.13, starts I receive a panic:
> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>
> Any idea?
>
>
> Bummer!
>
> Aoyama-san-
>
> Are you still maintaining isboot? Can you help debug this issue on FreeBSD
> 12-CURRENT?
>
> Once we get it working I will update the port with whatever is needed and
> send you the patches in case you'd like to cut a new release.
>
> Thank you!
>

I have solved the issue changing the function isboot_ifup() in the source
file isboot.c.

static int
isboot_ifup(struct ifnet *ifp)
{
struct socket *so;
struct ifreq ifr;
struct thread *td;
int error;

td = curthread;
error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
if (error) {
printf("%s: socreate, error=%d\n", __func__, error);
return (error);
}

/* boot NIC */
memset(&ifr, 0, sizeof(ifr));
strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));

/* set IFF_UP */
error = ifioctl(so, SIOCGIFFLAGS, (caddr_t)&ifr, td);
if (error) {
printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
return (error);
}

ifr.ifr_flags |= IFF_UP;
error = ifioctl(so, SIOCSIFFLAGS, (caddr_t)&ifr, td);
if (error) {
printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
return (error);
}
soclose(so);
return (0);
}

I have added a socket in the ifioctl() call as in the
/usr/src/sys/nfs/bootp_subr.c source.
Please let me know if you prefer a patch.
--
Regards,
Maurizio
___
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 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

[ resending from correct email address ]

> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  wrote:
> 
> I am running
> # uname
> -a
> 
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
> UTC 2018 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> 
> After compiling the kernel module as discussed in this thread :
> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
> 
> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
> boot driver version 0.2.13, starts I receive a panic:
> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
> 
> Any idea?

Bummer! 

Aoyama-san-

Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
12-CURRENT?

Once we get it working I will update the port with whatever is needed and send 
you the patches in case you'd like to cut a new release.

Thank you!
___
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"

Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[Maurizio Vairani]

I am running
# uname
-a

FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
UTC 2018 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

After compiling the kernel module as discussed in this thread :
https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html

I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
boot driver version 0.2.13, starts I receive a panic:
https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4

Any idea?
--
Thanks,
Maurizio
___
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: head -r325997: Fatal trap 12: page fault while in kernel mode (during a buildworld, virtualbox guest context) [2nd example]

[Mark Millard]

[Adding some analysis of where the 2 failures were in
source code terms.]

On 2017-Nov-19, at 9:07 PM, Mark Millard  wrote:

> [I got another of these. By the way: amd64 context.
> Again: buildworld was running.]
> 
> On 2017-Nov-19, at 5:52 PM, Mark Millard  wrote:
> 
>> Attempting a dump failed. I'm afraid all for
>> information is the below. The kernel was a
>> non-debug kernel (with debug information).
>> 
>> The following is hand typed from a screen shot:
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address = 0xff53f000e2b0
> 
> New one:  0x806b49010
> 
>> fault code= supervisor read data, page not present
> 
> New one:  supervisor write data, page not present
> 
>> instruction pointer   = 0x20:0x80f2b11e
> 
> New one:  0x20:0x80f2b21b
> 
>> stack pointer = 0x0:0xfe01aeb28970
> 
> New one:  0x28:0xfe01aeb28970
> 
>> frame pointer = 0x0:0xfe01aeb289f0
> 
> New one:  0x28:0xfe01aeb289f0
> 
>> 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   = 20 (pagedaemon)
>> [ thread pid 20 tid 100089 ]
>> Stopped at pmap_ts_referenced+0x72e: movq (%rcx,rdi,8),%rbx
> 
> New one: pmap_ts_referenced+0x82b: movq %rcx,0x10(%rax)
> 
>> bd > bt
>> Tracing pid 20 tid 100089 td 0xf80003eb3560
> 
> New one:td 0xf80003df6000
> 
>> pmap_ts_referenced() at pmap_ts_referenced_0x72e/frame 0xfe01aeb289f0
> New one:
> pmap_ts_referenced() at pmap_ts_referenced_0x82b/frame 0xfe01aeb289f0
> 
>> vm_pageout() at vm_pageout+0xdeb/frame 0xfe01aeb28ab0
> 
> Correction to original:frame 0xfe01aeb28a70
> (new is the same)
> 
>> fork_exit() at fork_exit+0x82/frame 0xfe01aeb28ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe01aeb28ab0
>> --- trap 0, rip = 0, rsp = 0, rpb = 0 ---
>> db>
>> 
>> The prior (cross) buildworld buildkernel had completed fine.
>> 
>> Until yesterday, I'd been running -r325700 or before and had not
>> seen such an issue ever before. I'd been using the virtualbox
>> version for a while before this as well.


Taking the case of:

Stopped at pmap_ts_referenced+0x72e: movq (%rcx,rdi,8),%rbx:

80f2b0fc  mov%rax,%rsi
80f2b0ff  shr$0x1b,%rsi
80f2b103  and$0xff8,%esi
80f2b109  mov(%rcx,%rsi,1),%rcx
80f2b10d  and%r10,%rcx
80f2b110  or %r9,%rcx
80f2b113  mov%eax,%edi
80f2b115  shr$0x15,%edi
80f2b118  and$0x1ff,%edi
80f2b11e  mov(%rcx,%rdi,8),%rbx
<<<<<<===
80f2b122  and%r10,%rbx
80f2b125  or %r9,%rbx
80f2b128  shr$0x9,%rax
80f2b12c  and$0xff8,%eax
80f2b131  lea(%rbx,%rax,1),%rsi
80f2b135  mov(%rbx,%rax,1),%rbx
80f2b139  mov%rbx,%rax
80f2b13c  and%rdx,%rax
80f2b13f  cmp%rdx,%rax
80f2b142  jne80f2b14f 


Which, if I understand right, is in the
"small_mappings:" code:

PG_A = pmap_accessed_bit(pmap);
PG_M = pmap_modified_bit(pmap);
PG_RW = pmap_rw_bit(pmap);
pde = pmap_pde(pmap, pv->pv_va);
KASSERT((*pde & PG_PS) == 0,
("pmap_ts_referenced: found a 2mpage in page %p's pv list",
m));
pte = pmap_pde_to_pte(pde, pv->pv_va);
if ((*pte & (PG_M | PG_RW)) == (PG_M | PG_RW))
vm_page_dirty(m);
if ((*pte & PG_A) != 0) {


with the failure being during *pde in:

/* Return a pointer to the PT slot that corresponds to a VA */
static __inline pt_entry_t *
pmap_pde_to_pte(pd_entry_t *pde, vm_offset_t va)
{
pt_entry_t *pte;

pte = (pt_entry_t *)PHYS_TO_DMAP(*pde & PG_FRAME);
return (&pte[pmap_pte_index(va)]);
}



Taking the case of:

New one: pmap_ts_referenced+0x82b: movq %rcx,0x10(%rax)

80f2b1fb  lock cmpxchg %rcx,(%rdx)
80f2b200  sete   %cl
80f2b203  test   %cl,%cl
80f2b205  je 80f2b27d 

80f2b207  test   %r12,%r12
80f2b20a  je 80f2b255 

80f2b20c  mov0x8(%r12),%rax
80f2b211  test   %rax,%rax
80f2b214  je 80f2b255 

80f2b216  mov0x10(%r12),%rcx
fff

Re: head -r325997: Fatal trap 12: page fault while in kernel mode (during a buildworld, virtualbox guest context) [2nd example]

[Mark Millard]

[I got another of these. By the way: amd64 context.
Again: buildworld was running.]

On 2017-Nov-19, at 5:52 PM, Mark Millard  wrote:

> Attempting a dump failed. I'm afraid all for
> information is the below. The kernel was a
> non-debug kernel (with debug information).
> 
> The following is hand typed from a screen shot:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0xff53f000e2b0

New one:  0x806b49010

> fault code= supervisor read data, page not present

New one:  supervisor write data, page not present

> instruction pointer   = 0x20:0x80f2b11e

New one:  0x20:0x80f2b21b

> stack pointer = 0x0:0xfe01aeb28970

New one:  0x28:0xfe01aeb28970

> frame pointer = 0x0:0xfe01aeb289f0

New one:  0x28:0xfe01aeb289f0

> 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   = 20 (pagedaemon)
> [ thread pid 20 tid 100089 ]
> Stopped at pmap_ts_referenced+0x72e: movq (%rcx,rdi,8),%rbx

New one: pmap_ts_referenced+0x82b: movq %rcx,0x10(%rax)

> bd > bt
> Tracing pid 20 tid 100089 td 0xf80003eb3560

New one:td 0xf80003df6000

> pmap_ts_referenced() at pmap_ts_referenced_0x72e/frame 0xfe01aeb289f0
New one:
pmap_ts_referenced() at pmap_ts_referenced_0x82b/frame 0xfe01aeb289f0

> vm_pageout() at vm_pageout+0xdeb/frame 0xfe01aeb28ab0

Correction to original:frame 0xfe01aeb28a70
(new is the same)

> fork_exit() at fork_exit+0x82/frame 0xfe01aeb28ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe01aeb28ab0
> --- trap 0, rip = 0, rsp = 0, rpb = 0 ---
> db>
> 
> The prior (cross) buildworld buildkernel had completed fine.
> 
> Until yesterday, I'd been running -r325700 or before and had not
> seen such an issue ever before. I'd been using the virtualbox
> version for a while before this as well.

===
Mark Millard
markmi at dsl-only.net


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

head -r325997: Fatal trap 12: page fault while in kernel mode (during a buildworld, virtualbox guest context)

[Mark Millard]

Attempting a dump failed. I'm afraid all for
information is the below. The kernel was a
non-debug kernel (with debug information).

The following is hand typed from a screen shot:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xff53f000e2b0
fault code= supervisor read data, page not present
instruction pointer   = 0x20:0x80f2b11e
stack pointer = 0x0:0xfe01aeb28970
frame pointer = 0x0:0xfe01aeb289f0
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   = 20 (pagedaemon)
[ thread pid 20 tid 100089 ]
Stopped at pmap_ts_referenced+0x72e: movq (%rcx,rdi,8),%rbx
bd > bt
Tracing pid 20 tid 100089 td 0xf80003eb3560
pmap_ts_referenced() at pmap_ts_referenced_0x72e/frame 0xfe01aeb289f0
vm_pageout() at vm_pageout+0xdeb/frame 0xfe01aeb28ab0
fork_exit() at fork_exit+0x82/frame 0xfe01aeb28ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe01aeb28ab0
--- trap 0, rip = 0, rsp = 0, rpb = 0 ---
db>

The prior (cross) buildworld buildkernel had completed fine.

Until yesterday, I'd been running -r325700 or before and had not
seen such an issue ever before. I'd been using the virtualbox
version for a while before this as well.

===
Mark Millard
markmi at dsl-only.net

___
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 (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[O. Hartmann]

Am Fri, 14 Apr 2017 20:18:57 +0300
Konstantin Belousov  schrieb:

> On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 02
> > fault virtual address   = 0xf8001282fb00
> > fault code  = supervisor read instruction, protection violation 
> >  
> 
> > ??() at 0xf8001282fb00
> > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
> > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > 0x7fffd6b8,
> > rbp = 0x7fffdcc0 ---  
> 
> You probably have BPF_JITTER option in your kernel config.  Either set
> net.bpf_jitter.enable to 0 for now, or remove the option.
> 
> It is due to r316767. The issue is known and a solution is being discussed.

simply setting "net.bpf_jitter.enable=0" in /boot/loader.conf.local doesn't 
help, the
Trap 12 still occurs.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgppTdkCwNgsL.pgp
Description: OpenPGP digital signature

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[O. Hartmann]

Am Sat, 15 Apr 2017 12:33:34 +0300
Konstantin Belousov  schrieb:

> On Sat, Apr 15, 2017 at 11:18:41AM +0200, O. Hartmann wrote:
> > Am Fri, 14 Apr 2017 20:18:57 +0300
> > Konstantin Belousov  schrieb:
> >   
> > > On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:  
> > > > Fatal trap 12: page fault while in kernel mode
> > > > cpuid = 2; apic id = 02
> > > > fault virtual address   = 0xf8001282fb00
> > > > fault code  = supervisor read instruction, protection 
> > > > violation
> > >   
> > > > ??() at 0xf8001282fb00
> > > > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > > > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > > > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 
> > > > 0xfe012d2af190
> > > > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > > > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > > > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > > > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > > > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > > > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > > > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > > > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > > > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > > > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > > > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > > > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > > > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > > > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > > > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > > > 0x7fffd6b8,
> > > > rbp = 0x7fffdcc0 ---
> > > 
> > > You probably have BPF_JITTER option in your kernel config.  Either set
> > > net.bpf_jitter.enable to 0 for now, or remove the option.
> > > 
> > > It is due to r316767. The issue is known and a solution is being 
> > > discussed.  
> > 
> > simply setting "net.bpf_jitter.enable=0" in /boot/loader.conf.local doesn't 
> > help, the
> > Trap 12 still occurs.  
> 
> It is sysctl, not tunable.

Correct, I didn't/couldn't think that far. Having a setting in /etc/sysctl.conf
accordingly, booting the kernel doesn't reveal the Trap 12 anymore.

Thanks.
Oliver


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp7Iu4sv0Ahq.pgp
Description: OpenPGP digital signature

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[Konstantin Belousov]

On Sat, Apr 15, 2017 at 11:18:41AM +0200, O. Hartmann wrote:
> Am Fri, 14 Apr 2017 20:18:57 +0300
> Konstantin Belousov  schrieb:
> 
> > On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 2; apic id = 02
> > > fault virtual address   = 0xf8001282fb00
> > > fault code  = supervisor read instruction, protection 
> > > violation  
> > 
> > > ??() at 0xf8001282fb00
> > > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
> > > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > > 0x7fffd6b8,
> > > rbp = 0x7fffdcc0 ---  
> > 
> > You probably have BPF_JITTER option in your kernel config.  Either set
> > net.bpf_jitter.enable to 0 for now, or remove the option.
> > 
> > It is due to r316767. The issue is known and a solution is being discussed.
> 
> simply setting "net.bpf_jitter.enable=0" in /boot/loader.conf.local doesn't 
> help, the
> Trap 12 still occurs.

It is sysctl, not tunable.
___
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 (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[O. Hartmann]

Am Fri, 14 Apr 2017 20:18:57 +0300
Konstantin Belousov  schrieb:

> On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 02
> > fault virtual address   = 0xf8001282fb00
> > fault code  = supervisor read instruction, protection violation 
> >  
> 
> > ??() at 0xf8001282fb00
> > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
> > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > 0x7fffd6b8,
> > rbp = 0x7fffdcc0 ---  
> 
> You probably have BPF_JITTER option in your kernel config.  Either set
> net.bpf_jitter.enable to 0 for now, or remove the option.
> 
> It is due to r316767. The issue is known and a solution is being discussed.


Thank you very much.

Indeed, I have.

Regards,

Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpaHRQeH4Vh6.pgp
Description: OpenPGP digital signature

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[Konstantin Belousov]

On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0xf8001282fb00
> fault code  = supervisor read instruction, protection violation

> ??() at 0xf8001282fb00
> bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
> ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> 0x7fffd6b8,
> rbp = 0x7fffdcc0 ---

You probably have BPF_JITTER option in your kernel config.  Either set
net.bpf_jitter.enable to 0 for now, or remove the option.

It is due to r316767. The issue is known and a solution is being discussed.
___
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 (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[O. Hartmann]

Am Fri, 14 Apr 2017 10:02:03 -0600
Alan Somers  schrieb:

> On Fri, Apr 14, 2017 at 9:53 AM, O. Hartmann  wrote:
> > I just updated today CURRENT's tree sources for nanoBSD to r316844 and 
> > recompiled an
> > image I use for an PCengines APU 2C4. The APU now crashes with the error 
> > shown below.
> >
> > r316717 is all right and boots and works as expected.
> >
> > Just now, I depend on the box, so debugging kernel with more info is 
> > underway, but in
> > due time.
> >
> > Kind regards,
> >
> > Oliver
> >
> > [...]
> > uhub2:  on 
> > usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > Link state changed to up
> > igb0: link state changed to UP
> > Link state changed to up
> > igb1: link state changed to UP
> > igb1.100: link state changed to UP
> > igb1.2: link state changed to UP
> > igb1.66: link state changed to UP
> > igb1.111: link state changed to UP
> > igb1.10: link state changed to UP
> > tun0: link state changed to UP
> > link state changed to down
> > igb0: link state changed to DOWN
> > Bump sched buckets to 64 (was 0)
> > Link state changed to up
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0xf80012231600
> > fault code  = supervisor read instruction, protection violation
> > instruction pointer = 0x20:0xf80012231600
> > stack pointer   = 0x28:0xfe012cdc1f58
> > frame pointer   = 0x28:0xfe012cdc1fc0
> > 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 = 941 (syslogd)
> > trap number = 12
> > panic: page fault
> > cpuid = 1
> > time = 1492182471
> > Uptime: 16s
> > PCEngines apu2
> > coreboot build 20160311  
> 
> At a minimum, you need to include a backtrace with a bug report like this.
> 
> -Alan

Just sent a PR:
Bug 218663

and added the backtrace as required:

[...]
Link state changed to up
Kernel page fault with the following non-sleepable locks held:
shared rw bpf interface lock (bpf interface lock) r = 0 (0xf80002ff4028) 
locked
@ /pool/sources/CURRENT/src/sys/net/bpf.c:2206 shared rw udpinp (udpinp) r = 0
(0xf800127f5c98) locked @ 
/pool/sources/CURRENT/src/sys/netinet/udp_usrreq.c:1140
stack backtrace: #0 0x80641960 at witness_debugger+0x70
#1 0x80642d8e at witness_warn+0x45e
#2 0x8096f563 at trap_pfault+0x53
#3 0x8096ed5e at trap+0x24e
#4 0x80952ce3 at calltrap+0x8
#5 0x806fc253 at iflib_txq_drain+0x1383
#6 0x806feda0 at drain_ring_lockless+0xc0
#7 0x806feb6e at ifmp_ring_enqueue+0x32e
#8 0x806fda90 at iflib_if_transmit+0xb0
#9 0x806dfb00 at ether_output+0x730
#10 0x80761ae6 at arprequest+0x426
#11 0x80761f41 at arpresolve_full+0x3d1
#12 0x807621ac at arpresolve+0x10c
#13 0x806df8b1 at ether_output+0x4e1
#14 0x80785c36 at ip_output+0x14e6
#15 0x8080ddd1 at udp_send+0xab1
#16 0x80676c44 at sosend_dgram+0x3e4
#17 0x8067d3a9 at kern_sendit+0x229


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xf8001282fb00
fault code  = supervisor read instruction, protection violation
instruction pointer = 0x20:0xf8001282fb00
stack pointer   = 0x28:0xfe012d2aef48
frame pointer   = 0x28:0xfe012d2aefb0
code segment= base rx0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 941 (syslogd)
[ thread pid 941 tid 100084 ]
Stopped at  0xf8001282fb00
db> bt
Tracing pid 941 tid 100084 td 0xf8000452
??() at 0xf8001282fb00
bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
udp_send() at udp_send+0xab1/frame 0xf

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[Alan Somers]

On Fri, Apr 14, 2017 at 9:53 AM, O. Hartmann  wrote:
> I just updated today CURRENT's tree sources for nanoBSD to r316844 and 
> recompiled an
> image I use for an PCengines APU 2C4. The APU now crashes with the error 
> shown below.
>
> r316717 is all right and boots and works as expected.
>
> Just now, I depend on the box, so debugging kernel with more info is 
> underway, but in due
> time.
>
> Kind regards,
>
> Oliver
>
> [...]
> uhub2:  on 
> usbus1
> uhub2: 4 ports with 4 removable, self powered
> Link state changed to up
> igb0: link state changed to UP
> Link state changed to up
> igb1: link state changed to UP
> igb1.100: link state changed to UP
> igb1.2: link state changed to UP
> igb1.66: link state changed to UP
> igb1.111: link state changed to UP
> igb1.10: link state changed to UP
> tun0: link state changed to UP
> link state changed to down
> igb0: link state changed to DOWN
> Bump sched buckets to 64 (was 0)
> Link state changed to up
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xf80012231600
> fault code  = supervisor read instruction, protection violation
> instruction pointer = 0x20:0xf80012231600
> stack pointer   = 0x28:0xfe012cdc1f58
> frame pointer   = 0x28:0xfe012cdc1fc0
> 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 = 941 (syslogd)
> trap number = 12
> panic: page fault
> cpuid = 1
> time = 1492182471
> Uptime: 16s
> PCEngines apu2
> coreboot build 20160311

At a minimum, you need to include a backtrace with a bug report like this.

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

CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

[O. Hartmann]

I just updated today CURRENT's tree sources for nanoBSD to r316844 and 
recompiled an
image I use for an PCengines APU 2C4. The APU now crashes with the error shown 
below.

r316717 is all right and boots and works as expected.

Just now, I depend on the box, so debugging kernel with more info is underway, 
but in due
time.

Kind regards,

Oliver

[...]
uhub2:  on 
usbus1
uhub2: 4 ports with 4 removable, self powered
Link state changed to up
igb0: link state changed to UP
Link state changed to up
igb1: link state changed to UP
igb1.100: link state changed to UP
igb1.2: link state changed to UP
igb1.66: link state changed to UP
igb1.111: link state changed to UP
igb1.10: link state changed to UP
tun0: link state changed to UP
link state changed to down
igb0: link state changed to DOWN
Bump sched buckets to 64 (was 0)
Link state changed to up


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xf80012231600
fault code  = supervisor read instruction, protection violation
instruction pointer = 0x20:0xf80012231600
stack pointer   = 0x28:0xfe012cdc1f58
frame pointer   = 0x28:0xfe012cdc1fc0
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 = 941 (syslogd)
trap number = 12
panic: page fault
cpuid = 1
time = 1492182471
Uptime: 16s
PCEngines apu2
coreboot build 20160311


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpM3yWLpc82O.pgp
Description: OpenPGP digital signature

Re: Fatal trap 12

[Ivan Klymenko]

On Thu, 23 Jun 2016 16:45:30 +
"Bjoern A. Zeeb"  wrote:

> Hi,
> 
> can you try checking out svn://svn.freebsd.org/base/projects/vnet and 
> see if a kernel from there works better?
> 
> It contains further pf/pflog/pfsync changes; mostly for VIMAGE which 
> will go into head the next days.
> 
> 
> Thanks
> 
> /bz

Update to r302164 - solved problem.
Thanks!
___
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

[Bjoern A. Zeeb]

Hi,

can you try checking out svn://svn.freebsd.org/base/projects/vnet and 
see if a kernel from there works better?


It contains further pf/pflog/pfsync changes; mostly for VIMAGE which 
will go into head the next days.



Thanks

/bz
___
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

[Ivan Klymenko]

On Thu, 23 Jun 2016 10:54:46 +0200
Johan Hendriks  wrote:

> I have the following in my kernel config
> # pf
> options ALTQ
> options ALTQ_CBQ
> options ALTQ_RED
> options ALTQ_RIO
> options ALTQ_HFSC
> options ALTQ_CDNR
> options ALTQ_PRIQ
> device  pf
> device  pflog
> device  pfsync
> 
> I can not alter the order the modules load as far as I know.
> I changed the following in /usr/src/sys/netpfil/pf/if_pflog.c
> 
> from
> 
> DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);
> 
> to
> 
> DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_FIREWALL, SI_ORDER_ANY);
> 
> But after a buildworld the same error.
> 

+1

> Do you compile pflog into the kernel or load it from loader by any 
> chance?   I can see what might happen here.  

Yes, i have kernel options:
device  pf
device  pflog
device  pfsync
ALTQ...

> 
> Can you try to see if this goes away if you load pflog after pf is 
> loaded?   If that helps change the SI_SUB_PSEUDO at the end of 
> sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix 

This does not solve the problem.
___
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

[Johan Hendriks]

I just removed the following from my kernel file

#device  pf
#device  pflog
#device  pfsync

Changed back the SI_SUB_PSEUDO in sys/netpfil/pf/if_pflog.c

Rebuild the kernel and now the kernel is booting normally.

regards

Johan


Op 23/06/16 om 02:01 schreef Bjoern A. Zeeb:
> On 22 Jun 2016, at 17:56, Ivan Klymenko wrote:
>
>> On Wed, 22 Jun 2016 20:45:26 +0300
>> Ivan Klymenko  wrote:
>>
>>> On Wed, 22 Jun 2016 20:36:36 +0300
>>> Ivan Klymenko  wrote:
>>>
 Hello.
 After update from r302000 to r302083 i have panic
 http://i.imgur.com/YfvvhdS.png

 Thanks.
>>> Sorry, the first time discovered a revision  r302060.
>>
>> There is a suspicion that the reason for this commit:
>> https://svnweb.freebsd.org/base?view=revision&revision=302054
>
> Do you compile pflog into the kernel or load it from loader by any
> chance?   I can see what might happen here.
>
> Can you try to see if this goes away if you load pflog after pf is
> loaded?   If that helps change the SI_SUB_PSEUDO at the end of
> sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix it.
>
> /bz
> ___
> 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"

___
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

[Johan Hendriks]

I have the following in my kernel config
# pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
device  pf
device  pflog
device  pfsync

I can not alter the order the modules load as far as I know.
I changed the following in /usr/src/sys/netpfil/pf/if_pflog.c

from

DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);

to

DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_FIREWALL, SI_ORDER_ANY);

But after a buildworld the same error.



Op 23/06/16 om 02:01 schreef Bjoern A. Zeeb:
> On 22 Jun 2016, at 17:56, Ivan Klymenko wrote:
>
>> On Wed, 22 Jun 2016 20:45:26 +0300
>> Ivan Klymenko  wrote:
>>
>>> On Wed, 22 Jun 2016 20:36:36 +0300
>>> Ivan Klymenko  wrote:
>>>
 Hello.
 After update from r302000 to r302083 i have panic
 http://i.imgur.com/YfvvhdS.png

 Thanks.
>>> Sorry, the first time discovered a revision  r302060.
>>
>> There is a suspicion that the reason for this commit:
>> https://svnweb.freebsd.org/base?view=revision&revision=302054
>
> Do you compile pflog into the kernel or load it from loader by any
> chance?   I can see what might happen here.
>
> Can you try to see if this goes away if you load pflog after pf is
> loaded?   If that helps change the SI_SUB_PSEUDO at the end of
> sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix it.
>
> /bz
> ___
> 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"

___
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

[Bjoern A. Zeeb]

On 22 Jun 2016, at 17:56, Ivan Klymenko wrote:


On Wed, 22 Jun 2016 20:45:26 +0300
Ivan Klymenko  wrote:


On Wed, 22 Jun 2016 20:36:36 +0300
Ivan Klymenko  wrote:


Hello.
After update from r302000 to r302083 i have panic
http://i.imgur.com/YfvvhdS.png

Thanks.

Sorry, the first time discovered a revision  r302060.


There is a suspicion that the reason for this commit:
https://svnweb.freebsd.org/base?view=revision&revision=302054


Do you compile pflog into the kernel or load it from loader by any 
chance?   I can see what might happen here.


Can you try to see if this goes away if you load pflog after pf is 
loaded?   If that helps change the SI_SUB_PSEUDO at the end of 
sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix 
it.


/bz
___
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

[Johan Hendriks]

Just a me too.

Build yesterday (revision unclear) and starts fine, today a rebuild and
a panic.
But I do not see the panic message as it reboots right away.
The latest line I see is

atkbd0:  irq 1 on atkbdc0

Then a real quick panic and then it reboots.
I captured it by filming and then pause it before the reboot. ( the
first part is unreadable, but from processor eflags it is the same!
except the 0xf80b values.)
But also 10 lines of KDB stack backtrace: , and 1s uptime.

The old kernel boots fine!

My system uses root on ZFS!

regards
Johan


Op 22/06/16 om 19:36 schreef Ivan Klymenko:
> Hello.
> After update from r302000 to r302083 i have panic
> http://i.imgur.com/YfvvhdS.png
>
> Thanks.
> ___
> 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"

___
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

[Ivan Klymenko]

On Wed, 22 Jun 2016 20:45:26 +0300
Ivan Klymenko  wrote:

> On Wed, 22 Jun 2016 20:36:36 +0300
> Ivan Klymenko  wrote:
> 
> > Hello.
> > After update from r302000 to r302083 i have panic
> > http://i.imgur.com/YfvvhdS.png
> > 
> > Thanks.  
> Sorry, the first time discovered a revision  r302060.

There is a suspicion that the reason for this commit:
https://svnweb.freebsd.org/base?view=revision&revision=302054
___
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

[Ivan Klymenko]

On Wed, 22 Jun 2016 20:36:36 +0300
Ivan Klymenko  wrote:

> Hello.
> After update from r302000 to r302083 i have panic
> http://i.imgur.com/YfvvhdS.png
> 
> Thanks.
Sorry, the first time discovered a revision  r302060.
___
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"

Fatal trap 12

[Ivan Klymenko]

Hello.
After update from r302000 to r302083 i have panic
http://i.imgur.com/YfvvhdS.png

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