Re: -CURRENT fatal trap cause by cxgbe module
On Mon, Mar 2, 2020 at 6:55 PM Ryan Libby wrote: > > On Sun, Mar 1, 2020 at 8:07 PM Dustin Marquess wrote: > > > > So I've been fighting with any current from the last month or so > > instantly crashing when I boot it. I did notice that kernels in the > > various snapshot images were working, however, so I was trying to > > figure out why. At first I thought it was because I had INVARIANTS > > and such disabled, but no, I finally figured it out. > > > > I've had in my /boot/loader.conf for a while now: > > > > if_cxgbe_load="YES" > > > > I guess since the stock installer kernels don't have cxgbe enabled by > > default. I added "device cxgbe" to my kernels a while ago. Normally > > the kernel would give some error about the module already being loaded > > or something and just continue. As of last month or so, however, > > instead it just crashes: > > > > FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git > > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > > WARNING: WITNESS option enabled, expect reduced performance. > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x8 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x80622931 > > stack pointer = 0x28:0x8241c9a0 > > frame pointer = 0x28:0x8241c9e0 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = resume, IOPL = 0 > > current process = 0 () > > trap number = 12 > > panic: page fault > > cpuid = 0 > > time = 1 > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0x8241c600 > > vpanic() at vpanic+0x18a/frame 0x8241c660 > > panic() at panic+0x43/frame 0x8241c6c0 > > trap_fatal() at trap_fatal+0x386/frame 0x8241c720 > > trap_pfault() at trap_pfault+0x99/frame 0x8241c7a0 > > trap() at trap+0x4e9/frame 0x8241c8d0 > > calltrap() at calltrap+0x8/frame 0x8241c8d0 > > --- trap 0xc, rip = 0x80622931, rsp = 0x8241c9a0, rbp > > = 0x8241c9e0 --- > > malloc() at malloc+0x51/frame 0x8241c9e0 > > sysctl_handle_string() at sysctl_handle_string+0x12d/frame > > 0x8241ca20 > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0xa2/frame > > 0x8241ca70 > > sysctl_register_oid() at sysctl_register_oid+0x54c/frame 0x8241cd80 > > sysctl_register_all() at sysctl_register_all+0x88/frame 0x8241cda0 > > mi_startup() at mi_startup+0xf2/frame 0x8241cdf0 > > btext() at btext+0x2c > > KDB: enter: panic > > [ thread pid 0 tid 0 ] > > Stopped at kdb_enter+0x37: movq$0,0xa5f4a6(%rip) > > db> > > > > If I take the if_cxgbe_load out, however, it boots fine. > > You maybe also have something defined in your /boot/loader.conf that > causes a tunable to be set? > > It looks like there's just an ordering bug in kern_sysctl.c, where we > call sysctl_register_all() with SI_SUB_KMEM, SI_ORDER_FIRST but we do > MALLOC_DEFINE() with SI_SUB_KMEM, SI_ORDER_THIRD. If > sysctl_register_all() is going to malloc(), it needs to run after > malloc_init(), and it looks like populating a string tunable causes it > to malloc(). Ah, indeed, I do! That explains why Navdeep couldn't reproduce it. -Dustin ___ 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: Pkg repository is broken...
On 3/03/2020 4:58 am, marco wrote: On Sun, Mar 01, 2020 at 04:50:59PM -0500, you (Brennan Vincent) sent the following to [freebsd-current] : Apparently something has its ABI erroneously listed as FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64. ``` $ sudo pkg update -f Updating FreeBSD repository catalogue... Fetching meta.conf: 100%163 B 0.2kB/s00:01 Fetching packagesite.txz: 100%6 MiB 6.4MB/s00:01 Processing entries: 72% pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64 pkg: repository FreeBSD contains packages with wrong ABI: FreeBSD:13.0:amd64 Processing entries: 100% Unable to update repository FreeBSD Error updating repositories! ``` Ran into this very same problem today too. Just learned on #freebsd that the repos are temporarily borked and people are working hard to fix it. I even tried bootstrapping pkg like: env ABI=FreeBSD:13:amd64 pkg bootstrap -f (pkg 1.13.2 already installed) to no avail. Hoping things get sorted soon. Tacked in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT fatal trap cause by cxgbe module
On Sun, Mar 1, 2020 at 8:07 PM Dustin Marquess wrote: > > So I've been fighting with any current from the last month or so > instantly crashing when I boot it. I did notice that kernels in the > various snapshot images were working, however, so I was trying to > figure out why. At first I thought it was because I had INVARIANTS > and such disabled, but no, I finally figured it out. > > I've had in my /boot/loader.conf for a while now: > > if_cxgbe_load="YES" > > I guess since the stock installer kernels don't have cxgbe enabled by > default. I added "device cxgbe" to my kernels a while ago. Normally > the kernel would give some error about the module already being loaded > or something and just continue. As of last month or so, however, > instead it just crashes: > > FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80622931 > stack pointer = 0x28:0x8241c9a0 > frame pointer = 0x28:0x8241c9e0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > trap number = 12 > panic: page fault > cpuid = 0 > time = 1 > > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8241c600 > vpanic() at vpanic+0x18a/frame 0x8241c660 > panic() at panic+0x43/frame 0x8241c6c0 > trap_fatal() at trap_fatal+0x386/frame 0x8241c720 > trap_pfault() at trap_pfault+0x99/frame 0x8241c7a0 > trap() at trap+0x4e9/frame 0x8241c8d0 > calltrap() at calltrap+0x8/frame 0x8241c8d0 > --- trap 0xc, rip = 0x80622931, rsp = 0x8241c9a0, rbp > = 0x8241c9e0 --- > malloc() at malloc+0x51/frame 0x8241c9e0 > sysctl_handle_string() at sysctl_handle_string+0x12d/frame 0x8241ca20 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0xa2/frame > 0x8241ca70 > sysctl_register_oid() at sysctl_register_oid+0x54c/frame 0x8241cd80 > sysctl_register_all() at sysctl_register_all+0x88/frame 0x8241cda0 > mi_startup() at mi_startup+0xf2/frame 0x8241cdf0 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at kdb_enter+0x37: movq$0,0xa5f4a6(%rip) > db> > > If I take the if_cxgbe_load out, however, it boots fine. > > Thanks! > -Dustin > ___ > 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" You maybe also have something defined in your /boot/loader.conf that causes a tunable to be set? It looks like there's just an ordering bug in kern_sysctl.c, where we call sysctl_register_all() with SI_SUB_KMEM, SI_ORDER_FIRST but we do MALLOC_DEFINE() with SI_SUB_KMEM, SI_ORDER_THIRD. If sysctl_register_all() is going to malloc(), it needs to run after malloc_init(), and it looks like populating a string tunable causes it to malloc(). Ryan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT fatal trap cause by cxgbe module
I'm not able to reproduce this. I tried a test kernel built with "device cxgbe" and had if_cxgbe_load="YES" in loader.conf and the system came up just fine. Regards, Navdeep On 3/1/20 8:07 PM, Dustin Marquess wrote: > So I've been fighting with any current from the last month or so > instantly crashing when I boot it. I did notice that kernels in the > various snapshot images were working, however, so I was trying to > figure out why. At first I thought it was because I had INVARIANTS > and such disabled, but no, I finally figured it out. > > I've had in my /boot/loader.conf for a while now: > > if_cxgbe_load="YES" > > I guess since the stock installer kernels don't have cxgbe enabled by > default. I added "device cxgbe" to my kernels a while ago. Normally > the kernel would give some error about the module already being loaded > or something and just continue. As of last month or so, however, > instead it just crashes: > > FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80622931 > stack pointer = 0x28:0x8241c9a0 > frame pointer = 0x28:0x8241c9e0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > trap number = 12 > panic: page fault > cpuid = 0 > time = 1 > > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8241c600 > vpanic() at vpanic+0x18a/frame 0x8241c660 > panic() at panic+0x43/frame 0x8241c6c0 > trap_fatal() at trap_fatal+0x386/frame 0x8241c720 > trap_pfault() at trap_pfault+0x99/frame 0x8241c7a0 > trap() at trap+0x4e9/frame 0x8241c8d0 > calltrap() at calltrap+0x8/frame 0x8241c8d0 > --- trap 0xc, rip = 0x80622931, rsp = 0x8241c9a0, rbp > = 0x8241c9e0 --- > malloc() at malloc+0x51/frame 0x8241c9e0 > sysctl_handle_string() at sysctl_handle_string+0x12d/frame 0x8241ca20 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0xa2/frame > 0x8241ca70 > sysctl_register_oid() at sysctl_register_oid+0x54c/frame 0x8241cd80 > sysctl_register_all() at sysctl_register_all+0x88/frame 0x8241cda0 > mi_startup() at mi_startup+0xf2/frame 0x8241cdf0 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at kdb_enter+0x37: movq$0,0xa5f4a6(%rip) > db> > > If I take the if_cxgbe_load out, however, it boots fine. > > Thanks! > -Dustin > ___ > 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: [package - head-amd64-default][sysutils/lsof] Failed for lsof-4.93.2_9,8 in build
On 3/2/20, Larry Rosenman wrote: > > Can someone help me here? > That's a fallout from my change, I'll take care of it in few h. > Thanmks! > Original Message > Subject: [package - head-amd64-default][sysutils/lsof] Failed for > lsof-4.93.2_9,8 in build > Date: 03/02/2020 11:55 am > From: pkg-fall...@freebsd.org > To: l...@freebsd.org > Cc: pkg-fall...@freebsd.org > > You are receiving this mail as a port that you maintain > is failing to build on the FreeBSD package build server. > Please investigate the failure and submit a PR to fix > build. > > Maintainer: l...@freebsd.org > Last committer: l...@freebsd.org > Ident: $FreeBSD: head/sysutils/lsof/Makefile 523727 2020-01-21 > 15:41:15Z ler $ > Log URL: > http://beefy18.nyi.freebsd.org/data/head-amd64-default/p527609_s358518/logs/lsof-4.93.2_9,8.log > Build URL: > http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default=p527609_s358518 > Log: > > =>> Building sysutils/lsof > build started at Mon Mar 2 17:55:04 UTC 2020 > port directory: /usr/ports/sysutils/lsof > package name: lsof-4.93.2_9,8 > building for: FreeBSD head-amd64-default-job-12 13.0-CURRENT FreeBSD > 13.0-CURRENT 1300082 amd64 > maintained by: l...@freebsd.org > Makefile ident: $FreeBSD: head/sysutils/lsof/Makefile 523727 > 2020-01-21 15:41:15Z ler $ > Poudriere version: 3.2.8-5-gc81843e5 > Host OSVERSION: 1300076 > Jail OSVERSION: 1300082 > Job Id: 12 > > > > > !!! Jail is newer than host. (Jail: 1300082, Host: 1300076) !!! > !!! This is not supported. !!! > !!! Host kernel must be same or newer than jail. !!! > !!! Expect build failures. !!! > > > > ---Begin Environment--- > SHELL=/bin/csh > OSVERSION=1300082 > UNAME_v=FreeBSD 13.0-CURRENT 1300082 > UNAME_r=13.0-CURRENT > BLOCKSIZE=K > STATUS=1 > HOME=/root > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin > LOCALBASE=/usr/local > USER=root > LIBEXECPREFIX=/usr/local/libexec/poudriere > POUDRIERE_VERSION=3.2.8-5-gc81843e5 > MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref > POUDRIERE_BUILD_TYPE=bulk > PACKAGE_BUILDING=yes > SAVED_TERM=screen > PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool > P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS > MASTERNAME=head-amd64-default > SCRIPTPREFIX=/usr/local/share/poudriere > OLDPWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p > SCRIPTPATH=/usr/local/share/poudriere/bulk.sh > POUDRIEREPATH=/usr/local/bin/poudriere > ---End Environment--- > > ---Begin Poudriere Port Flags/Env--- > PORT_FLAGS= > PKGENV= > FLAVOR= > DEPENDS_ARGS= > MAKE_ARGS= > ---End Poudriere Port Flags/Env--- > > ---Begin OPTIONS List--- > ---End OPTIONS List--- > > --MAINTAINER-- > l...@freebsd.org > --End MAINTAINER-- > > --CONFIGURE_ARGS-- > -n freebsd > --End CONFIGURE_ARGS-- > > --CONFIGURE_ENV-- > LSOF_CC="cc" FREEBSD_SYS="/usr/src/sys" > XDG_DATA_HOME=/wrkdirs/usr/ports/sysutils/lsof/work > XDG_CONFIG_HOME=/wrkdirs/usr/ports/sysutils/lsof/work > HOME=/wrkdirs/usr/ports/sysutils/lsof/work TMPDIR="/tmp" > PATH=/wrkdirs/usr/ports/sysutils/lsof/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin > > SHELL=/bin/sh CONFIG_SHELL=/bin/sh > --End CONFIGURE_ENV-- > > --MAKE_ENV-- > XDG_DATA_HOME=/wrkdirs/usr/ports/sysutils/lsof/work > XDG_CONFIG_HOME=/wrkdirs/usr/ports/sysutils/lsof/work > HOME=/wrkdirs/usr/ports/sysutils/lsof/work TMPDIR="/tmp" > PATH=/wrkdirs/usr/ports/sysutils/lsof/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin > > NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh > NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 > -pipe -fstack-protector-strong -fno-strict-aliasing " CPP="cpp" > CPPFLAGS="" LDFLAGS=" -fstack-protector-strong " LIBS="" CXX="c++" > CXXFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " > MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" > BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m > 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m > 444" > --End MAKE_ENV-- > > --PLIST_SUB-- > OSREL=13.0 PREFIX=%D LOCALBASE=/usr/local RESETPREFIX=/usr/local > LIB32DIR=lib DOCSDIR="share/doc/lsof" EXAMPLESDIR="share/examples/lsof" > DATADIR="share/lsof" WWWDIR="www/lsof" ETCDIR="etc/lsof" > --End PLIST_SUB-- > > --SUB_LIST-- > PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/lsof > DOCSDIR=/usr/local/share/doc/lsof > EXAMPLESDIR=/usr/local/share/examples/lsof WWWDIR=/usr/local/www/lsof > ETCDIR=/usr/local/etc/lsof > --End SUB_LIST-- > > ---Begin make.conf--- > USE_PACKAGE_DEPENDS=yes > BATCH=yes > WRKDIRPREFIX=/wrkdirs > PORTSDIR=/usr/ports > PACKAGES=/packages > DISTDIR=/distfiles > PACKAGE_BUILDING=yes > PACKAGE_BUILDING_FLAVORS=yes > /usr/local/etc/poudriere.d/make.conf > # XXX: We really need this but cannot use it while 'make checksum' does > not > # try the next mirror on checksum
Fwd: [package - head-amd64-default][sysutils/lsof] Failed for lsof-4.93.2_9,8 in build
Can someone help me here? Thanmks! Original Message Subject: [package - head-amd64-default][sysutils/lsof] Failed for lsof-4.93.2_9,8 in build Date: 03/02/2020 11:55 am From: pkg-fall...@freebsd.org To: l...@freebsd.org Cc: pkg-fall...@freebsd.org You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: l...@freebsd.org Last committer: l...@freebsd.org Ident: $FreeBSD: head/sysutils/lsof/Makefile 523727 2020-01-21 15:41:15Z ler $ Log URL: http://beefy18.nyi.freebsd.org/data/head-amd64-default/p527609_s358518/logs/lsof-4.93.2_9,8.log Build URL: http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default=p527609_s358518 Log: =>> Building sysutils/lsof build started at Mon Mar 2 17:55:04 UTC 2020 port directory: /usr/ports/sysutils/lsof package name: lsof-4.93.2_9,8 building for: FreeBSD head-amd64-default-job-12 13.0-CURRENT FreeBSD 13.0-CURRENT 1300082 amd64 maintained by: l...@freebsd.org Makefile ident: $FreeBSD: head/sysutils/lsof/Makefile 523727 2020-01-21 15:41:15Z ler $ Poudriere version: 3.2.8-5-gc81843e5 Host OSVERSION: 1300076 Jail OSVERSION: 1300082 Job Id: 12 !!! Jail is newer than host. (Jail: 1300082, Host: 1300076) !!! !!! This is not supported. !!! !!! Host kernel must be same or newer than jail. !!! !!! Expect build failures. !!! ---Begin Environment--- SHELL=/bin/csh OSVERSION=1300082 UNAME_v=FreeBSD 13.0-CURRENT 1300082 UNAME_r=13.0-CURRENT BLOCKSIZE=K STATUS=1 HOME=/root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin LOCALBASE=/usr/local USER=root LIBEXECPREFIX=/usr/local/libexec/poudriere POUDRIERE_VERSION=3.2.8-5-gc81843e5 MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref POUDRIERE_BUILD_TYPE=bulk PACKAGE_BUILDING=yes SAVED_TERM=screen PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS MASTERNAME=head-amd64-default SCRIPTPREFIX=/usr/local/share/poudriere OLDPWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p SCRIPTPATH=/usr/local/share/poudriere/bulk.sh POUDRIEREPATH=/usr/local/bin/poudriere ---End Environment--- ---Begin Poudriere Port Flags/Env--- PORT_FLAGS= PKGENV= FLAVOR= DEPENDS_ARGS= MAKE_ARGS= ---End Poudriere Port Flags/Env--- ---Begin OPTIONS List--- ---End OPTIONS List--- --MAINTAINER-- l...@freebsd.org --End MAINTAINER-- --CONFIGURE_ARGS-- -n freebsd --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- LSOF_CC="cc" FREEBSD_SYS="/usr/src/sys" XDG_DATA_HOME=/wrkdirs/usr/ports/sysutils/lsof/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/sysutils/lsof/work HOME=/wrkdirs/usr/ports/sysutils/lsof/work TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/sysutils/lsof/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- XDG_DATA_HOME=/wrkdirs/usr/ports/sysutils/lsof/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/sysutils/lsof/work HOME=/wrkdirs/usr/ports/sysutils/lsof/work TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/sysutils/lsof/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " CPP="cpp" CPPFLAGS="" LDFLAGS=" -fstack-protector-strong " LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" --End MAKE_ENV-- --PLIST_SUB-- OSREL=13.0 PREFIX=%D LOCALBASE=/usr/local RESETPREFIX=/usr/local LIB32DIR=lib DOCSDIR="share/doc/lsof" EXAMPLESDIR="share/examples/lsof" DATADIR="share/lsof" WWWDIR="www/lsof" ETCDIR="etc/lsof" --End PLIST_SUB-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/lsof DOCSDIR=/usr/local/share/doc/lsof EXAMPLESDIR=/usr/local/share/examples/lsof WWWDIR=/usr/local/www/lsof ETCDIR=/usr/local/etc/lsof --End SUB_LIST-- ---Begin make.conf--- USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PORTSDIR=/usr/ports PACKAGES=/packages DISTDIR=/distfiles PACKAGE_BUILDING=yes PACKAGE_BUILDING_FLAVORS=yes /usr/local/etc/poudriere.d/make.conf # XXX: We really need this but cannot use it while 'make checksum' does not # try the next mirror on checksum failure. It currently retries the same # failed mirror and then fails rather then trying another. It *does* # try the next if the size is mismatched though. #MASTER_SITE_FREEBSD=yes # Build ALLOW_MAKE_JOBS_PACKAGES with 2 jobs MAKE_JOBS_NUMBER=2 /usr/ports/Mk/Scripts/ports_env.sh _CCVERSION_921dbbb2=FreeBSD
Re: Pkg repository is broken...
On Sun, Mar 01, 2020 at 04:50:59PM -0500, you (Brennan Vincent) sent the following to [freebsd-current] : > Apparently something has its ABI erroneously listed as FreeBSD:13.0:amd64 > instead of FreeBSD:13:amd64. > > ``` > $ sudo pkg update -f > Updating FreeBSD repository catalogue... > Fetching meta.conf: 100%163 B 0.2kB/s00:01 > Fetching packagesite.txz: 100%6 MiB 6.4MB/s00:01 > Processing entries: 72% > pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64 > pkg: repository FreeBSD contains packages with wrong ABI: FreeBSD:13.0:amd64 > Processing entries: 100% > Unable to update repository FreeBSD > Error updating repositories! > ``` Ran into this very same problem today too. Just learned on #freebsd that the repos are temporarily borked and people are working hard to fix it. I even tried bootstrapping pkg like: env ABI=FreeBSD:13:amd64 pkg bootstrap -f (pkg 1.13.2 already installed) to no avail. Hoping things get sorted soon. -- Marco van Lienen -- Unix SysAdmin -- https://lordsith.net/ https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." pgpSXjInQ3g5x.pgp Description: PGP signature
Re: about loader & console
On Mon, Mar 02, 2020 at 10:47:41AM +0200, Toomas Soome wrote: > What we have now (on current): > > arm: efi console is the same state as in x86, no serial driver to provide > comconsole, the serial console is only available via redirection from > firmware. > Is it possible, on a Pi3 without WiFi nor bluetooth, to add enable_uart=1 to config.txt? At this point config.txt contains arm_control=0x200 dtparam=audio=on,i2c_arm=on,spi=on dtoverlay=mmc dtoverlay=pwm dtoverlay=pi3-disable-bt device_tree_address=0x4000 kernel=u-boot.bin and is, I think, default. Thanks for reading, bob prohaska ___ 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"
about loader & console
Hi! I have been busy with other bits for some time, but now back to poking some bits. What we have now (on current): x86: vidconsole on BIOS systems. Text mode, the screen is managed by teken terminal emulator, we “draw” on vga text buffer. comconsole: serial port driver shared by BIOS and UEFI mode. efi: Text mode, console “device” which can have gfx display, serial port or both connected as back end device, connection is done by the firmware. We write by using UEFI Simple Text Output Protocol. See also ConOut UEFI variable. To manage the screen, the efi console also defaults to use teken terminal emulator, however, if the serial port is multiplexed to ConOut, we can not have “our” terminal emulator to draw the screen, as that would distort the serial console. And worse, at least some UEFI firmware implementations do not pass ESC code via simple text output protocol, causing the console being filled by broken CSI sequences. arm: efi console is the same state as in x86, no serial driver to provide comconsole, the serial console is only available via redirection from firmware. I actually do have basic comconsole implementation via UEFI Serial IO protocol, but unfortunately, the UEFI API does not provide good way to identify serial ports, we only do get array of handles of serial ports. The SIO handle is opaque. What we want to get: We would like to have framebuffer console (at least on efi), where we do “draw” the glyphs and do not use simple text output protocol for console output. Why: this will allow us to provide more consistent screen output, draw images and we would not depend on simple text output any more. UEFI gfx console is already built on framebuffer - on physical systems we do get FB address, size and few other attributes, and after passing this all to kernel, the kernel will draw the conole, as Simple Text Output Protocol is not available once we start the kernel. To get this done, we need console font. To be able to output text, I do plan to build into loader binary the limited set (ascii + box drawing) 8x16 font, and once we have gained access to the disk, we will load best matching font for the current resolution. This makes first problem - we have font files in usr/share/vt/fonts, but there are too many options where the /usr might be, so we would need to copy some of those fonts to /boot tree. I’d use terminus fonts there for consistency (glyph range) for various glyph sizes. And the kernel default built in font is 8x16 terminus. With ability to draw our glyphs, we can build console device list in console variable, just as it is currently done with x86 BIOS version. If we should still use the console name “efi” for FB console or leave efi for pure Simple Text Output based console, is something we would need to decide. Once we can draw the FB console on UEFI, it is not too hard to add the implementation for BIOS VBE interface. To sum it all up: 0. my assumption is/was that we do not change the name of the console driver, to keep the expected values people are used with. However, it is quite easy to introduce new console types, if needed. 1. We need to provide serial driver on all platforms. 2. Provide option to switch between “text” and gfx mode. In some systems (BIOS VGA) the gfx performance may be very low and text mode might be preferred. 3. The screen updates are to be implemented via teken callback mechanism (as it is also done in kernel for that matter). 4. The support to display images is using pnglite (and therefore png format). Interpreters need updates to support the feature. I actually do have the core implementation for UEFI already, but polishing it up will still get some time. Actually I am cheating there quite a bit because I have done all this work already once and now I am porting it to different terminal emulator. I hope this writeup does give some light about what is happening in this area. thanks, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
