SCHED_ULE makes 256Mbyte i386 unusable
I decided to start a new thread on current related to SCHED_ULE, since I see more than just performance degradation and on a recent current kernel. (I cc'd a couple of the people discussing performance problems in freebsd-stable recently under a subject line of "Re: kern.sched.quantum: Creepy, sadistic scheduler". When testing a pNFS server on a single core i386 with 256Mbytes using a Dec. 2017 current/head kernel, I would see about a 30% performance degradation (elapsed run time for a kernel build over NFSv4.1) when the server kernel was built with options SCHED_ULE instead of options SCHED_4BSD Now, with a kernel from a couple of days ago, the options SCHED_ULE kernel becomes unusable shortly after starting testing. I have seen two variants of this: - Became essentially hung. All I could do was ping the machine from the network. - Reported "vm_thread_new: kstack allocation failed and then any attempt to do anything gets "No more processes". with the only difference being a kernel built with options SCHED_4BSD everything works and performs the same as the Dec 2017 kernel. I can try rolling back through the revisions, but it would be nice if someone could suggest where to start, because it takes a couple of hours to build a kernel on this system. So, something has made things worse for a head/current kernel this winter, rick ___ 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: SCHED_ULE makes 256Mbyte i386 unusable
On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote: > I decided to start a new thread on current related to SCHED_ULE, since I see > more than just performance degradation and on a recent current kernel. > (I cc'd a couple of the people discussing performance problems in > freebsd-stable > recently under a subject line of "Re: kern.sched.quantum: Creepy, sadistic > scheduler". > > When testing a pNFS server on a single core i386 with 256Mbytes using a Dec. > 2017 > current/head kernel, I would see about a 30% performance degradation (elapsed > run time for a kernel build over NFSv4.1) when the server kernel was built > with > options SCHED_ULE > instead of > options SCHED_4BSD > > Now, with a kernel from a couple of days ago, the > options SCHED_ULE > kernel becomes unusable shortly after starting testing. > I have seen two variants of this: > - Became essentially hung. All I could do was ping the machine from the > network. > - Reported "vm_thread_new: kstack allocation failed > and then any attempt to do anything gets "No more processes". This is strange. It usually means that you get KVA either exhausted or severly fragmented. Enter ddb, it should be operational since pings are replied. Try to see where the threads are stuck. > with the only difference being a kernel built with > options SCHED_4BSD > everything works and performs the same as the Dec 2017 kernel. > > I can try rolling back through the revisions, but it would be nice if someone > could suggest where to start, because it takes a couple of hours to build a > kernel on this system. > > So, something has made things worse for a head/current kernel this winter, > rick There are at least two potentially relevant changes. First is r326758 Dec 11 which bumped KSTACK_PAGES on i386 to 4. Second is r332489 Apr 13, which introduced 4/4G KVA/UVA split. Consequences of the first one are obvious, it is much harder to find the place to map the stack. Second change, on the other hand, provides almost full 4G for KVA and should have mostly compensate for the negative effects of the first. And, I cannot see how changing the scheduler would fix or even affect that behaviour. ___ 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"
i386 hangs during halt "vnodes remaining... 0 time out"
With a recent head/current kernel (doesn't happen when running a Dec. 2017 one), when I do a halt, it gets as far as: vnodes remaining... 0 time out and that's it (the time out appears several seconds after the first "0"). With a Dec. 2017 kernel there would be several "0"s printed. It appears that it is stuck in the first iteration of the sched_sync() loop after it is no longer in SYNCER_RUNNING state. Any ideas? rick ___ 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: i386 hangs during halt "vnodes remaining... 0 time out"
On Sat, 21 Apr 2018 21:09:09 + Rick Macklem wrote:
> With a recent head/current kernel (doesn't happen when running a Dec.
> 2017 one), when I do a halt, it gets as far as:
>
> vnodes remaining... 0 time out
>
> and that's it (the time out appears several seconds after the first "0").
> With a Dec. 2017 kernel there would be several "0"s printed.
> It appears that it is stuck in the first iteration of the sched_sync()
> loop after it is no longer in SYNCER_RUNNING state.
>
> Any ideas? rick
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404
I have a patch (attached) but haven't been able to test it yet.
Index: sys/kern/vfs_bio.c
===
--- sys/kern/vfs_bio.c (revision 332165)
+++ sys/kern/vfs_bio.c (working copy)
@@ -791,9 +791,12 @@ bufspace_daemon(void *arg)
{
struct bufdomain *bd;
+ EVENTHANDLER_REGISTER(shutdown_pre_sync, kthread_shutdown, curthread,
+ SHUTDOWN_PRI_LAST);
+
bd = arg;
for (;;) {
- kproc_suspend_check(curproc);
+ kthread_suspend_check();
/*
* Free buffers from the clean queue until we meet our
@@ -3357,7 +3360,7 @@ buf_daemon()
/*
* This process needs to be suspended prior to shutdown sync.
*/
- EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, bufdaemonproc,
+ EVENTHANDLER_REGISTER(shutdown_pre_sync, kthread_shutdown, curthread,
SHUTDOWN_PRI_LAST);
/*
@@ -3381,7 +3384,7 @@ buf_daemon()
bd_request = 0;
mtx_unlock(&bdlock);
- kproc_suspend_check(bufdaemonproc);
+ kthread_suspend_check();
/*
* Save speedupreq for this pass and reset to capture new
___
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: i386 hangs during halt "vnodes remaining... 0 time out"
On 04/21/2018 23:09, Rick Macklem wrote: With a recent head/current kernel (doesn't happen when running a Dec. 2017 one), when I do a halt, it gets as far as: vnodes remaining... 0 time out and that's it (the time out appears several seconds after the first "0"). With a Dec. 2017 kernel there would be several "0"s printed. It appears that it is stuck in the first iteration of the sched_sync() loop after it is no longer in SYNCER_RUNNING state. Any ideas? rick ___ 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" There is a PR which seems related: 227404 I was hit by this problem when upgrading an i386 UP system from r329142 to r332518. The culprit appears to be r329612. I reverted 4 files: sys/kern/vfs_bio.c -> r329187 sys/kern/vfs_subr.c -> r328643 sys/sys/buf.h -> r329078 sys/sys/bufobj.h -> r326256 rebuild the system, and the hang disappeared. I have now 2 i386 UP and 1 amd64 MP systems running with this modification, and 1 RPI2 in the pipe line. Hope it helps Claude Buisson ___ 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: i386 hangs during halt "vnodes remaining... 0 time out"
In message <20180421234934.10d7d...@kalimero.tijl.coosemans.org>, Tijl
Cooseman
s writes:
> --MP_/TDsO+CDIra7UXGs=vVO3NTB
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> On Sat, 21 Apr 2018 21:09:09 + Rick Macklem wrote:
> > With a recent head/current kernel (doesn't happen when running a Dec.
> > 2017 one), when I do a halt, it gets as far as:
> >
> > vnodes remaining... 0 time out
> >
> > and that's it (the time out appears several seconds after the first "0").
> > With a Dec. 2017 kernel there would be several "0"s printed.
> > It appears that it is stuck in the first iteration of the sched_sync()
> > loop after it is no longer in SYNCER_RUNNING state.
> >
> > Any ideas? rick
>
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404
> I have a patch (attached) but haven't been able to test it yet.
I've noticed this as well on my old Penium-M laptop (updated about
twice a year). I'll try your patch this weekend or early next week.
~cy
>
> --MP_/TDsO+CDIra7UXGs=vVO3NTB
> Content-Type: text/x-patch
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment; filename=bufdaemon.patch
>
> Index: sys/kern/vfs_bio.c
> ===
> --- sys/kern/vfs_bio.c(revision 332165)
> +++ sys/kern/vfs_bio.c(working copy)
> @@ -791,9 +791,12 @@ bufspace_daemon(void *arg)
> {
> struct bufdomain *bd;
>
> + EVENTHANDLER_REGISTER(shutdown_pre_sync, kthread_shutdown, curthread,
> + SHUTDOWN_PRI_LAST);
> +
> bd = arg;
> for (;;) {
> - kproc_suspend_check(curproc);
> + kthread_suspend_check();
>
> /*
>* Free buffers from the clean queue until we meet our
> @@ -3357,7 +3360,7 @@ buf_daemon()
> /*
>* This process needs to be suspended prior to shutdown sync.
>*/
> - EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, bufdaemonproc,
> + EVENTHANDLER_REGISTER(shutdown_pre_sync, kthread_shutdown, curthread,
> SHUTDOWN_PRI_LAST);
>
> /*
> @@ -3381,7 +3384,7 @@ buf_daemon()
> bd_request = 0;
> mtx_unlock(&bdlock);
>
> - kproc_suspend_check(bufdaemonproc);
> + kthread_suspend_check();
>
> /*
>* Save speedupreq for this pass and reset to capture new
>
> --MP_/TDsO+CDIra7UXGs=vVO3NTB
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
> 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"
>
> --MP_/TDsO+CDIra7UXGs=vVO3NTB--
>
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
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: SCHED_ULE makes 256Mbyte i386 unusable
Konstantin Belousov wrote: >On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote: >> I decided to start a new thread on current related to SCHED_ULE, since I see >> more than just performance degradation and on a recent current kernel. >> (I cc'd a couple of the people discussing performance problems in >> freebsd-stable >> recently under a subject line of "Re: kern.sched.quantum: Creepy, sadistic >> scheduler". >> >> When testing a pNFS server on a single core i386 with 256Mbytes using a Dec. >> 2017 >> current/head kernel, I would see about a 30% performance degradation (elapsed >> run time for a kernel build over NFSv4.1) when the server kernel was built >> with >> options SCHED_ULE >> instead of >> options SCHED_4BSD >> >> Now, with a kernel from a couple of days ago, the >> options SCHED_ULE >> kernel becomes unusable shortly after starting testing. >> I have seen two variants of this: >> - Became essentially hung. All I could do was ping the machine from the >> network. >> - Reported "vm_thread_new: kstack allocation failed >> and then any attempt to do anything gets "No more processes". >This is strange. It usually means that you get KVA either exhausted or >severly fragmented. Yes. I reduced the number of nfsd threads from 256->32 and the SCHED_ULE kernel is working ok now. I haven't done enough to compare performance yet. Maybe I'll post again when I have some numbers. >Enter ddb, it should be operational since pings are replied. Try to see >where the threads are stuck. I didn't do this, since reducing the number of kernel threads seems to have fixed the problem. For the pNFS server, the nfsd threads will spawn additional kernel threads to do proxies to the mirrored DS servers. >> with the only difference being a kernel built with >> options SCHED_4BSD >> everything works and performs the same as the Dec 2017 kernel. >> >> I can try rolling back through the revisions, but it would be nice if someone >> could suggest where to start, because it takes a couple of hours to build a >> kernel on this system. >> >> So, something has made things worse for a head/current kernel this winter, >> rick > >There are at least two potentially relevant changes. > >First is r326758 Dec 11 which bumped KSTACK_PAGES on i386 to 4. I've been running this machine with KSTACK_PAGES=4 for some time, so no change. >Second is r332489 Apr 13, which introduced 4/4G KVA/UVA split. Could this change have resulted in the system being able to allocate fewer kernel threads/stacks for some reason? >Consequences of the first one are obvious, it is much harder to find >the place to map the stack. Second change, on the other hand, provides >almost full 4G for KVA and should have mostly compensate for the negative >effects of the first. > >And, I cannot see how changing the scheduler would fix or even affect that >behaviour. My hunch is that the system was running near its limit for kernel threads/stacks. Then, somehow, the timing SCHED_ULE caused resulted in the nfsd trying to get to a higher peak number of threads and hit the limit. SCHED_4BSD happened to result in timing such that it stayed just below the limit and worked. I can think of a couple of things that might affect this: 1 - If SCHED_ULE doesn't do the termination of kernel threads as quickly, then they wouldn't terminate and release their resources before more new ones are spawned. 2 - If SCHED_ULE handles the nfsd threads in a more "bursty" way, then the burst could try and spawn more mirror DS worker threads at about the same time. Anyhow, thanks for the help, rick ___ 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"
Failed buildworld buildkernel: /usr/obj/. . ./arm.armv7/tmp/usr/bin/ld: cannot find -lgcc_s for all_subdir_lib/libdl (a build race?)
I tried to amd64 -> armv7 cross build head -r332861 and got an error about -lgcc_s not being found. I backed off to -r332858 for other reasons (powerpc* related). Retrying the armv7 build then worked. I had first upgraded the amd64 context the first time and had backed off amd64 first the second time. (The builds are explicit about -mcpu=cortext-a7 .) (When I think about it, I tend to check https://ci.freebsd.org to pick a version likely to build for the variations that I play with. But armv7 is not covered by https://ci.freebsd.org . armv7 variations are missing from the report for -r332796's snapshots. But I'm not aware of anything around that indicates why variations ended up missing for snapshots.) Below is the error report that shows the message and the _ERROR_CMD that was involved. I have no direct clue if it is because of a race relative to gcc_s availability or not. The context involved WITH_META_MODE=yes and -j28 . I do not see anything in -r332859 to -r332861 that would suggest anything but a race as a relevant difference, where a re-try found gcc_s already available. --- all_subdir_lib/libdl --- /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin/ld: cannot find -lgcc_s --- all_subdir_lib/libbsm --- Building /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/lib/libbsm/bsm_notify.o --- sbin/ipf/libipf__L --- Building /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sbin/ipf/libipf/printiphdr.o --- lib__L --- --- all_subdir_lib/libdl --- cc: error: linker command failed with exit code 1 (use -v to see invocation) --- all_subdir_lib/libdevinfo --- --- libdevinfo.a --- building static devinfo library --- kerberos5/lib__L --- Building /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/kerberos5/lib/libkadm5srv/set_keys.o --- lib__L --- --- all_subdir_lib/libdl --- *** [libdl.so.1.full] Error code 1 make[5]: stopped in /usr/src/lib/libdl .ERROR_TARGET='libdl.so.1.full' .ERROR_META_FILE='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/lib/libdl/libdl.so.1.full.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='@echo building shared library libdl.so.1; @rm -f libdl.so.1 libdl.so; cc -mcpu=cortex-a7 -target armv7-gnueabihf-freebsd12.0 --sysroot=/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp -B/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin -Wl,-F,libc.so.7 -Wl,--version-script=Version.map -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libdl.so.1.full -Wl,-soname,libdl.so.1 `NM='nm' NMFLAGS='' lorder dlfcn.pico | tsort -q` ;' .CURDIR='/usr/src/lib/libdl' .MAKE='make' .OBJDIR='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/lib/libdl' .TARGETS='all' DESTDIR='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp' LD_LIBRARY_PATH='' MACHINE='arm' MACHINE_ARCH='armv7' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20180222' PATH='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/bin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/sbin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.armv7-clang-bootstrap.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/libdl/Makefile /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/lib/libdl/../Makefile.inc /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.confs.mk /usr/src/shar e/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/lib/libdl /usr/src/lib/libc/gen' 1 error === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE makes 256Mbyte i386 unusable
> On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote: > > I decided to start a new thread on current related to SCHED_ULE, since I see > > more than just performance degradation and on a recent current kernel. > > (I cc'd a couple of the people discussing performance problems in > > freebsd-stable > > recently under a subject line of "Re: kern.sched.quantum: Creepy, sadistic > > scheduler". > > > > When testing a pNFS server on a single core i386 with 256Mbytes using a > > Dec. 2017 > > current/head kernel, I would see about a 30% performance degradation > > (elapsed > > run time for a kernel build over NFSv4.1) when the server kernel was built > > with > > options SCHED_ULE > > instead of > > options SCHED_4BSD > > > > Now, with a kernel from a couple of days ago, the > > options SCHED_ULE > > kernel becomes unusable shortly after starting testing. > > I have seen two variants of this: > > - Became essentially hung. All I could do was ping the machine from the > > network. > > - Reported "vm_thread_new: kstack allocation failed > > and then any attempt to do anything gets "No more processes". > This is strange. It usually means that you get KVA either exhausted or > severly fragmented. > > Enter ddb, it should be operational since pings are replied. Try to see > where the threads are stuck. > > > with the only difference being a kernel built with > > options SCHED_4BSD > > everything works and performs the same as the Dec 2017 kernel. > > > > I can try rolling back through the revisions, but it would be nice if > > someone > > could suggest where to start, because it takes a couple of hours to build a > > kernel on this system. > > > > So, something has made things worse for a head/current kernel this winter, > > rick > > There are at least two potentially relevant changes. > > First is r326758 Dec 11 which bumped KSTACK_PAGES on i386 to 4. My experience with this bump and trying to run a GENERIC -current (meaning it has INVARIANTS and WITNESS) is that you have a very unstable situation until you get above 1G of memory. And NFS is a major kstack consumer. > Second is r332489 Apr 13, which introduced 4/4G KVA/UVA split. > > Consequences of the first one are obvious, it is much harder to find > the place to map the stack. Second change, on the other hand, provides > almost full 4G for KVA and should have mostly compensate for the negative > effects of the first. > > And, I cannot see how changing the scheduler would fix or even affect that > behaviour. > ___ > 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" > -- Rod Grimes rgri...@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: i386 hangs during halt "vnodes remaining... 0 time out"
Cy Schubert wrote: >In message <201804212227.w3lmrp5w002...@slippy.cwsent.com>, Cy Schubert writes: >> In message <20180421234934.10d7d...@kalimero.tijl.coosemans.org>, Tijl >> Cooseman >> s writes: >> > --MP_/TDsO+CDIra7UXGs=vVO3NTB >> > Content-Type: text/plain; charset=US-ASCII >> > Content-Transfer-Encoding: 7bit >> > Content-Disposition: inline >> > >> > On Sat, 21 Apr 2018 21:09:09 + Rick Macklem wrot >> e: >> > > With a recent head/current kernel (doesn't happen when running a Dec. >> > > 2017 one), when I do a halt, it gets as far as: >> > > >> > > vnodes remaining... 0 time out >> > > >> > > and that's it (the time out appears several seconds after the first "0"). >> > > With a Dec. 2017 kernel there would be several "0"s printed. >> > > It appears that it is stuck in the first iteration of the sched_sync() >> > > loop after it is no longer in SYNCER_RUNNING state. >> > > >> > > Any ideas? rick >> > >> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 >> > I have a patch (attached) but haven't been able to test it yet. >> >> I've noticed this as well on my old Penium-M laptop (updated about >> twice a year). I'll try your patch this weekend or early next week. > >Works perfectly. Patch seems to work for my i386 as well. Thanks, rick ___ 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: i386 hangs during halt "vnodes remaining... 0 time out"
In message , Rick Macklem writes: > Cy Schubert wrote: > >In message <201804212227.w3lmrp5w002...@slippy.cwsent.com>, Cy Schubert > writes: > >> In message <20180421234934.10d7d...@kalimero.tijl.coosemans.org>, Tijl > >> Cooseman > >> s writes: > >> > --MP_/TDsO+CDIra7UXGs=vVO3NTB > >> > Content-Type: text/plain; charset=US-ASCII > >> > Content-Transfer-Encoding: 7bit > >> > Content-Disposition: inline > >> > > >> > On Sat, 21 Apr 2018 21:09:09 + Rick Macklem w > rot > >> e: > >> > > With a recent head/current kernel (doesn't happen when running a Dec. > >> > > 2017 one), when I do a halt, it gets as far as: > >> > > > >> > > vnodes remaining... 0 time out > >> > > > >> > > and that's it (the time out appears several seconds after the first "0 > "). > >> > > With a Dec. 2017 kernel there would be several "0"s printed. > >> > > It appears that it is stuck in the first iteration of the sched_sync() > >> > > loop after it is no longer in SYNCER_RUNNING state. > >> > > > >> > > Any ideas? rick > >> > > >> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 > >> > I have a patch (attached) but haven't been able to test it yet. > >> > >> I've noticed this as well on my old Penium-M laptop (updated about > >> twice a year). I'll try your patch this weekend or early next week. > > > >Works perfectly. > Patch seems to work for my i386 as well. > > Thanks, rick Yes, thank you. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: i386 hangs during halt "vnodes remaining... 0 time out"
In message <201804212227.w3lmrp5w002...@slippy.cwsent.com>, Cy Schubert writes: > In message <20180421234934.10d7d...@kalimero.tijl.coosemans.org>, Tijl > Cooseman > s writes: > > --MP_/TDsO+CDIra7UXGs=vVO3NTB > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > On Sat, 21 Apr 2018 21:09:09 + Rick Macklem wrot > e: > > > With a recent head/current kernel (doesn't happen when running a Dec. > > > 2017 one), when I do a halt, it gets as far as: > > > > > > vnodes remaining... 0 time out > > > > > > and that's it (the time out appears several seconds after the first "0"). > > > With a Dec. 2017 kernel there would be several "0"s printed. > > > It appears that it is stuck in the first iteration of the sched_sync() > > > loop after it is no longer in SYNCER_RUNNING state. > > > > > > Any ideas? rick > > > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 > > I have a patch (attached) but haven't been able to test it yet. > > I've noticed this as well on my old Penium-M laptop (updated about > twice a year). I'll try your patch this weekend or early next week. Works perfectly. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
