Re: Lack of /dev/vtvga0?

2018-06-23 Thread Mahmoud Al-Qudsi 
On Sat, Jun 23, 2018 at 12:11 AM, Chris H  wrote:
> I'm not clear if you're already possibly referring to this. But have
> you tried sc(4) ( SysCons ). If you haven't tried already;
> adding the following to your loader.conf(5) should give it to you:
>
> kern.vty=sc
>
> You can also include it in your custom kernel by adding this to your
> KERNCONF
>
> devicesc
> options   SC_PIXEL_MODE  # adds support for the raster text mode
>
> Hope this helps.

Hi Chris, thanks for responding.

Yup, I'm aware of using kern.vty to fall back to syscons, and SC_PIXEL_MODE to
get framebuffer support via /dev/tty* devices. I actually have a port of the
xf86-video-wsfb driver for scfb [0].

My question is actually specifically in regards to newcons/vt. By checking
`dmesg` I can see that the libvt driver device vtvga0 is instantiated, but
it's not mapped to any file in /dev/ which means I can't send it an IOCTL as I
normally would.

Or perhaps the problem is that with vt_vga loaded, IOCTLs to /dev/tty* devices
only respond to CONSIO IOCTLs and not libvt or FBIO IOCTLs, which is how they
would respond with SC_PIXEL_MODE and kern.vty=sc.

Note that this is with hw.vga.textmode=0, which afaict per vt(4) is not the
default, but at the same time does not seem to actually change anything.

I believe the entire point of libvt was to abstract away the KMS drivers from
the API framebuffer API and allow for dynamic switching of the backend driver
without needing to switch to a different graphics provider or change the
graphics library/framework/environment configuration, and indeed when loading
the binary blobs for the test GPUs I have in the system, a /dev/fb0 magically
appears, but there is no framebuffer device for the basic in-kernel VGA driver
that is used until a more appropriate KMS driver has been loaded (if ever).

[0]: https://github.com/neosmart/xf86-video-scfb/


Thanks,

Mahmoud Al-Qudsi
NeoSmart Technologies
___
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"

nfsd kernel threads won't die via SIGKILL

2018-06-23 Thread Rick Macklem 
During testing of the pNFS server I have been frequently killing/restarting the 
nfsd.
Once in a while, the "slave" nfsd process doesn't terminate and a "ps axHl" 
shows:
  0 48889 1   0   20  0  5884  812 svcexit  D -   0:00.01 nfsd: server 
  0 48889 1   0   40  0  5884  812 rpcsvc   I -   0:00.00 nfsd: server 
... more of the same
  0 48889 1   0   40  0  5884  812 rpcsvc   I -   0:00.00 nfsd: server 
  0 48889 1   0   -8  0  5884  812 rpcsvc   I -   1:51.78 nfsd: server 
  0 48889 1   0   -8  0  5884  812 rpcsvc   I -   2:27.75 nfsd: server 

You can see that the top thread (the one that was created with the process) is
stuck in "D"  on "svcexit".
The rest of the threads are still servicing NFS RPCs. If you still have an NFS 
mount on
the server, the mount continues to work and the CPU time for the last two 
threads
slowly climbs, due to NFS RPC activity. A SIGKILL was posted for the process and
these threads (created by kthread_add) are here, but the
cv_wait_sig/cv_timedwait_sig never seems to return EINTR for these other 
threads.

   if (ismaster || (!ismaster &&
1207grp->sg_threadcount > grp->sg_minthreads))
1208error = cv_timedwait_sig(&st->st_cond,
1209&grp->sg_lock, 5 * hz);
1210else
1211error = cv_wait_sig(&st->st_cond,
1212&grp->sg_lock);

The top thread (referred to in svc.c as "ismaster" did return from here with 
EINTR
and has now done an msleep() here, waiting for the other threads to terminate.

   /* Waiting for threads to stop. */
1387for (g = 0; g < pool->sp_groupcount; g++) {
1388grp = &pool->sp_groups[g];
1389mtx_lock(&grp->sg_lock);
1390while (grp->sg_threadcount > 0)
1391msleep(grp, &grp->sg_lock, 0, "svcexit", 0);
1392mtx_unlock(&grp->sg_lock);
1393}

Although I can't be sure if this patch has fixed the problem because it happens
intermittently, I have not seen the problem since applying this patch:
--- rpc/svc.c.sav   2018-06-21 22:52:11.623955000 -0400
+++ rpc/svc.c   2018-06-22 09:01:40.271803000 -0400
@@ -1388,7 +1388,7 @@ svc_run(SVCPOOL *pool)
grp = &pool->sp_groups[g];
mtx_lock(&grp->sg_lock);
while (grp->sg_threadcount > 0)
-   msleep(grp, &grp->sg_lock, 0, "svcexit", 0);
+   msleep(grp, &grp->sg_lock, 0, "svcexit", 1);
mtx_unlock(&grp->sg_lock);
}
 }

As you can see, all it does is add a timeout to the msleep(). 
I am not familiar with the signal delivery code in sleepqeue, so it probably
isn't correct, but my theory is alonge the lines of...

Since the msleep() doesn't have PCATCH, it does not set TDF_SINTR
and if that happens before the other threads return EINTR from cv_wait_sig(),
they no longer do so?
And I thought that waking up from the msleep() via timeouts would maybe allow
the other threads to return EINTR from cv_wait_sig()?

Does this make sense? rick
ps: I'll post if I see the problem again with the patch applied.
pss: This is a single core i386 system, just in case that might affect this.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic_testandclear_, atomic_testandset_

2018-06-23 Thread Matthew Macy 
It turns out ck already has equivalent primitives. Pardon the noise.

-M

On Sat, Jun 23, 2018 at 12:18 Matthew Macy  wrote:

> The functions in the subject are both documented in atomic(9) and are
> implemented by every arch except sparc64 and MIPS. I have some code in
> review that uses them that I intend to commit once the various design
> issues are addressed. Please implement them so that those targets can
> remain part of universe.
>
> Thanks in advance.
> -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"

atomic_testandclear_, atomic_testandset_

2018-06-23 Thread Matthew Macy 
The functions in the subject are both documented in atomic(9) and are
implemented by every arch except sparc64 and MIPS. I have some code in
review that uses them that I intend to commit once the various design
issues are addressed. Please implement them so that those targets can
remain part of universe.

Thanks in advance.
-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: Boot freezing after kernel load - root on zfs

2018-06-23 Thread Ben Woods 
On 23 June 2018 at 22:56, Joe Maloney  wrote:

> Ben,
> do you by chance have multicons enabled with comconsole, vidconsole?  This
> looks exactly like a race we encountered where the remaining output was
> actually being redirected to serial on some systems when multicons was
> being used.  It appeared to be a lockup when it wasn’t because keyboard
> input would also break.
>

Hi Joe,

Indeed, you are right - I have now fixed the problem! Thanks very much for
your help!

I was previously using a serial console to boot the machine, whereas now I
have an IP KVM.

The lines I commented out in my /boot/loader.conf to fix this were:
boot_multicons="YES"
boot_serial="YES"
comconsole_speed="115200"
console="comconsole,vidconsole"

I would have thought that the boot should still complete regardless of
whether the serial console is connected or not?

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
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: Boot freezing after kernel load - root on zfs

2018-06-23 Thread Ben Woods 
On 23 June 2018 at 12:37, Warner Losh  wrote:

> There were some issues with legacy geely booting recently. What version?
> UEFI or legacy BIOS booting?
>
> Warner
>


Hi Warner,

This was occurring with both my old and new beadm boot environments -
r330554 and r334554.

I am booting with legacy BIOS.

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
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: error building clang in HEAD

2018-06-23 Thread Mark Millard 
Gary Jennejohn gljennjohn at gmail.com wrote on
Sat Jun 23 13:41:00 UTC 2018 :

> cd /usr/src
> make -j10 makeworld
> 
> which produces this error output:
> 
> ===> lib/clang/libclang (all)
> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to 
> output file 'Sema/SemaTemplate.o': 'No such file or directory'
> 1 error generated.
> --- Sema/SemaTemplate.o ---
> *** [Sema/SemaTemplate.o] Error code 1

What version of head ( -r?? )?

Is this an AMD Ryzen, AMD Ryzen Threadripper, or AMD Epyc
context? If not, what is the alternative in use? Other
details could be relevant as well.

There was a time when there were various reports of such
for Ryzen variants but the failure would not be on the
same file each time and some builds would work. (I've
seen such myself but likely will not have access to a
Ryzen context again and it will likely be months for
access to a Ryzen Threadripper. So I'm just suggesting
additional information to report.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: error building clang in HEAD

2018-06-23 Thread Dimitry Andric 
On 23 Jun 2018, at 15:40, Gary Jennejohn  wrote:
> 
> There is a strange error building clang with this use case:
> 
> cd /usr/src
> make -j10 makeworld

What's the "makeworld" target?  I've not heard of this.


> which produces this error output:
> 
> ===> lib/clang/libclang (all)
> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to 
> output file 'Sema/SemaTemplate.o': 'No such file or directory'
> 1 error generated.
> --- Sema/SemaTemplate.o ---
> *** [Sema/SemaTemplate.o] Error code 1

This typically happens if "make obj" was not run before the rest of the
make targets.  Normally, the order is: make obj, then make depend, then
make (a.k.a. make all).

Is there a directory /usr/obj/usr/src/lib/libclang/Sema ?


> Note that this started happening after rm -rf /usr/obj/usr.

Indeed, that caused the subdirectories under the obj directories to have
disappeared.  For some reason, in your situation, "make obj" is not run
correctly.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Boot freezing after kernel load - root on zfs

2018-06-23 Thread Joe Maloney 
Ben,
do you by chance have multicons enabled with comconsole, vidconsole?  This 
looks exactly like a race we encountered where the remaining output was 
actually being redirected to serial on some systems when multicons was being 
used.  It appeared to be a lockup when it wasn’t because keyboard input would 
also break.

> On Jun 23, 2018, at 10:40 AM, Allan Jude  wrote:
> 
>> On 2018-06-23 00:37, Warner Losh wrote:
>> There were some issues with legacy geely booting recently. What version?
>> UEFI or legacy BIOS booting?
>> 
>> Warner 
>> 
>> On Fri, Jun 22, 2018, 10:26 PM Ben Woods > > wrote:
>> 
>>On 23 June 2018 at 12:08, Allan Jude >> wrote:
>> 
>>> If you just press shift a bunch of times, does it print the Mount root
>>> prompt?
>>> --
>>> Allan Jude
>>> 
>> 
>> 
>>No, unfortunately not. But please keep any troubleshooting suggestions
>>coming!
>> 
>>I have tried booting with the KVM monitor and USB disconnected, with the
>>same result.
>> 
>>It is also worth noting I can successfully boot from a USB stick running
>>the latest 12-current snapshot
>>FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there
>>I can
>>import both of my zpools (zroot and zstore), and then export them again
>>before rebooting - still can't boot from disk.
>> 
>>--
>>From: Benjamin Woods
>>woods...@gmail.com 
>>___
>>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
>>"
>> 
> 
> Warner: it is not that in this case, the screenshots show it getting
> just past mountroot, so it is well into the kernel when it is stopping.
> 
> -- 
> Allan Jude
> 
___
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: Boot freezing after kernel load - root on zfs

2018-06-23 Thread Allan Jude 
On 2018-06-23 00:37, Warner Losh wrote:
> There were some issues with legacy geely booting recently. What version?
> UEFI or legacy BIOS booting?
> 
> Warner 
> 
> On Fri, Jun 22, 2018, 10:26 PM Ben Woods  > wrote:
> 
> On 23 June 2018 at 12:08, Allan Jude  > wrote:
> 
> > If you just press shift a bunch of times, does it print the Mount root
> > prompt?
> > --
> > Allan Jude
> >
> 
> 
> No, unfortunately not. But please keep any troubleshooting suggestions
> coming!
> 
> I have tried booting with the KVM monitor and USB disconnected, with the
> same result.
> 
> It is also worth noting I can successfully boot from a USB stick running
> the latest 12-current snapshot
> FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there
> I can
> import both of my zpools (zroot and zstore), and then export them again
> before rebooting - still can't boot from disk.
> 
> --
> From: Benjamin Woods
> woods...@gmail.com 
> ___
> 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
> "
> 

Warner: it is not that in this case, the screenshots show it getting
just past mountroot, so it is well into the kernel when it is stopping.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

error building clang in HEAD

2018-06-23 Thread Gary Jennejohn 
There is a strange error building clang with this use case:

cd /usr/src
make -j10 makeworld

which produces this error output:

===> lib/clang/libclang (all)
error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' to output 
file 'Sema/SemaTemplate.o': 'No such file or directory'
1 error generated.
--- Sema/SemaTemplate.o ---
*** [Sema/SemaTemplate.o] Error code 1

make[6]: stopped in /usr/src/lib/clang/libclang
.ERROR_TARGET='Sema/SemaTemplate.o'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema_SemaTemplate.o.meta'
.MAKE.LEVEL='6'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes'
_ERROR_CMD='c++  -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -DNO_MALLOC_EXTRAS 
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm 
-I/usr/src/contrib/llvm/tools/clang/lib/Basic 
-I/usr/src/contrib/llvm/tools/clang/lib/Driver 
-I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT 
-DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86Tar
 getInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -Qunused-arguments -DNO_MALLOC_EXTRAS  -std=c++11 
-fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaTemplate.cpp -o 
Sema/SemaTemplate.o;'
.CURDIR='/usr/src/lib/clang/libclang'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64/lib/clang/libclang'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20180512'
PATH='/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk 
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/lib/clang/libclang/Makefile /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.linker.mk /usr/src/lib/clang/clang.pre.mk 
/usr/src/lib/clang/llvm.pre.mk /usr/src/lib/clang/clang.build.mk 
/usr/src/lib/clang/llvm.build.mk /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/lib/clang/libclang/../Makefile.inc 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk /usr/src
 /share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/lib/clang/libclang /usr/src/contrib/llvm/tools/clang/lib'
1 error

However, if I do this

cd /usr/src/lib/clang/libclang
make -j10 depend all

it succeeds.

I have META_MODE enabled.

It also succeeds with a simple make buildworld, but that's extremely
slow.

Note that this started happening after rm -rf /usr/obj/usr.

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