error message during "mergemaster"
In FreeBSD 13.0 when I update the kernel and world I receive the following error message during mergemaster: ka-freebsd:/usr/src# mergemaster *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot make[4]: "/usr/src/lib/libc/net/Makefile.inc" line 130: warning: duplicate script for target "afterinstallconfig" ignored make[4]: "/usr/src/lib/libc/gen/Makefile.inc" line 554: warning: using previous script for "afterinstallconfig" defined here I looks like the generated kernel correctly works but the error message should not be there... What can be the cuase and how can I repair it? Best regards Krasznai András rendszermérnök [M&S_logo] 1136 Budapest, Pannónia utca 11. Tel: +36 1 703 2923 Mobil: +36 30 703 2923 Központ: +36 1 703 2920 Fax: +36 1 703 2949 email: krasznai.and...@mands.hu ___ 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: "Sleeping with non-sleepable lock" in NFS on recent -current
On 2019-Sep-16 09:32:52 +0300, Konstantin Belousov wrote:
>On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote:
>> I'm consistently seeing panics in the NFS code on recent -current on aarm64.
>> The panics are one of the following two:
>> Sleeping on "vmopar" with the following non-sleepable locks held:
>> exclusive sleep mutex NEWNFSnode lock (NEWNFSnode lock) r = 0
>> (0xfd0078b346f0) locked @ /usr/src/sys/fs/nfsclient/nfs_clport.c:432
>>
>> Sleeping thread (tid 100077, pid 35) owns a non-sleepable lock
>>
>> Both panics have nearly identical backtraces (see below). I'm running
>> diskless on a Rock64 with both filesystem and swap over NFS. The panics
>> can be fairly reliably triggered by any of:
>> * "make -j4 buildworld"
>> * linking the kernel (as part of buildkernel)
>> * "make installworld"
>>
>> Has anyone else seen this?
...
>Weird since this should have been fixed long time ago. Anyway, please
>try the following, it should fix the rest of cases.
>
>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
...
>@@ -540,7 +541,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr
>*nap, void *nvaper,
> } else {
> np->n_size = vap->va_size;
> np->n_flag |= NSIZECHANGED;
>- vnode_pager_setsize(vp, np->n_size);
>+ setnsize = 1;
Should this else block include a "nsize = np->n_size;"? Without it,
nsize will remain set to 0, which looks wrong.
--
Peter Jeremy
signature.asc
Description: PGP signature
Re: "Sleeping with non-sleepable lock" in NFS on recent -current
On Mon, Sep 16, 2019 at 05:44:28PM +1000, Peter Jeremy wrote:
> On 2019-Sep-16 09:32:52 +0300, Konstantin Belousov
> wrote:
> >On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote:
> >> I'm consistently seeing panics in the NFS code on recent -current on
> >> aarm64.
> >> The panics are one of the following two:
> >> Sleeping on "vmopar" with the following non-sleepable locks held:
> >> exclusive sleep mutex NEWNFSnode lock (NEWNFSnode lock) r = 0
> >> (0xfd0078b346f0) locked @ /usr/src/sys/fs/nfsclient/nfs_clport.c:432
> >>
> >> Sleeping thread (tid 100077, pid 35) owns a non-sleepable lock
> >>
> >> Both panics have nearly identical backtraces (see below). I'm running
> >> diskless on a Rock64 with both filesystem and swap over NFS. The panics
> >> can be fairly reliably triggered by any of:
> >> * "make -j4 buildworld"
> >> * linking the kernel (as part of buildkernel)
> >> * "make installworld"
> >>
> >> Has anyone else seen this?
> ...
>
> >Weird since this should have been fixed long time ago. Anyway, please
> >try the following, it should fix the rest of cases.
> >
> >diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
> ...
> >@@ -540,7 +541,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr
> >*nap, void *nvaper,
> > } else {
> > np->n_size = vap->va_size;
> > np->n_flag |= NSIZECHANGED;
> >-vnode_pager_setsize(vp, np->n_size);
> >+setnsize = 1;
>
> Should this else block include a "nsize = np->n_size;"? Without it,
> nsize will remain set to 0, which looks wrong.
Yes, you are right.
diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
index 471e029a8b5..63ea4736707 100644
--- a/sys/fs/nfsclient/nfs_clport.c
+++ b/sys/fs/nfsclient/nfs_clport.c
@@ -511,10 +511,10 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr
*nap, void *nvaper,
* zero np->n_attrstamp to indicate that
* the attributes are stale.
*/
- vap->va_size = np->n_size;
+ nsize = vap->va_size = np->n_size;
+ setnsize = 1;
np->n_attrstamp = 0;
KDTRACE_NFS_ATTRCACHE_FLUSH_DONE(vp);
- vnode_pager_setsize(vp, np->n_size);
} else if (np->n_flag & NMODIFIED) {
/*
* We've modified the file: Use the larger
@@ -526,7 +526,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr
*nap, void *nvaper,
np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
}
- vnode_pager_setsize(vp, np->n_size);
+ nsize = np->n_size;
+ setnsize = 1;
} else if (vap->va_size < np->n_size) {
/*
* When shrinking the size, the call to
@@ -538,9 +539,9 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr
*nap, void *nvaper,
np->n_flag |= NSIZECHANGED;
setnsize = 1;
} else {
- np->n_size = vap->va_size;
+ nsize = np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
- vnode_pager_setsize(vp, np->n_size);
+ setnsize = 1;
}
} else {
np->n_size = vap->va_size;
___
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: "Sleeping with non-sleepable lock" in NFS on recent -current
On 2019-Sep-16 11:19:02 +0300, Konstantin Belousov wrote: >diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c >index 471e029a8b5..63ea4736707 100644 ... Thanks, that patch seems much more stable. -- Peter Jeremy signature.asc Description: PGP signature
hang up with r352239 and r352386 with i5-7500
Hi. My machine (with core i5-7500) is hangup when loading i915kms.ko on r352239 and r352386 (1300047). This machine was working good with r351728 (1300044). /etc/rc.conf has the following line. kld_list="i915kms.ko" It is good wowking with core i7-4500U on r352239 (1300047). -- Masachika ISHIZUKA ___ 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: hang up with r352239 and r352386 with i5-7500
On 2019-09-16 13:09, Masachika ISHIZUKA wrote: Hi. My machine (with core i5-7500) is hangup when loading i915kms.ko on r352239 and r352386 (1300047). This machine was working good with r351728 (1300044). /etc/rc.conf has the following line. kld_list="i915kms.ko" It is good wowking with core i7-4500U on r352239 (1300047). Hi! Which version of drm-current are you using? Have you recompiled it after updating the kernel? What happens if you change to kld_list="/boot/modules/i915kms.ko"? There is a patch here: https://github.com/FreeBSDDesktop/kms-drm/pull/175/commits/7b8fab2461262b22f64425146b60608bb0e0240d that might solve the issue, can you apply that and recompile drm-current-kmod and see if it works? Thanks! Regards -- Niclas Zeising ___ 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"
panic: sleeping thread on r352386
Hi. This panic happens on 1300047 (both r352239 and r352386) with core i5-7500 as follows. This panic dose not happen on r351728 (1300044). (The following lines were typed by hand so they might have some miss typed letters.) == Sleeping thread (tid 100177, pid 1814) owns a non-sleepable lock KDB: stack backtrace of thread 100177: sched_switch() at sched_switch+0x3f0/frame 0xfe008bc0e590 mi_switch() at mi_switch+0x172/frame 0xfe008bc0e5c0 sleepq_switch() at sleepq_switch+0x110/frame 0xfe008bc0e600 sleepQ-wait() at sleepq_wait+0x43/frame 0xfe008bc0e630 vm_page_sleep_if_busy() at (snip) vm_object_page_remove() at (snip) vnode_pager_setsize() at (snip) nfscl_loadattrcache() at (snip) ncl_writerpc() at (snip) ncl_doio() at (snip) nfssvc_iod() at (snip) fork_exit() at (snip) fork_trampoline() at (snip) --- trap 0, rip = 0, rsp = 0, rbp = 0 --- panic: sleeping thread cpuid = 3 time = 1568633100 KBD: stack backtrace: db_trace_self_wrapper() at (snip) vpanic() at (snip) (snip) --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter : panic [ thread pid 2108 tid 100236 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why db> -- Masachika ISHIZUKA ___ 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: hang up with r352239 and r352386 with i5-7500
>>My machine (with core i5-7500) is hangup when loading i915kms.ko >> on r352239 and r352386 (1300047). >>This machine was working good with r351728 (1300044). >>/etc/rc.conf has the following line. >> kld_list="i915kms.ko" >>It is good wowking with core i7-4500U on r352239 (1300047). >> > > Hi! > Which version of drm-current are you using? Thank you for reply. % pkg info drm-current-kmod drm-current-kmod-4.16.g20190828 Name : drm-current-kmod Version: 4.16.g20190828 Installed on : Mon Sep 2 14:42:56 2019 JST Origin : graphics/drm-current-kmod Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : graphics kld Licenses : BSD2CLAUSE, MIT, GPLv2 Maintainer : x...@freebsd.org WWW: https://github.com/FreeBSDDesktop/kms-drm Comment: DRM modules for the linuxkpi-based KMS components Options: DEBUG : off SOURCE : on Annotations: FreeBSD_version: 1300042 repo_type : binary repository : FreeBSD Flat size : 122MiB Description: amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components. Currently corresponding to Linux 4.16 DRM. This version is for FreeBSD CURRENT. amdgpu and radeonkms are known to fail with EFI boot. WWW: https://github.com/FreeBSDDesktop/kms-drm > Have you recompiled it after updating the kernel? No. > What happens if you change to kld_list="/boot/modules/i915kms.ko"? The same hangup has occured. > There is a patch here: > https://github.com/FreeBSDDesktop/kms-drm/pull/175/commits/7b8fab2461262b22f64425146b60608bb0e0240d > that might solve the issue, can you apply that and recompile > drm-current-kmod and see if it works? Thank you. I did the following. # portsnap fetch # portsnap update # cd /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux # vi pagevec.h (comment out line 49) # cd /usr/ports/graphics/drm-current-kmod # make # make deinstall # make install # reboot But, it hangs up. -- Masachika ISHIZUKA ___ 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: hang up with r352239 and r352386 with i5-7500
On Mon, 16 Sep 2019 20:09+0900, Masachika ISHIZUKA wrote: > My machine (with core i5-7500) is hangup when loading i915kms.ko > on r352239 and r352386 (1300047). > This machine was working good with r351728 (1300044). > > /etc/rc.conf has the following line. > kld_list="i915kms.ko" Pardon the intrusion. What happens if you add drm2.ko and/or switch to absolute paths? This is what I had to put in my /etc/rc.conf for a Dell Latitude E5530 to get rid of the message of drm2 being deprecated: kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko" -- Trond. ___ 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: svn commit: r351858 - in head: bin/uuidgen ...
On Sat, 14 Sep 2019 19:41:06 +0200 mj-mailingl...@gmx.de wrote: > Building a jail from pkgbase packages after base r351858 shows this cap_mkdb > message: > > to create the jail this command is used: > > pkg --rootdir /jails/test01 -o 'ASSUME_ALWAYS_YES=true' -o > 'ABI=FreeBSD:13:amd64' install --repository FreeBSD-base FreeBSD-utilities > FreeBSD-rc > (note: FreeBSD-base is the repository name, not a package) > > ... > Checking integrity... done (0 conflicting) > [1/20] Installing FreeBSD-clibs-13.0.s20190914152450... > [1/20] Extracting FreeBSD-clibs-13.0.s20190914152450: .. done > [2/20] Installing FreeBSD-runtime-13.0.s20190914152450... > [2/20] Extracting FreeBSD-runtime-13.0.s20190914152450: .. done > cap_mkdb: file argument: No such file or directory > [3/20] Installing FreeBSD-utilities-13.0.s20190914152450... > [3/20] Extracting FreeBSD-utilities-13.0.s20190914152450: .. done > [4/20] Installing FreeBSD-rc-13.0.s20190914152450... > [4/20] Extracting FreeBSD-rc-13.0.s20190914152450: .. done > ... > > This happens, after the login.conf file was moved into the Freebsd-utilities > package. > The order in which the packages are installed is problematic, since cap_mkdb > is executed in step 2, the FreeBSD-runtime package installation, > but the login.conf file is installed in step 3, the FreeBSD-utilities. > > > I opened a bugreport: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240582 > > -- > Martin Hi, thanks for the report, it's now fixed in r352389. -- Emmanuel Vadot ___ 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: hang up with r352239 and r352386 with i5-7500
>> My machine (with core i5-7500) is hangup when loading i915kms.ko >> on r352239 and r352386 (1300047). >> This machine was working good with r351728 (1300044). >> >> /etc/rc.conf has the following line. >> kld_list="i915kms.ko" > > Pardon the intrusion. > What happens if you add drm2.ko and/or switch to absolute paths? > > This is what I had to put in my /etc/rc.conf for a Dell Latitude > E5530 to get rid of the message of drm2 being deprecated: > > kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko" Hi. Thank you for mail. I'm using 13-current and it has no longer drm2.ko. This machine was working good on r351728 as follows. r351728% kldstat Id Refs AddressSize Name 1 90 0x8020 2336bb0 kernel 21 0x82537000 7278 ums.ko 31 0x82ef9000 aa70 tmpfs.ko 41 0x82f04000 4fb8 linprocfs.ko 54 0x82f09000 3d70 linux_common.ko 61 0x82f0d000 24fe linsysfs.ko 71 0x82f1 12eb90 i915kms.ko 81 0x8303f00077e90 drm.ko 94 0x830b7000125f0 linuxkpi.ko 102 0x830ca00013f30 linuxkpi_gplv2.ko 112 0x830de000 8e0 lindebugfs.ko 121 0x830df000 240d i915_kbl_dmc_ver1_04_bin.ko 131 0x830e2000 a218 if_lagg.ko 141 0x830ed000 3f00 ng_ubt.ko 156 0x830f1000 a998 netgraph.ko 162 0x830fc000 9378 ng_hci.ko 173 0x83106000 9c0 ng_bluetooth.ko 181 0x83107000 c890 snd_uaudio.ko 191 0x83114000 1840 uhid.ko 201 0x83116000 1b00 wmt.ko 211 0x83118000 d560 ng_l2cap.ko 221 0x8312600019900 ng_btsocket.ko 231 0x8314 2100 ng_socket.ko 241 0x83143000263b0 ipfw.ko 251 0x8316a0003c960 linux.ko 261 0x831a700034b70 linux64.ko 271 0x831dc000 45a0 autofs.ko 281 0x831e1000 acf mac_ntpd.ko -- Masachika ISHIZUKA ___ 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: hang up with r352239 and r352386 with i5-7500
On 2019-09-16 15:13, Masachika ISHIZUKA wrote: My machine (with core i5-7500) is hangup when loading i915kms.ko on r352239 and r352386 (1300047). This machine was working good with r351728 (1300044). /etc/rc.conf has the following line. kld_list="i915kms.ko" Pardon the intrusion. What happens if you add drm2.ko and/or switch to absolute paths? This is what I had to put in my /etc/rc.conf for a Dell Latitude E5530 to get rid of the message of drm2 being deprecated: kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko" Hi. Thank you for mail. I'm using 13-current and it has no longer drm2.ko. This machine was working good on r351728 as follows. r351728% kldstat Id Refs AddressSize Name 1 90 0x8020 2336bb0 kernel 21 0x82537000 7278 ums.ko 31 0x82ef9000 aa70 tmpfs.ko 41 0x82f04000 4fb8 linprocfs.ko 54 0x82f09000 3d70 linux_common.ko 61 0x82f0d000 24fe linsysfs.ko 71 0x82f1 12eb90 i915kms.ko 81 0x8303f00077e90 drm.ko 94 0x830b7000125f0 linuxkpi.ko 102 0x830ca00013f30 linuxkpi_gplv2.ko 112 0x830de000 8e0 lindebugfs.ko 121 0x830df000 240d i915_kbl_dmc_ver1_04_bin.ko 131 0x830e2000 a218 if_lagg.ko 141 0x830ed000 3f00 ng_ubt.ko 156 0x830f1000 a998 netgraph.ko 162 0x830fc000 9378 ng_hci.ko 173 0x83106000 9c0 ng_bluetooth.ko 181 0x83107000 c890 snd_uaudio.ko 191 0x83114000 1840 uhid.ko 201 0x83116000 1b00 wmt.ko 211 0x83118000 d560 ng_l2cap.ko 221 0x8312600019900 ng_btsocket.ko 231 0x8314 2100 ng_socket.ko 241 0x83143000263b0 ipfw.ko 251 0x8316a0003c960 linux.ko 261 0x831a700034b70 linux64.ko 271 0x831dc000 45a0 autofs.ko 281 0x831e1000 acf mac_ntpd.ko Hi! Can you please use absolute paths to i915kms.ko anyway, just to test? Thanks! Regards -- Niclas Zeising ___ 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: hang up with r352239 and r352386 with i5-7500
> Can you please use absolute paths to i915kms.ko anyway, just to test? The same hang up occure with kld_list="/boot/modules/i915kms.ko" in /etc/rc.conf. -- Masachika ISHIZUKA ___ 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: hang up with r352239 and r352386 with i5-7500
On 2019-09-16 16:06, Masachika ISHIZUKA wrote: Can you please use absolute paths to i915kms.ko anyway, just to test? The same hang up occure with kld_list="/boot/modules/i915kms.ko" in /etc/rc.conf. Even after applying the patch I suggested? Regards -- Niclas Zeising ___ 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: panic: sleeping thread on r352386
On Monday, 16 September 2019 7:55:32 PM AWST Masachika ISHIZUKA wrote: > Hi. > > This panic happens on 1300047 (both r352239 and r352386) with core > i5-7500 as follows. This panic dose not happen on r351728 (1300044). > (The following lines were typed by hand so they might have some miss > typed letters.) > > == > Sleeping thread (tid 100177, pid 1814) owns a non-sleepable lock > KDB: stack backtrace of thread 100177: [removed backtrace] https://svnweb.freebsd.org/base?view=revision&revision=352393 ___ 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: hang up with r352239 and r352386 with i5-7500
> On 2019-09-16 16:06, Masachika ISHIZUKA wrote:
>>> Can you please use absolute paths to i915kms.ko anyway, just to test?
>>The same hang up occure with kld_list="/boot/modules/i915kms.ko"
>> in /etc/rc.conf.
>>
>
> Even after applying the patch I suggested?
Yes.
kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"
will hang as well.
/boot/modules/{drm,i915kms}.ko is patched modules.
# /boot/kernel.r352239/{drm,i915kms}.ko is not patched.
--
Masachika ISHIZUKA
___
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"
r352368 can't boot
Hi,all Yesterday I've updated latest head (r352368) and rebuild 13.0-CURRENT. All went fine, but when I boot, it's stopped at boot stage. Then I typed `boot', booted normally and put login prompt and login go ahead. But `shutdown -r now', stopped at loader prompt same as login case. What happened? All I've done is whithin bhyve VM. root@vm:~ # vm start tbedfc Starting tbedfc * found guest in /vm/tbedfc * booting... root@vm:~ # vm console tbedfc Connected OK boot /boot/kernel/kernel text=0x16d7bdc data=0x1c8af8+0x64e118 syms=[0x8+0x182778+0x8+0x19fc7a] /boot/entropy size=0x1000 Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #0 r352368: Mon Sep 16 13:37:27 JST 2019 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. CPU: Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz (3503.56-MHz K8-class CPU) Origin="GenuineIntel" Id=0x906e9 Family=0x6 Model=0x9e Stepping=9 Features=0x9f83fbff Features2=0xfeda7a17 AMD Features=0x24100800 AMD Features2=0x121 Structured Extended Features=0xf39 XSAVE Features=0x1 TSC: P-state invariant Hypervisor: Origin = "bhyve bhyve " real memory = 5368709120 (5120 MB) avail memory = 4090740736 (3901 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-31 Timecounter "TSC-low" frequency 1751779076 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 000.42 [4335] netmap_init netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x811bcfa0, 0) error 19 [ath_hal] loaded nexus0 cryptosoft0: acpi0: acpi0: Power Button (fixed) atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 16777216 Hz quality 950 Event timer "HPET" frequency 16777216 Hz quality 550 Event timer "HPET1" frequency 16777216 Hz quality 450 Event timer "HPET2" frequency 16777216 Hz quality 450 Event timer "HPET3" frequency 16777216 Hz quality 450 Event timer "HPET4" frequency 16777216 Hz quality 450 Event timer "HPET5" frequency 16777216 Hz quality 450 Event timer "HPET6" frequency 16777216 Hz quality 450 Event timer "HPET7" frequency 16777216 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 virtio_pci0: port 0x2000-0x203f mem 0xc000-0xc0001fff irq 16 at device 4.0 on pci0 vtblk0: on virtio_pci0 vtblk0: 8192MB (16777216 512 byte sectors) virtio_pci1: port 0x2040-0x205f mem 0xc0002000-0xc0003fff irq 17 at device 5.0 on pci0 vtnet0: on virtio_pci1 vtnet0: Ethernet address: 58:9c:fc:0c:10:58 vtnet0: netmap queues/slots: TX 1/1024, RX 1/512 000.000150 [ 503] vtnet_netmap_attach vtnet attached txq=1, txd=1024 rxq=1, rxd=512 isab0: at device 31.0 on pci0 isa0: on isab0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] driver bug: Unable to set devclass (class: atkbdc devname: (unknown)) psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 vga0: at port 0x3b0-0x3bb iomem 0xb-0xb7fff pnpid PNP0900 on isa0 Timecounters tick every 10.000 msec usb_needs_explore_all: no devclass WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/vtbd0p2 [rw]... Setting hostuuid: fd03833b-4ce8-11e8-a966-589cfc0c1058. Setting hostid: 0x13d7974a. Starting file system checks: /dev/vtbd0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/vtbd0p2: clean, 376431 free (7015 frags, 46177 blocks, 0.6% fragmentation) Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat 32-bit compatibility ldconfig path: /usr/lib32 Setting hostname: tbedfc. Setting up harvesting: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . lo0: link state changed to UP vtnet0: link state changed to UP Starting Network: lo0 vtn
Re: panic: sleeping thread on r352386
>> This panic happens on 1300047 (both r352239 and r352386) with core >> i5-7500 as follows. This panic dose not happen on r351728 (1300044). >> (The following lines were typed by hand so they might have some miss >> typed letters.) >> >> == >> Sleeping thread (tid 100177, pid 1814) owns a non-sleepable lock >> KDB: stack backtrace of thread 100177: > > > https://svnweb.freebsd.org/base?view=revision&revision=352393 Thank you for reply. I updated to r352431 and this does not panic. Thank you very much. But 'make buildworld' fails by segment fault like below. (buildworld is running over the nfs file system.) --- modules-all --- --- ath_hal_ar5211.ko.debug --- objcopy --only-keep-debug ath_hal_ar5211.ko.full ath_hal_ar5211.ko.debug Segmentation fault (core dumped) *** [ath_hal_ar5211.ko.debug] Error code 139 make[4]: stopped in /usr/altlocal/freebsd-current/src/sys/modules/ath_hal_ar52111 error The position of segment fault is diffrent each time. The below is output of another 'make buildworld'. --- kernel.full --- Segmentation fault (core dumped) *** [kernel.full] Error code 139 make[2]: stopped in /usr/altlocal/freebsd-current/obj/usr/altlocal/freebsd-current/src/amd64.amd64/sys/GENERIC /var/log/messages is shown as bellow. Sep 17 11:22:56 okra kernel: Failed to fully fault in a core file segment at VA 0x800a0 with size 0x163000 to be written at offset 0x84a000 for process nm Sep 17 11:22:56 okra kernel: pid 53593 (nm), jid 0, uid 16220: exited on signal 11 (core dumped) Sep 17 11:22:57 okra kernel: Failed to fully fault in a core file segment at VA 0x800a0 with size 0x163000 to be written at offset 0x88b000 for process objcopy Sep 17 11:22:57 okra kernel: pid 53603 (objcopy), jid 0, uid 16220: exited on signal 11 (core dumped) Retry 'make buildworld' Sep 17 12:24:05 okra kernel: Failed to fully fault in a core file segment at VA 0x8002f6000 with size 0x93000 to be written at offset 0x239000 for process nm Sep 17 12:24:05 okra kernel: pid 96873 (nm), jid 0, uid 16220: exited on signal 11 (core dumped) Sep 17 12:24:05 okra kernel: Failed to fully fault in a core file segment at VA 0x80035f000 with size 0x93000 to be written at offset 0x281000 for process objcopy Sep 17 12:24:06 okra kernel: pid 96889 (objcopy), jid 0, uid 16220: exited on signal 11 (core dumped) Retry 'make buildworld' Sep 17 14:01:39 okra kernel: Failed to fully fault in a core file segment at VA 0x8048da000 with size 0x112000 to be written at offset 0x1a33000 for process ld.lld Sep 17 14:01:51 okra kernel: Failed to fully fault in a core file segment at VA 0x8117cc000 with size 0x1e7000 to be written at offset 0xe925000 for process ld.lld Sep 17 14:01:53 okra kernel: pid 50292 (ld.lld), jid 0, uid 16220: exited on signal 11 (core dumped) I can 'make buildworld' successfully on r351728(1300044). -- Masachika ISHIZUKA ___ 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: r352368 can't boot
> On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko wrote: > > Hi,all > > Yesterday I've updated latest head (r352368) and rebuild > 13.0-CURRENT. All went fine, but when I boot, it's stopped > at boot stage. Then I typed `boot', booted normally and put > login prompt and login go ahead. But `shutdown -r now', > stopped at loader prompt same as login case. What happened? > All I've done is whithin bhyve VM. > > > Consoles: userboot > > FreeBSD/amd64 User boot, Revision 1.1 > (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org) > Loading /boot/defaults/loader.conf > xemit not found > Error while including /boot/frames.4th, in the line: >h_el @ xemit > > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more detailed help. > OK > This is unfortunate case where the guest image has more recent boot scripts than hosts /boot/userboot.so has. I did push the fix for that issue to stable/11 and stable/12. The patch does introduce xemit word. Such situation is unfortunate, but accident waiting to happen with this method where we are attempting to use bootloader (userboot.so) from older system to load guest vm. rgds, 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"
