Re: How to handle the pack files now we have switched to git?
On Tue, 2021-01-05 at 11:08:48 +, Pete French wrote: So, for me the switch to git went very smoothly. I havent moved to etcupdate yet, but will probably do that soon. Hopwever I did hit one issue. What I do is to build on a single machine, and then send that to a number of places using rsync. But what seems to happen wuth git is that it has a big pack file of objects, and the name of the opack file is the SHA1 of whatever is inside it. So if something chnages then the filename chnages - and thus rsync tries to move the entire lot all over again, even if the change is tiny. That's not entirely correct. The packfile will only be rewritten if a) enough other stuff has accumulated b) you force a repack. You are fighting against git's GC mechanism a bit here, but you can still make it work. On your source of truth host, do the following: 1. git gc --aggressive 2. look at .git/objects/pack, there should be a single big pack 3. touch .git/objects/pack/pack-.keep (or was it .pack.keep?) 4. rsync --del to all other hosts Now future git gc runs will not delete that big pack, you'll only get churn in the new, much smaller, packs. hth Uli ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Sun, 2021-01-03 at 19:02:24 +0100, Helge Oldach wrote: Hi all, I have deep cloned main from https://git.freebsd.org/src.git as described in the mini primer and started pulling updates. Now I'm stumbling over a bit of confusion: | hmo@p48 /usr/src $ git log -p e35a01eec6926bfb5c088ca8961079b51a067bf3 | commit e35a01eec6926bfb5c088ca8961079b51a067bf3 | Merge: 2ff66a91552 96b88ac701b | Author: Philip Paeps | Date: Wed Dec 30 12:50:26 2020 +0800 | | contrib/tzdata: import tzdata 2020f | | Merge commit '96b88ac701b35ce68425046d4be8f51cb75b5d5b' into main | | Changes: https://github.com/eggert/tz/blob/2020f/NEWS | | MFC after:1 day | | commit 96b88ac701b35ce68425046d4be8f51cb75b5d5b | Author: Philip Paeps | Date: Wed Dec 30 12:45:24 2020 +0800 | | Import tzdata 2020f | | diff --git a/Makefile b/Makefile | index 5064a190c5a..1136af9298f 100644 | --- a/Makefile | +++ b/Makefile | @@ -945,7 +945,10 @@ check_public: $(VERSION_DEPS) | mkdir public.dir | ln $(VERSION_DEPS) public.dir What confuses me is that the diff refers to just "Makefile". Same for the other files in this commit. The diff just looks like the vendor commit and not like the merged commit. This is kind of confusing as clearly this commit does not refer to the main source Makefile, but just to contrib/tzdata/Makefile. Well, you're looking at the diff of the vendor import, not the diff of the merge commit. The vendor area doesn't have a prefix in its tree, see the output of git ls-tree -r 96b88ac701b35ce68425046d4be8f51cb75b5d5b That is the vendor area tree for tzdata. What trips you up is that git log -p does _not_ show diffs for merge commits by default, because with 2 parents for a commit, what's the diff really? Look carefully at the 2nd line, it says "Merge: 2ff66a91552 96b88ac701b" indicating that this is a merge commit. To get a meaningful diff output, you sadly have to hand-hold git. What always works is comparing 2 trees directly, so (add -p to see full diff): % git diff-tree 2ff66a91552 e35a01eec6926bfb5c088ca8961079b51a067bf3 :04 04 8feda71c4bc2d2deb3a6c3dcf19ca1272ef51c71 6e6f976db44b4430645b0c6d7a169d5e5564acec M contrib This has to assume that the first parent shown was the previous commit on main, but it could well have been the other way round. But you also list the commit for 96b88ac701b35ce68425046d4be8f51cb75b5d5b so it's clear that this had to be the one. You can short-cut this, assuming that the first parent will always be on main (I think this is true in the conversion). % git diff e35a01eec^1..e35a01eec (^1 means first parent of the commit, and is often equivalent to ~1 which means "go 1 back"). At which point you can read git-log(1) and see that there's also a --first-parent option, which will only walk the first parent and properly works in tandem with -p. hth Uli ___ 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: No more update on stable/12
Obviously. I mean why would you get it from a third party instead from the project directly? On Fri, 1 Jan 2021, 21:19 Tj, wrote: > So the suggestion is still to use official freebsd.org url where possible? > > > Belatedly, this has now happened. Before the stable and master branches > on GH were the legacy kind that we need to get rid of. As of yesterday, the > main and stable branches on GH now match what is on git.freebsd.org for > both doc and src. Please see the update on the legacy `master` branch on GH > if you want to keep using this 3rd party clone/mirror instead of using the > official FreeBSD one. Cheers Uli > ___ 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: No more update on stable/12
On Wed, 2020-12-30 at 17:47:00 +0800, Li-Wen Hsu wrote: On Wed, Dec 30, 2020 at 17:44 Li-Wen Hsu wrote: On Wed, Dec 30, 2020 at 17:33 Yasuhiro Kimura wrote: From: Peter Blok Subject: No more update on stable/12 Date: Wed, 30 Dec 2020 10:24:27 +0100 > I switched to git, but I noticed there were no MFC or any other updates over the last couple of days after the migration. git fetch doesn’t show any change. > > Is this correct and just the learning process of git or is something wrong with my git clone? Which repository do you use?. Currently new canonical src repository (https://git.freebsd.org/src.git) is updated but not mirrored to GitHub yet. Supported stable and releng branches will have git2svn exporters to keep sync with git through their supporting life cycle. I’m sorry the progress is delayed, but it will be staring syncing soon. And GitHub mirror will also be sync’d again soon after we completed the repository adjustment. For now please get the latest changes of stable branches from git.FreeBSD.org or other mirrors at GitLab and Codeberg. Belatedly, this has now happened. Before the stable and master branches on GH were the legacy kind that we need to get rid of. As of yesterday, the main and stable branches on GH now match what is on git.freebsd.org for both doc and src. Please see the update on the legacy `master` branch on GH if you want to keep using this 3rd party clone/mirror instead of using the official FreeBSD one. Cheers Uli ___ 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: git, $FreeBSD$ and mergemaster
On Fri, 2020-12-25 at 04:18:22 -0800, David Wolfskill wrote: On Fri, Dec 25, 2020 at 10:00:57PM +1300, Jonathan Chen wrote: Hi Kyle, On Thu, 24 Dec 2020 at 15:05, Kyle Evans wrote: ... > mergemaster only uses it as an optimization, if they're unexpanded > throughout then it falls back to diff(1) -- i.e. it's slower without. Thanks for the answer. However, wouldn't this mean that every run of "mergemaster" would prompt for local changes? The nice thing about using the $FreeBSD$ tags was that if I approved a local-change, subsequent runs of mergemaster would not prompt me about the local-change unless the etc-file had been modified in the source tree. Cheers. -- Jonathan Chen Indeed: the above-described behavior is what I have observed so far since the transition (tracking head & stable/12 daily on two machines). I would go a bit further than stating that the prior behavior was "nice." The only way forward is full git! Provide the /etc equivalent in a git branch or subdir, then check it out to /etc and handle local changes with git rebase or git merge. (I'm not even joking! :) Cheers Uli ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote: On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote: On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. ... I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean), but that's just a trivial issue with my source tree being marked -dirty when it isn't, and that would have been part of r368709 anyway. All my other git nits have been my own (refs/notes and origin name). Warner/others, up to r368820, we had log entries that looked like this: commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a Author: Li-Wen Hsu Date: Sun Dec 20 02:59:44 2020 + Mark the repository as being converted to Git. This is the last Subversion commit to src. Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=368820 Now, our git logs look like this: commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc Author: Ed Maste Date: Tue Dec 22 23:31:15 2020 -0500 newvers.sh: fix sense of git dirty check Previously we reported -dirty for an unmodified tree, and no -dirty if there were changes. PR: 252028 Reported by:John Kennedy (Specifically, no Notes: with revision= value) Yes, these notes are merely pointers to the SVN revisions. Without SVN, we will of course not get any new notes. For the kernel I compiled today, the uname output dumps out: FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ... Last kernel was (-dirty since fixed): FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ... So, the r368820-value isn't being updated for it to find anymore. The middle value corresponds to the git commit and does have value (878d53410f75 is your "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository as being converted to Git" r368820 commit). Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds "some" note in the last 10k revs and then uses that, instead of properly falling back to counting from HEAD, which would result in -c255126 or something around that. We'll fix it ... Cheers Uli ___ 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: -STABLE can no longer build -CURRENT kernel, linker missing ifunc
2018-07-25 17:04 GMT+02:00 Kyle Evans : > > On Wed, Jul 25, 2018 at 9:52 AM, Alan Somers wrote: > > On Wed, Jul 25, 2018 at 8:49 AM, Ian Lepore wrote: > > > >> On Wed, 2018-07-25 at 14:35 +0200, Ulrich Spörlein wrote: > >> > Hey all, as of a couple of weeks ago, neither 11.2-RELEASE nor a > >> > recent > >> > 11-STABLE can buildkernel from head. > >> > > >> > This has stopped the Coverity Scan runs dead in its track and I > >> > wonder how > >> > anyone would boostrap a move from 11.x to 12.0 then. > >> > > >> > % env __MAKE_CONF=/dev/null make buildkernel > >> > make[1]: "/data/freebsd.work/Makefile.inc1" line 343: > >> > SYSTEM_COMPILER: > >> > libclang will be built for bootstrapping a cross-compiler. > >> > make[1]: "/data/freebsd.work/Makefile.inc1" line 348: SYSTEM_LINKER: > >> > libclang will be built for bootstrapping a cross-linker. > >> > > >> > -- > >> > > > >> > > > > >> > > > > > >> > > > > Kernel build for GENERIC started on Wed Jul 25 14:34:46 CEST > >> > > > > 2018 > >> > -- > >> > ===> GENERIC > >> > mkdir -p /usr/obj/data/freebsd.work/amd64.amd64/sys > >> > > >> > -- > >> > > > >> > > > > >> > > > > > >> > > > > stage 1: configuring the kernel > >> > -- > >> > cd /data/freebsd.work/sys/amd64/conf; PATH=/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/freebsd.wo > >> > rk/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/amd64.am > >> > d64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/sbi > >> > n:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/ > >> > sbin:/usr/bin > >> > config -d /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC -I > >> > '/data/ > >> > freebsd.work/sys/amd64/conf' > >> > '/data/freebsd.work/sys/amd64/conf/GENERIC' > >> > Kernel build directory is > >> > /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC > >> > Don't forget to do ``make cleandepend && make depend'' > >> > > >> > -- > >> > > > >> > > > > >> > > > > > >> > > > > stage 2.1: cleaning up the object tree > >> > -- > >> > cd /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC; > >> > MACHINE_ARCH=amd64 > >> > MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd12.0 > >> > --sysroot=/usr/obj/data/freebsd.work/amd64.amd64/tmp -B/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp/usr/bin" CXX="c++ -target > >> > x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp -B/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp/usr/bin" CPP="cpp -target > >> > x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp -B/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" LD="ld" > >> > LLVM_LINK="" > >> > NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" > >> > INSTALL="sh > >> > /data/freebsd.work/tools/install.sh" PATH=/usr/obj/data/ > >> > freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/freebsd.wo > >> > rk/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/amd64.am > >> > d64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/sbi > >> > n:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/ > >> > sbin:/usr/bin > >> > make -m /data/freebsd.work/share/mk KERNEL=kernel cleandir > >> > make[2]: "/data/freebsd.work/sys/conf/kern.pre.mk" line 125: amd64 > >> > kernel > >> > requires linker ifunc support > >> > *** Error code 1 > >> > > >> &
-STABLE can no longer build -CURRENT kernel, linker missing ifunc
Hey all, as of a couple of weeks ago, neither 11.2-RELEASE nor a recent 11-STABLE can buildkernel from head. This has stopped the Coverity Scan runs dead in its track and I wonder how anyone would boostrap a move from 11.x to 12.0 then. % env __MAKE_CONF=/dev/null make buildkernel make[1]: "/data/freebsd.work/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/data/freebsd.work/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. -- >>> Kernel build for GENERIC started on Wed Jul 25 14:34:46 CEST 2018 -- ===> GENERIC mkdir -p /usr/obj/data/freebsd.work/amd64.amd64/sys -- >>> stage 1: configuring the kernel -- cd /data/freebsd.work/sys/amd64/conf; PATH=/usr/obj/data/ freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/sbin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC -I '/data/ freebsd.work/sys/amd64/conf' '/data/freebsd.work/sys/amd64/conf/GENERIC' Kernel build directory is /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC Don't forget to do ``make cleandepend && make depend'' -- >>> stage 2.1: cleaning up the object tree -- cd /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC; MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/freebsd.work/amd64.amd64/tmp -B/usr/obj/data/ freebsd.work/amd64.amd64/tmp/usr/bin" CXX="c++ -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/ freebsd.work/amd64.amd64/tmp -B/usr/obj/data/ freebsd.work/amd64.amd64/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/ freebsd.work/amd64.amd64/tmp -B/usr/obj/data/ freebsd.work/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /data/freebsd.work/tools/install.sh" PATH=/usr/obj/data/ freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/sbin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /data/freebsd.work/share/mk KERNEL=kernel cleandir make[2]: "/data/freebsd.work/sys/conf/kern.pre.mk" line 125: amd64 kernel requires linker ifunc support *** Error code 1 Stop. make[1]: stopped in /data/freebsd.work *** Error code 1 Stop. make: stopped in /data/freebsd.work ___ 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: pkg 1.5.0 is out
2015-07-01 13:38 GMT+02:00 Baptiste Daroussin : > > On Wed, Jul 01, 2015 at 01:36:14PM +0200, Hans Petter Selasky wrote: > > On 04/21/15 12:34, Slawa Olhovchenkov wrote: > > > On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: > > > > > >> Hi all, > > >> > > >> Final pkg 1.5.0 has been released. > > > > > > > Hi, > > > > Is there a way the external SAT solver functionality can be memory > > optimised? When trying to use this feature having +750 packages > > installed, the memory usage starts growing and growing beyond 4GBytes > > until PKG segfaults, even before the CNF export has started. > > > > env SAT_SOLVER=mysolver pkg upgrade > > Probably, but given the little amount of time pkg developers has we will > greatly > appreciate patches :) > > AKA this would be greatly appreciated, but very low on the priority list :( > > Best regards, > Bapt Hijacking this, I managed to mess up my local pkg repo somehow. I build my own set of packages, and typically do pkg upgrade on the clients. This time, I tried pkg upgrade -F, which went and downloaded everything and that's fine. But now when I run "pkg upgrade" it claims everything is already updated? root@coyote:~# pkg --version 1.5.4 root@coyote:~# pkg upgrade Updating acme repository catalogue... acme repository is up-to-date. All repositories are up-to-date. Checking for upgrades (68 candidates): 100% Processing candidates (68 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. So let's try brute forcing this: root@coyote:~# pkg install `pkg info -aqo` Updating acme repository catalogue... acme repository is up-to-date. All repositories are up-to-date. databases/db48 has no direct installation candidates, change it to db5? [Y/n]: Y Assertion failed: (0), function pkg_jobs_try_remote_candidate, file pkg_jobs.c, line 821. Child process pid=60776 terminated abnormally: Abort trap Exit 250 Using more force: root@coyote:~# pkg upgrade -f db48 Updating acme repository catalogue... acme repository is up-to-date. All repositories are up-to-date. db48 has no direct installation candidates, change it to db5? [Y/n]: y pkg: sqlite error while executing UPDATE packages SET name=?1 WHERE name=?2; in file pkg_jobs.c:1658: UNIQUE constraint failed: packages.name The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: db5: 4.8.30.0_2 -> 5.3.28_2 The process will require 37 MiB more space. 12 MiB to be downloaded. Proceed with this action? [y/N]: y Fetching db5-5.3.28_2.txz: 100% 12 MiB 6.4MB/s00:02 Checking integrity...Assertion failed: (strcmp(uid, p->uid) != 0), function pkg_conflicts_check_local_path, file pkg_jobs_conflicts.c, line 368. Child process pid=60922 terminated abnormally: Abort trap Exit 250 the -debug output has nothing of interest that I can see. What's up? ___ 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: sendmail vs ipv6 broken after upgrade to 9.1
On Wed, 2013-01-09 at 23:42:10 +0900, Hiroki Sato wrote: > Ulrich Spörlein wrote > in <20130109142111.gl35...@acme.spoerlein.net>: > > > On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: > > > On 01/08/2013 23:33, Hiroki Sato wrote: > > > > Ulrich Spörlein wrote > > > >in <20130108184051.gi35...@acme.spoerlein.net>: > > > > > > > > uq> After setting this, it now looks like this: > > > > uq> root@acme: ~# ip6addrctl > > > > uq> Prefix Prec Label Use > > > > uq> ::1/128 50 00 > > > > uq> ::/0 40 10 > > > > uq> 2002::/16 30 20 > > > > uq> ::/96 20 30 > > > > uq> :::0.0.0.0/96 10 40 > > > > uq> > > > > uq> And even sendmail is happily finding the sockets to bind to. Thanks > > > > for the hint! > > > > > > > > I think this just hides the problem. If gshapiro@'s explanation is > > > > correct, no :::0.0.0.0/96 address should be returned if the name > > > > resolution works fine... > > > > > > > > -- Hiroki > > > > > > > > > > getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- > > > > > > If a host has both IPv6 and IPv4 addresses, both are returned. > > > The IPv4 address is presented as a mapped address. > > > The order in which the addresses are returns depends on the > > > address selection policy (_hpreorder in lib/libc/net/name6.c) > > > > Is this also supposed to work for selecting the source IP address for > > outgoing packets/sockets? And should it work for ping6? > > Yes. > > > Using a tunnel for IPv6, I have this transfer net configured on my > > router, but for ACL purposes I would like to have all connections come > > from my real prefix, not the transfer net. So I wrote my own policy, yet > > ping6 seems to ignore it. > > > As you can see, source prefix stays 2a02:2528:ff00, though I'd like it > > to be 2a02:2528:ff0d. > > This is because the prefix on the interface has the first priority. > Why don't you use an fe80::/10 address to route packets to the other > endpoint of tun0? I don't think I have a choice here. To clarify: the sendmail problem is on a server that has native IPv6 connectivity, here I setup my actual prefix as the first address, the address I need to talk to the router is configured as an alias. This works fine. The source address problem I'm now talking about is happening on my router at home, which has a Sixxs tunnel and needs to use AICCU of all things to talk to the outside world, sixxs-aiccu will create the tun(4) interface and set it up like this: tun0: flags=8051 metric 0 mtu 1280 options=8 inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd inet6 2a02:2528:ff00:1b::2 --> 2a02:2528:ff00:1b::1 prefixlen 128 nd6 options=21 Opened by PID 82756 and I'd like to have ipv6 connection originating from this host use 2a02:2528:ff0d::1%em0 instead of 2a02:2528:ff00:1b::2%tun0 as the outgoing address. That tun0 interface can come and go, btw, which complicates things. Is this possible? Or should I just switch to the one local DSL provide I have here that actually offers native IPv6 for home DSL users? Cheers, Uli pgp1mnFAoe1vP.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: > On 01/08/2013 23:33, Hiroki Sato wrote: > > Ulrich Spörlein wrote > >in <20130108184051.gi35...@acme.spoerlein.net>: > > > > uq> After setting this, it now looks like this: > > uq> root@acme: ~# ip6addrctl > > uq> Prefix Prec Label Use > > uq> ::1/128 50 00 > > uq> ::/0 40 10 > > uq> 2002::/16 30 20 > > uq> ::/96 20 30 > > uq> :::0.0.0.0/96 10 40 > > uq> > > uq> And even sendmail is happily finding the sockets to bind to. Thanks for > > the hint! > > > > I think this just hides the problem. If gshapiro@'s explanation is > > correct, no :::0.0.0.0/96 address should be returned if the name > > resolution works fine... > > > > -- Hiroki > > > > getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- > > If a host has both IPv6 and IPv4 addresses, both are returned. > The IPv4 address is presented as a mapped address. > The order in which the addresses are returns depends on the > address selection policy (_hpreorder in lib/libc/net/name6.c) Is this also supposed to work for selecting the source IP address for outgoing packets/sockets? And should it work for ping6? Using a tunnel for IPv6, I have this transfer net configured on my router, but for ACL purposes I would like to have all connections come from my real prefix, not the transfer net. So I wrote my own policy, yet ping6 seems to ignore it. The tunnel: tun0: flags=8051 metric 0 mtu 1280 options=8 inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd inet6 2a02:2528:ff00:1b::2 --> 2a02:2528:ff00:1b::1 prefixlen 128 nd6 options=21 The policy: root@coyote:~# ip6addrctl Prefix Prec Label Use ::1/128 50 00 ::/0 40 1 107 2002::/16 30 20 ::/96 20 30 :::0.0.0.0/96 10 40 2a02:2528:ff0d::/64 60 5 85 The ping: root@coyote:~# ping6 acme PING6(56=40+8+8 bytes) 2a02:2528:ff00:1b::2 --> 2a01:4f8:131:23c2::1 16 bytes from 2a01:4f8:131:23c2::1, icmp_seq=0 hlim=54 time=43.606 ms 16 bytes from 2a01:4f8:131:23c2::1, icmp_seq=1 hlim=54 time=42.871 ms As you can see, source prefix stays 2a02:2528:ff00, though I'd like it to be 2a02:2528:ff0d. Cheers, Uli ___ 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: sendmail vs ipv6 broken after upgrade to 9.1
On Tue, 2013-01-08 at 10:09:20 -0800, Gregory Shapiro wrote:
> > How can I unstupid sendmail here?
>
> I don't think sendmail is being stupid here as it is doing what it has been
> doing under 8.x and 9.1 (the code is the same). I think something changed
> with the upgrade to 9.1. As far as tracking it down, the sendmail code does:
>
> getipnodebyname("acme.spoerlein.net", AF_INET6, AI_DEFAULT|AI_ALL, &err);
>
> This will only return an IPv4 mapped address if:
>
> 1. There are no IPv6 addresses configured on the interfaces. How are your
> IPv6 addresses assigned? If auto-configured (DHCPv6, RTADV), is it possible
> sendmail is being started before autoconfiguration has completed? Restarting
> the MTA after boot and seeing if it still gets the mapped address will say
> whether or not this is the cause.
>
> 2. The query for an record for acme.spoerlein.net failed. This doesn't
> appear to be the case for dns based on your dig output (assuming you ran that
> dig command on the same machine that is exhibiting the problem). However,
> your nsswitch.conf lists hosts before dns and there have been broken name
> resolution implementations that, with 'hosts' listed first in nsswitch.conf
> have given back bad info if the first hostname match didn't have the IPv6
> address. You could try switching the order in /etc/hosts to see if this
> helps. (Note, the broken implementation was not FreeBSD.)
>
> You can also test theory #2 by writing a small C program to do the
> getipnodebyname() call shown above and see what you get. If it gives the
> same bad address, then you need to look outside of sendmail. In the mean
> time, although not optimal, you can work around the issue by using the IPv6
> address instead of the hostname in the Addr= equate.
Turns out it was the missing setting of ip6addrctl_policy="ipv6_prefer"
in rc.conf that also bit me in strange and mysterious ways on another
machine where I did the upgrade. It's very unfortunate that this will
runtime-break sendmail and I honestly don't know why we make ipv4 the
default in this day and age.
Can some IPv6 guru chime in here? This is all thoroughly confusing.
Thanks!
Uli
___
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: sendmail vs ipv6 broken after upgrade to 9.1
On Tue, 2013-01-08 at 18:36:34 +0100, Michiel Boland wrote: > On 01/08/2013 16:18, Ulrich Spörlein wrote: > > Hey, > > > > I upgraded a server running 8.x to 9.1 over the weekend and sendmail no > > longer wants to bind the AF_INET6 sockets. > > > > So while this still works: > > > > DAEMON_OPTIONS(`Port=smtp, Addr=127.0.0.1, Name=MSA, M=Eu, > > InputMailFilters=dkim') > > DAEMON_OPTIONS(`Port=smtp, Addr=::1, Name=MSA, Family=inet6, M=Eu, > > InputMailFilters=dkim') > > > > this is broken: > > > > DAEMON_OPTIONS(`Port=submission, Addr=acme.spoerlein.net, Name=MSA, M=E, > > InputMailFilters=dkim') > > DAEMON_OPTIONS(`Port=submission, Addr=acme.spoerlein.net, Name=MSA, > > Family=inet6, M=E, InputMailFilters=dkim') > > > > which makes me believe this has to do with name resolution... > > > > The actual reported errors are: > > > > Jan 8 16:05:03 acme sm-msp-queue[98057]: starting daemon (8.14.6): > > queueing@00:30:00 > > Jan 8 16:05:03 acme sm-mta[98054]: NOQUEUE: SYSERR(root): > > opendaemonsocket: daemon MSA: cannot bind: Can't assign requested address > > What's the output of the 'ip6addrctl' command on your machine? > > Cheers > Michiel root@acme: ~# ip6addrctl Prefix Prec Label Use :::0.0.0.0/96 50 00 ::1/128 40 10 ::/0 30 272866 2002::/16 20 34 ::/96 10 40 Gah! I remember having to set ip6addrctl_policy="ipv6_prefer" on another system that I upgraded to 9.x a long time ago. After setting this, it now looks like this: root@acme: ~# ip6addrctl Prefix Prec Label Use ::1/128 50 00 ::/0 40 10 2002::/16 30 20 ::/96 20 30 :::0.0.0.0/96 10 40 And even sendmail is happily finding the sockets to bind to. Thanks for the hint! The bigger question now is, why don't we want to have a working IPv6 out of the box? Regards, Uli ___ 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"
sendmail vs ipv6 broken after upgrade to 9.1
Hey,
I upgraded a server running 8.x to 9.1 over the weekend and sendmail no
longer wants to bind the AF_INET6 sockets.
So while this still works:
DAEMON_OPTIONS(`Port=smtp, Addr=127.0.0.1, Name=MSA, M=Eu,
InputMailFilters=dkim')
DAEMON_OPTIONS(`Port=smtp, Addr=::1, Name=MSA, Family=inet6, M=Eu,
InputMailFilters=dkim')
this is broken:
DAEMON_OPTIONS(`Port=submission, Addr=acme.spoerlein.net, Name=MSA, M=E,
InputMailFilters=dkim')
DAEMON_OPTIONS(`Port=submission, Addr=acme.spoerlein.net, Name=MSA,
Family=inet6, M=E, InputMailFilters=dkim')
which makes me believe this has to do with name resolution...
The actual reported errors are:
Jan 8 16:05:03 acme sm-msp-queue[98057]: starting daemon (8.14.6):
queueing@00:30:00
Jan 8 16:05:03 acme sm-mta[98054]: NOQUEUE: SYSERR(root): opendaemonsocket:
daemon MSA: cannot bind: Can't assign requested address
Jan 8 16:05:03 acme sm-mta[98054]: daemon MSA: problem creating SMTP socket
Jan 8 16:05:08 acme sm-mta[98054]: NOQUEUE: SYSERR(root): opendaemonsocket:
daemon MSA: cannot bind: Can't assign requested address
Jan 8 16:05:08 acme sm-mta[98054]: daemon MSA: problem creating SMTP socket
Jan 8 16:05:13 acme sm-mta[98054]: NOQUEUE: SYSERR(root): opendaemonsocket:
daemon MSA: cannot bind: Can't assign requested address
Jan 8 16:05:13 acme sm-mta[98054]: daemon MSA: problem creating SMTP socket
This will loop a couple of times, but not make any progress. ktrace will show
what's up:
98054 sendmail CALL bind(0x6,0x708c14,0x10)
98054 sendmail STRU struct sockaddr { AF_INET, 88.198.49.12:587 }
98054 sendmail RET bind 0
98054 sendmail CALL socket(PF_INET6,SOCK_STREAM,IPPROTO_IP)
98054 sendmail RET socket 7
98054 sendmail CALL setsockopt(0x7,SOL_SOCKET,SO_REUSEADDR,0x7fffafa4,0x4)
98054 sendmail RET setsockopt 0
98054 sendmail CALL setsockopt(0x7,SOL_SOCKET,SO_KEEPALIVE,0x7fffafa4,0x4)
98054 sendmail RET setsockopt 0
98054 sendmail CALL fcntl(0x7,F_GETFD,0)
98054 sendmail RET fcntl 0
98054 sendmail CALL fcntl(0x7,F_SETFD,FD_CLOEXEC)
98054 sendmail RET fcntl 0
98054 sendmail CALL bind(0x7,0x708dbc,0x1c)
98054 sendmail STRU struct sockaddr { AF_INET6, [:::88.198.49.12]:587 }
98054 sendmail RET bind -1 errno 49 Can't assign requested address
Yeah right ... I don't want an IPv6-mapped-IPv4 address, I want it to bind to
the real thing.
/etc/nsswitch.conf has
hosts: files dns
and /etc/hosts has
root@acme: /etc/mail# grep acme /etc/hosts
88.198.49.12acme.spoerlein.net acme
2a01:4f8:131:23c2::1acme.spoerlein.net acme
Which shouldn't make a difference anyway, because of:
root@acme: /etc/mail# dig acme.spoerlein.net a +short; dig acme.spoerlein.net
+short
88.198.49.12
2a01:4f8:131:23c2::1
How can I unstupid sendmail here?
Uli
___
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 zcat uncompressing man pages
On Tue, 2012-09-25 at 12:58:01 +0100, Jamie Paul Griffin wrote: > Hi > > When I read 'certain' -- not all -- man pages zcat writes a small error to > stderr when opening the man page; however, the man page does actually open. > The message i get on the terminal is: > > zcat: error writing to output: Broken pipe > zcat: /usr/local/man/man5/muttrc.5.gz: uncompress failed > > When closing the man page, another message is shown on stderr: > > grotty: ():54131:fatal error: output > error > > > Would anyone here know the possible cause and fix for this issue? Well, what is /usr/local/man/man5/muttrc.5.gz? ls -l /usr/local/man/man5/muttrc.5.gz file /usr/local/man/man5/muttrc.5.gz zcat /usr/local/man/man5/muttrc.5.gz | head -5 xxd /usr/local/man/man5/muttrc.5.gz | head It looks like you simple have a garbled manpage, and the catpage is displayed instead. Cheers Uli ___ 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: stable/9 preferring IPv4 over IPv6, what changed?
On Sun, 2011-12-11 at 23:52:33 +0100, Dimitry Andric wrote:
> On 2011-12-11 23:33, Ulrich Spörlein wrote:
> > long story short: telnet foo on stable/8 will first try connecting via
> > IPv6, then via IPv4 (foo has A and records). On stable/9 it's the
> > other way round.
> >
> > This trips up my setup, where a bunch of hosts (some behind NAT) can all
> > talk to each other over their IPv6 addresses (some are tunneled), but
> > cannot do so via IPv4.
> >
> > Is this due to changes in bind or the resolver?
>
> Most likely due to changes in the IPv6 startup scripts and rc.conf
> settings. The behaviour seems to be determined by multiple settings in
> rc.conf, first of all:
>
> ip6addrctl_policy={ipv4_prefer|ipv6_prefer|AUTO}
>
> where the default value is AUTO. Values of ipv4_prefer and ipv6_prefer
> do what you expect them to.
>
> In case of AUTO, and if you don't have /etc/ip6addrctl.conf with
> explicit settings, /etc/rc.d/ip6addrctl checks the value of
> ipv6_activate_all_interfaces. If it is YES, IPv6 is preferred, if it is
> NO or unset, IPv4 is preferred.
>
> What are your IPv6-related settings in rc.conf?
Well, I had ipv6_enable set from the stable/8 days. The warnings and the
code make me believe it should behave as if ipv6_activate_all_interfaces
was set, somehow that's not the case, though.
I've now set ip6addrctl_policy and everything is back working again.
Thanks!
Uli
___
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"
stable/9 preferring IPv4 over IPv6, what changed?
Hello long story short: telnet foo on stable/8 will first try connecting via IPv6, then via IPv4 (foo has A and records). On stable/9 it's the other way round. This trips up my setup, where a bunch of hosts (some behind NAT) can all talk to each other over their IPv6 addresses (some are tunneled), but cannot do so via IPv4. Is this due to changes in bind or the resolver? Cheers, Uli ___ 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: Network throughput: Never get more than 112MB/s über two NICs
On Mon, 11.04.2011 at 12:00:39 +0200, Denny Schierz wrote: > hi, > > after testing severals loadbalancing (LACP) types with Cisco, we saw, > that we never get more than 112MB/s with two network cards and iperf. > > So, we tested without loadbalancing, 4 Clients (iperf -f M -c ) and > two target IPs. Every IP has his own 1Gb/s network card. > On the end, two clients had a connection to IP 1 and the second two to > IP 2. > > First we used the two onboard NICs and then, one onboard and one > external NIC, but without success. We never get more then 112MB/s > > All are connected through a Cisco Catalyst WS-X4515. > > The mainboard is a Intel S3420GP. Are the NICs PCI or PCIe? If the former, IIRC the PCI bus bandwidth maxes out at 133MB/s so that might explain your numbers. If your NICs are PCIe, I have no helpful clues, sorry. Uli ___ 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: RFC vgrind in base (and buildworld)
On Thu, 20.01.2011 at 21:17:40 +0100, Ulrich Spörlein wrote: > Hello, > > Currently our buildworld relies on groff(1) and vgrind(1) being present > in the host system. I have a patch ready that at least makes sure these > are built during bootstrap-tools and completes the WITHOUT_GROFF flag. > > vgrind(1) is only used for two papers under share/doc and we could > easily expand the results and commit them to svn directly, alleviating > the need to run vgrind(1) during buildworld. > > OTOH, there are much more useful tools to vgrind(1) for source code > formatting. So do we still have vgrind(1) users out there? > > Regards, > Uli [trying to get this thread back on track] Does anyone actually care about vgrind in base? Will people be angry if I unroll the 2 cases where it is used under share/doc? Regards, Uli ___ 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: RFC vgrind in base (and buildworld)
On Thu, 20.01.2011 at 15:31:03 -0500, Alexander Kabaev wrote:
> On Thu, 20 Jan 2011 21:17:40 +0100
> Ulrich Spörlein wrote:
>
> > Hello,
> >
> > Currently our buildworld relies on groff(1) and vgrind(1) being
> > present in the host system. I have a patch ready that at least makes
> > sure these are built during bootstrap-tools and completes the
> > WITHOUT_GROFF flag.
> >
> > vgrind(1) is only used for two papers under share/doc and we could
> > easily expand the results and commit them to svn directly, alleviating
> > the need to run vgrind(1) during buildworld.
> >
> > OTOH, there are much more useful tools to vgrind(1) for source code
> > formatting. So do we still have vgrind(1) users out there?
> >
> > Regards,
> > Uli
>
> Why it needs to be in bootsrap tools at all? We have build tools for
> this exact purpose.
Because the legacy target has the nice semantics of calling a tool's
obj,depend,all,install targets instead of doing only `all' or
`build-tool'.
We also currently set GROFF_BIN_PATH, GROFF_FONT_PATH, and
GROFF_TMAC_PATH to point to ${WORLDTMP}/legacy/... so it was trivial to
get groff working that way. I don't know the history of why we actually
do this for groff (it is broken currently), therefore I simply
piggy-backed onto that solution.
I forgot the link earlier:
https://www.spoerlein.net/cgit/cgit.cgi/freebsd.work/log/?h=groff
I wish there was an easy way to cleanly have this as a build-tool. While
we're at it: strfile similarly should be moved to a build-tool, not a
bootstrap-tool, as it is also only used to as a pre-requisite to
building fortune(6).
If someone can come up with a policy of what should go where, I'll
happily try to shoehorn the groff/vgrind/strfile things into it ...
Uli
pgpX0sUmqYxC3.pgp
Description: PGP signature
RFC vgrind in base (and buildworld)
Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli ___ 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: tmpfs regression in recent -STABLE
On Mon, 10.01.2011 at 16:49:14 -0500, John Baldwin wrote: > On Monday, January 10, 2011 4:40:04 pm Ulrich Spörlein wrote: > > Hey, > > > > the following line in fstab used to work just fine for my /tmp: > > > > tmpfs /tmptmpfs rw,size=1g,mode=17770 0 > > I thought there was a thread recently about tmpfs not supporting things like > "1g" for size? Nah, this must be some leak of another kind. Luckily I could bandaid this by unionfs mounting an mfs disk over /tmp so programs continue to run. But, tmpfs really is out of resources, as I cannot create new tmpfs's for example: r...@elmar: ~# mount -t tmpfs tmpfs /media mount: tmpfs : No space left on device And besides, the /tmp mount comes up fine and shows enough free space (I checked this the last time, after I had rebooted the box). Cheers, Uli ___ 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"
tmpfs regression in recent -STABLE
Hey, the following line in fstab used to work just fine for my /tmp: tmpfs /tmptmpfs rw,size=1g,mode=17770 0 But since I upgraded to 8.2-PRERELEASE, /tmp will soon run out of space (usually after leaving the box overnight). % df /tmp Filesystem 1K-blocks Used Avail Capacity Mounted on tmpfs 12 12 0 100%/tmp Yes, what you see here, is not "stuff" filling up the /tmp partition, *BUT* the /tmp partition shrinking to a ridiculous size. /tmp only has the usual stuff on it, as I can now no longer create temporary files there: % du /tmp 4 /tmp/.X11-unix 0 /tmp/.XIM-unix 0 /tmp/.ICE-unix 0 /tmp/.font-unix 4 /tmp/ssh-tEgl0QxQHp 4 /tmp/ksocket-uqs 12 /tmp/kde-uqs 4 /tmp/fam-uqs 8 /tmp/.vbox-uqs-ipc 0 /tmp/worker-uqs 44 /tmp Anything I could try? Uli ___ 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"
Are there digi(4) users running -STABLE? (was Re: Migrating ISA/PCI drivers)
[cross-posting to stable@, where some of those folk might hang out] On Fri, 19.11.2010 at 09:21:00 +1100, Peter Jeremy wrote: > I'm (belatedly) looking at porting digi(4) to the MPSAFE TTY system > and have some architectural questions. > > The digi(4) driver appears to support 5 different Digi card variants, > at least two of which exist in both ISA and PCI variants. Looking at > the Digi website, it appears that both PCI and ISA cards are still > available (as well as a PCIe card which is unlikely to work with the > current driver). I only have access to PCI/Xem cards and so can't > test my changes on any other card types. I presume Digi cards are not > that popular because noone else has shown any interest in the driver > since the MPSAFE TTY changes were announced about 2.5 years ago. > > How much effort should I invest in adapting code for other card types? > In particular, the ISA cards use windowed memory accesses and IO ports > where the PCI cards have a single flat memory aperture. Removing > support for ISA cards would simplify the code (and remove the need to > make decisions about whether I need to do window switches in new > code), as well as potentially allowing finer grained locks. > > My options would seem to be: > 1) Rip out the ISA support - this is the cleanest for me but maximises >effort for a future person wanting to support ISA Digi cards. > 2) Carry forward the ISA code as best I can and ensure new code includes >appropriate window switches etc. This maximises my effort but >hopefully makes it easier for someone to get ISA cards working. > 3) Ignore the ISA code. This is fairly easy but probably requires >similar effort to (1) to get it going on ISA since all the code >would need to be reviewed to add necessary ISA-specific locking/ >window switching. > > My preference is 1 since it leaves the least cruft (from my point of > view) in the code and doesn't give users the false impression that > ISA cards work. > > I would appreciate some advice on the best way forward. In the > absence of any input, I will probably stick with option 3 for now but > may move to option 1 if the ISA code starts getting in the way. Keep > in mind that digi(4) does not currently compile on FreeBSD-8 or later, > so any of the above options are an improvement over the status quo, > though all are a regression from FreeBSD-7. > > Of course, if someone has access to other Digi card types and wants > to assist with porting and testing, I would be happy to work with them. > > -- > Peter Jeremy ___ 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: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Mon, 15.11.2010 at 18:03:25 -0800, Pyun YongHyeon wrote: > On Sun, Nov 14, 2010 at 10:41:03AM +0100, Ulrich Sp??rlein wrote: > > On Mon, 08.11.2010 at 22:41:12 +0100, Ulrich Sp??rlein wrote: > > > On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > > > > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > > > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > > > > wrote: > > > > > > > Hello Pyun, > > > > > > > > > > > > > > On this new server, I cannot get more than ~280kByte/s > > > > > > > up/downstream out of > > > > > > > re(4) without any tweaking. > > > > > > > > > > > > > > re0: flags=8843 metric 0 > > > > > > > mtu 1500 > > > > > > > ?? ?? ?? > > > > > > > ??options=389b > > > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 > > > > > > > scopeid 0x1 > > > > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast > > > > > > > 46.4.12.191 > > > > > > > ?? ?? ?? ??nd6 options=3 > > > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > > > > ?? ?? ?? ??status: active > > > > > > > > > > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > > > > also agree on the resolved speed/duplex? > > > > > > > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > > > > means to check this easily. Especially I cannot change the setting > > > > > from > > > > > auto-neg. Btw, linux will show a negotiated 100/full link via > > > > > mii-tool. > > > > > > > > > > > > > I guess you can contact network administrator of the data center to > > > > check the switch configuration. IEEE 802.3 says if link parter use > > > > forced full-duplex media and you use auto media, the resolved > > > > duplex is half-duplex by definition. I think RealTek may have > > > > followed the standard. There is no reason to use manual media > > > > configuration unless your link partner is severely broken with > > > > auto-negotiation. > > > > > > > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > > > > auto-negotiation so manual media configuration is a kind of > > > > auto-negotiation with limited set of available media advertising. > > > > I don't know how Linux solve the silicon bug though. One of magic > > > > DSP fixups might fix the issue, the DSP fixups vendor released is > > > > not under BSD license and does not say more detailed information > > > > for the code. > > > > > > Luckily the provider switch me to another switch that is set to > > > autoneg, instead of hardcoded to 100/full. re(4) now happily transfers > > > with reasonable speeds, ie. 11MByte/s. > > > > Alas, spoken too soon. While the throughput is now up to speed, I have > > severe problems with packet loss on this device. Again, the linux rescue > > system works fine, but under a recent -STABLE (including your latest > > MFCs) I get an average packet loss of 10-20%. But it is not constant, > > meaning every 5th packet or so, but instead will drop no packets for > > minutes-hours and then blackout for 1-5 min straight (these times are > > estimates, I haven't used a stop watch or anything.) > > > > At first, putting the card into promisc mode seemed to alleviate the > > issue, but the average ping packet loss during the last 10h was again up > > to 10%. Due to the "blackout" nature, this drops all TCP sessions and is > > really annoying. > > > > Do you have any other ideas that I could try? Or should I simply switch > > to a different hardware altogether? > > > > Could you try latest re(4) in HEAD? It has a new feature that > displays hardware MAC counters and it contains a couple of PHY > access enhancements. You would get the MAC counters on console with > "sysctl dev.re.0.stats=1". And let me know how many frames were > dropped. This is very weird, I managed to narrow it down to IPv4 forwarding, that is making the box unreachable for certain periods. One the server, I did: # sysctl net.inet.ip.forwarding=1; sleep 7200; sysctl net.inet.ip.forwarding=0 And on a client, I did: # ping -c 7200 ... 7200 packets transmitted, 5269 packets received, 26.8% packet loss round-trip min/avg/max/stddev = 5.386/23.155/64.633/21.594 ms I have a couple of virtual interfaces, gif, tun (openvpn) and pf(4) running on that box, but no routing daemons or anything. I also had an IPv6 ping running simultaneously (using net/mtr) and this is showing me ~0% packet loss over IPv6 (net.inet6.ip6.forwarding is set, but this does not exhibit the problem). Now I had this very same software setup running on another box without any blackouts, so I'm wondering what the re(4) hardware would have to do with IPv4 forwarding. Next up, I'm going to test if net.inet.ip.fastforwarding exhibits the same blackouts. I will also take down all other interfaces, pf and openvpn and see if I can make any sense of this.
Re: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Mon, 08.11.2010 at 22:41:12 +0100, Ulrich Spörlein wrote: > On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > > wrote: > > > > > Hello Pyun, > > > > > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream > > > > > out of > > > > > re(4) without any tweaking. > > > > > > > > > > re0: flags=8843 metric 0 mtu > > > > > 1500 > > > > > ?? ?? ?? > > > > > ??options=389b > > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > > > ?? ?? ?? ??nd6 options=3 > > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > > ?? ?? ?? ??status: active > > > > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > > also agree on the resolved speed/duplex? > > > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > > means to check this easily. Especially I cannot change the setting from > > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > > > > > > I guess you can contact network administrator of the data center to > > check the switch configuration. IEEE 802.3 says if link parter use > > forced full-duplex media and you use auto media, the resolved > > duplex is half-duplex by definition. I think RealTek may have > > followed the standard. There is no reason to use manual media > > configuration unless your link partner is severely broken with > > auto-negotiation. > > > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > > auto-negotiation so manual media configuration is a kind of > > auto-negotiation with limited set of available media advertising. > > I don't know how Linux solve the silicon bug though. One of magic > > DSP fixups might fix the issue, the DSP fixups vendor released is > > not under BSD license and does not say more detailed information > > for the code. > > Luckily the provider switch me to another switch that is set to > autoneg, instead of hardcoded to 100/full. re(4) now happily transfers > with reasonable speeds, ie. 11MByte/s. Alas, spoken too soon. While the throughput is now up to speed, I have severe problems with packet loss on this device. Again, the linux rescue system works fine, but under a recent -STABLE (including your latest MFCs) I get an average packet loss of 10-20%. But it is not constant, meaning every 5th packet or so, but instead will drop no packets for minutes-hours and then blackout for 1-5 min straight (these times are estimates, I haven't used a stop watch or anything.) At first, putting the card into promisc mode seemed to alleviate the issue, but the average ping packet loss during the last 10h was again up to 10%. Due to the "blackout" nature, this drops all TCP sessions and is really annoying. Do you have any other ideas that I could try? Or should I simply switch to a different hardware altogether? Regards, Uli ___ 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: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sun, 07.11.2010 at 15:10:20 -0800, Pyun YongHyeon wrote: > On Sun, Nov 07, 2010 at 12:24:21PM +0100, Ulrich Sp??rlein wrote: > > On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > > > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Sp??rlein > > > wrote: > > > > Hello Pyun, > > > > > > > > On this new server, I cannot get more than ~280kByte/s up/downstream > > > > out of > > > > re(4) without any tweaking. > > > > > > > > re0: flags=8843 metric 0 mtu > > > > 1500 > > > > ?? ?? ?? > > > > ??options=389b > > > > ?? ?? ?? ??ether 00:21:85:63:74:34 > > > > ?? ?? ?? ??inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > > > ?? ?? ?? ??inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > > > ?? ?? ?? ??nd6 options=3 > > > > ?? ?? ?? ??media: Ethernet autoselect (100baseTX ) > > > > ?? ?? ?? ??status: active > > > > > > > > > > It seems the link was resolved to half-duplex. Does link partner > > > also agree on the resolved speed/duplex? > > > > As this is a dedicated server in a colo hundreds of km away, I have no > > means to check this easily. Especially I cannot change the setting from > > auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > > > I guess you can contact network administrator of the data center to > check the switch configuration. IEEE 802.3 says if link parter use > forced full-duplex media and you use auto media, the resolved > duplex is half-duplex by definition. I think RealTek may have > followed the standard. There is no reason to use manual media > configuration unless your link partner is severely broken with > auto-negotiation. > > Due to silicon bug of RealTek PHYs, rgephy(4) always use > auto-negotiation so manual media configuration is a kind of > auto-negotiation with limited set of available media advertising. > I don't know how Linux solve the silicon bug though. One of magic > DSP fixups might fix the issue, the DSP fixups vendor released is > not under BSD license and does not say more detailed information > for the code. Luckily the provider switch me to another switch that is set to autoneg, instead of hardcoded to 100/full. re(4) now happily transfers with reasonable speeds, ie. 11MByte/s. Thanks! Uli ___ 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: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sat, 06.11.2010 at 23:19:33 -0700, Pyun YongHyeon wrote: > On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Spörlein wrote: > > Hello Pyun, > > > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > > re(4) without any tweaking. > > > > re0: flags=8843 metric 0 mtu 1500 > > > > options=389b > > ether 00:21:85:63:74:34 > > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > nd6 options=3 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > It seems the link was resolved to half-duplex. Does link partner > also agree on the resolved speed/duplex? As this is a dedicated server in a colo hundreds of km away, I have no means to check this easily. Especially I cannot change the setting from auto-neg. Btw, linux will show a negotiated 100/full link via mii-tool. > > # ifconfig re0 > > re0: flags=8843 metric 0 mtu 1500 > > options=88 > > ether 00:21:85:63:74:34 > > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > > nd6 options=3 > > media: Ethernet 100baseTX (100baseTX ) > > status: active > > > > This time, it seems you used forced media configuration > instead of auto. It still shows duplex mismatch so it's > normal to see poor performance. What makes me wonder > is why you have duplex mismatch? > Did you use forced media configuration on link partner? > What happens when you use different switch? Sadly, none of these options are available to me :/ But even 100/half should give more than enough performance, right? Uli ___ 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: Abysmal re(4) performance under 8.1-STABLE (mid-August)
On Sat, 06.11.2010 at 10:37:00 +0100, Ulrich Spörlein wrote: > Hello Pyun, > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > re(4) without any tweaking. > > re0: flags=8843 metric 0 mtu 1500 > > options=389b > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet autoselect (100baseTX ) > status: active > > r...@pci0:2:0:0: class=0x02 card=0x368c1462 chip=0x816810ec rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet One more datapoint, I know that this (newer) revision r...@pci0:6:0:0: class=0x02 card=0x75221462 chip=0x816810ec rev=0x02 hdr=0x00 is working just fine in another system/board. > re0: port > 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x3800 > re0: MAC rev. 0x > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:21:85:63:74:34 > re0: [FILTER] > > > It's interesting to note, that re0 only negotiates half-duplex, where > linux will negotiate full-duplex (and gets ~10MByte/s as expected). > > Next, I disabled almost all options, except that I cannot disable > VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. > > # ifconfig re0 -vlanmtu > # ifconfig re0 -vlanhwcsum > ifconfig: -vlanhwcsum: bad value > # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > options=88 > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet 100baseTX (100baseTX ) > status: active > > If I then immediately start the test-download, I get a ~2MByte/s spike, > which quickly returns to something around 250kByte/s. > > Booting with > hw.pci.enable_msix=0 > hw.pci.enable_msi=0 > > I can get almost up to 400kByte/s, but this may be coincidence. > > So this is usually as far as it gets: > > re0 in190.504 KB/s246.136 KB/s 66.709 MB > out10.290 KB/s 12.985 KB/s6.076 MB > > But then I ran tcpdump in another session, and it looks like the ssh traffic > on > the upstream of the interface will make the downloads running in another > window > go faster: > > re0 in805.961 KB/s 1.577 MB/s 116.523 MB > out 222.940 KB/s502.045 KB/s 19.267 MB > > Any ideas? > > Uli > ___ > 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" ___ 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"
Abysmal re(4) performance under 8.1-STABLE (mid-August)
Hello Pyun, On this new server, I cannot get more than ~280kByte/s up/downstream out of re(4) without any tweaking. re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:21:85:63:74:34 inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active r...@pci0:2:0:0: class=0x02 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:21:85:63:74:34 re0: [FILTER] It's interesting to note, that re0 only negotiates half-duplex, where linux will negotiate full-duplex (and gets ~10MByte/s as expected). Next, I disabled almost all options, except that I cannot disable VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. # ifconfig re0 -vlanmtu # ifconfig re0 -vlanhwcsum ifconfig: -vlanhwcsum: bad value # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=88 ether 00:21:85:63:74:34 inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 inet 46.4.12.147 netmask 0xffc0 broadcast 46.4.12.191 nd6 options=3 media: Ethernet 100baseTX (100baseTX ) status: active If I then immediately start the test-download, I get a ~2MByte/s spike, which quickly returns to something around 250kByte/s. Booting with hw.pci.enable_msix=0 hw.pci.enable_msi=0 I can get almost up to 400kByte/s, but this may be coincidence. So this is usually as far as it gets: re0 in190.504 KB/s246.136 KB/s 66.709 MB out10.290 KB/s 12.985 KB/s6.076 MB But then I ran tcpdump in another session, and it looks like the ssh traffic on the upstream of the interface will make the downloads running in another window go faster: re0 in805.961 KB/s 1.577 MB/s 116.523 MB out 222.940 KB/s502.045 KB/s 19.267 MB Any ideas? Uli ___ 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: bsnmpd returns incorrect hrProcessorLoad values
On Wed, 03.02.2010 at 19:50:26 +0100, Gustau Pérez wrote:
> En/na Mikolaj Golub ha escrit:
> > On Fri, 29 Jan 2010 12:37:52 +0100 Gustau Pérez wrote:
> >
> >
> >> Hi,
> >>
> >> I'm using cacti to monitor some servers running FBSD. I was using 7.2
> >> with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was
> >> returning right values for the cores' load.
> >>
> >>I recently updated the servers (via csup) to RELENG_8 and bsnmpd is
> >> returning negative values for the cores' load. If I try something like
> >> in a 4-core system :
> >>
> >> snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1
> >>
> >>what I get is :
> >>
> >> .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0
> >> .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0
> >> .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0
> >> .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0
> >> .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182
> >> .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182
> >> .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182
> >> .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182
Guys,
can you please try the attached patch? I haven't yet tried it on an UP
system but it should mostly work. It is not finished though.
Regards,
Uli
Index: usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c
===
--- usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c (revision 208628)
+++ usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c (working copy)
@@ -63,6 +63,7 @@
/* the samples from the last minute, as required by MIB */
double samples[MAX_CPU_SAMPLES];
+ long states[MAX_CPU_SAMPLES][CPUSTATES];
/* current sample to fill in next time, must be < MAX_CPU_SAMPLES */
uint32_t cur_sample_idx;
@@ -112,6 +113,43 @@
return ((int)floor((double)sum/(double)e->sample_cnt));
}
+static int
+get_avg_usage(struct processor_entry *e)
+{
+ u_int i, oldest;
+ long delta = 0;
+ double load = 0.0;
+
+ assert(e != NULL);
+
+ /* Need two samples to perform delta calculation */
+ if (e->sample_cnt <= 1)
+ return (0);
+
+ /* oldest usable index */
+ if (e->sample_cnt == MAX_CPU_SAMPLES)
+ oldest = (e->cur_sample_idx + 1) % MAX_CPU_SAMPLES;
+ else
+ oldest = 0;
+
+ /* FIXME handle wrap around */
+ for (i = 0; i < CPUSTATES; i++) {
+ delta += e->states[e->cur_sample_idx][i];
+ delta -= e->states[oldest][i];
+ }
+ if (delta == 0)
+ return 0;
+
+ /* XXX idle time is in the last index always?!? */
+ load = (double)(e->states[e->cur_sample_idx][CPUSTATES-1] -
+ e->states[oldest][CPUSTATES-1]) / delta;
+ load = 100 - (load*100);
+ HRDBG("CPU no. %d delta ticks %ld pct usage %.2f", e->cpu_no,
+ delta, load);
+
+ return (floor(load));
+}
+
/*
* Stolen from /usr/src/bin/ps/print.c. The idle process should never
* be swapped out :-)
@@ -132,11 +170,15 @@
* Save a new sample
*/
static void
-save_sample(struct processor_entry *e, struct kinfo_proc *kp)
+save_sample(struct processor_entry *e, struct kinfo_proc *kp, long *cp_times)
{
+ int i;
+ for (i = 0; cp_times != NULL && i < CPUSTATES; i++)
+ e->states[e->cur_sample_idx][i] = cp_times[i];
+
e->samples[e->cur_sample_idx] = 100.0 - processor_getpcpu(kp);
- e->load = get_avg_load(e);
+ e->load = get_avg_usage(e);
e->cur_sample_idx = (e->cur_sample_idx + 1) % MAX_CPU_SAMPLES;
if (++e->sample_cnt > MAX_CPU_SAMPLES)
@@ -241,8 +283,6 @@
entry->idle_pid = kp->ki_pid;
HRDBG("CPU no. %d with SNMP index=%d has idle PID %d",
entry->cpu_no, entry->index, entry->idle_pid);
-
- save_sample(entry, kp);
}
}
@@ -386,12 +426,22 @@
refresh_processor_tbl(void)
{
struct processor_entry *entry;
- int need_pids;
+ int need_pids, nproc;
struct kinfo_proc *plist;
- int nproc;
+ size_t size;
processor_refill_tbl();
+ long pcpu_cp_times[hw_ncpu * CPUSTATES];
+ memset(pcpu_cp_times, 0, sizeof(pcpu_cp_times));
+
+ size = hw_ncpu * CPUSTATES * sizeof(long);
+ /* FIXME: assert entry->ncpu <= hw_ncpu <= length of cp_times */
+ if (sysctlbyname("kern.cp_times", pcpu_cp_times, &size, NULL, 0) == -1) {
+ syslog(LOG_ERR, "hrProcessorTable: sysctl(kern.cp_times) failed");
+ return;
+ }
+
need_pids = 0;
TAILQ_FOREACH(entry, &processor_tbl, link) {
if (entry->idle_pid <= 0) {
@@ -410,7 +460,7 @@
need_pids = 1;
continue;
}
- save_sample(entry, plist);
+ save_sample(entry, plist, &pcpu_cp_times[entry->cpu_no * CPUSTATES]);
}
if (need_pids == 1)
Index: usr.sbin/bsnmpd/modules/snmp_hostres/Makefile
===
--- usr.sbin/bsnmpd/modules/snmp_hostres/Makefile (revision 208628)
+++ usr.sbin/bsnmpd/modules/snmp_hostres/Makefile (working copy)
@@ -48,7 +48,8 @@
printcap.c
#Not having NDEBUG defined will enable assertions and a lot of output on stderr
-CFLAGS+= -DNDEBUG -I${LPRSRC}
+WARNS?= 1
+CFLAGS+= -I${LPRSRC}
XSYM= host hrStorageOther hrStorageRam hrStorageVirtualMemory \
hrS
Re: Any chance of someone commiting the patch in bin/131861 ?
On Fri, 14.05.2010 at 10:17:23 +0100, Pete French wrote: > > > Postfix will re-write this as part of sanitization, so I had to revert > > to creating mbox files by hand. Anyway, could you please test the > > following patch with a wider variety of mails? > > I've been testing your patch for a few weeks now as my main email > client, and I havent encountered any problems - it also does fix > the reply issues I was originally having. Do you want to attach it > to the PR ? After that maybe someone could commit it - I am pretty > certain it doesnt actualy break any exising behaviour. > > cheers, > > -pete. I'll try to get review by some fellow FreeBSD dev that is more familiar with our mail(1) history and then commit the changed eventually. Do you feel strongly about merging the fix to 8 or 7 or both? Regards, Uli ___ 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: Any chance of someone commiting the patch in bin/131861 ?
On Wed, 14.04.2010 at 15:38:21 +0100, Pete French wrote:
> > Sorry Pete, but the patch still seems incomplete. You merely catch the
> > case when a comma is followed by space or quotation marks, but the email
> > header might look like this:
> > To: f...@domain.com,b...@otherdomain.com
>
> I think the original code handles cases like that fine, my patch merely
> looks for an extra possibility. I've just tested it with the
> above, and it works.
>
> Can you give me an example of one which doesn't work for you ? Either
> in the original /usr/bin/mail or in my patched version ?
Well, the following header didn't work:
Cc: ,
Postfix will re-write this as part of sanitization, so I had to revert
to creating mbox files by hand. Anyway, could you please test the
following patch with a wider variety of mails?
commit 59a3e2a82bdeafb7bb46e8d5c39dcb2474d7f826
Author: Ulrich Spörlein
Date: Wed Apr 14 17:07:10 2010 +0200
bin/131861: [patch] mail(1) misses addresses when replying to all
There's a parsing error for fields where addresses are not separated by
space. This is often produced by MS Outlook, eg.:
Cc: ,"Mr Foo"
The following line now splits into the right tokens:
Cc: f...@b.com,z...@y.de, ,, "foo" ,"bar"
diff --git a/usr.bin/mail/util.c b/usr.bin/mail/util.c
index df2d840..af962c8 100644
--- a/usr.bin/mail/util.c
+++ b/usr.bin/mail/util.c
@@ -496,10 +496,11 @@ skin(name)
*cp2++ = ' ';
}
*cp2++ = c;
- if (c == ',' && *cp == ' ' && !gotlt) {
+ if (c == ',' && !gotlt &&
+ (*cp == ' ' || *cp == '"' || *cp == '<')) {
*cp2++ = ' ';
-while (*++cp == ' ')
- ;
+while (*cp == ' ')
+ cp++;
lastsp = 0;
bufend = cp2;
}
___
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: Any chance of someone commiting the patch in bin/131861 ?
On Wed, 14.04.2010 at 14:45:55 +0100, Pete French wrote: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/131861 > > I've been using the patch now for a couple of months with no > observable problems. It is very small, and does fix a real > annoyance with using /usr/bin/mail as your primary mail > reader. I realise this is probably a very small number of > people, but it wudlbe nice to get it committed if possible... > > cheers, > > -pete. [resolutely sticking to the command line even in 2010! :-)] Sorry Pete, but the patch still seems incomplete. You merely catch the case when a comma is followed by space or quotation marks, but the email header might look like this: To: f...@domain.com,b...@otherdomain.com Regards, Uli ___ 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: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: > On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: > > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > > > I have a strong suspicion that the issue is with bus_dma. If this is a > > > pci based card, then it is trying to allocate 32MB of contiguous > > > physical ram when the drm device is opened. This usually succeeds the > > > first time that the driver opens the device, but later, after memory has > > > become fragmented, this can become an issue. As I have mentioned, I > > > have code that reworks this whole process and I'll try and make a patch > > > available soon, but my I don't have a lot of time now, so it might be > > > the weekend before I can rebase the code and get a clean patch. > > > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE > > without > > the recent Xorg update (haven't done that yet) I usually startx right after > > boot, and this usually works fine. > > > > One time I had massive ZFS/git jobs running headless first and wanted to > > startx afterwards. X11 took quite some time to come up and although > > window "switching" was snappy, *moving* windows around was slow as hell, > > window contents were re-drawing at ~1FPS. > > > > This also seems to always happen if I stop X11 and startx it again. > > So I made a diff from a regular Xorg startup against the slow one: > > > > --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 > > +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 > > ... > > @@ -599,49 +599,22 @@ > > (II) RADEON(0): [drm] added 1 reserved context for kernel > > (II) RADEON(0): X context handle = 0x1 > > (II) RADEON(0): [drm] installed DRM signal handler > > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 > > -(II) RADEON(0): [pci] ring handle = 0xed1a5000 > > -(II) RADEON(0): [pci] Ring mapped at 0x802aa > > -(II) RADEON(0): [pci] Ring contents 0x > > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 > > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 > > -(II) RADEON(0): [pci] Ring read ptr contents 0x > > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 > > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 > > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x > > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 > > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 > > -(II) RADEON(0): [drm] register handle = 0xfe8e > > -(II) RADEON(0): [dri] Visual configs initialized > > +(EE) RADEON(0): [pci] Out of memory (-12) > > Yes, drm failed to allocate the 32MB to back the GART, so drm was > disabled. Hopefully, the new allocation strategy will resolve this > since it will just require 32MB of physical ram below 4GB without > needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... But it's your call, you obviously know more about this than me anyway :) Bye, Uli ___ 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: numeric sort(1) is broken on -STABLE
On Wed, 10.02.2010 at 15:00:07 -0600, Dan Nelson wrote: > In the last episode (Feb 10), Ulrich Spörlein said: > > On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > > > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > > > > > It somehow does not manifest when using a simple list and sorting on a > > > > specific column, but it always happens to me when using it in > > > > combination with find(1). > > > > > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > > > % find a b c -ls|sort -nk7,7 > > > > 8 64 -rw-r--r--1 uqs wheel > > > > 10485760 Feb 10 09:13 a > > > > 10 64 -rw-r--r--1 uqs wheel > > > > 5242880 Feb 10 09:13 b > > > > 12 64 -rw-r--r--1 uqs wheel > > > > 819200 Feb 10 09:13 c > > > > > > I bet you're using some non-C locale for LC_NUMERIC. What does "locale" > > > output tell you? > > > > Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as > > there are no non-ASCII symbols in that output it shouldn't matter, right? > > For me, 819200 is smaller than 10485760 in pretty much all locales. Why > > the hell is a numeric gnusort locale dependant? Why is -g working anyway? > > Try adding a 'b' to your sort flags. I bet the leading spaces in front of > your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 > and C have different ideas of what is whitespace? Indeed, 'b' is working too. So I've stocked up on the number of workarounds for this problem. What amazes me, is that no one seems to be as shocked as I to find out something basic like sorting on a number is not DTRT. Bye, Uli ___ 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: numeric sort(1) is broken on -STABLE
On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > Hi guys, > > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > It somehow does not manifest when using a simple list and sorting on a > > specific column, but it always happens to me when using it in > > combination with find(1). > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > % find a b c -ls|sort -nk7,7 > > 8 64 -rw-r--r--1 uqs wheel10485760 > > Feb 10 09:13 a > > 10 64 -rw-r--r--1 uqs wheel 5242880 > > Feb 10 09:13 b > > 12 64 -rw-r--r--1 uqs wheel 819200 > > Feb 10 09:13 c > > I bet you're using some non-C locale for LC_NUMERIC. > What does "locale" output tell you? Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as there are no non-ASCII symbols in that output it shouldn't matter, right? For me, 819200 is smaller than 10485760 in pretty much all locales. Why the hell is a numeric gnusort locale dependant? Why is -g working anyway? % locale LANG= LC_CTYPE=de_DE.UTF-8 LC_COLLATE="C" LC_TIME="C" LC_NUMERIC="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= % find a b c -ls | LC_ALL=C sort -nk7,7 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a Great, now I'm even more angry at sort(1) than before ... Regards, Uli ___ 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: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > I have a strong suspicion that the issue is with bus_dma. If this is a > pci based card, then it is trying to allocate 32MB of contiguous > physical ram when the drm device is opened. This usually succeeds the > first time that the driver opens the device, but later, after memory has > become fragmented, this can become an issue. As I have mentioned, I > have code that reworks this whole process and I'll try and make a patch > available soon, but my I don't have a lot of time now, so it might be > the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window "switching" was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. +(II) RADEON(0): [drm] removed 1 reserved context for kernel +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xff8014a6d000 at 0x8006d4000 +(II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f (II) RADEON(0): MC_AGP_LOCATION : 0x003f (==) RADEON(0): Backing store disabled -(II) RADEON(0): [DRI] installation complete -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 -(WW) RADEON(0): DRI init changed memory map, adjusting ... -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f is: 0x0003 -(II) RADEON(0): RADEONRestoreMemMapRegisters() : -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 -(II) RADEON(0): Direct rendering enabled -(II) RADEON(0): Setting EXA maxPitchBytes -(II) EXA(0): Offscreen pixmap area of 111050752 bytes -(II) EXA(0): Driver registered support for the following operations: -(II) Solid -(II) Copy -(II) Composite (RENDER acceleration) -(II) UploadToScreen -(II) DownloadFromScreen -(II) RADEON(0): Acceleration enabled +(WW) RADEON(0): Direct rendering disabled +(EE) RADEON(0): Acceleration initialization failed +(II) RADEON(0): Acceleration disabled (**) Option "dpms" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled -(II) RADEON(0): Set up textured video +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP Output CRT2 disable success (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled Output UNIPHY1 transmitter setup success @@ -661,7 +634,7 @@ Mode 1920x1200 - 2080 1235 9 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 +(II) RADEON(0): MC_AGP_LOCATION : 0x003f freq: 15400 best_freq: 15390 best_feedback_div: 57 Pretty obvious what went wrong... Bye, Uli ___ 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"
numeric sort(1) is broken on -STABLE
Hi guys, not sure if this is a pilot error, but it seems to me that gnu sort -n is broken on at least -STABLE (couldn't test -CURRENT yet). It somehow does not manifest when using a simple list and sorting on a specific column, but it always happens to me when using it in combination with find(1). % truncate -s10m a; truncate -s5m b; truncate -s800k c % find a b c -ls|sort -nk7,7 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c % find a b c -ls|sort -gk7,7 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a at least -g does what is expected and I can work around this for the time being. Here's bsdsort % find a b c -ls|bsdsort -nk7,7 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a and this is on Solaris 8 % find a b c -ls|sort -nk7,7 546728 16 -rw-r--r-- 1 spoerul xxx819200 Feb 10 09:49 c 546727 16 -rw-r--r-- 1 spoerul xxx 5242880 Feb 10 09:48 b 546724 16 -rw-r--r-- 1 spoerul xxx 10485760 Feb 10 09:48 a It even occured to me, that we don't have a sort regression suite under tools/regression. Anyone know a place to find one with a suitable license? Regards, Uli ___ 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: Multiple serial consoles via null modem cable
On Thu, 21.01.2010 at 11:37:06 +0200, Marin Atanasov wrote: > Here's what I did: > > box1 COM1/ttyd0 -> box2 COM1/ttyd0 -> using null modem cable > box1 COM2/ttyd1 -> box3 COM1/ttyd0 -> using null modem cable > > On box1 I have this in /etc/ttys: > > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > ttyd1 "/usr/libexec/getty std.9600" vt100 on secure > > Now if I want to connect to box1 from box2 or box3 through the serial > connection it should work, right? > But I only can connect to box1 from box2, because box2's COM port is > connected to box1's COM1 port. Are there actually two gettys running on the serial ports? Did you do kill -1 1 after the changes to /etc/ttys? On box1, what do the following commands produce egrep "uart|sio" /var/run/dmesg.boot pgrep -fl getty Regards, Uli ___ 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: UTF-8 problem in 8.0
On Fri, 01.01.2010 at 15:47:36 -0800, Derek Kulinski wrote: > Hello, > > After installing FreeBSD 8.0 I noticed that some characters aren't > displayed correctly (it worked fine for 7.2). > > Mainly the dash character is most noticeable (though it's possible > it's more of them). > > Example: > env LANG=C man sh > env LANG=pl_PL.UTF-8 man sh > env LANG=en_US.UTF-8 man sh > > The first command shows everything fine, the later two seem to show > some unprintable character in place of every dash (i.e. in the second > paragraph word "built-in", or the dashes that break up the words at > the end of the line) me too, though I'm only setting LC_CTYPE to de_DE.UTF-8 and I don't always see it. It must be some combination of xterm/ssh and/or putty that breaks this. On the other hand, I thought there was a commit done, that would render - (the dash) always as - (0x2d) so you can copy&paste the examples from the manpage into your shell. But perhaps I was just dreaming this up? Bye, Uli ___ 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: gstat: geom_gettree = -1: No such file or directory
On Fri, 01.01.2010 at 18:47:27 +0100, martinko wrote: > Hi list, > > gstat(8) does not work here on 8.0 (it worked happily on 6.x and 7.x) : > > # gstat > gstat: geom_gettree = -1: No such file or directory > > Is this known ? What can I do ? I doubt that it is widely known, but I've seen these 2-3 times before when fussing around with USB media and/or md(4) devices with gmirror on top. Basically, if you get really creative with the geom layering, this is likely to happen. It sure is a bug, but without a good way to reproduce, noone's gonna fix it. Regards, Uli ___ 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 link aggregation failover
On Sun, 27.09.2009 at 09:49:03 -0400, Daniel Eischen wrote: > On Sun, 27 Sep 2009, Ulrich Spörlein wrote: > > > On Sat, 12.09.2009 at 22:34:41 +0200, Maciej Jan Broniarz wrote: > >> Hello, > >> > >> I am trying to configure lagg failover mode on 7.2. > >> > >> I do: > >> > >> # ifconfig xl0 up > >> # ifconfig fxp0 up > >> # ifconfig lagg0 create > >> # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0 > >> # dhclient lagg0 > >> > >> And all seems to work ok. Still I disconnect the cable from the master > >> card the connection stops. > >> Although fxp0 becomes active the connection is still dead. If I start > >> pinging any host from that machine > >> the conection comes back to live, but having ping in background all the > >> time is not the solution. > >> > >> Am I doing something wrong or have I missed something in the configuration? > > > > Well, where is xl0 and fxp0 connected to? My first bet would be a > > standard switch, if so try setting both devices to the same MAC address. > > Otherwise the peers you connect to will send the IP packets to the wrong > > MAC address and only after a timeout (or a forced push thanks to the > > ping) will get their ARP cache into shape. > > lagg should automatically make xl0 and fxp0 appear at the same MAC > address. The only time you should have to manually set the MAC > address would be on cloned interfaces such as wlan, because the > cloned interfaces don't propagate the MAC change down to the > interface from which they were cloned. Interesting, thanks for the hint. I only use it for LAN/WLAN failover, so that's why I have to do this anyway. Regards, Uli ___ 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 link aggregation failover
On Sat, 12.09.2009 at 22:34:41 +0200, Maciej Jan Broniarz wrote: > Hello, > > I am trying to configure lagg failover mode on 7.2. > > I do: > > # ifconfig xl0 up > # ifconfig fxp0 up > # ifconfig lagg0 create > # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0 > # dhclient lagg0 > > And all seems to work ok. Still I disconnect the cable from the master card > the connection stops. > Although fxp0 becomes active the connection is still dead. If I start pinging > any host from that machine > the conection comes back to live, but having ping in background all the time > is not the solution. > > Am I doing something wrong or have I missed something in the configuration? Well, where is xl0 and fxp0 connected to? My first bet would be a standard switch, if so try setting both devices to the same MAC address. Otherwise the peers you connect to will send the IP packets to the wrong MAC address and only after a timeout (or a forced push thanks to the ping) will get their ARP cache into shape. Regards, Uli ___ 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: pw groupadd/useradd fail when the nscd cache is used for name/group resolution
On Thu, 09.07.2009 at 16:13:25 +0300, Vlad Galu wrote: > I've stumbled upon this while installing postgres. In > /etc/nsswitch.conf I had "group: cache files compat" and "passwd: > cache files compat". Once I commented them out things started working > again. Before the change, this is how it looked like: > > -- cut here -- > [r...@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql -g > 70 > pw: group disappeared during update > [r...@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql -g > 70 > pw: group 'pgsql' already exists > [r...@vgalu /usr/ports/databases/postgresql84-server]# > -- and here -- > > Shouldn't 'files' be used upon a cache miss? If this is a PEBKAC, > sorry for the noise. Just a me too. This is most likely because nscd is also caching negative lookups. The usual workaround would be to restart it using /etc/rc.d/nscd restart Cheers, Ulrich Spörlein ___ 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: mergemaster merge left/right
On Fri, 03.07.2009 at 10:51:08 +0200, Dominic Fandrey wrote: > I'd really like mergemaster to tell me whether the left > or the right side is the new file. > > # $FreeBSD: src/etc/devd.conf,v 1.38. | # $FreeBSD: src/etc/devd.conf,v > 1.38. > > Like this I have no idea which one to pick. When using X, maximize your xterm horizontally and use mergemaster -w100 or something like that. It will probe the tty again and offer the "real" width, so I usually just run mergemaster -w1 and hit enter. hth, Ulrich Spörlein ___ 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 weird device tasting loop since MFC
On Tue, 02.06.2009 at 11:24:08 +0200, Ulrich Spörlein wrote: > On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Spörlein wrote: > > Hi all, > > > > so I went ahead and updated my ~7.2 file server to the new ZFS goodness, > > and before running any further tests, I already discovered something > > weird and annoying. > > > > I'm using a mirror on GELI, where one disk is usually *not* attached as > > a means of poor man's backup. (I had to go that route, as send/recv of > > snapshots frequently deadlocked the system, whereas a mirror scrubbing > > did not) > > > > r...@coyote:~# zpool status > > pool: tank > > state: DEGRADED > > status: The pool is formatted using an older on-disk format. The pool can > > still be used, but some features are unavailable. > > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > > pool will no longer be accessible on older software versions. > > scrub: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > tank DEGRADED 0 0 0 > > mirror DEGRADED 0 0 0 > > ad4.eli ONLINE 0 0 0 > > 12333765091756463941 REMOVED 0 0 0 was > > /dev/da0.eli > > > > errors: No known data errors > > > > When imported, there is a constant "tasting" of all devices in the system, > > which also makes the floppy drive go spinning constantly, which is really > > annoying. It did not do this with the old ZFS, are there any remedies? > > > > gstat(8) is displaying the following every other second, together with a > > spinning fd0 drive. > > > > dT: 1.010s w: 1.000s filter: ^...$ > > L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name > > 0 0 0 00.0 0 00.00.0| fd0 > > 0 8 8 10140.1 0 00.00.1| md0 > > 0 32 32 40559.2 0 00.0 29.2| ad0 > > 0 77 10 12677.1 63 11252.3 31.8| ad4 > > > > There is no activity going on, especially md0 is for /tmp, yet it > > constantly tries to read stuff from everywhere. I will now insert the > > second drive and see if ZFS shuts up then ... > > It does, but it also did not start resilvering the second disk: > > r...@coyote:~# zpool status > pool: tank > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. >see: http://www.sun.com/msg/ZFS-8000-9P > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad4.eli ONLINE 0 0 0 > da0.eli ONLINE 0 016 > > errors: No known data errors > > Will now run the scrub and report back in 6-9h. Another datapoint: While the floppy-tasting has stopped, since the mirror sees all devices again, there is some other problem here: r...@coyote:/# zpool online tank da0.eli r...@coyote:/# zpool status pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli ONLINE 0 0 0 2.20M resilvered errors: No known data errors r...@coyote:/# zpool offline tank da0.eli r...@coyote:/# zpool status pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli OFFLINE 0 0 0 2.20M resilvered errors: No known data errors r...@coyote:/# zpool sta
Re: ZFS weird device tasting loop since MFC
On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Spörlein wrote:
> Hi all,
>
> so I went ahead and updated my ~7.2 file server to the new ZFS goodness,
> and before running any further tests, I already discovered something
> weird and annoying.
>
> I'm using a mirror on GELI, where one disk is usually *not* attached as
> a means of poor man's backup. (I had to go that route, as send/recv of
> snapshots frequently deadlocked the system, whereas a mirror scrubbing
> did not)
>
> r...@coyote:~# zpool status
> pool: tank
> state: DEGRADED
> status: The pool is formatted using an older on-disk format. The pool can
> still be used, but some features are unavailable.
> action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
> pool will no longer be accessible on older software versions.
> scrub: none requested
> config:
>
> NAME STATE READ WRITE CKSUM
> tank DEGRADED 0 0 0
> mirror DEGRADED 0 0 0
> ad4.eli ONLINE 0 0 0
> 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli
>
> errors: No known data errors
>
> When imported, there is a constant "tasting" of all devices in the system,
> which also makes the floppy drive go spinning constantly, which is really
> annoying. It did not do this with the old ZFS, are there any remedies?
>
> gstat(8) is displaying the following every other second, together with a
> spinning fd0 drive.
>
> dT: 1.010s w: 1.000s filter: ^...$
> L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name
> 0 0 0 00.0 0 00.00.0| fd0
> 0 8 8 10140.1 0 00.00.1| md0
> 0 32 32 40559.2 0 00.0 29.2| ad0
> 0 77 10 12677.1 63 11252.3 31.8| ad4
>
> There is no activity going on, especially md0 is for /tmp, yet it
> constantly tries to read stuff from everywhere. I will now insert the
> second drive and see if ZFS shuts up then ...
It does, but it also did not start resilvering the second disk:
r...@coyote:~# zpool status
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
ad4.eli ONLINE 0 0 0
da0.eli ONLINE 0 016
errors: No known data errors
Will now run the scrub and report back in 6-9h.
Cheers,
Ulrich Spörlein
--
http://www.dubistterrorist.de/
___
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"
ZFS weird device tasting loop since MFC
Hi all, so I went ahead and updated my ~7.2 file server to the new ZFS goodness, and before running any further tests, I already discovered something weird and annoying. I'm using a mirror on GELI, where one disk is usually *not* attached as a means of poor man's backup. (I had to go that route, as send/recv of snapshots frequently deadlocked the system, whereas a mirror scrubbing did not) r...@coyote:~# zpool status pool: tank state: DEGRADED status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli errors: No known data errors When imported, there is a constant "tasting" of all devices in the system, which also makes the floppy drive go spinning constantly, which is really annoying. It did not do this with the old ZFS, are there any remedies? gstat(8) is displaying the following every other second, together with a spinning fd0 drive. dT: 1.010s w: 1.000s filter: ^...$ L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 0 0 00.0 0 00.00.0| fd0 0 8 8 10140.1 0 00.00.1| md0 0 32 32 40559.2 0 00.0 29.2| ad0 0 77 10 12677.1 63 11252.3 31.8| ad4 There is no activity going on, especially md0 is for /tmp, yet it constantly tries to read stuff from everywhere. I will now insert the second drive and see if ZFS shuts up then ... Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ 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 on top of GELI / Intel Atom 330 system
On Sun, 31.05.2009 at 19:28:51 +0300, Dan Naumov wrote: > Hi > > Since you are suggesting 2 x 8GB USB for a root partition, what is > your experience with read/write speed and lifetime expectation of > modern USB sticks under FreeBSD and why 2 of them, GEOM mirror? Well, my current setup is using an old 2GB CF card, so read/write speeds suck (14 and 7 MB/s, respectively, IIRC), but then again, there are not many actual read/writes on / or /usr for my setup anyway. The 2x 8GB USB sticks I would of course use to gmirror the setup, although I have been told that this is rather excessive. Modern flash media should cope with enough write cycles to get you through a decade. With /var being on GELI+ZFS this point is mood even more, IMHO. A recent 8GB Sandisk U3 stick of mine manages to read/write ~25MB/s (working from memory here), so this is pretty much the maximum USB 2.0 is giving you. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ 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 on top of GELI / Intel Atom 330 system
On Fri, 29.05.2009 at 11:19:44 +0300, Dan Naumov wrote: > Also, free free to criticize my planned filesystem layout for the > first disk of this system, the idea behind /mnt/sysbackup is to take a > snapshot of the FreeBSD installation and it's settings before doing > potentially hazardous things like upgrading to a new -RELEASE: > > ad1s1 (freebsd system slice) > ad1s1a => 128bit Blowfish ad1s1a.eli 4GB swap > ad1s1b 128GB ufs2+s / > ad1s1c 128GB ufs2+s noauto /mnt/sysbackup > > ad1s2 => 128bit Blowfish ad1s2.eli > zpool > /home > /mnt/data1 Hi Dan, everybody has different needs, but what exactly are you doing with 128GB of / ? What I did is the following: 2GB CF card + CF to ATA adapter (today, I would use 2x8GB USB sticks, CF2ATA adapters suck, but then again, which Mobo has internal USB ports?) Filesystem 1024-blocks UsedAvail Capacity Mounted on /dev/ad0a 507630139740 32728030%/ /dev/ad0d 1453102 12922964455897%/usr /dev/md025367816 233368 0%/tmp /usr is quite crowded, but I just need to clean up some ports again. /var, /usr/src, /home, /usr/obj, /usr/ports are all on the GELI+ZFS pool. If /usr turns out to be to small, I can also move /usr/local there. That way booting and single user involves trusty old UFS only. I also do regular dumps from the UFS filesystems to the ZFS tank, but there's really no sacred data under / or /usr that I would miss if the system crashed (all configuration changes are tracked using mercurial). Anyway, my point is to use the full disks for GELI+ZFS whenever possible. This makes it more easy to replace faulty disks or grow ZFS pools. The FreeBSD base system, I would put somewhere else. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ 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 on top of GELI / Intel Atom 330 system
On Fri, 29.05.2009 at 12:47:38 +0200, Morgan Wesström wrote: > You can benchmark the encryption subsytem only, like this: > > # kldload geom_zero > # geli onetime -s 4096 -l 256 gzero > # sysctl kern.geom.zero.clear=0 > # dd if=/dev/gzero.eli of=/dev/null bs=1M count=512 > > 512+0 records in > 512+0 records out > 536870912 bytes transferred in 11.861871 secs (45260222 bytes/sec) > > The benchmark will use 256-bit AES and the numbers are from my Core2 Duo > Celeron E1200 1,6GHz. My old trusty Pentium III 933MHz performs at > 13MB/s on that test. Both machines are recompiled with CPUTYPE=core2 and > CPUTYPE=pentium3 respectively but unfortunately I have no benchmarks on > how they perform without the CPU optimizations. Hi Morgan, thanks for the nice benchmarking trick. I tried this on two ~7.2 systems: CPU: Intel Pentium III (996.77-MHz 686-class CPU) -> 14.3MB/s CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) -> 47.5MB/s Reading a big file from the pool of this P4 results in 27.6MB/s netto transfer rate (single 7200 rpm SATA disk). I would be *very* interested in numbers from the dual core Atom, both with 2 CPUs and with 1 active core only. I think that having dual core is a must for this setup, so you can use 2 GELI threads and have the ZFS threads on top of that to spread the load. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ 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: gemor mirror and priority
On Sat, 21.03.2009 at 08:44:42 -1000, Clifton Royston wrote: > Even if you don't, I think it's quite useful to make the *default* > priority set when creating a mirror be some value which allows both > higher and lower values to be specified. I hadn't known about that > issue until I read the original thread here a while back.If the default > were set to some mid-range value, or even to 2, for example, then at > least creating a new mirror and adding drives without setting a > priority would continue to behave as usual, while it would be possible > to explicitly insert new components with a lower priority. (I see why > one wouldn't want to change the default interpretation of existing > priority values for POLA reasons.) > > There are lots of reasons one could want to control priorities of > mirrored drives in various ways. One is to use gmirror as a long-term > backup approach: mirror with three drives, periodically disconnecting > one from the mirror to swap it with a fresh drive from a pool of backup > drives. I haven't tried this, but it's been on my mind to mess around > with soon. I did this for 2-3 years and it has worked very well. Of course I took care of using the right priorities from the start. This setup has now been replaced by a ZFS mirror. The resilver time is just so much better :) > In this case, I would want the designated backup drive to always be > lowest-priority, to ensure the mirror never accidentally started > rebuilding from a newly reinserted backup. (This probably wouldn't > happen anyway, but it would be nice to be sure...) This will not happen. Besides, I would strongly encourage you to disable automatic rebuilding for this type of setup. Cheers, Ulrich Spörlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe ___ 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: /dev/cuau* ports hang after a while
On Mon, 26.01.2009 at 15:00:11 +0200, Timo Rikkonen wrote: > Hi, > > We are using "VScom PCI-200L" and "Moxa Technologies, C168H/PCI" > -cards for serial ports. After installing 7.0 the ports or the > connection to the port hang after a while. A "while" could be > half-a-day or 10 minutes. There is no error message to be seen > anywhere. What exactly do you mean by "hang"? I discovered something odd, when I upgraded my 6.3 box to 7.1, namely, that the serial console (no matter if it's sio or uart) will not echo anything, once I "hang up" the line for the first time. To make this clear: I reboot with serial console attached, I see kernel console, then getty/login prompt. I can login fine, and do stuff. Once I exit tip(1) on the terminal, the port is "mostly" dead on the server. I say mostly, because I can still blindly enter the root login and confirm via separate ssh login, that I'm logged in to the machine on the serial getty port. So it seems to me, whenever sio/uart receive the first device close event, they get b0rked and receive only input, but can no longer send any output. > Not all ports hang at the same time, it could be just one or two of > them. Earlier versions (6.2-RELEASE) work just fine. The ports have > different devicenames after 7.0, in 6.2 they were /dev/cuad4-7, now > they are /dev/cuau0-3 (uart?) Try rebuilding a kernel without uart and see if they come up as sio ports again (and work?) > We have over 20 installations, now two of them have been upgraded to 7.0 with > mentioned side effects. Is this identical hardware? Cheers, Ulrich Spörlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe ___ 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"
Snapshot duration, performance and how to avoid I/O lock
Hi, I have to create regular snapshots of several volumes roughly 1.4TB in size (each). But using mksnap_ffs takes a lot of time (45 minutes) and it looks like it could be speed up. iostat reports some 2MB/s of I/O tty da0 da1 sa0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 77 16.00 120 1.87 0.00 0 0.00 0.00 0 0.00 0 0 8 4 89 0 231 16.00 131 2.04 0.00 0 0.00 0.00 0 0.00 0 0 6 2 91 0 77 16.00 127 1.98 0.00 0 0.00 0.00 0 0.00 0 0 5 3 92 0 204 16.00 123 1.92 0.00 0 0.00 0.00 0 0.00 0 0 6 3 91 0 77 16.00 128 2.00 0.00 0 0.00 0.00 0 0.00 0 0 6 3 91 gstat reports dT: 0.501s w: 0.500s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 1126 84 1341 11.8 426712.7 99.7| da0 The filesystem under snapshotting was *empty*, and right now is at Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2d 1376038286 815092 1265140132 0%/export/vol1 How come, a snapshot of an empty file system takes more than 800MB? Aren't the blocks copy-on-write? Why is the disk 100% busy while only a mere 2MB/s are pushed? This is on a 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xdc00-0xddff,0xd830-0xd8300fff irq 48 at device 1.0 on pci3 twa0: [FAST] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.00.005, BIOS BE9X 3.04.00.002 with a RAID5 over 7 SATA disks. da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 1430448MB (2929557504 512 byte sectors: 255H 63S/T 182356C) Another thing is blocking other disk I/O while snapshotting. Right now I did a ls(1) in the .snap directory, so I understand the filesystem is now suspended. The workaround would then be to "dont do that". But what if other snapshots are accessed during that time? I want to provide yesterdays snapshot to our users while taking the current snapshot and providing access to the newest data at the same time. Cheers Ulrich Spoerlein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
