Re: Leaving the Desktop Market
throttling is disabled now. -a On 4 May 2014 21:27, Kevin Oberman wrote: > On Sun, May 4, 2014 at 10:07 AM, Nathan Whitehorn > wrote: > >> On 05/04/14 10:05, Allan Jude wrote: >> >>> On 2014-05-04 11:47, Allan Jude wrote: >>> On 2014-05-04 10:28, Matthias Apitz wrote: > El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman > escribió: > > On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd >> wrote: >> >> Set it to the lowest available Cx state that you see in dev.cpu.0 . >>> >>> >>> Available is not required. Set it to C8. That guarantees that you >> will use >> the lowest available. The correct incantation in rc.conf is "Cmax". >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> But, unless you want laggy performance, you will probably also want: >> hint.p4tcc.0.disabled=1 >> hint.acpi_throttle.0.disabled=1 >> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >> well and TCC is not effective, as mentioned earlier in this thread. >> > Re/ powerd I have in /etc/rc.conf: > > # powerd > powerd_enable="YES" > powerd_flags="-a max -b adp" > # > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > (and the additional hint.* in /boot/loader.conf as well). Which process > 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config > values? > > Thx > > matthias > > In a pretty unscientific test on my laptop (Lenovo T530 with Intel i5 3320M), setting hw.acpi.cpu.cx_lowest=C8 lowered power consumption at idle by about 3 watts, which adds about 30-45 minutes to my battery life during conservative usage. Using PCBSD 10, so hint.acpi_throttle.0.disabled=1 was already set (apparently solves some issue with powerd on some AMD systems) I have added hint.p4tcc.0.disabled=1 but not sure where to expect to see a difference. I see the difference now, with the p4tcc stuff disabled, the lowest >>> cpufreq is now 1200mhz instead of 150mhz >>> >>> >>> >> I just set the default for acpi_throttle and p4tcc in HEAD to disabled by >> adding these line to the default /boot/device.hints. If you want them back, >> editing your device.hints will restore them. This can be reverted if many >> people want throttling enabled by default, but all I have heard so far -- >> and for the past many years -- is a unanimous chorus to turn it off. >> -Nathan >> > > Anyone playing around with Thermal Management should read the article on > Tom's Hardware on the subject. It explains things quite nicely. Even I > could understand it. :-) > http://www.tomshardware.com/reviews/cpu-cooler-fails,1695-3.html > The section on Thermal Monitor 2 was new to me as it has been added since I > last researched this several years ago. Note the tie-in between TM2 and > EST rather than simple throttling (skipping N of every 8 clock cycles). > Section 2 of the article has thermal specs on a lot of processors, too.. > > Bottom line of the article is to make sure TM2 is enabled and just leave it > alone to do its thing. No throttling of any sort for power mis-management. > > The one area that can stand a close look is the algorithm for adjusting > EST. It probably will make far less difference than C-states, but it is a > legitimate power management technique and it is under the control of > powerd. Several people have suggested modification for this and I think > it's at least worth a look. > > Finally, if we don't default p4tcc and throttling to off and change the > default for C-states to Cmax, a lot of people will be very unhappy. > Disabling throttling really must come first. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.co > ___ > 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" ___ 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"
Re: Leaving the Desktop Market
On Sun, May 4, 2014 at 10:07 AM, Nathan Whitehorn wrote: > On 05/04/14 10:05, Allan Jude wrote: > >> On 2014-05-04 11:47, Allan Jude wrote: >> >>> On 2014-05-04 10:28, Matthias Apitz wrote: >>> El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd > wrote: > > Set it to the lowest available Cx state that you see in dev.cpu.0 . >> >> >> Available is not required. Set it to C8. That guarantees that you > will use > the lowest available. The correct incantation in rc.conf is "Cmax". > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But, unless you want laggy performance, you will probably also want: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > well and TCC is not effective, as mentioned earlier in this thread. > Re/ powerd I have in /etc/rc.conf: # powerd powerd_enable="YES" powerd_flags="-a max -b adp" # performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" (and the additional hint.* in /boot/loader.conf as well). Which process 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config values? Thx matthias In a pretty unscientific test on my laptop (Lenovo T530 with Intel i5 >>> 3320M), setting hw.acpi.cpu.cx_lowest=C8 lowered power consumption at >>> idle by about 3 watts, which adds about 30-45 minutes to my battery life >>> during conservative usage. >>> >>> Using PCBSD 10, so hint.acpi_throttle.0.disabled=1 was already set >>> (apparently solves some issue with powerd on some AMD systems) >>> >>> I have added hint.p4tcc.0.disabled=1 but not sure where to expect to see >>> a difference. >>> >>> I see the difference now, with the p4tcc stuff disabled, the lowest >> cpufreq is now 1200mhz instead of 150mhz >> >> >> > I just set the default for acpi_throttle and p4tcc in HEAD to disabled by > adding these line to the default /boot/device.hints. If you want them back, > editing your device.hints will restore them. This can be reverted if many > people want throttling enabled by default, but all I have heard so far -- > and for the past many years -- is a unanimous chorus to turn it off. > -Nathan > Anyone playing around with Thermal Management should read the article on Tom's Hardware on the subject. It explains things quite nicely. Even I could understand it. :-) http://www.tomshardware.com/reviews/cpu-cooler-fails,1695-3.html The section on Thermal Monitor 2 was new to me as it has been added since I last researched this several years ago. Note the tie-in between TM2 and EST rather than simple throttling (skipping N of every 8 clock cycles). Section 2 of the article has thermal specs on a lot of processors, too.. Bottom line of the article is to make sure TM2 is enabled and just leave it alone to do its thing. No throttling of any sort for power mis-management. The one area that can stand a close look is the algorithm for adjusting EST. It probably will make far less difference than C-states, but it is a legitimate power management technique and it is under the control of powerd. Several people have suggested modification for this and I think it's at least worth a look. Finally, if we don't default p4tcc and throttling to off and change the default for C-states to Cmax, a lot of people will be very unhappy. Disabling throttling really must come first. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.co ___ 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"
Re: Leaving the Desktop Market
Hm, I was hoping for a little more discussion. Mostly around the "which older CPUs do we leave this on for?" crowd. I have Pentium-M class hardware that I was going to spin up -HEAD on. So I'll go install -HEAD on said older hardware and get a list of what does and doesn't work. I'm totally fine with disabling p4tcc and acpi_throttle if P states for cpu frequency adjustment are available. I just want to ensure that the temperature throttling stuff is going to get automatically engaged (by whichever magical BIOS/ACPI/SMI thing does it) and clock things down if the CPU gets way too hot. -a On 4 May 2014 10:07, Nathan Whitehorn wrote: > On 05/04/14 10:05, Allan Jude wrote: >> >> On 2014-05-04 11:47, Allan Jude wrote: >>> >>> On 2014-05-04 10:28, Matthias Apitz wrote: El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: > On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd > wrote: > >> Set it to the lowest available Cx state that you see in dev.cpu.0 . >> >> > Available is not required. Set it to C8. That guarantees that you will > use > the lowest available. The correct incantation in rc.conf is "Cmax". > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But, unless you want laggy performance, you will probably also want: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > well and TCC is not effective, as mentioned earlier in this thread. Re/ powerd I have in /etc/rc.conf: # powerd powerd_enable="YES" powerd_flags="-a max -b adp" # performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" (and the additional hint.* in /boot/loader.conf as well). Which process 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config values? Thx matthias >>> In a pretty unscientific test on my laptop (Lenovo T530 with Intel i5 >>> 3320M), setting hw.acpi.cpu.cx_lowest=C8 lowered power consumption at >>> idle by about 3 watts, which adds about 30-45 minutes to my battery life >>> during conservative usage. >>> >>> Using PCBSD 10, so hint.acpi_throttle.0.disabled=1 was already set >>> (apparently solves some issue with powerd on some AMD systems) >>> >>> I have added hint.p4tcc.0.disabled=1 but not sure where to expect to see >>> a difference. >>> >> I see the difference now, with the p4tcc stuff disabled, the lowest >> cpufreq is now 1200mhz instead of 150mhz >> >> > > I just set the default for acpi_throttle and p4tcc in HEAD to disabled by > adding these line to the default /boot/device.hints. If you want them back, > editing your device.hints will restore them. This can be reverted if many > people want throttling enabled by default, but all I have heard so far -- > and for the past many years -- is a unanimous chorus to turn it off. > -Nathan > > ___ > 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" ___ 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"
Re: Leaving the Desktop Market
On 05/04/14 10:05, Allan Jude wrote: On 2014-05-04 11:47, Allan Jude wrote: On 2014-05-04 10:28, Matthias Apitz wrote: El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: Set it to the lowest available Cx state that you see in dev.cpu.0 . Available is not required. Set it to C8. That guarantees that you will use the lowest available. The correct incantation in rc.conf is "Cmax". performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" But, unless you want laggy performance, you will probably also want: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix well and TCC is not effective, as mentioned earlier in this thread. Re/ powerd I have in /etc/rc.conf: # powerd powerd_enable="YES" powerd_flags="-a max -b adp" # performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" (and the additional hint.* in /boot/loader.conf as well). Which process 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config values? Thx matthias In a pretty unscientific test on my laptop (Lenovo T530 with Intel i5 3320M), setting hw.acpi.cpu.cx_lowest=C8 lowered power consumption at idle by about 3 watts, which adds about 30-45 minutes to my battery life during conservative usage. Using PCBSD 10, so hint.acpi_throttle.0.disabled=1 was already set (apparently solves some issue with powerd on some AMD systems) I have added hint.p4tcc.0.disabled=1 but not sure where to expect to see a difference. I see the difference now, with the p4tcc stuff disabled, the lowest cpufreq is now 1200mhz instead of 150mhz I just set the default for acpi_throttle and p4tcc in HEAD to disabled by adding these line to the default /boot/device.hints. If you want them back, editing your device.hints will restore them. This can be reverted if many people want throttling enabled by default, but all I have heard so far -- and for the past many years -- is a unanimous chorus to turn it off. -Nathan ___ 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"
Re: Leaving the Desktop Market
On 2014-05-04 11:47, Allan Jude wrote: > On 2014-05-04 10:28, Matthias Apitz wrote: >> El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: >> >>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: >>> Set it to the lowest available Cx state that you see in dev.cpu.0 . >>> Available is not required. Set it to C8. That guarantees that you will use >>> the lowest available. The correct incantation in rc.conf is "Cmax". >>> performance_cx_lowest="Cmax" >>> economy_cx_lowest="Cmax" >>> >>> But, unless you want laggy performance, you will probably also want: >>> hint.p4tcc.0.disabled=1 >>> hint.acpi_throttle.0.disabled=1 >>> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >>> well and TCC is not effective, as mentioned earlier in this thread. >> >> Re/ powerd I have in /etc/rc.conf: >> >> # powerd >> powerd_enable="YES" >> powerd_flags="-a max -b adp" >> # >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> (and the additional hint.* in /boot/loader.conf as well). Which process >> 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config >> values? >> >> Thx >> >> matthias >> > > In a pretty unscientific test on my laptop (Lenovo T530 with Intel i5 > 3320M), setting hw.acpi.cpu.cx_lowest=C8 lowered power consumption at > idle by about 3 watts, which adds about 30-45 minutes to my battery life > during conservative usage. > > Using PCBSD 10, so hint.acpi_throttle.0.disabled=1 was already set > (apparently solves some issue with powerd on some AMD systems) > > I have added hint.p4tcc.0.disabled=1 but not sure where to expect to see > a difference. > I see the difference now, with the p4tcc stuff disabled, the lowest cpufreq is now 1200mhz instead of 150mhz -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Fatal double fault in ZFS with yesterday's CURRENT [SOLVED]
"Steven Hartland" wrote: > Thanks for your help testing this Fabian, I've now committed the fix for > this for this: > http://svnweb.freebsd.org/changeset/base/265321 Thanks a lot, Steve. Fabian signature.asc Description: PGP signature
Re: Leaving the Desktop Market
On 2014-05-04 10:28, Matthias Apitz wrote: > El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: > >> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: >> >>> Set it to the lowest available Cx state that you see in dev.cpu.0 . >>> >>> >> Available is not required. Set it to C8. That guarantees that you will use >> the lowest available. The correct incantation in rc.conf is "Cmax". >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> But, unless you want laggy performance, you will probably also want: >> hint.p4tcc.0.disabled=1 >> hint.acpi_throttle.0.disabled=1 >> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >> well and TCC is not effective, as mentioned earlier in this thread. > > Re/ powerd I have in /etc/rc.conf: > > # powerd > powerd_enable="YES" > powerd_flags="-a max -b adp" > # > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > (and the additional hint.* in /boot/loader.conf as well). Which process > 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config > values? > > Thx > > matthias > In a pretty unscientific test on my laptop (Lenovo T530 with Intel i5 3320M), setting hw.acpi.cpu.cx_lowest=C8 lowered power consumption at idle by about 3 watts, which adds about 30-45 minutes to my battery life during conservative usage. Using PCBSD 10, so hint.acpi_throttle.0.disabled=1 was already set (apparently solves some issue with powerd on some AMD systems) I have added hint.p4tcc.0.disabled=1 but not sure where to expect to see a difference. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Leaving the Desktop Market
On 05/03/14 22:29, Adrian Chadd wrote: On 3 May 2014 21:52, Allan Jude wrote: * use cpufreq with some heuristics (like say, only step down to 2/3rd the frequency if idle) - and document why that decision is made (eg on CPU X, measuring Y at idle, power consumption was minimal at frequency=Z.); * make sure the lower frequencies and tcc kick in if a thermal cutoff is reached; * default to using lower Cx states out of the box if they're decided to not be buggy. There are a few CPUs for which lower C states cause problems but modernish hardware (say, nehalem and later) should be fine. According to the wiki, in 9.x and onward there is code that is supposed to detect if the higher Cx states are usable, and not use them if they are not, but I do not know how well this works. I'm not sure. I think those who care / know enough just put relevant bits into /etc/rc.conf and /boot/loader.conf rather than flipping it on by default. I'm kind of tempted to just flip on Cmax by default and teach powerd to not do cpufreq unless there's a thermal issue. Then take a step back and see what happens. Please remember that powerd is not x86-only. Other systems (e.g. PowerPC) use it in conjunction with cpufreq. But seriously, let's just pull tcc from GENERIC. I'll do it next week unless I hear any objections. -Nathan ___ 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"
Re: Leaving the Desktop Market
El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: > On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: > > > Set it to the lowest available Cx state that you see in dev.cpu.0 . > > > > > Available is not required. Set it to C8. That guarantees that you will use > the lowest available. The correct incantation in rc.conf is "Cmax". > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But, unless you want laggy performance, you will probably also want: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > well and TCC is not effective, as mentioned earlier in this thread. Re/ powerd I have in /etc/rc.conf: # powerd powerd_enable="YES" powerd_flags="-a max -b adp" # performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" (and the additional hint.* in /boot/loader.conf as well). Which process 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config values? Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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"
Re: Fatal double fault in ZFS with yesterday's CURRENT
- Original Message - From: "Fabian Keil" Thanks for your help testing this Fabian, I've now committed the fix for this for this: http://svnweb.freebsd.org/changeset/base/265321 Regards Steve ___ 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"
Re: portmaster/pkg still populating /var/db/pkg/
On 04/05/2014 09:46, Marc UBM wrote: > After my last port rebuild (libxml, libxcb, etc.) I realized that > portmaster is still populating /var/db/pkg with the old db scheme (i.e. > one directory for each port). At the same time, local.sqlite exists and > is up to date (I can query the db via pkg just fine). > > I switched to pkgng ages ago (sometime during the winter of 2011, I > believe) - have I missed any necessary steps or is this a known quirk? > > I'm using pkg-1.3.0.a10 and pkgconf-0.9.5, uname: > > FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #19 > r258254:264321M: Fri Apr 11 06:31:35 CEST 2014 > xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 It's a known thing. portmaster uses a per-package subdir under /var/db/pkg to stash some data about distfiles. It just looks superficially like the old-style pkg DB -- but rest assured, all the data describing your installed packages is stored in local.sqlite Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
[SOLVED] libllvmmc build is broken on i386
Dimitry Andric wrote on 25.04.2014 01:58: On 24 Apr 2014, at 19:05, Ruslan Makhmatkhanov wrote: I can't build current on i386 (last tried revision is 264886) for couple of days. Every time trying to build with making `make clean` and rm'ing /usr/obj first. The first error is appearing when building MCAsmBackend.cpp: """ /../contrib/llvm/lib/MC/MCAsmBackend.cpp -o MCAsmBackend.o In file included from /usr/src/lib/clang/libllvmmc/../../../contrib/llvm/lib/MC/MCAsmBackend.cpp:10: In file included from /usr/src/lib/clang/libllvmmc/../../../contrib/llvm/include/llvm/MC/MCAsmBackend.h:13: In file included from /usr/src/lib/clang/libllvmmc/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:14: In file included from /usr/src/lib/clang/libllvmmc/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:17: In file included from /usr/src/lib/clang/libllvmmc/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19: In file included from /usr/include/c++/v1/cstddef:36: /usr/include/c++/v1/__config:314:2: error: invalid preprocessing directive """ Here is the full buildlog: http://pastebin.com/mp4mrUTb Looks like your /usr/include/c++/v1/__config file is corrupt. Try reinstalling the file, e.g.: sudo install -o root -g wheel -m 444 /usr/src/contrib/libc++/include/__config /usr/include/c++/v1 Or alternatively, running: sudo make -C /usr/src/lib/libc++ install -Dimitry It actually bombed in different places across the toolchain. I replaced the clang/llvm bits from fresh -current ISO and everything builds fine now. Thank you! -- Regards, Ruslan T.O.S. Of Reality ___ 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"
Re: Fatal double fault in ZFS with yesterday's CURRENT
"Steven Hartland" wrote: > > "Steven Hartland" wrote: > > > > > From: "Fabian Keil" > > > > > > > After updating my laptop to yesterday's CURRENT (r265216), > > > > I got the following fatal double fault on boot: > > > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r265216/ > > > > > > > > My previous kernel was based on r264721. > > > > > > > > I'm using a couple of custom patches, some of them are ZFS-related > > > > and thus may be part of the problem (but worked fine for months). > > > > I'll try to reproduce the panic without the patches tomorrow. > > > > > > > > > > Your seeing a stack overflow in the new ZFS queuing code, which I > > > believe is being triggered by lack of support for TRIM in one of > > > your devices, something Xin reported to me yesterday. > > > > > > I commited a fix for failing TRIM requests processing slowly last > > > night so you could try updating to after r265253 and see if that > > > helps. > > > > Thanks. The hard disk is indeed unlikely to support TRIM requests, > > but I can still reproduce the problem with a kernel based on r265255. > > Thanks for testing, I suspect its still a numbers game with how many items > are outstanding in the queue and now that free / TRIM requests are also > now queued its triggering the failure. > > If your just on a HDD try setting the following in /boot/loader.conf as > a temporary workaround: > vfs.zfs.trim.enabled=0 That worked, thanks. > > > I still need to investigate the stack overflow more directly which > > > appears to be caused by the new zfs queuing code when things are > > > running slowly and there's a large backlog of IO's. > > > > > > I would be interested to know you config there so zpool layout and > > > hardware in the mean time. > > > > The system is a Lenovo ThinkPad R500: > > http://www.nycbug.org/index.cgi?action=dmesgd&do=view&dmesgid=2449 > > > > I'm booting from UFS, the panic occurs while the pool is being imported. > > > > The pool is located on a single geli-encrypted slice: > > > > fk@r500 ~ $zpool status tank > > pool: tank > > state: ONLINE > > scan: scrub repaired 0 in 4h11m with 0 errors on Sat Mar 22 18:25:01 2014 > > config: > > > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > >ada0s1d.eli ONLINE 0 0 0 > > > > errors: No known data errors > > > > Maybe geli fails TRIM requests differently. > > That helps, Xin also reported the issue with geli and thats what I'm testing > with, I believe this is a factor because is significantly slows things down > again meaning more items in the queues, but I've only managed to trigger it > once here as the machine I'm using is pretty quick. It probably doesn't make a difference, but my system is rather old and thus I'm still using geli version 3 for ada0s1d.eli while geli init nowadays defaults to geli version 7. The system certainly is also slow, though. Fabian signature.asc Description: PGP signature
