Re: [HEADSUP][CFT] pkgng beta1 is out
On 30.01.2012 16:39, Baptiste Daroussin wrote: Hi, pkgng has just reached the beta phase, and has now found its way to the ports tree (disabled by default). 1/ Why pkgng? Hi, What about pkgng support in tinderbox? -- Andrey Zonov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using nscd (ldap) makes passwd/group disappearing while installing ports
On 02/01/12 01:03, Benjamin Lee wrote: On 01/31/2012 03:03 PM, O. Hartmann wrote: I'm using on a couple of servers the nameservice cache dameon nscd and cache group, passwd and sudoers. Backend is LDAP, but local files should searched first. then ldap. cache is searched the very first even before files. Well, I'd expect that if a group is present, like cups or dhcp and reside in the local file (/etc/group or /etc/passwd), they are cached. Installing net/isc-dhcp42-server fails with this error: gmake[1]: Leaving directory `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2/server' gmake[1]: Entering directory `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' gmake[1]: Nothing to be done for `all-am'. gmake[1]: Leaving directory `/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.3-P2' === Installing for isc-dhcp42-server-4.2.3_2 === Generating temporary packing list === Creating users and/or groups. Creating group `dhcpd' with gid `136'. pw: group disappeared during update *** Error code 70 Stop in /usr/ports/net/isc-dhcp42-server. *** Error code 1 Stop in /usr/ports/net/isc-dhcp42-server. What's going on is: 1) The port checks if the group exists 2) nscd caches that the group does not exist in its negative cache 3) pw(8) creates the group then checks if it exists 4) nscd returns the negative cache entry (group does not exist) This causes pw(8) to error since it expects the group that it just created to exist. I also have this error very often when rebuilding/updating or even installing cups when nscd is enabled. A simple restart of nscd helps in most cases, most times I need to disable cache tag in /etc/nsswitch.conf, then everything runs smooth. Well, this behaviour is since a couple of years now, occurs sporadic. I have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? I like the cache facility, since in domains with a lot of users searching LDAP takes some time and caching help keeping traffic and latency short. But the namservice caching mechanism seems to be unreliable. What is up there? You should put files before cache in /etc/nsswitch.conf, e.g.: group: files cache ldap passwd: files cache ldap The problem is that tools that modify the passwd and group files, like pw(8), don't invalidate nscd's negative cache entries when making changes. Thank you for the explanation. Cheers, Oliver signature.asc Description: OpenPGP digital signature
Re: using nscd (ldap) makes passwd/group disappearing while installing ports
On 01/02/2012, at 19:25, O. Hartmann wrote: The problem is that tools that modify the passwd and group files, like pw(8), don't invalidate nscd's negative cache entries when making changes. Thank you for the explanation. How feasible would it be for pw to try and notify nscd? Or for nscd to monitor the passwd group files? Either would be somewhat racy though.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using nscd (ldap) makes passwd/group disappearing while installing ports
Am 01.02.2012 01:03, schrieb Benjamin Lee: What's going on is: 1) The port checks if the group exists 2) nscd caches that the group does not exist in its negative cache 3) pw(8) creates the group then checks if it exists 4) nscd returns the negative cache entry (group does not exist) This causes pw(8) to error since it expects the group that it just created to exist. I had suggested before, that nscd be changed to only rely on cached negative entries, if they have repeatedly been seen in the underlying files/data-bases. E.g. only consider negative entries valid after they have been repeatedly stored into the cache (I'd think 3 times are a reasonable number). That way, the first lookup of an account or group will lead to an entry with count=1, which is found during cache lookup but which is ignored due to a too low verification count. If the negative lookup is repeated 3 times within some reasonable time window (say 60 seconds), then it is to be considered verified. This will make the above sequence of queries and modifications of the passwd or group databases work with caching. This concept does not protect against scenarios where the negative cache entry is made active by several queries (e.g. manual checking for the presence of an account or group before the software installation repeats these tests). That is the reason to ask for more than 2 negative replies (3, perhaps better 5) before a negative cache entry is trusted. The main purpose of the cache (reduced latency for positive queries, limited load due to negative queries) will still be maintained. I also have this error very often when rebuilding/updating or even installing cups when nscd is enabled. A simple restart of nscd helps in most cases, most times I need to disable cache tag in /etc/nsswitch.conf, then everything runs smooth. Well, this behaviour is since a couple of years now, occurs sporadic. I have had in FreeBSD 7, 8, 9 and I see it in 10. What is it? I like the cache facility, since in domains with a lot of users searching LDAP takes some time and caching help keeping traffic and latency short. But the namservice caching mechanism seems to be unreliable. What is up there? You should put files before cache in /etc/nsswitch.conf, e.g.: group: files cache ldap passwd: files cache ldap The problem is that tools that modify the passwd and group files, like pw(8), don't invalidate nscd's negative cache entries when making changes. You point out an alternative to making negative entries trusted only after they have been repeatedly entered into the cache: Tools that are used to modify the passwd/group databases might signal their changes to nscd. They could either purge the modified caches for the current or for all users, or they could just clear the single affected entry. In each case, nscd needs to re-fetch the modified (and possibly all other cached) entries. A simple implementation of such invalidation could be to invoke nscd -I after each modification performed by pw. Still I think that the reduced trust in negative entries that have not been repeatedly tested is the best solution. I had looked into implementing such a logic in the cache, a few months back. It took more effort than I had hoped due to the way the cache is implemented, but I still think it should be possible without major changes to nscd. Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Race between cron and crontab
On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote: On 01/31/2012 08:49, John Baldwin wrote: A co-worker ran into a race between updating a cron tab via crontab(8) and cron(8) yesterday. Specifically, cron(8) failed to notice that a crontab was updated. The problem is that 1) by default our filesystems only use second granularity for timestamps and 2) cron only caches the seconds portion of a file's timestamp when checking for changes anyway. This means that cron can miss updates to a spool directory if multiple updates to the directory are performed within a single second and cron wakes up to scan the spool directory within the same second and scans it before all of the updates are complete. Specifically, when replacing a crontab, crontab(8) first creates a temporary file in /var/cron/tabs and then uses a rename to install it followed by touching the spool directory to update its modification time. However, the creation of the temporary file already changes the modification time of the directory, and cron may miss the rename if it scans the directory in between the creation of the temporary file and the rename. The fix I am planning to use locally is to simply force crontab(8) to sleep for a second before it touches the spool directory, thus ensuring that it the touch of the spool directory will use a later modification time than the creation of the temporary file. If you really want cron to have sub-second granularity I don't see how you could do it without using flags. crontab open sets flag that it is editing a file crontab close clears editing flag, sets something changed flag (if something actually changed of course) cron checks existence of something changed flag, pulls the update if there is no editing flag, clears changed flag I don't want it to have sub-second granularity, I just want to make 'crontab -e' more reliable so that cron doesn't miss edits. cron is currently using the mod-time of the spool directory as the 'something changed' flag (have you read the cron code?). The problem is that it currently can set the 'something changed' flag non-atomically while it is updating a crontab. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: CARP on -CURRENT
I much appreciate the responses and I was able to get CARP functioning using
the new ifconfig syntax under -CURRENT. Having done that, CARP is now acting as
it should, though now I have a new challenge with devd and automatic firing of
scripts during CARP failover. It appears that the documented method of doing
this at http://www.freebsd.org/doc/handbook/disks-hast.html no longer works
with the suggested devd.conf setup;
notify 30 {
match system IFNET;
match subsystem carp0;
match type LINK_UP;
action /usr/local/sbin/carp-hast-switch master;
};
notify 30 {
match system IFNET;
match subsystem carp0;
match type LINK_DOWN;
action /usr/local/sbin/carp-hast-switch slave;
Is it likely that the triggers associated with CARP for devd have changed due
to the recent new CARP overhaul? Does anyone know what the new triggers may be?
Love,
Andrew
-Original Message-
From: Sergey Kandaurov [mailto:pluk...@gmail.com]
Sent: Wednesday, January 18, 2012 4:24 PM
To: Andrew Hobbs
Cc: freebsd-current@freebsd.org
Subject: Re: CARP on -CURRENT
On 19 January 2012 00:54, Andrew Hobbs andrew.ho...@ai.net wrote:
Is CARP implemented on -CURRENT (FreeBSD 10)?
I'm playing around with some test boxes in the office running
-CURRENT; testbox# uname -a FreeBSD testbox.ai.net 10.0-CURRENT
FreeBSD 10.0-CURRENT #0: Wed Jan 18 19:21:12 EST 2012
r...@testbox.ai.net:/usr/obj/usr/src/sys/CARP amd64
I can't seem to create a carp interface despite having compiled a
kernel with device carp in it. Attempts to create a carp
interface fail; # ifconfig carp create
ifconfig: SIOCIFCREATE2: Invalid argument
From what I've read in the handbook entry on CARP
(http://www.freebsd.org/doc/handbook/carp.html), I should be able to
either compile in the carp device, as above, or load the if_carp.ko
kern module. There doesn't appear to be a if_carp.ko module in the
-CURRENT source tree, however. Only the carp module itself;
# ls -ald /usr/src/sys/modules/*carp*
drwxr-xr-x 2 root wheel 512 Dec 27 15:12 /usr/src/sys/modules/carp
Am I missing something completely obvious? Was the functionality of
if_carp.ko rolled into another module?
You should definitely read this changeset:
http://svn.freebsd.org/changeset/base/228571
and the updated carp ifconfig syntax in man carp. As for if_carp.ko, it was
renamed into carp.ko as part of the CARP implementation overhaul.
This only affects CURRENT.
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 下午11:28，Konstantin Belousov kostik...@gmail.com 写道： On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: ?? 2012??1??31?? 12:43??Kostik Belousov kostik...@gmail.com ?? On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: ?? 2012??1??30?? 2:36??Kostik Belousov kostik...@gmail.com ?? On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current patched with pcid.2.patch? It works well without other issue and it seem the pcid patch does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings. Thank you for your explanation. I just disabled nvidia-driver( not load it) , and use buildworld buildkernel to test the pcid.1.patch with 9-release, it seems the box reset before completing the buildkernel, the attachment is my kernel config, would you mind try it on 9-release with pcid.1.patch? I will git 10-current a try to see if there is something wrong with my hardware I just did checkout + buildworld + buildkernel with -j 10 on UFS with PCID turned on, everything finished fine. It is up to date HEAD. sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt vm.stats.sys.v_swtch: 13743519 vm.pmap.pcid_save_cnt: 7853519 I.e. the TLB was not flushed one each second context switch. Trying the HEAD with the patch is probably easiest way forward. Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2012-02-01 22:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-02-01 22:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-02-01 22:20:00 - cleaning the object tree TB --- 2012-02-01 22:21:02 - cvsupping the source tree TB --- 2012-02-01 22:21:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-02-01 22:26:27 - building world TB --- 2012-02-01 22:26:27 - CROSS_BUILD_TESTING=YES TB --- 2012-02-01 22:26:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-01 22:26:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-01 22:26:27 - SRCCONF=/dev/null TB --- 2012-02-01 22:26:27 - TARGET=i386 TB --- 2012-02-01 22:26:27 - TARGET_ARCH=i386 TB --- 2012-02-01 22:26:27 - TZ=UTC TB --- 2012-02-01 22:26:27 - __MAKE_CONF=/dev/null TB --- 2012-02-01 22:26:27 - cd /src TB --- 2012-02-01 22:26:27 - /usr/bin/make -B buildworld World build started on Wed Feb 1 22:26:28 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 2 00:30:56 UTC 2012 TB --- 2012-02-02 00:30:56 - generating LINT kernel config TB --- 2012-02-02 00:30:56 - cd /src/sys/i386/conf TB --- 2012-02-02 00:30:56 - /usr/bin/make -B LINT TB --- 2012-02-02 00:30:57 - cd /src/sys/i386/conf TB --- 2012-02-02 00:30:57 - /usr/sbin/config -m LINT TB --- 2012-02-02 00:30:57 - building LINT kernel TB --- 2012-02-02 00:30:57 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 00:30:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 00:30:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 00:30:57 - SRCCONF=/dev/null TB --- 2012-02-02 00:30:57 - TARGET=i386 TB --- 2012-02-02 00:30:57 - TARGET_ARCH=i386 TB --- 2012-02-02 00:30:57 - TZ=UTC TB --- 2012-02-02 00:30:57 - __MAKE_CONF=/dev/null TB --- 2012-02-02 00:30:57 - cd /src TB --- 2012-02-02 00:30:57 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 2 00:30:57 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Thu Feb 2 01:02:24 UTC 2012 TB --- 2012-02-02 01:02:24 - cd /src/sys/i386/conf TB --- 2012-02-02 01:02:24 - /usr/sbin/config -m LINT-NOINET TB --- 2012-02-02 01:02:24 - building LINT-NOINET kernel TB --- 2012-02-02 01:02:24 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 01:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 01:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 01:02:24 - SRCCONF=/dev/null TB --- 2012-02-02 01:02:24 - TARGET=i386 TB --- 2012-02-02 01:02:24 - TARGET_ARCH=i386 TB --- 2012-02-02 01:02:24 - TZ=UTC TB --- 2012-02-02 01:02:24 - __MAKE_CONF=/dev/null TB --- 2012-02-02 01:02:24 - cd /src TB --- 2012-02-02 01:02:24 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Thu Feb 2 01:02:24 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Thu Feb 2 01:32:19 UTC 2012 TB --- 2012-02-02 01:32:19 - cd /src/sys/i386/conf TB --- 2012-02-02 01:32:19 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-02-02 01:32:19 - building LINT-NOINET6 kernel TB --- 2012-02-02 01:32:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 01:32:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 01:32:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 01:32:19 - SRCCONF=/dev/null TB --- 2012-02-02 01:32:19 - TARGET=i386 TB --- 2012-02-02 01:32:19 - TARGET_ARCH=i386 TB --- 2012-02-02 01:32:19 - TZ=UTC TB --- 2012-02-02 01:32:19 - __MAKE_CONF=/dev/null TB --- 2012-02-02 01:32:19 - cd /src TB --- 2012-02-02 01:32:19 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Thu Feb 2 01:32:19 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Thu Feb 2 02:02:32 UTC 2012 TB --- 2012-02-02 02:02:32 - cd /src/sys/i386/conf TB --- 2012-02-02 02:02:32 - /usr/sbin/config -m LINT-NOIP TB --- 2012-02-02 02:02:32 - building LINT-NOIP kernel TB --- 2012-02-02 02:02:32 - CROSS_BUILD_TESTING=YES TB --- 2012-02-02 02:02:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-02 02:02:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-02 02:02:32 - SRCCONF=/dev/null TB --- 2012-02-02 02:02:32 - TARGET=i386 TB --- 2012-02-02 02:02:32 -
Smartmontools
Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Smartmontools
On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# I can't say for certain, but my guess is that you've been victimized by recent changes to CAM headers. Have you tried recompiling to get everything in sync? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Smartmontools
In message e5fba775-b6b6-4086-ba2b-d74a19cf4...@samsco.org, Scott Long writes : On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# I can't say for certain, but my guess is that you've been victimized by recen t changes to CAM headers. Have you tried recompiling to get everything in sy nc? Everything (kernel and userland) but smaartmontools (and other ports) has been rebuilt (two days ago). Rebuilding the port did the trick. Thanks. :) -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
On Thu, Feb 02, 2012 at 08:46:47AM +0800, Paul Ambrose wrote: Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic Unfortunately, you did not provided any details of the panic. Panic message and backtrace is the absolute minimum. pgpxg4eyJtcbA.pgp Description: PGP signature
Re: CARP on -CURRENT
On 2 February 2012 04:26, Andrew Hobbs andrew.ho...@ai.net wrote:
I much appreciate the responses and I was able to get CARP functioning using
the new ifconfig syntax under -CURRENT. Having done that, CARP is now acting
as it should, though now I have a new challenge with devd and automatic
firing of scripts during CARP failover. It appears that the documented method
of doing this at http://www.freebsd.org/doc/handbook/disks-hast.html no
longer works with the suggested devd.conf setup;
notify 30 {
match system IFNET;
match subsystem carp0;
match type LINK_UP;
action /usr/local/sbin/carp-hast-switch master;
};
notify 30 {
match system IFNET;
match subsystem carp0;
match type LINK_DOWN;
action /usr/local/sbin/carp-hast-switch slave;
Is it likely that the triggers associated with CARP for devd have changed due
to the recent new CARP overhaul? Does anyone know what the new triggers may
be?
You will need to change this to something like (as taken from man carp):
match system CARP;
match subsystem [0-9]+@;
match type(MASTER|BACKUP);
The subsystem now is generated as
snprintf(subsys, IFNAMSIZ+5, %u@%s, sc-sc_vhid, sc-sc_carpdev-if_xname);
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
