Re: svn commit: r213648 - head/sys/kern
On Sat, Oct 09, 2010 at 12:48:50PM +0300, Andriy Gapon wrote:
> on 09/10/2010 12:33 Bruce Evans said the following:
> > On Sat, 9 Oct 2010, Andriy Gapon wrote:
> >
> >> Log:
> >> panic_cpu variable should be volatile
> >>
> >> This is to prevent caching of its value in a register when it is checked
> >> and modified by multiple CPUs in parallel.
> >> Also, move the variable into the scope of the only function that uses it.
> >>
> >> Reviewed by:jhb
> >> Hint from:mdf
> >> MFC after:1 week
> >
> > I doubt that this is either necessary or sufficient. Most variables
> > aren't volatile while they are locked by a mutex. But panic() cannot use
> > normal mutex locking, so it should access this variable using atomic
> > ops with memory barriers. The compiler part of the memory barriers
> > effectively make _all_ variables temporily volatile. However, 2 of the
> > the 4 accesses to this variable doesn't use an atomic op.
> >
> > % #ifdef SMP
> > % /*
> > % * We don't want multiple CPU's to panic at the same time, so we
> > % * use panic_cpu as a simple spinlock. We have to keep checking
> > % * panic_cpu if we are spinning in case the panic on the first
> > % * CPU is canceled.
> > % */
> > % if (panic_cpu != PCPU_GET(cpuid))
> >
> > This access doesn't use an atomic op.
> >
> > % while (atomic_cmpset_int(&panic_cpu, NOCPU,
> > % PCPU_GET(cpuid)) == 0)
> >
> > This access uses an atomic op. Not all atomic ops use memory barriers,
> > at least on i386. However, this one does, at least on i386.
> >
> > (I'm always confused about what atomic_any() without acq or release
> > means. Do they mean that you don't want a memory barrier (this is
> > what the mostly give, at least on i386), and if so, what use are
> > they? There are far too many atomic ops, for far too many never-used
> > widths, with alternative spellings to encourage using a wrong one.
> > cmpset is is especially confusing since it you can spell it as cmpset,
> > cmpset_acq or compset_rel and always get the barrier, at least on
> > i386. At least cmpset only supports 1 width, at least on i386.)
> >
> > % while (panic_cpu != NOCPU)
> >
> > This access doesn't use an atomic op.
> >
> > % ; /* nothing */
> > % #endif
> > % ...
> > % #ifdef RESTARTABLE_PANICS
> > % /* See if the user aborted the panic, in which case we continue. */
> > % if (panicstr == NULL) {
> > % #ifdef SMP
> > % atomic_store_rel_int(&panic_cpu, NOCPU);
> >
> > This access uses an atomic op with a memory barrier, at least on i386.
> > Now its rel semantics are clear.
> >
> > panicstr is non-volatile and never accessed by an atomic op, so it probably
> > strictly needs to be declared volatile even more than panic_cpu. I think
>
> I agree about panicstr.
> But I am not sure if we have places in code (beyond panic function) itself
> where
> volatile vs. non-volatile would make any actual difference.
> But still.
>
> > the only thing that makes it work now is that it is bogusly pubic, and
> > compilers can't analyze the whole program yet -- if they could, then they
> > would see that it is only set in panic().
> >
> > % #endif
> > % return;
> > % }
> > % #endif
> > % #endif
> >
> > Now, why don't the partial memory barriers prevent caching the variable?
> >
> > % if (panic_cpu != PCPU_GET(cpuid))
> > % while (atomic_cmpset_int(&panic_cpu, NOCPU,
> > % PCPU_GET(cpuid)) == 0)
> > % while (panic_cpu != NOCPU)
> > % ; /* nothing */
> >
> > The very first access can't reasonably use a cachec value. atomic_cmpset()
> > can change panic_cpu, so even without the memory barrier, panic_cpu must
> > be reloaded for the third access the first time. But then when the third
> > access is repeated in the second while loop, the missing atomic op with
> > barrier makes things very broken. panic_cpu isn't changed by the loop,
> > and the compiler thinks that it isn't changed by anything else either, so
> > the compiler may reduce the loop to:
> >
> > % if (panic_cpu != NOCPU)
> > % for (;;)
> > % ; /* nothing */
>
>
> Yes, it's exactly the last loop that had the problem.
> On amd64 with -O2:
> .loc 1 544 0
> movlpanic_cpu(%rip), %eax
> .LVL134:
> .p2align 4,,7
> .L210:
> cmpl$255, %eax
> jne .L210
> jmp .L225
>
> > except I've seen claims that even an endless for loop can be optimized
> > to nothing. Declaring panic_cpu as volatile prevents the compiler doing
> > this, but I think it is insufficient. We really do want to see panic_cpu
> > changed by other CPUs, and what is the point of atomic_load_acq*() if not
> > to use for this -- if declaring things volatile were sufficient, then we
> > could just use *(volatile *)&var. atomic_load/store_acq/rel*() on i386
>
> I
Re: svn commit: r213648 - head/sys/kern
Thank you and Bruce for explanation.
The key point here (which I did not understand) is that
"something == PCPU_GET(cpuid))" may be true only if "something" is set by the
current cpu, in which case its value is not stale.
On Wed, Oct 13, 2010 at 09:05:04AM -0400, John Baldwin wrote:
> On Tuesday, October 12, 2010 5:08:04 pm Gennady Proskurin wrote:
> > On Sat, Oct 09, 2010 at 12:48:50PM +0300, Andriy Gapon wrote:
> > > on 09/10/2010 12:33 Bruce Evans said the following:
> > > > On Sat, 9 Oct 2010, Andriy Gapon wrote:
> > > >
> > > >> Log:
> > > >> panic_cpu variable should be volatile
> > > >>
> > > >> This is to prevent caching of its value in a register when it is
> > > >> checked
> > > >> and modified by multiple CPUs in parallel.
> > > >> Also, move the variable into the scope of the only function that
> > > >> uses it.
> > > >>
> > > >> Reviewed by:jhb
> > > >> Hint from:mdf
> > > >> MFC after:1 week
> > > >
> > > > I doubt that this is either necessary or sufficient. Most variables
> > > > aren't volatile while they are locked by a mutex. But panic() cannot
> > > > use
> > > > normal mutex locking, so it should access this variable using atomic
> > > > ops with memory barriers. The compiler part of the memory barriers
> > > > effectively make _all_ variables temporily volatile. However, 2 of the
> > > > the 4 accesses to this variable doesn't use an atomic op.
> > > >
> > > > % #ifdef SMP
> > > > % /*
> > > > % * We don't want multiple CPU's to panic at the same time, so we
> > > > % * use panic_cpu as a simple spinlock. We have to keep checking
> > > > % * panic_cpu if we are spinning in case the panic on the first
> > > > % * CPU is canceled.
> > > > % */
> > > > % if (panic_cpu != PCPU_GET(cpuid))
> > > >
> > > > This access doesn't use an atomic op.
> > > >
> > > > % while (atomic_cmpset_int(&panic_cpu, NOCPU,
> > > > % PCPU_GET(cpuid)) == 0)
> > > >
> > > > This access uses an atomic op. Not all atomic ops use memory barriers,
> > > > at least on i386. However, this one does, at least on i386.
> > > >
> > > > (I'm always confused about what atomic_any() without acq or release
> > > > means. Do they mean that you don't want a memory barrier (this is
> > > > what the mostly give, at least on i386), and if so, what use are
> > > > they? There are far too many atomic ops, for far too many never-used
> > > > widths, with alternative spellings to encourage using a wrong one.
> > > > cmpset is is especially confusing since it you can spell it as cmpset,
> > > > cmpset_acq or compset_rel and always get the barrier, at least on
> > > > i386. At least cmpset only supports 1 width, at least on i386.)
> > > >
> > > > % while (panic_cpu != NOCPU)
> > > >
> > > > This access doesn't use an atomic op.
> > > >
> > > > % ; /* nothing */
> > > > % #endif
> > > > % ...
> > > > % #ifdef RESTARTABLE_PANICS
> > > > % /* See if the user aborted the panic, in which case we continue.
> > > > */
> > > > % if (panicstr == NULL) {
> > > > % #ifdef SMP
> > > > % atomic_store_rel_int(&panic_cpu, NOCPU);
> > > >
> > > > This access uses an atomic op with a memory barrier, at least on i386.
> > > > Now its rel semantics are clear.
> > > >
> > > > panicstr is non-volatile and never accessed by an atomic op, so it
> > > > probably
> > > > strictly needs to be declared volatile even more than panic_cpu. I
> > > > think
> > >
> > > I agree about panicstr.
> > > But I am not sure if we have places in code (beyond panic function)
> > > itself where
> > > volatile vs. non-volatile would make any actual difference.
> > > But still.
> > >
> > > > the only thing that makes it work now is that it is bogusly pubic, and
> > > > compilers can't analyze the whole program yet -- if they could, then
> > > > they
Re: svn commit: r227310 - head/sys/fs/tmpfs
TMPFS is not usable without swap, it should have better algorithms to adjust
it's size, depending on amount of memory/swap available.
# swapoff -a
# swapinfo
Device 1K-blocks UsedAvail Capacity
# top
Mem: 253M Active, 282M Inact, 933M Wired, 3972K Cache, 135M Buf, 491M Free
Swap:
# df -h /tmp
FilesystemSizeUsed Avail Capacity Mounted on
tmpfs 436k436k 0B 100%/tmp
no free space on /tmp
# uname -a
FreeBSD gpr.drweb.com 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225446M: Thu Sep 8
17:30:46 MSK 2011
g...@gpr.drweb.com:/usr/obj/usr/src/freebsd-head/sys/DRW_A amd64
On Mon, Nov 07, 2011 at 04:21:50PM +, Marcel Moolenaar wrote:
> Author: marcel
> Date: Mon Nov 7 16:21:50 2011
> New Revision: 227310
> URL: http://svn.freebsd.org/changeset/base/227310
>
> Log:
> Don astbestos garment and remove the warning about TMPFS being experimental
> -- highly experimental even. So far the closest to a bug in TMPFS that
> people
> have gotten to relates to how ZFS can take away from the memory that TMPFS
> needs. One can argue that such is not a bug in TMPFS. Irrespective, even if
> there is a bug here and there in TMPFS, it's not in our own advantage to
> scare people away from using TMPFS. I for one have been using it, even with
> ZFS, very successfully.
>
> Modified:
> head/sys/fs/tmpfs/tmpfs_vfsops.c
>
> Modified: head/sys/fs/tmpfs/tmpfs_vfsops.c
> ==
> --- head/sys/fs/tmpfs/tmpfs_vfsops.c Mon Nov 7 15:43:11 2011
> (r227309)
> +++ head/sys/fs/tmpfs/tmpfs_vfsops.c Mon Nov 7 16:21:50 2011
> (r227310)
> @@ -156,9 +156,6 @@ tmpfs_mount(struct mount *mp)
> return EOPNOTSUPP;
> }
>
> - printf("WARNING: TMPFS is considered to be a highly experimental "
> - "feature in FreeBSD.\n");
> -
> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> ___
> svn-src-head@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r250700 - in head/sys: conf net netinet6 sys
On Thu, May 16, 2013 at 04:20:18PM +, Julian Elischer wrote: > +#define m_fibnumm_hdr.mh_nextpkt Are you sure this is correct? Shouldn't it be something like M_dat.MH.MH_pkthdr.fibnum or m_pkthdr.fibnum ? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r251741 - head/sys/contrib/dev/ath/ath_hal/ar9300
Replying to random ath commit. Now my ath wireless device does not work. It was broken some time after 8 Jun (after my last update at 8 Jun it worked, now after today's update to r251945 it does not). It spams log and console with messages: Jun 19 10:04:27 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:04:58 gpr last message repeated 101 times Jun 19 10:05:42 gpr last message repeated 143 times Jun 19 10:05:42 gpr kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing Jun 19 10:05:42 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:05:47 gpr last message repeated 11 times Jun 19 10:05:47 gpr kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing Jun 19 10:05:47 gpr kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing Jun 19 10:05:47 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:05:53 gpr last message repeated 19 times ... Jun 19 10:06:20 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:06:21 gpr last message repeated 4 times Jun 19 10:06:22 gpr kernel: ath0: ath_tx_should_swq_frame: f0:4f:7c:fc:b3:22: Node is asleep; sending mgmt (type=0, subtype=176) Jun 19 10:06:22 gpr kernel: ath0: ath_tx_should_swq_frame: f0:4f:7c:fc:b3:22: Node is asleep; sending mgmt (type=0, subtype=176) Jun 19 10:06:22 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:06:23 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:06:23 gpr kernel: ath0: ath_tx_node_wakeup: an=0xff8002322000: node was already awake Jun 19 10:06:24 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) Jun 19 10:06:25 gpr kernel: ath0: stuck beacon; resetting (bmiss count 4) # uname -a FreeBSD gpr.nnz-home.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r251945+1330981: Wed Jun 19 08:09:32 MSK 2013 g...@gpr.nnz-home.ru:/usr/obj/usr/src/freebsd-head/sys/GPR amd64 Boot log device info: Jun 19 10:04:18 gpr kernel: ath0: mem 0xfbdf-0xfbdf irq 19 at device 10.0 on pci0 Jun 19 10:04:18 gpr kernel: ath0: AR2413 mac 7.9 RF2413 phy 4.5 Jun 19 10:04:18 gpr kernel: ath0: 2GHz radio: 0x; 5GHz radio: 0x0056 # pciconf -lv ath0@pci0:0:10:0: class=0x02 card=0x2051168c chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212/AR5213 Wireless Network Adapter' class = network subclass = ethernet # rc.conf wlans_ath0="wlan0" create_args_wlan0="wlandev ath0 wlanmode hostap" ifconfig_wlan0="10.X.X.X/24" hostapd_enable="YES" I can do additional tests or submit more info, if necessary. On Fri, Jun 14, 2013 at 08:15:28AM +, Adrian Chadd wrote: > Author: adrian > Date: Fri Jun 14 08:15:28 2013 > New Revision: 251741 > URL: http://svnweb.freebsd.org/changeset/base/251741 > > Log: > The AR9300 HAL uses this config to program AR_PHY_SWITCH_COM_2 on AR9485 > NICs which have bluetooth coexistence enabled. > > The WB225 NIC has the common antenna switch configuration set to 0x0 which > disables all external switch bit setting. This obviously won't work when > doing coexistence. > > This value is a magic value from the windows .inf files. It _looks_ right > but I haven't yet verified it - unfortunately my AR9285+AR3012 BT combo > has an earlier BT device which doesn't actually _have_ firmware on it. > So I have to fix ath3kfw to handle loading in firmware into the newer > NICs before I can finish testing this. > > This may not hold true for CUS198, which is another custom AR9485 board. > > Modified: > head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c > > Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c > == > --- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c Fri Jun 14 > 08:13:21 2013(r251740) > +++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c Fri Jun 14 > 08:15:28 2013(r251741) > @@ -249,6 +249,9 @@ ar9300_attach_freebsd_ops(struct ath_hal > /* LNA diversity functions */ > ah->ah_divLnaConfGet = ar9300_ant_div_comb_get_config; > ah->ah_divLnaConfSet = ar9300_ant_div_comb_set_config; > + > + /* Setup HAL configuration defaults */ > + ah->ah_config.ath_hal_ant_ctrl_comm2g_switch_enable = 0x000bbb88; > } > > HAL_BOOL > ___ > svn-src-head@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Thu, Jun 20, 2013 at 11:49:13PM +0930, Daniel O'Connor wrote: > > On 20/06/2013, at 23:03, Julian Elischer wrote: > >> And do you think that the sort of user who is sufficiently engaged with > >> the project to do this is the sort of user who would not be willing to do > >> so if it meant installing the subversion port? If so, then there is a > >> clear case for svnlite. > > > > I think that it lowers the barrier.. once you start bringing ports into the > > picture you start running the risk of port revision hell. > > > If there is a statically linked port & corresponding package then the barrier > is almost as low, but has a few other advantages that other people have > listed. > > That approach has a small footprint (binary + man page), is always up to date > (so the VCS infrastructure is not tied to the earliest version of SVN) and > doesn't have any dependencies. svnlite (1.8.0-rc3 in base system) and subversion (1.7.10 from ports) are not interoperable, they create incompatible repositories (at least by default). Not a problem for me personally, I use git mirrors, just my 5 cents. Details below. Here the freebsd repo checked out by subversion port > svn info Path: . Working Copy Root Path: /usr/src/freebsd-head.svn URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 245668 Node Kind: directory Schedule: normal Last Changed Author: joel Last Changed Rev: 245667 Last Changed Date: 2013-01-19 11:07:05 +0400 (Sat, 19 Jan 2013) Now trying to work with svnlite: > svnlite info svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/usr/src/freebsd-head.svn' is too old (format 29) to work with client version '1.8.0-rc3 (Release Candidate 3)' (expects format 31). You need to upgrade the working copy first. Creating repo with svnlite and trying to run svn on it: > svnlite co http://svn.freebsd.org/base/head/bin/cat Acat/Makefile Acat/cat.1 Acat/cat.c Checked out revision 252033. > cd cat > svnlite info Path: . Working Copy Root Path: /tmp/src-test/cat URL: http://svn.freebsd.org/base/head/bin/cat Relative URL: ^/head/bin/cat Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 252033 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 249804 Last Changed Date: 2013-04-23 17:03:11 +0400 (Tue, 23 Apr 2013) > svn info svn: E155021: This client is too old to work with the working copy at '/tmp/src-test/cat' (format 31). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r237223 - head/sys/dev/fb
On Mon, Jun 18, 2012 at 07:54:11AM +, Poul-Henning Kamp wrote:
> Author: phk
> Date: Mon Jun 18 07:54:10 2012
> New Revision: 237223
> URL: http://svn.freebsd.org/changeset/base/237223
>
> Log:
> Fix the previous commit to only copy the data we were asked to and not
> twice as much.
>
> Spotted by: Taku YAMAMOTO
>
> Modified:
> head/sys/dev/fb/fbreg.h
>
> Modified: head/sys/dev/fb/fbreg.h
> ==
> --- head/sys/dev/fb/fbreg.h Mon Jun 18 07:43:23 2012(r237222)
> +++ head/sys/dev/fb/fbreg.h Mon Jun 18 07:54:10 2012(r237223)
> @@ -39,6 +39,7 @@
> static __inline void
> copyw(uint16_t *src, uint16_t *dst, size_t size)
> {
> + size >>= 1;
> while (size--)
> *dst++ = *src++;
> }
If size is odd, this does not copy the last byte. Not sure, whether this is
intended.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r242184 - in head: etc share/man/man5
Now squid startup script is unable to start squid
# pkg info -x ^squid
squid-3.2.3_1 HTTP Caching Proxy
# sysctl net.fibs
net.fibs: 1
# grep squid /etc/rc.conf
squid_enable="YES"
squid_pidfile="/var/squid/squid.pid"
squid_chdir="/var/squid"
# /usr/local/etc/rc.d/squid start
Starting squid.
setfib: NONE: invalid FIB (max 0)
Exit 1
/usr/local/etc/rc.d/squid: WARNING: failed to start squid
Exit 1
# sh -x /usr/local/etc/rc.d/squid start
... [skip] ...
+ debug 'run_rc_command: start_precmd: squid_setfib '
+ eval 'squid_setfib '
+ squid_setfib
+ sysctl net.fibs
+ [ xNONE != xNONE ]
+ return 0
+ _return=0
+ [ 0 -ne 0 ]
+ check_required_after start
+ local _f _args
+ return 0
+ return 0
+ check_startmsgs
+ [ -n '' ]
+ return 0
+ echo 'Starting squid.'
Starting squid.
+ [ -n '' ]
+ _doit='cd /var/squid && setfib -F NONE /usr/local/sbin/squid -f
/usr/local/etc/squid/squid.conf'
+ [ -n squid ]
+ _doit='su -m squid -c '\''sh -c "cd /var/squid && setfib -F NONE
/usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf"'\'
+ [ -n '' ]
+ _run_rc_doit 'su -m squid -c '\''sh -c "cd /var/squid && setfib -F NONE
/usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf"'\'
+ debug 'run_rc_command: doit: su -m squid -c '\''sh -c "cd /var/squid &&
setfib -F NONE /usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf"'\'
+ eval 'su -m squid -c '\''sh -c "cd /var/squid && setfib -F NONE
/usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf"'\'
+ su -m squid -c 'sh -c "cd /var/squid && setfib -F NONE /usr/local/sbin/squid
-f /usr/local/etc/squid/squid.conf"'
setfib: NONE: invalid FIB (max 0)
Exit 1
+ _return=1
+ [ 1 -ne 0 ]
+ [ -z '' ]
+ return 1
+ warn 'failed to start squid'
+ [ -x /usr/bin/logger ]
+ logger '/usr/local/etc/rc.d/squid: WARNING: failed to start squid'
+ echo '/usr/local/etc/rc.d/squid: WARNING: failed to start squid'
/usr/local/etc/rc.d/squid: WARNING: failed to start squid
+ return 1
Exit 1
On Sat, Oct 27, 2012 at 07:09:09PM +, Hiroki Sato wrote:
> Author: hrs
> Date: Sat Oct 27 19:09:09 2012
> New Revision: 242184
> URL: http://svn.freebsd.org/changeset/base/242184
>
> Log:
> Add setfib(1) support for services as _fib in rc.conf.
>
> Modified:
> head/etc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/etc/rc.subr
> ==
> --- head/etc/rc.subr Sat Oct 27 17:43:30 2012(r242183)
> +++ head/etc/rc.subr Sat Oct 27 19:09:09 2012(r242184)
> @@ -462,6 +462,8 @@ check_startmsgs()
> #NOTE: $flags from the parent environment
> #can be used to override this.
> #
> +#${name}_fib n Routing table number to run ${command} with.
> +#
> #${name}_nicen Nice level to run ${command} at.
> #
> #${name}_usern User to run ${command} as, using su(1) if not
> @@ -640,7 +642,8 @@ run_rc_command()
> fi
> eval _chdir=\$${name}_chdir _chroot=\$${name}_chroot \
> _nice=\$${name}_nice_user=\$${name}_user \
> - _group=\$${name}_group _groups=\$${name}_groups
> + _group=\$${name}_group _groups=\$${name}_groups \
> + _fib=\$${name}_fib
>
> if [ -n "$_user" ]; then# unset $_user if running as that user
> if [ "$_user" = "$(eval $IDCMD)" ]; then
> @@ -721,11 +724,13 @@ run_rc_command()
> if [ -n "$_chroot" ]; then
> _doit="\
> ${_nice:+nice -n $_nice }\
> +${_fib:+setfib -F $_fib }\
> chroot ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\
> $_chroot $command $rc_flags $command_args"
> else
> _doit="\
> ${_chdir:+cd $_chdir && }\
> +${_fib:+setfib -F $_fib }\
> $command $rc_flags $command_args"
> if [ -n "$_user" ]; then
> _doit="su -m $_user -c 'sh -c \"$_doit\"'"
>
> Modified: head/share/man/man5/rc.conf.5
> ==
> --- head/share/man/man5/rc.conf.5 Sat Oct 27 17:43:30 2012
> (r242183)
> +++ head/share/man/man5/rc.conf.5 Sat Oct 27 19:09:09 2012
> (r242184)
> @@ -24,7 +24,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd July 22, 2012
> +.Dd October 27, 2012
> .Dt RC.CONF 5
> .Os
> .Sh NAME
> @@ -179,6 +179,11 @@ Run the service under this user account.
> .Pq Vt str
> Run the chrooted service under this system group. Unlike the _user
> setting, this setting has no effect if the service is not chrooted.
> +.It Ao Ar name Ac Ns Va _fib
> +.Pq Vt int
> +The
> +.Xr setfib 1
> +value to run the service under.
> .It Ao Ar name Ac Ns Va _nice
> .Pq Vt int
> The
> ___
> svn-src-head@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-hea
Re: svn commit: r237223 - head/sys/dev/fb
On Tue, Jun 19, 2012 at 05:27:11AM +, Poul-Henning Kamp wrote:
> In message <68fbe843-7337-4c90-b01f-e0caabb62...@gsoft.com.au>, "Daniel
> O'Conno
> r" writes:
>
> >> If size is odd, this does not copy the last byte. Not sure, whether =
> >this is intended.
>
> Feel free to improve...
Index: fbreg.h
===
--- fbreg.h (revision 237289)
+++ fbreg.h (working copy)
@@ -39,9 +39,12 @@
static __inline void
copyw(uint16_t *src, uint16_t *dst, size_t size)
{
+ const int is_odd = (size & 0x1);
size >>= 1;
while (size--)
*dst++ = *src++;
+ if (is_odd)
+ *(char*)dst = *(char*)src; // copy last byte
}
#define bcopy_io(s, d, c) copyw((void*)(s), (void*)(d), (c))
#define bcopy_toio(s, d, c) copyw((void*)(s), (void*)(d), (c))
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r237223 - head/sys/dev/fb
On Wed, Jun 20, 2012 at 05:59:07PM +0930, Daniel O'Connor wrote:
>
> On 20/06/2012, at 17:11, Gennady Proskurin wrote:
> > On Tue, Jun 19, 2012 at 05:27:11AM +, Poul-Henning Kamp wrote:
> >> In message <68fbe843-7337-4c90-b01f-e0caabb62...@gsoft.com.au>, "Daniel
> >> O'Conno
> >> r" writes:
> >>
> >>>> If size is odd, this does not copy the last byte. Not sure, whether =
> >>> this is intended.
> >>
> >> Feel free to improve...
> >
> >
>
>
> Surely if you pass it an odd size you made a mistake - either the wrong
> function was used or you computed the size incorrectly.
Functions are called "bcopy_io" and so, such names tell nothing about data size
they work with ("copyw" tells something). If it is not supposed to work with
odd size, I agree, my patch is overkill, something like KASSERT (or just
one-line comment) is better.
I just wanted to be sure, that potential bug in this code is known to
developpers.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r240156 - head/lib/libproc
On Thu, Sep 06, 2012 at 03:19:49AM +, Rui Paulo wrote:
> Author: rpaulo
> Date: Thu Sep 6 03:19:48 2012
> New Revision: 240156
> URL: http://svn.freebsd.org/changeset/base/240156
>
> Log:
> Add support for demangling C++ symbols. This requires linking libproc with
> libc++rt/libsupc++.
>
> Discussed with: theraven
>
> Modified:
> head/lib/libproc/Makefile
> head/lib/libproc/proc_sym.c
>
> Modified: head/lib/libproc/Makefile
> ==
> --- head/lib/libproc/Makefile Thu Sep 6 02:07:58 2012(r240155)
> +++ head/lib/libproc/Makefile Thu Sep 6 03:19:48 2012(r240156)
> @@ -1,5 +1,7 @@
> # $FreeBSD$
>
> +.include
> +
> LIB= proc
>
> SRCS=proc_bkpt.c \
> @@ -13,6 +15,14 @@ INCS= libproc.h
>
> CFLAGS+= -I${.CURDIR}
>
> +.if ${MK_LIBCPLUSPLUS} != "no"
> +LDADD+= -lcxxrt
> +DPADD+= ${LIBCXXRT}
> +.else
> +LDADD+= -lsupc++
> +DPADD+= ${LIBSTDCPLUSPLUS}
> +.endif
> +
> SHLIB_MAJOR= 2
>
> WITHOUT_MAN=
>
> Modified: head/lib/libproc/proc_sym.c
> ==
> --- head/lib/libproc/proc_sym.c Thu Sep 6 02:07:58 2012
> (r240155)
> +++ head/lib/libproc/proc_sym.c Thu Sep 6 03:19:48 2012
> (r240156)
> @@ -46,6 +46,8 @@
>
> #include "_libproc.h"
>
> +extern char *__cxa_demangle(const char *, char *, size_t *, int *);
> +
> static void proc_rdl2prmap(rd_loadobj_t *, prmap_t *);
>
> static void
> @@ -266,7 +268,11 @@ proc_addr2sym(struct proc_handle *p, uin
> if (addr >= rsym && addr <= (rsym + sym.st_size)) {
> s = elf_strptr(e, dynsymstridx, sym.st_name);
> if (s) {
> - strlcpy(name, s, namesz);
> + if (strlen(s) > 2 &&
> + s[0] == '_' && s[1] == 'Z')
checking "strlen(s) > 2" is useless and not optimal here, you can omit it
completely
checking s[0] and s[1] is enough, it implies that length is >=2
you may add something like "s[2] != 0" if length should be strictly >2
> + __cxa_demangle(s, name, &namesz, NULL);
> + else
> + strlcpy(name, s, namesz);
> memcpy(symcopy, &sym, sizeof(sym));
> /*
>* DTrace expects the st_value to contain
> @@ -302,7 +308,11 @@ symtab:
> if (addr >= rsym && addr <= (rsym + sym.st_size)) {
> s = elf_strptr(e, symtabstridx, sym.st_name);
> if (s) {
> - strlcpy(name, s, namesz);
> + if (strlen(s) > 2 &&
> + s[0] == '_' && s[1] == 'Z')
> + __cxa_demangle(s, name, &namesz, NULL);
> + else
> + strlcpy(name, s, namesz);
the same here
> memcpy(symcopy, &sym, sizeof(sym));
> /*
>* DTrace expects the st_value to contain
> ___
> svn-src-head@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r246877 - head/sys/ufs/ffs
May be a dumb question, but I want to be explicit here.
Can system before this commit crash here or filesystem corruption happen during
ordinary work? (I mean no power loss and no crashes in other kernel code)
Or filesystem can be corrupted only if system crashes by other means (power
loss or something) during inode block allocation?
On Sat, Feb 16, 2013 at 03:11:40PM +, Kirk McKusick wrote:
> Author: mckusick
> Date: Sat Feb 16 15:11:40 2013
> New Revision: 246877
> URL: http://svnweb.freebsd.org/changeset/base/246877
>
> Log:
> The UFS2 filesystem allocates new blocks of inodes as they are needed.
> When a cylinder group runs short of inodes, a new block for inodes is
> allocated, zero'ed, and written to the disk. The zero'ed inodes must
> be on the disk before the cylinder group can be updated to claim them.
> If the cylinder group claiming the new inodes were written before the
> zero'ed block of inodes, the system could crash with the filesystem in
> an unrecoverable state.
>
> Rather than adding a soft updates dependency to ensure that the new
> inode block is written before it is claimed by the cylinder group
> map, we just do a barrier write of the zero'ed inode block to ensure
> that it will get written before the updated cylinder group map can
> be written. This change should only slow down bulk loading of newly
> created filesystems since that is the primary time that new inode
> blocks need to be created.
>
> Reported by: Robert Watson
> Reviewed by: kib
> Tested by: Peter Holm
>
> Modified:
> head/sys/ufs/ffs/ffs_alloc.c
>
> Modified: head/sys/ufs/ffs/ffs_alloc.c
> ==
> --- head/sys/ufs/ffs/ffs_alloc.c Sat Feb 16 14:51:30 2013
> (r246876)
> +++ head/sys/ufs/ffs/ffs_alloc.c Sat Feb 16 15:11:40 2013
> (r246877)
> @@ -1861,7 +1861,6 @@ gotit:
> /*
>* Check to see if we need to initialize more inodes.
>*/
> - ibp = NULL;
> if (fs->fs_magic == FS_UFS2_MAGIC &&
> ipref + INOPB(fs) > cgp->cg_initediblk &&
> cgp->cg_initediblk < cgp->cg_niblk) {
> @@ -1874,6 +1873,16 @@ gotit:
> dp2->di_gen = arc4random() / 2 + 1;
> dp2++;
> }
> + /*
> + * Rather than adding a soft updates dependency to ensure
> + * that the new inode block is written before it is claimed
> + * by the cylinder group map, we just do a barrier write
> + * here. The barrier write will ensure that the inode block
> + * gets written before the updated cylinder group map can be
> + * written. The barrier write should only slow down bulk
> + * loading of newly created filesystems.
> + */
> + babarrierwrite(ibp);
> cgp->cg_initediblk += INOPB(fs);
> }
> UFS_LOCK(ump);
> @@ -1892,8 +1901,6 @@ gotit:
> if (DOINGSOFTDEP(ITOV(ip)))
> softdep_setup_inomapdep(bp, ip, cg * fs->fs_ipg + ipref, mode);
> bdwrite(bp);
> - if (ibp != NULL)
> - bawrite(ibp);
> return ((ino_t)(cg * fs->fs_ipg + ipref));
> }
>
> ___
> svn-src-head@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r249484 - head/lib
Here is the quote from r231336 commit message:
===
commit be984b719cbcb225dc4afaf9f52b38fb882a09d3
Author: kientzle
Date: Fri Feb 10 05:05:42 2012 +
Implement -print-file-name=include (which is undocumented
but used by some Linux boot loaders). This option prints
out the directory holding the include files needed by
a freestanding program. The default implementation of
this doesn't work on FreeBSD because of the different
include file layout. But it's easy to implement:
just return /usr/include (or the cross-compiling equivalent).
===
It turns out, that now we create useless symlink /usr/lib/include just to ease
support of "some Linux boot loaders"?
I do not have full knowledge about the issue, so excuse me if I misunderstood
something.
On Sun, Apr 14, 2013 at 07:13:52PM +, Tim Kientzle wrote:
> Author: kientzle
> Date: Sun Apr 14 19:13:51 2013
> New Revision: 249484
> URL: http://svnweb.freebsd.org/changeset/base/249484
>
> Log:
> Install a symlink
> /usr/lib/include ==> /usr/include
>
> This fixes -print-file-name=include in clang (and is
> arguably a better way to fix the same issue in GCC than
> the change I made in r231336).
>
> MFC after: 1 week
>
> Modified:
> head/lib/Makefile
>
> Modified: head/lib/Makefile
> ==
> --- head/lib/Makefile Sun Apr 14 18:36:30 2013(r249483)
> +++ head/lib/Makefile Sun Apr 14 19:13:51 2013(r249484)
> @@ -252,4 +252,7 @@ _libusbhid= libusbhid
> _libusb= libusb
> .endif
>
> +afterinstall:
> + ln -fs ../include ${DESTDIR}/usr/lib/include
> +
> .include
> ___
> svn-src-head@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
