Re: dmesg submission service -- please submit today
On 9/10/18 3:15 am, Matt S wrote: > It really seems like the project would benefit from having better hardware > stats. If you make it a package, people have to be educated to get it and > use it--not that it doesn't have value, it just isn't well exposed and you > will only get stats from the most clueful users. > > I would suggest making anonymized stat upload part of the install and > upgrade process, to get wider coverage. > > - When installing, there's a new step or checkbox with an opt-in for > hardware data sharing, defaulting to off > - If you opt in, your info is uploaded as part of the install process > - Expose the same functionality in a new system-level command like > 'freebsd-uploadstats' and make it an optional but suggested part of the > upgrade process, which is something most users will see repeatedly if they > continue to be users. > > Perhaps the local machine can generate a hash of the report, check that > with the server before the upload goes through. Hardware doesn't change > that often. There is the bsdstats port for system version and hardware details, as the site has had errors listing hardware details for some time it may not last much longer. With the amount of TrueOS entries, it would indicate that they probably have (had?) it as a default install. If the FreeBSD project or foundation doesn't want to collect this data then a company that relies on *BSD, like iX Systems, may want to step up and provide servers to collect this data. I do think it would be better as an official project data collection rather than a third party service. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How do I stop using local_unbound ?
On 07/08/2018 05:01, Kevin Oberman wrote: > On Mon, Aug 6, 2018 at 7:57 AM, John Kennedy wrote: > >> On Mon, Aug 06, 2018 at 03:06:00PM +0100, Pete French wrote: >>> having enabled local_unbound in /etc/rc.d how do I remove that >>> and go back to using just DHCP delivered nameservers ? I >>> set it to 'NO' but yet the machine still seems to have traces of >>> the config in other places and keeps trying to use them, for reasons I >>> dont understand. >>> >>> Is there a quyick guide to clearing this off a system when you dont want >> to use >>> it anymore ? I get that it needs to be slightly complex to do what it >> does, >>> but its proving very hard to fix the broken DNS looksup! >> >> Hmm. First, make sure that it isn't running (service local_unbound stop, >> etc). >> Then look at your /etc/resolv.conf -- unbound tends to rewrite that on >> initial >> startup, taking some of it's settings and inserting itself into the middle >> as a >> caching DNS server. At the very least, you want something like this: >> >> nameserver 8.8.8.8 >> >> I think the default DHCP client stomps all over /etc/resolv.conf fairly >> well, >> but see what options are in there (for example, options for >> domain-name-servers >> and domain-name). The stock /etc/dhclient.conf is all comments. >> >> I have issues with the DNS results my ISP returns to me, but setting up a >> cache >> or using sites like 8.8.8.8 (google public DNS, if you don't mind feeding >> the >> beast) fixes that. >> > > If you don't want to feed the beast, maybe 9.9.9.9 (Quad9). You can read > about it at: > https://arstechnica.com/information-technology/2017/11/new-quad9-dns-service-blocks-malicious-domains-for-everyone/ There is also 1.1.1.1 and 1.0.0.1 from cloudflare - claims to be fastest https://1.1.1.1 -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64
On 01/08/2018 07:24, Mark Martinec wrote: > I have now upgraded this host from 11.1-RELEASE-p11 to 11.2-RELEASE > and the situation has not improved. Also turned off all services. > ZFS is still leaking memory about 30 MB per hour, until the host > runs out of memory and swap space and crashes, unless I reboot it > first every four days. > > Any advise before I try to get rid of that faulted disk with a pool > (or downgrade to 10.3, which was stable) ? > > Mark > > > 2018-07-23 17:12, myself wrote: >> After upgrading an older AMD host from FreeBSD 10.3 to 11.1-RELEASE-p11 >> (amd64), ZFS is gradually eating up all memory, so that it crashes every >> few days when the memory is completely exhausted (after swapping heavily >> for a couple of hours). >> >> This machine has only 4 GB of memory. After capping up the ZFS ARC >> to 1.8 GB the machine can now stay up a bit longer, but in four days >> all the memory is used up. The machine is lightly loaded, it runs >> a bind resolver and a lightly used web server, the ps output >> does not show any excessive memory use by any process. When you say all used up - you mean the amount of wired ram goes higher than about 90% physical ram? You can watch the wired amount in top, or calculate it as vm.stats.vm.v_wire_count * hw.pagesize ZFS ARC is marked as wired, there is also vm.max_wired which limits how much the kernel can wire, this defaults to 30% ram, so about 1.2G for you. It seems these two wired values don't interact and can add up to more than physical ram. I have reported this in bug 229764 Try the patch at https://reviews.freebsd.org/D7538 it has given me the best arc related memory improvements I have seen since 10.1, I now see arc being released instead of swap being used. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lightly loaded system eats swap space
On 20/06/2018 02:59, Jeremy Chadwick wrote: > In short (and nebulous as hell; sorry, I cannot be more specific given > the nature of the problem): there have been changes about ZFS's memory > allocation/releasing decision-making scheme compared to ZFS on "older" > FreeBSD (i.e. earlier 11.x, and definitely 10.x and 9.x). I would say the issues started with 10.x, I never had memory issues using 9.x with ZFS. I first had all ram marked wired when testing 10.1. > Recommendations like "limit your ARC" are nothing new in FreeBSD, but > are still ridiculous kludges: tech-lists' system clearly has 105GB MRU > (MRU = most recently used) in ARC, meaning there is memory that can be > released back to the rest of the OS for general use (re: memory > contention/pressure situation), but the OS is choosing to use swap > instead, eventually exhausting it. That logic sounds broken, IMO. (And > yes I did notice the size of bhyve process) This review is aiming to fix this - https://reviews.freebsd.org/D7538 I have been running the patch on stable/11 and after eight days uptime I still have zero swap in use, I can't recall a time in the last few years that I have had no swap usage past the first hour or two uptime. As I have commented in that review, the issue I am seeing is that arc_max is not counted when testing max_wired, the two together can add up to more than the physical ram and wiring all physical ram can push ram used by processes out to swap. I know with 8G physical ram having over 7G wired is not recoverable. max_wired seems to default to 30% ram (5G with 16G ram) I have never seen this mentioned in any zfs tuning, it should be subtracted from physical ram when calculating arc_max. arc_max should never be greater than (kmem_size - max_wired - padding) -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS+find(1) wiring all RAM
On 07/06/2018 16:09, Peter Jeremy wrote: > I've noticed that 11-stable/amd64 has been wiring seemingly excessive > amounts of RAM for some time (the problem goes back at least 6 months). > This extends to getting ENOMEM errors from g_io_deliver() and out-of-swap > errors killing processes on a low-memory system. I'm not sure when it > started by it seems to hawe gotten worse between r331535 and r334494. Don't know if this will help you at all -- I have seen excess wired for a few years, since 10.1, I now run 11-stable, my experience has seen the severity varying over time. I first reported this 28/10/2014 related to heavy disk use on a zpool. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654 The inability to get solid repeatable steps to reproduce have prevented me from chasing this more. My desktop machine originally had 8G and when wired went over 7G there was no choice but to reset. I now have 16G and have a script running constantly to monitor the wired and react when needed, allocating a big chunk of ram normally causes wired to be released, this has kept wired under 10G for several months. I see arc usage sitting at the arc_max setting with wired going more than two times that. My vm.max_wired is at 5G (default) and I think this is a limit that is somehow bypassed, if it could be enforced we might be good. This could be the point to chase in a bug report. > 1) Significant amounts of wired memory are in use but I can't find anything > in "vmstat -mz" that would explain where it's going. I started logging my wired usage and have about 6 months of data, in the following sample, allocating 2G more than free caused wired to drop 4G in about 2 secs, you can also see that arc usage did not change in this time. This leads me to think it may be related to changes made to add support for zfs but I don't think zfs is the one allocating this wired amount. The values I am logging are from - vm.max_wired vm.stats.vm.v_wire_count kstat.zfs.misc.arcstats.size vm.stats.vm.v_free_count 2018/06/06_13:22:53 wired: 9779M max_wired: 5210M ARC: 4.1G Free:3.1G 2018/06/06_13:22:53 wired: 9781M max_wired: 5210M ARC: 4.1G Free:3.0G 2018/06/06_13:22:54 Excess wired detected. Allocating 4.9G to reduce wired. 2018/06/06_13:22:54 wired: 9787M max_wired: 5210M ARC: 4.1G Free:3.0G 2018/06/06_13:22:54 wired: 9796M max_wired: 5210M ARC: 4.1G Free:1.9G 2018/06/06_13:22:55 wired: 9809M max_wired: 5210M ARC: 4.1G Free:389.6M 2018/06/06_13:22:55 wired: 8169M max_wired: 5210M ARC: 4.1G Free:1.2G 2018/06/06_13:22:55 wired: 5917M max_wired: 5210M ARC: 4.1G Free:2.6G 2018/06/06_13:22:55 wired: 5566M max_wired: 5210M ARC: 4.1G Free:2.2G -- Shane Ambler Shane (at) ShaneWare (dot) Biz http://ShaneWare.Biz ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
backtrace from lock violation - 11-STABLE
# uname -a FreeBSD leader.local 11.1-STABLE FreeBSD 11.1-STABLE #0 r325311: Fri Nov 3 03:31:50 ACDT 2017 root@leader.local:/usr/obj/usr/src/sys/GENERIC amd64 mounting a nullfs mount point causes a lock violation when running a debug kernel (enabling witness, invariants etc) After starting the system with the debug kernel I logged in as root and ran `mount_nullfs /var/crash /home/shane/test/crash` to get the following - Full core.txt at http://shaneware.biz/freebsddebugdata/core.txt-2017-11-25-13-19 http://shaneware.biz/freebsddebugdata/dmesg.boot Unread portion of the kernel message buffer: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0468cf4560 assert_vop_locked() at assert_vop_locked+0x77/frame 0xfe0468cf4590 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0xad/frame 0xfe0468cf45c0 nullfs_mount() at nullfs_mount+0x25f/frame 0xfe0468cf4700 vfs_donmount() at vfs_donmount+0xf6d/frame 0xfe0468cf4940 sys_nmount() at sys_nmount+0x72/frame 0xfe0468cf4980 amd64_syscall() at amd64_syscall+0x7a8/frame 0xfe0468cf4ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0468cf4ab0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x80086de6a, rsp = 0x7fffe048, rbp = 0x7fffe990 --- vnode 0xf80209c0: tag nullfs, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) lock type nullfs: UNLOCKED vp=0xf80209c0, lowervp=0xf80059f81c30 VOP_UNLOCK: 0xf80209c0 is not locked but should be KDB: enter: lock violation panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/fs/nullfs/null_vnops.c:720 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0468cf4400 vpanic() at vpanic+0x186/frame 0xfe0468cf4480 kassert_panic() at kassert_panic+0x126/frame 0xfe0468cf44f0 __mtx_lock_flags() at __mtx_lock_flags+0x158/frame 0xfe0468cf4540 null_unlock() at null_unlock+0x5d/frame 0xfe0468cf4590 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0xe8/frame 0xfe0468cf45c0 nullfs_mount() at nullfs_mount+0x25f/frame 0xfe0468cf4700 vfs_donmount() at vfs_donmount+0xf6d/frame 0xfe0468cf4940 sys_nmount() at sys_nmount+0x72/frame 0xfe0468cf4980 amd64_syscall() at amd64_syscall+0x7a8/frame 0xfe0468cf4ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0468cf4ab0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x80086de6a, rsp = 0x7fffe048, rbp = 0x7fffe990 --- KDB: enter: panic Uptime: 9m25s Dumping 1053 out of 16295 MB:..2%..11%..22%..31%..41%..51%..61%..72%..81%..92% -- FreeBSD - the place to B...Spinning Destruction ;) Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: error instaling any ports
On 18/10/2017 05:41, Kurt Jaeger wrote: > Please note: Your binaries from 9.1-PRE will work on 9.3, and probably on > 10.x, so no need to worry about the packages installed for now. > > You can rebuild your ports when you're on 10.x. > If you have trouble running anything after the system upgrade, installing misc/compat9x should resolve the issues until you get your ports updated. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Realtek RTL8192EU on FreeBSD 11.1
On 06/10/2017 03:41, Peter Ankerstål wrote: > Hi! > > I recently bought a noname usb wifi card to use in my gateway but I fail to > get it to work. It seems to work out of the box on my NanoPI running CURRENT: > > root@nanopi:~ # uname -a > FreeBSD nanopi.pean.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320481: Sat Jul > 1 13:10:46 CEST 2017 > pe...@torus.pean.org:/usr/local/crochet/work/obj/arm.armv6/usr/src12/sys/GENERIC > arm > > root@nanopi:~ # > […] > ugen0.2: at usbus0 > rtwn0 on uhub0 > rtwn0: <802.11n NIC> on usbus0 > rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R > > My other machine: > root@gw:~ # uname -a > FreeBSD gw.pean.org 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321606: Thu Jul 27 > 10:27:02 CEST 2017 r...@gw.pean.org:/usr/obj/usr/src/sys/SOEKRIS i386 svn revision 312680 - Add support for the Realtek RTL8192EU chipset. https://svnweb.freebsd.org/base?view=revision=312680 At this stage the support is in current but doesn't appear to have been merged into any releases. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: file system deadlock in RELENG_11
On 25/08/2017 05:40, Mike Tancsa wrote: On 8/24/2017 4:01 PM, Mike Tancsa wrote: OK, this is fairly easy to repeat. If I start a sync of a snapshot via zrep, it hangs the box. CTRL+T shows DEBUG: overiding stale lock on zroot/chyves from pid 19378 sending zroot/chyves@zrep_10 to 10.151.9.2:zroot/chyves cannot receive new filesystem stream: destination 'zroot/chyves/guests/resi/disk1' exists must specify -F to overwrite it Are you sending a snapshot from the host to the guest? or is the guest sending to the host? load: 0.48 cmd: zfs 29690 [tx->tx_sync_done_cv] 358.94r 0.00u 0.00s 0% 3476k load: 0.48 cmd: zfs 29690 [tx->tx_sync_done_cv] 360.42r 0.00u 0.00s 0% I was able to get ps to run and not sure if its helpful or not, but these are the two unkillable zfs processes root 5 0.0 0.0 0128 - DL 10:09 0:05.58 [zfskern] root 29683 0.0 0.07752 3824 5 DE+ 15:53 0:00.32 zfs send -R -I zroot/chyves@zrep_0d zroot/chyves@zrep_10 root 29690 0.0 0.07752 3492 5 D+ 15:53 0:00.00 zfs rename zroot/chyves@zrep_10 zroot/chyves@zrep_10_unsent Should be unrelated but several years ago there was a deadlock issue when renaming a zvol, unless the fix got undone recently this may just be a distraction or a hint of a solution... https://svnweb.freebsd.org/base?view=revision=272474 -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: buildworld build times 10-stable vs. 11-stable
On 16/01/2017 03:43, Slawa Olhovchenkov wrote: On Sun, Jan 15, 2017 at 10:40:42AM -0600, Dan Mack wrote: I have a system which builds world, kernel, install, boot, installworld, reboot several times per week. I just noticed that my build times increased from about (just cherry picking a couple build logs): Starting build of FreeBSD SVN [309852] 10.3-STABLE Kernel will be GENERIC building world ... 90:35 0 Starting build of FreeBSD SVN [312099] 11.0-STABLE Kernel will be GENERIC building world ... 146:23 0 before I start bisecting the log files, is there something obvious introduced in 11 that I missed that would explain the roughly 50 minute difference in my build times? clang? additional subsystems? lldb/clang and related. +1 Try adding WITHOUT_CLANG_EXTRAS WITHOUT_CLANG_FULL WITHOUT_LLDB to src.conf and see what build times you get. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: help install new kernel on root-on-ZFS on 11-STABLE
On 17/10/2016 09:01, Ben Woods wrote: On Monday, 17 October 2016, Brandon J. Wandersee < brandon.wander...@gmail.com> wrote: Last I checked, the automated installer created a separate pool called "bootpool," with a symlink from /boot to /bootpool. I believe this is the case if the option for full disk encryption is selected in the installer. This is required until the boot loader is capable of recognising and accessing a geli encrypted disk. For a "plain" install, /boot is nothing more than a directory created in the root filesystem that will get created during installation. This is the same for UFS and ZFS. I haven't checked during a build but I don't think anything gets installed into /boot before installkernel so you shouldn't expect it to exist before installkernel. As mentioned you can create a separate pool for /boot so you can load the kernel from a non-encrypted filesystem that can then mount the remaining encrypted filesystems. Another alternative setup is using boot environments that would create filesystems as /sys/ROOT/ that are then mounted as the root filesystem. Like a plain system the /boot folder would still be created at the installkernel stage. -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Newer clang than comes with install?
On 05/03/2016 01:23, Kevin P. Neal wrote: On Fri, Mar 04, 2016 at 02:22:26PM +, Brooks Davis wrote: On Thu, Mar 03, 2016 at 08:45:05AM -0500, kpn...@pobox.com wrote: I notice on 10.2 we're using "FreeBSD clang version 3.4.1". But there are bugs in this version of clang that I'm having trouble with. Is compiling a newer (say, 3.7.1) version of clang to target FreeBSD supported? I have no desire to replace any of the libraries, just the compiler itself. Is that supposed to work _without_ going through the ports/pkgs system? IOW, can I just download from llvm.org the clang+llvm source, compile it on FreeBSD, and then use it safely? It should. The ports don't include many patches. Yeah, I was just looking at the patches we do include. One of them it looks like causes some of the llvm.org-provided includes to not be installed. I'm not sure I can, well, not install them because I also need to use the same install to do cross compiles. A quick check shows that those includes are used when targetting cross and native. Am I correct about the include files? And, if so, are there plans to upstream patches so the llvm.org includes will work out of the box for FreeBSD-hosted-and-targetted compiles? I am fairly sure the BSD developers share as much as they can upstream. You may want to look at current, it now has clang 3.7 and it appears 3.8 is being tested. https://svnweb.freebsd.org/base?view=revision=288943 https://svnweb.freebsd.org/base/projects/clang380-import/ -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10-STABLE hangups frequently
On 19/02/2016 15:36, Shane Ambler wrote: On 18/02/2016 10:54, Marius Strobl wrote: Could those of you experiencing these hangs with ZFS please test whether instead of reverting all of r292895, a kernel built with just the merge of r291244 undone via the following patch gets rid of that problem - especially on amd64 - and report back? https://people.freebsd.org/~marius/r291244_reversal_10.diff Marius I have built 10-STABLE - r295756 with the patch applied. corei7 - 8GB - 3 disks in raidz The first 11 hours look promising. Now been running for 36 hours. This is my desktop machine and after a full day on it I am confident that this fixes the issue I have had. -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10-STABLE hangups frequently
On 18/02/2016 10:54, Marius Strobl wrote: Could those of you experiencing these hangs with ZFS please test whether instead of reverting all of r292895, a kernel built with just the merge of r291244 undone via the following patch gets rid of that problem - especially on amd64 - and report back? https://people.freebsd.org/~marius/r291244_reversal_10.diff Marius I have built 10-STABLE - r295756 with the patch applied. corei7 - 8GB - 3 disks in raidz The first 11 hours look promising. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10-STABLE hangups frequently
On 04/02/2016 05:33, Peter Jeremy wrote: On 2016-Feb-03 18:23:13 +1030, Shane Ambler <free...@shaneware.biz> wrote: Any chance you get high wired allocations? A high wired allocation is normal for ZFS - ARC shows up as "wired" memory. Sometimes several times in a day I see the wired amount shown in top rise to over 6GB (of 8GB) bringing the system to a crawl. When wired gets over 7GB the system rarely recovers. The ARC limit defaults to 1GB less than physical RAM so 6GB wired on an 8GB system isn't unexpected (my home system currently has 30GB wired out of 32GB). If this is causing problems for your workload, it sounds like you may need to explicitly reduce vfs.zfs.arc_max (note that this is a soft limit). I have vfs.zfs.arc_max=2G - and now realise I also had set vfs.zfs.arc_min=500M some time ago. Don't recall where I got it but I also have vfs.zfs.dirty_data_max=200M Going by figures shown in top, ARC is usually in the 1500M to 2000M range but when wired gets over 6GB I often see ARC drop to 500MB which I now realise matches arc_min. When wired gets over 6GB apps start to stop responding, I then try to push out some wired by running a script that allocates 4G, 9 times out of 10 this drops wired to under 4GB and everything keeps working. If I notice wired over 7GB there's usually no recover. I don't always get to see the figures before it totally locks up. On desktop1 I leave a terminal running top and another ready to run my script to allocate some ram. When an app stops responding I go to desktop1 and depending on what I see I manually allocate some ram to flush things out. Currently I have an uptime of 9 days 9 hours - I have manually allocated 4GB 30 times in that time. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10-STABLE hangups frequently
On 03/02/2016 05:09, Thierry Thomas wrote: Le mar 2 fév 16 à 8:55:46 +0100, Hajimu UMEMOTO <u...@mahoroba.org> écrivait : Hi, Hello, I'm disturbed by a frequent hangup of my 10-STABLE boxes since this year. It seems occur during running the periodic daily scripts. I've narrowed which commit causes this problem. It seems r292895 causes it. I see many `Resource temporarily unavailable' message just before hangup occurs. Any idea? Not exactly the same problem, but it is also occuring during periodic daily: <https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083810.html> and also: <https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083807.html> I'm also experiencing problems during daily periodic on a -STABLE box, but no kernel panics: the machine is frozen, and no login is possible, I have to hard reboot it. For the time being, I have commented out almost every entry in periodic.conf, and I'm trying to find the culprit. Regards, Any chance you get high wired allocations? Sometimes several times in a day I see the wired amount shown in top rise to over 6GB (of 8GB) bringing the system to a crawl. When wired gets over 7GB the system rarely recovers. I am now running 10.2-STABLE r292646 on corei7 with 8GB and ZFS FS This is my everyday desktop running xfce and a variety of gui apps. I use a small script to allocate several GB of ram that gives the pressure needed to start releasing some wired, provided I can get in early enough. Not sure how to gather any helpful info for this. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 10.1 Memory Exhaustion
On 14/07/2015 03:18, Karl Denninger wrote: The ARC is supposed to auto-size and use all available free memory. The problem is that the VM system and ARC system both make assumptions that under certain load patterns fight with one another, and when this happens and ARC wins the system gets in trouble FAST. The pattern is that the system will start to page RSS out rather than evict ARC, ARC will fill the freed space, it pages more RSS out. you see where this winds up heading yes? Something I noticed was that vfs.zfs.arc_free_target is smaller than vm.v_free_target on my desktop with 8GB I get vfs.zfs.arc_free_target: 14091 vm.v_free_target: 43195 Doesn't that cause arc allocation to trigger swapping leaving space for arc allocation -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help debugging stable/10
On 17/06/2015 17:22, Hans Petter Selasky wrote: On 06/17/15 09:24, Shane Ambler wrote: On 24/03/2015 01:55, Shane Ambler wrote: On 25/12/2014 23:03, Andriy Gapon wrote: On 25/12/2014 11:29, Hans Petter Selasky wrote: The cam_sim_free() is stuck, blocking the rest of that controller from enumerating. It might look like a non-USB stack issue. MAV: Do you have some ideas where to start looking, now we have a dump? Any refcounts to check in particular? Apparently sim-refcount 0. Not sure how to check who has the reference(s). Can anyone think of something I can try? To recap to save you going back through history - After running 9.0 - 9.2 for 3 years I upgraded to 10.1RC3 and started getting a locking issue, most new processes fail to start, top and ps failing being indicators, the most info I have got is a back trace using kgdb, there are 4 instances I got output from procstat -kk -a On several occasions I have found that after inserting a usb memstick the device failed to be created, leaving me unable to mount the filesystem without a restart. I then switched to stable/10 in hopes of a fix finding it's way in. The back traces I have been able to collect (and a dmesg) are listed at http://shaneware.biz/freebsddebugdata/ This is my everyday desktop machine. I am now running FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #11 r283839: Thu Jun 4 17:41:28 ACST 2015 root@leader.local:/usr/obj/usr/src/sys /GENERIC amd64 I can only say it appears to be getting worse, though I may just be getting sick of having to restart nearly every day. Lately it seems that the less I do the quicker it locks up. I have restarted twice this week and then let it sit while I have gone out, after returning I get maybe 10-15 mins then have to restart, one of them was less than an hour uptime. While running poudriere I have got past 1 day uptime but it locks up harder and I don't usually get a chance to record any data. Hi, One solution is to use fuse instead of the native fs, until the CAM/SCSI refcount issues are resolved. --HPS If you refer to the usb stick, it locks up without inserting one. I'll try with the extra fs kmods unloaded and see how it goes. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help debugging stable/10
On 24/03/2015 01:55, Shane Ambler wrote: On 25/12/2014 23:03, Andriy Gapon wrote: On 25/12/2014 11:29, Hans Petter Selasky wrote: The cam_sim_free() is stuck, blocking the rest of that controller from enumerating. It might look like a non-USB stack issue. MAV: Do you have some ideas where to start looking, now we have a dump? Any refcounts to check in particular? Apparently sim-refcount 0. Not sure how to check who has the reference(s). Can anyone think of something I can try? To recap to save you going back through history - After running 9.0 - 9.2 for 3 years I upgraded to 10.1RC3 and started getting a locking issue, most new processes fail to start, top and ps failing being indicators, the most info I have got is a back trace using kgdb, there are 4 instances I got output from procstat -kk -a On several occasions I have found that after inserting a usb memstick the device failed to be created, leaving me unable to mount the filesystem without a restart. I then switched to stable/10 in hopes of a fix finding it's way in. The back traces I have been able to collect (and a dmesg) are listed at http://shaneware.biz/freebsddebugdata/ This is my everyday desktop machine. I am now running FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #11 r283839: Thu Jun 4 17:41:28 ACST 2015 root@leader.local:/usr/obj/usr/src/sys /GENERIC amd64 I can only say it appears to be getting worse, though I may just be getting sick of having to restart nearly every day. Lately it seems that the less I do the quicker it locks up. I have restarted twice this week and then let it sit while I have gone out, after returning I get maybe 10-15 mins then have to restart, one of them was less than an hour uptime. While running poudriere I have got past 1 day uptime but it locks up harder and I don't usually get a chance to record any data. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help debugging stable/10
:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffe6d8, rbp = 0x7fffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xf800222d6b78 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1814 Mar 24 00:24:25 leader kernel: 2nd 0x818514a8 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2872 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022df6e690 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022df6e740 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe022df6e7d0 Mar 24 00:24:25 leader kernel: _sx_slock() at _sx_slock+0x76/frame 0xfe022df6e810 Mar 24 00:24:25 leader kernel: mountcheckdirs() at mountcheckdirs+0x47/frame 0xfe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x36f/frame 0xfe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffe6d8, rbp = 0x7fffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xf8001ca8e240 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xf8001ca8e5f0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2157 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022df6e460 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022df6e510 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe022df6e5a0 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfe022df6e6e0 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfe022df6e700 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe022df6e730 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfe022df6e7a0 Mar 24 00:24:25 leader kernel: vget() at vget+0x67/frame 0xfe022df6e7e0 Mar 24 00:24:25 leader kernel: devfs_allocv() at devfs_allocv+0xfd/frame 0xfe022df6e830 Mar 24 00:24:25 leader kernel: devfs_root() at devfs_root+0x43/frame 0xfe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x345/frame 0xfe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffe6d8, rbp = 0x7fffe7d0 --- Mar 24 00:24:25 leader kernel: Uptime: 12m42s -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Continuous timeout messages from 10.0 alpha4
This is a regression between alpha2 and alpha4. I first setup a disk to boot 10 just after alpha2 was tagged. A few days ago I updated to alpha4 and started getting timeout messages, I have just built alpha5 r256098 and still get them. I just had 10 running for a few hours and 3 of the messages log archives which syslog rotates each hour due to size contain 3370 2508 and 3162 timeout messages over 3 hours uptime. each entry is similar to -- Oct 7 19:00:02 leader kernel: ahcich1: Timeout on slot 15 port 0 Oct 7 19:00:02 leader kernel: ahcich1: is 4001 cs 8000 ss rs 8000 tfd 2451 serr cmd 4f17 With slot x cycling from 0-31 but not always in sequence. MB is ASUS P8H61M LE/USB3 - corei5 - 8MB - nvidia GT520 ahci0: Intel Cougar Point AHCI SATA controller port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported With the following connected to ahcich1 (LG blu-ray burner) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: HL-DT-ST BD-RE BH12LS38 1.00 Removable CD-ROM SCSI-0 device Most relevant dmesg info would be (full dmesg/logs available) -- ahci0: Intel Cougar Point AHCI SATA controller port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ahcich4: AHCI channel at channel 4 on ahci0 ahcich5: AHCI channel at channel 5 on ahci0 ahciem0: AHCI enclosure management bridge on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD20EARX-00PASB0 51.0AB51 ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x14K ada0: Previously was known as ad4 ada1 at ahcich4 bus 0 scbus2 target 0 lun 0 ada1: WDC WD10EARS-00Y5B1 80.00A80 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x14K ada1: Previously was known as ad8 ada2 at ahcich5 bus 0 scbus3 target 0 lun 0 ada2: eSATA-2 WD800JD-23JNA1 06.01C06 ATA-6 SATA 2.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 512bytes) ada2: 76324MB (156312576 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad10 ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: AHCI SGPIO Enclosure 1.00 0001 SEMB S-E-S 2.00 device ses0: SEMB SES Device ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Build failure for 9.2-RELEASE
On 03/10/2013 17:14, Thomas Mueller wrote: I failed with make buildworld on 9.2, building from a 9.2 prerelease. svn revision on system to be built was 255986. uname -a shows FreeBSD amelia2 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #17 r254196: Sun Aug 11 00:36:49 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 PRERELEASE would be from stable/9 - RELEASE from releng/9.2 Did you svn up on the stable branch or checkout releng/9.2? I had MODULES_WITH_WORLD=yes in /etc/make.conf to avoid the redundancy and annoyance of rebuilding modules every time I build a new kernel, like if I want a more portable kernel (for a USB-stick install) as well as my custom kernel. Point of failure seemed to be in module dtrace. I have in kernel config #optionsKDTRACE_FRAME # Ensure frames are compiled in #optionsKDTRACE_HOOKS # Kernel DTrace hooks Maybe I need to reenable these? The 9.2 release notes says DTrace hooks have been enabled by default in the GENERIC kernel so they should already be enabled. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
lock order reversal in 10-alpha2
After booting from a 10-alpha2 disk I am seeing lock order reversal messages show up from time to time. Current logs have 35 entries. The machine normally is running 9.1 from zfs root and I have setup a separate disk (eSATA case connected through backplane port to onboard SATA port) that I have installed 10-alpha amd64 onto a ufs partition to test port building with. I started by building 10 alpha1 and installing onto the new disk. I have since done svn up (last revision is 255868) then rebuilt and installed kernel and world while running 10 and still see these messages. I mentioned the existing 9.1 on zfs which I am not importing while running 10 from ufs as I noticed zfs mentioned in one of the entries. Initially I built with an empty src.conf but the last build I used the following - WITH_BSD_GREP=yes WITH_CLANG_EXTRAS=yes WITH_CTF=yes WITHOUT_LIB32=yes WITH_LLDB=yes Hardware is ASUS P8H61-M LE/USB3 corei5 8GB RAM nvidia GT520 I can provide full copy of log/messages or dmesg if required. A few samples -- messages:Sep 26 02:01:27 leader kernel: lock order reversal: messages-Sep 26 02:01:27 leader kernel: 1st 0xfe01eebd07f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 messages-Sep 26 02:01:27 leader kernel: 2nd 0xf800122f8200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 messages-Sep 26 02:01:27 leader kernel: KDB: stack backtrace: messages-Sep 26 02:01:27 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238a8f270 messages-Sep 26 02:01:27 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238a8f320 messages-Sep 26 02:01:27 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfe0238a8f3b0 messages-Sep 26 02:01:27 leader kernel: _sx_xlock() at _sx_xlock+0x75/frame 0xfe0238a8f3f0 messages-Sep 26 02:01:27 leader kernel: ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfe0238a8f430 messages-Sep 26 02:01:27 leader kernel: ufs_direnter() at ufs_direnter+0x688/frame 0xfe0238a8f4f0 messages-Sep 26 02:01:27 leader kernel: ufs_makeinode() at ufs_makeinode+0x573/frame 0xfe0238a8f6b0 messages-Sep 26 02:01:27 leader kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0xea/frame 0xfe0238a8f6e0 messages-Sep 26 02:01:27 leader kernel: vn_open_cred() at vn_open_cred+0x300/frame 0xfe0238a8f830 messages-Sep 26 02:01:27 leader kernel: kern_openat() at kern_openat+0x261/frame 0xfe0238a8f9a0 messages-Sep 26 02:01:27 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe0238a8fab0 messages-Sep 26 02:01:27 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0238a8fab0 messages-Sep 26 02:01:27 leader kernel: --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80185baca, rsp = 0x7fffd168, rbp = 0x7fffd1a0 --- messages.0:Sep 23 10:08:11 leader kernel: lock order reversal: messages.0-Sep 23 10:08:11 leader kernel: 1st 0xf801ba2e65f0 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3435 messages.0-Sep 23 10:08:11 leader kernel: 2nd 0xfe01ef93c1c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 messages.0-Sep 23 10:08:11 leader kernel: 3rd 0xf801ba2e6240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 messages.0-Sep 23 10:08:11 leader kernel: KDB: stack backtrace: messages.0-Sep 23 10:08:11 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe02397c2300 messages.0-Sep 23 10:08:11 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe02397c23b0 messages.0-Sep 23 10:08:11 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfe02397c2440 messages.0-Sep 23 10:08:11 leader kernel: __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfe02397c2570 messages.0-Sep 23 10:08:11 leader kernel: ffs_lock() at ffs_lock+0x84/frame 0xfe02397c25c0 messages.0-Sep 23 10:08:11 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe02397c25f0 messages.0-Sep 23 10:08:11 leader kernel: _vn_lock() at _vn_lock+0xab/frame 0xfe02397c2660 messages.0-Sep 23 10:08:11 leader kernel: vget() at vget+0x70/frame 0xfe02397c26b0 messages.0-Sep 23 10:08:11 leader kernel: vfs_hash_get() at vfs_hash_get+0xf5/frame 0xfe02397c2700 messages.0-Sep 23 10:08:11 leader kernel: ffs_vgetf() at ffs_vgetf+0x41/frame 0xfe02397c2790 messages.0-Sep 23 10:08:11 leader kernel: softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xfe02397c2840 messages.0-Sep 23 10:08:11 leader kernel: ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xfe02397c28c0 messages.0-Sep 23 10:08:11 leader kernel: ffs_fsync() at ffs_fsync+0x20/frame 0xfe02397c28f0 messages.0-Sep 23 10:08:11 leader kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf0/frame 0xfe02397c2920 messages.0-Sep 23 10:08:11 leader kernel: sys_fsync() at sys_fsync+0x156/frame 0xfe02397c29a0 messages.0-Sep 23 10:08:11 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe02397c2ab0 messages.0-Sep 23
Problem using mergemaster for 10-alpha
I have setup a few machines in the past from CD installer and my current
machine started with CD install and was then updated from source.
Currently my machine runs 9.1-RELEASE-p3
Yesterday I started to setup a clean 10.0 install onto a new drive that
I can boot from to test ports building with, but had trouble running
mergemaster to get the config files into place. I manually copied the
/etc files from /var/tmp/temproot to get the system running.
The steps I used are based on the handbook upgrade steps but I don't
see any variations to do a clean install from source (I created empty
src.conf and make.conf to prevent using my current files) -
setenv TOPDIR ~/Projects/f10-test
setenv TMPTESTROOT /mnt
setenv MAKEOBJDIRPREFIX ${TOPDIR}/obj
cd ${TOPDIR}
svn co svn://svn0.us-west.FreeBSD.org/base/head src
touch make.conf
touch src.conf
setenv __MAKE_CONF ${TOPDIR}/make.conf
setenv SRCCONF ${TOPDIR}/src.conf
cd ${TOPDIR}/src
make -j4 buildworld
make -j4 buildkernel
mount /dev/da4p3 ${TMPTESTROOT}
make installkernel DESTDIR=${TMPTESTROOT}
mergemaster -p -a -m ${TOPDIR}/src -D ${TMPTESTROOT}
make installworld DESTDIR=${TMPTESTROOT}
mergemaster -a -m ${TOPDIR}/src -D ${TMPTESTROOT}
When using mergemaster with -a I get the following error
*** Creating the temporary root environment in /var/tmp/temproot
*** /var/tmp/temproot ready for use
*** Creating and populating directory structure in /var/tmp/temproot
install: illegal option -- l
usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** FATAL ERROR: Cannot 'cd' to /home/shane/Projects/f10-test/src and
install files to
the temproot environment
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem using mergemaster for 10-alpha
On 20/09/2013 19:39, Bryan Drewery wrote: On Fri, Sep 20, 2013 at 03:38:17PM +0930, Shane Ambler wrote: When using mergemaster with -a I get the following error *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot install: illegal option -- l *** FATAL ERROR: Cannot 'cd' to /home/shane/Projects/f10-test/src and install files to the temproot environment See /usr/src/UPDATING entry 20130425 UPDATING describes mergemster -p as the issue and installing the new version as a fix. The new version fixes the fatal error above but it doesn't honour the -D option so doesn't install anything into /mnt still leaving me with manually copying from temproot. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs_enable vs zfs_load in loader.conf (but neither works)
On 09/09/2013 21:20, J David wrote: On Sun, Sep 8, 2013 at 11:11 PM, Darren Pilgrim list_free...@bluerosetech.com wrote: You can use zfs.root.mountfrom=zfs:data/root in /boot/loader.conf instead of an fstab entry. That has been in loader.conf the whole time. Mountpoint=legacy is required either way. It isn't. There is another machine right next to it running 9.2-RC1 and it works fine with the mountpoint=/ setting and an empty fstab. I installed 9.0 onto my machine booting from zfs about a year and a half ago and remember having issues getting it bootable. As I recall mounpoint=legacy and mountpoint=/ effectively point to two different filesystems. Changing the mounpoint after installing hides the / filesystem. So it isn't so much which mountpoint to use but which mountpoint *was* used when you installed the system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: OVH KS-2G Random Reboots [FreeBSD 9.1-RELEASE-p6]
On 30/08/2013 06:39, Paul Chakravarti wrote: I am running FreeBSD 9.1-RELEASE-p6 and am getting multiple random reboots daily (sometimes hours apart, sometimes minutes). I suspect that it might be a hardware issue however have tried extended runs (upto 8 hours) of 'cpuburn' and 'stress' from ports which run fine. Strangely there seem to be less reboots under heavy load but that may just be perception. Any chance it panics going to sleep? Full load keeps it awake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Properties list for zfs in FreeBSD
On 21/08/2013 23:39, Trond Endrestøl wrote: On Wed, 21 Aug 2013 13:02-, Zenny wrote: Where can I find a list of properties (-o/-O property=value) for creating a zpool? Read zpool(8) for zpool properties, and zfs(8) for zfs properties. Always a good place for detailed explanations. A quick way to list all properties is to use the get command to cause a usage output. zpool get usage: get all | property[,...] pool ... the following properties are supported: PROPERTY EDIT VALUES allocated NO size capacity NO size ... zfs get missing property argument usage: get [-rHp] [-d max] [-o all | field[,...]] [-t type[,...]] [-s source[,...]] all | property[,...] [filesystem|volume|snapshot] ... The following properties are supported: PROPERTY EDIT INHERIT VALUES availableNO NO size clones NO NO dataset[,...] ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Bind in FreeBSD, security advisories
On 31/07/2013 01:31, Daniel Kalchev wrote: But here is an idea: Remove BIND from HEAD overnight and see how many will complain ;-) If nobody complains, don't put it back in. Or change the default to off. If you want bind add WITH_BIND=yes to src.conf It's hard to say FreeBSD is a safe and secure OS when part of the base install is always being shown to have security flaws. New features need to prove they are reliable before they are accepted into a release yet we allow something that has a long proven history of being a source of security concerns. For something that needs to be constantly updated in between system updates then ports is the place to install it from. I think it is less about whether bind is useful and needs to be in base and more about should every user of FreeBSD be open to security issues or should a user have the option to say yes I want potentially insecure software on my machine. The ports system allows messages that make it obvious to the user about security concerns. Yes many users know the bind utilities and rely on them but a lot of users have no idea how to use them. I expect that the bind tools are used by a number of users that know what they are doing and need them for testing and debugging issues, they also know how to install them when they need them. I believe most users would not need or use these tools. How many people setup and use a FreeBSD machine without adding something from ports or packages? And yes I setup my own dns server to resolve internal host names instead of filling /etc/hosts with entries. As for the tools like dig and host, I rarely use them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does the image on isc.portsnap.freebsd.org have a virus?
On 31/07/2013 15:44, Chris H wrote: Greetings, I know this sounds crazy, and apologies if I am. But I have 2 RELENG_8 servers; 1 amd64, and 1 i386. about 3 wks ago, I migrated from cv(sup) updating, to svn on the amd64 box. After removing cv(sup) related folders, and the ports folder, I used: portsnap fetch After the fetch completed I ran: portsnap extract which verified/patched extracted the image to /usr/ports. Tonight, I initiated the same procedure on the i386 server. _BUT_ upon completion of the fetch, it proceeded to verify/patch extract; _not_ to /usr/ports, but to /var/db/portsnap/ports. re-examining /etc/portsnap.conf, and re-reading the portsnap(8) man page, reveals that _both_ .conf files are identical, as were the version(s) used on both boxes. An additional attempt to portsnap fetch, resulted in the same (unorthodox) behavior. What gives?! Are you watching as it started or when it finished? /var/db/portsnap is used by portsnap to download updates that it uses to generate the /usr/ports files. Just guessing but it may also extract and patch files there before moving them to /usr/ports ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does the image on isc.portsnap.freebsd.org have a virus?
On 01/08/2013 00:28, Chris H wrote: In the first instance, /usr/ports was removed (before initiating portsnap). But before the second attempt, I performed a mkdir /usr/ports. But in the end, the results were the same; portsnap fetch fetched the image, verified the image, extracted to /var/db/portsnap/ports, then patched, and exited. I did _not_ issue portsnap fetch portsnap extract. So I guess portsnap extract is a noop. Guess it's time to update the portsnap(8) man pages to indicate portsnap fetch is no longer an option. 'portsnap fetch' downloads the relevant data to /var/db/portsnap 'portsnap extract' extracts the files to /usr/ports 'portsnap update' updates existing files in /usr/ports So on a clean system you use portsnap fetch extract Then to update later you use portsnap fetch update (you can give multiple commands to portsnap in one go) If fetch extract works on amd64 and not i386 then you should submit a problem report so that it can be fixed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with zfsloader on 9.2-BETA2
On 01/08/2013 01:42, J David wrote: =34 1953525101 da2 GPT (931G) 34 222 - free - (111k) 256 19535084951 freebsd-zfs (931G) 1953508751 163849 !6a945a3b-1dd2-11b2-99a6-080020736631 (8.0M) da3 - da7 are identical to da2. So maybe it's a little weird that our boot blocks are on our ZLOG/L2ARC devices, rather than our data devices? I think that 8M partition looks weird. It looks like a leftover from a previous config? Two things I would think to consider - the odd alignment of the partition. Most recent drives benefit from 4K alignment. For the last couple of years drives have started using 4K blocks instead of the traditional 512byte blocks. They still accept 512byte blocks and internally remap to the 4K blocks with a penalty. google 4k partition alignment for a variety of discussions. Secondly do you need that trailing 8M? I would give zfs the entire drive and not use partitions. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zpool on a zvol inside zpool
On 22/07/2013 19:54, Stefan Esser wrote: Am 22.07.2013 10:04, schrieb Eugene M. Zheganin: Hi. I will make a zpool on a zvol encrypted by geli. I have configured a system in just that way, a few weeks ago. It seems to work just fine. It sounds like a fix may exist in head but if you want to use snapshots you may want to read kern/161968 first ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: recommended memory for zfs
On 09/05/2013 22:48, Benjamin Adams wrote: Hello zfs question about memory. I heard zfs is very ram hungry. Service looking to run: - nginx - postgres - php-fpm - python I have a machine with two quad core cpus but only 4 G Memory I'm looking to buy more ram now. What would be the recommend amount of memory for zfs across 6 drives on this setup? I believe I heard a calculation of 1GB cache per 1TB of disk. But basically zfs will use all free ram available if you access that much data from disk. You will want to set vfs.zfs.arc_max to allow enough ram for your apps to work in. If you consider the files for your website and the data you store you may find that you would never fill more than 500MB of cache. If you will be serving large media files that will easily use up the cache you could give them their own filesystem that only caches metadata - zfs set primarycache=metadata zroot/mediafiles ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Request for heimdal update to stable/releng
While looking into an issue with security/heimdal I found that v1.5.2 of heimdal has been in HEAD for 11 months and has had 2 small fixes in that time. Now that I look at it these two fixes should probably be duplicated to the port as well. This update has yet to be copied down to stable or releng branches, leaving releng with v1.1 which is over 5 years old. The issue I found in the ports version (pr/177397) appears to still exist in HEAD - while the hcrypto lib included is not used the man pages are still installed. Some of these man pages have the same names as openssl man pages. As openssl is used the hcrypto man pages don't need to be installed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No sound with Realtek ALC269
On 23/02/2013 01:32, Zhihao Yuan wrote: I my case, the sound card just do not work, though the device and the driver are working. Suggestions wanted. Thanks. I have a Realtek ALC887 on my machine. I first installed 9.0rc3 and had sound issues. I found the default sound driver didn't work or didn't pick the correct driver to use. The solution I found was to specify the specific driver by adding snd_hda_load=YES to /boot/loader.conf I think you can test that with kldload snd_hda ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 AMD64 multitasking efficiency low
I have two WD's a 1TB and a 2TB. Upgraded to 9.1 three days ago and don't think it is any worse than 9.0. I find things slow down if two things are trying to access the drive at the same time and when I do get some swapping it gets unbearable. One thing that always annoyed me was the security scans that start early morning, they make any tinderbox builds I leave running grind to a halt. They also run shortly after startup - and they show little cpu usage. Disable them by adding to /etc/periodic.conf daily_status_security_chksetuid_enable=NO daily_status_security_neggrpperm_enable=NO I'm sure the first one is a long scan but haven't verified the second. I think I recall the aio module made a difference for me. I believe kldload aio will make it active straight away - if not aio_load=YES in /etc/loader.conf to load at boot I have a desktop machine - ASUS P8H61-M/LE corei5 8GB ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD20EARX-00PASB0 51.0AB51 ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich4 bus 0 scbus2 target 0 lun 0 ada1: WDC WD10EARS-00Y5B1 80.00A80 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CLANG and -fstack-protector
On 13/02/2013 12:52, Dmitry Marakasov wrote: afaik, in prior discussion some years ago an issue was mentioned that some ports don't build with stack-protector, so I suggested to introduce STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by enabling stack protector are not transient, so we can have an exp-run to just mark all uncompatible ports and consider all others compatible). If there's interest in this, I can refresh the patch and submit it. I think it sounds like a good idea - I'd go with only specify unsafe when needed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 stability/robustness?
On 02/11/2012 15:57, Doug Hardie wrote: On 1 November 2012, at 19:14, Brett Glass wrote: I need to build up a few servers and routers, and am wondering how FreeBSD 9.1 is shaping up. Will it be likely to be more stable and robust than 9.0-RELEASE? It appears to be for me. I had problems with 9.0 not reading CDs and rebooting with no error messages frequently. I have upgraded to 9.1-RC2 and it now reads CDs just fine, and has not rebooted. However, the uptimes with 9.0 ranged from about 2 hours to 30 days. I have only had 9.1-RC2 running for a couple weeks so have not declared victory yet. I has been running for more than most of the uptimes already. Personally I have had little issue with 9.0. I started with installing PC-BSD-9.0RC3 then moved to FreeBSD 9.0-RELEASE Shortly after I installed a world built with clang which found an issue with libthr that is fixed in 9.1 Until yesterday my only restarts have been power failure or updating kernel and/or kmods - I seem to have trouble manually unloading the nvidia kmod so end up restarting. I am fairly certain the restart I had yesterday is related to cuse4bsd-kmod which I have disabled for now to try and prove that. While I can load and use the current version the previous one is the only one I have been able to have activated during startup. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CPU Competition Issue
On 30/10/2012 19:27, Andriy Gapon wrote: on 30/10/2012 03:33 Steven Nikkel said the following: I'm running a long duration CPU-centric process that will gobble up all available CPU time. I have it set to run at nice +20. While it's running I've noticed other processes have a hard time getting CPU time and run their activites very slowly. The processes I've noticed issues with are IO involved, but they don't appear to be IO blocked as they run dramatically faster and use much more CPU time when the CPU intensive process is not running. I haven't noticed issues with other processes, but I haven't been looking. If I push my CPU intensive process into idle priority 1, all the other processes return to their normal behaviour as if it's not running. This seems to be a specific behaviour on this one machine running 9.0-RELEASE-p4 on an Atom 330 dual core. I've tried with and without hyperthreading enabled with no noticeable change in behaviour. Can you try with lower nice value, like +10? You want a fix from r228718. AFAIR, it is not in 9.0. Could it be cache based? The atom's smaller cache causing more cache misses. Would you be running zfs? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gt520 and 9.1
On 05/10/2012 01:37, Zoran Kolic wrote: After years of using nvidia 6200 with nv, I had to move to above mentioned gt520. Fast search shoes I nvidia-driver. Correct? And to change nv in conf file to nvidia with nvidia_load=YES in rc.conf? I wait to install the card till release comes out. Best regards all Zoran I have a GT 520 in an ASUS P8H61-M LE/USB3 with a corei5 8GB running two HD lcd's I have run 9.0 since RC3 (when I got the machine) without issues until the recent update - v304.43 - that version failed to run the second monitor so I went back to v295.71_1. There is another update since but I haven't tried it yet. The nvidia_load=YES goes into /boot/loader.conf not rc.conf Yes to use nvidia instead of nv in xorg.conf. nvidia-xconfig is a cli app that will configure the xorg.conf without asking for any options while nvidia-settings is a gui app that you can adjust all options and can then generate the xorg.conf to your settings. And if you are running dual monitors I recommend using twinview not xinerama. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pcre-related problem to compile HipHop in FreeBSD9-RELEASE
On 18/04/2012 17:29, Zenny wrote:
Hi:
I am having problem while trying to compile HipHop similar to what has
been discussed here
(https://github.com/facebook/hiphop-php/issues/480#pull_comment_form)
/root/hhbuild/hiphop-php/src/runtime/base/preg.cpp:138: error:
'pcre_info' was not declared in this scope
*** Error code 1
I checked the specific line 138 which reads like:
if (pcre_info(pce-re, NULL, NULL) == PCRE_ERROR_BADMAGIC) {
pcre_cache.cleanup();
Any hints? Could not figure out whether it is FreeBSD9-, pcre- or
HipHop-related?
Thanks!
not declared in this scope - means it hasn't found a declaration for
that function. Usual cause is not including the correct header file, but
in the case of pcre the recent update broke a few programs when first
brought in.
I don't see it by greping the pcre headers and a quick search on
http://www.freebsd.org/cgi/man.cgi for pcre_info in 9.0-release and
ports shows it as obsolete and replaced by pcre_fullinfo() - my guess is
pcre_info() was removed in the pcre-8.30 release.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Too many open files
On 26/03/2012 02:19, C. P. Ghost wrote:
On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi
prabh...@digital-infotech.net wrote:
Greetings Friends,
have anyone has come across this warning / error? This occurs when i ssh
to my FreeBSD 9.0 System. any help would be greatly appreciated.
Warning:
/usr/share/games/fortune/freebsd-tips.dat: Too many open files in system
[mavi@titan ~]$ su
su: pam_start: system error
Thanks / Regards
Prabhpal
What does this command say on your system?
% sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles
You may have exceeded the maximum number of open files
in the system. Maybe some ill-conceived program that doesn't
close non-needed connections, files, etc is at fault? It's easy
to open more and more files, and to gradually fill the open
files descriptor table in the kernel this way.
-cpghost.
From knowing that you have too many files open you can increase the
maxfile numbers - but if you want to know what uses them try this -
lsof -n | awk '{print $2 \t $1}' | sort | uniq -c | sort
lsof outputs open file info, awk then gives us the PID and proc name
which gets sorted and uniq gives a count of each which we sort to have
the largest file count at the bottom of the list. What you end up with
is a list of two numbers and a name - count of files open followed by
the PID and proc name that has them open.
The catch is that it also includes network connections (I know how to
list only network but not sure how to exclude them)
ps ax | grep PID
will show you the full program name if it has been shortened.
lsof -p PID
will show all the open files for PID
Not sure if this is the best way but it works for me.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SAS Drive identification LEDs
On 21/03/2012 08:23, Matt Burke wrote: Under 9.0-RELEASE I'm having trouble figuring out how to light up the drive identification/fault lights on my enclosure (SAS disks on Chenbro 80H10321513C0 backplanes attached to Areca ARC-1320 HBAs) # setobjstat /dev/ses0 0xb 0x80 0x00 0x02 0x00 light on drive bay 8 starts flashing # setobjstat /dev/ses0 0xb 0x80 0x00 0x00 0x00 light on drive bay 8 stops flashing Which is great, but how can I work out how /dev/daNN maps to /dev/sesN element 0xNN? Not sure if I can help but I'll throw these thoughts at you - If I run dmesg | grep ada0 the first and last lines are - ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: Previously was known as ad4 or ls -l /dev | grep ada lrw-rw-rw- 1 root wheel - 4B 6 Mar 04:19 ad4@ - ada0 lrw-rw-rw- 1 root wheel - 6B 6 Mar 04:19 ad4p1@ - ada0p1 ... lrw-rw-rw- 1 root wheel - 4B 6 Mar 04:19 ad8@ - ada1 lrw-rw-rw- 1 root wheel - 6B 6 Mar 16:19 ad8p1@ - ada1p1 ... I think man glabel may give some ideas but man libgeom would be a starting place if your looking at drivers. I've read mav@'s 2011 PDF on Enclosure Management (http://people.freebsd.org/~mav/Enclosure_Management_en.pdf) which shows a work-in-progress driver and getencstat which does what I need, but it looks like the project's not been committed yet. Sounds like this is your best bet. Find out how close he is to release and offer to test, help push to be accepted in trunk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [releng_8 tinderbox] failure on i386/i386
On 08/03/2012 14:54, FreeBSD Tinderbox wrote: snip Kernel build for PAE started on Thu Mar 8 04:20:42 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh PAE-GENERIC cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug ld: kernel.debug: Not enough room for program headers (allocated 5, need 6) ld: final link failed: Bad value *** Error code 1 Stop in /obj/i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-08 04:24:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-08 04:24:30 - ERROR: failed to build PAE kernel TB --- 2012-03-08 04:24:30 - 5280.71 user 847.19 system 6555.20 real Not sure if this is related but thought I would start here. I started experimenting with tinderbox a few days ago and found multimedia/dirac as a dependancy failed to build with clang and made a patch to resolve that. As I tested building with tinderbox I found 8-STABLE failed to build with gcc. To further investigate I expanded my jails to include every releng (since 7.0) and found this - Every amd64 system version and compiler combination works. 7.4 7-STABLE 8.2 8.3 8-STABLE 9.0 fail to build with arch i386 and gcc Other system versions with i386 arch build. The error I get is - undefined reference to `__sync_fetch_and_add_4' After some googling I found setting CPUTYPE in the builds environment file has an effect. Setting CPUTYPE to i486 or nocona builds Setting CPUTYPE to i386, generic, native or empty fails Each of my builds has CC CXX CPP and ARCH set in the build environment file. I tried setting MACHINE_ARCH UNAME_m UNAME_p to i386 without change (without CPUTYPE). I also tested the dirac patch on redports and it builds 8.2-RELEASE with i386 arch - no CC set means gcc. So does that indicate a regression between 8.2 release and releng? The biggest question is whether this is related to tinderbox or the base system. I'm leaning to system. For reference I am running 9.0-RELEASE amd64 on a corei5 system 8GB RAM built with clang and WITHOUT_LIB32=yes This is my complete list of tinderbox builds - 7.0-amd64-gcc 7.0-i386-gcc 7.1-amd64-gcc 7.1-i386-gcc 7.2-amd64-gcc 7.2-i386-gcc 7.3-amd64-gcc 7.3-i386-gcc 7.4-amd64-gcc 7.4-i386-gcc 7-STABLE-amd64-gcc 7-STABLE-i386-gcc 8.0-amd64-gcc 8.0-i386-gcc 8.1-amd64-gcc 8.1-i386-gcc 8.2-amd64-gcc 8.2-i386-gcc 8.3-amd64-gcc 8.3-i386-gcc 8-STABLE-amd64-gcc 8-STABLE-i386-gcc 9.0-amd64-clang 9.0-amd64-gcc 9.0-i386-clang 9.0-i386-gcc 9-STABLE-amd64-clang 9-STABLE-amd64-gcc 9-STABLE-i386-clang 9-STABLE-i386-gcc 10-CURRENT-amd64-clang 10-CURRENT-amd64-gcc 10-CURRENT-i386-clang 10-CURRENT-i386-gcc -- Shane Ambler FreeBSD (at) ShaneWare (dot) Biz http://ShaneWare.Biz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
