From owner-freebsd-hackers@freebsd.org Sun Sep 17 02:22:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFB65E1B276 for ; Sun, 17 Sep 2017 02:22:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A002B6D71D for ; Sun, 17 Sep 2017 02:22:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30844 invoked from network); 17 Sep 2017 02:21:59 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 02:21:59 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Sep 2017 22:21:59 -0400 (EDT) Received: (qmail 18446 invoked from network); 17 Sep 2017 02:21:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 02:21:58 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 2BD81EC86EE; Sat, 16 Sep 2017 19:21:58 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: "APs not started" for failure cases only, possible missing atomic_load_acq_int's? Date: Sat, 16 Sep 2017 19:21:57 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 02:22:02 -0000 [As the following does not flow well from the previous message and stands somewhat on its own in some respects: I top post this.] ffff0000005fb14c adrp x8, ffff000000aaa000 = ffff0000005fb150 add x8, x8, #0x778 ffff0000005fb154 adrp x0, ffff0000006c9000 = ffff0000005fb158 add x0, x0, #0xb8a ffff0000005fb15c stlr w20, [x8] ffff0000005fb160 sev I ran into the following mention of SEV and making sure it is appropriately delayed: > The mechanism that signals an event to other PEs is IMPLEMENTATION = DEFINED. The PE is not required to guarantee the ordering of this event = with respect to the completion of memory accesses by instructions before = the SEV instruction. Therefore, ARM recommends that software includes a = DSB instruction before any SEV instruction. >=20 > The SEVL instruction appears to execute in program order relative to = any subsequent WFE instruction executed on the same PE, without the need = for any explicit insertion of barrier instructions. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Sep-16, at 4:08 PM, Mark Millard wrote: > [Adding a couple of numbers that help > interpret what I found as far as what > specifically did not work as expected.] >=20 > On 2017-Sep-16, at 3:17 PM, Mark Millard wrote: >=20 >> A new finding: >>=20 >> When verbose boot messages are enabled >> there is an earlier contrast between when >> booting works overall vs. when it later >> fails: >>=20 >> When it works: >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> done. >>=20 >> When it fails:=20 >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> APs not started >> done. >>=20 >> And it well explains why ->pc_curthread >> ends up NULL for secondaries (in particular >> cpu =3D=3D 1), init_secondary had never executed >> the assignments show below:=20 >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> The subsystem messages are from: >>=20 >> static void >> release_aps(void *dummy __unused) >> { =20 >> int i; >>=20 >> /* Only release CPUs if they exist */ >> if (mp_ncpus =3D=3D 1) >> return; >>=20 >> intr_pic_ipi_setup(IPI_AST, "ast", ipi_ast, NULL); >> intr_pic_ipi_setup(IPI_PREEMPT, "preempt", ipi_preempt, NULL); >> intr_pic_ipi_setup(IPI_RENDEZVOUS, "rendezvous", = ipi_rendezvous, NULL); >> intr_pic_ipi_setup(IPI_STOP, "stop", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_STOP_HARD, "stop hard", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_HARDCLOCK, "hardclock", ipi_hardclock, = NULL); >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> printf("Release APs\n"); >>=20 >> for (i =3D 0; i < 2000; i++) { >> if (smp_started) >> return; >> DELAY(1000); >> } >>=20 >> printf("APs not started\n"); >> } =20 >> SYSINIT(start_aps, SI_SUB_SMP, SI_ORDER_FIRST, release_aps, NULL); >>=20 >>=20 >> init_secondary has an example or two of not using >> atomic_load_acq_int when atomic_store_rel_int is in >> use. One is: >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> where aps_ready was declared via: >>=20 >> /* Set to 1 once we're ready to let the APs out of the pen. */ >> volatile int aps_ready =3D 0; >>=20 >> where release_aps has the use of atomic_store_rel_int: >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> There is also in init_secondary: >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> where smp_cpus is accessed without being explicitly >> atomic. mp_ncpus seems to have no atomic use at all. >>=20 >> Where: >>=20 >> /usr/src/sys/sys/smp.h:extern int smp_cpus; >> /usr/src/sys/kern/subr_smp.c:int smp_cpus =3D 1; /* how many cpu's = running */ >>=20 >> So no "volatile", unlike the earlier example. >>=20 >> /usr/src/sys/kern/kern_umtx.c: if (smp_cpus > 1) { >> /usr/src/sys/kern/subr_smp.c:SYSCTL_INT(_kern_smp, OID_AUTO, cpus, = CTLFLAG_RD|CTLFLAG_CAPRD, &smp_cpus, 0, >>=20 >> /usr/src/sys/sys/smp.h:extern int mp_ncpus; >> /usr/src/sys/kern/subr_smp.c:int mp_ncpus; >>=20 >>=20 >> The smp_started is not explicitly accessed as atomic >> in release_aps but in init_secondary has its update >> to 1 via: >>=20 >> mtx_lock_spin(&ap_boot_mtx); >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> mtx_unlock_spin(&ap_boot_mtx); >>=20 >> where: >>=20 >> /usr/src/sys/sys/smp.h:extern volatile int smp_started; >> /usr/src/sys/kern/subr_smp.c:volatile int smp_started; >>=20 >> ("volatile" again for this context.) >>=20 >> I'll also note that for the sparc64 architecture >> there is some code like: >>=20 >> if (__predict_false(atomic_load_acq_int(&smp_started) =3D=3D 0)) >>=20 >> that is explicitly matched to the atomic_store_rel_int >> in its mp_machdep.c . >>=20 >> I do not have enough background aarch64 knowledge to >> know if it is provable that atomic_load_acq_int is not >> needed in some of these cases. >>=20 >> But getting "APs not started" at least sometimes >> suggests an intermittent failure of the code as >> it is. >>=20 >>=20 >> Another difference is lack of explicit initialization >> of smp_started but explicit initialization of aps_ready >> and smp_cpus . >>=20 >>=20 >>=20 >> I have no clue if the boot sequence is supposed to >> handle "APs not started" by reverting to not being >> a symmetric multiprocessing boot or some other >> specific way instead of trying to avoiding use of >> what was not initialized by: >>=20 >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> in init_secondary. >=20 >=20 > Example mp_ncpus and smp_cpus figures from a > failed Pine64+ 2GB boot: >=20 > db> print/x *smp_cpus > 1 > db> print/x *mp_ncpus > 138800000004 >=20 > But that should be a 4 byte width. Showing > some context for reference: >=20 > db> x/bx mp_ncpus-4,4=20 > rebooting: 0 0 0 0 > db> x/bx mp_ncpus,4 > mp_ncpus: 4 0 0 0 > db> x/bx mp_ncpus+4,4=20 > scsi_delay: 88 13 0 0 >=20 > For completeness: >=20 > db> x/bx smp_cpus-4,4 > sysctl___kern_smp_disabled+0x5c: 0 0 0 0 > db> x/bx smp_cpus,4 > smp_cpus: 1 0 0 0 > db> x/bx smp_cpus+4,4=20 > smp_cpus+0x4: 0 0 0 0 >=20 > So smp_cpus was not incremented in memory. This > goes along with no occurances of: >=20 > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > updates happening in init_secondary: >=20 > /* Spin until the BSP releases the APs */ > while (!aps_ready) > __asm __volatile("wfe"); >=20 > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; > . . . > mtx_lock_spin(&ap_boot_mtx); >=20 > atomic_add_rel_32(&smp_cpus, 1); >=20 > if (smp_cpus =3D=3D mp_ncpus) { > /* enable IPI's, tlb shootdown, freezes etc */ > atomic_store_rel_int(&smp_started, 1); > } >=20 > mtx_unlock_spin(&ap_boot_mtx); >=20 > Which seems to imply that the aps_ready > update: >=20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > __asm __volatile("sev"); >=20 > in release_aps was not seen in the: >=20 > while (!aps_ready) > __asm __volatile("wfe"); >=20 > in init_secondary. >=20 > My guess is that "while (!aps_ready)" needs > to be explicit about its atomic status. > aps_ready is already volatile but apparently > that is not enough for this context to be > reliable. >=20 > The other potential needs for explicit atomics > are for later execution but may be required > overall as well. From owner-freebsd-hackers@freebsd.org Sun Sep 17 02:48:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D308E1CD04 for ; Sun, 17 Sep 2017 02:48:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1ECCB6E26B for ; Sun, 17 Sep 2017 02:48:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22879 invoked from network); 17 Sep 2017 02:48:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 02:48:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Sep 2017 22:48:04 -0400 (EDT) Received: (qmail 2970 invoked from network); 17 Sep 2017 02:48:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 02:48:04 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B3016EC86EE; Sat, 16 Sep 2017 19:48:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: SOLVED (patch): FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: "APs not started" for failure cases only: solved with patch Date: Sat, 16 Sep 2017 19:48:03 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: Message-Id: <514378CB-4E18-4BA6-B1BF-AEFFAFB7ADED@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 02:48:06 -0000 On 2017-Sep-16, at 7:21 PM, Mark Millard wrote: > [As the following does not flow well from the previous > message and stands somewhat on its own in some respects: > I top post this.] >=20 > ffff0000005fb14c adrp x8, ffff000000aaa000 = > ffff0000005fb150 add x8, x8, #0x778 > ffff0000005fb154 adrp x0, ffff0000006c9000 = > ffff0000005fb158 add x0, x0, #0xb8a > ffff0000005fb15c stlr w20, [x8] > ffff0000005fb160 sev >=20 > I ran into the following mention of SEV and making sure > it is appropriately delayed: >=20 >> The mechanism that signals an event to other PEs is IMPLEMENTATION = DEFINED. The PE is not required to guarantee the ordering of this event = with respect to the completion of memory accesses by instructions before = the SEV instruction. Therefore, ARM recommends that software includes a = DSB instruction before any SEV instruction. >>=20 >> The SEVL instruction appears to execute in program order relative to = any subsequent WFE instruction executed on the same PE, without the need = for any explicit insertion of barrier instructions. The following patch has allowed me to boot the pine64+ 2GB with even a non-debug kernel. # svnlite diff /usr/src/sys/arm64/arm64/mp_machdep.c Index: /usr/src/sys/arm64/arm64/mp_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm64/arm64/mp_machdep.c (revision 323246) +++ /usr/src/sys/arm64/arm64/mp_machdep.c (working copy) @@ -236,7 +236,9 @@ =20 atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ - __asm __volatile("sev"); + __asm __volatile( + "dsb ish \n" + "sev \n"); =20 printf("Release APs\n"); I will add this patch to bugzilla 222234. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Sep-16, at 4:08 PM, Mark Millard wrote: > [Adding a couple of numbers that help > interpret what I found as far as what > specifically did not work as expected.] >=20 > On 2017-Sep-16, at 3:17 PM, Mark Millard wrote: >=20 >> A new finding: >>=20 >> When verbose boot messages are enabled >> there is an earlier contrast between when >> booting works overall vs. when it later >> fails: >>=20 >> When it works: >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> done. >>=20 >> When it fails:=20 >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> APs not started >> done. >>=20 >> And it well explains why ->pc_curthread >> ends up NULL for secondaries (in particular >> cpu =3D=3D 1), init_secondary had never executed >> the assignments show below:=20 >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> The subsystem messages are from: >>=20 >> static void >> release_aps(void *dummy __unused) >> { =20 >> int i; >>=20 >> /* Only release CPUs if they exist */ >> if (mp_ncpus =3D=3D 1) >> return; >>=20 >> intr_pic_ipi_setup(IPI_AST, "ast", ipi_ast, NULL); >> intr_pic_ipi_setup(IPI_PREEMPT, "preempt", ipi_preempt, NULL); >> intr_pic_ipi_setup(IPI_RENDEZVOUS, "rendezvous", ipi_rendezvous, = NULL); >> intr_pic_ipi_setup(IPI_STOP, "stop", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_STOP_HARD, "stop hard", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_HARDCLOCK, "hardclock", ipi_hardclock, = NULL); >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> printf("Release APs\n"); >>=20 >> for (i =3D 0; i < 2000; i++) { >> if (smp_started) >> return; >> DELAY(1000); >> } >>=20 >> printf("APs not started\n"); >> } =20 >> SYSINIT(start_aps, SI_SUB_SMP, SI_ORDER_FIRST, release_aps, NULL); >>=20 >>=20 >> init_secondary has an example or two of not using >> atomic_load_acq_int when atomic_store_rel_int is in >> use. One is: >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> where aps_ready was declared via: >>=20 >> /* Set to 1 once we're ready to let the APs out of the pen. */ >> volatile int aps_ready =3D 0; >>=20 >> where release_aps has the use of atomic_store_rel_int: >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> There is also in init_secondary: >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> where smp_cpus is accessed without being explicitly >> atomic. mp_ncpus seems to have no atomic use at all. >>=20 >> Where: >>=20 >> /usr/src/sys/sys/smp.h:extern int smp_cpus; >> /usr/src/sys/kern/subr_smp.c:int smp_cpus =3D 1; /* how many cpu's = running */ >>=20 >> So no "volatile", unlike the earlier example. >>=20 >> /usr/src/sys/kern/kern_umtx.c: if (smp_cpus > 1) { >> /usr/src/sys/kern/subr_smp.c:SYSCTL_INT(_kern_smp, OID_AUTO, cpus, = CTLFLAG_RD|CTLFLAG_CAPRD, &smp_cpus, 0, >>=20 >> /usr/src/sys/sys/smp.h:extern int mp_ncpus; >> /usr/src/sys/kern/subr_smp.c:int mp_ncpus; >>=20 >>=20 >> The smp_started is not explicitly accessed as atomic >> in release_aps but in init_secondary has its update >> to 1 via: >>=20 >> mtx_lock_spin(&ap_boot_mtx); >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> mtx_unlock_spin(&ap_boot_mtx); >>=20 >> where: >>=20 >> /usr/src/sys/sys/smp.h:extern volatile int smp_started; >> /usr/src/sys/kern/subr_smp.c:volatile int smp_started; >>=20 >> ("volatile" again for this context.) >>=20 >> I'll also note that for the sparc64 architecture >> there is some code like: >>=20 >> if (__predict_false(atomic_load_acq_int(&smp_started) =3D=3D 0)) >>=20 >> that is explicitly matched to the atomic_store_rel_int >> in its mp_machdep.c . >>=20 >> I do not have enough background aarch64 knowledge to >> know if it is provable that atomic_load_acq_int is not >> needed in some of these cases. >>=20 >> But getting "APs not started" at least sometimes >> suggests an intermittent failure of the code as >> it is. >>=20 >>=20 >> Another difference is lack of explicit initialization >> of smp_started but explicit initialization of aps_ready >> and smp_cpus . >>=20 >>=20 >>=20 >> I have no clue if the boot sequence is supposed to >> handle "APs not started" by reverting to not being >> a symmetric multiprocessing boot or some other >> specific way instead of trying to avoiding use of >> what was not initialized by: >>=20 >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> in init_secondary. >=20 >=20 > Example mp_ncpus and smp_cpus figures from a > failed Pine64+ 2GB boot: >=20 > db> print/x *smp_cpus > 1 > db> print/x *mp_ncpus > 138800000004 >=20 > But that should be a 4 byte width. Showing > some context for reference: >=20 > db> x/bx mp_ncpus-4,4=20 > rebooting: 0 0 0 0 > db> x/bx mp_ncpus,4 > mp_ncpus: 4 0 0 0 > db> x/bx mp_ncpus+4,4=20 > scsi_delay: 88 13 0 0 >=20 > For completeness: >=20 > db> x/bx smp_cpus-4,4 > sysctl___kern_smp_disabled+0x5c: 0 0 0 0 > db> x/bx smp_cpus,4 > smp_cpus: 1 0 0 0 > db> x/bx smp_cpus+4,4=20 > smp_cpus+0x4: 0 0 0 0 >=20 > So smp_cpus was not incremented in memory. This > goes along with no occurances of: >=20 > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > updates happening in init_secondary: >=20 > /* Spin until the BSP releases the APs */ > while (!aps_ready) > __asm __volatile("wfe"); >=20 > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; > . . . > mtx_lock_spin(&ap_boot_mtx); >=20 > atomic_add_rel_32(&smp_cpus, 1); >=20 > if (smp_cpus =3D=3D mp_ncpus) { > /* enable IPI's, tlb shootdown, freezes etc */ > atomic_store_rel_int(&smp_started, 1); > } >=20 > mtx_unlock_spin(&ap_boot_mtx); >=20 > Which seems to imply that the aps_ready > update: >=20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > __asm __volatile("sev"); >=20 > in release_aps was not seen in the: >=20 > while (!aps_ready) > __asm __volatile("wfe"); >=20 > in init_secondary. >=20 > My guess is that "while (!aps_ready)" needs > to be explicit about its atomic status. > aps_ready is already volatile but apparently > that is not enough for this context to be > reliable. >=20 > The other potential needs for explicit atomics > are for later execution but may be required > overall as well. From owner-freebsd-hackers@freebsd.org Sun Sep 17 19:08:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24B89E25437 for ; Sun, 17 Sep 2017 19:08:17 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5B1D69ECD for ; Sun, 17 Sep 2017 19:08:16 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sun, 17 Sep 2017 21:07:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1505675285; bh=NMrRhLFCGzXtg1yZUAN05tWg/eWJfaLR0xSPLfCtQcY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aegOMZhAMfwPeM1YfaY5D/fQWzqUsj2hyEqGtPOBo5hhsYKh946fUVj4wXZVMEV1E wNvP2YY/Iy9DgIsSnadZnrj4h3dx8NdDQ81P0fWtyVqFxRrWpV6PV/RrmHlDvPjBuy x5YlaeSMV+6YQPYuFyccgECo/gdyGqiL1ZQlommHLMaNKCDI7g6KaTMX+890yIK6ww TfR4A0kvFydzpHgB0xSjQoDL/P3RK/9SfTzVr7DNAjZkgy121aSfvOorcZlQ4FrbNc Lv9Qt1hwjKQYeZ/DfejHQYRf5LXnQTDz2BTcVOTMnTJplif5V1F7inGmbrTDz5vflo lnEg41vqfDwew== Message-ID: <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> From: Alexander Leidinger To: Giulio Ferro Cc: freebsd-hackers@freebsd.org Subject: Re: devd in jail References: <20170810225439.Horde.1s8Qi_dlNtxgEigsNKbdrer@webmail.leidinger.net> <4a1a99a5-35ea-19c9-7ac8-77875ac6f71f@zirakzigil.org> <20170905151537.Horde.10cHNOX1OVri7mGaUcDeX1l@webmail.leidinger.net> <7ca865ee-b613-2f0c-daf0-d828884b5e74@zirakzigil.org> <1C181EF2-B8B1-4F42-BF80-ABEA0593DD43@dsl-only.net> <20170906122556.Horde.5OdDwtii7HXPNArY77YUyBi@webmail.leidinger.net> <20170906221947.Horde.RITHvdc1wVE9v0-3nBavR0Z@webmail.leidinger.net> <20170909150335.Horde.wBLIPwBuhV3lyQlBxKud39f@webmail.leidinger.net> <27e72cfb-54cf-4af8-b569-85fff089c45f@zirakzigil.org> <20170911161253.Horde.vawLu00EtbbHOVeJRXjp7N0@webmail.leidinger.net> <3236AD55-0D14-49A5-B5B9-3147A216D8A5@zirakzigil.org> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_m-3PkU99TW-_5ipOmna_WVb"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 18 Sep 2017 02:31:55 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 19:08:17 -0000 This message is in MIME format and has been PGP signed. --=_m-3PkU99TW-_5ipOmna_WVb Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Giulio Ferro (from Thu, 14 Sep 2017=20=20 09:23:31=20+0200): > Hi Alexander and all, > > Do you have any idea why putting the new patches parameter in=20=20 >=20jail.conf fails and how it can be solved? I can do test on this=20=20 >=20machine as you wish. I have no idea why it fails. The old way of doing it via rc.conf is: jail_JAILNAME_parameters=3D"allow.kmem_access" Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_m-3PkU99TW-_5ipOmna_WVb Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJZvsf3AAoJEKrxQhqFIICEbrsP/RbE+hetKyXfL6EKCqD0Y0PZ H+22Kqkr3bUgxnNRu5NETtoteqUT96ISCV8e1kNMlwh/ud6rAvxWWn4NhP/Pm+Aw OBWU5pTRXxC84tz+vcCmW5vjNS8Zf6mQGK+Ya88YK1DqU199BnbTpC/XIZCxWVob qZ2/smod5U9fMHN90KEHMVyZ7YdzjSfVHkjDYrJKbUKmOEEyASZFRxPhVlMASaIU vAa+IoTfzLyo9+A/CiZyPslV9Xirsc4mOA66OS/A9s6pAWfxOfcALIoIEoKen2Sg O0YbKZGBZZHTcmk2N8bjFnsDfBOPns2rcoWLtHWFdCUtxzPMVTvQe3/AHHBmSeNK GYMKgrkpl/pjQRLXPF1UbnlC6PGLfStooglPl8HOPO2aD3mHw0eZLEABkWdKcfBe P/ri3Wu3t45a/LwbzdUoVs+wBDA0zYMDIsxDFQ1uxITM9+yAvaneOWFpUeOkn2uq 9TWx4Jc6iXs2rybwSVhLacN+CgBvXb5Eo/kyDNuegsokzYoktNJfR+BWEz/qGETH 0g4cADAb5jwdjAP+WBu/OrNT2dTaN9is5FypvPMz9VHCh+aizr8FY411nyDjPURz whGnBr9X7GY4S/uqcC1i945wcHK54sezE7FMXWTqlNDyKUxTaubNmiOIKf2RNIA0 LHhHIBcSr1MPWgDopAtB =Eg5h -----END PGP SIGNATURE----- --=_m-3PkU99TW-_5ipOmna_WVb-- From owner-freebsd-hackers@freebsd.org Mon Sep 18 06:49:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 924EEE24097 for ; Mon, 18 Sep 2017 06:49:40 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.etoilesoft.fr (mx1.etoilesoft.fr [52.57.51.18]) by mx1.freebsd.org (Postfix) with ESMTP id 54D2181C2A for ; Mon, 18 Sep 2017 06:49:39 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.etoilesoft.fr (localhost [127.0.0.1]) by mx1.etoilesoft.fr (Postfix) with ESMTP id 1CC6F9C946; Mon, 18 Sep 2017 06:50:42 +0000 (UTC) Received: from [192.168.43.173] (localhost [127.0.0.1]) (Authenticated sender: auryn@zirakzigil.org) by mx1.etoilesoft.fr (Postfix) with ESMTPA id CD2CD9C945; Mon, 18 Sep 2017 06:50:41 +0000 (UTC) Subject: Re: devd in jail To: freebsd-hackers@freebsd.org, Alexander@leidinger.net References: <4a1a99a5-35ea-19c9-7ac8-77875ac6f71f@zirakzigil.org> <20170905151537.Horde.10cHNOX1OVri7mGaUcDeX1l@webmail.leidinger.net> <7ca865ee-b613-2f0c-daf0-d828884b5e74@zirakzigil.org> <1C181EF2-B8B1-4F42-BF80-ABEA0593DD43@dsl-only.net> <20170906122556.Horde.5OdDwtii7HXPNArY77YUyBi@webmail.leidinger.net> <20170906221947.Horde.RITHvdc1wVE9v0-3nBavR0Z@webmail.leidinger.net> <20170909150335.Horde.wBLIPwBuhV3lyQlBxKud39f@webmail.leidinger.net> <27e72cfb-54cf-4af8-b569-85fff089c45f@zirakzigil.org> <20170911161253.Horde.vawLu00EtbbHOVeJRXjp7N0@webmail.leidinger.net> <3236AD55-0D14-49A5-B5B9-3147A216D8A5@zirakzigil.org> <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> From: Giulio Ferro Message-ID: Date: Mon, 18 Sep 2017 08:49:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 06:49:40 -0000 On 17/09/2017 21:07, Alexander Leidinger wrote: > Quoting Giulio Ferro (from Thu, 14 Sep 2017 > 09:23:31 +0200): > >> Hi Alexander and all, >> >> Do you have any idea why putting the new patches parameter in >> jail.conf fails and how it can be solved? I can do test on this >> machine as you wish. > > I have no idea why it fails. > > The old way of doing it via rc.conf is: > jail_JAILNAME_parameters="allow.kmem_access" > > Bye, > Alexander. > Hi Alexander, nope, even the old way I get: jail: xxx: unknown parameter: allow.kmem_access Has anyone else tried this in 11.1 stable? From owner-freebsd-hackers@freebsd.org Mon Sep 18 14:29:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58547E144ED for ; Mon, 18 Sep 2017 14:29:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD9B56B4CC for ; Mon, 18 Sep 2017 14:29:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v8IESnYA020453 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Sep 2017 16:28:50 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: superbisquit@gmail.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id v8IEShsA050300; Mon, 18 Sep 2017 21:28:43 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: required kernel rebuilds To: Joe Nosay , FreeBSD Hackers References: <20170913155542.GA25871@mail.michaelwlucas.com> <59B9BE8D.5050807@grosbein.net> From: Eugene Grosbein Message-ID: <59BFD81B.8060003@grosbein.net> Date: Mon, 18 Sep 2017 21:28:43 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, score=5.5 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 3.3 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Flag: YES X-Spam-Level: ***** X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 14:29:01 -0000 On 18.09.2017 02:39, Joe Nosay wrote: > Most of you do not program on RISC platforms. Most of people do not program altogether. It is about running FreeBSD, not programming, is it? From owner-freebsd-hackers@freebsd.org Mon Sep 18 13:32:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5858CE10942 for ; Mon, 18 Sep 2017 13:32:38 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0633268B73 for ; Mon, 18 Sep 2017 13:32:38 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Mon, 18 Sep 2017 15:32:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1505741555; bh=T2tfSNgOegCF1an3A0ycmLUZFqcL2owOpY93E39Y7Vg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=BQq6VHDcmZFvuyC5F2AJobl8UilXYXJ+hucroZS54yHwlbzg3mESvY0591TNKE4lS 4KH+lVpV1fyLdRHuBwYwGTsJjnZCwhp66R7uQR+Z1UZRJTrNd9phZdz6JzlHg6XvCt /poikZr0kFXhDYny5Hv9pJeGSHDvpFnVyP5Hnvz9ZEkmYUPT8c3kImEyn+y0jizAMz i5A/9i7mOm4UjFbA1tCj8SlijsDg+T+rZoEA7TJyowXUQicMewToCYrbgnsNkvut0c HF+EpTgclIjUuaExYc7TO2/SofC3PGdGR7mtsHPG8O7DqijNG8CVkph3hA5j2c7pjZ eOfXZnARfZ01g== Message-ID: <20170918153212.Horde.reuh2WwJotWq2qHgpHwvnNq@webmail.leidinger.net> From: Alexander Leidinger To: Giulio Ferro Cc: freebsd-hackers@freebsd.org Subject: Re: devd in jail References: <4a1a99a5-35ea-19c9-7ac8-77875ac6f71f@zirakzigil.org> <20170905151537.Horde.10cHNOX1OVri7mGaUcDeX1l@webmail.leidinger.net> <7ca865ee-b613-2f0c-daf0-d828884b5e74@zirakzigil.org> <1C181EF2-B8B1-4F42-BF80-ABEA0593DD43@dsl-only.net> <20170906122556.Horde.5OdDwtii7HXPNArY77YUyBi@webmail.leidinger.net> <20170906221947.Horde.RITHvdc1wVE9v0-3nBavR0Z@webmail.leidinger.net> <20170909150335.Horde.wBLIPwBuhV3lyQlBxKud39f@webmail.leidinger.net> <27e72cfb-54cf-4af8-b569-85fff089c45f@zirakzigil.org> <20170911161253.Horde.vawLu00EtbbHOVeJRXjp7N0@webmail.leidinger.net> <3236AD55-0D14-49A5-B5B9-3147A216D8A5@zirakzigil.org> <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_7eXKBp8FFURc-MFKYqZEmFE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 18 Sep 2017 16:00:46 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 13:32:38 -0000 This message is in MIME format and has been PGP signed. --=_7eXKBp8FFURc-MFKYqZEmFE Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Giulio Ferro (from Mon, 18 Sep 2017=20=20 08:49:32=20+0200): > nope, even the old way I get: > > jail: xxx: unknown parameter: allow.kmem_access > > > Has anyone else tried this in 11.1 stable? As I'm creating the diff vs. 11.1 just for you: no. Here an updated change (thanks to jamie@ for the cluebat). It's a full=20= =20 patch=20vs 11.1. =20=20=20=20=20=20 http://www.Leidinger.net/FreeBSD/current-patches/x11_in_jail_releng_11_1.di= ff The=20difference of what you have already are two lines: ---snip--- Index: sys/kern/kern_jail.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_jail.c (revision 323230) +++ sys/kern/kern_jail.c (working copy) @@ -3788,6 +3806,8 @@ "B", "Jail may set file quotas"); SYSCTL_JAIL_PARAM(_allow, socket_af, CTLTYPE_INT | CTLFLAG_RW, "B", "Jail may create sockets other than just UNIX/IPv4/IPv6/route"); +SYSCTL_JAIL_PARAM(_allow, kmem_access, CTLTYPE_INT | CTLFLAG_RW, + "B", "Jail may access kmem-like devices (io, dri) if they exist"); SYSCTL_JAIL_PARAM_SUBNODE(allow, mount, "Jail mount/unmount=20=20 permission=20flags"); SYSCTL_JAIL_PARAM(_allow_mount, , CTLTYPE_INT | CTLFLAG_RW, ---snip--- I have validated this in -current, this is the missing piece. When=20=20 this=20is in the kernel, you should see kmem_access in the output of sysctl security.jail.param.allow This should then work with the jail.conf (and rc.conf) way of=20=20 configuring a jail. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_7eXKBp8FFURc-MFKYqZEmFE Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJZv8rcAAoJEKrxQhqFIICEE7sQAIBJ3xRG8b1xiPdfNkUfpRJ5 QzhgDiHtROIxBot8wJkIY0Gqtjicwrv67lXAILxoD3wG6AtTZq19eThTps+2Gr53 t3LhSHC+3RyOITiuoIB6ERrEjF54h80u59ke7ciE2F19vgii01Cx4BI1gte+s+ZC h+NJGLyLZXDssyVekGU4XdVgcfNcnSS7EUBI4fDaa35vrs9MTSb2fEVeBBsdhlTA n9jWfvmSHb3FpV9NUmmK6+6hj2m5fQVHeEdFuCSZLxV4c9i8m2mdmqmLwvk0o0z4 JRQ66UxDqRods3QhkhAwlQB+Qp7oatioZCvyuN34bFWt3vdhaC5N2BEb80JVCTel B/Ji0qSs2MdqtxwKKZP/LdK/ptmBJay4RLQjMbI6jULKAPaRg+sKBEiWB66IY3mH yrlW9VhCdelAeXfihKwQ2AcVBOmGs1Uu37H41lIO0HfXSs3r+XhATzinmz8127oA zv/tupLSkCkZdq5eJ+KHbJC9hM6qFi7B/iUTlW4mPg7Qsgs7+CreMnt4tHfWVqAp 5/UFdYBVinTjfDTuB2+PrZvD/3WZdlfBBDe/wgOI/uWDJIYl4X86tBF9D7JcRX7N amSrC7Okx+Fz2WRSGJzquHWKcwQdKQsFqqpcK0wmY0IctiVQKVNgvqKDnIkY3qE9 6MM1PqXtqDmCYDDIfYia =0efs -----END PGP SIGNATURE----- --=_7eXKBp8FFURc-MFKYqZEmFE-- From owner-freebsd-hackers@freebsd.org Wed Sep 20 04:29:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DFF8E1FA60 for ; Wed, 20 Sep 2017 04:29:03 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.etoilesoft.fr (mx1.etoilesoft.fr [52.57.51.18]) by mx1.freebsd.org (Postfix) with ESMTP id F1D797E71A for ; Wed, 20 Sep 2017 04:29:02 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.etoilesoft.fr (localhost [127.0.0.1]) by mx1.etoilesoft.fr (Postfix) with ESMTP id 5F18E9D1A6; Wed, 20 Sep 2017 04:30:08 +0000 (UTC) Received: from [172.25.55.86] (localhost [127.0.0.1]) (Authenticated sender: auryn@zirakzigil.org) by mx1.etoilesoft.fr (Postfix) with ESMTPA id EBA729C944; Wed, 20 Sep 2017 04:30:07 +0000 (UTC) From: Giulio Ferro Subject: Re: devd in jail To: Alexander Leidinger , freebsd-hackers@freebsd.org References: <7ca865ee-b613-2f0c-daf0-d828884b5e74@zirakzigil.org> <1C181EF2-B8B1-4F42-BF80-ABEA0593DD43@dsl-only.net> <20170906122556.Horde.5OdDwtii7HXPNArY77YUyBi@webmail.leidinger.net> <20170906221947.Horde.RITHvdc1wVE9v0-3nBavR0Z@webmail.leidinger.net> <20170909150335.Horde.wBLIPwBuhV3lyQlBxKud39f@webmail.leidinger.net> <27e72cfb-54cf-4af8-b569-85fff089c45f@zirakzigil.org> <20170911161253.Horde.vawLu00EtbbHOVeJRXjp7N0@webmail.leidinger.net> <3236AD55-0D14-49A5-B5B9-3147A216D8A5@zirakzigil.org> <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> <20170918153212.Horde.reuh2WwJotWq2qHgpHwvnNq@webmail.leidinger.net> Message-ID: Date: Wed, 20 Sep 2017 06:28:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170918153212.Horde.reuh2WwJotWq2qHgpHwvnNq@webmail.leidinger.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 04:29:03 -0000 Ok, I'm progressing :) I've patched, built and installed the new kernel. Now I can start the jail with the new parameter. Unfortunately Xorg still fails to start... :( Here's my setup: /etc/rc.conf.local ----------------------------------------------------------------------- ... jail_enable="YES" ... ----------------------------------------------------------------------- /etc/jail.conf ----------------------------------------------------------------------- exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.clean; mount.devfs; devfs_ruleset=1; path = "/usr/home/jails/$name"; xxx { host.hostname = "xxx.xxx.xxx"; vnet; vnet.interface = epair0b, epair1b; allow.kmem_access = "true"; persist; } ----------------------------------------------------------------------- /etc/devfs.rules ----------------------------------------------------------------------- [devfsrules_jail=1] add path pf unhide add path kmem unhide add path io unhide add path mem unhide add path pci unhide add path tty unhide add path ttyv0 unhide add path ttyv1 unhide add path ttyv8 unhide ----------------------------------------------------------------------- Now I can start the jail with /etc/rc.d/jail start The jail seems ok. Here's its /dev directory: ----------------------------------------------------------------------- # ls -l total 3 crw-r--r-- 1 root wheel 0x27 Sep 20 04:05 acpi crw-r----- 1 root operator 0x3e Sep 20 04:05 ada0 crw-r----- 1 root operator 0x3f Sep 20 04:05 ada0p1 crw-r----- 1 root operator 0x40 Sep 20 04:05 ada0p2 crw-rw-r-- 1 root operator 0x29 Sep 20 04:05 apm crw-rw---- 1 root operator 0x28 Sep 20 04:05 apmctl crw------- 1 root wheel 0x2b Sep 20 04:05 atkbd0 crw------- 1 root kmem 0x1c Sep 20 04:05 audit crw------- 1 root wheel 0x1b Sep 20 04:05 auditpipe crw------- 1 root wheel 0xd Sep 20 04:08 bpf lrwxr-xr-x 1 root wheel 3 Sep 20 04:09 bpf0 -> bpf crw-rw-rw- 1 root wheel 0x2e Sep 20 04:05 bpsm0 crw------- 1 root wheel 0xa Sep 20 04:16 console crw------- 1 root wheel 0xf Sep 20 04:05 consolectl crw-rw-rw- 1 root wheel 0xc Sep 20 04:05 ctty crw-rw---- 1 uucp dialer 0x32 Sep 20 04:05 cuau0 crw-rw---- 1 uucp dialer 0x33 Sep 20 04:05 cuau0.init crw-rw---- 1 uucp dialer 0x34 Sep 20 04:05 cuau0.lock crw------- 1 root wheel 0x4 Sep 20 04:05 devctl crw------- 1 root wheel 0x5 Sep 20 04:05 devctl2 cr--r--r-- 1 root wheel 0x3d Sep 20 04:05 devstat dr-xr-xr-x 2 root wheel 512 Sep 20 04:09 fd crw------- 1 root wheel 0x11 Sep 20 04:05 fido crw-rw-rw- 1 root wheel 0x18 Sep 20 04:05 full crw-r----- 1 root operator 0x6 Sep 20 04:05 geom.ctl dr-xr-xr-x 2 root wheel 512 Sep 20 04:09 gpt dr-xr-xr-x 2 root wheel 512 Sep 20 04:09 gptid crw-r--r-- 1 root wheel 0x2a Sep 20 04:05 hpet0 crw------- 1 root wheel 0x24 Sep 20 04:05 io lrwxr-xr-x 1 root wheel 6 Sep 20 04:09 kbd0 -> atkbd0 lrwxr-xr-x 1 root wheel 7 Sep 20 04:09 kbd1 -> kbdmux0 crw------- 1 root wheel 0x12 Sep 20 04:05 kbdmux0 crw------- 1 root wheel 0x25 Sep 20 04:05 klog crw-r----- 1 root kmem 0x15 Sep 20 04:05 kmem crw------- 1 root wheel 0xb Sep 20 04:05 mdctl crw-r----- 1 root kmem 0x14 Sep 20 04:05 mem crw-rw-rw- 1 root wheel 0x26 Sep 20 04:05 midistat crw------- 1 root wheel 0x17 Sep 20 04:05 netmap crw------- 1 root kmem 0x16 Sep 20 04:05 nfslock crw-rw-rw- 1 root wheel 0x19 Sep 20 04:17 null crw-r--r-- 1 root wheel 0x23 Sep 20 04:05 pci crw------- 1 root wheel 0x45 Sep 20 04:09 pf crw-rw-rw- 1 root wheel 0x2d Sep 20 04:05 psm0 dr-xr-xr-x 2 root wheel 512 Sep 20 04:10 pts crw-r--r-- 1 root wheel 0x8 Sep 20 04:05 random dr-xr-xr-x 2 root wheel 512 Sep 20 04:09 reroot crw-r--r-- 1 root wheel 0x7 Sep 20 04:05 sndstat lrwxr-xr-x 1 root wheel 4 Sep 20 04:09 stderr -> fd/2 lrwxr-xr-x 1 root wheel 4 Sep 20 04:09 stdin -> fd/0 lrwxr-xr-x 1 root wheel 4 Sep 20 04:09 stdout -> fd/1 crw------- 1 root wheel 0x10 Sep 20 04:05 sysmouse crw------- 1 root wheel 0x44 Sep 20 04:05 tap0 crw------- 1 root wheel 0x2f Sep 20 04:11 ttyu0 crw------- 1 root wheel 0x30 Sep 20 04:05 ttyu0.init crw------- 1 root wheel 0x31 Sep 20 04:05 ttyu0.lock crw------- 1 root wheel 0x47 Sep 20 04:11 ttyv0 crw------- 1 root wheel 0x48 Sep 20 04:11 ttyv1 crw------- 1 root wheel 0x49 Sep 20 04:11 ttyv2 crw------- 1 root wheel 0x4a Sep 20 04:11 ttyv3 crw------- 1 root wheel 0x4b Sep 20 04:11 ttyv4 crw------- 1 root wheel 0x4c Sep 20 04:11 ttyv5 crw------- 1 root wheel 0x4d Sep 20 04:11 ttyv6 crw------- 1 root wheel 0x4e Sep 20 04:11 ttyv7 crw------- 1 root wheel 0x4f Sep 20 04:05 ttyv8 crw------- 1 root wheel 0x50 Sep 20 04:05 ttyv9 crw------- 1 root wheel 0x51 Sep 20 04:05 ttyva crw------- 1 root wheel 0x52 Sep 20 04:05 ttyvb crw------- 1 root wheel 0x37 Sep 20 04:05 ufssuspend lrwxr-xr-x 1 root wheel 6 Sep 20 04:09 urandom -> random crw-r--r-- 1 root operator 0x3a Sep 20 04:05 usbctl dr-xr-xr-x 2 root wheel 512 Sep 20 04:09 xen crw------- 1 root operator 0x3b Sep 20 04:05 xpt0 crw-rw-rw- 1 root wheel 0x1a Sep 20 04:05 zero ----------------------------------------------------------------------- Here's the xorg.conf (automatically created by xrdp) ----------------------------------------------------------------------- # cat xorg.conf Section "ServerLayout" Identifier "X11 Server" Screen "Screen (xrdpdev)" InputDevice "xrdpMouse" "CorePointer" InputDevice "xrdpKeyboard" "CoreKeyboard" EndSection Section "ServerFlags" Option "DontVTSwitch" "on" Option "AutoAddDevices" "off" EndSection Section "Module" Load "dbe" Load "ddc" Load "extmod" Load "glx" Load "int10" Load "record" Load "vbe" Load "xorgxrdp" Load "fb" EndSection Section "InputDevice" Identifier "xrdpKeyboard" Driver "xrdpkeyb" EndSection Section "InputDevice" Identifier "xrdpMouse" Driver "xrdpmouse" EndSection Section "Monitor" Identifier "Monitor" Option "DPMS" HorizSync 30-80 VertRefresh 60-75 ModeLine "1920x1080" 138.500 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync ModeLine "1280x720" 74.25 1280 1720 1760 1980 720 725 730 750 +HSync +VSync Modeline "1368x768" 72.25 1368 1416 1448 1528 768 771 781 790 +hsync -vsync Modeline "1600x900" 119.00 1600 1696 1864 2128 900 901 904 932 -hsync +vsync EndSection Section "Device" Identifier "Video Card (xrdpdev)" Driver "xrdpdev" EndSection Section "Screen" Identifier "Screen (xrdpdev)" Device "Video Card (xrdpdev)" Monitor "Monitor" DefaultDepth 24 SubSection "Display" Depth 24 Modes "640x480" "800x600" "1024x768" "1280x720" "1280x1024" "1600x900" "1920x1080" EndSubSection EndSection ----------------------------------------------------------------------- I can start xrdp with its sesman. But when xorg is launched, I still have errors... Here the X log: ----------------------------------------------------------------------- # cat Xorg.13.log [ 5629.107] X.Org X Server 1.18.4 Release Date: 2016-07-19 [ 5629.107] X Protocol Version 11, Revision 0 [ 5629.107] Build Operating System: FreeBSD 11.0-RELEASE-p12 amd64 [ 5629.107] Current Operating System: FreeBSD xxx.xxx.xxx 11.1-STABLE FreeBSD 11.1-STABLE #2 r323738M: Tue Sep 19 08:47:53 UTC 2017 root@xxxhost.xxx.xxx:/usr/obj/usr/src/sys/XXXSRV amd64 [ 5629.107] Build Date: 12 September 2017 08:39:56AM [ 5629.107] [ 5629.107] Current version of pixman: 0.34.0 [ 5629.107] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 5629.107] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 5629.107] (==) Log file: "/var/log/Xorg.13.log", Time: Tue Sep 19 11:31:20 2017 [ 5629.108] (++) Using config file: "/etc/X11/xrdp/xorg.conf" [ 5629.108] (==) ServerLayout "X11 Server" [ 5629.108] (**) |-->Screen "Screen (xrdpdev)" (0) [ 5629.108] (**) | |-->Monitor "Monitor" [ 5629.108] (**) | |-->Device "Video Card (xrdpdev)" [ 5629.108] (**) |-->Input Device "xrdpMouse" [ 5629.108] (**) |-->Input Device "xrdpKeyboard" [ 5629.108] (**) Option "DontVTSwitch" "on" [ 5629.108] (**) Option "AutoAddDevices" "off" [ 5629.108] (**) Not automatically adding devices [ 5629.108] (==) Automatically enabling devices [ 5629.108] (==) Not automatically adding GPU devices [ 5629.108] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 5629.108] (WW) The directory "/usr/local/share/fonts/misc/" does not exist. [ 5629.108] Entry deleted from font path. [ 5629.108] (WW) The directory "/usr/local/share/fonts/TTF/" does not exist. [ 5629.108] Entry deleted from font path. [ 5629.108] (WW) The directory "/usr/local/share/fonts/OTF/" does not exist. [ 5629.108] Entry deleted from font path. [ 5629.108] (WW) The directory "/usr/local/share/fonts/Type1/" does not exist. [ 5629.108] Entry deleted from font path. [ 5629.108] (WW) The directory "/usr/local/share/fonts/100dpi/" does not exist. [ 5629.108] Entry deleted from font path. [ 5629.108] (WW) The directory "/usr/local/share/fonts/75dpi/" does not exist. [ 5629.108] Entry deleted from font path. [ 5629.108] (==) FontPath set to: [ 5629.108] (==) ModulePath set to "/usr/local/lib/xorg/modules" [ 5629.108] (II) Loader magic: 0x813b70 [ 5629.108] (II) Module ABI versions: [ 5629.108] X.Org ANSI C Emulation: 0.4 [ 5629.108] X.Org Video Driver: 20.0 [ 5629.108] X.Org XInput driver : 22.1 [ 5629.108] X.Org Server Extension : 9.0 [ 5629.108] (WW) checkDevMem: failed to open /dev/mem (Operation not permitted) [ 5629.108] (--) PCI:*(0:0:2:0) 1013:00b8:5853:0001 rev 0, Mem @ 0xf0000000/33554432, 0xf3000000/4096, BIOS @ 0x????????/65536 [ 5629.108] (II) "glx" will be loaded. This was enabled by default and also specified in the config file. [ 5629.108] (II) LoadModule: "dbe" [ 5629.108] (II) Module "dbe" already built-in [ 5629.108] (II) LoadModule: "ddc" [ 5629.108] (II) Module "ddc" already built-in [ 5629.108] (II) LoadModule: "extmod" [ 5629.108] (II) Module "extmod" already built-in [ 5629.108] (II) LoadModule: "glx" [ 5629.108] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 5629.109] (II) Module glx: vendor="X.Org Foundation" [ 5629.109] compiled for 1.18.4, module version = 1.0.0 [ 5629.109] ABI class: X.Org Server Extension, version 9.0 [ 5629.109] (==) AIGLX enabled [ 5629.109] (II) LoadModule: "int10" [ 5629.109] (II) Loading /usr/local/lib/xorg/modules/libint10.so [ 5629.109] (II) Module int10: vendor="X.Org Foundation" [ 5629.109] compiled for 1.18.4, module version = 1.0.0 [ 5629.109] ABI class: X.Org Video Driver, version 20.0 [ 5629.109] (II) LoadModule: "record" [ 5629.109] (II) Module "record" already built-in [ 5629.109] (II) LoadModule: "vbe" [ 5629.109] (II) Loading /usr/local/lib/xorg/modules/libvbe.so [ 5629.110] (II) Module vbe: vendor="X.Org Foundation" [ 5629.110] compiled for 1.18.4, module version = 1.1.0 [ 5629.110] ABI class: X.Org Video Driver, version 20.0 [ 5629.110] (II) LoadModule: "xorgxrdp" [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/libxorgxrdp.so [ 5629.110] (II) Module XORGXRDP: vendor="X.Org Foundation" [ 5629.110] compiled for 1.18.4, module version = 1.0.0 [ 5629.110] ABI class: X.Org Video Driver, version 20.0 [ 5629.110] xorgxrdpSetup: [ 5629.110] (II) LoadModule: "fb" [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/libfb.so [ 5629.110] (II) Module fb: vendor="X.Org Foundation" [ 5629.110] compiled for 1.18.4, module version = 1.0.0 [ 5629.110] ABI class: X.Org ANSI C Emulation, version 0.4 [ 5629.110] (II) LoadModule: "xrdpdev" [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/drivers/xrdpdev_drv.so [ 5629.110] (II) Module XRDPDEV: vendor="X.Org Foundation" [ 5629.110] compiled for 1.18.4, module version = 1.0.0 [ 5629.110] ABI class: X.Org Video Driver, version 20.0 [ 5629.110] xrdpdevSetup: [ 5629.110] (II) LoadModule: "xrdpmouse" [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/input/xrdpmouse_drv.so [ 5629.110] (II) Module XRDPMOUSE: vendor="X.Org Foundation" [ 5629.110] compiled for 1.18.4, module version = 1.0.0 [ 5629.110] Module class: X.Org XInput Driver [ 5629.110] ABI class: X.Org XInput driver, version 22.1 [ 5629.110] rdpmousePlug: [ 5629.110] (II) LoadModule: "xrdpkeyb" [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/input/xrdpkeyb_drv.so [ 5629.110] (II) Module XRDPKEYB: vendor="X.Org Foundation" [ 5629.110] compiled for 1.18.4, module version = 1.0.0 [ 5629.110] Module class: X.Org XInput Driver [ 5629.110] ABI class: X.Org XInput driver, version 22.1 [ 5629.110] rdpkeybPlug: [ 5629.111] rdpIdentify: [ 5629.111] (II) XRDPDEV: driver for xrdp: XRDPDEV [ 5629.111] rdpDriverFunc: op 10 [ 5629.111] (WW) Falling back to old probe method for XRDPDEV [ 5629.111] rdpProbe: [ 5629.111] (II) Loading sub module "fb" [ 5629.111] (II) LoadModule: "fb" [ 5629.111] (II) Loading /usr/local/lib/xorg/modules/libfb.so [ 5629.111] (II) Module fb: vendor="X.Org Foundation" [ 5629.111] compiled for 1.18.4, module version = 1.0.0 [ 5629.111] ABI class: X.Org ANSI C Emulation, version 0.4 [ 5629.111] (II) XRDPDEV(0): using default device [ 5629.111] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 5629.111] rdpPreInit: [ 5629.111] (**) XRDPDEV(0): Depth 24, (--) framebuffer bpp 32 [ 5629.111] (==) XRDPDEV(0): RGB weight 888 [ 5629.111] (==) XRDPDEV(0): Using gamma correction (1.0, 1.0, 1.0) [ 5629.111] (==) XRDPDEV(0): Default visual is TrueColor [ 5629.111] (==) XRDPDEV(0): DPI set to (96, 96) [ 5629.111] (II) XRDPDEV(0): mode "640x480" ok [ 5629.111] (II) XRDPDEV(0): mode "800x600" ok [ 5629.111] (--) XRDPDEV(0): Virtual size is 800x600 (pitch 800) [ 5629.111] (**) XRDPDEV(0): Default mode "800x600": 36.0 MHz (scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz [ 5629.111] (II) XRDPDEV(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d) [ 5629.111] (==) Depth 24 pixmap format is 32 bpp [ 5629.111] rdpScreenInit: virtualX 800 virtualY 600 rgbBits 8 depth 24 [ 5629.111] rdpScreenInit: pfbMemory bytes 1920000 [ 5629.111] rdpScreenInit: pfbMemory 0x807200000 [ 5629.111] rdpSimdInit: assigning yuv functions [ 5629.111] rdpSimdInit: cpuid ax 1 cx 0 return ax 0x000306f2 bx 0x00020800 cx 0xfffa3203 dx 0x178bfbff [ 5629.111] rdpSimdInit: sse2 amd64 yuv functions assigned [ 5629.111] rdpXvInit: depth 24 [ 5629.111] (==) XRDPDEV(0): Backing store enabled [ 5629.111] rdpClientConInit: kill disconnected [0] timeout [0] sec [ 5629.111] [ 5629.111] rdpScreenInit: out [ 5629.111] (==) RandR enabled [ 5629.111] MIT-SHM extension disabled due to lack of kernel support [ 5629.111] (II) AIGLX: Screen 0 is not DRI2 capable [ 5629.111] (EE) AIGLX: reverting to software rendering [ 5629.140] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 5629.141] (II) AIGLX: Loaded and initialized swrast [ 5629.141] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 5629.170] (II) Using input driver 'XRDPMOUSE' for 'xrdpMouse' [ 5629.170] (**) Option "CorePointer" [ 5629.170] (**) xrdpMouse: always reports core events [ 5629.170] rdpmousePreInit: drv 0x803c15240 info 0x803c37d20, flags 0x0 [ 5629.170] (II) XINPUT: Adding extended input device "xrdpMouse" (type: Mouse, id 6) [ 5629.170] rdpmouseControl: what 0 [ 5629.170] rdpmouseDeviceInit: [ 5629.170] rdpmouseCtrl: [ 5629.170] rdpRegisterInputCallback: type 1 proc 0x806da1d20 [ 5629.170] (**) xrdpMouse: (accel) keeping acceleration scheme 1 [ 5629.170] (**) xrdpMouse: (accel) acceleration profile 0 [ 5629.170] (**) xrdpMouse: (accel) acceleration factor: 2.000 [ 5629.170] (**) xrdpMouse: (accel) acceleration threshold: 4 [ 5629.170] rdpmouseControl: what 1 [ 5629.170] rdpmouseDeviceOn: [ 5629.170] (II) Using input driver 'XRDPKEYB' for 'xrdpKeyboard' [ 5629.170] (**) Option "CoreKeyboard" [ 5629.170] (**) xrdpKeyboard: always reports core events [ 5629.170] rdpkeybPreInit: drv 0x803c152c0 info 0x803c37e60, flags 0x0 [ 5629.170] (II) XINPUT: Adding extended input device "xrdpKeyboard" (type: Keyboard, id 7) [ 5629.170] rdpkeybControl: what 0 [ 5629.170] rdpkeybDeviceInit: [ 5629.193] rdpkeybChangeKeyboardControl: [ 5629.193] rdpkeybChangeKeyboardControl: autoRepeat on [ 5629.193] rdpRegisterInputCallback: type 0 proc 0x806fa41b0 [ 5629.193] rdpkeybControl: what 1 [ 5629.193] rdpkeybDeviceOn: [ 5629.193] (II) config/devd: probing input devices... [ 5629.194] (II) config/devd: adding input device (null) (/dev/kbdmux) [ 5629.194] (II) AutoAddDevices is off - not adding device. [ 5629.194] (II) config/devd: kbdmux is enabled, ignoring device atkbd0 [ 5629.194] (II) config/devd: adding input device (null) (/dev/sysmouse) [ 5629.194] (II) AutoAddDevices is off - not adding device. [ 5629.227] (II) config/devd: adding input device Mouse (/dev/psm0) [ 5629.227] (II) AutoAddDevices is off - not adding device. [ 5629.228] (EE) config/devd: fail to connect to devd [ 5629.228] [config] failed to initialise devd [ 5629.228] rdpSaveScreen: [ 5629.228] rdpDeferredRandR: [ 5629.228] rdpResizeSession: width 1024 height 768 [ 5629.228] calling RRScreenSizeSet [ 5629.228] rdpRRScreenSetSize: width 1024 height 768 mmWidth 271 mmHeight 203 [ 5629.228] rdpRRGetInfo: [ 5629.228] screen resized to 1024x768 [ 5629.229] RRScreenSizeSet ok 1 [ 5629.229] rdpResizeSession: width 1304 height 603 [ 5629.229] calling RRScreenSizeSet [ 5629.229] rdpRRScreenSetSize: width 1304 height 603 mmWidth 345 mmHeight 160 [ 5629.229] rdpRRGetInfo: [ 5629.229] screen resized to 1304x603 [ 5629.231] RRScreenSizeSet ok 1 [ 5629.297] rdpInDeferredUpdateCallback: [ 5629.297] rdpkeybChangeKeyboardControl: [ 5629.297] rdpkeybChangeKeyboardControl: autoRepeat off [ 5629.716] rdpClientConGotConnection: [ 5629.716] rdpClientConGotConnection: g_sck_accept ok new_sck 6 [ 5629.716] rdpClientConGotConnection: adding only clientCon [ 5629.720] rdpClientConProcessMsgVersion: version 0 0 0 1 [ 5629.720] rdpClientConProcessScreenSizeMsg: set width 1304 height 603 bpp 16 [ 5629.720] rdpClientConProcessScreenSizeMsg: shmemid -1 shmemptr 0xffffffffffffffff [ 5629.720] rdpClientConProcessMsgClientInput: invalidate x 0 y 0 cx 1304 cy 603 [ 5646.293] rdpClientConProcessMsgClientInfo: [ 5646.293] got client info bytes 5744 [ 5646.293] jpeg support 0 [ 5646.293] offscreen support 0 [ 5646.293] offscreen size 0 [ 5646.293] offscreen entries 0 [ 5646.293] client supports glyph cache but server disabled [ 5646.293] client can not do offscreen to offscreen blits [ 5646.293] client can do new(color) cursor [ 5646.293] client can not do multimon [ 5646.293] rdpRRSetRdpOutputs: numCrtcs 0 monitorCount 0 [ 5646.293] rdpRRSetRdpOutputs: add output 0 left 0 top 0 width 1304 height 603 [ 5646.293] rdpLoadLayout: keylayout 0x00000409 variant display 13 [ 5646.294] rdpkeybChangeKeyboardControl: [ 5646.294] rdpkeybChangeKeyboardControl: autoRepeat on [ 5646.294] rdpkeybChangeKeyboardControl: [ 5646.294] rdpkeybChangeKeyboardControl: autoRepeat on [ 5646.320] (EE) [ 5646.321] (EE) Backtrace: [ 5646.322] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5abfba] [ 5646.324] (EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x544) [0x8025cbd94] [ 5646.326] (EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xe5f) [0x8025cbbef] [ 5646.327] (EE) 3: ? (?+0xe5f) [0x7ffffffffff2] [ 5646.329] (EE) 4: /usr/local/lib/xorg/modules/libxorgxrdp.so (rdpCapture+0xf60) [0x806771aa0] [ 5646.331] (EE) 5: /usr/local/lib/xorg/modules/libxorgxrdp.so (rdpClientConAddAllBox+0x408) [0x80676fbf8] [ 5646.332] (EE) 6: /usr/local/lib/xorg/modules/libxorgxrdp.so (rdpClientConAddDirtyScreenReg+0x3c3) [0x80676ef13] [ 5646.334] (EE) 7: /usr/local/bin/Xorg (WaitForSomething+0x103e) [0x5a47ce] [ 5646.335] (EE) 8: /usr/local/bin/Xorg (UpdateCurrentTimeIf+0x121) [0x431621] [ 5646.337] (EE) 9: /usr/local/bin/Xorg (remove_fs_handlers+0x597) [0x43b697] [ 5646.338] (EE) 10: /usr/local/bin/Xorg (_start+0x17f) [0x42506f] [ 5646.340] (EE) 11: ? (?+0x17f) [0x80083617f] [ 5646.340] (EE) [ 5646.340] (EE) Segmentation fault at address 0xffffffffffffffff [ 5646.340] (EE) Fatal server error: [ 5646.340] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 5646.340] (EE) [ 5646.340] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 5646.340] (EE) Please also check the log file at "/var/log/Xorg.13.log" for additional information. [ 5646.340] (EE) [ 5646.340] rdpmouseControl: what 4 [ 5646.340] rdpkeybControl: what 4 [ 5646.340] rdpLeaveVT: [ 5646.340] (EE) Server terminated with error (1). Closing log file. ----------------------------------------------------------------------- I guess that the root of the issue may be here: (WW) checkDevMem: failed to open /dev/mem (Operation not permitted) Did I miss something in the configuration? Thanks again Giulio > Il giorno 18 set 2017, alle ore 15:32, Alexander Leidinger ha scritto: > > Quoting Giulio Ferro (from Mon, 18 Sep 2017 08:49:32 +0200): > >> nope, even the old way I get: >> >> jail: xxx: unknown parameter: allow.kmem_access >> >> >> Has anyone else tried this in 11.1 stable? > > As I'm creating the diff vs. 11.1 just for you: no. > > Here an updated change (thanks to jamie@ for the cluebat). It's a full patch vs 11.1. > http://www.Leidinger.net/FreeBSD/current-patches/x11_in_jail_releng_11_1.diff > > The difference of what you have already are two lines: > ---snip--- > Index: sys/kern/kern_jail.c > =================================================================== > --- sys/kern/kern_jail.c (revision 323230) > +++ sys/kern/kern_jail.c (working copy) > @@ -3788,6 +3806,8 @@ > "B", "Jail may set file quotas"); > SYSCTL_JAIL_PARAM(_allow, socket_af, CTLTYPE_INT | CTLFLAG_RW, > "B", "Jail may create sockets other than just UNIX/IPv4/IPv6/route"); > +SYSCTL_JAIL_PARAM(_allow, kmem_access, CTLTYPE_INT | CTLFLAG_RW, > + "B", "Jail may access kmem-like devices (io, dri) if they exist"); > > SYSCTL_JAIL_PARAM_SUBNODE(allow, mount, "Jail mount/unmount permission flags"); > SYSCTL_JAIL_PARAM(_allow_mount, , CTLTYPE_INT | CTLFLAG_RW, > ---snip--- > > I have validated this in -current, this is the missing piece. When this is in the kernel, you should see kmem_access in the output of > sysctl security.jail.param.allow > > This should then work with the jail.conf (and rc.conf) way of configuring a jail. > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From owner-freebsd-hackers@freebsd.org Wed Sep 20 06:33:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E75BE25D58 for ; Wed, 20 Sep 2017 06:33:12 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98AA3823E2 for ; Wed, 20 Sep 2017 06:33:10 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Wed, 20 Sep 2017 08:32:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1505889182; bh=6b1FiSCRGUR12m0Ii4les9iTSts3guBwDqUhESfhqAk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=J8eit8mtUQIsjTLY/ngR8jOHB8l0PPsp1OEvutd0Z5exCZTzNRfgoxzLGzsLSGKaY nDGoAr5Td5JMRHoP232VlSg3Ax5DkyuYIGuOC3t+VsbQYCI338ZHT8qHyTDP/Xpi6Z 6ff1yb/I301SssUPgXD9Xh4kPfXInypkbjhDgDHH+0Rs5wabIzBKGtWDvIFGCxm4eD V9mjJP2IqHYN0IdH8FPyPVf9SMZ7AYcEzgqBwL8Ckb4wlXtOgoN7UPKypFaD8su5lj lzavalDYXLpgka7lS6HorrvKVXv7RXwBopRE/lSgrwmykA0XL9QsabWYL1t1MgxYvP Z63HKGwt+p3tQ== Message-ID: <20170920083220.Horde.7owviieKDuNKXQBL8N0TGLf@webmail.leidinger.net> From: Alexander Leidinger To: Giulio Ferro Cc: freebsd-hackers@freebsd.org Subject: Re: devd in jail References: <7ca865ee-b613-2f0c-daf0-d828884b5e74@zirakzigil.org> <1C181EF2-B8B1-4F42-BF80-ABEA0593DD43@dsl-only.net> <20170906122556.Horde.5OdDwtii7HXPNArY77YUyBi@webmail.leidinger.net> <20170906221947.Horde.RITHvdc1wVE9v0-3nBavR0Z@webmail.leidinger.net> <20170909150335.Horde.wBLIPwBuhV3lyQlBxKud39f@webmail.leidinger.net> <27e72cfb-54cf-4af8-b569-85fff089c45f@zirakzigil.org> <20170911161253.Horde.vawLu00EtbbHOVeJRXjp7N0@webmail.leidinger.net> <3236AD55-0D14-49A5-B5B9-3147A216D8A5@zirakzigil.org> <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> <20170918153212.Horde.reuh2WwJotWq2qHgpHwvnNq@webmail.leidinger.net> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_p2u5K6d2IcgLaDKZBPfnkxA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Sep 2017 10:53:25 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 06:33:12 -0000 This message is in MIME format and has been PGP signed. --=_p2u5K6d2IcgLaDKZBPfnkxA Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Giulio Ferro (from Wed, 20 Sep 2017=20=20 06:28:55=20+0200): > Ok, I'm progressing :) > > > I've patched, built and installed the new kernel. Now I can start the > jail with the new parameter. > > Unfortunately Xorg still fails to start... :( > > > > Here's my setup: > > > > /etc/rc.conf.local > ----------------------------------------------------------------------- > ... > jail_enable=3D"YES" > ... > ----------------------------------------------------------------------- > > > > > /etc/jail.conf > ----------------------------------------------------------------------- > exec.start =3D "/bin/sh /etc/rc"; > exec.stop =3D "/bin/sh /etc/rc.shutdown"; > exec.clean; > mount.devfs; > devfs_ruleset=3D1; > > path =3D "/usr/home/jails/$name"; > > xxx { > host.hostname =3D "xxx.xxx.xxx"; > vnet; > vnet.interface =3D epair0b, epair1b; > allow.kmem_access =3D "true"; > persist; > } > ----------------------------------------------------------------------- > > > > > /etc/devfs.rules > ----------------------------------------------------------------------- > [devfsrules_jail=3D1] > add path pf unhide > > add path kmem unhide > add path io unhide > add path mem unhide > add path pci unhide > add path tty unhide > add path ttyv0 unhide > add path ttyv1 unhide > add path ttyv8 unhide > ----------------------------------------------------------------------- You should have this on the host, not inside the jail (from the /dev=20=20 listing=20it looks like you get the full devfs, not only the limited=20=20 amount).=20Mine (rule 15) looks like this: ---snip--- [devfsrules_unhide_audio=3D5] add path 'audio*' unhide add path 'dsp*' unhide add path midistat unhide add path 'mixer*' unhide add path 'music*' unhide add path 'sequencer*' unhide add path sndstat unhide add path speaker unhide [devfsrules_unhide_input=3D7] add path 'atkbd*' unhide add path 'kbd*' unhide add path 'joy*' unhide add path 'psm*' unhide add path sysmouse unhide add path 'ukbd*' unhide add path 'ums*' unhide [devfsrules_unhide_xorg=3D8] add path agpgart unhide add path dri unhide add path 'dri/card*' unhide add path nvidiactl unhide add path 'nvidia*' unhide add path io unhide add path mem unhide add path pci unhide add path tty unhide add path ttyv0 unhide add path ttyv1 unhide add path ttyv8 unhide [devfsrules_unhide_cuse=3D13] add path cuse unhide add path video unhide add path 'video*' unhide add path dvb unhide add path 'dvb*' unhide add path 'adapter*' unhide add path input unhide add path 'input*' unhide [devfsrules_jail_desktop=3D15] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add include $devfsrules_unhide_audio add include $devfsrules_unhide_input add include $devfsrules_unhide_xorg add include $devfsrules_unhide_kmem add include $devfsrules_unhide_cuse ---snip--- > Here's the xorg.conf (automatically created by xrdp) > ----------------------------------------------------------------------- > # cat xorg.conf > > Section "ServerLayout" > Identifier "X11 Server" > Screen "Screen (xrdpdev)" > InputDevice "xrdpMouse" "CorePointer" > InputDevice "xrdpKeyboard" "CoreKeyboard" > EndSection > > Section "ServerFlags" > Option "DontVTSwitch" "on" > Option "AutoAddDevices" "off" Option "AllowEmptyInput" "on" > EndSection > > Section "Module" > Load "dbe" > Load "ddc" > Load "extmod" > Load "glx" > Load "int10" > Load "record" > Load "vbe" > Load "xorgxrdp" > Load "fb" > EndSection > > Section "InputDevice" > Identifier "xrdpKeyboard" > Driver "xrdpkeyb" > EndSection > > Section "InputDevice" > Identifier "xrdpMouse" > Driver "xrdpmouse" > EndSection > > Section "Monitor" > Identifier "Monitor" > Option "DPMS" > HorizSync 30-80 > VertRefresh 60-75 > ModeLine "1920x1080" 138.500 1920 1968 2000 2080 1080 1083 1088=20=20 >=201111 +hsync -vsync > ModeLine "1280x720" 74.25 1280 1720 1760 1980 720 725 730 750=20=20 >=20+HSync +VSync > Modeline "1368x768" 72.25 1368 1416 1448 1528 768 771 781 790=20=20 >=20+hsync -vsync > Modeline "1600x900" 119.00 1600 1696 1864 2128 900 901 904 932=20=20 >=20-hsync +vsync > EndSection > > Section "Device" > Identifier "Video Card (xrdpdev)" > Driver "xrdpdev" > EndSection > > Section "Screen" > Identifier "Screen (xrdpdev)" > Device "Video Card (xrdpdev)" > Monitor "Monitor" > DefaultDepth 24 > SubSection "Display" > Depth 24 > Modes "640x480" "800x600" "1024x768" "1280x720" "1280x1024"=20=20 >=20"1600x900" "1920x1080" > EndSubSection > EndSection > ----------------------------------------------------------------------- > > > I can start xrdp with its sesman. But when xorg is launched, I still > have errors... > > Here the X log: > ----------------------------------------------------------------------- > # cat Xorg.13.log > [ 5629.107] > X.Org X Server 1.18.4 > Release Date: 2016-07-19 > [ 5629.107] X Protocol Version 11, Revision 0 > [ 5629.107] Build Operating System: FreeBSD 11.0-RELEASE-p12 amd64 > [ 5629.107] Current Operating System: FreeBSD xxx.xxx.xxx=20=20 >=2011.1-STABLE FreeBSD 11.1-STABLE #2 r323738M: Tue Sep 19 08:47:53 UTC=20= =20 >=202017 root@xxxhost.xxx.xxx:/usr/obj/usr/src/sys/XXXSRV amd64 > [ 5629.107] Build Date: 12 September 2017 08:39:56AM > [ 5629.107] > [ 5629.107] Current version of pixman: 0.34.0 > [ 5629.107] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [ 5629.107] Markers: (--) probed, (**) from config file, (=3D=3D)=20=20 >=20default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 5629.107] (=3D=3D) Log file: "/var/log/Xorg.13.log", Time: Tue Sep 19= =20=20 >=2011:31:20 2017 > [ 5629.108] (++) Using config file: "/etc/X11/xrdp/xorg.conf" > [ 5629.108] (=3D=3D) ServerLayout "X11 Server" > [ 5629.108] (**) |-->Screen "Screen (xrdpdev)" (0) > [ 5629.108] (**) | |-->Monitor "Monitor" > [ 5629.108] (**) | |-->Device "Video Card (xrdpdev)" > [ 5629.108] (**) |-->Input Device "xrdpMouse" > [ 5629.108] (**) |-->Input Device "xrdpKeyboard" > [ 5629.108] (**) Option "DontVTSwitch" "on" > [ 5629.108] (**) Option "AutoAddDevices" "off" > [ 5629.108] (**) Not automatically adding devices > [ 5629.108] (=3D=3D) Automatically enabling devices > [ 5629.108] (=3D=3D) Not automatically adding GPU devices > [ 5629.108] (=3D=3D) Max clients allowed: 256, resource mask: 0x1fffff > [ 5629.108] (WW) The directory "/usr/local/share/fonts/misc/" does=20=20 >=20not exist. > [ 5629.108] Entry deleted from font path. > [ 5629.108] (WW) The directory "/usr/local/share/fonts/TTF/" does not ex= ist. > [ 5629.108] Entry deleted from font path. > [ 5629.108] (WW) The directory "/usr/local/share/fonts/OTF/" does not ex= ist. > [ 5629.108] Entry deleted from font path. > [ 5629.108] (WW) The directory "/usr/local/share/fonts/Type1/" does=20= =20 >=20not exist. > [ 5629.108] Entry deleted from font path. > [ 5629.108] (WW) The directory "/usr/local/share/fonts/100dpi/"=20=20 >=20does not exist. > [ 5629.108] Entry deleted from font path. > [ 5629.108] (WW) The directory "/usr/local/share/fonts/75dpi/" does=20= =20 >=20not exist. > [ 5629.108] Entry deleted from font path. > [ 5629.108] (=3D=3D) FontPath set to: > > [ 5629.108] (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" > [ 5629.108] (II) Loader magic: 0x813b70 > [ 5629.108] (II) Module ABI versions: > [ 5629.108] X.Org ANSI C Emulation: 0.4 > [ 5629.108] X.Org Video Driver: 20.0 > [ 5629.108] X.Org XInput driver : 22.1 > [ 5629.108] X.Org Server Extension : 9.0 > [ 5629.108] (WW) checkDevMem: failed to open /dev/mem (Operation=20=20 >=20not permitted) > [ 5629.108] (--) PCI:*(0:0:2:0) 1013:00b8:5853:0001 rev 0, Mem @=20=20 >=200xf0000000/33554432, 0xf3000000/4096, BIOS @ 0x????????/65536 > [ 5629.108] (II) "glx" will be loaded. This was enabled by default=20=20 >=20and also specified in the config file. > [ 5629.108] (II) LoadModule: "dbe" > [ 5629.108] (II) Module "dbe" already built-in > [ 5629.108] (II) LoadModule: "ddc" > [ 5629.108] (II) Module "ddc" already built-in > [ 5629.108] (II) LoadModule: "extmod" > [ 5629.108] (II) Module "extmod" already built-in > [ 5629.108] (II) LoadModule: "glx" > [ 5629.108] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.s= o > [ 5629.109] (II) Module glx: vendor=3D"X.Org Foundation" > [ 5629.109] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.109] ABI class: X.Org Server Extension, version 9.0 > [ 5629.109] (=3D=3D) AIGLX enabled > [ 5629.109] (II) LoadModule: "int10" > [ 5629.109] (II) Loading /usr/local/lib/xorg/modules/libint10.so > [ 5629.109] (II) Module int10: vendor=3D"X.Org Foundation" > [ 5629.109] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.109] ABI class: X.Org Video Driver, version 20.0 > [ 5629.109] (II) LoadModule: "record" > [ 5629.109] (II) Module "record" already built-in > [ 5629.109] (II) LoadModule: "vbe" > [ 5629.109] (II) Loading /usr/local/lib/xorg/modules/libvbe.so > [ 5629.110] (II) Module vbe: vendor=3D"X.Org Foundation" > [ 5629.110] compiled for 1.18.4, module version =3D 1.1.0 > [ 5629.110] ABI class: X.Org Video Driver, version 20.0 > [ 5629.110] (II) LoadModule: "xorgxrdp" > [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/libxorgxrdp.so > [ 5629.110] (II) Module XORGXRDP: vendor=3D"X.Org Foundation" > [ 5629.110] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.110] ABI class: X.Org Video Driver, version 20.0 > [ 5629.110] xorgxrdpSetup: > [ 5629.110] (II) LoadModule: "fb" > [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/libfb.so > [ 5629.110] (II) Module fb: vendor=3D"X.Org Foundation" > [ 5629.110] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.110] ABI class: X.Org ANSI C Emulation, version 0.4 > [ 5629.110] (II) LoadModule: "xrdpdev" > [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/drivers/xrdpdev_drv= .so > [ 5629.110] (II) Module XRDPDEV: vendor=3D"X.Org Foundation" > [ 5629.110] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.110] ABI class: X.Org Video Driver, version 20.0 > [ 5629.110] xrdpdevSetup: > [ 5629.110] (II) LoadModule: "xrdpmouse" > [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/input/xrdpmouse_drv= .so > [ 5629.110] (II) Module XRDPMOUSE: vendor=3D"X.Org Foundation" > [ 5629.110] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.110] Module class: X.Org XInput Driver > [ 5629.110] ABI class: X.Org XInput driver, version 22.1 > [ 5629.110] rdpmousePlug: > [ 5629.110] (II) LoadModule: "xrdpkeyb" > [ 5629.110] (II) Loading /usr/local/lib/xorg/modules/input/xrdpkeyb_drv.= so > [ 5629.110] (II) Module XRDPKEYB: vendor=3D"X.Org Foundation" > [ 5629.110] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.110] Module class: X.Org XInput Driver > [ 5629.110] ABI class: X.Org XInput driver, version 22.1 > [ 5629.110] rdpkeybPlug: > [ 5629.111] rdpIdentify: > [ 5629.111] (II) XRDPDEV: driver for xrdp: XRDPDEV > [ 5629.111] rdpDriverFunc: op 10 > [ 5629.111] (WW) Falling back to old probe method for XRDPDEV > [ 5629.111] rdpProbe: > [ 5629.111] (II) Loading sub module "fb" > [ 5629.111] (II) LoadModule: "fb" > [ 5629.111] (II) Loading /usr/local/lib/xorg/modules/libfb.so > [ 5629.111] (II) Module fb: vendor=3D"X.Org Foundation" > [ 5629.111] compiled for 1.18.4, module version =3D 1.0.0 > [ 5629.111] ABI class: X.Org ANSI C Emulation, version 0.4 > [ 5629.111] (II) XRDPDEV(0): using default device > [ 5629.111] (WW) VGA arbiter: cannot open kernel arbiter, no=20=20 >=20multi-card support > [ 5629.111] rdpPreInit: > [ 5629.111] (**) XRDPDEV(0): Depth 24, (--) framebuffer bpp 32 > [ 5629.111] (=3D=3D) XRDPDEV(0): RGB weight 888 > [ 5629.111] (=3D=3D) XRDPDEV(0): Using gamma correction (1.0, 1.0, 1.0) > [ 5629.111] (=3D=3D) XRDPDEV(0): Default visual is TrueColor > [ 5629.111] (=3D=3D) XRDPDEV(0): DPI set to (96, 96) > [ 5629.111] (II) XRDPDEV(0): mode "640x480" ok > [ 5629.111] (II) XRDPDEV(0): mode "800x600" ok > [ 5629.111] (--) XRDPDEV(0): Virtual size is 800x600 (pitch 800) > [ 5629.111] (**) XRDPDEV(0): Default mode "800x600": 36.0 MHz=20=20 >=20(scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz > [ 5629.111] (II) XRDPDEV(0): Modeline "800x600"x0.0 36.00 800=20=20 >=20824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d) > [ 5629.111] (=3D=3D) Depth 24 pixmap format is 32 bpp > [ 5629.111] rdpScreenInit: virtualX 800 virtualY 600 rgbBits 8 depth 24 > [ 5629.111] rdpScreenInit: pfbMemory bytes 1920000 > [ 5629.111] rdpScreenInit: pfbMemory 0x807200000 > [ 5629.111] rdpSimdInit: assigning yuv functions > [ 5629.111] rdpSimdInit: cpuid ax 1 cx 0 return ax 0x000306f2 bx=20=20 >=200x00020800 cx 0xfffa3203 dx 0x178bfbff > [ 5629.111] rdpSimdInit: sse2 amd64 yuv functions assigned > [ 5629.111] rdpXvInit: depth 24 > [ 5629.111] (=3D=3D) XRDPDEV(0): Backing store enabled > [ 5629.111] rdpClientConInit: kill disconnected [0] timeout [0] sec > [ 5629.111] > [ 5629.111] rdpScreenInit: out > [ 5629.111] (=3D=3D) RandR enabled > [ 5629.111] MIT-SHM extension disabled due to lack of kernel support > [ 5629.111] (II) AIGLX: Screen 0 is not DRI2 capable > [ 5629.111] (EE) AIGLX: reverting to software rendering > [ 5629.140] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > [ 5629.141] (II) AIGLX: Loaded and initialized swrast > [ 5629.141] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > [ 5629.170] (II) Using input driver 'XRDPMOUSE' for 'xrdpMouse' > [ 5629.170] (**) Option "CorePointer" > [ 5629.170] (**) xrdpMouse: always reports core events > [ 5629.170] rdpmousePreInit: drv 0x803c15240 info 0x803c37d20, flags 0x0 > [ 5629.170] (II) XINPUT: Adding extended input device "xrdpMouse"=20=20 >=20(type: Mouse, id 6) > [ 5629.170] rdpmouseControl: what 0 > [ 5629.170] rdpmouseDeviceInit: > [ 5629.170] rdpmouseCtrl: > [ 5629.170] rdpRegisterInputCallback: type 1 proc 0x806da1d20 > [ 5629.170] (**) xrdpMouse: (accel) keeping acceleration scheme 1 > [ 5629.170] (**) xrdpMouse: (accel) acceleration profile 0 > [ 5629.170] (**) xrdpMouse: (accel) acceleration factor: 2.000 > [ 5629.170] (**) xrdpMouse: (accel) acceleration threshold: 4 > [ 5629.170] rdpmouseControl: what 1 > [ 5629.170] rdpmouseDeviceOn: > [ 5629.170] (II) Using input driver 'XRDPKEYB' for 'xrdpKeyboard' > [ 5629.170] (**) Option "CoreKeyboard" > [ 5629.170] (**) xrdpKeyboard: always reports core events > [ 5629.170] rdpkeybPreInit: drv 0x803c152c0 info 0x803c37e60, flags 0x0 > [ 5629.170] (II) XINPUT: Adding extended input device=20=20 >=20"xrdpKeyboard" (type: Keyboard, id 7) > [ 5629.170] rdpkeybControl: what 0 > [ 5629.170] rdpkeybDeviceInit: > [ 5629.193] rdpkeybChangeKeyboardControl: > [ 5629.193] rdpkeybChangeKeyboardControl: autoRepeat on > [ 5629.193] rdpRegisterInputCallback: type 0 proc 0x806fa41b0 > [ 5629.193] rdpkeybControl: what 1 > [ 5629.193] rdpkeybDeviceOn: > [ 5629.193] (II) config/devd: probing input devices... > [ 5629.194] (II) config/devd: adding input device (null) (/dev/kbdmux) > [ 5629.194] (II) AutoAddDevices is off - not adding device. > [ 5629.194] (II) config/devd: kbdmux is enabled, ignoring device atkbd0 > [ 5629.194] (II) config/devd: adding input device (null) (/dev/sysmouse) > [ 5629.194] (II) AutoAddDevices is off - not adding device. > [ 5629.227] (II) config/devd: adding input device Mouse (/dev/psm0) > [ 5629.227] (II) AutoAddDevices is off - not adding device. > [ 5629.228] (EE) config/devd: fail to connect to devd > [ 5629.228] [config] failed to initialise devd > [ 5629.228] rdpSaveScreen: > [ 5629.228] rdpDeferredRandR: > [ 5629.228] rdpResizeSession: width 1024 height 768 > [ 5629.228] calling RRScreenSizeSet > [ 5629.228] rdpRRScreenSetSize: width 1024 height 768 mmWidth 271=20=20 >=20mmHeight 203 > [ 5629.228] rdpRRGetInfo: > [ 5629.228] screen resized to 1024x768 > [ 5629.229] RRScreenSizeSet ok 1 > [ 5629.229] rdpResizeSession: width 1304 height 603 > [ 5629.229] calling RRScreenSizeSet > [ 5629.229] rdpRRScreenSetSize: width 1304 height 603 mmWidth 345=20=20 >=20mmHeight 160 > [ 5629.229] rdpRRGetInfo: > [ 5629.229] screen resized to 1304x603 > [ 5629.231] RRScreenSizeSet ok 1 > [ 5629.297] rdpInDeferredUpdateCallback: > [ 5629.297] rdpkeybChangeKeyboardControl: > [ 5629.297] rdpkeybChangeKeyboardControl: autoRepeat off > [ 5629.716] rdpClientConGotConnection: > [ 5629.716] rdpClientConGotConnection: g_sck_accept ok new_sck 6 > [ 5629.716] rdpClientConGotConnection: adding only clientCon > [ 5629.720] rdpClientConProcessMsgVersion: version 0 0 0 1 > [ 5629.720] rdpClientConProcessScreenSizeMsg: set width 1304 height=20= =20 >=20603 bpp 16 > [ 5629.720] rdpClientConProcessScreenSizeMsg: shmemid -1 shmemptr=20=20 >=200xffffffffffffffff > [ 5629.720] rdpClientConProcessMsgClientInput: invalidate x 0 y 0=20=20 >=20cx 1304 cy 603 > [ 5646.293] rdpClientConProcessMsgClientInfo: > [ 5646.293] got client info bytes 5744 > [ 5646.293] jpeg support 0 > [ 5646.293] offscreen support 0 > [ 5646.293] offscreen size 0 > [ 5646.293] offscreen entries 0 > [ 5646.293] client supports glyph cache but server disabled > [ 5646.293] client can not do offscreen to offscreen blits > [ 5646.293] client can do new(color) cursor > [ 5646.293] client can not do multimon > [ 5646.293] rdpRRSetRdpOutputs: numCrtcs 0 monitorCount 0 > [ 5646.293] rdpRRSetRdpOutputs: add output 0 left 0 top 0 width=20=20 >=201304 height 603 > [ 5646.293] rdpLoadLayout: keylayout 0x00000409 variant display 13 > [ 5646.294] rdpkeybChangeKeyboardControl: > [ 5646.294] rdpkeybChangeKeyboardControl: autoRepeat on > [ 5646.294] rdpkeybChangeKeyboardControl: > [ 5646.294] rdpkeybChangeKeyboardControl: autoRepeat on > [ 5646.320] (EE) > [ 5646.321] (EE) Backtrace: > [ 5646.322] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5abfba] > [ 5646.324] (EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x544) [0x8025cbd= 94] > [ 5646.326] (EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xe5f)=20=20 >=20[0x8025cbbef] > [ 5646.327] (EE) 3: ? (?+0xe5f) [0x7ffffffffff2] > [ 5646.329] (EE) 4: /usr/local/lib/xorg/modules/libxorgxrdp.so=20=20 >=20(rdpCapture+0xf60) [0x806771aa0] > [ 5646.331] (EE) 5: /usr/local/lib/xorg/modules/libxorgxrdp.so=20=20 >=20(rdpClientConAddAllBox+0x408) [0x80676fbf8] > [ 5646.332] (EE) 6: /usr/local/lib/xorg/modules/libxorgxrdp.so=20=20 >=20(rdpClientConAddDirtyScreenReg+0x3c3) [0x80676ef13] > [ 5646.334] (EE) 7: /usr/local/bin/Xorg (WaitForSomething+0x103e) [0x5a4= 7ce] > [ 5646.335] (EE) 8: /usr/local/bin/Xorg (UpdateCurrentTimeIf+0x121)=20= =20 >=20[0x431621] > [ 5646.337] (EE) 9: /usr/local/bin/Xorg (remove_fs_handlers+0x597)=20=20 >=20[0x43b697] > [ 5646.338] (EE) 10: /usr/local/bin/Xorg (_start+0x17f) [0x42506f] > [ 5646.340] (EE) 11: ? (?+0x17f) [0x80083617f] > [ 5646.340] (EE) > [ 5646.340] (EE) Segmentation fault at address 0xffffffffffffffff > [ 5646.340] (EE) > Fatal server error: > [ 5646.340] (EE) Caught signal 11 (Segmentation fault). Server aborting > [ 5646.340] (EE) > [ 5646.340] (EE) > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [ 5646.340] (EE) Please also check the log file at=20=20 >=20"/var/log/Xorg.13.log" for additional information. > [ 5646.340] (EE) > [ 5646.340] rdpmouseControl: what 4 > [ 5646.340] rdpkeybControl: what 4 > [ 5646.340] rdpLeaveVT: > [ 5646.340] (EE) Server terminated with error (1). Closing log file. > ----------------------------------------------------------------------- > > > > I guess that the root of the issue may be here: > (WW) checkDevMem: failed to open /dev/mem (Operation not permitted) Are you starting X with the root user, respectively is it suid-root? > Did I miss something in the configuration? I still think it is the segfault, not the other WW items... You can try to hand-mount a full devfs into the path of the jail, then=20= =20 chroot=20into it from the host (do not start the jail), and then start=20= =20 X.=20This way you don'T have the access restrictions of the jail (full=20= =20 access=20on the host), and you can validate the executables/config. Once=20= =20 this=20is running, you can give it a try in the jail. You could ktrace=20= =20 the=20running vs. the jailed version then, this should reveal more low=20= =20 level=20info what it tries to do. Bye, Alexander --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_p2u5K6d2IcgLaDKZBPfnkxA Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJZwgt0AAoJEKrxQhqFIICEZYsP/2dgNtRhsCfcNHZDdcwmS/Es oY06u76FJiGBZ3Ne0LgP+q0AttUiximLSJU12aHzeQhDPyb8peKnBw6RsnLlocsr kuas3bZ7YKTV5VG01O4ieqjaD/oeAMGvIPzPHCfueXjGOaSfVYOKE/rEJlllYYhB 7U7O87KCaGxu41aDxMvRwYPffx7HbOG3UQUXIITMg0NxVztsM99sqCnNzXSD4qy2 HVEuymAdZY6LBDq1/gexrbzIwyahJYHQaoZH1VebFLSTQ3kLcxzY63xvgs+JCZh1 uwAudGiJ6uymoE3tth8kJQdZ+5PyIwDem53vlpNF0Srfn+701LhMCRBvTWMyJ5SJ vBwQfc2GbH6SxRPI/R3nzXd034HnWkByDiB39boLlRBBT4d6ZLtTj8eGb+G1yuSn kmNJCUcDoaLMvklX3DHtpJzQczCU3rfbw0JjgV8D53BbPrmV1EqGWKeDZI7LohDW pfRy2Moz4THxlcARedcpmJvfJR4udbAcacIYbvtAzvH1bYa7q9GjA1k7lDuM+Oi4 Fs3D5ZJSJIHl+KIaRxwr92vU8NWL7MyaEslU2/nEf5BVyNrcoKb2a3jkG3B2oCXQ nDc91tiL/ESS4ycYhSHRkyuAOUrMJSSk1ux93gzueUi6cZTprLtsLZJzvFM2Xv33 X50EYF8QHSaWQSNwWtjH =UWsV -----END PGP SIGNATURE----- --=_p2u5K6d2IcgLaDKZBPfnkxA-- From owner-freebsd-hackers@freebsd.org Wed Sep 20 12:14:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91E62E0C05E for ; Wed, 20 Sep 2017 12:14:03 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.etoilesoft.fr (mx1.etoilesoft.fr [52.57.51.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4DB02696D7 for ; Wed, 20 Sep 2017 12:14:02 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.etoilesoft.fr (localhost [127.0.0.1]) by mx1.etoilesoft.fr (Postfix) with ESMTP id 064239D1A7; Wed, 20 Sep 2017 12:15:14 +0000 (UTC) Received: from mx1.etoilesoft.fr (localhost [127.0.0.1]) by mx1.etoilesoft.fr (Postfix) with ESMTP id A01AA9D1A6; Wed, 20 Sep 2017 12:15:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mailserver1.etoilesoft.fr X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,TW_XR autolearn=unavailable autolearn_force=no version=3.4.1 Received: from secure.etoilesoft.fr (localhost [127.0.0.1]) (Authenticated sender: auryn@zirakzigil.org) by mx1.etoilesoft.fr (Postfix) with ESMTPA; Wed, 20 Sep 2017 12:15:13 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 20 Sep 2017 14:15:13 +0200 From: auryn@zirakzigil.org To: Alexander Leidinger , freebsd-hackers@freebsd.org Subject: Re: devd in jail In-Reply-To: <20170920083220.Horde.7owviieKDuNKXQBL8N0TGLf@webmail.leidinger.net> References: <7ca865ee-b613-2f0c-daf0-d828884b5e74@zirakzigil.org> <1C181EF2-B8B1-4F42-BF80-ABEA0593DD43@dsl-only.net> <20170906122556.Horde.5OdDwtii7HXPNArY77YUyBi@webmail.leidinger.net> <20170906221947.Horde.RITHvdc1wVE9v0-3nBavR0Z@webmail.leidinger.net> <20170909150335.Horde.wBLIPwBuhV3lyQlBxKud39f@webmail.leidinger.net> <27e72cfb-54cf-4af8-b569-85fff089c45f@zirakzigil.org> <20170911161253.Horde.vawLu00EtbbHOVeJRXjp7N0@webmail.leidinger.net> <3236AD55-0D14-49A5-B5B9-3147A216D8A5@zirakzigil.org> <20170917210736.Horde.TlHhnPnnzSWoAGi9k7b1_sp@webmail.leidinger.net> <20170918153212.Horde.reuh2WwJotWq2qHgpHwvnNq@webmail.leidinger.net> <20170920083220.Horde.7owviieKDuNKXQBL8N0TGLf@webmail.leidinger.net> Message-ID: <15937e4af267475a5eafcba37fc23e75@zirakzigil.org> X-Sender: auryn@zirakzigil.org User-Agent: Roundcube Webmail/1.3-beta X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 12:14:03 -0000 On 2017-09-20 08:32, Alexander Leidinger wrote: Hi Alexander and all. Thanks a lot for your help. To make long story short, xorg in jail via xrdp doesn't work. I've manually mounted /dev and /var/run by nullfs to the jail, so that once in the jail I see exactly the same as in the host. But no, xorg isn't able to start properly. I've given up. I've resorted to using xrdp in the host machine, where it works correctly, and adapt this to my needs. I someone wants to investigate this further, I can give a hand. Cheers Giulio