Re: 'chflags: fts_read: Permission denied' on fresh -CURRENT
Yes, it allows to move further and build is currently running. Thanks Mateusz Guzik wrote: > Does: sysctl vfs.cache_fast_lookup=0 clean it up for you? > > On 8/25/20, Roman Bogorodskiy wrote: > > Hi, > > > > I've updated -CURRENT today to r364753, and poudriere started failing > > with: > > > > [00:00:00] Creating the reference jail...chflags: fts_read: Permission > > denied > > [00:00:00] Cleaning up > > [00:00:00] Unmounting file systems > > chflags: fts_read: Permission denied > > > > I've created a new jail and it fails with the same error. > > > > I'm not using zfs and also I use the same sources for poudriere jails as > > the host, i.e.: > > > > current 13.0-CURRENT 1300112 amd64 src=/usr/src 2020-08-25 > > 13:17:30 /usr/local/poudriere/jails/current > > current13 13.0-CURRENT 1300113 amd64 src=/usr/src 2020-08-25 > > 16:19:13 /usr/local/poudriere/jails/current13 > > > > Any ideas what could be wrong with this? > > > > Roman Bogorodskiy > > > > > -- > Mateusz Guzik Roman Bogorodskiy signature.asc Description: PGP signature
'chflags: fts_read: Permission denied' on fresh -CURRENT
Hi, I've updated -CURRENT today to r364753, and poudriere started failing with: [00:00:00] Creating the reference jail...chflags: fts_read: Permission denied [00:00:00] Cleaning up [00:00:00] Unmounting file systems chflags: fts_read: Permission denied I've created a new jail and it fails with the same error. I'm not using zfs and also I use the same sources for poudriere jails as the host, i.e.: current 13.0-CURRENT 1300112 amd64 src=/usr/src 2020-08-25 13:17:30 /usr/local/poudriere/jails/current current13 13.0-CURRENT 1300113 amd64 src=/usr/src 2020-08-25 16:19:13 /usr/local/poudriere/jails/current13 Any ideas what could be wrong with this? Roman Bogorodskiy signature.asc Description: PGP signature
Re: r359627 is panicked with 'softdep_setup_blkfree: not free'
Hans Petter Selasky wrote: > On 2020-04-06 14:50, Masachika ISHIZUKA wrote: > > > >I'm using r359627M. (r359627 with mount_udf2). > > > >It is panicked with 'softdep_setup_blkfree: not free'. > > > > > > > >Panic log was stored as follows. > > > > > >Sorry, this panic was my mistake. > > >I forgot to update drm-current-kmod. > > > > > > old% pkg info drm-current-kmod > > > [snip] > > > Annotations: > > > FreeBSD_version: 1300084 <--- old > > > [snip] > > > > > > old# pkg install -f drm-current-kmod > > > new% pkg info drm-current-kmod > > > [snip] > > > Annotations: > > > FreeBSD_version: 1300088 > > > [snip] > > > > > >This works fine. > > > >The panic was occured again. > >Crash dump was the same. > >To reinstall drm-current-kmod was not fixed this issue. > > > > Issue probably will go away if you boot to single-user-mode and run fsck -y > before booting the system. Regardless, kernel should not panic. Recently I've started observing issues like this too. For example, today I did: - run 'fsck -y' twice in single user mode (because actually I was forced to do that because last time I hard reset the box) - start building stuff with poudriere - after approx. 40-45 minutes I get this panic. Backtrace snippet is the following: (kgdb) #0 doadump (textdump=1) at src/sys/amd64/include/pcpu_aux.h:55 #1 0x80bbd4a0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:481 #2 0x80bbd8fa in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:913 #3 0x80bbd653 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:839 #4 0x80ec9792 in softdep_setup_blkfree (mp=0xfe00a35a7100, bp=, blkno=50732008, frags=1, wkhd=0xfe00a9b4ca98) at /usr/src/sys/ufs/ffs/ffs_softdep.c:10917 #5 0x80eaa8c0 in ffs_blkfree_cg (ump=, fs=0xfe00a1a58000, devvp=, bno=, size=, inum=, dephd=0xfe00a9b4ca98) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2335 #6 0x80ea7645 in ffs_blkfree (ump=0xf80003b0d200, fs=, devvp=0xf80005e785b8, bno=50732008, size=, inum=, vtype=VREG, dephd=0xfe00a9b4ca98, key=2) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2635 #7 0x80ec0b7e in handle_workitem_freefrag ( freefrag=0xf803777b7780) at /usr/src/sys/ufs/ffs/ffs_softdep.c:5707 #8 0x80ecc4ff in process_worklist_item (mp=0xfe00a35a7100, target=10, flags=512) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1853 #9 0x80eb7f57 in softdep_process_worklist (mp=0xfe00a35a7100, full=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1641 #10 0x80ebb96f in softdep_flush (addr=0xfe00a35a7100) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1426 #11 0x80b7b450 in fork_exit ( callout=0x80ebb890 , arg=0xfe00a35a7100, frame=0xfe00a9b4cc00) at /usr/src/sys/kern/kern_fork.c:1051 #12 0x810345ee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:1080 #13 0x in ?? () Current language: auto; currently minimal (kgdb) Roman Bogorodskiy signature.asc Description: PGP signature
Re: Build failed compiling ittnotify_static.pico
Dimitry Andric wrote:
> On 14 Mar 2020, at 17:24, Roman Bogorodskiy wrote:
> >
> > Dimitry Andric wrote:
> >> On 13 Mar 2020, at 23:58, Waitman Gobble wrote:
> >>>
> >>> On 2020-03-13 17:49, Waitman Gobble wrote:
> >>>> On 2020-03-13 16:57, Bob Willcox wrote:
> >> ...
> >>>>> cc: error: no such file or directory:
> >>>>> '/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c'
> >>>>> cc: error: no input files
> >>>>> *** [ittnotify_static.pico] Error code 1
> >>>>> Anyone else seeing this? Any suggestions for a fix?
> >>>>> Thanks,
> >>>>> Bob
> >>>> I've been getting the same thing since yesterday. I think the file is
> >>>> actually
> >>>> ittnotify_static.cpp
> >>>
> >>>
> >>> This is supposed to handle the rename, for some reason it's not happening
> >>> on my machine.
> >>>
> >>> Makefile.inc1
> >>>
> >>> # 20200310 r358851 rename of openmp's ittnotify_static.c to .cpp
> >>> .for f in ittnotify_static
> >>> @if [ -e "${OBJTOP}/lib/libomp/.depend.${f}.pico" ] && \
> >>> egrep -qw '${f}\.c' ${OBJTOP}/lib/libomp/.depend.${f}.pico;
> >>> then \
> >>> echo "Removing stale dependencies for ${f}"; \
> >>> rm -f ${OBJTOP}/lib/libomp/.depend.${f}.* \
> >>> ${OBJTOP}/obj-lib32/lib/libomp/.depend.${f}.* \
> >>>
> >>> ${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libomp/.depend.${f}.*}; \
> >>> fi
> >>> .endfor
> >>
> >> Hm, so during your buildworld, does it show "Removing stale dependencies
> >> for ittnotify_static" or not? And is the .depend file there? Can you
> >> check /usr/obj for the file .depend.ittnotify_static.pico, and list its
> >> permissions?
> >>
> >> -Dimitry
> >>
> >
> > I have the same issue updating one of my poudriere jails.
> > I don't see "Removing stale dependencies ..." messages.
> >
> > I see a couple of ittnotify_static related messages:
> >
> > make[5]:
> > /usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/obj-lib32/lib/libomp/.depend.ittnotify_static.pico,
> > 43: ignoring stale .depend for
> > /workspace/poudriere/jails/current/usr/src/contrib/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c
> > ...
> > make[5]:
> > /usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/obj-lib32/lib/libomp/.depend.ittnotify_static.pico,
> > 43: ignoring stale .depend for
> > /workspace/poudriere/jails/current/usr/src/contrib/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.h
>
> These are for the 32-bit stage. The initial fix I committed in r358907
> worked for the main buildword stage, but apparently not for the 32-bit
> stage, which stores its object files in a slightly different directory
> (e.g. the obj-lib32 subpath).
>
> Ed Maste tried to fix that up in r358909, but maybe it does not work in
> all situations, for example with custom MAKEOBJDIRPREFIX settings?
>
>
> > $ ls -al
> > /usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/lib/libomp/.depend.ittnotify_static.pico
> > -rw-r--r-- 1 root wheel 6565 Mar 14 19:30
> > /usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/lib/libomp/.depend.ittnotify_static.pico
>
> What is in the first two lines of that file?
$ head -2
/usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/lib/libomp/.depend.ittnotify_static.pico
ittnotify_static.pico: \
/workspace/poudriere/jails/current/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.cpp
\
$
> -Dimitry
>
Roman Bogorodskiy
signature.asc
Description: PGP signature
Re: Build failed compiling ittnotify_static.pico
Dimitry Andric wrote:
> On 13 Mar 2020, at 23:58, Waitman Gobble wrote:
> >
> > On 2020-03-13 17:49, Waitman Gobble wrote:
> >> On 2020-03-13 16:57, Bob Willcox wrote:
> ...
> >>> cc: error: no such file or directory:
> >>> '/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c'
> >>> cc: error: no input files
> >>> *** [ittnotify_static.pico] Error code 1
> >>> Anyone else seeing this? Any suggestions for a fix?
> >>> Thanks,
> >>> Bob
> >> I've been getting the same thing since yesterday. I think the file is
> >> actually
> >> ittnotify_static.cpp
> >
> >
> > This is supposed to handle the rename, for some reason it's not happening
> > on my machine.
> >
> > Makefile.inc1
> >
> > # 20200310 r358851 rename of openmp's ittnotify_static.c to .cpp
> > .for f in ittnotify_static
> >@if [ -e "${OBJTOP}/lib/libomp/.depend.${f}.pico" ] && \
> >egrep -qw '${f}\.c' ${OBJTOP}/lib/libomp/.depend.${f}.pico; then
> > \
> >echo "Removing stale dependencies for ${f}"; \
> >rm -f ${OBJTOP}/lib/libomp/.depend.${f}.* \
> > ${OBJTOP}/obj-lib32/lib/libomp/.depend.${f}.* \
> >
> > ${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libomp/.depend.${f}.*}; \
> >fi
> > .endfor
>
> Hm, so during your buildworld, does it show "Removing stale dependencies
> for ittnotify_static" or not? And is the .depend file there? Can you
> check /usr/obj for the file .depend.ittnotify_static.pico, and list its
> permissions?
>
> -Dimitry
>
I have the same issue updating one of my poudriere jails.
I don't see "Removing stale dependencies ..." messages.
I see a couple of ittnotify_static related messages:
make[5]:
/usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/obj-lib32/lib/libomp/.depend.ittnotify_static.pico,
43: ignoring stale .depend for
/workspace/poudriere/jails/current/usr/src/contrib/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c
...
make[5]:
/usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/obj-lib32/lib/libomp/.depend.ittnotify_static.pico,
43: ignoring stale .depend for
/workspace/poudriere/jails/current/usr/src/contrib/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.h
$ ls -al
/usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/lib/libomp/.depend.ittnotify_static.pico
-rw-r--r-- 1 root wheel 6565 Mar 14 19:30
/usr/obj/workspace/poudriere/jails/current/usr/src/amd64.amd64/lib/libomp/.depend.ittnotify_static.pico
$
Roman Bogorodskiy
signature.asc
Description: PGP signature
Re: panic after ifioctl/if_clone_destroy
Hans Petter Selasky wrote: > On 8/11/18 9:44 AM, Roman Bogorodskiy wrote: > >Hans Petter Selasky wrote: > > > >> On 08/06/18 21:43, Matthew Macy wrote: > >>> The struct thread is typesafe. The problem is that the link is no longer > >>> typesafe now that it’s not part of the thread. Thanks for pointing this > >>> out. I’ll commit a fix later today. > >>> > >> > >> Is there a patch yet? > >> > >> --HPS > >> > > > > This was committed in: > > > > https://svnweb.freebsd.org/changeset/base/337525 > > > > However, I've just updated to r337595, and it still panics. Not sure if > > that's related to the original issue though: > > > > (kgdb) #0 doadump (textdump=0) at pcpu.h:230 > > #1 0x8043ddfb in db_dump (dummy=, > > dummy2=, dummy3=, > > dummy4=) at /usr/src/sys/ddb/db_command.c:574 > > #2 0x8043dbc9 in db_command (cmd_table=) > > at /usr/src/sys/ddb/db_command.c:481 > > #3 0x8043d944 in db_command_loop () > > at /usr/src/sys/ddb/db_command.c:534 > > #4 0x80440b6f in db_trap (type=, > > code=) at /usr/src/sys/ddb/db_main.c:252 > > #5 0x80bdef83 in kdb_trap (type=9, code=0, tf= > out>) > > at /usr/src/sys/kern/subr_kdb.c:693 > > #6 0x8107aee1 in trap_fatal (frame=0xfe00760dc8a0, eva=0) > > at /usr/src/sys/amd64/amd64/trap.c:906 > > #7 0x8107a3bd in trap (frame=0xfe00760dc8a0) at counter.h:87 > > #8 0x81054d05 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:232 > > #9 0x80ded513 in inp_gcmoptions (ctx=0xf80003079f20) > > at epoch_private.h:188 > > #10 0x80bd9cba in epoch_call_task (arg=) > > at /usr/src/sys/kern/subr_epoch.c:507 > > #11 0x80bdd0a9 in gtaskqueue_run_locked (queue=0xf800035be900) > > at /usr/src/sys/kern/subr_gtaskqueue.c:332 > > #12 0x80bdce28 in gtaskqueue_thread_loop (arg=) > > at /usr/src/sys/kern/subr_gtaskqueue.c:507 > > #13 0x80b530c4 in fork_exit ( > > callout=0x80bdcda0 , > > arg=0xfe00061a4038, frame=0xfe00760dcac0) > > at /usr/src/sys/kern/kern_fork.c:1057 > > #14 0x81055cde in fork_trampoline () > > at /usr/src/sys/amd64/amd64/exception.S:990 > > #15 0x in ?? () > > Current language: auto; currently minimal > > (kgdb) > > > > Full core.txt is here: > > https://people.freebsd.org/~novel/misc/core.20180811.txt > > > > Roman Bogorodskiy > > > > What is the full panic message? Are you loading // unloading any network > modules? > > --HPS Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 04 instruction pointer = 0x20:0x80ded513 stack pointer = 0x28:0xfe00760dc960 frame pointer = 0x28:0xfe00760dc9a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (softirq_2) (more details in https://people.freebsd.org/~novel/misc/core.20180811.txt) Panic happens right after boot. I do have: if_tap_load="YES" if_bridge_load="YES" in /boot/loader.conf. Just as before, panic happens after creating/renaming bridge and tap interfaces. Last few lines before panic (as could be seen in core.20180811.txt linked above): bridge0: Ethernet address: 02:af:41:48:c7:00 bridge0: changing name to 'virbr0' tap0: Ethernet address: 00:bd:95:08:f7:00 tap0: link state changed to UP tap0: changing name to 'virbr0-nic' virbr0-nic: promiscuous mode enabled virbr0: link state changed to UP virbr0-nic: link state changed to DOWN virbr0: link state changed to DOWN bridge0: Ethernet address: 02:af:41:48:c7:00 bridge0: changing name to 'virbr-hostnet' tap0: Ethernet address: 00:bd:e5:0b:f7:00 tap0: link state changed to UP tap0: changing name to 'virbr-honet-nic' virbr-honet-nic: promiscuous mode enabled virbr-hostnet: link state changed to UP Roman Bogorodskiy signature.asc Description: PGP signature
Re: panic after ifioctl/if_clone_destroy
Hans Petter Selasky wrote: > On 08/06/18 21:43, Matthew Macy wrote: > > The struct thread is typesafe. The problem is that the link is no longer > > typesafe now that it’s not part of the thread. Thanks for pointing this > > out. I’ll commit a fix later today. > > > > Is there a patch yet? > > --HPS > This was committed in: https://svnweb.freebsd.org/changeset/base/337525 However, I've just updated to r337595, and it still panics. Not sure if that's related to the original issue though: (kgdb) #0 doadump (textdump=0) at pcpu.h:230 #1 0x8043ddfb in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:574 #2 0x8043dbc9 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:481 #3 0x8043d944 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #4 0x80440b6f in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:252 #5 0x80bdef83 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:693 #6 0x8107aee1 in trap_fatal (frame=0xfe00760dc8a0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:906 #7 0x8107a3bd in trap (frame=0xfe00760dc8a0) at counter.h:87 #8 0x81054d05 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #9 0x80ded513 in inp_gcmoptions (ctx=0xf80003079f20) at epoch_private.h:188 #10 0x80bd9cba in epoch_call_task (arg=) at /usr/src/sys/kern/subr_epoch.c:507 #11 0x80bdd0a9 in gtaskqueue_run_locked (queue=0xf800035be900) at /usr/src/sys/kern/subr_gtaskqueue.c:332 #12 0x80bdce28 in gtaskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_gtaskqueue.c:507 #13 0x80b530c4 in fork_exit ( callout=0x80bdcda0 , arg=0xfe00061a4038, frame=0xfe00760dcac0) at /usr/src/sys/kern/kern_fork.c:1057 #14 0x81055cde in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:990 #15 0x in ?? () Current language: auto; currently minimal (kgdb) Full core.txt is here: https://people.freebsd.org/~novel/misc/core.20180811.txt Roman Bogorodskiy signature.asc Description: PGP signature
Re: panic after ifioctl/if_clone_destroy
Hans Petter Selasky wrote: > Hi Roman, > > Can you try the attached patch? > > --HPS Thanks for the patch, works fine so far. I'll give it more testing in the next few days. Roman Bogorodskiy signature.asc Description: PGP signature
panic after ifioctl/if_clone_destroy
el: tap1: link state changed to UP Aug 5 19:02:43 romashka kernel: tap1: changing name to 'virbr0-nic' Aug 5 19:02:43 romashka kernel: virbr0: link state changed to UP Aug 5 19:02:43 romashka kernel: virbr0-nic: promiscuous mode enabled Aug 5 19:02:43 romashka rtsold[585]: interface tap1 removed Aug 5 19:05:03 romashka syslogd: kernel boot file is /boot/kernel/kernel Aug 5 19:05:03 romashka kernel: Aug 5 19:05:03 romashka syslogd: last message repeated 1 times Aug 5 19:05:03 romashka kernel: Fatal trap 12: page fault while in kernel mode If I disable libvirt service, system completes booting fine. What it tries to do on start, it creates a couple of bridge(4) and tap(4) devices, adds tap devices to bridges it created, and possibly destroy these interfaces in case of errors. It also starts dnsmasq on some of these interfaces. This problem started to appear about 2-4 weeks ago. Roman Bogorodskiy signature.asc Description: PGP signature
Re: EFI issues
O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Sun, 29 Jul 2018 12:09:58 +0400 > Roman Bogorodskiy schrieb: > > > O. Hartmann wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > Am Sat, 28 Jul 2018 11:29:40 +0400 > > > Roman Bogorodskiy schrieb: > > > > > > > Hi, > > > > > > > > I have a test box that's updated to -CURRENT usually once in a week or > > > > two. This box boots using UEFI. After a regular update about two weeks > > > > ago it started to panic on boot frequently (not UEFI related), but I > > > > could not get a crash dump because my swap partition was too small. So I > > > > moved data to the backup drive, repartitioned the main drive and boot > > > > again. This went fine, so I decided to upgrade to fresh -CURRENT from > > > > ~Jul 27th. Booting with the new kernel went fine, but after installworld > > > > machine stopped booting, and on the screen I see: > > > > > > > > FreeBSD/amd64 EFI loader, ... > > > > > > > > .. > > > > > > > > BootOrder: > > > > > > > > And then it gets stuck and nothing happens. > > > > > > > > As I already have a fresh backup, I decided that it'd be easier to > > > > just re-install and copy data back over (maybe I messed up with > > > > repartitioning). So I've downloaded a fresh snapshot: > > > > > > > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img > > > > > > > > And re-installed. In the installer I choose all the same settings that > > > > were before: UEFI + GPT, default partition scheme it suggested (efi > > > > followed by freebsd-ufs followed by freebsd-swap), just increased the > > > > swap size. > > > > > > > > And the newly installed system won't boot just like a previous one: > > > > > > > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg > > > > > > > > Is there a way to recover this? > > > > > > > > Roman Bogorodskiy > > > > > > Just curious: > > > > > > When I installed FreeBSD last time from the recent (2018-07-26) USB flash > > > drive on a > > > SSD, the freebsd-swap partition followed immediately after the ESP and/or > > > freebsd-boot GPT loader partition. But in most cases I used to use ZFS > > > for testing. > > > > When I reinstalled it yesterday from -CURRENT snapshot mentioned above, > > in guided mode it suggested a similar partitioning schema that I use: > > > > =>40 1953525088 ada0 GPT (932G) > > 40 409600 1 efi (200M) > > 409640 1803550720 2 freebsd-ufs (860G) > > 1803960360 148897792 3 freebsd-swap (71G) > > 1952858152 666976- free - (326M) > > > > The only difference it that the freebsd-swap size was 3.5G (and > > therefore, freebsd-ufs is large), the order was the same. > > > > > Since I had my UEFI adventure of my own these days and received valuable > > > hints from > > > the development/maintenance team on some UEFI aspects, it would be of > > > interest to > > > know your recent hardware and, more importantly since I see the boot > > > order presented > > > in you screenshot, a dump of the efi variable settings. Just for > > > curiosity. For that, > > > you have to boot the recent USB flash drive image with UEFI-only, then > > > logon as root > > > and perform > > > > > > kldload efirt > > > > > > and then issue > > > > > > # efibootmgr -v > > > > > > In my case, it looks like > > > > > > [...] > > > [ohartmann]: sudo efibootmgr -v > > > BootCurrent: 0001 > > > Timeout: 3 seconds > > > BootOrder : 0001, 0002, 0003, 0004, 0005, > > > +Boot0001* FreeBSD-12 \ > > > > > > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi) > > > \ ada0p1:/efi/boot/BOOTx64.efi (null) > > > Boot0002* Hard Drive BBS(HD,,0x0) > > > Boot0003* CD/DVD Drive BBS(CDROM,,0x0) > > > Boot0004* USB BBS(USB,,0x0) > > > Boot0005* Network Card BBS(Network,,0x0) > > > Boot FreeBSD-12 > > > HD(1,GP
Re: EFI issues
O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Sat, 28 Jul 2018 11:29:40 +0400 > Roman Bogorodskiy schrieb: > > > Hi, > > > > I have a test box that's updated to -CURRENT usually once in a week or > > two. This box boots using UEFI. After a regular update about two weeks > > ago it started to panic on boot frequently (not UEFI related), but I > > could not get a crash dump because my swap partition was too small. So I > > moved data to the backup drive, repartitioned the main drive and boot > > again. This went fine, so I decided to upgrade to fresh -CURRENT from > > ~Jul 27th. Booting with the new kernel went fine, but after installworld > > machine stopped booting, and on the screen I see: > > > > FreeBSD/amd64 EFI loader, ... > > > > .. > > > > BootOrder: > > > > And then it gets stuck and nothing happens. > > > > As I already have a fresh backup, I decided that it'd be easier to > > just re-install and copy data back over (maybe I messed up with > > repartitioning). So I've downloaded a fresh snapshot: > > > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img > > > > And re-installed. In the installer I choose all the same settings that > > were before: UEFI + GPT, default partition scheme it suggested (efi > > followed by freebsd-ufs followed by freebsd-swap), just increased the > > swap size. > > > > And the newly installed system won't boot just like a previous one: > > > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg > > > > Is there a way to recover this? > > > > Roman Bogorodskiy > > Just curious: > > When I installed FreeBSD last time from the recent (2018-07-26) USB flash > drive on a SSD, > the freebsd-swap partition followed immediately after the ESP and/or > freebsd-boot GPT > loader partition. But in most cases I used to use ZFS for testing. When I reinstalled it yesterday from -CURRENT snapshot mentioned above, in guided mode it suggested a similar partitioning schema that I use: =>40 1953525088 ada0 GPT (932G) 40 409600 1 efi (200M) 409640 1803550720 2 freebsd-ufs (860G) 1803960360 148897792 3 freebsd-swap (71G) 1952858152 666976- free - (326M) The only difference it that the freebsd-swap size was 3.5G (and therefore, freebsd-ufs is large), the order was the same. > Since I had my UEFI adventure of my own these days and received valuable > hints from the > development/maintenance team on some UEFI aspects, it would be of interest to > know your > recent hardware and, more importantly since I see the boot order presented in > you > screenshot, a dump of the efi variable settings. Just for curiosity. For > that, you have > to boot the recent USB flash drive image with UEFI-only, then logon as root > and perform > > kldload efirt > > and then issue > > # efibootmgr -v > > In my case, it looks like > > [...] > [ohartmann]: sudo efibootmgr -v > BootCurrent: 0001 > Timeout: 3 seconds > BootOrder : 0001, 0002, 0003, 0004, 0005, > +Boot0001* FreeBSD-12 \ > > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi) > \ >ada0p1:/efi/boot/BOOTx64.efi (null) > Boot0002* Hard Drive BBS(HD,,0x0) > Boot0003* CD/DVD Drive BBS(CDROM,,0x0) > Boot0004* USB BBS(USB,,0x0) > Boot0005* Network Card BBS(Network,,0x0) > Boot FreeBSD-12 > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi) > ada0p1:/efi/boot/BOOTx64.efi (null) > > > Unreferenced Variables: > [...] > > Boot is the same as Boot0001 and is defined due to some "bug" Warner Losh > has fixed > recently, it is the same as Boot0001 Motherboard is (from dmidecode): Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 0806 Release Date: 02/20/2014 Address: 0xF Runtime Size: 64 kB ROM Size: 16 MB Characteristics: PCI is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5
Re: EFI issues
Roman Bogorodskiy wrote: > Hi, > > I have a test box that's updated to -CURRENT usually once in a week or > two. This box boots using UEFI. After a regular update about two weeks > ago it started to panic on boot frequently (not UEFI related), but I > could not get a crash dump because my swap partition was too small. So I > moved data to the backup drive, repartitioned the main drive and boot > again. This went fine, so I decided to upgrade to fresh -CURRENT from > ~Jul 27th. Booting with the new kernel went fine, but after installworld > machine stopped booting, and on the screen I see: > > FreeBSD/amd64 EFI loader, ... > > .. > > BootOrder: > > And then it gets stuck and nothing happens. > > As I already have a fresh backup, I decided that it'd be easier to > just re-install and copy data back over (maybe I messed up with > repartitioning). So I've downloaded a fresh snapshot: > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img > > And re-installed. In the installer I choose all the same settings that > were before: UEFI + GPT, default partition scheme it suggested (efi > followed by freebsd-ufs followed by freebsd-swap), just increased the > swap size. > > And the newly installed system won't boot just like a previous one: > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg > > Is there a way to recover this? Tried updating to get r336837 mentioned in another thread, and it still doesn't help. Current version is r336859. Partitioning schema looks this way: =>40 1953525088 ada0 GPT (932G) 40 409600 1 efi (200M) 409640 1803550720 2 freebsd-ufs (860G) 1803960360 148897792 3 freebsd-swap (71G) 1952858152 666976- free - (326M) I can boot it when booting from memstick r336739 and setting vfs.root.mountfrom="ufs:ada0p2". Roman Bogorodskiy signature.asc Description: PGP signature
EFI issues
Hi, I have a test box that's updated to -CURRENT usually once in a week or two. This box boots using UEFI. After a regular update about two weeks ago it started to panic on boot frequently (not UEFI related), but I could not get a crash dump because my swap partition was too small. So I moved data to the backup drive, repartitioned the main drive and boot again. This went fine, so I decided to upgrade to fresh -CURRENT from ~Jul 27th. Booting with the new kernel went fine, but after installworld machine stopped booting, and on the screen I see: FreeBSD/amd64 EFI loader, ... .. BootOrder: And then it gets stuck and nothing happens. As I already have a fresh backup, I decided that it'd be easier to just re-install and copy data back over (maybe I messed up with repartitioning). So I've downloaded a fresh snapshot: FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img And re-installed. In the installer I choose all the same settings that were before: UEFI + GPT, default partition scheme it suggested (efi followed by freebsd-ufs followed by freebsd-swap), just increased the swap size. And the newly installed system won't boot just like a previous one: https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg Is there a way to recover this? Roman Bogorodskiy signature.asc Description: PGP signature
Re: "panic: Unholding 5 with cnt = 0" head/amd64 @r331290
David Wolfskill wrote: > This is on my build machine, running a GENERIC kernel. (Laptop is still > building lib32 shim libraries as I type). > > Here's a copy/paste from the serial console: > > da3: Attempt to query device size failed: NOT READY, Medium not present > da3: quirks=0x2 > da3: Delete methods: <NONE(*),ZERO> > GEOM: new disk da1 > GEOM: new disk da2 > GEOM: new disk da3 > (da1:umass-sim0:0:0:1): PREVENT ALLOW MEDIUM REMOVAL not supported. > ugen0.4: at usbus0 > (dpanic: Unholding 5 with cnt = 0 > cpuid = 3 > time = 1521633742 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe4913c0 > vpanic() at vpanic+0x18d/frame 0xfe491420 > panic() at panic+0x43/frame 0xfe491480 > dadone() at dadone+0x1cc9/frame 0xfe4919e0 > xpt_done_process() at xpt_done_process+0x390/frame 0xfe491a20 > xpt_done_td() at xpt_done_td+0xf6/frame 0xfe491a70 > fork_exit() at fork_exit+0x84/frame 0xfe491ab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe491ab0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 15 tid 100065 ] > Stopped at kdb_enter+0x3b: movq$0,kdb_why > db> > > > Anything I can/should do to poke at it before trying to capture a dump? Looks like it's related to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510#c18 > Peace, > david > -- > David H. Wolfskillda...@catwhisker.org > An investigator who doesn't make a perp nervous isn't doing his job. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. Roman Bogorodskiy signature.asc Description: PGP signature
Re: Strange ARC/Swap/CPU on yesterday's -CURRENT
iere for building tests. I've noticed that as well. I have 16G of RAM and two disks, the first one is UFS with the system installation and the second one is ZFS which I use to store media and data files and for poudreire. I don't recall the exact date, but it started fairly recently. System would swap like crazy to a point when I cannot even ssh to it, and can hardly login through tty: it might take 10-15 minutes to see a command typed in the shell. I've updated loader.conf to have the following: vfs.zfs.arc_max="4G" vfs.zfs.prefetch_disable="1" It fixed the problem, but introduced a new one. When I'm building stuff with poudriere with ccache enabled, it takes hours to build even small projects like curl or gnutls. For example, current build: [10i386-default] [2018-03-07_07h44m45s] [parallel_build:] Queued: 3 Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 2 Time: 06:48:35 [02]: security/gnutls | gnutls-3.5.18 build (06:47:51) Almost 7 hours already and still going! gstat output looks like this: dT: 1.002s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 0 0 00.0 0 00.00.0 da0 0 1 0 00.0 11280.70.1 ada0 1106106439 64.6 0 00.0 98.8 ada1 0 1 0 00.0 11280.70.1 ada0s1 0 0 0 00.0 0 00.00.0 ada0s1a 0 0 0 00.0 0 00.00.0 ada0s1b 0 1 0 00.0 11280.70.1 ada0s1d ada0 here is UFS driver, and ada1 is ZFS. > Regards. > -- > Danilo G. Baio (dbaio) Roman Bogorodskiy signature.asc Description: PGP signature
lldb 6.0.0 segfaults on opening a core file
01698231 lldb`::LoadCore() at Process.cpp:2853
frame #18: 0x0184b85d lldb`::DoExecute() at
CommandObjectTarget.cpp:371
frame #19: 0x0181811f lldb`::Execute() at CommandObject.cpp:991
frame #20: 0x018268f8 lldb`::HandleCommand() at
CommandInterpreter.cpp:1683
frame #21: 0x01829e2a lldb`::IOHandlerInputComplete() at
CommandInterpreter.cpp:2771
frame #22: 0x018e25ff lldb`::Run() at IOHandler.cpp:573
frame #23: 0x0190ab5f lldb`::ExecuteIOHandlers() at
Debugger.cpp:961
frame #24: 0x0182a9a3 lldb`::RunCommandInterpreter() at
CommandInterpreter.cpp:2971
frame #25: 0x0192ce29 lldb`::RunCommandInterpreter() at
SBDebugger.cpp:905
frame #26: 0x01677263 lldb`::MainLoop() at Driver.cpp:1105
frame #27: 0x016779bc lldb`main at Driver.cpp:1253
frame #28: 0x01674095 lldb`_start(ap=,
cleanup=) at crt1.c:74
(lldb) fr s 4
frame #4: 0x017fa8e5 lldb`::ConsumeTemplateArgs() at
CPlusPlusNameParser.cpp:245
242 }
243}
244
-> 245assert(template_counter >= 0);
246if (template_counter > 0) {
247 return false;
248}
(lldb) expr template_counter
error: use of undeclared identifier 'template_counter' <-- is that because of
some optimizations?
(lldb)
Is that a known problem? Or maybe something wrong with my system? I
don't use lldb very often, but I don't remember it crashing like that.
Roman Bogorodskiy
signature.asc
Description: PGP signature
Re: lldb input issue
Pedro Giffuni wrote: > On 03/06/16 15:20, Pedro Giffuni wrote: > > > > > > El 06/03/2016 a las 15:05, Baptiste Daroussin escribió: > >> On Sun, Mar 06, 2016 at 10:55:27PM +0300, Roman Bogorodskiy wrote: > >>>Baptiste Daroussin wrote: > >>> > >>>> On Sun, Mar 06, 2016 at 07:44:34PM +0300, Roman Bogorodskiy wrote: > >>>>> Hi, > >>>>> > >>>>> I'm seeing an issue with lldb: when I start it (without arguments) and > >>>>> try to type commands, it looks like this: > >>>>> > >>>>> $ lldb > >>>>> (lldb) \U+7F68\U+7F65\U+7F6C\U+7F70\U+7F0A > >>>>> > >>>>> So, basically, I cannot execute any command and cannot even exit from > >>>>> its shell, only by ctrl-z and killing it. > >>>>> > >>>>> This happens to me on today's -CURRENT / amd64. > >>>>> > >>>>> I was wondering if that's an issue with my user's locale, but the > >>>>> behavior is same for root. > >>>>> > >>>>> Also, I can see exactly the same behavior with lldb on FreeBSD. > >>> ^^^ > >>> Oops, that's supposed to be 'freefall'. > >>> > >>>>> Is that some known issue or maybe configuration problem? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Roman Bogorodskiy > >>>> > >>>> > >>>> Sounds like an issue with libedit, probably due to the latest import > >>>> of libedit > >>>> (just a guess) > >>> It could be. BTW, I've installed lldb38 using pkg and it works fine. > >>> > >> Which is linked to libedit from ports (older that in base) so it seems > >> to prove > >> that libedit update might be the issue there. > > > > Hmm ... most of the changes were cosmetical. I will take a look though. > > > > Actually we have had two updates lately with sufficient changes that it > is not easy to find which may be the culprit. I will revert the last > change in the hope that it is enough. > > Sorry about this. Thanks, appears it fixed the issue. Roman Bogorodskiy signature.asc Description: PGP signature
Re: lldb input issue
Baptiste Daroussin wrote: > On Sun, Mar 06, 2016 at 07:44:34PM +0300, Roman Bogorodskiy wrote: > > Hi, > > > > I'm seeing an issue with lldb: when I start it (without arguments) and > > try to type commands, it looks like this: > > > > $ lldb > > (lldb) \U+7F68\U+7F65\U+7F6C\U+7F70\U+7F0A > > > > So, basically, I cannot execute any command and cannot even exit from > > its shell, only by ctrl-z and killing it. > > > > This happens to me on today's -CURRENT / amd64. > > > > I was wondering if that's an issue with my user's locale, but the > > behavior is same for root. > > > > Also, I can see exactly the same behavior with lldb on FreeBSD. ^^^ Oops, that's supposed to be 'freefall'. > > Is that some known issue or maybe configuration problem? > > > > Thanks, > > > > Roman Bogorodskiy > > > > Sounds like an issue with libedit, probably due to the latest import of > libedit > (just a guess) It could be. BTW, I've installed lldb38 using pkg and it works fine. Roman Bogorodskiy signature.asc Description: PGP signature
lldb input issue
Hi, I'm seeing an issue with lldb: when I start it (without arguments) and try to type commands, it looks like this: $ lldb (lldb) \U+7F68\U+7F65\U+7F6C\U+7F70\U+7F0A So, basically, I cannot execute any command and cannot even exit from its shell, only by ctrl-z and killing it. This happens to me on today's -CURRENT / amd64. I was wondering if that's an issue with my user's locale, but the behavior is same for root. Also, I can see exactly the same behavior with lldb on FreeBSD. Is that some known issue or maybe configuration problem? Thanks, Roman Bogorodskiy signature.asc Description: PGP signature
UEFI, loader and keyboard problems
Hi, I'm running -CURRENT amd64 and have weird problems with keyboard in loader. Specifically, some char keys produce numbers. For example: boot -- b66t The problem appears to be with the right side of the query layout. 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The same for the second row, 'h' is still 'h', but 'j' is '1' etc. That happens with USB keyboard only, PS/2 works as expected. I also cannot use keyboard in serial console in boot loader, but it becomes available when system boots. FreeBSD 11.0-CURRENT (GENERIC) #0 r282110: Mon Apr 27 20:49:15 UTC 2015 /boot/loader.conf: boot_multicons=YES boot_serial=YES comconsole_speed=115200 console=efi,comconsole Am I triggering some bug or it's some configuration problem? Roman Bogorodskiy pgpi8UjLW3LVP.pgp Description: PGP signature
Re: UEFI, loader and keyboard problems
Dimitry Andric wrote: On 16 May 2015, at 18:50, Roman Bogorodskiy no...@freebsd.org wrote: I'm running -CURRENT amd64 and have weird problems with keyboard in loader. Specifically, some char keys produce numbers. For example: boot -- b66t The problem appears to be with the right side of the query layout. 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The same for the second row, 'h' is still 'h', but 'j' is '1' etc. Is this maybe some weird keyboard in combination with NUM LOCK on? Urgh! That's right, numlock is the reason. It's some noname mini-keyboard. However, I still cannot use keyboard in loader via serial console, wondering if I'm doing something stupid as well... Roman Bogorodskiy pgpcn6M65a0Ed.pgp Description: PGP signature
Re: ffs_copyonwrite panics
Jeremie Le Hen wrote: Hi Roman, On Mon, May 24, 2010 at 03:21:41PM +0400, Roman Bogorodskiy wrote: I am not sure how to save coredump as when the system boots after the crash and starts saving coredump from swap partition to disk the system crashes again. Generally, the system is almost unusable and in order to try a new kernel I cross-compile it on my i386 laptop and copy in using livefs cdrom. Do you have an idea how to save a trace? Sorry for the late reply. If you're still undergoing this issue, once your kernel has crashed and dumped his memory, you can reboot using your previously working kernel. You will be able to save the core to the disk. I've tried old kernel when just spotted this issue, but with the old kernel and new world I wasn't able to use ppp so I gave up on that quickly. Back then I haven't had dumpdev configured so wan't able to save a dump. Anyways, in the end I've tried different various kernels, including 8.0 kernel and world but was still having problems with writing stuff to disk. Finally, I've did a reinstall of 8.0 with newfs for all partitions and it now works fine, so probably the fs was damaged somehow. Roman Bogorodskiy signature.asc Description: Digital signature
Re: ffs_copyonwrite panics
Jeff Roberson wrote: Tried today's -CURRENT and unfortunately the behaviour is still same. Can you give me a full stack trace? Do you have coredumps enabled? I would like to have you look at a few things in a core or send it to me with your kernel. I am not sure how to save coredump as when the system boots after the crash and starts saving coredump from swap partition to disk the system crashes again. Generally, the system is almost unusable and in order to try a new kernel I cross-compile it on my i386 laptop and copy in using livefs cdrom. Do you have an idea how to save a trace? Thanks, Roman Bogorodskiy signature.asc Description: Digital signature
Re: ffs_copyonwrite panics
Jeff Roberson wrote: On Tue, 18 May 2010, Roman Bogorodskiy wrote: Hi, I've been using -CURRENT last update in February for quite a long time and few weeks ago decided to finally update it. The update was quite unfortunate as system became very unstable: it just hangs few times a day and panics sometimes. Some things can be reproduced, some cannot. Reproducible ones: 1. background fsck always makes system hang 2. system crashes on operations with nullfs mounts (disabled that for now) The most annoying one is ffs_copyonwrite panic which I cannot reproduce. The thing is that if I will run 'startx' on it with some X apps it will panic just in few minutes. When I leave the box with nearly no stress (just use it as internet gateway for my laptop) it behaves a little better but will eventually crash in few hours anyway. This may have been my fault. Can you please update and let me know if it is resolved? There was both a deadlock and a copyonwrite panic as a result of the softupdates journaling import. I just fixed the deadlock today. Tried today's -CURRENT and unfortunately the behaviour is still same. Roman Bogorodskiy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ffs_copyonwrite panics
Hi, I've been using -CURRENT last update in February for quite a long time and few weeks ago decided to finally update it. The update was quite unfortunate as system became very unstable: it just hangs few times a day and panics sometimes. Some things can be reproduced, some cannot. Reproducible ones: 1. background fsck always makes system hang 2. system crashes on operations with nullfs mounts (disabled that for now) The most annoying one is ffs_copyonwrite panic which I cannot reproduce. The thing is that if I will run 'startx' on it with some X apps it will panic just in few minutes. When I leave the box with nearly no stress (just use it as internet gateway for my laptop) it behaves a little better but will eventually crash in few hours anyway. The even more annoying thing is that when I cannot save the dump, because when the system boots and runs 'savecore' it leads to fss_copyonwrite panic as well. The panic happens when about 90% complete (as seem via ctrl-t). Any ideas how to debug and get rid of this issue? System arch is amd64. I don't know what other details could be useful. Roman Bogorodskiy signature.asc Description: Digital signature
