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
m
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"
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"
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"
[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
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]"
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 -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: 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]"
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: 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: > > 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]"
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: > 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: 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: > > 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: 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]"
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=0x1 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: 21 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 eisab0: 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: 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]
: /home/ncvs/src/usr.bin/telnet/Makefile,v
> retrieving revision 1.23
> diff -u -r1.23 Makefile
> --- usr.bin/telnet/Makefile 20 Jul 2003 23:29:46 - 1.23
> +++ usr.bin/telnet/Makefile 22 Jul 2003 11:41:02 -
> @@ -20,25 +20,26 @@
> DPADD=3D ${LIBTERMCAP} ${LIBTELNET}
> LDADD=3D -ltermcap ${LIBTELNET}
> =20
> -.if !defined(RELEASE_CRUNCH)
> -CFLAGS+=3D -DINET6 -DIPSEC
> -DPADD+=3D${LIBIPSEC}
> -LDADD+=3D-lipsec
> -.else
> +.if defined(RELEASE_CRUNCH)
> .PATH: ${TELNETDIR}/libtelnet
> SRCS+=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: 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: [-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: ``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: Broken ep0
Maxime Henrion writes: > > Can you have a look at this please? > > > > The symptoms are an ep0 that works for a few packets and then > > completely stops working. It doesn't respond to pings, nothing. > > I think you and/or Warner got mistaken. My last round of changes > to if_ep.c _fixed_ some race conditions that previously weren't a > problem, but became a problem once Warner flag'd the pccbb interrupts > INTR_MPSAFE. It's very possible that there are other problems left > in the ep(4) driver, but I highly doubt my changes to if_ep.c are the > culprit. I'm sorry but I can't do anything for you since I don't > even have ep(4) hardware here ; I was able to fix the race conditions > mentioned above because people reported panics with stacktrace that > made the problem obvious. OK - problem. I have a broken driver, with a dodgy patch to "fix" it, and you guys are both saying "not my problem". I'm quite happy to make it my problem, but I'll need a bit of help, please. Who is it going to be? 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]"
Broken ep0
Hi Since your last round of changes to if_ep.c (up to 1.117), the pccard ep0 on my ToPIC97 based laptop is broken. I've chatted to Warner about this, and I have a local hack where I back out a fix of his, and this allows the ep0 device to work (I think he said there was a race condition in the interrupts). Can you have a look at this please? The symptoms are an ep0 that works for a few packets and then completely stops working. It doesn't respond to pings, nothing. 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.
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.
"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]"
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]"
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]"
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: 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]"
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: 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: 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: 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: > 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]"
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]"
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: > 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: > 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: > 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: 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: > 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: 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: PATCH: type errors in src-tree
Dag-Erling Smorgrav writes: > Jens Rehsack <[EMAIL PROTECTED]> writes: > > Of course. Very often in ilmid.c the type caddr_t was used, and nearly > > the same count of 'const char *'s was used. I've searched the include > > files for caddr_t (core address) and found it defined as 'char *', so > > I decided to used commonly caddr_t - maybe later I check which of them > > could be changed into 'c_caddr_t' for being const. But You can of > > couse replace all 'caddr_t' which 'char *'. > > This is wrong. caddr_t should be uniersally replaced with void *. I'm currently doing this for kicks (Well, actually because it kills a botload of warnings, lint and otherwise). Once make world is working again, I'll put up a patch. My approach is to typedef caddr_t to void*, and then fix the errors this causes. So far, they are all no-brainers; mainly function prototypes that are inconsistent with their definitions. There are a few places where caddr_t is assumed to point to char. 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
"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: 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
"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
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: 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: 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: 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
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 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
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
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: > 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: > 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: > 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:
> > 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
David Malone writes: > On Sun, Feb 02, 2003 at 07:08:47PM +0000, 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: > 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
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
[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
[EMAIL PROTECTED] writes: > RC4 can be implemented in about 4 lines of C. Yah. If you like writing obfuscated C! > Anyway, last time we discussed this, I think we stuck with the rand() > we had because we feared that people were using it's repeatable well > documented sequence of random numbers in regression testing. I guess those arguments are now moot? > This is still a valid concern, but I don't know how significant a > concern it is. "Insignificant", IMO. 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 19:32:50 +0100, [EMAIL PROTECTED] wrote: > > > Anyway, last time we discussed this, I think we stuck with the > > rand() we had because we feared that people were using it's > > repeatable well documented sequence of random numbers in regression > > testing. > > As documented, it must be repeatable across the calls for same seed, > that is all. It not means repeatable accross platforms or across > different OS versions. In fact it is already not repeatable across > different OS'es, so regression is limited. Also, regression must not > stop bugs fixing progress in anycase. Given a particular seed, it is repeatable across anything that can compile C. 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) 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
"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 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
