Searched hist:166 (Results 1 - 5 of 5) sorted by relevance

/freebsd-10.2-release/lib/libcrypt/
H A Dcrypt.cdiff 42981 Thu Jan 21 13:50:09 MST 1999 brandon Rewrite of crypt library to be more modular, and addition of the
Secure Hashing Algorithm - 1 (SHA-1), along with the further
refinement of what $x$salt$hash means. With this new crypt the
following are all acceptable:

$1$
$MD5$
$SHA1$

Note: $2$ is used by OpenBSD's Blowfish, which I considered adding
as $BF$, but there is no actual need for it with SHA-1. However,
somebody wishing to add OpenBSD password support could easilly add
it in now.

There is also a malloc_crypt() available in the library now, which
behaves exactly the same as crypt(), but it uses a malloced buffer
instead of a static buffer. However, this is not standard so will
likely not be used much (at all).

Also, for those interested I did a brief speed test Pentium 166/MMX,
which shows the DES crypt to do approximately 2640 crypts a CPU second,
MD5 to do about 62 crypts a CPU second and SHA1 to do about 18 crypts
a CPU second.

Reviewed by: Mark Murray
H A DMakefilediff 42981 Thu Jan 21 13:50:09 MST 1999 brandon Rewrite of crypt library to be more modular, and addition of the
Secure Hashing Algorithm - 1 (SHA-1), along with the further
refinement of what $x$salt$hash means. With this new crypt the
following are all acceptable:

$1$
$MD5$
$SHA1$

Note: $2$ is used by OpenBSD's Blowfish, which I considered adding
as $BF$, but there is no actual need for it with SHA-1. However,
somebody wishing to add OpenBSD password support could easilly add
it in now.

There is also a malloc_crypt() available in the library now, which
behaves exactly the same as crypt(), but it uses a malloced buffer
instead of a static buffer. However, this is not standard so will
likely not be used much (at all).

Also, for those interested I did a brief speed test Pentium 166/MMX,
which shows the DES crypt to do approximately 2640 crypts a CPU second,
MD5 to do about 62 crypts a CPU second and SHA1 to do about 18 crypts
a CPU second.

Reviewed by: Mark Murray
/freebsd-10.2-release/sys/dev/sound/pci/
H A Demu10k1.cdiff 153799 Wed Dec 28 17:57:36 MST 2005 netchild Fix the order of the stereo channels (left <-> right).

From the PR:
---snip---
I think I have found the change which reversed the channels.
Revision 1.44 of emu10k1.c, which added Audigy support, has the line

emu_wrptr(sc, v->vnum, FXRT, 0xd01c0000);

replaced with the following lines:

if (sc->audigy) {
emu_wrptr(sc, v->vnum, A_FXRT1, v->fxrt1);
emu_wrptr(sc, v->vnum, A_FXRT2, v->fxrt2);
emu_wrptr(sc, v->vnum, A_SENDAMOUNTS, 0);
}
else
emu_wrptr(sc, v->vnum, FXRT, v->fxrt1 << 16);

where v->fxrt1 << 16 == 0xd10c0000

I don't have Audigy, so I'm not sure if the problem affects Audigy cards
too. The order of the channels can't be tested by just altering mixer
settings. Here's a small program to test if the channels are reversed on
your sound card:

#include <sys/soundcard.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
int fd = open("/dev/dsp", O_WRONLY), format = AFMT_S16_LE;
int channels = 2, rate = 22050, i;

/* 450 Hz sine wave on left channel, right channel silent */
unsigned char samples[] = {0, 0, 0, 0, 94, 16, 0, 0, 120, 32, 0, 0,
9, 48, 0, 0, 208, 62, 0, 0, 143, 76, 0, 0, 12, 89, 0, 0, 19, 100,
0, 0, 117, 109, 0, 0, 11, 117, 0, 0, 182, 122, 0, 0, 92, 126, 0,
0, 239, 127, 0, 0, 105, 127, 0, 0, 202, 124, 0, 0, 32, 120, 0, 0,
124, 113, 0, 0, 251, 104, 0, 0, 193, 94, 0, 0, 249, 82, 0, 0,
212, 69, 0, 0, 138, 55, 0, 0, 85, 40, 0, 0, 120, 24, 0, 0, 51, 8,
0, 0, 205, 247, 0, 0, 136, 231, 0, 0, 171, 215, 0, 0, 118, 200,
0, 0, 44, 186, 0, 0, 7, 173, 0, 0, 63, 161, 0, 0, 5, 151, 0, 0,
132, 142, 0, 0, 224, 135, 0, 0, 54, 131, 0, 0, 151, 128, 0, 0,
17, 128, 0, 0, 164, 129, 0, 0, 74, 133, 0, 0, 245, 138, 0, 0,
139, 146, 0, 0, 237, 155, 0, 0, 244, 166, 0, 0, 113, 179, 0, 0,
48, 193, 0, 0, 247, 207, 0, 0, 136, 223, 0, 0, 162, 239, 0, 0};

ioctl(fd, SNDCTL_DSP_SETFMT,&format);
ioctl(fd, SNDCTL_DSP_CHANNELS,&channels);
ioctl(fd, SNDCTL_DSP_SPEED,&rate);

for(i=0;i<500;i++)
write(fd, &samples, sizeof(samples));
write(fd, &samples, 2); /* swap channels */
for(i=0;i<500;i++)
write(fd, &samples, sizeof(samples));

return 0;
}

You should hear a sound on the left channel followed by a sound on the
right channel. If you hear a sound on the right channel first, the
channels are reversed.
---snip---

Owners of an audigy card should verify if it DTRT and report back.

Noticed by: Matthias Buelow <mkb@mukappabeta.de>
Submitted by: Juha-Matti Tilli <juhis@nallukka.net>
PR: 72221
/freebsd-10.2-release/sys/i386/i386/
H A Dpmap.cdiff 15832 Tue May 21 00:39:39 MDT 1996 dyson To quote Stephen McKay: pmap_copy is a complex NOP at this moment :-).

With this fix from Stephen, we are getting the target fork performance
that I have been trying to attain: P5-166, before the mega-commit: 700-800usecs,
after: 600usecs, with Stephen's fix: 500usecs!!! Also, this could be the
solution of some strange panic problems...
Reviewed by: dyson@freebsd.org
Submitted by: Stephen McKay <syssgm@devetir.qld.gov.au>
/freebsd-10.2-release/sys/amd64/amd64/
H A Dpmap.cdiff 15832 Tue May 21 00:39:39 MDT 1996 dyson To quote Stephen McKay: pmap_copy is a complex NOP at this moment :-).

With this fix from Stephen, we are getting the target fork performance
that I have been trying to attain: P5-166, before the mega-commit: 700-800usecs,
after: 600usecs, with Stephen's fix: 500usecs!!! Also, this could be the
solution of some strange panic problems...
Reviewed by: dyson@freebsd.org
Submitted by: Stephen McKay <syssgm@devetir.qld.gov.au>

Completed in 469 milliseconds