Two Intel E31220L 9.0-Stable systems, 'kern.random' missing on one?
Hi, I have two SuperMicro E31220L based systems - both had identical /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of 2012/12/03). Now I've noticed of them complains at boot time that a bunch of OID's are missing - and sure enough: " sysctl kern.random sysctl: unknown oid 'kern.random' " But the other system returns these fine. One system ID's as 'Intel E31220L @ 2.20Ghz' - the other ID's as 'Intel E31220L V2 @ 2.30Ghz' the V2 system is apparently 'missing' the kern.random stuff. The only reason I can think for the OID's not being present is if one system is using hardware RNG? - Though 'man 4 random' states: "The only hardware implementation currently is for the VIA C3 Nehemiah (stepping 3 or greater) CPU. More will be added in the future." Is there any other reason why they would have 'disappeared' on the non V2 system? (in fact, looking at the Feature2 line I can see 'RDRAND' on the V2 system, hmm so I'm guessing that's it?!) Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
$* and $@ exhibit same behaviour -> those of $*
I've noticed this under 9.0-RELEASE-p5
#!/bin/sh
#
ftest_dot ()
{
local i
for i in $*
{
echo "$i"
}
}
ftest_monkey ()
{
local i
for i in $@
{
echo "$i"
}
}
echo
ftest_dot one 'spaced path' two ''
echo
ftest_monkey one 'spaced path' two ''
echo
exit 55
Output:
---
one
spaced
path
two
one
spaced
path
two
Expected output is:
---
one
spaced
path
two
one
spaced path
two
I hope fix'll get into 9.1
Domagoj Smolčić
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: $* and $@ exhibit same behaviour -> those of $*
> Looks fine to me. Try quoting $@ in ftest_monkey. > -Garrett Yes, it did a trick. That tiny detail. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: $* and $@ exhibit same behaviour -> those of $*
On 12/3/2012 11:09 AM, rank1see...@gmail.com wrote:
> I've noticed this under 9.0-RELEASE-p5
>
>
> #!/bin/sh
> #
> ftest_dot ()
> {
> local i
>
> for i in $*
> {
> echo "$i"
> }
> }
>
> ftest_monkey ()
> {
> local i
>
> for i in $@
> {
> echo "$i"
> }
> }
>
From my understanding, used in that context, they should be the same.
$* Expands to the positional parameters, starting from one. When
the expansion occurs within a double-quoted string it
expands to
a single field with the value of each parameter separated
by the
first character of the IFS variable, or by a space if IFS is
unset.
$@ Expands to the positional parameters, starting from one. When
the expansion occurs within double-quotes, each positional
param‐
eter expands as a separate argument. If there are no
positional
parameters, the expansion of @ generates zero arguments, even
when @ is double-quoted. What this basically means, for
example,
is if $1 is “abc” and $2 is “def ghi”, then "$@" expands
to the
two arguments:
"abc" "def ghi"
Note the first sentence in both. The difference only occurs when used
inside quotes, i.e. "$@" and "$*"
Bryan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Missing quote in comment in 8.3 & 9.0 & 9.1RC2 etc/sendmail/freebsd.mc
Hi hack...@freebsd.org
There is a missing double quote " in
8.3 & 9.0 & 9.1RC2 src/etc/sendmail/freebsd.mc
8.2-RELEASE & earlier are OK.
Here's a diff -c to .mc
The diff is not to fix it, but to help generate a freebsd.cf to
understand the difference. The patch for a fix would befar more trivial :-)
--
*** 9.1-RC3/src/etc/sendmail/freebsd.mc Mon Oct 29 21:16:44 2012
--- 9.1-RC3/src+debug/etc/sendmail/freebsdjhs.mcMon Dec 3 18:44:33 2012
***
*** 66,75
dnl For that, visit
dnl http://www.google.com/Top/Computers/Internet/E-mail/Spam/Blacklists/
! dnl Uncomment to activate your chosen DNS based blacklist
! dnl FEATURE(dnsbl, `dnsbl.example.com')
! dnl Alternatively, you can provide your own server and rejection message:
! dnl FEATURE(dnsbl, `dnsbl.example.com', ``"550 Mail from " $&{client_addr} "
rejected'')
dnl Dialup users should uncomment and define this appropriately
dnl define(`SMART_HOST', `your.isp.mail.server')
--- 66,77
dnl For that, visit
dnl http://www.google.com/Top/Computers/Internet/E-mail/Spam/Blacklists/
! # Uncomment to activate your chosen DNS based blacklist
! FEATURE(dnsbl, `jhs0.dnsbl.example.com')
! # Alternatively, you can provide your own server and rejection message:
! FEATURE(dnsbl, `jhs3.dnsbl.example.com', ``"550 Mail from " $&{client_addr} "
rejected'')
! # original line above has 3 x " , line below has 4
! FEATURE(dnsbl, `jhs4.dnsbl.example.com', ``"550 Mail from " $&{client_addr} "
rejected"'')
dnl Dialup users should uncomment and define this appropriately
dnl define(`SMART_HOST', `your.isp.mail.server')
--
The .cf output is
--
# DNS based IP address spam list jhs0.dnsbl.example.com
R$* $: $&{client_addr}
R$-.$-.$-.$-$: $(dnsbl $4.$3.$2.$1.jhs0.dnsbl.example.com. $:
OK $)
ROK $: OKSOFAR
R$+ $: TMPOK
R$+ $#error $@ 5.7.1 $: "550 Rejected: " $&{client_addr} " listed
at jhs0.dnsbl.example.com"
# DNS based IP address spam list jhs3.dnsbl.example.com
R$* $: $&{client_addr}
R$-.$-.$-.$-$: $(dnsbl $4.$3.$2.$1.jhs3.dnsbl.example.com. $:
OK $)
ROK $: OKSOFAR
R$+ $: TMPOK
R$+ $#error $@ 5.7.1 $: "550 Mail from " $&{client_addr} " rejected
# DNS based IP address spam list jhs4.dnsbl.example.com
R$* $: $&{client_addr}
R$-.$-.$-.$-$: $(dnsbl $4.$3.$2.$1.jhs4.dnsbl.example.com. $:
OK $)
ROK $: OKSOFAR
R$+ $: TMPOK
R$+ $#error $@ 5.7.1 $: "550 Mail from " $&{client_addr} " rejected"
--
Above, jhs3 seems bad & jhs4 seems good.
A copy of this diff + follow up is in
http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/etc/sendmail/freebsd.mc.REL=ALL.diff
The error appeared in 8.3 & 9.0 & 9.1RC3, it was OK earlier :
4.11-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl,
`blackholes.mail-abuse.org', `"550 Mail from " $&{client_addr} " rejected, see
http://mail-abuse.org/cgi-bin/lookup?"; $&{client_addr}')
6.4-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl,
`blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see
http://mail-abuse.org/cgi-bin/lookup?"; $&{client_addr}'')
7.3-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl,
`blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see
http://mail-abuse.org/cgi-bin/lookup?"; $&{client_addr}'')
7.4-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl,
`blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see
http://mail-abuse.org/cgi-bin/lookup?"; $&{client_addr}'')
8.2-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl,
`blackholes.mail-abuse.org', ``"550 Mail from " $&{client_addr} " rejected, see
http://mail-abuse.org/cgi-bin/lookup?"; $&{client_addr}'')
8.3-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `dnsbl.example.com',
``"550 Mail from " $&{client_addr} " rejected'')
9.0-RELEASE/src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `dnsbl.example.com',
``"550 Mail from " $&{client_addr} " rejected'')
9.1-RC3//src/etc/sendmail/freebsd.mc:dnl FEATURE(dnsbl, `dnsbl.example.com',
``"550 Mail from " $&{client_addr} " rejected'')
Why others didnt notice earlier:
It's just a comment, I assume not checked by anything automatic at
freebsd.org.
How I caught it:
I have my own src/etc/sendmail/ Makefile diffs & fdef'd common.cpp
that generates various .mc files for each of my hosts, & many
versions, which filters the .cpp to create .mcfiles, inc. a check
file that should be an exact match with that version's freebsd.mc
... & cpp complained: unmatched ".
I will send-pr unless I hear otherwise.
But as 9.1-RELEASE is imminent, & it would be a trivial anodyne
fix to a comment for re@ , so they want to fix, so cc'd to re@.
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
Rep
Re: Two Intel E31220L 9.0-Stable systems, 'kern.random' missing on one?
On Mon, Dec 03, 2012 at 03:11:21PM +, Karl Pielorz wrote: > > Hi, > > I have two SuperMicro E31220L based systems - both had identical > /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of > 2012/12/03). > > Now I've noticed of them complains at boot time that a bunch of OID's are > missing - and sure enough: > > " > sysctl kern.random > sysctl: unknown oid 'kern.random' > " > > But the other system returns these fine. > > One system ID's as 'Intel E31220L @ 2.20Ghz' - the other ID's as 'Intel > E31220L V2 @ 2.30Ghz' the V2 system is apparently 'missing' the kern.random > stuff. > > The only reason I can think for the OID's not being present is if one > system is using hardware RNG? - Though 'man 4 random' states: > > "The only hardware implementation currently is for the > VIA C3 Nehemiah (stepping 3 or greater) CPU. More will be added in the > future." > > Is there any other reason why they would have 'disappeared' on the non V2 > system? (in fact, looking at the Feature2 line I can see 'RDRAND' on the V2 > system, hmm so I'm guessing that's it?!) You noted that RDRAND is supported by your hardware. And indeed, FreeBSD got the RDRAND (aka Bull Mountain) hardware random number generator support recently. From my reading of the sys/dev/random code, the kern.random OID is only instantiated if the software implementation is selected. If you prefer software, you can disable RDRAND with hw.ivy_rng_enable=0 tunable. pgpiF9CoXmpgC.pgp Description: PGP signature
[PATCH] Bugs in DTrace debug locking code
DTrace has an unused logging facility built-in. The logging is intended to
be safe to be called from the handler of a DTrace probe (what DTrace calls
"probe context"). Because a DTrace probe could be enabled almost anywhere
in the kernel, this means that it can't use standard FreeBSD
synchronization primitives, and so it has rolled its own spin lock. As so
often happens when rolling your own synchronization, there are several bugs
here:
1) It doesn't use spinlock_enter/spinlock_exit, which means that a thread
holding a spin lock can be switched out. A subsequent thread could be
starved trying to acquire the lock (worse, there's the chance of a nasty
case of priority inversion here, where a low-priority thread holds the lock
but cannot run because a high-priority thread is spinning on that same
lock). This is the bug that caused me to start looking into this code: I
saw a situation where a user thread had taken the lock and subsequently
been switched out, and a softclock thread starved waiting for the spin lock.
2) The code uses per-CPU buffers and thus has a lock for every CPU. It
ends up doing the following in many cases:
dtrace_debug_lock(curcpu);
//...
dtrace_debug_unlock(curcpu);
There is nothing that guarantees that the thread can not have migrated to a
new CPU in the meantime.
3) The locks do not use acquire and release memory barriers.
4) The locks are all right next to each other in memory, so false sharing
will defeat much of the purpose of having per-CPU buffers in the first
place.
5) The locks do not record their owner, make it difficult to debug problems
with them.
(There is a sixth problem, namely that this code is compiled into the
kernel when nothing in the tree uses this log facility, but there is still
some code paths which check for log messages. That's why I saw my crash in
#1 in the first place. I plan on taking it out in a separate commit.)
The following patch addresses these issues. I've tried stress-testing
DTrace but I've been unable to reproduce my original crash on head. Any
comments or objections?
Index: sys/cddl/dev/dtrace/dtrace_debug.c
===
--- sys/cddl/dev/dtrace/dtrace_debug.c (revision 243795)
+++ sys/cddl/dev/dtrace/dtrace_debug.c (working copy)
@@ -39,6 +39,7 @@
struct dtrace_debug_data {
char bufr[DTRACE_DEBUG_BUFR_SIZE];
+ uintptr_t lock;
char *first;
char *last;
char *next;
@@ -46,12 +47,14 @@
static char dtrace_debug_bufr[DTRACE_DEBUG_BUFR_SIZE];
-static volatile u_long dtrace_debug_flag[MAXCPU];
-
static void
dtrace_debug_lock(int cpu)
{
- while (dtrace_cmpset_long(&dtrace_debug_flag[cpu], 0, 1) == 0)
+ uintptr_t tid;
+
+ tid = (uintptr_t)curthread;
+ spinlock_enter();
+ while (atomic_cmpset_acq_long(&dtrace_debug_data[cpu].lock, 0, tid)
== 0)
/* Loop until the lock is obtained. */
;
}
@@ -59,7 +62,8 @@
static void
dtrace_debug_unlock(int cpu)
{
- dtrace_debug_flag[cpu] = 0;
+ atomic_store_rel_long(&dtrace_debug_data[cpu].lock, 0);
+ spinlock_exit();
}
static void
@@ -151,10 +155,11 @@
*/
static __inline void
-dtrace_debug__putc(char c)
+dtrace_debug__putc(int cpu, char c)
{
- struct dtrace_debug_data *d = &dtrace_debug_data[curcpu];
+ struct dtrace_debug_data *d;
+ d = &dtrace_debug_data[cpu];
*d->next++ = c;
if (d->next == d->last)
@@ -172,24 +177,30 @@
static void __used
dtrace_debug_putc(char c)
{
- dtrace_debug_lock(curcpu);
+ int cpu;
- dtrace_debug__putc(c);
+ cpu = curcpu;
+ dtrace_debug_lock(cpu);
- dtrace_debug_unlock(curcpu);
+ dtrace_debug__putc(cpu, c);
+
+ dtrace_debug_unlock(cpu);
}
static void __used
dtrace_debug_puts(const char *s)
{
- dtrace_debug_lock(curcpu);
+ int cpu;
+ cpu = curcpu;
+ dtrace_debug_lock(cpu);
+
while (*s != '\0')
- dtrace_debug__putc(*s++);
+ dtrace_debug__putc(cpu, *s++);
- dtrace_debug__putc('\0');
+ dtrace_debug__putc(cpu, '\0');
- dtrace_debug_unlock(curcpu);
+ dtrace_debug_unlock(cpu);
}
/*
@@ -219,7 +230,7 @@
#define MAXNBUF (sizeof(intmax_t) * NBBY + 1)
static void
-dtrace_debug_vprintf(const char *fmt, va_list ap)
+dtrace_debug_vprintf(int cpu, const char *fmt, va_list ap)
{
char nbuf[MAXNBUF];
const char *p, *percent, *q;
@@ -243,10 +254,10 @@
width = 0;
while ((ch = (u_char)*fmt++) != '%' || stop) {
if (ch == '\0') {
- dtrace_debug__putc('\0');
+ dtrace_debug__putc(cpu, '\0');
return;
}
- dtrace_debug__putc(ch);
+ dtrace_debug__putc(cpu, ch);
}
percent = fm
