math(s) library folks - 128-bit tgammal(3) review please?
Hi folks Could those folks interested in the math.h library please review https://reviews.freebsd.org/D44168 ? It is a fix for 128-bit (IEEE float) tgammal(3), which has been a "stub" implementation using the 80-bit version to date. The above patch fixes that. Thanks! M -- Mark R V Murray
Re: What to do about tgammal?
> On 18 Dec 2021, at 17:51, Steve Kargl > wrote: > > On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote: >> >> Hmm. I think my understanding of ULP is missing something? >> >> I thought that ULP could not be greater than the mantissa size >> in bits? >> >> I.e., I thought it represents average rounding error (compared with >> "perfect rounding"), not truncation error, as the above very large >> ULPs suggest. >> > > The definition of ULP differs according which expert you > choose to follow. :-) For me (a non-expert), ULP is measured > in the system of the "accurate answer", which is assumed to > have many more bits of precision than the "approximate answer". > From a very old das@ email and for long double I have Thank you! I checked the definition that I was used to, and it is roughly "how many bits of the mantissa are inaccurate (because of rounding error)". I can see how both work. For utterly massive numbers like from Gamma(), I can see how accounting for a much larger range works. It still feels slightly tricky, as e.g. how many digits after the floating point do you account for? > I don't print out the hex representation in ld128, but you see > the number of correct decimal digits is 33 digits compared to > 36. Looking good! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: What to do about tgammal?
> On 18 Dec 2021, at 03:52, Steve Kargl > wrote: > > On Tue, Dec 14, 2021 at 10:21:55PM +, Mark Murray wrote: >> On 14 Dec 2021, at 21:51, Steve Kargl >> wrote: >>> Interval max ULP x at Max ULP >>> [6,1755.1]0.873414 at 1.480588145237629047468e+03 >>> [1.0662,6]0.861508 at 1.999467927053585410537e+00 >>> [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 >>> [-1.,-1.0001] 3.157770 at -1.246957268051453610329e+00 >>> [-2.,-2.0001] 2.987659 at -2.220949465449893090070e+00 >>> >>> Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or >> >> Extra diffs most welcome! >> > > Hi Mark, > > Don't know if you noticed, but I borroewed a few cpu cycles > from grimoire. Didn't notice a thing! :-) > My WIP is already better than the imprecise.c > kludge from theraven@. I need to work out the details of > computing logl(x) in extra precision or see if I can leverage > what Bruce did a few years ago. Anywho, current results: > > Interval tested for tgammal: [128,1755] > count: 100 > xm = 1.71195767195767195767195767195767183e+03L > libm = 7.79438030237108165017007606176403036e+4790L > mpfr = 7.79438030237108165017007606175285456e+4790L > ULP = 14869.19517 > > Interval tested for tgammal: [16,128] > count: 100 > xm = 1.27687183687183687183687183687183690e+02L > libm = 6.61421998891483212224382625339007663e+212L > mpfr = 6.61421998891483212224382625338960267e+212L > ULP = 731.00958 > > Interval tested for tgammal: [10,16] > count: 100 > xm = 1.54261654261654261654261654261654251e+01L > libm = 2.74203137295418912508367515208072654e+11L > mpfr = 2.74203137295418912508367515208073861e+11L > ULP = 45.61161 > > Interval tested for tgammal: [1.2446e-60,10] > count: 100 > xm = 6.26200626138006138006138006138006065e-02L > libm = 1.54507103764516989381203274093299079e+01L > mpfr = 1.54507103764516989381203274093299091e+01L > ULP = 0.76751 Hmm. I think my understanding of ULP is missing something? I thought that ULP could not be greater than the mantissa size in bits? I.e., I thought it represents average rounding error (compared with "perfect rounding"), not truncation error, as the above very large ULPs suggest. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: What to do about tgammal?
On 14 Dec 2021, at 21:51, Steve Kargl wrote: > Interval max ULP x at Max ULP > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > [1.0662,6]0.861508 at 1.999467927053585410537e+00 > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > [-1.,-1.0001] 3.157770 at -1.246957268051453610329e+00 > [-2.,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or Extra diffs most welcome! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: What to do about tgammal?
> On 14 Dec 2021, at 20:41, Steve Kargl > wrote: > > On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: >> >> This is now visible for review at >> https://reviews.freebsd.org/D33444 <https://reviews.freebsd.org/D33444> >> > > Just looked at this again. I cannot tell from the > diff whether you've 'git mv' src/imprecise.c to > ld128/b_tgammal.c. This is need to still get the > mapping of tgammal -> tgamma. Fixed, thanks! Thats what I get from checking only on an ld80 machine! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: What to do about tgammal?
> On 13 Dec 2021, at 02:22, Steve Kargl > wrote: > > On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote: >> >> >>> On 4 Dec 2021, at 18:53, Steve Kargl >>> wrote: >>> >>> >>> So, is anyone interested in seeing a massive patch? >> >> Me, please! >> > > So, I have the ld80 case working. I'll open a PR if > on does not exist. The pr will contain This is now visible for review at https://reviews.freebsd.org/D33444 <https://reviews.freebsd.org/D33444> Thanks! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: What to do about tgammal?
> On 4 Dec 2021, at 18:53, Steve Kargl > wrote: > > > So, is anyone interested in seeing a massive patch? Me, please! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: BUG in libm's powf
> On 6 Sep 2021, at 21:22, Gordon Bergling wrote:
>
> could you turn to test program into an AFT test to prevent further
> regressions?
Certainly!
M
>
> —Gordon
>
>> Am 06.09.2021 um 20:04 schrieb Steve Kargl
>> :
>>
>> No, thank you for the quick response.
>>
>> Of course, a one character diff might be easier to review. :-)
>>
>> --
>> steve
>>
>> On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote:
>>> Thanks!
>>>
>>> And it's committed!
>>>
>>> M
>>>
>>>> On 6 Sep 2021, at 18:53, Steve Kargl
>>>> wrote:
>>>>
>>>> Fine with me. I don't have a phabricator account and
>>>> bugzilla reports seems to get lost in the ether.
>>>>
>>>> --
>>>> steve
>>>>
>>>> On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
>>>>> Hi
>>>>>
>>>>> I've opened a Phab ticket for this. I hope that's OK?
>>>>>
>>>>> https://reviews.freebsd.org/D31865
>>>>>
>>>>> M
>>>>>
>>>>>> On 6 Sep 2021, at 16:28, Steve Kargl
>>>>>> wrote:
>>>>>>
>>>>>> Paul Zimmermann has identified a bug in Openlibm's powf(),
>>>>>> which is identical to FreeBSD's libm. Both derived from
>>>>>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>>>>>>
>>>>>> Consider
>>>>>>
>>>>>> % cat h.c
>>>>>> #include
>>>>>> #include
>>>>>> int
>>>>>> main(void)
>>>>>> {
>>>>>> float x, y, z;
>>>>>> x = 0x1.ecp-1F;
>>>>>> y = -0x1.02p+27F;
>>>>>> z = 0x1.557a86p115F;
>>>>>> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> % cc -o h -fno-builtin h.c -lm && ./h
>>>>>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>>>>>>
>>>>>> Note, clang seems to have a builtin for powf(), but one cannot
>>>>>> count of clang being the only consumer of libm. With the patch
>>>>>> at the end of this email, I get
>>>>>>
>>>>>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath &&
>>>>>> ./h
>>>>>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>>>>>>
>>>>>> Watch for copy and paste whitespace corruption.
>>>>>>
>>>>>> --- /usr/src/lib/msun/src/e_powf.c 2021-02-21 03:29:00.956878000
>>>>>> -0800
>>>>>> +++ src/e_powf.c 2021-09-06 08:17:09.88000 -0700
>>>>>> @@ -136,7 +136,7 @@
>>>>>> /* |y| is huge */
>>>>>> if(iy>0x4d00) { /* if |y| > 2**27 */
>>>>>> /* over/underflow if x is not close to one */
>>>>>> -if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>>>>> +if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>>>>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>>>>>> /* now |1-x| is tiny <= 2**-20, suffice to compute
>>>>>> log(x) by x-x^2/2+x^3/3-x^4/4 */
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Steve
>>>>>>
>>>>>
>>>>> --
>>>>> Mark R V Murray
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Steve
>>>>
>>>
>>> --
>>> Mark R V Murray
>>>
>>
>>
>>
>> --
>> Steve
>>
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: BUG in libm's powf
Thanks!
And it's committed!
M
> On 6 Sep 2021, at 18:53, Steve Kargl
> wrote:
>
> Fine with me. I don't have a phabricator account and
> bugzilla reports seems to get lost in the ether.
>
> --
> steve
>
> On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
>> Hi
>>
>> I've opened a Phab ticket for this. I hope that's OK?
>>
>> https://reviews.freebsd.org/D31865
>>
>> M
>>
>>> On 6 Sep 2021, at 16:28, Steve Kargl
>>> wrote:
>>>
>>> Paul Zimmermann has identified a bug in Openlibm's powf(),
>>> which is identical to FreeBSD's libm. Both derived from
>>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>>>
>>> Consider
>>>
>>> % cat h.c
>>> #include
>>> #include
>>> int
>>> main(void)
>>> {
>>> float x, y, z;
>>> x = 0x1.ecp-1F;
>>> y = -0x1.02p+27F;
>>> z = 0x1.557a86p115F;
>>> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>>> return 0;
>>> }
>>>
>>> % cc -o h -fno-builtin h.c -lm && ./h
>>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>>>
>>> Note, clang seems to have a builtin for powf(), but one cannot
>>> count of clang being the only consumer of libm. With the patch
>>> at the end of this email, I get
>>>
>>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
>>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>>>
>>> Watch for copy and paste whitespace corruption.
>>>
>>> --- /usr/src/lib/msun/src/e_powf.c 2021-02-21 03:29:00.956878000 -0800
>>> +++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
>>> @@ -136,7 +136,7 @@
>>>/* |y| is huge */
>>> if(iy>0x4d00) { /* if |y| > 2**27 */
>>> /* over/underflow if x is not close to one */
>>> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>>> /* now |1-x| is tiny <= 2**-20, suffice to compute
>>>log(x) by x-x^2/2+x^3/3-x^4/4 */
>>>
>>>
>>> --
>>> Steve
>>>
>>
>> --
>> Mark R V Murray
>>
>
>
>
> --
> Steve
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: BUG in libm's powf
Hi
I've opened a Phab ticket for this. I hope that's OK?
https://reviews.freebsd.org/D31865
M
> On 6 Sep 2021, at 16:28, Steve Kargl
> wrote:
>
> Paul Zimmermann has identified a bug in Openlibm's powf(),
> which is identical to FreeBSD's libm. Both derived from
> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>
> Consider
>
> % cat h.c
> #include
> #include
> int
> main(void)
> {
> float x, y, z;
> x = 0x1.ecp-1F;
> y = -0x1.02p+27F;
> z = 0x1.557a86p115F;
> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> return 0;
> }
>
> % cc -o h -fno-builtin h.c -lm && ./h
> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>
> Note, clang seems to have a builtin for powf(), but one cannot
> count of clang being the only consumer of libm. With the patch
> at the end of this email, I get
>
> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>
> Watch for copy and paste whitespace corruption.
>
> --- /usr/src/lib/msun/src/e_powf.c2021-02-21 03:29:00.956878000 -0800
> +++ src/e_powf.c 2021-09-06 08:17:09.88000 -0700
> @@ -136,7 +136,7 @@
> /* |y| is huge */
> if(iy>0x4d00) { /* if |y| > 2**27 */
> /* over/underflow if x is not close to one */
> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> /* now |1-x| is tiny <= 2**-20, suffice to compute
> log(x) by x-x^2/2+x^3/3-x^4/4 */
>
>
> --
> Steve
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
objcopy "text file busy" build failure with populated /usr/obj
Hi *
I've been getting these build failures for a while (weeks/months). The machine
is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and zfs
filesystem. If I empty out /usr/obj, then the build works, but takes a few
hours. If I do a no-clean build with /obj/obj populated with he contents of a
previous build, and /usr/src with updated ("svn update") sources, then the
below nearly always happens early in the rebuild. It is in "stage 4.4: building
everything" that this happens. The build is parallel (-j8), and I have manually
de-threaded the output.
The generated command-line from the logfile is:
cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64 MACHINE=arm64
CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target
aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++
-target aarch64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target
aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" LD="ld"
LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size"
STRIPBIN="strip" INSTALL="install -U"
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make -f Makefile.inc1
BWPHASE=everything DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all
Anyone else seeing this?
objcopy --strip-debug --add-gnu-debuglink=objcopy.debug objcopy.full objcopy
objcopy: open objcopy failed: Text file busy
--- all_subdir_usr.bin/objcopy ---
*** [objcopy] Error code 1
make[4]: stopped in /usr/src/usr.bin/objcopy
M
--
signature.asc
Description: Message signed with OpenPGP
Re: Problem with zfs.ko: lockstat_enabled symbol
On 12 Sep 2020, at 12:18, Eric McCorkle wrote: > > I recently updated my other laptop, and now I'm getting a problem > loading zfs.ko at boot, relating to the lockstat_enabled symbol not > being defined (this happens during kernel boot and prevents mounting > root, so I can't get an exact trace) > > Looking at the new kernel, it seems that only zfs.ko contains the symbol > lockstat_enabled (notably, kernel does not). In my old kernel, zfs.ko > does not contain a reference to that symbol. > > Has anyone else seen this? Is there a workaround, or was this a one-off > bug? I had this, and I fixed it by adding options ZFS ... to my kernel config. I found this in a nearby NOTES file; perhaps it should be in GENERIC? M -- signature.asc Description: Message signed with OpenPGP
Re: The spkr driver
> On 28 Aug 2020, at 17:25, Warner Losh wrote: > > Greetings, Hi > I'd like to retire the spkr driver. It was a cute hack before sound cards > were ubiquitous, but it's not been kept up to date, and it's not clear that > it still works It is still Giant locked, and though it's not a huge > effort to do the locking I literally have no way to test it that I trust... It does work, and de-orbiting it will break morse(6), the "-p" option in particular. Is this a great loss? I doubt it; Its a cute hack. I reckon morse could stand learning how to inject sounds into /dev/audio anyway. > Is anybody using it these days for anything? If not, I'd propose we > de-orbit it before 13. If so, I need people to test patches to remove > Giant... I could test the patches, but frankly I'd rather fix morse(6). M -- signature.asc Description: Message signed with OpenPGP
Re: r356096 causes early panic with options RANDOM_ENABLE_UMA
Hi RANDOM_ENABLE_UMA has not been tested in a while and my need to be retired. It had a pretty significant effect on a time-critical part of the kernel, and there are much better ways to get entropy. Thanks, M > On 16 Feb 2020, at 12:51, Lev Serebryakov wrote: > > Hello freebsd-current, > > Any kernel built from r356096 and later (till r357508 at least) panics > early (sometimes too early to print proper panic diagnostics!) with page > fault on this system when I have these options enabled in kernel config: > > options RANDOM_LOADABLE > options RANDOM_ENABLE_UMA > > It is not fixed at least in r357508 > > -- > Best regards, > Lev mailto:l...@freebsd.org > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > signature.asc Description: Message signed with OpenPGP
Re: Can't update CLang-based system
Tim Kientzle writes:
I have a FreeBSD-CURRENT AMD64 system here that was last updated at =
r215029.
I'm trying to update it to r219079, but the build fails in lib/libz when =
it tries to compile gvmat64.S. It looks like the Makefile here has a =
workaround for clang on AMD64, but it doesn't seem to actually be =
working in this case.
Hi
Exactly the same problem here on r219091:
[graveyard] /usr/src 11:25 am # which clang
/usr/bin/clang
[graveyard] /usr/src 11:25 am # clang -v
FreeBSD clang version 2.9 (trunk 126547) 20110226
Target: x86_64-undermydesk-freebsd9.0
Thread model: posix
[graveyard] /usr/src 11:25 am # cat /etc/src.conf
KERNCONF= G_AMD64_C
#
BATCH_DELETE_OLD_FILES= yes
#
WITHOUT_LPR=yes
WITHOUT_SENDMAIL= yes
WITHOUT_CTM=yes
#
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Then make buildworld with empty /usr/obj and -DNOCLEAN:
:
:
--
stage 1.2: bootstrap tools
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL=sh
/usr/src/tools/install.sh
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
WORLDTMP=/usr/obj/usr/src/tmp VERSION=FreeBSD 9.0-CURRENT amd64 900033
MAKEFLAGS=-m /usr/src/tools/build/mk -D NOCLEAN -m /usr/src/share/mk
TARGET=amd64 TARGET_ARCH=amd64 make -f Makefile.inc1 DESTDIR=
BOOTSTRAPPING=900033 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT
-DWITHOUT_MAN -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS
-DNO_WARNS -DNO_CTF bootstrap-tools
=== lib/clang/libllvmsupport (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for
/usr/src/lib/clang/libllvmsupport
rm -f .depend
CC='clang' mkdep -f .depend -a
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\
-I/usr/obj/usr/src/tmp/legacy/usr/include
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regcomp.c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regerror.c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regexec.c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfree.c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regstrlcpy.c
CC='clang' mkdep -f .depend -a
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\
-I/usr/obj/usr/src/tmp/legacy/usr/include
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSInt.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allocator.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Atomic.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CommandLine.cp
p
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConstantRange.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CrashRecoveryContext.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGDeltaAlgorithm.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DeltaAlgorithm.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf.cpp
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DynamicLibrary.cpp
/usr/src/mov edx, [(rsp + 8 - 96)]
^
/tmp/cc-D1h2GI.s:302:3: warning: ignoring directive for now
.att_syntax
^
/tmp/cc-D1h2GI.s:304:3: warning: ignoring directive for now
.intel_syntax noprefix
^
/tmp/cc-D1h2GI.s:309:9: error: unknown use of instruction mnemonic without a
size suffix
mov r11d,258
^
/tmp/cc-D1h2GI.s:310:9: error: unknown use of instruction mnemonic without a
size suffix
mov [ rcx + 160], r8d
Re: Setting up IPv6 in /etc/rc.conf
Bjoern A. Zeeb writes:
On Fri, 15 Oct 2010, Mark Murray wrote:
Alexey Shuvaev writes:
gifconfig_gif0_ipv6=2001:::::2 2001:::::1
prefixlen 128
I suppose you should prefix it with inet6 keyword.
There are 2 examples in rc.conf (search for Sample IPv6).
Ah!
It didn't occur to me that I might need TWO inet6's! I'll give that a go
when
I play with this again tomorrow.
It's just one inet6; put there what you would pass to ifconfig on the
command line. The fact that ifconfig defaults to inet is the
problem leading to more confusion.
In which case, I'm back to square one. What should work doesn't.
I have the necessary commands in /etc/rc.local to bring up IPv6.
I think the samples in defaults/rc.conf will be more clear soon.
Cool! Thanks.
M
--
Mark R V Murray
Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open)
Pi: 132511160
___
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
Setting up IPv6 in /etc/rc.conf
Hi IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the following (which works): $ ifconfig gif0 create $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44 $ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen 128 $ route -n add -inet6 default 2001:::::1 $ ifconfig gif0 up ... when my non-working setup in /etc/rc.conf contains gif_interfaces=gif0 gifconfig_gif0=192.168.0.2 11.22.33.44 gifconfig_gif0_ipv6=2001:::::2 2001:::::1 prefixlen 128 ipv6_defaultrouter=-inet6 default 2001:::::1 ... which used to work. The bit that fails is the bit where gif0 gets its tunnel IPv6 addresses. I've tried both gifconfig_gif0_ipv6=... and ifconfig_gif0_ipv6= The IPv6 endmpoints never make it onto gif0. This used to work, but setting up IPv6 in CURRENT is a moving target, and I can't find a working example any more. I've looked in /etc/defaults/rc.conf, but the gifN examples there are all devoid of any IPv6 examples. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 ___ 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: Setting up IPv6 in /etc/rc.conf
Alexey Shuvaev writes: gifconfig_gif0_ipv6=2001:::::2 2001:::::1 prefixlen 128 I suppose you should prefix it with inet6 keyword. There are 2 examples in rc.conf (search for Sample IPv6). Ah! It didn't occur to me that I might need TWO inet6's! I'll give that a go when I play with this again tomorrow. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 ___ 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
[no subject]
Hi You haven't responded to this. I'm very interested in these patches, please. M --- Forwarded Message Date:Thu, 27 Nov 2003 11:51:19 + From:Mark Murray [EMAIL PROTECTED] To: Terry Lambert [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: rtld + static linking Terry Lambert writes: I've looked without much success. Could you give a timeframe, a subject and/or something? Note that the part you snipped indicated that the patches were posted by a third party, and that my own patches had been offered, but were not posted in their entirety to the mailing list. In actuality, I only ever posted portions of my own patches, since they also required compiler and linker changes. Could you please post your patches in their entirety? M - -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] --- End of Forwarded Message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Terry Lambert writes: I've looked without much success. Could you give a timeframe, a subject and/or something? Note that the part you snipped indicated that the patches were posted by a third party, and that my own patches had been offered, but were not posted in their entirety to the mailing list. In actuality, I only ever posted portions of my own patches, since they also required compiler and linker changes. Could you please post your patches in their entirety? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Terry Lambert writes: Since I have patches to make dlopen work with static binaries, and : [ snip ] : As to inevitable where are the patches?, please check the -current list archives, you will find at least one set there. I've looked without much success. Could you give a timeframe, a subject and/or something? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Operating system advocacy (Was: Re: 40% slowdown with dynamic /bin/sh)
Matthew Dillon writes: Hmm. Well, I think there's some confusion here. While I certainly like my vision for DFly better then I like the vision for FreeBSD-5, that is simply in the eye of the beholder... of course I am going to like my own vision better. It's my vision, after all! Your vision is obviously different. In fact, I expect that each person has his own vision for the project, so don't knock me for mine. There is a lot of opinion-knocking happening here on both sides, and tempers are flaring. Can I please ask that all parties take a step back and do what it takes to increase light and reduce heat? But that has nothing to do with perceived inferiority or superiority. True, inferiority/superiority issues are notoriously fulminative, and we need to get this track back to the technical level, and away from more personal achievment issues. The issue isn't so much whether one project is better then the other as it is whether one is able and willing to borrow a proven concept from another project to replace the one that maybe isn't so hot in one's own. No. This thread is about a much more basic issue; the resolution of the static/dynamic issue in the / volume. Which operating system has the better solution, while a valid discussion point, is a side track here, and is serving to add heat, not light. As it happens, I have borrowed quite a bit of code from 5.x. As it also happens, I believe that 5.x would benefit by adopting some of the things that have already been proven to work quite well in DragonFly. For example, using a statistical time accumulation model instead of calling microtime() in the middle of the critical thread switch path, or not preemptively switching threads operating in kernelland to another cpu, or the implementation of a mutexless scheduler. Just a few examples. I can only point out the concepts and ideas and point to the code in DFly, it is up to FreeBSD-5 developers to take the ball up and either throw it away or run with it. Good points all. Perhaps they need to be discussed in their own right, and not as a digression to the original thread? And, just for the record, I feel quite obligated to try to move the FreeBSD project forward along a path that I believe will be more beneficial to its users. Careful. You are working hard on a very admirable project; please can you continue to do do, and as-and-when issues from DFBSD prove their worth, they will be adopted by other projects. This is a case where the separation of strong personalities actually works out rather nicely, and you can help this by proving how well DFBSD technology is :-). There have been personality clashes in the past; some of these have been shown to be unresolvable, but we now have the improved situation where the talented folks are still developing BSD code without hindering each other. This way BSD and its users win. The way you can best help BSD is to continue to develop DragonFlyBSD. Just to be clear: My obligation is to all the people who use FreeBSD, not to the feelings of particular developers whos vision(s) I might disagree with. I have no intent or intention of screwing over FreeBSD (how absurd!) but you should not mistakenly equate that to me being accomodating to FreeBSD's current vision which, yes! it is true! I have serious disagreements with. Sure. There are going to be disagreements, This is why there are 4 BSD's available for free. Over the years I have recommended FreeBSD to hundreds of people and I take that responsibility very seriously. Thank you! I hope that you will also be able to do that with DragonFlyBSD. If it is within the scope of the FreeBSD charter for a person to post based on a perceived obligation to the end users of FreeBSD, then I certainly still have a right to post to this group. Sort of. General opinion-mongering, flamage, sidetracking and so on are off-charter. This is FreeBSD CURRENT, and it is most likely the best to keep it somewhat restricted to that as some folks are starting to get annoyed at the Dragonfly Advertising. I think that keeping DFBSD-Advocacy/Discussion on FreeBSD lists to a pretty low level would help keep blood pressure down all round (No offense intended, DFBSD is a worthwhile project, its just that inter-project politics are somewhat rough, and I'm trying to cool things down!) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
The matcd(4) driver needs a maintainer
Hi The matcd(4) driver needs an active maintainer. Do we have any volunteers? Without active maintenance/use, the driver will rot, die and be removed from the tree. Speak up now! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help saving my system
Scott M. Likens writes: Ah, such a strong comment from such a strong member. I would have thought you were to high to stoop that low? But I guess it's good to be flamed for being honest? is it not? Please don't encourage flames and flamers by responding to them. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help saving my system
Jason Dictos writes: From what I understand in the freebsd hand book, a cvsup get and a buildworld won't touch anything in /etc, so if I just re-do a build world of current I an *assuming* i'll be able to get back on track. Sort of. You've changed versions pretty seriously, so its very likey that you've got a big mess left behind. Its possible to clean up this mess, if you know what you are doing. If there is nothing on the box that you want to keep, its probably faster to reinstall. Otherwise you can muddle through, but for the most part, unless you show some pretty specific problems in rather fine (and not too long) detail, you are pretty much on your own. Sorry! For this, the questions@ and newbies@ lists are better than [EMAIL PROTECTED] M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AES is broken.
Poul-Henning Kamp writes: For stuff like AES we should _really_ have a standalone regression test. Anyone out there willing to make one from the official AES test-vectors from NIST ? Yeah. I can do this. Gimme a day or three. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Base packaging
Paul Richards writes: I've got a prototype setup that packages the base tree. It turned out to be very simple. It needs a lot more polishing and testing but it looks like this can definitely be made to work with just some tidying up and re-arranging of our existing make files. I've succesfully created packages of /sbin by adding the following to /usr/src/sbin/Makefile -- PORTNAME= FreeBSD-sbin PORTVERSION= 1.0 COMMENT=sbin CATEGORIES=misc -- ... etc. This is excellent! However, I suspect that a marginally better place to use these would be in the make distribute target that make release uses. This way, the files are already separated out into directory structures, and it may be easier to build complex pkg-plist's with find(1). ALSO, it may be easier to make more fine-grained packages (DISTRIBUTION=foo) with this. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Entropy harvesting: interrupts ethernet point_to_point
Putinas writes: Hi all, on the recent src with custom compiled kernel ( generic minus some stuff what I don't need ) with firewall compiled in kernel , system infinitely hangs on boot unless I press ctrl-c at this point: Entropy harvesting: interrupts ethernet point_to_point Same things happens on two different computers with nearly similar custom kernel configuration Could you tell me, what's causing the problem ? * If needed I can submit my kernel configuration * When it hangs, please press ctrl-T, and report back the status line that you get in response. Thanks! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Entropy harvesting: interrupts ethernet point_to_point
Doug Barton writes: I've seen this problem on my compaq evo n610c as well, but didn't realize it was affecting other hardware as well. I tried to stir up interest in getting the acpi problem fixed, but wasn't successful. Hmmm :-( Mark, ok with you if I nuke the sysctl -a line in rc.d/initrandom? I hate to lose that source (no matter how small), but if the can't finish sysctl -a cancer is spreading... I'd really rather see sysctl fixed, rather than weakening Innocent Bystanders, but I'm not going to force this issue. So, reluctantly, yes, if you can't find a better place to hack a fix. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Current panic in pmap/VM
Hi all I'm getting a repeatable panic on i386/SMP CURRENT with a big C++ compile (one of the KDE3 things). It is a page fault in kernel mode, and the hand-transcribed backtrace is pmap_ts_referenced() vm_pageout_scan() vm_pageout() fork_exit() fork_trampoline() I'm happy to try patches if anyone has ideas. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Current panic in pmap/VM
John Baldwin writes: pmap_ts_referenced() vm_pageout_scan() vm_pageout() fork_exit() fork_trampoline() I'm happy to try patches if anyone has ideas. Having the fault address as well as the source file/line of where the fault occurs could be helpful. From 2 panics, I have 2 addresses - 0xc02cbbab and 0xc02cfb9b (Custom kernels, so I doubt those will help). The source file is src/sys/i386/i386/pmap.c, and it is in the pmap_ts_referenced() function (a short function) at about line 2895. I'm suspecting that a lock is needed. I'll need to put a serial debugger on to go any further. Does this work, or will I be wasting effort? (Getting that cable in is going to be a _pain_). M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: pca driver being retired.
Dan Nelson writes: In the last episode (Aug 13), Julian Elischer said: Well I'm not too happy about this.. It's the only audio I have on my TI-810 laptop. That is however not running -current yet. I'm also not pleased from the perspective that this is the only major example in the tree of how to use the clock-speedup code in i386/isa/clock.c. A very nice piece of functionality I use quite often. It's also handy if you don't have external speakers hooked up to a machine, and want something better than beeps. Would it be a useful exercise for the minority(?) of users who use this driver to either see if it can be effectively newbussed or turned into a port or both? I see considerable scope for an infrastructure that would allow drivers to be ports. _Easily_. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alpha/EISA broken?
Wilko Bulte writes: Sounds like an SRM problem or EISA configuration problem. Normaly the bus and then system board should be probed at this point. We never used EISA on alpha before - EISA bridge support was only conditionalisized on pci. Which triggers me: did you run the ECU? A copy is at: ftp://ftp.tcja.nl/pub/wilko/alpha I have this now. It looks like something I dd(1) onto a floppy? In case something is wrong with your eisa setup. Eisa configuration has to be done via alphabios. Do 'runecu' from the SRM console and it should work. With the froppy in the drive, I presume? The SRM console is the prompt where you type boot, right? (Typing from work - will do at home later). M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alpha/EISA broken?
Wilko Bulte writes: On Thu, Jul 31, 2003 at 01:40:28PM +0100, Mark Murray wrote: Wilko Bulte writes: Sounds like an SRM problem or EISA configuration problem. Normaly the bus and then system board should be probed at this point. We never used EISA on alpha before - EISA bridge support was only conditionalisized on pci. Which triggers me: did you run the ECU? A copy is at: ftp://ftp.tcja.nl/pub/wilko/alpha I have this now. It looks like something I dd(1) onto a floppy? yessir :-) And then do what with? Boot off it? run it from the bios? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make rerelease broken?
Scott Long writes: Bruce Cran wrote: There appears to be a breakage of 'rerelease' - that is, 'release' works, but 'rerelease' fails in telnetd. After fixing the Makefile for the gcc -Os build, the build failed in /usr/src/contrib/telnet/telnetd/authenc.c and ext.h. I have since verified that the 'release' succeeds when the 'rerelease' fails. I get messages about 'undefined reference to nclearto' - it's not finding the extern char *nclearto from ext.h. For some reason, it only fails when doing the rerelease. -- Bruce Cran I saw this too, but couldn't verify that it wasn't due to other problems that I was experiencing. Mark, can you take a glance at this? This seems to only happen when 'rerelease' triggers something to be rebuilt. I kept on seeing this with rescue/ when I was trying to fix the kerberos5 and telnet builds. There is something dodgy with the crunchgen stuff that leaves behind .o files compiled with the wrong -DFOO defines. Result is things that don't link properly much later. I'd need a complete log to comment further. PLEASE DON'T EMAIL IT!! Please put it somewhere for me to fetch. Any diffs to release/Makefile and the exact command line used to kick off the build would be useful too. Thanks! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alpha/EISA broken?
Wilko Bulte writes: And then do what with? Boot off it? run it from the bios? runecu from SRM. Better have a VGA card installed. Serial console is possible to but is a bit (hum..) of a challenge. I'm in big trouble. I have no VGA, it hangs off EISA, and I need to turn it on. I can connect on a serial console, but ECU assumes a VT220, and the output is unreadable. Any suggestions? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Alpha/EISA broken?
Hi Latest boot on my Alpha breaks thus: Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xfc3303c0... sio1: gdb debugging port Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Fri Jul 25 11:50:23 BST 2003 [EMAIL PROTECTED]:/usr/src/sys/alpha/compile/G_ALPHA Preloaded elf kernel /boot/kernel/kernel at 0xfc868000. Preloaded elf module /boot/kernel/linux.ko at 0xfc8680d0. Preloaded elf module /boot/kernel/sysvshm.ko at 0xfc8681a0. Preloaded elf module /boot/kernel/sysvsem.ko at 0xfc868270. Preloaded elf module /boot/kernel/sysvmsg.ko at 0xfc868340. Preloaded elf module /boot/kernel/osf1.ko at 0xfc868410. Preloaded elf module /boot/kernel/if_dc.ko at 0xfc8684e0. Preloaded elf module /boot/kernel/miibus.ko at 0xfc8685b0. Preloaded elf module /boot/kernel/random.ko at 0xfc868680. Preloaded elf module /boot/kernel/isp.ko at 0xfc868750. Preloaded elf module /boot/kernel/cam.ko at 0xfc868820. Preloaded elf module /boot/kernel/nfsserver.ko at 0xfc8688f0. Preloaded elf module /boot/kernel/nfsclient.ko at 0xfc8689c8. AlphaServer 1000/1000A AlphaServer 1000A 5/500, 500MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1BWX OSF PAL rev: 0x1000600020117 real memory = 266371072 (254 MB) avail memory = 250863616 (239 MB) cia0: 2117x Core Logic chipset cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21DWEN,BWEN pcib0: 2117x PCI host bus adapter on cia0 pci0: PCI bus on pcib0 eisab0: PCI-EISA bridge at device 7.0 on pci0 halted CPU 0 halt code = 7 machine check while in PAL mode PC = 18100 Any idea what gives? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alpha/EISA broken?
Wilko Bulte writes: halt code = 7 machine check while in PAL mode PC = 18100 Any idea what gives? Not really, but as a datapoint today's -current does work OK on a EISA-less machine. GENERIC kernel also has above error. Remove eisa, and the boot goes straight to panic (no clock). M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Alpha/EISA broken?
Wilko Bulte writes: GENERIC kernel also has above error. Remove eisa, and the boot goes straight to panic (no clock). That is because your clock sits behind eisa I think. ticso recently posted some days ago that eisa is now mandatory on alpha. I did not follow in detail to be honest. Check the archives. Well, that's left me hosed :-(. I looked through current@ and alpha@ (briefly) and saw nothing obvious. What should I be looking for? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
Hi
Please do not commit this.
M
Ruslan Ermilov writes:
--A9z/3b/E4MkkD+7G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 22, 2003 at 07:42:33PM +0300, Ruslan Ermilov wrote:
Hi!
=20
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
=20
Missed in the patch: set DISTRIBUTION=3Dcrypto in lib/libtelnet/Makefile,
so that we still have crypto/usr/include/arpa/telnet.h.
%%%
Index: Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile 20 Jul 2003 23:29:46 - 1.16
+++ Makefile 23 Jul 2003 06:37:09 -
@@ -13,10 +13,11 @@
=20
WARNS?=3D2
=20
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OP=
ENSSL)
+DISTRIBUTION=3D crypto
SRCS+=3D encrypt.c auth.c enc_des.c sra.c pk.c
CFLAGS+=3D -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
SRCS+=3D kerberos5.c
CFLAGS+=3D -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
CFLAGS+=3D -DFORWARD -Dnet_write=3Dtelnet_net_write
%%%
Cheers,
--=20
Ruslan ErmilovSysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
--A9z/3b/E4MkkD+7G
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/Hi8lUkv4P6juNwoRArAKAJ0QpXpQ9YPuG5gXUo/5p+uia83CiACfTkYW
Myhb+SttdXFnNahueIHJ7Us=
=LyZK
-END PGP SIGNATURE-
--A9z/3b/E4MkkD+7G--
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
+=3D genget.c getent.c misc.c
CFLAGS+=3D -DHAS_CGETENT
-.endif
+.else
+CFLAGS+=3D -DINET6 -DIPSEC
+DPADD+=3D${LIBIPSEC}
+LDADD+=3D-lipsec
=20
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OP=
ENSSL)
+DISTRIBUTION=3D crypto
SRCS+=3D authenc.c=20
CFLAGS+=3D -DENCRYPTION -DAUTHENTICATION -DIPSEC
DPADD+=3D${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBIPSEC} ${LIBPAM}
LDADD+=3D-lmp -lcrypto -lcrypt -lipsec ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
CFLAGS+=3D -DKRB5 -DFORWARD -Dnet_write=3Dtelnet_net_write
DPADD+=3D${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
LDADD+=3D-lkrb5 -lasn1 -lcom_err -lroken
+.endif
.endif
.endif
=20
--a8Wt8u1KmwUX3Y2C--
--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/HWl5Ukv4P6juNwoRAgnvAJ96n/MFl2mtKOPU4v6H2/7xEQjQbQCfWKZO
l3wwJ/OZmt0wCqmhWkpvMGg=
=9BF1
-END PGP SIGNATURE-
--v9Ux+11Zm5mwPlX6--
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm writes: Tinderbox wrote: gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/c at gets.3 catgets.3.gz Segmentation fault (core dumped) *** Error code 139 These false alarms are wearing a bit thin. Is there a problem with the tinderbox build machine perhaps? My home box is doing it too. as(1) blowing up randomly. No usable core dumps. :-(. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: telnet build fails without openssl...
Anti writes: buildworld fails at telnet if you build with NOCRYPT and NO_OPENSSL -- telnet stuff is looking for NO_CRYPTO to disable this, which isn't documented anywhere... Thanks! This should be fixed now. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ``Resource temporarily unavailable'' in vi
Mikhail Teterin writes: Every once in a while, a vi-session dies on me with: input: Resource temporarily unavailable What does it mean, why does it happen, and how can I prevent it? Thanks a lot! -mi P.S. Running recent -current. I'm seeing this on current. I use bash, and the machine is not loaded. The heaviest process is spamassassin. There isn't even X running on the box. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a disk bootable...
Hi Ian! Ian Freislich writes: I've used fdisk to create one slice (da0s1). I then used bsdlabel to make make the partitions a, b, e and f. Then to put the boot block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' it trashes the label. Then I copy all my filesystems off the IDE drive I'm trying to rid myself of onto the SCSI disk. When I tell the BIOS to boot off SCSI, it complains 'Missing Operating System'. I've seen this before, and I think it is a geometry problem. Boot the system in verbose mode (off the floppy), and go back and see what the boot probe thinks the geomtery is. (blat the boot partitions first, if you can). Then, when you fdisk, make damn sure that the probed geometry is used. After that, you shouldn't have probelms. If that fixes your problem, please report it in detail to [EMAIL PROTECTED] so we can get a more permanent fix. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3COM ep0 pccard device broken in current.
What a weekend. Frigging _everything_ was a messup. M. Warner Losh writes: In message: [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] writes: : M. Warner Losh writes: : Have you gotten all of the recent changes to current wrt ep0? It was : broken by my making cbbintr mpsafe. Well, it was broken a long time : ago, my change just opened a race that used to be won, but now is : lost. : : Yup. I believe so, but please confirm where the change was to be sure? There were two changes. One is in pccbb.c that makes things a MPSAFE interrupt. You could revert to version 1.175 of pccbb.c. Bingo! (I presumed that you meant 1.75, pccbb doesn't go as far as 1.175). Backing out to 1.75 has my ep0 working again! For ep.c, you need the following or newer Revision 1.115 / (download) - annotate - [select for diffs], Thu Jun 26 13:27:44 2003 UTC (7 days, 23 hours ago) by mux Changes since 1.114: +5 -7 lines Got that. NOW. Can I interest you in doing some ToPIC97 fixes, helping to sort out some working but uncommitted Libretto-110CT ACPI/HDD fixes and a has-never-worked dc0 cardbus card? Pleze? :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3COM ep0 pccard device broken in current.
Andrea Campi writes: I played with this, but without playing with the pccbb.c stuff. I'll give it a go tonight. Mark, I used to see the same issue you are seeing starting from the time the change to pccbb.c went in, but mux's fix to if_ep.c solved it all for me. However, it's always possible that yours is a slightly different problem, so I'd be interested to hear what you are doing exacly so that I could try and repeat it. Hi. Reverting pccbb.c to 1.75 fixed this for me. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3COM ep0 pccard device broken in current.
M. Warner Losh writes: Have you gotten all of the recent changes to current wrt ep0? It was broken by my making cbbintr mpsafe. Well, it was broken a long time ago, my change just opened a race that used to be won, but now is lost. Yup. I believe so, but please confirm where the change was to be sure? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3COM ep0 pccard device broken in current.
M. Warner Losh writes: In message: [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] writes: : M. Warner Losh writes: : Have you gotten all of the recent changes to current wrt ep0? It was : broken by my making cbbintr mpsafe. Well, it was broken a long time : ago, my change just opened a race that used to be won, but now is : lost. : : Yup. I believe so, but please confirm where the change was to be sure? There were two changes. One is in pccbb.c that makes things a MPSAFE interrupt. You could revert to version 1.175 of pccbb.c. I'll play with that in a few hours when I get home. For ep.c, you need the following or newer You mean if_ep.c, right? Revision 1.115 / (download) - annotate - [select for diffs], Thu Jun 26 13:27:44 2003 UTC (7 days, 23 hours ago) by mux Changes since 1.114: +5 -7 lines Fix a race condition that was introduced since pccbb interrupts are flag'ed INTR_MPSAFE. In ep_if_start(), use the IF_DEQUEUE macro to grab the next mbuf to send, and use IF_PREPEND if the card is busy and we actually can't handle it right now. The old code was first getting the mbuf by taking it from the queue without using the macros, thus without locking, and without removing it from the queue either. It was later assuming that IF_DEQUEUE would give him this same mbuf. Tested by:mich I played with this, but without playing with the pccbb.c stuff. I'll give it a go tonight. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
3COM ep0 pccard device broken in current.
Hi Anyone else notice if the epN pccard device is broken in current? The symptoms are the device failing to move packets shortly after you begin to move traffic (a few secs). Pings start doing a no buffer space available, and connections time out. A kernel of 28th may is good, and if I back out recent diffs to if_ep.c it doesn't fix anything, so I'm suspecting pccardd code. Any similar observations? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI stuff to make Libretto 110CT work
John Baldwin writes: On 24-Jun-2003 Mark Murray wrote: Hi You (?) gave me these patches at least 6 months ago, and they've been working for my Libretto ever since then. Is it OK if I commit them? No, not quite yet. Those are rather hackish and I didn't develop them, one of the other ACPI guys did. OK. Can we work on this, then? The patches are developing a bit of a following of folks who would _love_ to see them committed. :-) What is needed? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where is rogue?
Kris Kennaway writes: Oops. Fix coming later today. Any progress on this? Yes. I'll commit as soon as I upload the dist tarball. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where is rogue?
Tilman Linneweh writes: BTW, there are some open PRs regarding the freebsd-games. Currently they are all assigned to freebsd-ports-bugs.=20 Does anyone volunteer to handle these, or are there plans to put the games sources in a CVS somewhere (projects repository?).=20 The port carries a copy of the repository with it. Anyone may fix this port, I'm not holding a lock. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI stuff to make Libretto 110CT work
Hi
You (?) gave me these patches at least 6 months ago, and they've
been working for my Libretto ever since then. Is it OK if I commit
them?
M
--
Mark Murray
iumop ap!sdn w,I idlaH
Index: dev/acpica/acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.89
diff -u -d -r1.89 acpi.c
--- dev/acpica/acpi.c 1 May 2003 18:51:43 - 1.89
+++ dev/acpica/acpi.c 2 May 2003 08:15:39 -
@@ -817,6 +817,10 @@
if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, scopes[i], parent)))
AcpiWalkNamespace(ACPI_TYPE_ANY, parent, 100, acpi_probe_child, bus, NULL);
+if (devclass_get_device(devclass_find(isa), 0) == NULL) {
+ device_set_flags(BUS_ADD_CHILD(bus, 0, isa, 0), 1);
+}
+
/*
* Scan all of the child devices we have created and let them probe/attach.
*/
Index: isa/isa_common.c
===
RCS file: /home/ncvs/src/sys/isa/isa_common.c,v
retrieving revision 1.35
diff -u -d -r1.35 isa_common.c
--- isa/isa_common.c11 Jun 2003 00:32:45 - 1.35
+++ isa/isa_common.c11 Jun 2003 08:10:34 -
@@ -1108,6 +1108,60 @@
1, /* no softc */
};
+static int
+acpi_isa_probe(device_t dev)
+{
+
+ if (device_get_flags(dev) == 0) {
+ return (ENXIO);
+ }
+
+ return (isa_probe(dev));
+}
+
+static device_method_t acpi_isa_methods[] = {
+ /* Device interface */
+ DEVMETHOD(device_probe, acpi_isa_probe),
+ DEVMETHOD(device_attach,isa_attach),
+ DEVMETHOD(device_detach,bus_generic_detach),
+ DEVMETHOD(device_shutdown, bus_generic_shutdown),
+ DEVMETHOD(device_suspend, bus_generic_suspend),
+ DEVMETHOD(device_resume,bus_generic_resume),
+
+ /* Bus interface */
+ DEVMETHOD(bus_add_child,isa_add_child),
+ DEVMETHOD(bus_print_child, isa_print_child),
+ DEVMETHOD(bus_probe_nomatch,isa_probe_nomatch),
+ DEVMETHOD(bus_read_ivar,isa_read_ivar),
+ DEVMETHOD(bus_write_ivar, isa_write_ivar),
+ DEVMETHOD(bus_child_detached, isa_child_detached),
+ DEVMETHOD(bus_driver_added, isa_driver_added),
+ DEVMETHOD(bus_setup_intr, isa_setup_intr),
+ DEVMETHOD(bus_teardown_intr,isa_teardown_intr),
+
+ DEVMETHOD(bus_get_resource_list,isa_get_resource_list),
+ DEVMETHOD(bus_alloc_resource, isa_alloc_resource),
+ DEVMETHOD(bus_release_resource, isa_release_resource),
+ DEVMETHOD(bus_set_resource, isa_set_resource),
+ DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
+ DEVMETHOD(bus_delete_resource, bus_generic_rl_delete_resource),
+ DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
+ DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
+
+ /* ISA interface */
+ DEVMETHOD(isa_add_config, isa_add_config),
+ DEVMETHOD(isa_set_config_callback, isa_set_config_callback),
+ DEVMETHOD(isa_pnp_probe,isa_pnp_probe),
+
+ { 0, 0 }
+};
+
+static driver_t acpi_isa_driver = {
+ isa,
+ acpi_isa_methods,
+ 1, /* no softc */
+};
+
/*
* ISA can be attached to a PCI-ISA bridge or directly to the legacy device.
*/
@@ -1115,5 +1169,6 @@
DRIVER_MODULE(isa, eisab, isa_driver, isa_devclass, 0, 0);
#if defined(__i386__) || defined(__amd64__)
DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0);
+DRIVER_MODULE(isa, acpi, acpi_isa_driver, isa_devclass, 0, 0);
#endif
MODULE_VERSION(isa, 1);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Email accounts on FreeBSD 5.1-RELEASE
Alex Ayala writes: I got a question, if I want to create an email account on my Freebsd 5.1 box, but not let them have shell access do I just do a adduser and specify /sbin/nologin? If I want an off-road vehicle, do I just buy a Land Rover? It usually comes to quite a lot more than that, depending on what it is you want to do _exactly_. The above will work in certain circumstances, but simple testing will tell you that. What we can't tell is whether you need a Land Rover or a Bulldozer. :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Email accounts on FreeBSD 5.1-RELEASE
Alex Ayala writes: Ok, maybe...yes I read what I wrote and didn't quite explain what I really wanted to say. I want to setup accounts on my box so users can retrieve emails by accessing my pop server. Do I need to setup user accounts on my box with the adduser command? I don't want them to be able to have access to the shell by any means. Is like when I wanted to give someone access to my ftp server I just created an account and took out the shell part in the passwd file. Sorry my english is not the greatest. Trying to explain something and can't find the right words. Is that a bit better to understand? Sort of. But you need to understand how to specify and set up a secure system. What is your threat model? What resources are your (ab)users most likely to throw at you, and what are the consequences if they succeed? How much can you afford to spend to prevent this compared with what you guess they are prepared to spend to attack you? Only you can answer these questions. Once you know the comprehensive answer to these questions, you know what to ask of the software and hardware you investigate to perform the task. While you are asking the questions, _experiment_ with what you have, and look for real-life holes in your setup. Try to think like the attacker you are trying to thwart. Attack yourself. Get paranoid. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where is rogue?
Kris Kennaway writes: I installed freebsd-games, and it has most of the games I remember, but n= ot rogue. Well, hrumph, it's supposed to be in that port. Mark, it looks like rogue wasn't added for some reason. Oops. Fix coming later today. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
CTM - any users left?
Hi all Last time I looked, we had _very_ few CTM users. Is there any reason that the CTM stuff should not be a port? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: rpc.yppasswdd working again
Martin Blapp writes: Small, but important message for NIS users. All users who had problems with NIS should rebuild their world. Long outstanding problems have been fixed and rpc.yppasswdd allows root again to change passwords on ypmaster without knowledge of the users password. Does this not create a vulnerability? Example: Bad Guy sets up a personal workstation with himself as root and steals an IP address from the machine he just switched off. Now he can change passwords on the server at will. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: rpc.yppasswdd working again
Martin Blapp writes: maps using ypchpass(1). Again, this only applies to the super-user on the NIS master server: none of these special functions can be performed over the network. I am happy! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Trolling and forge subscribes.
Can someone find out who's trying to add the freebsd mailinglist to other mailinglists? This is getting annoying. PLEASE DO NOT REPLY TO ANY OF THESE TROLLS! Turn on your filters, train your spam-assassins etc. Please DON'T contribute to the traffic. The best way to make a troll go away is to ignore it. I'm dealing with the problem. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: `make buildworld' failed
Doug Barton writes: For you, the easiest way to jump is to remove MAKE_KERBEROS4 from /etc/make.conf. Yes. You should not be using that; it is well broken now. Is it worth putting an #ifdef in /usr/src/Makefile to stop this in its tracks? Not everyone running -current is on top of this stuff (for better or worse). No. :-). If you use CURRENT, stay current. We can't prevent _every_ foot-shoot. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `make buildworld' failed
Ruslan Ermilov writes: KerberosIV support was recently dropped from HEAD, but Mark forgot to remove some vestiges. I've sent him a patch on March 14, but he seems off-line for a moment. I'm on-line, just busy with other things. Please do NOT make that commit. Those KerbIV remains are markers for stuff that we need to revisit. For you, the easiest way to jump is to remove MAKE_KERBEROS4 from /etc/make.conf. Yes. You should not be using that; it is well broken now. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! KerberosIV is being retired!
Hello all Mission control has launched the retro-rocket module to de-orbit KerberosIV (AKA eBones). This package has had a long and illustrious career with FreeBSD; it is now time for a graceful retirement in the ports tree. The de-orbiting process will happen this weekend, in stages. Long live Kerberos 5 !! M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Mark Murray wrote: Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. Only if some idiot breaks the API contract again. Whatever happened to you broke it, you fix it? Hopefully, the next time it happens, and something gets punted to the Attic, it will be code *you* care about, instead of code I care about. Then it will be *your* problem, and I can sit back and make smarmy postings. Guess what? This has already happened. I'm working on a fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Let' start wth the libalias/natd incremental checksum update code; the code is based on RFC1141, instead of RFC1624. As a result, it get updated incorrectly occasionally, because it's using two's complement instead of one's complement math. Per RFC1642: RFC 1141 yields an updated header checksum of -0 when it should be +0. This is because it assumed that one's complement has a distributive property, which does not hold when the result is 0 (see derivation of [Eqn. 2]). People see this as hands on FTP installs, etc., going through FreeBSD based NAT's. It's very obvious ad easy to repeat: 1)Put a printf in tcp_input.c that compalins when the checksum is incorect. 2)Do a CVSup from that machine through a FreeBSD NAT How long can this remain unfixed before the code is diked out, and the checksum is recalculated fully, instead? Terry, you sound rather foolish when you argue like this. This is semantic tomfoolery and off topic. End of thread. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Juli Mallett writes: This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Mark Murray wrote: Will it be runnable (as in tested), rather than a compile-only fix? Is tested a requirement fo code to be committed or to have it stay in the tree? Both. Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... Be careful of your interpretation of my answer. State _all_ your premises, and be careful not to use any undeclared ones. Do not hold me to any premise that I have not agreed to. All broken code needs to be fixed XOR removed. All fixes need to be tested. All code in the tree needs to be tested often to ensure that it is not broken. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
John Polstra writes: In article [EMAIL PROTECTED], Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: This is wrong. caddr_t should be uniersally replaced with void *. Not quite. There is (or at least used to be) a lot of code that assumed you could do address arithmetic on a caddr_t. You can't do that on a void *, at least not in ANSI C. I think gcc lets you do it, but it's an extension. As I have discovered. I specifically looked for this, and my misreading of the spec is now clear. :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No more new majors, and help loose the old ones...
Poul-Henning Kamp writes: We now have a facility for autoallocating major numbers for device drivers at run time. We will accept no more allocations in sys/conf/majors, unless very good and unavoidable circumstances forces a particular device driver to require a static major number. Please help remove entries in sys/conf/majors for which there exists no software, and convert drivers to use MAJOR_AUTO instead of using static major numbers. Thanks in advance! What is a good driver to crib this from? I'll do /dev/(null|zero|random). M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OpenSSL should define OPENSSL_THREADS?
Jacques A. Vidrine writes: Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? I think you may be right. OpenSSL 0.9.7's out-of-the box configure creates an opensslconf.h that would define OPENSSL_THREADS on FreeBSD. Mark supplied the opensslconf.h's that are used in the FreeBSD build ... let's see if this is intentional or not. [cc'd] Not intentional. If adding it breaks nothing, go ahead. I have Panic City right now on my devboxes, so I'm working on fixing that. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
Dag-Erling Smorgrav writes: Andrey A. Chernov [EMAIL PROTECTED] writes: Admins with no /etc/opieaccess AFFECTED! Admins with no /etc/opieaccess IDIOTS for not running mergemaster! POLA. We don't want to burn our user/admins. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
Andrey A. Chernov writes: On Sun, Feb 16, 2003 at 11:01:43 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: [...] Please disregard. Andrey does not know what he's talking about and ignores any attempt at explaining what the real issue is and what real users want. Unless you specify exact details of what I ignore, I'll be forced to treat your reply as NO REVIEW and commit this changes. No, Andrey, you will not. P.S. It really des who ignore that simple fact that was localhost alias in OPIE for years before any evil PAM appearse. As you see, I am specific. Does the -as-localhost-alias break other PAM modules? In what way does localhost or NULL break OPIE? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
Andrey A. Chernov writes: On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Admins with no /etc/opieaccess AFFECTED! Admins with no /etc/opieaccess IDIOTS for not running mergemaster! Moreover, admins WITH old /etc/opieaccess (i.e. without your line) are affected too! Local logins becomes mysteriosly disabled for their users. With a suitable HEADS UP! and appropriate changes to the documentation, might is be possible to move _all_ policy control into PAM, instead of having it split between OPIE and PAM? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
David O'Brien writes: On Sun, Feb 16, 2003 at 07:11:49PM +, Mark Murray wrote: In the case where an application is OPIEised and not PAMised, we need to figure out something; PAMizing such apps is not terribly hard. If any of them are in the base system, then this situation is a bug in its own right. If they are ports, they need to fall in with FreeBSD/sysadmin policy. I'll state it again, because many don't seem to listen -- many of us consider OPIEized, but not PAMized 3rd party ports a Good Thing. PAM is nothing but a PITA, OPIE offers useful real functionality. David, This is not a failure to understand; it is a disagreement. I am asserting that PAM is the way FreeBSD is doing its authentication policy-setting. I am asserting that as a result of this applications need to comply, somehow. Right now, this is not hard. In future, it may get harder. DES has committed some PAM policy tweaks that make this possible. Bear in mind that PAM may leave you behind at some point; it is in the focus. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
David O'Brien writes: With a suitable HEADS UP! and appropriate changes to the documentation, might is be possible to move _all_ policy control into PAM, instead of having it split between OPIE and PAM? Nope. What about opieized, but not pamized applications? OPIE needs to act on FreeBSD like it does on every other Unix platform. It really does seem like DES is chaning existing practice. Changing existing practice is what I'm asking about. If there is a particular policy on a FreeBSD box, then OPIE should really be falling in with that, no? In the case where an application is OPIEised and not PAMised, we need to figure out something; PAMizing such apps is not terribly hard. If any of them are in the base system, then this situation is a bug in its own right. If they are ports, they need to fall in with FreeBSD/sysadmin policy. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
Andrey A. Chernov writes: If I understand correctly, this still doesn't solve the problem, because any PRNG sequence that hits the magic value will still get stuck there forever. It was true for the first patch I post which just move problem to another= place (this is commonly spreaded method for this PRNG). It is false for the last patch I post which not stuck with any given seed. How do you _know_ that your newly chosen magic number isn't going to cause some kind of recurring (and too-short) sequence of numbers? Will it recur after 5 iterations? 100? 1000? 100? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
Andrey A. Chernov writes: On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote: How do you _know_ that your newly chosen magic number isn't going to cause some kind of recurring (and too-short) sequence of numbers? I run simple test for it, it is not too short. simple test? How long did you check for? random() is documented to not repeat before some number of outputs; how do you know that this fix does not significantly shorten that? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
[EMAIL PROTECTED] writes: BTW, note that new formulae also used in the kernel (by BSD developers) and taken from there - libkern/random.c - so all you say is true there too. It should be nuked from the kernel, and arc4random() used instead. I agree. If no-one objects, I'll do this? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Jeroen C. van Gelderen writes: Wouldn't it be a good idea to change the name at the same time? Or should it be retained for compatibility reasons with other BSDs? Currently the name needlessly exposes implementation detail. Callers expect good, cheap, non-blocking randomness but don't give a hoot if that is actually provided trough use of RC4 or not. I see no reason why the implementation could be changed if the contract is maintained. Good point. We can re-implement random() internally with arc4rand(). Objections? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote: I think it's worthwhile to wait till we get a chance to try arc4random(). This is libc's rand/random, it can't be fixed with arc4random() as designed. Why not? Arc4 is a) deterministic and b) good for all bits. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote: I believe that this change just moves the bad seed to 123459876; after calling srand() with that seed, each call to rand() returns 0. Yes. Nothing better is possible for this formulae and this is documented in algorithm, some value must be excluded. Excluding 0 is bad only because srand(0) is commonly used and srand(123459876) is not. This means that this routine has a chance of failing spectacularly. We should not use it. Ragarding to old formulae, the question is: what is worse, generate non-random lover bits everytime (old variant) or exclude one seed value (new variant)? Neither. New RNG is needed. Of course formulae can be changed to some another algorithm, but keep in mind that rand() must be simple and speedy. Now used variant is most simpler, others are much more complex. RC4 is fast. RC4 is simple. Any objections? :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: Objections? We can't, simple because sequence must be repeated for the same seed across the calls. RC4 is repeatable. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote: Why not? Arc4 is a) deterministic and b) good for all bits. If you mean arc4random() function - not, because it use true randomness, if you mean RC4 algorithm, probably yes, but we should compare its distribution with our current variant and be sure that speed is acceptable. What form RC4 distribution have? (I have read the whole thread) I think we need four things. 1) void srandom(int arg) which uses the argument to seed. 2) void srandomdev(void) which uses system entropy to seed. 3) int random(void) which returns a number statistically random in all bits. 4) something else which returns as many bytes of randomness (statistically random in all bits) as the caller asks for. We have most of this, and RC4 can deliver. RC4's licence is fine. Call it ArCFour and there is no problem. The code is small, fast and repeatable, and meets conditions 1-4 above. Coding is Junior-high-school level, given the spec. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
[EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Mark Murray wr ites: We have most of this, and RC4 can deliver. RC4's licence is fine. Call it ArCFour and there is no problem. The code is small, fast and repeatable, and meets conditions 1-4 above. There are some concerns about RC4's strength and predictability. Not here. We are talking statistical randomness, not cryptographic. RC4 is jst fine. In cases were we just want trivial randomness, this doesn't matter, but when we start to seed it with /dev/random to get good randomness we to be more careful. Sure. srandomdev() needs to burn some output. Maybe we should spend an AES on it, just in case ? Hold that thought. The moral equivalent of 'dd if=random() of=/dev/null bs=1 count=4096' is enough for now. Any problems, and I'll be right with you! M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: Good point. We can re-implement random() internally with arc4rand(). Objections? Guys, please realize that random() is also used in generating simulation inputs (or timing or whatever). If you go change the underlying algorithm or its parameters one can't generate the same sequence from the same seed when repeating a test. Some chip bug symptoms show up after hours/days of simulation time and only with specific inputs so repeatablity is a requirement. RC4 is _utterly_ repeatable, given a particular seed/key. The old 16 bit rand() was broken enough that it didn't matter much (read: _I_ don't care) if its behavior got changed but random() has a pretty long cycle and enough randomness to be very useful and it *is* used. Yes. And it breaks, and we have a complainant. *Please* don't change random() -- if you do that you will break existing tests. It is not a matter of just rewriting tests since there is no easy way to predict which input triggers a certain bug -- one can try to use the same binaries but that prevents fixing of bugs in the test generation code itself. Heisenbug. Which tests do we break? Tests for specific output, or tests for more general cases? The random() function in libc is documented to give the same pseudo-random output for a particular seed. if you link your program against a _different_ libc, you cannot expect your results to follow a particular number sequence. We have to be able to fix bugs, and a bug has been identified. If you want a stable generator here, link statically, and keep a set of compatiblity libraries around. If you think random() is not random enough for your purposes, go create a new function with a *new* name. Any supporters of this request? [I see from his latest email that PHK remembered the old discussion!] So did I! M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: Not changing random() was of real concern to me when I was doing chip simulations. ASIC design verification folks won't be happy if the rug is pulled out from under them. In general crypto and simulation needs are different and I don't trust the crypto guys to look out for the simulation guys! Are you a Verilog guy ar a VRML guy? Something else maybe? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
David Malone writes: On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote: RC4 is _utterly_ repeatable, given a particular seed/key. I presume it also produces reasonably uniform output for most seeds too. Yes. Modulo the requirement to burn a bit of output after a reseed. The old 16 bit rand() was broken enough that it didn't matter much (read: _I_ don't care) if its behavior got changed but random() has a pretty long cycle and enough randomness to be very useful and it *is* used. Yes. And it breaks, and we have a complainant. I thought the complaint was about rand, not random? Erm, yes. Similar difference though. PRNGs are _trouble_ unless designed properly. If you think random() is not random enough for your purposes, go create a new function with a *new* name. Any supporters of this request? I'd support that. People who are using rand and random for crypto type randomness are deceiving themselves, as neither are portably suitable for that use. Lots of people are using rand, random and the rand48 suite for simulation or games, and this type of randomness has different requirements (as Bakul points out - repeatability being a useful one). Repeatability is fine. Is convergence-to-constant OK? I'd suggest we ammend the rand and random man pages saying that sequences produced from either cannot be expected to be suitable for cryptographic purposes, but are should be OK for simulation and games. (I guess a couple of numbers produced after calling srandomdev might be safe, but I wouldn't like to bet on them being that safe...) I'm fine with this. The man page can refer people on to arc4random, the apropriate OpenSSL pages, uuidgen and so on. As different consumers have different, sometimes contradictory, requirements for randomness it seems foolish to try to lump them all into one group of functions. Yes. We should separately document (or at least clarify) the differences between cryptographic randomness and statistical randomness. We should also make sure that both are bug-free. Cast-in-stone algorithms are dumb, but if you really want those, its probably best to put them in your own code. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes:
RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
Yes. This is called fixing bugs. We (OS maintainers) reserve that
right. If you need something more predictable, please maintain your
own code.
Yes. And it breaks, and we have a complainant.
So create a new function! Or use a different function to
generate or initialize the seed. I think one has to treat a
behavior bug very carefully. If enough people are depending
on it, it pretty much has to get enshrined as part of the
spec -- sort of like the timeout arg to select().
The documented behaviour is rand(3)/random(3). No guarantee
of lifelong repeatability is provided.
Would you prefer that we defined random() as
int
random(void)
{
static int retval = 0;
return retval++;
}
and worked on statistical randomness somewhere else?
The random() function in libc is documented to give the same
pseudo-random output for a particular seed. If you link your
program against a _different_ libc, you cannot expect your
results to follow a particular number sequence.
There is an expectation that on subsequent releases of the
same OS things continue to work.
Where is that expectation guaranteed?
Where is that expectation supported?
Historically rand() and random() under unix have been used
the most for simulation. [aside: Earl T. Cohen (the author
of random(3)) also has had a lot to do in this area]
Why not totally separate all uses of crypto related random
number generator uses from the traditional simulation use?
That way you can change crypto_random to your heart's content
as the crypto needs change (as they will).
The two are related topics.
Consider the (joking reference to) elephant-free biology. :-)
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: Yes, *I* can do it but I don't work at every place they do simulation! If in the extreme you are suggesting that a portable application shouldn't rely on any OS features, you are of course right but that kind of makes mockery of any claims of compatibility. The point of compatibility is to not break interfaces unless there is a significant benefit. We are not proposing interface breaks. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: Note that it is rand() that is broken, not random() as can be seen by modifying Kris Kennaways' test so I don't see why Mark Murray was talking about changing it in the first place. rand(3) says: STANDARDS The rand() and srand() functions conform to ISO/IEC 9899:1990 (``ISO C89''). rand(3) does not specify an exact algorithm (the man page does, but not the standard). random(3) has no such standardisation. Any code that assumes particular constants is _broken_[1]. If it has been recompiled or if it is dynamically linked against a shared library other than the one it was tested aginst, different results are a _feature_. M [1] no nitpicking on INT_MAX, please. -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: random(3) also provides an initstate() call which presumably allows you to change the amount of randomnes. So here is another suggestion: why not fold your algorithm change in that function? For example, initstate(seed, RC4, 3); changes the algorithm to RC4. Yes, this is a change in the interface but one I am sure most people can live with. No. Evil interface change. #ifdef hell while programs try to figure out OS differences. If an os provides a function, that function should be as good as possible while not breaking standards. We have lousy functions like gets(3), that we have to keep because the standards say we do and programmers keep on writing code that uses them. rand() and random() have a docimented interface, and empirical programmer expectations about their outputs simply result in bad code. There is an expectation that on subsequent releases of the same OS things continue to work. Where is that expectation guaranteed? Where is that expectation supported? This expectation is a reasonable one. Most commerical OSes do a good job of maintaining compatibility. IRIX certainly did a pretty good job of it. FreeBSD also does a pretty good job on the whole. Reasonable is an opinion. It is not shared by me. :-) Irix was well known for its bugs. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: Since you keep talking about random(), I must conclude you're knee-jerking, since we're not discussing that function. Please stay on-topic :-) Read through the thread. In particular see Mark's message [EMAIL PROTECTED] where he says Good point. We can re-implement random() internally with arc4rand(). Quote it in context, please. That was random(9). KERNEL random(). However, the argument applies equally well to rand(3) and random(3). M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Bakul Shah writes: No. Evil interface change. #ifdef hell while programs try to figure out OS differences. How so? This or a similar change is upward compatible in that the existing behavior is left unchanged and it gives you a way to replace the algorithm. It requies that programmers know about evil localisms. It screws over portability of source code. The basic issue is just what is the expected and (implicitly) promised behavior of random(). You believe one implied output. Another programmer believes another. Only way out is to make the routine honest. AFAIK all random(3) implementations in various versions of Unix come from Earl's original 4.2BSD implementation so in my view the _expected_ behavior is to see the _exact_ same sequence starting from a given seed. This function is called random() but it is equivalent to a mathematical function which must provide the same sequence for the exact same input. Maybe that is the greatgrandfather. The grandchildren speak with different accents now. :-) You and a number of other people are saying that the exact sequence is *not* promised so you are free to change the algortithm as long as the statistical distribution is uniform. Not quite. Close. You compile program on a machine with a constant argument to srand[om](). Run the more than once, and rand[om]() will give you the same sequence. Another OS, another time, another version of libc, the sequence will again be constant, but different from last time. Earl chose to name his new implementation random() [even though clearly he was replacing rand(3)] probably to not break any existing scripts. In my view any further behavior change should either use a new name or make an upward compatible change. You have said that before, and I understand your words. I disagree with them. Now the question is whether perl uses system provided random() or rand() or its own since perl is used extensively in ASIC verification. Different question. Ask the perl developers. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote: That was random(9). KERNEL random(). KERNEL random() can be easily implemented (better - replaced) with arc4random(), there is no objections. But... 1) Implementing random(3) with RC4 is not needed, its algorithm is already equal or better. Rubbish. :-) RC4's internal state is 256 bytes. In theory, its cycle-of-repetition is 2^(8*256) bits. The current library PRNGs are quite a bit less than that. 2) Implementing rand(3) with RC4 can be possible only if seed (i.e. state) can be stored in single word (due to rand_r()) restrictions. This is true. Sort of. But in this case, things get less easy. Hmm. I need to look at this some more. Thanks! M M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote: 1) Implementing random(3) with RC4 is not needed, its algorithm is already equal or better. Rubbish. :-) RC4's internal state is 256 bytes. In theory, its cycle-of-repetition is 2^(8*256) bits. This is comparable with random() TYPE4 which internal state is 252 bytes. I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise. Its not obvious how it works. RC4 is 10-20 lines and clean with no magic numbers. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote: I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise. Its not obvious how it works. RC4 is 10-20 lines and clean with no magic numbers. That's why randomness tests + mathematician to interpretate their results are needed to compare what we have now in random(3) with RC4. Easy and understandable code not always mean better results. We can't switch algorithms blindly, i.e. when their comparative quality remains unknown. Actually, RC4 is well understood (and trusted). LCRNG's are considered less good in comparison with cryptographic techniques. There is too much to go wrong in them (as you have just discovered!) :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Style fixups for proc.h
Hi OK to commit the style fixups below? (They just make sure that all function prototypes have all arguments named, and that all names are protected). int foo(int bar); becomes int foo(int _bar); M Index: proc.h === RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.291 diff -u -d -r1.291 proc.h @@ -860,101 +860,101 @@ extern int lastpid; -struct proc *pfind(pid_t); /* Find process by id. */ -struct pgrp *pgfind(pid_t);/* Find process group by id. */ -struct proc *zpfind(pid_t);/* Find zombie process by id. */ +struct proc *pfind(pid_t _pid);/* Find process by id. */ +struct pgrp *pgfind(pid_t _pid); /* Find process group by id. */ +struct proc *zpfind(pid_t _pid); /* Find zombie process by id. */ -void adjustrunqueue(struct thread *, int newpri); -void ast(struct trapframe *framep); +void adjustrunqueue(struct thread *_td, int _newpri); +void ast(struct trapframe *_framep); struct thread *choosethread(void); -intcr_cansignal(struct ucred *cred, struct proc *proc, int signum); -intenterpgrp(struct proc *p, pid_t pgid, struct pgrp *pgrp, struct session *sess); -intenterthispgrp(struct proc *p, struct pgrp *pgrp); -void faultin(struct proc *p); -void fixjobc(struct proc *p, struct pgrp *pgrp, int entering); -intfork1(struct thread *, int, int, struct proc **); -void fork_exit(void (*)(void *, struct trapframe *), void *, - struct trapframe *); -void fork_return(struct thread *, struct trapframe *); -intinferior(struct proc *p); -intleavepgrp(struct proc *p); +intcr_cansignal(struct ucred *_cred, struct proc *_p, int _signum); +intenterpgrp(struct proc *_p, pid_t _pgid, struct pgrp *pgrp, struct session +*_sess); +intenterthispgrp(struct proc *_p, struct pgrp *_pgrp); +void faultin(struct proc *_p); +void fixjobc(struct proc *_p, struct pgrp *_pgrp, int _entering); +intfork1(struct thread *_td, int, int, struct proc **_p); +void fork_exit(void (*_func)(void *_ptr, struct trapframe *_tf), void *_ptr, + struct trapframe *_tf); +void fork_return(struct thread *_td, struct trapframe *_tf); +intinferior(struct proc *_p); +intleavepgrp(struct proc *_p); void mi_switch(void); -intp_candebug(struct thread *td, struct proc *p); -intp_cansee(struct thread *td, struct proc *p); -intp_cansched(struct thread *td, struct proc *p); -intp_cansignal(struct thread *td, struct proc *p, int signum); -struct pargs *pargs_alloc(int len); -void pargs_drop(struct pargs *pa); -void pargs_free(struct pargs *pa); -void pargs_hold(struct pargs *pa); +intp_candebug(struct thread *_td, struct proc *_p); +intp_cansee(struct thread *_td, struct proc *_p); +intp_cansched(struct thread *_td, struct proc *_p); +intp_cansignal(struct thread *_td, struct proc *_p, int _signum); +struct pargs *pargs_alloc(int _len); +void pargs_drop(struct pargs *_pa); +void pargs_free(struct pargs *_pa); +void pargs_hold(struct pargs *_pa); void procinit(void); void threadinit(void); -void proc_linkup(struct proc *p, struct ksegrp *kg, - struct kse *ke, struct thread *td); -void proc_reparent(struct proc *child, struct proc *newparent); -intsecurelevel_ge(struct ucred *cr, int level); +void proc_linkup(struct proc *_p, struct ksegrp *_kg, + struct kse *_ke, struct thread *_td); +void proc_reparent(struct proc *_child, struct proc *_newparent); +intsecurelevel_ge(struct ucred *_cr, int _level); intsecurelevel_gt(struct ucred *cr, int level); -void setrunnable(struct thread *); -void setrunqueue(struct thread *); -void setsugid(struct proc *p); +void setrunnable(struct thread *_td); +void setrunqueue(struct thread *_td); +void setsugid(struct proc *_p); void sleepinit(void); -void stopevent(struct proc *, u_int, u_int); +void stopevent(struct proc *_p, u_int _arg1, u_int _arg2); void cpu_idle(void); void cpu_switch(void); void cpu_throw(void) __dead2; -void unsleep(struct thread *); -void userret(struct thread *, struct trapframe *, u_int); +void unsleep(struct thread *_td); +void userret(struct thread *_td, struct trapframe *_tf, u_int _arg); -void cpu_exit(struct thread *); -void cpu_sched_exit(struct thread *); -void exit1(struct thread *, int) __dead2; -void cpu_fork(struct thread *, struct proc *, struct thread *, int); -void cpu_set_fork_handler(struct thread *, void (*)(void *), void *); -void cpu_wait(struct proc *); +void cpu_exit(struct thread *_td); +void cpu_sched_exit(struct thread *_td); +void exit1(struct thread *_td, int _ret) __dead2; +void cpu_fork(struct thread *_td1, struct proc *_p, struct thread *_td2, int _ret); +void cpu_set_fork_handler(struct thread *_td, void (*_pfunc)(void *_arg), void +*_ptr); +void cpu_wait(struct proc *_p); /* New in KSE. */ struct ksegrp
Re: Style fixups for proc.h
Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global namespace. 2 ways to fix this are to protect the prototype argument names with the _, or to remove the argument name altogether. proc.h has no clear guidance, in that recent commits don't stick to the established style of the file. Some newish prototypes have a mixture of named/unnamed args in the same function. While I was making all prototypes' args named, I protected them. I'd like to fix the warnings, and I'd like the file to be consistent WRT argument naming. It's certainly not part of style(9) that I've ever noticed and it's generally noy done that way.. is there a move to do this on all the other files? There is a move to fix lint(1) warnings. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
