kern/188685: [cam] QUIRK: Add 4K quirks for WD Red and Black MHDDs
Number: 188685
Category: kern
Synopsis: [cam] QUIRK: Add 4K quirks for WD Red and Black MHDDs
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Wed Apr 16 09:20:00 UTC 2014
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 9.2-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 9.2-STABLE FreeBSD 9.2-STABLE #0 r264285: Tue
Apr 8 17:25:59 PDT 2014
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
Description:
Add some 4K quirks for the following Western Digital Caviar MHDDs:
- WD Black, 4000GB, WD4003FZEX
- WD Black, 3000GB, WD3003FZEX
- WD Black, 2000GB, WD2003FZEX
- WD Black, 1000GB, WD1003FZEX
- WD Black, 500GB, WD5003AZEX (yes this really does use 4K physical)
- WD Black, 2000GB, WD2002FAEX
- WD Black, 1000GB, WD1002FAEX
- WD Black, 4000GB, WD4001FAEX
- WD Black, 3000GB, WD3001FAEX
- WD Black, 2000GB, WD2001FAEX
- WD Black, 1000GB, WD1001FAEX
- WD Red,750GB, WD7500BFCX (yes this really does use 4K physical)
- WD Red, 1000GB, WD10JFCX
Also add a comment reflecting that WDRX also matches some models
of Red drives (not listed above) and not just Green.
How-To-Repeat:
n/a
Fix:
Apply below patch.
--- sys/cam/ata/ata_da.c.orig 2014-01-20 17:15:51.0 -0800
+++ sys/cam/ata/ata_da.c2014-04-16 02:09:04.326162134 -0700
@@ -235,16 +235,31 @@
/*quirks*/ADA_Q_4K
},
{
+ /* WDC Caviar Red Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, *, WDC WDCX*, * },
+ /*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 */
+ /* WDC Caviar Green/Red Advanced Format (4k) drives */
{ T_DIRECT, SIP_MEDIA_FIXED, *, WDC WDRX*, * },
/*quirks*/ADA_Q_4K
},
{
+ /* WDC Caviar Red Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, *, WDC WD??CX*, * },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /* WDC Caviar Black Advanced Format (4k) drives */
+ { T_DIRECT, SIP_MEDIA_FIXED, *, WDC WD??EX*, * },
+ /*quirks*/ADA_Q_4K
+ },
+ {
/* WDC Caviar Green Advanced Format (4k) drives */
{ T_DIRECT, SIP_MEDIA_FIXED, *, WDC WD??RS*, * },
/*quirks*/ADA_Q_4K
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/188685: [cam] QUIRK: Add 4K quirks for WD Red and Black MHDDs
Patch available here: http://jdc.koitsu.org/freebsd/188685/ata_da.c.diff -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/182360: nslookup emits SIGSEGV when Ctrl-D (EOF) pressed
On Wed, Sep 25, 2013 at 08:42:25PM +, delp...@freebsd.org wrote: Synopsis: nslookup emits SIGSEGV when Ctrl-D (EOF) pressed State-Changed-From-To: open-patched State-Changed-By: delphij State-Changed-When: Wed Sep 25 20:41:38 UTC 2013 State-Changed-Why: Fixed in -HEAD, MFC reminder. (Note that it's too late to fix this for 9.2-RELEASE). Responsible-Changed-From-To: freebsd-bugs-delphij Responsible-Changed-By: delphij Responsible-Changed-When: Wed Sep 25 20:41:38 UTC 2013 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=182360 Should HEAD r255873 be reverted as a result of HEAD r255891? I see HEAD r255891 got MFC'd (as r255924) -- thank you. I had a feeling the issue was in libedit but wasn't entirely certain which was the proper place to fix it. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/182360: nslookup emits SIGSEGV when Ctrl-D (EOF) pressed
Number: 182360 Category: bin Synopsis: nslookup emits SIGSEGV when Ctrl-D (EOF) pressed Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Tue Sep 24 22:30:00 UTC 2013 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 9.2-PRERELEASE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r255608: Mon Sep 16 00:47:48 PDT 2013 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 Description: nslookup crashes (SIGSEGV/sig11) when Ctrl-D (EOF) is entered any time during the interactive prompt. I can reproduce this on two completely separate amd64 9.2-PRERELEASE systems (one is r255608, another is r255864), on completely different hardware. Not sure if this issue is caused by introduced bugs/changes in libedit, or in recent versions of BIND that have been imported. I do not build my systems' /lib with debug symbols enabled so tracking this down is something someone with debug symbols will need to do (unless they can look at the code and know what's wrong). If one thinks this is a system configuration issue, I can provide /etc/make.conf and /etc/src.conf (the only two relevant file I can think of) if asked. Validation and a stack trace is below: $ nslookup ^DSegmentation fault: 11 (core dumped) $ ls -l nslookup.core -rw---1 jdc users 13996032 Sep 24 15:16 nslookup.core $ gdb /usr/bin/nslookup nslookup.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `nslookup'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libedit.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libedit.so.7 Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008014e61ab in strlen () from /lib/libc.so.7 [New Thread 801c08000 (LWP 101041/nslookup)] [New Thread 801c07c00 (LWP 101040/nslookup)] [New Thread 801c07800 (LWP 101039/nslookup)] [New Thread 801c07400 (LWP 100757/nslookup)] (gdb) bt #0 0x0008014e61ab in strlen () from /lib/libc.so.7 #1 0x000801461a7e in strdup () from /lib/libc.so.7 #2 0x0008009f3dfb in history () from /lib/libedit.so.7 #3 0x0008009f3735 in history () from /lib/libedit.so.7 #4 0x0008009e1fbf in add_history () from /lib/libedit.so.7 #5 0x0040eacd in getinput () #6 0x0054df38 in run () #7 0x000800fb9e10 in pthread_getprio () from /lib/libthr.so.3 #8 0x in ?? () (gdb) How-To-Repeat: 1. Run nslookup 2. Press Ctrl-D (EOF) Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/178040: [cam] [patch] Add 4K quirks for Intel 320 and 510-series SSDs
Number: 178040
Category: kern
Synopsis: [cam] [patch] Add 4K quirks for Intel 320 and 510-series SSDs
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Mon Apr 22 04:50:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 9.1-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #1 r249715M: Sun
Apr 21 21:07:17 PDT 2013
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
Description:
Intel's 320-series and 510-series SSDs advertise 512-byte sectors
sizes for both logical and physical. This adds ADA_Q_4K quirks
for both. (Intel, for whatever reason, didn't add physical sector
advertisement in ATA IDENTIFY; maybe they're strictly adhering to
non-draft specs, I don't know...)
Validation of my claims:
root@icarus:~ # smartctl -a /dev/ada0
...
Model Family: Intel 320 Series SSDs
Device Model: INTEL SSDSA2CW080G3
...
Firmware Version: 4PC10302
User Capacity:80,026,361,856 bytes [80.0 GB]
Sector Size: 512 bytes logical/physical
...
root@icarus:~ # smartctl -a /dev/ada5
...
Model Family: Intel 510 Series SSDs
Device Model: INTEL SSDSC2MH120A2
...
Firmware Version: PPG4
User Capacity:120,034,123,776 bytes [120 GB]
Sector Size: 512 bytes logical/physical
...
How-To-Repeat:
n/a
Fix:
Apply below patch. Patch will also be available at the following
URL once I get a GNATS PR:
http://jdc.koitsu.org/freebsd/{prnum}/
Index: sys/cam/ata/ata_da.c
===
--- sys/cam/ata/ata_da.c(revision 249745)
+++ sys/cam/ata/ata_da.c(working copy)
@@ -350,6 +350,14 @@ static struct ada_quirk_entry ada_quirk_table[] =
},
{
/*
+* Intel 320 Series SSDs
+* 4k optimised trim only works in 4k requests + 4k aligned
+*/
+ { T_DIRECT, SIP_MEDIA_FIXED, *, INTEL SSDSA2CW*, * },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /*
* Intel 330 Series SSDs
* 4k optimised trim only works in 4k requests + 4k aligned
* Submitted by: Steven Hartland
steven.hartl...@multiplay.co.uk
@@ -360,6 +368,14 @@ static struct ada_quirk_entry ada_quirk_table[] =
},
{
/*
+* Intel 510 Series SSDs
+* 4k optimised trim only works in 4k requests + 4k aligned
+*/
+ { T_DIRECT, SIP_MEDIA_FIXED, *, INTEL SSDSC2MH*, * },
+ /*quirks*/ADA_Q_4K
+ },
+ {
+ /*
* OCZ Deneva R Series SSDs
* 4k optimised trim only works in 4k requests + 4k aligned
* Submitted by: Steven Hartland
steven.hartl...@multiplay.co.uk
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/177319: Add more x86 CPU feature flag definitions
Number: 177319
Category: kern
Synopsis: Add more x86 CPU feature flag definitions
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Sat Mar 23 19:20:02 UTC 2013
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 9.1-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r248403: Sat
Mar 16 20:33:01 PDT 2013
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
Description:
While reading this thread:
http://lists.freebsd.org/pipermail/freebsd-current/2013-March/040666.html
It occurred to me that we might be missing some x86 CPU feature flag
definitions in comparison to other OSes (e.g. Linux).
My comparison source was the Linux 3.8.4 source code, specifically
arch/x86/include/asm/cpufeature.h. That can be viewed here:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/include/asm/cpufeature.h?h=linux-3.8.y
How-To-Repeat:
n/a
Fix:
Apply below patch (intended for stable/9, but can be backported to head
I'm sure). Patch is also available here once I get a PR number:
http://jdc.koitsu.org/freebsd/{prnum}/
I strongly recommend someone familiar with these bits review this patch
first, as AFAIK these are only for cosmetical representation rather than
operational, but I could be wrong.
Index: sys/amd64/amd64/identcpu.c
===
--- sys/amd64/amd64/identcpu.c (revision 248655)
+++ sys/amd64/amd64/identcpu.c (working copy)
@@ -366,13 +366,13 @@ printcpuinfo(void)
\017b14
\020LWP /* Lightweight Profiling */
\021FMA4 /* 4-operand FMA instructions */
- \022b17
+ \022TCE /* Translation Cache Extension
*/
\023b18
\024NodeId/* NodeId MSR support */
\025b20
\026TBM /* Trailing Bit Manipulation */
\027Topology /* Topology Extensions */
- \030b23
+ \030CorePerfC /* Core Perf. Counter
Extensions */
\031b24
\032b25
\033b26
@@ -390,9 +390,17 @@ printcpuinfo(void)
\020
\001GSFSBASE
\002TSCADJ
+ \004BMI1
+ \005HLE
+ \006AVX2
\010SMEP
+ \011BMI2
\012ENHMOVSB
\013INVPCID
+ \014RTM
+ \023RDSEED
+ \024ADX
+ \025SMAP
);
}
Index: sys/i386/i386/identcpu.c
===
--- sys/i386/i386/identcpu.c(revision 248655)
+++ sys/i386/i386/identcpu.c(working copy)
@@ -842,13 +842,13 @@ printcpuinfo(void)
\017b14
\020LWP /* Lightweight Profiling */
\021FMA4 /* 4-operand FMA instructions */
- \022b17
+ \022TCE /* Translation Cache Extension
*/
\023b18
\024NodeId/* NodeId MSR support */
\025b20
\026TBM /* Trailing Bit Manipulation */
\027Topology /* Topology Extensions */
- \030b23
+ \030CorePerfC /* Core Perf. Counter
Extensions */
\031b24
\032b25
\033b26
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
conf/177217: rc.d/ddb -- squelch warning when ddb_enable=yes but DDB missing from kernel
Number: 177217
Category: conf
Synopsis: rc.d/ddb -- squelch warning when ddb_enable=yes but DDB
missing from kernel
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Fri Mar 22 01:20:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 9.1-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r248403: Sat
Mar 16 20:33:01 PDT 2013
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
Description:
If a user has ddb_enable=yes in rc.conf, but their kernel is
lacking options DDB and friends, then the following message is
shown during boot:
/etc/rc.d/ddb: WARNING: failed precmd routine for ddb
The reason is that returning 1 from inside of precmd causes rc.subr
to emit the above warning. Returning 0 would cause rc.subr to
continue on and try to run /sbin/ddb, which emits even more errors.
IMO, the simplest way to solve this dillema is to use exit 1 and
bail out of the rc.d script ASAP; some other rc.d scripts use this
method as well.
To make this fact clearer to future committers/readers, I added
an explanation comment. I also added use of $SYSCTL_N to be
consistent with other scripts.
I should note I did try getting rid of the precmd stuff and instead
making a ddb_start() routine + doing the necessary magic, but this
induces all sorts of edge cases/nuances relating to required_files
and command_args and some other things. exit 1 just seems easier.
If someone has a better/cleaner method, I'm happy to test such.
How-To-Repeat:
1. Set ddb_enable=yes in rc.conf on a system lacking DDB support
in the kernel
2. Run /etc/rc.d/ddb start
Fix:
Patch is below, and will be available at the following URL one I
get a PR number:
http://jdc.koitsu.org/freebsd/{prnum}/
Verified as working on stable/9 (r248403).
Index: etc/rc.d/ddb
===
--- etc/rc.d/ddb(revision 248604)
+++ etc/rc.d/ddb(working copy)
@@ -19,8 +19,11 @@ stop_cmd=:
ddb_prestart()
{
# Silently exit if ddb is not enabled
- if [ -z `sysctl -Nq debug.ddb.scripting.scripts` ]; then
- return 1
+ # NOTE: exit is needed here, not return, else rc.subr emits
+ # a failed precmd routine warning when ddb_enable=yes is
+ # used on a system which lacks DDB support in the kernel.
+ if [ -z `$SYSCTL_N -q debug.ddb.scripting.scripts` ]; then
+ exit 1
fi
}
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/176807: libgssapi causes segfaults on i386
Number: 176807
Category: bin
Synopsis: libgssapi causes segfaults on i386
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Sun Mar 10 08:40:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 9.1-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r247132: Thu
Feb 21 19:15:34 PST 2013
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
Description:
Issue:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html
Some key details -- such as that Heimdal is **not** the problem:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057818.html
Fix/patch for the issue:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057830.html
Possibly related PR:
kern/147454
How-To-Repeat:
The thread/issue actually contains the necessary bits that you
need to install + configuration details to reproduce the issue.
I was able to reproduce it on a freshly installed system. So
for how to repeat the problem, you gotta read the communications
between Reko Turja and myself.
Fix:
Patch is available for download here:
http://jdc.koitsu.org/freebsd/gss_release_buffer.c.patch
And is also attached below.
--- lib/libgssapi/gss_release_buffer.c.orig 2009-08-03 01:13:06.0
-0700
+++ lib/libgssapi/gss_release_buffer.c 2010-07-17 19:47:25.0 -0700
@@ -37,7 +37,7 @@
{
*minor_status = 0;
- if (buffer-value)
+ if (buffer-length buffer-value)
free(buffer-value);
_gss_buffer_zero(buffer);
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/176181: rc.subr emitting warnings for non-defined xxx_enable vars, and errors/warnings not going to terminal
Number: 176181 Category: bin Synopsis: rc.subr emitting warnings for non-defined xxx_enable vars, and errors/warnings not going to terminal Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Feb 15 22:10:00 UTC 2013 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 9.1-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 16:55:49 PST 2013 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 Description: The following discussion has taken place on freebsd-stable: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072303.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072304.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072317.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072318.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072319.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072320.html There are two issues as I see them: 1. Lack of a defined xxx_enable variable in rc.conf(5) (regardless of the value) results in warn() being called. Ex: WARNING: $svnserve_enable is not set properly - see rc.conf(5). A lack of definition of xxx_enable variable should be treated as the same as xxx_enable=no (i.e. the service is disabled) and should not emit a warning. 2. When using service(8), the warn() calls are not making it to the user's terminal -- they only end up in /var/log/messages. Looking at rc.subr(8), it appears the echo statements in err() and warn() are not making it to the user's terminal. I tried using logger -s and it made no difference -- it's as if some part of the rc.subr infrastructure is redirecting stdout and stderr to /dev/null way before the echo statements. How-To-Repeat: * Install a port that uses rc.d in some way * Make sure there is no xxx_enable variable set for it in /etc/rc.conf * Run service -e * Check /var/log/messages Fix: The patch provided by Alfred Bartsch does address issue #1, however I feel that (effectively) changing checkyesno() to remove the warn() is not the right solution. I believe it would be wiser to handle the situation through, for example, an if [ -n $xxx_enable ] test of some kind. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
misc/174625: Numerous typo fixes in comments/strings
Number: 174625
Category: misc
Synopsis: Numerous typo fixes in comments/strings
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Sat Dec 22 01:30:00 UTC 2012
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 9.1-PRERELEASE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0
r244089: Mon Dec 10 08:20:27 PST 2012
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
Description:
Fix numerous typos/spelling mistakes in kernel/userland src
bits:
oustanding (should be outstanding)
connecter (should be connector, sans French spelling)
conected(should be connected)
conecting (should be connecting)
disconect (should be disconnect)
diconnect (should be disconnect)
syncronous (should be synchronous)
asyncronous (should be asynchronous)
These are only changed for comments or printf()-like strings;
no functions are renamed, etc...
Some of these may need to be submit upstream to official sources
(ex. tcsh, ZFS, WPA, PCI Vendors List, OpenSM), so if the commiter
wants to exclude those, I understand.
How-To-Repeat:
Fix:
Below diff is against base/stable/9 r244573; manually backporting
these to CURRENT/HEAD may be needed.
Patch will be available at the below URL once I get a PR number:
http://jdc.koitsu.org/freebsd/{prnum}
Index: contrib/ofed/management/opensm/opensm/osm_ucast_ftree.c
===
--- contrib/ofed/management/opensm/opensm/osm_ucast_ftree.c (revision
244573)
+++ contrib/ofed/management/opensm/opensm/osm_ucast_ftree.c (working copy)
@@ -2731,7 +2731,7 @@ __osm_ftree_rank_leaf_switches(IN ftree_fabric_t *
case IB_NODE_TYPE_CA:
/* HCA connected directly to another HCA - not FatTree
*/
OSM_LOG(p_ftree-p_osm-log, OSM_LOG_ERROR, ERR AB0F:
- CA conected directly to another CA:
+ CA connected directly to another CA:
0x%016 PRIx64 --- 0x%016 PRIx64 \n,
__osm_ftree_hca_get_guid_ho(p_hca),
cl_ntoh64(osm_node_get_node_guid
@@ -2841,7 +2841,7 @@ __osm_ftree_fabric_construct_hca_ports(IN ftree_fa
case IB_NODE_TYPE_CA:
/* HCA connected directly to another HCA - not FatTree
*/
OSM_LOG(p_ftree-p_osm-log, OSM_LOG_ERROR, ERR AB11:
- CA conected directly to another CA:
+ CA connected directly to another CA:
0x%016 PRIx64 --- 0x%016 PRIx64 \n,
cl_ntoh64(osm_node_get_node_guid(p_node)),
cl_ntoh64(remote_node_guid));
Index: contrib/tcsh/nls/C/set2
===
--- contrib/tcsh/nls/C/set2 (revision 244573)
+++ contrib/tcsh/nls/C/set2 (working copy)
@@ -76,7 +76,7 @@ $set 2
73 Third Last Realtime Signal
74 Second Last Realtime Signal
75 Last Realtime Signal
-76 LAN Asyncronous I/O
+76 LAN Asynchronous I/O
77 PTY read/write availability
78 I/O intervention required
79 HFT monitor mode granted
Index: contrib/tcsh/nls/german/set2
===
--- contrib/tcsh/nls/german/set2(revision 244573)
+++ contrib/tcsh/nls/german/set2(working copy)
@@ -76,7 +76,7 @@ $set 2
73 Third Last Realtime Signal
74 Second Last Realtime Signal
75 Last Realtime Signal
-76 LAN Asyncronous I/O
+76 LAN Asynchronous I/O
77 PTY read/write availability
78 I/O intervention required
79 HFT monitor mode granted
Index: contrib/tcsh/nls/russian/set2
===
--- contrib/tcsh/nls/russian/set2 (revision 244573)
+++ contrib/tcsh/nls/russian/set2 (working copy)
@@ -76,7 +76,7 @@ $set 2
73 Third Last Realtime Signal
74 Second Last Realtime Signal
75 Last Realtime Signal
-76 LAN Asyncronous I/O
+76 LAN Asynchronous I/O
77 PTY read/write availability
78 I/O intervention required
79 HFT monitor mode granted
Index: contrib/tcsh/nls/ukrainian/set2
===
--- contrib/tcsh/nls/ukrainian/set2 (revision 244573)
+++ contrib/tcsh/nls/ukrainian/set2 (working copy)
@@ -76,7 +76,7 @@ $set 2
73 Third Last Realtime Signal
74 Second Last Realtime Signal
75 Last Realtime Signal
-76 LAN Asyncronous I/O
+76 LAN
Re: bin/159833: camcontrol(8): [patch] add ATA security options to camcontrol including secure erase
The following reply was made to PR bin/159833; it has been noted by GNATS. From: Jeremy Chadwick j...@koitsu.org To: bug-follo...@freebsd.org, kill...@multiplay.co.uk Cc: m...@freebsd.org, a...@freebsd.org Subject: Re: bin/159833: camcontrol(8): [patch] add ATA security options to camcontrol including secure erase Date: Thu, 8 Nov 2012 10:54:44 -0800 This incredibly useful PR/patch has been neglected for over a year. SSDs are mainstream now and being used commonly by FreeBSD users. This greatly increases the want for secure erase. Sure, we have TRIM for UFS, and HEAD/CURRENT has TRIM for ZFS, and that's good at keeping the FTL optimal on an SSD, but let's be reasonable here. Alexander and Andriy, I know you're both busy, but can either of you review this? If you need/want an updated patch (specifically for 8.3 and 9.x), I can provide updated ones (will take me some time of course). Thanks guys. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/173010: Backgrounded processes remain in ttyin state / SIGCONT does not remove sleeping processes from sleep queue
Another follow-up in the thread -- fix has been committed to HEAD, pending 2 weeks for MFC. This fix **will not** make it into 9.1-RELEASE, sadly, but will obviously be available in RELENG_9 going forward. From: Ed Schouten e...@80386.nl To: Jeremy Chadwick j...@koitsu.org Date: Thu, 25 Oct 2012 11:06:09 +0200 Cc: Konstantin Belousov kostik...@gmail.com, freebsd-sta...@freebsd.org, j...@freebsd.org Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? 2012/10/25 Jeremy Chadwick j...@koitsu.org: I assume a commit to HEAD + MFC in 2 weeks is in order? Yes. We're far too late to get this into 9.1, so I'll MFC it after the release. Patch committed as r242078! -- Ed Schouten e...@80386.nl ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/173010: Backgrounded processes remain in ttyin state / SIGCONT does not remove sleeping processes from sleep queue
Mail thread on -stable at this point, including a patch from ed@
From: Ed Schouten e...@80386.nl
To: Konstantin Belousov kostik...@gmail.com
Date: Thu, 25 Oct 2012 09:45:11 +0200
Cc: Jeremy Chadwick j...@koitsu.org, freebsd-sta...@freebsd.org,
j...@freebsd.org
Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug?
Hi all,
2012/10/23 Ed Schouten e...@80386.nl:
Will try to come up with a decent patch tomorrow evening.
Ahem; the day after tomorrow. Jeremy, could you please try the following patch?
http://80386.nl/pub/tty-bg-read.txt
I decomposed the TTY read routine into four separate functions to
improve clarity. While this was initially true, I think it's a pity
the four functions are constantly becoming a bit more complex.
The same issue is also present on the output path, but I have no idea
how realistic/hard it is to fix this issue. Also, it might not really
be an issue in practice. If you do a large write and become a
non-foreground process group, you might be able to circumvent TOSTOP
while the write() is in transit.
Fixing this might be tedious, because we currently enforce that writes
to a TTY are serialized. Blocking inside the write() might then cause
a deadlock. But in my opinion, I would prefer the serialization over
the enforcing of TOSTOP.
Thanks again for reporting the issue!
--
Ed Schouten e...@80386.nl
From: Jeremy Chadwick j...@koitsu.org
To: Ed Schouten e...@80386.nl
Date: Thu, 25 Oct 2012 01:46:03 -0700
Cc: Konstantin Belousov kostik...@gmail.com, freebsd-sta...@freebsd.org,
j...@freebsd.org
Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug?
On Thu, Oct 25, 2012 at 09:45:11AM +0200, Ed Schouten wrote:
2012/10/23 Ed Schouten e...@80386.nl:
Will try to come up with a decent patch tomorrow evening.
Ahem; the day after tomorrow. Jeremy, could you please try the following
patch?
http://80386.nl/pub/tty-bg-read.txt
I decomposed the TTY read routine into four separate functions to
improve clarity. While this was initially true, I think it's a pity
the four functions are constantly becoming a bit more complex.
The same issue is also present on the output path, but I have no idea
how realistic/hard it is to fix this issue. Also, it might not really
be an issue in practice. If you do a large write and become a
non-foreground process group, you might be able to circumvent TOSTOP
while the write() is in transit.
Fixing this might be tedious, because we currently enforce that writes
to a TTY are serialized. Blocking inside the write() might then cause
a deadlock. But in my opinion, I would prefer the serialization over
the enforcing of TOSTOP.
After the patch, testing with grep and cat, and checking cv/state for
the latter case:
(01:30:39 jdc@icarus) ~ $ csh
% grep -r -2011 .
[1] 1964
% jobs
[1] + Suspended (tty input) grep -r -2011 .
% fg
grep -r -2011 .
^C
% jobs
% grep -r -2011 .
^Z
Suspended
% bg
[1]grep -r -2011 .
[1] + Suspended (tty input) grep -r -2011 .
% fg
grep -r -2011 .
^C
% cat
[1] 2042
% jobs
[1] + Suspended (tty input) cat
% ps -auxwU jdc | grep cat
jdc 2042 0.0 0.0 9908 1496 1 T 1:34AM 0:00.00 cat
jdc 2044 0.0 0.0 16268 1864 1 S+1:34AM 0:00.00 grep cat
% top -b -U jdc | grep cat
2042 jdc 1 200 9908K 1496K STOP0 0:00 0.00% cat
2047 jdc 1 200 16268K 1864K piperd 0 0:00 0.00% grep cat
% fg
cat
^C
% exit
I do not get dropped characters or witness any other anomalies. I
tested behaviour with /bin/sh, as well as bash. All seems good.
Thanks again for reporting the issue!
No, thank *you* and others for looking + fixing it! :-)
I assume a commit to HEAD + MFC in 2 weeks is in order?
I'll update the PR with this part of our mail thread.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
Index: sys/kern/tty.c
===
--- sys/kern/tty.c (Revision 241962)
+++ sys/kern/tty.c (Arbeitskopie)
@@ -361,7 +361,7 @@
return (p-p_session == tp-t_session p-p_flag P_CONTROLT);
}
-static int
+int
tty_wait_background(struct tty *tp, struct thread *td, int sig)
{
struct proc *p = td-td_proc;
@@ -433,13 +433,6 @@
error = ttydev_enter(tp);
if (error)
goto done;
-
- error = tty_wait_background(tp, curthread, SIGTTIN);
- if (error) {
- tty_unlock(tp);
- goto done;
- }
-
error = ttydisc_read(tp, uio, ioflag);
tty_unlock(tp);
Index: sys/kern/tty_ttydisc.c
===
--- sys/kern/tty_ttydisc.c (Revision 241962)
+++ sys/kern/tty_ttydisc.c (Arbeitskopie)
@@ -126,6
Re: kern/173010: Backgrounded processes remain in ttyin state / SIGCONT does not remove sleeping processes from sleep queue
The following reply was made to PR kern/173010; it has been noted by GNATS. From: Jeremy Chadwick j...@koitsu.org To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/173010: Backgrounded processes remain in ttyin state / SIGCONT does not remove sleeping processes from sleep queue Date: Thu, 25 Oct 2012 01:51:45 -0700 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mail thread on -stable at this point, including a patch from ed@ From: Ed Schouten e...@80386.nl To: Konstantin Belousov kostik...@gmail.com Date: Thu, 25 Oct 2012 09:45:11 +0200 Cc: Jeremy Chadwick j...@koitsu.org, freebsd-sta...@freebsd.org, j...@freebsd.org Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Hi all, 2012/10/23 Ed Schouten e...@80386.nl: Will try to come up with a decent patch tomorrow evening. Ahem; the day after tomorrow. Jeremy, could you please try the following patch? http://80386.nl/pub/tty-bg-read.txt I decomposed the TTY read routine into four separate functions to improve clarity. While this was initially true, I think it's a pity the four functions are constantly becoming a bit more complex. The same issue is also present on the output path, but I have no idea how realistic/hard it is to fix this issue. Also, it might not really be an issue in practice. If you do a large write and become a non-foreground process group, you might be able to circumvent TOSTOP while the write() is in transit. Fixing this might be tedious, because we currently enforce that writes to a TTY are serialized. Blocking inside the write() might then cause a deadlock. But in my opinion, I would prefer the serialization over the enforcing of TOSTOP. Thanks again for reporting the issue! -- Ed Schouten e...@80386.nl From: Jeremy Chadwick j...@koitsu.org To: Ed Schouten e...@80386.nl Date: Thu, 25 Oct 2012 01:46:03 -0700 Cc: Konstantin Belousov kostik...@gmail.com, freebsd-sta...@freebsd.org, j...@freebsd.org Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? On Thu, Oct 25, 2012 at 09:45:11AM +0200, Ed Schouten wrote: 2012/10/23 Ed Schouten e...@80386.nl: Will try to come up with a decent patch tomorrow evening. Ahem; the day after tomorrow. Jeremy, could you please try the following patch? http://80386.nl/pub/tty-bg-read.txt I decomposed the TTY read routine into four separate functions to improve clarity. While this was initially true, I think it's a pity the four functions are constantly becoming a bit more complex. The same issue is also present on the output path, but I have no idea how realistic/hard it is to fix this issue. Also, it might not really be an issue in practice. If you do a large write and become a non-foreground process group, you might be able to circumvent TOSTOP while the write() is in transit. Fixing this might be tedious, because we currently enforce that writes to a TTY are serialized. Blocking inside the write() might then cause a deadlock. But in my opinion, I would prefer the serialization over the enforcing of TOSTOP. After the patch, testing with grep and cat, and checking cv/state for the latter case: (01:30:39 jdc@icarus) ~ $ csh % grep -r -2011 . [1] 1964 % jobs [1] + Suspended (tty input) grep -r -2011 . % fg grep -r -2011 . ^C % jobs % grep -r -2011 . ^Z Suspended % bg [1]grep -r -2011 . [1] + Suspended (tty input) grep -r -2011 . % fg grep -r -2011 . ^C % cat [1] 2042 % jobs [1] + Suspended (tty input) cat % ps -auxwU jdc | grep cat jdc 2042 0.0 0.0 9908 1496 1 T 1:34AM 0:00.00 cat jdc 2044 0.0 0.0 16268 1864 1 S+1:34AM 0:00.00 grep cat % top -b -U jdc | grep cat 2042 jdc 1 200 9908K 1496K STOP0 0:00 0.00% cat 2047 jdc 1 200 16268K 1864K piperd 0 0:00 0.00% grep cat % fg cat ^C % exit I do not get dropped characters or witness any other anomalies. I tested behaviour with /bin/sh, as well as bash. All seems good. Thanks again for reporting the issue! No, thank *you* and others for looking + fixing it! :-) I assume a commit to HEAD + MFC in 2 weeks is in order? I'll update the PR with this part of our mail thread. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tty-bg-read.txt Index: sys/kern/tty.c === --- sys/kern/tty.c (Revision 241962) +++ sys/kern/tty.c (Arbeitskopie) @@ -361,7 +361,7 @@ return (p
kern/173010: Backgrounded processes remain in ttyin state / SIGCONT does not remove sleeping processes from sleep queue
Number: 173010 Category: kern Synopsis: Backgrounded processes remain in ttyin state / SIGCONT does not remove sleeping processes from sleep queue Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Oct 24 03:50:00 UTC 2012 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 9.1-PRERELEASE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sun Oct 21 05:24:09 PDT 2012 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 Description: The following bug/quirk in the tty layer has been discovered. This issue affects processes which require tty input but are backgrounded. This issue has been discussed with kib@ and ed@ on freebsd-stable who confirmed the issue. Full details are in the thread titled pty/tty or signal strangeness, or grep/bsdgrep bug? here: http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/thread.html#70204 This affects any process that requires tty input; it's not specific grep/bsdgrep. How-To-Repeat: Step-by-step instructions are available: http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070204.html Fix: kib@ did provide a patch but mentioned it would be best to wait for what ed@ proposes. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2))
Number: 167321 Category: kern Synopsis: Implement sysctl to control kernel accounting log messages (e.g. acct(2)) Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Thu Apr 26 11:40:08 UTC 2012 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.2-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 10 17:43:50 PST 2012 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: The periodic script daily/310.accounting results in accounting being fully stopped then fully started every day. This causes the message Accounting disabled followed by Accounting enabled being printed on the console (syslog level kern.notice). This happens because daily/310.accounting calls /etc/rc.d/accounting with the argument rotate_log. This function quite literally calls /usr/sbin/accton twice. See accounting_rotate_log() (read it slowly) to see what's going on. The messages comes from src/sys/kern/kern_acct.c, where log(LOG_NOTICE, ...) is called every time accounting is toggled via the acct(2) syscall (accomplished via accton(8)). The end result is a kernel message buffer that will eventually be filled with the above two messages. This is extremely annoying, and unecessary for something like accounting log rotation. We wanted to use accounting (mainly for tracking disk I/O on a per-user and per-process level), but because of this problem, we had to cease use of it. How-To-Repeat: 1. Set accounting_enabled=yes in /etc/rc.conf 2. Start accounting via /etc/rc.d/accounting start 3. Look at dmesg or /var/log/messages 4. Run /etc/periodic/daily/310.accounting 5. Look at dmesg or /var/log/messages Fix: There's a couple ways to fix this, but I'm of the opinion this is the best choice with the least breakage: Implement a sysctl called kern.acct_logging which would control whether or not the log() statements are called. 1=enable logging, 0=disable logging. Default value would be 1 (to remain fully compatible with the existing model). Toggling this sysctl WOULD NOT result in any log() message being generated (i.e. no Account logging disabled message or similar), because if it did, we've solved absolutely nothing. Key point for those concerned about security (wait, what if someone turns off logging? Wouldn't you want to know that?): acct(2) can only be called by root, and sysctls can only be modified by root. An attacker who wanted to circumvent accounting would have to already have root. Thus, the sysctl variable poses no security concern. If there are still somehow security concerns, then this could be made into a loader-adjustable-only tunable. I'd be happy to write the kernel code for this (it can't be that complex), but I would need someone senior to make sure it's safe/wouldn't cause problems. The kernel is not my most familiar of playgrounds. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2))
The following reply was made to PR kern/167321; it has been noted by GNATS.
From: Jeremy Chadwick j...@koitsu.org
To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Cc:
Subject: Re: kern/167321: Implement sysctl to control kernel accounting log
messages (e.g. acct(2))
Date: Thu, 26 Apr 2012 05:00:08 -0700
Proposed patch is attached, as well as available at the below URL.
Please note I HAVE NOT tested this, but it seems simple enough.
http://jdc.koitsu.org/freebsd/167321/
Patch written for RELENG_8, may/may not patch cleanly on others.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
--- SNIP ---
--- src/sys/kern/kern_acct.c.orig 2009-08-03 01:13:06.0 -0700
+++ src/sys/kern/kern_acct.c 2012-04-26 04:53:31.428339406 -0700
@@ -146,6 +146,9 @@
#define ACCT_RUNNING1 /* Accounting kthread is running. */
#define ACCT_EXITREQ2 /* Accounting kthread should exit. */
+/* sysctl variable used for controlling non-critical log() calls */
+static int acct_logging = 1;
+
/*
* Values associated with enabling and disabling accounting
*/
@@ -188,6 +191,9 @@
SYSCTL_INT(_kern, OID_AUTO, acct_suspended, CTLFLAG_RD, acct_suspended, 0,
Accounting suspended or not);
+SYSCTL_INT(_kern, OID_AUTO, acct_logging, CTLFLAG_RW, acct_logging, 0
+ Log non-critical accounting messages);
+
/*
* Accounting system call. Written based on the specification and previous
* implementation done by Mark Tinguely.
@@ -299,7 +305,8 @@
}
acct_configured = 1;
sx_xunlock(acct_sx);
- log(LOG_NOTICE, Accounting enabled\n);
+ if (acct_logging)
+ log(LOG_NOTICE, Accounting enabled\n);
return (error);
}
@@ -319,7 +326,8 @@
acct_vp = NULL;
acct_cred = NULL;
acct_flags = 0;
- log(LOG_NOTICE, Accounting disabled\n);
+ if (acct_logging)
+ log(LOG_NOTICE, Accounting disabled\n);
return (error);
}
@@ -593,13 +601,15 @@
if (sb.f_bavail (int64_t)(acctresume * sb.f_blocks /
100)) {
acct_suspended = 0;
- log(LOG_NOTICE, Accounting resumed\n);
+ if (acct_logging)
+ log(LOG_NOTICE, Accounting resumed\n);
}
} else {
if (sb.f_bavail = (int64_t)(acctsuspend * sb.f_blocks /
100)) {
acct_suspended = 1;
- log(LOG_NOTICE, Accounting suspended\n);
+ if (acct_logging)
+ log(LOG_NOTICE, Accounting suspended\n);
}
}
}
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2))
...and also the patch for the acct(2) man page, documenting this variable. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | --- SNIP --- --- src/lib/libc/sys/acct.2.orig2009-08-03 01:13:06.0 -0700 +++ src/lib/libc/sys/acct.2 2012-04-26 05:11:42.670706272 -0700 @@ -87,6 +87,16 @@ .It Va kern.acct_suspend The percentage of free disk space below which process accounting will suspend. +.It Va kern.acct_logging +If set to 0, the kernel will inhibit console messages indicating when +accounting is enabled, disabled, suspended, or resumed. This can be +useful when the +.Xr periodic.conf 5 +variable +.Va daily_accounting_enable +is set to +.Dq YES . +The default value is 1 (enabled). .El .Sh RETURN VALUES On error -1 is returned. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2))
The following reply was made to PR kern/167321; it has been noted by GNATS. From: Jeremy Chadwick j...@koitsu.org To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2)) Date: Thu, 26 Apr 2012 05:18:02 -0700 ...and also the patch for the acct(2) man page, documenting this variable. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | --- SNIP --- --- src/lib/libc/sys/acct.2.orig 2009-08-03 01:13:06.0 -0700 +++ src/lib/libc/sys/acct.22012-04-26 05:11:42.670706272 -0700 @@ -87,6 +87,16 @@ .It Va kern.acct_suspend The percentage of free disk space below which process accounting will suspend. +.It Va kern.acct_logging +If set to 0, the kernel will inhibit console messages indicating when +accounting is enabled, disabled, suspended, or resumed. This can be +useful when the +.Xr periodic.conf 5 +variable +.Va daily_accounting_enable +is set to +.Dq YES . +The default value is 1 (enabled). .El .Sh RETURN VALUES On error -1 is returned. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2))
Note for readers/committer: hold off on doing anything quite yet. I'm in conversation with John Baldwin (jhb@) about this issue, and he's given me a patch (to both the periodic script and the kernel) that may rectify the entire excess logging situation entirely. Will report back in the next few weeks (have health things/doctors visits going on, so please be patient). Thanks. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2))
The following reply was made to PR kern/167321; it has been noted by GNATS. From: Jeremy Chadwick j...@koitsu.org To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/167321: Implement sysctl to control kernel accounting log messages (e.g. acct(2)) Date: Thu, 26 Apr 2012 22:19:13 -0700 Note for readers/committer: hold off on doing anything quite yet. I'm in conversation with John Baldwin (jhb@) about this issue, and he's given me a patch (to both the periodic script and the kernel) that may rectify the entire excess logging situation entirely. Will report back in the next few weeks (have health things/doctors visits going on, so please be patient). Thanks. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: [sysctl] [patch] Implement sysctl to control kernel accounting log messages (e.g. acct(2))
On Thu, Apr 26, 2012 at 09:30:01AM -0400, John Baldwin wrote:
Hmm, reading the rc.d script and the kernel code, it is not clear to me why
you are seeing Accounting disabled messages at all. You should be seeing
two Accounting enabled messages, but no disabled.
Taken from our logs on one box (but they all show the same behaviour):
/var/log/messages:Apr 26 00:39:47 ra kernel: Accounting enabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting disabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting enabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting disabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting enabled
/var/log/messages:Apr 26 04:38:40 ra kernel: Accounting disabled
00:39 = when we enabled accounting for the very first time
03:01 = entries caused by periodic script
04:38 = when we disabled accounting due to this problem.
However, it seems that the 'rotate_log' command in
/etc/rc.d/accounting can be simplified. The kernel doesn't care about
the pathname, so it doesn't need to have accton re- run when the file
is renamed from its temporary filename to it's full name.
You could then update the acct() system call to not log the message
when accounting is switched from one file to another atomically. I
think these two changes will address your problem while preserving the
useful logging:
Your kernel patch looks a *lot* more elegant and logical (yep I
understand it :-) ). I'll give it a try on my home machine here and
report back the results. Might be a few days though given health
problems and doctors visits going on.
Thanks as usual, John!
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
Index: etc/rc.d/accounting
===
--- etc/rc.d/accounting (revision 234685)
+++ etc/rc.d/accounting (working copy)
@@ -65,9 +65,7 @@
mv ${accounting_file} ${accounting_file}.0
if checkyesno accounting_enable; then
- ln $_file ${accounting_file##*/}
- ${accounting_command} ${accounting_file}
- unlink $_file
+ mv $_file ${accounting_file}
fi
}
Index: sys/kern/kern_acct.c
===
--- sys/kern/kern_acct.c (revision 234685)
+++ sys/kern/kern_acct.c (working copy)
@@ -297,9 +297,11 @@
return (error);
}
}
- acct_configured = 1;
+ if (!acct_configured) {
+ acct_configured = 1;
+ log(LOG_NOTICE, Accounting enabled\n);
+ }
sx_xunlock(acct_sx);
- log(LOG_NOTICE, Accounting enabled\n);
return (error);
}
--
John Baldwin
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/167321: [sysctl] [patch] Implement sysctl to control kernel accounting log messages (e.g. acct(2))
The following reply was made to PR kern/167321; it has been noted by GNATS.
From: Jeremy Chadwick j...@koitsu.org
To: John Baldwin j...@freebsd.org
Cc:
Subject: Re: kern/167321: [sysctl] [patch] Implement sysctl to control kernel
accounting log messages (e.g. acct(2))
Date: Thu, 26 Apr 2012 22:17:56 -0700
On Thu, Apr 26, 2012 at 09:30:01AM -0400, John Baldwin wrote:
Hmm, reading the rc.d script and the kernel code, it is not clear to me why
you are seeing Accounting disabled messages at all. You should be seeing
two Accounting enabled messages, but no disabled.
Taken from our logs on one box (but they all show the same behaviour):
/var/log/messages:Apr 26 00:39:47 ra kernel: Accounting enabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting disabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting enabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting disabled
/var/log/messages:Apr 26 03:01:00 ra kernel: Accounting enabled
/var/log/messages:Apr 26 04:38:40 ra kernel: Accounting disabled
00:39 = when we enabled accounting for the very first time
03:01 = entries caused by periodic script
04:38 = when we disabled accounting due to this problem.
However, it seems that the 'rotate_log' command in
/etc/rc.d/accounting can be simplified. The kernel doesn't care about
the pathname, so it doesn't need to have accton re- run when the file
is renamed from its temporary filename to it's full name.
You could then update the acct() system call to not log the message
when accounting is switched from one file to another atomically. I
think these two changes will address your problem while preserving the
useful logging:
Your kernel patch looks a *lot* more elegant and logical (yep I
understand it :-) ). I'll give it a try on my home machine here and
report back the results. Might be a few days though given health
problems and doctors visits going on.
Thanks as usual, John!
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
Index: etc/rc.d/accounting
===
--- etc/rc.d/accounting (revision 234685)
+++ etc/rc.d/accounting (working copy)
@@ -65,9 +65,7 @@
mv ${accounting_file} ${accounting_file}.0
if checkyesno accounting_enable; then
-ln $_file ${accounting_file##*/}
-${accounting_command} ${accounting_file}
-unlink $_file
+mv $_file ${accounting_file}
fi
}
Index: sys/kern/kern_acct.c
===
--- sys/kern/kern_acct.c (revision 234685)
+++ sys/kern/kern_acct.c (working copy)
@@ -297,9 +297,11 @@
return (error);
}
}
-acct_configured = 1;
+if (!acct_configured) {
+acct_configured = 1;
+log(LOG_NOTICE, Accounting enabled\n);
+}
sx_xunlock(acct_sx);
-log(LOG_NOTICE, Accounting enabled\n);
return (error);
}
--
John Baldwin
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Fwd: Re: Fwd: Re: bin/161739: top(1): top -b does not restore ICANON and ECHO terminal capabilities when exiting
The following reply was made to PR bin/161739; it has been noted by GNATS.
From: Jeremy Chadwick free...@jdc.parodius.com
To: bug-follo...@freebsd.org
Cc:
Subject: Fwd: Re: Fwd: Re: bin/161739: top(1): top -b does not restore ICANON
and ECHO terminal capabilities when exiting
Date: Tue, 17 Apr 2012 10:40:04 -0700
Below is an Email I sent kib@ about this problem, as he said he could
not reproduce it.
I spent 3 hours on this today, writing a debugging routine to print out
all the internal variables and the terminal structures (termios) to
find out where the problem lies.
It appears that now the -b flag works fine, but -a is now broken
as a result of that commit.
The explanation for what's happening in the code is below. Someone just
needs to figure out why is_a_terminal becomes 0 during the program's
execution (printing output, etc.) because this is what causes the issue.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
- Forwarded message from Jeremy Chadwick free...@jdc.parodius.com -
From: Jeremy Chadwick free...@jdc.parodius.com
To: Konstantin Belousov kostik...@gmail.com
Date: Tue, 17 Apr 2012 10:29:33 -0700
Subject: Re: Fwd: Re: bin/161739: top(1): top -b does not restore ICANON and
ECHO terminal capabilities when exiting
I stand partially corrected -- it looks like your change made recently
fixed the problem in the PR for the -b flag only; but now -a has the
problem.
I wrote a debug printing routine and shoved it into top.c to look at the
results of new_settings and old_settings (termios struct), and also what
the current terminal settings are for comparison and some other internal
variables which are used to determine when/how to reset the terminal.
There is definitely a problem.
(10:23:01 jdc@omake) ~/usr.bin/top $ ./top -a 2/tmp/results
{pressed q after 1 iteration}
(10:23:18 jdc@omake) ~/usr.bin/top $ (10:23:24 jdc@omake) ~/usr.bin/top $
{I had to type stty icanon echo to restore things}
Results:
(10:23:26 jdc@omake) ~/usr.bin/top $ cat /tmp/results
DEBUG: before init_termcap
DEBUG: is_a_terminal = 0
DEBUG: smart_terminal = 0
DEBUG: interactive= 2 (Maybe)
DEBUG: displays = 0
DEBUG: old_settings:
DEBUG: c_iflag = 0x0
DEBUG: c_oflag = 0x0
DEBUG: c_cflag = 0x0
DEBUG: c_lflag = 0x0 ()
DEBUG: new_settings:
DEBUG: c_iflag = 0x0
DEBUG: c_oflag = 0x0
DEBUG: c_cflag = 0x0
DEBUG: c_lflag = 0x0 ()
DEBUG: current terminal settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x5cb (ECHOKE,ECHOE,ECHO,ECHOCTL,ISIG,ICANON,IEXTEN,)
DEBUG: after init_termcap
DEBUG: is_a_terminal = 0
DEBUG: smart_terminal = 1
DEBUG: interactive= 2 (Maybe)
DEBUG: displays = 0
DEBUG: old_settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x5cb (ECHOKE,ECHOE,ECHO,ECHOCTL,ISIG,ICANON,IEXTEN,)
DEBUG: new_settings:
DEBUG: c_iflag = 0x0
DEBUG: c_oflag = 0x0
DEBUG: c_cflag = 0x0
DEBUG: c_lflag = 0x0 ()
DEBUG: current terminal settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x5cb (ECHOKE,ECHOE,ECHO,ECHOCTL,ISIG,ICANON,IEXTEN,)
DEBUG: before init_screen
DEBUG: is_a_terminal = 0
DEBUG: smart_terminal = 1
DEBUG: interactive= 1 (Yes)
DEBUG: displays = -1
DEBUG: old_settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x5cb (ECHOKE,ECHOE,ECHO,ECHOCTL,ISIG,ICANON,IEXTEN,)
DEBUG: new_settings:
DEBUG: c_iflag = 0x0
DEBUG: c_oflag = 0x0
DEBUG: c_cflag = 0x0
DEBUG: c_lflag = 0x0 ()
DEBUG: current terminal settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x5cb (ECHOKE,ECHOE,ECHO,ECHOCTL,ISIG,ICANON,IEXTEN,)
DEBUG: after init_screen
DEBUG: is_a_terminal = 1
DEBUG: smart_terminal = 1
DEBUG: interactive= 1 (Yes)
DEBUG: displays = -1
DEBUG: old_settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x5cb (ECHOKE,ECHOE,ECHO,ECHOCTL,ISIG,ICANON,IEXTEN,)
DEBUG: new_settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x4c3 (ECHOKE,ECHOE,ECHOCTL,ISIG,IEXTEN,)
DEBUG: current terminal settings:
DEBUG: c_iflag = 0x2b02
DEBUG: c_oflag = 0x3
DEBUG: c_cflag = 0x4b00
DEBUG: c_lflag = 0x4c3 (ECHOKE,ECHOE
Re: bin/161739: top(1): top -b does not restore ICANON and ECHO terminal capabilities when exiting
The following reply was made to PR bin/161739; it has been noted by GNATS. From: Jeremy Chadwick free...@jdc.parodius.com To: bug-follo...@freebsd.org Cc: Subject: Re: bin/161739: top(1): top -b does not restore ICANON and ECHO terminal capabilities when exiting Date: Mon, 16 Apr 2012 14:46:09 -0700 This issue has now begun to affect top -a as well. I just deployed a new RELENG_8 box yesterday which has this same problem when using top -a. So it's no longer limited to just the -b flag. I do not know who/what touched code that caused this new behaviour. RELENG_8 from 2012/02/10 only behaves this way with -b RELENG_8 from 2012/04/15 behaves this way with -b and -a Please increase the priority from medium to high as a result. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
conf/166460: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts
Number: 166460
Category: conf
Synopsis: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic
scripts
Confidential: no
Severity: non-critical
Priority: medium
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Wed Mar 28 02:00:22 UTC 2012
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 8.2-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 10
17:43:50 PST 2012
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
Description:
First: not sure if I got the right Category. This might be kern
or misc.
Issue was discussed on freebsd-stable here:
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066962.html
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066978.html (root
cause)
When ipfilter is removed from the system via src.conf knob
WITHOUT_IPFILTER, periodic scripts which rely on ipfstat(8) do not
get removed during make delete-old. This results in errors
like the following during periodic security phase:
ipfstat: not found
Root cause appears to be lack of OLD_FILES entries for the two
periodic scripts in question. Patch should fix this. Only tested on
RELENG_8; other adjustments may be needed for RELENG_7 or RELENG_9.
Note that etc/periodic/security/610.ipf6denied is a tricky one: it's
both
IPFILTER-related *and* IPv6. So I'm not sure if this removal should go
under the MK_IPFILTER check or the MK_INET6 check.
How-To-Repeat:
1. Add WITHOUT_IPFILTER=true to /etc/src.conf
2. Rebuild system (world/kernel), mergemaster, etc... -- the usual
3. Run periodic security and watch for ipfstat: not found messages
Fix:
Apply below patch:
--- src/tools/build/mk/OptionalObsoleteFiles.inc.orig 2010-11-22
17:39:30.0 -0800
+++ src/tools/build/mk/OptionalObsoleteFiles.inc2012-03-27
18:56:15.167308202 -0700
@@ -605,6 +605,8 @@
OLD_FILES+=usr/share/man/man8/ipmon.8.gz
OLD_FILES+=usr/share/man/man8/ipnat.8.gz
OLD_FILES+=usr/share/man/man8/ippool.8.gz
+OLD_FILES+=etc/periodic/security/510.ipfdenied
+OLD_FILES+=etc/periodic/security/610.ipf6denied
.endif
.if ${MK_IPX} == no
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/163095: Add WITH_OPENSSH_NONE_CIPHER src.conf(5) knob
Brooks, Any word on this? It's been over 3 months, patch is included. Any political things going on which are blocking this being committed to HEAD, and then MFC'd (I absolutely need it MFC'd to RELENG_8, not to mention that's where I wrote it for -- I don't use RELENG_9). Thanks, and sorry for the bother! ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
conf/165956: periodic/daily/420.status-network should show dropped packets
Number: 165956 Category: conf Synopsis: periodic/daily/420.status-network should show dropped packets Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Mar 12 01:30:10 UTC 2012 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.2-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 10 17:43:50 PST 2012 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: Sorry if I got the Category wrong -- I can never remember what to choose for periodic scripts! The nightly periodic script for network interface statistics, daily/420.status-network, uses netstat -in. This is not the same as dropped packets caused by use of ipfw or pf; these types of dropped packets would be caused by Ethernet problems (cabling or NIC driver issues) or similar anomalies on that level. I propose that -d be added to the netstat flag list, to give more visibility into problems. How-To-Repeat: n/a Fix: Change periodic/daily/420.status-network as documented in Description. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/163095: Add WITH_OPENSSH_NONE_CIPHER src.conf(5) knob
Number: 163095
Category: bin
Synopsis: Add WITH_OPENSSH_NONE_CIPHER src.conf(5) knob
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Tue Dec 06 18:10:07 UTC 2011
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 8.2-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Dec 1
04:37:29 PST 2011
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
Description:
The recently-committed addition of the HPN patches to the base
system OpenSSH introduced the ability to make use of the None
cipher:
http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/README.hpn
However, enabling use of it requires a somewhat hackish
addition to /etc/make.conf like the following:
.if ${.CURDIR:M/usr/src/secure/*}
CFLAGS+=-DNONE_CIPHER_ENABLED
.endif
The below patch adds the ability to enable this cipher by simply
adding WITH_OPENSSH_NONE_CIPHER to one's /etc/src.conf.
The below patch was tested on RELENG_8 (with buildworld); may
require minor adjustments for application to the 9.x source.
Patch and situation itself was initially discussed with bz@ and
brooks@ privately. Desire for this is also justified via the
user community:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064727.html
How-To-Repeat:
n/a
Fix:
Apply the below patch. Patch will also be available for download
at the below URL, once I get a PR number.
http://jdc.parodius.com/freebsd/{prnum}/
Committer should be aware that the src.conf.5 man page will need
to be rebuilt prior to commit. I believe
src/tools/build/options/makeman is for this purpose.
diff -ruN /origsrc/secure/lib/libssh/Makefile src/secure/lib/libssh/Makefile
--- /origsrc/secure/lib/libssh/Makefile 2010-04-20 23:33:10.0 -0700
+++ src/secure/lib/libssh/Makefile 2011-12-06 09:38:15.976388562 -0800
@@ -39,6 +39,10 @@
LDADD+=-lgssapi -lkrb5 -lhx509 -lasn1 -lcom_err -lmd -lroken
.endif
+.if ${MK_OPENSSH_NONE_CIPHER} != no
+CFLAGS+= -DNONE_CIPHER_ENABLED
+.endif
+
NO_LINT=
DPADD+=${LIBCRYPTO} ${LIBCRYPT}
diff -ruN /origsrc/secure/usr.bin/ssh/Makefile src/secure/usr.bin/ssh/Makefile
--- /origsrc/secure/usr.bin/ssh/Makefile2010-04-20 23:33:10.0
-0700
+++ src/secure/usr.bin/ssh/Makefile 2011-12-06 09:38:24.173485693 -0800
@@ -25,6 +25,10 @@
LDADD+= -lgssapi
.endif
+.if ${MK_OPENSSH_NONE_CIPHER} != no
+CFLAGS+= -DNONE_CIPHER_ENABLED
+.endif
+
.if defined(X11BASE) || defined(LOCALBASE)
# Recommended /etc/make.conf setting is X11BASE=${LOCALBASE} for x.org
# 7.x upgrade on = 6.2, but LOCALBASE has moved out of scope of src/
diff -ruN /origsrc/secure/usr.sbin/sshd/Makefile
src/secure/usr.sbin/sshd/Makefile
--- /origsrc/secure/usr.sbin/sshd/Makefile 2010-04-20 23:33:10.0
-0700
+++ src/secure/usr.sbin/sshd/Makefile 2011-12-06 09:37:56.833786139 -0800
@@ -38,6 +38,10 @@
LDADD+= -lgssapi_krb5 -lgssapi -lkrb5 -lasn1
.endif
+.if ${MK_OPENSSH_NONE_CIPHER} != no
+CFLAGS+= -DNONE_CIPHER_ENABLED
+.endif
+
.if defined(X11BASE)
# Recommended /etc/make.conf setting is X11BASE=${LOCALBASE} for x.org
# 7.x upgrade on = 6.2, but LOCALBASE has moved out of scope of src/
diff -ruN /origsrc/share/mk/bsd.own.mk src/share/mk/bsd.own.mk
--- /origsrc/share/mk/bsd.own.mk2010-05-25 13:16:36.0 -0700
+++ src/share/mk/bsd.own.mk 2011-12-06 09:38:46.729274164 -0800
@@ -408,7 +408,8 @@
BIND_SIGCHASE \
BIND_XML \
HESIOD \
-IDEA
+IDEA \
+OPENSSH_NONE_CIPHER
.if defined(WITH_${var}) defined(WITHOUT_${var})
.error WITH_${var} and WITHOUT_${var} can't both be set.
.endif
diff -ruN /origsrc/tools/build/options/WITH_OPENSSH_NONE_CIPHER
src/tools/build/options/WITH_OPENSSH_NONE_CIPHER
--- /origsrc/tools/build/options/WITH_OPENSSH_NONE_CIPHER 1969-12-31
16:00:00.0 -0800
+++ src/tools/build/options/WITH_OPENSSH_NONE_CIPHER2011-12-06
09:39:30.929282637 -0800
@@ -0,0 +1,8 @@
+.\ $FreeBSD: $
+Set to include the None cipher into OpenSSH and its libraries.
+Additional adjustments may need to be done to system configuration
+files, such as
+.Xr sshd_config 5 ,
+to enable this cipher. Please see
+.Pa /usr/src/crypto/openssh/README.hpn
+for full details.
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/161739: top -b does not restore ICANON and ECHO terminal capabilities when exiting
Number: 161739 Category: bin Synopsis: top -b does not restore ICANON and ECHO terminal capabilities when exiting Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Oct 17 12:00:24 UTC 2011 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.2-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Sep 28 05:02:05 PDT 2011 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: It appears that top -b results in top disabling ICANON and ECHO the controlling terminal/tty, but upon exit never re-enables them. I can confirm this problem on RELENG_7 (7.4-STABLE) and RELENG_8 (8.2-STABLE). top -b does not work on RELENG_6. stty -a after running top -b shows -icanon and -echo, which confirms the bug. I have not looked at the top code to find out where the bug is, but I do see calls which adjust ICANON and ECHO capabilities on the tty, so it's definitely there. How-To-Repeat: 1. Run top -b 2. Attempt to type something into your shell or make use of an app which relies on canonical input. Fix: Manually typing stty echo icanon after using top -b will restore proper bits on the tty. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID
The following reply was made to PR bin/160494; it has been noted by GNATS. From: Jeremy Chadwick free...@jdc.parodius.com To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Sylvio C?sar Teixeira Amorim scjamo...@bsd.com.br Subject: Re: bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID Date: Tue, 6 Sep 2011 08:55:52 -0700 On Tue, Sep 06, 2011 at 08:41:39AM -0300, Sylvio C?sar Teixeira Amorim wrote: Do a patch and send me. I had a chance to review the net-snmp code. My previous claim was incorrect -- net-snmp DOES NOT suffer from the problem documented in this PR. The code in net-snmp which uses kvm_getprocs(3) is for the hrSW*Run OIDs, which (properly) uses KERN_PROC_ALL to ensure they count kernel threads for kernel modules. The hrSystemProcesses OID with net-snmp returns the correct number of system processes (not including threads). Verification: icarus# snmpwalk -v2c -c public localhost hrSystemProcesses HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 60 So this PR/issue is specific to bsnmpd. Sorry to waste your time, Sylvio! The PR should remain open as bsnmpd needs to be fixed. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID
On Tue, Sep 06, 2011 at 08:41:39AM -0300, Sylvio C?sar Teixeira Amorim wrote: Do a patch and send me. I had a chance to review the net-snmp code. My previous claim was incorrect -- net-snmp DOES NOT suffer from the problem documented in this PR. The code in net-snmp which uses kvm_getprocs(3) is for the hrSW*Run OIDs, which (properly) uses KERN_PROC_ALL to ensure they count kernel threads for kernel modules. The hrSystemProcesses OID with net-snmp returns the correct number of system processes (not including threads). Verification: icarus# snmpwalk -v2c -c public localhost hrSystemProcesses HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 60 So this PR/issue is specific to bsnmpd. Sorry to waste your time, Sylvio! The PR should remain open as bsnmpd needs to be fixed. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID
A patch has been made for this issue, and has been tested/verified: http://jdc.parodius.com/freebsd/160494/ -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID
The following reply was made to PR bin/160494; it has been noted by GNATS. From: Jeremy Chadwick free...@jdc.parodius.com To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID Date: Tue, 6 Sep 2011 09:18:49 -0700 A patch has been made for this issue, and has been tested/verified: http://jdc.parodius.com/freebsd/160494/ -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID
Number: 160494 Category: bin Synopsis: bsnmpd returns inaccurate data for hrSystemProcesses OID Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Sep 05 22:50:03 UTC 2011 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.2-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Tue Aug 23 18:20:42 PDT 2011 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: (CC'ing maintainer of ports/net-mgmt/net-snmp, since said port has the exact same problem described below. Maintainer may want to report this upstream to the net-snmp folks, since based on my review of the net-snmp code this looks like it affects multiple BSDs (any BSD that implements kvm_getprocs(3), sans Darwin which has its own code)) bsnmpd(8)'s support for HOST-MIB has a bug where the hrSystemProcesses OID returns an inaccurate number of system processes. On a machine with ~50 actual processes, hrSystemProcesses.0 reports 240 or so (this will vary per machine configuration/driver/etc. given the nature of the issue). The root cause is use of KERN_PROC_ALL when calling kvm_getprocs(3) in src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_scalars.c, function OS_getSystemProcesses. KERN_PROC_ALL, per the kvm_getprocs(3) man page, includes system processes *as well* as visible kernel threads. According to the official HOST-MIB, hrSystemProcesses should be the number of process contexts currently loaded or running; the industry norm is to return system process counts only: http://www.net-snmp.org/docs/mibs/host.html Comparatively, for hrSystemProcesses, both Linux and Solaris 10 return the actual number of processes running on the box and DO NOT include kernel threads. Use of KERN_PROC_ALL is also in function swrun_OS_get_procs in src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_swrun_tbl.c, however the comment at the top of the code indicates this is intentional (Get all visible proceses including the kernel visible threads). This code is used for the hrSWRun and hrSWRunPert OIDs. I'm of the opinion that code SHOULD NOT be changed; hrSWRun can include things like kernel modules, so kernel thread count seems relevant there. However, the spelling mistake (proceses) should be corrected. :-) hrSystemProcesses behaviour varies per FreeBSD version. Old RELENG_6 (specifically 6.4-STABLE) returns just the process count; RELENG_7 and newer return the number of system processes in addition to kernel threads. I imagine the explanation is that some kernel innards changed between FreeBSD releases, but there is no mention of that change here: http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html I would need to dig through kernel code to find the actual change that induced this. Finally, I want to point out that existing FreeBSD utilities like pkill have noted this change in the past. See lines 318-319: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/pkill/pkill.c?annotate=1.4.2.5 How-To-Repeat: Compare snmpwalk -v2c -c community some.system.name hrSystemProcesses count to that of ps -auxwww. Fix: In usr.sbin/bsnmpd/modules/snmp_hostres/hostres_scalars.c, function OS_getSystemProcesses, change KERN_PROC_ALL to KERN_PROC_PROC. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/159284: [ata] Update ATA command-to-string definitions
Number: 159284
Category: kern
Synopsis: [ata] Update ATA command-to-string definitions
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Fri Jul 29 05:40:07 UTC 2011
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 8.2-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Jun 25
20:56:03 PDT 2011
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
Description:
Update ata-queue.c to have knowledge of newer ATA commands and
what their related titles/strings are per T13/1699-D Revision 6a
working draft specification.
While I'm here, change space to underscore on command 0xc0 (for
consistency), and fix typo in command 0xf5 (FREEZE not FREE).
Can probably kick this one over to mav@ for approve/reject.
How-To-Repeat:
n/a
Fix:
Apply below patch. Intended for RELENG_8 source dated 2011/07/28.
Patch will also be available on the web here once I get a PR number:
http://jdc.parodius.com/freebsd/{PRnum}/
--- src/sys/dev/ata/ata-queue.c.orig2010-05-02 05:40:54.0 -0700
+++ src/sys/dev/ata/ata-queue.c 2011-07-28 22:17:16.957972544 -0700
@@ -726,6 +726,7 @@
else {
switch (request-u.ata.command) {
case 0x00: return (NOP);
+ case 0x03: return (CFA_REQUEST_EXTENDED_ERR);
case 0x08: return (DEVICE_RESET);
case 0x20: return (READ);
case 0x24: return (READ48);
@@ -733,18 +734,43 @@
case 0x26: return (READ_DMA_QUEUED48);
case 0x27: return (READ_NATIVE_MAX_ADDRESS48);
case 0x29: return (READ_MUL48);
+ case 0x2a: return (READ_STREAM_DMA48);
+ case 0x2b: return (READ_STREAM48);
+ case 0x2f: return (READ_LOG48);
case 0x30: return (WRITE);
case 0x34: return (WRITE48);
case 0x35: return (WRITE_DMA48);
case 0x36: return (WRITE_DMA_QUEUED48);
case 0x37: return (SET_MAX_ADDRESS48);
+ case 0x38: return (CFA_WRITE_NO_ERASE);
case 0x39: return (WRITE_MUL48);
+ case 0x3a: return (WRITE_STREAM_DMA48);
+ case 0x3b: return (WRITE_STREAM48);
+ case 0x3d: return (WRITE_DMA_FUA48);
+ case 0x3e: return (WRITE_DMA_QUEUED_FUA48);
+ case 0x3f: return (WRITE_LOG48);
+ case 0x40: return (READ_VERIFY);
+ case 0x42: return (READ_VERIFY48);
+ case 0x45: return (WRITE_UNCORRECTABLE48);
+ case 0x47: return (READ_LOG_DMA48);
+ case 0x51: return (CONFIGURE_STREAM);
+ case 0x57: return (WRITE_LOG_DMA48);
+ case 0x5b: return (TRUSTED_NONDATA);
+ case 0x5c: return (TRUSTED_RECEIVE);
+ case 0x5d: return (TRUSTED_RECEIVE_DMA);
+ case 0x5e: return (TRUSTED_SEND);
+ case 0x5f: return (TRUSTED_SEND_DMA);
+ case 0x60: return (READ_FPDMA_QUEUED);
+ case 0x61: return (WRITE_FPDMA_QUEUED);
case 0x70: return (SEEK);
+ case 0x87: return (CFA_TRANSLATE);
+ case 0x90: return (EXEC_DEVICE_DIAGNOSTIC);
+ case 0x92: return (DOWNLOAD_MICROCODE);
case 0xa0: return (PACKET_CMD);
case 0xa1: return (ATAPI_IDENTIFY);
case 0xa2: return (SERVICE);
case 0xb0: return (SMART);
- case 0xc0: return (CFA ERASE);
+ case 0xc0: return (CFA_ERASE);
case 0xc4: return (READ_MUL);
case 0xc5: return (WRITE_MUL);
case 0xc6: return (SET_MULTI);
@@ -752,8 +778,18 @@
case 0xc8: return (READ_DMA);
case 0xca: return (WRITE_DMA);
case 0xcc: return (WRITE_DMA_QUEUED);
+ case 0xcd: return (CFA_WRITE_MUL_NO_ERASE);
+ case 0xce: return (WRITE_MUL_FUA48);
+ case 0xd1: return (CHECK_MEDIA_CARD_TYPE);
+ case 0xe0: return (STANDBY_IMMEDIATE);
+ case 0xe1: return (IDLE_IMMEDIATE);
+ case 0xe2: return (STANDBY);
+ case 0xe3: return (IDLE);
+ case 0xe4: return (READ_BUFFER);
+ case 0xe5: return (CHECK_POWER_MODE);
case 0xe6: return (SLEEP);
case 0xe7: return (FLUSHCACHE);
+ case 0xe8: return (WRITE_BUFFER);
case 0xea: return (FLUSHCACHE48);
case 0xec: return (ATA_IDENTIFY);
case 0xef:
@@ -766,7 +802,12 @@
}
sprintf(buffer, SETFEATURES 0x%02x, request-u.ata.feature);
return buffer;
- case 0xf5: return (SECURITY_FREE_LOCK);
+ case 0xf1: return (SECURITY_SET_PASSWORD);
+ case 0xf2: return (SECURITY_UNLOCK);
+ case 0xf3: return (SECURITY_ERASE_PREPARE);
+ case 0xf4: return (SECURITY_ERASE_UNIT);
+ case 0xf5: return (SECURITY_FREEZE_LOCK);
+ case 0xf6: return (SECURITY_DISABLE_PASSWORD);
case 0xf8: return (READ_NATIVE_MAX_ADDRESS);
case 0xf9: return
Re: kern/89837: [pci] PCI code outputs superfluous failed to enable/disable memory/port mapping! messages
The following reply was made to PR kern/89837; it has been noted by GNATS. From: Jeremy Chadwick free...@jdc.parodius.com To: John Baldwin j...@freebsd.org Cc: bug-follo...@freebsd.org Subject: Re: kern/89837: [pci] PCI code outputs superfluous failed to enable/disable memory/port mapping! messages Date: Wed, 27 Apr 2011 14:42:58 -0700 On Wed, Apr 27, 2011 at 05:32:47PM -0400, John Baldwin wrote: I suspect this no longer occurs after the PCI bus was changed to handle BARs on legacy ATA devices. Thanks for the follow-up, John. That sounds extremely likely. Given that, closing this PR should be fine. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/156484: ntpd regularly flips between PLL and FLL mode (time sync status change 6001/2001)
Number: 156484 Category: bin Synopsis: ntpd regularly flips between PLL and FLL mode (time sync status change 6001/2001) Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Apr 18 22:40:07 UTC 2011 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.2-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Mar 24 04:21:44 PDT 2011 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: ntpd on FreeBSD machines, including that on RELENG_8 source dated in March 2011 (ntpd 4.2.4p5), regularly flips between PLL and FLL mode. This can be seen in one's log files as such: Apr 15 14:36:14 ra ntpd[946]: kernel time sync status change 6001 Apr 15 15:01:53 ra ntpd[946]: kernel time sync status change 2001 I'm seeing this on literally all production servers which sync off of public time sources. Servers which sync off of local time sources (stratum 3) do not see the problem, but I doubt that's of any relevancy. These logging messages were disabled in the most recent version of ntpd-dev according to the official NTP developers (see comment #10): http://bugs.ntp.org/show_bug.cgi?id=452 Using maxpoll 9 as a workaround, which was proposed in 2006, also does not solve the problem, but does decrease the regularity of it: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html How-To-Repeat: n/a Fix: Given that this annoyance has existed for many years now, can we please work on getting the most recent ntpd into FreeBSD? The latest stable build is 4.2.6p3, but I don't know if this removes the printing of the messages or not (see bugs.ntp.org URL, comment #5). Someone would need to review the source code. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/153753: ZFS v15 - grammatical error when attempting to use existing cache device
Number: 153753 Category: kern Synopsis: ZFS v15 - grammatical error when attempting to use existing cache device Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Jan 07 08:20:07 UTC 2011 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.2-PRERELEASE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Nov 27 12:54:04 PST 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: When attempting to use an already-in-use cache device in another pool, the error message makes little sense (specifically the use of the word unknown below): invalid vdev specification use '-f' to override the following errors: /some/disk is part of unknown pool 'data' How-To-Repeat: # zpool create data ada1 cache da0 # zpool create backups ada2 # zpool status pool: backups state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM backups ONLINE 0 0 0 ada2 ONLINE 0 0 0 errors: No known data errors pool: data state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 ada1 ONLINE 0 0 0 cache da0 ONLINE 0 0 0 errors: No known data errors # zpool add backups cache da0 invalid vdev specification use '-f' to override the following errors: /dev/da0 is part of unknown pool 'data' Fix: The word unknown should probably be active, or better yet, removed altogether. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
conf/151063: [rc.subr] Verify network link and packet flow before starting network services
Number: 151063 Category: conf Synopsis: [rc.subr] Verify network link and packet flow before starting network services Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Wed Sep 29 10:00:11 UTC 2010 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.1-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Sep 15 14:59:46 PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: There's a long-standing issue that plagues both users and system administrators on FreeBSD: network services (named, ntpd, etc.) starting before the actual network layer is up and fully functional. Monitoring link state according to ifconfig is not enough -- actual packet flow verification is needed. I've written a script along with the help of the community and Doug Barton to help alleviate this problem as best possible. There are better solutions over the long-term, involving daemons which maintain/spawn services (think svcs(1) and svcadm(1M) on Solaris), but for now this should be sufficient. Original discussion thread: http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html The script is in use by existing community users, and tested by a good number of people with complex network environments (dual NICs + vlan(4) + NAT) on both RELENG_7 and RELENG_8. So far it has been used by placing the script into /usr/local/etc/rc.d followed by setting appropriate vars in /etc/rc.conf: http://jdc.parodius.com/freebsd/netwait Patches for rc.conf(5) man page and /etc/defaults/rc.conf: http://jdc.parodius.com/freebsd/netwait_patches/ All of this should be reviewed by someone with familiarity with rc(8). Please CC Doug Barton do...@freebsd.org as well. Thanks! How-To-Repeat: n/a Fix: n/a Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/150723: bsnmpd(1): add knowledge of ada disks (ATA via SCSI CAM)
On Thu, Sep 23, 2010 at 07:11:35PM +0300, Shteryana Shopova wrote: I am seeing a similar problem with removable USB disks - libdevinfo(3) reports that the name of the device is umass0 and as a result the disk name da0 does not match the device entry. Thus I also see the same snmpd[3632]: disk_OS_get_disks: device 'da0' not in device list messages in the system log. In addition two entries are present for the disk in the hrDeviceTable - hrDeviceDescr[57] = umass0: Kingston DataTraveler 2.0, clas hrDeviceDescr[154] = da0: As I don't have an ada disk to test with, could you please show me the output of #devinfo -v #camcontrol devlist -v and also the complete output when walking the hrDeviceTable on your system. No problem. Due to the amount of output, I felt it'd be prudent to put them up on the web for easier review. Here you go: http://jdc.parodius.com/freebsd/150723/camcontrol.txt http://jdc.parodius.com/freebsd/150723/devinfo.txt http://jdc.parodius.com/freebsd/150723/snmpwalk.txt It's interesting that the adaX disks don't show up in devinfo. On a different system where ahci.ko and SCSI CAM *is not* in use, devinfo shows the disks (ad4 and ad6) under their appropriate ataX devices. Sadly I don't have any native SCSI (non-AHCI) systems, so I can't see if disks there appear correctly -- but from your experience, it sounds like they don't. Furthermore, it appears the FreeNAS folks also see this problem (scroll down near the bottom): http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=57t=1001 I'm adding mav@ to the CC list since he might have some ideas regarding the issue. It sounds like CAM(4) might not be doing something it should (maybe with devclass(9)? I'm just guessing). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/150723: bsnmpd(1): add knowledge of ada disks (ATA via SCSI CAM)
Number: 150723 Category: bin Synopsis: bsnmpd(1): add knowledge of ada disks (ATA via SCSI CAM) Confidential: no Severity: non-critical Priority: high Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Sep 19 15:20:00 UTC 2010 Closed-Date: Last-Modified: Originator: Jeremy Chadwick Release:FreeBSD 8.1-STABLE amd64 Organization: Environment: System: FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Sep 15 14:59:46 PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Description: bsnmpd(1) does not properly handle disks attached to the ada(4) subsystem. The daemon outputs the following syslog errors when starting: snmpd[2964]: disk_OS_get_disks: device 'ada3' not in device list snmpd[2964]: disk_OS_get_disks: device 'ada2' not in device list snmpd[2964]: disk_OS_get_disks: device 'ada1' not in device list snmpd[2964]: disk_OS_get_disks: device 'ada0' not in device list This is for a system with the following in sysctl kern.disks: kern.disks: ada3 ada2 ada1 ada0 These disks are: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD3000HLFS-01G6U0 04.04V01 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 286168MB (586072368 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: WDC WD1001FALS-00U9B0 05.00K05 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: WDC WD1001FALS-00U9B0 05.00K05 ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: WDC WD1001FALS-00U9B0 05.00K05 ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) Walking the appropriate OID branches is interesting: - hrDeviceType is correct - hrDeviceDescr doesn't show the hard disk model/firmware version - hrDeviceStatus is incorrect - hrDiskStorageMedia is incorrect - hrDiskStorageCapacity is correct - (Unrelated) hrDiskStorageRemoveble appears to have a typo in its MIB name (should be hrDiskStorageRemovable -- a, not e!) hrDeviceTable = HOST-RESOURCES-MIB::hrDeviceIndex.158 = INTEGER: 158 HOST-RESOURCES-MIB::hrDeviceIndex.159 = INTEGER: 159 HOST-RESOURCES-MIB::hrDeviceIndex.160 = INTEGER: 160 HOST-RESOURCES-MIB::hrDeviceIndex.161 = INTEGER: 161 HOST-RESOURCES-MIB::hrDeviceType.158 = OID: HOST-RESOURCES-TYPES::hrDeviceDiskStorage HOST-RESOURCES-MIB::hrDeviceType.159 = OID: HOST-RESOURCES-TYPES::hrDeviceDiskStorage HOST-RESOURCES-MIB::hrDeviceType.160 = OID: HOST-RESOURCES-TYPES::hrDeviceDiskStorage HOST-RESOURCES-MIB::hrDeviceType.161 = OID: HOST-RESOURCES-TYPES::hrDeviceDiskStorage HOST-RESOURCES-MIB::hrDeviceDescr.158 = STRING: ada3: HOST-RESOURCES-MIB::hrDeviceDescr.159 = STRING: ada2: HOST-RESOURCES-MIB::hrDeviceDescr.160 = STRING: ada1: HOST-RESOURCES-MIB::hrDeviceDescr.161 = STRING: ada0: HOST-RESOURCES-MIB::hrDeviceID.158 = OID: SNMPv2-SMI::zeroDotZero HOST-RESOURCES-MIB::hrDeviceID.159 = OID: SNMPv2-SMI::zeroDotZero HOST-RESOURCES-MIB::hrDeviceID.160 = OID: SNMPv2-SMI::zeroDotZero HOST-RESOURCES-MIB::hrDeviceID.161 = OID: SNMPv2-SMI::zeroDotZero HOST-RESOURCES-MIB::hrDeviceStatus.158 = INTEGER: unknown(1) HOST-RESOURCES-MIB::hrDeviceStatus.159 = INTEGER: unknown(1) HOST-RESOURCES-MIB::hrDeviceStatus.160 = INTEGER: unknown(1) HOST-RESOURCES-MIB::hrDeviceStatus.161 = INTEGER: unknown(1) HOST-RESOURCES-MIB::hrDeviceErrors.158 = Counter32: 0 HOST-RESOURCES-MIB::hrDeviceErrors.159 = Counter32: 0 HOST-RESOURCES-MIB::hrDeviceErrors.160 = Counter32: 0 HOST-RESOURCES-MIB::hrDeviceErrors.161 = Counter32: 0 hrDiskStorageTable = HOST-RESOURCES-MIB::hrDiskStorageAccess.158 = INTEGER: readWrite(1) HOST-RESOURCES-MIB::hrDiskStorageAccess.159 = INTEGER: readWrite(1) HOST-RESOURCES-MIB::hrDiskStorageAccess.160 = INTEGER: readWrite(1) HOST-RESOURCES-MIB::hrDiskStorageAccess.161 = INTEGER: readWrite(1) HOST-RESOURCES-MIB::hrDiskStorageMedia.158 = INTEGER: unknown(2) HOST-RESOURCES-MIB::hrDiskStorageMedia.159 = INTEGER: unknown(2) HOST-RESOURCES-MIB::hrDiskStorageMedia.160 = INTEGER: unknown(2) HOST-RESOURCES-MIB::hrDiskStorageMedia.161 = INTEGER: unknown(2) HOST-RESOURCES-MIB::hrDiskStorageRemoveble.158 = INTEGER: false(2) HOST-RESOURCES-MIB::hrDiskStorageRemoveble.159 = INTEGER: false(2) HOST-RESOURCES-MIB::hrDiskStorageRemoveble.160 = INTEGER: false(2) HOST-RESOURCES
