svn commit: r222518 - head/sys/cddl/compat/opensolaris/kern
Author: pjd Date: Tue May 31 07:02:49 2011 New Revision: 222518 URL: http://svn.freebsd.org/changeset/base/222518 Log: Imagine situation where a security problem is found in setuid binary. User upgrades his system to fix the problem, but if he has any ZFS snapshots for the file system which contains problematic binary, any user can mount the snapshot and execute vulnerable binary. Prevent this from happening by always mounting snapshots with setuid turned off. MFC after:2 weeks Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c == --- head/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c Tue May 31 05:00:45 2011(r222517) +++ head/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c Tue May 31 07:02:49 2011(r222518) @@ -172,6 +172,11 @@ mount_snapshot(kthread_t *td, vnode_t ** */ mp->mnt_flag |= MNT_RDONLY; /* +* We don't want snapshots to allow access to vulnerable setuid +* programs, so we turn off setuid when mounting snapshots. +*/ + mp->mnt_flag |= MNT_NOSUID; + /* * We don't want snapshots to be visible in regular * mount(8) and df(1) output. */ ___ 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 commit: r222519 - head/usr.sbin/usbdump
Author: bcr (doc committer) Date: Tue May 31 07:13:07 2011 New Revision: 222519 URL: http://svn.freebsd.org/changeset/base/222519 Log: Minor wording adjustments to usbdump(8). PR: docs/157317 Submitted by: Warren Block (wblock at wonkity dot com) Reviewed by: hps@ MFC after:5 days Modified: head/usr.sbin/usbdump/usbdump.8 Modified: head/usr.sbin/usbdump/usbdump.8 == --- head/usr.sbin/usbdump/usbdump.8 Tue May 31 07:02:49 2011 (r222518) +++ head/usr.sbin/usbdump/usbdump.8 Tue May 31 07:13:07 2011 (r222519) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd December 4, 2010 +.Dd May 31, 2011 .Dt USBDUMP 8 .Os .Sh NAME @@ -63,16 +63,16 @@ Write the raw packets to .Ar file . .El .Sh EXAMPLES -Captures USB raw packets on usbus2: +Capture the USB raw packets on usbus2: .Pp .Dl "usbdump -i usbus2 -s 256 -v" .Pp -Dumps the USB raw packets of usbus2 into the file without packet +Dump the USB raw packets of usbus2 into the file without packet size limit: .Pp .Dl "usbdump -i usbus2 -s 0 -w /tmp/dump_pkts" .Pp -Read the USB raw packets from previous file: +Read and display the USB raw packets from previous file: .Pp .Dl "usbdump -r /tmp/dump_pkts -v" .Sh OUTPUT FORMAT ___ 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: r222466 - head/sbin/umount
On Mon, 30 May 2011, Rick Macklem wrote: On Mon, May 30, 2011 at 01:48:53PM +0100, Robert Watson wrote: On Sun, 29 May 2011, Rick Macklem wrote: Modify the umount(8) command so that it doesn't do a sync(2) syscall before unmount(2) for the "-f" case. This avoids a forced dismount from getting stuck for an NFS mountpoint in sync() when the server is not responsive. With this commit, forced dismounts should normally work for the NFS clients, but can take up to about 1minute to complete. I'm actually a bit confused about why umount(8) calls sync(2) at all: surely it's the responsibility of the file system, rather than the userland tool, to ensure consistency subject to file system configuration and unmount-time flags? This call is from the same department as triple-sync before reboot, IMO. Hehe. I'm so old, I do two syncs, as required by 6th Edition.:-) I am apparently not so old, since my reboot script only has 1 sync :-). I assumed the sync() was meant to be an optimization (given the comment for it) in the sense that it would get the writes of dirty blocks started "right away". However, given the short period of time from the the sync(2) It is only an optimization. Any number of syncs are useless for actually syncing the system, since sync(2) only does an async sync (it returns without waiting for most writes to complete). As you pointed out later in this thread, unmount(2) does a sync that works -- a sync sync -- before doing the unmount proper. It does this irrespective of the force flag: % if (((mp->mnt_flag & MNT_RDONLY) || %(error = VFS_SYNC(mp, MNT_WAIT)) == 0) || (flags & MNT_FORCE) != 0) % error = VFS_UNMOUNT(mp, flags); The force flag doesn't mean that i/o's are forced to complete. It only means that open files are forced to be closed (and a few related things). This can be seen here. We wait (potentially forever) for any existing writes to complete. Only then do we look at the force flag and bale out if the sync failed and the force flag is _not_ set. Most i/o problems will cause hangs in this sync, and the force flag won't help. But if we somehow get past this sync, and have i/o problems, then honoring the force flag and continuing gives even more fragility, since we have almost passed the point of being able to give up after an error (this point is typically very early in VFS_UNMOUNT()). Many file systems have had bugs in this area. Before 1999/01/22 (vfs_bio.c 1.196), b*write() gave up after an i/o error, and pretended to succeed. Both recoverable and unrecoverable errors were mishandled. This avoided many hangs in VFS_SYNC(). When this was partially fixed, many VFS_SYNC()s couldn't handle the errors, and paniced when they should have looped endlessly. Now I think they mostly loop endlessly, even for unrecoverable errors when they shouldn't. My version attempts to fix vfs_bio.c 1.196 by still giving up after an unrecoverable i/o error. This reduced endless loops but gave more panics in other places that can't handle the errors, mainly in the VFS_UMOUNT() call in the above -- many file systems saw the errors after the point where it is posible to either recover from them or loop endlessly on them, and then a panic occurred soon after the VFS_UMOUNT() returned with a half-complete unmount(), since neither a success or a failure return can indicate this state. call to the unmount(2) call, I'm not convinced it makes a significant difference. (I thought of just getting rid of it, but figured it was harmless for the non "-f" case and might matter for a buggy fs that doesn't get the unmount(2) quite right. ie. Same argument as doing the triple-sync, just to be sure.) I think you shouldn't have touched umount(8). The sync can still hang or just be in progress when unmount(2) is called, and unmount(2) still does its own sync, so nfs_unmount() must still handle hanging syncs in some way. My reboot script has more details related to this: %%% sh
Re: svn commit: r222084 - head/contrib/gperf/src
On Wed, 18 May 2011 m...@freebsd.org wrote:
On Wed, May 18, 2011 at 2:31 PM, Dimitry Andric wrote:
On 2011-05-18 23:16, Pawel Jakub Dawidek wrote:
On Wed, May 18, 2011 at 09:06:20PM +, Ben Laurie wrote:
Author: benl
Date: Wed May 18 21:06:20 2011
New Revision: 222084
URL: http://svn.freebsd.org/changeset/base/222084
Log:
? Fix clang warnings.
? Approved by: philip (mentor)
[...]
- ? ? ? ? ? ?fprintf (stderr, " by changing asso_value['%c'] (char #%d)
to %d\n",
+ ? ? ? ? ? ?fprintf (stderr, " by changing asso_value['%c'] (char #%zd)
to %d\n",
? ? ? ? ? ? ? ? ? ? ? *p, p - union_set + 1, asso_values[(unsigned
char)(*p)]);
Hmm, both 'p' and 'union_set' are 'char *' and %zd is for ssize_t. It is
a bit strange that it fixes the warning.
If you subtract two pointers, such as in this case, you get a ptrdiff_t.
Strictly, this doesn't have to be exactly the same type as ssize_t, but
in practice it will almost always be.
You can also cast the result to intmax_t, and use %jd, then it will
always be correct, but possibly have some small overhead.
Or you can use %td which is the C99 conversion specifier for ptrdiff_t.
Of course this is the only correct fix.
All the changes are wrong IMO. Apart from being unmaintainable since they
are in dusty contrib code:
% Modified: head/contrib/gperf/src/gen-perf.cc
% ==
% --- head/contrib/gperf/src/gen-perf.ccWed May 18 21:04:29 2011
(r222083)
% +++ head/contrib/gperf/src/gen-perf.ccWed May 18 21:06:20 2011
(r222084)
% @@ -246,7 +246,7 @@ Gen_Perf::change (List_Node *prior, List
%{
% if (option[DEBUG])
%{
% -fprintf (stderr, " by changing asso_value['%c'] (char #%d) to
%d\n",
% +fprintf (stderr, " by changing asso_value['%c'] (char #%zd) to
%d\n",
% *p, p - union_set + 1, asso_values[(unsigned
char)(*p)]);
% fflush (stderr);
%}
%
%td
% Modified: head/contrib/gperf/src/key-list.cc
% ==
% --- head/contrib/gperf/src/key-list.ccWed May 18 21:04:29 2011
(r222083)
% +++ head/contrib/gperf/src/key-list.ccWed May 18 21:06:20 2011
(r222084)
% @@ -497,8 +497,8 @@ Key_List::merge (List_Node *list1, List_
%*resultp = list1;
%break;
% }
% - if (occurrence_sort && list1->occurrence < list2->occurrence
% - || hash_sort && list1->hash_value > list2->hash_value)
% + if ((occurrence_sort && list1->occurrence < list2->occurrence)
% + || (hash_sort && list1->hash_value > list2->hash_value))
% {
%*resultp = list2;
%resultp = &list2->next; list2 = list1; list1 = *resultp;
It is a compiler bug to warn about precedence when there is no problem
with precedence, as here for && vs ||. clang recently became even
more broken than gcc for this -- it now warns even without -Wparentheses
(or -Wall, which implies -Wparentheses) in CFLAGS, so it issues broken
warning at very low WARNS levels (for WARNS=1, maybe even with no
WARNS).
% @@ -1035,17 +1035,16 @@ Key_List::output_hash_function (void)
%if (option[CPLUSPLUS])
% printf ("%s::", option.get_class_name ());
%printf ("%s ", option.get_hash_name ());
% - printf (option[KRC] ?
% - "(str, len)\n"
% -" register char *str;\n"
% -" register unsigned int len;\n" :
% - option[C] ?
% - "(str, len)\n"
% -" register const char *str;\n"
% -" register unsigned int len;\n" :
% - option[ANSIC] | option[CPLUSPLUS] ?
% - "(register const char *str, register unsigned int len)\n" :
% - "");
% + if (option[KRC] || option[C] || option [ANSIC] || option[CPLUSPLUS])
% +printf (option[KRC] ?
% + "(str, len)\n"
% + " register char *str;\n"
% + " register unsigned int len;\n" :
% + option[C] ?
% + "(str, len)\n"
% + " register const char *str;\n"
% + " register unsigned int len;\n" :
% + "(register const char *str, register unsigned int len)\n");
%
%/* Note that when the hash function is called, it has already been verified
% that min_key_len <= len <= max_key_len. */
Far too invasive, and I can't even see a problem in the original. The
original has an empty format for the default case. This is perfectly valid,
an serves as documentation for the default case. The expression is a
"computed switch" statement. The change also obfuscates the pseudo-cases
option[ANSIC] and option[CPLUSPLUS] as the default pseudo-case (after
filtering out the actual default case before the pseudo-switch.
% @@ -1442,7 +1441,7 @@ Key_List::output_lookup_array (void)
%
%if (option[D
svn commit: r222520 - head/sys/cam/ata
Author: mav
Date: Tue May 31 09:22:52 2011
New Revision: 222520
URL: http://svn.freebsd.org/changeset/base/222520
Log:
Add quirks to hint 4K physical sector (Advanced Format) for ATA disks not
reporting it properly (none? of known disks now).
Hitachi and WDC AF disks seem could be identified more or less formally.
For Seagate and Samsung enumerate some found models/series.
For other disks it can be forced with kern.cam.ada.X.quirks=1 tunable.
Modified:
head/sys/cam/ata/ata_da.c
Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c Tue May 31 07:13:07 2011(r222519)
+++ head/sys/cam/ata/ata_da.c Tue May 31 09:22:52 2011(r222520)
@@ -89,7 +89,8 @@ typedef enum {
} ada_flags;
typedef enum {
- ADA_Q_NONE = 0x00
+ ADA_Q_NONE = 0x00,
+ ADA_Q_4K= 0x01,
} ada_quirks;
typedef enum {
@@ -154,6 +155,86 @@ struct ada_quirk_entry {
static struct ada_quirk_entry ada_quirk_table[] =
{
{
+ /* Hitachi Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "Hitachi H??E3*", "*"
},
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Samsung Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "SAMSUNG HD204UI*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Seagate Barracuda Green Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "STDL*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Seagate Momentus Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "ST9500423AS*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Seagate Momentus Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "ST9500424AS*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Seagate Momentus Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "ST9750420AS*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Seagate Momentus Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "ST9750422AS*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* Seagate Momentus Thin Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "ST???LT*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Caviar Green Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WDRS*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Caviar Green Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WDRX*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Caviar Green Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD??RS*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Caviar Green Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD??RX*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Scorpio Black Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD???PKT*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Scorpio Black Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD?PKT*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Scorpio Blue Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD???PVT*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Scorpio Blue Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD?PVT*", "*" },
+ /*quirks*/ADA_Q_4K
+ },
+ {
/* Default */
{
T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED,
@@ -740,7 +821,7 @@ adaregister(struct cam_periph *periph, v
struct disk_params *dp;
caddr_t match;
u_int maxio;
- int legacy_id;
+ int legacy_id, quirks;
cgd = (struct ccb_getdev *)arg;
if (periph == NULL) {
@@ -815,6 +896,11 @@ adaregister(struct cam_periph *periph, v
*/
(void)cam_periph_hold(periph, PRIBIO);
mtx_unlock(periph->sim->mtx);
+ snprintf(announce_buf, sizeof(announce_buf),
+ "kern.cam.ada.%d.quirks", periph->unit_number);
+ quirks = softc->quirks;
+ TUNABLE_INT_FETCH(announce_buf, &quirks);
+ softc->quirks = q
svn commit: r222523 - head/share/man/man7
Author: nwhitehorn Date: Tue May 31 12:59:15 2011 New Revision: 222523 URL: http://svn.freebsd.org/changeset/base/222523 Log: It is generally considered useful for release media to have kernels on them. Submitted by: joel Modified: head/share/man/man7/release.7 Modified: head/share/man/man7/release.7 == --- head/share/man/man7/release.7 Tue May 31 12:54:32 2011 (r222522) +++ head/share/man/man7/release.7 Tue May 31 12:59:15 2011 (r222523) @@ -65,7 +65,9 @@ and should have experience upgrading sys The release build process requires that .Pa /usr/obj be populated with the output of -.Dq Li "make buildworld" . +.Dq Li "make buildworld" +and +.Dq Li "make buildkernel" . This is necessary to provide the object files for the release or, when using .Pa generate-release.sh , @@ -294,7 +296,7 @@ The following sequence of commands can b cd /usr svn co svn://svn.freebsd.org/base/head src cd src -make buildworld +make buildworld buildkernel cd release make release make install DESTDIR=/var/freebsd-snapshot ___ 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 commit: r222527 - head/sbin/ifconfig
Author: bz
Date: Tue May 31 14:40:21 2011
New Revision: 222527
URL: http://svn.freebsd.org/changeset/base/222527
Log:
Conditionally compile in the af_inet and af_inet6, af_nd6 modules.
If compiled in for dual-stack use, test with feature_present(3)
to see if we should register the IPv4/IPv6 address family related
options.
In case there is no "inet" support we would love to go with the
usage() and make the address family mandatory (as it is for anything
but inet in theory). Unfortunately people are used to
ifconfig IF up/down
etc. as well, so use a fallback of "link". Adjust the man page
to reflect these minor details.
Improve error handling printing a warning in addition to the usage
telling that we do not know the given address family in two places.
Reviewed by: hrs, rwatson
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after:2 weeks
Modified:
head/sbin/ifconfig/Makefile
head/sbin/ifconfig/af_inet.c
head/sbin/ifconfig/af_inet6.c
head/sbin/ifconfig/af_nd6.c
head/sbin/ifconfig/ifconfig.8
head/sbin/ifconfig/ifconfig.c
Modified: head/sbin/ifconfig/Makefile
==
--- head/sbin/ifconfig/Makefile Tue May 31 14:18:10 2011(r222526)
+++ head/sbin/ifconfig/Makefile Tue May 31 14:40:21 2011(r222527)
@@ -15,10 +15,16 @@ SRCS= ifconfig.c # base support
# of the toolchain.
#
SRCS+= af_link.c # LLC support
+.if ${MK_INET_SUPPORT} != "no"
SRCS+= af_inet.c # IPv4 support
+.endif
+.if ${MK_INET6_SUPPORT} != "no"
SRCS+= af_inet6.c # IPv6 support
+.endif
SRCS+= af_atalk.c # AppleTalk support
+.if ${MK_INET6_SUPPORT} != "no"
SRCS+= af_nd6.c# ND6 support
+.endif
SRCS+= ifclone.c # clone device support
SRCS+= ifmac.c # MAC support
@@ -38,6 +44,12 @@ SRCS+= ifpfsync.c # pfsync(4) support
SRCS+= ifbridge.c # bridge support
SRCS+= iflagg.c# lagg support
+.if ${MK_INET6_SUPPORT} != "no"
+CFLAGS+= -DINET6
+.endif
+.if ${MK_INET_SUPPORT} != "no"
+CFLAGS+= -DINET
+.endif
.if ${MK_IPX_SUPPORT} != "no" && !defined(RELEASE_CRUNCH)
SRCS+= af_ipx.c# IPX support
DPADD+=${LIBIPX}
Modified: head/sbin/ifconfig/af_inet.c
==
--- head/sbin/ifconfig/af_inet.cTue May 31 14:18:10 2011
(r222526)
+++ head/sbin/ifconfig/af_inet.cTue May 31 14:40:21 2011
(r222527)
@@ -200,5 +200,7 @@ static struct afswtch af_inet = {
static __constructor void
inet_ctor(void)
{
+ if (!feature_present("inet"))
+ return;
af_register(&af_inet);
}
Modified: head/sbin/ifconfig/af_inet6.c
==
--- head/sbin/ifconfig/af_inet6.c Tue May 31 14:18:10 2011
(r222526)
+++ head/sbin/ifconfig/af_inet6.c Tue May 31 14:40:21 2011
(r222527)
@@ -541,6 +541,9 @@ inet6_ctor(void)
#defineN(a)(sizeof(a) / sizeof(a[0]))
size_t i;
+ if (!feature_present("inet6"))
+ return;
+
for (i = 0; i < N(inet6_cmds); i++)
cmd_register(&inet6_cmds[i]);
af_register(&af_inet6);
Modified: head/sbin/ifconfig/af_nd6.c
==
--- head/sbin/ifconfig/af_nd6.c Tue May 31 14:18:10 2011(r222526)
+++ head/sbin/ifconfig/af_nd6.c Tue May 31 14:40:21 2011(r222527)
@@ -225,5 +225,9 @@ static struct afswtch af_nd6 = {
static __constructor void
nd6_ctor(void)
{
+
+ if (!feature_present("inet6"))
+ return;
+
af_register(&af_nd6);
}
Modified: head/sbin/ifconfig/ifconfig.8
==
--- head/sbin/ifconfig/ifconfig.8 Tue May 31 14:18:10 2011
(r222526)
+++ head/sbin/ifconfig/ifconfig.8 Tue May 31 14:40:21 2011
(r222527)
@@ -28,7 +28,7 @@
.\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94
.\" $FreeBSD$
.\"
-.Dd March 20, 2011
+.Dd May 31, 2011
.Dt IFCONFIG 8
.Os
.Sh NAME
@@ -42,7 +42,7 @@
.Op Fl n
.Ar interface
.Op Cm create
-.Op Ar address_family
+.Ar address_family
.Oo
.Ar address
.Op Ar dest_address
@@ -165,8 +165,10 @@ and
.Dq link .
.\" and
.\" .Dq ns .
-The default is
-.Dq inet .
+The default if available is
+.Dq inet
+or otherwise
+.Dq link .
.Dq ether
and
.Dq lladdr
Modified: head/sbin/ifconfig/ifconfig.c
==
--- head/sbin/ifconfig/ifconfig.c Tue May 31 14:18:10 2011
(r222526)
+++ head/sbin/ifconfig/ifconfig.c Tue May 31 14:40:21 2011
(r222527)
@@ -220,8 +220,10 @@ main(int argc, char *argv[])
Re: svn commit: r222084 - head/contrib/gperf/src
On 18/05/2011 22:16, Pawel Jakub Dawidek wrote: > On Wed, May 18, 2011 at 09:06:20PM +, Ben Laurie wrote: >> Author: benl >> Date: Wed May 18 21:06:20 2011 >> New Revision: 222084 >> URL: http://svn.freebsd.org/changeset/base/222084 >> >> Log: >> Fix clang warnings. >> >> Approved by: philip (mentor) > [...] >> -fprintf (stderr, " by changing asso_value['%c'] (char #%d) to >> %d\n", >> +fprintf (stderr, " by changing asso_value['%c'] (char #%zd) to >> %d\n", >> *p, p - union_set + 1, asso_values[(unsigned >> char)(*p)]); > > Hmm, both 'p' and 'union_set' are 'char *' and %zd is for ssize_t. It is > a bit strange that it fixes the warning. Why? The difference between two pointers is ssize_t, surely? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff ___ 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 commit: r222528 - in head/usr.sbin/pc-sysinstall: backend backend-query
Author: bz
Date: Tue May 31 15:02:30 2011
New Revision: 222528
URL: http://svn.freebsd.org/changeset/base/222528
Log:
Start teaching pc-sysinstall about IPv6.
Add some additional empty string checks for IPv4 and try to configure
a netmask along with the address rather than doing things twice.
Contrary to AUTO-DHCP, IPv6-SLAAC will accept static configuration
as well, which we will use at least for resolv.conf currently and
if we were given a static address configure that as an alias as well.
The pc-sysinstaller changes going along were committed to PC-BSD as r10773.
Reviewed by: kmoore
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after:20 days
Modified:
head/usr.sbin/pc-sysinstall/backend-query/enable-net.sh
head/usr.sbin/pc-sysinstall/backend-query/test-netup.sh
head/usr.sbin/pc-sysinstall/backend/functions-networking.sh
Modified: head/usr.sbin/pc-sysinstall/backend-query/enable-net.sh
==
--- head/usr.sbin/pc-sysinstall/backend-query/enable-net.sh Tue May 31
14:40:21 2011(r222527)
+++ head/usr.sbin/pc-sysinstall/backend-query/enable-net.sh Tue May 31
15:02:30 2011(r222528)
@@ -1,6 +1,11 @@
#!/bin/sh
#-
# Copyright (c) 2010 iXsystems, Inc. All rights reserved.
+# Copyright (c) 2011 The FreeBSD Foundation
+# All rights reserved.
+#
+# Portions of this software were developed by Bjoern Zeeb
+# under sponsorship from the FreeBSD Foundation.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
@@ -40,23 +45,67 @@ NETMASK="$3"
DNS="$4"
GATEWAY="$5"
MIRRORFETCH="$6"
+IPV6="$7"
+IPV6GATE="$8"
+IPV6DNS="$9"
if [ -z "${NIC}" ]
then
- echo "ERROR: Usage enable-net "
+ echo "ERROR: Usage enable-net " \
+ " "
exit 150
fi
if [ "$NIC" = "AUTO-DHCP" ]
then
enable_auto_dhcp
+elif [ "$NIC" = "IPv6-SLAAC" ]
+then
+ enable_auto_slaac
+ # In addition, if static values were defined, add them as well.
+ # We might not get DNS information from RAs, for example.
+ if [ -n "${IPV6}" ]; then
+VAL=""
+get_first_wired_nic
+if [ -n "${VAL}" ]; then
+ ifconfig ${VAL} inet6 ${IPV6} alias
+fi
+ fi
+ # Append only here.
+ if [ -n "${IPV6DNS}" ]; then
+echo "nameserver ${IPV6DNS}" >>/etc/resolv.conf
+ fi
+ # Do not
+ if [ -n "${IPV6GATE}" ]; then
+# Check if we have a default route already to not overwrite.
+if ! route -n get -inet6 default > /dev/null 2>&1 ; then
+ route add -inet6 default ${IPV6GATE}
+fi
+ fi
else
echo "Enabling NIC: $NIC"
- ifconfig ${NIC} ${IP} ${NETMASK}
-
- echo "nameserver ${DNS}" >/etc/resolv.conf
-
- route add default ${GATE}
+ if [ -n "${IP}" ]; then
+ifconfig ${NIC} inet ${IP} ${NETMASK}
+ fi
+ if [ -n "${IPV6}" ]; then
+ifconfig ${NIC} inet6 ${IPV6} alias
+ fi
+
+ # Keep default from IPv4-only support times and clear the resolv.conf file.
+ : > /etc/resolv.conf
+ if [ -n "${DNS}" ]; then
+echo "nameserver ${DNS}" >>/etc/resolv.conf
+ fi
+ if [ -n "${IPV6DNS}" ]; then
+echo "nameserver ${IPV6DNS}" >>/etc/resolv.conf
+ fi
+
+ if [ -n "${GATE}" ]; then
+route add -inet default ${GATE}
+ fi
+ if [ -n "${IPV6GATE}" ]; then
+route add -inet6 default ${IPV6GATE}
+ fi
fi
case ${MIRRORFETCH} in
Modified: head/usr.sbin/pc-sysinstall/backend-query/test-netup.sh
==
--- head/usr.sbin/pc-sysinstall/backend-query/test-netup.sh Tue May 31
14:40:21 2011(r222527)
+++ head/usr.sbin/pc-sysinstall/backend-query/test-netup.sh Tue May 31
15:02:30 2011(r222528)
@@ -1,6 +1,11 @@
#!/bin/sh
#-
# Copyright (c) 2010 iXsystems, Inc. All rights reserved.
+# Copyright (c) 2011 The FreeBSD Foundation
+# All rights reserved.
+#
+# Portions of this software were developed by Bjoern Zeeb
+# under sponsorship from the FreeBSD Foundation.#
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
@@ -26,8 +31,8 @@
# $FreeBSD$
-# Script which tests "fetch" when using a network connection, and saves
-# if we are using direct connect, or need FTP passive mode
+# Script which tries to ping "home" to see if Internet connectivity is
+# available.
#
rm ${TMPDIR}/.testftp >/dev/null 2>/dev/null
@@ -39,12 +44,26 @@ then
exit 0
fi
+ping6 -c 2 www.pcbsd.org >/dev/null 2>/dev/null
+if [ "$?" = "0" ]
+then
+ echo "ftp: Up"
+ exit 0
+fi
+
ping -c 2 www.freebsd.org >/dev/null 2>/dev/null
if [ "$?" = "0" ]
then
echo "ftp: Up"
exit 0
fi
-
+
+ping6 -c 2 www.freebsd.org >/dev/null 2>/dev/null
+if [ "$?" = "0" ]
+then
+ echo "ftp: Up"
+ exit 0
+fi
+
echo "ftp: Down"
exit 1
Mo
svn commit: r222529 - head/sys/contrib/pf/net
Author: bz
Date: Tue May 31 15:05:29 2011
New Revision: 222529
URL: http://svn.freebsd.org/changeset/base/222529
Log:
Remove some further INET related symbols from pf to allow the module
to not only compile bu load as well for testing with IPv6-only kernels.
For the moment we ignore the csum change in pf_ioctl.c given the
pending update to pf45.
Reported by: dru
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after:20 days
Modified:
head/sys/contrib/pf/net/pf.c
head/sys/contrib/pf/net/pf_ioctl.c
head/sys/contrib/pf/net/pf_norm.c
Modified: head/sys/contrib/pf/net/pf.c
==
--- head/sys/contrib/pf/net/pf.cTue May 31 15:02:30 2011
(r222528)
+++ head/sys/contrib/pf/net/pf.cTue May 31 15:05:29 2011
(r222529)
@@ -6132,9 +6132,11 @@ pf_routable(struct pf_addr *addr, sa_fam
#ifdef __FreeBSD__
/* XXX MRT not always INET */ /* stick with table 0 though */
+#ifdef INET
if (af == AF_INET)
in_rtalloc_ign((struct route *)&ro, 0, 0);
else
+#endif
rtalloc_ign((struct route *)&ro, 0);
#else /* ! __FreeBSD__ */
rtalloc_noclone((struct route *)&ro, NO_CLONING);
@@ -6214,9 +6216,11 @@ pf_rtlabel_match(struct pf_addr *addr, s
# ifdef RTF_PRCLONING
rtalloc_ign((struct route *)&ro, (RTF_CLONING|RTF_PRCLONING));
# else /* !RTF_PRCLONING */
+#ifdef INET
if (af == AF_INET)
in_rtalloc_ign((struct route *)&ro, 0, 0);
else
+#endif
rtalloc_ign((struct route *)&ro, 0);
# endif
#else /* ! __FreeBSD__ */
@@ -6789,11 +6793,13 @@ pf_check_proto_cksum(struct mbuf *m, int
KMOD_UDPSTAT_INC(udps_badsum);
break;
}
+#ifdef INET
case IPPROTO_ICMP:
{
KMOD_ICMPSTAT_INC(icps_checksum);
break;
}
+#endif
#ifdef INET6
case IPPROTO_ICMPV6:
{
@@ -6889,9 +6895,11 @@ pf_check_proto_cksum(struct mbuf *m, int
case IPPROTO_UDP:
KMOD_UDPSTAT_INC(udps_badsum);
break;
+#ifdef INET
case IPPROTO_ICMP:
KMOD_ICMPSTAT_INC(icps_checksum);
break;
+#endif
#ifdef INET6
case IPPROTO_ICMPV6:
KMOD_ICMP6STAT_INC(icp6s_checksum);
Modified: head/sys/contrib/pf/net/pf_ioctl.c
==
--- head/sys/contrib/pf/net/pf_ioctl.c Tue May 31 15:02:30 2011
(r222528)
+++ head/sys/contrib/pf/net/pf_ioctl.c Tue May 31 15:05:29 2011
(r222529)
@@ -3735,9 +3735,12 @@ pf_check6_out(void *arg, struct mbuf **m
*/
int chk;
- /* We need a proper CSUM befor we start (s. OpenBSD ip_output) */
+ /* We need a proper CSUM before we start (s. OpenBSD ip_output) */
if ((*m)->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
+#ifdef INET
+ /* XXX-BZ copy&paste error from r126261? */
in_delayed_cksum(*m);
+#endif
(*m)->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
}
chk = pf_test6(PF_OUT, ifp, m, NULL, inp);
Modified: head/sys/contrib/pf/net/pf_norm.c
==
--- head/sys/contrib/pf/net/pf_norm.c Tue May 31 15:02:30 2011
(r222528)
+++ head/sys/contrib/pf/net/pf_norm.c Tue May 31 15:05:29 2011
(r222529)
@@ -949,6 +949,7 @@ pf_fragcache(struct mbuf **m0, struct ip
return (NULL);
}
+#ifdef INET
int
pf_normalize_ip(struct mbuf **m0, int dir, struct pfi_kif *kif, u_short
*reason,
struct pf_pdesc *pd)
@@ -1198,6 +1199,7 @@ pf_normalize_ip(struct mbuf **m0, int di
return (PF_DROP);
}
+#endif
#ifdef INET6
int
___
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 commit: r222530 - in head: contrib/top usr.bin/top
Author: jhb
Date: Tue May 31 15:11:23 2011
New Revision: 222530
URL: http://svn.freebsd.org/changeset/base/222530
Log:
Add a new option to toggle the display of the system idle process (per-CPU
idle threads). The process is displayed by default (subject to whether or
not system processes are displayed) to preserve existing behavior. The
system idle process can be hidden via the '-z' command line argument or the
'z' key while top is running. When it is hidden, top more closely matches
the behavior of FreeBSD <= 4.x where idle time was not accounted to any
process.
MFC after:2 weeks
Modified:
head/contrib/top/commands.c
head/contrib/top/machine.h
head/contrib/top/top.X
head/contrib/top/top.c
head/usr.bin/top/machine.c
Modified: head/contrib/top/commands.c
==
--- head/contrib/top/commands.c Tue May 31 15:05:29 2011(r222529)
+++ head/contrib/top/commands.c Tue May 31 15:11:23 2011(r222530)
@@ -94,6 +94,7 @@ S - toggle the displaying of syste
a - toggle the displaying of process titles\n\
t - toggle the display of this process\n\
u - display processes for only one user (+ selects all users)\n\
+z - toggle the displaying of the system idle process\n\
\n\
\n", stdout);
}
Modified: head/contrib/top/machine.h
==
--- head/contrib/top/machine.h Tue May 31 15:05:29 2011(r222529)
+++ head/contrib/top/machine.h Tue May 31 15:11:23 2011(r222530)
@@ -65,6 +65,7 @@ struct process_select
int uid; /* only this uid (unless uid == -1) */
int wcpu; /* show weighted cpu */
int jail; /* show jail ID */
+int kidle; /* show per-CPU idle threads */
char *command; /* only this command (unless == NULL) */
};
Modified: head/contrib/top/top.X
==
--- head/contrib/top/top.X Tue May 31 15:05:29 2011(r222529)
+++ head/contrib/top/top.X Tue May 31 15:11:23 2011(r222530)
@@ -10,7 +10,7 @@ top \- display and update information ab
.SH SYNOPSIS
.B top
[
-.B \-abCHIijnPqStuv
+.B \-abCHIijnPqStuvz
] [
.BI \-d count
] [
@@ -142,6 +142,9 @@ Write version number information to stde
No other processing takes place when this option is used. To see current
revision information while top is running, use the help command \*(lq?\*(rq.
.TP
+.B \-z
+Do not display the system idle process.
+.TP
.BI \-d count
Show only
.I count
@@ -303,6 +306,9 @@ ID.
Toggle the display of the
.I top
process.
+.TP
+.B z
+Toggle the display of the system idle process.
.SH "THE DISPLAY"
The actual display varies depending on the specific variant of Unix
that the machine is running. This description may not exactly match
Modified: head/contrib/top/top.c
==
--- head/contrib/top/top.c Tue May 31 15:05:29 2011(r222529)
+++ head/contrib/top/top.c Tue May 31 15:11:23 2011(r222530)
@@ -196,9 +196,9 @@ char *argv[];
fd_set readfds;
#ifdef ORDER
-static char command_chars[] = "\f qh?en#sdkriIutHmSCajo";
+static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo";
#else
-static char command_chars[] = "\f qh?en#sdkriIutHmSCaj";
+static char command_chars[] = "\f qh?en#sdkriIutHmSCajz";
#endif
/* these defines enumerate the "strchr"s of the commands in command_chars */
#define CMD_redraw 0
@@ -224,8 +224,9 @@ char *argv[];
#defineCMD_wcputog 19
#defineCMD_showargs20
#defineCMD_jidtog 21
+#define CMD_kidletog 22
#ifdef ORDER
-#define CMD_order 22
+#define CMD_order 23
#endif
/* set the buffer for stdout */
@@ -258,6 +259,7 @@ char *argv[];
ps.thread = No;
ps.wcpu= 1;
ps.jail= No;
+ps.kidle = Yes;
ps.command = NULL;
/* get preset options from the environment */
@@ -283,7 +285,7 @@ char *argv[];
optind = 1;
}
- while ((i = getopt(ac, av, "CSIHPabijnquvs:d:U:m:o:t")) != EOF)
+ while ((i = getopt(ac, av, "CSIHPabijnquvzs:d:U:m:o:t")) != EOF)
{
switch(i)
{
@@ -412,10 +414,14 @@ char *argv[];
pcpu_stats = Yes;
break;
+ case 'z':
+ ps.kidle = !ps.kidle;
+ break;
+
default:
fprintf(stderr,
"Top version %s\n"
-"Usage: %s [-abCHIijnPqStuv] [-d count] [-m io | cpu] [-o field] [-s time]\n"
+"Usage: %s [-abCHIijnPqStuvz] [-d count] [-m io | cpu] [-o field] [-s time]\n"
" [-U username] [number]\n",
version_string(), myname);
exit(1);
@@ -1075,7 +1081,13 @@ restart:
reset_display
svn commit: r222531 - in head/sys: i386/pci ia64/ia64 kern mips/mips net powerpc/booke powerpc/powerpc sparc64/sparc64 sys
Author: nwhitehorn
Date: Tue May 31 15:11:43 2011
New Revision: 222531
URL: http://svn.freebsd.org/changeset/base/222531
Log:
On multi-core, multi-threaded PPC systems, it is important that the threads
be brought up in the order they are enumerated in the device tree (in
particular, that thread 0 on each core be brought up first). The SLIST
through which we loop to start the CPUs has all of its entries added with
SLIST_INSERT_HEAD(), which means it is in reverse order of enumeration
and so AP startup would always fail in such situations (causing a machine
check or RTAS failure). Fix this by changing the SLIST into an STAILQ,
and inserting new CPUs at the end.
Reviewed by: jhb
Modified:
head/sys/i386/pci/pci_cfgreg.c
head/sys/ia64/ia64/machdep.c
head/sys/ia64/ia64/mp_machdep.c
head/sys/ia64/ia64/pmap.c
head/sys/kern/kern_idle.c
head/sys/kern/sched_4bsd.c
head/sys/kern/subr_kdb.c
head/sys/kern/subr_pcpu.c
head/sys/mips/mips/mp_machdep.c
head/sys/net/netisr.c
head/sys/powerpc/booke/pmap.c
head/sys/powerpc/powerpc/mp_machdep.c
head/sys/sparc64/sparc64/mp_machdep.c
head/sys/sparc64/sparc64/pmap.c
head/sys/sys/pcpu.h
Modified: head/sys/i386/pci/pci_cfgreg.c
==
--- head/sys/i386/pci/pci_cfgreg.c Tue May 31 15:11:23 2011
(r222530)
+++ head/sys/i386/pci/pci_cfgreg.c Tue May 31 15:11:43 2011
(r222531)
@@ -553,7 +553,7 @@ pcie_cfgregopen(uint64_t base, uint8_t m
(uintmax_t)base);
#ifdef SMP
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu)
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu)
#endif
{
Modified: head/sys/ia64/ia64/machdep.c
==
--- head/sys/ia64/ia64/machdep.cTue May 31 15:11:23 2011
(r222530)
+++ head/sys/ia64/ia64/machdep.cTue May 31 15:11:43 2011
(r222531)
@@ -316,7 +316,7 @@ cpu_startup(void *dummy)
/*
* Create sysctl tree for per-CPU information.
*/
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) {
snprintf(nodename, sizeof(nodename), "%u", pc->pc_cpuid);
sysctl_ctx_init(&pc->pc_md.sysctl_ctx);
pc->pc_md.sysctl_tree = SYSCTL_ADD_NODE(&pc->pc_md.sysctl_ctx,
Modified: head/sys/ia64/ia64/mp_machdep.c
==
--- head/sys/ia64/ia64/mp_machdep.c Tue May 31 15:11:23 2011
(r222530)
+++ head/sys/ia64/ia64/mp_machdep.c Tue May 31 15:11:43 2011
(r222531)
@@ -357,7 +357,7 @@ cpu_mp_start()
/* Keep 'em spinning until we unleash them... */
ia64_ap_state.as_spin = 1;
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) {
pc->pc_md.current_pmap = kernel_pmap;
pc->pc_other_cpus = all_cpus & ~pc->pc_cpumask;
/* The BSP is obviously running already. */
@@ -424,7 +424,7 @@ cpu_mp_unleash(void *dummy)
cpus = 0;
smp_cpus = 0;
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) {
cpus++;
if (pc->pc_md.awake) {
kproc_create(ia64_store_mca_state, pc, NULL, 0, 0,
@@ -462,7 +462,7 @@ ipi_selected(cpumask_t cpus, int ipi)
{
struct pcpu *pc;
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) {
if (cpus & pc->pc_cpumask)
ipi_send(pc, ipi);
}
@@ -486,7 +486,7 @@ ipi_all_but_self(int ipi)
{
struct pcpu *pc;
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) {
if (pc != pcpup)
ipi_send(pc, ipi);
}
Modified: head/sys/ia64/ia64/pmap.c
==
--- head/sys/ia64/ia64/pmap.c Tue May 31 15:11:23 2011(r222530)
+++ head/sys/ia64/ia64/pmap.c Tue May 31 15:11:43 2011(r222531)
@@ -535,7 +535,7 @@ pmap_invalidate_page(vm_offset_t va)
critical_enter();
vhpt_ofs = ia64_thash(va) - PCPU_GET(md.vhpt);
tag = ia64_ttag(va);
- SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
+ STAILQ_FOREACH(pc, &cpuhead, pc_allcpu) {
pte = (struct ia64_lpte *)(pc->pc_md.vhpt + vhpt_ofs);
atomic_cmpset_64(&pte->tag, tag, 1UL << 63);
}
Modified: head/sys/kern/kern_idle.c
==
--- head/sys/kern/kern_idle.c Tue May 31 15:11:23 2011(r222530)
+++ head/sys/kern/kern_idle.c Tue May 31 15:11:43 2011(r222531)
@@ -60,7 +60,7 @@ idle_setup(void *dummy)
p = NULL; /* start with no idle
Re: svn commit: r222084 - head/contrib/gperf/src
On Tue, May 31, 2011 at 03:28:45PM +0100, Ben Laurie wrote: > On 18/05/2011 22:16, Pawel Jakub Dawidek wrote: > > On Wed, May 18, 2011 at 09:06:20PM +, Ben Laurie wrote: > >> Author: benl > >> Date: Wed May 18 21:06:20 2011 > >> New Revision: 222084 > >> URL: http://svn.freebsd.org/changeset/base/222084 > >> > >> Log: > >> Fix clang warnings. > >> > >> Approved by: philip (mentor) > > [...] > >> -fprintf (stderr, " by changing asso_value['%c'] (char #%d) to > >> %d\n", > >> +fprintf (stderr, " by changing asso_value['%c'] (char #%zd) > >> to %d\n", > >> *p, p - union_set + 1, asso_values[(unsigned > >> char)(*p)]); > > > > Hmm, both 'p' and 'union_set' are 'char *' and %zd is for ssize_t. It is > > a bit strange that it fixes the warning. > > Why? The difference between two pointers is ssize_t, surely? > >From n1256.pdf, When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements. The size of the result is implementation-defined, and its type (a signed integer type) is ptrdiff_t defined in the header. ptrdiff_t is not necessarily that same as ssize_t. -- Steve ___ 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 commit: r222532 - in head: contrib/top usr.bin/top
Author: jhb Date: Tue May 31 15:41:10 2011 New Revision: 222532 URL: http://svn.freebsd.org/changeset/base/222532 Log: - Document the -H option and 'H' key alongside other options and keys rather than at the bottom of the manpage. - Remove an obsolete comment about SWAIT being a stale state. It was resurrected for a different purpose in FreeBSD 5 to mark idle ithreads. - Add a comment documenting that the SLEEP and LOCK states typically display the name of the event being waited on with lock names being prefixed with an asterisk and sleep event names not having a prefix. MFC after:1 week Modified: head/contrib/top/top.X head/usr.bin/top/top.local.1 Modified: head/contrib/top/top.X == --- head/contrib/top/top.X Tue May 31 15:11:43 2011(r222531) +++ head/contrib/top/top.X Tue May 31 15:41:10 2011(r222532) @@ -89,6 +89,10 @@ Use \*(lqbatch\*(rq mode. In this mode, ignored. Interrupt characters (such as ^C and ^\e) still have an effect. This is the default on a dumb terminal, or when the output is not a terminal. .TP +.B \-H +Display each thread for a multithreaded process individually. +By default a single summary line is displayed for each process. +.TP .B \-i Use \*(lqinteractive\*(rq mode. In this mode, any input is immediately read for processing. See the section on \*(lqInteractive Mode\*(rq @@ -292,6 +296,9 @@ or .BR r enice command. .TP +.B H +Toggle the display of threads. +.TP .B i (or .BR I ) @@ -358,8 +365,11 @@ the order of the processes, and COMMAND is the name of the command that the process is currently running (if the process is swapped out, this column is marked \*(lq\*(rq). .SH NOTES -The \*(lqABANDONED\*(rq state (known in the kernel as \*(lqSWAIT\*(rq) was -abandoned, thus the name. A process should never end up in this state. +If a process is in the \*(lqSLEEP\*(rq or \*(lqLOCK\*(rq state, +the state column will report the name of the event or lock on which the +process is waiting. +Lock names are prefixed with an asterisk \*(lq*\*(rq while sleep events +are not. .SH AUTHOR William LeFebvre, EECS Department, Northwestern University .SH ENVIRONMENT Modified: head/usr.bin/top/top.local.1 == --- head/usr.bin/top/top.local.1Tue May 31 15:11:43 2011 (r222531) +++ head/usr.bin/top/top.local.1Tue May 31 15:41:10 2011 (r222532) @@ -1,10 +1,6 @@ .\" $FreeBSD$ .SH "FreeBSD NOTES" -.SH DISPLAY OF THREADS -The '-H' option will toggle the display of kernel visible thread contexts. -At runtime the 'H' key will toggle this mode. The default is OFF. - .SH DESCRIPTION OF MEMORY Mem: 9220K Active, 1M Inact, 3284K Wired, 1M Cache, 2M Buf, 1320K Free Swap: 91M Total, 79M Free, 13% Inuse, 80K In, 104K Out ___ 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: r221900 - head
On 15/05/2011 05:19, Bjoern A. Zeeb wrote: > On Sat, 14 May 2011, Colin Percival wrote: > >> Author: cperciva >> Date: Sat May 14 17:44:12 2011 >> New Revision: 221900 >> URL: http://svn.freebsd.org/changeset/base/221900 >> >> Log: >> Encourage Ben Laurie to finish getting his commit bit by appointing him >> as the OpenSSL maintainer. > > > I'd like to thanks Simon for doing this all the years! Great job! > > I am also happy Ben volunteered to pick up the task:) Great to have > you doing this for FreeBSD! Now I'm back from my travels someone's going to have to tell me what I need to do! -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff ___ 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 commit: r222534 - head/usr.bin/tftp
Author: imp
Date: Tue May 31 16:59:14 2011
New Revision: 222534
URL: http://svn.freebsd.org/changeset/base/222534
Log:
Fix a couple of spelling errors.
Submitted by: bcr@
Modified:
head/usr.bin/tftp/main.c
Modified: head/usr.bin/tftp/main.c
==
--- head/usr.bin/tftp/main.cTue May 31 15:49:28 2011(r222533)
+++ head/usr.bin/tftp/main.cTue May 31 16:59:14 2011(r222534)
@@ -155,7 +155,7 @@ static struct cmd cmdtab[] = {
{ "options",setoptions,
"enable or disable RFC2347 style options" },
{ "help", help, "print help information"},
- { "packetdrop", setpacketdrop, "artifical packetloss feature" },
+ { "packetdrop", setpacketdrop, "artificial packetloss feature" },
{ "?", help, "print help information"},
{ NULL, NULL, NULL}
};
@@ -955,7 +955,7 @@ setblocksize(int argc, char *argv[])
if (!options_rfc_enabled)
printf("RFC2347 style options are not enabled "
- "(but proceding anyway)\n");
+ "(but proceeding anyway)\n");
if (argc != 1) {
int size = atoi(argv[1]);
@@ -993,7 +993,7 @@ setblocksize2(int argc, char *argv[])
if (!options_rfc_enabled || !options_extra_enabled)
printf(
"RFC2347 style or non-RFC defined options are not enabled "
- "(but proceding anyway)\n");
+ "(but proceeding anyway)\n");
if (argc != 1) {
int size = atoi(argv[1]);
___
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 commit: r222535 - head/tools/tools/nanobsd
Author: imp
Date: Tue May 31 17:14:06 2011
New Revision: 222535
URL: http://svn.freebsd.org/changeset/base/222535
Log:
Don't need (and can't use) -L to copy links here.
Modified:
head/tools/tools/nanobsd/nanobsd.sh
Modified: head/tools/tools/nanobsd/nanobsd.sh
==
--- head/tools/tools/nanobsd/nanobsd.sh Tue May 31 16:59:14 2011
(r222534)
+++ head/tools/tools/nanobsd/nanobsd.sh Tue May 31 17:14:06 2011
(r222535)
@@ -418,7 +418,7 @@ populate_slice ( ) (
echo "Creating ${dev} with ${dir} (mounting on ${mnt})"
newfs_part $dev $mnt $lbl
cd ${dir}
- find . -print | grep -Ev '/(CVS|\.svn)' | cpio -Ldumpv ${mnt}
+ find . -print | grep -Ev '/(CVS|\.svn)' | cpio -dumpv ${mnt}
df -i ${mnt}
umount ${mnt}
)
___
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 commit: r222537 - in head/sys: kern sys
Author: ken Date: Tue May 31 17:29:58 2011 New Revision: 222537 URL: http://svn.freebsd.org/changeset/base/222537 Log: Fix apparent garbage in the message buffer. While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix scrambled console output, the message buffer and syslog were still getting log messages one character at a time. While all of the characters still made it into the log (courtesy of atomic operations), they were often interleaved when there were multiple threads writing to the buffer at the same time. This fixes message buffer accesses to use buffering logic as well, so that strings that are less than PRINTF_BUFR_SIZE will be put into the message buffer atomically. So now dmesg output should look the same as console output. subr_msgbuf.c:Convert most message buffer calls to use a new spin lock instead of atomic variables in some places. Add a new routine, msgbuf_addstr(), that adds a NUL-terminated string to a message buffer. This takes a priority argument, which allows us to eliminate some races (at least in the the string at a time case) that are present in the implementation of msglogchar(). (dangling and lastpri are static variables, and are subject to races when multiple callers are present.) msgbuf_addstr() also allows the caller to request that carriage returns be stripped out of the string. This matches the behavior of msglogchar(), but in testing so far it doesn't appear that any newlines are being stripped out. So the carriage return removal functionality may be a candidate for removal later on if further analysis shows that it isn't necessary. subr_prf.c: Add a new msglogstr() routine that calls msgbuf_logstr(). Rename putcons() to putbuf(). This now handles buffered output to the message log as well as the console. Also, remove the logic in putcons() (now putbuf()) that added a carriage return before a newline. The console path was the only path that needed it, and cnputc() (called by cnputs()) already adds a carriage return. So this duplication resulted in kernel-generated console output lines ending in '\r''\r''\n'. Refactor putchar() to handle the new buffering scheme. Add buffering to log(). Change log_console() to use msglogstr() instead of msglogchar(). Don't add extra newlines by default in log_console(). Hide that behavior behind a tunable/sysctl (kern.log_console_add_linefeed) for those who would like the old behavior. The old behavior led to the insertion of extra newlines for log output for programs that print out a string, and then a trailing newline on a separate write. (This is visible with dmesg -a.) msgbuf.h: Add a prototype for msgbuf_addstr(). Add three new fields to struct msgbuf, msg_needsnl, msg_lastpri and msg_lock. The first two are needed for log message functionality previously handled by msglogchar(). (Which is still active if buffering isn't enabled.) Include sys/lock.h and sys/mutex.h for the new mutex. Reviewed by: gibbs Modified: head/sys/kern/subr_msgbuf.c head/sys/kern/subr_prf.c head/sys/sys/msgbuf.h Modified: head/sys/kern/subr_msgbuf.c == --- head/sys/kern/subr_msgbuf.c Tue May 31 17:24:18 2011(r222536) +++ head/sys/kern/subr_msgbuf.c Tue May 31 17:29:58 2011(r222537) @@ -31,8 +31,16 @@ #include #include +#include +#include #include +/* + * Maximum number conversion buffer length: uintmax_t in base 2, plus <> + * around the priority, and a terminating NUL. + */ +#defineMAXPRIBUF (sizeof(intmax_t) * NBBY + 3) + /* Read/write sequence numbers are modulo a multiple of the buffer size. */ #define SEQMOD(size) ((size) * 16) @@ -51,6 +59,9 @@ msgbuf_init(struct msgbuf *mbp, void *pt mbp->msg_s
svn commit: r222540 - head/sys/fs/nfsclient
Author: rmacklem
Date: Tue May 31 17:43:25 2011
New Revision: 222540
URL: http://svn.freebsd.org/changeset/base/222540
Log:
Fix the new NFS client so that it doesn't do an NFSv3
Pathconf RPC for cases where the reply doesn't include
the answer. This fixes a problem reported by avg@ where
the NFSv3 Pathconf RPC would fail when "ls -l" did an
lpathconf(2) for _PC_ACL_NFS4.
Tested by:avg
MFC after:2 weeks
Modified:
head/sys/fs/nfsclient/nfs_clvnops.c
Modified: head/sys/fs/nfsclient/nfs_clvnops.c
==
--- head/sys/fs/nfsclient/nfs_clvnops.c Tue May 31 17:34:30 2011
(r222539)
+++ head/sys/fs/nfsclient/nfs_clvnops.c Tue May 31 17:43:25 2011
(r222540)
@@ -3293,7 +3293,13 @@ nfs_pathconf(struct vop_pathconf_args *a
struct thread *td = curthread;
int attrflag, error;
- if (NFS_ISV34(vp)) {
+ if (NFS_ISV4(vp) || (NFS_ISV3(vp) && (ap->a_name == _PC_LINK_MAX ||
+ ap->a_name == _PC_NAME_MAX || ap->a_name == _PC_CHOWN_RESTRICTED ||
+ ap->a_name == _PC_NO_TRUNC))) {
+ /*
+* Since only the above 4 a_names are returned by the NFSv3
+* Pathconf RPC, there is no point in doing it for others.
+*/
error = nfsrpc_pathconf(vp, &pc, td->td_ucred, td, &nfsva,
&attrflag, NULL);
if (attrflag != 0)
@@ -3302,7 +3308,10 @@ nfs_pathconf(struct vop_pathconf_args *a
if (error != 0)
return (error);
} else {
- /* For NFSv2, just fake them. */
+ /*
+* For NFSv2 (or NFSv3 when not one of the above 4 a_names),
+* just fake them.
+*/
pc.pc_linkmax = LINK_MAX;
pc.pc_namemax = NFS_MAXNAMLEN;
pc.pc_notrunc = 1;
___
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: r221900 - head
On Tue, May 31, 2011 at 04:52:10PM +0100, Ben Laurie wrote: > Now I'm back from my travels someone's going to have to tell me what I > need to do! Now you understand the reason not to leave the room: someone just volunteers you to do stuff, when you do. mcl ___ 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 commit: r222541 - head/sbin/umount
Author: rmacklem Date: Tue May 31 18:27:18 2011 New Revision: 222541 URL: http://svn.freebsd.org/changeset/base/222541 Log: Add a sentence to the umount.8 man page to clarify the behaviour for forced dismount when used on an NFS mount point. Requested by Jeremy Chadwick. This is a content change. MFC after:2 weeks Modified: head/sbin/umount/umount.8 Modified: head/sbin/umount/umount.8 == --- head/sbin/umount/umount.8 Tue May 31 17:43:25 2011(r222540) +++ head/sbin/umount/umount.8 Tue May 31 18:27:18 2011(r222541) @@ -28,7 +28,7 @@ .\" @(#)umount.8 8.2 (Berkeley) 5/8/95 .\" $FreeBSD$ .\" -.Dd July 18, 2003 +.Dd May 31, 2011 .Dt UMOUNT 8 .Os .Sh NAME @@ -78,6 +78,9 @@ The file system is forcibly unmounted. Active special devices continue to work, but all other files return errors if further accesses are attempted. The root file system cannot be forcibly unmounted. +For NFS, a forced dismount can take up to 1 minute or more to +complete against an unresponsive server and may throw away +data not yet written to the server for this case. .It Fl h Ar host Only file systems mounted from the specified host will be unmounted. ___ 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 commit: r222542 - head/sys/dev/nfe
Author: yongari
Date: Tue May 31 18:45:15 2011
New Revision: 222542
URL: http://svn.freebsd.org/changeset/base/222542
Log:
If driver is not running, disable interrupts and do not try to
process received frames. Previously it was possible to handle RX
interrupts even if controller is not fully initialized. This
resulted in non-working driver after system is up and running.
Reported by: hselasky
Tested by:hselasky
Modified:
head/sys/dev/nfe/if_nfe.c
Modified: head/sys/dev/nfe/if_nfe.c
==
--- head/sys/dev/nfe/if_nfe.c Tue May 31 18:27:18 2011(r222541)
+++ head/sys/dev/nfe/if_nfe.c Tue May 31 18:45:15 2011(r222542)
@@ -1889,7 +1889,7 @@ nfe_int_task(void *arg, int pending)
if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) {
NFE_UNLOCK(sc);
- nfe_enable_intr(sc);
+ nfe_disable_intr(sc);
return;
}
___
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 commit: r222543 - in head/sys/dev: ipw iwi iwn wpi
Author: bschmidt
Date: Tue May 31 19:08:25 2011
New Revision: 222543
URL: http://svn.freebsd.org/changeset/base/222543
Log:
Add module version to iwi/ipw/wpi and iwn.
The version is used to check if a module is already preset, not setting
it results in:
can't re-use a leaf (ipw)!
module_register: module pci/ipw already exists!
Module pci/ipw failed to register: 17
while trying to load the module due to an entry in loader.conf. With this
commit we get the expected:
module ipw already present!
Reported by: Dru Lavigne, bz
Tested by:bz
MFC after:1 week
Modified:
head/sys/dev/ipw/if_ipw.c
head/sys/dev/iwi/if_iwi.c
head/sys/dev/iwn/if_iwn.c
head/sys/dev/wpi/if_wpi.c
Modified: head/sys/dev/ipw/if_ipw.c
==
--- head/sys/dev/ipw/if_ipw.c Tue May 31 18:45:15 2011(r222542)
+++ head/sys/dev/ipw/if_ipw.c Tue May 31 19:08:25 2011(r222543)
@@ -199,6 +199,8 @@ static devclass_t ipw_devclass;
DRIVER_MODULE(ipw, pci, ipw_driver, ipw_devclass, 0, 0);
+MODULE_VERSION(ipw, 1);
+
static int
ipw_probe(device_t dev)
{
Modified: head/sys/dev/iwi/if_iwi.c
==
--- head/sys/dev/iwi/if_iwi.c Tue May 31 18:45:15 2011(r222542)
+++ head/sys/dev/iwi/if_iwi.c Tue May 31 19:08:25 2011(r222543)
@@ -232,6 +232,8 @@ static devclass_t iwi_devclass;
DRIVER_MODULE(iwi, pci, iwi_driver, iwi_devclass, 0, 0);
+MODULE_VERSION(iwi, 1);
+
static __inline uint8_t
MEM_READ_1(struct iwi_softc *sc, uint32_t addr)
{
Modified: head/sys/dev/iwn/if_iwn.c
==
--- head/sys/dev/iwn/if_iwn.c Tue May 31 18:45:15 2011(r222542)
+++ head/sys/dev/iwn/if_iwn.c Tue May 31 19:08:25 2011(r222543)
@@ -401,6 +401,8 @@ static devclass_t iwn_devclass;
DRIVER_MODULE(iwn, pci, iwn_driver, iwn_devclass, 0, 0);
+MODULE_VERSION(iwn, 1);
+
MODULE_DEPEND(iwn, firmware, 1, 1, 1);
MODULE_DEPEND(iwn, pci, 1, 1, 1);
MODULE_DEPEND(iwn, wlan, 1, 1, 1);
Modified: head/sys/dev/wpi/if_wpi.c
==
--- head/sys/dev/wpi/if_wpi.c Tue May 31 18:45:15 2011(r222542)
+++ head/sys/dev/wpi/if_wpi.c Tue May 31 19:08:25 2011(r222543)
@@ -273,6 +273,8 @@ static devclass_t wpi_devclass;
DRIVER_MODULE(wpi, pci, wpi_driver, wpi_devclass, 0, 0);
+MODULE_VERSION(wpi, 1);
+
static const uint8_t wpi_ridx_to_plcp[] = {
/* OFDM: IEEE Std 802.11a-1999, pp. 14 Table 80 */
/* R1-R4 (ral/ural is R4-R1) */
___
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 commit: r222544 - in head/sys: contrib/dev/acpica contrib/dev/acpica/debugger contrib/dev/acpica/include contrib/dev/acpica/tables dev/acpica/Osd
Author: jkim Date: Tue May 31 19:45:58 2011 New Revision: 222544 URL: http://svn.freebsd.org/changeset/base/222544 Log: Merge ACPICA 20110527. Modified: head/sys/contrib/dev/acpica/changes.txt head/sys/contrib/dev/acpica/debugger/dbexec.c head/sys/contrib/dev/acpica/debugger/dbinput.c head/sys/contrib/dev/acpica/debugger/dbutils.c head/sys/contrib/dev/acpica/debugger/dbxface.c head/sys/contrib/dev/acpica/include/acconfig.h head/sys/contrib/dev/acpica/include/acdebug.h head/sys/contrib/dev/acpica/include/acglobal.h head/sys/contrib/dev/acpica/include/aclocal.h head/sys/contrib/dev/acpica/include/acpiosxf.h head/sys/contrib/dev/acpica/include/acpixf.h head/sys/contrib/dev/acpica/include/acpredef.h head/sys/contrib/dev/acpica/osunixxf.c head/sys/contrib/dev/acpica/tables/tbinstal.c head/sys/dev/acpica/Osd/OsdDebug.c Directory Properties: head/sys/contrib/dev/acpica/ (props changed) Modified: head/sys/contrib/dev/acpica/changes.txt == --- head/sys/contrib/dev/acpica/changes.txt Tue May 31 19:08:25 2011 (r222543) +++ head/sys/contrib/dev/acpica/changes.txt Tue May 31 19:45:58 2011 (r222544) @@ -1,31 +1,99 @@ +27 May 2011. Summary of changes for version 20110527: + +This release is available at www.acpica.org/downloads + +1) ACPI CA Core Subsystem: + +ASL Load() operator: Reinstate most restrictions on the incoming ACPI table +signature. Now, only allow SSDT, OEMx, and a null signature. History: +1) Originally, we checked the table signature for "SSDT" or "PSDT". + (PSDT is now obsolete.) +2) We added support for OEMx tables, signature "OEM" plus a fourth + "don't care" character. +3) Valid tables were encountered with a null signature, so we just + gave up on validating the signature, (05/2008). +4) We encountered non-AML tables such as the MADT, which caused + interpreter errors and kernel faults. So now, we once again allow + only SSDT, OEMx, and now, also a null signature. (05/2011). + +Added the missing _TDL predefined name to the global name list in order to +enable validation. Affects both the core ACPICA code and the iASL compiler. + +Example Code and Data Size: These are the sizes for the OS-independent +acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug +version of the code includes the debug output trace mechanism and has a much +larger code and data size. + + Previous Release (VC 9.0): +Non-Debug Version: 90.0K Code, 23.8K Data, 113.8K Total +Debug Version: 164.5K Code, 68.0K Data, 232.5K Total + Current Release (VC 9.0): +Non-Debug Version: 90.1K Code, 23.9K Data, 114.0K Total +Debug Version: 165.6K Code, 68.4K Data, 234.0K Total + +2) iASL Compiler/Disassembler and Tools: + +Debugger/AcpiExec: Implemented support for "complex" method arguments on the +debugger command line. This adds support beyond simple integers -- including +Strings, Buffers, and Packages. Includes support for nested packages. +Increased the default command line buffer size to accommodate these arguments. +See the ACPICA reference for details and syntax. ACPICA BZ 917. + +Debugger/AcpiExec: Implemented support for "default" method arguments for the +Execute/Debug command. Now, the debugger will always invoke a control method +with the required number of arguments -- even if the command line specifies +none or insufficient arguments. It uses default integer values for any missing +arguments. Also fixes a bug where only six method arguments maximum were +supported instead of the required seven. + +Debugger/AcpiExec: Add a maximum buffer length parameter to AcpiOsGetLine and +also return status in order to prevent buffer overruns. See the ACPICA +reference for details and syntax. ACPICA BZ 921 + +iASL: Cleaned up support for Berkeley yacc. A general cleanup of code and +makefiles to simplify support for the two different but similar parser +generators, bison and yacc. + +Updated the generic unix makefile for gcc 4. The default gcc version is now +expected to be 4 or greater, since options specific to gcc 4 are used. + + 13 April 2011. Summary of changes for version 20110413: 1) ACPI CA Core Subsystem: Implemented support to execute a so-called "orphan" _REG method under the EC -device. This change will force the execution of a _REG method underneath the EC +device. This change will force the execution of a _REG method underneath the +EC device even if there is no corresponding operation region of type EmbeddedControl. Fixes a problem seen on some machines and apparently is compatible with Windows behavior. ACPICA BZ 875. Added more predefined methods that are eligible for automatic NULL package -element removal. This change adds another group of predefined names to the list
Re: svn commit: r222466 - head/sbin/umount
>
> It is only an optimization. Any number of syncs are useless for
> actually syncing the system, since sync(2) only does an async sync (it
> returns without waiting for most writes to complete). As you pointed
> out later in this thread, unmount(2) does a sync that works -- a sync
> sync -- before doing the unmount proper. It does this irrespective of
> the force flag:
>
> % if (((mp->mnt_flag & MNT_RDONLY) ||
> % (error = VFS_SYNC(mp, MNT_WAIT)) == 0) || (flags & MNT_FORCE) != 0)
> % error = VFS_UNMOUNT(mp, flags);
>
> The force flag doesn't mean that i/o's are forced to complete. It
> only means that open files are forced to be closed (and a few related
> things). This can be seen here. We wait (potentially forever) for
> any existing writes to complete. Only then do we look at the force
> flag and bale out if the sync failed and the force flag is _not_ set.
> Most i/o problems will cause hangs in this sync, and the force flag
> won't help. But if we somehow get past this sync, and have i/o
> problems, then honoring the force flag and continuing gives even more
> fragility, since we have almost passed the point of being able to give
> up after an error (this point is typically very early in
> VFS_UNMOUNT()).
>
Well, in vgonel(), which is called from vflush() and seems to be what
gets rid of the vnode even when open for forced dismounts, there is:
/*
* Clear out any buffers associated with the vnode.
* If the flush fails, just toss the buffers.
*/
- followed shortly by
if (vinvalbuf(vp, V_SAVE, 0, 0) != 0)
vinvalbuf(vp, 0, 0, 0);
It seems to me that this code is willing to give up when it can't write
dirty buffers, but???
To me, a forced dismount of an NFS mount that just wedges on an
unresponsive server isn't very useful. The only case I can think
of where a forced dismount that isn't willing to throw away dirty
buffers might be useful would be when an app. (userland process)
is for some reason unkillable and is sitting with an open NFS file.
Is this a problem in practice? (I do know that a mount stuck on an
unresponsive server is a real problem. There have been several PRs,
the most recent being kern/157365.)
I brought up the concept of a "hard forced dismount" at the developer
summit a year ago, but no one seemed to see a difference between that
and what they believed a forced dismount already did. After that, I
thought about it a little and couldn't see much use for a "soft forced
dismount that fails instead of throwing away dirty buffers, but does
close down open files".
- For example, suppose a userland process is writing a file through
the stdio library:
A - fopen()s a file for writing
B - does fwrite()s of small amounts of data
C - does an fflush()
If the open is closed by a forced dismount before C, the written data
will be lost, since it isn't even in the kernel yet. If the file is on
a responsive NFS server, it will be written to the server shortly after C.
So, there seems to be a narrow window around C where the data will be lost
for a forced dismount that throws away dirty buffers vs one that doesn't
"but only if the server is responsive".
In other words, "Is there much difference between ripping the open files
out from under a app. before it does a write syscall vs throwing the data
away when it's in the kernel buffer but not yet written to an NFS server?"
Anyhow, the way I now have the NFS clients, they do a "hard forced dismount"
where they can throw away dirty buffers not yet written to the server.
Recent patches to nfs_sync() make it return without attempting writes for
the forced dismount case and the vgonel() { see above code snippet } throws
away the data when the first vinvalbuf(.., V_SAVE,.) fails.
> Many file systems have had bugs in this area. Before 1999/01/22
> (vfs_bio.c 1.196), b*write() gave up after an i/o error, and pretended
> to succeed. Both recoverable and unrecoverable errors were mishandled.
> This avoided many hangs in VFS_SYNC(). When this was partially fixed,
> many VFS_SYNC()s couldn't handle the errors, and paniced when they
> should have looped endlessly. Now I think they mostly loop endlessly,
> even for unrecoverable errors when they shouldn't. My version attempts
> to fix vfs_bio.c 1.196 by still giving up after an unrecoverable i/o
> error. This reduced endless loops but gave more panics in other places
> that can't handle the errors, mainly in the VFS_UMOUNT() call in the
> above -- many file systems saw the errors after the point where it is
> posible to either recover from them or loop endlessly on them, and
> then
> a panic occurred soon after the VFS_UMOUNT() returned with a
> half-complete
> unmount(), since neither a success or a failure return can indicate
> this
> state.
>
> > call to the unmount(2) call, I'm not convinced it makes a
> > significant
> > difference. (I thought of just getting rid of it, but figured it was
> > harmless for the non "-f" case and might matter for a buggy fs
Re: svn commit: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: > Author: ken > Date: Tue May 31 17:29:58 2011 > New Revision: 222537 > URL: http://svn.freebsd.org/changeset/base/222537 > > Log: > Fix apparent garbage in the message buffer. > > While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix > scrambled console output, the message buffer and syslog were still getting > log messages one character at a time. While all of the characters still > made it into the log (courtesy of atomic operations), they were often > interleaved when there were multiple threads writing to the buffer at the > same time. This seems to panic my box with "lock "msgbuf" 0xfe0127e0 already initialized". Unfortunately, though I booted with a fresh CURRENT this morning successfully, both /boot/kernel and /boot/kernel.old give this panic. To add insult to injury, when the kernel drops into the debugger, my keyboard input no longer works so I can't get a stack, etc. So: 1) Is there anything else I can do to help debug this? 2) how can I resurrect this box without a reinstall? I will try to repro on a virtual machine so I have a snapshot to come back to. Thanks, matthew > This fixes message buffer accesses to use buffering logic as well, so that > strings that are less than PRINTF_BUFR_SIZE will be put into the message > buffer atomically. So now dmesg output should look the same as console > output. > > subr_msgbuf.c: Convert most message buffer calls to use a new > spin > lock instead of atomic variables in some places. > > Add a new routine, msgbuf_addstr(), that adds a > NUL-terminated string to a message buffer. This > takes a priority argument, which allows us to > eliminate some races (at least in the the string > at a time case) that are present in the > implementation of msglogchar(). (dangling and > lastpri are static variables, and are subject to > races when multiple callers are present.) > > msgbuf_addstr() also allows the caller to request > that carriage returns be stripped out of the > string. This matches the behavior of msglogchar(), > but in testing so far it doesn't appear that any > newlines are being stripped out. So the carriage > return removal functionality may be a candidate > for removal later on if further analysis shows > that it isn't necessary. > > subr_prf.c: Add a new msglogstr() routine that calls > msgbuf_logstr(). > > Rename putcons() to putbuf(). This now handles > buffered output to the message log as well as > the console. Also, remove the logic in putcons() > (now putbuf()) that added a carriage return before > a newline. The console path was the only path that > needed it, and cnputc() (called by cnputs()) > already adds a carriage return. So this > duplication resulted in kernel-generated console > output lines ending in '\r''\r''\n'. > > Refactor putchar() to handle the new buffering > scheme. > > Add buffering to log(). > > Change log_console() to use msglogstr() instead of > msglogchar(). Don't add extra newlines by default > in log_console(). Hide that behavior behind a > tunable/sysctl (kern.log_console_add_linefeed) for > those who would like the old behavior. The old > behavior led to the insertion of extra newlines > for log output for programs that print out a > string, and then a trailing newline on a separate > write. (This is visible with dmesg -a.) > > msgbuf.h: Add a prototype for msgbuf_addstr(). > > Add three new fields to struct msgbuf, msg_needsnl, > msg_lastpri and msg_lock. The first two are needed > for log message functionality previously handled > by msglogchar(). (Which is still active if > buffering isn't enabled.) > > Include sys/lock.h and sys/mutex.h for the new > mutex. > > Reviewed by: gibbs > > Modified: > head/sys/kern/subr_msgbuf.c > head/sys/kern/subr_prf.c > head/sys/sys/msgbuf.h > > Modified: head/sys/kern/subr_msgbuf.c
Re: svn commit: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 2:00 PM, wrote: > On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: >> Author: ken >> Date: Tue May 31 17:29:58 2011 >> New Revision: 222537 >> URL: http://svn.freebsd.org/changeset/base/222537 >> >> Log: >> Fix apparent garbage in the message buffer. >> >> While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix >> scrambled console output, the message buffer and syslog were still getting >> log messages one character at a time. While all of the characters still >> made it into the log (courtesy of atomic operations), they were often >> interleaved when there were multiple threads writing to the buffer at the >> same time. > > This seems to panic my box with "lock "msgbuf" 0xfe0127e0 > already initialized". > > Unfortunately, though I booted with a fresh CURRENT this morning > successfully, both /boot/kernel and /boot/kernel.old give this panic. > To add insult to injury, when the kernel drops into the debugger, my > keyboard input no longer works so I can't get a stack, etc. > > So: > > 1) Is there anything else I can do to help debug this? 1. sysctl debug.debugger_on_panic=1 ? > 2) how can I resurrect this box without a reinstall? 2. Best way is to probably to use the bsdinstall CD, use the LiveCD mode, setup the system as usual (mount /, mount devfs, chroot, mount -a), rewind to an earlier version of svn (shouldn't be too hard if you run /etc/rc.d/network restart from inside the chroot), rebuild the kernel (and potentially world), and install the kernel to the chroot, then exit and reboot (this is a method I picked up from installing Gentoo Linux multiple times, but it should work for FreeBSD as well). This is part of the reason why I'm an avid using of make installkernel INSTKERNNAME=$KERNCONF.$SVN_REVISION , symlink /boot/kernel to the latest one I want to boot, and I only go through every once in a blue moon to reap the kernels I don't need anymore -- I don't know until after a few weeks soak on my workstation whether or not a regression is present in the kernel. > I will try to repro on a virtual machine so I have a snapshot to come back to. HTH! -Garrett ___ 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: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 2:14 PM, Garrett Cooper wrote: > On Tue, May 31, 2011 at 2:00 PM, wrote: >> On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: >>> Author: ken >>> Date: Tue May 31 17:29:58 2011 >>> New Revision: 222537 >>> URL: http://svn.freebsd.org/changeset/base/222537 >>> >>> Log: >>> Fix apparent garbage in the message buffer. >>> >>> While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix >>> scrambled console output, the message buffer and syslog were still getting >>> log messages one character at a time. While all of the characters still >>> made it into the log (courtesy of atomic operations), they were often >>> interleaved when there were multiple threads writing to the buffer at the >>> same time. >> >> This seems to panic my box with "lock "msgbuf" 0xfe0127e0 >> already initialized". >> >> Unfortunately, though I booted with a fresh CURRENT this morning >> successfully, both /boot/kernel and /boot/kernel.old give this panic. >> To add insult to injury, when the kernel drops into the debugger, my >> keyboard input no longer works so I can't get a stack, etc. >> >> So: >> >> 1) Is there anything else I can do to help debug this? > > 1. sysctl debug.debugger_on_panic=1 ? Sorry.. I meant 'debug.debugger_on_panic=0'. >> 2) how can I resurrect this box without a reinstall? > > 2. Best way is to probably to use the bsdinstall CD, use the LiveCD > mode, setup the system as usual (mount /, mount devfs, chroot, mount > -a), rewind to an earlier version of svn (shouldn't be too hard if you > run /etc/rc.d/network restart from inside the chroot), rebuild the > kernel (and potentially world), and install the kernel to the chroot, > then exit and reboot (this is a method I picked up from installing > Gentoo Linux multiple times, but it should work for FreeBSD as well). > > This is part of the reason why I'm an avid using of make installkernel > INSTKERNNAME=$KERNCONF.$SVN_REVISION , symlink /boot/kernel to the > latest one I want to boot, and I only go through every once in a blue > moon to reap the kernels I don't need anymore -- I don't know until > after a few weeks soak on my workstation whether or not a regression > is present in the kernel. > >> I will try to repro on a virtual machine so I have a snapshot to come back >> to. ___ 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: r221853 - in head/sys: dev/md dev/null sys vm
On Sunday 29 May 2011 05:01:57 m...@freebsd.org wrote: > On Sat, May 28, 2011 at 12:03 PM, Pieter de Goeje wrote: > > To me it looks like it's not able to cache the zeroes anymore. Is this > > intentional? I tried to change ZERO_REGION_SIZE back to 64K but that > > didn't help. > > Hmm. I don't have access to my FreeBSD box over the weekend, but I'll > run this on my box when I get back to work. > > Meanwhile you could try setting ZERO_REGION_SIZE to PAGE_SIZE and I > think that will restore things to the original performance. Indeed it does. I couldn't find any authoritative docs stating wether or not the cache on this CPU is virtually indexed, but apparently at least some of it is. Regards, Pieter ___ 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: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 14:00:18 -0700, m...@freebsd.org wrote: > On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: > > Author: ken > > Date: Tue May 31 17:29:58 2011 > > New Revision: 222537 > > URL: http://svn.freebsd.org/changeset/base/222537 > > > > Log: > > ?Fix apparent garbage in the message buffer. > > > > ?While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix > > ?scrambled console output, the message buffer and syslog were still getting > > ?log messages one character at a time. ?While all of the characters still > > ?made it into the log (courtesy of atomic operations), they were often > > ?interleaved when there were multiple threads writing to the buffer at the > > ?same time. > > This seems to panic my box with "lock "msgbuf" 0xfe0127e0 > already initialized". > > Unfortunately, though I booted with a fresh CURRENT this morning > successfully, both /boot/kernel and /boot/kernel.old give this panic. > To add insult to injury, when the kernel drops into the debugger, my > keyboard input no longer works so I can't get a stack, etc. Uh-oh! > So: > > 1) Is there anything else I can do to help debug this? > 2) how can I resurrect this box without a reinstall? > > I will try to repro on a virtual machine so I have a snapshot to come back to. My guess is that this is an issue with the message buffer reinitialization path. lock_init() (called by mtx_init()) has an assert to make sure that the lock is initialized, and that is just a flag check. Since the spin lock is part of the message buffer structure, if it is held over from a previous boot, the LO_INITIALIZED flag may still be set. Try power cycling the machine. If it is an issue with re-initialization, that should clear the memory and allow you to boot. My testing has been with VMs (under Xen), so the reinit path has probably not been tested as fully as it should have been. Sorry about that! As for the debugger, that's another issue altogether. It does work for me, but then again if the spin lock initialization is broken for the message buffer that may affect things. Try a cold boot and see if that helps. If so, I think we can probably just bzero the mutex in msgbuf_reinit() and that will fix things. Ken -- Kenneth Merry k...@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: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 2:46 PM, Kenneth D. Merry wrote: > On Tue, May 31, 2011 at 14:00:18 -0700, m...@freebsd.org wrote: >> On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: >> > Author: ken >> > Date: Tue May 31 17:29:58 2011 >> > New Revision: 222537 >> > URL: http://svn.freebsd.org/changeset/base/222537 >> > >> > Log: >> > ?Fix apparent garbage in the message buffer. >> > >> > ?While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix >> > ?scrambled console output, the message buffer and syslog were still getting >> > ?log messages one character at a time. ?While all of the characters still >> > ?made it into the log (courtesy of atomic operations), they were often >> > ?interleaved when there were multiple threads writing to the buffer at the >> > ?same time. >> >> This seems to panic my box with "lock "msgbuf" 0xfe0127e0 >> already initialized". >> >> Unfortunately, though I booted with a fresh CURRENT this morning >> successfully, both /boot/kernel and /boot/kernel.old give this panic. >> To add insult to injury, when the kernel drops into the debugger, my >> keyboard input no longer works so I can't get a stack, etc. > > Uh-oh! > >> So: >> >> 1) Is there anything else I can do to help debug this? >> 2) how can I resurrect this box without a reinstall? >> >> I will try to repro on a virtual machine so I have a snapshot to come back >> to. > > My guess is that this is an issue with the message buffer reinitialization > path. lock_init() (called by mtx_init()) has an assert to make sure that > the lock is initialized, and that is just a flag check. > > Since the spin lock is part of the message buffer structure, if it is held > over from a previous boot, the LO_INITIALIZED flag may still be set. > > Try power cycling the machine. If it is an issue with re-initialization, > that should clear the memory and allow you to boot. Hmm, apparently my previous presses of the power button weren't long enough. I let it sit off for 20 seconds and it boots okay now. Thanks, matthew > My testing has been with VMs (under Xen), so the reinit path has probably > not been tested as fully as it should have been. Sorry about that! > > As for the debugger, that's another issue altogether. It does work for me, > but then again if the spin lock initialization is broken for the message > buffer that may affect things. > > Try a cold boot and see if that helps. If so, I think we can probably just > bzero the mutex in msgbuf_reinit() and that will fix things. > > Ken > -- > Kenneth Merry > k...@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: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 15:02:37 -0700, m...@freebsd.org wrote: > On Tue, May 31, 2011 at 2:46 PM, Kenneth D. Merry wrote: > > On Tue, May 31, 2011 at 14:00:18 -0700, m...@freebsd.org wrote: > >> On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry > >> wrote: > >> > Author: ken > >> > Date: Tue May 31 17:29:58 2011 > >> > New Revision: 222537 > >> > URL: http://svn.freebsd.org/changeset/base/222537 > >> > > >> > Log: > >> > ?Fix apparent garbage in the message buffer. > >> > > >> > ?While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix > >> > ?scrambled console output, the message buffer and syslog were still > >> > getting > >> > ?log messages one character at a time. ?While all of the characters still > >> > ?made it into the log (courtesy of atomic operations), they were often > >> > ?interleaved when there were multiple threads writing to the buffer at > >> > the > >> > ?same time. > >> > >> This seems to panic my box with "lock "msgbuf" 0xfe0127e0 > >> already initialized". > >> > >> Unfortunately, though I booted with a fresh CURRENT this morning > >> successfully, both /boot/kernel and /boot/kernel.old give this panic. > >> To add insult to injury, when the kernel drops into the debugger, my > >> keyboard input no longer works so I can't get a stack, etc. > > > > Uh-oh! > > > >> So: > >> > >> 1) Is there anything else I can do to help debug this? > >> 2) how can I resurrect this box without a reinstall? > >> > >> I will try to repro on a virtual machine so I have a snapshot to come back > >> to. > > > > My guess is that this is an issue with the message buffer reinitialization > > path. ?lock_init() (called by mtx_init()) has an assert to make sure that > > the lock is initialized, and that is just a flag check. > > > > Since the spin lock is part of the message buffer structure, if it is held > > over from a previous boot, the LO_INITIALIZED flag may still be set. > > > > Try power cycling the machine. ?If it is an issue with re-initialization, > > that should clear the memory and allow you to boot. > > Hmm, apparently my previous presses of the power button weren't long > enough. I let it sit off for 20 seconds and it boots okay now. Okay, so it probably is the re-initialization code. Can you try this patch and see if it survives a warm boot? I also changed the initialization path, so we don't get tripped up by garbage left in memory. Also, does the debugger work now that it has booted successfully? Thanks, Ken -- Kenneth Merry k...@freebsd.org Index: subr_msgbuf.c === --- subr_msgbuf.c (revision 222537) +++ subr_msgbuf.c (working copy) @@ -61,6 +61,7 @@ mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_needsnl = 0; + bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); } @@ -95,6 +96,7 @@ mbp->msg_lastpri = -1; /* Assume that the old message buffer didn't end in a newline. */ mbp->msg_needsnl = 1; + bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); } ___ 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: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 3:11 PM, Kenneth D. Merry wrote: > On Tue, May 31, 2011 at 15:02:37 -0700, m...@freebsd.org wrote: >> On Tue, May 31, 2011 at 2:46 PM, Kenneth D. Merry wrote: >> > On Tue, May 31, 2011 at 14:00:18 -0700, m...@freebsd.org wrote: >> >> On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry >> >> wrote: >> >> > Author: ken >> >> > Date: Tue May 31 17:29:58 2011 >> >> > New Revision: 222537 >> >> > URL: http://svn.freebsd.org/changeset/base/222537 >> >> > >> >> > Log: >> >> > ?Fix apparent garbage in the message buffer. >> >> > >> >> > ?While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix >> >> > ?scrambled console output, the message buffer and syslog were still >> >> > getting >> >> > ?log messages one character at a time. ?While all of the characters >> >> > still >> >> > ?made it into the log (courtesy of atomic operations), they were often >> >> > ?interleaved when there were multiple threads writing to the buffer at >> >> > the >> >> > ?same time. >> >> >> >> This seems to panic my box with "lock "msgbuf" 0xfe0127e0 >> >> already initialized". >> >> >> >> Unfortunately, though I booted with a fresh CURRENT this morning >> >> successfully, both /boot/kernel and /boot/kernel.old give this panic. >> >> To add insult to injury, when the kernel drops into the debugger, my >> >> keyboard input no longer works so I can't get a stack, etc. >> > >> > Uh-oh! >> > >> >> So: >> >> >> >> 1) Is there anything else I can do to help debug this? >> >> 2) how can I resurrect this box without a reinstall? >> >> >> >> I will try to repro on a virtual machine so I have a snapshot to come >> >> back to. >> > >> > My guess is that this is an issue with the message buffer reinitialization >> > path. ?lock_init() (called by mtx_init()) has an assert to make sure that >> > the lock is initialized, and that is just a flag check. >> > >> > Since the spin lock is part of the message buffer structure, if it is held >> > over from a previous boot, the LO_INITIALIZED flag may still be set. >> > >> > Try power cycling the machine. ?If it is an issue with re-initialization, >> > that should clear the memory and allow you to boot. >> >> Hmm, apparently my previous presses of the power button weren't long >> enough. I let it sit off for 20 seconds and it boots okay now. > > Okay, so it probably is the re-initialization code. Can you try this patch > and see if it survives a warm boot? I also changed the initialization > path, so we don't get tripped up by garbage left in memory. This patch survived a warm reboot (shutdown -r now). > Also, does the debugger work now that it has booted successfully? The debugger (or rather, my keyboard in the debugger) works on a successful boot. I used sysctl debug.kdb.enter=1 to test it. Thanks, matthew ___ 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 commit: r222550 - head/sys/kern
Author: ken Date: Tue May 31 22:39:32 2011 New Revision: 222550 URL: http://svn.freebsd.org/changeset/base/222550 Log: Fix a bug introduced in revision 222537. In msgbuf_reinit() and msgbuf_init(), we weren't initializing the mutex. Depending on the contents of memory, the LO_INITIALIZED flag might be set on the mutex (either due to a warm reboot, and the message buffer remaining in place, or due to garbage in memory) and in that case, with INVARIANTS turned on, we would trigger an assertion that the mutex had already been initialized. Fix this by bzeroing the message buffer mutex for the _init() and _reinit() paths. Reported by: mdf Modified: head/sys/kern/subr_msgbuf.c Modified: head/sys/kern/subr_msgbuf.c == --- head/sys/kern/subr_msgbuf.c Tue May 31 21:42:34 2011(r222549) +++ head/sys/kern/subr_msgbuf.c Tue May 31 22:39:32 2011(r222550) @@ -61,6 +61,7 @@ msgbuf_init(struct msgbuf *mbp, void *pt mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; mbp->msg_needsnl = 0; + bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); } @@ -95,6 +96,7 @@ msgbuf_reinit(struct msgbuf *mbp, void * mbp->msg_lastpri = -1; /* Assume that the old message buffer didn't end in a newline. */ mbp->msg_needsnl = 1; + bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); } ___ 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: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 15:16:05 -0700, m...@freebsd.org wrote: > On Tue, May 31, 2011 at 3:11 PM, Kenneth D. Merry wrote: > > On Tue, May 31, 2011 at 15:02:37 -0700, m...@freebsd.org wrote: > >> On Tue, May 31, 2011 at 2:46 PM, Kenneth D. Merry wrote: > >> > On Tue, May 31, 2011 at 14:00:18 -0700, m...@freebsd.org wrote: > >> >> On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry > >> >> wrote: > >> >> > Author: ken > >> >> > Date: Tue May 31 17:29:58 2011 > >> >> > New Revision: 222537 > >> >> > URL: http://svn.freebsd.org/changeset/base/222537 > >> >> > > >> >> > Log: > >> >> > ?Fix apparent garbage in the message buffer. > >> >> > > >> >> > ?While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to > >> >> > fix > >> >> > ?scrambled console output, the message buffer and syslog were still > >> >> > getting > >> >> > ?log messages one character at a time. ?While all of the characters > >> >> > still > >> >> > ?made it into the log (courtesy of atomic operations), they were often > >> >> > ?interleaved when there were multiple threads writing to the buffer > >> >> > at the > >> >> > ?same time. > >> >> > >> >> This seems to panic my box with "lock "msgbuf" 0xfe0127e0 > >> >> already initialized". > >> >> > >> >> Unfortunately, though I booted with a fresh CURRENT this morning > >> >> successfully, both /boot/kernel and /boot/kernel.old give this panic. > >> >> To add insult to injury, when the kernel drops into the debugger, my > >> >> keyboard input no longer works so I can't get a stack, etc. > >> > > >> > Uh-oh! > >> > > >> >> So: > >> >> > >> >> 1) Is there anything else I can do to help debug this? > >> >> 2) how can I resurrect this box without a reinstall? > >> >> > >> >> I will try to repro on a virtual machine so I have a snapshot to come > >> >> back to. > >> > > >> > My guess is that this is an issue with the message buffer > >> > reinitialization > >> > path. ?lock_init() (called by mtx_init()) has an assert to make sure that > >> > the lock is initialized, and that is just a flag check. > >> > > >> > Since the spin lock is part of the message buffer structure, if it is > >> > held > >> > over from a previous boot, the LO_INITIALIZED flag may still be set. > >> > > >> > Try power cycling the machine. ?If it is an issue with re-initialization, > >> > that should clear the memory and allow you to boot. > >> > >> Hmm, apparently my previous presses of the power button weren't long > >> enough. ?I let it sit off for 20 seconds and it boots okay now. > > > > Okay, so it probably is the re-initialization code. ?Can you try this patch > > and see if it survives a warm boot? ?I also changed the initialization > > path, so we don't get tripped up by garbage left in memory. > > This patch survived a warm reboot (shutdown -r now). Cool! I just checked in the patch. > > Also, does the debugger work now that it has booted successfully? > > The debugger (or rather, my keyboard in the debugger) works on a > successful boot. I used sysctl debug.kdb.enter=1 to test it. Ahh, glad things are working there too. Let me know if you (or anyone else) run into any more issues. Thanks for testing this! Ken -- Kenneth Merry k...@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: r221853 - in head/sys: dev/md dev/null sys vm
On Tue, May 31, 2011 at 2:48 PM, Pieter de Goeje wrote: > On Sunday 29 May 2011 05:01:57 m...@freebsd.org wrote: >> On Sat, May 28, 2011 at 12:03 PM, Pieter de Goeje wrote: >> > To me it looks like it's not able to cache the zeroes anymore. Is this >> > intentional? I tried to change ZERO_REGION_SIZE back to 64K but that >> > didn't help. >> >> Hmm. I don't have access to my FreeBSD box over the weekend, but I'll >> run this on my box when I get back to work. >> >> Meanwhile you could try setting ZERO_REGION_SIZE to PAGE_SIZE and I >> think that will restore things to the original performance. > > Indeed it does. I couldn't find any authoritative docs stating wether or not > the cache on this CPU is virtually indexed, but apparently at least some of > it is. On my physical box (some Dell thing from about 2008), I ran 10 loops of dd if=/dev/zero of=/dev/null bs=XX count=XX where bs went by powers of 2 from 512 bytes to 2M, and count was set so that the dd always transferred 8GB. I compared ZERO_REGION_SIZE of 64k and 2M on amd64. The summary of the ministat(1) output is: bs=512b - no difference bs=1K - no difference bs=2k - no difference bs=4k - no difference bs=8k - no difference bs=16k - no difference bs=32k - no difference bs=64k - no difference bs=128k - 2M is 0.69% faster bs=256k - 2M is 0.98% faster bs=512k - 2M is 0.65% faster bs=1M - 2M is 1.02% faster bs=2M - 2M is 2.17% slower I'll play again with a 4K buffer. For some applications (/dev/zero) a small size is sufficient. For some (md(4)) a ZERO_REGION_SIZE at least as large as the sectorsize is desired so that a single kernel buffer pointer can be used to set up a uio for VOP_WRITE(9). Attached is the ministat output; I hope it makes it. :-) Thanks, matthew x /data/zero-amd64-small/zero-512.txt + /data/zero-amd64-large/zero-512.txt +--+ | + x| |+ + +x*x+ +x x * x+x +x| | |__|__AM___MA___|___| | +--+ N Min MaxMedian AvgStddev x 10 13.564276 13.666499 13.590373 13.591993 0.030172083 + 10 13.49174 13.616263 13.569925 13.568006 0.033884281 No difference proven at 95.0% confidence x /data/zero-amd64-small/zero-1024.txt + /data/zero-amd64-large/zero-1024.txt +--+ |++ ++xx x x +* ++ xx++| | ||___AAM__M|_| | +--+ N Min MaxMedian AvgStddev x 10 7.155384 7.182849 7.168076 7.16613820.01041489 + 10 7.124263 7.207363 7.170449 7.1647896 0.023453662 No difference proven at 95.0% confidence x /data/zero-amd64-small/zero-2048.txt + /data/zero-amd64-large/zero-2048.txt +--+ | + | |+ + +xx *x +* xx+ ++xx x| ||_|A_M__M__A_|_| | +--+ N Min MaxMedian AvgStddev x 10 3.827242 3.867095 3.837901 3.839988 0.012983755 + 10 3.809213 3.843682 3.835748 3.8302765 0.011340307 No difference proven at 95.0% confidence x /data/zero-amd64-small/zero-4096.txt + /data/zero-amd64-large/zero-4096.txt +--+ |+ + ++xxx x + + * x+ ++ x x x| | |___AM_M_A___|_| | +--+ N Min MaxMedian AvgStddev x 10 2.165541 2.201224 2.173227 2.1769029 0.013803193 + 10 2.161362 2.185911 2.172388 2.1719634 0.0088129371 No difference proven at 95.0% confidence x /data/zero-amd64-small/zero-8192.txt + /data/zero-amd64-large/zero-8192.txt +--+ |+x| |+ x + + +x +x++x+ x xx + x x| | |__|___A__M_A_|___| | +--
Re: svn commit: r221853 - in head/sys: dev/md dev/null sys vm
On Tue, May 31, 2011 at 3:47 PM, wrote: > On Tue, May 31, 2011 at 2:48 PM, Pieter de Goeje wrote: >> On Sunday 29 May 2011 05:01:57 m...@freebsd.org wrote: >>> On Sat, May 28, 2011 at 12:03 PM, Pieter de Goeje wrote: >>> > To me it looks like it's not able to cache the zeroes anymore. Is this >>> > intentional? I tried to change ZERO_REGION_SIZE back to 64K but that >>> > didn't help. >>> >>> Hmm. I don't have access to my FreeBSD box over the weekend, but I'll >>> run this on my box when I get back to work. >>> >>> Meanwhile you could try setting ZERO_REGION_SIZE to PAGE_SIZE and I >>> think that will restore things to the original performance. >> >> Indeed it does. I couldn't find any authoritative docs stating wether or not >> the cache on this CPU is virtually indexed, but apparently at least some of >> it is. > > On my physical box (some Dell thing from about 2008), I ran 10 loops > of dd if=/dev/zero of=/dev/null bs=XX count=XX where bs went by powers > of 2 from 512 bytes to 2M, and count was set so that the dd always > transferred 8GB. I compared ZERO_REGION_SIZE of 64k and 2M on amd64. > > The summary of the ministat(1) output is: > > bs=512b - no difference > bs=1K - no difference > bs=2k - no difference > bs=4k - no difference > bs=8k - no difference > bs=16k - no difference > bs=32k - no difference > bs=64k - no difference > bs=128k - 2M is 0.69% faster > bs=256k - 2M is 0.98% faster > bs=512k - 2M is 0.65% faster > bs=1M - 2M is 1.02% faster > bs=2M - 2M is 2.17% slower > > I'll play again with a 4K buffer. The data is harder to parse precisely, but in general it looks like on my box using a 4K buffer results in significantly worse performance when the dd(1) block size is larger than 4K. How much worse depends on the block size, but it goes from 6% at bs=8k to 17% at bs>=256k. Showing 4k/64k/2M ZERO_REGION_SIZE graphically in the ministat(1) output also makes it clear that the difference between 64k and 2M is nearly insignificant on my box compared to using 4k. http://people.freebsd.org/~mdf/zero-ministat.txt Cheers, matthew ___ 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 commit: r222551 - head/sys/dev/cxgbe
Author: np
Date: Tue May 31 23:49:13 2011
New Revision: 222551
URL: http://svn.freebsd.org/changeset/base/222551
Log:
Firmware device log.
# sysctl dev.t4nex.0.devlog
MFC after:mdf's sysctl+sbuf changes are MFC'd
Modified:
head/sys/dev/cxgbe/t4_main.c
Modified: head/sys/dev/cxgbe/t4_main.c
==
--- head/sys/dev/cxgbe/t4_main.cTue May 31 22:39:32 2011
(r222550)
+++ head/sys/dev/cxgbe/t4_main.cTue May 31 23:49:13 2011
(r222551)
@@ -271,6 +271,7 @@ static void setup_memwin(struct adapter
static int cfg_itype_and_nqueues(struct adapter *, int, int,
struct intrs_and_queues *);
static int prep_firmware(struct adapter *);
+static int get_devlog_params(struct adapter *, struct devlog_params *);
static int get_capabilities(struct adapter *, struct fw_caps_config_cmd *);
static int get_params(struct adapter *, struct fw_caps_config_cmd *);
static void t4_set_desc(struct adapter *);
@@ -297,6 +298,7 @@ static int sysctl_holdoff_pktc_idx(SYSCT
static int sysctl_qsize_rxq(SYSCTL_HANDLER_ARGS);
static int sysctl_qsize_txq(SYSCTL_HANDLER_ARGS);
static int sysctl_handle_t4_reg64(SYSCTL_HANDLER_ARGS);
+static int sysctl_devlog(SYSCTL_HANDLER_ARGS);
static inline void txq_start(struct ifnet *, struct sge_txq *);
static uint32_t fconf_to_mode(uint32_t);
static uint32_t mode_to_fconf(uint32_t);
@@ -402,6 +404,9 @@ t4_attach(device_t dev)
if (rc != 0)
goto done; /* error message displayed already */
+ /* Read firmware devlog parameters */
+ (void) get_devlog_params(sc, &sc->params.devlog);
+
/* Get device capabilities and select which ones we'll use */
rc = get_capabilities(sc, &caps);
if (rc != 0) {
@@ -1420,6 +1425,34 @@ prep_firmware(struct adapter *sc)
}
static int
+get_devlog_params(struct adapter *sc, struct devlog_params *dlog)
+{
+ struct fw_devlog_cmd devlog_cmd;
+ uint32_t meminfo;
+ int rc;
+
+ bzero(&devlog_cmd, sizeof(devlog_cmd));
+ devlog_cmd.op_to_write = htobe32(V_FW_CMD_OP(FW_DEVLOG_CMD) |
+ F_FW_CMD_REQUEST | F_FW_CMD_READ);
+ devlog_cmd.retval_len16 = htobe32(FW_LEN16(devlog_cmd));
+ rc = -t4_wr_mbox(sc, sc->mbox, &devlog_cmd, sizeof(devlog_cmd),
+ &devlog_cmd);
+ if (rc != 0) {
+ device_printf(sc->dev,
+ "failed to get devlog parameters: %d.\n", rc);
+ bzero(dlog, sizeof (*dlog));
+ return (rc);
+ }
+
+ meminfo = be32toh(devlog_cmd.memtype_devlog_memaddr16_devlog);
+ dlog->memtype = G_FW_DEVLOG_CMD_MEMTYPE_DEVLOG(meminfo);
+ dlog->start = G_FW_DEVLOG_CMD_MEMADDR16_DEVLOG(meminfo) << 4;
+ dlog->size = be32toh(devlog_cmd.memsize_devlog);
+
+ return (0);
+}
+
+static int
get_capabilities(struct adapter *sc, struct fw_caps_config_cmd *caps)
{
int rc;
@@ -2387,6 +2420,10 @@ t4_sysctls(struct adapter *sc)
CTLTYPE_STRING | CTLFLAG_RD, &intr_pktcount, sizeof(intr_pktcount),
sysctl_int_array, "A", "interrupt holdoff packet counter values");
+ SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "devlog",
+ CTLTYPE_STRING | CTLFLAG_RD, sc, 0,
+ sysctl_devlog, "A", "device log");
+
return (0);
}
@@ -2730,6 +2767,120 @@ sysctl_handle_t4_reg64(SYSCTL_HANDLER_AR
return (sysctl_handle_64(oidp, &val, 0, req));
}
+const char *devlog_level_strings[] = {
+ [FW_DEVLOG_LEVEL_EMERG] = "EMERG",
+ [FW_DEVLOG_LEVEL_CRIT] = "CRIT",
+ [FW_DEVLOG_LEVEL_ERR] = "ERR",
+ [FW_DEVLOG_LEVEL_NOTICE]= "NOTICE",
+ [FW_DEVLOG_LEVEL_INFO] = "INFO",
+ [FW_DEVLOG_LEVEL_DEBUG] = "DEBUG"
+};
+
+const char *devlog_facility_strings[] = {
+ [FW_DEVLOG_FACILITY_CORE] = "CORE",
+ [FW_DEVLOG_FACILITY_SCHED] = "SCHED",
+ [FW_DEVLOG_FACILITY_TIMER] = "TIMER",
+ [FW_DEVLOG_FACILITY_RES]= "RES",
+ [FW_DEVLOG_FACILITY_HW] = "HW",
+ [FW_DEVLOG_FACILITY_FLR]= "FLR",
+ [FW_DEVLOG_FACILITY_DMAQ] = "DMAQ",
+ [FW_DEVLOG_FACILITY_PHY]= "PHY",
+ [FW_DEVLOG_FACILITY_MAC]= "MAC",
+ [FW_DEVLOG_FACILITY_PORT] = "PORT",
+ [FW_DEVLOG_FACILITY_VI] = "VI",
+ [FW_DEVLOG_FACILITY_FILTER] = "FILTER",
+ [FW_DEVLOG_FACILITY_ACL]= "ACL",
+ [FW_DEVLOG_FACILITY_TM] = "TM",
+ [FW_DEVLOG_FACILITY_QFC]= "QFC",
+ [FW_DEVLOG_FACILITY_DCB]= "DCB",
+ [FW_DEVLOG_FACILITY_ETH]= "ETH",
+ [FW_DEVLOG_FACILITY_OFLD] = "OFLD",
+ [FW_DEVLOG_FACILITY_RI] = "RI",
+ [FW_DEVLOG_FACILITY_ISCSI] = "ISCSI",
+ [FW_DEVLOG_FACILITY_FCOE] = "FCOE",
+ [FW_DEVLOG_FACILITY_FOISCSI]= "FOISCSI",
+ [FW_DEVLOG
svn commit: r222552 - head/sys/dev/cxgbe
Author: np
Date: Wed Jun 1 01:32:58 2011
New Revision: 222552
URL: http://svn.freebsd.org/changeset/base/222552
Log:
Provide hit-count with rest of the information about a filter.
MFC after:1 week
Modified:
head/sys/dev/cxgbe/t4_main.c
Modified: head/sys/dev/cxgbe/t4_main.c
==
--- head/sys/dev/cxgbe/t4_main.cTue May 31 23:49:13 2011
(r222551)
+++ head/sys/dev/cxgbe/t4_main.cWed Jun 1 01:32:58 2011
(r222552)
@@ -305,6 +305,7 @@ static uint32_t mode_to_fconf(uint32_t);
static uint32_t fspec_to_fconf(struct t4_filter_specification *);
static int get_filter_mode(struct adapter *, uint32_t *);
static int set_filter_mode(struct adapter *, uint32_t);
+static inline uint64_t get_filter_hits(struct adapter *, uint32_t);
static int get_filter(struct adapter *, struct t4_filter *);
static int set_filter(struct adapter *, struct t4_filter *);
static int del_filter(struct adapter *, struct t4_filter *);
@@ -3064,6 +3065,20 @@ done:
return (rc);
}
+static inline uint64_t
+get_filter_hits(struct adapter *sc, uint32_t fid)
+{
+ uint32_t tcb_base = t4_read_reg(sc, A_TP_CMM_TCB_BASE);
+ uint64_t hits;
+
+ t4_write_reg(sc, PCIE_MEM_ACCESS_REG(A_PCIE_MEM_ACCESS_OFFSET, 0),
+ tcb_base + (fid + sc->tids.ftid_base) * TCB_SIZE);
+ t4_read_reg(sc, PCIE_MEM_ACCESS_REG(A_PCIE_MEM_ACCESS_OFFSET, 0));
+ hits = t4_read_reg64(sc, MEMWIN0_BASE + 16);
+
+ return (be64toh(hits));
+}
+
static int
get_filter(struct adapter *sc, struct t4_filter *t)
{
@@ -3087,7 +3102,10 @@ get_filter(struct adapter *sc, struct t4
t->idx = i;
t->l2tidx = f->l2t ? f->l2t->idx : 0;
t->smtidx = f->smtidx;
- t->hits = 0;/* XXX implement */
+ if (f->fs.hitcnts)
+ t->hits = get_filter_hits(sc, t->idx);
+ else
+ t->hits = UINT64_MAX;
t->fs = f->fs;
return (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"
Re: svn commit: r222423 - head/sbin/newfs
On Sat May 28 11, Niclas Zeising wrote: > On 2011-05-28 17:14, Kirk McKusick wrote: > > Author: mckusick > > Date: Sat May 28 15:14:50 2011 > > New Revision: 222423 > > URL: http://svn.freebsd.org/changeset/base/222423 > > > > Log: > > Update the manual page to reflect the new 32K/4K defaults. > > > > Reminded by: Ivan Voras > > > > Modified: > > head/sbin/newfs/newfs.8 > > > > See docs/157354 as well. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=157354 i believe tuning(7) might also benefit from updating it to reflect the new defaults. cheers. alex > > Regards! > -- > Niclas -- a13x ___ 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: r222537 - in head/sys: kern sys
on 31/05/2011 20:29 Kenneth D. Merry said the following: > + mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); Sorry that I didn't gather myself together for a review before this change got actually committed. Do you see any reason not to make this spinlock recursive? I am a little bit worried about "exotic" situations like receiving an NMI in the middle of printing and wanting to print in the NMI context, or similar things that penetrate contexts with disabled interrupts - e.g. Machine Check Exception. Also it's not clear to me if there won't any bigger damage in the situations like those described above. P.S. I have been thinking about fixing the problem in a different fashion, via reserving portions of dmesg buffer for a whole message using CAS: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031535.html -- Andriy Gapon ___ 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"
