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 jul...@freebsd.org 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: 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: Atheros 5212 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: 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: r249484 - head/lib
Here is the quote from r231336 commit message:
===
commit be984b719cbcb225dc4afaf9f52b38fb882a09d3
Author: kientzle kientzle@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
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 bsd.subdir.mk
___
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: 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 name_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-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 bsd.own.mk
+
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: 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... fb.patch 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: 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: 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: 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 discussed this with kib and the idea is that atomic operation is not needed
in
that place and volatile is sufficient, because we don't need barrier semantics
there and only want to ensure that variable is reloaded from memory.
