panic in g_vfs_strategy()
After a forced umount of a msdos filesystem, I received a panic. I have the kernel and vmcore. The first hundred or so lines of core.txt.4 follow my .sig. -- Steve troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.4 Tue Jun 21 14:32:29 PDT 2016 FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r299122: Thu May 5 10:03:31 PDT 2016 ka...@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 panic: general protection fault Unread portion of the kernel message buffer: Device da1s1 went missing before all of the data could be written to it; expect data loss. Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 10 instruction pointer = 0x20:0x8050c4a1 stack pointer = 0x28:0xfe0239276fc0 frame pointer = 0x28:0xfe0239277000 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30604 (sendmail) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0239276c60 vpanic() at vpanic+0x182/frame 0xfe0239276ce0 panic() at panic+0x43/frame 0xfe0239276d40 trap_fatal() at trap_fatal+0x351/frame 0xfe0239276da0 trap() at trap+0x6d1/frame 0xfe0239276f00 calltrap() at calltrap+0x8/frame 0xfe0239276f00 --- trap 0x9, rip = 0x8050c4a1, rsp = 0xfe0239276fd0, rbp = 0xfe0239277000 --- g_vfs_strategy() at g_vfs_strategy+0x31/frame 0xfe0239277000 bufwrite() at bufwrite+0x1da/frame 0xfe0239277040 vop_stdfsync() at vop_stdfsync+0x220/frame 0xfe02392770b0 devfs_fsync() at devfs_fsync+0x67/frame 0xfe02392770e0 VOP_FSYNC_APV() at VOP_FSYNC_APV+0x80/frame 0xfe0239277110 bufsync() at bufsync+0x35/frame 0xfe0239277140 bufobj_invalbuf() at bufobj_invalbuf+0x126/frame 0xfe02392771b0 vgonel() at vgonel+0x17e/frame 0xfe0239277220 vgone() at vgone+0x4c/frame 0xfe0239277250 devfs_delete() at devfs_delete+0x1f3/frame 0xfe02392772c0 devfs_populate_loop() at devfs_populate_loop+0x20f/frame 0xfe0239277320 devfs_populate() at devfs_populate+0x2a/frame 0xfe0239277340 devfs_populate_vp() at devfs_populate_vp+0x9b/frame 0xfe0239277390 devfs_lookup() at devfs_lookup+0x2c/frame 0xfe02392774a0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x7a/frame 0xfe02392774d0 lookup() at lookup+0x561/frame 0xfe0239277560 namei() at namei+0x3ef/frame 0xfe0239277620 vn_open_cred() at vn_open_cred+0x26c/frame 0xfe0239277790 kern_openat() at kern_openat+0x220/frame 0xfe0239277910 amd64_syscall() at amd64_syscall+0x33f/frame 0xfe0239277a30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0239277a30 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x2015336da, rsp = 0x7fffb328, rbp = 0x7fffb410 --- Uptime: 7d21h3m52s Dumping 1033 out of 8143 MB:..2%..11%..21%..31%..41%..52%..61%..72%..81%..92% #0 doadump (textdump=1) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:221 #1 0x8057e7f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0x8057ec6b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0x8057eaa3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0x807e5ab1 in trap_fatal (frame=0xfe0239276f10, eva=0) at /usr/src/sys/amd64/amd64/trap.c:841 #5 0x807e5741 in trap (frame=0xfe0239276f10) at /usr/src/sys/amd64/amd64/trap.c:203 #6 0x807cc133 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #7 0x8050c4a1 in g_vfs_strategy (bo=0xf801303510d0, bp=0xfe01f05637c0) at atomic.h:184 #8 0x8060d41a in bufwrite (bp=0xfe01f05637c0) at buf.h:405 #9 0x8061a750 in vop_stdfsync (ap=0xfe0239277120) at /usr/src/sys/kern/vfs_default.c:695 #10 0x8047d637 in devfs_fsync (ap=0xfe0239277120) at /usr/src/sys/fs/devfs/devfs_vnops.c:694 #11 0x8084d920 in VOP_FSYNC_APV (vop=, a=) at vnode_if.c:1331 #12 0x8060d535 in bufsync (bo=, waitfor=) at vnode_if.h:549 #13 0x80627686 in bufobj_invalbuf (bo=, flags=, slpflag=, slptimeo=) at /usr/src/sys/kern/vfs_subr.c:1539 #14 0x8062a20e in vgonel (vp=) at /usr/src/sys/kern/vfs_subr.c:1617 #15 0x8062a6bc in vgone (vp=0xf80130351000) at /usr/src/sys/kern/vfs_subr.c:3079 #16 0x80477e33 in devfs_delete (dm=0xf800088d6080, de=0xf8022d551500, flags=0) at /usr/src/sys/fs/devfs/devfs_devs.c:397 #17 0x804782df in devfs_populate_loop (dm=, cleanup=) at /usr/src/sys/fs/devfs/devfs_devs.c:535 #18 0x804780ba in devfs_populate (dm=) at /usr/src/sys/fs/devfs/devfs_devs.c:662 #
Re: console in 11.0-ALPHA4
Ed, For once, we have pretty good VGL support in the libSDL, at least version 1.x has been tested and seems to be building/working fine with sc(4)+vesa(4) on supported hardware/VMs. http://libsdl.org/download-1.2.php So pretty much any application built against SDL 1.2 library should work. Unless it uses some specific X11 stuff directly that is. For what it's worth, I also have direct vgl support in my pet project here: https://github.com/sobomax/digger ) -Max On Tue, Jun 21, 2016 at 6:29 AM, Ed Maste wrote: > On the topic of vgl(3) specifically, in October 2014 I wrote on this list: > > > vgl(3) is a graphics library for syscons(4) that provides some basic > > graphics operations (e.g. some mode setting, bitmaps, boxes, > > ellipses). Right now it does not support the newer vt(4) console. > > > > In order to help determine the priority of a porting effort to add > > vt(4) support I'd like to better understand where vgl is being used > > now. I'd be interested in hearing about both open source software > > using vgl as well as proprietary or internal applications. So if > > you're using vgl I'd appreciate a follow up (in private is fine) with > > a brief description of your use case. > > That received exactly one private reply, where it was pointed out that > dosbox is an example consumer. Nobody replied to say they actually use > vgl(3). > > I will post a followup to -stable to ask the same question, but > please, let me know if you use vgl(3) in open source or proprietary > software. > ___ > 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" > > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft ___ 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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On Tue, 2016-06-21 at 15:30 -0700, Mark Millard wrote: > Ian Lepore ian at freebsd.org wrote on Tue Jun 21 17:55:28 UTC 2016 > : > > > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > > > Em 21/06/2016 07:33, Keith White escreveu: > > > > In an earlier message Ian said that he thought he knew what the > > > > problem was... > > > > > > Here the problem occurs when using wifi. I do not have tested > > > wired > > > because I don't have a cable here. > > > > > > > > > []'s > > > > > > -Otacilio > > > > The wifi alignment fault should be fixed as of r302064. Sorry it > > took > > so long. > > > > -- Ian > > > > FYI: I've not had any -r301975 problems with WiFi on my rpi2. > > But I cross build for TARGET_ARCH=armv6 with: > > > XCFLAGS+= -march=armv7-a -mcpu=cortex-a7 > > XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 > > (And similarly for self-hosted.) It may be that the -march and/or > -mcpu matter to the code generation and explain my lack of problems. > > The builds also have INVARIANTS and WITNESS off. > > === > Mark Millard > markmi at dsl-only.net INVARIANTS being on was one of the things required to trigger the alignment fault. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On Tue, 21 Jun 2016, Ian Lepore wrote: On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: Em 21/06/2016 07:33, Keith White escreveu: In an earlier message Ian said that he thought he knew what the problem was... Here the problem occurs when using wifi. I do not have tested wired because I don't have a cable here. []'s -Otacilio The wifi alignment fault should be fixed as of r302064. Sorry it took so long. -- Ian Many thanks Ian! Yes, this has fixed the problem. No more panics on ssh to rpi-b. ...keith ___ 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"
(beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
Ian Lepore ian at freebsd.org wrote on Tue Jun 21 17:55:28 UTC 2016 : > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > > Em 21/06/2016 07:33, Keith White escreveu: > > > In an earlier message Ian said that he thought he knew what the > > > problem was... > > > > Here the problem occurs when using wifi. I do not have tested wired > > because I don't have a cable here. > > > > > > []'s > > > > -Otacilio > > The wifi alignment fault should be fixed as of r302064. Sorry it took > so long. > > -- Ian > FYI: I've not had any -r301975 problems with WiFi on my rpi2. But I cross build for TARGET_ARCH=armv6 with: > XCFLAGS+= -march=armv7-a -mcpu=cortex-a7 > XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 (And similarly for self-hosted.) It may be that the -march and/or -mcpu matter to the code generation and explain my lack of problems. The builds also have INVARIANTS and WITNESS off. === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: WITH_SYSTEM_COMPILER default on
Bryan Drewery bdrewery at FreeBSD.org wrote on Tue Jun 21 19:03:46 UTC 2016 :
> This feature is where the bootstrap compiler in buildworld is not built
> if the one in /usr/bin/cc matches what would be built. It is very
> conservative and requires a complete match of major/minor version and
> the compiler revision (__FreeBSD_cc_version).
>
> The only complaint so far about this feature was that when we bumped the
> compiler revision, too much of clang would rebuild. That was addressed
> in r301277.
>
> I would like to enable this feature by default in head for 11.0.
>
> Unless there are any objections I will do so in a few days.
>
> --
> Regards,
> Bryan Drewery
I've only been using WITH_SYSTEM_COMPILER= for system-clang based builds with
the host matching TARGET_ARCH ("self hosted").
For xtoolchain use (self-hosted or not) I've been using in my src.conf files
for such contexts:
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
For cross builds (all being amd64 -> something else, such as armv6, powerpc64,
or powerpc) based on using some build of the system clang 3.8.0 I've been using:
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
WITH_BINUTILS_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
As I understand the history the paths for finding tools, headers, etc. built
into the clang cross compiler were not necessarily the same as for the live the
system compiler that has paths appropriate specifically to self-hosting. This
helped avoid getting the wrong versions of files involved.
This was true despite the normal clang code generation being able to target
other architectures.
As for self-hosted system-clang based builds I've been using:
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
WITH_BINUTILS_BOOTSTRAP=
#WITH_CLANG_BOOTSTRAP=
(So in this case I've left some things implicit in operation.)
As stands I'll not notice the SYSTEM_COMPILER default's consequences because
I'm always explicit about WITH vs. WITHOUT for SYSTM_COMPILER. If you want some
sort of experiment(s), let me know.
But I only currently have an amd64 context and a rpi2 armv6 context. The
dual-proessor, each dual-core powerpc64 was much faster at self-hosted
xtoolchain builds compared to any self-hosted rpi2 build but I do not have
access to the powerpc family for now. Self-hosted amd64 xtoolchain builds do
not work yet for normal settings: duplicate declarations tend to stop the
builds if one leaves on the warnings-as-errors status for buildkernel. (At
least last that I tried such.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libpam.so lost in update to 11.0-ALPHA3
On 6/16/16 3:35 PM, Bryan Drewery wrote: > On 6/16/16 11:39 AM, Florian Ermisch wrote: >> >> >> Am 14. Juni 2016 13:36:32 MESZ, schrieb Ben Woods : >>> On Tuesday, 14 June 2016, Pavel Timofeev wrote: >>> 14 июня 2016 г. 10:37 пользователь "Ben Woods" >>> > написал: > > On 14 June 2016 at 09:11, René Ladan >>> > wrote: > >> Hi, >> >> I updated my pkgbase installation (11.0-amd64 from a few weeks >>> ago) to >> 11.0-ALPHA3. Building and installing went fine but it turns out >>> that >> libpam.so* is lost in the update (both the symlink and the >>> actual so, >> currently so.6) : >> >> # pkg upgrade >> # pkg autoremove >><>> one >> version lower) >> << yes, I forgot to run mergemaster>> >> # reboot >> <>> still fine) >> >> Is this a known bug? >> >> Regards, >> René >> > > Michael Lucas mentioned on twitter a few days ago that pam was >>> broken > recently in FreeBSD current. > > Michael: was this a problem with libpam.so going missing? Were you >>> using > pkgbase, or is this an issue with the normal build/install system >>> also? > > Regards, > Ben > > -- Hi! I have the same problem with normal build/install system. >>> >>> Ok, thanks for the feedback. >>> >>> Bringing in the FreeBSD-current@ mailing list as it is not a problem >>> with >>> PkgBase, but with 11-current. >>> >>> Regards, >>> Ben >>> >> On my laptop running a few weeks old CURRENT sudo >> just broke after a `pkg upgrade`. The missing lib it's >> complaining about is libpam.so.6 but when built from >> ports it's linked against libpam.so.5. >> > > > Packages built after base r301892 will be fixed. > > Actually the case of libpam.so.6 needed by sudo and your system has libpam.so.5 is just part of running head and using head packages. The head packages are built every 2 days from the latest head at that time. So packages were built using the bumped libpam.so.6 but your system didn't yet have that so sudo failed to work. The only good way to fix this is to not be splitting our dependencies up so that some are not in the package set. Meaning, not having base libraries and moving everything into the same ports/pkg system. Which by the way is *not* what pkgbase does in its current form since we're using 2 repositories that have different dependencies between them. We would need a single repository, or not be removing old versions from both and pkg supporting multiple versions from remotes. I don't see the first happening due to secteam/re needs of controlling the base system builds, and I don't see the latter happening soon. The __FreeBSD_version bump in r301892 only fixed the sudo package still wanting libpam.so.5 rather than the bumped libpam.so.6. Packages on head have several issues. Technically after upgrading your world/kernel the only safe thing to do with packages is to reinstall all of them to ensure they are all ABI-compatible with pkg upgrade -f. Even then because of the 2 day delay there is risk of not having it all be compatible. Pkg could use more logic to handle all of this better, perhaps by comparing __FreeBSD_version numbers of local and remote and not upgrading past it. I don't know. -- Regards, Bryan Drewery ___ 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"
Heads Up: struct disk KBI change
This will break binary compatibility for loadable modules that depend on struct disk. DISK_VERSION has been bumped, and I bumped __FreeBSD_version in a subsequent change. So, if you have module that uses struct disk, you'll need to recompile against the latest version of head. Ken - Forwarded message from "Kenneth D. Merry" - Date: Tue, 21 Jun 2016 20:18:19 + (UTC) From: "Kenneth D. Merry" To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r302069 - head/sys/geom Author: ken Date: Tue Jun 21 20:18:19 2016 New Revision: 302069 URL: https://svnweb.freebsd.org/changeset/base/302069 Log: Fix a bug that caused da(4) instances to hang around after the underlying device is gone. The problem was that when disk_gone() is called, if the GEOM disk creation process has not yet happened, the withering process couldn't start. We didn't record any state in the GEOM disk code, and so the d_gone() callback to the da(4) driver never happened. The solution is to track the state of the creation process, and initiate the withering process from g_disk_create() if the disk is being created. This change does add fields to struct disk, and so I have bumped DISK_VERSION. geom_disk.c: Track where we are in the disk creation process, and check to see whether our underlying disk has gone away or not. In disk_gone(), set a new d_goneflag variable that g_disk_create() can check to see if it needs to clean up the disk instance. geom_disk.h:Add a mutex to struct disk (for internal use) disk init level, and a gone flag. Bump DISK_VERSION because the size of struct disk has changed and fields have been added at the beginning. Sponsored by: Spectra Logic Approved by: re (marius) Modified: head/sys/geom/geom_disk.c head/sys/geom/geom_disk.h - End forwarded message - -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ALPHA4-amd64-r301975 UFS crashes on VMware Wks
Hello community, ( sorry for my bad english lang skills ) I would like to report problem with FreeBSD-11.0-ALPHA4-amd64-20160617-r301975. After clean install, while trying to install any binary packages with pkg (ex: pkg install xorg ) Kernel crashes happen usually during any disk intensive operation. ( pkg upgrade wanted to upgrade two packages - get text and python27 ) Crash occured immediatelly after confirming pkg to continue ( y/N ) Jun 21 18:53:58 Auriga pkg: gettext-runtime upgraded: 0.19.7 -> 0.19.8.1 Jun 21 18:53:59 Auriga kernel: lock order reversal: Jun 21 18:53:59 Auriga kernel: 1st 0xf80033631068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 Jun 21 18:53:59 Auriga kernel: 2nd 0xfe00f625e170 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 Jun 21 18:53:59 Auriga kernel: 3rd 0xf80033499068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 Jun 21 18:53:59 Auriga kernel: stack backtrace: Jun 21 18:53:59 Auriga kernel: #0 0x80aa7320 at witness_debugger+0x70 Jun 21 18:53:59 Auriga kernel: #1 0x80aa7214 at witness_checkorder+0xe54 Jun 21 18:53:59 Auriga kernel: #2 0x80a206d2 at __lockmgr_args+0x4c2 Jun 21 18:53:59 Auriga kernel: #3 0x80d09426 at ffs_lock+0xa6 Jun 21 18:53:59 Auriga kernel: #4 0x81014f2a at VOP_LOCK1_APV+0xea Jun 21 18:53:59 Auriga kernel: #5 0x80b17b8a at _vn_lock+0x9a Jun 21 18:53:59 Auriga kernel: #6 0x80b07fb3 at vget+0x63 Jun 21 18:53:59 Auriga kernel: #7 0x80afa84c at vfs_hash_get+0xcc Jun 21 18:53:59 Auriga kernel: #8 0x80d05130 at ffs_vgetf+0x40 Jun 21 18:53:59 Auriga kernel: #9 0x80cfca21 at softdep_sync_buf+0xb51 Jun 21 18:53:59 Auriga kernel: #10 0x80d0a016 at ffs_syncvnode+0x256 Jun 21 18:53:59 Auriga kernel: #11 0x80ce0d83 at ffs_truncate+0x8d3 Jun 21 18:53:59 Auriga kernel: #12 0x80d11741 at ufs_direnter+0x681 Jun 21 18:53:59 Auriga kernel: #13 0x80d1aa59 at ufs_makeinode+0x5e9 Jun 21 18:53:59 Auriga kernel: #14 0x80d165e3 at ufs_create+0x33 Jun 21 18:53:59 Auriga kernel: #15 0x8101281b at VOP_CREATE_APV+0xdb Jun 21 18:53:59 Auriga kernel: #16 0x80b173d8 at vn_open_cred+0x2f8 Jun 21 18:53:59 Auriga kernel: #17 0x80b1075c at kern_openat+0x25c Jun 21 18:54:01 Auriga pkg: python27 upgraded: 2.7.11_2 -> 2.7.11_3 After executing "pkg install xorg" - three crashes happened during installation. Running on VMware 12 Workstation. FreeBSD 10.3 RELEASE, Debian Linux, Windows running there without any problems. Is possible that filesystem is damaged/inconsistent after these crashes ? data lost etc ? Karel ( FBSD newbie ) ___ 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: PostgreSQL performance on FreeBSD
Thanks, Konstantin for the great work, we are definitely looking forward to get all those improvements to be part of the default FreeBSD kernel/port. Would be nice if you can post an update some day later as to what's integrated and what's not. Just in case, I've opened #14206 with PG to switch us to using POSIX semaphores by default. Apart from the mentioned performance benefits, SYSV semaphores are PITA to deal with as they come in very limited quantities by default. Also they might stay around if PG dies/gets nuked and prevent it from starting again due to overflow. We've got some quite ugly code to clean up those using ipcrm(1) in our build scripts to deal with just that. I am happy that code could be retired now. -Maxim On Fri, Jun 3, 2016 at 11:53 AM, John Baldwin wrote: > On Friday, June 03, 2016 11:29:03 AM Adrian Chadd wrote: > > On 3 June 2016 at 11:27, Adrian Chadd wrote: > > > > > That and the other NUMA stuff is something to address in -12. > > > > And, I completely welcome continued development in NUMA scaling in > > combination with discussion. The iterator changes I committed are a > > more generic version of a patch people were applying on top of -10 and > > -head for at least what, three years now? Maybe more if -9 also just > > did round-robin and not first-touch? > > 8 and 9 did first-touch. Only 10 did round-robin. > > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ 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: console in 11.0-ALPHA4
P.S. On more of IMHO side, I think having simple built in console graphics library is quite important in order for kids to actually explore FreeBSD early. I remember learning my first computer in elementary, with only few KB of RAM it had BASIC interpreter built in and could already do basic graphics primitives with just few lines of code. And that's what we had explored quite early in the learning process. Computers we are running on today are literally million times more powerful that that, both hardware and software-wise, still you should not need to install whole X11 monstrosity to write graphics version of "hello world". In any case if somebody is to add vt(4) support into libvgl, I could probably help with testing that as well as possibly porting it to SDL 2.0. My reduction of interest to maintaining that support has been generally caused by the vesa going out of scope gradually, but with vt it might actually revive it by opening it up for getting it running on most today's x86 hardware and smaller arm systems as well. -Max On Tue, Jun 21, 2016 at 11:33 AM, Maxim Sobolev wrote: > Ed, > > For once, we have pretty good VGL support in the libSDL, at least version > 1.x has been tested and seems to be building/working fine with > sc(4)+vesa(4) on supported hardware/VMs. > > http://libsdl.org/download-1.2.php > > So pretty much any application built against SDL 1.2 library should work. > Unless it uses some specific X11 stuff directly that is. > > For what it's worth, I also have direct vgl support in my pet project > here: https://github.com/sobomax/digger ) > > -Max > > On Tue, Jun 21, 2016 at 6:29 AM, Ed Maste wrote: > >> On the topic of vgl(3) specifically, in October 2014 I wrote on this list: >> >> > vgl(3) is a graphics library for syscons(4) that provides some basic >> > graphics operations (e.g. some mode setting, bitmaps, boxes, >> > ellipses). Right now it does not support the newer vt(4) console. >> > >> > In order to help determine the priority of a porting effort to add >> > vt(4) support I'd like to better understand where vgl is being used >> > now. I'd be interested in hearing about both open source software >> > using vgl as well as proprietary or internal applications. So if >> > you're using vgl I'd appreciate a follow up (in private is fine) with >> > a brief description of your use case. >> >> That received exactly one private reply, where it was pointed out that >> dosbox is an example consumer. Nobody replied to say they actually use >> vgl(3). >> >> I will post a followup to -stable to ask the same question, but >> please, let me know if you use vgl(3) in open source or proprietary >> software. >> ___ >> 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 >> " >> >> > > > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > Tel (Canada): +1-778-783-0474 > Tel (Toll-Free): +1-855-747-7779 > Fax: +1-866-857-6942 > Web: http://www.sippysoft.com > MSN: sa...@sippysoft.com > Skype: SippySoft > ___ 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"
WITH_SYSTEM_COMPILER default on
This feature is where the bootstrap compiler in buildworld is not built if the one in /usr/bin/cc matches what would be built. It is very conservative and requires a complete match of major/minor version and the compiler revision (__FreeBSD_cc_version). The only complaint so far about this feature was that when we bumped the compiler revision, too much of clang would rebuild. That was addressed in r301277. I would like to enable this feature by default in head for 11.0. Unless there are any objections I will do so in a few days. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > Em 21/06/2016 07:33, Keith White escreveu: > > In an earlier message Ian said that he thought he knew what the > > problem was... > > Here the problem occurs when using wifi. I do not have tested wired > because I don't have a cable here. > > > []'s > > -Otacilio The wifi alignment fault should be fixed as of r302064. Sorry it took so long. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: BBB (cpsw(4)) seems to be broken in the latest 11-current
On Jun 20, 2016, at 6:33 PM, Keith White wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > >> On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >>> Jim, some update from here. Running r283287 of the driver, I still see the >>> same "watchdog timeout" messages, but they do not lead to the interface >>> lockout. The traffic resumes momentarily. Which is probably why I never paid >>> much attention to those warnings before. Therefore, I suspect that the new >>> MAC code does not deal with watchdog-triggered interface reset as good as >>> the old code. Does it give you any ideas about what could be wrong there by >>> any chance? >> >> >> Hi Maxim, >> >> My recent changes contributed somehow to expose the bug more frequently. >> >> There was a condition in tx packet reclamation where we aren't >> restarting the tx queue in one of the possible stall conditions. >> >> Please try the attached patch and let me know if it works for you. >> >> Luiz > > Your patch fixes the problem for me. Thanks! > > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 > 18:19:55 EDT 2016 > kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm armv6 > > ...keith The patch also fixes the problem for me. FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #2 r302030M: Tue Jun 21 10:20:59 EDT 2016 pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm Cheers, Paul. ___ 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: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory
On Tue, Jun 21, 2016 at 9:55 AM, Jan Bramkamp wrote: > On 18/06/16 17:15, Alan Somers wrote: >> >> On Thu, Jun 16, 2016 at 7:20 AM, Chris H wrote: >>> >>> On Wed, 15 Jun 2016 08:03:55 -0400 Nikolai Lifanov >>> >>> wrote >>> On 06/14/2016 21:05, Marcelo Araujo wrote: > > 2016-06-15 8:17 GMT+08:00 Chris H : > >> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo >> >> wrote >> >>> Hey, >>> >>> Thanks for the CFT Craig. >>> >>> 2016-06-09 14:41 GMT+08:00 Xin Li : >>> On 6/8/16 23:10, Craig Rodrigues wrote: > > Hi, > > I have worked with Marcelo Araujo to port OpenBSD's ypldap to > FreeBSD > current. > > In latest current, it should be possible to put in /etc/rc.conf: > > nis_ypldap_enable="YES" > to activate the ypldap daemon. > > When set up properly, it should be possible to log into FreeBSD, > and >> >> have > > the backend password database come from an LDAP database such > as OpenLDAP > > There is some documentation for setting this up, but it is OpenBSD specific: > > > http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client > http://puffysecurity.com/wiki/ypldap.html#2 > > I did not bother porting the OpenBSD LDAP server to FreeBSD, so > that > information > does not apply. I figure that openldap from ports should work > fine. > > I was wondering if there is someone out there familiar enough with >> >> LDAP > > and has a setup they can test this stuff out with, provide > feedback, >> >> and > > help > improve the documentation for FreeBSD? Looks like it would be a fun weekend project. I've cc'ed a potential person who may be interested in this as well. But will this worth the effort? (I think the current implementation would do everything with plaintext protocol over wire, so while it extends life for legacy applications that are still using NIS/YP, it doesn't seem to be something that we should recommend end user to use?) >>> >>> I can see two good point to use ypldap that would be basically for >>> users >>> that needs to migrate from NIS to LDAP or need to make some >>> integration >>> between legacy(NIS) and LDAP during a transition period to LDAP. >>> >>> As mentioned, NIS is 'plain text' not safe by its nature, however >>> there >> >> are >>> >>> still lots of people out there using NIS, and ypldap(8) is a good >>> tool to >>> help these people migrate to a more safe tool like LDAP. >>> >>> > I would also be interested in hearing from someone who can see if > ypldap can work against a Microsoft Active Directory setup? Cheers, >>> All my tests were using OpenLDAP, I used the OpenBSD documentation to >> >> setup >>> >>> everything, and the file share/examples/ypldap/ypldap.conf can be a >>> good >>> start to anybody that wants to start to work with ypldap(8). >>> >>> Would be nice hear from other users how was their experience using >>> ypldap >>> with MS Active Directory and perhaps some HOWTO how they made all the >> >> setup >>> >>> would be amazing to have. >>> >>> Also, would be useful to know who are still using NIS and what kind >>> of >>> setup(user case), maybe even the reason why they are still using it. >> >> >> Honestly, I think the best way to motivate people to do the right >> thing(tm) Would be to remove Yellow Pages from the tree, entirely. :-) >> It's been dead for *years*, and as you say, isn't safe, anyway.. >> > > Yes, I have a plan for that, but I don't believe it will happens before > FreeBSD 12-RELEASE. > Please don't, at least for now. NIS is fast, simple, reliable, and works on first boot without additional software. I have passwords in Kerberos, so the usual cons doesn't apply. This is very valuable to me. It's not hurting anyone. What's the motivation behind removing it? >>> >>> >>> In all honesty, my comment was somewhat tongue-in-cheek. But from >>> a purely maintenance POV, at this point in time. I think the Yellow >>> Pages are better suited for the ports tree, than in $BASE. >>> >> >> It will be hard to wean people off of NIS as long as KGSSAPI is >> disabled in GENERIC. Does anybody know why it isn't enabled by >> default? > > > Because it's just a `kldload kgssapi` away. Put it in loader.conf or rc.conf > depending on your needs/preferences. Thanks Jan. I didn
Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory
On 18/06/16 17:15, Alan Somers wrote: On Thu, Jun 16, 2016 at 7:20 AM, Chris H wrote: On Wed, 15 Jun 2016 08:03:55 -0400 Nikolai Lifanov wrote On 06/14/2016 21:05, Marcelo Araujo wrote: 2016-06-15 8:17 GMT+08:00 Chris H : On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo wrote Hey, Thanks for the CFT Craig. 2016-06-09 14:41 GMT+08:00 Xin Li : On 6/8/16 23:10, Craig Rodrigues wrote: Hi, I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD current. In latest current, it should be possible to put in /etc/rc.conf: nis_ypldap_enable="YES" to activate the ypldap daemon. When set up properly, it should be possible to log into FreeBSD, and have the backend password database come from an LDAP database such as OpenLDAP There is some documentation for setting this up, but it is OpenBSD specific: http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client http://puffysecurity.com/wiki/ypldap.html#2 I did not bother porting the OpenBSD LDAP server to FreeBSD, so that information does not apply. I figure that openldap from ports should work fine. I was wondering if there is someone out there familiar enough with LDAP and has a setup they can test this stuff out with, provide feedback, and help improve the documentation for FreeBSD? Looks like it would be a fun weekend project. I've cc'ed a potential person who may be interested in this as well. But will this worth the effort? (I think the current implementation would do everything with plaintext protocol over wire, so while it extends life for legacy applications that are still using NIS/YP, it doesn't seem to be something that we should recommend end user to use?) I can see two good point to use ypldap that would be basically for users that needs to migrate from NIS to LDAP or need to make some integration between legacy(NIS) and LDAP during a transition period to LDAP. As mentioned, NIS is 'plain text' not safe by its nature, however there are still lots of people out there using NIS, and ypldap(8) is a good tool to help these people migrate to a more safe tool like LDAP. I would also be interested in hearing from someone who can see if ypldap can work against a Microsoft Active Directory setup? Cheers, All my tests were using OpenLDAP, I used the OpenBSD documentation to setup everything, and the file share/examples/ypldap/ypldap.conf can be a good start to anybody that wants to start to work with ypldap(8). Would be nice hear from other users how was their experience using ypldap with MS Active Directory and perhaps some HOWTO how they made all the setup would be amazing to have. Also, would be useful to know who are still using NIS and what kind of setup(user case), maybe even the reason why they are still using it. Honestly, I think the best way to motivate people to do the right thing(tm) Would be to remove Yellow Pages from the tree, entirely. :-) It's been dead for *years*, and as you say, isn't safe, anyway.. Yes, I have a plan for that, but I don't believe it will happens before FreeBSD 12-RELEASE. Please don't, at least for now. NIS is fast, simple, reliable, and works on first boot without additional software. I have passwords in Kerberos, so the usual cons doesn't apply. This is very valuable to me. It's not hurting anyone. What's the motivation behind removing it? In all honesty, my comment was somewhat tongue-in-cheek. But from a purely maintenance POV, at this point in time. I think the Yellow Pages are better suited for the ports tree, than in $BASE. It will be hard to wean people off of NIS as long as KGSSAPI is disabled in GENERIC. Does anybody know why it isn't enabled by default? Because it's just a `kldload kgssapi` away. Put it in loader.conf or rc.conf depending on your needs/preferences. ___ 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"
geom_part: support < 128 GPT partition entries
Hi, I'd appreciate a review for: https://reviews.freebsd.org/D6900 Summary: This change is useful primarily for using GPT on embedded boards like the pine64 (and others using an Allwinner SoC) that want a firmware image loaded below sector 34 (8K in that instance). Note that because this changes g_part_scheme, it breaks the ABI. Thanks! -- wca signature.asc Description: PGP signature
Re: Intel Atom I2C
Hi, On 07:05 Tue 21 Jun , Lundberg, Johannes wrote: > Hi Imre > > Thanks for the info! May I ask, isn't your system UEFI, same as mine? Last > I tried DragonFly didn't support UEFI... Yes, the HP x2 210 is UEFI only, but DragonFly *can* boot from UEFI :) I did a port of FreeBSD's UEFI bootloader to DragonFly, which I commited ca. 2 months ago, and I added basic support in the kernel for UEFI booting. Only UEFI support in DragonFly's installer is still missing :( > > I also had hangs when probing certain I2C controller (maybe it was the > 7th...) > > Perhaps using linuxkpi and the linux driver would be a good option for > this. i915 uses I2C and it works with basically unmodified Intel source > code. Or maybe I try to port your efforts later :) It's not really an option here, to use the linux driver, since this I2c bus has to integrate tightly with the operating-system for the ACPI operation region handling, and the I2cSerialBus resource handling. > On Tue, Jun 21, 2016 at 7:00 AM, Imre Vadasz wrote: > > > So autodetection via smbus(4) probably shouldn't be used at all for this > > kind of I2c/smbus. > > On my HP x2 210 Cherryview tablet it even causes the system to hard freeze, > > when running the autodetection on the 7th I2C controller. > > > > Imre > > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 > もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 > 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. ___ 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: 11.0-ALPHA4 and VIMAGE
On 20/06/16 18:05, Bjoern A. Zeeb wrote: Hi, On 20 Jun 2016, at 15:37, Ernie Luzar wrote: Hello list; I have installed 11.0-ALPHA4-i386-20160617-r301975 to test VIMAGE. I have read previous list posts saying vimage was going to be part of the base system in 11.0. When I configure a jail with vnet I get a error typical of vimage not being compiled into the kernel. To me it looks like vimage is not part of the base system in 11.0. What is the status of vimage in 11.0? I am not sure anyone said that it would be in GENERIC for 11.0. The plan is to have it more stable and leak a lot less memory possibly and some bits made it in to HEAD over the last months already, another patch for a top-down teardown is in the review system, and I am currently working on fixing a lot of pf. Is there any hope reliable VIMAGE support will make it into the 11.0 release? ___ 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: Intel Atom I2C
Hi Imre Thanks for the info! May I ask, isn't your system UEFI, same as mine? Last I tried DragonFly didn't support UEFI... I also had hangs when probing certain I2C controller (maybe it was the 7th...) Perhaps using linuxkpi and the linux driver would be a good option for this. i915 uses I2C and it works with basically unmodified Intel source code. Or maybe I try to port your efforts later :) On Tue, Jun 21, 2016 at 7:00 AM, Imre Vadasz wrote: > So autodetection via smbus(4) probably shouldn't be used at all for this > kind of I2c/smbus. > On my HP x2 210 Cherryview tablet it even causes the system to hard freeze, > when running the autodetection on the 7th I2C controller. > > Imre > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ 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: Intel Atom I2C
So autodetection via smbus(4) probably shouldn't be used at all for this kind of I2c/smbus. On my HP x2 210 Cherryview tablet it even causes the system to hard freeze, when running the autodetection on the 7th I2C controller. Imre ___ 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: Intel Atom I2C
Hi, No driver for the DMA controller is needed for using the I2C controllers. On many devices the I2C controllers are only mapped as ACPI devices, and not as PCI-devices, but the existing ichiic driver can trivially be adapted to attach via acpi, which is already done by DragonFly's ichiic: https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/sys/bus/smbus/ichiic/ig4_acpi.c On many Cherryview devices, the I2C controller driver needs to install a handler for ACPI accesses to I2cSerialBus fields inside of GenericSerialBus operation regions. I have already committed the I2cSerialBus operation region Field handling to DraognFly master (implemented by the smbacpi(4) driver which attaches as a child to ichiic: https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/sys/bus/smbus/smbacpi/smbacpi.c) The I2cSerialBus operation region Field handling is e.g. needed on the HP X2 210 tablet/detachable for the AC adapter and ACPI battery devices, as well as for activating power on the external micro-sd card slot via the sdhc controller's _PS0 ACPI-method. Peripheral devices hanging on the I2c busses usually are detected as ACPI devices, which have I2cSerialBus resource entries. On current Cherryview devices the I2c peripheral devices usually aren't explicitly child devices of the I2c-Controller devices, but the I2cSerialBus resources contain a string which can be dereferenced to get the corresponding I2c-bus device. The same mechanism is used for mapping GPIO pins and GPIO interrupts (with the GpioInt and GpioIo resource entries). Also, since the I2c peripheral devices usually are no longer children of the I2c-bus, the correct device attachement/initialization order needs to be derived via the _DEP acpi methods. ___ 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: console in 11.0-ALPHA4
On the topic of vgl(3) specifically, in October 2014 I wrote on this list: > vgl(3) is a graphics library for syscons(4) that provides some basic > graphics operations (e.g. some mode setting, bitmaps, boxes, > ellipses). Right now it does not support the newer vt(4) console. > > In order to help determine the priority of a porting effort to add > vt(4) support I'd like to better understand where vgl is being used > now. I'd be interested in hearing about both open source software > using vgl as well as proprietary or internal applications. So if > you're using vgl I'd appreciate a follow up (in private is fine) with > a brief description of your use case. That received exactly one private reply, where it was pointed out that dosbox is an example consumer. Nobody replied to say they actually use vgl(3). I will post a followup to -stable to ask the same question, but please, let me know if you use vgl(3) in open source or proprietary software. ___ 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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
[A top-post of a new result: WiFI works fine too. Quotes are from input/output, with some redacting. This is the first time I've set up WiFi on FreeBSD.] WiFI (urtwn0) also works fine for me with ssh on the rpi2 11.0 -r301975 context. . . > urtwn0: on > usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > # ifconfig . . . > wlan0: flags=8843 metric 0 mtu 1500 > ether > inet 192.168.0.122 netmask 0xff00 broadcast 192.168.0.255 > groups: wlan > ssid "Millard's AirPort2" channel 11 (2462 MHz 11g ht/20) bssid > regdomain FCC country US authmode WPA2/802.11i privacy ON > deftxkey UNDEF TKIP 3:128-bit txpower 30 bmiss 7 scanvalid 60 > protmode CTS ht20 -ampdutx ampdurx ampdulimit 64k ampdudensity 4 -stbc > wme roaming MANUAL > media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > status: associated > nd6 options=29 An ssh markmi@192.168.0.122 into the rpi2 from Mac OS X's terminal worked fine: > Warning: Permanently added '192.168.0.122' (ECDSA) to the list of known hosts. > Password for markmi@rpi2: > Last login: Tue Jun 21 01:04:54 2016 from 192.168.0.105 > FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 > > Welcome to FreeBSD! > > Release Notes, Errata: https://www.FreeBSD.org/releases/ > Security Advisories: https://www.FreeBSD.org/security/ > FreeBSD Handbook: https://www.FreeBSD.org/handbook/ > FreeBSD FAQ: https://www.FreeBSD.org/faq/ > Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ > FreeBSD Forums:https://forums.FreeBSD.org/ > > Documents installed with the system are in the /usr/local/share/doc/freebsd/ > directory, or can be installed later with: pkg install en-freebsd-doc > For other languages, replace "en" with a language code like de or fr. > > Show the version of FreeBSD installed: freebsd-version ; uname -a > Please include that output and any error messages when posting questions. > Introduction to manual pages: man man > FreeBSD directory layout: man hier > > Edit /etc/motd to change this login announcement. > You can look through a file in a nice text-based interface by typing > > less filename > $ The problem is apparently not general to all armv6 WiFi contexts. I'll note that I did not disable or unplug the wired Ethernet. === Mark Millard markmi at dsl-only.net On 2016-Jun-21, at 4:14 AM, Mark Millard wrote: > On 2016-Jun-21, at 3:33 AM, Keith White wrote: > >> On Tue, 21 Jun 2016, Mark Millard wrote: >> >>> Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 : >>> > The kernel panic is totally reproducible. I need only do a ssh in the > beaglebone using ptty on windows or ssh on freebsd and the kernel > panic > is raised. >>> . . . FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to raise the fault is ssh in the beaglebone. >>> >>> (After this quotes are command input/output from my test activity.) >>> >>> Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . . >>> # uname -apKU FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm armv6 1100117 1100117 >>> >>> >>> This is a no-debug kernel build (but with symbols). Details are given later >>> below. >>> # ssh markmi@192.168.0.105 Password: Last login: Tue Jun 21 01:04:46 2016 markmi$ >>> >>> Similarly I can ssh into the rpi2 from outside, here using new remote >>> connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . >>> Password for markmi@rpi2: Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ FreeBSD Forums:https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier Edit /etc/motd to change this login announcement. To determine whether a file is a text file, executable, or some other type of file, use file filen
Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On 2016-Jun-21, at 3:33 AM, Keith White wrote:
> On Tue, 21 Jun 2016, Mark Millard wrote:
>
>> Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 :
>>
>>> > The kernel panic is totally reproducible. I need only do a ssh in the
>>> > beaglebone using ptty on windows or ssh on freebsd and the kernel > panic
>>> > is raised.
>> . . .
>>> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to
>>> raise the fault is ssh in the beaglebone.
>>
>> (After this quotes are command input/output from my test activity.)
>>
>> Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . .
>>
>>> # uname -apKU
>>> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16
>>> 18:12:02 PDT 2016
>>> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm
>>> armv6 1100117 1100117
>>
>>
>> This is a no-debug kernel build (but with symbols). Details are given later
>> below.
>>
>>> # ssh markmi@192.168.0.105
>>> Password:
>>> Last login: Tue Jun 21 01:04:46 2016
>>> markmi$
>>
>> Similarly I can ssh into the rpi2 from outside, here using new remote
>> connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . .
>>
>>> Password for markmi@rpi2:
>>> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1
>>> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016
>>> Welcome to FreeBSD!
>>> Release Notes, Errata: https://www.FreeBSD.org/releases/
>>> Security Advisories: https://www.FreeBSD.org/security/
>>> FreeBSD Handbook: https://www.FreeBSD.org/handbook/
>>> FreeBSD FAQ: https://www.FreeBSD.org/faq/
>>> Questions List:
>>> https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
>>> FreeBSD Forums:https://forums.FreeBSD.org/
>>> Documents installed with the system are in the /usr/local/share/doc/freebsd/
>>> directory, or can be installed later with: pkg install en-freebsd-doc
>>> For other languages, replace "en" with a language code like de or fr.
>>> Show the version of FreeBSD installed: freebsd-version ; uname -a
>>> Please include that output and any error messages when posting questions.
>>> Introduction to manual pages: man man
>>> FreeBSD directory layout: man hier
>>> Edit /etc/motd to change this login announcement.
>>> To determine whether a file is a text file, executable, or some other type
>>> of file, use
>>>
>>> file filename
>>> -- Dru
>>> $
>>
>> No panics or other odd notices.
>>
>> The problem is apparently not general to all armv6 contexts.
>>
>> Various context details follow. . .
>>
>>> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host TO_TYPE=armv6
>>> #
>>> KERNCONF=RPI2-NODBG
>>> TARGET=arm
>>> .if ${.MAKE.LEVEL} == 0
>>> TARGET_ARCH=${TO_TYPE}
>>> .export TARGET_ARCH
>>> .endif
>>> #
>>> #WITH_CROSS_COMPILER=
>>> WITH_SYSTEM_COMPILER=
>>> #
>>> #CPUTYPE=soft
>>> WITH_LIBSOFT=
>>> WITH_LIBCPLUSPLUS=
>>> WITH_BINUTILS_BOOTSTRAP=
>>> #WITHOUT_CLANG_BOOTSTRAP=
>>> WITH_CLANG=
>>> WITH_CLANG_IS_CC=
>>> WITH_CLANG_FULL=
>>> WITH_CLANG_EXTRAS=
>>> WITH_LLDB=
>>> #
>>> WITH_BOOT=
>>> WITHOUT_LIB32=
>>> #
>>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
>>> WITHOUT_GCC_BOOTSTRAP=
>>> WITHOUT_GCC=
>>> WITHOUT_GCC_IS_CC=
>>> WITHOUT_GNUCXX=
>>> #
>>> NO_WERROR=
>>> #WERROR=
>>> MALLOC_PRODUCTION=
>>> #
>>> WITH_DEBUG_FILES=
>>> #
>>> XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
>>> XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
>>> # There is no XCPPFLAGS but XCPP ets XCFLAGS content.
>>
>> ~/src.configs/make.conf was empty.
>>
>>> # more /usr/src/sys/arm/conf/RPI2-NODBG
>>> #
>>> # RPI2 -- Custom configuration for the Raspberry Pi 2
>>> #
>>> # For more information on this file, please read the config(5) manual page,
>>> # and/or the handbook section on Kernel Configuration Files:
>>> #
>>> #
>>> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
>>> #
>>> # The handbook is also available locally in /usr/share/doc/handbook
>>> # if you've installed the doc distribution, otherwise always see the
>>> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
>>> # latest information.
>>> #
>>> # An exhaustive list of options and more detailed explanations of the
>>> # device lines is also present in the ../../conf/NOTES and NOTES files.
>>> # If you are in doubt as to the purpose or necessity of a line, check first
>>> # in NOTES.
>>> #
>>> ident RPI2-NODBG
>>> include "RPI2"
>>> makeoptions DEBUG=-g# Build kernel with gdb(1) debug
>>> symbols
>>> options ALT_BREAK_TO_DEBUGGER
>>> #optionsVERBOSE_SYSINIT # Enable verbose sysinit messages
>>> options KDB # Enable kernel debugger support
>>> # For minimum debugger support (stable branch) use:
>>> #optionsKDB_TRACE # Print a stack trace for a panic
>>> options DDB # Enable the kernel debugger
>>> nooptions
Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
Em 21/06/2016 07:33, Keith White escreveu: In an earlier message Ian said that he thought he knew what the problem was... Here the problem occurs when using wifi. I do not have tested wired because I don't have a cable here. []'s -Otacilio ___ 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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On Tue, 21 Jun 2016, Mark Millard wrote:
Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 :
> The kernel panic is totally reproducible. I need only do a ssh in the
> beaglebone using ptty on windows or ssh on freebsd and the kernel
> panic is raised.
. . .
FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to
raise the fault is ssh in the beaglebone.
(After this quotes are command input/output from my test activity.)
Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . .
# uname -apKU
FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 18:12:02
PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG
arm armv6 1100117 1100117
This is a no-debug kernel build (but with symbols). Details are given later
below.
# ssh markmi@192.168.0.105
Password:
Last login: Tue Jun 21 01:04:46 2016
markmi$
Similarly I can ssh into the rpi2 from outside, here using new remote
connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . .
Password for markmi@rpi2:
Last login: Mon May 9 19:27:33 2016 from 192.168.2.1
FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories: https://www.FreeBSD.org/security/
FreeBSD Handbook: https://www.FreeBSD.org/handbook/
FreeBSD FAQ: https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:https://forums.FreeBSD.org/
Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout: man hier
Edit /etc/motd to change this login announcement.
To determine whether a file is a text file, executable, or some other type
of file, use
file filename
-- Dru
$
No panics or other odd notices.
The problem is apparently not general to all armv6 contexts.
Various context details follow. . .
# more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host
TO_TYPE=armv6
#
KERNCONF=RPI2-NODBG
TARGET=arm
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
#
#CPUTYPE=soft
WITH_LIBSOFT=
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
#WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
# There is no XCPPFLAGS but XCPP ets XCFLAGS content.
~/src.configs/make.conf was empty.
# more /usr/src/sys/arm/conf/RPI2-NODBG
#
# RPI2 -- Custom configuration for the Raspberry Pi 2
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
ident RPI2-NODBG
include "RPI2"
makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols
options ALT_BREAK_TO_DEBUGGER
#optionsVERBOSE_SYSINIT # Enable verbose sysinit messages
options KDB # Enable kernel debugger support
# For minimum debugger support (stable branch) use:
#optionsKDB_TRACE # Print a stack trace for a panic
options DDB # Enable the kernel debugger
nooptions INVARIANTS # Enable calls of extra sanity checking
nooptions INVARIANT_SUPPORT # Extra sanity checks of internal
structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect deadlocks and
cycles
nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
nooptions DIAGNOSTIC
My /usr/src tree has some changes/additions --but mostly for powerpc64 and
powerpc issues:
# svnlite status /usr/src/
M /usr/src/contrib/llvm/lib/CodeGen/Sele
(beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 :
> > The kernel panic is totally reproducible. I need only do a ssh in the
> > beaglebone using ptty on windows or ssh on freebsd and the kernel
> > panic is raised.
. . .
> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to
> raise the fault is ssh in the beaglebone.
(After this quotes are command input/output from my test activity.)
Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . .
> # uname -apKU
> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 18:12:02
> PDT 2016
> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm armv6
> 1100117 1100117
This is a no-debug kernel build (but with symbols). Details are given later
below.
> # ssh markmi@192.168.0.105
> Password:
> Last login: Tue Jun 21 01:04:46 2016
> markmi$
Similarly I can ssh into the rpi2 from outside, here using new remote
connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . .
> Password for markmi@rpi2:
> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1
> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016
>
> Welcome to FreeBSD!
>
> Release Notes, Errata: https://www.FreeBSD.org/releases/
> Security Advisories: https://www.FreeBSD.org/security/
> FreeBSD Handbook: https://www.FreeBSD.org/handbook/
> FreeBSD FAQ: https://www.FreeBSD.org/faq/
> Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
> FreeBSD Forums:https://forums.FreeBSD.org/
>
> Documents installed with the system are in the /usr/local/share/doc/freebsd/
> directory, or can be installed later with: pkg install en-freebsd-doc
> For other languages, replace "en" with a language code like de or fr.
>
> Show the version of FreeBSD installed: freebsd-version ; uname -a
> Please include that output and any error messages when posting questions.
> Introduction to manual pages: man man
> FreeBSD directory layout: man hier
>
> Edit /etc/motd to change this login announcement.
> To determine whether a file is a text file, executable, or some other type
> of file, use
>
> file filename
> -- Dru
> $
No panics or other odd notices.
The problem is apparently not general to all armv6 contexts.
Various context details follow. . .
> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host
> TO_TYPE=armv6
> #
> KERNCONF=RPI2-NODBG
> TARGET=arm
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> #WITH_CROSS_COMPILER=
> WITH_SYSTEM_COMPILER=
> #
> #CPUTYPE=soft
> WITH_LIBSOFT=
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> #WITHOUT_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG_FILES=
> #
> XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
> XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
> # There is no XCPPFLAGS but XCPP ets XCFLAGS content.
~/src.configs/make.conf was empty.
> # more /usr/src/sys/arm/conf/RPI2-NODBG
> #
> # RPI2 -- Custom configuration for the Raspberry Pi 2
> #
> # For more information on this file, please read the config(5) manual page,
> # and/or the handbook section on Kernel Configuration Files:
> #
> #
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
> #
> # The handbook is also available locally in /usr/share/doc/handbook
> # if you've installed the doc distribution, otherwise always see the
> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
> # latest information.
> #
> # An exhaustive list of options and more detailed explanations of the
> # device lines is also present in the ../../conf/NOTES and NOTES files.
> # If you are in doubt as to the purpose or necessity of a line, check first
> # in NOTES.
> #
>
> ident RPI2-NODBG
>
> include "RPI2"
>
> makeoptions DEBUG=-g# Build kernel with gdb(1) debug
> symbols
> options ALT_BREAK_TO_DEBUGGER
> #optionsVERBOSE_SYSINIT # Enable verbose sysinit messages
>
> options KDB # Enable kernel debugger support
>
> # For minimum debugger support (stable branch) use:
> #optionsKDB_TRACE # Print a stack trace for a panic
> options DDB # Enable the kernel debugger
>
> nooptions INVARIANTS # Enable calls of extra sanity
> checking
> nooptions INVARIANT_SUPPORT # Extra sanity checks of internal
> structures, required by INVARIANTS
> nooptions WITNESS # Enable checks to detect deadlocks
> and cycles
> nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for
Re: console in 11.0-ALPHA4
On Mon, 20 Jun 2016 22:11:52 -0700 "Chris H" wrote: > On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin wrote > > > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: > > > Ed Maste wrote: > > > > On 20 June 2016 at 14:29, Ernie Luzar wrote: > > > >> I found the cause of this boot time message > > > >> "vicontrol: setting cursor type: Inappropriate ioctl for device" > > > >> > > > >> In my rc.conf I had this statement > > > >> vidcontrol -c blink -h 250 > > > >> From testing it seems that vt does not handle the "blink" option for > > > >> causing the cursor to blink. Is there a vt option to enable cursor > > > >> blinking > > > > > > I've submitted two PRs for the issues you reported here: > > > > Bug 210413 - vidcontrol -c does not work with > > > > vt(4) Bug 210415 - vidcontrol -h does not work with vt(4) > > > > (edit) > > > > There is currently no option to enable cursor blinking. > > > > > > > > > Further testing shows that: > > > > > > 1. The rc.conf option screen saver "saver= " and the "blanktime= " > > > options work in vt for both text and graph modes. > > > > > > 2. The cursor copy/paste does not work in vt text mode. It only works in > > > vt graph mode. vt needs to be fixed so copy/paste function also works in > > > text mode. > > > > > > 3. Boot time splash screen does not work in vt at all no matter which > > > mode is enabled. Using this in loader.conf > > > splash_bmp_load="YES" > > > bitmap_name="/boot/splash.bmp" > > > bitload_load="YES" > > > > > > This works in 10.x. The splash screen function can not be allowed to be > > > removed from the base system just because vt can not handle it. This > > > also means any vt changes need to updated in the handbook section on > > > splash screen. > > > > > > In conclusion, vt is not ready to replace the sc console driver yet. vt > > > needs to be fixed before becoming the default in 11.0. Using vt as the > > > default console driver effects every user. It completely changes the > > > FreeBSD experience. It's detrimental to the public relations and the > > > professional image of FreeBSD to publish the 11.0-RELEASE using vt in > > > its current condition. If time doesn't permit to get these vt things > > > fixed before publishing 11.0 then vt should not become the default > > > console driver. > > > > OTOH, if you use EFI, then you can't use sc(4). You get no working console > > with EFI (which is becoming more popular) if you use sc(4). You also do > > not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable > > console if you use sc(4). You also do not have a working console after > > loading the KMS drivers (either by starting X or via explicit kldload) when > > using sc(4). This affects just about every modern Intel system using an > > Intel GPU (so more widespread than EFI even). > > > > There are tradeoffs in both directions. Neither console is a subset of the > > other. However, sc(4) is not really extendable to support the things it is > > missing. vt(4) is actively worked on, and patches for the features it lacks > > that you need are certainly welcomed. > AMD, and ATI are also quite popular, as well as nVidia. In the case of > nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI. most recent nVidia BLOBs (starting with the separation of the kernel module in nvidia-modset.ko and nvidia.ko kernel object modules) do not work properly nor with sc(4), neither vt(4) on most recent CURRENT! See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201340 With non-UEFI, die console is unusable due to some weird 1980s blocky-coloured signs in 80x25 col/rows, with UEFI there is simply black screen when switching to console - this is the fact as long the nvidia-modeset.ko is loaded. After unloading, the problems disappear. And by the way: at the moment nVidia's offering of a BLOB is the only, and THE only way to provide acceptable support and performnce for recent and modern GPUs. Since many people or those making decissions are not inclined to purchase "old" but working stuff for a perspective of 3-5 years, a working console seemes to me to be important. > > I think the [original] point here was; for all that vt(4) intends to > provide, it's just not ready for prime time, and as such, shouldn't > be made default, just yet. :-) > > --Chris > > > > -- > > John Baldwin > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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"
