[EMAIL PROTECTED] wrote:
> >su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
>
> Don't use the -L and -l arguments unless you have to.
Thanks, but that was what I originally tried, and I still got the
"gbde: ioctl(GEOMCONFIGGEOM): Invalid argument" error. In other words,
I get the same error
Sorry, I'm being forgetful: I'm getting these errors under
5.0-RELEASE.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men t
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>[EMAIL PROTECTED] wrote:
>
>> >su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
>>
>> Don't use the -L and -l arguments unless you have to.
>
> Thanks, but that was what I originally tried, and I still got the
>"gbde: ioctl(GEOMCONFIGGEOM):
[EMAIL PROTECTED] wrote:
> Can you please try this:
>
> mdconfig -a -t malloc -s 4m -u 75
> gbde init /dev/md75
> gbde attach md75
Nope, exact same error.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and d
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>[EMAIL PROTECTED] wrote:
>
>> Can you please try this:
>>
>> mdconfig -a -t malloc -s 4m -u 75
>> gbde init /dev/md75
>> gbde attach md75
>
> Nope, exact same error.
That is weird, it works like a charm here.
syv
On Sun, Feb 02, 2003 at 13:12:55 -0800, Doug Barton wrote:
>
> If I had to guess, I'd say that you're eager to fix the mistake you made,
> and I suppose that's commendable. However, it's been broken for two years,
> it can wait another couple days for a more thorough fix.
If you talk about 0 prob
On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote:
> On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
> > So far, this is final variant for 0 problem fixing ready for committing.
> > Any objections?
>
> What tests have you run on this code to ensure it doesn't still ha
> > another suggestion: why not fold your algorithm change in
> > that function? For example,
> >
> > initstate(seed, "RC4", 3);
> >
> > changes the algorithm to RC4. Yes, this is a change in the
> > interface but one I am sure most people can live with.
>
> No. Evil interface change. #ifd
[EMAIL PROTECTED] wrote:
> Say, do you actually have the GEOM_BDE option in your kernel ?
Sigh, no. I missed it in gbde(4).
You might want to further idiot-proof gbde(8) with code like:
err(1, "ioctl(GEOMCONFIGGEOM) (is \"options GEOM_BDE\" in the kernel?)");
Thanks for the hel
On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
>
> That was random(9). KERNEL random().
KERNEL random() can be easily implemented (better - replaced) with
arc4random(), there is no objections. But...
1) Implementing random(3) with RC4 is not needed, its algorithm is
already equal or
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>[EMAIL PROTECTED] wrote:
>
>> Say, do you actually have the GEOM_BDE option in your kernel ?
>
> Sigh, no. I missed it in gbde(4).
>
> You might want to further idiot-proof gbde(8) with code like:
>
>err(1, "ioctl(GEOMCONFIGGEOM) (is
Bakul Shah writes:
> > No. Evil interface change. #ifdef hell while programs try to
> > figure out OS differences.
>
> How so? This or a similar change is upward compatible in
> that the existing behavior is left unchanged and it gives you
> a way to replace the algorithm.
It requies that progra
On Mon, Feb 03, 2003 at 12:55:40AM +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote:
> > On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
> > > So far, this is final variant for 0 problem fixing ready for committing.
> > > Any objectio
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
> >
> > That was random(9). KERNEL random().
>
> KERNEL random() can be easily implemented (better - replaced) with
> arc4random(), there is no objections. But...
>
> 1) Implementing random(3) with RC4 is no
On Sun, Feb 02, 2003 at 14:21:02 -0800, Kris Kennaway wrote:
>
> If I understand correctly, this still doesn't solve the problem,
> because any PRNG sequence that hits the "magic" value will still get
> stuck there forever.
It was true for the first patch I post which just move problem to another
On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
> > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > already equal or better.
>
> Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> cycle-of-repetition is 2^(8*256) bits.
This is comparable with rand
On Sun, Feb 02, 2003 at 01:59:25PM -0800, Bakul Shah wrote:
>
> AFAIK all random(3) implementations in various versions of
> Unix come from Earl's original 4.2BSD implementation so in my
> view the _expected_ behavior is to see the _exact_ same
> sequence starting from a given seed. This function
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
>
> > > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > > already equal or better.
> >
> > Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> > cycle-of-repetition is 2^(
I'm getting double-faults on my laptop, and I have managed to capture
them in DDB because I roughly know when to expect them.
But It seems that the panic and DDB offers absolutely no helpful
information about a double-fault ?
How does one debug problems like this ?
--
Poul-Henning Kamp
On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
>
> I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> Its not obvious how it works.
>
> RC4 is 10-20 lines and clean with no magic numbers.
That's why randomness tests + mathematician to interpretate their res
Thus spake Bakul Shah <[EMAIL PROTECTED]>:
> > As I said, I don't know how big a concern this is. But last time
> > it was enough of a concern to make us keep rand() as it was.
>
> [I know you are talking about rand() but Mark Murray's
> earlier email about wanting to re-implement random() really
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
> >
> > I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> > Its not obvious how it works.
> >
> > RC4 is 10-20 lines and clean with no magic numbers.
>
> That's why randomness tes
On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> FreeBSD Redhat SunOS
> 660787754660787754645318364
FWIW - AIX aggrees with Solaris.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> Last 10 digits.
>
> FreeBSD Redhat SunOS
> 660787754660787754645318364
> 3275486913275486911583150371
> 2009993994 2009993994 715222008
> 1653966416 1653966416 1349166998
> 1074113008 1074113008 566227131
> 2142626740 2142626740 1382825076
> 15177758
[From address modified because I don't want every message in this
thread to end up in my personal mailbox. I'll read them in the
list, thank you very much.]
On Sun, Feb 02, 2003 at 09:23:43PM +, Mark Murray wrote:
> Bakul Shah writes:
> > > Since you keep talking about random(), I must conclu
Mark Murray wrote:
> "Jeroen C. van Gelderen" writes:
> > Wouldn't it be a good idea to change the name at the same time? Or
> > should it be retained for compatibility reasons with other BSDs?
> >
> > Currently the name needlessly exposes implementation detail. Callers
> > expect good, cheap, non-
Mark Murray wrote:
> "Andrey A. Chernov" writes:
> > > Objections?
> >
> > We can't, simple because sequence must be repeated for the same seed
> > across the calls.
>
> RC4 is repeatable.
I tried that, and it didn't repeat the sequence I got when I
previously used "rand()"... 8-) 8-).
-- Terry
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Oliver Brandmueller <[EMAIL PROTECTED]> writes:
> : fine. Any ideas?
>
> Thanks for the info! I've sent in a different message that I think
> will fix this problem. The problem is that /usr/local isn't mounted
> when devd st
Edward Brocklesby wrote:
> On Sunday 02 February 2003 6:48 pm, Bakul Shah wrote:
> > Guys, please realize that random() is also used in generating
> > simulation inputs (or timing or whatever). If you go change
> > the underlying algorithm or its parameters one can't generate
> > the same sequence
* De: David Malone <[EMAIL PROTECTED]> [ Data: 2003-02-02 ]
[ Subjecte: Re: rand() is broken ]
> On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> > FreeBSD Redhat SunOS
> > 660787754660787754645318364
>
> FWIW - AIX aggrees with Solaris.
Endiannes, or a
Mark Murray <[EMAIL PROTECTED]> wrote:
>
>3) int random(void) which returns a number statistically
> random in all bits.
>
>We have most of this, and RC4 can deliver. RC4's "licence" is
>fine. Call it "ArCFour" and there is no problem. The code is
>small, fast and repeatable, and meets conditions
On Sunday 02 February 2003 11:59 pm, Terry Lambert wrote:
> Edward Brocklesby wrote:
> > Maybe I missed something, but why cannot you just rip random() from libc,
> > rename it to bakul_shah_random() and use that in your testing code? Then
> > you are safe from any changes to random(), and indeed
On Sun, Feb 02, 2003 at 04:02:27PM -0800, Juli Mallett wrote:
> * De: David Malone <[EMAIL PROTECTED]> [ Data: 2003-02-02 ]
> [ Subjecte: Re: rand() is broken ]
> > On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> > > FreeBSD Redhat SunOS
> > > 6607877546607877
Mark Murray wrote:
> Bakul Shah writes:
> > random(3) also provides an initstate() call which presumably
> > allows you to change the amount of randomnes. So here is
> > another suggestion: why not fold your algorithm change in
> > that function? For example,
> >
> > initstate(seed, "RC4", 3)
> Interesting The SunOS output exactly matches random(3)
> behavior from 4.3BSD! In fact random() remained the same for
> 4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.
>
> 4.2BSD random() behavior is different from all of the above.
> There was real bug-fix between 4.2BSD and 4.3BSD.
>
> I do
> > Binary packages from third party software vendors.
>
> What about them? They either,
> a) link to a static libc, and use its rand() always; or
> b) link to a shared libc, and use its rand(), as the binary API hasn't
> changed; or
It isn't a question of the API. It's a question of expected funct
Edward Brocklesby wrote:
> On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
> > What I am suggesting is to leave random() as it is and
> > guarantee its behavior won't change and add cryto_random() or
> > whatever, and indicate it *may* change.
>
> Where was it indicated that random() wouldn'
Doug Barton wrote:
> I can think of one significant benefit... I had noticed that my perl
> script to pick random windowmaker themes (which uses rand()) seemed to be
> picking the same themes over and over again. Now I know why. :) I had to
> create a "last seen" list to artificially increase the "
Doug Barton <[EMAIL PROTECTED]> wrote:
>
>I can think of one significant benefit... I had noticed that my perl
>script to pick random windowmaker themes (which uses rand()) seemed to be
>picking the same themes over and over again.
That's a bug in perl's compile-time configuration. It can be told
On Monday 03 February 2003 12:18 am, Don wrote:
> It isn't a question of the API. It's a question of expected function
> output.
Then it's applicable not only to binary packages as Terry states, but any
source that uses rand().
> I run FreeBSD and not Linux because of the stability and predict
Thus spake Andrey A. Chernov <[EMAIL PROTECTED]>:
> On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
> > FreeBSD's rand() implementation has been broken for the past 23
> > months, since the following commit:
>
> > i.e. the first value returned from rand() is correlated with the seed
>
Steve Kargl wrote:
> I was going to stay out of this, but
>
> #include
> #include
> int main(void) {
> int i;
> long x;
> x = 100L;
> srandom(x);
> for (i = 0; i < 1010; i++) {
> x = random();
> printf("%ld\n", x);
> }
> return 0;
> }
>
> Last 10 digits.
>
> FreeBSD
> > It isn't a question of the API. It's a question of expected function
> > output.
>
> Then it's applicable not only to binary packages as Terry states, but any
> source that uses rand().
I think Terry mentioned binary packages simply because it is harder to fix
them than something available as s
On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> Edward Brocklesby wrote:
> > Where was it indicated that random() wouldn't change?
>
> Right there in the boot message, and again when you logged in,
> where the system indicated to you that it was a BSD system;
Sorry, I can't quite work
Mark Murray wrote:
> > That's why randomness tests + mathematician to interpretate their results
> > are needed to compare what we have now in random(3) with RC4. Easy and
> > understandable code not always mean better results. We can't switch
> > algorithms blindly, i.e. when their comparative qua
On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
>
> I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> those, but I'm pretty sure the reason you got a different answer
> for newer Solaris was because it uses the SVR4 code, instead.
>
That's the whole point! You sh
Terry Lambert wrote:
> > Last 10 digits.
> >
> > FreeBSD Redhat SunOS
> 386BSD 0.1+
> patchkitTRU64
Crap.
Ignore these numbers. I replaced the libc implementation on both
these machines, and forgot I had done it. When I put the code
back to what it was, they give the Solar
On Monday 03 February 2003 12:41 am, Don wrote:
> I think Terry mentioned binary packages simply because it is harder to fix
> them than something available as source but I could be mistaken.
Possibly -- if we're looking at this from the point of view of the user of
said binary package, rather th
Don wrote:
> > > It isn't a question of the API. It's a question of expected function
> > > output.
> >
> > Then it's applicable not only to binary packages as Terry states, but any
> > source that uses rand().
>
> I think Terry mentioned binary packages simply because it is harder to fix
> them t
Edward Brocklesby wrote:
> On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> > Edward Brocklesby wrote:
> > > Where was it indicated that random() wouldn't change?
> >
> > Right there in the boot message, and again when you logged in,
> > where the system indicated to you that it was a BS
Steve Kargl wrote:
> On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
> > I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> > those, but I'm pretty sure the reason you got a different answer
> > for newer Solaris was because it uses the SVR4 code, instead.
>
> That's
³¬Ò»Á÷ÍøÂçÊÓƵ»áÒé¡¢Ãâ·Ñµç»°¡¢Ô¶³Ì½Ìѧר¼Ò»áÕïϵͳ
±¾¹«Ë¾×îвúÆ·:ÍøÂçÊÓƵ»áÒéÊÓƵ·þÎñÆ÷---¹ã·ºÓÃÓÚ¸ßÇåÎú¶È¾ÖÓò»ò¹ãÓòÊÓƵ»áÒé¡¢ÍøÂç¼à¿Ø¡¢Ó׶ùÔ°¾´ÀÏÔººÍÒ½Ôº²¡·¿¼ÒÈËÒìµØÔ¶³Ì¼à»¤¡¢×¨¼ÒÔ¶³ÌÒ½ÁÆ»áÕïºÍ½Ìѧ¡¢ÍøÂçÔ¶³Ì½ÌÊÒÒÔ¼°ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ,ÍøÉÏ·ç¾°Çø,¾ÆµêʵʱÊÓƵչʾ¡¢µçÊÓ½ÚÄ¿ÍøÉÏʵʱת²¥¡¢´
On Thu, Jan 30, 2003 at 07:37:04PM -, Patrick Stinson wrote:
> has anyone every had problems with appending existing files on volumes
> mounted by smbfs or shlight?
>
> $ echo "sdsad" >> hey
> $ echo "sdsad" >> hey
> cannot create hey: Permission denied
Please try this patch and let me know
On Fri, 31 Jan 2003 13:24:49 +0100,
Michael Nottebrock <[EMAIL PROTECTED]> wrote:
> I'm sorry to have to bother you further, but this patch does not solve the
> problem completely. Amd works partially now, but I still get 'mountd rpc
> failed: RPC: Unable to receive' errors when I try to access
THis is repeatable for me at will.
5.0-current, supped as of 2/1.
4 80GIG maxtors on 2 promise IDE ultra 66 cards, exported via NFS.
newfs'd an 80G FS on each drive, created one big file filled with
zero's from /dev/zero on each drive. (Softupdates/UFS1)
login to my other box, which has the
101 - 156 of 156 matches
Mail list logo
