Re: IPv6 accept_rtadv + bfe0
Doug Barton wrote in <4ea23c08.6060...@freebsd.org>: do> On 10/19/2011 00:29, Hiroki Sato wrote: do> > Mattia Rossi wrote do> > in <4e9dfe11.2070...@swin.edu.au>: do> > do> > mr> So the _ipv6 bit doesn't take care of passing "inet6" to ifconfig do> > mr> automatically? do> > do> > No. You always need to add the inet6 keyword wherever needed. do> do> That seems redundant, and contrary to how the IPv4 equivalents work. And do> obviously it's confusing to users. From what I can see looking at some do> 7.x and 8.x systems it also seems to be a POLA violation. do> do> Perhaps this is something that you should reconsider? I am still thinking that omitting an address family keyword before an address is a bad practice. Omitting "inet" keyword in ifconfig_IF and doing in ifconfing_IF_AF are different. The former one uses ifconfig(8)'s default AF, and bz's experiments of noinet/noinet6 environment showed it was problematic. For the latter a keyword has to be automatically prepended in the rc.d scripts if we want to do so. For IPv6, having a non-null $ifconfig_IF_ipv6 means the interface is IPv6-capable and doesn't always involve address configuration (e.g. ifconfig_IF_ipv6="up" is valid). So, automatic prepending of "inet6" breaks this. Thus, both have a bad side effect. And I want to make ifconfig accept a command line for v4->v6 and/or v6->v4 tunneling as a p2p link like "inet 10.1.1.1 2001:db8::1" for a specific type of interfaces in the future. I am not sure if it will happen actually, but omitting an AF keyword and/or automatic prepending of the keyword make things difficult. -- Hiroki pgpCsla8j2XGv.pgp Description: PGP signature
9.0-RC1 panic in tcp_input: negative winow.
The panic message says: panic: tcp_input negative window: tp 0xfe007763e000 rcv_nxt 3718269252 rcv_adv 3718268291 I only have picture of the backtrace: http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpo3XZOvEVzL.pgp Description: PGP signature
Increase the degree of interactivity ULE scheduler
Hello people!
I have:
CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz K8-class CPU)
FreeBSD 10.0-CURRENT r226607 amd64
For example during the building of the port lang/gcc46 in four streams (-j 4)
with a heavy load on the processor - use the system was nearly impossible -
responsiveness was terrible - the mouse cursor sometimes froze on the spot a
few seconds...
I managed to achieve a significant increase in the degree of interactivity ULE
scheduler due to the following changes:
##
--- sched_ule.c.orig2011-10-22 11:40:30.0 +0300
+++ sched_ule.c 2011-10-22 12:25:05.0 +0300
@@ -2119,6 +2119,14 @@
THREAD_LOCK_ASSERT(td, MA_OWNED);
tdq = TDQ_SELF();
+ if (td->td_pri_class & PRI_FIFO_BIT)
+ return;
+ ts = td->td_sched;
+ /*
+* We used up one time slice.
+*/
+ if (--ts->ts_slice > 0)
+ return;
#ifdef SMP
/*
* We run the long term load balancer infrequently on the first cpu.
@@ -2144,9 +2152,6 @@
if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
tdq->tdq_ridx = tdq->tdq_idx;
}
- ts = td->td_sched;
- if (td->td_pri_class & PRI_FIFO_BIT)
- return;
if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) {
/*
* We used a tick; charge it to the thread so
@@ -2157,11 +2162,6 @@
sched_priority(td);
}
/*
-* We used up one time slice.
-*/
- if (--ts->ts_slice > 0)
- return;
- /*
* We're out of time, force a requeue at userret().
*/
ts->ts_slice = sched_slice;
##
What do you think about this?
Thanks!___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
replacement of ataidle for freebsd 9
Hello, can somebody please advice how to disable APM power management for HDD on laptops? > camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 00 00" -v camcontrol: error sending command (pass0:ahcich0:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 00 00 00 00 00 00 00 (pass0:ahcich0:0:0:0): CAM status: ATA Status Error (pass0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass0:ahcich0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 00 00 What else should I try? > uname -a FreeBSD devbox 9.0-RC1 FreeBSD 9.0-RC1 #0: Thu Oct 20 08:48:57 EEST 2011 root@devbox:/usr/obj/usr/src/sys/GENERIC amd64 Thanks! -- Eugene N Dzhurinsky pgpXWhgKl3KiZ.pgp Description: PGP signature
Re: replacement of ataidle for freebsd 9
Why do you not want to use ataidle? -- Bruce Cran (ataidle maintainer) On 22 Oct 2011, at 11:36, Eugene Dzhurinsky wrote: > Hello, can somebody please advice how to disable APM power management for HDD > on laptops? > >> camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 00 00" -v > camcontrol: error sending command > (pass0:ahcich0:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 00 00 00 00 00 00 00 > (pass0:ahcich0:0:0:0): CAM status: ATA Status Error > (pass0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) > (pass0:ahcich0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 00 00 > > What else should I try? > >> uname -a > FreeBSD devbox 9.0-RC1 FreeBSD 9.0-RC1 #0: Thu Oct 20 08:48:57 EEST 2011 > root@devbox:/usr/obj/usr/src/sys/GENERIC amd64 > > Thanks! > > -- > Eugene N Dzhurinsky ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Sat, 22 Oct 2011, Pawel Jakub Dawidek wrote: The panic message says: panic: tcp_input negative window: tp 0xfe007763e000 rcv_nxt 3718269252 rcv_adv 3718268291 I only have picture of the backtrace: http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg I've seen that issue once before in the r222XYZ days -- it's a problem that's been around since the TCP / IP code has been refactored in FreeBSD. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: replacement of ataidle for freebsd 9
On Sat, Oct 22, 2011 at 02:23:53PM +0100, Bruce Cran wrote: > Why do you not want to use ataidle? > ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 > ataidle -P 0 /dev/ad4 ataidle: error: identify device /dev/ad4 > ls -l /dev | grep ad lrwxr-xr-x 1 root wheel4 Oct 22 18:16 ad4@ -> ada0 lrwxr-xr-x 1 root wheel6 Oct 22 18:16 ad4s1@ -> ada0s1 lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1a@ -> ada0s1a lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1b@ -> ada0s1b lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1d@ -> ada0s1d lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1e@ -> ada0s1e lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1f@ -> ada0s1f lrwxr-xr-x 1 root wheel6 Oct 22 18:16 ad4s2@ -> ada0s2 crw-r- 1 root operator0, 81 Oct 22 18:16 ada0 crw-r- 1 root operator0, 84 Oct 22 18:16 ada0s1 crw-r- 1 root operator0, 88 Oct 22 21:16 ada0s1a crw-r- 1 root operator0, 90 Oct 22 18:16 ada0s1b crw-r- 1 root operator0, 92 Oct 22 21:16 ada0s1d crw-r- 1 root operator0, 94 Oct 22 21:16 ada0s1e crw-r- 1 root operator0, 96 Oct 22 21:16 ada0s1f crw-r- 1 root operator0, 86 Oct 22 21:16 ada0s2 > smartctl -a /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: ST9500423AS Serial Number:W2V003TQ LU WWN Device Id: 5 000c50 03d75b968 Firmware Version: 0002SDM1 User Capacity:500,107,862,016 bytes [500 GB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is:Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is:Sat Oct 22 18:20:22 2011 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled -- Eugene N Dzhurinsky pgpFw5hq6gcCH.pgp Description: PGP signature
Re: sys/conf/newvers.sh vs. subversion-1.7
On Fri, 21 Oct 2011, Craig Rodrigues wrote:
Hi,
I tried following:
(1) Run svnversion in non-svn directory:
return status == 0
prints out "exported"
time:
real0m0.043s
user0m0.000s
sys 0m0.045s
(2) Run svnversion in svn directory:
return status == 0
prints out "223847M"
time:
real0m2.563s
user0m0.980s
sys 0m1.187s
(3) Run "svn info --non-interactive ." in non-svn directory:
return status == 1
prints out "svn: '.' is not a working copy"
time:
real0m0.056s
user0m0.007s
sys 0m0.046s
(4) Run "svn info --non-interactive ." in svn directory:
return status == 0
prints out "a bunch of info about from svn"
time:
real0m0.023s
user0m0.000s
sys 0m0.024s
I thought that since svnversion seems to always have a return status of 0, and
is almost 2 seconds slower than "svn info" when run inside a svn directory,
that using "svn info" is a preferable way inside a script of determining
if a directory is part of a svn repo or not.
$(svn info | awk '/^Revision:/ {print $2}')
is what I use in my installkernel wrapper script. Granted, I didn't know
about svnversion some time later, but it appears that svnversion broke
some things by consolidating the .svn directories as Chris shows above
with the 'exported' line.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
2011/10/22 Garrett Cooper :
>
> $(svn info | awk '/^Revision:/ {print $2}')
>
> is what I use in my installkernel wrapper script. Granted, I didn't know
> about svnversion some time later, but it appears that svnversion broke some
> things by consolidating the .svn directories as Chris shows above with the
> 'exported' line.
Won't work for localized builds :
$ echo $LANG
fr_FR.ISO8859-15
$ pwd
/usr/src
$ $(svn info | awk '/^Revision:/ {print $2}')
$ svn info
Chemin : .
Chemin racine de la copie de travail : /usr/src
URL : http://svn.freebsd.org/base/stable/9
Racine du dépôt : http://svn.freebsd.org/base
UUID du dépôt : ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Révision : 226629
[...]
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org - against HTML email & vCards X
www: http://www.gid0.org - against proprietary attachments / \
"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
Olivier Smedts writes:
>>
>> $(svn info | awk '/^Revision:/ {print $2}')
>>
>> is what I use in my installkernel wrapper script. Granted, I didn't know
>> about svnversion some time later, but it appears that svnversion broke some
>> things by consolidating the .svn directories as Chris shows above with the
>> 'exported' line.
>
> Won't work for localized builds :
> $ echo $LANG
> fr_FR.ISO8859-15
> $ pwd
> /usr/src
> $ $(svn info | awk '/^Revision:/ {print $2}')
> $ svn info
While you can try to set LC_MESSAGES to `C' locale
subversion also supports XML output
$ echo $(svn info --xml | awk -F\" '/revision/ && ++i > 1 { print $2 }')
226629
Unlike `svnversion' it doesn't show whether the checked out
sources are `M' (modified) or not. Not that I found it useful
compared to `svn st -q' though.
> Chemin : .
> Chemin racine de la copie de travail : /usr/src
> URL : http://svn.freebsd.org/base/stable/9
> Racine du dépôt : http://svn.freebsd.org/base
> UUID du dépôt : ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Révision : 226629
> [...]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 22/10/2011 18:29, Garrett Cooper wrote:
> On Fri, 21 Oct 2011, Craig Rodrigues wrote:
>
>> Hi,
>>
>> I tried following:
>>
>> (1) Run svnversion in non-svn directory:
>>
>> return status == 0
>> prints out "exported"
>>
>> time:
>> real0m0.043s
>> user0m0.000s
>> sys 0m0.045s
>>
>> (2) Run svnversion in svn directory:
>>
>> return status == 0
>> prints out "223847M"
>>
>> time:
>> real0m2.563s
>> user0m0.980s
>> sys 0m1.187s
>>
>>
>> (3) Run "svn info --non-interactive ." in non-svn directory:
>>
>> return status == 1
>> prints out "svn: '.' is not a working copy"
>>
>> time:
>>
>> real0m0.056s
>> user0m0.007s
>> sys 0m0.046s
>>
>>
>> (4) Run "svn info --non-interactive ." in svn directory:
>>
>>return status == 0
>>prints out "a bunch of info about from svn"
>>
>> time:
>>
>> real0m0.023s
>> user0m0.000s
>> sys 0m0.024s
>>
>>
>>
>> I thought that since svnversion seems to always have a return status
>> of 0, and
>> is almost 2 seconds slower than "svn info" when run inside a svn
>> directory,
>> that using "svn info" is a preferable way inside a script of determining
>> if a directory is part of a svn repo or not.
>
> $(svn info | awk '/^Revision:/ {print $2}')
>
> is what I use in my installkernel wrapper script. Granted, I didn't know
> about svnversion some time later, but it appears that svnversion broke
> some things by consolidating the .svn directories as Chris shows above
> with the 'exported' line.
svnversion actually does more than "svn info", which is why it's slower:
1. It descends into the subdirectories recursively.
2. It "recognizes" different checked out revisions in those
subdirectories, plus local modifications and other stuff.
So, while "svn info ." will only produce the version of the directory
it's run from, and that regardless of any possible local modifications,
svnversion will produce version number that is...
... a single number if the working copy is single revision, unmodified,
not switched and with an URL that matches the TRAIL_URL argument. If the
working copy is unusual the version number will be more complex:
4123:4168 mixed revision working copy
4168M modified working copy
4123S switched working copy
4123:4168MS mixed revision, modified, switched working copy
I guess that for most folks that's generally irrelevant, but even I, not
in any way being a developer, find it helpful to be reminded when I'm
working on a system that I've fiddled with, even in a minor way.
Concerning the breakage, the problem is actually not in svnversion per
se, but rather in the algorithm in newvers.sh, which checks whether
${SRCDIR}/sys is under Subversion control. It would be all the same if
"svn info ." was used instead, to the best of my understanding.
Speaking of that, and in the context of the recursion that svnversion
does, something else comes to my mind...
svnversion is currently executed in ${SRCDIR}/sys, so the revision
number is relevant only to the kernel sources. But FreeBSD is not just a
kernel, unlike Linux, so wouldn't it make more sense to actually check
the revision directly at ${SRCDIR}, thus catching possible different
revisions in other parts of the base system source tree?
I mean, when somebody says "I'm running FreeBSD 9.0-RC1 r226607", their
kernel tree might be at r226607 all right, but they also can easily have
some very different revisions checked out for lib, include, etc. Not
that I really expect many inexperienced users showing with versions like
"FreeBSD 9.0-RC1 r226353:226607M", but, well, you never know.
As I'm pretty far away from the development process, that might not
really make much sense or even sound straight nonsense, of course. :)
Cheers,
Luchesar
P.S. As for the original problem, from my really modest experience, I
find the proposal by John and Doug sound -- to run svnversion if it
simply exists, and not bother looking for .svn directory/ies, which
might indeed be in some unexpected places. svnversion seems to exit
pretty fast when the directory is not under Subversion control, so this
shouldn't cause unnecessary delays for those not using Subversion for
their source trees (and if they don't have it installed at all, that's
going to be even less of a problem, of course).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On Oct 22, 2011, at 8:39 AM, Olivier Smedts wrote:
> 2011/10/22 Garrett Cooper :
>>
>> $(svn info | awk '/^Revision:/ {print $2}')
>>
>> is what I use in my installkernel wrapper script. Granted, I didn't know
>> about svnversion some time later, but it appears that svnversion broke some
>> things by consolidating the .svn directories as Chris shows above with the
>> 'exported' line.
>
> Won't work for localized builds :
> $ echo $LANG
> fr_FR.ISO8859-15
> $ pwd
> /usr/src
> $ $(svn info | awk '/^Revision:/ {print $2}')
> $ svn info
> Chemin : .
> Chemin racine de la copie de travail : /usr/src
> URL : http://svn.freebsd.org/base/stable/9
> Racine du dépôt : http://svn.freebsd.org/base
> UUID du dépôt : ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Révision : 226629
> [...]
That was of course just an example of what I did :).
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/22/2011 08:29, Garrett Cooper wrote:
> $(svn info | awk '/^Revision:/ {print $2}')
2 subshells and a pipe for this, vs. only 1 subshell for just running
svnversion.
Anyone else want to propose a more complex solution when a simple and
more effective one already exists? :)
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
22.10.2011 22:12, Doug Barton пишет:
> On 10/22/2011 08:29, Garrett Cooper wrote:
>> $(svn info | awk '/^Revision:/ {print $2}')
>
> 2 subshells and a pipe for this, vs. only 1 subshell for just running
> svnversion.
>
> Anyone else want to propose a more complex solution when a simple and
> more effective one already exists? :)
I'm not an exert here, so I'm not sure which one and why did you call
"simple and more effective":
-
% uname -a
FreeBSD bsam.tel.ru 9.0-BETA2 FreeBSD 9.0-BETA2 #32 r225746: Sat Sep 24
17:00:42 MSK 2011 b...@bsam.tel.ru:/usr/obj/usr/src/sys/BB i386
% time svnversion /usr/src
226160
svnversion /usr/src 8,80s user 7,12s system 16% cpu 1:34,16 total
% time (svn info /usr/src | awk '/^Revision:/ {print $2}')
226160
( svn info /usr/src | awk '/^Revision:/ {print $2}'; ) 0,00s user 0,00s
system 16% cpu 0,013 total
-
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
Hello,
On my Soekris net5501 (AMD Geode i586 CPU) clang make buildworld fails
on an illegal instruction "nopw %cs:0x0(%eax,%eax,1)".
# make buildworld
...
ranlib libiberty.a
clang -O2 -pipe -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\"
-I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g
-DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89
-I/usr/obj/usr/src/tmp/legacy/usr/include
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o gengtype gengtype.o
gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a
clang: warning: argument unused during compilation: '-g'
clang: warning: argument unused during compilation: '-std=gnu89'
./gengtype
*** Signal 4
Stop in /usr/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1
# cd /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools
# gdb ./gengtype
(gdb) r
Starting program: /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/gengtype
Program received signal SIGILL, Illegal instruction.
0x08048b24 in do_typedef (s=0x80532bf "CUMULATIVE_ARGS", pos=0x805e1a4)
at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:103
103 {
(gdb) disas 0x08048b24
Dump of assembler code for function do_typedef:
0x08048b10 : push %ebp
0x08048b11 : mov%esp,%ebp
0x08048b13 : push %ebx
0x08048b14 : push %edi
0x08048b15 : push %esi
0x08048b16 : sub$0xc,%esp
0x08048b19 : mov$0x805e1d4,%edi
0x08048b1e : mov0x10(%ebp),%esi
0x08048b21 : mov0x8(%ebp),%ebx
0x08048b24 : nopw %cs:0x0(%eax,%eax,1)
/etc/make.conf for clang (same as the wiki)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang -E
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
#NO_FSCHG=
--
Help will be welcome.
Thanks regards.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/22/2011 12:07, Boris Samorodov wrote:
> 22.10.2011 22:12, Doug Barton пишет:
>> On 10/22/2011 08:29, Garrett Cooper wrote:
>>> $(svn info | awk '/^Revision:/ {print $2}')
>>
>> 2 subshells and a pipe for this, vs. only 1 subshell for just running
>> svnversion.
>>
>> Anyone else want to propose a more complex solution when a simple and
>> more effective one already exists? :)
>
> I'm not an exert here, so I'm not sure which one and why did you call
> "simple and more effective":
Please read the rest of this thread, where the fact that svnversion does
more than what 'svn info' does, and that people find the more that it
does to be useful.
So "simpler" is "one command, not 2 or more," and "more effective" is
"provides more information, and people find that extra information
useful." :)
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On Oct 22, 2011, at 12:13 PM, Doug Barton wrote:
> On 10/22/2011 12:07, Boris Samorodov wrote:
>> 22.10.2011 22:12, Doug Barton пишет:
>>> On 10/22/2011 08:29, Garrett Cooper wrote:
$(svn info | awk '/^Revision:/ {print $2}')
>>>
>>> 2 subshells and a pipe for this, vs. only 1 subshell for just running
>>> svnversion.
>>>
>>> Anyone else want to propose a more complex solution when a simple and
>>> more effective one already exists? :)
>>
>> I'm not an exert here, so I'm not sure which one and why did you call
>> "simple and more effective":
>
> Please read the rest of this thread, where the fact that svnversion does
> more than what 'svn info' does, and that people find the more that it
> does to be useful.
>
> So "simpler" is "one command, not 2 or more," and "more effective" is
> "provides more information, and people find that extra information
> useful." :)
I was just offering an alternative (improperly timed), and as dougb@ pointed
out, svnversion works better.
Thanks,
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPv6 accept_rtadv + bfe0
On Sat, Oct 22, 2011 at 04:13:36PM +0900, Hiroki Sato wrote: > Doug Barton wrote > in <4ea23c08.6060...@freebsd.org>: > > do> On 10/19/2011 00:29, Hiroki Sato wrote: > do> > Mattia Rossi wrote > do> > in <4e9dfe11.2070...@swin.edu.au>: > do> > > do> > mr> So the _ipv6 bit doesn't take care of passing "inet6" to ifconfig > do> > mr> automatically? > do> > > do> > No. You always need to add the inet6 keyword wherever needed. > do> > do> That seems redundant, and contrary to how the IPv4 equivalents work. And > do> obviously it's confusing to users. From what I can see looking at some > do> 7.x and 8.x systems it also seems to be a POLA violation. > do> > do> Perhaps this is something that you should reconsider? > > I am still thinking that omitting an address family keyword before an > address is a bad practice. > > Omitting "inet" keyword in ifconfig_IF and doing in ifconfing_IF_AF > are different. The former one uses ifconfig(8)'s default AF, and > bz's experiments of noinet/noinet6 environment showed it was > problematic. For the latter a keyword has to be automatically > prepended in the rc.d scripts if we want to do so. For IPv6, having > a non-null $ifconfig_IF_ipv6 means the interface is IPv6-capable and > doesn't always involve address configuration > (e.g. ifconfig_IF_ipv6="up" is valid). So, automatic prepending of > "inet6" breaks this. Thus, both have a bad side effect. > > And I want to make ifconfig accept a command line for v4->v6 and/or > v6->v4 tunneling as a p2p link like "inet 10.1.1.1 2001:db8::1" for a > specific type of interfaces in the future. I am not sure if it will > happen actually, but omitting an AF keyword and/or automatic > prepending of the keyword make things difficult. > I can maybe just say, I have now upgraded various machines from 7.x or 8.x to 9 and even though I have read the rc.conf manual I keep tripping on the new IPv6 rc stuff. Various being client, server and router / firewall. It looks like ipv6_prefix_IF now needs an ifconfig_IF_ipv6 = "inet6 auto_linklocal" otherwise it is ignored. In the rc.conf man page, in the ifconfig__ipv6 section, it is suggested to use ifconfig__alias for aliases, but somewhere else it says that that _alias is deprecated. What would be nice is something like the ipv4_addrs_IF= variable. The last paragraph in ifconfig__ipv6, about "inet6 accept_rtadv" should probably be closer to the begining, with some added sentence to make it clear that it is probably what the normal client machine needs. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
Le Sat, 22 Oct 2011 20:51:29 +0200, Patrick Lamaiziere a écrit : > On my Soekris net5501 (AMD Geode i586 CPU) clang make buildworld fails > on an illegal instruction "nopw %cs:0x0(%eax,%eax,1)". I've found a test program from Roman Divacky to check the CPU as clang (http://lev.vlakno.cz/~rdivacky/Host.cpp) It returns "cpu = pentium", looks good. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: replacement of ataidle for freebsd 9
On 22/10/2011 16:21, Eugene Dzhurinsky wrote: ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 Thanks for reporting the breakage, I'll see if I can get it fixed in time for 9.0. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r226642 lib/librtld_db, ".depend", line 1: Need an operator, make: fatal errors
amd64 with SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 in /etc/make.conf "make buildworld" gives: ===> lib/librtld_db (cleandir) ".depend", line 1: Need an operator ".depend", line 3: Need an operator *skip* ".depend", line 924: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Please advise -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC1 panic in tcp_input: negative winow.
On 10/22/11 19:49, Pawel Jakub Dawidek wrote: The panic message says: panic: tcp_input negative window: tp 0xfe007763e000 rcv_nxt 3718269252 rcv_adv 3718268291 I only have picture of the backtrace: http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg ewww that is not good. Can you give us any more information about the machine and what it's doing? Is it terminating TCP connections from the internet at large or only local LAN (i.e. is there likely to be packet loss happening)? Are you doing TSO or LRO? Do you have any non-default tuning in place? Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 9.0-RC1 Available...
The first of the Release Candidate builds of the 9.0-RELEASE release cycle is now available. Since this is the first release of a brand new branch I cross-post the announcements on both -current and -stable. But just so you know most of the developers active in head and stable/9 pay more attention to the -current mailing list. If you notice problems you can report them through the normal Gnats PR system or on the -current mailing list. The 9.0-RELEASE cycle will be tracked here: http://wiki.freebsd.org/Releng/9.0-TODO Wrapping up RC1 was a bit delayed due to a bug found during the initial testing of the RC1 images and a few glitches that came up as part of making FreeBSD-Update available. We'll update the schedule soon. NOTE: The location of the FTP install tree and ISOs is the same as it had been for BETA2/BETA3, though we are still deciding if this will be the layout we switch to for the release. ISO images for the following architectures are available, with pathnames given relative to the top-level of the FTP site: amd64: .../releases/amd64/amd64/ISO-IMAGES/9.0/ i386: .../releases/i386/i386/ISO-IMAGES/9.0/ ia64: .../releases/ia64/ia64/ISO-IMAGES/9.0/ powerpc: .../releases/powerpc/powerpc/ISO-IMAGES/9.0/ powerpc64: .../releases/powerpc/powerpc64/ISO-IMAGES/9.0/ sparc64: .../releases/sparc64/sparc64/ISO-IMAGES/9.0/ MD5/SHA256 checksums are tacked on below. If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is now "RELENG_9", if you use "." (head) you will get 10-CURRENT. If you would like to access the source tree via SVN it is "svn://svn.freebsd.org/base/stable/9/". We still have the nit that the creation of a new SVN branch winds up causing what looks like a check-in of the entire tree in CVS (a side-effect of the svn2cvs exporter) so "mergemaster -F" is your friend if you are using csup/cvsup. FreeBSD Update -- The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.[34]-RELEASE, 8.[12]-RELEASE, or 9.0-BETA[123] can upgrade as follows: First, a minor change must be made to the freebsd-update code in order for it to accept file names appearing in FreeBSD 9.0 which contain the '%' and '@' characters; without this change, freebsd-update will error out with the message "The update metadata is correctly signed, but failed an integrity check". # sed -i '' -e 's/=_/=%@_/' /usr/sbin/freebsd-update Now freebsd-update can fetch bits belonging to 9.0-RC1. During this process freebsd-update will ask for help in merging configuration files. # freebsd-update upgrade -r 9.0-RC1 Due to changes in the way that FreeBSD is packaged on the release media, two complications may arise in this process: 1. The FreeBSD kernel, which previously could appear in either /boot/kernel or /boot/GENERIC, now only appears as /boot/kernel. As a result, any kernel appearing in /boot/GENERIC will be deleted. Please carefully read the output printed by freebsd-update and confirm that an updated kernel will be placed into /boot/kernel before proceeding beyond this point. 2. The FreeBSD source tree in /usr/src (if present) will be deleted. (Normally freebsd-update will update a source tree, but in this case the changes in release packaging result in freebsd-update not recognizing that the source tree from the old release and the source tree from the new release correspond to the same part of FreeBSD.) # freebsd-update install The system must now be rebooted with the newly installed kernel before the non-kernel components are updated. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.2-RELEASE or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 9.0-RC1: # shutdown -r now Checksums: MD5 (FreeBSD-9.0-RC1-amd64-bootonly.iso) = 625d64340f952de2fca7102dac7f180f MD5 (FreeBSD-9.0-RC1-amd64-dvd1.iso) = 5cccbb21a8448e54e4d631619b5f4861 MD5 (FreeBSD-9.0-RC1-amd64-memstick.img) = 07f83c8015a1907953b826b0c65069f0 MD5 (FreeBSD-9.0-RC1-i386-bootonly.iso) = 59f1c057eaa6bff6c69d8e411adeb13c MD5 (FreeBSD-9.0-RC1-i386-dvd1.iso) = 0f168bcfa832282cf6e3914ffc5a5014 MD5 (FreeBSD-9.0-RC1-i386-memstick.img) = ccbc2db07a19b3e77e75958cd7470643 MD5 (FreeBSD-9.0-RC1-ia64-bootonly.iso) = e2e80ffae14950d0437c067e7c6553f1 MD5 (FreeBSD-9.0-RC1-ia64-memstick) = 997bb23954682d503ba10fc3f1a2d624 MD5 (FreeBSD-9.0-RC1-ia64-release.iso) = 3703dc72d55fb9c66450e800b1
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Sun, 23 Oct 2011, Lawrence Stewart wrote: On 10/22/11 19:49, Pawel Jakub Dawidek wrote: The panic message says: panic: tcp_input negative window: tp 0xfe007763e000 rcv_nxt 3718269252 rcv_adv 3718268291 I only have picture of the backtrace: http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg ewww that is not good. Can you give us any more information about the machine and what it's doing? Is it terminating TCP connections from the internet at large or only local LAN (i.e. is there likely to be packet loss happening)? Are you doing TSO or LRO? Do you have any non-default tuning in place? I can't speak for pjd@, but when this issue occured a couple months ago for me, the system I had run into the issue with was doing packet forwarding via ipfw from an internal NAT via ipfw to a corporate network. The system was using bce(4) on the internal and external interface. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-RC1 Available...
On 10/22/11, Ken Smith wrote: > > The first of the Release Candidate builds of the 9.0-RELEASE release > cycle is now available. Since this is the first release of a brand New in RC1, with GENERIC: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/fs/devfs/devfs_devs.c cc1: warnings being treated as errors /usr/src/sys/fs/devfs/devfs_devs.c: In function 'devfs_free': /usr/src/sys/fs/devfs/devfs_devs.c:174: warning: implicit declaration of function 'devfs_free_cdp_inode' /usr/src/sys/fs/devfs/devfs_devs.c:174: warning: nested extern declaration of 'devfs_free_cdp_inode' [-Wnested-externs] /usr/src/sys/fs/devfs/devfs_devs.c: At top level: /usr/src/sys/fs/devfs/devfs_devs.c:689: warning: no previous prototype for 'devfs_alloc_cdp_inode' [-Wmissing-prototypes] /usr/src/sys/fs/devfs/devfs_devs.c:696: warning: no previous prototype for 'devfs_free_cdp_inode' [-Wmissing-prototypes] /usr/src/sys/fs/devfs/devfs_devs.c:696: warning: conflicting types for 'devfs_free_cdp_inode' /usr/src/sys/fs/devfs/devfs_devs.c:174: warning: previous implicit declaration of 'devfs_free_cdp_inode' was here *** Error code 1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-RC1 Available...
On Sat, Oct 22, 2011 at 10:45 PM, Greg Miller wrote: > On 10/22/11, Ken Smith wrote: >> >> The first of the Release Candidate builds of the 9.0-RELEASE release >> cycle is now available. Since this is the first release of a brand > > New in RC1, with GENERIC: Was r226041 MFCed properly? -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Sun, Oct 23, 2011 at 12:35:15PM +1100, Lawrence Stewart wrote: > On 10/22/11 19:49, Pawel Jakub Dawidek wrote: > > The panic message says: > > > > panic: tcp_input negative window: tp 0xfe007763e000 rcv_nxt > > 3718269252 rcv_adv 3718268291 > > > > I only have picture of the backtrace: > > > > http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg > > > > ewww that is not good. Can you give us any more information about the > machine and what it's doing? Is it terminating TCP connections from the > internet at large or only local LAN (i.e. is there likely to be packet > loss happening)? Are you doing TSO or LRO? Do you have any non-default > tuning in place? It is my local file server. It is doing NFS and AFP over LAN and also downloads files from the internet. It is triggered after few hours. I changed the KASSERT() into printf() and added printing 'win' variable and this is what got logged during the night: 05:16:24 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1107827269 rcv_adv 1107826256 win=242 05:16:29 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1107833451 rcv_adv 1107832977 win=880 05:16:41 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1107849563 rcv_adv 1107848860 win=639 05:20:02 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108108230 rcv_adv 1108107331 win=567 05:24:30 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108433302 rcv_adv 1108432272 win=974 05:24:46 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108450385 rcv_adv 1108450060 win=751 05:26:44 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108574818 rcv_adv 1108573851 win=71 05:28:03 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108654103 rcv_adv 1108653166 win=0 05:28:43 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108692396 rcv_adv 1108691451 win=0 05:30:06 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1108781258 rcv_adv 1108780372 win=235 05:35:05 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1109067578 rcv_adv 1109067335 win=663 05:37:03 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1109180403 rcv_adv 1109179411 win=0 05:41:03 tcp_input negative window: tp 0xfe0026772b70 rcv_nxt 1109428265 rcv_adv 1109427375 win=170 And the systems seems to be fine. I'm happy to test patches, but one round would take 24h. My suggestion would be that if we won't be able to fix it before 9.0, we should turn this assertion off, as the system seems to be able to recover. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpcUNlslP3cT.pgp Description: PGP signature
Question about: /etc/periodic/security/800.loginfail
Hi, I noticed that the daily security emails don't show failed logins properly, because the logged string does not match. This is how the lines are grepped for failed logins: n=$(catmsgs | egrep -ia "^$yesterday.*: .*(fail|invalid|bad|illegal)" | tee /dev/stderr | wc -l) This is how the lines look like that I don't see: Oct 23 08:21:16 hostname.domain.com sshd[21547]: error: PAM: authentication error for root from xxx.yyy.com Is there a reason why these messages don't belong into the security mails (except that it would blow up the output)? I think that these log lines are much more useful than those "POSSIBLE BREAK-IN ATTEMPT!" lines or pam_ldap errors, like this one below, which don't tell the origin of the attack: Oct 22 00:07:48 hostname.domain.com sshd[77983]: pam_ldap: error trying to bind as user "uid=root,ou=People,dc=domain" (Invalid credentials) So the question is if this egrep pipe sufficient and if it tells you precisely enough what's going on. Any opinions on this? -- Martin signature.asc Description: PGP signature
