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: newfs silently fails if random is not ready (?)
Nice catch! Thanks :-)
M
> On 5 Sep 2018, at 04:13, Conrad Meyer wrote:
>
> Hi Lev,
>
> I took a first attempt at reproducing this problem on a fast
> desktop-class system. First steps, give us a way to revert back to
> unseeded status:
>
> --- a/sys/dev/random/fortuna.c
> +++ b/sys/dev/random/fortuna.c
> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>
> #ifdef _KERNEL
> #include
> +#include
> #include
> #include
> #include
> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>return;
>}
>
> + /*
> +* When set, pretend we do not have enough entropy to reseed yet.
> +*/
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
> + if (RETURN_VALUE != 0) {
> + RANDOM_RESEED_UNLOCK();
> + return;
> + }
> + });
> +
> +
> #ifdef _KERNEL
>fortuna_state.fs_lasttime = now;
> #endif
> @@ -442,5 +454,11 @@ bool
> random_fortuna_seeded(void)
> {
>
> + /* When set, act as if we are not seeded. */
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
> + if (RETURN_VALUE != 0)
> + fortuna_state.fs_counter = UINT128_ZERO;
> + });
> +
>return (!uint128_is_zero(fortuna_state.fs_counter));
> }
>
>
> Second step, enable the failpoints and launch repro program:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
> debug.fail_point.random_fortuna_pre_read: off -> return(1)
> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
> debug.fail_point.random_fortuna_seeded: off -> return(1)
>
> $ cat ./blocked_random_poc.c
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
>printf("%x\n", arc4random());
>return (0);
> }
>
>
> $ ./blocked_random_poc
> ...
>
>
> Third step, I looked at what that process was doing:
>
> Curiously, it is not in getrandom() at all, but instead the ARND
> sysctl fallback. I probably need to rebuild world (libc) to test this
> (new libc arc4random based on Chacha).
>
> $ procstat -kk 1196
> PIDTID COMMTDNAME KSTACK
> 1196 100435 blocked_random_poc - read_random+0x3d
> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
> amd64_syscall+0x940 fast_syscall_common+0x101
>
>
> When I unblocked the failpoints, it completed successfully:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
> debug.fail_point.random_fortuna_pre_read: return(1) -> off
> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
> debug.fail_point.random_fortuna_seeded: return(1) -> off
>
> ...
> 9e5eb30f
>
>
> Best,
> Conrad
> ___
> 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"
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: em broken on current amd64
> On 13 Sep 2015, at 16:45, Sean Bruno wrote: > Any chance you can turn TSO off if its on and see what your results are? Only TSO4 was on. I turned it off; no difference. M -- Mark R V Murray ___ 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"
Re: em broken on current amd64
> On 8 Sep 2015, at 19:02, Mark R V Murray wrote: > > >> On 8 Sep 2015, at 17:22, Sean Bruno wrote: >> >> >>>>> >>>>> I’m also seeing breakage with the em0 device; this isn’t a kernel >>>>> hang, it is a failure to move data after about 10-15 minutes. The >>>>> symptom is that my WAN ethernet no longer moves traffic, no pings, >>>>> nothing. Booting looks normal: >>>>> >>>>> em0: port >>>>> 0x30c0-0x30df mem 0x5030-0x5031,0x50324000-0x50324fff irq >>>>> 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet >>>>> address: 00:16:76:d3:e1:5b em0: netmap queues/slots: TX 1/1024, RX >>>>> 1/1024 >>>>> >>>>> Fixing it is as easy as … >>>>> >>>>> # ifconfig em0 down ; service ipfw restart ; ifconfig em0 up >>>>> >>>>> :-) >>>>> >>>>> I’m running CURRENT, r287538. This last worked of me a month or so >>>>> ago at my previous build. >>>>> >>>>> M >>>>> >>>> >>>> >>>> Just so I'm clear, the original problem reported was a failure to >>>> attach (you were among several folks reporting breakage). Is that fixed >>>> ? >>> >>> I did not report the failure to attach, and I am not seeing it as I don’t >>> think I built a kernel that had that particular failure. I am having the >>> “failure after 10-15 minutes” problem; this is on an em0 device. >>> >>> M >>> >> >> >> Hrm, that's odd. That sounds like a hole where interrupts aren't being >> reset for "reasons" that I cannot fathom. >> >> What hardware (pciconf -lv) does your system actually have? The em(4) >> driver doesn't identify components which is frustrating. > > pciconf -lv output below: > > hostb0@pci0:0:0:0:class=0x06 card=0x514d8086 chip=0x29a08086 rev=0x02 > hdr=0x00 >vendor = 'Intel Corporation' >device = '82P965/G965 Memory Controller Hub' >class = bridge >subclass = HOST-PCI I just caught this, on today’s build: em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 -- em0: hw tdh = 127, hw tdt = 139 em0: Tx Queue Status = -2147483648 em0: TX descriptors avail = 1012 em0: Tx Descriptors avail failure = 0 em0: RX Queue 0 -- em0: hw rdh = 0, hw rdt = 1023 em0: RX discarded packets = 0 em0: RX Next to Check = 0 em0: RX Next to Refresh = 1023 [graveyard] /usr/ports 09:42 pm # uname -a FreeBSD graveyard.grondar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287705: Sat Sep 12 15:07:54 BST 2015 r...@graveyard.grondar.org:/b/obj/usr/src/sys/G_AMD64_GATE amd64 M -- Mark R V Murray ___ 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"
Re: em broken on current amd64
chip=0x28478086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCI Express Port 5' class = bridge subclass = PCI-PCI uhci2@pci0:0:29:0: class=0x0c0300 card=0x514d8086 chip=0x28308086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI Controller' class = serial bus subclass = USB uhci3@pci0:0:29:1: class=0x0c0300 card=0x514d8086 chip=0x28318086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI Controller' class = serial bus subclass = USB uhci4@pci0:0:29:2: class=0x0c0300 card=0x514d8086 chip=0x28328086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI Controller' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x514d8086 chip=0x28368086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB2 EHCI Controller' class = serial bus subclass = USB pcib6@pci0:0:30:0: class=0x060401 card=0x514d8086 chip=0x244e8086 rev=0xf2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x514d8086 chip=0x28108086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801HB/HR (ICH8/R) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci1@pci0:0:31:2:class=0x01018f card=0x514d8086 chip=0x28208086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) 4 port SATA Controller [IDE mode]' class = mass storage subclass = ATA ichsmb0@pci0:0:31:3:class=0x0c0500 card=0x514d8086 chip=0x283e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus atapci2@pci0:0:31:5:class=0x010185 card=0x514d8086 chip=0x28258086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801HR/HO/HH (ICH8R/DO/DH) 2 port SATA Controller [IDE mode]' class = mass storage subclass = ATA atapci0@pci0:2:0:0: class=0x01018f card=0x610111ab chip=0x610111ab rev=0xb1 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88SE6101/6102 single-port PATA133 interface' class = mass storage subclass = ATA dc0@pci0:6:0:0: class=0x02 card=0xf0041385 chip=0x000211ad rev=0x20 hdr=0x00 vendor = 'Lite-On Communications Inc' device = 'LNE100TX' class = network subclass = ethernet sym0@pci0:6:1:0:class=0x01 card=0x80001092 chip=0x008f1000 rev=0x04 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = '53c875J' class = mass storage subclass = SCSI none1@pci0:6:3:0: class=0x0c0010 card=0x514d8086 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments' device = 'TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]' class = serial bus subclass = FireWire M -- Mark R V Murray ___ 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"
Re: em broken on current amd64
> On 8 Sep 2015, at 00:44, Sean Bruno wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > On 09/07/15 14:10, Mark R V Murray wrote: >> >>> On 5 Sep 2015, at 17:11, Garrett Cooper >>> wrote: >>> >>> >>>> On Sep 5, 2015, at 08:50, Manfred Antar wrote: >>>> >>>> Recent changes to em have broken current on amd64. Booting >>>> kernel will hang when trying to load em0, then will continue >>>> booting without the driver loading (No Network) This is on a HP >>>> SFF 8000 with em0 embedded on the motherboard. >>>> >>>> boot messages: >>>> >>>> em0: port >>>> 0x3100-0x311f mem 0xf310-0xf311,0xf3125000-0xf3125fff >>>> irq 19 at device 25.0 on pci0 em0: attempting to allocate 1 MSI >>>> vectors (1 supported) em0: using IRQ 265 for MSI em0: Using an >>>> MSI interrupt em0: The EEPROM Checksum Is Not Valid >>>> device_attach: em0 attach returned 5 >>> >>> Tijl said the same. The offending commit's r287467. Cheers, >> >> I’m also seeing breakage with the em0 device; this isn’t a kernel >> hang, it is a failure to move data after about 10-15 minutes. The >> symptom is that my WAN ethernet no longer moves traffic, no pings, >> nothing. Booting looks normal: >> >> em0: port >> 0x30c0-0x30df mem 0x5030-0x5031,0x50324000-0x50324fff irq >> 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet >> address: 00:16:76:d3:e1:5b em0: netmap queues/slots: TX 1/1024, RX >> 1/1024 >> >> Fixing it is as easy as … >> >> # ifconfig em0 down ; service ipfw restart ; ifconfig em0 up >> >> :-) >> >> I’m running CURRENT, r287538. This last worked of me a month or so >> ago at my previous build. >> >> M >> > > > Just so I'm clear, the original problem reported was a failure to > attach (you were among several folks reporting breakage). Is that fixed > ? I did not report the failure to attach, and I am not seeing it as I don’t think I built a kernel that had that particular failure. I am having the “failure after 10-15 minutes” problem; this is on an em0 device. M -- Mark R V Murray ___ 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"
Re: em broken on current amd64
> On 5 Sep 2015, at 17:11, Garrett Cooper wrote: > > >> On Sep 5, 2015, at 08:50, Manfred Antar wrote: >> >> Recent changes to em have broken current on amd64. >> Booting kernel will hang when trying to load em0, then will continue booting >> without the driver loading (No Network) >> This is on a HP SFF 8000 with em0 embedded on the motherboard. >> >> boot messages: >> >> em0: port 0x3100-0x311f mem >> 0xf310-0xf311,0xf3125000-0xf3125fff irq 19 at device 25.0 on pci0 >> em0: attempting to allocate 1 MSI vectors (1 supported) >> em0: using IRQ 265 for MSI >> em0: Using an MSI interrupt >> em0: The EEPROM Checksum Is Not Valid >> device_attach: em0 attach returned 5 > > Tijl said the same. The offending commit's r287467. > Cheers, I’m also seeing breakage with the em0 device; this isn’t a kernel hang, it is a failure to move data after about 10-15 minutes. The symptom is that my WAN ethernet no longer moves traffic, no pings, nothing. Booting looks normal: em0: port 0x30c0-0x30df mem 0x5030-0x5031,0x50324000-0x50324fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:16:76:d3:e1:5b em0: netmap queues/slots: TX 1/1024, RX 1/1024 Fixing it is as easy as … # ifconfig em0 down ; service ipfw restart ; ifconfig em0 up :-) I’m running CURRENT, r287538. This last worked of me a month or so ago at my previous build. M -- Mark R V Murray ___ 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"
Re: Device random seems broken.
> On 22 Aug 2015, at 13:49, Mark R V Murray wrote: > > >> On 22 Aug 2015, at 06:03, Steve Kargl >> wrote: >> >> >> Please fix. > > On its way. Fixed. A git commit was in the wrong review (D3197 instead of D3354). This is now committed as svn commit r287023. M -- Mark R V Murray ___ 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"
Re: Device random seems broken.
> On 22 Aug 2015, at 06:03, Steve Kargl > wrote: > > > Please fix. On its way. M -- Mark R V Murray ___ 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"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 18:51, Steve Kargl > wrote: > >> >> I?m sorry my commit caused the problem. >> > > Nothing to be sorry about. This is -current after all. Thanks :-) >> I?m also trying to find out why, but I don?t know enough about USB or >> mass-storage devices to know why, so this may take me a while. In the >> meanwhile, I?ll try to help by pointing out things I do know. > > Yes, I did the bisection to find that r273872 exposes the problem. > What I don't know is if this is hardware specific to a Dell Latitude > D530 laptop, USB specific, or some weird interaction between the > random and USB. > > What I also find odd is that I seem to be the only person seeing > this behavior when it is trivial for me to reproduce: boot laptop, > plug in usb device, wait usb recognizes the device, then unplug > the device. Strange for me too. I’m not exactly being bombarded with bug reports. > If you have not read the entire thread, once the laptop keyboard and > video output lock up, I can ssh into the laptop. If I run usbconfig, > it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices > have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? M -- Mark R V Murray ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 18:31, Ian Lepore wrote: > > The point I'm trying to make here is that you trimmed away the important > part of the prior messages and replied only to the part where Steve's > debugging efforts were somewhat speculating. The non-speculative part > was where he bisected the failure to an exact commit: > >>>> The problem is caused >>>> by r273872. This is the recent random device patch. I have no >>>> idea why removing a usb device would cause the system to lock >>>> up other than random is probably trying to harvest some entropy. I’m sorry my commit caused the problem. I’m also trying to find out why, but I don’t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I’ll try to help by pointing out things I do know. M -- Mark R V Murray ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 18:21, Ian Lepore wrote: > > On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: >>> On 16 Nov 2014, at 17:51, Steve Kargl >>> wrote: >>> >>> Is there a 'random: device_detach():' missing between the 'umass0' >>> and 'da0' messages in the last 4 lines. >> >> No. At attach time, the RNG grabs some probe entropy. At detach time it does >> nothing. >> >> M > > And yet... Steve has gathered evidence that the system bricks when a > device is detached with the new entropy-gathering code and doesn't do so > prior to that code. What else is the new code doing around detach time? Nothing, except possibly harvesting interrupt entropy. I’ll promise to be astonished if this is other-than-harmless. I’d be more suspicious of the harvester thread, but I still can’t see how its hurting :-( M -- Mark R V Murray ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
> On 16 Nov 2014, at 17:51, Steve Kargl > wrote: > > Is there a 'random: device_detach():' missing between the 'umass0' > and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M -- Mark R V Murray ___ 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"
Fwd: New /dev/random code for review please.
Hi Folks, Please could the wisdom-of-crowds apply its collective attention to this? Thanks! M Begin forwarded message: > From: Mark R V Murray > Subject: New /dev/random code for review please. > Date: 4 May 2014 18:28:43 BST > To: "sect...@freebsd.org Team" > Content-Type: multipart/signed; > boundary="Apple-Mail=_E0FAF9BA-F43A-41EC-ADF7-C7F66942DC33"; > protocol="application/pgp-signature"; micalg=pgp-sha512 > X-Smtp-Server: gromit.grondar.org:grondar > X-Universally-Unique-Identifier: 57DA4E05-F926-490F-811D-27C027A43800 > Message-Id: <64478e8f-ed98-43c2-99bc-167356d3e...@grondar.org> > Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) > > Hi guys > > I’m now about ready to start the job of merging the revamped /dev/random > gubbins over to CURRENT from a project branch. > > The project branch is > svn://svn.freebsd.org/base/projects/random_number_generator > > Not all of the above branch is to be merged right now; the UMA_ALLOC > harvester bit will NOT be merged. In follow-up discussions, I will work out > how to do this properly. Right now, that code works, but will no doubt piss > off RWatson and company for messing up the carefully optimised slab > allocator! :-) > > In the first merge, very little change should be observed. ‘sysctl > kern.random’ will look different as the harvesting has been slightly > generalised. Yarrow will still be used, but Fortuna will be available as an > alternative. Automatic startup due to probing entropy is tested and > more-or-less trusted (analysis of numbers to form part of a more academic > study). > > The code is much simplified, and use of overly complex data structures has > been rewritten. > > I request review and comments please, with a view to merging this to CURRENT. > > Thanks! > > M > -- > Mark R V Murray > -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH RFC] Disable save-entropy in jails
On 25 Dec 2013, at 02:04, Xin Li wrote: > No, we are not talking about removing /var/db/entropy. What I am > proposing to do is to disable entropy savings from jails. Here is why: > > The way a PRNG works is that it uses one or many entropy sources to > "feed" its internal state, and generate a series of pseudo-random > numbers from the internal state via a PRF. > > FreeBSD collects entropy from several sources: Ethernet, interrupts, > software interrupts, etc., as well as hardware RNG that is available > to the system, and use all these entropy to derive the internal state > of its PRNG. > > When reading from /dev/random, one essentially consumes entropy that > is fed into the random device, and eventually it would cause a reseed. > In an ideal world, we would want this to be less predicable and > controllable from a potential attacker. So far so good. :-) > Normal applications tends to read /dev/random in small bites, and do > so in a discrete and nearly random manner, assuming we have a lot of > processes running. Saving entropy, on the other hand, happen in > larger chunks at a determined time. With multiple jails running, one > would have a lot of big chunk reads from the /dev/random device, > making its behavior more deterministic, which could have bad consequences. I doubt it goes as far as “bad”, but it certainly does no good. I would support the notion of not caching entropy in jails IFF this didn’t leak out and prevent harvesting in the jail’s host AND this gave a noticeable simplification of script code. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Patch: Add option to fmt to ignore email reply lines
On 26 Nov 2013, at 12:10, Anthony Perkins wrote: > On Mon, Nov 25, 2013 at 09:58:12PM +, Mark Robert Vaughan Murray > wrote: >> >> You may want to extend your idea a bit and do what par (ports/textproc/par) >> does. This is a paragraph reformatter that takes the quoting into account, >> replacing it after the paragraph wrapping. > > I did consider doing this but decided against it on the basis that > the incoming mail from the previous sender was unpredictable. If > it included, for example, a list of a few short sentences or bullet > points these would all be combined into one long paragraph in the > reply. Not true. In fact par is rather good at preserving changing indent levels. Its not perfect, but its darn good. > If others also feel this would be desirable I will look at implementing > it with an updated patch. Yes please! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Patch: Add option to fmt to ignore email reply lines
On 25 Nov 2013, at 12:54, Anthony Perkins wrote: > I've added an option to 'fmt' to ignore lines beginning with the > greater-than symbol, so that whole email replies can be piped through > fmt (e.g. via vi from mutt) without needing to repeat the command > for each of my paragraphs. > > This is my first real patch, so I would appreciate any feedback. I’ve not tried your patch, but I like the idea. When using NMH, I like to use a paragraph reformatter before sending, and fmt(1) was terrible because (as you note) it can’t handle the reply quoting. You may want to extend your idea a bit and do what par (ports/textproc/par) does. This is a paragraph reformatter that takes the quoting into account, replacing it after the paragraph wrapping. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Anyone else seeing uma_zalloc_arg panics?
On 23 Nov 2013, at 10:24, Don Lewis wrote: > On 23 Nov, Mark Robert Vaughan Murray wrote: >> Hi * >> >> Anyone else seeing panics like this? >> >> This is CURRENT, amd64, 2 CPUs, source synced on Thursday 21st Nov evening >> GMT sometime. >> >> +panic: uma_zalloc_arg: Returning an empty bucket. >> +cpuid = 1 >> +KDB: stack backtrace: >> +db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe003c7dd820 >> +kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003c7dd8d0 >> +vpanic() at vpanic+0x126/frame 0xfe003c7dd910 >> +kassert_panic() at kassert_panic+0x136/frame 0xfe003c7dd980 >> +uma_zalloc_arg() at uma_zalloc_arg+0x49a/frame 0xfe003c7dd9f0 >> +bucket_alloc() at bucket_alloc+0x8b/frame 0xfe003c7dda10 >> +uma_zfree_arg() at uma_zfree_arg+0x2a1/frame 0xfe003c7dda70 >> +bucket_cache_drain() at bucket_cache_drain+0x1b/frame 0xfe003c7ddaa0 >> +zone_drain_wait() at zone_drain_wait+0xd1/frame 0xfe003c7ddb00 >> +uma_reclaim() at uma_reclaim+0x42d/frame 0xfe003c7ddb30 >> +vm_pageout() at vm_pageout+0x3bc/frame 0xfe003c7ddbb0 >> +fork_exit() at fork_exit+0x84/frame 0xfe003c7ddbf0 >> +fork_trampoline() at fork_trampoline+0xe/frame 0xfe003c7ddbf0 >> +--- trap 0, rip = 0, rsp = 0xfe003c7ddcb0, rbp = 0 --- >> +KDB: enter: panic >> >> M > > Yes, I got one of these a couple days ago: > <http://docs.freebsd.org/cgi/mid.cgi?201311212234.rALMY0bN009437> > > Just curious ... are you running i386 or amd64? My test machine is > i386, but I suspect that most people running head are running amd64. Er, amd64, as I said ;-) M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Anyone else seeing uma_zalloc_arg panics?
Hi * Anyone else seeing panics like this? This is CURRENT, amd64, 2 CPUs, source synced on Thursday 21st Nov evening GMT sometime. +panic: uma_zalloc_arg: Returning an empty bucket. +cpuid = 1 +KDB: stack backtrace: +db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe003c7dd820 +kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003c7dd8d0 +vpanic() at vpanic+0x126/frame 0xfe003c7dd910 +kassert_panic() at kassert_panic+0x136/frame 0xfe003c7dd980 +uma_zalloc_arg() at uma_zalloc_arg+0x49a/frame 0xfe003c7dd9f0 +bucket_alloc() at bucket_alloc+0x8b/frame 0xfe003c7dda10 +uma_zfree_arg() at uma_zfree_arg+0x2a1/frame 0xfe003c7dda70 +bucket_cache_drain() at bucket_cache_drain+0x1b/frame 0xfe003c7ddaa0 +zone_drain_wait() at zone_drain_wait+0xd1/frame 0xfe003c7ddb00 +uma_reclaim() at uma_reclaim+0x42d/frame 0xfe003c7ddb30 +vm_pageout() at vm_pageout+0x3bc/frame 0xfe003c7ddbb0 +fork_exit() at fork_exit+0x84/frame 0xfe003c7ddbf0 +fork_trampoline() at fork_trampoline+0xe/frame 0xfe003c7ddbf0 +--- trap 0, rip = 0, rsp = 0xfe003c7ddcb0, rbp = 0 --- +KDB: enter: panic M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Duplicated WITH_*/WITHOUT_* options
On 21 Nov 2013, at 12:11, Dimitry Andric wrote: > These duplicated settings are not oversights, just artifacts of how > bsd.own.mk works. The defaults are simply different for different > arches, e.g. WITH_CLANG is the default for x86, powerpc and LE arm, but > WITHOUT_CLANG is the default for other arches. Similar for the other > settings. That makes sense, thanks! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random_harvestq eats much on geode-lx alix2c3
On 20 Nov 2013, at 10:58, freebsdonline wrote: > Stanisław Halik wrote: >> but what do you ask for? Also, can text >> attachments be put here? For posterity's sake, better not to link to them. > It is poor hardware as you said but FreeBSD should run well on it. I also > have Alix boards running FreeBSD as router, and cpu load is almost 0. The entropy-harvesting stuff needs to be adaptable to slow and fast. On an old box, one which would work well as a small gateway/firewall, aggressive harvesting may (does!) slow down the OS. On a multiple-CPU grunt-grade server, that may not be enough, and we may be scrambling for more. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Duplicated WITH_*/WITHOUT_* options
Hi
I noticed we have some duplicated WITH_*/WITHOUT_* options; presumably this is
an oversight?
[graveyard] /usr/src/tools/build/options 08:37 am # for i in WITH_* ; do if [
-e WITHOUT_${i##WITH_} ] ; then echo WITHOUT_${i##WITH_} ${i} ; fi; done
WITHOUT_CLANG WITH_CLANG
WITHOUT_CLANG_FULL WITH_CLANG_FULL
WITHOUT_CLANG_IS_CC WITH_CLANG_IS_CC
WITHOUT_FDT WITH_FDT
WITHOUT_GCC WITH_GCC
WITHOUT_GNUCXX WITH_GNUCXX
WITHOUT_LIBCPLUSPLUS WITH_LIBCPLUSPLUS
WITHOUT_NAND WITH_NAND
WITHOUT_TESTS WITH_TESTS
As its not all that obvious which one “wins”, can this be cleaned up? I don’t
mind doing the work if there is a somewhat foolproof way of doing so.
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: random_harvestq eats much on geode-lx alix2c3
On 19 Nov 2013, at 00:22, Stanisław Halik wrote: > Hey, > > random_harvestq eats much, much CPU on alix2c3: > > CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class CPU) > glxsb0: mem > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > > Could you please add a sysctl/loader knob for it, or a way to throttle > collection? > > Here's top output: > > 14 root 1 -16- 0K 8K -6:12 15.97% rand_harvestq Take a look at random(4) - sysctls to turn off harvesting are documented there. That is quite a busy harvestq - could you please give me some more details of what that box is and what it was doing at the time (numbers would be good!) Thanks! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: HW fed /dev/random
On 10 Sep 2013, at 19:13, Harald Schmalzbauer wrote: > Hello, > > some time ago, before random(4) was rewritten for FreeBSD 5 by Mark > Murray, we had rng, the i815 hardware random number generator. > At this time, there were rumors about the quality of the randomness. > > Now we have rdrand (BullMountain hardware random generator in IvyBridge) > and Dual_EC_DRBG (NSA's NIST contribution) makes me wonder if quality is > again something to worry about - although kib's commit message states: > „From the Intel whitepapers and articles about Bull Mountain, it seems > that we do not need to perform post-processing of RDRAND results, like > AES-encryption of the data with random IV and keys, which was done for > Padlock. Intel claims that sanitization is performed in hardware.“ > > When we use the software random device, one has great control over > /dev/random with sysctk kern.random. > Are there considerations to extend the HW-rng-implementation by optional > post processing? Yes. This was discussed in Cambridge recently, and will no doubt be brought up again in Malta. There are indeed plans to post-process the output of rdrand. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 18:31, Glen Barber wrote: > On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: >> Glen Barber writes: >>> The correct workaround (which now I see I should have done before >>> locking head/) is to revert this commit so it can be properly fixed. >> >> Glen, to be fair, the mips boot fails because they're trying to use a >> device before it's ready. > > To be clear, when I sent my last emails, tinderbox was complaining about > build failures (which it did not catch up to the recent head/ > revisions), so at the time I thought head/ was still broken for > arm and mips architectures. > > Sorry for the misunderstanding on my part. delphij corrected me on > this. No worries, thanks! Keep up the good work! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:31, Glen Barber wrote: > On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: >> ok. So I can work around this for these MIPS AP images by echoing something >> into /dev/random ? >> > > The correct workaround (which now I see I should have done before > locking head/) is to revert this commit so it can be properly fixed. > > Calling "echo '' >/dev/random" the "KNOB" is insulting. Using a write to /dev/random as a reseed was there from day one (check random(4)), and while it is not the clearest thing on the planet that a reseed unblocks the device, that has always been there by intent. That is how etc/rc.d/initrandom is supposed to work. In checking the man page I've released that connection needs to be clarified. I've (re)set the "seeded" bit, so behaviour is as it was. I'll look for a way to set this bit from the kernel config file. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:36, Glen Barber wrote: > Either way, I think this commit needs to be reverted until properly > fixed and tested. The hyperbole is getting a little thick. How about sysctl kern.random.sys.seeded=1 ?? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 22:31, Ian Lepore wrote: > Those of us who have to cope with limited systems will fix our config > for those systems; that part of it shouldn't be your problem beyond > providing us with a knob. If there is NO random number generator, then /dev/random blocks. Period. If you don't want to block, don't read /dev/random. If you have an RNG loaded (like Yarrow), the intent is that it will block-until-secure, but you can insta-unblock it by writing to it. The intent is that early in the boot, while running all the /etc/rc.d/* stuff, you write anything you like (hopefully random crud) to the device and it seeds itself with what it gets. At file close after the write, it unblocks. So at the minimum, you can unblock Yarrow by doing $ echo '' > /dev/random ... as soon as the device is active. There is your knob. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 21:38, Ian Lepore wrote: > I keep trying to say this, and I keep getting the feeling that it just > doesn't register with anyone I say it to, like I'm speaking some > language from another planet or something... Sorry. I haven't forgotten this. Right now, for 10.0, the intent is "Fix the bugs first". The all-singing variant is going to follow. > There may be NO entropy of any sort available on an embedded system, and > you cannot block the ability to boot and run such a system just because > you think it's a bad idea to run without sufficient randomness. It's > not your call to make -- it's a decision for the person using or > administering the system. True. But the current fix for this (AKA the status quo) means that things are broken for everyone, and I'm trying to get things "fixed by default" with some kind of workaround for the folks that need it, rather than the other way round. > You must provide a mechanism that disables the blocking behavior. The > mechanism must be either a kernel compile-time config knob (not all > platforms use loader(8) or anything else that can set a tunable var), or > something in the rc system that can unblock /dev/random before anything > else needs it. The latter implies that the kernel itself must not block > before getting to that point in rc processing, even if it needs random > numbers for something (like cooking up a temporary MAC address). Any kind of write to /dev/random (Yarrow) will unblock it. This may be a matter of scripting in /etc/rc.d/. Like "echo '' > /dev/random", and it just needs to happen early enough, i.e. before you do a blocking read. > It's okay to make it hard to do the wrong thing by accident. It's not > okay to make it impossible to do that thing on purpose. Again, true, but please bear in mind that things are suboptimal right now. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 21:42, Adrian Chadd wrote: > We discussed this at the dev summit. Mark asked what we'd like to do. > > Mark - would you mind terribly adding a kernel compile option that controls > that blocking default, so we can flip it on for the ARM/MIPS boards that > don't have a hardware PRNG to start seeding things with? This has some merit; but I need to thing about how to do it. Per-architecture block/no-block defaults are going to get messy unless done properly. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 20:12, Sean Bruno wrote: > On Sat, 2013-09-07 at 19:56 +0100, Mark R V Murray wrote: >>> Ok. Right now, the mips kernel doesn't build unless I have random >> built >>> in, we were using it as a module previously. >> >> >> I'm testing a fix, but if you want to help out, please move the >> random_null_func() >> from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. >> >> Thanks! >> >> M > > Closer: > > --- kernel.debug --- > linking kernel.debug > random_adaptors.o: In function `random_sysctl_active_adaptor_handler': > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): > undefined reference to `random_get_active_adaptor' > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): > relocation truncated to fit: R_MIPS_26 against > `random_get_active_adaptor' > *** [kernel.debug] Error code 1 Nearly there - I saw that too. Proposed fix enclosed. M -- Mark R V Murray rng_fix.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 19:49, Sean Bruno wrote: > On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: >>> Looks like it does indeed work if that is set to 1. >>> >>> This "DIR-825" config, should be loading random as a module, not >> built >>> into the kernel due to size limitations of the kernel on this board. >> >> Hmm. I'll set it back to 1, but this is technically a security issue. >> >> Thanks for the report back, and sorry for the hassles! >> >> M >> -- >> Mark R V Murray > > Ok. Right now, the mips kernel doesn't build unless I have random built > in, we were using it as a module previously. I'm testing a fix, but if you want to help out, please move the random_null_func() from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. Thanks! M -- Mark R V Murray rng_fix.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 19:36, Sean Bruno wrote: > On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: >> On 7 Sep 2013, at 17:43, Sean Bruno wrote: >>> trying to enable random on my DIR-825 kernconf I get this on boot: >>> >>> Configuration file: /etc/cfg/hostapd.wlan0.conf >>> Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" >>> Entropy device is blocking >> >> Please make a change to sys/dev/random/randomdev_soft.c; >> >> Around line 82, please change from ".seeded = 0" to ".seeded = 1". >> >> If that works, then your report above with the "Entropy device is blocking." >> is trying to read random numbers before /dev/random is secure; this is a BAD >> security problem. >> >> M > > > Looks like it does indeed work if that is set to 1. > > This "DIR-825" config, should be loading random as a module, not built > into the kernel due to size limitations of the kernel on this board. Hmm. I'll set it back to 1, but this is technically a security issue. Thanks for the report back, and sorry for the hassles! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 17:43, Sean Bruno wrote: > trying to enable random on my DIR-825 kernconf I get this on boot: > > Configuration file: /etc/cfg/hostapd.wlan0.conf > Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" > Entropy device is blocking Please make a change to sys/dev/random/randomdev_soft.c; Around line 82, please change from ".seeded = 0" to ".seeded = 1". If that works, then your report above with the "Entropy device is blocking." is trying to read random numbers before /dev/random is secure; this is a BAD security problem. M -- Mark R V Murray Entropy device is blocking signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 17:43, Sean Bruno wrote: > with "nodevice random" I can no longer compile for MIPS > --- kernel.debug --- > pseudo_rng.o:(.data+0x3c): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x44): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x74): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x78): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x84): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x8c): more undefined references to > `random_null_func' follow > random_adaptors.o: In function `random_sysctl_active_adaptor_handler': > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): > undefined reference to `random_get_active_adaptor' > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): > relocation truncated to fit: R_MIPS_26 against > `random_get_active_adaptor' This is easy enough to fix. Doing a build now. > trying to enable random on my DIR-825 kernconf I get this on boot: > > Configuration file: /etc/cfg/hostapd.wlan0.conf > Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" > Entropy device is blocking. Can you please see if you can get the output of "sysctl -a | grep random" at that point? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Can't update CLang-based system
onic without a size suffix mov r11d,258 ^ /tmp/cc-D1h2GI.s:310:9: error: unknown use of instruction mnemonic without a size suffix mov [ rcx + 160], r8d ^ /tmp/cc-D1h2GI.s:316:9: error: unknown use of instruction mnemonic without a size suffix mov eax, [ rcx + 164] ^ /tmp/cc-D1h2GI.s:317:9: error: unknown use of instruction mnemonic without a size suffix cmp r11d, eax ^ /tmp/cc-D1h2GI.s:318:9: error: unknown use of instruction mnemonic without a size suffix cmovng eax, r11d ^ /tmp/cc-D1h2GI.s:320:9: error: unknown use of instruction mnemonic without a size suffix mov rbx,[(rsp + 40 - 96)] ^ /tmp/cc-D1h2GI.s:321:9: error: unknown use of instruction mnemonic without a size suffix mov rbp,[(rsp + 48 - 96)] ^ /tmp/cc-D1h2GI.s:322:9: error: unknown use of instruction mnemonic without a size suffix mov r12,[(rsp + 56 - 96)] ^ /tmp/cc-D1h2GI.s:323:9: error: unknown use of instruction mnemonic without a size suffix mov r13,[(rsp + 64 - 96)] ^ /tmp/cc-D1h2GI.s:324:9: error: unknown use of instruction mnemonic without a size suffix mov r14,[(rsp + 72 - 96)] ^ /tmp/cc-D1h2GI.s:325:9: error: unknown use of instruction mnemonic without a size suffix mov r15,[(rsp + 80 - 96)] ^ /tmp/cc-D1h2GI.s:328:9: error: unknown use of instruction mnemonic without a size suffix ret 0 ^ /tmp/cc-D1h2GI.s:336:3: error: unknown use of instruction mnemonic without a size suffix ret 0 ^ *** Error code 1 Stop in /usr/src/lib/libz. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 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
"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
